Re: [PATCH v4 3/3] pci: intel: Add sysfs attributes to configure pcie link

[Bjorn Helgaas]

On Thu, Oct 31, 2019 at 10:13:11AM +0100, Rafael J. Wysocki wrote:
> On Thursday, October 31, 2019 3:56:37 AM CET Bjorn Helgaas wrote:
> > On Thu, Oct 31, 2019 at 12:31:44AM +0100, Rafael J. Wysocki wrote:
> > > On Wed, Oct 30, 2019 at 11:14 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:

> > > > Rafael had some concerns about the proposed ASPM interface [2], but I
> > > > don't know what they are yet.
> > > 
> > > I was talking about the existing ASPM interface in sysfs.  The new one
> > > I still have to review, but I'm kind of wondering what about people
> > > who used the old one?  Would it be supported going forward?
> > 
> > The old one interface was enabled by CONFIG_PCIEASPM_DEBUG.  Red Hat
> > doesn't enable that.  Ubuntu does.  I *thought* we heard from a
> > Canonical person who said they didn't have any tools that used it, but
> > I can't find that now.  I don't know about SUSE.
> > 
> > So the idea was to drop it on the theory that nobody is using it.
> > Possibly that's too aggressive.
> 
> Well, one problem is that the "old" (actually existing) I/F has made it
> to one of my OSS EU presentation slides (I did not talk to this particular
> slide, but it is there in the deck that's available for downloading), so who
> knows who is going to use it. :-)
> 
> So I guess that there's a risk that needs to be taken into consideration.
> 
> What could be done, in principle, would be to make the new I/F depend on
> CONFIG_PCIEASPM_DEBUG being unset and provide the "old" one when it is set.

I would prefer to enable the new interface unconditionally to make it
easier for userspace tools like powertop to use it.

I think the existing and new interfaces could coexist, with the
existing interface being enabled by CONFIG_PCIEASPM_DEBUG as it is
today.  The patch that removes the existing interface is the last in
the series and could easily be dropped.

> In any case, the pcie_aspm.policy module parameter cannot be dropped, because
> AFAICS there is quite a bit of user space using it (e.g. TLP).

What is TLP?  Since CONFIG_PCIEASPM is a bool, aspm.o is built in
statically if enabled, so pcie_aspm.policy is effectively a boot-time
kernel parameter, right?  We don't have a plan to remove it.

Bjorn