Re: [RFC 00/15] ACPI graph support

From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Mark Brown <broonie@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh@kernel.org>, Al Stone <ahs3@redhat.com>
Subject: Re: [RFC 00/15] ACPI graph support
Date: Wed, 12 Oct 2016 02:32:04 +0200	[thread overview]
Message-ID: <2933991.PYcZctIsx9@vostro.rjw.lan> (raw)
In-Reply-To: <20161011124429.ptizsviqiwzbmbxc@sirena.org.uk>

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

On Tuesday, October 11, 2016 02:44:29 PM Mark Brown wrote:
> 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@kernel.org> 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.

Yes, it does, but why exactly do you think this is wrong?

Is there any specific problem it creates that you can point to?

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

So for the boards I'm talking about ACPI is the only realistic choice.

Thanks,
Rafael

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]