linux-stable.git/drivers/pci/hotplug, branch linux-6.5.y

PCI: pciehp: Use RMW accessors for changing LNKCTL

2023-09-13T07:53:30+00:00

[ Upstream commit 5f75f96c61039151c193775d776fde42477eace1 ]

As hotplug is not the only driver touching LNKCTL, use the RMW capability
accessor which handles concurrent changes correctly.

Suggested-by: Lukas Wunner 
Fixes: 7f822999e12a ("PCI: pciehp: Add Disable/enable link functions")
Link: https://lore.kernel.org/r/20230717120503.15276-4-ilpo.jarvinen@linux.intel.com
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Bjorn Helgaas 
Acked-by: "Rafael J. Wysocki" 
Signed-off-by: Sasha Levin

PCI: acpiphp: Use pci_assign_unassigned_bridge_resources() only for non-root bus

2023-08-08T19:30:00+00:00

40613da52b13 ("PCI: acpiphp: Reassign resources on bridge if necessary")
changed acpiphp hotplug to use pci_assign_unassigned_bridge_resources()
which depends on bridge being available, however enable_slot() can be
called without bridge associated:

  1. Legitimate case of hotplug on root bus (widely used in virt world)

  2. A (misbehaving) firmware, that sends ACPI Bus Check notifications to
     non existing root ports (Dell Inspiron 7352/0W6WV0), which end up at
     enable_slot(..., bridge = 0) where bus has no bridge assigned to it.
     acpihp doesn't know that it's a bridge, and bus specific 'PCI
     subsystem' can't augment ACPI context with bridge information since
     the PCI device to get this data from is/was not available.

Issue is easy to reproduce with QEMU's 'pc' machine, which supports PCI
hotplug on hostbridge slots. To reproduce, boot kernel at commit
40613da52b13 in VM started with following CLI (assuming guest root fs is
installed on sda1 partition):

  # qemu-system-x86_64 -M pc -m 1G -enable-kvm -cpu host \
        -monitor stdio -serial file:serial.log           \
        -kernel arch/x86/boot/bzImage                    \
        -append "root=/dev/sda1 console=ttyS0"           \
        guest_disk.img

Once guest OS is fully booted at qemu prompt:

  (qemu) device_add e1000

(check serial.log) it will cause NULL pointer dereference at:

  void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
  {
    struct pci_bus *parent = bridge->subordinate;

  BUG: kernel NULL pointer dereference, address: 0000000000000018

   ? pci_assign_unassigned_bridge_resources+0x1f/0x260
   enable_slot+0x21f/0x3e0
   acpiphp_hotplug_notify+0x13d/0x260
   acpi_device_hotplug+0xbc/0x540
   acpi_hotplug_work_fn+0x15/0x20
   process_one_work+0x1f7/0x370
   worker_thread+0x45/0x3b0

The issue was discovered on Dell Inspiron 7352/0W6WV0 laptop with following
sequence:

  1. Suspend to RAM
  2. Wake up with the same backtrace being observed:
  3. 2nd suspend to RAM attempt makes laptop freeze

Fix it by using __pci_bus_assign_resources() instead of
pci_assign_unassigned_bridge_resources() as we used to do, but only in case
when bus doesn't have a bridge associated (to cover for the case of ACPI
event on hostbridge or non existing root port).

That lets us keep hotplug on root bus working like it used to and at the
same time keeps resource reassignment usable on root ports (and other 1st
level bridges) that was fixed by 40613da52b13.

Fixes: 40613da52b13 ("PCI: acpiphp: Reassign resources on bridge if necessary")
Link: https://lore.kernel.org/r/20230726123518.2361181-2-imammedo@redhat.com
Reported-by: Woody Suwalski 
Tested-by: Woody Suwalski 
Tested-by: Michal Koutný 
Link: https://lore.kernel.org/r/11fc981c-af49-ce64-6b43-3e282728bd1a@gmail.com
Signed-off-by: Igor Mammedov 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
Acked-by: Michael S. Tsirkin

Merge branch 'pci/hotplug'

2023-06-26T17:59:56+00:00

- Simplify Attention Button logging (Bjorn Helgaas)

- Cancel bringup sequence if card is not present, to keep from blinking
  Power Indicator indefinitely (Rongguang Wei)

- Reassign bridge resources if necessary for ACPI hotplug (Igor Mammedov)

* pci/hotplug:
  PCI: acpiphp: Reassign resources on bridge if necessary
  PCI: pciehp: Cancel bringup sequence if card is not present
  PCI: pciehp: Simplify Attention Button logging

PCI: pciehp: Rely on dev->link_active_reporting

2023-06-14T22:58:12+00:00

Use dev->link_active_reporting to determine whether Data Link Layer Link
Active Reporting is available rather than re-retrieving the capability.

Link: https://lore.kernel.org/r/alpine.DEB.2.21.2305310028150.59226@angie.orcam.me.uk
Signed-off-by: Maciej W. Rozycki 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Lukas Wunner

PCI: acpiphp: Reassign resources on bridge if necessary

2023-05-24T16:53:41+00:00

When using ACPI PCI hotplug, hotplugging a device with large BARs may fail
if bridge windows programmed by firmware are not large enough.

Reproducer:
  $ qemu-kvm -monitor stdio -M q35  -m 4G \
      -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=on \
      -device id=rp1,pcie-root-port,bus=pcie.0,chassis=4 \
      disk_image

 wait till linux guest boots, then hotplug device:
   (qemu) device_add qxl,bus=rp1

 hotplug on guest side fails with:
   pci 0000:01:00.0: [1b36:0100] type 00 class 0x038000
   pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x03ffffff]
   pci 0000:01:00.0: reg 0x14: [mem 0x00000000-0x03ffffff]
   pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x00001fff]
   pci 0000:01:00.0: reg 0x1c: [io  0x0000-0x001f]
   pci 0000:01:00.0: BAR 0: no space for [mem size 0x04000000]
   pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x04000000]
   pci 0000:01:00.0: BAR 1: no space for [mem size 0x04000000]
   pci 0000:01:00.0: BAR 1: failed to assign [mem size 0x04000000]
   pci 0000:01:00.0: BAR 2: assigned [mem 0xfe800000-0xfe801fff]
   pci 0000:01:00.0: BAR 3: assigned [io  0x1000-0x101f]
   qxl 0000:01:00.0: enabling device (0000 -> 0003)
   Unable to create vram_mapping
   qxl: probe of 0000:01:00.0 failed with error -12

However when using native PCIe hotplug
  '-global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off'
it works fine, since kernel attempts to reassign unused resources.

Use the same machinery as native PCIe hotplug to (re)assign resources.

Link: https://lore.kernel.org/r/20230424191557.2464760-1-imammedo@redhat.com
Signed-off-by: Igor Mammedov 
Signed-off-by: Bjorn Helgaas 
Acked-by: Michael S. Tsirkin 
Acked-by: Rafael J. Wysocki 
Cc: stable@vger.kernel.org

PCI: pciehp: Cancel bringup sequence if card is not present

2023-05-24T16:52:38+00:00

If a PCIe hotplug slot has an Attention Button, the normal hot-add flow is:

  - Slot is empty and slot power is off
  - User inserts card in slot and presses Attention Button
  - OS blinks Power Indicator for 5 seconds
  - After 5 seconds, OS turns on Power Indicator, turns on slot power, and
    enumerates the device

Previously, if a user pressed the Attention Button on an *empty* slot,
pciehp logged the following messages and blinked the Power Indicator
until a second button press:

  [0.000] pciehp: Button press: will power on in 5 sec
  [0.001] # Power Indicator starts blinking
  [5.001] # 5 second timeout; slot is empty, so we should cancel the
            request to power on and turn off Power Indicator

  [7.000] # Power Indicator still blinking
  [8.000] # possible card insertion
  [9.000] pciehp: Button press: canceling request to power on

The first button press incorrectly left the slot in BLINKINGON_STATE, so
the second was interpreted as a "cancel power on" event regardless of
whether a card was present.

If the slot is empty, turn off the Power Indicator and return from
BLINKINGON_STATE to OFF_STATE after 5 seconds, effectively canceling the
request to power on.  Putting the slot in OFF_STATE also means the second
button press will correctly request a slot power on if the slot is
occupied.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20230512021518.336460-1-clementwei90@163.com
Fixes: d331710ea78f ("PCI: pciehp: Become resilient to missed events")
Suggested-by: Lukas Wunner 
Signed-off-by: Rongguang Wei 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Lukas Wunner

PCI: pciehp: Simplify Attention Button logging

2023-05-24T16:49:50+00:00

Previously, pressing the Attention Button always logged two lines, the
first from pciehp_ist() and the second from pciehp_handle_button_press():

  Attention button pressed
  Powering on due to button press

Since pciehp_handle_button_press() always logs the more detailed message,
remove the generic "Attention button pressed" message.  Reword the
pciehp_handle_button_press() to be of the form:

  Button press: will power on in 5 sec
  Button press: will power off in 5 sec
  Button press: canceling request to power on
  Button press: canceling request to power off
  Button press: ignoring invalid state %#x

Link: https://lore.kernel.org/r/20230522214051.619337-1-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Lukas Wunner

Merge branch 'pci/resource'

2023-04-20T21:16:34+00:00

- Add pci_dev_for_each_resource() and pci_bus_for_each_resource() iterators
  to simplify loops (Andy Shevchenko)

* pci/resource:
  EISA: Drop unused pci_bus_for_each_resource() index argument
  PCI: Make pci_bus_for_each_resource() index optional
  PCI: Document pci_bus_for_each_resource()
  PCI: Introduce pci_dev_for_each_resource()
  PCI: Introduce pci_resource_n()

Merge branch 'pci/hotplug'

2023-04-20T21:16:33+00:00

- Fix pciehp AB-BA deadlock between reset_lock and device_lock (Lukas
  Wunner)

* pci/hotplug:
  PCI: pciehp: Fix AB-BA deadlock between reset_lock and device_lock

PCI: Use of_property_present() for testing DT property presence

2023-04-18T21:01:37+00:00

It is preferred to use typed property access functions (i.e.
of_property_read_ functions) rather than low-level
of_get_property()/of_find_property() functions for reading properties. As
part of this, convert of_get_property()/of_find_property() calls to the
recently added of_property_present() helper when we just want to test for
presence of a property and nothing more.

Link: https://lore.kernel.org/r/20230310144719.1544443-1-robh@kernel.org
Signed-off-by: Rob Herring 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: AngeloGioacchino Del Regno   # pcie-mediatek