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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
