linux-kernel - Re: [PATCH 5/8] pinctrl-tz1090: add TZ1090 pinctrl driver

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: <CACRpkdZ5KW0qUF7vG1ZTmc0gez2T+e4KBugUGMpkXnXNmEMdEw@mail.gmail.com>
Date:	Wed, 15 May 2013 21:07:46 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	James Hogan <james.hogan@...tec.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	Rob Landley <rob@...dley.net>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH 5/8] pinctrl-tz1090: add TZ1090 pinctrl driver

On Tue, May 14, 2013 at 2:22 PM, James Hogan <james.hogan@...tec.com> wrote:

> I think that's the other way around, i.e. that's talking about mapping
> several pingroups to the same function. The next paragraph is closer to
> the problem:
>
> Documentation/pinctrl.txt
>> - PINS for a certain FUNCTION using a certain PIN GROUP on a certain
>>   PIN CONTROLLER are provided on a first-come first-serve basis, so if some
>>   other device mux setting or GPIO pin request has already taken your physical
>>   pin, you will be denied the use of it. To get (activate) a new setting, the
>>   old one has to be put (deactivated) first.
>
> In my example the tft pingroup contains all the tft pins, but I might
> want a particular pin inside that pingroup to never be controlled by the
> mux (using the per-pin mux disable (SELECT) bits).
>
> So if I use pinmux I'd have something like:
> * "tft" pingroup maps to "tft" function
> * "tft_green0" pingroup (containing individual pin inside "tft"
> pingroup) maps to "none" function to disable muxing (or the inverse,
> with each pin in use mapping to "periph" to enable muxing).
> in which case the pin has multiple muxes "controlling" it (even though
> they're sort of nested). The above paragraph seems to condemn this
> arrangement.

So if this usecase is what you want to support, why don't you just
exclude that one pin from the "tft" group and put it into another
group?

If you want it activated anyway as part of some state e.g.
"default", you can just specify multiple groups for that state.

> Or using pinconf I'd have something like:
> * "tft" pingroup maps to "tft" function
> * "tft_green0" pin (in "tft" pingroup) has pinconf "no-periph" (or the
> inverse, with each one in use having pinconf "periph")

If you want some pinconf set up for this one pin as part
of a configured state that's OK even if the pin isn't muxed
in as part of this state. muxing and config are orthogonal.

> Or modifying the pinctrl subsystem maybe something like:
> * [optional: particular named pins in] "tft" pingroup map to "tft" function
> that way enabling a mux doesn't necessarily apply to all pins in the
> group, and drivers for hardware that doesn't support partial enabling of
> the mux can reject it (I might experiment with this if I get the time).

No thanks, this will be hopeless to understand, the pinctrl
subsystem is already really hard for outsiders to understand,
let us not raise the bar even more...

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/