Yea, but I think that is a response to google not allowing / strongly encouraging android kernel patches into mainline. This is a huge difference than the previous model where there were forked versions of the system tied to a kernel version.
This talk is a great overview of where things are going...
Distro? I dunno probably not without at least some tweaking at least to the DT.
Stock android? Yes, perhaps. Some functionality from devices is provided via closed firmware blobs that you'll need too. I'm thinking of the modem or other DSPs at least. However I suppose that projects like LineageOS just harvest those from working phones?
I know one developer at Qualcomm who uses Linux on their Snapdragon laptop.
The firmware blobs will be what people are objecting to, if they're specific to a kernel version. What you really want out of this is to be able to install updated kernels on the device without needing a corresponding firmware blob nobody has released.
The firmware blobs execute on the peripherals that happen to be software programmable - not on the CPU (or "apps" CPU). And therefore they're not bound to a particular kernel.
IMO the blobs aren't very objectionable while still not ideal. Would I prefer to have the source to software running on all the peripherals? Sure, I would. But once you're programming on the peripherals it narrows significantly the audience who's interested and capable at changing behavior or making fixes.
I could be wrong but I think this is actually somewhat common.
This is not genuine argument. Check the sources at kernel.org and you will see tons of Qualcomm drivers upstreamed by Qualcomm.
Did Qualcomm do a bad job w upstreaming, for years? yes, they did. Are they improving? yes, IMO they are.
disclaimer: Qualcomm employee.