On Thu, Oct 6, 2016 at 11:37 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > 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. When I said "DT-centric" I really meant "full of of_* calls retrieving data from a 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. Well, that was my first reaction to this series, but then I thought "Let's see what can go wrong with this specifically" and then I couldn't find anything. If you see something like that, please let me know, because I may be overlooking it, but otherwise I would prefer to focus on the technical side of things instead of wast^Hspending time on theoretical worries. >> 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 I'm not sure to what extent it has shown that and even so, it doesn't mean this is a good idea. > 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. There is at least one major problem with this approach. If the ACPI part needs to point to anything in the DTB or if the DTB part needs to point to the ACPI part outside of it, there's no clean way that could be done. I actually am not aware of any way whatever, but if there are some, I kind of don't expect them to be pretty. > 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. I'm not really sure what you mean here. _DSD properties can convey the same information as DT in the same layout. The only difference is that DT uses phandles to point to things and _DSD properties use ACPI namespace paths for this purpose. That actually is where code changes need to be made, the rest is already there. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
