[Proposal] PM sleep children of inactive I2C bus segments off Masters in multi-master systems

[Danielle Costantino]

added proper mailing lists...I hope

[Danielle Costantino]

Re-sending Proposal:

Currently I2C mux devices that support multiple master arbitration are
the i2c-mux-pca9541 and i2c-arb-gpio-challenge drivers. I propose to
add the ability to configure an interrupt pin from the Master Selector
device to indicate that bus ownership has been lost. Once the device
loses ownership, all of its children should enter a pm sleep mode (as
you can't talk to them at this point) until master-ship has been
reacquired.

This has come up as an issue when the master loses control over a bus
the return code of all transactions to its lave devices is EIO (not
very helpful).

Any comments would be appreciated, I am just looking if there is
interest in this.

Thanks,

Post by Danielle Costantino
added proper mailing lists...I hope

Hi Danielle,
I don't see the actual proposal, and I don't find anything on the web
either when looking for the headline :-(.
Guenter

[Danielle Costantino]

Post by Danielle Costantino
Currently I2C mux devices that support multiple master arbitration are
the i2c-mux-pca9541 and i2c-arb-gpio-challenge drivers. I propose to
add the ability to configure an interrupt pin from the Master Selector
device to indicate that bus ownership has been lost. Once the device
loses ownership, all of its children should enter a pm sleep mode (as
you can't talk to them at this point) until master-ship has been
reacquired.

Not sure I understand what you are proposing here.

Lets say you have a active - standby based multi-master system. If the
other master forced arbitration (took mastership) the next transation
on any slaves of that bus would return EAGAIN or EBUSY.

Another point is that once mastership has been lost, the configuration
of the devices on that bus are no longer known to be valid...therefor
a re-init of those devices may be needed.

A typical use case would be a power supply such as the one supported by
drivers/hwmon/lineage-pem.c from both an active and standby system
controller. The power supply needs to be accessible from both controllers.
If one controller looses access, it can only mean that it did not follow
the access protocol. Similar, one controller enforcing access means that
it either does not follow the access protocol either, or that the other
end did not follow the protocol (or maybe the other end died).
In all cases, loss of access does not mean that the end device can or should
be put in sleep mode, not even logically. All it means is that there was
an access protocol error. Not sure if there is anything that can be done
about that, but putting the device into sleep mode does not seem to be
an appropriate response to me.

Post by Danielle Costantino
This has come up as an issue when the master loses control over a bus
the return code of all transactions to its lave devices is EIO (not
very helpful).

But, again, doesn't that mean that there was some access protocol error ?
Shouldn't it try to re-acquire mastership instead, and block all accesses
to slaves until it acquired it ?

EIO is such a generic error it makes finding weather there was a
problem communicating or is no longer master of the bus segment.

Thanks,
Guenter

Thanks

[Guenter Roeck]

Post by Danielle Costantino

Post by Danielle Costantino
Currently I2C mux devices that support multiple master arbitration are
the i2c-mux-pca9541 and i2c-arb-gpio-challenge drivers. I propose to
add the ability to configure an interrupt pin from the Master Selector
device to indicate that bus ownership has been lost. Once the device
loses ownership, all of its children should enter a pm sleep mode (as
you can't talk to them at this point) until master-ship has been
reacquired.

Not sure I understand what you are proposing here.

Lets say you have a active - standby based multi-master system. If the
other master forced arbitration (took mastership) the next transation
on any slaves of that bus would return EAGAIN or EBUSY.
Another point is that once mastership has been lost, the configuration
of the devices on that bus are no longer known to be valid...therefor
a re-init of those devices may be needed.

Unfortunately that is a generic problem in a multi-master system.
You never know if the other end reconfigured a device or not,
even if there was no error.

Post by Danielle Costantino

A typical use case would be a power supply such as the one supported by
drivers/hwmon/lineage-pem.c from both an active and standby system
controller. The power supply needs to be accessible from both controllers.
If one controller looses access, it can only mean that it did not follow
the access protocol. Similar, one controller enforcing access means that
it either does not follow the access protocol either, or that the other
end did not follow the protocol (or maybe the other end died).
In all cases, loss of access does not mean that the end device can or should
be put in sleep mode, not even logically. All it means is that there was
an access protocol error. Not sure if there is anything that can be done
about that, but putting the device into sleep mode does not seem to be
an appropriate response to me.

Post by Danielle Costantino
This has come up as an issue when the master loses control over a bus
the return code of all transactions to its lave devices is EIO (not
very helpful).

But, again, doesn't that mean that there was some access protocol error ?
Shouldn't it try to re-acquire mastership instead, and block all accesses
to slaves until it acquired it ?

EIO is such a generic error it makes finding weather there was a
problem communicating or is no longer master of the bus segment.

AFAICS the only time the pca9541 driver returns -EIO is if a transaction
did not complete. Only possible improvement I could imagine would be to
check if mastership was lost if there was an error, and return something
more useful if that is the case. Both -EBUSY or -EAGAIN might make sense
here; I don't really know what would be better or more appropriate.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Danielle Costantino]

My goal was to automatically put the devices behind the master
selector in a (logical) state where all settings would be verified and
if needed corrected and initialized back to how the device was
configured prior to giving up the bus.

The error return is the main issue, but I was hoping to automate
multi-master bus re-initialization.

Post by Guenter Roeck

Post by Danielle Costantino

Post by Danielle Costantino
Currently I2C mux devices that support multiple master arbitration are
the i2c-mux-pca9541 and i2c-arb-gpio-challenge drivers. I propose to
add the ability to configure an interrupt pin from the Master Selector
device to indicate that bus ownership has been lost. Once the device
loses ownership, all of its children should enter a pm sleep mode (as
you can't talk to them at this point) until master-ship has been
reacquired.

Not sure I understand what you are proposing here.

Lets say you have a active - standby based multi-master system. If the
other master forced arbitration (took mastership) the next transation
on any slaves of that bus would return EAGAIN or EBUSY.
Another point is that once mastership has been lost, the configuration
of the devices on that bus are no longer known to be valid...therefor
a re-init of those devices may be needed.

Unfortunately that is a generic problem in a multi-master system.
You never know if the other end reconfigured a device or not,
even if there was no error.

Post by Danielle Costantino

A typical use case would be a power supply such as the one supported by
drivers/hwmon/lineage-pem.c from both an active and standby system
controller. The power supply needs to be accessible from both controllers.
If one controller looses access, it can only mean that it did not follow
the access protocol. Similar, one controller enforcing access means that
it either does not follow the access protocol either, or that the other
end did not follow the protocol (or maybe the other end died).
In all cases, loss of access does not mean that the end device can or should
be put in sleep mode, not even logically. All it means is that there was
an access protocol error. Not sure if there is anything that can be done
about that, but putting the device into sleep mode does not seem to be
an appropriate response to me.

Post by Danielle Costantino
This has come up as an issue when the master loses control over a bus
the return code of all transactions to its lave devices is EIO (not
very helpful).

But, again, doesn't that mean that there was some access protocol error ?
Shouldn't it try to re-acquire mastership instead, and block all accesses
to slaves until it acquired it ?

EIO is such a generic error it makes finding weather there was a
problem communicating or is no longer master of the bus segment.

AFAICS the only time the pca9541 driver returns -EIO is if a transaction
did not complete. Only possible improvement I could imagine would be to
check if mastership was lost if there was an error, and return something
more useful if that is the case. Both -EBUSY or -EAGAIN might make sense
here; I don't really know what would be better or more appropriate.
Guenter

[Guenter Roeck]

Post by Danielle Costantino
My goal was to automatically put the devices behind the master
selector in a (logical) state where all settings would be verified and
if needed corrected and initialized back to how the device was
configured prior to giving up the bus.

That kind of reaction could result in a re-configuration war
if both masters disagree how devices should be configured.
Also, unless I am missing something, it would require changes
in pretty much every i2c client driver. That doesn't really sound
feasible to me.

Maybe you can find an error code which with some level of confidence
reflects "lost mastership". Then you can implement whatever makes sense
for your use case in your user space application(s).

Guenter

Post by Danielle Costantino
The error return is the main issue, but I was hoping to automate
multi-master bus re-initialization.

Post by Guenter Roeck

Post by Danielle Costantino

Post by Danielle Costantino
Currently I2C mux devices that support multiple master arbitration are
the i2c-mux-pca9541 and i2c-arb-gpio-challenge drivers. I propose to
add the ability to configure an interrupt pin from the Master Selector
device to indicate that bus ownership has been lost. Once the device
loses ownership, all of its children should enter a pm sleep mode (as
you can't talk to them at this point) until master-ship has been
reacquired.

Not sure I understand what you are proposing here.

Lets say you have a active - standby based multi-master system. If the
other master forced arbitration (took mastership) the next transation
on any slaves of that bus would return EAGAIN or EBUSY.
Another point is that once mastership has been lost, the configuration
of the devices on that bus are no longer known to be valid...therefor
a re-init of those devices may be needed.

Unfortunately that is a generic problem in a multi-master system.
You never know if the other end reconfigured a device or not,
even if there was no error.

Post by Danielle Costantino

A typical use case would be a power supply such as the one supported by
drivers/hwmon/lineage-pem.c from both an active and standby system
controller. The power supply needs to be accessible from both controllers.
If one controller looses access, it can only mean that it did not follow
the access protocol. Similar, one controller enforcing access means that
it either does not follow the access protocol either, or that the other
end did not follow the protocol (or maybe the other end died).
In all cases, loss of access does not mean that the end device can or should
be put in sleep mode, not even logically. All it means is that there was
an access protocol error. Not sure if there is anything that can be done
about that, but putting the device into sleep mode does not seem to be
an appropriate response to me.

Post by Danielle Costantino
This has come up as an issue when the master loses control over a bus
the return code of all transactions to its lave devices is EIO (not
very helpful).

But, again, doesn't that mean that there was some access protocol error ?
Shouldn't it try to re-acquire mastership instead, and block all accesses
to slaves until it acquired it ?

EIO is such a generic error it makes finding weather there was a
problem communicating or is no longer master of the bus segment.

AFAICS the only time the pca9541 driver returns -EIO is if a transaction
did not complete. Only possible improvement I could imagine would be to
check if mastership was lost if there was an error, and return something
more useful if that is the case. Both -EBUSY or -EAGAIN might make sense
here; I don't really know what would be better or more appropriate.
Guenter

--
- Danielle Costantino

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Danielle Costantino]

Thanks, I will probably work on error return values for master
selectors and add IRQ support to the pca9541 driver.

Post by Guenter Roeck

Post by Danielle Costantino
My goal was to automatically put the devices behind the master
selector in a (logical) state where all settings would be verified and
if needed corrected and initialized back to how the device was
configured prior to giving up the bus.

That kind of reaction could result in a re-configuration war
if both masters disagree how devices should be configured.
Also, unless I am missing something, it would require changes
in pretty much every i2c client driver. That doesn't really sound
feasible to me.
Maybe you can find an error code which with some level of confidence
reflects "lost mastership". Then you can implement whatever makes sense
for your use case in your user space application(s).
Guenter

Post by Danielle Costantino
The error return is the main issue, but I was hoping to automate
multi-master bus re-initialization.

Post by Guenter Roeck

Post by Danielle Costantino

Post by Danielle Costantino
Currently I2C mux devices that support multiple master arbitration are
the i2c-mux-pca9541 and i2c-arb-gpio-challenge drivers. I propose to
add the ability to configure an interrupt pin from the Master Selector
device to indicate that bus ownership has been lost. Once the device
loses ownership, all of its children should enter a pm sleep mode (as
you can't talk to them at this point) until master-ship has been
reacquired.

Not sure I understand what you are proposing here.

Lets say you have a active - standby based multi-master system. If the
other master forced arbitration (took mastership) the next transation
on any slaves of that bus would return EAGAIN or EBUSY.
Another point is that once mastership has been lost, the configuration
of the devices on that bus are no longer known to be valid...therefor
a re-init of those devices may be needed.

Unfortunately that is a generic problem in a multi-master system.
You never know if the other end reconfigured a device or not,
even if there was no error.

Post by Danielle Costantino

A typical use case would be a power supply such as the one supported by
drivers/hwmon/lineage-pem.c from both an active and standby system
controller. The power supply needs to be accessible from both controllers.
If one controller looses access, it can only mean that it did not follow
the access protocol. Similar, one controller enforcing access means that
it either does not follow the access protocol either, or that the other
end did not follow the protocol (or maybe the other end died).
In all cases, loss of access does not mean that the end device can or should
be put in sleep mode, not even logically. All it means is that there was
an access protocol error. Not sure if there is anything that can be done
about that, but putting the device into sleep mode does not seem to be
an appropriate response to me.

Post by Danielle Costantino
This has come up as an issue when the master loses control over a bus
the return code of all transactions to its lave devices is EIO (not
very helpful).

But, again, doesn't that mean that there was some access protocol error ?
Shouldn't it try to re-acquire mastership instead, and block all accesses
to slaves until it acquired it ?

EIO is such a generic error it makes finding weather there was a
problem communicating or is no longer master of the bus segment.

AFAICS the only time the pca9541 driver returns -EIO is if a transaction
did not complete. Only possible improvement I could imagine would be to
check if mastership was lost if there was an error, and return something
more useful if that is the case. Both -EBUSY or -EAGAIN might make sense
here; I don't really know what would be better or more appropriate.
Guenter

--
- Danielle Costantino

[Wolfram Sang]

Post by Guenter Roeck
Maybe you can find an error code which with some level of confidence
reflects "lost mastership". Then you can implement whatever makes sense
for your use case in your user space application(s).

We have a documented fault code for ArbitrationLost and that is -EAGAIN
(see Documentation/i2c/fault-codes). If a driver does use something
else, patches are very welcome.

Other than that, I find this thread very confusing. Of course can
another master modify the clients, this is what multi-master is all
about, no?

[Guenter Roeck]

Post by Wolfram Sang

Post by Guenter Roeck
Maybe you can find an error code which with some level of confidence
reflects "lost mastership". Then you can implement whatever makes sense
for your use case in your user space application(s).

We have a documented fault code for ArbitrationLost and that is -EAGAIN
(see Documentation/i2c/fault-codes). If a driver does use something
else, patches are very welcome.
Other than that, I find this thread very confusing. Of course can
another master modify the clients, this is what multi-master is all
about, no?

That is the point I was trying to make in one of my earlier replies.

Guenter

[Wolfram Sang]

Post by Guenter Roeck

Post by Wolfram Sang

Post by Guenter Roeck
Maybe you can find an error code which with some level of confidence
reflects "lost mastership". Then you can implement whatever makes sense
for your use case in your user space application(s).

We have a documented fault code for ArbitrationLost and that is -EAGAIN
(see Documentation/i2c/fault-codes). If a driver does use something
else, patches are very welcome.
Other than that, I find this thread very confusing. Of course can
another master modify the clients, this is what multi-master is all
about, no?

That is the point I was trying to make in one of my earlier replies.

Yes, and I wondered why the thread continued after that, so I thought
I'll bring it up again :) No, seriously, I did not understand the reply
to that mail of yours, but I'll try again tomorrow after some sleep.

[Guenter Roeck]

Post by Danielle Costantino
Currently I2C mux devices that support multiple master arbitration are
the i2c-mux-pca9541 and i2c-arb-gpio-challenge drivers. I propose to
add the ability to configure an interrupt pin from the Master Selector
device to indicate that bus ownership has been lost. Once the device
loses ownership, all of its children should enter a pm sleep mode (as
you can't talk to them at this point) until master-ship has been
reacquired.

Not sure I understand what you are proposing here.

A typical use case would be a power supply such as the one supported by
drivers/hwmon/lineage-pem.c from both an active and standby system
controller. The power supply needs to be accessible from both controllers.
If one controller looses access, it can only mean that it did not follow
the access protocol. Similar, one controller enforcing access means that
it either does not follow the access protocol either, or that the other
end did not follow the protocol (or maybe the other end died).

In all cases, loss of access does not mean that the end device can or should
be put in sleep mode, not even logically. All it means is that there was
an access protocol error. Not sure if there is anything that can be done
about that, but putting the device into sleep mode does not seem to be
an appropriate response to me.

Post by Danielle Costantino
This has come up as an issue when the master loses control over a bus
the return code of all transactions to its lave devices is EIO (not
very helpful).

But, again, doesn't that mean that there was some access protocol error ?
Shouldn't it try to re-acquire mastership instead, and block all accesses
to slaves until it acquired it ?

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Guenter Roeck]

Post by Danielle Costantino
added proper mailing lists...I hope

Hi Danielle,

I don't see the actual proposal, and I don't find anything on the web
either when looking for the headline :-(.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html