linux-kernel - Re: [PATCH 2/2] OMAP: HSMMC: Fix response type for busy after response

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]

Date:	Wed, 14 Jan 2009 12:19:55 +0200
From:	Adrian Hunter <ext-adrian.hunter@...ia.com>
To:	Adrian Hunter <ext-adrian.hunter@...ia.com>
CC:	Tony Lindgren <tony@...mide.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	lkml <linux-kernel@...r.kernel.org>,
	Pierre Ossman <drzeus-mmc@...eus.cx>,
	linux-omap Mailing List <linux-omap@...r.kernel.org>
Subject: Re: [PATCH 2/2] OMAP: HSMMC: Fix response type for busy after response

Adrian Hunter wrote:
>>>From 410bc62034c021f8767c8dae469c3215783992ca Mon Sep 17 00:00:00 2001
> From: Adrian Hunter <ext-adrian.hunter@...ia.com>
> Date: Mon, 12 Jan 2009 16:13:08 +0200
> Subject: [PATCH] OMAP: HSMMC: Fix response type for busy after response
> 
> Some MMC commands result in the card becoming busy after
> the response is received.  This needs to be specified
> for the omap_hsmmc host controller, which is what this
> patch does.  However, the effect is that some commands
> with no data will cause a Transfer Complete (TC) interrupt
> in addition to the Command Complete (CC) interrupt.
> In order to deal with that, the irq handler has needed
> a few changes also.
> 
> The benefit of this change is that the omap_hsmmc host
> controller driver now waits for the TC interrupt while
> the card is busy, so the mmc_block driver needs to poll
> the card status just once instead of repeatedly.
> i.e. the net result is more sleep and less cpu.
> 
> This also fixes the hidden problem that the controller
> was turning off the clock to the card while the card
> was busy - the clock was then switched on for the
> duration of each Send Status command used for polling,
> which is why writes did not lock up altogether.
> i.e. really dysfunctional.

That paragraph is not true.  According to the standard:

"The host is allowed to shut down the clock of a “busy” card. The card will complete the programming
operation regardless of the host clock. However, the host must provide a clock edge for the card to turn
off its busy signal. Without a clock edge the card (unless previously disconnected by a deselect command
-CMD7) will force the DAT0 line down, forever."

i.e. during busy state the clock is only needed to check whether the busy state is over.

I will resend the patch, without that paragraph and with a fix to report the
error code when there is a timeout error in the busy state.
--
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/