I have been trying to customize few i2c drivers and integrate it with a pla tform based on Intel Atom processor. Tried to use the i2c_add_driver concep t based on MODULE_DEVICE_TABLE inturn using .id_table which shall invoke t he probe function when the device and driver are both found on the system b y the Linux device driver subsystem. Used .id_table instead of .of_match_ta ble to avoid dependency on device tree. However, when I manually do a insmo d, the probe is not getting invoked though the call to i2c_add_driver is ha ppening.
On deep dive into linux flow of driver model (linux i2c driver stack), susp ecting that the flow of i2c_add_driver > i2c_register_driver > driver_regis ter > bus_add_driver > driver_attach > __driver_attach > driver_probe_devic e > 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 tur n also avoids the sysfs based path generation for my device.
On analysis via code walk through of linux i2c stack / driver model it appe ars 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_cl ient.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 s eems to check for compatible string based on device tree(.of type) and if i t is not available it goes with id_table based verification (i2c_match_id(i f id_table)). Also, the other suspect is that the bus information is not pa ssed via i2c_register_board_info and hence registration with bus does not g o through well from driver_register/bus_add_driver due to which klist_drive rs may not have the driver registered/list updated, inturn it may be possib le, the i2c_device_match gets into issue due to mismatch between the id whi le 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 to ss.
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 d ts 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 dt s file or board info such that it succeeds in invoking the probe function i n the case of i2c_add_driver based driver/loadable kernel module. If yes, c an 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 m andatory requirement, kindly let me know what else should be taken care or alternate approach to ensure that the probe is getting called and devices g et populated for respective bus in sysfs.
Thanks in advans, Karthik Balaguru