linux-kernel - Re: [PATCH V1] regulator: fixed: Support for open-drain gpio

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:	Tue, 7 Feb 2012 11:43:41 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Laxman Dewangan <ldewangan@...dia.com>, grant@...retlab.ca
Cc:	lrg@...com, linux-kernel@...r.kernel.org,
	linux-tegra@...r.kernel.org
Subject: Re: [PATCH V1] regulator: fixed: Support for open-drain gpio

On Tue, Feb 07, 2012 at 04:16:36PM +0530, Laxman Dewangan wrote:

> To make the pin to high/low for enabling/disabling the switches,
> the pins will have the pull-up connected and the high/low can be
> set using following methods:
> LOW: gpio_direction_output(gpio, 0) ... this drives the signal
> 	and overrides the pullup.
> HIGH: gpio_direction_input(gpio) ... this turns off the output,
> 	so the pullup (or some other device) controls the signal.

Thinking about this further this is potentially going to apply to any
GPIO output - perhaps we should push the implementation down into
gpiolib so we just specify a flag when requesting the GPIO and then
gpiolib does the pull low/high Z thing for us.  That would be much less
effort in individual drivers, we'd just need to be able to set the flag
and could potentially directly use any hardware open drain output
support (some GPIO controllers will do all this in hardware) if the
driver API were extended.  Grant, does that sound reasonable?

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)