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

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: William McVicker <willmcvicker@google.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Peter Griffin <peter.griffin@linaro.org>,
	robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	mturquette@baylibre.com, conor+dt@kernel.org, sboyd@kernel.org,
	tomasz.figa@gmail.com, s.nawrocki@samsung.com,
	linus.walleij@linaro.org, wim@linux-watchdog.org,
	linux@roeck-us.net, catalin.marinas@arm.com, will@kernel.org,
	arnd@arndb.de, olof@lixom.net, cw00.choi@samsung.com,
	tudor.ambarus@linaro.org, andre.draszik@linaro.org,
	semen.protsenko@linaro.org, soc@kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-gpio@vger.kernel.org, linux-watchdog@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [PATCH 18/21] arm64: dts: google: Add initial Google gs101 SoC support
Date: Fri, 6 Oct 2023 08:06:30 +0200	[thread overview]
Message-ID: <44816879-a3a7-4bd0-bb20-19a645107b4b@linaro.org> (raw)
In-Reply-To: <ZR9EnFw3vB92vlYM@google.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel