[i2c] rewrite i2c core ... ?

[David Brownell]

You wrote at Tue Oct 3 14:43 CEST 2006:

> > I had imagined that there'd be short term fixes (this being one),
> > and in the not-so-longer term the I2C stack would get fixed.  ISTR
> > posting a patch about 2 years ago with one notion of how that stack
> > should get fixed, to a distinct lack of interest/feedback/comment.
> 
> Several persons proposed to extend the i2c-core to make it possible,
> including Nathan Lutchansky and Alessandro Zummo. The problem is that
> they were merely adding workarounds on top of a broken i2c-core. What
> we really need is a rewrite of i2c-core which would follow the
> principles of the device driver model.

I hope there's agreement on that "need a rewrite" point!  I agree;
but if there's much pushback, the momentum behind the older stack
could cause some nasty arguments ... even though it's probably a
misnomer to call it an "I2C" stack, since it behaves poorly with
controller drivers that don't support SMBUS_QUICK and relies so
much on not-guaranteed-to-work chip probing.

Technically, several people have liked the notion of seeding such
a thing with the SPI stack:  clone-and-modify SPI, remove support
for full duplex, fix names to not be spi_*, update addressing model,
now we're probably at almost 1.5 KB code on ARM.  Then create a synch
smbus-ish/compat layer, add drivers, shake/stir to taste.  There
are surely worse ways to start!


>		 Since then Mark Hoffman has been 
> working on a cleanest approach, but he appears to be even busier than I
> am so progress is slow.

Just to be clear ... there's nothing currently usable to address this?
No reviewable/runnable patches, etc?  Are there any archived emails
summarizing proposals that have been discussed?

- Dave