Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
Am 2021-03-17 10:30, schrieb tudor.amba...@microchip.com: soft-wr-protect.c or software-write-protect.c ? Having in mind that we have the SWP configs, I think I prefer swp.c. But let's see what majority thinks, we'll do as majority prefers. Michael, Pratyush? It's just an internal name, thus as long as it remotely makes sense, I'm fine. It's just a matter of taste, isn't it? Sure, it's a matter of preference. What's yours? if i have to choose, swp.c But here's one technical reason that would bother me more: name clashes between the core modules: core, sfdp, otp, swp and the vendor names. It is very unlikely, but there is a non-zero chance ;) We can move all manufacturers to a manufacturers/ folder. Each manufacturer driver will have to #include "../core.h", about what I have some mixed feelings. I don't think it makes sense as long as there is no clash; or until there are many more core modules, so you can't keep them apart anymore. It will just make it harder to follow the git history. -michael
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/17/21 2:35 PM, Pratyush Yadav wrote: > On 17/03/21 06:09AM, tudor.amba...@microchip.com wrote: >> On 3/15/21 8:23 AM, Vignesh Raghavendra wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >>> content is safe >>> >>> On 3/9/21 12:58 PM, tudor.amba...@microchip.com wrote: On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know > the content is safe > > On 3/6/21 3:20 PM, Tudor Ambarus wrote: >> It makes the core file a bit smaller and provides better separation >> between the Software Write Protection features and the core logic. >> All the next generic software write protection features (e.g. Individual >> Block Protection) will reside in swp.c. >> >> Signed-off-by: Tudor Ambarus >> --- >> drivers/mtd/spi-nor/Makefile | 2 +- >> drivers/mtd/spi-nor/core.c | 407 +- >> drivers/mtd/spi-nor/core.h | 4 + >> drivers/mtd/spi-nor/swp.c| 419 +++ > > Hmmm, name swp.c does not seem intuitive to me. How about expanding it a > bit: > > soft-wr-protect.c or software-write-protect.c ? >> >> Having in mind that we have the SWP configs, I think I prefer swp.c. >> But let's see what majority thinks, we'll do as majority prefers. >> Michael, Pratyush? > > I don't have much of an opinion on this tbh. But I usually prefer short > names so I'd go with swp.c here. Maybe also add a comment at the top of > the file mentioning the full name "Software Write Protection logic" or > something similar for clarification. > I don't have hard objection to swp.c. As Pratyush suggested, a comment at top of the file indicating the purpose would be good to have.
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/17/21 10:21 AM, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Am 2021-03-17 07:09, schrieb tudor.amba...@microchip.com: >> On 3/15/21 8:23 AM, Vignesh Raghavendra wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know >>> the content is safe >>> >>> On 3/9/21 12:58 PM, tudor.amba...@microchip.com wrote: On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you > know the content is safe > > On 3/6/21 3:20 PM, Tudor Ambarus wrote: >> It makes the core file a bit smaller and provides better separation >> between the Software Write Protection features and the core logic. >> All the next generic software write protection features (e.g. >> Individual >> Block Protection) will reside in swp.c. >> >> Signed-off-by: Tudor Ambarus >> --- >> drivers/mtd/spi-nor/Makefile | 2 +- >> drivers/mtd/spi-nor/core.c | 407 >> +- >> drivers/mtd/spi-nor/core.h | 4 + >> drivers/mtd/spi-nor/swp.c | 419 >> +++ > > Hmmm, name swp.c does not seem intuitive to me. How about expanding > it a > bit: > > soft-wr-protect.c or software-write-protect.c ? >> >> Having in mind that we have the SWP configs, I think I prefer swp.c. >> But let's see what majority thinks, we'll do as majority prefers. >> Michael, Pratyush? > > It's just an internal name, thus as long as it remotely makes sense, > I'm fine. It's just a matter of taste, isn't it? Sure, it's a matter of preference. What's yours? > > But here's one technical reason that would bother me more: name > clashes between the core modules: core, sfdp, otp, swp and the > vendor names. It is very unlikely, but there is a non-zero chance ;) > We can move all manufacturers to a manufacturers/ folder. Each manufacturer driver will have to #include "../core.h", about what I have some mixed feelings.
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 17/03/21 06:09AM, tudor.amba...@microchip.com wrote: > On 3/15/21 8:23 AM, Vignesh Raghavendra wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > > content is safe > > > > On 3/9/21 12:58 PM, tudor.amba...@microchip.com wrote: > >> On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: > >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know > >>> the content is safe > >>> > >>> On 3/6/21 3:20 PM, Tudor Ambarus wrote: > It makes the core file a bit smaller and provides better separation > between the Software Write Protection features and the core logic. > All the next generic software write protection features (e.g. Individual > Block Protection) will reside in swp.c. > > Signed-off-by: Tudor Ambarus > --- > drivers/mtd/spi-nor/Makefile | 2 +- > drivers/mtd/spi-nor/core.c | 407 +- > drivers/mtd/spi-nor/core.h | 4 + > drivers/mtd/spi-nor/swp.c| 419 +++ > >>> > >>> Hmmm, name swp.c does not seem intuitive to me. How about expanding it a > >>> bit: > >>> > >>> soft-wr-protect.c or software-write-protect.c ? > > Having in mind that we have the SWP configs, I think I prefer swp.c. > But let's see what majority thinks, we'll do as majority prefers. > Michael, Pratyush? I don't have much of an opinion on this tbh. But I usually prefer short names so I'd go with swp.c here. Maybe also add a comment at the top of the file mentioning the full name "Software Write Protection logic" or something similar for clarification. > > >>> > >> > > cut > > > > > I am not a fan of renaming Kconfig options as it breaks make > > olddefconfig flow which many developers rely on. > > > > I'm fine keeping them as they are for now. If someone else screams we will > reconsider. -- Regards, Pratyush Yadav Texas Instruments Inc.
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
Am 2021-03-17 07:09, schrieb tudor.amba...@microchip.com: On 3/15/21 8:23 AM, Vignesh Raghavendra wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On 3/9/21 12:58 PM, tudor.amba...@microchip.com wrote: On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On 3/6/21 3:20 PM, Tudor Ambarus wrote: It makes the core file a bit smaller and provides better separation between the Software Write Protection features and the core logic. All the next generic software write protection features (e.g. Individual Block Protection) will reside in swp.c. Signed-off-by: Tudor Ambarus --- drivers/mtd/spi-nor/Makefile | 2 +- drivers/mtd/spi-nor/core.c | 407 +- drivers/mtd/spi-nor/core.h | 4 + drivers/mtd/spi-nor/swp.c| 419 +++ Hmmm, name swp.c does not seem intuitive to me. How about expanding it a bit: soft-wr-protect.c or software-write-protect.c ? Having in mind that we have the SWP configs, I think I prefer swp.c. But let's see what majority thinks, we'll do as majority prefers. Michael, Pratyush? It's just an internal name, thus as long as it remotely makes sense, I'm fine. It's just a matter of taste, isn't it? But here's one technical reason that would bother me more: name clashes between the core modules: core, sfdp, otp, swp and the vendor names. It is very unlikely, but there is a non-zero chance ;) -michael
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/15/21 8:23 AM, Vignesh Raghavendra wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 3/9/21 12:58 PM, tudor.amba...@microchip.com wrote: >> On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >>> content is safe >>> >>> On 3/6/21 3:20 PM, Tudor Ambarus wrote: It makes the core file a bit smaller and provides better separation between the Software Write Protection features and the core logic. All the next generic software write protection features (e.g. Individual Block Protection) will reside in swp.c. Signed-off-by: Tudor Ambarus --- drivers/mtd/spi-nor/Makefile | 2 +- drivers/mtd/spi-nor/core.c | 407 +- drivers/mtd/spi-nor/core.h | 4 + drivers/mtd/spi-nor/swp.c| 419 +++ >>> >>> Hmmm, name swp.c does not seem intuitive to me. How about expanding it a >>> bit: >>> >>> soft-wr-protect.c or software-write-protect.c ? Having in mind that we have the SWP configs, I think I prefer swp.c. But let's see what majority thinks, we'll do as majority prefers. Michael, Pratyush? >>> >> cut > > I am not a fan of renaming Kconfig options as it breaks make > olddefconfig flow which many developers rely on. > I'm fine keeping them as they are for now. If someone else screams we will reconsider.
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
Am 2021-03-15 07:09, schrieb tudor.amba...@microchip.com:
On 3/6/21 1:19 PM, Michael Walle wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know
the content is safe
Am 2021-03-06 10:50, schrieb Tudor Ambarus:
It makes the core file a bit smaller and provides better separation
between the Software Write Protection features and the core logic.
All the next generic software write protection features (e.g.
Individual
Block Protection) will reside in swp.c.
Signed-off-by: Tudor Ambarus
---
[..]
@@ -3554,6 +3152,9 @@ int spi_nor_scan(struct spi_nor *nor, const
char
*name,
if (ret)
return ret;
+ if (nor->params->locking_ops)
Should this be in spi_nor_register_locking_ops(), too? I.e.
void spi_nor_register_locking_ops() {
if (!nor->params->locking_ops)
return;
..
}
Yes, the checking should be done inside spi_nor_register_locking_ops,
will move it.
Btw, what do you find a better name, spi_nor_register_locking_ops or
spi_nor_init_locking_ops? Applies to OTP as well.
probably register_locking_ops(), as long as the function just does
that.
For OTP, I want to provide nvmem support, too. Thus it will not
only register the mtd ops and thus spi_nor_otp_init() will be
better for my case.
-michael
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 15/03/21 06:09AM, tudor.amba...@microchip.com wrote:
> On 3/6/21 1:19 PM, Michael Walle wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Am 2021-03-06 10:50, schrieb Tudor Ambarus:
> >> It makes the core file a bit smaller and provides better separation
> >> between the Software Write Protection features and the core logic.
> >> All the next generic software write protection features (e.g.
> >> Individual
> >> Block Protection) will reside in swp.c.
> >>
> >> Signed-off-by: Tudor Ambarus
> >> ---
> >
> > [..]
> >
> >> @@ -3554,6 +3152,9 @@ int spi_nor_scan(struct spi_nor *nor, const char
> >> *name,
> >> if (ret)
> >> return ret;
> >>
> >> + if (nor->params->locking_ops)
> >
> > Should this be in spi_nor_register_locking_ops(), too? I.e.
> >
> > void spi_nor_register_locking_ops() {
> > if (!nor->params->locking_ops)
> > return;
> > ..
> > }
>
> Yes, the checking should be done inside spi_nor_register_locking_ops,
> will move it.
>
> Btw, what do you find a better name, spi_nor_register_locking_ops or
> spi_nor_init_locking_ops? Applies to OTP as well.
On a quick glance, spi_nor_register_locking_ops() can be mistaken to
mean "Register locking ops". That is, ops to lock/unlock flash
registers. If you do want to keep using "register", IMO
spi_nor_locking_ops_register() would be better.
>
> Thanks,
> ta
>
> >
> > I don't have a strong opinion on that so far. I just noticed because
> > I put the check into spi_nor_otp_init() for my OTP series. They should
> > be the same though.
> >
> >> + spi_nor_register_locking_ops(nor);
> >
> > -michael
>
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/9/21 12:58 PM, tudor.amba...@microchip.com wrote: > On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >> content is safe >> >> On 3/6/21 3:20 PM, Tudor Ambarus wrote: >>> It makes the core file a bit smaller and provides better separation >>> between the Software Write Protection features and the core logic. >>> All the next generic software write protection features (e.g. Individual >>> Block Protection) will reside in swp.c. >>> >>> Signed-off-by: Tudor Ambarus >>> --- >>> drivers/mtd/spi-nor/Makefile | 2 +- >>> drivers/mtd/spi-nor/core.c | 407 +- >>> drivers/mtd/spi-nor/core.h | 4 + >>> drivers/mtd/spi-nor/swp.c| 419 +++ >> >> Hmmm, name swp.c does not seem intuitive to me. How about expanding it a >> bit: >> >> soft-wr-protect.c or software-write-protect.c ? >> > > I thought about the SWP configs that we have. > > How about keeping swp.c and rename configs to: > s/MTD_SPI_NOR_SWP_DISABLE/MTD_SPI_NOR_DISABLE_BOOT_SWP > s/MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE/MTD_SPI_DISABLE_BOOT_SWP_ON_VOLATILE > s/MTD_SPI_NOR_SWP_KEEP/MTD_SPI_NOR_KEEP_BOOT_SWP > > The renamed configs should better indicate that the software write protection > is disabled just at boot time, while the locking support is still enabled. > Otherwise one may think that with a MTD_SPI_NOR_SWP_DISABLE, all the > software write protection features are stripped/not available. > I am not a fan of renaming Kconfig options as it breaks make olddefconfig flow which many developers rely on. Regards Vignesh
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/6/21 1:19 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Am 2021-03-06 10:50, schrieb Tudor Ambarus:
>> It makes the core file a bit smaller and provides better separation
>> between the Software Write Protection features and the core logic.
>> All the next generic software write protection features (e.g.
>> Individual
>> Block Protection) will reside in swp.c.
>>
>> Signed-off-by: Tudor Ambarus
>> ---
>
> [..]
>
>> @@ -3554,6 +3152,9 @@ int spi_nor_scan(struct spi_nor *nor, const char
>> *name,
>> if (ret)
>> return ret;
>>
>> + if (nor->params->locking_ops)
>
> Should this be in spi_nor_register_locking_ops(), too? I.e.
>
> void spi_nor_register_locking_ops() {
> if (!nor->params->locking_ops)
> return;
> ..
> }
Yes, the checking should be done inside spi_nor_register_locking_ops,
will move it.
Btw, what do you find a better name, spi_nor_register_locking_ops or
spi_nor_init_locking_ops? Applies to OTP as well.
Thanks,
ta
>
> I don't have a strong opinion on that so far. I just noticed because
> I put the check into spi_nor_otp_init() for my OTP series. They should
> be the same though.
>
>> + spi_nor_register_locking_ops(nor);
>
> -michael
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On 3/6/21 3:20 PM, Tudor Ambarus wrote: >> It makes the core file a bit smaller and provides better separation >> between the Software Write Protection features and the core logic. >> All the next generic software write protection features (e.g. Individual >> Block Protection) will reside in swp.c. >> >> Signed-off-by: Tudor Ambarus >> --- >> drivers/mtd/spi-nor/Makefile | 2 +- >> drivers/mtd/spi-nor/core.c | 407 +- >> drivers/mtd/spi-nor/core.h | 4 + >> drivers/mtd/spi-nor/swp.c| 419 +++ > > Hmmm, name swp.c does not seem intuitive to me. How about expanding it a > bit: > > soft-wr-protect.c or software-write-protect.c ? > I thought about the SWP configs that we have. How about keeping swp.c and rename configs to: s/MTD_SPI_NOR_SWP_DISABLE/MTD_SPI_NOR_DISABLE_BOOT_SWP s/MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE/MTD_SPI_DISABLE_BOOT_SWP_ON_VOLATILE s/MTD_SPI_NOR_SWP_KEEP/MTD_SPI_NOR_KEEP_BOOT_SWP The renamed configs should better indicate that the software write protection is disabled just at boot time, while the locking support is still enabled. Otherwise one may think that with a MTD_SPI_NOR_SWP_DISABLE, all the software write protection features are stripped/not available. Cheers, ta
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/6/21 3:20 PM, Tudor Ambarus wrote: > It makes the core file a bit smaller and provides better separation > between the Software Write Protection features and the core logic. > All the next generic software write protection features (e.g. Individual > Block Protection) will reside in swp.c. > > Signed-off-by: Tudor Ambarus > --- > drivers/mtd/spi-nor/Makefile | 2 +- > drivers/mtd/spi-nor/core.c | 407 +- > drivers/mtd/spi-nor/core.h | 4 + > drivers/mtd/spi-nor/swp.c| 419 +++ Hmmm, name swp.c does not seem intuitive to me. How about expanding it a bit: soft-wr-protect.c or software-write-protect.c ? Regards Vignesh
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
Am 2021-03-06 10:50, schrieb Tudor Ambarus:
It makes the core file a bit smaller and provides better separation
between the Software Write Protection features and the core logic.
All the next generic software write protection features (e.g.
Individual
Block Protection) will reside in swp.c.
Signed-off-by: Tudor Ambarus
---
[..]
@@ -3554,6 +3152,9 @@ int spi_nor_scan(struct spi_nor *nor, const char
*name,
if (ret)
return ret;
+ if (nor->params->locking_ops)
Should this be in spi_nor_register_locking_ops(), too? I.e.
void spi_nor_register_locking_ops() {
if (!nor->params->locking_ops)
return;
..
}
I don't have a strong opinion on that so far. I just noticed because
I put the check into spi_nor_otp_init() for my OTP series. They should
be the same though.
+ spi_nor_register_locking_ops(nor);
-michael
[PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
It makes the core file a bit smaller and provides better separation
between the Software Write Protection features and the core logic.
All the next generic software write protection features (e.g. Individual
Block Protection) will reside in swp.c.
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/Makefile | 2 +-
drivers/mtd/spi-nor/core.c | 407 +-
drivers/mtd/spi-nor/core.h | 4 +
drivers/mtd/spi-nor/swp.c| 419 +++
4 files changed, 428 insertions(+), 404 deletions(-)
create mode 100644 drivers/mtd/spi-nor/swp.c
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 653923896205..da05b03f28d2 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
-spi-nor-objs := core.o sfdp.o
+spi-nor-objs := core.o sfdp.o swp.o
spi-nor-objs += atmel.o
spi-nor-objs += catalyst.o
spi-nor-objs += eon.o
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index d12f14aba957..08c9cfd9bcde 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -1730,376 +1730,6 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
return ret;
}
-static u8 spi_nor_get_sr_bp_mask(struct spi_nor *nor)
-{
- u8 mask = SR_BP2 | SR_BP1 | SR_BP0;
-
- if (nor->flags & SNOR_F_HAS_SR_BP3_BIT6)
- return mask | SR_BP3_BIT6;
-
- if (nor->flags & SNOR_F_HAS_4BIT_BP)
- return mask | SR_BP3;
-
- return mask;
-}
-
-static u8 spi_nor_get_sr_tb_mask(struct spi_nor *nor)
-{
- if (nor->flags & SNOR_F_HAS_SR_TB_BIT6)
- return SR_TB_BIT6;
- else
- return SR_TB_BIT5;
-}
-
-static u64 spi_nor_get_min_prot_length_sr(struct spi_nor *nor)
-{
- unsigned int bp_slots, bp_slots_needed;
- u8 mask = spi_nor_get_sr_bp_mask(nor);
-
- /* Reserved one for "protect none" and one for "protect all". */
- bp_slots = (1 << hweight8(mask)) - 2;
- bp_slots_needed = ilog2(nor->info->n_sectors);
-
- if (bp_slots_needed > bp_slots)
- return nor->info->sector_size <<
- (bp_slots_needed - bp_slots);
- else
- return nor->info->sector_size;
-}
-
-static void spi_nor_get_locked_range_sr(struct spi_nor *nor, u8 sr, loff_t
*ofs,
- uint64_t *len)
-{
- struct mtd_info *mtd = >mtd;
- u64 min_prot_len;
- u8 mask = spi_nor_get_sr_bp_mask(nor);
- u8 tb_mask = spi_nor_get_sr_tb_mask(nor);
- u8 bp, val = sr & mask;
-
- if (nor->flags & SNOR_F_HAS_SR_BP3_BIT6 && val & SR_BP3_BIT6)
- val = (val & ~SR_BP3_BIT6) | SR_BP3;
-
- bp = val >> SR_BP_SHIFT;
-
- if (!bp) {
- /* No protection */
- *ofs = 0;
- *len = 0;
- return;
- }
-
- min_prot_len = spi_nor_get_min_prot_length_sr(nor);
- *len = min_prot_len << (bp - 1);
-
- if (*len > mtd->size)
- *len = mtd->size;
-
- if (nor->flags & SNOR_F_HAS_SR_TB && sr & tb_mask)
- *ofs = 0;
- else
- *ofs = mtd->size - *len;
-}
-
-/*
- * Return 1 if the entire region is locked (if @locked is true) or unlocked (if
- * @locked is false); 0 otherwise
- */
-static int spi_nor_check_lock_status_sr(struct spi_nor *nor, loff_t ofs,
- uint64_t len, u8 sr, bool locked)
-{
- loff_t lock_offs;
- uint64_t lock_len;
-
- if (!len)
- return 1;
-
- spi_nor_get_locked_range_sr(nor, sr, _offs, _len);
-
- if (locked)
- /* Requested range is a sub-range of locked range */
- return (ofs + len <= lock_offs + lock_len) && (ofs >=
lock_offs);
- else
- /* Requested range does not overlap with locked range */
- return (ofs >= lock_offs + lock_len) || (ofs + len <=
lock_offs);
-}
-
-static int spi_nor_is_locked_sr(struct spi_nor *nor, loff_t ofs, uint64_t len,
- u8 sr)
-{
- return spi_nor_check_lock_status_sr(nor, ofs, len, sr, true);
-}
-
-static int spi_nor_is_unlocked_sr(struct spi_nor *nor, loff_t ofs, uint64_t
len,
- u8 sr)
-{
- return spi_nor_check_lock_status_sr(nor, ofs, len, sr, false);
-}
-
-/*
- * Lock a region of the flash. Compatible with ST Micro and similar flash.
- * Supports the block protection bits BP{0,1,2}/BP{0,1,2,3} in the status
- * register
- * (SR). Does not support these features found in newer SR bitfields:
- * - SEC: sector/block protect - only handle SEC=0 (block protect)
- * - CMP: complement protect - only support CMP=0 (range is not complemented)
- *
- * Support for the following is provided
