On 7/25/05, Yuli Barcohen [off-list ref] wrote:

quoted

quoted

quoted

quoted

quoted

Kate Alhola writes:

=20
    Yuli> SPI is very similar to I2C IMHO. I'm not sure separate
    Yuli> infrastructure is needed. We support SPI on MPC8xx/82xx/85xx
    Yuli> using the standard I2C infrastructure. I only had to add a
    Yuli> couple of IOCTLs to control clock frequency and polarity. Due
    Yuli> to such an implementation, lm-sensors work OK with SPI
    Yuli> temperature sensors, for example.
=20
    Kate> SPI IS wery similar than I2C and for this reason it looks a
    Kate> like that all SPI subsystems implementations are based on I2C
    Kate> code.

Thanks for the comments everyone.  I had seen the first cut at an SPI
subsystem on the lkml, but I hadn't seen the revised patch.  My
understanding from GregKH's comments on the first patch is that i2c is
a bit of a mess:

From http://lkml.org/lkml/2005/5/31/251

"The i2c dev interface is a mess, please don't duplicate it, there is
no need to do so."

What is current opinion on the i2c subsystem?  Did I misunderstand
Greg's I2C comments?  I put together the SPI patch as an alternative
implementation that matches the current coding conventions (as I
understand them).

Yuli, are there any plans to submit your i2c changes to support SPI
back to mainline?

I've now got to go back and review the revised SPI patch on the LKML.

Thanks again,
g.