Skip to contentSkip to conversation

Retry count for i2c-mux

PATCH New Elie De Brauwer 2 participants 6 messages Dec 8, 2013 – Dec 12, 2013 3 messages not in the archive

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Retry count for i2c-mux

Wolfram,

I bumped into an issue where I needed to rely on the retry mechanism. I have a master controller and some muxed busses. However when testing I observed that the retry worked when using the bus attached to the master controller directly used the retry count set but the same behavior failed on the muxed bus since the retry count there was zero. The root cause was in the creationg of the muxed busses which have their own struct i2c_adapter which gets kzalloc in i2c_add_mux_adapter(), my (trivial) patch to this problem is to also copy the retries field of the parent to the i2c_adapter of the muxed bus.

(Obviously the retry count could be set by the I2C_RETRIES ioctl, but I'd still think it's sensible to have a system initialized in a sane state).

my 2 cents
E.

Elie De Brauwer (1):
i2c-mux: Inherit retry count from parent controller for muxed bus.

 drivers/i2c/i2c-mux.c |    1 +
 1 file changed, 1 insertion(+)
Signature · 1 line
1.7.10.4

A message that is not in the archive (sent off-list or not yet received): 1386499701-5522-1-git-send-email-eliedebrauwer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

#2 lore raw

PATCH 1/1 i2c-mux: Inherit retry count from parent controller for muxed bus.

Today if a mux i2c bus gets created the default retry count of the muxed bus is zero. Hence it it possible that you end up with a situation where the parent controller sets a default retry count which gets applied and used while the muxed bus (using the same controller) has a default retry count of zero. This can be solved by initializing the retry count of the muxed bus by the retry count of the parent at creation time.

---
 drivers/i2c/i2c-mux.c |    1 +
 1 file changed, 1 insertion(+)
drivers/i2c/i2c-mux.c +1 -0
index 797e311..1f879d8 100644
@@ -139,6 +139,7 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent,
 	priv->adap.algo = &priv->algo;
 	priv->adap.algo_data = priv;
 	priv->adap.dev.parent = &parent->dev;
+	priv->adap.retries = parent->retries;
 
 	/* Sanity check on class */
 	if (i2c_mux_parent_classes(parent) & class)
Signature · 1 line
1.7.10.4

A message that is not in the archive (sent off-list or not yet received): 1386499701-5522-2-git-send-email-eliedebrauwer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

#4 lore raw

Re: [PATCH] i2c-mux: Inherit retry count from parent controller for muxed bus.

Quoted 9 lines · Elie De Brauwer

Today if a mux i2c bus gets created the default retry count of the muxed bus is zero. Hence it it possible that you end up with a situation where the parent controller sets a default retry count which gets applied and used while the muxed bus (using the same controller) has a default retry count of zero. This can be solved by initializing the retry count of the muxed bus by the retry count of the parent at creation time.

Makes sense. Have you checked the timeout value, too?

#5 lore raw

Re: [PATCH] i2c-mux: Inherit retry count from parent controller for muxed bus.

Quoted 9 lines · Wolfram Sang
Quoted 8 lines · Elie De Brauwer

Today if a mux i2c bus gets created the default retry count of the muxed bus is zero. Hence it it possible that you end up with a situation where the parent controller sets a default retry count which gets applied and used while the muxed bus (using the same controller) has a default retry count of zero. This can be solved by initializing the retry count of the muxed bus by the retry count of the parent at creation time.

Quoted 4 lines
Quoted 1 line

Makes sense. Have you checked the timeout value, too?

Point taken, I hadn't bumped into this since i2c_add_mux_adapter() calls i2c_add_adapter() which essentially sets is to 1 second if it is zero. But it makes sense indeed to also use this value from the parent. I'll post an updated version later today.

Thanks
E.

Signature · 1 line
Elie De Brauwer
#6 lore raw

PATCH v2 1/1 i2c-mux: Inherit retry count and timeout from parent for muxed bus.

In reply to a message not in the archive

If a muxed i2c bus gets created the default retry count and timeout of the muxed bus is zero. Hence it it possible that you end up with a situation where the parent controller sets a default retry count and timeout which gets applied and used while the muxed bus (using the same controller) has a default retry count of zero and a default timeout of 1s (set in i2c_add_adapter()). This can be solved by initializing the retry count and timeout of the muxed bus with the values used by the the parent at creation time.

---
 drivers/i2c/i2c-mux.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/i2c/i2c-mux.c +2 -0
index 797e311..2d0847b 100644
@@ -139,6 +139,8 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent,
 	priv->adap.algo = &priv->algo;
 	priv->adap.algo_data = priv;
 	priv->adap.dev.parent = &parent->dev;
+	priv->adap.retries = parent->retries;
+	priv->adap.timeout = parent->timeout;
 
 	/* Sanity check on class */
 	if (i2c_mux_parent_classes(parent) & class)
Signature · 1 line
1.7.10.4

A message that is not in the archive (sent off-list or not yet received): 1386614908-4872-1-git-send-email-eliedebrauwer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

Applied
#8 lore raw

Re: [PATCH v2] i2c-mux: Inherit retry count and timeout from parent for muxed bus.

Quoted 10 lines · Elie De Brauwer

If a muxed i2c bus gets created the default retry count and timeout of the muxed bus is zero. Hence it it possible that you end up with a situation where the parent controller sets a default retry count and timeout which gets applied and used while the muxed bus (using the same controller) has a default retry count of zero and a default timeout of 1s (set in i2c_add_adapter()). This can be solved by initializing the retry count and timeout of the muxed bus with the values used by the the parent at creation time.

Applied to for-current, thanks, good catch!