On 03/03/2021 17:43, Greg Kroah-Hartman wrote:
I don't think that will work in practice. Many ARCH_ symbols for various
architectures contradict with each other. Almost all watchdog drivers
only _build_ for specific platforms/architectures.
Great, that's horrible to hear, so much for a "generic arm64 kernel
binary" which I _thought_ was the goal.
ugh, you would have thought we would have learned our lesson with
arm32...
I have no idea what you are talking about here. arm64 kernels have
always been generic, but you still need drivers for each piece of
hardware, we unfortunately can't stop SoC vendors from reinventing
the wheel with each new platform and then having to add yet another
driver for each subsystems.
That's fine, drivers are easy, but when I see comments like "ARCH_
symbols contradict" that means that we can not make a generic kernel
image. Otherwise there's no contradiction :)
No, they don't contradict.
And "new drivers" are almost always not really "new" as everyone uses
much the same IP blocks. As proof of this patch where the DWC3 IP block
is being used by multiple SoC vendors. To handle that, you split out
the SoC-specific portions into sub-drivers, so that you can build a
single image of the driver that works on multiple platforms. Nothing
new, we've been doing this for years, it's just that out-of-mainline SoC
trees that think they can touch "core IP block code" break this all the
time, which is what I am pushing back on.
I am perfectly fine with (and like it!) putting dwc3 exynos back into
base/main dwc3 and getting rid of USB_DWC3_EXYNOS entirely. But this
was not part of this patch...
Anyway, this is just me as a driver subsystem maintainer being grumpy to
see ARCH_ dependancies on tiny little things like SoC-portions for
generic IP drivers. Or on individual drivers (i.e. Samsung serial port
driver), where they don't belong at all.
At least with Samsung serial driver we see adding new SoC - Apple M1.
Here, the guys in Samsung want to tweak several kernel parts to work
with their out-of-tree code without contributing this code back. It's
not a community-friendly approach. The upstream kernel should be tweaked
to the out-of-tree unknown, hidden and uncontrollable code.
Instead I expect from Samsung to contribute the basic Exynos9 support to
the upstream.
Best regards,
Krzysztof
