From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Shevchenko Date: Tue, 3 Mar 2020 16:56:41 +0200 Subject: [PATCH v1] x86: acpi: Refactor XSDT handling in acpi_add_table() In-Reply-To: References: <20200227140051.75072-1-andriy.shevchenko@linux.intel.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Mar 3, 2020 at 12:00 PM Wolfgang Wallner 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