All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Vignesh Raghavendra <vigneshr@ti.com>,
	<Tudor.Ambarus@microchip.com>, <linux-mtd@lists.infradead.org>
Cc: broonie@kernel.org, fengsheng5@huawei.com
Subject: Re: flash_lock issue for n25q 128mb spi nor part
Date: Tue, 17 Dec 2019 10:09:46 +0000	[thread overview]
Message-ID: <57102617-e39e-3ca2-8e06-fbc1572fa40d@huawei.com> (raw)
In-Reply-To: <6667f429-4732-d098-843a-7a030010f192@ti.com>

On 17/12/2019 08:57, Vignesh Raghavendra wrote:
> Hi Tudor,
> 
> On 12/16/2019 11:39 PM, Tudor.Ambarus@microchip.com wrote:
> [...]
> 
>>>
>>> But, as you may see, it seems that my change to spi_nor_write() is still
>>> required to stop the first unlock failure message, but it needs to be
>>> relocated to after write_err label, as we now jump there for
>>> spi_nor_wait_till_ready() failure. I guess the equivalent relocation is
>>> also required for spi_nor_erase().
>>>
>>> Or maybe spi_nor_wait_till_ready() should clear this flag always.
>>
>> I reproduced this on a n25q256a, with both erase and write. Did a lock,
>> an erase or write, and then the unlock raises an error on the read back test:
>> it receives 0x02 to write (the prev operation let the SR.WE set to 1),
>> and after write, it reads back 0x00 (which is correct, WE is de-asserted).
>>
>> What is pretty strange is that Micron says about erase or program operations
>> that: "When the operation is in progress, the write in progress bit is set
>> to 1. The write enable latch bit is cleared to 0, whether the operation is
>> successful or not".
>>
>> So what I guess it happens, is that when an erase/write command tries to
>> modify a software protected area, the flash completely ignores the command,
>> so no Write In Progress, and no clearing of the WE.
>>
> 
> 
>>From PROGRAM Operations section of mt25q datasheet:
> 
> " When a command is applied to a protected sector, the command is not
> executed, the write enable latch bit remains set to 1, and flag status
> register bits 1 and 4 are set."
> 
> So, Data sheet is quite clear about this and SW would need to clear WEL
> (if required) after write failure.

Yeah, I think that the datasheet could have been better written in that 
regard.

So about "whether the operation is successful or not" - I wonder what 
they mean by "successful". Does it mean simply that the command 
completes, even with error?

Thanks,
John

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2019-12-17 10:10 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-02 17:28 flash_lock issue for n25q 128mb spi nor part John Garry
2019-12-03  9:45 ` Tudor.Ambarus
2019-12-03 10:31   ` John Garry
2019-12-03 11:07     ` Tudor.Ambarus
2019-12-03 11:44       ` John Garry
2019-12-03 12:05         ` Tudor.Ambarus
2019-12-03 12:27           ` Tudor.Ambarus
2019-12-03 12:35             ` John Garry
2019-12-03 13:57               ` John Garry
2019-12-03 14:44                 ` Tudor.Ambarus
2019-12-03 15:29                   ` John Garry
2019-12-04 11:10                     ` John Garry
2019-12-16 18:09                       ` Tudor.Ambarus
2019-12-17  8:57                         ` Vignesh Raghavendra
2019-12-17 10:09                           ` John Garry [this message]
2020-01-09 10:36                           ` John Garry
2020-01-10 11:51                             ` Tudor.Ambarus
2020-01-10 11:56                               ` John Garry
2020-01-15  9:28                                 ` John Garry
2020-03-09 10:15                               ` [RESEND PATCH 1/2] mtd: spi-nor: Clear WEL bit when erase or program errors occur Tudor.Ambarus
2020-03-09 10:15                                 ` [RESEND PATCH 2/2] mtd: spi-nor: Fix description of the sr_ready() return value Tudor.Ambarus
2020-03-09 15:04                                 ` [RESEND PATCH 1/2] mtd: spi-nor: Clear WEL bit when erase or program errors occur John Garry
2020-03-23 17:58                                   ` Tudor.Ambarus
2019-12-03 14:16               ` [PATCH] mtd: spi-nor: Fix the write Status Register on micron flashes Tudor.Ambarus
2019-12-03 14:16                 ` Tudor.Ambarus
2019-12-03 14:50                 ` [PATCH v2] mtd: spi-nor: Fix the writing of the " Tudor.Ambarus
2019-12-03 14:50                   ` Tudor.Ambarus
2019-12-04 10:18                   ` John Garry
2019-12-04 10:18                     ` John Garry
2020-01-09 19:14                   ` Miquel Raynal
2020-01-09 19:14                     ` Miquel Raynal

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=57102617-e39e-3ca2-8e06-fbc1572fa40d@huawei.com \
    --to=john.garry@huawei.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=broonie@kernel.org \
    --cc=fengsheng5@huawei.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vigneshr@ti.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.