Documentation issue on attaching new style drivers
Quoting from Documentation/i2c/writing-clients, the section entitled "Standard Driver Model Binding ("New Style")" has the following paragraph:
Drivers match devices when i2c_client.driver_name and the driver name are the same; this approach is used in several other busses that don't have device typing support in the hardware. The driver and module name should match, so hotplug/coldplug mechanisms will modprobe the driver.
Having tried this whilst upgrading an old driver in my own tree, I found that this does not work, and that you need to supply your own idtable for the .id_table entry.
I had a quick look in drivers/i2c/i2c-core.c and it seems that the only thing the .match entry i2c_device_match() is doing is checking the driver's id_table, as so:
static int i2c_device_match(struct device *dev, struct device_driver *drv)
{
struct i2c_client *client = to_i2c_client(dev);
struct i2c_driver *driver = to_i2c_driver(drv);
/* make legacy i2c drivers bypass driver model probing entirely;
* such drivers scan each i2c adapter/bus themselves.
*/
if (!is_newstyle_driver(driver))
return 0;
/* match on an id table if there is one */
if (driver->id_table)
return i2c_match_id(driver->id_table, client) != NULL;
return 0;
}Is the documentation wrong, and all drivers need to have an id_table in them, or is the i2c-core.c wrong for only checking the id_table entries?
My suspicion is that everyone is using the id_table as this can be passed to the MODULE_DEVICE_TABLE() to allow autoloading of the relevant modules? Note, the i2c_probe function will correctly pass a NULL ID if there is no id_table present.
Signature · 8 lines
Ben ([email protected], http://www.fluff.org/) 'a smiley only costs 4 bytes' _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Ben,
Quoted 35 lines · Ben Dooks
Quoting from
Documentation/i2c/writing-clients, the section entitled "Standard Driver Model Binding ("New Style")" has the following paragraph:Drivers match devices when i2c_client.driver_name and the driver name are the same; this approach is used in several other busses that don't have device typing support in the hardware. The driver and module name should match, so hotplug/coldplug mechanisms will modprobe the driver.
Having tried this whilst upgrading an old driver in my own tree, I found that this does not work, and that you need to supply your own idtable for the .id_table entry.
I had a quick look in
drivers/i2c/i2c-core.cand it seems that the only thing the .match entryi2c_device_match()is doing is checking the driver'sid_table, as so:static int
i2c_device_match(struct device *dev, struct device_driver *drv){ struct i2c_client *client = to_i2c_client(dev); struct i2c_driver *driver = to_i2c_driver(drv); /* make legacy i2c drivers bypass driver model probing entirely; * such drivers scan each i2c adapter/bus themselves. */ if (!is_newstyle_driver(driver)) return 0; /* match on an id table if there is one */ if (driver->id_table) return i2c_match_id(driver->id_table, client) != NULL; return 0; }
Quoted 3 lines
Is the documentation wrong, and all drivers need to have an
id_tablein them, or is thei2c-core.cwrong for only checking theid_tableentries?
The documentation is wrong, or more precisely, it's out-of-date. It was correct when it was written, but the i2c subsystem was updated since then and I forgot to update this piece of documentation. Do you feel like submitting a patch fixing it?
Quoted 4 lines
My suspicion is that everyone is using the
id_tableas this can be passed to theMODULE_DEVICE_TABLE()to allow autoloading of the relevant modules? Note, thei2c_probefunction will correctly pass a NULL ID if there is noid_tablepresent.
The id_table is mandatory. The i2c_device_probe() function can be simplified now, as it will never be called if driver->id_table is NULL. I'll send a patch right now, thanks for pointing this out.
Signature · 6 lines
Jean Delvare _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c