On Tue, Nov 24, 2020 at 05:02:18PM +0100, Bastien Nocera wrote:
> On Wed, 2020-11-11 at 17:32 +0100, Greg KH wrote:
> > On Wed, Nov 11, 2020 at 04:03:30PM +, Limonciello, Mario wrote:
> > > > > > Given we're effectively ending up with the combination of
> > > > > > runtime PM turned
> > > > >
On Wed, 2020-11-11 at 17:32 +0100, Greg KH wrote:
> On Wed, Nov 11, 2020 at 04:03:30PM +, Limonciello, Mario wrote:
> > > > > 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:
> > > > >
On Tue, 2020-11-24 at 14:37 +0200, Mathias Nyman wrote:
>
> 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
Hi,
On 11/24/20 1:37 PM, Mathias Nyman wrote:
> On 23.11.2020 15.54, Hans de Goede wrote:
>> Hi,
>>
>> On 11/11/20 3:31 PM, Mika Westerberg wrote:
>>> On Wed, Nov 11, 2020 at 12:27:32PM +0100, Hans de Goede wrote:
Hi,
On 11/10/20 6:25 PM, Mika Westerberg wrote:
> On Tue, Nov
On 23.11.2020 15.54, Hans de Goede wrote:
> Hi,
>
> On 11/11/20 3:31 PM, Mika Westerberg wrote:
>> On Wed, Nov 11, 2020 at 12:27:32PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 11/10/20 6:25 PM, Mika Westerberg wrote:
On Tue, Nov 10, 2020 at 04:02:33PM +, Limonciello, Mario wrote:
On Mon, Nov 23, 2020 at 02:54:19PM +0100, Hans de Goede wrote:
> Hi,
>
> On 11/11/20 3:31 PM, Mika Westerberg wrote:
> > On Wed, Nov 11, 2020 at 12:27:32PM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 11/10/20 6:25 PM, Mika Westerberg wrote:
> >>> On Tue, Nov 10, 2020 at 04:02:33PM +,
Hi,
On 11/11/20 3:31 PM, Mika Westerberg wrote:
> On Wed, Nov 11, 2020 at 12:27:32PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/10/20 6:25 PM, Mika Westerberg wrote:
>>> On Tue, Nov 10, 2020 at 04:02:33PM +, Limonciello, Mario wrote:
>
> On Tue, Nov 10, 2020 at 11:57:07AM +0100,
On Wed, Nov 11, 2020 at 04:03:30PM +, Limonciello, Mario wrote:
> > >> 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:
> > >>
> > >>
> >
> >> 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
On Wed, Nov 11, 2020 at 12:27:32PM +0100, Hans de Goede wrote:
> Hi,
>
> On 11/10/20 6:25 PM, Mika Westerberg wrote:
> > On Tue, Nov 10, 2020 at 04:02:33PM +, Limonciello, Mario wrote:
> >>>
> >>> On Tue, Nov 10, 2020 at 11:57:07AM +0100, Bastien Nocera wrote:
> Hey,
>
>
Hi,
On 11/10/20 6:25 PM, Mika Westerberg wrote:
> On Tue, Nov 10, 2020 at 04:02:33PM +, Limonciello, Mario wrote:
>>>
>>> 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
> One note... I'll double check, but on my XPS 13 9380, as I recall, I
> have to manually disable autosuspend on all of the XHCI controllers
> and internal hubs after running "powertop --auto-tune", or else any
> external mouse attached to said USB device will be dead to the world
> for 2-3
One note... I'll double check, but on my XPS 13 9380, as I recall, I
have to manually disable autosuspend on all of the XHCI controllers
and internal hubs after running "powertop --auto-tune", or else any
external mouse attached to said USB device will be dead to the world
for 2-3 seconds if the
> On Tue, Nov 10, 2020 at 05:45:43PM +, Limonciello, Mario wrote:
> > > > 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
On Tue, Nov 10, 2020 at 05:45:43PM +, Limonciello, Mario wrote:
> > > 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
> > 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
On Tue, Nov 10, 2020 at 04:02:33PM +, Limonciello, Mario wrote:
> >
> > 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:
> > >
> >
On Tue, Nov 10, 2020 at 04:02:33PM +, Limonciello, Mario wrote:
> >
> > 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:
> > >
> >
>
> 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
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_autosuspend_rules.py
>
> The problem here is
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
21 matches
Mail list logo
