On 19 Feb 2002 eeh@netbsd.org wrote:

> | At 19 Feb 2002 19:48:19 -0000,  wrote:
> | 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.

Why not?

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

No, but there is a/are standard SMBus command(s) aren't there? When
talking to an i2c chip, why not use SMBus commands when what we want to do
happens to match SMBus commands?

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

Why? Either the SMBus commands had a 1-1 mapping with i2c commands, or
they didn't. If they didn't, they weren't the thing to use. If they did,
where is the problem.

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

Well, the rest of us do want to go there. Please explain to us why it
won't work. If you succeed, then everyone will say, "yes, they need to be
different." But until then, since the chips are electrically compatable,
why shouldn't we use a mutually-compatable software interface?

Take care,

Bill