- 09 Sep, 2019 2 commits
-
-
Sandeep Sheriker Mallikarjun authored
Add support for SAM9X60 irqchip. Signed-off-by:
Sandeep Sheriker Mallikarjun <sandeepsheriker.mallikarjun@microchip.com> Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1568026835-6646-1-git-send-email-claudiu.beznea@microchip.com [claudiu.beznea@microchip.com: update aic5_irq_fixups[], update documentation]
-
Talel Shenhar authored
Introduce interrupts retrigger support for Amazon's Annapurna Labs Fabric Interrupt Controller. Signed-off-by:
Talel Shenhar <talel@amazon.com> Signed-off-by:
-
- 05 Sep, 2019 2 commits
-
-
Marc Zyngier authored
When allocating a range of LPIs for a Multi-MSI capable device, this allocation extended to the closest power of 2. But on the release path, the interrupts are released one by one. This results in not releasing the "extra" range, leaking the its_device. Trying to reprobe the device will then fail. Fix it by releasing the LPIs the same way we allocate them. Fixes: 8208d170 ("irqchip/gic-v3-its: Align PCI Multi-MSI allocation on their size") Reported-by:
Jiaxing Luo <luojiaxing@huawei.com> Tested-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Masahiro Yamada authored
Replace the chain of platform_get_resource() and devm_ioremap_resource() with devm_platform_ioremap_resource(). This allows to remove the local variable for (struct resource *), and have one function call less. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
- 03 Sep, 2019 1 commit
-
-
Dexuan Cui authored
Recently device pass-through stops working for Linux VM running on Hyper-V. git-bisect shows the regression is caused by the recent commit 467a3bb9 ("PCI: hv: Allocate a named fwnode ..."), but the root cause is that the commit d59f6617 forgets to set the domain->fwnode for IRQCHIP_FWNODE_NAMED*, and as a result: 1. The domain->fwnode remains to be NULL. 2. irq_find_matching_fwspec() returns NULL since "h->fwnode == fwnode" is false, and pci_set_bus_msi_domain() sets the Hyper-V PCI root bus's msi_domain to NULL. 3. When the device is added onto the root bus, the device's dev->msi_domain is set to NULL in pci_set_msi_domain(). 4. When a device driver tries to enable MSI-X, pci_msi_setup_msi_irqs() calls arch_setup_msi_irqs(), which uses the native MSI chip (i.e. arch/x86/kernel/apic/msi.c: pci_msi_controller) to set up the irqs, but actually pci_msi_setup_msi_irqs() is supposed to call msi_domain_alloc_irqs() with the hbus->irq_domain, which is created in hv_pcie_init_irq_domain() and is associated with the Hyper-V chip hv_msi_irq_chip. Consequently, the irq line is not properly set up, and the device driver can not receive any interrupt. Fixes: d59f6617 ("genirq: Allow fwnode to carry name information only") Fixes: 467a3bb9 ("PCI: hv: Allocate a named fwnode instead of an address-based one") Reported-by:
Lili Deng <v-lide@microsoft.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
-
- 30 Aug, 2019 6 commits
-
-
Lubomir Rintel authored
On MMP3, the GIC can be set as a root IRQ interrupt controller. If the device tree indicated that GIC is enabled, avoid hooking up mmp2_handle_irq(). The interrupt muxes are still being used. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
-
Andres Salomon authored
On mmp3, there's an extra set of ICU registers (ICU2) that handle interrupts on the extra cores. When masking off interrupts on MP1, these should be masked as well. We add a new interrupt controller via device tree to identify when we're looking at an mmp3 machine via compatible field of "marvell,mmp3-intc". [lkundrak@v3.sk: Changed "mrvl,mmp3-intc" compatible strings to "marvell,mmp3-intc". Tidied up the subject line a bit.] Signed-off-by:
Andres Salomon <dilinger@queued.net> Signed-off-by:
-
Lubomir Rintel authored
The lack of chained_irq_exit() leaves the muxed interrupt masked on MMP3. For reasons unknown this is not a problem on MMP2. Signed-off-by:
-
Lubomir Rintel authored
The "regs" property of the "mrvl,mmp2-mux-intc" devices are silly. They are offsets from intc's base, not addresses on the parent bus. At this point it probably can't be fixed. On an OLPC XO-1.75 machine, the muxes are children of the intc, not the axi bus, and thus of_address_to_resource() won't work. We should treat the values as mere integers as opposed to bus addresses. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20190822092643.593488-7-lkundrak@v3.sk
-
Jerome Brunet authored
The meson sm1 SoCs uses the same type of GPIO interrupt controller IP block as the other meson SoCs, A total of 100 pins can be spied on: - 223:100 undefined (no interrupt) - 99:97 3 pins on bank GPIOE - 96:77 20 pins on bank GPIOX - 76:61 16 pins on bank GPIOA - 60:53 8 pins on bank GPIOC - 52:37 16 pins on bank BOOT - 36:28 9 pins on bank GPIOH - 27:12 16 pins on bank GPIOZ - 11:0 12 pins in the AO domain Mapping is the same as the g12a family but the sm1 controller allows to trig an irq on both edges of the input signal. This was not possible with the previous SoCs families Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Reviewed-by:
-
Jerome Brunet authored
Update the dt-binding to add support for the sm1 SoC family in the amlogic GPIO interrupt controller driver. Signed-off-by:
-
- 20 Aug, 2019 16 commits
-
-
Stephen Boyd authored
We don't need dev_err() messages when platform_get_irq() fails now that platform_get_irq() prints an error message itself when something goes wrong. Let's remove these prints with a simple semantic patch. // <smpl> @@ expression ret; struct platform_device *E; @@ ret = ( platform_get_irq(E, ...) | platform_get_irq_byname(E, ...) ); if ( \( ret < 0 \| ret <= 0 \) ) { ( -if (ret != -EPROBE_DEFER) -{ ... -dev_err(...); -... } | ... -dev_err(...); ) ... } // </smpl> While we're here, remove braces on if statements that only have one statement (manually). Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
Masahiro Yamada authored
Add a header include guard just in case. Signed-off-by:
-
Lubomir Rintel authored
Using a default domain on DT platforms is unnecessary, as the firmware tables describe the full topology, and nothing is implicit. Signed-off-by:
-
Zenghui Yu authored
We try to find a free LPI region in device's lpi_map and allocate them (set them to 1) when we want to allocate LPIs for this device. This is what bitmap_find_free_region() has done for us. The following set_bit is redundant and a bit confusing (since we only set_bit against the first allocated LPI idx). Remove it, and make the set_bit explicit by comment. Signed-off-by:
Zenghui Yu <yuzenghui@huawei.com> Signed-off-by:
-
Marc Zyngier authored
It looks like the HIP06/07 SoCs have extra bits in their GICD_TYPER registers, which confuse the GICv3.1 code (these systems appear to expose ESPIs while they actually don't). Detect these systems as early as possible and wipe the fields that should be RES0 in the register. Tested-by:
-
Marc Zyngier authored
When evaluating potential quirks matched by reads of the IIDR register, skip the quirk entries that use a "compatible" property attached to them, as these are DT based. Signed-off-by: -
Marc Zyngier authored
As is it usual for the GIC, it isn't disallowed to put together a system that is majorly inconsistent, with a distributor supporting the extended ranges while some of the CPUs don't. Kindly tell the user that things are sailing isn't going to be smooth. Signed-off-by: -
Marc Zyngier authored
Expand the pre-existing PPI support to be able to deal with the Extended PPI range (EPPI). This includes obtaining the number of PPIs from each individual redistributor, and compute the minimum set (just in case someone builds something really clever...). Signed-off-by: -
Marc Zyngier authored
Update the GICv3 binding to allow interrupts in the EPPI range. Signed-off-by: -
Marc Zyngier authored
Again, PPIs are becoming a variable set. Let's hack the PPI partition code to make the top-level array dynamically allocated. Signed-off-by: -
Marc Zyngier authored
As we're about to have a variable number of PPIs, let's make the allocation of the NMI refcounts dynamic. Also apply some minor cleanups (moving things around). Signed-off-by: -
Marc Zyngier authored
GICv3.1 allows up to 80 PPIs (16 legaci PPIs and 64 Extended PPIs), meaning we can't just leave the old 16 hardcoded everywhere. We also need to add the infrastructure to discover the number of PPIs on a per redistributor basis, although we still pretend there is only 16 of them for now. No functional change. Signed-off-by: -
Marc Zyngier authored
Add the required support for the ESPI range, which behave exactly like the SPIs of old, only with new funky INTIDs. Signed-off-by: -
Marc Zyngier authored
GICv3.1 introduces support for new interrupt ranges, one of them being the Extended SPI range (ESPI). The DT binding is extended to deal with it as a new interrupt class. Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
-
Marc Zyngier authored
In the beginning, life was simple. The GIC driver mostly cared about PPIs, SPIs and LPIs, all with nicely layed out ranges. We're about to change all that, with new ranges such as EPPI and ESPI interleaved in the middle of the no-irq-land between the "special IDs" and the LPI range. Boo. In order to make our life less hellish, let's introduce a set of primitives that will allow ranges to be identified easily and offsets to be remapped. So far, there is no functionnal change. Signed-off-by: -
Marc Zyngier authored
gic_configure_irq is currently passed the (re)distributor address, to which it applies an a fixed offset to get to the configuration registers. This offset is constant across all GICs, or rather it was until to v3.1... An easy way out is for the individual drivers to pass the base address of the configuration register for the considered interrupt. At the same time, move part of the error handling back to the individual drivers, as things are about to change on that front. Signed-off-by:
-
- 07 Aug, 2019 8 commits
-
-
Marc Zyngier authored
Booting a large arm64 server (HiSi D05) leads to the following shouting at boot time: [ 20.722132] debugfs: File 'irqchip@(____ptrval____)-3' in directory 'domains' already present! [ 20.730851] debugfs: File 'irqchip@(____ptrval____)-3' in directory 'domains' already present! [ 20.739560] debugfs: File 'irqchip@(____ptrval____)-3' in directory 'domains' already present! [ 20.748267] debugfs: File 'irqchip@(____ptrval____)-3' in directory 'domains' already present! [ 20.756975] debugfs: File 'irqchip@(____ptrval____)-3' in directory 'domains' already present! [ 20.765683] debugfs: File 'irqchip@(____ptrval____)-3' in directory 'domains' already present! [ 20.774391] debugfs: File 'irqchip@(____ptrval____)-3' in directory 'domains' already present! and many more... Evidently, we expect something a bit more informative than ____ptrval____, and certainly we want all of our domains, not just the first one. For that, turn the %p used to generate the fwnode name into something that won't be repainted (%pa). Given that we've now fixed all users to pass a pointer to a PA, it will actually do the right thing. Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Marc Zyngier authored
To allocate its fwnode that is then used to allocate an irqdomain, the driver uses irq_domain_alloc_fwnode(), passing it a VA as an identifier. This is a rather bad idea, as this address ends up published in debugfs (and we want to move away from VAs there anyway). Instead, let's allocate a named fwnode by using the device GUID as an identifier. It is allegedly unique, and can be traced back to the original device. Acked-by:
-
Marc Zyngier authored
Do not expose the base VA (it appears in debugfs). Instead, record the PA, which at least can be used to precisely identify the associated irqchip and domain. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
-
Marc Zyngier authored
Do not expose the base VA (it appears in debugfs). Instead, record the PA, which at least can be used to precisely identify the associated irqchip and domain. Acked-by:
-
Marc Zyngier authored
Do not expose the frame's VA (it appears in debugfs). Instead, record the PA, which at least can be used to precisely identify the associated irqchip and domain. Acked-by:
-
Marc Zyngier authored
Do not expose the distributor's VA (it appears in debugfs). Instead, record the PA, which at least can be used to precisely identify the associated irqchip and domain. Acked-by:
-
Marc Zyngier authored
Do not expose the ITS' VA (it appears in debugfs). Instead, record the PA, which at least can be used to precisely identify the associated irqchip and domain. Acked-by:
-
Marc Zyngier authored
Do not expose the distributor's VA (it appears in debugfs). Instead, record the PA, which at least can be used to precisely identify the associated irqchip and domain. Acked-by:
-
- 05 Aug, 2019 1 commit
-
-
Linus Torvalds authored
-
- 04 Aug, 2019 4 commits
-
-
git://git.infradead.org/users/jjs/linux-tpmddLinus Torvalds authored
Pull tpm fixes from Jarkko Sakkinen: "Two bug fixes that did not make into my first pull request" * tag 'tpmdd-next-20190805' of git://git.infradead.org/users/jjs/linux-tpmdd: tpm: tpm_ibm_vtpm: Fix unallocated banks tpm: Fix null pointer dereference on chip register error path
-
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linuxLinus Torvalds authored
Pull MTD fixes from Miquel Raynal: "NAND: - Fix Micron driver as some chips enable internal ECC correction during their discovery while they advertize they do not have any. Hyperbus: - Restrict the build to only ARM64 SoCs (and compile testing) which is what should have been done since the beginning. - Fix Kconfig issue by selection something instead of implying it" * tag 'mtd/fixes-for-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: hyperbus: Add hardware dependency to AM654 driver mtd: hyperbus: Kconfig: Fix HBMC_AM654 dependencies mtd: rawnand: micron: handle on-die "ECC-off" devices correctly -
Nayna Jain authored
The nr_allocated_banks and allocated banks are initialized as part of tpm_chip_register. Currently, this is done as part of auto startup function. However, some drivers, like the ibm vtpm driver, do not run auto startup during initialization. This results in uninitialized memory issue and causes a kernel panic during boot. This patch moves the pcr allocation outside the auto startup function into tpm_chip_register. This ensures that allocated banks are initialized in any case. Fixes: 879b5892 ("tpm: retrieve digest size of unknown algorithms with PCR read") Reported-by:
Michal Suchanek <msuchanek@suse.de> Signed-off-by:
Nayna Jain <nayna@linux.ibm.com> Reviewed-by:
Mimi Zohar <zohar@linux.ibm.com> Tested-by:
Sachin Sant <sachinp@linux.vnet.ibm.com> Tested-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
-
Milan Broz authored
If clk_enable is not defined and chip initialization is canceled code hits null dereference. Easily reproducible with vTPM init fail: swtpm chardev --tpmstate dir=nonexistent_dir --tpm2 --vtpm-proxy BUG: kernel NULL pointer dereference, address: 00000000 ... Call Trace: tpm_chip_start+0x9d/0xa0 [tpm] tpm_chip_register+0x10/0x1a0 [tpm] vtpm_proxy_work+0x11/0x30 [tpm_vtpm_proxy] process_one_work+0x214/0x5a0 worker_thread+0x134/0x3e0 ? process_one_work+0x5a0/0x5a0 kthread+0xd4/0x100 ? process_one_work+0x5a0/0x5a0 ? kthread_park+0x90/0x90 ret_from_fork+0x19/0x24 Fixes: 719b7d81 ("tpm: introduce tpm_chip_start() and tpm_chip_stop()") Cc: stable@vger.kernel.org # v5.1+ Signed-off-by:
Milan Broz <gmazyland@gmail.com> Reviewed-by:
-
