On Oct 27, 2005, at 2:49 AM, Jared D. McNeill wrote:

>> This needs to be done within the context of sys/dev/i2c (which
>> already has support for doing smbus operations with "regular" I2C
>> interfaces).  If it doesn't integrate with the existing I2C
>> framework, it's a non-starter.
>
> Should 'smbus' attach to iic, or should iic also be an smbus?

Neither.  smbus operations are really just specific i2c sequences, so  
there really doesn't need to be an "smbus" instance at all (since  
every iic would logically have an smbus child -- seems rather  
pointless).

Although...

So, iic uses indirect config.  But, I believe that smbus can actually  
use direct config (isn't there some handshaking method to determine  
which devices are on an SMBus?)  If that is the case, then maybe it  
makes sense to attach an smbus instance to an iic instance (iff  
specified in the kernel config file).  In that case, then smbus  
devices would attach to the smbus.  The iic_smbus_*_byte() helper  
functions could move into the smbus module, and just become  
smbus_*_byte().

As for the controller interface, just glue an smbus controller in as  
a regular i2c controller, and error out with ENOTSUP if the arguments  
to the "exec" method don't match SMBus's constraints.

>> There should not be /dev/smb* device nodes, IMO.
>
> Agreed, but without support for attaching other devices (where the  
> code
> is today), not very useful :) It's at least helpful for debugging.

Let's get the configuration and glue worked out first.  Need to  
figure out how it would interact with a hypothetical /dev/i2c*.

/dev/smb* is the wrong name anyway.  If we were to have such devices,  
they should be /dev/smbus*.

-- thorpej