[PATCH] iio: accel: adxl380: clamp FIFO sample count

[PATCH] iio: accel: adxl380: clamp FIFO sample count

[Shengzhuo Wei]

The FIFO entry count is a 9-bit device-reported value and can therefore
be as large as 511. fifo_buf[], however, only has room for
ADXL380_FIFO_SAMPLES (315) entries.

After rounding the count down to a multiple of fifo_set_size,
adxl380_irq_handler() uses it directly as the length of a bulk FIFO
read. If the reported count exceeds ADXL380_FIFO_SAMPLES, this can
overflow fifo_buf.

Clamp the reported entry count to the size of fifo_buf before rounding
it down.

Fixes: df36de13677a ("iio: accel: add ADXL380 driver")
Cc: stable@vger.kernel.org
Assisted-by: GLM:5.2
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
---
 drivers/iio/accel/adxl380.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
index 7dca5523091fc4c6a3c3bf7e388d5d0d507bee19..8a9d82e1d882aa45721013590ecbd86b083a15a6 100644
--- a/drivers/iio/accel/adxl380.c
+++ b/drivers/iio/accel/adxl380.c
@@ -966,6 +966,7 @@ static irqreturn_t adxl380_irq_handler(int irq, void  *p)
 	if (ret)
 		return IRQ_HANDLED;
 
+	fifo_entries = min(fifo_entries, ADXL380_FIFO_SAMPLES);
 	fifo_entries = rounddown(fifo_entries, st->fifo_set_size);
 	ret = regmap_noinc_read(st->regmap, ADXL380_FIFO_DATA, &st->fifo_buf,
 				sizeof(*st->fifo_buf) * fifo_entries);

---
base-commit: 848acc8ffe1b7cd5f1bf427b93069becfebc2c9d
change-id: 20260809-adxl380-fifo-clamp-f07a570d96b1

Best regards,
-- 
Shengzhuo Wei <me@cherr.cc>

Re: [PATCH] iio: accel: adxl380: clamp FIFO sample count

[Jonathan Cameron]

On Sun, 09 Aug 2026 06:18:51 +0800
"Shengzhuo Wei" <me@cherr.cc> wrote:

> The FIFO entry count is a 9-bit device-reported value and can therefore
> be as large as 511. fifo_buf[], however, only has room for
> ADXL380_FIFO_SAMPLES (315) entries.
> 
> After rounding the count down to a multiple of fifo_set_size,
> adxl380_irq_handler() uses it directly as the length of a bulk FIFO
> read. If the reported count exceeds ADXL380_FIFO_SAMPLES, this can
> overflow fifo_buf.
> 
> Clamp the reported entry count to the size of fifo_buf before rounding
> it down.
> 
> Fixes: df36de13677a ("iio: accel: add ADXL380 driver")

In my opinion at least, these are not fixes. In general we don't expect
drivers to be hardened against broken hardware returning out of spec
values.  I don't mind taking simple cases though that don't complicate
the code much and if anything make it a little easier to follow,
but I don't currently see any reason to mark them as a fix.

So drop that tag for v2.

> Cc: stable@vger.kernel.org
> Assisted-by: GLM:5.2
> Signed-off-by: Shengzhuo Wei <me@cherr.cc>
> ---
>  drivers/iio/accel/adxl380.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
> index 7dca5523091fc4c6a3c3bf7e388d5d0d507bee19..8a9d82e1d882aa45721013590ecbd86b083a15a6 100644
> --- a/drivers/iio/accel/adxl380.c
> +++ b/drivers/iio/accel/adxl380.c
> @@ -966,6 +966,7 @@ static irqreturn_t adxl380_irq_handler(int irq, void  *p)
>  	if (ret)
>  		return IRQ_HANDLED;
>  
> +	fifo_entries = min(fifo_entries, ADXL380_FIFO_SAMPLES);

This is papering over what we think is a hardware failure. Unless I am
missing something the device is returning garbage, otherwise we are in
range and this has no affect. We have no idea how much data there is
if we get a value outside the expected range. 

As such I'd expect an error print and probably no attempt to carry
on reading as we have no idea what happened.

>  	fifo_entries = rounddown(fifo_entries, st->fifo_set_size);
>  	ret = regmap_noinc_read(st->regmap, ADXL380_FIFO_DATA, &st->fifo_buf,
>  				sizeof(*st->fifo_buf) * fifo_entries);
> 
> ---
> base-commit: 848acc8ffe1b7cd5f1bf427b93069becfebc2c9d
> change-id: 20260809-adxl380-fifo-clamp-f07a570d96b1
> 
> Best regards,

Re: [PATCH] iio: accel: adxl380: clamp FIFO sample count

[Shengzhuo Wei]

在 2026-08-10 00:28，Jonathan Cameron 写道：
> > Fixes: df36de13677a ("iio: accel: add ADXL380 driver")
> 
> In my opinion at least, these are not fixes. In general we don't expect
> drivers to be hardened against broken hardware returning out of spec
> values.  I don't mind taking simple cases though that don't complicate
> the code much and if anything make it a little easier to follow,
> but I don't currently see any reason to mark them as a fix.
> 
> So drop that tag for v2.
> 

Hi Jonathan,

Thanks. Understood — I'll drop the Fixes tag and stop clamping. 

> This is papering over what we think is a hardware failure. Unless I am
> missing something the device is returning garbage, otherwise we are in
> range and this has no affect. We have no idea how much data there is
> if we get a value outside the expected range. 
> 
> As such I'd expect an error print and probably no attempt to carry
> on reading as we have no idea what happened.

For v2 I'll treat an out-of-range count as a hardware error, 
log it, and skip the read rather than carrying on:

    ret = adxl380_get_fifo_entries(st, &fifo_entries);
    if (ret)
            return IRQ_HANDLED;

    if (fifo_entries > ADXL380_FIFO_SAMPLES) {
            dev_err_ratelimited(st->dev,
                                "invalid FIFO entry count %u (max %lu)\n",
                                fifo_entries, ADXL380_FIFO_SAMPLES);
            return IRQ_HANDLED;
    }

    fifo_entries = rounddown(fifo_entries, st->fifo_set_size);
    ret = regmap_noinc_read(st->regmap, ADXL380_FIFO_DATA, &st->fifo_buf,
                            sizeof(*st->fifo_buf) * fifo_entries);

Same for adxl367 (push_fifo_data: dev_err_ratelimited and return true
without reading the FIFO).

I'll send the two as a single series with a cover letter, no Fixes tags.

Let me know if this looks OK to you, or if you'd change anything, and
I'll send the v2 series.

Best regards,
Shengzhuo Wei