linux-kernel - RE: How to enable auto-suspend by default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM6PR19MB263696FE5FA50F344B559488FAE90@DM6PR19MB2636.namprd19.prod.outlook.com>
Date:   Tue, 10 Nov 2020 18:08:42 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@...l.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     Bastien Nocera <hadess@...ess.net>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Linux PM <linux-pm@...r.kernel.org>,
        "linux-usb@...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>,
        Hans de Goede <hdegoede@...hat.com>
Subject: RE: How to enable auto-suspend by default

> On Tue, Nov 10, 2020 at 05:45:43PM +0000, 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 either
> don't
> > > > use systemd or don't regularly update udev rules from systemd can take
> > > > advantage of better defaults on modern hardware.
> > >
> > > That's what the "hardware ids" database is supposed to be handling.
> > > It's easier to manage this in userspace than in the kernel.
> > >
> > > I just love systems where people feel it is safer to update the kernel
> > > than it is to update a hardware database file :)
> > >
> > > > 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.
> > >
> > > That's an Intel PCI device id.  If someone else is abusing that number,
> > > I'm sure Intel would want to know about it and would be glad to go after
> > > them.
> >
> > Sorry I wasn't intending to insinuate an abuse of the number, but rather
> that
> > the PCI device in the "Volteer" product and that in XPS 9310 appear are the
> > same so they are possibly using the same hardware for this device.
> 
> Ok, but again, given that the device might be on different transports,
> the ability for the device to properly autosuspend might be different,
> right?
> 

I would think since it's provided by the PCH unlikely to be different transports.
I'm not sure though, Matthias might need to confirm.

On my side if I don't put that device into autosuspend the power consumption
goes up.