From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Kamal Dasu <kdasu.kdev@gmail.com>
Cc: MTD Maling List <linux-mtd@lists.infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
bcm-kernel-feedback-list@broadcom.com
Subject: Re: [PATCH] mtd: brcmnand: Check flash write protect pin status
Date: Wed, 15 Feb 2017 20:50:22 +0100 [thread overview]
Message-ID: <20170215205022.794e9eb3@bbrezillon> (raw)
In-Reply-To: <CAC=U0a3z+9SUO5RYxrKiZxbPgrNFY8AyRPO=1Nfv6UbHa4SQ5g@mail.gmail.com>
On Wed, 15 Feb 2017 13:51:15 -0500
Kamal Dasu <kdasu.kdev@gmail.com> wrote:
>
> >
> > I still have a hard time understanding what the problem is with this
> > commit message. Can you try to clarify that?
> >
>
> Software assumed that setting/resetting the NAND_WP controller
> register would assert/de-assert the #WP pin instantaneously from the
> flash parts perspective, and was proceeding to erase/program. Nand
> driver was not verifying flash status byte for WP. In rigorous
> testing we found this was causing rare data corruptions with erase
> and/or subsequent programming. So to make sure the flash part is ready
> to accept erase/program commands was to send status read command and
> read back the WP bit status from the flash whenever we change the pin
> state. I will clarify this in the commit message as well.
I prefer this explanation ;-).
[...]
>
> >> mb(); /* flush previous writes */
> >> brcmnand_write_reg(ctrl, BRCMNAND_CMD_START,
> >> cmd << brcmnand_cmd_shift(ctrl));
> >> @@ -2462,14 +2517,6 @@ int brcmnand_probe(struct platform_device *pdev, struct brcmnand_soc *soc)
> >> /* Disable XOR addressing */
> >> brcmnand_rmw_reg(ctrl, BRCMNAND_CS_XOR, 0xff, 0, 0);
> >>
> >> - if (ctrl->features & BRCMNAND_HAS_WP) {
> >> - /* Permanently disable write protection */
> >> - if (wp_on == 2)
> >> - brcmnand_set_wp(ctrl, false);
> >> - } else {
> >> - wp_on = 0;
> >> - }
> >> -
> >> /* IRQ */
> >> ctrl->irq = platform_get_irq(pdev, 0);
> >> if ((int)ctrl->irq < 0) {
> >> @@ -2522,6 +2569,14 @@ int brcmnand_probe(struct platform_device *pdev, struct brcmnand_soc *soc)
> >> }
> >>
> >> list_add_tail(&host->node, &ctrl->host_list);
> >> +
> >> + if (ctrl->features & BRCMNAND_HAS_WP) {
> >> + /* Permanently disable write protection */
> >> + if (wp_on == 2)
> >> + brcmnand_set_wp(host, false);
> >> + } else {
> >> + wp_on = 0;
> >> + }
> >
> > Hm, this is not really related to the change you describe in your
> > commit message. This should probably go in a separate commit.
> >
>
> It is related to the change since this code moved within the probe
> function due the new brcmnand_set_wp() prototype. So has to be part
> of the same commit.
You could change the prototype of brcmnand_set_wp() in the first patch
(+ move in the call where appropriate in the probe function and patch
brcmnand_wp() to pass host instead of ctrl), and then rework the
brcmnand_set_wp() implementation in a second patch.
prev parent reply other threads:[~2017-02-15 19:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-14 16:23 [PATCH] mtd: brcmnand: Check flash write protect pin status Kamal Dasu
2017-02-15 8:51 ` Boris Brezillon
2017-02-15 18:51 ` Kamal Dasu
2017-02-15 19:50 ` Boris Brezillon [this message]
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=20170215205022.794e9eb3@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=computersforpeace@gmail.com \
--cc=f.fainelli@gmail.com \
--cc=kdasu.kdev@gmail.com \
--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