linux-kernel - Re: [PATCH] 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: <200703091317.58178.david-b@pacbell.net>
Date:	Fri, 9 Mar 2007 13:17:56 -0800
From:	David Brownell <david-b@...bell.net>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Jean Delvare <khali@...ux-fr.org>,
	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] Bitbanging i2c bus driver using the GPIO API

On Friday 09 March 2007 12:08 pm, Russell King wrote:
> On Fri, Mar 09, 2007 at 11:30:12AM -0800, David Brownell wrote:
> > On Friday 09 March 2007 10:48 am, 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.
> > 
> > That's the right idea!  But remember that not all GPIOs support
> > reading back the actual value on SCL (it's an OUT pin, so lacking
> > multidrive capability the values "should" be what you wrote), so
> > getscl() support should depend on a flag in platform data.  In
> > the same vein, if SCL is an output-only pin, you won't be able
> > to change its direction ... but then, I'm not sure why you were
> > changing its direction in setscl() rather than just its value.
> 
> That's a more correct I2C implementation.  If you read the specs, the
> SDA and SCL signals are supposed to be driven by open-collector or
> open-drain drivers, such that devices only pull the bus low.  Pull-up
> resistors pull the signals high when undriven.

Exactly as I had mentioned:

> > I2C has another interesting special case.  at91_set_multi_drive()
> > would be appropriate (yes?) for ARCH_AT91 to use on SCL, to best
> > support both clock stretching and multi-master configurations.

Where "multi-drive" == open-drain.  You're saying it should also be
used on SDA too ... OK, I was focussing on clock stretching but it
applies there too.

 
> This avoids the possibility of damage caused when one device drives
> a signal low and another device tries to drive it high.
> 
> Therefore, the correct I2C GPIO implementation is one where you drive
> both SDA and SCL low by using a combination of the data direction
> register and the output level register, but avoid driving the output
> high.

I see your point -- it does answer my question -- but you seem to have
overlooked a highly relevant one of mine.  :)

Regardless, those nuances should be captured in comments in that
driver:  that for GPIOs that don't support open drain output (only
push/pull drivers), that it's faked by otherwise-unnecessary
tweaking of GPIO direction.

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