linux-kernel - RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings

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: <74CDBE0F657A3D45AFBB94109FB122FF17801D230A@HQMAIL01.nvidia.com>
Date:	Tue, 17 Jan 2012 11:50:33 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...aro.org>,
	Shawn Guo <shawn.guo@...aro.org>
CC:	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Richard Zhao <richard.zhao@...aro.org>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"cjb@...top.org" <cjb@...top.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Dong Aisheng <dongas86@...il.com>
Subject: RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux
 mappings

Linus Walleij wrote at Monday, January 16, 2012 9:09 AM:
> On Sat, Jan 14, 2012 at 2:22 AM, Shawn Guo <shawn.guo@...aro.org> wrote:
> > On Fri, Jan 13, 2012 at 10:16:36AM -0800, Stephen Warren wrote:
> >> Admittedly, the wording of Linusw's actually seems to agree more with how
> >> you're interpreting what Dong said, but in that case, I don't think his
> >> reply makes sense - the whole purpose of the mux mapping table is to
> >> represent the board-specific configuration. If we're going to circumvent
> >> it, we should completely remove it from the pinctrl subsystem, rather than
> >> having some boards avoid using it by creating virtual pin groups instead.
> >>
> > IMO, it's a compromise.  It still makes sense to have concept of
> > pingroup in pinctrl subsystem, because platforms like Tegra have
> > the HW pingroup.
> 
> I'm not able to follow this discussion, it's too much stuff here that I don't
> quite grasp :-(
> 
> The pinctrl idea of a group is defined in Documentation/pinctrl.txt:
> 
> ---------------------8<---------------------------8<-----------------------------
> 
> Pin groups
> ==========
> 
> Many controllers need to deal with groups of pins, so the pin controller
> subsystem has a mechanism for enumerating groups of pins and retrieving the
> actual enumerated pins that are part of a certain group.
> 
> For example, say that we have a group of pins dealing with an SPI interface
> on { 0, 8, 16, 24 }, and a group of pins dealing with an I2C interface on pins
> on { 24, 25 }.
...
> ---------------------8<---------------------------8<-----------------------------
> 
> 
> As you can see none of the text above claims that the group is
> about hardware-defined groups or anything like that.

Well, I guess that's true, but didn't we only add the concept of groups
to the pinctrl subsystem in order to support Tegra's HW-group-based
muxing? And irrespective of that, why would you want to define "virtual"
groups in the pinctrl driver when the whole point of the pin mux mapping
table allowing multiple entries for a device was to handle the mux-by-
pin case?

> The groups
> are just that - a group of pins, an abstract concept of a group.
> It could be drawn i UML even... maybe I'll do that for my
> ELC presentation :-)

I should ask: Who here is coming to Linaro Connect and/or ELC? I'm
Currently signed up for Linaro Connect, but not ELC. I could probably
add ELC if there was good reason.

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