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]
Date:	Thu, 25 Sep 2014 11:47:52 +0200
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	"David E. Box" <david.e.box@...ux.intel.com>
Cc:	wsa@...-dreams.de, jdelvare@...e.de, arnd@...db.de,
	dianders@...omium.org, u.kleine-koenig@...gutronix.de,
	laurent.pinchart+renesas@...asonboard.com,
	boris.brezillon@...e-electrons.com, maxime.coquelin@...com,
	andrew@...n.ch, sjg@...omium.org, markus.mayer@...aro.org,
	ch.naveen@...sung.com, jacob.jun.pan@...ux.intel.com,
	max.schwarz@...ine.de, mika.westerberg@...ux.intel.com,
	skuribay@...ox.com, Romain.Baeriswyl@...lis.com,
	wenkai.du@...el.com, chiau.ee.chew@...el.com,
	christian.ruppert@...lis.com, alan@...ux.intel.com,
	linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org
Subject: Re: [PATCH V2] i2c-designware: Add Intel Baytrail PMIC I2C bus
 support

Hi David,

On Tue, Sep 23, 2014 at 12:58:54PM -0700, David E. Box wrote:
> Hi Maxime,
> 
> On Tue, Sep 23, 2014 at 09:00:57PM +0200, Maxime Ripard wrote:
> > Hi David,
> > 
> > On Tue, Sep 23, 2014 at 11:40:26AM -0700, David E. Box wrote:
> > > This patch implements an I2C bus sharing mechanism between the host and platform
> > > hardware on select Intel BayTrail SoC platforms using the X-Powers AXP288 PMIC.
> > > 
> > > On these platforms access to the PMIC must be shared with platform hardware. The
> > > hardware unit assumes full control of the I2C bus and the host must request
> > > access through a special semaphore. Hardware control of the bus also makes it
> > > necessary to disable runtime pm to avoid interfering with hardware transactions.
> > > 
> > > Signed-off-by: David E. Box <david.e.box@...ux.intel.com>
> > 
> > Sorry for stepping in like this without really knowing your platform,
> > but wouldn't using the hwspinlock framework make more sense than
> > hardcoding your own internal functions here?
> 
> I looked into this but didn't see a clear way on our platform to identify the
> semaphore seperately from doing it in the designware platform driver. The way
> we can find it now is through evaluating an ACPI _SEM object on every i2c device
> that gets probed by the dw driver since at probe time we can get the acpi handle.

And you have no way to turn it around and identify which semaphore is
associated to which i2c bus?

If so, there is probably some way to associate a given instance of the
i2c driver to one semaphore.

> Without this handle however there isn't a clear way of evaluating the _SEM
> object which would be needed to register a hwspinlock in separate code.
> 
> Plus it would still require changes to the designware i2c core, though admittedly
> having a generic hwspinlock pointer added to the struct is cleaner.

Not only cleaner, but that could also be used by other platforms that
are using this I2C driver (and since it's a designware IP, there must
be quite a lot) together with hardware locking.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ