wifi: rtw89: 8852be: add .shutdown callback to quiesce device on reboot

From: "Yuhang.chen" <[email protected]>

Since hardware rfkill polling was introduced, warm reboot on arm64 platforms can panic with an asynchronous SError when the rfkill poll workqueue reads a register while the PCIe link is being torn down:

SError Interrupt on CPU8, code 0x00000000be000011 -- SError

  Workqueue: events_power_efficient rfkill_poll [rfkill]
  Call trace:
    rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci]
    rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core]
    rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core]
    ieee80211_rfkill_poll+0x3c/0x70 [mac80211]
    cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211]
    rfkill_poll+0x30/0x88 [rfkill]
  Kernel panic - not syncing: Asynchronous SError Interrupt

During device_shutdown() the 8852BE PCI driver has no .shutdown callback, so the device is never quiesced and the rfkill polling keeps running. Once the platform brings the PCIe link down, the next MMIO read targets a non-responding device and is reported as an asynchronous SError, which is fatal on arm64.

Add a .shutdown callback that runs the existing remove path to stop the rfkill polling, free interrupts and power down the chip before the link goes away. A NULL drvdata check guards the case where probe did not fully complete.

Fixes 0b38e6277aed ("wifi: rtw89: add support for hardware rfkill")

Cc [email protected]

Signed-off-by Yuhang.chen <[email protected]>

---
 drivers/net/wireless/realtek/rtw89/rtw8852be.c | 9 +++++++++
 1 file changed, 9 insertions(+)

drivers/net/wireless/realtek/rtw89/rtw8852be.c +0 -0

index 5bc0a6a99d1d..9aebecbac067 100644

drivers/net/wireless/realtek/rtw89/rtw8852be.c +0 -1

        .driver.pm      = &rtw89_pm_ops,
        .err_handler    = &rtw89_pci_err_handler,
 };
--

2.34.1

Does it mean the work is running after .shutdown but before .remove?

Not prefer calling rtw89_pci_remove() twice.

I think this fix can apply to all PCI devices for this driver, right?

Hi Ping-Ke,

Thanks for the review.

Quoted 1 line

Does it mean the work is running after .shutdown but before .remove?

On the reboot/poweroff path the kernel only runs device_shutdown(), which invokes each driver's .shutdown callback; .remove is *not* called on this path -- it only runs on driver unbind, module unload or hot-unplug. The rfkill polling workqueue, however, keeps being scheduled by the rfkill core throughout the whole shutdown sequence until the system finally halts. During that window the platform starts tearing the PCIe link down, and the next MMIO read issued by rtw89_ops_rfkill_poll() then targets a non-responding device, which on arm64 is reported as a fatal asynchronous SError. So it is not ".remove after .shutdown"; .remove never runs on reboot -- the poll work simply outlives the link, and that is exactly what the new flag stops.

From: "Yuhang.chen" <[email protected]>

Since the hardware rfkill polling was introduced, arm64 platforms can panic with an asynchronous SError during warm reboot:

SError Interrupt on CPU8, code 0x00000000be000011 -- SError

  Workqueue: events_power_efficient rfkill_poll [rfkill]
    rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci]
    rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core]
    rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core]
    ieee80211_rfkill_poll+0x3c/0x70 [mac80211]
    cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211]
    rfkill_poll+0x30/0x88 [rfkill]
  Kernel panic - not syncing: Asynchronous SError Interrupt

On the reboot path the kernel only runs device_shutdown(), which calls each driver's .shutdown callback; .remove is not invoked. The rtw89 PCI driver had no .shutdown callback, so nothing stopped the rfkill polling work while the platform was tearing the PCIe link down. Once the link is gone, the next MMIO read from the poll handler targets a non-responding device and is reported as a fatal asynchronous SError on arm64.

Add rtw89_pci_shutdown(), wired to all rtw89 PCI device drivers, which sets a new RTW89_FLAG_SHUTDOWN flag (mirroring the USB RTW89_FLAG_UNPLUGGED pattern). When the flag is set, rtw89_ops_rfkill_poll() returns early, so no MMIO read is issued to the chip after shutdown begins and the SError no longer occurs.

This does not call the full .remove path from .shutdown, to keep the shutdown handler minimal and avoid running the non-idempotent teardown twice.

Fixes 0b38e6277aed ("wifi: rtw89: add support for hardware rfkill")

Cc [email protected]

Suggested-by Ping-Ke Shih <[email protected]>

Signed-off-by Yuhang.chen <[email protected]>

From: "Yuhang.chen" <[email protected]>

Since the hardware rfkill polling was introduced, arm64 platforms can panic with an asynchronous SError during warm reboot:

SError Interrupt on CPU8, code 0x00000000be000011 -- SError

  Workqueue: events_power_efficient rfkill_poll [rfkill]
    rtw89_pci_ops_read8+0x94/0x160 [rtw89_pci]
    rtw89_core_rfkill_poll+0x50/0x1e0 [rtw89_core]
    rtw89_ops_rfkill_poll+0x40/0x68 [rtw89_core]
    ieee80211_rfkill_poll+0x3c/0x70 [mac80211]
    cfg80211_rfkill_poll+0x40/0x2a0 [cfg80211]
    rfkill_poll+0x30/0x88 [rfkill]
  Kernel panic - not syncing: Asynchronous SError Interrupt

On the reboot path the kernel only runs device_shutdown(), which calls each driver's .shutdown callback; .remove is not invoked. The rtw89 PCI driver had no .shutdown callback, so nothing stopped the rfkill polling work while the platform was tearing the PCIe link down. Once the link is gone, the next MMIO read from the poll handler targets a non-responding device and is reported as a fatal asynchronous SError on arm64.

Add rtw89_pci_shutdown(), wired to all rtw89 PCI device drivers, which sets a new RTW89_FLAG_SHUTDOWN flag (mirroring the USB RTW89_FLAG_UNPLUGGED pattern). When the flag is set, rtw89_ops_rfkill_poll() returns early, so no MMIO read is issued to the chip after shutdown begins and the SError no longer occurs.

This does not call the full .remove path from .shutdown, to keep the shutdown handler minimal and avoid running the non-idempotent teardown twice.

Fixes 0b38e6277aed ("wifi: rtw89: add support for hardware rfkill")

Cc [email protected]

Suggested-by Ping-Ke Shih <[email protected]>

Signed-off-by Yuhang.chen <[email protected]>

Acked-by Ping-Ke Shih <[email protected]>