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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAK=WgbZ1M0JZE2BH0ukNo33hBuffTGbd3-DD0WCiwZ-akgvQ-Q@mail.gmail.com>
Date:	Tue, 18 Mar 2014 15:35:32 +0200
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Suman Anna <s-anna@...com>
Cc:	Mark Rutland <mark.rutland@....com>,
	Tony Lindgren <tony@...mide.com>,
	Kumar Gala <galak@...eaurora.org>,
	"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

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.

Thanks,
Ohad.
--
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/