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]
Date:	Wed, 28 Jan 2015 21:58:42 -0600
From:	Suman Anna <s-anna@...com>
To:	Mark Rutland <mark.rutland@....com>
CC:	Ohad Ben-Cohen <ohad@...ery.com>, Tony Lindgren <tony@...mide.com>,
	Rob Herring <robherring2@...il.com>,
	Kumar Gala <galak@...eaurora.org>,
	Bjorn Andersson <bjorn@...o.se>,
	Josh Cartwright <joshc@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock

On 01/22/2015 12:56 PM, Mark Rutland wrote:
> On Wed, Jan 21, 2015 at 05:56:37PM +0000, Suman Anna wrote:
>> On 01/21/2015 06:41 AM, Ohad Ben-Cohen wrote:
>>> On Tue, Jan 20, 2015 at 8:05 PM, Tony Lindgren <tony@...mide.com> wrote:
>>>> How about default to Linux id space and allow overriding that with
>>>> a module param option if needed?
>>>
>>> I'm not sure I'm following.
>>>
>>> If the main point of contention is the base_id field, I'm also fine
>>> with removing it entirely, as I'm not aware of any actual user for it
>>> (Suman please confirm?).
>>
>> Yeah, well the current implementations that I am aware of only have a
>> single bank, so all of them would be using a value of 0. I am yet to see
>> a platform with multiple instances where the property really makes a
>> difference. v7 has the property mandatory, so all the implementations
>> would need to define this value even if it is 0.
>>
>> regards
>> Suman
>>
>>>
>>> Mark? Rob? Will you accept Suman's patches if the base_id field is removed?
> 
> My concern is that the mapping of hwspinlock IDs doesn't seem to be
> explicit in the DT on a per-context basis, which is what I'd expect.
> 
> e.g.
> 
> lck: hwspinlock-device@f00 {
> 	...
> 	#hwlock-cells = <1>;
> };
> 
> some-other-os-interface {
> 	...
> 	hwlocks = <&lck 0>, <&lck 1>, <&lck 2>, <&lck 3>;
> 	hwlock-names = "glbl", "pool0", "pool1", "pool2";
> };
> 
> a-different-os-interface {
> 	...
> 	hwlocks = <&lck 18>, <&lck 21>, <&lck 4>, <&lck 5>;
> 	hwlock-names = "init", "teardown", "pool0", "pool1";
> };
> 
> That's the only way I would expect this to possibly remain a stable
> over time, and it's the entire reason for #hwlock-cells, no?
> 
> How do you expect the other components sharing the hwspinlocks to be
> described?

Yes indeed, this is what any of the clients will use on Linux. But this is not necessarily the semantics for exchanging hwlocks with the other processor(s) which is where the global id space comes into picture.

regards
Suman

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ