On Wed, Mar 3, 2021 at 3:05 PM Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Mar 03, 2021 at 11:38:39AM +0100, Krzysztof Kozlowski wrote: > > 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. > > 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