linux-kernel - Re: [PATCH 1/2] mmc_block: print better data error message after timeout

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] [day] [month] [year] [list]

Date:	Sun, 21 Dec 2008 15:22:49 +0100
From:	Pierre Ossman <drzeus@...eus.cx>
To:	Adrian Hunter <ext-adrian.hunter@...ia.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] mmc_block: print better data error message after
 timeout

On Thu, 04 Dec 2008 15:35:43 +0200
Adrian Hunter <ext-adrian.hunter@...ia.com> wrote:

> Pierre Ossman wrote:
> > On Wed, 29 Oct 2008 12:29:48 +0200
> > Adrian Hunter <ext-adrian.hunter@...ia.com> wrote:
> > 
> >> Waiting for the card to become ready after an error is also not included,
> >> as it is not in the standards and is a separate issue anyway.
> > 
> > What do you mean?
> 
> You had suggested
> 
> 	while (card not ready)
> 		status |= send_status();
> 
> and I didn't do it, because of the reasons given above.
> 

What confused me was that you sait "it is not in the standards", but
perhaps you were just referring to the read case? In the write case the
specs are clear that errors will be done during execution, which can be
delayed for writes.

> From: Adrian Hunter <ext-adrian.hunter@...ia.com>
> Date: Thu, 16 Oct 2008 12:55:25 +0300
> Subject: [PATCH] mmc_block: print better error messages
> 
> Add command response and card status to error
> messages.
> 
> Signed-off-by: Adrian Hunter <ext-adrian.hunter@...ia.com>
> ---

Queued. Thanks for all the work. :)

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)