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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Wed, Jun 19, 2013 at 11:05:15AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 19, 2013 at 10:39:38AM +0100, Mark Brown wrote:
> > On Wed, Jun 19, 2013 at 10:25:08AM +0100, Russell King - ARM Linux wrote:
> > > On Tue, Jun 18, 2013 at 07:09:48PM +0100, Mark Brown wrote:
> > 
> > > > This sounds like a problem which will affect a lot of devices and hence
> > > > ought to be handled better by the PM core or at least frameworks in
> > > > general.  Is it really device specific?
> > 
> > > It's always been something that has been recommended to be dealt with
> > > by the driver.  If reading the interrupt status you read ~0, then it
> > > likely is because the device is powered down or removed from the system.
> > 
> > > PCMCIA drivers have done this for years.
> > 
> > I know, some PCI devices too.  It's not just an issue for memory mapped
> > devices, the same thing happens with devices on other buses - there's a
> > whole bunch of issues around moving out of the various suspend states
> > and getting interrupts (things like getting an interrupt controller
> > waking up and delivering interrupts before the control bus for a device
> > connected to it has woken up).  
> > 
> > The driver does need to be the one deciding what to do about being in
> > suspend but we really ought to be able to do something without having to
> > interact with the hardware partly just for neatness but more because on
> > general buses the error handling is too painful.
> 
> 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".

This sounds the simplest thing that solves the problem with the Lynxpoint
SPI controller driver. Then I don't need to add any new flags to the
private structure but just check that if reading the status register
returns ~0 and bail out in that case.