On Thu, Oct 06, 2016 at 02:26:50PM +0200, Rafael J. Wysocki wrote: > On Thu, Oct 6, 2016 at 10:57 AM, Lorenzo Pieralisi > > I am trying to understand why x86 wants to do this, please understand > > our point of view too, we do not want to block progress we want to > > prevent a mess. > It is not "x86" who wants to do that. > It is people who work on support for boards with ACPI firmware and > containing devices that in Linux are handled by DT-centric code. Yes, it's important to remember that there's a whole world of other people using ACPI on x86 who are doing different things. I have to say I'm not sure how DT centric we really are, there's a lot of things that have been around since before DT. > Of course, the reason why that code is DT-centric is because it was > developed on systems using DT and there were no uses on ACPI-based > systems for it back then. Still, it is DT-centric as a matter of fact > and *something* has to be done in order to make it work with ACPI. Personally I don't have that big a concern around per device properties other than the need to go through yet another round of churn for them (though it is just mechanical which will make it less painful). I do worry when it goes to generic things and inter-device relationships. > And it is not an option for those boards to use DT in the firmware. There's nothing stopping these systems defining a DSD that contains a DTB which overrides some or all of the ACPI if the system supports it (or otherwise providing both system descriptions). The two can coexist happily enough as arm64 has shown and it seems like it ought to save a whole lot of work especially around the bits that need inter device links and are hence need some new ACPI bindings defining. I can see that removing ACPI entirely would present serious difficulties but it's less clear to me how much is really gained by having an embedded Linux specific ACPI variant over having some Linux specific data in ACPI that happens to be parsable as DT. The circumstances that the two platforms face appear to be very similar.
Attachment:
signature.asc
Description: PGP signature
