linux-kernel - RE: [PATCH] pinctrl: make the pinmux-pins more helpful

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Feb 2012 09:27:22 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	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>,
	Shawn Guo <shawn.guo@...escale.com>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	Dong Aisheng <dong.aisheng@...aro.org>,
	Rajendra Nayak <rajendra.nayak@...aro.org>,
	Haojian Zhuang <haojian.zhuang@...vell.com>
Subject: RE: [PATCH] pinctrl: make the pinmux-pins more helpful

Linus Walleij wrote at Wednesday, February 29, 2012 2:39 AM:
> On Fri, Feb 24, 2012 at 5:44 PM, Stephen Warren <swarren@...dia.com> wrote:
> 
> > If we do make a change like this, I'd prefer the format to be:
> >
> > UNCLAIMED
> > "%s (HOG)", desc->owner
> > desc->owner
> 
> I don't see the point, the debugfs files are supposed to be
> human-readable, a human is not interested in the fact that
> the pinctrl device itself is owning the pin, what is interesting is
> that it is hogged.

Well, I'm a human and I care far more that the pin controller device is
what owns the configuration rather than some artificial "hog" concept
is present...

> >> I somewhat mourn the loss of being able to tell from the debugfs
> >> which function is using a certain pin, does anyone have ideas on
> >> how to go about fixing this properly? The root file
> >> pinctrl-handles does tell it, but requires cross-referencing
> >> which isn't helpful.
> >
> > This doesn't seem like a big deal to me; it's very easy to cross-
> > reference.
> 
> Not to me it isn't, looks like I would have to create scripts to
> do that for a large pin controller and that's less helpful than
> just having the information there.
> 
> > That said, we could either:
> >
> > a) Add a field to pin_desc which indicates current usage. This would be
> > set whenever the pin's mux function was set, i.e. in pinctrl_select_state()
> > or pinctrl_request_gpio().
> 
> That's like re-introducing the former "function" field I guess.
> 
> Simple if I just also #ifdef CONFIG_DEBUGFS... so I'd go
> for this.
> 
> > b) Add a pinctrl driver ops function which reads and prints the current
> > state from HW.
> >
> > (and note the fact that having the debug file list the current mux
> > function per pin doesn't really make sense on HW where the muxing is
> > per group...)
> 
> On U300 it makes a lot of sense even thogh it is essentially
> group based. When sitting with the datasheet with the pin names
> and use groups it's simple to see exactly how any one pin is muxed
> for the moment and troubleshoot from there.

If the HW muxes per group, then there's no concept of "which function is
selected for a pin", since functions are selected for a group not for a
pin.

So, the datasheet will be written in terms of "group X supports functions
A, B, C, D", not pins P, Q, R support functions "A, B, C, D". So,
representing mux function in debugfs at the group level would make a lot
more sense given that HW design.

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