linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jungseung Lee <js07.lee@samsung.com>
To: Jungseung Lee <js07.lee@gmail.com>,
	Tudor.Ambarus@microchip.com, js07.lee@samsung.com
Cc: linux-mtd@lists.infradead.org, vigneshr@ti.com
Subject: Re: [PATCH v3 2/3] mtd: spi-nor: add 4bit block protection support
Date: Wed, 22 Jan 2020 20:42:00 +0900	[thread overview]
Message-ID: <0a2c4e9132f7d4f61fd3ce87c5393c65515b937e.camel@samsung.com> (raw)
In-Reply-To: <CAPP0e=NMzizy=fEZi4nWzo9GAJOpB2Qwv7ReK7HDvrGKUv+VEw@mail.gmail.com>

Hi, Tudor,

2020-01-18 (Sat), 00:06 +0900, Jungseung Lee:
> Hi, Tudor,
> 
> On Tue, Jan 14, 2020 at 7:49 PM <Tudor.Ambarus@microchip.com> wrote:
> > 
> > Hi, Jungseung,
> > 
> > Thanks for working on this.
> > 
> > On Monday, January 13, 2020 7:59:06 AM EET Jungseung Lee wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > > know the
> > > content is safe
> > > 
> > > Currently, we are supporting block protection only for
> > > flash chips with 3 block protection bits in the SR register.
> > > This patch enables block protection support for some flash with
> > > 4 block protection bits(bp0-3).
> > 
> > Some? Isn't this generic for all the flashes that support BP0-3?
> > 
> 
> This one would be a generic solution to support BP0-3 on Status
> Register.
> From my study, this covers all the flashes listed on spi-nor.c that
> have BP0-3 bit on SR.
> It looks like I have to change this description.
> 
> Note that it is NOT for some flashes that have BP0-3 in another
> register.
> As you know, just like SPI_NOR_HAS_TB did.
> 
> > > 
> > > Signed-off-by: Jungseung Lee <js07.lee@samsung.com>
> > > ---
> > > v3 :
> > >   Fix wrong ofs calculation on v2 patch
> > > v2 :
> > >   Add sample table portion about 4bit block protection on the
> > > comment
> > >   Trivial coding style change
> > > 
> > >  drivers/mtd/spi-nor/spi-nor.c | 127
> > > +++++++++++++++++++++++++++++-----
> > >  include/linux/mtd/spi-nor.h   |   8 +++
> > >  2 files changed, 119 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-
> > > nor/spi-nor.c
> > > index e3da6a8654a8..7e8af6c4fdfa 100644
> > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > @@ -238,6 +238,14 @@ struct flash_info {
> > >                                          * status register. Must
> > > be used
> > > with * SPI_NOR_HAS_TB.
> > >                                          */
> > > +#define SPI_NOR_HAS_BP3                BIT(17) /*
> > > +                                        * Flash SR has 4 bit
> > > fields (BP0-3)
> > > +                                        * for block protection.
> > > +                                        */
> > > +#define SPI_NOR_BP3_SR_BIT6    BIT(18) /*
> > > +                                        * BP3 is bit 6 of status
> > > register.
> > > +                                        * Must be used with
> > 
> > Are we safe to replace SPI_NOR_TB_SR_BIT6 and SPI_NOR_BP3_SR_BIT6
> > with a
> > SPI_NOR_SR_TB_BIT6_BP3_BIT5? Or maybe with a
> > SPI_NOR_SR_BP3_BIT6_TB_BIT5, how
> > is more convenient?
> > 
> 
> Let's think about some flash in which BP0-3 exists in the status
> register but TB exists in another register.
> for example, mx25u12835f.
> I haven't tested yet, but according to the datasheet, I think this
> patch can support 4bit block protection for the flash.
> 
> In order to embrace the case, how about letting them as It is.
> Is there any suggestion?
> 

Hmm.. I again have summarized the case of using 4bit block protection.

* Not supporting TB on status register.

- BP3(BIT5)
  SPI_NOR_HAS_BP3

- BP3(BIT6)
  SPI_NOR_HAS_BP3 | SPI_NOR_BP3_SR_BIT6

* Supporting TB on status register.

- TB(BIT6), BP3(BIT5)
  SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_HAS_BP3
  vs
  SPI_NOR_HAS_TB | SPI_NOR_HAS_BP3 | SPI_NOR_SR_TB_BIT6_BP3_BIT5
    
- TB(BIT5), BP3(BIT6)
  SPI_NOR_HAS_TB | SPI_NOR_HAS_BP3 | SPI_NOR_BP3_SR_BIT6
  vs
  SPI_NOR_HAS_TB | SPI_NOR_HAS_BP3 | SPI_NOR_SR_TB_BIT5_BP3_BIT6  
    
SPI_NOR_BP3_SR_BIT6 and SPI_NOR_TB_SR_BIT6 must exist becuase it maybe
used. It would be ok to add some definitions(as you mentioned) to get
same value with SPI_NOR_BP3_SR_BIT6 or SPI_NOR_TB_SR_BIT6 for
readabilty.

But I think there is nothing looks so cool. Any suggestion?

> > Cheers,
> > ta
> > 
> 
> 
Thanks,
Jungseung Lee


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

  reply	other threads:[~2020-01-22 11:42 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200113055910epcas1p4f97dfeb465b00d66649d6321cffc7b5a@epcas1p4.samsung.com>
2020-01-13  5:59 ` [PATCH v3 1/3] mtd: spi-nor: introduce SR_BP_SHIFT define Jungseung Lee
     [not found]   ` <CGME20200113055910epcas1p377b2618bea2ca860acac2b6f34e2b83e@epcas1p3.samsung.com>
2020-01-13  5:59     ` [PATCH v3 2/3] mtd: spi-nor: add 4bit block protection support Jungseung Lee
2020-01-14 10:49       ` Tudor.Ambarus
2020-01-17 15:06         ` Jungseung Lee
2020-01-22 11:42           ` Jungseung Lee [this message]
2020-01-22 14:31             ` Tudor.Ambarus
2020-01-22 17:14               ` Michael Walle
2020-01-23  3:59                 ` Jungseung Lee
2020-01-23  8:15                   ` Michael Walle
2020-02-11  7:52           ` chenxiang (M)
2020-03-04  5:20             ` Jungseung Lee
2020-03-04  8:36               ` chenxiang (M)
2020-03-07  7:40                 ` Jungseung Lee
2020-01-22 19:36       ` Michael Walle
2020-01-23  6:22         ` Jungseung Lee
2020-01-23  8:10           ` Michael Walle
2020-01-23  8:53             ` Jungseung Lee
2020-01-23  9:31               ` Michael Walle
2020-01-28 11:01                 ` Jungseung Lee
2020-01-28 12:29                   ` [SPAM] " Michael Walle
2020-01-30  8:17                     ` Jungseung Lee
2020-01-30  8:36                       ` [SPAM] " Michael Walle
2020-01-30 10:07                         ` Jungseung Lee
2020-02-03 13:56                       ` Vignesh Raghavendra
2020-02-03 14:38                         ` [SPAM] " Michael Walle
2020-02-03 14:58                           ` Jungseung Lee
2020-02-03 17:31                           ` Vignesh Raghavendra
2020-02-07 12:17                         ` Tudor.Ambarus
2020-02-10  8:33                           ` Michael Walle
2020-02-10  9:47                             ` Tudor.Ambarus
2020-02-10  9:59                               ` Tudor.Ambarus
2020-02-10 10:40                                 ` Michael Walle
2020-02-10 11:27                                   ` Tudor.Ambarus
2020-02-10 12:14                                     ` Michael Walle
2020-02-10 15:50                                       ` Tudor.Ambarus
2020-02-10 10:29                               ` Michael Walle
2020-02-10 11:26                                 ` Tudor.Ambarus
2020-02-19 10:50                                   ` Jungseung Lee
2020-02-19 11:08                                     ` Michael Walle
2020-02-19 11:23                                       ` Jungseung Lee
2020-02-19 11:36                                         ` Michael Walle
2020-02-20 19:09                                     ` Michael Walle
2020-02-21  9:30                                       ` Tudor.Ambarus
2020-02-25  8:20                                         ` Tudor.Ambarus
2020-02-25  9:25                                           ` Jungseung Lee
     [not found]   ` <CGME20200113055910epcas1p384c04182e7c643163d659d42fafd01b3@epcas1p3.samsung.com>
2020-01-13  5:59     ` [PATCH v3 3/3] mtd: spi-nor: support lock/unlock for a few Micron chips Jungseung Lee
2020-01-13 12:30       ` John Garry
2020-01-13 12:40         ` Jungseung Lee
2020-01-13 12:45         ` Jungseung Lee
2020-01-13 13:00           ` John Garry
2020-02-17  0:18   ` [PATCH v3 1/3] mtd: spi-nor: introduce SR_BP_SHIFT define 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=0a2c4e9132f7d4f61fd3ce87c5393c65515b937e.camel@samsung.com \
    --to=js07.lee@samsung.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=js07.lee@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --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).