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

[Krzysztof Kozlowski]

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@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?
>>
>> 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