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

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: William McVicker <willmcvicker@google.com>,
	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@google.com
Subject: Re: [PATCH 18/21] arm64: dts: google: Add initial Google gs101 SoC support
Date: Thu, 5 Oct 2023 21:29:26 +0200	[thread overview]
Message-ID: <efc9f099-9c97-460b-b0c8-9891aa3b772a@linaro.org> (raw)
In-Reply-To: <2023100513-mashing-scrubber-ea59@gregkh>

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