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

[Bryan O'Donoghue <bod@kernel.org>]

On 29/06/2026 02:34, Bjorn Andersson wrote:
> 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.
>> 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.

Boot to console is infinitely superior to not booting at all, if OpenBSD 
can boot to console on day 1, a community project with no funded effort, 
how much effort is really involved in Linux being able to do the same 
thing ?

https://undeadly.org/cgi?action=article;sid=20240620105457#:~:text=se%3E%20Date%3A%202024%2D06,I%20beat%20my%20last%20record.

Console, keyboard, NVME, USB. I believe their policy is also ACPI to 
bootstrap until DT gets going sufficient.

There's nothing to stop populating DT nodes with ACPI data being part of 
that boot story.
>> 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.
There are two arguments, three really.

- Boot in ACPI mode to console.
   This should be done, it at least allows people to tinker with their
   hardware.

- DT-ACPI mode.
   This proposal. Surely worthwhile doing and not incompatible with your
   notion of shipping an upstream compliant DT somewhere.
   In fact it might even let you boot enough of a system based on a
   silicon vendor DT that never changes to again - allow end users to
   actually do something with their hardware absent lots of upstream
   churn post release.

- ACPI-DT mode.
   It is entirely possible to have Linux eat ACPI tables and produce
   in-memory DT. Not easy or nice but technically feasible.

   It could even be hybrid with the first bullet point.

Either way supporting more ACPI on the boot path shouldn't be a barrier 
to better DT support.

---
bod