linux-kernel - Re: Fwd: [Proposal] PM sleep children of inactive I2C bus segments off Masters in multi-master systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141001202058.GB6948@svl-evodev-groeck.juniper.net>
Date:	Wed, 1 Oct 2014 13:20:58 -0700
From:	Guenter Roeck <groeck@...iper.net>
To:	Danielle Costantino <danielle.costantino@...il.com>
CC:	linux-i2c <linux-i2c@...r.kernel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Rajat Jain <rajatjain@...iper.net>
Subject: Re: Fwd: [Proposal] PM sleep children of inactive I2C bus segments
 off Masters in multi-master systems

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@...iper.net> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/