In the EBBR specifcation we require to use either ACPI tables or a device-tree.
[RFC 00/12] RFC: Devicetree-ACPI hybrid mode https://lore.kernel.org/linux-acpi/20260623145225.143218-1-johannes.goede@os... suggests to use a mix of ACPI and device-tree in Linux for better supporting Qualcomm latops.
We may have to revisit our requirement.
Best regards
Heinrich
Hello Heinrich,
On Tue, 23 Jun 2026, at 20:13, Heinrich Schuchardt wrote:
In the EBBR specifcation we require to use either ACPI tables or a device-tree.
[RFC 00/12] RFC: Devicetree-ACPI hybrid mode https://lore.kernel.org/linux-acpi/20260623145225.143218-1-johannes.goede@os... suggests to use a mix of ACPI and device-tree in Linux for better supporting Qualcomm latops.
We may have to revisit our requirement.
This is just an RFC that has little chance of being adopted. It is not the kernel's job to reason about how to reconcile two overlapping hardware descriptions.
Hi Heinrich,
On Tue, 23 Jun 2026 at 21:10, Ard Biesheuvel ardb@kernel.org wrote:
Hello Heinrich,
On Tue, 23 Jun 2026, at 20:13, Heinrich Schuchardt wrote:
In the EBBR specifcation we require to use either ACPI tables or a device-tree.
[RFC 00/12] RFC: Devicetree-ACPI hybrid mode https://lore.kernel.org/linux-acpi/20260623145225.143218-1-johannes.goede@os... suggests to use a mix of ACPI and device-tree in Linux for better supporting Qualcomm latops.
We may have to revisit our requirement.
This is just an RFC that has little chance of being adopted. It is not the kernel's job to reason about how to reconcile two overlapping hardware descriptions.
I understand the desire to use ACPI with Qualcomm laptops but this is not necessarily a good idea, unless the goal is just to force ACPI everywhere. The DT is working well today on a very large range of Qualcomm devices, not to mention many other ARM vendors. We should stick with it unless there are critical problems to resolve.
Qualcomm could encourage OEMs to allocate and publish a compatible string (or string list) in the firmware (vendor,device), so that the hardware can be identified easily, e.g. via a configuration table or EFI protocol (assuming it is running Tianocore/EDK2). The compatible string is the approach that hundreds of ARM Chromebook models have taken for the last dozen-or-so years (including with Qualcomm Chromebooks) and it works well.
Regards, Simon
boot-architecture@lists.linaro.org