On Tue, Mar 3, 2020 at 12:00 PM Wolfgang Wallner <[email protected]> wrote:
... > > Wait, this is not a *name*, this is ACPI _HID. ACPI _HID, of course, > > should be somewhere in board code. > > > > I was thinking myself about some U-Boot framework that actually takes > > ACPI _HID from the driver. So, when you define in U-Boot device tree a > > compatible string (for U-Boot use), in the driver it will have in the > > class structure the callback / field / stubstructure to use when ACPI > > generate tables is enabled. It will drop duplication of compatible > > with ACPI _HID in each DTS. > > There is a related discussion in another thread, here is the link: > https://lists.denx.de/pipermail/u-boot/2020-February/398856.html Thank you for pointing this out. I totally agree with you. I really do not like the idea of polluting DT with ACPI bits. > I have brought that up, but I'm no expert in this area, so any feedback would > be welcome. > > That discussion is not only about inferring _HID, but also about the idea of > inferring other ACPI properties from device tree (the example discussed is the > HID offset). Yes, that's what I'm implying above as well. I'm on the same page with you! -- With Best Regards, Andy Shevchenko
