Re: [PATCH v8 2/2] usb: dwc3: Add Google Tensor SoC DWC3 glue driver

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Dec 02, 2025 at 03:01:13AM -0600, Roy Luo wrote:
> On Sat, Nov 22, 2025 at 8:59 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Sat, Nov 22, 2025 at 09:32:06AM +0000, Roy Luo wrote:
> > > Add support for the DWC3 USB controller found on Google Tensor G5
> > > (codename: laguna). The controller features dual-role functionality
> > > and hibernation.
> > >
> > > The primary focus is implementing hibernation support in host mode,
> > > enabling the controller to enter a low-power state (D3). This is
> > > particularly relevant during system power state transition and
> > > runtime power management for power efficiency.
> > > Highlights:
> > > - Align suspend callback with dwc3_suspend_common() for deciding
> > >   between a full teardown and hibernation in host mode.
> > > - Integration with `psw` (power switchable) and `top` power domains,
> > >   managing their states and device links to support hibernation.
> > > - A notifier callback dwc3_google_usb_psw_pd_notifier() for
> > >   `psw` power domain events to manage controller state
> > >   transitions to/from D3.
> > > - Coordination of the `non_sticky` reset during power state
> > >   transitions, asserting it on D3 entry and deasserting on D0 entry
> > >   in hibernation scenario.
> > > - Handling of high-speed and super-speed PME interrupts
> > >   that are generated by remote wakeup during hibernation.
> > >
> > > Co-developed-by: Joy Chakraborty <joychakr@google.com>
> > > Signed-off-by: Joy Chakraborty <joychakr@google.com>
> > > Co-developed-by: Naveen Kumar <mnkumar@google.com>
> > > Signed-off-by: Naveen Kumar <mnkumar@google.com>
> > > Signed-off-by: Roy Luo <royluo@google.com>
> > > ---
> > >  drivers/usb/dwc3/Kconfig       |  13 +
> > >  drivers/usb/dwc3/Makefile      |   1 +
> > >  drivers/usb/dwc3/dwc3-google.c | 628 +++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 642 insertions(+)
> > >
> > > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> > > index 4925d15084f816d3ff92059b476ebcc799b56b51..f58c70dabf108878cbefe0abea88572d9ae81e26 100644
> > > --- a/drivers/usb/dwc3/Kconfig
> > > +++ b/drivers/usb/dwc3/Kconfig
> > > @@ -200,4 +200,17 @@ config USB_DWC3_GENERIC_PLAT
> > >         the dwc3 child node in the device tree.
> > >         Say 'Y' or 'M' here if your platform integrates DWC3 in a similar way.
> > >
> > > +config USB_DWC3_GOOGLE
> > > +     tristate "Google Platform"
> > > +     depends on COMPILE_TEST
> > > +     depends on OF && COMMON_CLK && RESET_CONTROLLER
> >
> > Shouldn't this be:
> >         depends on (OF && COMMON_CLK && RESET_CONTROLLER) || COMPILE_TEST
> >
> > I shouldn't have to enable those options to just get a build test here,
> > the apis should be properly stubbed out if those options are not
> > enabled, right?
> >
> > thanks,
> >
> > greg k-h
> 
> Hi Greg,
> 
> I agree with your interpretation of COMPILE_TEST but it doesn't
> seem to align with upstream convention. I found the following pattern
> in several device driver Kconfig files (including but not limited to usb,
> pinctrl and phy).
> 
>     depends on COMPILE_TEST || ARCH_XXX
>     depends on CONFIG_A && CONFIG_B...
> 
> For this patch, the APIs exposed by OF, COMMON_CLK
> and RESET_CONTROLLER are properly stubbed out so
> I'm all good to go with your suggestion, but I'd like to make
> sure this approach is conventional.

Whatever works for building properly, as-is, what you have in this patch
didn't work for my systems at all.

> I plan to add ARCH_GOOGLE as a dependency in the next
> version per [1], so the "depends on" would probably look like
> the following per your suggestion:

But "Google" is not an arch :(

And really, the whole "only have a sub-arch symbol" is something that
personally, I think is totally wrong and prevents kernel images from
being built for more than one "arch".  As an example, the Android GKI
kernel has to support more than one of these, so what does putting this
behind a symbol that no one will actually use mean anything?  Android
will never be only building a ARCH_GOOGLE kernel.

>     depends on (OF && COMMON_CLK && RESET_CONTROLLER && ARCH_GOOGLE)
> || COMPILE_TEST
> 
> Please let me know your thoughts.
> [1] https://lore.kernel.org/linux-phy/1a53d473-fc13-4ac5-ba52-4701d95e3073@kernel.org/

Again, I hate the ARCH_ stuff, but Krzysztof does seem to like it for
some reason, so I'll defer to others here.  But note, as someone who
helps maintain a "generic" ARM64 kernel, these ARCH_* usages for
different platforms do nothing at all to help anyone out.

thanks,

greg k-h