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

[Roy Luo <royluo@google.com>]

On Wed, Dec 3, 2025 at 12:25 AM Doug Anderson <dianders@google.com> wrote:
>
> Hi,
>
> On Tue, Dec 2, 2025 at 1:42 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > >> 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
> >
> > Probably you think ARCH_FOO as arch/FOO/ directory, but this is not the
> > case. ARCH_FOO in this context is SoC platform, so e.g.
> > arch/arm64/boot/dts/FOO/.
> >
> > All of ARCH_FOO build into one image and that's recommended way to limit
> > unnecessary drivers.
> >
> > It's just confusing naming for whatever reason.
> >
> > > 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.
> >
> > But distros will be, people will be. OK, maybe not for ARCH_GOOGLE, but
> > ARCH_QCOM we do for Qualcomm-based laptops and embedded folks even more.
> >
> > We had this talk in the past. The point is that these drivers here are
> > unusable outside of that hardware platform, so only when you choose
> > hardware platform (ARCH_EXYNOS, ARCH_GOOGLE, ARCH_QCOM) you will be able
> > to choose these drivers.
> >
> > You can also look at ARCH_FOO a bit orthogonal to actual kernel
> > architecture, because ARCH_EXYNOS is for both arm (arm32) and arm64. The
> > drivers should be available for all Exynos-platforms, regardless whether
> > this is arm32 or arm64.
>
> FWIW I don't feel strongly about the ARCH_XYZ Kconfig settings, but
> I'd tend to agree with Krzysztof that I personally find them useful.
> Sure, it's fine to just turn all of the ARCH_XYZ values on and they
> shouldn't conflict with each other, but it provides an easy way for
> someone to know that certain drivers are only useful if the kernel
> you're building supports a given arch. If I'm building a kernel that
> doesn't need to support any Qualcomm boards, for instance, I can just
> turn that arch off and I don't even need to think about all of the
> Qualcomm-related config options.
>
> FWIW, if you do add a "depend" on ARCH_GOOGLE you should mention
> somewhere (maybe "after the cut" in your patch) that ARCH_GOOGLE
> doesn't exist yet. It should eventually exist when some version of
> this patch lands:
>
> https://lore.kernel.org/r/20251111112158.3.I35b9e835ac49ab408e5ca3e0983930a1f1395814@changeid/
>
> ...but it's not there yet. ;-)
>
> -Doug

Hi all,

I appreciate the detailed discussion regarding Kconfig dependencies.
Based on all the feedback, I'll make the following adjustments:
- I will update the Kconfig dependency to depends on
  ARCH_GOOGLE || COMPILE_TEST and drop the other
  dependencies on OF && COMMON_CLK && RESET_CONTROLLER
  as suggested by Krzysztof. This should also address the build
  coverage concern from Greg.
- As Doug pointed out, the ARCH_GOOGLE Kconfig option does
  not exist... yet. I will add a note about this in the next version.

Thank you all again for helping me improve this patch.
I will send out a new version with these changes soon.

Regards,
Roy Luo