Re: [BUG] sdhci regression in 2.6.21-rc2

[Andrew Morton]

On Mon, 05 Mar 2007 10:19:55 -0500 Mark Lord <lkml@xxxxxx> wrote:

> 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@xxxxxxxxx>
> ---
> --- 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;
>  	}

This is actually pretty standard handling for a lot of drivers: any
device which can appear on a cardbus or other hot-unpluggable bus and which
shares interupts needs such treatment.

I don't know whether anything which this driver drives could ever appear on
such a bus, but I'm inclined to just apply it into 2.6.21.

(I'm also inclined to drop the darned mmc tree - am getting rather tired of
people moving their files all over the tree all the time).

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