public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Harald Nordgard-Hansen <hhansen@pvv.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Fix recovery after failed write-buffer operation in cfi_cmdset_0002.c
Date: Wed, 21 Nov 2012 09:48:39 +0200	[thread overview]
Message-ID: <1353484119.2701.4.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <509D03B7.3070304@pvv.org>

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

Hi,

On Fri, 2012-11-09 at 14:23 +0100, Harald Nordgard-Hansen wrote:
> When working on a problem with some flash chips that lock up during
> write-buffer operations, I think there may be a bug in the linux
> handling of chips using cfi_cmdset_0002.c.
> 
> The datasheets I have found for a number of these chips all specify that
> when aborting a write-buffer command, it is not enough to use the
> standard reset.  Rather a "write-to-buffer-reset command" is needed.
> This command is quite similar for all chips, the main variance seem to
> be if the final 0xF0 can go to any address or must go to addr_unlock1.
> 
> The bug is then in the recovery handling when timing out at the end of
> do_write_buffer, where using the normal reset command is not sufficient.
> 
> Without this change, if the write-buffer command fails then any
> following operations on the flash also fail.
> 
> The small patch here should apply against just about all kernels I've
> seen over the last 5 years, the code has not changed in this area for a
> long time...
> 
> -Harald Nordgård-Hansen

Hi, your patch is not applicable, it is line-wrapped. Can you please
send a patch I can easily apply?
> 
> --------
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c      2012-05-21
> 13:46:28.679794861 +0200
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c      2012-10-30
> 18:27:49.939109556 +0100
> @@ -1536,8 +1536,10 @@
>                 UDELAY(map, chip, adr, 1);
>         }
> 
> -       /* reset on all failures. */
> -       map_write( map, CMD(0xF0), chip->start );

Would be nice to put a short comment about what you do and why, may be
some reference as well. Just to make sure if someone reads the code,
he/she has some clue what are these about.

Thanks!

> +       /* write-to-buffer-reset on all failures. */
> +       cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
> cfi->device_type, NULL);
> +       cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
> cfi->device_type, NULL);
> +       cfi_send_gen_cmd(0xF0, cfi->addr_unlock1, chip->start, map, cfi,
> cfi->device_type, NULL);
>         xip_enable(map, chip, adr);
>         /* FIXME - should have reset delay before continuing */


-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-11-21  7:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-09 13:23 Fix recovery after failed write-buffer operation in cfi_cmdset_0002.c Harald Nordgard-Hansen
2012-11-21  7:48 ` Artem Bityutskiy [this message]
2012-11-23 22:11   ` Harald Nordgard-Hansen
2012-12-03 13:24     ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1353484119.2701.4.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=hhansen@pvv.org \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox