Tell me that you do not understand the problem space of supporting ARM SoC in the upstream #Linux #kernel at all (including #RaspberryPi support) without telling me that you do not understand that problem space.

No, I don't want to make fun of the one who posted that. It's totally valid to ask that question like that, especially when coming from a x86_64 background.

Which is why I found it a good example showing that some (a lot?) of users not even remotely understand the things many of us are dealing with every day – not even the basic "the Raspberry Pi might run Linux[1], but Linux[2] only supports it partially – and it supports new models often not a all within the first few months (sometimes years)".

Or the aspect "ARM SoCs and boards build around them are a bit like a combination of a slightly or heavily modified x86_64 cpu with a special designed motherboard incl. a GPU et. at., which is why support for one ARM chip does not mean at all that other ARM chips with the same ISA are supported, too.

And there are more. Like non-redistributable firmware files, less standardization or common ground in various areas like booting and hardware-introspection, ….

[1] here the word means a Linux distribution that is using a patched variant of Linux[2]

[2] here the word means the kernel called "Linux" distributed through kernel.org

@kernellogger maybe that question also makes "more sense" if the person comes from an x86 world? Where devices can typically be discovered through probing. Where EFI etc. standardizes the booting process. While on ARM you typically have to "wire" them in through a DTS file. And have differing, hard-coded boot offsets in a u-boot config etc.
I wish the ARM+MIPS world would adopt some of the mechanisms from the x86 world. That would also make it so much easier to add device support in #OpenWrt.

@T_X "comes from the x86 world": definitely!

"would adopt": ARM and others did a lot or work in that area, but it seems at least some parts of the industry ignore that and just continue to use the approaches they are used to :-/

@kernellogger Deep inside, I am sad that RISC-V doesn't seem to be doing much better than ARM in that regard.

@T_X @kernellogger It is already happening. Many ARM64 platforms use ACPI in a sane way. Some, like Qualcomm Snapdragon, uses ACPI in borked way making it completely unusable for Linux. So yes, they adopted something from x86 world and still this makes it no easier for Linux or any other non-qcom OS.

@kernellogger Is this a mistake made by ARM or by kernel developers or who?

I had an ARM-based chromebook some 10 years ago, it kinda worked as a pure Linux desktop... and seems like not much progress has been made in the last decade.

Seems to me that Snapdragon should've eaten both Intel and AMD for breakfast.

@vegai I assume by "mistake" you mean the situation wrt to Linux support for the Snapdragon-based Laptops sold with Windows?

That I'd say is 95+ percent Qualcomm's fault. If they had got proper support upstream (especially into Linux [the kernel] and Mesa) and made all the necessary firmware files redistributable, then Fedora, Ubuntu, et. al. and the community would have done a lot of the other things by now to bring things to the level of x86 laptops (where things are not perfect either, but way better).