Subject: Re: SMBus implementation
To: Jared D.McNeill <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 10/27/2005 06:27:05
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
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
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
> 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*.