All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Rosin <peda@axentia.se>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	Adrian Fiergolski <adrian.fiergolski@cern.ch>
Subject: Re: [RFC PATCH 1/2] i2c: Add i2c_verify_device_id() to verify device id
Date: Mon, 19 Mar 2018 17:47:05 +0100	[thread overview]
Message-ID: <99548eb6-1958-b2a1-1f2c-ba995f8965ee@axentia.se> (raw)
In-Reply-To: <1521475859-16765-1-git-send-email-linux@roeck-us.net>

On 2018-03-19 17:10, Guenter Roeck wrote:
> Commit dde67eb1beeb ("i2c: add i2c_get_device_id() to get the standard
> I2C device id") added a function to return the standard I2C device ID.
> Use that function to verify the device ID of a given device.

Yeah, you're moving complexity from the driver to the core, reducing
the indentation level and generally make things look neater. In fact,
I thought about adding something like this, but didn't since I only had
the one user.

The only negative is the added line count, but I suppose more drivers
will call this function down the line so it should be a net win in the
long run. There was the PCA9641 chip earlier today e.g., but maybe we
should wait for more device id users?

I wonder when other manufacturers will get on board?

I also wonder if NXP will ever release a chip with part-id 0 and
die-revision 0? If not, an all zero struct i2c_device_identity
could be used instead of manufacturer_id 0xffff and that would
simplify the pca954x driver code a bit more. But I guess we can
never know the answer to that question. And even if we did, the
answer might change later. But it would be nice...

> Cc: Peter Rosin <peda@axentia.se>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> RFC:
> - Compile tested only

Can't test either since I have no chips, but the code looks good.

Adrian have HW, but maybe he's getting tried of testing?

Hmmm, for testing purposes it would be nice if a linux slave device
implemented this. But I don't have HW that supports that either so it
wouldn't help *me* anyway...

Anyway, ack from me for both patches. But maybe I'm the one
picking them up? Wolfram?

Cheers,
Peter

> - Should there also be I2C_DEVICE_PART_ID_ANY to enable maching
>   against all parts from a given manufacturer ?
> 
>  drivers/i2c/i2c-core-base.c | 34 ++++++++++++++++++++++++++++++++++
>  include/linux/i2c.h         |  3 +++
>  2 files changed, 37 insertions(+)
> 
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 16a3b73375a6..4e4372b064f6 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -2009,6 +2009,40 @@ int i2c_get_device_id(const struct i2c_client *client,
>  }
>  EXPORT_SYMBOL_GPL(i2c_get_device_id);
>  
> +/**
> + * i2c_verify_device_id - verify device ID
> + * @client: The device to query
> + * @id: Expected device ID
> + *
> + * Returns negative errno on error, zero on success.
> + */
> +int i2c_verify_device_id(const struct i2c_client *client,
> +			 const struct i2c_device_identity *id)
> +{
> +	struct i2c_device_identity real_id;
> +	int ret;
> +
> +	if (id->manufacturer_id == I2C_DEVICE_ID_NONE)
> +		return 0;
> +
> +	ret = i2c_get_device_id(client, &real_id);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (id->manufacturer_id != real_id.manufacturer_id ||
> +	    id->part_id != real_id.part_id ||
> +	    (id->die_revision != I2C_DEVICE_DIE_REVISION_ANY &&
> +	     id->die_revision != real_id.die_revision)) {
> +		dev_err(&client->dev, "unexpected device id %03x-%03x-%x\n",
> +			real_id.manufacturer_id, real_id.part_id,
> +			real_id.die_revision);
> +		return -ENODEV;
> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(i2c_verify_device_id);
> +
>  /* ----------------------------------------------------
>   * the i2c address scanning function
>   * Will not work for 10-bit addresses!
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 44ad14e016b5..45bae9717ecb 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -189,6 +189,8 @@ i2c_smbus_read_i2c_block_data_or_emulated(const struct i2c_client *client,
>  					  u8 command, u8 length, u8 *values);
>  int i2c_get_device_id(const struct i2c_client *client,
>  		      struct i2c_device_identity *id);
> +int i2c_verify_device_id(const struct i2c_client *client,
> +			 const struct i2c_device_identity *id);
>  #endif /* I2C */
>  
>  /**
> @@ -216,6 +218,7 @@ struct i2c_device_identity {
>  #define I2C_DEVICE_ID_NONE                         0xffff
>  	u16 part_id;
>  	u8 die_revision;
> +#define I2C_DEVICE_DIE_REVISION_ANY		     0xff
>  };
>  
>  enum i2c_alert_protocol {
> 

  parent reply	other threads:[~2018-03-19 16:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19 16:10 [RFC PATCH 1/2] i2c: Add i2c_verify_device_id() to verify device id Guenter Roeck
2018-03-19 16:10 ` [RFC PATCH 2/2] i2c: mux: pca954x: Use API function to verify device ID Guenter Roeck
2018-03-19 16:47 ` Peter Rosin [this message]
2018-03-19 18:48   ` [RFC PATCH 1/2] i2c: Add i2c_verify_device_id() to verify device id Guenter Roeck
2018-03-19 19:55     ` Peter Rosin
2018-03-19 20:50       ` Guenter Roeck
2018-03-19 23:09         ` Peter Rosin
2018-04-08  7:34 ` Wolfram Sang
2018-04-08  9:08   ` Peter Rosin
2018-04-08 10:28     ` Peter Rosin
2018-04-09 18:29   ` Guenter Roeck

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=99548eb6-1958-b2a1-1f2c-ba995f8965ee@axentia.se \
    --to=peda@axentia.se \
    --cc=adrian.fiergolski@cern.ch \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=wsa@the-dreams.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.