Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode

[Bjorn Andersson <andersson@kernel.org>]

On Fri, Jun 26, 2026 at 03:43:59PM +0100, Bryan O'Donoghue wrote:
> On 26/06/2026 15:33, Bryan O'Donoghue wrote:
> > On 23/06/2026 15:52, Hans de Goede wrote:
> > > Comments, thoughts ?
> > 
> > Throw out DT and just do this...
> > 
> > One thing I like about this approach TBH is that you don't do the easy
> > thing of presuming to push the hard work into the bootloader - thus
> > creating a dependency on bootloader.
> > 
> > We've had _alot_ of problems doing DT selectivity to get OSes installed
> > on arm64 laptops. You mentioned I2C-HID devices and EC controllers which
> > I agree are a good and obvious targets.
> > 
> > I don't think this can replace a full and complete DT but, then I don't
> > think that should be the objective.
> > 
> > Much like installing cursed OSes like Windows on "normal" laptops or x86
> > machines, you'd expect to boot in ACPI mode have enough of the OS
> > running to install more of the OS - which I think _can_ be a viable
> > objective with an ACPI-DT translator.
> > 
> > Sadly OpenBSD could boot all the way to console on the Qcom laptops
> > where Linux could not - because ACPI support was better there.
> > 
> > And, we have Nvidia laptops coming too, Windows laptops which will parse
> > ACPI tables to boot.
> > 
> > There's almost no upside in having ACPI data and not trying to make
> > maximal use of it, especially if you don't have a DT supplied by
> > antecedent boot stages.
> > 
> > ---
> > bod
> > 
> 
> I'm going to agree with myself some more on the boot story.
> 

Good for you.

> If you can boot Linux _at_all_ and dump out ACPI tables from the booted
> system you are way further along than not being able to boot without a
> "real" DT.
> 
> Again, bootloaders have had to be educated on how to make that DT selection
> - a problem that isn't well solved or converged on - and even if such an
> agreed method were present, exactly 100% useless to you without the DT to go
> with it.
> 

The problem of selecting "after-market hardware description" will remain
as long as "BIOS" ships without upstream-compliant descriptions. I'm not
sure I understand in what way your comment relate to the patchset at
hand though.

> As a Linux user I don't expect everything to work, especially so on aarch64
> but, if I can get to a boot console with a screen and keyboard - I have
> scope to play in a way I otherwise don't - parsing DSDT from Windows and
> walking backwards to DT.
> 

We supported this on SDM850 and 8cx, we had sufficient amount of
support/quirks in Linux to allow you to boot and run the Debian
installer - but that's how far it was possible to push things without
improving ACPI specification and tables.

Given that you couldn't run any real use cases, this was not adequately
maintained and as we moved on to 8cx Gen3 I argued that we should
prioritize the DT-effort.

> DT _should_ be the landing zone of course but, ACPI-DT hybrid to "just boot"
> seems like an obvious yes to me.
> 

But this proposal doesn't give you ACPI+DT, it gives you DT+ACPI, you
still need a base DT that is somewhat functional - and then you
explicitly need to make references to the external ACPI representation.

Quite nice for experimentation, but I don't think it will solve either
of your problems.

Regards,
Bjorn

> ---
> bod