linux-kernel - Re: [PATCH] pinctrl: document the "GPIO mode" pitfall

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: <CACRpkdaMdU4DHWULnSB_dvGk8pTRbirL1HVTGqJ2rwqXR798uQ@mail.gmail.com>
Date:	Fri, 26 Apr 2013 10:49:12 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Stephen Warren <swarren@...dia.com>,
	Anmar Oueja <anmar.oueja@...aro.org>,
	Pankaj Dev <pankaj.dev@...com>
Subject: Re: [PATCH] pinctrl: document the "GPIO mode" pitfall

On Fri, Apr 26, 2013 at 1:15 AM, Laurent Pinchart
<laurent.pinchart@...asonboard.com> wrote:
> On Thursday 25 April 2013 23:39:18 Linus Walleij wrote:
>> On Tue, Apr 23, 2013 at 3:33 PM, Laurent Pinchart wrote:

>> > Could you clarify the exact scope of the two configuration parameters ?
>>
>> PIN_CONFIG_OUTPUT is left a bit unspecified, but here the idea was a passive
>> drive, like just connecting the pin to VDD or GND without any driver stage
>> at all.
>
> Isn't that a driver stage ? :-)

OK something that is not a totempole type drive ...
push/pull surely implies a totempole type design.

> What is unclear to me is the interaction between OUTPUT and DRIVE_*.
> That's the part I would like to see clarified.

I sent some patch now, check it ... hm reported-by still doesn't add
you to CC :-/ better patch git-send-email...

> Does DRIVE_* imply that the pin
> is driven by the selected function, and OUTPUT imply that the pin is driven to
> a fixed level ?

That is unclear, but I suggest DRIVE* implies that everything on the pin
is driven according to that configuration. (Else it is getting ignored...)

OUTPUT would be used when you don't know the particulars or when
the driving cannot be controlled in a fine-grained manner like with the
DRIVE* configs.

Does this make sense?

> If so, how do you configure the drive type of a pin that will
> be used through the GPIO API ?

It is possible to use the pinctrl and GPIO APIs orthogonally.

For example the pinctrl can use hogs to reconfigure the pins
during sleep without intervention from the GPIO API.

So they will be fingering on the same pins registers.
Maybe even the same register (if access can be protected
properly) from different APIs.

> What about cases where I want to drive the pin
> to a fixed level in a non low-power output mode (for instance because I need
> more current that what the low-power output mode provides) ?

Just use pinconfig for that?

Is the usecase something like a power-supplying GPIO pin
and then sometimes you want to provide more power from it?

Then use pinconfig to shunt in the driver stages, and GPIO API
to enable/disable it.

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/