RE: How to enable auto-suspend by default

["Limonciello, Mario" <Mario.Limonciello@dell.com>]

> >> 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@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.

> 
> > Typically we haven't done that for PCH side xHCI controllers though, but
> > I don't see why not if it works that is. Adding Mathias to comment more
> > on that since he is the xHCI maintainer.
> 
> If we are also going to enable this for the non TCSS Intel XHCI controllers,
> maybe just uncondtionally enable it for all Intel XHCI controllers, or
> if necessary do a deny-list for some older models and enable it for anything
> not on the deny-list (so all newer models). That should avoid the game of
> whack-a-mole which we will have with this otherwise.
> 
> Note the deny-list + enable anything not on it approach could be done
> either in the kernel or in a udev-rule + hwdb combo.
> 
> Regards,
> 
> Hans