linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Peter Rosin <peda@axentia.se>
Cc: Kachalov Anton <mouse@mayc.ru>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: i2c: slave support framework improvements
Date: Thu, 28 Jul 2016 11:15:14 +0200	[thread overview]
Message-ID: <20160728091514.GA17499@katana> (raw)
In-Reply-To: <c72d3c73-30e4-1ee0-f763-99027e35051f@axentia.se>

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


> What I mean is that it is possible to have an i2c bus with some random
> i2c device at e.g. address 0x48, say some eeprom, and then register to
> be a slave device also at address 0x48, e.g. slave-24c02. If there is
> another master on the bus, it cannot sanely use any of these two devices
> at i2c address 0x48 since there is an address conflict.

That is an address conflict, yes. Even for a single-master system. You
need to make sure your slave address is unique on the bus. The kernel
can't really help you with that, because it could only detect address
conflicts if a driver would be attached to a device. If there is no
driver and all communication is done via i2c-dev, for example, then
I can't see a way to detect this.

> Or am I misunderstanding something? In my mind i2c slave support is
> the equivalent of usb gadget support, is it something else?

No, you are correct.


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

  reply	other threads:[~2016-07-28  9:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-23  6:51 i2c: slave support framework improvements Kachalov Anton
2016-07-23 19:51 ` Wolfram Sang
2016-07-25  7:02   ` Kachalov Anton
2016-07-25  7:21     ` Wolfram Sang
2016-07-25  7:47       ` Kachalov Anton
2016-07-25  8:28         ` Wolfram Sang
2016-07-25  9:11           ` Kachalov Anton
2016-07-25  9:41             ` Wolfram Sang
2016-07-25 10:00               ` Kachalov Anton
2016-07-26  9:50                 ` Peter Rosin
2016-07-26 16:51                   ` Kachalov Anton
2016-07-28  6:55                     ` Peter Rosin
2016-07-28  8:25                       ` Peter Rosin
2016-07-28 14:39                       ` Kachalov Anton
2016-07-28  7:41                     ` Wolfram Sang
2016-07-28  8:20                       ` Peter Rosin
2016-07-28  8:39                         ` Wolfram Sang
2016-07-28  8:54                           ` Peter Rosin
2016-07-28  9:15                             ` Wolfram Sang [this message]
2016-07-28  9:39                               ` Peter Rosin
2016-08-01 10:46                                 ` Wolfram Sang
2016-08-15  8:58                                 ` Peter Rosin
2016-08-16 12:12                                   ` Wolfram Sang
2016-08-16 13:33                                     ` Peter Rosin
2016-08-16 13:53                                       ` Kachalov Anton
2016-07-28 14:44                       ` Kachalov Anton

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=20160728091514.GA17499@katana \
    --to=wsa@the-dreams.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mouse@mayc.ru \
    --cc=peda@axentia.se \
    /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).