Linux devs what part(s) of the kernel do you hate with a passion

@sterophonick devicetree

@frog why do it suck

@sterophonick imagine if you needed to write a big file describing your PC hardware and it wouldn't boot without it for exactly no fucking reason because ACPI exists.

@frog @sterophonick from firmware developer perspective, devicetree is much saner than ACPI lol

OS developers shouldn't have to write one though, it should be passed to the kernel by firmware

@elly @sterophonick That doesn't work if you're trying to run regular Linux on unsupported hardware (so, every Android phone, WoA laptops and old Windows Phones :P)

We are in the realm of someone has to ship these things somehow to make X hardware work, nobody is. So the "meta" is "oh just download this random dtb/build from X kernel tree and somehow shove this in your ESP and specify `devicetree blah` in grub"

It's just not sustainable or a realistic option.
(Especially when, afaiu these devices support ACPI, but drivers and other parts of kernel are not hooked up for that...)

Is there even a guarantee in the kernel for backwards compat for older DTs now? I remember there was some discussion a while ago and the answer was: No. That kinda rules out the firmware option you are suggesting anyway right?

This whole thing is such as mess :<

@frog @sterophonick

That doesn’t work if you’re trying to run regular Linux on unsupported hardware (so, every Android phone, WoA laptops and old Windows Phones :P)

Trust me, I know

https://gitlab.com/postmarketOS/pmaports/-/raw/master/device/community/linux-postmarketos-mediatek-mt8183/arm64-dts-mediatek-mt8183-Add-video-encoder-decoder.patch

https://gitlab.com/postmarketOS/pmaports/-/raw/master/device/community/linux-postmarketos-mediatek-mt8183/arm64-dts-mediatek-mt8183-Add-missing-GPU-clocks.patch

(etc)

So the “meta” is “oh just download this random dtb/build from X kernel tree and somehow shove this in your ESP and specify devicetree blah in grub”

Yeah, that doesn’t work. DT bindings in downstream kernels aren’t compatible with upstream.

Is there even a guarantee in the kernel for backwards compat for older DTs now? I remember there was some discussion a while ago and the answer was: No.

I thought this policy was adopted a while ago?

If you modify a driver, you need to ensure it doesn’t break bindings that have been in place before the change - and of course all changes need to be documented or maintainers will chase after you (i.e Robert Foss).

That kinda rules out the firmware option you are suggesting anyway right?

Well, assuming I’m right (and they did in fact adopt this policy)… no? Once you write working devicetree, you shouldn’t have to worry about it ever again since it’s supposed to be forwards-compatible.

ACPI isn’t a silver bullet either, especially on odd hardware such as Chrome{books,boxes}, which use special hardware like USB muxers, DSP, I2S codecs and so on. We often need to patch things up in firmware, as upstream maintainers are very, very stubborn - to the point where we decided to not deal with them and do as much as we can in coreboot.

This of course means that stock firmware Google ships on those machines technically supports AltFW (EDK2), but almost nothing works correctly. They don’t test it properly, we don’t want to deal with maintainers of drivers/platform/chrome, so you basically need to replace firmware with our builds that fixes all bugs.

If you’re bringing up a new platform, you will need to do kernel and firmware work - it’s just a matter of which brings you less pain. So far for me, ARM64 seems a lot saner than x86

You can take a look at interrupt routing that gets fed into acpigen on x86 for instance… https://github.com/coreboot/coreboot/blob/main/src/soc/intel/tigerlake/acpi/pcie.asl

@elly @sterophonick Thanks for the write up.

If stuff is forward compatible that's cool.

The problem with having fw provide the dt, is a lot of these devices are not running custom fw -- coreboot, tianocore, all that stuff is super cool. But realistically it's not going to happen for every one of these devices...

@frog @sterophonick Happy to see people enjoying my infodumps :D

True, that's why for devices that don't have this option, it's good to have "3rd-stage payload" - such as U-Boot or LinuxBoot, which gets rid of firmware-related complexity (i.e depthcharge, lk), patches things up (ACPI/DT) and then loads the kernel.

Of course it would be great if we could replace i.e Qualcomm's XBL entirely, but thanks to keys in BootROM and closed-source TEE/TF that needs to run in EL3, it pretty much impossible unfortunately

@frog @sterophonick @elly being forward compatible was a requirement from the start IIRC as it would have been impossible to maintain otherwise without an insanely big ci system!

@elly @sterophonick @frog The way it's meant to work is that if you get your bindings upstream, then Linux will stay compatible with those. Obviously every rule has some exceptions, but that's the policy we "inflict" on people and do our best to prevent that breaking.

What ends up happening though is that while the description for a particular peripheral etc is stable and Linux tries to be backwards compatible, the actual dts files often evolve over time, with new peripherals being added etc. Cos of thatm you need to update the dtb get the new support. In an ideal world where every SoC and board was in mainline before customers got it, you'd not need to change anything.