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> <CAOvb9ygJ9afqLaeJRuCK+zFMH2vxjA4JGXAu2qZUvqqyUzhnmQ@mail.gmail.com>
In-Reply-To: <CAOvb9ygJ9afqLaeJRuCK+zFMH2vxjA4JGXAu2qZUvqqyUzhnmQ@mail.gmail.com>
From:   Prashant Malani <pmalani@chromium.org>
Date:   Thu, 1 Dec 2022 16:29:57 -0800
Message-ID: <CACeCKae3SGt9ihq-B2s6V2HiiHU+dSL6pRaxY15aaLoJUNQYmg@mail.gmail.com>
Subject: Re: [PATCH] platform/chrome: Create new USB driver for RGB keyboard
 in ChromeOS devices
To:     Won Chung <wonchung@google.com>
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 2:52 PM Won Chung <wonchung@google.com> wrote:
>
> On Thu, Dec 1, 2022 at 1:36 PM Prashant Malani <pmalani@chromium.org> wrote:
> > >
> > > 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?

Um, it should be(?); usb_enable_autosuspend() [1] and `echo auto >
power/control` [2]
both seem to call the same runtime PM function. I've not looked into
runtime PM code
deeper than that, but it may be worthwhile to examine what's causing the suspend
to get blocked.

[1] https://elixir.bootlin.com/linux/latest/source/drivers/usb/core/driver.c#L1637
[2] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/sysfs.c#L113