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] [day] [month] [year] [list]

Message-ID: <20150225194715.421.87263@quantum>
Date:	Wed, 25 Feb 2015 11:47:15 -0800
From:	Mike Turquette <mturquette@...aro.org>
To:	Mark Brown <broonie@...nel.org>,
	"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>,
	"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

Quoting Mark Brown (2015-01-18 05:41:24)
> 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.

Not fun is right. Please see Stephen's attempt here:

http://lkml.kernel.org/r/<1409792466-5092-1-git-send-email-sboyd@...eaurora.org>

I'm hoping this approach will be revisited soon.

Regards,
Mike

> 
> > 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.
--
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/