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]

Date:	Thu, 16 May 2013 10:12:44 +0100
From:	James Hogan <james.hogan@...tec.com>
To:	Linus Walleij <linus.walleij@...aro.org>
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

Hi Linus,

On 15/05/13 20:07, Linus Walleij wrote:
> 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?

It's a very board specific thing (that was just one example). To
generalise your suggestion would make all muxing pingroups contain no
pins (which is perhaps accurate since the thing that's muxed by the
group is a set of internal signals that may be muxed out to pins via the
SELECT bits).

Cheers
James

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