From: Bastien Nocera <hadess@hadess.net>
To: Mathias Nyman <mathias.nyman@linux.intel.com>,
Hans de Goede <hdegoede@redhat.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: "Limonciello, Mario" <Mario.Limonciello@dell.com>,
Greg KH <gregkh@linuxfoundation.org>,
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>
Subject: Re: How to enable auto-suspend by default
Date: Tue, 24 Nov 2020 16:53:00 +0100 [thread overview]
Message-ID: <56726c3591feb0a61dd2bf8ffa5dc218af46cbab.camel@hadess.net> (raw)
In-Reply-To: <ecd964af-efdb-99c6-45cb-4979397fb324@linux.intel.com>
On Tue, 2020-11-24 at 14:37 +0200, Mathias Nyman wrote:
> <snip>
> I don't think we are ready to enable runtime pm as default for all
> Intel xHCI controllers.
> The risk of xHCI not waking up when user plugs a mouse/keyboard,
> making the system unusable
> just seems too high compared to the powersaving benefit.
>
> The powersaving benefit from autosuspending the TCSS xHCI is a lot
> better, and we, (Mika mostly)
> has been able to verify they work.
>
> So I propose we for now continue adding TCSS xHCI controllers to the
> allowlist in kernel.
> For others I think a userspace allow/denylist makes sense.
>
> Long term goal would be default allow for all, with short denylist in
> kernel.
Is there any way to preemptively enable autosuspend for all the _TCSS_
xHCI controllers?
This was the problem the original post tried to tease out, whether it
would be easier/better to enable autosuspend by default, and not enable
it on systems where it breaks something, rather than default to sucking
battery until somebody notices that a device ID got missed.
next prev parent reply other threads:[~2020-11-24 15:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 10:57 How to enable auto-suspend by default Bastien Nocera
2020-11-10 11:34 ` Greg KH
2020-11-10 16:02 ` Limonciello, Mario
2020-11-10 17:18 ` Greg KH
2020-11-10 17:45 ` Limonciello, Mario
2020-11-10 18:00 ` Greg KH
2020-11-10 18:08 ` Limonciello, Mario
2020-11-10 19:55 ` Theodore Y. Ts'o
2020-11-10 20:45 ` Limonciello, Mario
2020-11-10 17:25 ` Mika Westerberg
2020-11-11 11:27 ` Hans de Goede
2020-11-11 14:31 ` Mika Westerberg
2020-11-23 13:54 ` Hans de Goede
2020-11-23 14:01 ` Mika Westerberg
2020-11-24 12:37 ` Mathias Nyman
2020-11-24 12:38 ` Hans de Goede
2020-11-24 15:53 ` Bastien Nocera [this message]
2020-11-11 16:03 ` Limonciello, Mario
2020-11-11 16:32 ` Greg KH
2020-11-24 16:02 ` Bastien Nocera
2020-11-24 16:35 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56726c3591feb0a61dd2bf8ffa5dc218af46cbab.camel@hadess.net \
--to=hadess@hadess.net \
--cc=Mario.Limonciello@dell.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=mika.westerberg@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).