Hi Wolfram,

On Tue, Aug 17, 2021 at 10:44:20PM +0200, Wolfram Sang wrote:

quoted

quoted

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 <redacted>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

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.

It's a bit unrelated to this patch, but I can add another patch to the
series.

While I have your attention, there's a question for you in the cover
letter :-) Could you please have a look ?

-- 
Regards,

Laurent Pinchart