linux-kernel - Re: [PATCH 1/2 v5] pinctrl: add a pin config 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>] [day] [month] [year] [list]

Date:	Wed, 7 Dec 2011 00:02:03 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
Cc:	linux-kernel@...r.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>,
	Barry Song <21cnbao@...il.com>,
	Haojian Zhuang <haojian.zhuang@...vell.com>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	Shawn Guo <shawn.guo@...escale.com>,
	Rajendra Nayak <rajendra.nayak@...aro.org>
Subject: Re: [PATCH 1/2 v5] pinctrl: add a pin config interface

Hm, at some point I hit the wrong reply button so the list missed mine
and Stephens replies :-/ sorry. Quoting verbose.

On Mon, Dec 5, 2011 at 6:56 PM, Stephen Warren <swarren@...dia.com> wrote:
> Linus Walleij wrote at Monday, December 05, 2011 8:43 AM:
>> On Thu, Dec 1, 2011 at 10:44 PM, Stephen Warren <swarren@...dia.com> wrote:
>> > Linus Walleij wrote at Thursday, December 01, 2011 3:55 AM:
> ...
>> >> +extern int pin_config_get(struct pinctrl_dev *pctldev, int pin,
>> >> +                       unsigned long *config);
>> >> +extern int pin_config_set(struct pinctrl_dev *pctldev, int pin,
>> >> +                       unsigned long config);
>> >
>> > Should the per-pin APIs take a pin name (char*) instead of a pin number
>> > just like the per-group APIs? That seems more consistent. Currently, only
>> > the pinctrl core -> driver API ever deals with pin numbers, and e.g. the
>> > mapping table only deals with names.
>>
>> But the group definitions deal only with numbers.
>>
>> And the name is not compulsory, and not required to be
>> unique. Which is in turn a side effect of the fact that some chip
>> engineers insist on doing crazy stuff like naming 15 different
>> pins "GND". So requireing them to all be uniquely named
>> could lead to enforcing som arbitrary naming policy which
>> cause a disalignment with terms found in the data sheet,
>> or just bring us full circle back to pin numbers by prefixing
>> or suffixing each name with a number albeit in ASCII...
>>
>> So we'd better stick with numbers ftm, as pointed out
>> we want to get rid of casual use of these functions
>> anyway.
>
> The big problem here is: How do users of these APIs know what the pin
> numbers are? With names, the datasheet presumably gives standard names
> to each pin, whereas the numbering scheme chosen by a pinctrl driver can
> be essentially arbitrary (well, perhaps not with a PLCC package, but
> with others...). I suppose the driver could expose a header with all the
> names in, but it seems like we're trying to get away from that kind of
> thing.
>
> Related, numbers in device tree suck, since there's currently no way of
> using symbolic constants. I suppose the DT parsing code would do a mapping
> from text name to pin number using the driver's exposed table of pins
> though.
>
> Re: unique names: Every pins does have a unique name. "GND" is really
> the semantics of the pin, not its name; it always has some defined ball,
> pad, or pin number which can be included in the name to make it unique.
> I'd certainly vote for making pin names mandatory and unique.

Hm, you are making a perfectly good point about cross-referencing
documentation. And matches my experience.

I certainly have to look into this.

So I need to make pin names
- compulsory
- unique
- reqrite API accessors

I think it can be done since the in-tree drivers have all unique pin
names.

I'll hack on this, it'll be a good step forward.

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/