[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <fe8ab4cab3740afd261fa902f14ecae002a1122d.camel@hadess.net>
Date: Tue, 10 Nov 2020 11:57:07 +0100
From: Bastien Nocera <hadess@...ess.net>
To: Linux PM <linux-pm@...r.kernel.org>, linux-usb@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>
Cc: Hans de Goede <hdegoede@...hat.com>,
Mario Limonciello <mario.limonciello@...l.com>
Subject: How to enable auto-suspend by default
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_autosuspend_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.
So the question is: how can we make it easier for device drivers to
implicitly allow autosuspend *unless they opt-out*, especially for
frameworks where the device's transport layer isn't directly available
(eg. HID devices)?
If that can't be done in the kernel drivers directly, would it be
possible for the kernel to ship with a somewhat canonical list that
systemd (or its replacement on other "Linuxes") could use to generate
those user-space quirks?
Ideally, for example, all new "iwlwifi" or all tested "iwlwifi" devices
should have autosuspend enabled by the developers adding support for
them, as in the script above, rather than downstreams (systemd upstream
included) having to chase new PCI IDs.
Cheers
Powered by blists - more mailing lists