Re: [RFC 00/15] ACPI graph support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 11, 2016 at 01:44:46AM +0200, Rafael J. Wysocki wrote:
> On Thu, Oct 6, 2016 at 11:37 PM, Mark Brown <broonie@xxxxxxxxxx> wrote:

> > 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.

My primary concern is the addition of what appear to be phandles
introduced as part of this patch set.  The previous discussion had been
that we'd enable simple DT bindings which don't need inter-device
references and that those needed more careful study.  This appears to
be changing that.

> >> 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.

People seem reasonably happy with it so far, YMMV.

> > 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.

The way ARM implements this is that you don't get the DT and ACPI
simultaneously, they're both present in the firmware and the OS picks
which one it wants to use at runtime.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux