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, 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.

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 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 to ensure that the
probe is getting called and devices get populated for respective bus in sysfs.

Thanks in advans,
Karthik Balaguru

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)