raises hand Me! I actually run the upstream kernel on an Allwinner device and was looking into why certain audio features weren't enabled. Turns out that someone had written a patch and it'd got stuck in kernel-patch-submission hell, including mutually conflicting requirements from the ALSA and ARM SoC maintainers. This seems to be basically the norm from what I've seen - endless bikeshedding, vague and changing requirements, and other delays that make it almost impossible to get support for modern SoCs merged before they're long obsolete.
I think upstream support for the chips affected by this got stuck in long arguments about the most elegant way to support their clocking and reset infrastructure, which needs to be solved before actual peripheral drivers can be developed. The H3 seems to be approaching the point where it has enough upstream support for a handful of limited uses, over a year after the mainlining effort started. The A83T is still held up on getting the support code necessary to actually boot Linux merged.
That was a nice idea back in the days when hardware was made up of discrete, standalone single-purpose peripherals. Unfortunately there's no such thing as "cleanly seperated" anything in modern SoCs - everything's interdependent. For example, the main USB controllers on Allwinner chips are basically standard EHCI, same as on any PC, except they also rely on the centralized Allwinner clock-generation and reset block and the Linux EHCI driver has to co-operate with the driver for it. There's a whole bunch of shared infrastructure within Linux to make this possible which has to be updated from time to time due to new requirements.
I think modern Intel chips are similar, except that they run closed-source management firmware to help them look more like a collection of separate devices to Windows - but they aren't and Skylake can't enter lower CPU power states unless the SATA link is in power-saving mode and a whole bunch of other peripherals co-operate because they share hardware. ARM SoCs just don't have the magic firmware that lets the drivers hide this from the OS.
If it was, all you'd have would been opaque Allwinner stuff like this one, complete with backdoors. While I agree with you on a theoretical level, upstream is the only sanity check we have right now. Also, once upstreamed code generally keeps working, but out of tree drivers tend to get bit rot fairly quick.
While I do agree that Linux is partly to blame for this fiasco, we are also in a different world.
Who is responsible for the fact that an active I2C device prevents entering sleep state 0 but an active SPI device does not? Where does that information get recorded? And who needs to act on it?
On the RPi, you can change pin direction without being in supervisor mode--that's not true on the BeagleBone.
These aren't easy questions, and the Linux architecture makes it even harder.
I think upstream support for the chips affected by this got stuck in long arguments about the most elegant way to support their clocking and reset infrastructure, which needs to be solved before actual peripheral drivers can be developed. The H3 seems to be approaching the point where it has enough upstream support for a handful of limited uses, over a year after the mainlining effort started. The A83T is still held up on getting the support code necessary to actually boot Linux merged.