Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <js07.lee@samsung.com>, <michael@walle.cc>, <vigneshr@ti.com>
Cc: linux-mtd@lists.infradead.org, Tudor.Ambarus@microchip.com
Subject: [PATCH v3 1/5] mtd: spi-nor: Fix gap in SR block protection locking
Date: Mon, 23 Mar 2020 09:24:33 +0000	[thread overview]
Message-ID: <20200323092430.1466234-2-tudor.ambarus@microchip.com> (raw)
In-Reply-To: <20200323092430.1466234-1-tudor.ambarus@microchip.com>

From: Tudor Ambarus <tudor.ambarus@microchip.com>

Fix the gap for the SR block protection, the BP bits were set with
a +1 value than actually needed. This patch does not change the
behavior of the locking operations, just fixes the protected areas.

On a 16Mbit flash with 64KByte erase sector, the following changed
for the lock operation:

Number of blocks | BP2:0 before | BP2:0 now |
               1 | 010b         | 001b      |
               2 | 110b         | 010b      |
               3 | 110b         | 010b      |
               4 | 100b         | 011b      |
               5 | 100b         | 011b      |
               6 | 100b         | 011b      |
               7 | 100b         | 011b      |
               8 | 101b         | 100b      |
               9 | 101b         | 100b      |
             ... | ...          | ...       |

For the lock operation, if one requests to lock an area that is not
matching the upper boundary of a BP protected area, we round down
the total length and lock less than the user requested, in order to
not lock more than the user actually requested.

For the unlock operation, read the number of blocks column as
"locked all but number of blocks value". On a 16Mbit flash with
64KByte erase sector, the following changed for the lock operation:

Number of blocks | BP2:0 before | BP2:0 now |
               1 | 111b         | 101b      |
             ... | ...          | ...       |
              15 | 111b         | 101b      |
              16 | 110b         | 101b      |
              17 | 110b         | 100b      |
             ... | ...          | ...       |
              24 | 101b         | 100b      |
              25 | 101b         | 011b      |
              26 | 101b         | 011b      |
              27 | 101b         | 011b      |
              28 | 100b         | 011b      |
              29 | 100b         | 010b      |
              30 | 011b         | 010b      |
              31 | 010b         | 001b      |
              32 | 000b         | 000b      |

For the unlock operation, if one requests to unlock an area that is
not matching the upper boundary of a BP protected area, we round up
the total length and unlock more than the user actually requested.

Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
---
 drivers/mtd/spi-nor/core.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 877557dbda7f..36660068bc04 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1654,13 +1654,13 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, uint64_t len)
 	/*
 	 * Need smallest pow such that:
 	 *
-	 *   1 / (2^pow) <= (len / size)
+	 *   1 / ((2^pow) - 1) <= (len / size)
 	 *
 	 * so (assuming power-of-2 size) we do:
 	 *
-	 *   pow = ceil(log2(size / len)) = log2(size) - floor(log2(len))
+	 *   pow = ceil(log2(size / len)) = log2(size) - floor(log2(len)) + 1
 	 */
-	pow = ilog2(mtd->size) - ilog2(lock_len);
+	pow = ilog2(mtd->size) - ilog2(lock_len) + 1;
 	val = mask - (pow << SR_BP_SHIFT);
 	if (val & ~mask)
 		return -EINVAL;
@@ -1739,13 +1739,13 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
 	/*
 	 * Need largest pow such that:
 	 *
-	 *   1 / (2^pow) >= (len / size)
+	 *   1 / ((2^pow) - 1) >= (len / size)
 	 *
 	 * so (assuming power-of-2 size) we do:
 	 *
-	 *   pow = floor(log2(size / len)) = log2(size) - ceil(log2(len))
+	 *   pow = floor(log2(size / len)) = log2(size) - ceil(log2(len)) + 1
 	 */
-	pow = ilog2(mtd->size) - order_base_2(lock_len);
+	pow = ilog2(mtd->size) - order_base_2(lock_len) + 1;
 	if (lock_len == 0) {
 		val = 0; /* fully unlocked */
 	} else {
-- 
2.23.0

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

  parent reply	other threads:[~2020-03-23  9:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23  9:24 [PATCH v3 0/5] mtd: spi-nor: Add SR 4bit block protection support Tudor.Ambarus
2020-03-23  9:24 ` [PATCH v3 2/5] mtd: spi-nor: Set all BP bits to one when lock_len == mtd->size Tudor.Ambarus
2020-03-23 14:08   ` Jungseung Lee
2020-03-23 18:28   ` Michael Walle
2020-03-23  9:24 ` Tudor.Ambarus [this message]
2020-03-23 18:27   ` [PATCH v3 1/5] mtd: spi-nor: Fix gap in SR block protection locking Michael Walle
2020-03-23 19:20     ` Tudor.Ambarus
2020-03-23 19:54       ` Michael Walle
2020-03-23 20:26         ` Tudor.Ambarus
2020-03-23 21:14           ` Michael Walle
2020-03-23 21:30             ` Tudor.Ambarus
2020-03-23 21:33               ` Tudor.Ambarus
2020-03-23 22:35               ` Michael Walle
2020-03-24  5:37                 ` Tudor.Ambarus
2020-03-24  3:52   ` Jungseung Lee
2020-03-25  9:44   ` Tudor.Ambarus
2020-03-23  9:24 ` [PATCH v3 3/5] mtd: spi-nor: Add new formula for SR block protection handling Tudor.Ambarus
     [not found]   ` <000001d600ff$063a8fd0$12afaf70$@samsung.com>
2020-03-23 13:32     ` Jungseung Lee
2020-03-23  9:24 ` [PATCH v3 4/5] mtd: spi-nor: Add SR 4bit block protection support Tudor.Ambarus
2020-03-23 12:43   ` Jungseung Lee
2020-03-23 12:55     ` Tudor.Ambarus
2020-03-23 13:16       ` Jungseung Lee
2020-03-23 18:33   ` Michael Walle
2020-03-23 18:51     ` Tudor.Ambarus
2020-03-23  9:24 ` [PATCH v3 4/5] mtd: spi-nor: Add 4bit SR " Tudor.Ambarus
2020-03-23  9:46   ` Tudor.Ambarus
2020-03-23  9:24 ` [PATCH v3 5/5] mtd: spi-nor: Enable locking for n25q512ax3/n25q512a 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=20200323092430.1466234-2-tudor.ambarus@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=js07.lee@samsung.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --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