Re: [PATCH v3 04/15] ACPI: Document ACPI device specific properties

[Arnd Bergmann <arnd@arndb.de>]

On Friday 03 October 2014 14:56:10 Mark Rutland wrote:
> 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).

I suppose it might even be possible to define the ACPI references to
have an optional string, so you can do

         Package () {
                 Package () { ^ref1, data, data }, 
                 Package () { "foo", ^ref2, data, data, data },
         }

The parser should be able to interpret both anonymous and named
references just by looking at the type of the first member.
You might not want to allow mixing them in a single property, but
that is more a style question than a technical requirement.

	Arnd