Hi Wolfram, Thank you for the advice. Sorry for the delay in my response. (sorry for the duplicated message. I neglected to set plain text in my email editor). On Fri, Jan 3, 2014 at 7:52 AM, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > > I am not sure I get the problem. If you use i2c_register_board_info() to > > register the known devices on the designware busses the dynamically > > assigned numbers are guaranteed to be enumarated higer than the static > > ones. Check drivers/i2c/i2c-boardinfo.c. > > Ping. Was this helpful or do you still have the issue? Our devices and our platforms have some other requirements which turned me away from using i2c_register_board_info. i2c_register_board_info looks to create predeclarations for a specific i2c bus... However, right now, the chromeos_laptop driver is structured to do explicit declaration (using i2c_new_probed_device) *after* the busses have come up. Specifically, we have a class of atmel_mxt i2c touchpad/touchscreen devices that may appear at different addresses depending on whether the touch device is in bootloader mode or operational mode. For that reason, the chromeos_laptop driver uses i2c_new_probed_device with a list of possible addresses when dealing with the atmel touch device. You can see the driver here : drivers/platform/chrome/chromeos_laptop.c Is there some way of getting the "probe" behavior while using i2c_register_board_info? -- Benson Leung Software Engineer, Chrom* OS bleung@xxxxxxxxxxxx -- 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
