RE: How to enable auto-suspend by default

From: "Limonciello, Mario" <Mario.Limonciello@dell.com>
To: Greg KH <gregkh@linuxfoundation.org>,
	Bastien Nocera <hadess@hadess.net>,
	Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Linux PM <linux-pm@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	Hans de Goede <hdegoede@redhat.com>
Subject: RE: How to enable auto-suspend by default
Date: Tue, 10 Nov 2020 16:02:33 +0000	[thread overview]
Message-ID: <DM6PR19MB2636C94B56D5FBC0BD98A1B0FAE90@DM6PR19MB2636.namprd19.prod.outlook.com> (raw)
In-Reply-To: <X6p6ubTOoMPUPPXi@kroah.com>

> 
> On Tue, Nov 10, 2020 at 11:57:07AM +0100, Bastien Nocera wrote:
> > Hey,
> >
> > systemd has been shipping this script to enable auto-suspend on a
> > number of USB and PCI devices:
> >
> https://github.com/systemd/systemd/blob/master/tools/chromiumos/gen_autosuspen
> d_rules.py
> >
> > The problem here is twofold. First, the list of devices is updated from
> > ChromeOS, and the original list obviously won't be updated by ChromeOS
> > developers unless a device listed exists in a ChromeBook computer,
> > which means a number of devices that do support autosuspend aren't
> > listed.
> >
> > The other problem is that this list needs to exist at all, and that it
> > doesn't seem possible for device driver developers (at various levels
> > of the stack) to opt-in to auto-suspend when all the variants of the
> > device (or at least detectable ones) support auto-suspend.
> 
> A driver can say they support autosuspend today, but I think you are
> concerned about the devices that are controlled by class-compliant
> drivers, right?  And for those, no, we can't do this in the kernel as
> there are just too many broken devices out there.
> 

I guess what Bastien is getting at is for newer devices supported by class
drivers rather than having to store an allowlist in udev rules, can we set
the allowlist in the kernel instead.  Then distributions that either don't
use systemd or don't regularly update udev rules from systemd can take
advantage of better defaults on modern hardware.

The one item that stood out to me in that rules file was 8086:a0ed.
It's listed as "Volteer XHCI", but that same device ID is actually present
in an XPS 9310 in front of me as well and used by the xhci-pci kernel module.

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/6a7c533d4a1854f54901a065d8c672e890400d8a

@Mika Westerberg should 8086:a0ed be quirked like the TCSS xHCI too?

> As proof of this, look at other operating systems.  They had to
> implement the same type of "allowed devices" list that we do.  In fact,
> we did this for Linux because they did this, which means that when
> hardware manufacturers test their device, they only test with other
> operating systems and not Linux and so, we need to match what those
> other OSes do as well.
> 

(insert "some" 😊)