linux-kernel - Re: [PATCH 2/2] spi/pxa2xx: use a flag to check if the device is runtime suspended

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: <20130619135920.GV1403@sirena.org.uk>
Date:	Wed, 19 Jun 2013 14:59:21 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	linux-kernel@...r.kernel.org, Eric Miao <eric.y.miao@...il.com>,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH 2/2] spi/pxa2xx: use a flag to check if the device is
 runtime suspended

On Wed, Jun 19, 2013 at 11:05:15AM +0100, Russell King - ARM Linux wrote:

> And that's why doing it by "read the ISR and check its value" is the
> best way, and not doing the "what state does the kernel think this
> device is in".

Not entirely, and of course that's not always an option either.

> The latter may be fine if the device is only connected to a non-shared
> interrupt, but as soon as you start sharing interrupts, it fails - what
> do you do if the device signals an interrupt on a level-sensitive input
> but the kernel's state says that it's not yet active?  The answer -
> you spin forever entering the same interrupt handler until the IRQ
> input gets disabled permanently until you reboot the system.

Or we teach the interrupt core how to handle it better - checking for
I/O failures works in the case where the device is genuinely asleep and
we can see I/O failures without undue pain but starts to fall over with
other scenarios.

> As far as device sequencing, that is where the tree topology of the
> device model is supposed to save you - the parenting of devices is
> supposed to reflect their relationship, and the way things like PM
> and runtime PM work, those relationships dictate the order in which
> PM operations occur.  For instance, with runtime PM, a parent will
> not be placed into a suspend state unless its children are already
> suspended, unless the parent signals that it is independent of the
> childs states.

This doesn't fix everything (though it's a lot better with deferred
probing since things now mostly end up in the actual dependency order),
there's still some nasty issues especially around devices which can
interrupt from suspend states.  If that can happen then you can get the
interrupt controller being awake and delivering the interrupt while the
device (or worse, the control bus for the device) is not able to
interact with it.  This is a different problem in that the interrupt
genuinely is firing, it's just that the control path isn't available
yet, but it's the same general class of things.

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