linux-kernel - Re: [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding for ARM SPE

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: <20170117103100.55e98029aac55ef7770350f3@arm.com>
Date:   Tue, 17 Jan 2017 10:31:00 -0600
From:   Kim Phillips <kim.phillips@....com>
To:     Will Deacon <will.deacon@....com>
Cc:     Mark Rutland <mark.rutland@....com>,
        <linux-arm-kernel@...ts.infradead.org>, <marc.zyngier@....com>,
        <alex.bennee@...aro.org>, <christoffer.dall@...aro.org>,
        <tglx@...utronix.de>, <peterz@...radead.org>,
        <alexander.shishkin@...ux.intel.com>, <robh@...nel.org>,
        <suzuki.poulose@....com>, <pawel.moll@....com>,
        <mathieu.poirier@...aro.org>, <mingo@...hat.com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding
 for ARM SPE

On Mon, 16 Jan 2017 10:59:04 +0000
Will Deacon <will.deacon@....com> wrote:

> On Fri, Jan 13, 2017 at 06:43:52PM +0000, Mark Rutland wrote:
> > On Fri, Jan 13, 2017 at 04:03:49PM +0000, Will Deacon wrote:
> > > +- compatible : should be one of:
> > > +	       "arm,arm-spe-pmu-v1"
> > 
> > The second "arm" here doesn't seem to add much. Should that be "armv8.2"
> > instead?
> 
> I don't think armv8.2 is particularly helpful, because that effectively ties
> together the SPE version and the architecture version, which I don't think
> is strictly required. The reason I added it was so that you could describe
> a partner implementation as something like:
> 
>   acme,arm-spe-pmu-v1
> 
> and know that it was acme's implementation of an ARM architectural feature.

Wouldn't such an implementation be compatible with an
"arm,arm-spe-pmu-v1" (or one with less "arm"s)?

> If I drop the second "arm", I was worried that it might conflict with other
> namespaces (e.g. acme's signal-processing-element's power-management-unit).

I'd personally let them worry about that, esp. because this problem
would come up first and hopefully be fixed in the marketing domain
before it reaches its device tree specification stage.

Kim