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

Message-ID: <CACRpkdZX+=9m-b+y9+tk0GQ+0TKmKasez+c=yY89ofkompf=bA@mail.gmail.com>
Date:	Wed, 29 Feb 2012 18:47:42 +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 Wed, Feb 29, 2012 at 6:27 PM, Stephen Warren <swarren@...dia.com> wrote:
> 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...

Yeah OK I'll try to add both then to please both instances of
human...

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

I think we're talking past each other, it's that old thing with group
concepts again. I'd just say that for debugging
and understanding the muxing on U300 style hardware this
is very useful. It may be pointless in Tegra style HW.

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