From: "chenxiang (M)" <chenxiang66@hisilicon.com>
To: Jungseung Lee <js07.lee@gmail.com>, <Tudor.Ambarus@microchip.com>
Cc: Linuxarm <linuxarm@huawei.com>,
John Garry <john.garry@huawei.com>,
linux-mtd@lists.infradead.org, vigneshr@ti.com,
Jungseung Lee <js07.lee@samsung.com>
Subject: Re: [PATCH v3 2/3] mtd: spi-nor: add 4bit block protection support
Date: Tue, 11 Feb 2020 15:52:06 +0800 [thread overview]
Message-ID: <7932da1d-77d8-04a4-4ee1-8ab88ec97f97@hisilicon.com> (raw)
In-Reply-To: <CAPP0e=NMzizy=fEZi4nWzo9GAJOpB2Qwv7ReK7HDvrGKUv+VEw@mail.gmail.com>
Hi Jungseung Lee,
在 2020/1/17 23:06, 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?
In my board(hisilicon D06) there is a mx25u12835f Flash, and i enable
SPI_NOR_HAS_LOCK and SPI_NOR_HAS_BP3 which is not enabled in spi-nor.c,
find it seems not work:
Euler:~ # ls /dev/mtd0
/dev/mtd0
Euler:~ # ./flash_lock -i /dev/mtd0
Device: /dev/mtd0
Start: 0
Len: 0x1000000
Lock status: unlocked
Return code: 0
Euler:~ #
Euler:~ # ./flash_lock /dev/mtd0
flash_lock: error!: could not lock device: /dev/mtd0
error 5 (Input/output error)
Euler:~ # ./flash_lock -i /dev/mtd0
Device: /dev/mtd0
Start: 0
Len: 0x1000000
Lock status: locked
Return code: 1
Euler:~ #
I find that in function spi_nor_write_sr_and_check(), if spi_nor has
16bit SR, spi_nor_write_16bit_sr_and_check() will be called, if not
spi_nor_write_sr1_and_check() will be called.
For mx25u12835f, it just has 8bit SR, but SNOR_F_HAS_16BIT_SR is set as
default, so it causes above issue;
Even hack the code to not set flag SNOR_F_HAS_16BIT_SR, it seems that
lock is still not valided as Program/Erase still success even if it is
locked:
Euler:~ # ./flash_lock -i /dev/mtd0
Device: /dev/mtd0
Start: 0
Len: 0x1000000
Lock status: unlocked
Return code: 0
Euler:~ #
Euler:~ # ./mtd_debug erase /dev/mtd0 0xe40000 4096
Erased 4096 bytes from address 0x00e40000 in flash
Euler:~ #
Euler:~ # ./flash_lock /dev/mtd0
Euler:~ #
Euler:~ # ./flash_lock -i /dev/mtd0
Device: /dev/mtd0
Start: 0
Len: 0x1000000
Lock status: locked
Return code: 1
Euler:~ #
Euler:~ # ./mtd_debug erase /dev/mtd0 0xe40000 4096
Erased 4096 bytes from address 0x00e40000 in flash
Euler:~ # ./flash_lock -i /dev/mtd0
Device: /dev/mtd0
Start: 0
Len: 0x1000000
Lock status: locked
Return code: 1
Euler:~ #
Euler:~ #
Thanks,
chenxiang
>
>> Cheers,
>> ta
>>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
> .
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-02-11 7:52 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
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) [this message]
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=7932da1d-77d8-04a4-4ee1-8ab88ec97f97@hisilicon.com \
--to=chenxiang66@hisilicon.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=john.garry@huawei.com \
--cc=js07.lee@gmail.com \
--cc=js07.lee@samsung.com \
--cc=linux-mtd@lists.infradead.org \
--cc=linuxarm@huawei.com \
--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).