From: Pratyush Yadav <p.yadav@ti.com>
To: <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: Tue, 6 Apr 2021 16:37:20 +0530 [thread overview]
Message-ID: <20210406110718.y6dacaeqahc7fbpi@ti.com> (raw)
In-Reply-To: <20210401195012.4009166-2-yaliang.wang@windriver.com>
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.
>
> 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.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-04-06 11:08 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 [this message]
2021-04-06 14:52 ` Yaliang.Wang
2021-04-08 16:22 ` Pratyush Yadav
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=20210406110718.y6dacaeqahc7fbpi@ti.com \
--to=p.yadav@ti.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 \
--cc=yaliang.wang@windriver.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