linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>
Cc: linux-mtd@lists.infradead.org, vigneshr@ti.com, js07.lee@samsung.com
Subject: Re: [PATCH v3 1/5] mtd: spi-nor: Fix gap in SR block protection locking
Date: Mon, 23 Mar 2020 19:20:25 +0000	[thread overview]
Message-ID: <5899969.zVFlrMANan@192.168.0.120> (raw)
In-Reply-To: <b9a6d699790e48723489ecbbf1322dfe@walle.cc>

On Monday, March 23, 2020 8:27:13 PM EET Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> Hi,
> 
> Am 2020-03-23 10:24, schrieb 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.
> 
> So instead of rounding up, it does round down now?

No. Why do you say that it rounds up? The behavior is not changed, the patch 
merely fix the protected area, which was wrong before. The round down is 
present before this patch.
 
> 
> > 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.
> 
> I don't know if that is really what a user really want. Because you'd
> end up with regions which the user believes are locked but are not.

True. I'm thinking of how we can improve this, but it's not in the scope of 
this patch set, because the behavior is not changed.

> IMHO if you'd have to make a choice I'd prefer to have the remainder
> locked. Not the other way around. Esp. since the user explicitly
> express to have a region locked.
> 

We can still talk about this. Please notice that the formula that we want to 
introduce does the same thing as described in this commit message: for 
unaligned locks, it round down the length, and for unaligned unlocks it rounds 
up the length.

I'm waiting for a reply.
ta


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

  reply	other threads:[~2020-03-23 19:20 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 1/5] mtd: spi-nor: Fix gap in SR block protection locking Tudor.Ambarus
2020-03-23 18:27   ` Michael Walle
2020-03-23 19:20     ` Tudor.Ambarus [this message]
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 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 ` [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=5899969.zVFlrMANan@192.168.0.120 \
    --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;
as well as URLs for NNTP newsgroup(s).