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

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 :)

thanks,

greg k-h