summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* xen/events: Implement irq distributionThomas Gleixner2020-12-151-8/+68
| | | | | | | | | | | | | | Keep track of the assignments of event channels to CPUs and select the online CPU with the least assigned channels in the affinity mask which is handed to irq_chip::irq_set_affinity() from the core code. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194045.457218278@linutronix.de
* xen/events: Reduce irq_info:: Spurious_cnt storage sizeThomas Gleixner2020-12-151-3/+5
| | | | | | | | | | | | | | | | To prepare for interrupt spreading reduce the storage size of irq_info::spurious_cnt to u8 so the required flag for the spreading logic will not increase the storage size. Protect the usage site against overruns. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194045.360198201@linutronix.de
* xen/events: Only force affinity mask for percpu interruptsThomas Gleixner2020-12-151-14/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All event channel setups bind the interrupt on CPU0 or the target CPU for percpu interrupts and overwrite the affinity mask with the corresponding cpumask. That does not make sense. The XEN implementation of irqchip::irq_set_affinity() already picks a single target CPU out of the affinity mask and the actual target is stored in the effective CPU mask, so destroying the user chosen affinity mask which might contain more than one CPU is wrong. Change the implementation so that the channel is bound to CPU0 at the XEN level and leave the affinity mask alone. At startup of the interrupt affinity will be assigned out of the affinity mask and the XEN binding will be updated. Only keep the enforcement for real percpu interrupts. On resume the overwrite is not required either because info->cpu and the affinity mask are still the same as at the time of suspend. Same for rebind_evtchn_irq(). This also prepares for proper interrupt spreading. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194045.250321315@linutronix.de
* xen/events: Use immediate affinity settingThomas Gleixner2020-12-151-26/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | There is absolutely no reason to mimic the x86 deferred affinity setting. This mechanism is required to handle the hardware induced issues of IO/APIC and MSI and is not in use when the interrupts are remapped. XEN does not need this and can simply change the affinity from the calling context. The core code invokes this with the interrupt descriptor lock held so it is fully serialized against any other operation. Mark the interrupts with IRQ_MOVE_PCNTXT to disable the deferred affinity setting. The conditional mask/unmask operation is already handled in xen_rebind_evtchn_to_cpu(). This makes XEN on x86 use the same mechanics as on e.g. ARM64 where deferred affinity setting is not required and not implemented and the code path in the ack functions is compiled out. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194045.157601122@linutronix.de
* xen/events: Remove disfunct affinity spreadingThomas Gleixner2020-12-152-42/+1
| | | | | | | | | | | | | | | | | | | | | | | | This function can only ever work when the event channels: - are already established - interrupts assigned to them - the affinity has been set by user space already because any newly set up event channel is forced to be bound to CPU0 and the affinity mask of the interrupt is forced to contain cpumask_of(0). As the CPU0 enforcement was in place _before_ this was implemented it's entirely unclear how that can ever have worked at all. Remove it as preparation for doing it proper. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194045.065115500@linutronix.de
* xen/events: Remove unused bind_evtchn_to_irq_lateeoi()Thomas Gleixner2020-12-151-6/+0
| | | | | | | | | | Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Juergen Gross <jgross@suse.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20201210194044.972064156@linutronix.de
* net/mlx5: Use effective interrupt affinityThomas Gleixner2020-12-151-1/+1
| | | | | | | | | | | | | | | | Using the interrupt affinity mask for checking locality is not really working well on architectures which support effective affinity masks. The affinity mask is either the system wide default or set by user space, but the architecture can or even must reduce the mask to the effective set, which means that checking the affinity mask itself does not really tell about the actual target CPUs. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20201210194044.876342330@linutronix.de
* net/mlx5: Replace irq_to_desc() abuseThomas Gleixner2020-12-153-7/+3
| | | | | | | | | | | | | | | | | | No driver has any business with the internals of an interrupt descriptor. Storing a pointer to it just to use yet another helper at the actual usage site to retrieve the affinity mask is creative at best. Just because C does not allow encapsulation does not mean that the kernel has no limits. Retrieve a pointer to the affinity mask itself and use that. It's still using an interface which is usually not for random drivers, but definitely less hideous than the previous hack. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20201210194044.769458162@linutronix.de
* net/mlx4: Use effective interrupt affinityThomas Gleixner2020-12-151-1/+1
| | | | | | | | | | | | | | | | Using the interrupt affinity mask for checking locality is not really working well on architectures which support effective affinity masks. The affinity mask is either the system wide default or set by user space, but the architecture can or even must reduce the mask to the effective set, which means that checking the affinity mask itself does not really tell about the actual target CPUs. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20201210194044.672935978@linutronix.de
* net/mlx4: Replace irq_to_desc() abuseThomas Gleixner2020-12-153-11/+6
| | | | | | | | | | | | | | | | | | No driver has any business with the internals of an interrupt descriptor. Storing a pointer to it just to use yet another helper at the actual usage site to retrieve the affinity mask is creative at best. Just because C does not allow encapsulation does not mean that the kernel has no limits. Retrieve a pointer to the affinity mask itself and use that. It's still using an interface which is usually not for random drivers, but definitely less hideous than the previous hack. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20201210194044.580936243@linutronix.de
* PCI: mobiveil: Use irq_data_get_irq_chip_data()Thomas Gleixner2020-12-151-6/+2
| | | | | | | | | | | | | | | | | | Going through a full irq descriptor lookup instead of just using the proper helper function which provides direct access is suboptimal. In fact it _is_ wrong because the chip callback needs to get the chip data which is relevant for the chip while using the irq descriptor variant returns the irq chip data of the top level chip of a hierarchy. It does not matter in this case because the chip is the top level chip, but that doesn't make it more correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20201210194044.473308721@linutronix.de
* PCI: xilinx-nwl: Use irq_data_get_irq_chip_data()Thomas Gleixner2020-12-151-6/+2
| | | | | | | | | | | | | | | | | | Going through a full irq descriptor lookup instead of just using the proper helper function which provides direct access is suboptimal. In fact it _is_ wrong because the chip callback needs to get the chip data which is relevant for the chip while using the irq descriptor variant returns the irq chip data of the top level chip of a hierarchy. It does not matter in this case because the chip is the top level chip, but that doesn't make it more correct. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20201210194044.364211860@linutronix.de
* NTB/msi: Use irq_has_action()Thomas Gleixner2020-12-151-3/+1
| | | | | | | | | | Use the proper core function. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Link: https://lore.kernel.org/r/20201210194044.255887860@linutronix.de
* mfd: ab8500-debugfs: Remove the racy fiddling with irq_descThomas Gleixner2020-12-151-13/+3
| | | | | | | | | | | | | | | | | | | | | First of all drivers have absolutely no business to dig into the internals of an irq descriptor. That's core code and subject to change. All of this information is readily available to /proc/interrupts in a safe and race free way. Remove the inspection code which is a blatant violation of subsystem boundaries and racy against concurrent modifications of the interrupt descriptor. Print the irq line instead so the information can be looked up in a sane way in /proc/interrupts. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20201210194044.157283633@linutronix.de
* pinctrl: nomadik: Use irq_has_action()Thomas Gleixner2020-12-151-5/+6
| | | | | | | | | | Let the core code do the fiddling with irq_desc. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201210194044.065003856@linutronix.de
* drm/i915/pmu: Replace open coded kstat_irqs() copyThomas Gleixner2020-12-153-18/+43
| | | | | | | | | | | | | | | | | | | | | | Driver code has no business with the internals of the irq descriptor. Aside of that the count is per interrupt line and therefore takes interrupts from other devices into account which share the interrupt line and are not handled by the graphics driver. Replace it with a pmu private count which only counts interrupts which originate from the graphics card. To avoid atomics or heuristics of some sort make the counter field 'unsigned long'. That limits the count to 4e9 on 32bit which is a lot and postprocessing can easily deal with the occasional wraparound. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://lore.kernel.org/r/20201210194043.957046529@linutronix.de
* drm/i915/lpe_audio: Remove pointless irq_to_desc() usageThomas Gleixner2020-12-151-4/+0
| | | | | | | | | | | Nothing uses the result and nothing should ever use it in driver code. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20201210194043.862572239@linutronix.de
* s390/irq: Use irq_desc_kstat_cpu() in show_msi_interrupt()Thomas Gleixner2020-12-151-1/+1
| | | | | | | | | | The irq descriptor is already there, no need to look it up again. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20201210194043.769108348@linutronix.de
* parisc/irq: Use irq_desc_kstat_cpu() in show_interrupts()Thomas Gleixner2020-12-151-1/+1
| | | | | | | | | | The irq descriptor is already there, no need to look it up again. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: linux-parisc@vger.kernel.org Link: https://lore.kernel.org/r/20201210194043.659522455@linutronix.de
* arm64/smp: Use irq_desc_kstat_cpu() in arch_show_interrupts()Thomas Gleixner2020-12-151-1/+1
| | | | | | | | | | The irq descriptor is already there, no need to look it up again. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201210194043.546326568@linutronix.de
* ARM: smp: Use irq_desc_kstat_cpu() in show_ipi_list()Thomas Gleixner2020-12-151-1/+1
| | | | | | | | | | The irq descriptor is already there, no need to look it up again. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201210194043.454288890@linutronix.de
* genirq: Provide kstat_irqdesc_cpu()Thomas Gleixner2020-12-152-2/+8
| | | | | | | | | | | | Most users of kstat_irqs_cpu() have the irq descriptor already. No point in calling into the core code and looking it up once more. Use it in per_cpu_count_show() to start with. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201210194043.362094758@linutronix.de
* genirq: Make kstat_irqs() staticThomas Gleixner2020-12-152-14/+6
| | | | | | | | | No more users outside the core code. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201210194043.268774449@linutronix.de
* parisc/irq: Simplify irq count output for /proc/interruptsThomas Gleixner2020-12-151-4/+1
| | | | | | | | | | The SMP variant works perfectly fine on UP as well. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: linux-parisc@vger.kernel.org Link: https://lore.kernel.org/r/20201210194043.172893840@linutronix.de
* genirq: Annotate irq stats data racesThomas Gleixner2020-12-152-4/+5
| | | | | | | | | | | Both the per cpu stats and the accumulated count are accessed lockless and can be concurrently modified. That's intentional and the stats are a rough estimate anyway. Annotate them with data_race(). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201210194043.067097663@linutronix.de
* genirq: Provide irq_get_effective_affinity()Thomas Gleixner2020-12-151-0/+7
| | | | | | | | | | Provide an accessor to the effective interrupt affinity mask. Going to be used to replace open coded fiddling with the irq descriptor. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201210194042.967177918@linutronix.de
* genirq: Move irq_set_lockdep_class() to coreThomas Gleixner2020-12-152-6/+18
| | | | | | | | | irq_set_lockdep_class() is used from modules and requires irq_to_desc() to be exported. Move it into the core code which lifts another requirement for the export. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201210194042.860029489@linutronix.de
* genirq: Move status flag checks to coreThomas Gleixner2020-12-152-12/+25
| | | | | | | | | | These checks are used by modules and prevent the removal of the export of irq_to_desc(). Move the accessor into the core. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201210194042.703779349@linutronix.de
* genirq: Move irq_has_action() into core codeThomas Gleixner2020-12-155-7/+21
| | | | | | | | | | | | | | This function uses irq_to_desc() and is going to be used by modules to replace the open coded irq_to_desc() (ab)usage. The final goal is to remove the export of irq_to_desc() so driver cannot fiddle with it anymore. Move it into the core code and fixup the usage sites to include the proper header. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201210194042.548936472@linutronix.de
* Merge tag 'irqchip-5.11' of ↵Thomas Gleixner2020-12-151468-9236/+19693
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates for 5.11 from Marc Zyngier: - Preliminary support for managed interrupts on platform devices - Correctly identify allocation of MSIs proxyied by another device - Remove the fasteoi IPI flow which has been proved useless - Generalise the Ocelot support to new SoCs - Improve GICv4.1 vcpu entry, matching the corresponding KVM optimisation - Work around spurious interrupts on Qualcomm PDC - Random fixes and cleanups Link: https://lore.kernel.org/r/20201212135626.1479884-1-maz@kernel.org
| * irqchip/qcom-pdc: Fix phantom irq when changing between rising/fallingDouglas Anderson2020-12-121-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a problem if we use gpio-keys and configure wakeups such that we only want one edge to wake us up. AKA: wakeup-event-action = <EV_ACT_DEASSERTED>; wakeup-source; Specifically we end up with a phantom interrupt that blocks suspend if the line was already high and we want wakeups on rising edges (AKA we want the GPIO to go low and then high again before we wake up). The opposite is also problematic. Specifically, here's what's happening today: 1. Normally, gpio-keys configures to look for both edges. Due to the current workaround introduced in commit c3c0c2e18d94 ("pinctrl: qcom: Handle broken/missing PDC dual edge IRQs on sc7180"), if the line was high we'd configure for falling edges. 2. At suspend time, we change to look for rising edges. 3. After qcom_pdc_gic_set_type() runs, we get a phantom interrupt. We can solve this by just clearing the phantom interrupt. NOTE: it is possible that this could cause problems for a client with very specific needs, but there's not much we can do with this hardware. As an example, let's say the interrupt signal is currently high and the client is looking for falling edges. The client now changes to look for rising edges. The client could possibly expect that if the line has a short pulse low (and back high) that it would always be detected. Specifically no matter when the pulse happened, it should either have tripped the (old) falling edge trigger or the (new) rising edge trigger. We will simply not trip it. We could narrow down the race a bit by polling our parent before changing types, but no matter what we do there will still be a period of time where we can't tell the difference between a real transition (or more than one transition) and the phantom. Fixes: f55c73aef890 ("irqchip/pdc: Add PDC interrupt controller for QCOM SoCs") Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20201211141514.v4.1.I2702919afc253e2a451bebc3b701b462b2d22344@changeid
| * driver core: platform: Add devm_platform_get_irqs_affinity()John Garry2020-12-112-0/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drivers for multi-queue platform devices may also want managed interrupts for handling HW queue completion interrupts, so add support. The function accepts an affinity descriptor pointer, which covers all IRQs expected for the device. The function is devm class as the only current in-tree user will also use devm method for requesting the interrupts; as such, the function is made as devm as it can ensure ordering of freeing the irq and disposing of the mapping. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1606905417-183214-5-git-send-email-john.garry@huawei.com
| * ACPI: Drop acpi_dev_irqresource_disabled()John Garry2020-12-111-12/+5
| | | | | | | | | | | | | | | | | | | | | | The functionality of acpi_dev_irqresource_disabled() is same as in common irqresource_disabled(), so drop acpi_dev_irqresource_disabled() in favour of that function. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/1606905417-183214-4-git-send-email-john.garry@huawei.com
| * resource: Add irqresource_disabled()John Garry2020-12-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | Add a common function to set the fields for a irq resource to disabled, which mimics what is done in acpi_dev_irqresource_disabled(), with a view to replace that function. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/1606905417-183214-3-git-send-email-john.garry@huawei.com
| * genirq/affinity: Add irq_update_affinity_desc()John Garry2020-12-112-0/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a function to allow the affinity of an interrupt be switched to managed, such that interrupts allocated for platform devices may be managed. This new interface has certain limitations, and attempts to use it in the following circumstances will fail: - For when the kernel is configured for generic IRQ reservation mode (in config GENERIC_IRQ_RESERVATION_MODE). The reason being that it could conflict with managed vs. non-managed interrupt accounting. - The interrupt is already started, which should not be the case during init - The interrupt is already configured as managed, which means double init Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1606905417-183214-2-git-send-email-john.garry@huawei.com
| * irqchip/gic-v3-its: Flag device allocation as proxied if behind a PCI bridgeMarc Zyngier2020-12-111-3/+8
| | | | | | | | | | | | | | | | | | | | An aliasing PCI bridge is another case where we should flag the corresponding allocation as "proxied", as MSIs are coming with the bridge's RID, and not the originating device's. Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20201129135208.680293-4-maz@kernel.org
| * irqchip/gic-v3-its: Tag ITS device as shared if allocating for a proxy deviceMarc Zyngier2020-12-111-0/+3
| | | | | | | | | | | | | | | | | | The ITS already has some notion of "shared" devices. Let's map the MSI_ALLOC_FLAGS_PROXY_DEVICE flag onto this internal property. Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20201129135208.680293-3-maz@kernel.org
| * platform-msi: Track shared domain allocationMarc Zyngier2020-12-112-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have two flavours of platform-MSI: - MSIs generated by devices for themselves (the usual case) - MSIs generated on behalf of other devices, as the generating device is some form of bridge (either a wire-to-MSI bridge, or even a non-transparent PCI bridge that repaints the PCI requester ID). In the latter case, the underlying interrupt architecture may need to track this in order to keep the mapping alive even when no MSI are currently being generated. Add a set of flags to the generic msi_alloc_info_t structure, as well as the MSI_ALLOC_FLAGS_PROXY_DEVICE flag that will get advertized by the platform-MSI code when allocating an irqdomain for a device. Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20201129135208.680293-2-maz@kernel.org
| * irqchip/ti-sci-intr: Fix freeing of irqsLokesh Vutla2020-12-111-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ti_sci_intr_irq_domain_free() assumes that out_irq of intr is stored in data->chip_data and uses it for calling ti_sci irq_free() and then mark the out_irq as available resource. But ti_sci_intr_irq_domain_alloc() is storing p_hwirq(parent's hardware irq) which is translated from out_irq. This is causing resource leakage and eventually out_irq resources might be exhausted. Fix ti_sci_intr_irq_domain_alloc() by storing the out_irq in data->chip_data. Fixes: a5b659bd4bc7 ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR") Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201102120631.11165-1-lokeshvutla@ti.com
| * irqchip/ti-sci-inta: Fix printing of inta id on probe successLokesh Vutla2020-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | On a successful probe, the driver tries to print a success message with INTA device id. It uses pdev->id for printing the id but id is stored in inta->ti_sci_id. Fix it by correcting the dev_info parameter. Fixes: 5c4b585d2910 ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC") Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201102120614.11109-1-lokeshvutla@ti.com
| * drivers/irqchip: Remove EZChip NPS interrupt controllerVineet Gupta2020-12-113-173/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | NPS platform has been removed from ARC port and there are no in-tree users of it now. So RIP ! Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <maz@kernel.org> Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20201105212210.1891598-3-vgupta@synopsys.com
| * Revert "genirq: Add fasteoi IPI flow"Valentin Schneider2020-12-112-28/+0
| | | | | | | | | | | | | | | | | | | | | | | | handle_percpu_devid_fasteoi_ipi() has no more users, and handle_percpu_devid_irq() can do all that it was supposed to do. Get rid of it. This reverts commit c5e5ec033c4ab25c53f1fd217849e75deb0bf7bf. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201109094121.29975-6-valentin.schneider@arm.com
| * irqchip/hip04: Make IPIs use handle_percpu_devid_irq()Valentin Schneider2020-12-111-5/+1
| | | | | | | | | | | | | | | | | | As done for the Arm GIC irqchips, move IPIs to handle_percpu_devid_irq() as handle_percpu_devid_fasteoi_ipi() isn't actually required. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201109094121.29975-5-valentin.schneider@arm.com
| * irqchip/bcm2836: Make IPIs use handle_percpu_devid_irq()Valentin Schneider2020-12-111-1/+1
| | | | | | | | | | | | | | | | | | As done for the Arm GIC irqchips, move IPIs to handle_percpu_devid_irq() as handle_percpu_devid_fasteoi_ipi() isn't actually required. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201109094121.29975-4-valentin.schneider@arm.com
| * irqchip/armada-370-xp: Make IPIs use handle_percpu_devid_irq()Valentin Schneider2020-12-111-1/+1
| | | | | | | | | | | | | | | | | | As done for the Arm GIC irqchips, move IPIs to handle_percpu_devid_irq() as handle_percpu_devid_fasteoi_ipi() isn't actually required. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201109094121.29975-3-valentin.schneider@arm.com
| * irqchip/gic, gic-v3: Make SGIs use handle_percpu_devid_irq()Valentin Schneider2020-12-112-13/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | handle_percpu_devid_fasteoi_ipi() states: * The biggest difference with the IRQ version is that the interrupt is * EOIed early, as the IPI could result in a context switch, and we need to * make sure the IPI can fire again All that can actually happen scheduler-wise within the handling of an IPI is the raising of TIF_NEED_RESCHED (and / or folding thereof into preempt_count); see scheduler_ipi() or sched_ttwu_pending() for instance. Said flag / preempt_count is evaluated some time later before returning to whatever context was interrupted, and this gates a call to preempt_schedule_irq() (arm64_preempt_schedule_irq() in arm64). Per the above, SGI's do not need a different handler than PPI's, so make them use the same (handle_percpu_devid_irq). Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20201109094121.29975-2-valentin.schneider@arm.com
| * irqchip/ocelot: Add support for Jaguar2 platformsGregory CLEMENT2020-12-111-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | This patch extends irqchip driver for ocelot to be used with an other vcoreiii base platform: Jaguar2. Based on a larger patch from Lars Povlsen <lars.povlsen@microchip.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201125103206.136498-7-gregory.clement@bootlin.com
| * irqchip/ocelot: Add support for Serval platformsGregory CLEMENT2020-12-111-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | This patch extends irqchip driver for ocelot to be used with an other vcoreiii base platform: Serval. Based on a larger patch from Lars Povlsen <lars.povlsen@microchip.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201125103206.136498-6-gregory.clement@bootlin.com
| * irqchip/ocelot: Add support for Luton platformsGregory CLEMENT2020-12-111-4/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch extends irqchip driver for oceleot to be used with an other vcoreiii base platform: Luton. For this platform there is a few differences: - the interrupt must be enabled for the parent controller - there is no trigger register needed to be managed Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201125103206.136498-5-gregory.clement@bootlin.com
| * irqchip/ocelot: prepare to support more SoCGregory CLEMENT2020-12-111-22/+54
| | | | | | | | | | | | | | | | | | | | This patch extends irqchip driver for oceleot to be used with other vcoreiii base platforms. Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201125103206.136498-4-gregory.clement@bootlin.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-26 11:06:34 +0100