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: <DM6PR19MB2636460E97BD5E47957BB43AFAE90@DM6PR19MB2636.namprd19.prod.outlook.com>
Date:   Tue, 10 Nov 2020 17:45:43 +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

> > 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.

> 
> But note, PCI devices can be behind lots of different types of busses,
> so maybe the "can this device autosuspend" differs for them because of
> different implementations of where the device is, right?
> 

Well the reason that I raise it is that without that device auto-suspended the
SOC on the XPS 9310 consumes too much power.

> > 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 quirked like the TCSS xHCI too?
> 
> Submit a patch!
> 
> thanks,
> 
> greg k-h

If that's the appropriate conclusion, will do.