lkml.org 
[lkml]   [2014]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v3 04/15] ACPI: Document ACPI device specific properties
    Date
    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.


    \
     
     \ /
      Last update: 2014-10-04 02:21    [W:4.743 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site