Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221130231936.1666390-1-wonchung@google.com> <CACeCKad16bs_f6bLthTAoEL28tPvf1S10WDeM7ugeaS9g7R25w@mail.gmail.com>
 <CANLzEksD=dKgPuCUD74b3YQKCApbZKO_t7Q=tyNKONvAOQ89hw@mail.gmail.com> <CACeCKad7RGVPGdrd9WNpRhn3n99R5TG9zFJpCrMj7CDLK18rMA@mail.gmail.com>
In-Reply-To: <CACeCKad7RGVPGdrd9WNpRhn3n99R5TG9zFJpCrMj7CDLK18rMA@mail.gmail.com>
From:   Won Chung <wonchung@google.com>
Date:   Thu, 1 Dec 2022 14:52:36 -0800
Message-ID: <CAOvb9ygJ9afqLaeJRuCK+zFMH2vxjA4JGXAu2qZUvqqyUzhnmQ@mail.gmail.com>
Subject: Re: [PATCH] platform/chrome: Create new USB driver for RGB keyboard
 in ChromeOS devices
To:     Prashant Malani <pmalani@chromium.org>
Cc:     Benson Leung <bleung@chromium.org>, linux-kernel@vger.kernel.org,
        chrome-platform@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Dec 1, 2022 at 1:36 PM Prashant Malani <pmalani@chromium.org> wrote:
>
> Hey Benson,
>
> On Thu, Dec 1, 2022 at 1:00 PM Benson Leung <bleung@chromium.org> wrote:
> >
> > Hi Prashant,
> >
> >
> > On Thu, Dec 1, 2022 at 12:10 PM Prashant Malani <pmalani@chromium.org> wrote:
> > >
> > > Hi Won,
> > >
> > > On Wed, Nov 30, 2022 at 3:19 PM Won Chung <wonchung@google.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.
>

Hi Prashant,

As Benson mentioned, I can check on my test Vell device that changing
power/control does not suspend the device.
Should it be controllable even without a driver bound?

The RGB keyboard seems to be able to enter sleep with a suspend signal.
Fyi, here are the related bugs for more context: b/242087721 and b/249173368

Thank you,
Won

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