On 1/20/21 5:02 PM, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Am 2021-01-20 15:52, schrieb tudor.amba...@microchip.com: >> On 1/20/21 4:05 PM, Michael Walle wrote: >>>> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c >>>> index 00e48da0744a..d6e1396abb96 100644 >>>> --- a/drivers/mtd/spi-nor/sst.c >>>> +++ b/drivers/mtd/spi-nor/sst.c >>>> @@ -8,6 +8,39 @@ >>>> >>>> #include "core.h" >>>> >>>> +static int sst26vf_lock(struct spi_nor *nor, loff_t ofs, uint64_t >>>> len) >>>> +{ >>>> + return -EOPNOTSUPP; >>>> +} >>>> + >>>> +static int sst26vf_unlock(struct spi_nor *nor, loff_t ofs, uint64_t >>>> len) >>>> +{ >>>> + if (ofs == 0 && len == nor->params->size) >>>> + return spi_nor_global_block_unlock(nor); >>> >>> >>> Some blocks might not be unlocked because they are permanently >>> locked. Does it make sense to read BPNV of the control register >>> and add a debug message here? >> >> It would, yes. If any block is permanently locked in the unlock_all >> case, >> I'll just print a dbg message and return -EINVAL. Sounds good? > > spi_nor_sr_unlock(), atmel_at25fs_unlock() and atmel_global_unprotect() > will return -EIO in case the SR wasn't writable.
You mean in the spi_nor_write_sr_and_check() calls. -EIO is fine there if what we wrote is different than what we read back, it would indicate an IO error. GBULK command clears all the write-protection bits in the Block Protection register, except for those bits that have been permanently locked down. So even if we have few blocks permanently locked, i.e. CR.BPNV == 1, the GBULK can clear the protection for the remaining blocks. So not really an IO error, but rather an -EINVAL, because the user asks to unlock more than we can. Cheers, ta