>> 3. for chips like max732x, actually, the range of 0x50 - 0x5F will be >> monitored by the I2C chips at startup to decide the connections of >> AD2/AD0 pins to GND/VCC/SCL/SDA, so actually, even if the chip >> is finally decided at, say 0x56, no sane hardware designers will put >> another chip whose address falls between 0x50-0x5F together with >> such a max732x chip, ugly, but true. > > Why do these chips have a selectable address at all then, if they > virtually use all the range of possible addresses? I don't buy this > point at all. I see no reason why putting another chip in the same > range would cause any problem.
Selectable address is used to decide the initial state of each pin (especially the output level). Due to the fact that SCL/SDA are initially held high, the chip has to monitor the first I2C activity to decide if AD2/AD0 is tied to one of GND/VCC/SCL/SDA. > >> One i2c_client requesting a group of address could somehow be >> more reasonable, and requested address can be changed at >> run-time. > > It would be more reasonable, but it would be racy (as your original > driver was, now that I come to think of it.) Without a mutex (or > equivalent) to protect the i2c_client structure, two concurrent > accesses at different addresses would break. And if you add a mutex to > the i2c_client, and take it for every access, then you have a > performance degradation. I definitely prefer to waste a few hundreds > bytes in memory. > > One possible solution to this problem would be to split the few fields > needed by i2c_smbus_* and friends, to a separate structure (say, > i2c_handle). One i2c_client structure would include one i2c_handle, and > could have an optional array of extra ones for multi-address chips. > This would however require that we change the prototype of all > i2c_smbus_* helper functions, this is a big change, so it better be > well considered and deemed worth the effort. Sounds good. > >> >> Anyway, here's the one for i2c_new_dummy(). >> (...) ... > Looks OK to me. > So , do you see any chance of this getting merged during this window? If that's possible, please consider merge, thanks. > -- > Jean Delvare > -- Cheers - eric _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
