public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Marek Vasut <marek.vasut@gmail.com>
Cc: Kamal Dasu <kdasu.kdev@gmail.com>,
	linux-mtd@lists.infradead.org, f.fainelli@gmail.com,
	richard@nod.at, bcm-kernel-feedback-list@broadcom.com,
	cyrille.pitchen@atmel.com, computersforpeace@gmail.com,
	dwmw2@infradead.org
Subject: Re: [PATCH V2, 2/2] mtd: nand: brcmnand: Check flash #WP pin status before nand erase/program
Date: Sat, 18 Feb 2017 09:03:27 +0100	[thread overview]
Message-ID: <20170218090327.76954604@bbrezillon> (raw)
In-Reply-To: <1c718482-719a-190b-8e86-ca21f6bf330f@gmail.com>

On Fri, 17 Feb 2017 22:38:04 +0100
Marek Vasut <marek.vasut@gmail.com> wrote:

> On 02/16/2017 07:46 PM, Kamal Dasu wrote:
> > brcmnand controller v6.x and v7.x lets driver to enable disable #WP pin
> > via NAND_WP bit in CS_SELECT register. Driver implementation assumes that
> > setting/resetting the bit would assert/de-assert  #WP pin instantaneously
> > from the flash part's perspective, and was proceeding to erase/program
> > without verifying flash status byte for protection bit. In rigorous
> > testing this was causing rare data corruptions with erase and/or
> > subsequent programming. To fix this added verification logic to
> > brcmandn_wp_set() by reading  flash status and verifying protection bit
> > indicating #WP pin status.  The new logic makes sure controller as well
> > as the flash is ready to accept commands.
> > 
> > Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
> > ---
> >  drivers/mtd/nand/brcmnand/brcmnand.c | 53 ++++++++++++++++++++++++++++++++++--
> >  1 file changed, 51 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
> > index c7c4efe..2f082a3 100644
> > --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> > +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> > @@ -101,6 +101,9 @@ struct brcm_nand_dma_desc {
> >  #define BRCMNAND_MIN_BLOCKSIZE	(8 * 1024)
> >  #define BRCMNAND_MIN_DEVSIZE	(4ULL * 1024 * 1024)
> >  
> > +#define FLASH_RDY	(NAND_STATUS_READY)  
> 
> Drop extra parenthesis
> 
> > +#define NAND_CTRL_RDY	(INTFC_CTLR_READY | INTFC_FLASH_READY)
> > +
> >  /* Controller feature flags */
> >  enum {
> >  	BRCMNAND_HAS_1K_SECTORS			= BIT(0),
> > @@ -765,12 +768,57 @@ enum {
> >  	CS_SELECT_AUTO_DEVICE_ID_CFG		= BIT(30),
> >  };
> >  
> > -static int brcmnand_set_wp(struct brcmnand_host *host, int en)
> > +static void bcmnand_ctrl_busy_poll(struct brcmnand_controller *ctrl, u32 mask)
> > +{
> > +	unsigned long timeout = jiffies + msecs_to_jiffies(200);
> > +
> > +	while ((brcmnand_read_reg(ctrl, BRCMNAND_INTFC_STATUS) & mask) !=
> > +		mask) {  
> 
> Ewww, make this into something like ...
> 
> while (true) { / for (;;) {
>  reg = read.....
>  if ((reg & mask) == mask)
>    ...
>  if (time ....)
>    dev_warn...
>  cpu_relax();
> }
> 
> But then again, there's the readx_poll_timeout() , which seems like
> exactly the thing you implemented here .

I agree that using readl_poll_timeout() would be better, but it's not
so simple (see brcmnand_read_reg() and brcmnand_readl()
implementations).

> 
> > +		if (time_after(jiffies, timeout)) {
> > +			dev_warn(ctrl->dev, "timeout on ctrl_ready\n");
> > +			break;
> > +		}
> > +		cpu_relax();
> > +	}
> > +}
> > +
> > +static inline void brcmnand_set_wp_reg(struct brcmnand_controller *ctrl, int en)
> >  {
> > -	struct brcmnand_controller *ctrl = host->ctrl;
> >  	u32 val = en ? CS_SELECT_NAND_WP : 0;
> >  
> >  	brcmnand_rmw_reg(ctrl, BRCMNAND_CS_SELECT, CS_SELECT_NAND_WP, 0, val);
> > +}
> > +
> > +static int brcmnand_set_wp(struct brcmnand_host *host, int en)
> > +{
> > +	struct brcmnand_controller *ctrl = host->ctrl;
> > +	struct mtd_info *mtd = nand_to_mtd(&host->chip);
> > +	struct nand_chip *chip = mtd_to_nand(mtd);
> > +	u32 sts_reg;
> > +	bool is_wp;
> > +
> > +	/*
> > +	 * make sure ctrl/flash ready before and after
> > +	 * changing state of WP PIN
> > +	 */
> > +	bcmnand_ctrl_busy_poll(ctrl, NAND_CTRL_RDY | FLASH_RDY);
> > +	brcmnand_set_wp_reg(ctrl, en);
> > +	chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
> > +	bcmnand_ctrl_busy_poll(ctrl, NAND_CTRL_RDY | FLASH_RDY);
> > +	sts_reg = brcmnand_read_reg(ctrl, BRCMNAND_INTFC_STATUS);
> > +	/* NAND_STATUS_WP 0x80 = not protected, 0x00 = protected */
> > +	is_wp = (sts_reg & NAND_STATUS_WP) ? false : true;  
> 
> I dont think you need the ternary op here.

Indeed.

> 
> > +	if (is_wp != en) {
> > +		u32 nand_wp = brcmnand_read_reg(ctrl, BRCMNAND_CS_SELECT);
> > +
> > +		nand_wp &= CS_SELECT_NAND_WP;
> > +		dev_err_ratelimited(&host->pdev->dev,
> > +				    "#WP %s sts:0x%x expected %s NAND_WP 0x%x\n",
> > +				    is_wp ? "On" : "Off",  sts_reg & 0xff,
> > +				    en ? "On" : "Off", nand_wp ? 1 : 0);
> > +		return -EINVAL;
> > +	}
> >  
> >  	return 0;
> >  }
> > @@ -1167,6 +1215,7 @@ static void brcmnand_send_cmd(struct brcmnand_host *host, int cmd)
> >  	BUG_ON(ctrl->cmd_pending != 0);
> >  	ctrl->cmd_pending = cmd;
> >  
> > +	bcmnand_ctrl_busy_poll(ctrl, NAND_CTRL_RDY);
> >  	intfc = brcmnand_read_reg(ctrl, BRCMNAND_INTFC_STATUS);
> >  	WARN_ON(!(intfc & INTFC_CTLR_READY));
> >  
> >   
> 
> 

  reply	other threads:[~2017-02-18  8:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16 18:46 [PATCH V2, 1/2] mtd: nand: brcmnand: Change brcmnand_set_wp() prototype Kamal Dasu
2017-02-16 18:46 ` [PATCH V2, 2/2] mtd: nand: brcmnand: Check flash #WP pin status before nand erase/program Kamal Dasu
2017-02-17 21:38   ` Marek Vasut
2017-02-18  8:03     ` Boris Brezillon [this message]
2017-02-18 15:21       ` Marek Vasut
2017-02-18  8:01   ` [PATCH V2, 2/2] mtd: nand: brcmnand: Check flash #WP pin status before nand erase/programAAs Boris Brezillon

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=20170218090327.76954604@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@atmel.com \
    --cc=dwmw2@infradead.org \
    --cc=f.fainelli@gmail.com \
    --cc=kdasu.kdev@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=richard@nod.at \
    /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