Back- and forward-porting code is just hard. There are ~183000 commits between current Linux and Linux 3.10, and even though most of those are driver changes or make only minor changes to core APIs, there are going to be dozens or hundreds of small changes you'd need to make to a driver to forward-port it to modern Linux, or to a security fix to backport it to an Android kernel.
You could have a long-term stable API between the drivers and the rest of the kernel, but the kernel developers don't want that because it would restrict their ability to make breaking changes in the interests of performance or maintainability. It would also encourage proprietary drivers even more, and make them explicitly legal (at the moment, proprietary drivers are at best in a grey area, and most likely illegal).
The lack of a stable kernel API may be part of it but I think the main reason drivers don't get into the mainline kernel is that they are written as big hacks: hard coding values and not following standard kernel practices.
Instead of using a device tree the drivers expects memory address to be passed to the uboot command line and other venders just hardcode the addresses, making you modify the sources to run the driver on a different device
On one project I attempted to move the kernel from 3.0.35 to 3.10 and even that was a huge pile of problems, asking vendors to bring their drivers up to speed. Some did, some didn't. It wasn't worth the trouble so off we went, shipping with 3.0.35.
Well i think it is the closest ARM has to PCI enumeration right now.
Best i recall, Intel started Moblin (that later merged with Maemo to from Meego) because their mobile Atom SoC didn't provide PCI enumeration. Thus MS was reluctant to provide a Windows version for it, as Windows was highly reliant on just that for hardware management.
Didn't Open Firmware solve all these problems years ago? I'm pretty sure I remember operating systems being able to use Open Firmware to query option ROMs for driver details in a scalable (and machine independent!) way, way back in the 1990s.
It's always saddened me that Open Firmware never got picked up for IA. They went for EFI instead...
Proprietary drivers already exist and they are legal. (Whether or not that's a good thing, is a different, controversial topic.) They work by having the user compile an open-source shim module which allows device control from userspace. Then the user installs a proprietary program into userspace (i.e. as the root user) and this program permits control of the device from the rest of userspace.
There is nothing explicitly stopping a user from installing a different, open-source program that talks to the open-source shim module.
You could have a long-term stable API between the drivers and the rest of the kernel, but the kernel developers don't want that because it would restrict their ability to make breaking changes in the interests of performance or maintainability. It would also encourage proprietary drivers even more, and make them explicitly legal (at the moment, proprietary drivers are at best in a grey area, and most likely illegal).