linux-stable.git/drivers/pci, branch v5.10.7

PCI: Fix pci_slot_release() NULL pointer dereference

2020-12-30T10:54:28+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-30T10:54:05+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: Invalidate correct PAXB inbound windows

2020-12-30T10:53:27+00:00

[ Upstream commit 89bbcaac3dff21f3567956b3416f5ec8b45f5555 ]

Second stage bootloaders prior to Linux boot may use all inbound windows
including IARR1/IMAP1. We need to ensure that all previous configuration
of inbound windows are invalidated during the initialization stage of
the Linux iProc PCIe driver so let's add a fix to define and invalidate
IARR1/IMAP1 because it is currently missing, fixing the issue.

Link: https://lore.kernel.org/r/20201001060054.6616-3-srinath.mannam@broadcom.com
Fixes: 9415743e4c8a ("PCI: iproc: Invalidate PAXB address mapping")
Signed-off-by: Roman Bacik 
Signed-off-by: Srinath Mannam 
[lorenzo.pieralisi@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sasha Levin

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

2020-12-30T10:53:27+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: Fix overflow in command-line resource alignment requests

2020-12-30T10:53:26+00:00

[ Upstream commit cc73eb321d246776e5a9f7723d15708809aa3699 ]

The shift of 1 by align_order is evaluated using 32 bit arithmetic and the
result is assigned to a resource_size_t type variable that is a 64 bit
unsigned integer on 64 bit platforms. Fix an overflow before widening issue
by making the 1 a ULL.

Addresses-Coverity: ("Unintentional integer overflow")
Fixes: 32a9a682bef2 ("PCI: allow assignment of memory resources with a specified alignment")
Signed-off-by: Colin Ian King 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Logan Gunthorpe 
Signed-off-by: Sasha Levin

PCI: Bounds-check command-line resource alignment requests

2020-12-30T10:53:26+00:00

[ Upstream commit 6534aac198b58309ff2337981d3f893e0be1d19d ]

32-bit BARs are limited to 2GB size (2^31).  By extension, I assume 64-bit
BARs are limited to 2^63 bytes.  Limit the alignment requested by the
"pci=resource_alignment=" command-line parameter to 2^63.

Link: https://lore.kernel.org/r/20201007123045.GS4282@kadam
Reported-by: Dan Carpenter 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin

PCI: brcmstb: Initialize "tmp" before use

2020-12-30T10:53:18+00:00

[ Upstream commit ddaff0af653136ee1e0b49116ecf2988c2fc64ca ]

The variable 'tmp' is used multiple times in the brcm_pcie_setup()
function.  One such usage did not initialize 'tmp' to the current value
of the target register.  By luck the mistake does not currently affect
behavior;  regardless 'tmp' is now initialized properly.

Suggested-by: Rafał Miłecki 
Link: https://lore.kernel.org/r/20201102205712.23332-1-james.quinlan@broadcom.com
Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver")
Signed-off-by: Jim Quinlan 
Signed-off-by: Lorenzo Pieralisi 
Acked-by: Nicolas Saenz Julienne 
Acked-by: Florian Fainelli 
Signed-off-by: Sasha Levin

PCI: Disable MSI for Pericom PCIe-USB adapter

2020-12-30T10:53:18+00:00

[ Upstream commit f83c37941e881224885f2e694e0626bea358e96b ]

Pericom PCIe-USB adapter advertises MSI, but documentation says "The MSI
Function is not implemented on this device" in chapters 7.3.27,
7.3.29-7.3.31, and Alberto found that MSI in fact does not work.

Disable MSI for these devices.

Datasheet: https://www.diodes.com/assets/Datasheets/PI7C9X440SL.pdf
Fixes: 306c54d0edb6 ("usb: hcd: Try MSI interrupts on PCI devices")
Link: https://lore.kernel.org/linux-usb/20201030134826.GP4077@smile.fi.intel.com/
Link: https://lore.kernel.org/r/20201106100526.17726-1-andriy.shevchenko@linux.intel.com
Reported-by: alberto.vignani@fastwebnet.it
Signed-off-by: Andy Shevchenko 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin

PCI: mvebu: Fix duplicate resource requests

2020-11-04T19:55:30+00:00

With commit 669cbc708122 ("PCI: Move DT resource setup into
devm_pci_alloc_host_bridge()"), the DT 'ranges' is parsed and populated
into resources when the host bridge is allocated. The resources are
requested as well, but that happens a second time for the mvebu driver in
mvebu_pcie_parse_request_resources(). We should only be requesting the
additional resources added in mvebu_pcie_parse_request_resources().  These
are not added by default because they use custom properties rather than
standard DT address translation.

Also, the bus ranges was also populated by default, so we can remove it
from mvebu_pci_host_probe().

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209729
Fixes: 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()")
Link: https://lore.kernel.org/r/20201023145252.2691779-1-robh@kernel.org
Reported-by: vtolkm@googlemail.com
Tested-by: Jan Kundrát 
Signed-off-by: Rob Herring 
Signed-off-by: Bjorn Helgaas 
Acked-by: Lorenzo Pieralisi 
Cc: Thomas Petazzoni 
Cc: Jason Cooper 
Cc: Russell King

PCI: dwc: Restore ATU memory resource setup to use last entry

2020-11-04T19:55:30+00:00

Prior to commit 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources"),
the DWC driver was setting up the last memory resource rather than the
first memory resource. This doesn't matter for most platforms which only
have 1 memory resource, but it broke Tegra194 which has a 2nd
(prefetchable) memory region that requires an ATU entry. The first region
on Tegra194 relies on the default 1:1 pass-thru of outbound transactions
and doesn't need an ATU entry.

Fixes: 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources")
Link: https://lore.kernel.org/r/20201026154852.221483-1-robh@kernel.org
Reported-by: Vidya Sagar 
Signed-off-by: Rob Herring 
Signed-off-by: Bjorn Helgaas 
Acked-by: Lorenzo Pieralisi 
Acked-by: Jingoo Han 
Cc: Gustavo Pimentel