linux-kernel - Re: [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem

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:	Sun, 18 Jan 2015 13:41:24 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Krzysztof Kozlowski <k.kozlowski@...sung.com>
Cc:	Tomasz Figa <tomasz.figa@...il.com>,
	Paul Osmialowski <p.osmialowsk@...sung.com>,
	Wolfram Sang <wsa@...-dreams.de>,
	Jonathan Corbet <corbet@....net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kukjin Kim <kgene@...nel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	Michael Turquette <mturquette@...aro.org>,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	Russell King <rmk+kernel@....linux.org.uk>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>
Subject: Re: [RFC 1/3] i2c: Enhancement of i2c API to address circular lock
 dependency problem

On Sun, Jan 18, 2015 at 11:54:56AM +0100, Krzysztof Kozlowski wrote:
> W dniu 18.01.2015 o 07:30, Tomasz Figa pisze:

> >So, the question is, do we actually have hardware that _really_
> >requires _actual_ preparation or all the clk_prepare_enable()s in I2C
> >drivers (at least in i2c-s3c2410) are just to simplify the code?

> I completely forgot that you already thought about this deadlock in 2014. I
> think we can try the no-prepare way for i2c-s3c2410. However this would be
> only workaround for specific chip. Other buses (like SPI) would require
> similar changes.

Right, and it's every single driver which would need an update too which
is a bit icky and sad.  On the other hand a more detailed fix is going
to involve trying to make the clock API locking more fine grained which
isn't fun.

> I wondered why this was not observed (at least not observed by me with
> lockdep) on Gear 2 (Rinato) board. This is quite similar case: the S2MPS14
> PMIC provides regulators and 32kHz clocks. I think it is exactly the same
> pattern as for max77686... but somehow lockdep never reported that deadlock
> there.

Mostly the clocks on PMICs never get changed at runtime which helps a
lot here.

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