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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230310204825.GA1277880@bhelgaas>
Date:   Fri, 10 Mar 2023 14:48:25 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Kai-Heng Feng <kai.heng.feng@...onical.com>, nic_swsd@...ltek.com,
        bhelgaas@...gle.com, koba.ko@...onical.com,
        acelan.kao@...onical.com, davem@...emloft.net, edumazet@...gle.com,
        kuba@...nel.org, pabeni@...hat.com,
        sathyanarayanan.kuppuswamy@...ux.intel.com, vidyas@...dia.com,
        rafael.j.wysocki@...el.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH net-next v9 3/5] r8169: Consider chip-specific ASPM can
 be enabled on more cases

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/