On Wed, Oct 01, 2014 at 01:03:59PM -0700, Danielle Costantino wrote: > On Wed, Oct 1, 2014 at 12:41 PM, Guenter Roeck <groeck@xxxxxxxxxxx> wrote: > > On Wed, Oct 01, 2014 at 11:44:59AM -0700, Danielle Costantino wrote: > >> 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. > >> > > 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. > > 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. > > > >> 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-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
