Re: [BUG] sdhci regression in 2.6.21-rc2

Andrew Morton
2007-03-06T04:20:33Z

On Mon, 05 Mar 2007 10:19:55 -0500 Mark Lord <lkml@rtr.ca> 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@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;
> }

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).