On 13 May 2013 10:26, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Mon, May 13, 2013 at 9:16 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > >>> - status = driver->probe(client, i2c_match_id(driver->id_table, client)); >>> + if (dev->driver->of_match_table) >>> + /* Device tree matching */ >>> + status = driver->probe(client, NULL); >>> + else >>> + /* Fall back to matching the id_table */ >>> + status = driver->probe(client, i2c_match_id(driver->id_table, client)); >> >> If you correctly register a device with "vendor,product" in the devicetree >> the driver can already fetch the of_device_id using of_match_device(dt_ids, &client->dev) >> just like a platform driver would do aswell. > > Yes, this is what I write in the commit message: > > "(...) If the driver wants to deduce secondary info > from the struct of_device_id .data field, it has to call > of_match_device() on its own match table in the probe function > device tree probe path." > >> i2c_match_id will return a NULL pointer if called with "vendor,product", >> because nothing matches in the drivers id_table, so for this case you >> change nothing. >> >> If anything, you introduce the problem that a devicetree capable driver >> no longer gets a i2c_device_id if the device was instantiated with >> i2c_board_info. > > Hm, you're right there, what about this: > > + if (dev->of_node) > + /* Device tree matching */ > + status = driver->probe(client, NULL); > + else > + /* Fall back to matching the id_table */ > + status = driver->probe(client, > i2c_match_id(driver->id_table, client)); > > If the device has an of_node it surely should not be using the > id_table and it'd be correct to pass NULL, right? That will break anything described in the device tree, but the driver currently using the heuristic and depending on the data field. You would instead need to test for an of_match_device() hit when suppressing the data field. g. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
