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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 02/12/2025 10:27, Greg Kroah-Hartman wrote:
>>>         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

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.

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

True and that's not their goal. The truly generic kernels, like you
mentioned or arch/arm64/configs/defconfig, build everything for arm64.
The entire point is to limit this for actual users wanting much smaller
kernels and distros, which do not need these on for example RISC-V.


Best regards,
Krzysztof