Hi Ard, On Fri, 19 Sept 2025 at 09:50, Ard Biesheuvel <a...@kernel.org> wrote: > > On Fri, 19 Sept 2025 at 17:10, Simon Glass <s...@chromium.org> wrote: > > > > Hi, > > > > On Mon, 8 Sept 2025 at 15:41, ff <f...@shokubai.tech> wrote: > > > > > > > > > > > > On 8 Sep 2025, at 20:43, Heinrich Schuchardt > > > <heinrich.schucha...@canonical.com> wrote: > > > > > > > > > > > > > > > ff <f...@shokubai.tech> schrieb am Mo., 8. Sept. 2025, 19:27: > > > Dear fellow firmware aficionados, > > > > > > Static ACPI has been adopted by Mercedes and other silicon vendors to: > > > - meet the safety requirements > > > - stay away from DT lifecycle issues > > > - leverage chiplet and CXL bindings > > > - truly multi-host/hypervisor (or even secure/no-secure should people > > > want it) as bindings are defined in an ad-hoc forum (not by an OS > > > community) > > > > > > Hello François, > > > > > > Thanks for sharing. > > > > > > Which organization do you refer to by ad-hoc forum? Ad-hoc does not sound > > > like a specification body. Wouldn't this work be done in the UEFI Forum? > > > Yes > > > > > > If ACPI looses the dynamic powers of ASL, what purpose would it serve > > > that is not already covered by device-trees? > > > Absolutely. And so from a descriptive point of view they are « equal ». > > > The existential DT problem is its life cycle , i.e. not provided by > > > firmware (secure or not). A new forum should be established to address > > > arm, riscv x86 to define DT (EBBR is a good example that cross arch > > > collaboration can be done. And Linux community shall stop tinkering all > > > the time with this. > > > > > > Do the Mercedes aficionados plan to upstream the drivers changes? > > > It will/is in efi forum. There will be public publications by other > > > vendors. > > > > > > Best regards > > > > > > Heinrich > > > > > > > > > > > > DT community leaders and enthusiasts, I believe discussion on the bigger > > > picture related to DT relevance in the long run may be needed as I > > > believe many embedded solutions will follow Mercedes example. > > > > IMO the reason ACPI doesn't have to worry about the OS needing a > > particular devicetree is that the ACPI tables don't describe > > everything. > > ACPI tables and AML do describe everything that cannot describe > itself, otherwise, how would the OS know about the presence of those > undescribed peripherals?
Indeed, but you have actually explained this yourself below. > > The main difference is the level of abstraction: AML carries code > logic along with the device description that can en/disable the device > and put it into different power states. This is backed by so-called > OperationRegions, which are ways to expose [abstracted] SPI, I2C and > serial busses to the AML interpreter (as well as MMIO memory) so that > the code sequences effectuating things like power state changes can be > reduced to pokes of device register, regardless of how those are > accessed on the particular system. > > On x86, many onboard devices are simply described as PCIe devices, > even though they are not actually connected to any PCIe fabric. This > solves the self-description problem, vastly reducing the number of > devices that need to be described via AML. > > Also, there is a lot more homogeneity in how the system topology is > constructed: on embedded systems, it is quite common to, e.g., tie the > PHY interrupt line from the PCIe NIC to some GPIO controller that is > not a naturally associated with that device at all, and this is > something ACPI struggles with, and where DT shines. > > DT simply operates at a different abstraction level - it describes > every detail of the system topology, including every clock generator > and power source. This makes it very flexible and very powerful, but > also a maintenance burden: e.g., if some OEM issues a v2 of some board > where one clock generator IC has been replaced because the original is > EOL, it requires a new DT and potentially an OS update if the new part > was not supported yet. ACPI is more flexible here, as it can simply > ship different ACPI tables that make the v2 board look 100% identical > to the v1 as far as the OS is concerned. There is also the PEP addition you mention below, which I tend to see as an admission that ACPI cannot handle the complexity of modern systems. > > But the problem re having to worry about the OS needing a particular > devicetree has nothing to do with any of this. The problem here is > that there is no process or hygiene in the kernel community around > backward compatibility. The exact same piece of equipment is described > in a different way in every kernel version. And how these descriptions > differ from one another is not documented. > > If DT bindings were versioned, and drivers would remain compatible > with the old version as support for a new one is added, many of the > kernel vs DT version issues would go away, and only actual > bugs/inaccuracies in device trees would require firmware updates or > other means to switch over to an updated version. > > However, there is no ambition whatsoever in the Linux community to > address these issues. Developers are actively opposed to putting DTs > in firmware, because then they are on the hook to honour the bindings > indefinitely. Yes, I agree. I did see that Rob Herring did some work on checking for incompatible changes in the schema, but I have not been following it. For now we need to support having the DT in both firmware and the OS. > > > > The new way to handle this seems to be with an OEM- or > > device-specific Windows driver. I'm not sure how that would work in > > Linux. > > This is why the Windows-on-ARM ACPI laptops cannot boot in ACPI mode > in Linux: ACPI is not suitable for describing these systems, and so on > Windows, they basically re-invented board files for ACPI (called PEP). > This is mostly due to the complex SoC topology, which pure ACPI cannot > describe with sufficient accuracy and so they just ship some > board-specific drivers and wire them up via minimal ACPI abstractions. This is exactly my point. > > > My Qualcomm laptop (using Linux) currently just reboots if it > > gets too hot. > > > > Not sure what you are trying to say here. Is this a dig at ACPI? Or > Windows? Or both? Neither...I'm just pointing out the implications of ACPI for these systems. Without a driver for the complex thermal (in this case) trade-offs, they are not reliable. We need DT rather than ACPI. We also need a way to control the pan / read temperature sensors etc., which may mean talking to an EC. So we also need a kernel driver for that, or even ideally some standard message format. Regards, Simon _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
