summaryrefslogtreecommitdiffstats
path: root/net/bluetooth
diff options
context:
space:
mode:
authorDavid Brownell <david-b@pacbell.net>2007-11-15 19:24:01 +0100
committerJean Delvare <khali@hyperion.delvare>2007-11-15 19:24:01 +0100
commit907135aaa0cc120a347222c8f274ecc5ca0db641 (patch)
tree0572c3fc649030ffee737907228a9bfb6094a63a /net/bluetooth
parentMerge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (diff)
downloadlinux-907135aaa0cc120a347222c8f274ecc5ca0db641.tar.xz
linux-907135aaa0cc120a347222c8f274ecc5ca0db641.zip
i2c-dev: "how does it work" comments
This adds some "how does this work" comments to the i2c-dev driver, plus separators between the three main components: - The parallel list of i2c_adapters ("i2c_dev_list"), each of which gets a "struct i2c_dev" and a /dev/i2c-X character special file. - An i2cdev_driver gets adapter add/remove notifications, which are used to maintain that list of adapters. - Special file operations, which let userspace talk either directly to the adapter (for i2c_msg operations) or through cached addressing info using an anonymous i2c_client (never registered anywhere). Plus there's the usual module load/unload record keeping. After making sense of this code, I think that the anonymous i2c_client is pretty shady. But since it's never registered, using this code with a system set up for "new style" I2C drivers is no more complicated than always using the I2C_SLAVE_FORCE ioctl (instead of I2C_SLAVE). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Diffstat (limited to 'net/bluetooth')
0 files changed, 0 insertions, 0 deletions