[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<FR2PPF4571F02BCBB9894C421F5472EDE968CF8A@FR2PPF4571F02BC.DEUP281.PROD.OUTLOOK.COM>
Date: Fri, 31 Oct 2025 09:56:45 +0000
From: Remi Buisson <Remi.Buisson@....com>
To: Jonathan Cameron <jic23@...nel.org>,
Dan Carpenter
<dan.carpenter@...aro.org>
CC: David Lechner <dlechner@...libre.com>,
Nuno Sá
<nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>
Subject: RE: [PATCH next] iio: imu: inv_icm45600: Add a missing return
statement in probe()
>
>
>From: Jonathan Cameron <jic23@...nel.org>
>Sent: Monday, October 27, 2025 3:24 PM
>To: Dan Carpenter <dan.carpenter@...aro.org>
>Cc: Remi Buisson <Remi.Buisson@....com>; David Lechner <dlechner@...libre.com>; Nuno Sá <nuno.sa@...log.com>; Andy Shevchenko <andy@...nel.org>; linux-iio@...r.kernel.org; linux-kernel@...r.kernel.org; kernel-janitors@...r.kernel.org
>Subject: Re: [PATCH next] iio: imu: inv_icm45600: Add a missing return statement in probe()
>
>On Wed, 22 Oct 2025 14: 02: 20 +0300 Dan Carpenter <dan. carpenter@ linaro. org> wrote: > The intention here was clearly to return -ENODEV but the return statement > was missing. It would result in an off by one read in i3c_chip_info[]
>On Wed, 22 Oct 2025 14:02:20 +0300
>Dan Carpenter <dan.carpenter@...aro.org> wrote:
>
>> The intention here was clearly to return -ENODEV but the return statement
>> was missing. It would result in an off by one read in i3c_chip_info[] on
>> the next line. Add the return statement.
>>
>> Fixes: 1bef24e9007e ("iio: imu: inv_icm45600: add I3C driver for inv_icm45600 driver")
>> Signed-off-by: Dan Carpenter <dan.carpenter@...aro.org>
>> ---
>> drivers/iio/imu/inv_icm45600/inv_icm45600_i3c.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/imu/inv_icm45600/inv_icm45600_i3c.c b/drivers/iio/imu/inv_icm45600/inv_icm45600_i3c.c
>> index b5df06b97d44..9247eae9b3e2 100644
>> --- a/drivers/iio/imu/inv_icm45600/inv_icm45600_i3c.c
>> +++ b/drivers/iio/imu/inv_icm45600/inv_icm45600_i3c.c
>> @@ -57,7 +57,8 @@ static int inv_icm45600_i3c_probe(struct i3c_device *i3cdev)
>> }
>>
>> if (chip == nb_chip)
>> - dev_err_probe(&i3cdev->dev, -ENODEV, "Failed to match part id %d\n", whoami);
>> + return dev_err_probe(&i3cdev->dev, -ENODEV,
>> + "Failed to match part id %d\n", whoami);
>>
>> return inv_icm45600_core_probe(regmap, i3c_chip_info[chip], false, NULL);
>> }
>
>I'm going to apply this but the resulting code is still wrong (even if not
>a true bug after this fix).
>
>A hard ID match like this breaks use of dt fallback compatibles.
>What this should do is 'give it a go' on matching, but if there no match it should
>carry on as if the match was to whatever the compatible that was supplied was.
>When that happens a dev_info() is appropriate but not error out as this does.
>
>Remi, if possible could you look at adding such a patch on top of this?
>
>Thanks,
>
>Jonathan
>
Thanks Jonathan, the fix is correct.
The problem is that I3C don't specify any device in the device tree,
and these sensors cannot be identified by their I3C IDs neither.
So, the driver cannot fallbacks to any compatible device, other than picking one, more or less, at random.
Do you see any way to work around this limitation?
Powered by blists - more mailing lists