From: Bryan O'Donoghue <bod@kernel.org>
To: Hans de Goede <johannes.goede@oss.qualcomm.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>
Cc: Srinivas Kandagatla <srini@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Dmitry Baryshkov <lumag@kernel.org>,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
Abel Vesa <abel.vesa@oss.qualcomm.com>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-acpi@vger.kernel.org
Subject: Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode
Date: Fri, 26 Jun 2026 15:43:59 +0100 [thread overview]
Message-ID: <b5283758-bf75-4906-b821-d6bd7a81e3cd@kernel.org> (raw)
In-Reply-To: <04b4f1b0-4d8f-41eb-9b6f-d90b88aec2ff@kernel.org>
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.
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.
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.
DT _should_ be the landing zone of course but, ACPI-DT hybrid to "just
boot" seems like an obvious yes to me.
---
bod
next prev parent reply other threads:[~2026-06-26 14:44 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <pskkNka1-QtLVb1tcyyUSjNNeMAWUUOLyvn0XSpq55AyeqXnEjOWDCXF1pWVAufJEya52NTx6ZCXz5dMHcMlyQ==@protonmail.internalid>
2026-06-23 14:52 ` [RFC 00/12] RFC: Devicetree-ACPI hybrid mode Hans de Goede
2026-06-23 14:52 ` [RFC 01/12] ACPI: Introduce DT-ACPI " Hans de Goede
2026-06-23 14:52 ` [RFC 02/12] arm64: acpi: Cleanup acpi=[on|off|force] handling Hans de Goede
2026-06-23 14:52 ` [RFC 03/12] arm64: acpi: add acpi=hybrid support Hans de Goede
2026-06-23 14:52 ` [RFC 04/12] ACPI: Add helpers for dealing with ACPI fwnode as secondary fwnode Hans de Goede
2026-06-23 14:52 ` [RFC 05/12] ACPI: glue: Implement setting secondary-fwnode for DT-ACPI hybrid mode Hans de Goede
2026-06-23 14:52 ` [RFC 06/12] ACPI: scan: Retry acpi_device_notify() in " Hans de Goede
2026-06-23 14:52 ` [RFC 07/12] ACPI: Make device_match_acpi_handle() also check the secondary fwnode Hans de Goede
2026-06-23 14:52 ` [RFC 08/12] irqchip/gic-v3: Always call acpi_set_irq_model() Hans de Goede
2026-06-23 14:52 ` [RFC 09/12] pinctrl: qcom: Add support for WoA ACPI tables virtual TLMM pin numbers Hans de Goede
2026-06-29 1:59 ` Bjorn Andersson
2026-06-29 10:30 ` Hans de Goede
2026-06-23 14:52 ` [RFC 10/12] i2c: acpi: Also register ACPI i2c_clients for adapters with a secondary ACPI fwnode Hans de Goede
2026-06-23 14:52 ` [RFC 11/12] i2c: qcom-geni: Fall back to i2c_acpi_find_bus_speed() Hans de Goede
2026-06-23 14:52 ` [RFC 12/12] arm64: dts: qcom: x1e78100-thinkpad-t14s: Move keyb and touchpad to ACPI enumeration Hans de Goede
2026-06-29 1:43 ` Bjorn Andersson
2026-06-29 10:19 ` Hans de Goede
2026-06-25 10:18 ` [RFC 00/12] RFC: Devicetree-ACPI hybrid mode Konrad Dybcio
2026-06-26 14:33 ` Bryan O'Donoghue
2026-06-26 14:43 ` Bryan O'Donoghue [this message]
2026-06-29 1:34 ` Bjorn Andersson
2026-06-29 8:41 ` Bryan O'Donoghue
2026-06-26 15:52 ` Sudeep Holla
2026-06-26 20:57 ` Dmitry Baryshkov
2026-06-27 14:12 ` Sudeep Holla
2026-06-28 19:23 ` Dmitry Baryshkov
2026-06-29 8:22 ` Sudeep Holla
2026-06-29 2:27 ` Bjorn Andersson
2026-06-29 10:07 ` Hans de Goede
2026-06-29 11:48 ` Hanjun Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b5283758-bf75-4906-b821-d6bd7a81e3cd@kernel.org \
--to=bod@kernel.org \
--cc=abel.vesa@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=devicetree@vger.kernel.org \
--cc=johannes.goede@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=rafael@kernel.org \
--cc=srini@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.