> Although it doesn't appear to have made it into the mainstream kernel source
Now, who wants to blame upstream kernel maintainers for not merging in all the dirt around and requiring high quality of code submissions?
Now, who wants to blame upstream kernel maintainers for not merging in all the dirt around and requiring high quality of code submissions?
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.
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.
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.