linux-kernel - Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API

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: <200703102031.34186.david-b@pacbell.net>
Date:	Sat, 10 Mar 2007 20:31:32 -0800
From:	David Brownell <david-b@...bell.net>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Bryan Wu <bryan.wu@...log.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Deepak Saxena <dsaxena@...xity.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Bitbanging i2c bus driver using the GPIO API

On Saturday 10 March 2007 12:15 pm, Jean Delvare wrote:
> Hi Haavard,
> 
> On Sat, 10 Mar 2007 14:13:28 +0100, Haavard Skinnemoen wrote:
> > This is a very simple bitbanging i2c bus driver utilizing the new
> > arch-neutral GPIO API. Useful for chips that don't have a built-in
> > i2c controller, additional i2c busses, or testing purposes.

This updated version looks a lot better.  However it doesn't address
the API change -- gpio_direction_output(gpio, initial_value) -- which
is understandable since that patch hasn't yet merged.

> I like the idea very much. Would this let us get rid of i2c-ixp2000?
> i2c-ixp4xx? scx200_i2c? Other drivers?

There's CONFIG_GENERIC_GPIO support for ixp4xx (nyet upstream, ISTR it's
waiting on the gpio_direction_output update), so that one should be
particularly easy to replace.  Presumably some other bitbang drivers
could vanish before long too.

> What value will you get if the SDA pin is open-drain and currently in
> output mode?

For output GPIOs, gpio_get_value() is specified to either return the
actual value at the pin ... or zero, if the hardware can't do that.
Most GPIO pins *can* do that.  (Specifically, that's how AT91 GPIOs
work, open drain or otherwise.)

(However, there can be various latencies involved.  On one chip
when I wrote the output value, then immediately read it back, I
got the old value.  Reason:  the GPIO controller clock needed
to tick first in order to latch the new input value!  It was only
about 30 MHz, so the back-to-back instructions were too fast.  You
can also sometimes notice capacitance causing similar delays.
Of course those latencies apply regardless of pin direction.)

I think Haavard is assuming the GPIO actually returns that value,
since otherwise there'd be no point in trying to use the open drain
mode.  It'd be worth capturing that in the i2c-gpio.h definition
for that struct.

> Are such GPIO pins actually able to detect that the pin is 
> low while they are not themselves driving it low?

Given a "yes" to the above, then clearly "yes" here too.  As
I noted, if it can't actually sense the value at the pin, that
function should always return zero.

- Dave

-
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/