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

From: "Arnd Bergmann" <arnd@arndb.de>
To: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
	"William McVicker" <willmcvicker@google.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Peter Griffin" <peter.griffin@linaro.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	krzysztof.kozlowski+dt@linaro.org,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Tomasz Figa" <tomasz.figa@gmail.com>,
	"Sylwester Nawrocki" <s.nawrocki@samsung.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Olof Johansson" <olof@lixom.net>,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	"Tudor Ambarus" <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,
	"open list:GPIO SUBSYSTEM" <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, 06 Oct 2023 10:48:58 +0200	[thread overview]
Message-ID: <e8b23683-36ac-4547-9386-935a1b211d7d@app.fastmail.com> (raw)
In-Reply-To: <44816879-a3a7-4bd0-bb20-19a645107b4b@linaro.org>

On Fri, Oct 6, 2023, at 08:06, Krzysztof Kozlowski wrote:
> 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:
>>
>> 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.

Right: in general, all drivers are independent of the platform
besides the typical 'depends on ARCH_FOO || COMPILE_TEST' dependency,
but I think it's worth mentioning the known exceptions, so Greg and
Will can take that fight to the respective places rather than
discussing it in the platform submission:

- Some subsystems are considered 'special' and the maintainers
  prefer the drivers to be automatically selected based on the
  ARCH_* settings instead of having user-visible options. This is
  traditionally true for large chunks of drivers/irqchip,
  drivers/clocksource and drivers/pinctrl, though it has gotten
  better over time on all of them.

- Some older 32-bit platforms are still not as modular as we'd
  like them to be, especially the StrongARM (ARMv4) platforms that
  require a custom kernel build, and some of ARMv4T and ARMv5
  boards that are still missing DT support. These tend to require
  drivers they directly link to from board code, so disabling
  the drivers would cause a link failure until this gets
  cleaned up.

- A couple of drivers are force-enabled based on the ARCH_*
  options because booting without these drivers would risk
  permanent damage to hardware, e.g. in overtemp or overcurrent
  scenarios.

- ACPI based platforms require the PCI host bridge driver to
  be built-in rather than a loadable module because ACPI
  needs to probe PCI devices during early boot.

- Some subsystems (notably drivers/gpu/, but others as well)
  have an excessive number of 'select' statements, so you
  end up surprise-enabling a number of additional drivers
  and subsystems by enabling certain less important platform
  specific drivers.

      Arnd