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

[Rafael J. Wysocki]

On Saturday, October 04, 2014 12:56:21 PM Arnd Bergmann wrote:
> On Saturday 04 October 2014 01:58:30 Rafael J. Wysocki wrote:
> > 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:
> > > > 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.
> 
> It only really makes sense to do it that way though if it's used
> consistently, and all references do naming like this rather than
> the foo-names method.

This almost sounds like "this will only makes sense if it's beautiful"
which I'm not sure I agree with. :-)

As long as it is clear what information is represented, I have no problems
with having multiple ways of expressing it and using them however people
like.  In fact, we don't even really know at this point which way will turn
out to be most convenient eventually.

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