From: Danielle Costantino <danielle.costantino@gmail.com>
To: Peter Rosin <peda@axentia.se>, MikeB <mabnhdev@gmail.com>
Cc: linux-i2c@vger.kernel.org
Subject: Re: i2c-mux adapter names not unique
Date: Mon, 13 Mar 2017 23:46:32 -0700 [thread overview]
Message-ID: <275e8255-0728-add7-f737-70708f423229@gmail.com> (raw)
In-Reply-To: <152b649c-76c0-9541-4159-43ad77b14469@axentia.se>
[-- Attachment #1.1: Type: text/plain, Size: 2578 bytes --]
Using an adapter id is not a valid and deterministic method for
identifying a i2c bus. The way you can identify what adapter you need to
bind to is by identifying the unique parent device that hosts the
adapter (pci, platform, usb, ....) and identifying a constant parameter
like bus id/ SN/ bus address, using this as your adapter base and
traversing the bus tree based on the channel you need to connect to your
mux. Take a look at the work done with lsi2c and i2cdev.
https://github.com/costad2/i2cdev
Good luck,
Danielle
On 03/13/2017 02:01 PM, Peter Rosin wrote:
> On 2017-03-13 16:05, MikeB wrote:
>> On Mon, Mar 13, 2017 at 10:48 AM, Peter Rosin <peda@axentia.se> wrote:
>>> And why not fix the bad assumption in OpenSwitch instead and kill the
>>> generic problem for every kind of adapter? Limiting yourself to a
>>> band-aid for i2c-mux adapters seems short-sighted and not very helpful
>>> for the next victim of this OpenSwitch problem...
>>>
>>> Note that you do not need two muxing levels to get duplicate names like
>>> this, it's enough with two parallel multiplexers on the root adapter. Or,
>>> of course, two AT91 adapters (or similar, i.e. with a fixed name).
>> If I thought that OpenSwitch's expectation of Linux to name unique
>> adapters uniquely, I would push for a change in OpenSwitch.
>>
>> I personally think Linux's naming convention is a short-sighted and
>> insufficient which is why I came to Linux first.
>>
>> I don't want a short-sighted band-aid which is why I asked the
>> original question.
>>
>> I'll try elsewhere for a solution...
> That's probably best, since if we do change the adapter naming convention
> to something that is unique and stable across reboots (which presumably is
> what is sought, and BTW probably not a trivial problem) some other person
> is going to suffer a regression when OpenSwitch fails to associate with
> the intended adapter after a kernel update. I.e. the very fact that
> OpenSwitch is already using this interface makes it harder to change. And
> who knows, maybe there are other users that will suffer if naming is
> changed?
>
> [Note that I know nothing about OpenSwitch, I'm just deducing the above
> from what you have stated previously]
>
> I'm sorry, but there's not always a simple and convenient answer...
>
> Cheers,
> peda
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
prev parent reply other threads:[~2017-03-14 6:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-13 13:14 i2c-mux adapter names not unique MikeB
2017-03-13 13:34 ` Peter Rosin
2017-03-13 14:00 ` MikeB
2017-03-13 14:48 ` Peter Rosin
2017-03-13 15:05 ` MikeB
2017-03-13 21:01 ` Peter Rosin
2017-03-14 6:46 ` Danielle Costantino [this message]
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=275e8255-0728-add7-f737-70708f423229@gmail.com \
--to=danielle.costantino@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=mabnhdev@gmail.com \
--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).