On Friday, October 03, 2014 05:02:13 PM Arnd Bergmann wrote:

On Friday 03 October 2014 14:56:10 Mark Rutland wrote:

quoted

On Thu, Oct 02, 2014 at 03:55:56PM +0100, Arnd Bergmann wrote:

quoted

On Thursday 02 October 2014 17:38:09 Mika Westerberg wrote:

quoted

On Thu, Oct 02, 2014 at 04:29:03PM +0200, Arnd Bergmann wrote:

quoted

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.

Yes, that only is a matter of implementing the parser.

For now, it simply is easier for us to parse the

	Package () { ^ref1, data, data }

format only, because we have functions for parsing lists of strings,
lists of numbers etc. for other purposes anyway and we can re-use them
for the names etc.  I don't see a reason why the parser cannot be extended in
the future to handle "all in one" packages, but not necessarily at the moment.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.