drivers/mtd/spi-nor/winbond.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
This series fixes block protection handling for the following Winbond SPI-NOR devices: - w25q256jwm - w25q256jw - w25q64jvm The devices do not correctly describe their Status Register layout and protection capabilities (locking flags, TB bit, BP bit configuration). As a result, the spi-nor core rejects protection requests and locking operations fail with -EINVAL, e.g.: flash_lock -l /dev/mtd29 flash_lock: error!: could not lock device: /dev/mtd29 error 22 (Invalid argument) Update the device flags to match the actual hardware behavior so that locking and unlocking regions work correctly. All changes were validated using flash_lock on the affected devices. Changes in v2: - Remove last patch in series that added dual/quad read for w25q64jvm - Added Minimum testing requirements for w25q256jwm and w25q64jvm Eliav Farber (3): mtd: spi-nor: winbond: Fix locking support for w25q256jwm mtd: spi-nor: winbond: Fix locking support for w25q256jw mtd: spi-nor: winbond: Fix locking support for w25q64jvm drivers/mtd/spi-nor/winbond.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.47.3
On Wed, Feb 18 2026, Eliav Farber wrote: > This series fixes block protection handling for the following Winbond > SPI-NOR devices: > - w25q256jwm > - w25q256jw > - w25q64jvm > > The devices do not correctly describe their Status Register layout and > protection capabilities (locking flags, TB bit, BP bit configuration). > As a result, the spi-nor core rejects protection requests and locking > operations fail with -EINVAL, e.g.: > > flash_lock -l /dev/mtd29 > flash_lock: error!: could not lock device: /dev/mtd29 > error 22 (Invalid argument) > > Update the device flags to match the actual hardware behavior so that > locking and unlocking regions work correctly. > > All changes were validated using flash_lock on the affected devices. Applied patches 1 and 3 to spi-nor/next. Thanks! Skipped patch 2 since you say that you haven't got a device to test with. I don't have a very strong opinion on this, but I do think we should test patches on real hardware just to we get some sanity checking for the patch. [...] -- Regards, Pratyush Yadav
>> The devices do not correctly describe their Status Register layout and >> protection capabilities (locking flags, TB bit, BP bit configuration). >> As a result, the spi-nor core rejects protection requests and locking >> operations fail with -EINVAL, e.g.: >> >> flash_lock -l /dev/mtd29 >> flash_lock: error!: could not lock device: /dev/mtd29 >> error 22 (Invalid argument) >> >> Update the device flags to match the actual hardware behavior so that >> locking and unlocking regions work correctly. >> >> All changes were validated using flash_lock on the affected devices. > > Applied patches 1 and 3 to spi-nor/next. Thanks! > > Skipped patch 2 since you say that you haven't got a device to test > with. I don't have a very strong opinion on this, but I do think we > should test patches on real hardware just to we get some sanity checking > for the patch. Honestly, I am pretty convinced patch 2 cannot make more harm as the block protection is already badly broken by not being described at all. Furthermore, for similar chips I have, these bits are relevant, so I would rather be in favour of going forward with patch 2, because at most it will just not fix the behaviour as it pretends it does. My 2cts :) Miquèl
On Mon, Mar 30 2026, Miquel Raynal wrote: >>> The devices do not correctly describe their Status Register layout and >>> protection capabilities (locking flags, TB bit, BP bit configuration). >>> As a result, the spi-nor core rejects protection requests and locking >>> operations fail with -EINVAL, e.g.: >>> >>> flash_lock -l /dev/mtd29 >>> flash_lock: error!: could not lock device: /dev/mtd29 >>> error 22 (Invalid argument) >>> >>> Update the device flags to match the actual hardware behavior so that >>> locking and unlocking regions work correctly. >>> >>> All changes were validated using flash_lock on the affected devices. >> >> Applied patches 1 and 3 to spi-nor/next. Thanks! >> >> Skipped patch 2 since you say that you haven't got a device to test >> with. I don't have a very strong opinion on this, but I do think we >> should test patches on real hardware just to we get some sanity checking >> for the patch. > > Honestly, I am pretty convinced patch 2 cannot make more harm as the > block protection is already badly broken by not being described at > all. Furthermore, for similar chips I have, these bits are relevant, so > I would rather be in favour of going forward with patch 2, because at > most it will just not fix the behaviour as it pretends it does. > > My 2cts :) Hmm, okay, I'll apply that one too then. -- Regards, Pratyush Yadav
Hi Eliav, On Wed Feb 18, 2026 at 3:35 PM CET, Eliav Farber wrote: > This series fixes block protection handling for the following Winbond > SPI-NOR devices: > - w25q256jwm > - w25q256jw > - w25q64jvm > > The devices do not correctly describe their Status Register layout and > protection capabilities (locking flags, TB bit, BP bit configuration). > As a result, the spi-nor core rejects protection requests and locking > operations fail with -EINVAL, e.g.: > > flash_lock -l /dev/mtd29 > flash_lock: error!: could not lock device: /dev/mtd29 > error 22 (Invalid argument) > > Update the device flags to match the actual hardware behavior so that > locking and unlocking regions work correctly. > > All changes were validated using flash_lock on the affected devices. > > Changes in v2: > - Remove last patch in series that added dual/quad read for w25q64jvm Why? Unfortunately, you didn't answer my questions. > - Added Minimum testing requirements for w25q256jwm and w25q64jvm Thanks, but why was the w25q256jw left out? > Eliav Farber (3): > mtd: spi-nor: winbond: Fix locking support for w25q256jwm > mtd: spi-nor: winbond: Fix locking support for w25q256jw > mtd: spi-nor: winbond: Fix locking support for w25q64jvm You're supposed to pick the Reviewed-by: tags up before sending a new version, see [1]. -michael [1] https://docs.kernel.org/process/submitting-patches.html > > drivers/mtd/spi-nor/winbond.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-)
> > Changes in v2: > > - Remove last patch in series that added dual/quad read for w25q64jvm > > Why? Unfortunately, you didn't answer my questions. The SFDP dump I added indicates that both dual-read and quad-read modes are supported. > > - Added Minimum testing requirements for w25q256jwm and w25q64jvm > > Thanks, but why was the w25q256jw left out? I still haven’t been able to get a card with w25q256jw. Is it needed in order to add the lock flags? --- Regards, Eliav
On Thu Feb 19, 2026 at 9:59 AM CET, Eliav Farber wrote: >> > Changes in v2: >> > - Remove last patch in series that added dual/quad read for w25q64jvm >> >> Why? Unfortunately, you didn't answer my questions. > > The SFDP dump I added indicates that both dual-read and quad-read modes > are supported. That was already the case for your initial submission. So what has changed? If you're a bit more verbose in the changelog, that would make things much easier for us reviewers. >> > - Added Minimum testing requirements for w25q256jwm and w25q64jvm >> >> Thanks, but why was the w25q256jw left out? > > I still haven’t been able to get a card with w25q256jw. > Is it needed in order to add the lock flags? Not from my side, other maintainers may disagree. I'm more interested in the SFDP dump. In any case, you already have my Reviewed-by. -michael
© 2016 - 2026 Red Hat, Inc.