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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150217135649.GU9110@finisterre.sirena.org.uk>
Date:	Tue, 17 Feb 2015 22:56:49 +0900
From:	Mark Brown <broonie@...nel.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Simon Horman <horms@...ge.net.au>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Wim Van Sebroeck <wim@...ana.be>,
	Wolfram Sang <wsa@...-dreams.de>,
	Magnus Damm <magnus.damm@...il.com>,
	Support Opensource <support.opensource@...semi.com>,
	Guenter Roeck <linux@...ck-us.net>,
	Lee Jones <lee.jones@...aro.org>,
	Linux Watchdog Mailing List <linux-watchdog@...r.kernel.org>,
	Linux I2C <linux-i2c@...r.kernel.org>,
	Linux-sh list <linux-sh@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Steve Twiss <stwiss.opensource@...semi.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: ARM: shmobile: koelsch: da9210/da9063 interrupt storm (was: Re:
 [PATCH 3/4] ARM: shmobile: koelsch: Add DA9063 PMIC device node for system
 restart)

On Tue, Feb 17, 2015 at 01:05:07PM +0100, Geert Uytterhoeven wrote:

> However, as soon as the da9210 driver will get interrupt support (I wrote
> something, based on the da9211 driver) and the da9210 will have an interrupts
> property in DTS, the interrupt storm will reappear, irrespectively of the order
> in which the two drivers are initialized.

Well, there's another problem there - unless things changed since I last
looked we don't support shared threaded IRQs.

> So far I see only two solutions:
>   - Add platform code that matches against "renesas,koelsch" (and
>     "renesas,lager"), and mask the interrupts in both the da9210 and da9063.
>     This code has to run after the i2c master driver has been initialized,
>     but before the i2c slave drivers are initialized.
>   - Handle the masking in the bootloader (u-boot), which already knows how to
>     reset the board by kicking the da9063. This requires everybody to upgrade
>     his bootloader, though.

> Does anyone have a better solution?

We could try to make the code that masks interrupts on error handle
screaming shared interrupts a bit more gracefully during bootstrap by
shutting things up a bit more aggressively and retrying when something
else registers but that just feels like it's going to open up a
particularly messy rabbit hole.  

Of the options you list above the platform code sounds the most
palatable.

> Question: Is it really the default state of the regulator to not mask
> any interrupts?
> Or could this have been changed by the bootloader? I couldn't find code related
> to that in U-Boot, but as I didn't compile the bootloader myself, I can't be
> 100% certain about the source code.

It wouldn't surprise me, having talked with designers of analogue chips
they can at times have some innovative ideas about interaction with the
processor and interrupts in particular.  It's also possible that there's
some transient condition that occurs during startup that causes the
interrupts to be flagged.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ