[PATCH 18/21] arm64: dts: google: Add initial Google gs101 SoC support

Greg KH gregkh at linuxfoundation.org
Thu Oct 5 12:23:22 PDT 2023


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@kroah.com/
> > 
> > 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



More information about the linux-arm-kernel mailing list