[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141003135610.GM26643@leverpostej>
Date: Fri, 3 Oct 2014 14:56:10 +0100
From: Mark Rutland <mark.rutland@....com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Mika Westerberg <mika.westerberg@...ux.intel.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linus Walleij <linus.walleij@...aro.org>,
Alexandre Courbot <gnurou@...il.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Bryan Wu <cooloney@...il.com>,
Lee Jones <lee.jones@...aro.org>,
"grant.likely@...aro.org" <grant.likely@...aro.org>,
Aaron Lu <aaron.lu@...el.com>,
Darren Hart <dvhart@...ux.intel.com>
Subject: Re: [PATCH v3 04/15] ACPI: Document ACPI device specific properties
On Thu, Oct 02, 2014 at 03:55:56PM +0100, Arnd Bergmann wrote:
> On Thursday 02 October 2014 17:38:09 Mika Westerberg wrote:
> > On Thu, Oct 02, 2014 at 04:29:03PM +0200, Arnd Bergmann wrote:
> > > Is this a limitation in the way that the AML syntax and compiler works,
> > > or is this a decision you made specifically for the _DSD syntax and that
> > > could still be changed if there is an overwhelming interest?
> >
> > It is only limitation of the _DSD device property UUID specification and
> > our implementation. It can be changed if needed.
>
> Ok, I see. I think it would be nice if this could be changed in order
> to avoid having to copy the #xxx-cells and xxx-names properties from
> DT, by providing a more natural syntax.
I'd certainly not like to see #foo-cells in _DSD given it should be
possible with a package to have a package description like the
following:
Package () {
Package () { ^ref1, data, data },
Package () { ^ref2, dta, data, data },
}
Where the #foo-cells is implicit in each instance. That makes variadic
properties possible, and makes it possible to perform validation on each
tuple even in the binary format, which we can't do with a DTB
I'm not so sure on foo-names unless we made names an explicit
requirement from the start (which I wish was the case on the DT side).
Even then we might need other parallel properties anyway (think
clock-indicies).
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists