From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>, <yaliang.wang@windriver.com>
Cc: <miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
<linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 1/2] mtd: spi-nor: core: move Spansion SR ready codes out of core
Date: Mon, 8 Mar 2021 07:35:53 +0000 [thread overview]
Message-ID: <968a4761-78e1-d0d7-69a8-988867eca91a@microchip.com> (raw)
In-Reply-To: <20210301190829.foqbaroznavsf7ka@ti.com>
On 3/1/21 9:08 PM, Pratyush Yadav wrote:
>> + if (nor->manufacturer && nor->manufacturer->fixups &&
>> + nor->manufacturer->fixups->sr_ready)
>> + return nor->manufacturer->fixups->sr_ready(nor);
> I don't think nor->info->fixups is the correct place for this hook.
> Those should be about fixing up incorrect or missing information about
> the flash. It should instead be placed in nor->params.
>
Pratyush is right.
> This eliminates the need for the call to
> nor->manufacturer->fixups->sr_ready. Now you can simply call
> nor->params->sr_ready(). The fixup hooks will take care of populating it
> with the correct function based on the flash or manufacturer.
>
For operations that require a different sequence of opcodes issued,
or different checks needed, I would use something like from below.
struct spi_nor_ops {
int (*ready)(struct spi_nor *nor);
};
struct spi_nor_flash_parameter {
...
struct spi_nor_erase_map erase_map;
struct spi_nor_ops ops;
...
};
You'll have to get rid of the SNOR_F_USE_FSR, SNOR_F_READY_XSR_RDY and
SNOR_F_USE_CLSR. You'll init the default spi_nor_ready() in
spi_nor_info_init_params(), and you will overwrite it for the 3 cases
from above in the manufacturer or flash default_init() hook.
You'll then use across the core nor->params->ops.ready().
Not related to your patch, but related with the overall architecture:
there is another case, where the just the opcode differs, where manufacturers
use different hex opcodes for the same command (ex. some manufacturers use 0x35
for reading CR, others use 0x15). That will require a struct spi_nor_opcodes.
Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-03-08 7:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 14:28 [PATCH 1/2] mtd: spi-nor: core: move Spansion SR ready codes out of core yaliang.wang
2021-03-01 14:28 ` [PATCH 2/2] mtd: spi-nor: spansion: uses CLSR command in S25FL{064|128|256}L chips yaliang.wang
2021-03-02 11:15 ` Pratyush Yadav
2021-04-01 18:44 ` Yaliang.Wang
2021-03-01 19:08 ` [PATCH 1/2] mtd: spi-nor: core: move Spansion SR ready codes out of core Pratyush Yadav
2021-03-08 7:35 ` Tudor.Ambarus [this message]
2021-03-02 9:18 ` Vignesh Raghavendra
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=968a4761-78e1-d0d7-69a8-988867eca91a@microchip.com \
--to=tudor.ambarus@microchip.com \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--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;
as well as URLs for NNTP newsgroup(s).