[i2c] rewrite i2c core ... ?

[Jean Delvare]

Hi David,

On Sun, 12 Nov 2006 17:43:54 -0800, David Brownell wrote:
> > 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;

Yes, there is.

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

This is a misdesign of the I2C protocol in the first place. If devices
can be instanciated arbitrarily on the bus in the new model, it will
make things easier in a number of areas, but we still need device
detection in some cases so we won't be able to give up the SMBUS_QUICK
trick.

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

Except that you can't have two i2c subsystems in the kernel at the same
time, symbol names will inevitably collide. You need to replace the i2c
core, and convert existing i2c device drivers, rather than adding new
ones. Likewise, don't create a new smbus compatibility layer, when we
already have one which works just fine.

I don't think things will be easier by starting from scratch, as
opposed to converting the existing code. In the end you'll still need
to convert a large part of the existing code and drivers. But I'm not
stopping you from giving it a try, as nothing is happening right now,
any help is welcome.

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

No, there's nothing to test right now. I don't think Mark ever posted
his work publicly. I have one patch from him but it was really
preliminary stuff, it's even no longer in my public i2c tree. Previous
proposal by Alessandro and Nathan is archived on the sensors list if
you want to take a look:
http://lists.lm-sensors.org/pipermail/lm-sensors/2005-November/014299.html

-- 
Jean Delvare