linux-kernel - RE: [PATCH 2/2] pinctrl: add a generic control interface

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] [day] [month] [year] [list]

Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF173E1B4180@HQMAIL01.nvidia.com>
Date:	Mon, 24 Oct 2011 21:49:55 -0700
From:	Stephen Warren <swarren@...dia.com>
To:	Shawn Guo <shawn.guo@...escale.com>,
	Linus Walleij <linus.walleij@...aro.org>
CC:	Barry Song <21cnbao@...il.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linaro Dev <linaro-dev@...ts.linaro.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	David Brown <davidb@...eaurora.org>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: RE: [PATCH 2/2] pinctrl: add a generic control interface

Shawn Guo wrote at Sunday, October 23, 2011 2:51 AM:
...
> To me, pin_config() and its parameters should be invisible to client
> drivers.  For amba-pl011 example, do you think any of those SoCs will
> need multiple sets of uart pin configurations to switch for different
> working modes?  If that's case, the individual SoC pinctrl driver
> should be responsible for mapping particular pin configuration to
> specific pl011 working mode.  Otherwise, the amba-pl011 can simply
> call pinmux_enable(...) to have both mux and cfg set up.

I agree.

Somebody at the ARM workshop yesterday (and I'm sorry, I forget who; I'm
missing too much sleep) pointed out another very good reason:

If there's some IP block that's used in a bunch of SoCs, and each SoC has
different sets of params (or values) that can be set, the IP block driver
shouldn't know about each SoC, and set those values; instead, the board
should be telling the pinmux system exactly what parameters to set, and
the IP block driver should simply be telling pinmux "set up the pins".

Now, I suppose that this could also be done by providing all the params
and values to the driver through platform data, however:

a) The driver is already calling pinctrl to set up the muxing in an
abstract way (mapping table hides the details); I'd like to see pin
config work in the same way.

b) If this were implemented through platform data in each driver, then
every driver's DT binding and probe code will need to define the format
of this data and parse it at probe time. Instead, if this is all in some
table handled by the pinctrl system, it's defined once, and parse once,
which seems a lot simpler.

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