Hi Linus, On Mon, 18 May 2009 16:22:36 +0200, Linus Walleij wrote: > Here we have a problem. See above: > msgs[0].addr = ab3100_i2c_client->addr + 1; > > So this chip actually has two addresses. A "special" address > to deal with test registers, one address up. The I2C framework > assume all devices have one and one address only (which is > of course mostly true). No, the I2C framework doesn't assume this. All the I2C framework assumes is that only one device can use a given address on any one I2C segment (which seems reasonable.) > Here is a special case. When the first device has registered, > you know that the other address is available as well. > > You could think of several ugly solutions: > > * Keep using i2c_transfer() directly as we do now. > > * Make a raw copy of the i2c_device with something like > memcpy(mock_client, i2c_client, sizeof(i2c_client); > mock_client->addr++; > then use i2c_master_send() > > * Register a new i2c_device in board_info for the other > address while strictly speaking it is the same device, and > this will yield a lot of probing and synchronization code, > because writing the test registers is used when probing the > first device, so we have to wait for that device to be probed > before we can probe the other one etc. > > Right now I lean toward the first alternative. Neither is correct. Simply use i2c_new_dummy() on the second I2C address, and keep a pointer to the instantiated i2c_client for future use. Don't forget to call i2c_unregister_device() in your .remove() method. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html