In message <20020218053721.16516.qmail@mail.netbsd.org>eeh@netbsd.org writes
>| Have you read the SMBus spec?
>
>This is I2C bus.  What does SMBus have to do with this?

In some market segments of the hardware NetBSD supports, hardware
supports "i2c" devices but does not give any direct access to i2c.
Instead, you access i2c devices via an SMBus controller and/or
smb-to-i2c bridge.  The interface via these bridges is at a higher
level of abstraction than i2c.

Its easy to hide a low-level phase-aware, bit-banging, i2c interface
underneath a higher-level (smb) interface. The converse is much harder.

If we want to support i2c devices attached via various x86-world SMB
interfaces like PIIX4, or Serverworks OSB4 or CSB5 (Acer?) then our
``machine independent'' i2c interface has to support accessing i2c
devices which are wired up via these "smart" SMBus controllers.
That's where the proposed interface loses.

(See http://www2.lm-sensors.nu/~lm78/pdfs/smbnot.pdf, an Intel(?)
hardware design note for interconnecting SMbus and i2c devices, and
corresponding pullup values.)

So... the lowest-common-denominator is an SMBus-like API.

Sure, provide a raw bitbanging interface for i2c devices where that's
(a) provided, and (b) necessary. But dont *force* it, in case the i2c
bus is really an SMbus.