On Thu, Oct 05, 2023 at 09:18:48PM +0200, Krzysztof Kozlowski wrote: > >> I'd like to bring up this thread and discuss the option of not introducing > >> another ARCH_* config: > >> > >> https://lore.kernel.org/all/20200306103652.GA3634389@xxxxxxxxx/ > > > > I agree, PLEASE don't add platform config options as that makes it > > impossible to make a unified kernel image that works for more than one > > platform at the same time. > > There is no single problem in making unified image as we were doing > since beginning of ARM64. The ARCH_* is not a obstacle for this. Then why are the ARCH_* options needed at all? What does this help out with? > >> I especially don't like the "depends on ARCH_EXYNOS" because that forces one to > >> include all the other Exynos drivers that ARCH_EXYNOS selects that Google > >> Tensor SoCs don't need. Can we consider using SOC_GOOGLE instead and for all > >> drivers that actually depend on the SoC hardware, we can just add "depends on > >> SOC_GOOGLE"? > > > > Why do any of this at all? It should not be needed. > > > >> The idea is that drivers should be tied to hardware -- not a specific vendor. > > > > And drivers should be auto-loaded. > > > > All of these drivers are not vendor-specific at all, they are based on > > the same IP blocks as others, so that is how they should be unified. > > They are vendor specific. All of them are specifically for Exynos > hardwre, because this is Exynos. We call it Google GS/Tensor SoC just > for fancy convenience, but this just Exynos. Ok, then why is this ARCH_ option needed if these IP blocks really are from something else and are part of other drivers? confused, greg k-h