[PATCH 0/2] iio: light: adux1020: fix proximity measurement issues

[PATCH 0/2] iio: light: adux1020: fix proximity measurement issues

[Raffaele Tranfaglia via B4 Relay]

While testing the guard() conversion of this driver with i2c-stub, I
found two issues in adux1020_measure().

Patch 1 fixes a real bug: the interrupt clear value is computed as
~u16, which integer promotion turns into 0xffffff0f. Plain I2C
adapters silently truncate it to 0xff0f, but SMBus-only adapters reject
it with -EINVAL, so every proximity read fails on them.

Patch 2 extracts the FIFO byte count with FIELD_GET(). The current code
compares the unshifted field against the packet size. Per the
datasheet, the FIFO only stores complete packets, so this does not
misbehave on a working device, hence no Fixes tag.

Tested on arm64 QEMU with i2c-stub (an SMBus-only adapter), lockdep and
UBSAN enabled, planting FIFO byte counts in INT_STATUS by hand:
- before: reads fail with -EINVAL
- patch 1: count 2 returns the planted sample; count 1 also returns it
  (issue fixed by patch 2); count 0 times out with -EIO
- patch 1+2: count 2 returns the sample; counts 1 and 0 time out with
  -EIO
No lockdep or UBSAN reports.

I prepared these patches with the help of an AI coding assistant, and
reviewed and tested them myself.

---
Raffaele Tranfaglia (2):
      iio: light: adux1020: fix interrupt clear value on SMBus-only adapters
      iio: light: adux1020: extract the FIFO byte count with FIELD_GET()

 drivers/iio/light/adux1020.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
---
base-commit: b70566610b48ba49dec636019da4d696db64b085
change-id: 20261109-adux1020-measure-fixes-9f3bb844f758

Best regards,
--  
Raffaele Tranfaglia <raffaele.tranfaglia@gmail.com>

[PATCH 1/2] iio: light: adux1020: fix interrupt clear value on SMBus-only adapters

[Raffaele Tranfaglia via B4 Relay]

From: Raffaele Tranfaglia <raffaele.tranfaglia@gmail.com>

adux1020_measure() clears the mode interrupt by writing the inverted
interrupt enable mask to INT_STATUS. The mask is a u16, but integer
promotion makes ~0x00f0 evaluate to 0xffffff0f, which does not fit in
the 16-bit register.

On adapters supporting plain I2C, regmap formats the value with
put_unaligned_be16() and silently truncates it to 0xff0f. On adapters
that only support SMBus word transfers, regmap_smbus_word_write_swapped()
rejects values above 0xffff with -EINVAL, so every proximity read fails.

Mask the value to 16 bits so that SMBus-only adapters send the same
0xff0f that has always been written on plain I2C adapters.

Fixes: 356543545576 ("iio: light: Add support for ADUX1020 sensor")
Signed-off-by: Raffaele Tranfaglia <raffaele.tranfaglia@gmail.com>
---
 drivers/iio/light/adux1020.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/light/adux1020.c b/drivers/iio/light/adux1020.c
index d4281b9754c3..cccd509dd18a 100644
--- a/drivers/iio/light/adux1020.c
+++ b/drivers/iio/light/adux1020.c
@@ -346,7 +346,7 @@ static int adux1020_measure(struct adux1020_data *data,
 
 	/* Clear mode interrupt */
 	ret = regmap_write(data->regmap, ADUX1020_REG_INT_STATUS,
-			   (~adux1020_modes[mode].int_en));
+			   ~adux1020_modes[mode].int_en & 0xffff);
 	if (ret < 0)
 		return ret;
 

-- 
2.56.0

Re: [PATCH 1/2] iio: light: adux1020: fix interrupt clear value on SMBus-only adapters

[Andy Shevchenko]

On Mon, Nov 09, 2026 at 11:39:02AM +0000, Raffaele Tranfaglia via B4 Relay wrote:
> 
> adux1020_measure() clears the mode interrupt by writing the inverted
> interrupt enable mask to INT_STATUS. The mask is a u16, but integer
> promotion makes ~0x00f0 evaluate to 0xffffff0f, which does not fit in
> the 16-bit register.

Huh?! Where did you get it from? the mentioned promotion may only happen for
a signed char which may not hold 0x00f0 in the first place. The above is some
nonsense.

> On adapters supporting plain I2C, regmap formats the value with
> put_unaligned_be16() and silently truncates it to 0xff0f. On adapters
> that only support SMBus word transfers, regmap_smbus_word_write_swapped()
> rejects values above 0xffff with -EINVAL, so every proximity read fails.
> 
> Mask the value to 16 bits so that SMBus-only adapters send the same
> 0xff0f that has always been written on plain I2C adapters.

...

>  	ret = regmap_write(data->regmap, ADUX1020_REG_INT_STATUS,
> -			   (~adux1020_modes[mode].int_en));
> +			   ~adux1020_modes[mode].int_en & 0xffff);

On top of that regmap should limit the value to 16-bit anyway. If there is a
problem in regmap to cut the upper bits, it should be addressed rather there.

>  	if (ret < 0)
>  		return ret;

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] iio: light: adux1020: fix interrupt clear value on SMBus-only adapters

[Raffaele Tranfaglia]

On Mon, 9 Nov 2026 at 23:49, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Mon, Nov 09, 2026 at 11:39:02AM +0000, Raffaele Tranfaglia via B4 Relay wrote:
> >
> > adux1020_measure() clears the mode interrupt by writing the inverted
> > interrupt enable mask to INT_STATUS. The mask is a u16, but integer
> > promotion makes ~0x00f0 evaluate to 0xffffff0f, which does not fit in
> > the 16-bit register.
>
> Huh?! Where did you get it from? the mentioned promotion may only happen for
> a signed char which may not hold 0x00f0 in the first place. The above is some
> nonsense.

The integer promotions apply to all types with a rank lower than int
(e.g. char and short, signed or unsigned), as long as int can represent
all their values (C11 6.3.1.1p2 [1]). For ~ the standard says "The
integer promotions are performed on the operand" (6.5.3.3p4 [2]). So the
u16 0x00f0 becomes the int 0x000000f0, and ~ yields 0xffffff0f, which
regmap_write() receives as an unsigned int. sizeof(~v) is 4 for a u16 v.

It is also what I observed: with i2c-stub (SMBus only), every read of
in_proximity_raw fails with -EINVAL from the val > 0xffff check in
regmap_smbus_word_write_swapped(), and succeeds with this patch.

That said, I can reword the commit message to make this clearer.

[1] https://port70.net/~nsz/c/c11/n1570.html#6.3.1.1p2
[2] https://port70.net/~nsz/c/c11/n1570.html#6.5.3.3p4

> >       ret = regmap_write(data->regmap, ADUX1020_REG_INT_STATUS,
> > -                        (~adux1020_modes[mode].int_en));
> > +                        ~adux1020_modes[mode].int_en & 0xffff);
>
> On top of that regmap should limit the value to 16-bit anyway. If there is a
> problem in regmap to cut the upper bits, it should be addressed rather there.

Currently regmap is inconsistent here: the SMBus backends in
regmap-i2c.c (and regmap-fsi.c) reject out-of-range values with -EINVAL,
while the formatted plain I2C path silently truncates them. If you
think regmap_write() is the right place to mask the value to val_bits,
I can try to fix it there as a separate patch to regmap.

However, even if regmap changed, the driver would still be passing a
32-bit value for a 16-bit register. regmap_write() takes an unsigned
int, but logically it accepts values of the register width, so I think
the driver should be fixed in any case. From a quick search, this is
also what other drivers do when writing an inverted value to a narrower
register, e.g. ad4691 uses ~BIT(chan->channel) & GENMASK(15, 0) and
zpa2326 uses (u8)~ZPA2326_CTRL_REG1_MASK_DATA_READY. Fixing the driver
is also the change that can be backported cleanly through the Fixes:
tag.

--
Best regards,
Raffaele

Re: [PATCH 1/2] iio: light: adux1020: fix interrupt clear value on SMBus-only adapters

[Andy Shevchenko]

On Tue, Nov 10, 2026 at 08:12:06AM +0000, Raffaele Tranfaglia wrote:
> On Mon, 9 Nov 2026 at 23:49, Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> > On Mon, Nov 09, 2026 at 11:39:02AM +0000, Raffaele Tranfaglia via B4 Relay wrote:

...

> > > adux1020_measure() clears the mode interrupt by writing the inverted
> > > interrupt enable mask to INT_STATUS. The mask is a u16, but integer
> > > promotion makes ~0x00f0 evaluate to 0xffffff0f, which does not fit in
> > > the 16-bit register.
> >
> > Huh?! Where did you get it from? the mentioned promotion may only happen for
> > a signed char which may not hold 0x00f0 in the first place. The above is some
> > nonsense.
> 
> The integer promotions apply to all types with a rank lower than int
> (e.g. char and short, signed or unsigned), as long as int can represent
> all their values (C11 6.3.1.1p2 [1]). For ~ the standard says "The
> integer promotions are performed on the operand" (6.5.3.3p4 [2]). So the
> u16 0x00f0 becomes the int 0x000000f0, and ~ yields 0xffffff0f, which
> regmap_write() receives as an unsigned int. sizeof(~v) is 4 for a u16 v.

Indeed, I missed that u16 --> int, which is signed. Oh, well...

> It is also what I observed: with i2c-stub (SMBus only), every read of
> in_proximity_raw fails with -EINVAL from the val > 0xffff check in
> regmap_smbus_word_write_swapped(), and succeeds with this patch.

Can you give a Kunit test case? Because regmap specifies the val_bits == 16.
See also [3].

> That said, I can reword the commit message to make this clearer.
> 
> [1] https://port70.net/~nsz/c/c11/n1570.html#6.3.1.1p2
> [2] https://port70.net/~nsz/c/c11/n1570.html#6.5.3.3p4

[3]: https://lore.kernel.org/linux-iio/avLpEA6CoZvicvDN@ashevche-desk.local/

> > >       ret = regmap_write(data->regmap, ADUX1020_REG_INT_STATUS,
> > > -                        (~adux1020_modes[mode].int_en));
> > > +                        ~adux1020_modes[mode].int_en & 0xffff);
> >
> > On top of that regmap should limit the value to 16-bit anyway. If there is a
> > problem in regmap to cut the upper bits, it should be addressed rather there.
> 
> Currently regmap is inconsistent here: the SMBus backends in
> regmap-i2c.c (and regmap-fsi.c) reject out-of-range values with -EINVAL,
> while the formatted plain I2C path silently truncates them. If you
> think regmap_write() is the right place to mask the value to val_bits,
> I can try to fix it there as a separate patch to regmap.

I believe this is due to some specific value formatters in the regmap, where
format_write is defined (!= NULL) or other similar cases.

> However, even if regmap changed, the driver would still be passing a
> 32-bit value for a 16-bit register.

Is it a problem?

> regmap_write() takes an unsigned int, but logically it accepts values of the
> register width, so I think the driver should be fixed in any case. From a
> quick search, this is also what other drivers do when writing an inverted
> value to a narrower register, e.g. ad4691 uses ~BIT(chan->channel) &
> GENMASK(15, 0) and zpa2326 uses (u8)~ZPA2326_CTRL_REG1_MASK_DATA_READY.
> Fixing the driver is also the change that can be backported cleanly through
> the Fixes: tag.

Well, I disagree based on the above analysis. But if you make a KUnit test case
(against regmap) to prove your point, it will be well appreciated!

-- 
With Best Regards,
Andy Shevchenko

[PATCH 2/2] iio: light: adux1020: extract the FIFO byte count with FIELD_GET()

[Raffaele Tranfaglia via B4 Relay]

From: Raffaele Tranfaglia <raffaele.tranfaglia@gmail.com>

adux1020_measure() masks INT_STATUS with ADUX1020_FIFO_STATUS_MASK but
does not shift the result down, so it compares 256 times the FIFO byte
count against the packet size. A count of 1 would thus be treated as a
complete 2-byte proximity packet.

This does not happen on a correctly working device, because the FIFO
only stores complete packets and the driver always reads complete
packets, so the count is always a multiple of the packet size. Still,
use FIELD_GET() so the comparison matches the datasheet's polling
procedure and does not depend on that.

Signed-off-by: Raffaele Tranfaglia <raffaele.tranfaglia@gmail.com>
---
 drivers/iio/light/adux1020.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/light/adux1020.c b/drivers/iio/light/adux1020.c
index cccd509dd18a..dd5230c6dceb 100644
--- a/drivers/iio/light/adux1020.c
+++ b/drivers/iio/light/adux1020.c
@@ -331,7 +331,7 @@ static int adux1020_measure(struct adux1020_data *data,
 		if (ret < 0)
 			return ret;
 
-		status &= ADUX1020_FIFO_STATUS_MASK;
+		status = FIELD_GET(ADUX1020_FIFO_STATUS_MASK, status);
 		if (status >= adux1020_modes[mode].bytes)
 			break;
 		msleep(20);

-- 
2.56.0