On 1/20/21 5:49 PM, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Am 2021-01-20 16:39, schrieb tudor.amba...@microchip.com: >> 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. > > Doesn't EINVAL indicate wrong parameters, but does nothing? In this > case, unlock would be partially successful. > yes, that's what I said I'll do: "If any block is permanently locked in the unlock_all case, I'll just print a dbg message and return -EINVAL", without sending a GBULK cmd. Caller wrongly asks to unlock all, when we can just unlock partial memory.
It's similar to what is at: https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/tree/drivers/mtd/spi-nor/core.c?h=spi-nor/next#n1946 > In any case, my point was that depending on the underlying locking > ops, either -EIO or -EINVAL is returned if spi_nor_unlock() fails > for the same reason, that is unlock() wasn't possible because of > some sort of hardware write protection. And IMHO it should return > the same errno (whatever the correct errno is in this case). > But the reasons are different: 1/caller wrongly asks to unlock more than we can, thus -EINVAL 2/ -EIO when we don't read what we expect to read. Cheers, ta