Thanks, I will probably work on error return values for master selectors and add IRQ support to the pca9541 driver. On Wed, Oct 1, 2014 at 1:43 PM, Guenter Roeck <groeck@xxxxxxxxxxx> wrote: > On Wed, Oct 01, 2014 at 01:32:28PM -0700, Danielle Costantino wrote: >> 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 > >> The error return is the main issue, but I was hoping to automate >> multi-master bus re-initialization. >> >> On Wed, Oct 1, 2014 at 1:20 PM, Guenter Roeck <groeck@xxxxxxxxxxx> wrote: >> > 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 >> >> >> >> -- >> - Danielle Costantino -- - Danielle Costantino -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
