Populating device list in sysfs, probe invocation - device driver customization / integra...

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to


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

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

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

Site Timeline