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:

quoted

On Wed, Nov 11, 2020 at 04:03:30PM +0000, Limonciello, Mario wrote:

quoted

quoted

quoted

quoted

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

quoted

quoted

@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@redhat.com/

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