linux-kernel - Re: [PATCH V1 2/3] Documentation: gpio: Add details of open-drain configuration

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: <20120213220656.GA11931@opensource.wolfsonmicro.com>
Date:	Mon, 13 Feb 2012 14:06:57 -0800
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Laxman Dewangan <ldewangan@...dia.com>,
	linus.walleij@...ricsson.com, dunlap@...otime.net, lrg@...com,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-tegra@...r.kernel.org
Subject: Re: [PATCH V1 2/3] Documentation: gpio: Add details of open-drain
 configuration

On Mon, Feb 13, 2012 at 02:18:09PM -0700, Grant Likely wrote:
> On Mon, Feb 13, 2012 at 11:59:47AM +0530, Laxman Dewangan wrote:
> > Adding details of open drain configuration of the gpio so that
> > client can set the pin as open drain at the time of gpio request.

> Implicitly, the gpio api already supports open-drain and several drivers
> make use of it.  Instead of being a separate flag; users who need open
> drain will set the pin to input.  For example, see the i2c-gpio driver.

> I'm not convinced this is needed; but my opinion could be swayed.

The actual idea is to provide support for doing the switch to input to
drivers that just want to set a logic level and don't (at their level)
care one way or another if it's a CMOS or open drain output but instead
leaves it up to board configuration which mode is used.  Laxman posted a
patch for doing this to a regulator driver but looking at it the code
for emulating open drain while also maintaining support for regular CMOS
is fiddly enough that it seemed like it should be factored out of the
individual drivers.

> Also, you should include a patch to make i2c-gpio.c use this new
> functionality as a proof-of-concept.  You may not be able to test it,
> but it will make it a lot easier to justify merging by showing how it
> cleans up a gpio user.

The regulator patch is one example - I think things that could be CMOS
are probably more interesting here than drivers that always want open
drain as they have more of a complexity hit from needing to decide if
they'll use the emulation or not.

We could also at some later point add support for hardware which can
implement open drain mode itself though I'm not sure if there's enough
problem with emulating to make it worth the effort.

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