linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

      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).