In message <20020220084714.5B89FB5@proven.weird.com>Greg A. Woods writes

>
>In other words a plain simple straight i2c interface is always going to
>be useful for instances where all you have is an i2c bus.


Nobody ever said it isn't useful. It's not *always* best, though.

Suppose someone takes a native I2c controller (like some of the via
apollo?), and wires a native SMBus device behind it (say, an lm78).
Then a better design than othe one on the table is an SMBus-style
(QUICK/BYTE[rw]/BLOCK[rw] &c) API, in software, as part of the
interface of all i2c-like devices.

OTOH, if the i2c[sic] device you want to talk to is behind a PIIX4, (or
Serverworks clone), or an ALI 1535 or AMD 756 or Intel 801 or viapro
(or an Apple Keywest?), then the only option you have is  SMBus ops.

>However when you have an SMBus you probably only want to talk to SMBus
>devices, not any i2c devices that may be front-ended by them [...]

Maybe, maybe not. Thats where the commments on the proposed
architecture arise.


Havard, how about this:
  1.  Extend the proposed i2c(9), to include SMBus primitives.
  2.  Note that NetBSD may support ``i2c busses'' attached via SMBus
     controllers, where only the SMBus primitives are supported;
  3. provide an i2c bitbang statemachine to do SMBus-style transactions
     (to lm78s, &c), for attachments where the "i2c"  controller doesn't
     do SMBus in hardware?

This may still not be OK (IPMI? ICMB?), but it seems a closer match
to hardware "out there" today than just raw bitbanging.