linux-kernel - Re: [PATCH] platform/chrome: Create new USB driver for RGB keyboard in ChromeOS devices

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: <CACeCKad7RGVPGdrd9WNpRhn3n99R5TG9zFJpCrMj7CDLK18rMA@mail.gmail.com>
Date:   Thu, 1 Dec 2022 13:36:33 -0800
From:   Prashant Malani <pmalani@...omium.org>
To:     Benson Leung <bleung@...omium.org>
Cc:     Won Chung <wonchung@...gle.com>, linux-kernel@...r.kernel.org,
        chrome-platform@...ts.linux.dev
Subject: Re: [PATCH] platform/chrome: Create new USB driver for RGB keyboard
 in ChromeOS devices

Hey Benson,

On Thu, Dec 1, 2022 at 1:00 PM Benson Leung <bleung@...omium.org> wrote:
>
> Hi Prashant,
>
>
> On Thu, Dec 1, 2022 at 12:10 PM Prashant Malani <pmalani@...omium.org> wrote:
> >
> > Hi Won,
> >
> > On Wed, Nov 30, 2022 at 3:19 PM Won Chung <wonchung@...gle.com> wrote:
> > >
> > > Without any driver bound to RGB keyboard, it may not be suspended
> > > properly, preventing USB xHCI to be suspended and causing power drain.
> > > Create new USB driver for RGB keyboard so that it can be suspended
> > > properly.
> >
> > This seems like overkill. Can't you set this from USB's sysfs nodes
> > like power/control [1] ?
> >
> > [1] https://www.kernel.org/doc/html/latest/driver-api/usb/power-management.html#the-user-interface-for-dynamic-pm
> >
> >
> > Best regards,
> >
> > -Prashant
>
> We're seeing some behavior where a bound driver is needed in order for
> this USB device to properly enter suspend state. Just manipulating the
> power/control and other sysfs nodes for this usb device when there's
> no driver in the kernel doesn't seem to affect the device's ability to
> drop into a usb low power state.

That seems like an issue with the device then, which should be debugged
from the device side and/or its interaction with the USB subsystem.

>
> Also, I synced with Won about this offline, but the primary concern is
> not this prism usb device runtime suspending, it's actually it's
> ability to enter suspend state during system suspend. Right now, this
> internal usb device is keeping the whole system from entering lower
> S0iX states because it's not sleeping. This driver patch doesn't
> address that yet, but I'd like Won to dig down and see if he can get
> it suspending at suspend time too.

Auto-suspend / dynamic PM should take care of that FWIU (but I may be mistaken).