On 10/05/2023, Krzysztof Kozlowski wrote: > On 05/10/2023 21:23, Greg KH wrote: > > 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? > > It helps all the people and distros who do not want to build/package > drivers or modules for unrelated hardware or architectures. > > Let's take Samsung Exynos UART driver. It will never, 100% never, work > on x86, x86_64. There is no single need to package it for kernels build > for these products. It will not work on nVidia Tegra ARM64, Qualcomm > ARM64 SoC, so if you do not want to run on Exynos, then you do no select > ARCH_EXYNOS and have significantly smaller image. > > Now, there is no problem to have one kernel for nVidia Tegra + Qualcomm > + Samsung Exynos with everything you need. The ARCH_EXYNOS or SOC_EXYNOS > or SOC_GOOGLE serves only the purpose to allow distros and people > customize build for specific hardware. > > It does not limit anyone on anything. I'm glad you brought up Exynos UART because this is where one of the limitations is introduced. For example, if you want to modularize out all the vendor specific drivers from the core kernel to create a common arm64 kernel binary that works on all ARM64 devices, you will not be able to build in the early console UART drivers without enabling the respective ARCH_* configs. Being able to include SERIAL_SAMSUNG and SERIAL_MSM without all the vendor specific drivers that ARCH_EXYNOS and ARCH_QCOM select is very valuable for debugging early boot issues. I understand that ARCH_* configs are used to selectively pick which device tree blobs are built, but forcing developers to pick all or nothing is where I have a problem. Regards, Will > > > > > > >>>> 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? > > For the same reason above, because if I want to build kernel for > Qualcomm, I want to drop easily anything not related. If I want to build > kernel without I2C, I disable I2C bus which effectively disables all > drivers which work on I2C. If I want to build kernel without Exynos, I > disable ARCH_EXYNOS which effectively disables entire Exynos hardware. > > Think of SoC as a bus or interface. > > Best regards, > Krzysztof >
