On Sat, May 04, 2019 at 05:31:04PM +0200, Heiner Kallweit wrote: > On 30.04.2019 19:53, Bjorn Helgaas wrote: > > On Sat, Apr 13, 2019 at 11:12:41AM +0200, Heiner Kallweit wrote: > > I like the idea of exposing these sysfs control files all the time, > > instead of only when CONFIG_PCIEASPM_DEBUG=y, but I think when we do > > that, we should put the files at the downstream end of the link (e.g., > > an endpoint) instead of at the upstream end (e.g., a root port or > > switch downstream port). We had some conversation about this here: > > > > https://lore.kernel.org/lkml/20180727202619.GD173328@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > Doing it at the downstream end would require more changes, of course, > > and probably raises some locking issues, but I think we have a small > > This isn't obvious to me as I'm not that familiar with the PCIe subsystem. > - Why do we need more changes on the downstream end? I just meant that it might be a little more complicated because the existing PCIEASPM_DEBUG code works at the upstream end so you can't use it directly. > - Which locking is affected? Normally if we operate on device X, we only touch registers in device X. Here we need to also touch things in the bridge upstream from X, so it's outside the usual model. We've had locking issues in the device enable path where we sometimes have to enable the upstream bridge before enabling the device itself. I don't know if there are similar issues here or not, so I mentioned it as a possibility. > > window of opportunity here where we can tweak the sysfs structure > > before we're committed to supporting something forever. > > > > Bjorn > > > Heiner
