| At 19 Feb 2002 19:48:19 -0000,  wrote:
| > | > A framework for smart SMBus controllers can be easily built on a more
| > | > general i2c framework.
| > |
| > | How do you figure?  you need to expose the well-defined smbus commands
| > | all the way through the interface, or every back-end driver has to
| > | look at the commands that it sees, and try to recognize them as
| > | specific smbus commands.
| > 
| > I'd have thought that was obvious.  You create a SMBus interface which
| > SMBus devices call to generate a series i2c operations, then call 
| > i2c_cmd() as often as required to process the i2c commands.  SMOP.
|
| And how do smart controllers use that?
|
| they get called separately by that smbus interface?  or they grok the
| results of 'i2c_cmd' and turn them back into smart commands?

They get called by the smbus interface.

| The point is, how do you do this without inventing a new set of
| interfaces and add a whole new set of code, for smbus controllers,
| when really it _is_ the same code that needs to be written.

It *IS NOT* the same code.

| the only difference is that on 'real i2c' there's a higher likelyhood
| of needing commands with a non-standard format, which _need_ to be
| bitbanged.

There is *_NO_ _STANDARD_ _I2C_ _FORMAT_*!!!!!  

Pretending that there is a standard i2c format is merely going to 
cause headaches for people who discover that the SMBus commands they 
used to communicate to a i2c device, because they thought they were 
shorthand i2c commands, simply don't work.

| in i2c devices (which may appear on smbus) which _can_ use the
| higher-level command formats, you _should_ use higher-level command
| formats, to make the drivers clearer and to make the code more easily
| shared between the busses (and higher-performance, when there's a
| smart controller).

This idea is soooo broken in soooo many ways I really don't want to go
there.

Eduardo