Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Salah Triki <salah.triki@gmail.com>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5] iio: humidity: ens210: Fix missing I2C functionality checks
Date: Wed, 6 May 2026 17:19:10 +0100	[thread overview]
Message-ID: <20260506171910.533a3e74@jic23-huawei> (raw)
In-Reply-To: <20260506095835.10112-1-salah.triki@gmail.com>

On Wed,  6 May 2026 10:58:35 +0100
Salah Triki <salah.triki@gmail.com> wrote:

> The ENS210 driver uses SMBus transactions (such as byte, word, and block
> data reads/writes) during the probe and measurement phases. However, the
> initial functionality check only validated a subset of these capabilities,
> which could lead to loading failures on adapters requiring SMBus
> emulation or native-only controllers.
> 
> To ensure compatibility across a wide range of I2C adapters, modify the
> functionality check to verify if the adapter supports the required native
> operations or, failing that, supports the SMBus emulation layer.
> 
> Fixes: c524fbca672e ("iio: humidity: Add support for ENS210")
Are there any known i2c adapters that this actually applies to?
Feels to me like hardening against unexpected results rather than a
real fix.  So probably drop the tag.
> Signed-off-by: Salah Triki <salah.triki@gmail.com>
> ---
> Changes since v4:
> - Fixed the alignment and indentation of the I2C functionality check
>   per Andy's review.
> 
> Changes since v3:
> - Fixed the alignment and indentation of the I2C functionality check
>   per Andy's review.
> 
> Changes since v2:
> - Fixed the alignment and indentation of the I2C functionality check
>   per Maxime's review.
> 
> Changes since v1:
> - Updated the I2C functionality test to check for both required native
>   operations and SMBus emulation (`I2C_FUNC_SMBUS_EMUL`) to prevent
>   loading issues on controllers lacking the emulation flag.
That one is spurious. See below. A device on a bus doesn't care
how these bus operations are occurring so should never be messing
with that define.

> 
>  drivers/iio/humidity/ens210.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/humidity/ens210.c b/drivers/iio/humidity/ens210.c
> index 77418d97f30d..159a3c158c9f 100644
> --- a/drivers/iio/humidity/ens210.c
> +++ b/drivers/iio/humidity/ens210.c
> @@ -204,7 +204,10 @@ static int ens210_probe(struct i2c_client *client)
>  	if (!i2c_check_functionality(client->adapter,
>  				     I2C_FUNC_SMBUS_WRITE_BYTE_DATA |
>  				     I2C_FUNC_SMBUS_WRITE_BYTE |
> -				     I2C_FUNC_SMBUS_READ_I2C_BLOCK)) {
> +				     I2C_FUNC_SMBUS_READ_BYTE_DATA |
> +				     I2C_FUNC_SMBUS_READ_WORD_DATA |
> +				     I2C_FUNC_SMBUS_READ_I2C_BLOCK) &&
Look at definitions of:
I2C_FUNC_SMBUS_BYTE_DATA and I2C_FUNC_SMUS_WORD_DATA

As you might imagine it's common to want the pairs or read and write
so there are macros for it.


> +	    !i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_EMUL)) {
I don't follow the point in this check. See how I2C_FUNC_SMBUS_EMUL is defined
#define I2C_FUNC_SMBUS_EMUL		(I2C_FUNC_SMBUS_QUICK | \
					 I2C_FUNC_SMBUS_BYTE | \
					 I2C_FUNC_SMBUS_BYTE_DATA | \
					 I2C_FUNC_SMBUS_WORD_DATA | \
					 I2C_FUNC_SMBUS_PROC_CALL | \
					 I2C_FUNC_SMBUS_WRITE_BLOCK_DATA | \
					 I2C_FUNC_SMBUS_I2C_BLOCK | \
					 I2C_FUNC_SMBUS_PEC)


So if that passes the earlier one already passed as it's a subset.


>  		return dev_err_probe(&client->dev, -EOPNOTSUPP,
>  			"adapter does not support some i2c transactions\n");
>  	}


      parent reply	other threads:[~2026-05-06 16:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06  9:58 [PATCH v5] iio: humidity: ens210: Fix missing I2C functionality checks Salah Triki
2026-05-06 10:17 ` Joshua Crofts
2026-05-06 16:20   ` Jonathan Cameron
2026-05-06 10:38 ` Andy Shevchenko
2026-05-06 16:19 ` Jonathan Cameron [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=20260506171910.533a3e74@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andy@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=salah.triki@gmail.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