Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 12 Dec 2023 15:27:07 -0600 | From | Bjorn Helgaas <> | Subject | Re: [PATCH v2 1/6] PCI/ASPM: Add locked helper for enabling link state |
| |
On Tue, Dec 12, 2023 at 11:48:27AM +0800, Kai-Heng Feng wrote: > On Fri, Dec 8, 2023 at 4:47 AM Bjorn Helgaas <helgaas@kernel.org> wrote: > ...
> > I hope we can obsolete this whole idea someday. Using pci_walk_bus() > > in qcom and vmd to enable ASPM is an ugly hack to work around this > > weird idea that "the OS isn't allowed to enable more ASPM states than > > the BIOS did because the BIOS might have left ASPM disabled because it > > knows about hardware issues." More history at > > https://lore.kernel.org/linux-pci/20230615070421.1704133-1-kai.heng.feng@canonical.com/T/#u > > > > I think we need to get to a point where Linux enables all supported > > ASPM features by default. If we really think x86 BIOS assumes an > > implicit contract that the OS will never enable ASPM more > > aggressively, we might need some kind of arch quirk for that. > > The reality is that PC ODM toggles ASPM to workaround hardware > defects, assuming that OS will honor what's set by the BIOS. > If ASPM gets enabled for all devices, many devices will break.
That's why I mentioned some kind of arch quirk. Maybe we're forced to do that for x86, for instance. But even that is a stop-gap.
The idea that the BIOS ASPM config is some kind of handoff protocol is really unsupportable.
Do we have concrete examples of where enabling ASPM for a device that advertises ASPM support will break something?
Bjorn
| ![\](/images/icornerr.gif) |