Re: [PATCH] PCI/PM: Move ASUS EHCI workaround out of generic code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 11, 2025 at 3:34 PM Mario Limonciello <superm1@xxxxxxxxxx> wrote:
>
> On 9/11/25 8:11 AM, Lukas Wunner wrote:
> > In 2012, commit dbf0e4c7257f ("PCI: EHCI: fix crash during suspend on ASUS
> > computers") amended pci_pm_suspend_noirq() to work around a BIOS issue by
> > clearing the Command register if the suspended device is a USB EHCI host
> > controller.
> >
> > Commit 0b68c8e2c3af ("PCI: EHCI: Fix crash during hibernation on ASUS
> > computers") subsequently amended pci_pm_poweroff_noirq() to do the same.
> >
> > Two years later, commit 7d2a01b87f16 ("PCI: Add pci_fixup_suspend_late
> > quirk pass") introduced the ability to execute arbitrary quirks
> > specifically in pci_pm_suspend_noirq() and pci_pm_poweroff_noirq().
> >
> > This allows moving the ASUS workaround out of generic code and into a
> > proper quirk to improve maintainability and readability.  Constrain to x86
> > since the ASUS BIOS doesn't seem to have been used on other arches.
> >
> > lspci output of affected EHCI host controllers reveals that the only bits
> > set in the Command register are Memory Space Enable and Bus Master Enable:
> >    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658778
> >
> > The latter is cleared by:
> >    hcd_pci_suspend()
> >      suspend_common()
> >        pci_disable_device()
> >
> > pci_disable_device() does not clear I/O and Memory Space Enable, although
> > its name suggests otherwise.
>
> That was my gut reaction as well.
>
> > The kernel has never disabled these bits
> > once they're enabled.  Doing so would avoid the need for the quirk, but it
> > is unclear what will break if this fundamental behavior is changed.
> >
>
> It's too late for this cycle to do so, but how would you feel about
> making this change at the start of the next cycle so it had a whole
> cycle to bake in linux-next and see if there is a problem in doing so?

One cycle in linux-next may not be sufficient I'm afraid because
linux-next is not tested on the majority of systems running Linux.

We'd probably learn about the breakage from distro vendors.

> If there is it could certainly be moved back to a quirk.

Most likely, it would work on the majority of systems, but there would
be a tail of systems where it would break.  That tail would then need
to be quirked somehow and it may be worse than just one quirk we have
today.





[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux