> > When matching an OF device, the match mechanism tries all components of > > the compatible property. This can result with a device matched with a > > compatible string that isn't the first in the compatible list. For > > instance, with a compatible property set to > > > > compatible = "ti,dac081c081", "ti,dac5571"; > > > > the driver will match the second compatible string, as the first one > > isn't listed in the of_device_id table. The device will however be named > > "dac081c081" by the I2C core. > > > > This causes an issue when identifying the chip. The probe function > > receives a i2c_device_id that comes from the module's I2C device ID > > table. There is no entry in that table for "dac081c081", which results > > in a NULL pointer passed to the probe function. > > > > To fix this, add chip_id information in the data field of the OF device > > ID table, and retrieve it with of_device_get_match_data() for OF > > devices. > > > > Signed-off-by: Jose Cazarin <joseespiriki@xxxxxxxxx> > > Reviewed-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > Interesting problem that I hadn't previously realised could happen. > > One request though, can we use device_get_match_data() here rather than > the of specific version? Include property.h as well for that. > > That should allow the same issue with compatible to work correctly when > using PRP0001 based ACPI methods. > https://elixir.bootlin.com/linux/v5.14-rc1/source/drivers/acpi/bus.c#L891 > Will result in acpi_of_device_get_match_data() being called which will > match to the of_device_id table. Couldn't you use the "new" probe_new() callback instead which will drop the i2c_device_id? Kieran was interested in such conversions IIRC.
Attachment:
signature.asc
Description: PGP signature
