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/
next prev parent 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).