linux-kernel - Re: [PATCHv4 0/7] omap hwspinlock dt support

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: <5339EFFB.30304@ti.com>
Date:	Mon, 31 Mar 2014 17:45:15 -0500
From:	Suman Anna <s-anna@...com>
To:	Ohad Ben-Cohen <ohad@...ery.com>,
	Mark Rutland <mark.rutland@....com>,
	Kumar Gala <galak@...eaurora.org>
CC:	Tony Lindgren <tony@...mide.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCHv4 0/7] omap hwspinlock dt support

On 03/18/2014 08:35 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Tue, Mar 18, 2014 at 1:46 AM, Suman Anna <s-anna@...com> wrote:
>> So far, we have not come across multiple controllers. I see your point,
>> and I think this also depends on the semantics of how you exchange the
>> lock id number. The agreement at the moment is on base_ids across
>> multiple SoC components. If the semantics involve exchanging the
>> controller instance, for example, then we might get away with it. But
>> that probably involves adding additional helpers to retrieve controller
>> instance in addition to lock number, or some other similar functions.
> 
> Yes, this could be done too, but I agree it is less simple with no real win.
> 
>> Sorry, I should have rephrased it better - by order, I meant the
>> inherent order between board early code and other drivers. With DT, we
>> cannot guarantee that right, as specific locks are requested from drivers.
> 
> Yeah.
> 
>> Understood. And we may have to assign the client association with a lock
>> as well. These are core changes that were actually not needed in the
>> non-DT case due to the inherent order as stated above. So, are you
>> suggesting that we add one more property to the controller node to mark
>> which are reserved, or rely on constructing this through DT tree parsing?
> 
> I guess this is a question to the DT folks; both approaches work from
> hwspinlock perspective.
> 
> In the past Arnd Benoit and myself were happy with adding one more
> property to the controller node, but this might be somewhat error
> prone as it leaves room for mistakes - developers can add hwlock
> phandles and forget to update the reserved property in the controller
> node.

Ohad,
I agree that this is the most simplest form (either a reserved number
starting from base, or a reserved range - I prefer the first). The
developer errors can be restricted by having the
of_hwspin_lock_request_specific() return an error if anything outside
this reserved range is requested.

Mark, Kumar,
Any recommendations/objections on this problem/approach?

I also have to bring back the hwlock-base-id property (dropped in v3)
for registration purposes, so that the registration does not change
based on the probe order of the multiple controller nodes.

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/