Re: [PATCH v3 2/8] PCI/ASPM: Add pci_force_enable_link_state() API

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 6260 bytes --]

On Tue, 13 Oct 2026, Bjorn Helgaas wrote:
> On Tue, Oct 13, 2026 at 02:41:32PM +0300, Ilpo Järvinen wrote:
> > On Mon, 12 Oct 2026, Bjorn Helgaas wrote:
> > > On Wed, Jul 08, 2026 at 04:30:16PM +0200, Manivannan Sadhasivam wrote:
> > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > 
> > > > pci_enable_link_state() and pci_enable_link_state_locked() APIs only enable
> > > > the ASPM states that were not previously disabled via
> > > > pci_disable_link_state*() API or blacklisted during init (e.g. the pre-1.1
> > > > device blacklist, which is only meant to be overridden with
> > > > 'pcie_aspm=force'). This is an intentional behavior as these APIs must not
> > > > silently re-enable states that were deliberately disabled, since doing so
> > > > could enable ASPM on a link where it is known to be unsafe.
> > > 
> > > I think this is saying that many uses of pci_disable_link_state() are
> > > to avoid hardware errata, i.e., these are basically quirks, and we
> > > should *never* enable those ASPM states.
> > > 
> > > > However, some drivers (e.g. the atheros WLAN drivers) save the currently
> > > > enabled ASPM states, disable all ASPM states before firmware download, and
> > > > then try to restore exactly the states that were enabled before. Restoring
> > > > those states requires re-enabling states that were just disabled via
> > > > pci_disable_link_state() API. But, this cannot be achieved using the
> > > > existing APIs.
> > > 
> > > This sounds like it's also for hardware errata: if ASPM works
> > > correctly, there's no need to disable it during firmware download.  I
> > > think this is *only* the atheros drivers, isn't it?  I didn't see any
> > > others.
> > 
> > There are more that should use disable/enable API. In addition ath*, I had 
> > also these in my unfinished series:
> > 
> >   brcmfmac
> >   ib-hfi1
> >   rtlwifi
> >   rtsx
> >   r8169
> 
> Thanks for those pointers!
> 
> > > > Hence, add pci_force_enable_link_state() API for such callers. Unlike
> > > > pci_enable_link_state(), it re-enables the requested states even if they
> > > > were previously disabled via pci_disable_link_state() or disabled during
> > > > init. The caller is therefore responsible for only enabling states the
> > > > device actually supports, typically the ones previously reported by
> > > > pcie_aspm_enabled().
> > > 
> > > The problem is that pci_enable_link_state() cannot enable things that
> > > were disabled by pci_disable_link_state().  They're not symmetric,
> > > which violates the caller's expectation.
> > 
> > Yes.
> > 
> > This patch seems to come with my Suggested-by but what I suggested (and 
> > had a patch for) was to make disable/enable proper symmetric pairs because 
> > it is very trappy otherwise. If something else is needed in addition, that 
> > should be named differently like Bjorn also seems to suggest (however see 
> > my alternative suggestion below).
> > 
> > I renamed the current pci_enable_link_state() to 
> > pci_set_default_link_state() in my own attempt to get room for adding the 
> > symmetric pair.
> 
> We might need new names for pci_enable_link_state(),
> pci_disable_link_state(), and the quirk thing.  If we keep the same
> names, I think it will be pretty complicated to manage the changing
> semantics when backporting driver changes that use them.

I'm not good at picking names, but yes, reusing a name in the same 
kernel cycle using the same signature is asking for trouble.

> > > Instead of adding pci_force_enable_link_state(), I think we should add
> > > a new interface for the *quirk* behavior that permanently disables
> > > states.  Then pci_enable_link_state() and pci_disable_link_state()
> > > could be made symmetric.
> > 
> > My suggestion is to make the disables/enables counted per state which 
> > would allow parallel sources of disables to function without clashing.
> 
> By parallel sources, are you thinking of sysfs and driver calls?  If
> locking would be sufficient I think that would end up being simpler.
>
> But maybe the issue is these devices where we think ASPM breakage only
> happens in certain circumstances, e.g., firmware download, so we want
> to keep states disabled for that period.  Then I guess locking inside
> the enable/disable doesn't prevent sysfs from enabling those states
> during that period.

There are (at least) these sources:

- quirks (disable only)
- hw has ASPM related problem at certain phase of operation
- sysfs
- lane margining (the proposed patch)

I don't think locks can really solve this well as the sources seem largely 
independent from each other and are not necessarily short-lived periods 
(one could perhaps say some cases occur early enough the other sources don't 
matter but there are still enough sources even with that considered so 
that disable/enable pair could overlap, potentially leading to unwanted 
enable of a state).

IIRC, L0p was also incompatible with ASPM states. But it could be HW is 
fine with both being configure at the same point of time (I've not checked 
the spec with that in mind).

> > Disable quirks could simply not have the pairing enable, no special 
> > interface needed.
> 
> I'm not sure what this looks like to the caller.  A parameter that
> says whether to count the disable?

A quirk would just makes pci_disable_link_state(pdev, PCIE_LINK_STATE_L1) 
call (or whatever that ends up being called if a new name is selected), 
which increases disabled counter for L1 state. As there's no pairing 
enable, L1 cannot be enabled anymore by anything.

Only if the particular state disable counter is 0, the ASPM driver allows 
enabling that state or the other states depending on that state.


Sysfs accessors need to keep an additional bit per state to not request 
multiple disables/enables for a single state. The rest of the sources have 
it naturally from their operation and pairing disable/enable calls.

> I think having a different function name would be helpfully
> descriptive because permanently removing an advertised capability is
> different from temporarily disabling a feature.

-- 
 i.