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

[Hanjun Guo <guohanjun@huawei.com>]

Hi Hans,

On 2026/6/23 22:52, Hans de Goede wrote:
> Hi All,
> 
> Currently as soon as the kernel boots with a populated DT provided then
> the arch/arm64 code sets acpi_disabled=1 and the complete ACPI subsystem
> gets disabled. On WoA Snapdragon laptops where the factory Windows OS
> actually boots using these tables this is not necessarily desirable.

That exactly to let us know what's missing for DT or ACPI, then we can
identify the missing parts of the device descriptions for booting.

> 
> It might still be interesting to at least parse the ACPI tables and make
> the ACPI fwnodes available for device-drivers to use. I call this DT-ACPI
> hybrid mode.
> 
> This mainly is an experiment for now and possibly a method for accelerating
> the ongoing effort to run Linux on currently available Snapdragon laptops.
> 
> On current laptops Linux cannot boot using ACPI due to some information
> missing from the ACPI tables. People are working on changing this so that
> for future WoA Snapdragon laptops Linux can boot using ACPI only without
> requiring Devicetree.
> 
> 
> There are a couple of scenarios where DT-ACPI hybrid mode is useful:
> 
> a) This leads to a populated /sys/firmware/acpi/tables allowing one to run
> acpidump, which is useful to grab info from the ACPI tables when e.g.
> creating a DT for a new laptop model. As a bonus /sys/firmware/acpi/bgrt
> is also populated allowing the boot-splash to show the vendor logo.

I think this is just for debug purpose, not for production.

> 
> b) It might be useful for device-drivers to be able to access ACPI data
> for the device even when running in DT mode. 

On the other hand, it will introduce confusion if we have problems to
solve or bugs to fix, how can I quickly identify it's a ACPI table
problem, a device tree issue, or both?

[...]
> 
> Comments, thoughts ?

Please take look at the document of ACPI for ARM64, it says:

Relationship with Device Tree
-----------------------------
ACPI support in drivers and subsystems for Arm should never be mutually
exclusive with DT support at compile time.

*At boot time the kernel will only use one description method depending*
*on parameters passed from the boot loader (including kernel bootargs).*

Regardless of whether DT or ACPI is used, the kernel must always be
capable of booting with either scheme (in kernels with both schemes
enabled at compile time).

So why we wrote it down when we upstream the ACPI support for ARM64?
because ACPI is a standard and we need to make the ARM64 parts
public available for the ACPI spec, then we add the support
for the kernel, if not, people will hack the system to just make it
work, it's bad for compatibility and maintainability.

Thanks
Hanjun