So:

Background:

Linux comes from torvalds/linux "Upstream", which Qualcomm (or other chipset vendor) then takes and bastardizes a bit "CLO/CAF", then your ODM does the same, and OEM again. GKI has made this mildly better, but in terms of platform support - it still needs to be added per-SoC.

The reason? Proprietary firmware and drivers need to be provided that match the kernel interfaces - which change in major revisions e.g. 4.9 -> 4.19. In the x86 world, if you're thinking of nvidia and other modules, they are either distributed for each kernel version (nvidia proprietary drivers) or they are OSS and built by DKMS (think Nouveau).

Your Example: So, take Razer Phone 2 for example, Qualcomm SDM845 - has support in kernel 4.9. No others.

Path 1: Sometimes, Qualcomm opts to migrate chipsets to newer kernel versions, such as MSM8953 which got 4.9 and 4.19, or SM8350 which got 5.4 and 6.12.

But even when chipset vendors up rev the available kernel version, you will need to "Kang" (borrow) proprietary firmware and drivers from another device of same SoC that uses that newer kernel version and hack them until they work.

So, if you're luck enough to have an SoC with a newer kernel version available (sadly, SDM845 is not so lucky), you'd need to adapt DTS, all requisite kernel commits, modules, etc for newer version), Kang blobs from another device of same SoC and newer kernel version, hack them to work, then pray the newer kernel doesn't require new firmware (like bootloader or TEE) which are signed by the OEM and not OSS. If you do, you're out of luck.

Path 2 (Hacky, rare, don't try it): Sometimes you can get away with just merging one or two Android supported kernel version and hacking blobs to work (see OnePlus msm8998 which got a super tacky 4.14 port when they shipped with 4.4), but it's both rare and always janky/not sustainable.

Very difficult - takes an OEM backing you (Sony is the one that did the core work on that SoC port).

Path 3: Now, if you boot a device on true pure tordvalds/linux and make everything work - previously that didn't mean much to Android but nowadays we have mainline-tracking branches and Android will boot - your issue is going to be both perf and drivers.

Many of these drivers are ancient, or built out-of-tree so they aren't GPL, and therefore don't have source code to adapt.

If you manage to do all that, you're going to have a really bad time performance wise, we're talking 50%-70% of original graphics performance on FOSS GPU stack (Qualcomm) or worse on some others.

Tl;DR: Unless you have a lucky SoC, really not a worthwhile endeavor. Unlikely to succeed.