The goal is to always upstream every driver (and we do a pretty good job at that). Depending on the lineage of the software (who developed it, what they developed it for) - it may not be possible to meet the kernel coding guidelines - so we don't send those upstream.
It baffles me how many times companies go "oh, instead of contributing these changes to an existing distribution, or the mainline, let's release our own shitty fork of that major distribution, which of course we will do a terrible job of keeping current with, and stop maintaining after about a year because the intern that was doing it moved on."
I always thought the reason for this is that you can't just dump any half-baked crap into the kernel repo, it needs to have a certain level of quality. Its just cheaper that way, and there is no back-and-forth discussing issues for several months. But maybe I'm wrong?
under drivers/ there is a place called staging/ that you put your drivers there until it's solid then becomes official, to encourage exactly that, it's way better a place to host drivers than vendor's own repo or distro, in my opinion.
As I understand, Linux doesn't have a kernel-to-driver API so "upstreaming" a driver means that you have to maintain it and update every time something in the kernel changes.
Windows driver model is so much better. Windows driver model allows you (in theory) to run drivers written 20 years ago.
Linux model doesn't scale because the more drivers the kernel includes, the more work is required to update them when something changes.
Also Linux model doesn't allow reusing unmodified drivers by other operating systems. So developers of other OS's have to duplicate the work that already has been done.
That's what you have to do if you don't upstream. The Linux community is responsible for updating any upstreamed drivers that are affected by code changes that they make.
