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: <CACRpkdYYhsY-2vQnxpM-rB9_6yXiY4XBNhb4eyNvK=eD=dxK5w@mail.gmail.com>
Date:	Fri, 3 May 2013 15:03:13 +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 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.

The idea is definately not for the pin config to act
as a "backend" for pin muxing, rather to partition
the problem into two independent parts.

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/