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

PCI: Blacklist power management of Gigabyte X299 DESIGNARE EX PCIe ports

2019-04-20T07:16:04+00:00

[ Upstream commit 85b0cae89d5266e6a7abb2e83c6f716326fc494c ] Gigabyte X299 DESIGNARE EX motherboard has one PCIe root port that is connected to an Alpine Ridge Thunderbolt controller. This port has slot implemented bit set in the config space but other than that it is not hotplug capable in the sense we are expecting in Linux (it has dev->is_hotplug_bridge set to 0): 00:1c.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #5 Bus: primary=00, secondary=05, subordinate=46, sec-latency=0 Memory behind bridge: 78000000-8fffffff [size=384M] Prefetchable memory behind bridge: 00003800f8000000-00003800ffffffff [size=128M] ... Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 ... SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #8, PowerLimit 25.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- Changed: MRL- PresDet+ LinkState+ This system is using ACPI based hotplug to notify the OS that it needs to rescan the PCI bus (ACPI hotplug). If there is nothing connected in any of the Thunderbolt ports the root port will not have any runtime PM active children and is thus automatically runtime suspended pretty soon after boot by PCI PM core. Now, when a device is connected the BIOS SMI handler responsible for enumerating newly added devices is not able to find anything because the port is in D3. Prevent this from happening by blacklisting PCI power management of this particular Gigabyte system. Link: https://bugzilla.kernel.org/show_bug.cgi?id=202031 Reported-by: Kedar A Dongre Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

PCI: pciehp: Ignore Link State Changes after powering off a slot

2019-04-17T06:38:54+00:00

commit 3943af9d01e94330d0cfac6fccdbc829aad50c92 upstream. During a safe hot remove, the OS powers off the slot, which may cause a Data Link Layer State Changed event. The slot has already been set to OFF_STATE, so that event results in re-enabling the device, making it impossible to safely remove it. Clear out the Presence Detect Changed and Data Link Layer State Changed events when the disabled slot has settled down. It is still possible to re-enable the device if it remains in the slot after pressing the Attention Button by pressing it again. Fixes the problem that Micah reported below: an NVMe drive power button may not actually turn off the drive. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203237 Reported-by: Micah Parrish Tested-by: Micah Parrish Signed-off-by: Sergey Miroshnichenko [bhelgaas: changelog, add bugzilla URL] Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman

PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller

2019-04-17T06:38:54+00:00

commit 9cde402a59770a0669d895399c13407f63d7d209 upstream. There is a Marvell 88SE9170 PCIe SATA controller I found on a board here. Some quick testing with the ARM SMMU enabled reveals that it suffers from the same requester ID mixup problems as the other Marvell chips listed already. Add the PCI vendor/device ID to the list of chips which need the workaround. Signed-off-by: Andre Przywara Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

PCI/PME: Fix hotplug/sysfs remove deadlock in pcie_pme_remove()

2019-04-05T20:33:00+00:00

[ Upstream commit 95c80bc6952b6a5badc7b702d23e5bf14d251e7c ] Dongdong reported a deadlock triggered by a hotplug event during a sysfs "remove" operation: pciehp 0000:00:0c.0:pcie004: Slot(0-1): Link Up # echo 1 > 0000:00:0c.0/remove PME and hotplug share an MSI/MSI-X vector. The sysfs "remove" side is: remove_store pci_stop_and_remove_bus_device_locked pci_lock_rescan_remove pci_stop_and_remove_bus_device ... pcie_pme_remove pcie_pme_suspend synchronize_irq # wait for hotplug IRQ handler pci_unlock_rescan_remove The hotplug side is: pciehp_ist pciehp_handle_presence_or_link_change pciehp_configure_device pci_lock_rescan_remove # wait for pci_unlock_rescan_remove() INFO: task bash:10913 blocked for more than 120 seconds. # ps -ax |grep D PID TTY STAT TIME COMMAND 10913 ttyAMA0 Ds+ 0:00 -bash 14022 ? D 0:00 [irq/745-pciehp] # cat /proc/14022/stack __switch_to+0x94/0xd8 pci_lock_rescan_remove+0x20/0x28 pciehp_configure_device+0x30/0x140 pciehp_handle_presence_or_link_change+0x324/0x458 pciehp_ist+0x1dc/0x1e0 # cat /proc/10913/stack __switch_to+0x94/0xd8 synchronize_irq+0x8c/0xc0 pcie_pme_suspend+0xa4/0x118 pcie_pme_remove+0x20/0x40 pcie_port_remove_service+0x3c/0x58 ... pcie_port_device_remove+0x2c/0x48 pcie_portdrv_remove+0x68/0x78 pci_device_remove+0x48/0x120 ... pci_stop_bus_device+0x84/0xc0 pci_stop_and_remove_bus_device_locked+0x24/0x40 remove_store+0xa4/0xb8 dev_attr_store+0x44/0x60 sysfs_kf_write+0x58/0x80 It is incorrect to call pcie_pme_suspend() from pcie_pme_remove() for two reasons. First, pcie_pme_suspend() calls synchronize_irq(), which will wait for the native hotplug interrupt handler as well as for the PME one, because they share one IRQ (as per the spec). That may deadlock if hotplug is signaled while pcie_pme_remove() is running and the latter calls pci_lock_rescan_remove() before the former. Second, if pcie_pme_suspend() figures out that wakeup needs to be enabled for the port, it will return without disabling the interrupt as expected by pcie_pme_remove() which was overlooked by commit c7b5a4e6e8fb ("PCI / PM: Fix native PME handling during system suspend/resume"). To fix that, rework pcie_pme_remove() to disable the PME interrupt, clear its status and prevent the PME worker function from re-enabling it before calling free_irq() on it, which should be sufficient. Fixes: c7b5a4e6e8fb ("PCI / PM: Fix native PME handling during system suspend/resume") Link: https://lore.kernel.org/linux-pci/c7697e7c-e1af-13e4-8491-0a3996e6ab5d@huawei.com Reported-by: Dongdong Liu Signed-off-by: Rafael J. Wysocki [bhelgaas: add URL and deadlock details from Dongdong] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin

PCI: dwc: skip MSI init if MSIs have been explicitly disabled

2019-03-23T19:10:02+00:00

commit 3afc8299f39a27b60e1519a28e18878ce878e7dd upstream. Since 7c5925afbc58 (PCI: dwc: Move MSI IRQs allocation to IRQ domains hierarchical API) the MSI init claims one of the controller IRQs as a chained IRQ line for the MSI controller. On some designs, like the i.MX6, this line is shared with a PCIe legacy IRQ. When the line is claimed for the MSI domain, any device trying to use this legacy IRQs will fail to request this IRQ line. As MSI and legacy IRQs are already mutually exclusive on the DWC core, as the core won't forward any legacy IRQs once any MSI has been enabled, users wishing to use legacy IRQs already need to explictly disable MSI support (usually via the pci=nomsi kernel commandline option). To avoid any issues with MSI conflicting with legacy IRQs, just skip all of the DWC MSI initalization, including the IRQ line claim, when MSI is disabled. Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains hierarchical API") Tested-by: Tim Harvey Signed-off-by: Lucas Stach Signed-off-by: Lorenzo Pieralisi Acked-by: Gustavo Pimentel Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

PCI/DPC: Fix print AER status in DPC event handling

2019-03-23T19:10:02+00:00

commit 9f08a5d896ce43380314c34ed3f264c8e6075b80 upstream. Previously dpc_handler() called aer_get_device_error_info() without initializing info->severity, so aer_get_device_error_info() relied on uninitialized data. Add dpc_get_aer_uncorrect_severity() to read the port's AER status, mask, and severity registers and set info->severity. Also, clear the port's AER fatal error status bits. Fixes: 8aefa9b0d910 ("PCI/DPC: Print AER status in DPC event handling") Signed-off-by: Dongdong Liu [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Reviewed-by: Keith Busch Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman

PCI/ASPM: Use LTR if already enabled by platform

2019-03-23T19:10:02+00:00

commit 10ecc818ea7319b5d0d2b4e1aa6a77323e776f76 upstream. RussianNeuroMancer reported that the Intel 7265 wifi on a Dell Venue 11 Pro 7140 table stopped working after wakeup from suspend and bisected the problem to 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR"). David Ward reported the same problem on a Dell Latitude 7350. After af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it"), we don't enable LTR unless the platform has granted LTR control to us. In addition, we don't notice if the platform had already enabled LTR itself. After 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR"), we avoid using LTR if we don't think the path to the device has LTR enabled. The combination means that if the platform itself enables LTR but declines to give the OS control over LTR, we unnecessarily avoided using ASPM L1.2. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201469 Fixes: 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR") Fixes: af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it") Reported-by: RussianNeuroMancer Reported-by: David Ward Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v4.18+ Signed-off-by: Greg Kroah-Hartman

PCI: Fix __initdata issue with "pci=disable_acs_redir" parameter

2019-02-23T08:07:26+00:00

commit d2fd6e81912a665993b24dcdc1c1384a42a54f7e upstream. The disable_acs_redir parameter stores a pointer to the string passed to pci_setup(). However, the string passed to PCI setup is actually a temporary copy allocated in static __initdata memory. After init, once the memory is freed, it is no longer valid to reference this pointer. This bug was noticed in v5.0-rc1 after a change in commit c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions") caused pci_disable_acs_redir() to be called during shutdown which manifested as an unable to handle kernel paging request at: RIP: 0010:pci_enable_acs+0x3f/0x1e0 Call Trace: pci_restore_state.part.44+0x159/0x3c0 pci_restore_standard_config+0x33/0x40 pci_pm_runtime_resume+0x2b/0xd0 ? pci_restore_standard_config+0x40/0x40 __rpm_callback+0xbc/0x1b0 rpm_callback+0x1f/0x70 ? pci_restore_standard_config+0x40/0x40 rpm_resume+0x4f9/0x710 ? pci_conf1_read+0xb6/0xf0 ? pci_conf1_write+0xb2/0xe0 __pm_runtime_resume+0x47/0x70 pci_device_shutdown+0x1e/0x60 device_shutdown+0x14a/0x1f0 kernel_restart+0xe/0x50 __do_sys_reboot+0x1ee/0x210 ? __fput+0x144/0x1d0 do_writev+0x5e/0xf0 ? do_writev+0x5e/0xf0 do_syscall_64+0x48/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 It was also likely possible to trigger this bug when hotplugging PCI devices. To fix this, instead of storing a pointer, we use kstrdup() to copy the disable_acs_redir_param to its own buffer which will never be freed. Fixes: aaca43fda742 ("PCI: Add "pci=disable_acs_redir=" parameter for peer-to-peer support") Tested-by: Jarkko Nikula Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Reviewed-by: Jarkko Nikula Signed-off-by: Greg Kroah-Hartman

PCI: imx: Enable MSI from downstream components

2019-02-12T18:47:19+00:00

[ Upstream commit 75cb8d20c112aba70f23d98e3f8d0a38ace16006 ] The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2) controls whether a Function can request service using MSI. i.MX6 Root Ports implement the MSI Capability and may use MSI to request service for events like PME, hotplug, AER, etc. In addition, on i.MX6, the MSI Enable bit controls delivery of MSI interrupts from components below the Root Port. Prior to f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically also enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root Ports, it set the MSI Enable bit so it could use PME, hotplug, AER, etc. As a side effect, that also enabled delivery of MSI interrupts from downstream components. The imx6q-pcie driver itself does not depend on portdrv, so set MSI Enable in imx6q-pcie so MSI from downstream components works even if nobody uses MSI for the Root Port events. Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of CONFIG_PCIEPORTBUS") Signed-off-by: Richard Zhu Signed-off-by: Bjorn Helgaas Tested-by: Sven Van Asbroeck Tested-by: Trent Piepho Reviewed-by: Lucas Stach Acked-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin

switchtec: Fix SWITCHTEC_IOCTL_EVENT_IDX_ALL flags overwrite

2019-02-12T18:47:09+00:00

[ Upstream commit e4a7dca5de625018b29417ecc39dc5037d9a5a36 ] In the ioctl_event_ctl() SWITCHTEC_IOCTL_EVENT_IDX_ALL case, we call event_ctl() several times with the same "ctl" struct. Each call clobbers ctl.flags, which leads to the problem that we may not actually enable or disable all events as the user requested. Preserve the event flag value with a temporary variable. Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver") Signed-off-by: Joey Zhang Signed-off-by: Wesley Sheng [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Signed-off-by: Sasha Levin