Sorry for replying to self...
On 2018-04-08 11:08, Peter Rosin wrote:
> On 2018-04-08 09:34, Wolfram Sang wrote:
>> Hi,
>>
>> On Mon, Mar 19, 2018 at 09:10:58AM -0700, Guenter Roeck wrote:
>>> Commit dde67eb1beeb ("i2c: add i2c_get_device_id() to get the standard
>>> I2C device id") added a function to return the standard I2C device ID.
>>> Use that function to verify the device ID of a given device.
>>
>> I am very open to these patches, just...
>>
>>>
>>> Cc: Peter Rosin <peda@xxxxxxxxxx>
>>> Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx>
>>> ---
>>> RFC:
>>> - Compile tested only
>>
>> ... I would really like to have them tested. After that happened, Peter
>> and I can figure out who should apply them for seamless upstreaming.
>>
>>> - Should there also be I2C_DEVICE_PART_ID_ANY to enable maching
>>> against all parts from a given manufacturer ?
>>
>> Can't we just add it when we need it?
Is it really reasonable to verify just the manufacturer? I don't see the
use case? I mean, we can never know if the verified manufacturer will
release unexpected chips further down the line.
>>> + dev_err(&client->dev, "unexpected device id %03x-%03x-%x\n",
>>> + real_id.manufacturer_id, real_id.part_id,
>>> + real_id.die_revision);
>>> + return -ENODEV;
>>
>> I wonder about the ERR loglevel. ENODEV is not an error, I'd think?
>
> Well, in this case someone has said that I2C addr <xyz> is a <uvw> device,
> but when verifying the actual device at that addr, that's not what is
> found. Hence, I think an error is appropriate? On the other hand, a driver
> that can handle different kinds of devices might not want the error. But
> for that case, maybe the driver should be using i2c_get_device_id() and
> figure out the details by itself?
Maybe it should just be -EINVAL, and that's your real objection?
Cheers,
Peter
