Problem with multiple i2c multiplexers on one bus, and mux bus naming

Problem with multiple i2c multiplexers on one bus, and mux bus naming

[Guenter Roeck]

Hi all,

I have an interesting situation with multiple i2c multiplexers (pca9548) on a single i2c bus.

The problem with this is that multiple mux i2c adapters and up with the same name,
"i2c-N-mux (chan_id M)", where N is the parent bus number and M is the mux channel.
This makes it difficult to identify the actual mux chip serving a mux adapter.

Here is an example with two pca9548 in a system, both connected to i2c bus 2 (which is
itself a mux connected to bus 0).

# grep . */name
i2c-0/name:MPC adapter at 0xfff703000
i2c-1/name:MPC adapter at 0xfff703100
i2c-10/name:i2c-2-mux (chan_id 7)
i2c-11/name:i2c-2-mux (chan_id 0)
i2c-12/name:i2c-2-mux (chan_id 1)
i2c-13/name:i2c-2-mux (chan_id 2)
i2c-14/name:i2c-2-mux (chan_id 3)
i2c-15/name:i2c-2-mux (chan_id 4)
i2c-16/name:i2c-2-mux (chan_id 5)
i2c-17/name:i2c-2-mux (chan_id 6)
i2c-18/name:i2c-2-mux (chan_id 7)
i2c-19/name:i2c-0-mux (chan_id 1)
i2c-2/name:i2c-0-mux (chan_id 0)
i2c-20/name:i2c-0-mux (chan_id 2)
i2c-21/name:i2c-0-mux (chan_id 3)
i2c-22/name:i2c-0-mux (chan_id 4)
i2c-23/name:i2c-0-mux (chan_id 5)
i2c-24/name:i2c-0-mux (chan_id 6)
i2c-25/name:i2c-0-mux (chan_id 7)
i2c-3/name:i2c-2-mux (chan_id 0)
i2c-4/name:i2c-2-mux (chan_id 1)
i2c-5/name:i2c-2-mux (chan_id 2)
i2c-6/name:i2c-2-mux (chan_id 3)
i2c-7/name:i2c-2-mux (chan_id 4)
i2c-8/name:i2c-2-mux (chan_id 5)
i2c-9/name:i2c-2-mux (chan_id 6)

In this example, i2c-3 and i2c-11 share the same name, as do i2c-4 and i2c-12 and so on.
If I now have, say, temperature sensors on address 0x49 on both i2c-3 and i2c-11,
I have no means to determine the location of those temperature sensors. Sure,
I can figure it out manually, but if something changes in bus numbering I have
to start all over again.

Would it be possible to add the chip address into the mux name ? Something like
	i2c-N-XX-M-mux
where N is the parent bus number, XX is the mux i2c address, and M is the mux channel.
I understand this may require an API change, as the mux chip is not necessarily an i2c
and the i2c-mux core code doesn't really care what the mux chip is. So maybe there is
a different/better solution; ultimately, what I need is really a means to identify
the mux chip if there are multiple muxes on a single i2c bus. And, of course, unique
i2c adapter names would be nice to have as well.

Is there another way to identify the mux adapter chip through sysfs in this situation ?

Thanks,
Guenter

Re: Problem with multiple i2c multiplexers on one bus, and mux bus naming

[Jean Delvare]

Hi Guenter,

On Sat, 16 Nov 2013 10:31:00 -0800, Guenter Roeck wrote:
> I have an interesting situation with multiple i2c multiplexers (pca9548) on a single i2c bus.
> 
> The problem with this is that multiple mux i2c adapters and up with the same name,
> "i2c-N-mux (chan_id M)", where N is the parent bus number and M is the mux channel.
> This makes it difficult to identify the actual mux chip serving a mux adapter.
> 
> Here is an example with two pca9548 in a system, both connected to i2c bus 2 (which is
> itself a mux connected to bus 0).
> 
> # grep . */name
> i2c-0/name:MPC adapter at 0xfff703000
> i2c-1/name:MPC adapter at 0xfff703100
> i2c-10/name:i2c-2-mux (chan_id 7)
> i2c-11/name:i2c-2-mux (chan_id 0)
> i2c-12/name:i2c-2-mux (chan_id 1)
> i2c-13/name:i2c-2-mux (chan_id 2)
> i2c-14/name:i2c-2-mux (chan_id 3)
> i2c-15/name:i2c-2-mux (chan_id 4)
> i2c-16/name:i2c-2-mux (chan_id 5)
> i2c-17/name:i2c-2-mux (chan_id 6)
> i2c-18/name:i2c-2-mux (chan_id 7)
> i2c-19/name:i2c-0-mux (chan_id 1)
> i2c-2/name:i2c-0-mux (chan_id 0)
> i2c-20/name:i2c-0-mux (chan_id 2)
> i2c-21/name:i2c-0-mux (chan_id 3)
> i2c-22/name:i2c-0-mux (chan_id 4)
> i2c-23/name:i2c-0-mux (chan_id 5)
> i2c-24/name:i2c-0-mux (chan_id 6)
> i2c-25/name:i2c-0-mux (chan_id 7)
> i2c-3/name:i2c-2-mux (chan_id 0)
> i2c-4/name:i2c-2-mux (chan_id 1)
> i2c-5/name:i2c-2-mux (chan_id 2)
> i2c-6/name:i2c-2-mux (chan_id 3)
> i2c-7/name:i2c-2-mux (chan_id 4)
> i2c-8/name:i2c-2-mux (chan_id 5)
> i2c-9/name:i2c-2-mux (chan_id 6)
> 
> In this example, i2c-3 and i2c-11 share the same name, as do i2c-4 and i2c-12 and so on.
> If I now have, say, temperature sensors on address 0x49 on both i2c-3 and i2c-11,
> I have no means to determine the location of those temperature sensors. Sure,
> I can figure it out manually, but if something changes in bus numbering I have
> to start all over again.

I am aware of the problem. I did mention it when the i2c-mux code was
originally submitted, but apparently nobody paid attention.

> Would it be possible to add the chip address into the mux name ? Something like
> 	i2c-N-XX-M-mux
> where N is the parent bus number, XX is the mux i2c address, and M is the mux channel.

That would partly solve the problem indeed. "i2c-N-mux-XX (chan_id M)"
would be a slightly less intrusive change but functionally equivalent
to your proposal.

I say "partly" because these new names would still not be unique
identifiers. You still have to check which bus is "N" in order to tell
what the segment really is. Unfortunately, coming up with a naming
scheme that includes the root bus name and works with arbitrary depths
of multiplexing isn't easy. We currently have a static limit to the name length
of i2c_adapters (47 chars) and I'm not sure we want to change that.
Tools such as i2cdetect only have room for 32 characters, lower than
the current maximum. OTOH libsensors, for example, needs truly unique
bus names for per-chip configuration, and that doesn't work with the
current scheme nor the scheme you proposed.

> I understand this may require an API change, as the mux chip is not necessarily an i2c
> and the i2c-mux core code doesn't really care what the mux chip is. So maybe there is
> a different/better solution; ultimately, what I need is really a means to identify
> the mux chip if there are multiple muxes on a single i2c bus. And, of course, unique
> i2c adapter names would be nice to have as well.
> 
> Is there another way to identify the mux adapter chip through sysfs in this situation ?

No reliable way I can think of. You can only suppose that in most cases
the i2c bus segments will be created in the same order as the I2C slave
address of the multiplexer they are branched from. So i2c-3 would be on
the mux with the lower I2C address and i2c-11 on the mux with the
higher I2C address. But that's only a guess and that may become wrong
for various reasons.

-- 
Jean Delvare

Re: Problem with multiple i2c multiplexers on one bus, and mux bus naming

[Jean Delvare]

Oh, I forgot to mention...

> On Sat, 16 Nov 2013 10:31:00 -0800, Guenter Roeck wrote:
> > I understand this may require an API change, as the mux chip is not necessarily an i2c
> > and the i2c-mux core code doesn't really care what the mux chip is.

Such an API change would be perfectly acceptable. Mux drivers are few
and i2c-mux is still relatively new. Unique i2c adapter name is
something important, definitely worth changing the API if needed.

-- 
Jean Delvare

Re: Problem with multiple i2c multiplexers on one bus, and mux bus naming

[Guenter Roeck]

On 11/16/2013 12:41 PM, Jean Delvare wrote:
> Hi Guenter,
>
> On Sat, 16 Nov 2013 10:31:00 -0800, Guenter Roeck wrote:
>> I have an interesting situation with multiple i2c multiplexers (pca9548) on a single i2c bus.
>>
>> The problem with this is that multiple mux i2c adapters and up with the same name,
>> "i2c-N-mux (chan_id M)", where N is the parent bus number and M is the mux channel.
>> This makes it difficult to identify the actual mux chip serving a mux adapter.
>>
>> Here is an example with two pca9548 in a system, both connected to i2c bus 2 (which is
>> itself a mux connected to bus 0).
>>
>> # grep . */name
>> i2c-0/name:MPC adapter at 0xfff703000
>> i2c-1/name:MPC adapter at 0xfff703100
>> i2c-10/name:i2c-2-mux (chan_id 7)
>> i2c-11/name:i2c-2-mux (chan_id 0)
>> i2c-12/name:i2c-2-mux (chan_id 1)
>> i2c-13/name:i2c-2-mux (chan_id 2)
>> i2c-14/name:i2c-2-mux (chan_id 3)
>> i2c-15/name:i2c-2-mux (chan_id 4)
>> i2c-16/name:i2c-2-mux (chan_id 5)
>> i2c-17/name:i2c-2-mux (chan_id 6)
>> i2c-18/name:i2c-2-mux (chan_id 7)
>> i2c-19/name:i2c-0-mux (chan_id 1)
>> i2c-2/name:i2c-0-mux (chan_id 0)
>> i2c-20/name:i2c-0-mux (chan_id 2)
>> i2c-21/name:i2c-0-mux (chan_id 3)
>> i2c-22/name:i2c-0-mux (chan_id 4)
>> i2c-23/name:i2c-0-mux (chan_id 5)
>> i2c-24/name:i2c-0-mux (chan_id 6)
>> i2c-25/name:i2c-0-mux (chan_id 7)
>> i2c-3/name:i2c-2-mux (chan_id 0)
>> i2c-4/name:i2c-2-mux (chan_id 1)
>> i2c-5/name:i2c-2-mux (chan_id 2)
>> i2c-6/name:i2c-2-mux (chan_id 3)
>> i2c-7/name:i2c-2-mux (chan_id 4)
>> i2c-8/name:i2c-2-mux (chan_id 5)
>> i2c-9/name:i2c-2-mux (chan_id 6)
>>
>> In this example, i2c-3 and i2c-11 share the same name, as do i2c-4 and i2c-12 and so on.
>> If I now have, say, temperature sensors on address 0x49 on both i2c-3 and i2c-11,
>> I have no means to determine the location of those temperature sensors. Sure,
>> I can figure it out manually, but if something changes in bus numbering I have
>> to start all over again.
>
> I am aware of the problem. I did mention it when the i2c-mux code was
> originally submitted, but apparently nobody paid attention.
>
>> Would it be possible to add the chip address into the mux name ? Something like
>> 	i2c-N-XX-M-mux
>> where N is the parent bus number, XX is the mux i2c address, and M is the mux channel.
>
> That would partly solve the problem indeed. "i2c-N-mux-XX (chan_id M)"
> would be a slightly less intrusive change but functionally equivalent
> to your proposal.
>
Yes, that would be ok as well and might be less invasive for name scanning code.

> I say "partly" because these new names would still not be unique
> identifiers. You still have to check which bus is "N" in order to tell
> what the segment really is. Unfortunately, coming up with a naming
> scheme that includes the root bus name and works with arbitrary depths
> of multiplexing isn't easy. We currently have a static limit to the name length
> of i2c_adapters (47 chars) and I'm not sure we want to change that.
> Tools such as i2cdetect only have room for 32 characters, lower than
> the current maximum. OTOH libsensors, for example, needs truly unique
> bus names for per-chip configuration, and that doesn't work with the
> current scheme nor the scheme you proposed.
>
I think it would still be unique name, as long as the parent adapter number
is well defined (which it hopefully is). At least with the change I can
1) identify the mux and 2) walk back in the tree of i2c adapters to find
the root. Using above example, I know that i2c-2-mux (chan_id 0) is on bus 2.
Bus 2 is i2c-0-mux (chan_id 0), so I know it is connected to bus 0.

Am I missing something ?

>> I understand this may require an API change, as the mux chip is not necessarily an i2c
>> and the i2c-mux core code doesn't really care what the mux chip is. So maybe there is
>> a different/better solution; ultimately, what I need is really a means to identify
>> the mux chip if there are multiple muxes on a single i2c bus. And, of course, unique
>> i2c adapter names would be nice to have as well.
>>
>> Is there another way to identify the mux adapter chip through sysfs in this situation ?
>
> No reliable way I can think of. You can only suppose that in most cases
> the i2c bus segments will be created in the same order as the I2C slave
> address of the multiplexer they are branched from. So i2c-3 would be on
> the mux with the lower I2C address and i2c-11 on the mux with the
> higher I2C address. But that's only a guess and that may become wrong
> for various reasons.
>
Yes, it falls apart if part of the i2c chain is inserted and removed dynamically.
We have tried using fixed bus numbers, but that has its own problems.

Thanks,
Guenter

Re: Problem with multiple i2c multiplexers on one bus, and mux bus naming

[Guenter Roeck]

On Sat, Nov 16, 2013 at 09:43:18PM +0100, Jean Delvare wrote:
> Oh, I forgot to mention...
> 
> > On Sat, 16 Nov 2013 10:31:00 -0800, Guenter Roeck wrote:
> > > I understand this may require an API change, as the mux chip is not necessarily an i2c
> > > and the i2c-mux core code doesn't really care what the mux chip is.
> 
> Such an API change would be perfectly acceptable. Mux drivers are few
> and i2c-mux is still relatively new. Unique i2c adapter name is
> something important, definitely worth changing the API if needed.
> 
I managed to do it without changing the API; see patch below.
This results in

i2c-0/name:MPC adapter at 0xfff703000
i2c-1/name:MPC adapter at 0xfff703100
i2c-10/name:i2c-2-mux-75 (chan_id 7)
i2c-11/name:i2c-2-mux-76 (chan_id 0)
i2c-12/name:i2c-2-mux-76 (chan_id 1)
i2c-13/name:i2c-2-mux-76 (chan_id 2)
i2c-14/name:i2c-2-mux-76 (chan_id 3)
i2c-15/name:i2c-2-mux-76 (chan_id 4)
i2c-16/name:i2c-2-mux-76 (chan_id 5)
i2c-17/name:i2c-2-mux-76 (chan_id 6)
i2c-18/name:i2c-2-mux-76 (chan_id 7)
i2c-19/name:i2c-0-mux (chan_id 1)
i2c-2/name:i2c-0-mux (chan_id 0)
i2c-20/name:i2c-0-mux (chan_id 2)
i2c-21/name:i2c-0-mux (chan_id 3)
i2c-22/name:i2c-0-mux (chan_id 4)
i2c-23/name:i2c-0-mux (chan_id 5)
i2c-24/name:i2c-0-mux (chan_id 6)
i2c-25/name:i2c-0-mux (chan_id 7)
i2c-3/name:i2c-2-mux-75 (chan_id 0)
i2c-4/name:i2c-2-mux-75 (chan_id 1)
i2c-5/name:i2c-2-mux-75 (chan_id 2)
i2c-6/name:i2c-2-mux-75 (chan_id 3)
i2c-7/name:i2c-2-mux-75 (chan_id 4)
i2c-8/name:i2c-2-mux-75 (chan_id 5)
i2c-9/name:i2c-2-mux-75 (chan_id 6)

This retains the old mux name if the mux is not an i2c device, and adds
the i2c device address if it is. This solves the problem for me.

Comments ?

Thanks,
Guenter

---

>From 592db23cd3a769a5369e15260ffa6924acf91ddb Mon Sep 17 00:00:00 2001
From: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
Date: Sun, 17 Nov 2013 09:25:21 -0800
Subject: [PATCH] i2c: mux: Create unique i2c mux name if the parent is an i2c
 device

If an i2c mux parent is an i2c device, there can be more than one such device on
a single i2c bus. The current mux naming scheme does not take this into account
and creates multiple i2c adapters with the same name.

Expand the mux adapter name to include the i2c client's I2C address to solve the
problem.

Signed-off-by: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
---
 drivers/i2c/i2c-mux.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 797e311..9a49fe9 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -109,7 +109,9 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent,
 				int (*deselect) (struct i2c_adapter *,
 						 void *, u32))
 {
+	struct i2c_client *client = i2c_verify_client(mux_dev);
 	struct i2c_mux_priv *priv;
+	char client_addr[8];
 	int ret;
 
 	priv = kzalloc(sizeof(struct i2c_mux_priv), GFP_KERNEL);
@@ -133,8 +135,15 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent,
 	priv->algo.functionality = i2c_mux_functionality;
 
 	/* Now fill out new adapter structure */
+	if (client)
+		scnprintf(client_addr, sizeof(client_addr), "-%02x",
+			  client->addr);
+	else
+		client_addr[0] = '\0';
+
 	snprintf(priv->adap.name, sizeof(priv->adap.name),
-		 "i2c-%d-mux (chan_id %d)", i2c_adapter_id(parent), chan_id);
+		 "i2c-%d-mux%s (chan_id %d)", i2c_adapter_id(parent),
+		 client_addr, chan_id);
 	priv->adap.owner = THIS_MODULE;
 	priv->adap.algo = &priv->algo;
 	priv->adap.algo_data = priv;
-- 
1.7.9.7

Re: Problem with multiple i2c multiplexers on one bus, and mux bus naming

[Jean Delvare]

On Sun, 17 Nov 2013 09:23:32 -0800, Guenter Roeck wrote:
> I think it would still be unique name, as long as the parent adapter number
> is well defined (which it hopefully is). At least with the change I can
> 1) identify the mux and 2) walk back in the tree of i2c adapters to find
> the root. Using above example, I know that i2c-2-mux (chan_id 0) is on bus 2.
> Bus 2 is i2c-0-mux (chan_id 0), so I know it is connected to bus 0.
> 
> Am I missing something ?

You're not missing anything. It is indeed possible to "resolve" the
name to uniqueness. My only concern is that someone has to do it, and
for example libsensors currently doesn't. The configuration file parser
would have to be extended to do that resolution in order to fully
support chip-instance-specific configuration statements on multiplexed
topologies. Same goes for i2c-tools: normally you can pass the bus by
name instead of number, but with the need to resolve the name of muxed
branches, this no longer works.

I'm not saying this is a blocker problem, just something to keep in
mind.

-- 
Jean Delvare

Re: Problem with multiple i2c multiplexers on one bus, and mux bus naming

[Jean Delvare]

Hi Guenter,

On Sun, 17 Nov 2013 10:56:24 -0800, Guenter Roeck wrote:
> I managed to do it without changing the API; see patch below.
> This results in
> 
> i2c-0/name:MPC adapter at 0xfff703000
> i2c-1/name:MPC adapter at 0xfff703100
> i2c-10/name:i2c-2-mux-75 (chan_id 7)
> i2c-11/name:i2c-2-mux-76 (chan_id 0)
> i2c-12/name:i2c-2-mux-76 (chan_id 1)
> i2c-13/name:i2c-2-mux-76 (chan_id 2)
> i2c-14/name:i2c-2-mux-76 (chan_id 3)
> i2c-15/name:i2c-2-mux-76 (chan_id 4)
> i2c-16/name:i2c-2-mux-76 (chan_id 5)
> i2c-17/name:i2c-2-mux-76 (chan_id 6)
> i2c-18/name:i2c-2-mux-76 (chan_id 7)
> i2c-19/name:i2c-0-mux (chan_id 1)
> i2c-2/name:i2c-0-mux (chan_id 0)
> i2c-20/name:i2c-0-mux (chan_id 2)
> i2c-21/name:i2c-0-mux (chan_id 3)
> i2c-22/name:i2c-0-mux (chan_id 4)
> i2c-23/name:i2c-0-mux (chan_id 5)
> i2c-24/name:i2c-0-mux (chan_id 6)
> i2c-25/name:i2c-0-mux (chan_id 7)
> i2c-3/name:i2c-2-mux-75 (chan_id 0)
> i2c-4/name:i2c-2-mux-75 (chan_id 1)
> i2c-5/name:i2c-2-mux-75 (chan_id 2)
> i2c-6/name:i2c-2-mux-75 (chan_id 3)
> i2c-7/name:i2c-2-mux-75 (chan_id 4)
> i2c-8/name:i2c-2-mux-75 (chan_id 5)
> i2c-9/name:i2c-2-mux-75 (chan_id 6)
> 
> This retains the old mux name if the mux is not an i2c device, and adds
> the i2c device address if it is. This solves the problem for me.
> 
> Comments ?

This "for me" worries me a bit. You basically restored the uniqueness
for the multiple I2C-based multiplexer case. But for multiple
GPIO-based multiplexers, for example, the name confusion still exists.
If we are going to address this problem, I believe we should do so in a
way which doesn't need revisiting in a couple months. You are changing
adapter names people or tools may be relying on, we really don't want
to do this too often.

We could use the first GPIO pin number as the unique identifier for the
GPIO case. However I2C addresses and GPIO pin numbers could collide...
So we'd need separate name spaces, too.

I agree this makes things even more complicated than they are right
now, but I can't think of any other way that would be both robust and
durable.

-- 
Jean Delvare

Re: Problem with multiple i2c multiplexers on one bus, and mux bus naming

[Guenter Roeck]

On 11/17/2013 12:41 PM, Jean Delvare wrote:
> Hi Guenter,
>
> On Sun, 17 Nov 2013 10:56:24 -0800, Guenter Roeck wrote:
>> I managed to do it without changing the API; see patch below.
>> This results in
>>
>> i2c-0/name:MPC adapter at 0xfff703000
>> i2c-1/name:MPC adapter at 0xfff703100
>> i2c-10/name:i2c-2-mux-75 (chan_id 7)
>> i2c-11/name:i2c-2-mux-76 (chan_id 0)
>> i2c-12/name:i2c-2-mux-76 (chan_id 1)
>> i2c-13/name:i2c-2-mux-76 (chan_id 2)
>> i2c-14/name:i2c-2-mux-76 (chan_id 3)
>> i2c-15/name:i2c-2-mux-76 (chan_id 4)
>> i2c-16/name:i2c-2-mux-76 (chan_id 5)
>> i2c-17/name:i2c-2-mux-76 (chan_id 6)
>> i2c-18/name:i2c-2-mux-76 (chan_id 7)
>> i2c-19/name:i2c-0-mux (chan_id 1)
>> i2c-2/name:i2c-0-mux (chan_id 0)
>> i2c-20/name:i2c-0-mux (chan_id 2)
>> i2c-21/name:i2c-0-mux (chan_id 3)
>> i2c-22/name:i2c-0-mux (chan_id 4)
>> i2c-23/name:i2c-0-mux (chan_id 5)
>> i2c-24/name:i2c-0-mux (chan_id 6)
>> i2c-25/name:i2c-0-mux (chan_id 7)
>> i2c-3/name:i2c-2-mux-75 (chan_id 0)
>> i2c-4/name:i2c-2-mux-75 (chan_id 1)
>> i2c-5/name:i2c-2-mux-75 (chan_id 2)
>> i2c-6/name:i2c-2-mux-75 (chan_id 3)
>> i2c-7/name:i2c-2-mux-75 (chan_id 4)
>> i2c-8/name:i2c-2-mux-75 (chan_id 5)
>> i2c-9/name:i2c-2-mux-75 (chan_id 6)
>>
>> This retains the old mux name if the mux is not an i2c device, and adds
>> the i2c device address if it is. This solves the problem for me.
>>
>> Comments ?
>
> This "for me" worries me a bit. You basically restored the uniqueness
> for the multiple I2C-based multiplexer case. But for multiple
> GPIO-based multiplexers, for example, the name confusion still exists.

Only if some genius connects multiple separate gpio based multiplexers
to the same bus. In practice, though, that can be modeled as single
gpio mux with more pins, so I didn't think that is that much of a problem.

> If we are going to address this problem, I believe we should do so in a
> way which doesn't need revisiting in a couple months. You are changing
> adapter names people or tools may be relying on, we really don't want
> to do this too often.
>
Good point. One possible solution might be to add the mux type into the name.
	i2c-2-mux-i2c-76 (chan_id 0)
	i2c-2-mux-gpio-77 (chan_id 0)

We could add an additional parameter to the API, such as
	const char *qualifier
to provide the "i2c-76" or "gpio-77" string. If the qualifier is NULL,
the name would revert to the old naming scheme. Would that make sense ?

Thanks,
Guenter

> We could use the first GPIO pin number as the unique identifier for the
> GPIO case. However I2C addresses and GPIO pin numbers could collide...
> So we'd need separate name spaces, too.
>
> I agree this makes things even more complicated than they are right
> now, but I can't think of any other way that would be both robust and
> durable.
>

Re: Problem with multiple i2c multiplexers on one bus, and mux bus naming

[Jean Delvare]

Hi Guenter,

On Sun, 17 Nov 2013 13:13:43 -0800, Guenter Roeck wrote:
> On 11/17/2013 12:41 PM, Jean Delvare wrote:
> > On Sun, 17 Nov 2013 10:56:24 -0800, Guenter Roeck wrote:
> >> This retains the old mux name if the mux is not an i2c device, and adds
> >> the i2c device address if it is. This solves the problem for me.
> >>
> >> Comments ?
> >
> > This "for me" worries me a bit. You basically restored the uniqueness
> > for the multiple I2C-based multiplexer case. But for multiple
> > GPIO-based multiplexers, for example, the name confusion still exists.
> 
> Only if some genius connects multiple separate gpio based multiplexers
> to the same bus.

This is totally possible, for a variety of reasons, including physical
location of the GPIO pins and bus segment ends, but also economical
(using the same chips on several boards.)

> In practice, though, that can be modeled as single
> gpio mux with more pins, so I didn't think that is that much of a problem.

I admit I had not considered this. But would it work if the different
GPIO pins are on different chips (say south bridge and Super-I/O for
example)? The i2c-mux-gpio driver assumes a single chip, at least when
passed by name.

> > If we are going to address this problem, I believe we should do so in a
> > way which doesn't need revisiting in a couple months. You are changing
> > adapter names people or tools may be relying on, we really don't want
> > to do this too often.
>
> Good point. One possible solution might be to add the mux type into the name.
> 	i2c-2-mux-i2c-76 (chan_id 0)
> 	i2c-2-mux-gpio-77 (chan_id 0)

Yes, that's pretty much what I had in mind.

> We could add an additional parameter to the API, such as
> 	const char *qualifier
> to provide the "i2c-76" or "gpio-77" string. If the qualifier is NULL,
> the name would revert to the old naming scheme. Would that make sense ?

Yes, although your first draft gave me some hope that i2c-mux could do
some magic to guess the type and identifier automatically. But maybe
it's not that clean to have to touch i2c-mux for every new i2c-mux-*
driver. Not that I expect too many of them... so it's mostly a matter
of principle. An explicit qualifier as you suggest above might be
cleaner.

-- 
Jean Delvare

Re: Problem with multiple i2c multiplexers on one bus, and mux bus naming

[Guenter Roeck]

On Mon, Nov 18, 2013 at 03:14:41PM +0100, Jean Delvare wrote:
> Hi Guenter,
> 
> On Sun, 17 Nov 2013 13:13:43 -0800, Guenter Roeck wrote:
> > On 11/17/2013 12:41 PM, Jean Delvare wrote:
> > > On Sun, 17 Nov 2013 10:56:24 -0800, Guenter Roeck wrote:
> > >> This retains the old mux name if the mux is not an i2c device, and adds
> > >> the i2c device address if it is. This solves the problem for me.
> > >>
> > >> Comments ?
> > >
> > > This "for me" worries me a bit. You basically restored the uniqueness
> > > for the multiple I2C-based multiplexer case. But for multiple
> > > GPIO-based multiplexers, for example, the name confusion still exists.
> > 
> > Only if some genius connects multiple separate gpio based multiplexers
> > to the same bus.
> 
> This is totally possible, for a variety of reasons, including physical
> location of the GPIO pins and bus segment ends, but also economical
> (using the same chips on several boards.)
> 
Ok.

> > In practice, though, that can be modeled as single
> > gpio mux with more pins, so I didn't think that is that much of a problem.
> 
> I admit I had not considered this. But would it work if the different
> GPIO pins are on different chips (say south bridge and Super-I/O for
> example)? The i2c-mux-gpio driver assumes a single chip, at least when
> passed by name.
> 
... so you could or should not pass a name if that is the case.

> > > If we are going to address this problem, I believe we should do so in a
> > > way which doesn't need revisiting in a couple months. You are changing
> > > adapter names people or tools may be relying on, we really don't want
> > > to do this too often.
> >
> > Good point. One possible solution might be to add the mux type into the name.
> > 	i2c-2-mux-i2c-76 (chan_id 0)
> > 	i2c-2-mux-gpio-77 (chan_id 0)
> 
> Yes, that's pretty much what I had in mind.
> 
> > We could add an additional parameter to the API, such as
> > 	const char *qualifier
> > to provide the "i2c-76" or "gpio-77" string. If the qualifier is NULL,
> > the name would revert to the old naming scheme. Would that make sense ?
> 
> Yes, although your first draft gave me some hope that i2c-mux could do
> some magic to guess the type and identifier automatically. But maybe
> it's not that clean to have to touch i2c-mux for every new i2c-mux-*
> driver. Not that I expect too many of them... so it's mostly a matter
> of principle. An explicit qualifier as you suggest above might be
> cleaner.
> 
Another option would be to use the patch I provided, except to create
names such as i2c-2-mux-i2c-76. The API change could then be added later
if/as needed.

But, yes, an API change would be cleaner. Before I submit a "final" patch,
it would be great to get feedback and direcetion from Wolfram ... after all,
he'll have to approve it at the end.

Thanks,
Guenter