On Tue, Oct 11, 2016 at 02:11:06PM +0200, Rafael J. Wysocki wrote: > On Tue, Oct 11, 2016 at 1:44 AM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > On Thu, Oct 6, 2016 at 11:37 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> 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. ACPI *can* be used in this way but it's not clear that this is a mainstream usage of ACPI. > In fact, from the utility perspective, _DSD properties are just like > an "embedded DTB" you talked about, except that they are represented > in ASL (which makes them easier to handle in a couple of ways) and use > namespace paths instead of phandles to point to things. It does require an awful lot of code churn to implement and it does seem like it's going to be ending up with a lot of non-standard ACPI bindings available to system integrators targeting Linux that perhaps lack broad buy in. This would be a bit annoying if we end up with bad bindings that way but it'd also be sad if we were getting good bindings that weren't getting broad adoption for whatever reason.
Attachment:
signature.asc
Description: PGP signature
