[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