Re: [PATCH v4 0/4] PCI/ASPM: add sysfs attributes for controlling ASPM

[Bjorn Helgaas <helgaas@kernel.org>]

On Wed, Aug 28, 2019 at 07:48:18AM +0200, Heiner Kallweit wrote:
> On 28.08.2019 07:40, Heiner Kallweit wrote:
> > On 28.08.2019 01:35, Bjorn Helgaas wrote:
> >> On Sat, Aug 24, 2019 at 05:39:37PM +0200, Heiner Kallweit wrote:
> >>> Background of this extension is a problem with the r8169 network driver.
> >>> Several combinations of board chipsets and network chip versions have
> >>> problems if ASPM is enabled, therefore we have to disable ASPM per
> >>> default. However especially on notebooks ASPM can provide significant
> >>> power-saving, therefore we want to give users the option to enable
> >>> ASPM. With the new sysfs attributes users can control which ASPM
> >>> link-states are disabled.
> >>>
> >>> v2:
> >>> - use a dedicated sysfs attribute per link state
> >>> - allow separate control of ASPM and PCI PM L1 sub-states
> >>>
> >>> v3:
> >>> - patch 3: statically allocate the attribute group
> >>> - patch 3: replace snprintf with printf
> >>> - add patch 4
> >>>
> >>> v4:
> >>> - patch 3: add call to sysfs_update_group because is_visible callback
> >>>            returns false always at file creation time
> >>> - patch 3: simplify code a little
> >>>
> >>> Heiner Kallweit (4):
> >>>   PCI/ASPM: add L1 sub-state support to pci_disable_link_state
> >>>   PCI/ASPM: allow to re-enable Clock PM
> >>>   PCI/ASPM: add sysfs attributes for controlling ASPM link states
> >>>   PCI/ASPM: remove Kconfig option PCIEASPM_DEBUG and related code
> >>>
> >>>  Documentation/ABI/testing/sysfs-bus-pci |  13 ++
> >>>  drivers/pci/pci-sysfs.c                 |  10 +-
> >>>  drivers/pci/pci.h                       |  12 +-
> >>>  drivers/pci/pcie/Kconfig                |   7 -
> >>>  drivers/pci/pcie/aspm.c                 | 236 ++++++++++++++++--------
> >>>  include/linux/pci-aspm.h                |  10 +-
> >>>  6 files changed, 195 insertions(+), 93 deletions(-)
> >>
> >> I can fix this if you don't get to it, but this doesn't apply cleanly
> >> to either my "master" branch (v5.3-rc1) or my "next" branch.  I always
> >> prefer series based on my "master" branch when possible.
> >>
> > I based it on top of linux-next, can rebase it to your master branch.

That'd be great.  linux-next is a moving target, so I never apply
patches based directly on that.

> Ah, one more point:
> This series has a dependency on Mika Westerberg's
> "PCI: Make pcie_downstream_port() available outside of access.c"
> that is sitting in your inbox. How do you want to deal with this?

Just mention the dependency in the cover letter and I'll take care of
it.

Thanks!