kernel/linux.git/drivers/pci, branch v4.14.217

PCI: Fix pci_slot_release() NULL pointer dereference

2020-12-29T12:47:11+00:00

commit 4684709bf81a2d98152ed6b610e3d5c403f9bced upstream. If kobject_init_and_add() fails, pci_slot_release() is called to delete slot->list from parent->slots. But slot->list hasn't been initialized yet, so we dereference a NULL pointer: Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... CPU: 10 PID: 1 Comm: swapper/0 Not tainted 4.4.240 #197 task: ffffeb398a45ef10 task.stack: ffffeb398a470000 PC is at __list_del_entry_valid+0x5c/0xb0 LR is at pci_slot_release+0x84/0xe4 ... __list_del_entry_valid+0x5c/0xb0 pci_slot_release+0x84/0xe4 kobject_put+0x184/0x1c4 pci_create_slot+0x17c/0x1b4 __pci_hp_initialize+0x68/0xa4 pciehp_probe+0x1a4/0x2fc pcie_port_probe_service+0x58/0x84 driver_probe_device+0x320/0x470 Initialize slot->list before calling kobject_init_and_add() to avoid this. Fixes: 8a94644b440e ("PCI: Fix pci_create_slot() reference count leak") Link: https://lore.kernel.org/r/1606876422-117457-1-git-send-email-zhongjubin@huawei.com Signed-off-by: Jubin Zhong Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v5.9+ Signed-off-by: Greg Kroah-Hartman

PM: ACPI: PCI: Drop acpi_pm_set_bridge_wakeup()

2020-12-29T12:47:04+00:00

commit 7482c5cb90e5a7f9e9e12dd154d405e0219656e3 upstream. The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to be reference counted for wakeup enabling, because they may be enabled to signal wakeup on behalf of their subordinate devices and that may happen for multiple times in a row, whereas for the other devices it only makes sense to enable wakeup signaling once. However, this becomes problematic if the bridge itself is suspended, because it is treated as a "regular" device in that case and the reference counting doesn't work. For instance, suppose that there are two devices below a bridge and they both can signal wakeup. Every time one of them is suspended, wakeup signaling is enabled for the bridge, so when they both have been suspended, the bridge's wakeup reference counter value is 2. Say that the bridge is suspended subsequently and acpi_pci_wakeup() is called for it. Because the bridge can signal wakeup, that function will invoke acpi_pm_set_device_wakeup() to configure it and __acpi_pm_set_device_wakeup() will be called with the last argument equal to 1. This causes __acpi_device_wakeup_enable() invoked by it to omit the reference counting, because the reference counter of the target device (the bridge) is 2 at that time. Now say that the bridge resumes and one of the device below it resumes too, so the bridge's reference counter becomes 0 and wakeup signaling is disabled for it, but there is still the other suspended device which may need the bridge to signal wakeup on its behalf and that is not going to work. To address this scenario, use wakeup enable reference counting for all devices, not just for bridges, so drop the last argument from __acpi_device_wakeup_enable() and __acpi_pm_set_device_wakeup(), which causes acpi_pm_set_device_wakeup() and acpi_pm_set_bridge_wakeup() to become identical, so drop the latter and use the former instead of it everywhere. Fixes: 1ba51a7c1496 ("ACPI / PCI / PM: Rework acpi_pci_propagate_wakeup()") Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Acked-by: Bjorn Helgaas Cc: 4.14+ # 4.14+ Signed-off-by: Greg Kroah-Hartman

PCI: iproc: Fix out-of-bound array accesses

2020-12-29T12:46:56+00:00

[ Upstream commit a3ff529f5d368a17ff35ada8009e101162ebeaf9 ] Declare the full size array for all revisions of PAX register sets to avoid potentially out of bound access of the register array when they are being initialized in iproc_pcie_rev_init(). Link: https://lore.kernel.org/r/20201001060054.6616-2-srinath.mannam@broadcom.com Fixes: 06324ede76cdf ("PCI: iproc: Improve core register population") Signed-off-by: Bharat Gooty Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin

PCI: qcom: Add missing reset for ipq806x

2020-12-29T12:46:44+00:00

commit ee367e2cdd2202b5714982739e684543cd2cee0e upstream Add missing ext reset used by ipq8064 SoC in PCIe qcom driver. Link: https://lore.kernel.org/r/20200615210608.21469-5-ansuelsmth@gmail.com Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Signed-off-by: Sham Muthayyan Signed-off-by: Ansuel Smith Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Reviewed-by: Philipp Zabel Acked-by: Stanimir Varbanov Cc: stable@vger.kernel.org # v4.5+ [sudip: manual backport] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

PCI: Add device even if driver attach failed

2020-12-02T07:34:39+00:00

commit 2194bc7c39610be7cabe7456c5f63a570604f015 upstream. device_attach() returning failure indicates a driver error while trying to probe the device. In such a scenario, the PCI device should still be added in the system and be visible to the user. When device_attach() fails, merely warn about it and keep the PCI device in the system. This partially reverts ab1a187bba5c ("PCI: Check device_attach() return value always"). Link: https://lore.kernel.org/r/20200706233240.3245512-1-rajatja@google.com Signed-off-by: Rajat Jain Signed-off-by: Bjorn Helgaas Reviewed-by: Greg Kroah-Hartman Cc: stable@vger.kernel.org # v4.6+ [sudip: use dev_warn] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

PCI: iproc: Set affinity mask on MSI interrupts

2020-10-29T08:07:11+00:00

[ Upstream commit eb7eacaa5b9e4f665bd08d416c8f88e63d2f123c ] The core interrupt code expects the irq_set_affinity call to update the effective affinity for the interrupt. This was not being done, so update iproc_msi_irq_set_affinity() to do so. Link: https://lore.kernel.org/r/20200803035241.7737-1-mark.tomlinson@alliedtelesis.co.nz Fixes: 3bc2b2348835 ("PCI: iproc: Add iProc PCIe MSI support") Signed-off-by: Mark Tomlinson Signed-off-by: Lorenzo Pieralisi Reviewed-by: Ray Jui Signed-off-by: Sasha Levin

PCI: Fix pci_create_slot() reference count leak

2020-09-03T09:22:26+00:00

[ Upstream commit 8a94644b440eef5a7b9c104ac8aa7a7f413e35e5 ] kobject_init_and_add() takes a reference even when it fails. If it returns an error, kobject_put() must be called to clean up the memory associated with the object. When kobject_init_and_add() fails, call kobject_put() instead of kfree(). b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject") fixed a similar problem. Link: https://lore.kernel.org/r/20200528021322.1984-1-wu000273@umn.edu Signed-off-by: Qiushi Wu Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

PCI: hotplug: ACPI: Fix context refcounting in acpiphp_grab_context()

2020-08-21T07:48:17+00:00

commit dae68d7fd4930315389117e9da35b763f12238f9 upstream. If context is not NULL in acpiphp_grab_context(), but the is_going_away flag is set for the device's parent, the reference counter of the context needs to be decremented before returning NULL or the context will never be freed, so make that happen. Fixes: edf5bf34d408 ("ACPI / dock: Use callback pointers from devices' ACPI hotplug contexts") Reported-by: Vasily Averin Cc: 3.15+ # 3.15+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

irqdomain/treewide: Free firmware node after domain removal

2020-08-21T07:48:16+00:00

commit ec0160891e387f4771f953b888b1fe951398e5d9 upstream. Commit 711419e504eb ("irqdomain: Add the missing assignment of domain->fwnode for named fwnode") unintentionally caused a dangling pointer page fault issue on firmware nodes that were freed after IRQ domain allocation. Commit e3beca48a45b fixed that dangling pointer issue by only freeing the firmware node after an IRQ domain allocation failure. That fix no longer frees the firmware node immediately, but leaves the firmware node allocated after the domain is removed. The firmware node must be kept around through irq_domain_remove, but should be freed it afterwards. Add the missing free operations after domain removal where where appropriate. Fixes: e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally allocated") Signed-off-by: Jon Derrick Signed-off-by: Thomas Gleixner Reviewed-by: Andy Shevchenko Acked-by: Bjorn Helgaas # drivers/pci Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1595363169-7157-1-git-send-email-jonathan.derrick@intel.com Signed-off-by: Greg Kroah-Hartman

PCI: Release IVRS table in AMD ACS quirk

2020-08-21T07:48:11+00:00

[ Upstream commit 090688fa4e448284aaa16136372397d7d10814db ] The acpi_get_table() should be coupled with acpi_put_table() if the mapped table is not used at runtime to release the table mapping. In pci_quirk_amd_sb_acs(), IVRS table is just used for checking AMD IOMMU is supported, not used at runtime, so put the table after using it. Fixes: 15b100dfd1c9 ("PCI: Claim ACS support for AMD southbridge devices") Link: https://lore.kernel.org/r/1595411068-15440-1-git-send-email-guohanjun@huawei.com Signed-off-by: Hanjun Guo Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin