On 06/10/2023 01:19, William McVicker wrote: > 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. When you build single kernel there is never need to NOT ENABLE respective ARCH configs. Please describe me upstream case for such need to NOT ENABLE. > 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. Really? How related? The drivers are independent. You describe some out-of-tree development process which we never needed for upstream work. And we did here quite a lot of upstream, specially if you look at ARCH_QCOM. > > 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. No one forces you to pick up everything or nothing. You select ARCH_EXYNOS and still can drop all optional drivers. It's true you cannot drop mandatory drivers, but you are upstreaming Exynos platform, right? We do not talk about your out-of-tree Google work because it does not matter. Best regards, Krzysztof
