All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Jean Delvare <jdelvare@suse.de>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	linux-i2c@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH i2c-tools 2/2] tools: restrict all addresses defined by the standard
Date: Sun, 17 Mar 2019 22:36:03 +0100	[thread overview]
Message-ID: <20190317213602.GB1471@kunai> (raw)
In-Reply-To: <20190315142446.5571d5aa@endymion>

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

Hi Jean,

> > The I2C standard reserves addresses 0x03-0x07. Adapt our tools to that.
> 
> I have a different interpretation of the specification. Addresses
> 0x04-0x07 are marked as "Hs-mode master code". They are not explicitly
> marked as "reserved" (although admittedly the table is named "Reserved
> addresses"). My understanding is that HS-mode will "use" these

Yes, my understanding is that the table lists all reserved addresses.

> addresses, which means that you can't use HS-mode _and_ slaves at
> addresses 0x04-0x07 on the same I²C bus segment. I do not read this as
> "non-HS-mode slaves can't use these addresses". But maybe this is just
> me, and also I don't know that much about HS-mode really.

From the spec, section 5.3.2: "Hs-mode master codes are reserved 8-bit
codes, which are not used for slave addressing or other purposes."

> Address 0x03 is indeed reserved, so obviously that this really makes me
> wonder how the original range of 0x03-0x77 was decided. Unfortunately
> the git history doesn't go that far (this range was already used in
> i2cget and i2cdetect at the time i2c-tools was split to its own
> repository).

My theory (only guessing, I didn't check): When introducing Hs-mode, the
I2C designers wanted to have the possibility for 8 Hs-masters. So, they
took addresses 0x04-0x07 (and the R/W bit) which allows for easy logic
in HW. And 0x03 was marked "reserved for future use" because it was in
the middle of those two reserved blocks. That would mean that before
Hs-mode, addresses 0x03-0x77 was in deed possible.

> That being said... In the end it doesn't really matter if addresses
> 0x03-0x07 are considered reserved but "should not", as long as the user
> has an option to override that limitation. Now that such an option is
> consistently available for all i2c tools, I have no objection to being
> more conservative by default.

Cool, I read this as an ack. Thanks!

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-03-17 21:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11 22:33 [PATCH i2c-tools 0/2] tools: improvements to handling restricted addresses Wolfram Sang
2019-03-11 22:33 ` [PATCH i2c-tools 1/2] tools: i2ctransfer: consequently document -a Wolfram Sang
2019-03-15 12:43   ` Jean Delvare
2019-03-17 21:23     ` Wolfram Sang
2019-04-23 21:13   ` Wolfram Sang
2019-03-11 22:33 ` [PATCH i2c-tools 2/2] tools: restrict all addresses defined by the standard Wolfram Sang
2019-03-15 13:24   ` Jean Delvare
2019-03-17 21:36     ` Wolfram Sang [this message]
2019-04-23 21:13   ` Wolfram Sang
2019-03-12 15:50 ` [PATCH i2c-tools 0/2] tools: improvements to handling restricted addresses Niklas Söderlund

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=20190317213602.GB1471@kunai \
    --to=wsa@the-dreams.de \
    --cc=jdelvare@suse.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=wsa+renesas@sang-engineering.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 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.