From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
To: Tudor.Ambarus@microchip.com, p.yadav@ti.com
Cc: linux-mtd@lists.infradead.org, michael@walle.cc,
miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mtd: spi-nor: Introduce erase_proto
Date: Mon, 25 Jul 2022 16:54:16 +0200 [thread overview]
Message-ID: <7caffdd6-2292-d454-7a76-5dbc30ab9c29@nokia.com> (raw)
In-Reply-To: <c1a4e233-f00b-a4c4-8c28-111889f272d9@microchip.com>
Hi Tudor!
On 18/07/2022 18:50, Tudor.Ambarus@microchip.com wrote:
>>> @@ -2727,6 +2727,9 @@ static void spi_nor_late_init_params(struct spi_nor *nor)
>>> */
>>> if (nor->flags & SNOR_F_HAS_LOCK && !nor->params->locking_ops)
>>> spi_nor_init_default_locking_ops(nor);
>>> +
>>> + if (!nor->erase_proto)
>>> + nor->erase_proto = nor->write_proto;
>> I get that you are trying to not break any existing flashes with this,
>> but I don't quite like it. We should keep the same initialization flow
>> with erase_proto as with write_proto, read_proto, etc. That is,
>> initialize it to SNOR_PROTO_1_1_1 in spi_nor_scan() and then let the
>> initialization procedure change it as needed.
>>
>> The problem with this is of course that it could break some flashes by
>> selecting the wrong erase. I would expect _most_ flashes to use
>> erase_proto as 1-1-1 but I of course haven't went and looked at every
>> single flash to point out the exceptions.
>>
>> I would like to hear from others if they think it is okay to do this.
>>
> Doesn't [1] solve Alexander's problem? Alexander, would you please test
> Patrice's patch and provide a Tested-by tag if everything is ok?
Yes, looks good, provided the Tested-by tag.
> Thanks,
> ta
>
> [1] https://patchwork.ozlabs.org/project/linux-mtd/patch/20220629133013.3382393-1-patrice.chotard@foss.st.com/
>
--
Best regards,
Alexander Sverdlin.
prev parent reply other threads:[~2022-07-25 14:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 10:08 [PATCH 1/2] mtd: spi-nor: Introduce erase_proto Alexander A Sverdlin
2021-12-09 10:08 ` [PATCH 2/2] mtd: spi-nor: micron/st: Hardcode erase_proto to 1-1-1 Alexander A Sverdlin
2021-12-16 20:07 ` Pratyush Yadav
2021-12-16 20:05 ` [PATCH 1/2] mtd: spi-nor: Introduce erase_proto Pratyush Yadav
2022-07-18 16:50 ` Tudor.Ambarus
2022-07-25 14:54 ` Alexander Sverdlin [this message]
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=7caffdd6-2292-d454-7a76-5dbc30ab9c29@nokia.com \
--to=alexander.sverdlin@nokia.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--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).