Hi, 

I have been trying to customize few i2c drivers and integrate it with a platform based on Intel Atom processor. Tried to use the i2c_add_driver concept based on MODULE_DEVICE_TABLE inturn using .id_table  which shall invoke the probe function when the device and driver are both found on the system by the Linux device driver subsystem. Used .id_table instead of .of_match_table to avoid dependency on device tree. However, when I manually do a insmod, the probe is not getting invoked though the call to i2c_add_driver is happening. 

On deep dive into linux flow of driver model (linux i2c driver stack), suspecting that the flow of i2c_add_driver > i2c_register_driver > driver_register > bus_add_driver > driver_attach > __driver_attach > driver_probe_device > really_probe > i2c_device_probe > my_device_probe is getting broken in between these calls and hence the probe is not getting invoked which in turn also avoids the sysfs based path generation for my device.   

On analysis via code walk through of linux i2c stack / driver model it appears that the possible suspect are that name in i2c_device_id (via .id_table) does not match with name passed via i2c_register_board_info (i.e., i2c_client.name via type in i2c_board_info) and hence the  probe is 
not getting invoked. It appears that i2c_device_match routine of i2c_core seems to check for compatible string based on device tree(.of type) and if it is not available it goes with id_table based verification (i2c_match_id(if id_table)). Also, the other suspect is that the bus information is not passed via i2c_register_board_info and hence registration with bus does not go through well from driver_register/bus_add_driver due to which klist_drivers may not have the driver registered/list updated, inturn it may be possible, the i2c_device_match gets into issue due to mismatch between the id while addition to the bus. This in turn can impact getting the devices listed in sysfs and hence the sysfs based path generation for device goes for a toss. 

The debug logs seems to suggest that __driver_attach is not getting invoked and hence driver_match_device , driver_probe_device does not get triggered.

However, the framework that i have seems to be not based on board_info or dts file (grep did not return i2c_register_board_info or dts file). So, can you kindly let me know whether it is mandatory requirement to use either dts file or board info such that it succeeds in invoking the probe function in the case of i2c_add_driver based driver/loadable kernel module. If yes, can you kindly share the few reference of dts file for intel atom processor(or equivalent) in kernel codebase and points to be taken care or the place of invocation of i2c_register_board_info for intel atom processor such that i2c_board_info is registered via i2c_register_board_info. If it is not a mandatory requirement, kindly let me know what else should be taken care or alternate approach to ensure that the probe is getting called and devices get populated for respective bus in sysfs. 

Thanks in advans, 
Karthik Balaguru