Right. My point was that Qualcomm is not doing this themselves. The only snapdragon support in upstream (Linux, Mesa, etc.) is done by dedicated people in the OSS community.
Qualcomm (and MediaTek, etc.) fork the latest LTS kernel or android common kernel, hack it up for that SoC, and dump that on vendors as the msmXXXX kernel.
They'll rebase on top of upstream or android common kernel patches (of that version) for the contracted lifespan, and then pretend that SoC didn't exist.
This seems like such a short-sighted move by Qualcomm, is there some reason that they would do this and risk losing Google as a customer? Or, did they always assume that they would lose Google as a customer and so they thought it wouldn't be worth the investment?
Google really doesn't have much of a choice in the matter. As big as they are, so far it doesn't appear that they've decided that this isn't an important enough problem to make their own phone SoCs. Qualcomm doesn't exactly have many competitors that could be endorsed over them. Huawei/HiSilicon is anathema in US, Samsung uses Qualcomm's Snapdragon over their own Exynos line in the US, Amlogic and MediaTek don't make high-end SoCs, and Apple only makes them for their own phones.
Qualcomm thrives off of the trend of people expecting new phones every year (or every 6 months in some cases). Since they target the mid and high cost devices, all they have to do is make the phone work for a two or so years, and most people buying those phones are going to have gotten bored of their phone by then.
This is one of the main motivations for Project Treble, which is to completely disconnect the phone's userspace from the kernel version it runs on. It's a hard challenge though. Qualcomm and the other vendors for these high turnover products aren't all that interested in supporting it, because they benefit from replacing phones frequently. If you've ever looked at one of the phone kernels, they shove way more into them than upstream would ever accept (the entire radio stack, graphics stack, quick charge logic, etc.). This tends to make the software running on Android phones heavily coupled to the vendor kernel.
The downstream kernels are full of terrible and disgusting hacks. They're just doing the bare minimum to get some semblance of Linux running on the hardware, then forgetting about it almost entirely aside from whatever random security hotfixes they're going to release, and refocusing entirely on their next design. There's no real effort being put into coding for long-term maintainability, that's left to the hobbyist community.
