From: Jonathan Cameron <jic23@kernel.org>
To: Petre Rodan <petre.rodan@subdimension.ro>
Cc: "Marcelo Schmitt" <marcelo.schmitt1@gmail.com>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Andreas Klinger" <ak@it-klinger.de>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
"Jonathan Cameron" <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH 06/14] iio: pressure: mprls0025pa: memset rx_buf before reading new data
Date: Sun, 21 Dec 2025 18:21:51 +0000 [thread overview]
Message-ID: <20251221182151.288a6da4@jic23-huawei> (raw)
In-Reply-To: <aUZdb9R9BLMfBpLJ@sunspire.home.arpa>
On Sat, 20 Dec 2025 10:25:19 +0200
Petre Rodan <petre.rodan@subdimension.ro> wrote:
> Hello,
>
> On Sat, Dec 20, 2025 at 01:47:05AM -0300, Marcelo Schmitt wrote:
> > On 12/18, Petre Rodan wrote:
> > > Zero out input buffer before reading the new conversion.
> > > Perform this operation in core instead of in the bus specific code.
> > >
> > > Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro>
> > > ---
> > > drivers/iio/pressure/mprls0025pa.c | 2 ++
> > > drivers/iio/pressure/mprls0025pa_i2c.c | 1 -
> > > 2 files changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/iio/pressure/mprls0025pa.c b/drivers/iio/pressure/mprls0025pa.c
> > > index 00b1ff1e50a8..7cc8dd0d8476 100644
> > > --- a/drivers/iio/pressure/mprls0025pa.c
> > > +++ b/drivers/iio/pressure/mprls0025pa.c
> > > @@ -16,6 +16,7 @@
> > > #include <linux/mod_devicetable.h>
> > > #include <linux/module.h>
> > > #include <linux/property.h>
> > > +#include <linux/string.h>
> > > #include <linux/units.h>
> > >
> > > #include <linux/gpio/consumer.h>
> > > @@ -239,6 +240,7 @@ static int mpr_read_pressure(struct mpr_data *data, s32 *press)
> > > }
> > > }
> > >
> > > + memset(data->rx_buf, 0, sizeof(data->rx_buf));
> > This is unusual and I don't think it's needed for the SPI path. Doesn't the I2C
> > subsystem overwrite the rx buffer with what it reads from the device?
>
> I thought it's best practice to ensure that old conversions are not accidentally re-used in case the read operation fell thru the cracks.
> that's exactly why in this particular case the BUSY flag is implemented on the hardware side.
>
> please tell me how a few byte memset() would be detrimental.
We don't normally do this as old data isn't a potential leak of anything
sensitive. However in most drivers this only spills out at all as
a result of say a change in configured channels and is normally harmless
as userspace knows to ignore stuff in the gaps anyway. If there is
another cases here (you mention the busy flag) then add a comment on why
it makes sense. I don't in general want drivers to start doing this as
it is in the fast path and sometimes the memset is non trivial (here it
is probably irrelevant as the buffer is small).
Thanks,
Jonathan
>
> best regards,
> peter
>
> > > ret = data->ops->read(data, MPR_CMD_NOP, MPR_PKT_NOP_LEN);
> > > if (ret < 0)
> > > return ret;
> > > diff --git a/drivers/iio/pressure/mprls0025pa_i2c.c b/drivers/iio/pressure/mprls0025pa_i2c.c
> > > index a0bbc6af9283..0fe8cfe0d7e7 100644
> > > --- a/drivers/iio/pressure/mprls0025pa_i2c.c
> > > +++ b/drivers/iio/pressure/mprls0025pa_i2c.c
> > > @@ -25,7 +25,6 @@ static int mpr_i2c_read(struct mpr_data *data, const u8 unused, const u8 cnt)
> > > if (cnt > MPR_MEASUREMENT_RD_SIZE)
> > > return -EOVERFLOW;
> > >
> > > - memset(data->rx_buf, 0, MPR_MEASUREMENT_RD_SIZE);
> > > ret = i2c_master_recv(client, data->rx_buf, cnt);
> > > if (ret < 0)
> > > return ret;
>
next prev parent reply other threads:[~2025-12-21 18:21 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-18 11:05 [PATCH 00/14] iio: pressure: mprls0025pa: driver code cleanup Petre Rodan
2025-12-18 11:05 ` [PATCH 01/14] iio: pressure: mprls0025pa: Kconfig allow bus selection Petre Rodan
2025-12-20 4:39 ` Marcelo Schmitt
2025-12-21 18:06 ` Jonathan Cameron
2025-12-18 11:05 ` [PATCH 02/14] iio: pressure: mprls0025pa: remove redundant mutex Petre Rodan
2025-12-20 4:45 ` Marcelo Schmitt
2025-12-21 18:13 ` Jonathan Cameron
2025-12-18 11:05 ` [PATCH 03/14] iio: pressure: mprls0025pa: rename buffer variable Petre Rodan
2025-12-18 11:05 ` [PATCH 04/14] iio: pressure: mprls0025pa: introduce tx buffer Petre Rodan
2025-12-20 4:46 ` Marcelo Schmitt
2025-12-18 11:05 ` [PATCH 05/14] iio: pressure: mprls0025pa: zero out spi_transfer struct Petre Rodan
2025-12-21 18:18 ` Jonathan Cameron
2025-12-18 11:05 ` [PATCH 06/14] iio: pressure: mprls0025pa: memset rx_buf before reading new data Petre Rodan
2025-12-20 4:47 ` Marcelo Schmitt
2025-12-20 8:25 ` Petre Rodan
2025-12-21 18:21 ` Jonathan Cameron [this message]
2025-12-22 5:57 ` Petre Rodan
2025-12-22 14:06 ` Marcelo Schmitt
2025-12-27 14:31 ` Jonathan Cameron
2026-01-03 8:00 ` Petre Rodan
2026-01-11 11:44 ` Jonathan Cameron
2025-12-18 11:05 ` [PATCH 07/14] iio: pressure: mprls0025pa: make ops->write function consistent Petre Rodan
2025-12-20 4:49 ` Marcelo Schmitt
2025-12-20 9:59 ` Petre Rodan
2025-12-18 11:05 ` [PATCH 08/14] iio: pressure: mprls0025pa: stricter checks for the status byte Petre Rodan
2025-12-20 4:50 ` Marcelo Schmitt
2025-12-18 11:05 ` [PATCH 09/14] iio: pressure: mprls0025pa: mitigate SPI CS delay violation Petre Rodan
2025-12-20 4:51 ` Marcelo Schmitt
2025-12-20 7:48 ` Petre Rodan
2025-12-22 14:36 ` Marcelo Schmitt
2025-12-18 11:05 ` [PATCH 10/14] iio: pressure: mprls0025pa: cleanup pressure calculation Petre Rodan
2025-12-20 4:53 ` Marcelo Schmitt
2025-12-18 11:05 ` [PATCH 11/14] iio: pressure: mprls0025pa: fix scan_type struct Petre Rodan
2025-12-21 18:34 ` Jonathan Cameron
2025-12-18 11:05 ` [PATCH 12/14] iio: pressure: mprls0025pa: fix interrupt flag Petre Rodan
2025-12-21 18:38 ` Jonathan Cameron
2025-12-22 7:22 ` Petre Rodan
2025-12-27 16:40 ` Jonathan Cameron
2025-12-18 11:05 ` [PATCH 13/14] iio: pressure: mprls0025pa: cleanup includes and forward declarations Petre Rodan
2025-12-20 4:55 ` Marcelo Schmitt
2025-12-18 11:05 ` [PATCH 14/14] iio: pressure: mprls0025pa: add copyright line Petre Rodan
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=20251221182151.288a6da4@jic23-huawei \
--to=jic23@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=ak@it-klinger.de \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.com \
--cc=nuno.sa@analog.com \
--cc=petre.rodan@subdimension.ro \
/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