Re: [BUG] sdhci regression in 2.6.21-rc2

[Mark Lord <lkml@rtr.ca>]

Mark Lord wrote:
> Pierre Ossman wrote:
>> Mark Lord wrote:
>>> Another regression, for Pierre Ossman this time.
>>>
>>> My syslog gets spammed like this (below) on suspend/resume (to RAM) 
>>> cycles.
>>> Worked fine, without all of the noise, in all previous kernels up to
>>> 2.6.20+.
>>>
>>
>> This looks like a PCI configuration issue.
> 
> To me, it looks like a buggy driver "resume" sequence.
> The low-level SDHCI driver is trying to use the device
> before the PM/PCI stuff has restored the pre-suspend state.
...

I've dug a bit deeper, instrumenting the driver,
and found/fixed the problem.

The interrupt is shared with another device, which resumes
earlier than the sdhci controller, and generates an interrupt.

The sdhci interrupt handler runs, sees 0xffffffff in its own
device's interrupt status, and tries to handle it..
The reason for the 0xffffffff is that the device is still
suspended, and *all* regs are reading back 0xffffffff.

So.. the suspend routine should de-register the irq handler,
and the resume routine should re-register it again.

Or perhaps a simpler kludge like this one, which fixes it for me:

Signed-off-by:  Mark Lord <mlord@pobox.com>
---
--- linux/drivers/mmc/sdhci.c.orig	2007-03-02 15:06:31.000000000 -0500
+++ linux/drivers/mmc/sdhci.c	2007-03-05 10:13:51.000000000 -0500
@@ -994,7 +994,7 @@
 
 	intmask = readl(host->ioaddr + SDHCI_INT_STATUS);
 
-	if (!intmask) {
+	if (!intmask || intmask == 0xffffffff) {
 		result = IRQ_NONE;
 		goto out;
 	}