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

[Rafael J. Wysocki]

On Friday, October 03, 2014 05:02:13 PM Arnd Bergmann wrote:
> 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.

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/