linux-kernel - Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock

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: <CAK=WgbaHEbqVVBAUL1aaO3i+pPbTZM2DRB=1kSE6A6+pPmS4yQ@mail.gmail.com>
Date:	Wed, 11 Feb 2015 12:29:37 +0200
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Bjorn Andersson <bjorn@...o.se>
Cc:	Suman Anna <s-anna@...com>, Mark Rutland <mark.rutland@....com>,
	Rob Herring <robherring2@...il.com>,
	Kumar Gala <galak@...eaurora.org>,
	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 Fri, Feb 6, 2015 at 2:34 AM, Bjorn Andersson <bjorn@...o.se> wrote:
>> Yep, will do as soon as I hear from Ohad on what to do with the patch
>> "hwspinlock/core: maintain a list of registered hwspinlock banks" that I
>> dropped from v7. Without that and dropping hwlock-base-id, I can't get
>> the translations done.
>>
>
> My suggestion is to replace the global id-tree with a list of hwlocks
> and iterate over these if we ever get more than one driver registered.
> As long as #hwlock-drivers < log(#total-hwlocks) this should be
> faster.
>
> I would however argue that clients that would notice any kind of
> difference are using the API incorrectly.
>
> Unfortunately this is a somewhat larger change than just slapping DT
> support on the framework :/

I suspect we want to wait with framework changes until there's a real
hardware use case justifying them.

With regard to DT, however, we obviously do want to be prepared for
multiple hwlock blocks even if they do not exist today.

So how about adopting an approach where:
- DT fully supports multi hwlock blocks (i.e. no global id field)
- Framework left mostly unchanged at the moment. This means issuing an
explicit error in case a secondary hwlock block shows up, and then
hwlock id could trivially be the lock index.

If multi hwlock hardware use case, or some new hwlock id translation
requirements, do show up in the future, it's always easy to add
framework support for it. At that point we'll know better what the
requirements are, and framework changes would be justifiable.

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/