linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Pratyush Yadav <p.yadav@ti.com>
To: "Yaliang.Wang" <Yaliang.Wang@windriver.com>
Cc: <tudor.ambarus@microchip.com>, <miquel.raynal@bootlin.com>,
	<richard@nod.at>, <vigneshr@ti.com>,
	<linux-mtd@lists.infradead.org>, <tkuw584924@gmail.com>
Subject: Re: [PATCH 2/3] mtd: spi-nor: core: reuse spi_nor_clear_sr function
Date: Thu, 8 Apr 2021 21:52:40 +0530	[thread overview]
Message-ID: <20210408162238.7ts64buwfwhlsckk@ti.com> (raw)
In-Reply-To: <177cb8e0-8ce1-395d-d181-997fd9e9f749@windriver.com>

On 06/04/21 10:52PM, Yaliang.Wang wrote:
> 
> On 4/6/21 7:07 PM, Pratyush Yadav wrote:
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> > 
> > On 02/04/21 03:50AM,yaliang.wang@windriver.com  wrote:
> > > From: Yaliang Wang<Yaliang.Wang@windriver.com>
> > > 
> > > spi_nor_clear_fsr() and spi_nor_clear_sr() are almost the same, except
> > > the opcode they used, the codes can be easily reused without much
> > > changing.
> > Honestly, I am not sure how I feel about this. Yes, it would reduce some
> > code duplication but at the same time reduces the readability slightly.
> > spi_nor_clear_fsr(nor) is easier to read than spi_nor_clear_sr(nor, OP_CLFSR).
> > I won't blame someone for missing that 'F' and thinking that it actually
> > simply clears the SR. Dunno...
> > 
> > Anyway, if we do decide to go through with this change, the code changes
> > look good to me.
> The reason why am I doing this is quite simple, the contents of the
> function  are relatively  common, no other manufacturer specific codes
> involved, and it can be easily expanded to other manufacturers.  Actually
> there is an instant example, "is25wp256" chip needs to clear error bits with
> using CLEAR EXTENDED READ REGISTER OPERATION (CLERP, 82h) [1].

Ok.

> 
> With that said, the name of the function do can be revised, maybe the name
> "spi_nor_clear_status()" is more proper?

Yes, this is certainly better. While you're doing this then you might 
also want to look into spi_nor_read_sr() and spi_nor_read_fsr() and see 
if we can exploit similarities there as well.

> 
> [1]: https://www.issi.com/WW/pdf/25LP-WP256.pdf ; Page21,Page22 ;
> > > Signed-off-by: Yaliang Wang<Yaliang.Wang@windriver.com>
> > > ---
> > >   drivers/mtd/spi-nor/core.c | 40 +++++++-------------------------------
> > >   1 file changed, 7 insertions(+), 33 deletions(-)
> > > 
> > > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > > index 6dc8bd0a6bd4..dbd6adb6aa0b 100644
> > > --- a/drivers/mtd/spi-nor/core.c
> > > +++ b/drivers/mtd/spi-nor/core.c
> > > @@ -652,14 +652,15 @@ static int spi_nor_xsr_ready(struct spi_nor *nor)
> > >   /**
> > >    * spi_nor_clear_sr() - Clear the Status Register.
> > >    * @nor:     pointer to 'struct spi_nor'.
> > > + * @opcode:  the SPI command op code to clear status register.
> > >    */
> > > -static void spi_nor_clear_sr(struct spi_nor *nor)
> > > +static void spi_nor_clear_sr(struct spi_nor *nor, u8 opcode)
> > >   {
> > >        int ret;
> > > 
> > >        if (nor->spimem) {
> > >                struct spi_mem_op op =
> > > -                     SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_CLSR, 0),
> > > +                     SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 0),
> > >                                   SPI_MEM_OP_NO_ADDR,
> > >                                   SPI_MEM_OP_NO_DUMMY,
> > >                                   SPI_MEM_OP_NO_DATA);
> > > @@ -668,12 +669,12 @@ static void spi_nor_clear_sr(struct spi_nor *nor)
> > > 
> > >                ret = spi_mem_exec_op(nor->spimem, &op);
> > >        } else {
> > > -             ret = spi_nor_controller_ops_write_reg(nor, SPINOR_OP_CLSR,
> > > +             ret = spi_nor_controller_ops_write_reg(nor, opcode,
> > >                                                       NULL, 0);
> > >        }
> > > 
> > >        if (ret)
> > > -             dev_dbg(nor->dev, "error %d clearing SR\n", ret);
> > > +             dev_dbg(nor->dev, "error %d clearing status\n", ret);
> > >   }
> > > 
> > >   /**
> > > @@ -697,7 +698,7 @@ static int spi_nor_sr_ready(struct spi_nor *nor)
> > >                else
> > >                        dev_err(nor->dev, "Programming Error occurred\n");
> > > 
> > > -             spi_nor_clear_sr(nor);
> > > +             spi_nor_clear_sr(nor, SPINOR_OP_CLSR);
> > > 
> > >                /*
> > >                 * WEL bit remains set to one when an erase or page program
> > > @@ -715,33 +716,6 @@ static int spi_nor_sr_ready(struct spi_nor *nor)
> > >        return !(nor->bouncebuf[0] & SR_WIP);
> > >   }
> > > 
> > > -/**
> > > - * spi_nor_clear_fsr() - Clear the Flag Status Register.
> > > - * @nor:     pointer to 'struct spi_nor'.
> > > - */
> > > -static void spi_nor_clear_fsr(struct spi_nor *nor)
> > > -{
> > > -     int ret;
> > > -
> > > -     if (nor->spimem) {
> > > -             struct spi_mem_op op =
> > > -                     SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_CLFSR, 0),
> > > -                                SPI_MEM_OP_NO_ADDR,
> > > -                                SPI_MEM_OP_NO_DUMMY,
> > > -                                SPI_MEM_OP_NO_DATA);
> > > -
> > > -             spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
> > > -
> > > -             ret = spi_mem_exec_op(nor->spimem, &op);
> > > -     } else {
> > > -             ret = spi_nor_controller_ops_write_reg(nor, SPINOR_OP_CLFSR,
> > > -                                                    NULL, 0);
> > > -     }
> > > -
> > > -     if (ret)
> > > -             dev_dbg(nor->dev, "error %d clearing FSR\n", ret);
> > > -}
> > > -
> > >   /**
> > >    * spi_nor_fsr_ready() - Query the Flag Status Register to see if the flash is
> > >    * ready for new commands.
> > > @@ -766,7 +740,7 @@ static int spi_nor_fsr_ready(struct spi_nor *nor)
> > >                        dev_err(nor->dev,
> > >                        "Attempted to modify a protected sector.\n");
> > > 
> > > -             spi_nor_clear_fsr(nor);
> > > +             spi_nor_clear_sr(nor, SPINOR_OP_CLFSR);
> > > 
> > >                /*
> > >                 * WEL bit remains set to one when an erase or page program
> > --
> > Regards,
> > Pratyush Yadav
> > Texas Instruments Inc.
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

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

  reply	other threads:[~2021-04-08 16:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-01 19:50 [PATCH 1/3] mtd: spi-nor: core: Add manuafacturer/chip specific operations yaliang.wang
2021-04-01 19:50 ` [PATCH 2/3] mtd: spi-nor: core: reuse spi_nor_clear_sr function yaliang.wang
2021-04-06 11:07   ` Pratyush Yadav
2021-04-06 14:52     ` Yaliang.Wang
2021-04-08 16:22       ` Pratyush Yadav [this message]
2021-04-01 19:50 ` [PATCH 3/3] mtd: spi-nor: core: move Spansion checking ready codes into spansion.c yaliang.wang
2021-04-05  8:54 ` [PATCH 1/3] mtd: spi-nor: core: Add manuafacturer/chip specific operations Pratyush Yadav
2021-04-05  9:53   ` Tudor.Ambarus

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=20210408162238.7ts64buwfwhlsckk@ti.com \
    --to=p.yadav@ti.com \
    --cc=Yaliang.Wang@windriver.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=tkuw584924@gmail.com \
    --cc=tudor.ambarus@microchip.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).