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 20:55:55 +0100 [thread overview]
Message-ID: <11684f49-dee5-7037-f5c9-5bb8becf114f@axentia.se> (raw)
In-Reply-To: <20180319184850.GB23774@roeck-us.net>
On 2018-03-19 19:48, Guenter Roeck wrote:
> On Mon, Mar 19, 2018 at 05:47:05PM +0100, Peter Rosin wrote:
>> 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".
No need to bother NXP, PCA9848 has already claimed 0-0-0. Sigh.
But while I googled that I found old datasheets for the chips PCA9672
through PCA9675 which use a different layout for the three bytes in
the device id. They have 8 manufacturer bits, 7 category bits, 6 bits
of feature indication and then 3 bits of revision. The top category
bits are zero so it is compatible for NXP chips. But since noone else
has implemented this, it is probably safe, but still a little bit
disturbing.
I also found that NXP apparently uses the same part id (0x100) and die
revision (0) for PCA9570 and PCA9670. That seems odd.
Example old datasheet (2006):
https://www.digchip.com/datasheets/download_datasheet.php?id=1098812&part-number=PCA9672
Cheers,
Peter
next prev parent reply other threads:[~2018-03-19 19:56 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
2018-03-19 19:55 ` Peter Rosin [this message]
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=11684f49-dee5-7037-f5c9-5bb8becf114f@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).