From: Guenter Roeck <linux@roeck-us.net>
To: Peter Rosin <peda@axentia.se>
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 11:48:50 -0700 [thread overview]
Message-ID: <20180319184850.GB23774@roeck-us.net> (raw)
In-Reply-To: <99548eb6-1958-b2a1-1f2c-ba995f8965ee@axentia.se>
On Mon, Mar 19, 2018 at 05:47:05PM +0100, Peter Rosin wrote:
> 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?
>
Unfortunately it looks like only NXPs GPIO expanders and i2c muxes support
it, or at least I didn't find any other chips. I figured though that it
would be worth it even if only two drivers (or even one) end up using it.
> I wonder when other manufacturers will get on board?
>
Hah, good question. As mentioned above, I didn't find any.
> 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...
>
That would be nice. You could ask at i2c.support@nxp.com, but I guess
it would always be somewhat risky since the standard doesn't restrict
its use, and some product manager at NXP might decide in the future
that a device ID of 0x00 would be "cool".
Guenter
> > 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 {
> >
>
next prev parent reply other threads:[~2018-03-19 18:48 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 ` [RFC PATCH 1/2] i2c: Add i2c_verify_device_id() to verify device id Peter Rosin
2018-03-19 18:48 ` Guenter Roeck [this message]
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=20180319184850.GB23774@roeck-us.net \
--to=linux@roeck-us.net \
--cc=adrian.fiergolski@cern.ch \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox