linux-kernel - RE: [PATCH 0/2] pin controller subsystem v7

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:	Tue, 20 Sep 2011 13:10:55 -0700
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Barry Song <21cnbao@...il.com>
CC:	Lee Jones <lee.jones@...aro.org>, Joe Perches <joe@...ches.com>,
	Russell King <linux@....linux.org.uk>,
	Linaro Dev <linaro-dev@...ts.linaro.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	David Brown <davidb@...eaurora.org>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: RE: [PATCH 0/2] pin controller subsystem v7

Linus Walleij wrote at Friday, September 16, 2011 6:13 AM:
> From: Linus Walleij <linus.walleij@...aro.org>
> 
> This is the sixth iteration of the controller subsystem...

Overall, the changelog sounds like a great move in the right direction.
There's just one small thing I'd comment on here:

> ChangeLog v6->v7:
> 
> - Make it possible to have several map entries matching the
>   same device, pin controller and function, but using
>   a different group, and alter the semantics so that
>   pinmux_get() will pick all matching map entries, and
>   store the associated groups in a list. The list will
>   then be iterated over at pinmux_enable()/pinmux_disable()
>   and corresponding driver functions called for each
>   defined group. Notice that you're only allowed to map
>   multiple *groups* to the same
>   { device, pin controller, function } triplet, attempts
>   to map the same device to multiple pin controllers will
>   for example fail. This is hopefully the crucial feature
>   requested by Stephen Warren.

I've been viewing the map table as:

input: (device, device's function) 
output: list of (controller, controller's group, controller's function)

... hence I was surprised to see that you explicitly note that mapping a
single device to multiple controllers was disallowed.

That said, I suppose this restriction won't cause any issues for any
use-case I'm aware of; the only possibilities might be:

a) Multiple pinmux controllers within the SoC, but perhaps the driver
should just aggregate multiple HW modules into a single Linux device
anyway?

b) Where the pinmux map wants to affect the pinmux on both ends of some
bus, where the two ends are different chips each having obviously separate
pinmux controllers.

Then again, if this need ever does arise, we should be able to just relax
this restriction without causing any backwards-compatibility issues, so
I don't see a specific need to change this now; I just thought I'd mention
it so you're aware of what I'm thinking.

I'll go review the code now.

-- 
nvpublic

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