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

Date:	Thu, 20 Oct 2011 11:41:29 -0700
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...aro.org>,
	Shawn Guo <shawn.guo@...escale.com>
CC:	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Barry Song <21cnbao@...il.com>,
	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

Linus Walleij wrote at Thursday, October 20, 2011 7:44 AM:
> On Thu, Oct 20, 2011 at 4:45 AM, Shawn Guo <shawn.guo@...escale.com> wrote:
> 
> > We should not require device driver to call these APIs directly.  There
> > are so many pinctrl subsystem internal details left to its users.
> 
> As explained I already have drivers that need to do this. OK they
> are out-of-tree, but they do exist.
> 
> For U5500 we have a SIM card driver which sets pull down resistance
> and load capacitance in response to information retrieved from the
> card at runtime. This is not static or internal to pinctrl at all. How should
> I solve this if pin configuration is not exposed?

I think drivers should operate at a higher level than "set pin X's param
Y to value Z".

I imagine the set of states that the SIM card driver needs to set up are
defined by the SIM protocol.

So, the driver communicates with the SIM card, find out that it supports
Certain clock frequencies or capabilities etc., and then needs to program
the SIM card and associated SoC-side HW to operate in the selected mode.

The set of legal modes for the SIM card protocol is presumably pretty
small, so the SIM driver might want to request "basic" or "fast" operation
(note: I have zero knowledge of SIM cars, so those mode names are bogus).

Similarly, SD/MMC drivers might know about a mode name for each clock
frequency (or range) that an SD card is allowed to support by spec.

However, I still think it's a good idea for pinctrl drivers to expose
each of their available configuration options with as little veneer or
abstraction as possible.

To bridge these two levels of abstraction, I think the pinctrl core
needs to be provided with information or an API to map between them.

I imagine this could be implemented as a table rather similar to the
existing mux table, or even part of that mux table.

The table would be at least partially board-specific (since a given SD
instance might be mux'd onto a different set of pins between two boards,
and the values for each param might be determined during board
characterization), but for a given HW module (SIM, SD), at least some
of the data might be the same across any board that use that function,
irrespective of which set of pins is in use or independent of board
characterization. So, we might have to think about how the board and
SoC code (and/or DT board/SoC bindings) could interact to reduce
duplication of common settings, but we should probably defer that
discussion.

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