Re: How to enable auto-suspend by default

[Greg KH]

On Tue, Nov 24, 2020 at 05:02:18PM +0100, Bastien Nocera wrote:
> On Wed, 2020-11-11 at 17:32 +0100, Greg KH wrote:
> > On Wed, Nov 11, 2020 at 04:03:30PM +0000, Limonciello, Mario wrote:
> > > > > > Given we're effectively ending up with the combination of
> > > > > > runtime PM turned
> > > > > > on by udev rules, do we need something like this for that ID:
> > > > > > 
> > > > > > 
> > > > https://github.com/torvalds/linux/commit/6a7c533d4a1854f54901a065d8c672e890400
> > > > d8a
> > > > > > 
> > > > > > @Mika Westerberg should 8086:a0ed be quirked like the TCSS
> > > > > > xHCI too?
> > > > > 
> > > > > I think this one is the TGL PCH xHCI. The quirk currently for
> > > > > xHCI
> > > > > controllers that are part of the TCSS (Type-C SubSystem) where
> > > > > it is
> > > > > important to put all devices into low power mode whenever
> > > > > possible,
> > > > > otherwise it keeps the whole block on.
> > > > 
> > > > Note that there are currently some IDs missing from the xHCIs
> > > > which
> > > > are part of the TCSS too. At least the id for the xHCI in the
> > > > thunderbolt
> > > > controller on the Lenovo T14 gen 1 is missing. I started a
> > > > discussion
> > > > about extending the kernel quirk list for this vs switching to
> > > > hwdb
> > > > a while a go:
> > > > 
> > > > https://lore.kernel.org/linux-usb/b8b21ba3-0a8a-ff54-5e12-
> > > > cf8960651086@xxxxxxxxxx/
> > > > 
> > > > The conclusion back then was to switch to hwdb, but I never got
> > > > around to
> > > > this.
> > > 
> > > I guess the problem I see with switching to a hwdb for this type of
> > > thing is
> > > that if there is a "bug" in your kernel driver around autosuspend
> > > you will
> > > then be potentially causing it to occur more regularly on a kernel
> > > that didn't
> > > necessarily pick up the fix but does have the newer hwdb.
> > > 
> > > I don't know how common that will really be though.
> > > 
> > > Since Mika mentioned the really light userspace scenario, what
> > > about shipping
> > > the hwdb "with" the kernel in tree?  This could allow evicting all
> > > these quirk
> > > scenarios from the kernel at the same time as switching to a hwdb
> > > and also cover
> > > the problem I suggested might happen with a bug in older kernel and
> > > newer userspace.
> > 
> > We took things out of the kernel to put it in hwdb years ago as it
> > was
> > easier for people to update a "text file" than it was their kernel
> > image.  I don't think you want to go backwards here :)
> 
> There are (unfortunately) a couple of Linux based OSes that don't use
> systemd, which is one of the problems we see.

You don't have to use systemd to use hwdb.  If you want to handle quirks
for hardware issues that are done in userspace, the overall solution for
this in Linux is hwdb.  To try to reverse that decision we all made a
long time ago is just going to duplicate work for almost no gain that I
can see.

What distros need this that can not pick this up from hwdb today?

> I think it might be a good idea to have a repository or directory
> that's accessible to same contributions as the drivers, where this sort
> of data is kept, as close to the drivers as possible.

And who is going to maintain that?  The data that ends up in hwdb
already comes from multiple places today, why add yet-another-one?  Are
you going to somehow unify all of those existing data sources into a
single entity?  Who is going to run that service and what would the end
output look like (hint, you would have to provide hwdb support, so why
not just use that?)

> You could always split off your quirks into separate "works with any
> kernel" and "works from this version of the kernel" files,

We don't have those today, that's not a thing.

> the goal here would be to make sure that there is a canonical list of
> devices that can be autosuspended, without user-space always playing
> catch-up (especially as is the case now where systemd is being fed by
> ChromeOS which is fed in some other way).

There is no way we can ever create such a "canonical list".  Hint,
another operating system tried it, they failed, and they actually had
partnerships with most hardware vendors, and paid developers to do this
work.  What are you going to do differently than they did to solve this
problem?

> The Venn diagram of folks that contribute to hwdb quirks databases in
> systemd and that contribute to kernel drivers has a pretty small
> overlap. Moving much of those quirks to a kernel-controlled repository
> (whatever format it ends up being in) would make sense so that the
> "quirk enablement" and the "driver writing" sections overlap.

But they don't overlap today, why make us do more work for no gain?

thanks,

greg k-h