linux-kernel - Re: [PATCH V2] i2c-designware: Add Intel Baytrail PMIC I2C bus support

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: <20140925094752.GY15315@lukather>
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)