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]

Date:	Mon, 17 Mar 2014 16:23:34 +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 Sat, Mar 15, 2014 at 1:58 AM, Suman Anna <s-anna@...com> wrote:
> The series doesn't change the semantics of hwspinlock registration or adds a
> new OF controller registration function. Implementations would still need to
> register a controller using a base_id and number of locks. The series rather
> adds a DT-friendly function _ONLY_ for requesting a specific hwlock, and
> there are no restrictions on the args specifier being relative id numbers.
> Though this is what the simple default xlate helper does (most common
> usage), the added xlate ops and #hwlock-cells should allow individual
> implementation drivers to adjust any variations, and return a relative lock
> w.r.t its registered base_id, as this is how a lock gets registered in the
> first place.

I might be missing something, but why can't we have the
specifier+base_id be the hwlock id and then we can entirely drop most
of the core changes in this patch-set? I realize we couldn't easily
support sparse id numbers, but not sure this is relevant to
hwspinlocks? do we have a use case that couldn't be supported in this
case?

> I actually started out this series with the base_id property, and dropped it
> in v3 based on comments looking at it from the request-specific-lock
> semantics with DT. That said, the drivers still need to manage a 'base_id'
> needed for registration when they get probed for multiple controllers.
> Getting the base_id from DT _may_ be useful just for registration purposes,
> but for requesting a hwlock, a controller phandle and an implementation
> defined args-specifier should suffice IMHO.

How could drivers know what the base_id is if DT doesn't provide it?
please note that we can't depend on order of controller probing; the
hwlock id numbers cannot depend on implementation details.

> The exact notion of informing the hwspinlock core about a list of reserved
> locks is missing at the moment (even in the non-DT case). I am not sure if
> this got lost during the conversion of the registration from per lock to
> registering a bank of locks together, or if it is implied by the base_id +
> num_locks combination. The core today supports requesting only those locks
> that were actually registered, whether allocating a free one dynamically or
> giving a specific one.

Before DT came along, early board code could have reserved specific
hwspinlocks if needed. Now with DT, we should add the list of reserved
locks to the controller node, in order to prevent them from being
dynamically allocated by others.

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/