It's not that easy though. The kernel doesn't have a stable internal API, which means that it's nearly impossible to maintain an out-of-tree driver. The kernel

It's not that easy though. The kernel doesn't have a stable internal API, which means that it's nearly impossible to maintain an out-of-tree driver. The kernel operates on a classic google-style monorepo model (well, maybe google-style isn't a good term, after all, they certainly didn't invent it...) because when someone changes a kernel API they are obligated to ensure the change is propagated to all related code. You get maintenance basically for free in the kernel, but only if you build an in-tree driver. FWIW, a proprietary "binary blob" driver has already been available for a while that was built out-of-tree, but it constantly has to be updated for the latest kernel and doesn't release a version for every single kernel, so it's very difficult to use it unless you either 1) specifically use the exact version the driver requires (which is ridiculous-you should be able to dictate which kernel version you want) or 2) use a well-known and well-supported repo (which limits your choice as well). Ultimately, the best way to get driver support into the kernel is to go through the standard kernel channels. And also FWIW, the kernel does care about how drivers are written-even if the driver is out-of-tree, its possible shittiness reflects back (totally unfairly, I know) on the kernel. By having a gatekeeper for device drivers, they can ensure that the kernel is as stable as possible for as many users as possible, and that's a laudable end goal. It's also orthogonal to wide hardware support, as all that was required in this situation was for AMD to adhere to the guidelines properly, but they didn't do so, so they have no right to be upset that their code got rejected.