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:	Fri, 3 May 2013 16:06:10 +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 03/05/13 14:03, Linus Walleij wrote:
> On Fri, May 3, 2013 at 2:23 PM, James Hogan <james.hogan@...tec.com> wrote:
>> [Me]
>>> If what you need is to set the pin into "GPIO mode" to drive it
>>> to some default state then from pinconf-generic.h you should use
>>> one of the existing defines like PIN_CONFIG_OUTPUT
>>> to actively drive it to high or low as default, or
>>> PIN_CONFIG_BIAS_HIGH_IMPEDANCE for some default
>>> GPIO input mode.
>>>
>>> Read the new section named "GPIO mode pitfalls" in
>>> Documentation/pinctrl.txt
>>
>> Thanks, that was interesting. I've had a think about this (and done some
>> experiments with a multimeter), and the problem is these generic
>> pinconfs already have meanings which don't match what the SELECT
>> register does. For example, having a pin be tristate and not controlled
>> by the peripheral, and having it tristate as far as the gpio hardware is
>> concerned (e.g. no pull-up) but still controlled by the peripheral, are
>> two very different things that need disambiguation.
> 
> I don't know if that is necessary.
> 
> While I do recognize that it is possible that we need to put
> pins into "GPIO mode", i.e. drive them actively low or high,
> as PIN_CONFIG_OUTPUT does, I'm not convinced that
> pin config should handle the case where a signal is passed
> through from a peripheral.
> 
> I think that for every pin that is put to use for a peripheral
> you must anyway at some point call .enable() on the
> struct pinmux_ops of the pin controller.
> 
> Thus this part of the problem (poking that "select" bit)
> should be handled by the pinmux part of the driver.
> 
> The pinconf part does not need to know about it.

Okay, so how would you recommend handling the case of a pin in a muxing
pingroup that shouldn't be put into peripheral mode?

E.g. imagine an 18bit display is wired to the (24bit) tft pins (which
are muxed as a group to "tft" function), and the least significant tft
pins are used as GPIOs to control something like board power supplies.

Without using pinconf I think the muxing pingroups would have to overlap
like below (is that acceptable?):

pingroup "tft_pins"
	pins:      "red0"..."red7"
	functions: "tft", "lcd"

pingroup "red0"
	pins:      "red0"
	functions: "peripheral" (OR "none")
...
pingroup "red7"
	pins:      "red7"
	functions: "peripheral" (OR "none")

and then do something like this?

map {
	tft_mux {
		pins = "tft_pins";
		function = "tft";
		/* mux tft pins to tft panel interface */
	};
	tft_pins {
		pins = "red7", "red6", "red5", "red4", "red2";
		function = "peripheral";
		/* mux pins to peripherals */
	};
};

or maybe this:

map {
	tft_mux {
		pins = "tft_pins";
		function = "tft";
		/* auto sets individual pins to peripheral */
	};
	tft_pins {
		pins = "red1", "red0";
		function = "none";
		/* set individual pins to !peripheral */
	};
};

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/