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

DISCUSSION Guenter Roeck 2 participants 10 messages Nov 16, 2013 – Nov 18, 2013 8 messages not in the archive

Subsystems (3)

I2C subsystem host drivers I2C I2C muxes

lore

Share & tools

lore

Guenter Roeck

author

2013-11-16 18:31 UTC #0 lore raw

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jean Delvare

2013-11-16 20:41 UTC #2 lore raw

Hi Guenter,

Quoted 37 lines · Guenter Roeck

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)

Quoted 5 lines

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.

Quoted 3 lines

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.

Quoted 7 lines

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.

Signature · 1 line

Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jean Delvare

2013-11-16 20:43 UTC #4 lore raw

Oh, I forgot to mention...

Quoted 3 lines · Guenter Roeck

Quoted 2 lines
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.

Signature · 1 line

Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

Guenter Roeck

author

2013-11-17 18:56 UTC #6 lore raw

Quoted 10 lines · Jean Delvare

Oh, I forgot to mention...
Quoted 3 lines · Guenter Roeck
Quoted 2 lines
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

---

Quoted 1 line

From 592db23cd3a769a5369e15260ffa6924acf91ddb Mon Sep 17 00:00:00 2001

From: Guenter Roeck <[email protected]>
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 <[email protected]>

---
 drivers/i2c/i2c-mux.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

drivers/i2c/i2c-mux.c +10 -1

index 797e311..9a49fe9 100644
@@ -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;

Signature · 1 line

1.7.9.7

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jean Delvare

2013-11-17 20:41 UTC #8 lore raw

Hi Guenter,

Quoted 30 lines · Guenter Roeck

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)

Quoted 4 lines

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.

Signature · 1 line

Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

Guenter Roeck

author

2013-11-17 21:13 UTC #10 lore raw

Quoted 33 lines · Jean Delvare

Hi Guenter,
Quoted 30 lines · Guenter Roeck
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)

Quoted 8 lines

Quoted 4 lines
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.

Quoted 5 lines

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

Quoted 8 lines

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.

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jean Delvare

2013-11-18 14:14 UTC #12 lore raw

Hi Guenter,

Quoted 5 lines · Guenter Roeck

Quoted 4 lines · Jean Delvare
Quoted 3 lines · Guenter Roeck
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.

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
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.)

Quoted 2 lines

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.

Quoted 8 lines

Quoted 4 lines
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.

Quoted 4 lines

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.

Signature · 1 line

Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

Guenter Roeck

author

2013-11-18 17:14 UTC #14 lore raw

Quoted 14 lines · Jean Delvare

Hi Guenter,
Quoted 11 lines · Guenter Roeck
Quoted 9 lines · Jean Delvare
Quoted 4 lines · Guenter Roeck
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.

Quoted 7 lines

Quoted 2 lines
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.

Quoted 8 lines

Quoted 2 lines
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.

Quoted 16 lines

Quoted 8 lines
Quoted 4 lines
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.
Quoted 4 lines
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 ?

Quoted 7 lines

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

Guenter Roeck

author

2013-11-17 17:23 UTC #15 lore raw

In reply to a message not in the archive

Quoted 49 lines · Jean Delvare

Hi Guenter,
Quoted 37 lines · Guenter Roeck
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)
Quoted 5 lines
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.

Quoted 8 lines

Quoted 3 lines
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.

Quoted 11 lines

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 ?

Quoted 6 lines

Quoted 6 lines
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.

Quoted 9 lines

Quoted 1 line
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jean Delvare

2013-11-17 20:31 UTC #17 lore raw

Quoted 7 lines · Guenter Roeck

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.

Signature · 1 line

Jean Delvare