Re: [PATCH net-next v9 3/5] r8169: Consider chip-specific ASPM can be enabled on more cases

[Bjorn Helgaas <helgaas@kernel.org>]

On Fri, Mar 10, 2023 at 09:42:04PM +0100, Heiner Kallweit wrote:
> On 09.03.2023 21:17, Bjorn Helgaas wrote:
> > On Sat, Feb 25, 2023 at 11:46:33AM +0800, Kai-Heng Feng wrote:
> >> To really enable ASPM on r8169 NICs, both standard PCIe ASPM and
> >> chip-specific ASPM have to be enabled at the same time.
> >>
> >> Before enabling ASPM at chip side, make sure the following conditions
> >> are met:
> >> 1) Use pcie_aspm_support_enabled() to check if ASPM is disabled by
> >>    kernel parameter.
> >> 2) Use pcie_aspm_capable() to see if the device is capable to perform
> >>    PCIe ASPM.
> >> 3) Check the return value of pci_disable_link_state(). If it's -EPERM,
> >>    it means BIOS doesn't grant ASPM control to OS, and device should use
> >>    the ASPM setting as is.
> >>
> >> Consider ASPM is manageable when those conditions are met.
> >>
> >> While at it, disable ASPM at chip-side for TX timeout reset, since
> >> pci_disable_link_state() doesn't have any effect when OS isn't granted
> >> with ASPM control.
> > 
> > 1) "While at it, ..." is always a hint that maybe this part could be
> > split to a separate patch.
> > 
> > 2) The mix of chip-specific and standard PCIe ASPM configuration is a
> > mess.  Does it *have* to be intermixed at run-time, or could all the
> > chip-specific stuff be done once, e.g., maybe chip-specific ASPM
> > enable could be done at probe-time, and then all subsequent ASPM
> > configuration could done via the standard PCIe registers?
> > 
> > I.e., does the chip work correctly if chip-specific ASPM is enabled,
> > but standard PCIe ASPM config is *disabled*?
> > 
> > The ASPM sysfs controls [1] assume that L0s, L1, L1.1, L1.2 can all be
> > controlled simply by using the standard PCIe registers.  If that's not
> > the case for r8169, things will break when people use the sysfs knobs.
> > 
> This series has been superseded meanwhile and what is being discussed
> here has become obsolete.

For completeness, I guess the replacement of this series is:

  https://lore.kernel.org/all/af076f1f-a034-82e5-8f76-f3ec32a14eaa@gmail.com/