> It’s never as simple as submitting existing work upstream and making a few changes.
If they had started by working with upstream, then they wouldn't have to go through unnecessary revisions trying to adapt the thing they already wrote.
They were experienced with working with upstream and it still took them that long to do it.
LOL. It simply doesn't work that way.
It's all about time to market. A BSP with a custom fork of the Linux kernel that barely works can be done concurrent with hardware development.
But if you say as a manufacturer, we'll first get it upstream-supported by Linux and then release the hardware... by the time the quality is good enough for the proper upstream Linux kernel, the hardware is multiple generations outdated.
And often enough, the software side is an afterthought. The BSP teams get thrown the hardware and told to "make it work", which all too often means having to do horrible hacks to the Linux kernel that would be completely unacceptable upstream. Even if they'd hire Greg KH himself, the fundamental problem remains that the BSP teams aren't asked if the HW designers can make the life of the BSP team easier.
The one notable exception to this unholy mess, however, is Apple. And that is why Apple hardware seamlessly integrates within the ecosystem, why it is so performant and why it is so energy efficient.