Thread (130 messages) 130 messages, 14 authors, 2014-10-07

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

From: Rafael J. Wysocki <hidden>
Date: 2014-10-05 21:20:45
Also in: linux-acpi, lkml

On Saturday, October 04, 2014 12:56:21 PM Arnd Bergmann wrote:
On Saturday 04 October 2014 01:58:30 Rafael J. Wysocki wrote:
quoted
On Friday, October 03, 2014 05:02:13 PM Arnd Bergmann wrote:
quoted
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:
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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help