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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1817639.W8PYrU1iOP@vostro.rjw.lan>
Date:	Sat, 04 Oct 2014 01:58:30 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Mark Rutland <mark.rutland@....com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Bryan Wu <cooloney@...il.com>,
	Lee Jones <lee.jones@...aro.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Aaron Lu <aaron.lu@...el.com>,
	Darren Hart <dvhart@...ux.intel.com>
Subject: Re: [PATCH v3 04/15] ACPI: Document ACPI device specific properties

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/