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