The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Shengzhuo Wei" <me@cherr.cc>
To: "Jonathan Cameron" <jic23@kernel.org>
Cc: "Shengzhuo Wei" <me@cherr.cc>, "Nuno Sá" <nuno.sa@analog.com>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Ramona Gradinariu" <ramona.gradinariu@analog.com>,
	"Antoniu Miclaus" <antoniu.miclaus@analog.com>,
	"David Lechner" <dlechner@baylibre.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	linux@analog.com, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] iio: accel: adxl380: clamp FIFO sample count
Date: Mon, 10 Aug 2026 13:06:01 +0800	[thread overview]
Message-ID: <anlcOa5tkTUN9EQr@nobug> (raw)
In-Reply-To: <20260810002808.76ffd95a@jic23-huawei>

在 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

      reply	other threads:[~2026-08-10  5:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-08 22:18 [PATCH] iio: accel: adxl380: clamp FIFO sample count Shengzhuo Wei
2026-08-09 23:28 ` Jonathan Cameron
2026-08-10  5:06   ` Shengzhuo Wei [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=anlcOa5tkTUN9EQr@nobug \
    --to=me@cherr.cc \
    --cc=Michael.Hennerich@analog.com \
    --cc=andy@kernel.org \
    --cc=antoniu.miclaus@analog.com \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@analog.com \
    --cc=nuno.sa@analog.com \
    --cc=ramona.gradinariu@analog.com \
    --cc=stable@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox