linux-kernel - Re: [BUG] sdhci regression in 2.6.21-rc2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070305201707.8d8a092e.akpm@linux-foundation.org>
Date:	Mon, 5 Mar 2007 20:17:07 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Mark Lord <lkml@....ca>
Cc:	Pierre Ossman <drzeus-list@...eus.cx>, sdhci-devel@...t.drzeus.cx,
	Adrian Bunk <bunk@...sta.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] sdhci regression in 2.6.21-rc2

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

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