[Limb]

I have a question regarding "mainline" that I hope someone could help clarify.

What is the difference (in terms of coding, etc.) between mainlining support for a chip into Linux versus pinning it to a specific kernel revision? What makes it easy to bring a chip up on a specific kernel version,but not easy to submit that to the mainline kernel so future versions of the kernel are compatible?

Are there significant changes between kernel versions that require someone to be an active maintainer for the specific chip, making sure changes to the kernel stay compatible with the chip? And thus most manufacturer don't care enough to keep supporting future versions once they get on specific kernel version working?

[garaetjjte]

To have code included in mainline you need to have reasonably sane code in the first place, and then invest some time working with upstream maintainers to address their concerns. On the other hand vendor code dumps are usually haphazardly put together garbage that nobody wants to touch.

[forty]

Rebasing (possibly shitty) patches from the SBC vendor to a recent kernel can be non trivial in my experience (as someone who have 0 knowledge of the Linux kernel code, so I'm a good baseline to define what's trivial ^^). And yes most vendors are will ship one working kernel source and forget about it forever right after :) even vendors that are not the worse depend on drivers that are provided by the SoC vendor, and might be stuck because rebasing a GPU driver might even be hard for them I guess.

[megous]

Code will stay compatible (if someone refactors something, they'll update all the drivers), so that's not it. You just need to test your hardware with each new kernel release (every two months), otherwise you may not notice any breakage.