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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CACRpkdZ-a+kyknb-q+_=TLGcNshwkLAY4918bwD7e6LzL3sWbg@mail.gmail.com>
Date:	Wed, 29 Feb 2012 10:38:46 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
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

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.

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

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