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 --]
next prev parent 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