Messages in this thread |  | | From | Roy Luo <> | | Date | Wed, 3 Dec 2025 11:04:56 +0800 | | Subject | Re: [PATCH v8 2/2] usb: dwc3: Add Google Tensor SoC DWC3 glue driver |
| |
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
|  |