Linux I2C development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-iio@vger.kernel.org,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Andi Shyti" <andi.shyti@kernel.org>,
	linux-i2c@vger.kernel.org
Subject: Re: [RESEND PATCH 00/22] IIO: Clean out superfluous I2C checks for single transfers
Date: Thu, 16 Jul 2026 16:20:53 -0700	[thread overview]
Message-ID: <20260716162053.00006f99@oss.qualcomm.com> (raw)
In-Reply-To: <5e9b7479-ed16-48aa-bd4f-26abc09e690e@metafoo.de>

On Thu, 16 Jul 2026 07:55:32 -0700
Lars-Peter Clausen <lars@metafoo.de> wrote:

> On 7/15/26 5:57 PM, Jonathan Cameron wrote:
> > Resend to include linux-iio. Sorry to all who get it twice.
> >
> > This came up in a recent review and I realised I have been giving incorrect
> > review feedback for years. Both i2_master_send() and i2c_master_recv() plus
> > the dma safe variants only ever return either an error or the full buffer
> > size.  Short accesses do not occur.  
> There is actually one interesting corner case. If 
> i2c_transfer_buffer_flags() returns 0 i2c_master_{send,recv}() will also 
> return 0, in which case the updated drivers will now read uninitialized 
> memory. Maybe i2c_master_{send,recv}() needs to be updated to translate 
> that to -EIO.

That's indeed curious (and I'd missed it entirely!).

So ends up being either the master_xfer_atomic() or master_xfer() callbacks
returning 0.  master_xfer_atomic() is novel, it's a union with xfer_atomic()
and no one ever sets it via that union element but given the types are the same
all calls will actually be to xfer_atomic().

Could remove that complexity whilst here but there a bunch of related callbacks
(e.g. master_xfer() in union with xfer() where drivers are still using the old
naming and I'm not sure I want to chase that through various subsystem trees
right now (though for fun - and maybe profit) I had claude work out a series.
Was fun watching it write a semantic patch and spend a while debugging it.
Glad it has as much trouble with coccinelle scripts as the rest of us.
There are still a few hundred instances and I haven't touched all the callbacks,
just this pair.

Anyhow, back to the question of whether they do return 0.  Yup they do :(

https://elixir.bootlin.com/linux/v7.1.3/source/drivers/i2c/busses/i2c-cadence.c#L1153

So any defense against that case would require hardening further up the stack.

+CC Andi and the i2c list.  Would anyone mind a patch to do something like:

 static inline int i2c_master_recv(const struct i2c_client *client,
                                  char *buf, int count)
 {
-       return i2c_transfer_buffer_flags(client, buf, count, I2C_M_RD);
+       int ret;
+
+       ret = i2c_transfer_buffer_flags(client, buf, count, I2C_M_RD);
+       if (ret == 0)
+               return -EIO;
+
+       return ret;
 };

Just to avoid the need for special case checks on ever call from every driver
so that they return ret if negative or else have to check for non 0 return
value and return -EIO or similar.   Maybe somewhere out there is someone using
that 0 to mean something magic, but I doubt it.

Jonathan

`
> >
> > This series (also my first upstream series prepared by poking claude)
> > removes the redundant checks from all IIO drivers.
> >
> > Thanks,
> >
> > Jonathan
> >
> > Jonathan Cameron (22):
> >    iio: adc: ltc2471: Remove redundant i2c_master_recv() length check
> >    iio: adc: ti-ads7138: Remove redundant i2c_master_send() length checks
> >    iio: adc: versal-sysmon: Remove redundant i2c_master_{send,recv}()
> >      length checks
> >    iio: chemical: scd30: Remove redundant i2c_master_{send,recv}() length
> >      checks
> >    iio: chemical: scd4x: Remove redundant i2c_master_{send,recv}() length
> >      checks
> >    iio: chemical: sgp30: Remove redundant i2c_master_recv() length check
> >    iio: chemical: sgp40: Remove redundant i2c_master_recv() length check
> >    iio: chemical: sps30: Remove redundant i2c_master_{send,recv}() length
> >      checks
> >    iio: dac: ad5446: Remove redundant i2c_master_send() length check
> >    iio: dac: ad5696: Remove redundant i2c_master_send() length check
> >    iio: dac: m62332: Remove redundant i2c_master_send() length check
> >    iio: dac: max517: Remove redundant i2c_master_send() length check
> >    iio: dac: max5821: Remove redundant i2c_master_{send,recv}() length
> >      checks
> >    iio: dac: mcp4725: Remove redundant i2c_master_{send,recv}() length
> >      checks
> >    iio: dac: mcp4728: Remove redundant i2c_master_{send,recv}() length
> >      checks
> >    iio: light: lv0104cs: Remove redundant i2c_master_{send,recv}() length
> >      checks
> >    iio: potentiometer: ad5110: Remove redundant i2c_master_{send,recv}()
> >      length checks
> >    iio: pressure: abp2030pa: Remove redundant i2c_master_{send,recv}()
> >      length checks
> >    iio: pressure: adp810: Remove redundant i2c_master_{send,recv}()
> >      length checks
> >    iio: pressure: icp10100: Remove redundant i2c_master_send() length
> >      check
> >    iio: pressure: mprls0025pa: Remove redundant i2c_master_{send,recv}()
> >      length checks
> >    iio: pressure: sdp500: Remove redundant i2c_master_recv() length check
> >
> >   drivers/iio/adc/ltc2471.c              |  2 --
> >   drivers/iio/adc/ti-ads7138.c           |  4 ----
> >   drivers/iio/adc/versal-sysmon-i2c.c    |  6 ------
> >   drivers/iio/chemical/scd30_i2c.c       |  4 ----
> >   drivers/iio/chemical/scd4x.c           |  8 --------
> >   drivers/iio/chemical/sgp30.c           |  2 --
> >   drivers/iio/chemical/sgp40.c           |  4 ----
> >   drivers/iio/chemical/sps30_i2c.c       |  4 ----
> >   drivers/iio/dac/ad5446-i2c.c           |  2 --
> >   drivers/iio/dac/ad5696-i2c.c           |  2 +-
> >   drivers/iio/dac/m62332.c               |  2 --
> >   drivers/iio/dac/max517.c               |  6 ++----
> >   drivers/iio/dac/max5821.c              | 14 ++------------
> >   drivers/iio/dac/mcp4725.c              | 22 ++++++----------------
> >   drivers/iio/dac/mcp4728.c              | 13 +------------
> >   drivers/iio/light/lv0104cs.c           |  4 ----
> >   drivers/iio/potentiometer/ad5110.c     | 18 +++---------------
> >   drivers/iio/pressure/abp2030pa_i2c.c   |  4 ----
> >   drivers/iio/pressure/adp810.c          |  4 ----
> >   drivers/iio/pressure/icp10100.c        |  2 --
> >   drivers/iio/pressure/mprls0025pa_i2c.c |  4 ----
> >   drivers/iio/pressure/sdp500.c          |  4 ----
> >   22 files changed, 15 insertions(+), 120 deletions(-)
> >  
> 


           reply	other threads:[~2026-07-16 23:20 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <5e9b7479-ed16-48aa-bd4f-26abc09e690e@metafoo.de>]

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=20260716162053.00006f99@oss.qualcomm.com \
    --to=jonathan.cameron@oss.qualcomm.com \
    --cc=andi.shyti@kernel.org \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=lars@metafoo.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-iio@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox