From: Salah Triki <salah.triki@gmail.com>
To: Crt Mori <cmo@melexis.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iio: temperature: mlx90614: Fix dual channel probe condition check
Date: Thu, 17 Sep 2026 14:16:15 +0100 [thread overview]
Message-ID: <aqvoH9ohxkJ6iPei@pc> (raw)
In-Reply-To: <CAKv63utdoBrCFiw8vkGsMhY9PrWX0DWdxqP5szvTGpdmfSQh5A@mail.gmail.com>
Hi Crt,
Thanks for your feedback.
Actually, the patch primarily fixes the behavior for the MLX90614.
In the current codebase, MLX90614 has `chip_info->dual_channel = true`.
Because `mlx90614_probe_num_ir_sensors()` checks
`if (chip_info->dual_channel)`, it returns 0 immediately for MLX90614
without reading the EEPROM CONFIG1 register. As a result, dual-channel
MLX90614 sensors are incorrectly registered as single-channel devices.
For MLX90615 (`dual_channel = false`), the condition was bypassed, causing
an unnecessary SMBus read to EEPROM CONFIG1, even though MLX90615 only
supports a single object channel.
By changing the check to `if (!chip_info->dual_channel)`, we fix both
issues:
1. MLX90614 correctly reads EEPROM CONFIG1 to detect whether it operates
in single or dual channel mode.
2. MLX90615 skips the EEPROM read entirely.
I don't have physical hardware to test this on; this bug was spotted via
code inspection.
Best regards,
Salah
On Thu, Sep 17, 2026 at 01:27:48PM +0200, Crt Mori wrote:
> So this fix is for the MLX90615, which is registered as single channel
> operation? Did you test on 90614 as well?
>
> Best regards,
> Crt
>
> Crt Mori
>
> Melexis Technologies NV
> Transportstraat 1
> 3980 Tessenderlo
>
> Mobile: +32 492 46 22 15
> E-mail: cmo@melexis.com
> Website: www.melexis.com
>
> ----------------------------------------------------------
> The contents of this e-mail are CONFIDENTIAL AND PROPRIETARY. Please
> read our disclaimer at http://www.melexis.com/mailpolicy
>
>
> On Thu, 17 Sept 2026 at 13:01, Salah Triki <salah.triki@gmail.com> wrote:
> >
> > In mlx90614_probe_num_ir_sensors(), the check on chip_info->dual_channel
> > is inverted.
> >
> > Currently, if dual_channel is true (MLX90614), the function returns 0
> > immediately without checking op_eeprom_config1. This forces all MLX90614
> > devices to be registered as single sensor (num_channels = 2), making the
> > second object temperature channel inaccessible.
> >
> > Conversely, if dual_channel is false (MLX90615), the function skips the
> > early return and performs an unnecessary SMBus read on EEPROM CONFIG1 even
> > though MLX90615 does not support dual channel operation.
> >
> > Fix this by negating the condition so that single-channel chips return
> > early with 0, while dual-channel capable chips (MLX90614) proceed to read
> > the EEPROM configuration register to detect whether 1 or 2 object channels
> > are present.
> >
> > Fixes: 3d5ead238bc8 ("iio: mlx90614: Factor our register IO and constants into model specific descriptor")
> > Assisted-by: LLM
> > Signed-off-by: Salah Triki <salah.triki@gmail.com>
> > ---
> > drivers/iio/temperature/mlx90614.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/temperature/mlx90614.c b/drivers/iio/temperature/mlx90614.c
> > index 27d6ab5f5d7a..4f79da1f905e 100644
> > --- a/drivers/iio/temperature/mlx90614.c
> > +++ b/drivers/iio/temperature/mlx90614.c
> > @@ -565,7 +565,7 @@ static int mlx90614_probe_num_ir_sensors(struct i2c_client *client)
> > const struct mlx_chip_info *chip_info = data->chip_info;
> > s32 ret;
> >
> > - if (chip_info->dual_channel)
> > + if (!chip_info->dual_channel)
> > return 0;
> >
> > ret = i2c_smbus_read_word_data(client, chip_info->op_eeprom_config1);
> > --
> > 2.43.0
> >
prev parent reply other threads:[~2026-09-17 13:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 11:01 [PATCH] iio: temperature: mlx90614: Fix dual channel probe condition check Salah Triki
2026-09-17 11:27 ` Crt Mori
2026-09-17 13:16 ` Salah Triki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aqvoH9ohxkJ6iPei@pc \
--to=salah.triki@gmail.com \
--cc=andy@kernel.org \
--cc=cmo@melexis.com \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.