On Wed, Mar 3, 2021 at 3:05 PM Greg Kroah-Hartman
[off-list ref] wrote:

On Wed, Mar 03, 2021 at 11:38:39AM +0100, Krzysztof Kozlowski wrote:

quoted

On Wed, Mar 03, 2021 at 11:30:38AM +0100, Greg Kroah-Hartman wrote: >
It's getting more generic topic, so let me Cc Arnd and Guenter (I think
once I discussed this with Guenter around watchdog).

This is so far component of a SoC, so it cannot be re-used outside of
SoC. Unless it appears in a new SoC (just like recent re-use of Samsung
serial driver for Apple M1). Because of the architecture, you cannot
build universal kernel without ARCH_EXYNOS. You need it. Otherwise the
kernel won't boot on hardware with DWC Exynos.

So, to create a "generic" arm64 kernel, I need to go enable all of the
ARCH_* variants as well?  I thought we were trying to NOT do the same
mess that arm32 had for this type of thing.

Yes, same as on any other architecture that supports more than one
platform at a time.

quoted

Since DWC Exynos won't work without ARCH_EXYNOS - the user will not get
any usable binary - I think all, or almost all, SoC specific drivers are
limited per ARCH. This limits the amount of choices for distro people
and other kernel configuring folks, so they won't have to consider
useless options.

Why do we have ARCH_EXYNOS at all?  x86-64 doesn't have this, why is
arm64 somehow special here?

There are only about five chip vendors for x86-64, and they largely
just use the same drivers. You still have platform support that you need to
enable to run on all machines, see:

CONFIG_X86_NUMACHIP
CONFIG_X86_VSMP
CONFIG_X86_UV
CONFIG_X86_GOLDFISH
CONFIG_X86_INTEL_CE
CONFIG_X86_INTEL_MID
CONFIG_X86_AMD_PLATFORM_DEVICE
CONFIG_KVM_GUEST
CONFIG_JAILHOUSE_GUEST
CONFIG_ACRN_GUEST
CONFIG_CHROME_PLATFORMS
CONFIG_MELLANOX_PLATFORM
CONFIG_SURFACE_PLATFORMS
laptop vendors in drivers/platform/x86/Kconfig

Most of these have only a few drivers, while none of the interesting
x86 platforms that modified from ARM or MIPS SoCs
(Allwinner/Rockchip Sofia, Unisoc SC9861G-IA, Maxlinear
XWAY, MobilEye EyeQ6) made it upstream so far, and probably
never will.

That's my complaint, it feels wrong that I have to go and enable all
different ARCH_ symbols just to build these drivers.  If people want
'default' configurations, then provide an exynos default config file,
right?

It is very intentional that there is only one defconfig, this helps ensure
that none of the platform specific drivers conflicts with other platforms.

I've complained about this before, from a driver subsystem maintainer
point of view, this is crazy, drivers should be building and working on
everything.  Worst case, it's a cpu-type issue, to build or not build a
driver (i.e. s390, i386), best case it's a feature-type issue to depend
on (i.e. USB, TTY, etc.).  But never a "this one sub-architecture of
this one cpu"-type issue.  That feels crazy to me...

Basing on the CPU type seems way crazier to me, these have
almost nothing to do with what kind of drivers one gets to use.

SoC designers rarely care much about the CPU core they put
in a SoC, they just license a part fits their needs.
At the moment everyone is using ARM, but before that they had
the same platforms on powerpc, mips, sh, or their own custom
architecture. Some get acquired by Intel and start using x86
cores, and some others move to RISC-V.

       Arnd