[RFC PATCH] PCI: Avoid bus reset for Realtek RTL8126

[RFC PATCH] PCI: Avoid bus reset for Realtek RTL8126

[John Garry]

From testing on a Orion O6 board, a bus level reset for a RTL8126 may not
recover:
root@radxa-kernel:/sys/devices/pci0000:00/0000:00:00.0/0000:01:00.0# more reset_method
bus
root@radxa-kernel:/sys/devices/pci0000:00/0000:00:00.0/0000:01:00.0# echo 1 > reset
 r8169 0000:01:00.0: resetting
 r8169 0000:01:00.0: not ready 1023ms after bus reset; waiting
 r8169 0000:01:00.0: not ready 2047ms after bus reset; waiting
 r8169 0000:01:00.0: not ready 4095ms after bus reset; waiting
 r8169 0000:01:00.0: not ready 8191ms after bus reset; waiting
 r8169 0000:01:00.0: not ready 16383ms after bus reset; waiting
 r8169 0000:01:00.0: not ready 32767ms after bus reset; waiting
 SError Interrupt on CPU6, code 0x00000000be000011 -- SError

Add a quirk to avoid this reset method.

Signed-off-by: John Garry <john.garry@arm.com>
---
I'm sending as an RFC as I am not sure that this is an issue with the
development board and not the controller.

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 7f1f47ea2ee4..69eef714838a 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3850,6 +3850,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ASMEDIA, 0x1164, quirk_no_bus_reset);
 /* Intel DG1 0x4905 may not recover from bus reset */
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x4905, quirk_no_bus_reset);
 
+/* Realtek RTL8126 may not recover from a bus reset */
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REALTEK, 0x8126, quirk_no_bus_reset);
+
 static void quirk_no_pm_reset(struct pci_dev *dev)
 {
 	/*
-- 
2.47.3

Re: [RFC PATCH] PCI: Avoid bus reset for Realtek RTL8126

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] PCI: quirk_no_bus_reset() with DECLARE_PCI_FIXUP_FINAL runs too late
--

commit 6a48b331f38758a39c2143e3a32823e61b24d0c5
Author: John Garry <john.garry@arm.com>

PCI: Avoid bus reset for Realtek RTL8126

This commit adds a quirk_no_bus_reset() fixup for the Realtek RTL8126
(0x8126) PCI device to avoid bus-level resets that may fail to recover.

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index fb3c5d517f91e..8346d223886a6 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3850,6 +3850,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ASMEDIA, 0x1164, quirk_no_bus_reset);
>  /* Intel DG1 0x4905 may not recover from bus reset */
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x4905, quirk_no_bus_reset);
>  
> +/* Realtek RTL8126 may not recover from a bus reset */
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REALTEK, 0x8126, quirk_no_bus_reset);

[Severity: Medium]
Should this use DECLARE_PCI_FIXUP_HEADER instead of
DECLARE_PCI_FIXUP_FINAL, matching the other quirk_no_bus_reset() entries?

During PCI enumeration in drivers/pci/probe.c, pci_device_add() runs header
fixups before probing and caching supported reset methods and registering
the device:

drivers/pci/probe.c:pci_device_add() {
	/* Fix up broken headers */
	pci_fixup_device(pci_fixup_header, dev);

	pci_reassigndev_resource_alignment(dev);

	pci_init_capabilities(dev);
		-> pci_init_reset_methods(dev);
	...
	ret = device_add(&dev->dev);
		-> pci_dev_reset_attr_is_visible()
}

Final fixups do not run until later in drivers/pci/bus.c:

drivers/pci/bus.c:pci_bus_add_device() {
	pci_fixup_device(pci_fixup_final, dev);
	...
}

Because PCI_DEV_FLAGS_NO_BUS_RESET is not set on dev->dev_flags when
pci_init_reset_methods() probes pci_reset_bus_function(), the bus reset
method still succeeds during probing and is recorded in
dev->reset_methods[].

As a result, when a Realtek RTL8126 is enumerated, reset_method in sysfs
still advertises bus, pci_dev_reset_attr_is_visible() still exposes the
reset attribute via pci_reset_supported() even when bus is the only reset
method, and calling pci_reset_function() still runs
pci_dev_save_and_disable() and pci_dev_restore() before
__pci_reset_function_locked() fails with -ENOTTY.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103172758.1816004-1-john.garry@arm.com?part=1