public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: spi-nor: excessive locking in spi_nor_erase()
Date: Tue, 16 Apr 2024 17:44:32 +0200	[thread overview]
Message-ID: <mafs01q758g7z.fsf@kernel.org> (raw)
In-Reply-To: <069251d381826e9bc8a59c49c39c393c2860a028.camel@infinera.com> (Joakim Tjernlund's message of "Mon, 15 Apr 2024 15:55:10 +0000")

Hi,

On Mon, Apr 15 2024, Joakim Tjernlund wrote:

> static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
> {
> ...
> Lock here
> 	ret = spi_nor_lock_and_prep(nor);
> 	if (ret)
> 		return ret;
> ....
> Then we have:
> 	} else if (spi_nor_has_uniform_erase(nor)) {
> 		while (len) {
> 			ret = spi_nor_write_enable(nor);
> 			if (ret)
> 				goto erase_err;
>
> 			ret = spi_nor_erase_sector(nor, addr);
> 			if (ret)
> 				goto erase_err;
>
> 			ret = spi_nor_wait_till_ready(nor);
> 			if (ret)
> 				goto erase_err;
>
> 			addr += mtd->erasesize;
> 			len -= mtd->erasesize;
> 		}
>
> 	/* erase multiple sectors */
> 	} else {
> 		ret = spi_nor_erase_multi_sectors(nor, addr, len);
> 		if (ret)
> 			goto erase_err;
> 	}
> ....
> erase_err:
> unlock here
> 	spi_nor_unlock_and_unprep(nor);
>
> 	return ret;
> }

Firstly, seems like you are looking at an older version of the driver.
spi_nor_erase() looks a bit different now, though works pretty much the
same in practice. See [0].

>
> So erase locks the flash for the whole erase op which can include many sectors and I don't see
> any Erase Suspend handling in spi-nor like the cfi_cmdset_0001/cfi_cmdset_0002 has.
>
> Locking can be a challenge but this seems over the top, anyone working/looking into improving this?

I think you should lead with what the problem you see with this and what
you think can be improved. Why do you think the locking is "over the
top"? What should be improved?

Most flashes can't do any operations (except poll status register) when
a program or erase operation is in progress. So the locking here makes
sense to me. We do not want to let other tasks attempt any other
operations until the erase is done. The only exception is some
multi-bank flashes that can do erase on one bank and reads on other
banks. Miquel's series [1] takes care of those (though I do not see any
flashes using that feature yet).

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/spi-nor/core.c#n1789
[1] https://lore.kernel.org/linux-mtd/20230328154105.448540-1-miquel.raynal@bootlin.com/

-- 
Regards,
Pratyush Yadav

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2024-04-16 15:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15 15:55 spi-nor: excessive locking in spi_nor_erase() Joakim Tjernlund
2024-04-16 15:44 ` Pratyush Yadav [this message]
2024-04-16 18:03   ` Joakim Tjernlund
2024-04-17 12:42     ` Pratyush Yadav
2024-04-17 12:54       ` Joakim Tjernlund
2024-04-19 12:58         ` Pratyush Yadav
2024-04-19 13:14           ` Joakim Tjernlund

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=mafs01q758g7z.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --cc=Joakim.Tjernlund@infinera.com \
    --cc=linux-mtd@lists.infradead.org \
    /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