@artagnon

> The #kernel community seems pretty annoyed.

Source? I briefly looked at https://lore.kernel.org/ to find something, but there were so many hits and nothing you might have referred to quickly stood out, but I guess I just did not look closely enough.

@artagnon

Sorry, my question was imprecise. I knew about that stuff. But I had understood your toot as if the kernel community was annoyed by the "non-ACPI boot up process". But from looking at it again I miss-interpreted the text. Sorry again.

@artagnon @kernellogger The Phoronix clickbait still goes? That's so bollocks and so weird because Michael Larabel usually understands that stuff... Can we stop spreading this sort of FUD?

All GPUs for all upstream supported boards are enabled. Nothing got disabled by
"default". You have usable laptops. And whatever shady deals you mention, is so imprecise that not worth responding...

@artagnon @kernellogger With such clickbaits, Phoronix goes from poor source of knowledge about Linux kernel to "junk" source.

@artagnon @kernellogger Since I am one of folks who receives/gets-cc all the patches for all Qualcomm Snapdragon X1 Elite laptops (and I work on this with Dmitry), I can tell you that several laptops are already supported in decent way. The support varies, because it is work in progress and laptops do not work with ACPI under Linux (ask Qualcomm), thus require DTS.

Except reference or developer devices we already have: Lenovo Thinkpad Yoga Slim 7x and ASUS Vivobook S15.

There could be more easily, but someone has to actually buy that device and submit DTS. Adding support Lenovo Slim 7x was pretty trivial, according to Srinivas who posted the patches.

So which exactly "first-hands" reports do you mean? People trying to run random kernel without DTS hoping that ACPI will work? That never worked any of these devices...

@artagnon @kernellogger And I forgot - also Lenovo ThinkPad T14s, the third consumer-available laptop.

@artagnon @kernellogger

I’ve edited out the link. The LKML patch clearly states that the GPU requires OEM signing; nothing more.

Correct but why is that a problem? The ZAP firmware file needed for this will be most likely available. At least it is available already for two of mentioned earlier Lenovo laptops: Thinkpad Yoga Slim 7 and ThinkPad T14s.

Dmitry’s unimportant and harmless cleanup spurred some weird, harming gossips or uncertainties…

@krzk @artagnon

I more and more think a lot of Linux people (me included!) currently are in the need for a article along the lines of "the arm64 world is different: things to learn and things to unlearn for people primarily familiar with the internals of x86 Linux"

@kernellogger It boils down whether ACPI is properly implemented on given platform. There are ARM64 platforms running correctly under ACPI, e.g. most of the ARM64 servers, and you don't care about such differences.
The trouble starts when ACPI is not there (so almost all embedded designs, mobile phones/tables) or ACPI is somehow botched (e.g. Qualcomm Snapdragon compute platforms and laptops based on it), because then you go with Devicetree/DTS and everything starts... But such platforms are not consumer devices, usually. And really the Qualcomm Snapdragon for laptops should have just used ACPI.

RE: https://fosstodon.org/@kernellogger/112871174600451364

@krzk

related question just out of curiosity (so feel free to ignore!), if I may:

> the Qualcomm Snapdragon for laptops should have just used ACPI.

Windows boots via ACPI on those laptop, doesn't it? So is it possible to make Linux support it as well if someone would be really motivated? How much work would that most likely be? A lot?

@krzk @kernellogger What does ACPI has to do with GPU firmwares? Honestly, most of ARM "weirdness" comes from x86 lagging behind in hardware design. And affects RISC-V or MIPS in the exact same way.

@mripard Nothing, but the topic shifted towards why usage of such laptops is non-trivial in the beginning.

RE: https://fosstodon.org/@mripard/112874339733019220

@kernellogger The problem is that Qualcomm ships devices with some weird ACPI tables which Linux simply cannot use. I don't know the details good enough to explain more. Maybe it would require rewriting several drivers to work with such Qcom-ACPI-variant.

RE: https://fosstodon.org/@kernellogger/112874114752280325

@krzk

Ahh, interesting, many thx. That answer totally suffices for now -- and most like the details sooner or alter somewhere will come up somewhere!

thx again!

@krzk I still believe it's the same topic. Like, x86 now has the exact same problem that ARM had for a decade or so with cameras. And ACPI has nothing to do with it. But, as an industry, we only really care about fixing things if it affects x86, anything else is ARM being weird.

@krzk @kernellogger ACPI isn’t a magic bullet, it’s got very strong assumptions about how the hardware looks which lead to a miserable stream of quirks when they’re broken. It solves problems in its space but outside of that it just gets in the way. The problems the laptops (of all architecures) have often come down to ACPI not wanting to see a system that looks like a laptop.

@kernellogger @krzk Windows doesn’t meaningfully boot on with ACPI in the way it does on a server system, a lot of functionality is not described. It loads a large platform quirk driver which is essentially providing what the DT does on those platforms, you could do this with quirk tables in the kernel and not use “DT” but it’d be a distinction without a difference.

@broonie @kernellogger @krzk well, it would get us out of the unsafe DT loading problem, which is kind of nice.

@vathpela @kernellogger @krzk Could you expand on what that problem is?

@broonie @kernellogger @krzk the need to sign the FDT files and verify them before loading them. Admittedly I expect it's a little harder to do an exploit with a malicious FDT than with a malicious DSDT, but probably not that much harder.

@vathpela @kernellogger @krzk Oh, just general secure boot - that’s needed anyway for the initrd and is just a more widely applicable thing. Might actually end up being more tractable too…