* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Jim Mattson @ 2026-04-03 18:10 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm, Asit Mallick,
Tao Zhang, bpf, netdev, linux-doc
In-Reply-To: <20260402-vmscape-bhb-v9-2-94d16bc29774@linux.intel.com>
On Thu, Apr 2, 2026 at 5:32 PM Pawan Gupta
<pawan.kumar.gupta@linux.intel.com> wrote:
>
> As a mitigation for BHI, clear_bhb_loop() executes branches that overwrite
> the Branch History Buffer (BHB). On Alder Lake and newer parts this
> sequence is not sufficient because it doesn't clear enough entries. This
> was not an issue because these CPUs use the BHI_DIS_S hardware mitigation
> in the kernel.
>
> Now with VMSCAPE (BHI variant) it is also required to isolate branch
> history between guests and userspace. Since BHI_DIS_S only protects the
> kernel, the newer CPUs also use IBPB.
>
> A cheaper alternative to the current IBPB mitigation is clear_bhb_loop().
> But it currently does not clear enough BHB entries to be effective on newer
> CPUs with larger BHB. At boot, dynamically set the loop count of
> clear_bhb_loop() such that it is effective on newer CPUs too. Use the
> X86_FEATURE_BHI_CTRL feature flag to select the appropriate loop count.
>
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
> arch/x86/entry/entry_64.S | 8 +++++---
> arch/x86/include/asm/nospec-branch.h | 2 ++
> arch/x86/kernel/cpu/bugs.c | 13 +++++++++++++
> 3 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 3a180a36ca0e..bbd4b1c7ec04 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -1536,7 +1536,9 @@ SYM_FUNC_START(clear_bhb_loop)
> ANNOTATE_NOENDBR
> push %rbp
> mov %rsp, %rbp
> - movl $5, %ecx
> +
> + movzbl bhb_seq_outer_loop(%rip), %ecx
> +
> ANNOTATE_INTRA_FUNCTION_CALL
> call 1f
> jmp 5f
> @@ -1556,8 +1558,8 @@ SYM_FUNC_START(clear_bhb_loop)
> * This should be ideally be: .skip 32 - (.Lret2 - 2f), 0xcc
> * but some Clang versions (e.g. 18) don't like this.
> */
> - .skip 32 - 18, 0xcc
> -2: movl $5, %eax
> + .skip 32 - 20, 0xcc
> +2: movzbl bhb_seq_inner_loop(%rip), %eax
> 3: jmp 4f
> nop
> 4: sub $1, %eax
> diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> index 70b377fcbc1c..87b83ae7c97f 100644
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -548,6 +548,8 @@ DECLARE_PER_CPU(u64, x86_spec_ctrl_current);
> extern void update_spec_ctrl_cond(u64 val);
> extern u64 spec_ctrl_current(void);
>
> +extern u8 bhb_seq_inner_loop, bhb_seq_outer_loop;
> +
> /*
> * With retpoline, we must use IBRS to restrict branch prediction
> * before calling into firmware.
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 83f51cab0b1e..2cb4a96247d8 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -2047,6 +2047,10 @@ enum bhi_mitigations {
> static enum bhi_mitigations bhi_mitigation __ro_after_init =
> IS_ENABLED(CONFIG_MITIGATION_SPECTRE_BHI) ? BHI_MITIGATION_AUTO : BHI_MITIGATION_OFF;
>
> +/* Default to short BHB sequence values */
> +u8 bhb_seq_outer_loop __ro_after_init = 5;
> +u8 bhb_seq_inner_loop __ro_after_init = 5;
> +
> static int __init spectre_bhi_parse_cmdline(char *str)
> {
> if (!str)
> @@ -3242,6 +3246,15 @@ void __init cpu_select_mitigations(void)
> x86_spec_ctrl_base &= ~SPEC_CTRL_MITIGATIONS_MASK;
> }
>
> + /*
> + * Switch to long BHB clear sequence on newer CPUs (with BHI_CTRL
> + * support), see Intel's BHI guidance.
> + */
> + if (cpu_feature_enabled(X86_FEATURE_BHI_CTRL)) {
> + bhb_seq_outer_loop = 12;
> + bhb_seq_inner_loop = 7;
> + }
> +
How does this work for VMs in a heterogeneous migration pool that
spans the Alder Lake boundary? They can't advertise BHI_CTRL, because
it isn't available on all hosts in the migration pool, but they need
the long sequence when running on Alder Lake or newer.
Previously, I considered such a migration pool infeasible, because of
the change in MAXPHYADDR, but I now predict that I will lose that
battle.
> x86_arch_cap_msr = x86_read_arch_cap_msr();
>
> cpu_print_attack_vectors();
>
> --
> 2.34.1
>
>
>
^ permalink raw reply
* Re: [PATCH v9 07/10] x86/vmscape: Use static_call() for predictor flush
From: Pawan Gupta @ 2026-04-03 17:26 UTC (permalink / raw)
To: Sean Christopherson, Borislav Petkov
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Dave Hansen, Peter Zijlstra, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, KP Singh, Jiri Olsa,
David S. Miller, David Laight, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, David Ahern, Martin KaFai Lau, Eduard Zingerman,
Song Liu, Yonghong Song, John Fastabend, Stanislav Fomichev,
Hao Luo, Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm,
Asit Mallick, Tao Zhang, bpf, netdev, linux-doc
In-Reply-To: <20260403164432.ltnr5oupddscwaqu@desk>
On Fri, Apr 03, 2026 at 09:44:32AM -0700, Pawan Gupta wrote:
> On Fri, Apr 03, 2026 at 07:52:23AM -0700, Sean Christopherson wrote:
> > On Thu, Apr 02, 2026, Pawan Gupta wrote:
> > > --- a/arch/x86/kvm/x86.c
> > > +++ b/arch/x86/kvm/x86.c
> > > @@ -11463,7 +11463,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> > > * set for the CPU that actually ran the guest, and not the CPU that it
> > > * may migrate to.
> > > */
> > > - if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
> > > + if (vmscape_mitigation_enabled())
> >
> > This is pretty lame. It turns a statically patched MOV
>
> Yes it is, this was done ...
>
> > 11548 if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
> > 11549 this_cpu_write(x86_ibpb_exit_to_user, true);
> > 0x000000000003c57a <+858>: movb $0x1,%gs:0x0(%rip) # 0x3c582 <vcpu_enter_guest+866>
> >
> > into a function call and two sets of conditional branches. And with mitigations
> > enabled, that function call may trigger the wonderful unret insanity
> >
> > 11548 if (vmscape_mitigation_enabled())
> > 0x000000000003c575 <+853>: call 0x3c57a <vcpu_enter_guest+858>
> > 0x000000000003c57a <+858>: test %al,%al
> > 0x000000000003c57c <+860>: je 0x3c586 <vcpu_enter_guest+870>
> >
> > 11549 this_cpu_write(x86_predictor_flush_exit_to_user, true);
> > 0x000000000003c57e <+862>: movb $0x1,%gs:0x0(%rip) # 0x3c586 <vcpu_enter_guest+870>
> >
> >
> > 3166 {
> > 0xffffffff81285320 <+0>: endbr64
> > 0xffffffff81285324 <+4>: call 0xffffffff812aa5a0 <__fentry__>
> >
> > 3167 return !!static_call_query(vmscape_predictor_flush);
> > 0xffffffff81285329 <+9>: mov 0x13a4f30(%rip),%rax # 0xffffffff8262a260 <__SCK__vmscape_predictor_flush>
> > 0xffffffff81285330 <+16>: test %rax,%rax
> > 0xffffffff81285333 <+19>: setne %al
> >
> > 3168 }
> > 0xffffffff81285336 <+22>: jmp 0xffffffff81db1e30 <__x86_return_thunk>
> >
> > While this isn't KVM's super hot inner run loop, it's still very much a hot path.
> > Even more annoying, KVM will eat the function call on kernels with CPU_MITIGATIONS=n.
> >
> > I'd like to at least do something like the below to make the common case of
> > multiple guest entry/exits more or less free, and to avoid the CALL+(UN)RET
> > overhead, but trying to include linux/static_call.h in processor.h (or any other
> > core x86 header) creates a cyclical dependency :-/
> >
> > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> > index 20ab4dd588c6..0dc0680a80f8 100644
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -36,6 +36,7 @@ struct vm86;
> > #include <linux/err.h>
> > #include <linux/irqflags.h>
> > #include <linux/mem_encrypt.h>
> > +#include <linux/static_call.h>
> >
> > /*
> > * We handle most unaligned accesses in hardware. On the other hand
> > @@ -753,7 +754,11 @@ enum mds_mitigations {
> > };
> >
> > extern bool gds_ucode_mitigated(void);
> > -extern bool vmscape_mitigation_enabled(void);
> > +
> > +static inline bool vmscape_mitigation_enabled(void)
> > +{
> > + return !!static_call_query(vmscape_predictor_flush);
> > +}
> >
> > /*
> > * Make previous memory operations globally visible before
> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > index 366ebe1e1fb9..02bf626f0773 100644
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
> > @@ -148,6 +148,7 @@ DEFINE_STATIC_KEY_FALSE(switch_mm_cond_l1d_flush);
> > * sequence. This defaults to no mitigation.
> > */
> > DEFINE_STATIC_CALL_NULL(vmscape_predictor_flush, write_ibpb);
> > +EXPORT_STATIC_CALL_GPL(vmscape_predictor_flush);
>
> ... to avoid exporting the static key, so that modules (other than KVM)
> cannot do static_call_update(vmscape_predictor_flush).
>
> Peter suggested changes that allowed adding EXPORT_STATIC_CALL_FOR_KVM():
>
> https://lore.kernel.org/all/20260319214409.GL3738786@noisy.programming.kicks-ass.net/
Sorry, this is the correct link for EXPORT_STATIC_CALL_FOR_KVM():
https://lore.kernel.org/all/20260320062206.bdrnmnvho6lhmejw@desk/
> EXPORT_STATIC_CALL_FOR_KVM() seems to be a cleaner approach to me.
>
> Boris, I know you didn't like exporting the static_key. But, as Sean said
> this is a hot path, and avoiding the unnecessary call would benefit all
> CPUs (affected or unaffected). Moreover, EXPORT_STATIC_CALL_FOR_KVM()
> somewhat addresses your concern of exporting the static_key to the world.
> Would you be okay with it?
^ permalink raw reply
* Re: [PATCH v3 02/24] PCI: Add API to track PCI devices preserved across Live Update
From: Chris Li @ 2026-04-03 17:24 UTC (permalink / raw)
To: Yanjun.Zhu
Cc: David Matlack, Alex Williamson, Bjorn Helgaas,
Adithya Jayachandran, Alexander Graf, Alex Mastro, Andrew Morton,
Ankit Agrawal, Arnd Bergmann, Askar Safin, Borislav Petkov (AMD),
Dapeng Mi, David Rientjes, Feng Tang, Jacob Pan, Jason Gunthorpe,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Kees Cook,
Kevin Tian, kexec, kvm, Leon Romanovsky, Leon Romanovsky,
linux-doc, linux-kernel, linux-kselftest, linux-mm, linux-pci,
Li RongQing, Lukas Wunner, Marco Elver, Michał Winiarski,
Mike Rapoport, Parav Pandit, Pasha Tatashin, Paul E. McKenney,
Pawan Gupta, Peter Zijlstra (Intel), Pranjal Shrivastava,
Pratyush Yadav, Raghavendra Rao Ananta, Randy Dunlap,
Rodrigo Vivi, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, Vivek Kasireddy, William Tu, Yi Liu
In-Reply-To: <e3fe7085-1297-47b8-bb17-a48196e8f37f@linux.dev>
On Thu, Apr 2, 2026 at 2:29 PM Yanjun.Zhu <yanjun.zhu@linux.dev> wrote:
> > +config PCI_LIVEUPDATE
> > + bool "PCI Live Update Support (EXPERIMENTAL)"
> > + depends on PCI && LIVEUPDATE
> > + help
> > + Support for preserving PCI devices across a Live Update. This option
> > + should only be enabled by developers working on implementing this
> > + support. Once enough support as landed in the kernel, this option
> > + will no longer be marked EXPERIMENTAL.
> > +
> > + If unsure, say N.
>
> Currently, it only supports 'n' or 'y'. Is it possible to add 'm'
> (modular support)?
>
> This would allow the feature to be built as a kernel module. For
> development
>
> purposes, modularization means we only need to recompile a single module
>
> for testing, rather than rebuilding the entire kernel. Compiling a
> module should
>
> be significantly faster than a full kernel build.
Building as a module has extra complexity to handle, e.g. the callback
can happen when the module hasn't been loaded. Then the user space can
take an arbitrarily long time to load the module.
It needs more infrastructure to support the liveupdate as a module.
Chris
^ permalink raw reply
* Re: [PATCH v6 2/2] PCI: s390: Expose the UID as an arch specific PCI slot attribute
From: Farhan Ali @ 2026-04-03 17:19 UTC (permalink / raw)
To: Niklas Schnelle, Bjorn Helgaas, Jonathan Corbet, Lukas Wunner,
Shuah Khan
Cc: Alexander Gordeev, Christian Borntraeger, Gerald Schaefer,
Gerd Bayer, Heiko Carstens, Julian Ruess, Matthew Rosato,
Peter Oberparleiter, Ramesh Errabolu, Sven Schnelle,
Vasily Gorbik, linux-doc, linux-kernel, linux-pci, linux-s390
In-Reply-To: <20260402-uid_slot-v6-2-d5ea0a14ddb9@linux.ibm.com>
On 4/2/2026 1:34 PM, Niklas Schnelle wrote:
> On s390, an individual PCI function can generally be identified by two
> identifiers, the FID and the UID. Which identifier is used depends on
> the scope and the platform configuration.
>
> The first identifier, the FID, is always available and identifies a PCI
> device uniquely within a machine. The FID may be virtualized by
> hypervisors, but on the LPAR level, the machine scope makes it
> impossible to create the same configuration based on FIDs on two
> different LPARs of the same machine, and difficult to reuse across
> machines.
>
> Such matching LPAR configurations are useful, though, allowing
> standardized setups and booting a Linux installation on different LPARs.
> To this end the UID, or user-defined identifier, was introduced. While
> it is only guaranteed to be unique within an LPAR and only if indicated
> by firmware, it allows users to replicate PCI device setups.
>
> On s390, which uses a machine hypervisor, a per PCI function hotplug
> model is used. The shortcoming with the UID then is, that it is not
> visible to the user without first attaching the PCI function and
> accessing the "uid" device attribute. The FID, on the other hand, is
> used as the slot name and is thus known even with the PCI function in
> standby.
>
> Remedy this shortcoming by providing the UID as an attribute on the slot
> allowing the user to identify a PCI function based on the UID without
> having to first attach it. Do this via a macro mechanism analogous to
> what was introduced by commit 265baca69a07 ("s390/pci: Stop usurping
> pdev->dev.groups") for the PCI device attributes.
>
> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
> Reviewed-by: Julian Ruess <julianr@linux.ibm.com>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---
> Documentation/arch/s390/pci.rst | 7 +++++++
> arch/s390/include/asm/pci.h | 4 ++++
> arch/s390/pci/pci_sysfs.c | 20 ++++++++++++++++++++
> drivers/pci/slot.c | 13 ++++++++++++-
> 4 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/arch/s390/pci.rst b/Documentation/arch/s390/pci.rst
> index 31c24ed5506f1fc07f89821f67a814118514f441..4c0f35c8a5588eee3cf0d596e0057f24b3ed079c 100644
> --- a/Documentation/arch/s390/pci.rst
> +++ b/Documentation/arch/s390/pci.rst
> @@ -57,6 +57,13 @@ Entries specific to zPCI functions and entries that hold zPCI information.
>
> - /sys/bus/pci/slots/XXXXXXXX/power
>
> + In addition to using the FID as the name of the slot the slot directory
> + also contains the following s390 specific slot attributes.
> +
> + - uid:
> + The User-defined identifier (UID) of the function which may be configured
> + by this slot. See also the corresponding attribute of the device.
> +
> A physical function that currently supports a virtual function cannot be
> powered off until all virtual functions are removed with:
> echo 0 > /sys/bus/pci/devices/DDDD:BB:dd.f/sriov_numvf
> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
> index c0ff19dab5807c7e1aabb48a0e9436aac45ec97d..5dcf35f0f325f5f44b28109a1c8d9aef18401035 100644
> --- a/arch/s390/include/asm/pci.h
> +++ b/arch/s390/include/asm/pci.h
> @@ -208,6 +208,10 @@ extern const struct attribute_group zpci_ident_attr_group;
> &pfip_attr_group, \
> &zpci_ident_attr_group,
>
> +extern const struct attribute_group zpci_slot_attr_group;
> +
> +#define ARCH_PCI_SLOT_GROUPS (&zpci_slot_attr_group)
> +
> extern unsigned int s390_pci_force_floating __initdata;
> extern unsigned int s390_pci_no_rid;
>
> diff --git a/arch/s390/pci/pci_sysfs.c b/arch/s390/pci/pci_sysfs.c
> index c2444a23e26c4218832bb91930b5f0ffd498d28f..d98d97df792adb3c7e415a8d374cc2f3a65fbb52 100644
> --- a/arch/s390/pci/pci_sysfs.c
> +++ b/arch/s390/pci/pci_sysfs.c
> @@ -187,6 +187,17 @@ static ssize_t index_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(index);
>
> +static ssize_t zpci_uid_slot_show(struct pci_slot *slot, char *buf)
> +{
> + struct zpci_dev *zdev = container_of(slot->hotplug, struct zpci_dev,
> + hotplug_slot);
> +
> + return sysfs_emit(buf, "0x%x\n", zdev->uid);
> +}
I think the way we assign the same pci slot to multifunctions (PF and VF
on the same LPAR), IIUC we could possibly display the wrong uid here. I
am hoping my patch [1] can fix this. I am curious, is there any
s390-tool that would use the uid? Though this would only impact the NETD
devices on newer machines, so I don't know if we want to gate this
behind my patch?
[1] https://lore.kernel.org/all/20260330174011.1161-2-alifm@linux.ibm.com/
Thanks
Farhan
> +
> +static struct pci_slot_attribute zpci_slot_attr_uid =
> + __ATTR(uid, 0444, zpci_uid_slot_show, NULL);
> +
> static umode_t zpci_index_is_visible(struct kobject *kobj,
> struct attribute *attr, int n)
> {
> @@ -243,6 +254,15 @@ const struct attribute_group pfip_attr_group = {
> .attrs = pfip_attrs,
> };
>
> +static struct attribute *zpci_slot_attrs[] = {
> + &zpci_slot_attr_uid.attr,
> + NULL,
> +};
> +
> +const struct attribute_group zpci_slot_attr_group = {
> + .attrs = zpci_slot_attrs,
> +};
> +
> static struct attribute *clp_fw_attrs[] = {
> &uid_checking_attr.attr,
> NULL,
> diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
> index 787311614e5b6ebb39e7284f9b9f205a0a684d6d..2f8fcfbbec24e73d0bb6e40fd04c05a94f518045 100644
> --- a/drivers/pci/slot.c
> +++ b/drivers/pci/slot.c
> @@ -96,7 +96,18 @@ static struct attribute *pci_slot_default_attrs[] = {
> &pci_slot_attr_cur_speed.attr,
> NULL,
> };
> -ATTRIBUTE_GROUPS(pci_slot_default);
> +
> +static const struct attribute_group pci_slot_default_group = {
> + .attrs = pci_slot_default_attrs,
> +};
> +
> +static const struct attribute_group *pci_slot_default_groups[] = {
> + &pci_slot_default_group,
> +#ifdef ARCH_PCI_SLOT_GROUPS
> + ARCH_PCI_SLOT_GROUPS,
> +#endif
> + NULL,
> +};
>
> static const struct kobj_type pci_slot_ktype = {
> .sysfs_ops = &pci_slot_sysfs_ops,
>
^ permalink raw reply
* Re: [PATCH v9 01/10] x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop()
From: Borislav Petkov @ 2026-04-03 17:11 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260403164552.chdvvmdfaufcgxzo@desk>
On Fri, Apr 03, 2026 at 09:45:52AM -0700, Pawan Gupta wrote:
> Thanks.
You don't have to say "thanks" to every review - we're one big family.
:-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v6 1/2] docs: s390/pci: Improve and update PCI documentation
From: Farhan Ali @ 2026-04-03 16:54 UTC (permalink / raw)
To: Niklas Schnelle, Bjorn Helgaas, Jonathan Corbet, Lukas Wunner,
Shuah Khan
Cc: Alexander Gordeev, Christian Borntraeger, Gerald Schaefer,
Gerd Bayer, Heiko Carstens, Julian Ruess, Matthew Rosato,
Peter Oberparleiter, Ramesh Errabolu, Sven Schnelle,
Vasily Gorbik, linux-doc, linux-kernel, linux-pci, linux-s390
In-Reply-To: <20260402-uid_slot-v6-1-d5ea0a14ddb9@linux.ibm.com>
On 4/2/2026 1:34 PM, Niklas Schnelle wrote:
> Update the s390 specific PCI documentation to better reflect current
> behavior and terms such as the handling of Isolated VFs via commit
> 25f39d3dcb48 ("s390/pci: Ignore RID for isolated VFs").
>
> Add a descriptions for /sys/firmware/clp/uid_is_unique which was added
> in commit b043a81ce3ee ("s390/pci: Expose firmware provided UID Checking
> state in sysfs") but missed documentation.
>
> Similarly add documentation for the fidparm attribute added by commit
> 99ad39306a62 ("s390/pci: Expose FIDPARM attribute in sysfs") and
> add a list of pft values and their names.
>
> Finally improve formatting of the different attribute descriptions by
> adding a separating colon.
>
> Signed-off-by: Niklas Schnelle<schnelle@linux.ibm.com>
> ---
> Documentation/arch/s390/pci.rst | 139 +++++++++++++++++++++++++++-------------
> 1 file changed, 94 insertions(+), 45 deletions(-)
Thanks for updating this! I wonder if we should update this
documentation to better explain some of the nuances of PCI on s390, or
more like "intro to zpci". But that could be a separate thing.
Reviewed-by: Farhan Ali<alifm@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v9 01/10] x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop()
From: Pawan Gupta @ 2026-04-03 16:45 UTC (permalink / raw)
To: Borislav Petkov
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260403151630.GWac_ZzhQZj5LUDlRf@fat_crate.local>
On Fri, Apr 03, 2026 at 05:16:30PM +0200, Borislav Petkov wrote:
> On Thu, Apr 02, 2026 at 05:30:47PM -0700, Pawan Gupta wrote:
> > Currently, the BHB clearing sequence is followed by an LFENCE to prevent
> > transient execution of subsequent indirect branches prematurely. However,
> > the LFENCE barrier could be unnecessary in certain cases. For example, when
> > the kernel is using the BHI_DIS_S mitigation, and BHB clearing is only
> > needed for userspace. In such cases, the LFENCE is redundant because ring
> > transitions would provide the necessary serialization.
> >
> > Below is a quick recap of BHI mitigation options:
> >
> > On Alder Lake and newer
> >
> > BHI_DIS_S: Hardware control to mitigate BHI in ring0. This has low
> > performance overhead.
> >
> > Long loop: Alternatively, a longer version of the BHB clearing sequence
> > can be used to mitigate BHI. It can also be used to mitigate the BHI
> > variant of VMSCAPE. This is not yet implemented in Linux.
> >
> > On older CPUs
> >
> > Short loop: Clears BHB at kernel entry and VMexit. The "Long loop" is
> > effective on older CPUs as well, but should be avoided because of
> > unnecessary overhead.
> >
> > On Alder Lake and newer CPUs, eIBRS isolates the indirect targets between
> > guest and host. But when affected by the BHI variant of VMSCAPE, a guest's
> > branch history may still influence indirect branches in userspace. This
> > also means the big hammer IBPB could be replaced with a cheaper option that
> > clears the BHB at exit-to-userspace after a VMexit.
> >
> > In preparation for adding the support for the BHB sequence (without LFENCE)
> > on newer CPUs, move the LFENCE to the caller side after clear_bhb_loop() is
> > executed. Allow callers to decide whether they need the LFENCE or not. This
> > adds a few extra bytes to the call sites, but it obviates the need for
> > multiple variants of clear_bhb_loop().
> >
> > Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> > Tested-by: Jon Kohler <jon@nutanix.com>
> > Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > ---
> > arch/x86/entry/entry_64.S | 5 ++++-
> > arch/x86/include/asm/nospec-branch.h | 4 ++--
> > arch/x86/net/bpf_jit_comp.c | 2 ++
> > 3 files changed, 8 insertions(+), 3 deletions(-)
>
> Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
Thanks.
^ permalink raw reply
* Re: [PATCH v9 07/10] x86/vmscape: Use static_call() for predictor flush
From: Pawan Gupta @ 2026-04-03 16:44 UTC (permalink / raw)
To: Sean Christopherson
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <ac_UJx99kDJY8j3t@google.com>
On Fri, Apr 03, 2026 at 07:52:23AM -0700, Sean Christopherson wrote:
> On Thu, Apr 02, 2026, Pawan Gupta wrote:
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -11463,7 +11463,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> > * set for the CPU that actually ran the guest, and not the CPU that it
> > * may migrate to.
> > */
> > - if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
> > + if (vmscape_mitigation_enabled())
>
> This is pretty lame. It turns a statically patched MOV
Yes it is, this was done ...
> 11548 if (cpu_feature_enabled(X86_FEATURE_IBPB_EXIT_TO_USER))
> 11549 this_cpu_write(x86_ibpb_exit_to_user, true);
> 0x000000000003c57a <+858>: movb $0x1,%gs:0x0(%rip) # 0x3c582 <vcpu_enter_guest+866>
>
> into a function call and two sets of conditional branches. And with mitigations
> enabled, that function call may trigger the wonderful unret insanity
>
> 11548 if (vmscape_mitigation_enabled())
> 0x000000000003c575 <+853>: call 0x3c57a <vcpu_enter_guest+858>
> 0x000000000003c57a <+858>: test %al,%al
> 0x000000000003c57c <+860>: je 0x3c586 <vcpu_enter_guest+870>
>
> 11549 this_cpu_write(x86_predictor_flush_exit_to_user, true);
> 0x000000000003c57e <+862>: movb $0x1,%gs:0x0(%rip) # 0x3c586 <vcpu_enter_guest+870>
>
>
> 3166 {
> 0xffffffff81285320 <+0>: endbr64
> 0xffffffff81285324 <+4>: call 0xffffffff812aa5a0 <__fentry__>
>
> 3167 return !!static_call_query(vmscape_predictor_flush);
> 0xffffffff81285329 <+9>: mov 0x13a4f30(%rip),%rax # 0xffffffff8262a260 <__SCK__vmscape_predictor_flush>
> 0xffffffff81285330 <+16>: test %rax,%rax
> 0xffffffff81285333 <+19>: setne %al
>
> 3168 }
> 0xffffffff81285336 <+22>: jmp 0xffffffff81db1e30 <__x86_return_thunk>
>
> While this isn't KVM's super hot inner run loop, it's still very much a hot path.
> Even more annoying, KVM will eat the function call on kernels with CPU_MITIGATIONS=n.
>
> I'd like to at least do something like the below to make the common case of
> multiple guest entry/exits more or less free, and to avoid the CALL+(UN)RET
> overhead, but trying to include linux/static_call.h in processor.h (or any other
> core x86 header) creates a cyclical dependency :-/
>
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 20ab4dd588c6..0dc0680a80f8 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -36,6 +36,7 @@ struct vm86;
> #include <linux/err.h>
> #include <linux/irqflags.h>
> #include <linux/mem_encrypt.h>
> +#include <linux/static_call.h>
>
> /*
> * We handle most unaligned accesses in hardware. On the other hand
> @@ -753,7 +754,11 @@ enum mds_mitigations {
> };
>
> extern bool gds_ucode_mitigated(void);
> -extern bool vmscape_mitigation_enabled(void);
> +
> +static inline bool vmscape_mitigation_enabled(void)
> +{
> + return !!static_call_query(vmscape_predictor_flush);
> +}
>
> /*
> * Make previous memory operations globally visible before
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 366ebe1e1fb9..02bf626f0773 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -148,6 +148,7 @@ DEFINE_STATIC_KEY_FALSE(switch_mm_cond_l1d_flush);
> * sequence. This defaults to no mitigation.
> */
> DEFINE_STATIC_CALL_NULL(vmscape_predictor_flush, write_ibpb);
> +EXPORT_STATIC_CALL_GPL(vmscape_predictor_flush);
... to avoid exporting the static key, so that modules (other than KVM)
cannot do static_call_update(vmscape_predictor_flush).
Peter suggested changes that allowed adding EXPORT_STATIC_CALL_FOR_KVM():
https://lore.kernel.org/all/20260319214409.GL3738786@noisy.programming.kicks-ass.net/
EXPORT_STATIC_CALL_FOR_KVM() seems to be a cleaner approach to me.
Boris, I know you didn't like exporting the static_key. But, as Sean said
this is a hot path, and avoiding the unnecessary call would benefit all
CPUs (affected or unaffected). Moreover, EXPORT_STATIC_CALL_FOR_KVM()
somewhat addresses your concern of exporting the static_key to the world.
Would you be okay with it?
^ permalink raw reply
* Re: [PATCH v8 0/3] Support runtime configuration for per-VM's HGATP mode
From: Anup Patel @ 2026-04-03 16:43 UTC (permalink / raw)
To: fangyu.yu
Cc: pbonzini, corbet, atish.patra, pjw, palmer, aou, alex, skhan,
guoren, radim.krcmar, andrew.jones, linux-doc, kvm, kvm-riscv,
linux-riscv, linux-kernel
In-Reply-To: <20260403153019.9916-1-fangyu.yu@linux.alibaba.com>
On Fri, Apr 3, 2026 at 9:00 PM <fangyu.yu@linux.alibaba.com> wrote:
>
> From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>
> Currently, RISC-V KVM hardcodes the G-stage page table format (HGATP mode)
> to the maximum mode detected at boot time (e.g., SV57x4 if supported). but
> often such a wide GPA is unnecessary, just as a host sometimes doesn't need
> sv57.
>
> This patch reuse KVM_CAP_VM_GPA_BITS to select HGATP.MODE. User-space can
> now explicitly request a specific HGATP mode (SV39x4, SV48x4, SV57x4 or
> SV32x4) during VM creation.
>
> ---
> Changes in v8:
> - Reuse KVM_CAP_VM_GPA_BITS to advertise and select the effective GPA width
> for a VM (Anup's suggestion).
> - Handle the kvm == NULL case and task kvm->lock and kvm->slots_lock to serialize
> against concurrent vCPU creation and memslot updates (Radim's suggestion).
> - Link to v7:
> https://lore.kernel.org/linux-riscv/20260402132303.6252-1-fangyu.yu@linux.alibaba.com/
> ---
> Changes in v7 (Anup's suggestions):
> - Keep the original HGATP mode probing logic.
> - Link to v6:
> https://lore.kernel.org/linux-riscv/20260330122601.22140-1-fangyu.yu@linux.alibaba.com/
> ---
> Changes in v6 (Anup's suggestions):
> - Reworked kvm_riscv_gstage_gpa_bits() and kvm_riscv_gstage_gpa_size() to
> take "unsigned long pgd_levels" instead of "struct kvm_arch *".
> - Moved kvm_riscv_gstage_mode() helper from kvm_host.h to kvm_gstage.h.
> - Renamed kvm->arch.kvm_riscv_gstage_pgd_levels to kvm->arch.pgd_levels.
> - Added pgd_levels to struct kvm_gstage to avoid repeated
> gstage->kvm->arch pointer chasing.
> - Link to v5:
> https://lore.kernel.org/linux-riscv/20260204134507.33912-1-fangyu.yu@linux.alibaba.com/
> ---
> Changes in v5:
> - Use architectural HGATP.MODE encodings as the bit index for the supported-mode
> bitmap and for the VM-mode selection UAPI; no new UAPI mode/bit defines are
> introduced(per Radim).
> - Allow KVM_CAP_RISCV_SET_HGATP_MODE on RV32 as well(per Drew).
> - Link to v4:
> https://lore.kernel.org/linux-riscv/20260202140716.34323-1-fangyu.yu@linux.alibaba.com/
> ---
> Changes in v4:
> - Extend kvm_riscv_gstage_mode_detect() to probe all HGATP.MODE values
> supported by the host and record them in a bitmask.
> - Treat unexpected pgd_levels in kvm_riscv_gstage_mode() as an internal error
> (e.g. WARN_ON_ONCE())(per Radim).
> - Move kvm_riscv_gstage_gpa_bits() and kvm_riscv_gstage_gpa_size() to header
> as static inline helpers(per Radim).
> - Drop gstage_mode_user_initialized and Remove the kvm_debug() message from
> KVM_CAP_RISCV_SET_HGATP_MODE(per Radim).
> - Link to v3:
> https://lore.kernel.org/linux-riscv/20260125150450.27068-1-fangyu.yu@linux.alibaba.com/
> ---
> Changes in v3:
> - Reworked the patch formatting (per Drew).
> - Dropped kvm->arch.kvm_riscv_gstage_mode and derive HGATP.MODE from
> kvm_riscv_gstage_pgd_levels via a helper, avoiding redundant per-VM state(per Drew).
> - Removed kvm_riscv_gstage_max_mode and keep only kvm_riscv_gstage_max_pgd_levels
> for host capability detection(per Drew).
> - Other initialization and return value issues(per Drew).
> - Enforce that KVM_CAP_RISCV_SET_HGATP_MODE can only be enabled before any vCPUs
> are created by rejecting the ioctl once kvm->created_vcpus is non-zero(per Radim).
> - Add a memslot safety check and reject the capability unless
> kvm_are_all_memslots_empty(kvm) is true, ensuring the G-stage format is not
> changed after any memslots have been installed(per Radim).
> - Link to v2:
> https://lore.kernel.org/linux-riscv/20260105143232.76715-1-fangyu.yu@linux.alibaba.com/
>
> Fangyu Yu (3):
> RISC-V: KVM: Support runtime configuration for per-VM's HGATP mode
> RISC-V: KVM: Cache gstage pgd_levels in struct kvm_gstage
> RISC-V: KVM: Reuse KVM_CAP_VM_GPA_BITS to select HGATP.MODE
>
> arch/riscv/include/asm/kvm_gstage.h | 47 ++++++++++++++++---
> arch/riscv/include/asm/kvm_host.h | 1 +
> arch/riscv/kvm/gstage.c | 65 +++++++++++++--------------
> arch/riscv/kvm/main.c | 12 ++---
> arch/riscv/kvm/mmu.c | 70 +++++++++--------------------
> arch/riscv/kvm/vm.c | 49 ++++++++++++++++++--
> arch/riscv/kvm/vmid.c | 3 +-
> 7 files changed, 148 insertions(+), 99 deletions(-)
>
> --
> 2.50.1
>
This series is in good shape now. I will wait one more day to see
if there are any comments and after that I will merge for Linux-7.1
Thanks,
Anup
^ permalink raw reply
* Re: [PATCH v8 3/3] RISC-V: KVM: Reuse KVM_CAP_VM_GPA_BITS to select HGATP.MODE
From: Anup Patel @ 2026-04-03 16:42 UTC (permalink / raw)
To: fangyu.yu
Cc: pbonzini, corbet, atish.patra, pjw, palmer, aou, alex, skhan,
guoren, radim.krcmar, andrew.jones, linux-doc, kvm, kvm-riscv,
linux-riscv, linux-kernel
In-Reply-To: <20260403153019.9916-4-fangyu.yu@linux.alibaba.com>
On Fri, Apr 3, 2026 at 9:00 PM <fangyu.yu@linux.alibaba.com> wrote:
>
> From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>
> Reuse KVM_CAP_VM_GPA_BITS to advertise and select the effective
> G-stage GPA width for a VM.
>
> KVM_CHECK_EXTENSION(KVM_CAP_VM_GPA_BITS) returns the effective GPA
> bits for a VM, KVM_ENABLE_CAP(KVM_CAP_VM_GPA_BITS) allows userspace
> to downsize the effective GPA width by selecting a smaller G-stage
> page table format:
> - gpa_bits <= 41 selects Sv39x4 (pgd_levels=3)
> - gpa_bits <= 50 selects Sv48x4 (pgd_levels=4)
> - gpa_bits <= 59 selects Sv57x4 (pgd_levels=5)
>
> Reject the request with -EINVAL for unsupported values and with -EBUSY
> if vCPUs have been created or any memslot is populated.
>
> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
> Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> Reviewed-by: Guo Ren <guoren@kernel.org>
LGTM.
Reviewed-by: Anup Patel <anup@brainfault.org>
Thanks,
Anup
> ---
> arch/riscv/kvm/vm.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/kvm/vm.c b/arch/riscv/kvm/vm.c
> index fb7c4e07961f..a9f083feeb76 100644
> --- a/arch/riscv/kvm/vm.c
> +++ b/arch/riscv/kvm/vm.c
> @@ -214,12 +214,52 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>
> int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
> {
> + if (cap->flags)
> + return -EINVAL;
> +
> switch (cap->cap) {
> case KVM_CAP_RISCV_MP_STATE_RESET:
> - if (cap->flags)
> - return -EINVAL;
> kvm->arch.mp_state_reset = true;
> return 0;
> + case KVM_CAP_VM_GPA_BITS: {
> + unsigned long gpa_bits = cap->args[0];
> + unsigned long new_levels;
> + int r = 0;
> +
> + /* Decide target pgd levels from requested gpa_bits */
> +#ifdef CONFIG_64BIT
> + if (gpa_bits <= 41)
> + new_levels = 3; /* Sv39x4 */
> + else if (gpa_bits <= 50)
> + new_levels = 4; /* Sv48x4 */
> + else if (gpa_bits <= 59)
> + new_levels = 5; /* Sv57x4 */
> + else
> + return -EINVAL;
> +#else
> + /* 32-bit: only Sv32x4*/
> + if (gpa_bits <= 34)
> + new_levels = 2;
> + else
> + return -EINVAL;
> +#endif
> + if (new_levels > kvm_riscv_gstage_max_pgd_levels)
> + return -EINVAL;
> +
> + /* Follow KVM's lock ordering: kvm->lock -> kvm->slots_lock. */
> + mutex_lock(&kvm->lock);
> + mutex_lock(&kvm->slots_lock);
> +
> + if (kvm->created_vcpus || !kvm_are_all_memslots_empty(kvm))
> + r = -EBUSY;
> + else
> + kvm->arch.pgd_levels = new_levels;
> +
> + mutex_unlock(&kvm->slots_lock);
> + mutex_unlock(&kvm->lock);
> +
> + return r;
> + }
> default:
> return -EINVAL;
> }
> --
> 2.50.1
>
^ permalink raw reply
* Re: [PATCH v2 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Willy Tarreau @ 2026-04-03 16:39 UTC (permalink / raw)
To: Kees Cook
Cc: greg, edumazet, rdunlap, Jonathan Corbet, skhan, workflows,
linux-doc, linux-kernel
In-Reply-To: <202604030845.9DBD539AB@keescook>
On Fri, Apr 03, 2026 at 08:48:56AM -0700, Kees Cook wrote:
> On Fri, Apr 03, 2026 at 08:20:17AM +0200, Willy Tarreau wrote:
> > [...]
> > +One difficulty for most first-time reporters is to figure the right list of
> > +recipients to send a report to. In the Linux kernel, all official maintainers
> > +are trusted, so the consequences of accidentally including the wrong maintainer
> > +are essentially a bit more noise for that person, i.e. nothing dramatic. As
>
> Yeah, this is the central point: we already trust maintainers; there is
> nothing "special" about security@kernel.org.
Yep!
> > [...]
> > +single line suitable for use in the To: field of a mailer like this::
> > +
> > + $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
> > + --no-git-fallback --no-substatus --no-rolestats --no-multiline \
> > + --pattern-depth 1 drivers/example.c
> > + dev1@example.com, dev2@example.org
>
> To echo Greg, yeah, this is great, and has been an implicit action we've
> done for years, so there's every reason to delegate it to the reporter
> to avoid the round-trip.
Thanks!
> Though I guess we'll see if these new instructions actually change
> anything -- we still have people asking for CVE assignments. :P
I think it will move a little bit, because AI bots read this, so the
annoying ones who used to send us reports they didn't read will make
better ones. We've seen improvements already over the last two months,
with more plain text and less copy-pasted markdown. But maybe the MD
wasn't emitted in the first place. It's also true that the reports
quality has improved and now the tools are used by some experienced
people (but not just them yet). Anyway, we'll see. Now we have just
a link to copy-paste in return, we'll see how it evolves.
Cheers,
Willy
^ permalink raw reply
* [PATCH v4 27/27] mtd: spi-nor: winbond: Add W25Q02NWxxIM CMP locking support
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Unfortunately, this chip also comes with an incorrect BFPT table,
indicating the Control Register cannot be read back. This is wrong,
reading back the register works and has no (observed) side effect. The
datasheet clearly indicates supporting the 35h command and all bits from
the CR are marked readable. QE and CMP bits are inside, and can be
properly read back.
Add a fixup for this, otherwise it would defeat the use of the CMP
feature.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Test run with W25Q02NWxxIM:
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 $bs $all_but_one # all but the first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0000ffff | unlocked | 1
00010000-0fffffff | locked | 4095
$ flash_lock -u /dev/mtd0 $bs 1 # all but the two first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0001ffff | unlocked | 2
00020000-0fffffff | locked | 4094
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 0 $all_but_one # same from the other side
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0ffeffff | locked | 4095
0fff0000-0fffffff | unlocked | 1
$ flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # all but two
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0ffdffff | locked | 4094
0ffe0000-0fffffff | unlocked | 2
---
drivers/mtd/spi-nor/winbond.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
index 72053a4505f9..639d72f48769 100644
--- a/drivers/mtd/spi-nor/winbond.c
+++ b/drivers/mtd/spi-nor/winbond.c
@@ -377,7 +377,9 @@ static const struct flash_info winbond_nor_parts[] = {
}, {
/* W25Q02NWxxIM */
.id = SNOR_ID(0xef, 0x80, 0x22),
- .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP,
+ .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 |
+ SPI_NOR_4BIT_BP | SPI_NOR_HAS_CMP,
+ .fixups = &winbond_rdcr_fixup,
}, {
/* W25H512NWxxAM */
.id = SNOR_ID(0xef, 0xa0, 0x20),
--
2.53.0
^ permalink raw reply related
* [PATCH v4 26/27] mtd: spi-nor: winbond: Add W25Q01NWxxIM CMP locking support
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Test run with W25Q01NWxxIM:
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 $bs $all_but_one # all but the first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0000ffff | unlocked | 1
00010000-0fffffff | locked | 4095
$ flash_lock -u /dev/mtd0 $bs 1 # all but the two first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0001ffff | unlocked | 2
00020000-0fffffff | locked | 4094
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 0 $all_but_one # same from the other side
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0ffeffff | locked | 4095
0fff0000-0fffffff | unlocked | 1
$ flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # all but two
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0ffdffff | locked | 4094
0ffe0000-0fffffff | unlocked | 2
---
drivers/mtd/spi-nor/winbond.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
index 373c0af9daa2..72053a4505f9 100644
--- a/drivers/mtd/spi-nor/winbond.c
+++ b/drivers/mtd/spi-nor/winbond.c
@@ -372,7 +372,8 @@ static const struct flash_info winbond_nor_parts[] = {
}, {
/* W25Q01NWxxIM */
.id = SNOR_ID(0xef, 0x80, 0x21),
- .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP,
+ .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 |
+ SPI_NOR_4BIT_BP | SPI_NOR_HAS_CMP,
}, {
/* W25Q02NWxxIM */
.id = SNOR_ID(0xef, 0x80, 0x22),
--
2.53.0
^ permalink raw reply related
* [PATCH v4 25/27] mtd: spi-nor: winbond: Add W25H01NWxxIQ CMP locking support
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Unfortunately, this chip also comes with an incorrect BFPT table,
indicating the Control Register cannot be read back. This is wrong,
reading back the register works and has no (observed) side effect. The
datasheet clearly indicates supporting the 35h command and all bits from
the CR are marked readable. QE and CMP bits are inside, and can be
properly read back.
Add a fixup for this, otherwise it would defeat the use of the CMP
feature.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Test run with W25H01NWxxIQ:
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 $bs $all_but_one # all but the first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0000ffff | unlocked | 1
00010000-07ffffff | locked | 2047
$ flash_lock -u /dev/mtd0 $bs 1 # all but the two first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0001ffff | unlocked | 2
00020000-07ffffff | locked | 2046
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 0 $all_but_one # same from the other side
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-07feffff | locked | 2047
07ff0000-07ffffff | unlocked | 1
$ flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # alll but two
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-07fdffff | locked | 2046
07fe0000-07ffffff | unlocked | 2
---
drivers/mtd/spi-nor/winbond.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
index 959fd4f46eb5..373c0af9daa2 100644
--- a/drivers/mtd/spi-nor/winbond.c
+++ b/drivers/mtd/spi-nor/winbond.c
@@ -366,7 +366,9 @@ static const struct flash_info winbond_nor_parts[] = {
}, {
/* W25Q01NWxxIQ */
.id = SNOR_ID(0xef, 0x60, 0x21),
- .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP,
+ .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 |
+ SPI_NOR_4BIT_BP | SPI_NOR_HAS_CMP,
+ .fixups = &winbond_rdcr_fixup,
}, {
/* W25Q01NWxxIM */
.id = SNOR_ID(0xef, 0x80, 0x21),
--
2.53.0
^ permalink raw reply related
* [PATCH v4 24/27] mtd: spi-nor: winbond: Add W25H02NWxxAM CMP locking support
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Unfortunately, this chip also comes with an incorrect BFPT table,
indicating the Control Register cannot be read back. This is wrong,
reading back the register works and has no (observed) side effect. The
datasheet clearly indicates supporting the 35h command and all bits from
the CR are marked readable. QE and CMP bits are inside, and can be
properly read back.
Add a fixup for this, otherwise it would defeat the use of the CMP
feature.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Test run with W25H02NWxxAM:
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 $bs $all_but_one # all but the first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0000ffff | unlocked | 1
00010000-0fffffff | locked | 4095
$ flash_lock -u /dev/mtd0 $bs 1 # all but the two first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0001ffff | unlocked | 2
00020000-0fffffff | locked | 4094
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 0 $all_but_one # same from the other side
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0ffeffff | locked | 4095
0fff0000-0fffffff | unlocked | 1
$ flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # all but two
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0ffdffff | locked | 4094
0ffe0000-0fffffff | unlocked | 2
---
drivers/mtd/spi-nor/winbond.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
index 1b9b0e9598ef..959fd4f46eb5 100644
--- a/drivers/mtd/spi-nor/winbond.c
+++ b/drivers/mtd/spi-nor/winbond.c
@@ -73,6 +73,26 @@ static const struct spi_nor_fixups w25q256_fixups = {
.post_bfpt = w25q256_post_bfpt_fixups,
};
+static int
+winbond_rdcr_post_bfpt_fixup(struct spi_nor *nor,
+ const struct sfdp_parameter_header *bfpt_header,
+ const struct sfdp_bfpt *bfpt)
+{
+ /*
+ * W25H02NW, unlike its W25H512NW nor W25H01NW cousins, improperly sets
+ * the QE BFPT configuration bits, indicating a non readable CR. This is
+ * both incorrect and impractical, as the chip features a CMP bit for its
+ * locking scheme that lays in the Control Register, and needs to be read.
+ */
+ nor->flags &= ~SNOR_F_NO_READ_CR;
+
+ return 0;
+}
+
+static const struct spi_nor_fixups winbond_rdcr_fixup = {
+ .post_bfpt = winbond_rdcr_post_bfpt_fixup,
+};
+
/**
* winbond_nor_select_die() - Set active die.
* @nor: pointer to 'struct spi_nor'.
@@ -368,7 +388,9 @@ static const struct flash_info winbond_nor_parts[] = {
}, {
/* W25H02NWxxAM */
.id = SNOR_ID(0xef, 0xa0, 0x22),
- .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP,
+ .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 |
+ SPI_NOR_4BIT_BP | SPI_NOR_HAS_CMP,
+ .fixups = &winbond_rdcr_fixup,
},
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 23/27] mtd: spi-nor: winbond: Add W25H01NWxxAM CMP locking support
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Test run with W25H01NWxxAM:
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 $bs $all_but_one # all but the first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0000ffff | unlocked | 1
00010000-07ffffff | locked | 2047
$ flash_lock -u /dev/mtd0 $bs 1 # all but the two first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0001ffff | unlocked | 2
00020000-07ffffff | locked | 2046
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 0 $all_but_one # same from the other side
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-07feffff | locked | 2047
07ff0000-07ffffff | unlocked | 1
$ flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # all but two
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-07fdffff | locked | 2046
07fe0000-07ffffff | unlocked | 2
---
drivers/mtd/spi-nor/winbond.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
index 7609dcc768f0..1b9b0e9598ef 100644
--- a/drivers/mtd/spi-nor/winbond.c
+++ b/drivers/mtd/spi-nor/winbond.c
@@ -363,7 +363,8 @@ static const struct flash_info winbond_nor_parts[] = {
}, {
/* W25H01NWxxAM */
.id = SNOR_ID(0xef, 0xa0, 0x21),
- .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP,
+ .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 |
+ SPI_NOR_4BIT_BP | SPI_NOR_HAS_CMP,
}, {
/* W25H02NWxxAM */
.id = SNOR_ID(0xef, 0xa0, 0x22),
--
2.53.0
^ permalink raw reply related
* [PATCH v4 22/27] mtd: spi-nor: winbond: Add W25H512NWxxAM CMP locking support
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
This chip has support for the locking complement (CMP) feature. Add
the relevant bit to enable it.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Test run following the freshly written documentation:
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 $bs $all_but_one # all but the first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0000ffff | unlocked | 1
00010000-03ffffff | locked | 1023
$ flash_lock -u /dev/mtd0 $bs 1 # all but the two first
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0001ffff | unlocked | 2
00020000-03ffffff | locked | 1022
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 0 $all_but_one # same from the other side
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03feffff | locked | 1023
03ff0000-03ffffff | unlocked | 1
$ flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # all but two
$ show_sectors
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03fdffff | locked | 1022
03fe0000-03ffffff | unlocked | 2
---
drivers/mtd/spi-nor/winbond.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
index fb855fe44733..7609dcc768f0 100644
--- a/drivers/mtd/spi-nor/winbond.c
+++ b/drivers/mtd/spi-nor/winbond.c
@@ -358,7 +358,8 @@ static const struct flash_info winbond_nor_parts[] = {
}, {
/* W25H512NWxxAM */
.id = SNOR_ID(0xef, 0xa0, 0x20),
- .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 | SPI_NOR_4BIT_BP,
+ .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_TB_SR_BIT6 |
+ SPI_NOR_4BIT_BP | SPI_NOR_HAS_CMP,
}, {
/* W25H01NWxxAM */
.id = SNOR_ID(0xef, 0xa0, 0x21),
--
2.53.0
^ permalink raw reply related
* [PATCH v4 21/27] mtd: spi-nor: Add steps for testing locking with CMP
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
Extend the test coverage by giving guidelines to verify the CMP bit acts
according to our expectations.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
The instructions listed in this file target people adding support for
new chips, however here are below extra steps that I also ran with the
same W25H512NWxxAM chip. They are here to prove core correctness.
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 0 1008
$ show_sectors
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03efffff | locked | 1008
03f00000-03ffffff | unlocked | 16
$ flash_lock -l /dev/mtd0 0 1009
$ show_sectors # should not change
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03efffff | locked | 1008
03f00000-03ffffff | unlocked | 16
$ flash_lock -l /dev/mtd0 0 1015
$ show_sectors # should not change
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03efffff | locked | 1008
03f00000-03ffffff | unlocked | 16
$ flash_lock -l /dev/mtd0 0 1016
$ show_sectors # should cover more
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03f7ffff | locked | 1016
03f80000-03ffffff | unlocked | 8
$ flash_lock -u /dev/mtd0 $((1015 * $bs)) 1
$ show_sectors # should not change
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03f7ffff | locked | 1016
03f80000-03ffffff | unlocked | 8
$ flash_lock -u /dev/mtd0 $((1009 * $bs)) 7
$ show_sectors # should not change
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03f7ffff | locked | 1016
03f80000-03ffffff | unlocked | 8
$ flash_lock -u /dev/mtd0 $((1008 * $bs)) 8
$ show_sectors # range should reduce down to initial value
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03efffff | locked | 1008
03f00000-03ffffff | unlocked | 16
[Similar situations, on the other side of the device]
$ flash_lock -u /dev/mtd0
$ flash_lock -l /dev/mtd0 $((16 * $bs)) 1008
$ show_sectors
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-000fffff | unlocked | 16
00100000-03ffffff | locked | 1008
$ flash_lock -l /dev/mtd0 $((15 * $bs)) 1009
$ show_sectors # should not change
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-000fffff | unlocked | 16
00100000-03ffffff | locked | 1008
$ flash_lock -l /dev/mtd0 $((9 * $bs)) 1015
$ show_sectors # should not change
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-000fffff | unlocked | 16
00100000-03ffffff | locked | 1008
$ flash_lock -l /dev/mtd0 $((8 * $bs)) 1016
$ show_sectors # should cover more
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0007ffff | unlocked | 8
00080000-03ffffff | locked | 1016
$ flash_lock -u /dev/mtd0 $((8 * $bs)) 1
$ show_sectors # should not change
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0007ffff | unlocked | 8
00080000-03ffffff | locked | 1016
$ flash_lock -u /dev/mtd0 $((8 * $bs)) 7
$ show_sectors # should not change
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0007ffff | unlocked | 8
00080000-03ffffff | locked | 1016
$ flash_lock -u /dev/mtd0 $((8 * $bs)) 8
$ show_sectors # range should reduce down to initial value
software locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-000fffff | unlocked | 16
00100000-03ffffff | locked | 1008
---
Documentation/driver-api/mtd/spi-nor.rst | 36 ++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst
index 4755eb75fe5e..ec46bba8297a 100644
--- a/Documentation/driver-api/mtd/spi-nor.rst
+++ b/Documentation/driver-api/mtd/spi-nor.rst
@@ -331,3 +331,39 @@ section, after the ``---`` marker.
------------------+----------+--------
00000000-0000ffff | locked | 1
00010000-03ffffff | unlocked | 1023
+
+ If the flash features a Complement (CMP) bit, we can protect with
+ more granularity above half of the capacity. Let's lock all but one
+ block, then unlock one more block::
+
+ root@1:~# all_but_one=$((($size / $bs) - 1))
+ root@1:~# flash_lock -u /dev/mtd0
+ root@1:~# flash_lock -l /dev/mtd0 $bs $all_but_one # all but the first
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-0000ffff | unlocked | 1
+ 00010000-03ffffff | locked | 1023
+ root@1:~# flash_lock -u /dev/mtd0 $bs 1 # all but the two first
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-0001ffff | unlocked | 2
+ 00020000-03ffffff | locked | 1022
+ root@1:~# flash_lock -u /dev/mtd0
+ root@1:~# flash_lock -l /dev/mtd0 0 $all_but_one # same from the other side
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-03feffff | locked | 1023
+ 03ff0000-03ffffff | unlocked | 1
+ root@1:~# flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # all but two
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-03fdffff | locked | 1022
+ 03fe0000-03ffffff | unlocked | 2
--
2.53.0
^ permalink raw reply related
* [PATCH v4 20/27] mtd: spi-nor: swp: Add support for the complement feature
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
The current locking implementation allows to select a power of two
number of blocks, which is going to be the protected amount, as well as
telling whether this is the data at the top (end of the device) or the
bottom (beginning of the device). This means at most we can cover half
of the device or the entire device, but nothing in between.
The complement feature allows a much finer grain of configuration, by
allowing to invert what is considered locked and unlocked.
Add support for this feature. The only known position for the CMP bit is
bit 6 of the configuration register.
The locking and unlocking logics are kept unchanged if the CMP bit is
unavailable. Otherwise, once the regular logic has been applied, we
check if we already found an optimal configuration. If not, we try with
the CMP bit set. If the coverage is closer to the request, we use it.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/spi-nor/core.c | 3 +
drivers/mtd/spi-nor/core.h | 4 +
drivers/mtd/spi-nor/debugfs.c | 1 +
drivers/mtd/spi-nor/swp.c | 196 +++++++++++++++++++++++++++++++++++-------
include/linux/mtd/spi-nor.h | 1 +
5 files changed, 173 insertions(+), 32 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index eb7744926e44..c1e1d6d7cdf0 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2974,6 +2974,9 @@ static void spi_nor_init_flags(struct spi_nor *nor)
nor->flags |= SNOR_F_HAS_SR_BP3_BIT6;
}
+ if (flags & SPI_NOR_HAS_CMP)
+ nor->flags |= SNOR_F_HAS_SR2_CMP_BIT6;
+
if (flags & SPI_NOR_RWW && nor->params->n_banks > 1 &&
!nor->controller_ops)
nor->flags |= SNOR_F_RWW;
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 8717a0ad90f0..842ab2a5a903 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -141,6 +141,7 @@ enum spi_nor_option_flags {
SNOR_F_ECC = BIT(15),
SNOR_F_NO_WP = BIT(16),
SNOR_F_SWAP16 = BIT(17),
+ SNOR_F_HAS_SR2_CMP_BIT6 = BIT(18),
};
struct spi_nor_read_command {
@@ -483,6 +484,8 @@ struct spi_nor_id {
* SPI_NOR_NO_ERASE: no erase command needed.
* SPI_NOR_QUAD_PP: flash supports Quad Input Page Program.
* SPI_NOR_RWW: flash supports reads while write.
+ * SPI_NOR_HAS_CMP: flash SR2 has complement (CMP) protect bit. Must
+ * be used with SPI_NOR_HAS_LOCK.
*
* @no_sfdp_flags: flags that indicate support that can be discovered via SFDP.
* Used when SFDP tables are not defined in the flash. These
@@ -531,6 +534,7 @@ struct flash_info {
#define SPI_NOR_NO_ERASE BIT(6)
#define SPI_NOR_QUAD_PP BIT(8)
#define SPI_NOR_RWW BIT(9)
+#define SPI_NOR_HAS_CMP BIT(10)
u8 no_sfdp_flags;
#define SPI_NOR_SKIP_SFDP BIT(0)
diff --git a/drivers/mtd/spi-nor/debugfs.c b/drivers/mtd/spi-nor/debugfs.c
index 1ed1a0bbef3b..e1b3406d489b 100644
--- a/drivers/mtd/spi-nor/debugfs.c
+++ b/drivers/mtd/spi-nor/debugfs.c
@@ -30,6 +30,7 @@ static const char *const snor_f_names[] = {
SNOR_F_NAME(ECC),
SNOR_F_NAME(NO_WP),
SNOR_F_NAME(SWAP16),
+ SNOR_F_NAME(HAS_SR2_CMP_BIT6),
};
#undef SNOR_F_NAME
diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
index d75ed83eb787..f5a2d667379a 100644
--- a/drivers/mtd/spi-nor/swp.c
+++ b/drivers/mtd/spi-nor/swp.c
@@ -32,6 +32,15 @@ static u8 spi_nor_get_sr_tb_mask(struct spi_nor *nor)
return SR_TB_BIT5;
}
+static u8 spi_nor_get_sr_cmp_mask(struct spi_nor *nor)
+{
+ if (!(nor->flags & SNOR_F_NO_READ_CR) &&
+ nor->flags & SNOR_F_HAS_SR2_CMP_BIT6)
+ return SR2_CMP_BIT6;
+ else
+ return 0;
+}
+
u64 spi_nor_get_min_prot_length_sr(struct spi_nor *nor)
{
unsigned int bp_slots, bp_slots_needed;
@@ -59,8 +68,10 @@ void spi_nor_get_locked_range_sr(struct spi_nor *nor, const u8 *sr, loff_t *ofs,
u64 min_prot_len;
u8 bp_mask = spi_nor_get_sr_bp_mask(nor);
u8 tb_mask = spi_nor_get_sr_tb_mask(nor);
+ u8 cmp_mask = spi_nor_get_sr_tb_mask(nor);
u8 bp, val = sr[0] & bp_mask;
bool tb = (nor->flags & SNOR_F_HAS_SR_TB) ? sr[0] & tb_mask : 0;
+ bool cmp = sr[1] & cmp_mask;
if (nor->flags & SNOR_F_HAS_SR_BP3_BIT6 && val & SR_BP3_BIT6)
val = (val & ~SR_BP3_BIT6) | SR_BP3;
@@ -68,22 +79,37 @@ void spi_nor_get_locked_range_sr(struct spi_nor *nor, const u8 *sr, loff_t *ofs,
bp = val >> SR_BP_SHIFT;
if (!bp) {
- /* No protection */
- *ofs = 0;
- *len = 0;
- return;
+ if (!cmp) {
+ /* No protection */
+ *ofs = 0;
+ *len = 0;
+ return;
+ } else {
+ /* Full protection */
+ *ofs = 0;
+ *len = nor->params->size;
+ }
}
min_prot_len = spi_nor_get_min_prot_length_sr(nor);
*len = min_prot_len << (bp - 1);
-
if (*len > nor->params->size)
*len = nor->params->size;
- if (tb)
- *ofs = 0;
- else
- *ofs = nor->params->size - *len;
+ if (cmp)
+ *len = nor->params->size - *len;
+
+ if (!cmp) {
+ if (tb)
+ *ofs = 0;
+ else
+ *ofs = nor->params->size - *len;
+ } else {
+ if (tb)
+ *ofs = nor->params->size - *len;
+ else
+ *ofs = 0;
+ }
}
/*
@@ -140,13 +166,15 @@ static int spi_nor_sr_set_bp_mask(struct spi_nor *nor, u8 *sr, u8 pow)
}
static int spi_nor_build_sr(struct spi_nor *nor, const u8 *old_sr, u8 *new_sr,
- u8 pow, bool use_top)
+ u8 pow, bool use_top, bool cmp)
{
u8 bp_mask = spi_nor_get_sr_bp_mask(nor);
u8 tb_mask = spi_nor_get_sr_tb_mask(nor);
+ u8 cmp_mask = spi_nor_get_sr_cmp_mask(nor);
int ret;
new_sr[0] = old_sr[0] & ~bp_mask & ~tb_mask;
+ new_sr[1] = old_sr[1] & ~cmp_mask;
/* Build BP field */
ret = spi_nor_sr_set_bp_mask(nor, &new_sr[0], pow);
@@ -154,9 +182,13 @@ static int spi_nor_build_sr(struct spi_nor *nor, const u8 *old_sr, u8 *new_sr,
return ret;
/* Build TB field */
- if (!use_top)
+ if ((!cmp && !use_top) || (cmp && use_top))
new_sr[0] |= tb_mask;
+ /* Build CMP field */
+ if (cmp)
+ new_sr[1] |= cmp_mask;
+
return 0;
}
@@ -168,15 +200,22 @@ void spi_nor_cache_sr_lock_bits(struct spi_nor *nor, u8 *sr)
{
u8 bp_mask = spi_nor_get_sr_bp_mask(nor);
u8 tb_mask = spi_nor_get_sr_tb_mask(nor);
+ u8 cmp_mask = spi_nor_get_sr_cmp_mask(nor);
if (!sr) {
if (spi_nor_read_sr(nor, nor->bouncebuf))
return;
+ if (!(nor->flags & SNOR_F_NO_READ_CR)) {
+ if (spi_nor_read_cr(nor, nor->bouncebuf + 1))
+ return;
+ }
+
sr = nor->bouncebuf;
}
nor->dfs_sr_cache[0] = sr[0] & (bp_mask | tb_mask | SR_SRWD);
+ nor->dfs_sr_cache[1] = sr[1] & cmp_mask;
}
/*
@@ -185,10 +224,11 @@ void spi_nor_cache_sr_lock_bits(struct spi_nor *nor, u8 *sr)
* 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 conditionally for some flash:
* - TB: top/bottom protect
+ * - CMP: complement protect (BP and TP describe the unlocked part, while
+ * the reminder is locked)
*
* Sample table portion for 8MB flash (Winbond w25q64fw):
*
@@ -215,11 +255,13 @@ void spi_nor_cache_sr_lock_bits(struct spi_nor *nor, u8 *sr)
static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
{
u64 min_prot_len = spi_nor_get_min_prot_length_sr(nor);
- u8 status_old[1] = {}, status_new[1] = {};
- loff_t ofs_old, ofs_new;
- u64 len_old, len_new;
+ u8 status_old[2] = {}, status_new[2] = {}, status_new_cmp[2] = {};
+ u8 *best_status_new = status_new;
+ loff_t ofs_old, ofs_new, ofs_new_cmp;
+ u64 len_old, len_new, len_new_cmp;
loff_t lock_len;
- bool can_be_top = true, can_be_bottom = nor->flags & SNOR_F_HAS_SR_TB;
+ bool can_be_top = true, can_be_bottom = nor->flags & SNOR_F_HAS_SR_TB,
+ can_be_cmp = spi_nor_get_sr_cmp_mask(nor);
bool use_top;
int ret;
u8 pow;
@@ -230,6 +272,14 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
status_old[0] = nor->bouncebuf[0];
+ if (!(nor->flags & SNOR_F_NO_READ_CR)) {
+ ret = spi_nor_read_cr(nor, nor->bouncebuf + 1);
+ if (ret)
+ return ret;
+
+ status_old[1] = nor->bouncebuf[1];
+ }
+
/* If nothing in our range is unlocked, we don't need to do anything */
if (spi_nor_is_locked_sr(nor, ofs, len, status_old))
return 0;
@@ -260,24 +310,56 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
else
pow = ilog2(lock_len) - ilog2(min_prot_len) + 1;
- ret = spi_nor_build_sr(nor, status_old, status_new, pow, use_top);
+ ret = spi_nor_build_sr(nor, status_old, status_new, pow, use_top, false);
if (ret)
return ret;
+ /*
+ * In case the region asked is not fully met, maybe we can try with the
+ * complement feature
+ */
+ spi_nor_get_locked_range_sr(nor, status_new, &ofs_new, &len_new);
+ if (can_be_cmp && len_new != lock_len) {
+ pow = ilog2(nor->params->size - lock_len) - ilog2(min_prot_len) + 1;
+ ret = spi_nor_build_sr(nor, status_old, status_new_cmp, pow, use_top, true);
+ if (ret)
+ return ret;
+
+ /*
+ * ilog2() "floors" the result, which means in some cases we may have to
+ * manually reduce the scope when the complement feature is used.
+ * The uAPI is to never lock more than what is requested, but less is accepted.
+ * Make sure we are not covering a too wide range, reduce it otherwise.
+ */
+ spi_nor_get_locked_range_sr(nor, status_new_cmp, &ofs_new_cmp, &len_new_cmp);
+ if (len_new_cmp > lock_len) {
+ pow++;
+ ret = spi_nor_build_sr(nor, status_old, status_new_cmp, pow, use_top, true);
+ if (ret)
+ return ret;
+ }
+
+ /* Pick the CMP configuration if we cover a closer range */
+ spi_nor_get_locked_range_sr(nor, status_new, &ofs_new, &len_new);
+ spi_nor_get_locked_range_sr(nor, status_new_cmp, &ofs_new_cmp, &len_new_cmp);
+ if (len_new_cmp > len_new)
+ best_status_new = status_new_cmp;
+ }
+
/*
* Disallow further writes if WP# pin is neither left floating nor
* wrongly tied to GND (that includes internal pull-downs).
* WP# pin hard strapped to GND can be a valid use case.
*/
if (!(nor->flags & SNOR_F_NO_WP))
- status_new[0] |= SR_SRWD;
+ best_status_new[0] |= SR_SRWD;
/* Don't bother if they're the same */
- if (status_new[0] == status_old[0])
+ if (best_status_new[0] == status_old[0] && best_status_new[1] == status_old[1])
return 0;
spi_nor_get_locked_range_sr(nor, status_old, &ofs_old, &len_old);
- spi_nor_get_locked_range_sr(nor, status_new, &ofs_new, &len_new);
+ spi_nor_get_locked_range_sr(nor, best_status_new, &ofs_new, &len_new);
/* Don't "lock" with no region! */
if (!len_new)
@@ -288,11 +370,11 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
(ofs_old < ofs_new || (ofs_new + len_new) < (ofs_old + len_old)))
return -EINVAL;
- ret = spi_nor_write_sr_and_check(nor, status_new[0]);
+ ret = spi_nor_write_sr_cr_and_check(nor, best_status_new);
if (ret)
return ret;
- spi_nor_cache_sr_lock_bits(nor, status_new);
+ spi_nor_cache_sr_lock_bits(nor, best_status_new);
return 0;
}
@@ -306,11 +388,13 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
{
u64 min_prot_len = spi_nor_get_min_prot_length_sr(nor);
int ret;
- u8 status_old[1], status_new[1];
- loff_t ofs_old, ofs_new;
- u64 len_old, len_new;
+ u8 status_old[2], status_new[2], status_new_cmp[2];
+ u8 *best_status_new = status_new;
+ loff_t ofs_old, ofs_new, ofs_new_cmp;
+ u64 len_old, len_new, len_new_cmp;
loff_t lock_len;
- bool can_be_top = true, can_be_bottom = nor->flags & SNOR_F_HAS_SR_TB;
+ bool can_be_top = true, can_be_bottom = nor->flags & SNOR_F_HAS_SR_TB,
+ can_be_cmp = spi_nor_get_sr_cmp_mask(nor);
bool use_top;
u8 pow;
@@ -320,6 +404,14 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
status_old[0] = nor->bouncebuf[0];
+ if (!(nor->flags & SNOR_F_NO_READ_CR)) {
+ ret = spi_nor_read_cr(nor, nor->bouncebuf + 1);
+ if (ret)
+ return ret;
+
+ status_old[1] = nor->bouncebuf[1];
+ }
+
/* If nothing in our range is locked, we don't need to do anything */
if (spi_nor_is_unlocked_sr(nor, ofs, len, status_old))
return 0;
@@ -357,30 +449,62 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
else
pow = ilog2(lock_len) - ilog2(min_prot_len) + 1;
- ret = spi_nor_build_sr(nor, status_old, status_new, pow, use_top);
+ ret = spi_nor_build_sr(nor, status_old, status_new, pow, use_top, false);
if (ret)
return ret;
+ /*
+ * In case the region asked is not fully met, maybe we can try with the
+ * complement feature
+ */
+ spi_nor_get_locked_range_sr(nor, status_new, &ofs_new, &len_new);
+ if (can_be_cmp && len_new != lock_len) {
+ pow = ilog2(nor->params->size - lock_len) - ilog2(min_prot_len) + 1;
+ ret = spi_nor_build_sr(nor, status_old, status_new_cmp, pow, use_top, true);
+ if (ret)
+ return ret;
+
+ /*
+ * ilog2() "floors" the result, which means in some cases we may have to
+ * manually reduce the scope when the complement feature is used.
+ * The uAPI is to never unlock more than what is requested, but less is accepted.
+ * Make sure we are not covering a too small range, increase it otherwise.
+ */
+ spi_nor_get_locked_range_sr(nor, status_new_cmp, &ofs_new_cmp, &len_new_cmp);
+ if (len_new_cmp < lock_len) {
+ pow--;
+ ret = spi_nor_build_sr(nor, status_old, status_new_cmp, pow, use_top, true);
+ if (ret)
+ return ret;
+ }
+
+ /* Pick the CMP configuration if we cover a closer range */
+ spi_nor_get_locked_range_sr(nor, status_new, &ofs_new, &len_new);
+ spi_nor_get_locked_range_sr(nor, status_new_cmp, &ofs_new_cmp, &len_new_cmp);
+ if (len_new_cmp > len_new)
+ best_status_new = status_new_cmp;
+ }
+
/* Don't protect status register if we're fully unlocked */
if (lock_len == 0)
- status_new[0] &= ~SR_SRWD;
+ best_status_new[0] &= ~SR_SRWD;
/* Don't bother if they're the same */
- if (status_new[0] == status_old[0])
+ if (best_status_new[0] == status_old[0] && best_status_new[1] == status_old[1])
return 0;
/* Only modify protection if it will not lock other areas */
spi_nor_get_locked_range_sr(nor, status_old, &ofs_old, &len_old);
- spi_nor_get_locked_range_sr(nor, status_new, &ofs_new, &len_new);
+ spi_nor_get_locked_range_sr(nor, best_status_new, &ofs_new, &len_new);
if (len_old && len_new &&
(ofs_new < ofs_old || (ofs_old + len_old) < (ofs_new + len_new)))
return -EINVAL;
- ret = spi_nor_write_sr_and_check(nor, status_new[0]);
+ ret = spi_nor_write_sr_cr_and_check(nor, best_status_new);
if (ret)
return ret;
- spi_nor_cache_sr_lock_bits(nor, status_new);
+ spi_nor_cache_sr_lock_bits(nor, best_status_new);
return 0;
}
@@ -400,6 +524,14 @@ static int spi_nor_sr_is_locked(struct spi_nor *nor, loff_t ofs, u64 len)
if (ret)
return ret;
+ if (!(nor->flags & SNOR_F_NO_READ_CR)) {
+ ret = spi_nor_read_cr(nor, nor->bouncebuf + 1);
+ if (ret)
+ return ret;
+ } else {
+ nor->bouncebuf[1] = 0;
+ }
+
return spi_nor_is_locked_sr(nor, ofs, len, nor->bouncebuf);
}
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 9ad77f9e76c2..4b92494827b1 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -125,6 +125,7 @@
#define SR2_LB1 BIT(3) /* Security Register Lock Bit 1 */
#define SR2_LB2 BIT(4) /* Security Register Lock Bit 2 */
#define SR2_LB3 BIT(5) /* Security Register Lock Bit 3 */
+#define SR2_CMP_BIT6 BIT(6)
#define SR2_QUAD_EN_BIT7 BIT(7)
/* Supported SPI protocols */
--
2.53.0
^ permalink raw reply related
* [PATCH v4 19/27] mtd: spi-nor: Add steps for testing locking support
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
As recently raised on the mailing list, it may be useful to propose a
list of steps to go through in order to proove the devices have been
described correctly, especially since all the block protection
information is not stored in any kind of table and is instead filled
manually by developpers.
Use the debugfs output to ease the comparison between expectations and
reality.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Documentation/driver-api/mtd/spi-nor.rst | 128 +++++++++++++++++++++++++++++++
1 file changed, 128 insertions(+)
diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst
index 148fa4288760..4755eb75fe5e 100644
--- a/Documentation/driver-api/mtd/spi-nor.rst
+++ b/Documentation/driver-api/mtd/spi-nor.rst
@@ -203,3 +203,131 @@ section, after the ``---`` marker.
mtd.writesize = 1
mtd.oobsize = 0
regions = 0
+
+5) If your flash supports locking, please go through the following test
+ procedure to make sure it correctly behaves. The below example
+ expects the typical situation where eraseblocks and lock sectors have
+ the same size. In case you enabled MTD_SPI_NOR_USE_4K_SECTORS, you
+ must adapt `bs` accordingly.
+
+ Warning: These tests may hard lock your device! Make sure:
+ - The device is not hard locked already (#WP strapped to low and
+ SR_SRWD bit set)
+ - If you have a WPn pin, you may want to set `no-wp` in your DT for
+ the time of the test, to only make use of software protection.
+ Otherwise, clearing the locking state depends on the WPn
+ signal and if it is tied to low, the flash will be permanently
+ locked.
+
+ Test full chip locking and make sure expectations, the MEMISLOCKED
+ ioctl output, the debugfs output and experimental results are all
+ aligned::
+
+ root@1:~# alias show_sectors='grep -A4 "locked sectors" /sys/kernel/debug/spi-nor/spi0.0/params'
+ root@1:~# flash_lock -u /dev/mtd0
+ root@1:~# flash_lock -i /dev/mtd0
+ Device: /dev/mtd0
+ Start: 0
+ Len: 0x4000000
+ Lock status: unlocked
+ Return code: 0
+ root@1:~# mtd_debug erase /dev/mtd0 0 2097152
+ Erased 2097152 bytes from address 0x00000000 in flash
+ root@1:~# mtd_debug write /dev/mtd0 0 2097152 spi_test
+ Copied 2097152 bytes from spi_test to address 0x00000000 in flash
+ root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read
+ Copied 2097152 bytes from address 0x00000000 in flash to spi_read
+ root@1:~# sha256sum spi*
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-03ffffff | unlocked | 1024
+
+ root@1:~# flash_lock -l /dev/mtd0
+ root@1:~# flash_lock -i /dev/mtd0
+ Device: /dev/mtd0
+ Start: 0
+ Len: 0x4000000
+ Lock status: locked
+ Return code: 1
+ root@1:~# mtd_debug erase /dev/mtd0 0 2097152
+ Erased 2097152 bytes from address 0x00000000 in flash
+ root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read
+ Copied 2097152 bytes from address 0x00000000 in flash to spi_read
+ root@1:~# sha256sum spi*
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
+ root@1:~# dd if=/dev/urandom of=./spi_test2 bs=1M count=2
+ 2+0 records in
+ 2+0 records out
+ root@1:~# mtd_debug write /dev/mtd0 0 2097152 spi_test2
+ Copied 2097152 bytes from spi_test to address 0x00000000 in flash
+ root@1:~# mtd_debug read /dev/mtd0 0 2097152 spi_read2
+ Copied 2097152 bytes from address 0x00000000 in flash to spi_read
+ root@1:~# sha256sum spi*
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_read2
+ c444216a6ba2a4a66cccd60a0dd062bce4b865dd52b200ef5e21838c4b899ac8 spi_test
+ bea9334df51c620440f86751cba0799214a016329f1736f9456d40cf40efdc88 spi_test2
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-03ffffff | locked | 1024
+
+ Once we trust the debugfs output we can use it to test various
+ situations. Check top locking/unlocking (end of the device)::
+
+ root@1:~# bs=$(cat /sys/class/mtd/mtd0/erasesize)
+ root@1:~# size=$(cat /sys/class/mtd/mtd0/size)
+
+ root@1:~# flash_lock -u /dev/mtd0
+ root@1:~# flash_lock -l /dev/mtd0 $(($size - (2 * $bs))) 2 # last two
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-03fdffff | unlocked | 1022
+ 03fe0000-03ffffff | locked | 2
+ root@1:~# flash_lock -u /dev/mtd0 $(($size - (2 * $bs))) 1 # last one
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-03feffff | unlocked | 1023
+ 03ff0000-03ffffff | locked | 1
+
+ If the flash features 4 block protection bits (BP), we can protect
+ more than 4MB (typically 128 64kiB-blocks or more), with a finer
+ grain than locking the entire device::
+
+ root@1:~# flash_lock -u /dev/mtd0
+ root@1:~# flash_lock -l /dev/mtd0 $(($size - (2**7 * $bs))) $((2**7))
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-037fffff | unlocked | 896
+ 03800000-03ffffff | locked | 128
+
+ If the flash features a Top/Bottom (TB) bit, we can protect the
+ beginning of the flash::
+
+ root@1:~# flash_lock -u /dev/mtd0
+ root@1:~# flash_lock -l /dev/mtd0 0 2 # first two
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-0001ffff | locked | 2
+ 00020000-03ffffff | unlocked | 1022
+ root@1:~# flash_lock -u /dev/mtd0 $bs 1 # first one
+ root@1:~# show_sectors
+ software locked sectors
+ region (in hex) | status | #blocks
+ ------------------+----------+--------
+ 00000000-0000ffff | locked | 1
+ 00010000-03ffffff | unlocked | 1023
--
2.53.0
^ permalink raw reply related
* [PATCH v4 18/27] mtd: spi-nor: debugfs: Add a locked sectors map
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
In order to get a very clear view of the sectors being locked, besides
the `params` output giving the ranges, we may want to see a proper map
of the sectors and for each of them, their status. Depending on the use
case, this map may be easier to parse by humans and gives a more acurate
feeling of the situation. At least myself, for the few locking-related
developments I recently went through, I found it very useful to get a
clearer mental model of what was locked/unlocked.
Here is an example of output:
$ cat /sys/kernel/debug/spi-nor/spi0.0/locked-sectors-map
Locked sectors map (x: locked, .: unlocked, unit: 64kiB)
0x00000000 (# 0): ................ ................ ................ ................
0x00400000 (# 64): ................ ................ ................ ................
0x00800000 (# 128): ................ ................ ................ ................
0x00c00000 (# 192): ................ ................ ................ ................
0x01000000 (# 256): ................ ................ ................ ................
0x01400000 (# 320): ................ ................ ................ ................
0x01800000 (# 384): ................ ................ ................ ................
0x01c00000 (# 448): ................ ................ ................ ................
0x02000000 (# 512): ................ ................ ................ ................
0x02400000 (# 576): ................ ................ ................ ................
0x02800000 (# 640): ................ ................ ................ ................
0x02c00000 (# 704): ................ ................ ................ ................
0x03000000 (# 768): ................ ................ ................ ................
0x03400000 (# 832): ................ ................ ................ ................
0x03800000 (# 896): ................ ................ ................ ................
0x03c00000 (# 960): ................ ................ ................ ..............xx
The output is wrapped at 64 sectors, spaces every 16 sectors are
improving the readability, every line starts by the first sector
offset (hex) and number (decimal).
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/spi-nor/debugfs.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/mtd/spi-nor/debugfs.c b/drivers/mtd/spi-nor/debugfs.c
index 298ce3d9e905..1ed1a0bbef3b 100644
--- a/drivers/mtd/spi-nor/debugfs.c
+++ b/drivers/mtd/spi-nor/debugfs.c
@@ -190,6 +190,40 @@ static int spi_nor_params_show(struct seq_file *s, void *data)
}
DEFINE_SHOW_ATTRIBUTE(spi_nor_params);
+static int spi_nor_locked_sectors_map_show(struct seq_file *s, void *data)
+{
+ struct spi_nor *nor = s->private;
+ struct spi_nor_flash_parameter *params = nor->params;
+ unsigned int min_prot_len = spi_nor_get_min_prot_length_sr(nor);
+ unsigned int offset = 0, sector = 0;
+ bool locked;
+ int i;
+
+ seq_printf(s, "Locked sectors map (x: locked, .: unlocked, unit: %dkiB)\n",
+ min_prot_len / 1024);
+ while (offset < params->size) {
+ seq_printf(s, " 0x%08x (#%5d): ", offset, sector);
+ for (i = 0; i < 64 && offset < params->size; i++) {
+ locked = spi_nor_is_locked_sr(nor, offset, min_prot_len,
+ nor->dfs_sr_cache);
+ if (locked)
+ seq_puts(s, "x");
+ else
+ seq_puts(s, ".");
+
+ if (((i + 1) % 16) == 0)
+ seq_puts(s, " ");
+
+ offset += min_prot_len;
+ sector++;
+ }
+ seq_puts(s, "\n");
+ }
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(spi_nor_locked_sectors_map);
+
static void spi_nor_print_read_cmd(struct seq_file *s, u32 cap,
struct spi_nor_read_command *cmd)
{
@@ -275,6 +309,8 @@ void spi_nor_debugfs_register(struct spi_nor *nor)
debugfs_create_file("params", 0444, d, nor, &spi_nor_params_fops);
debugfs_create_file("capabilities", 0444, d, nor,
&spi_nor_capabilities_fops);
+ if (spi_nor_has_default_locking_ops(nor))
+ debugfs_create_file("locked-sectors-map", 0444, d, nor, &spi_nor_locked_sectors_map_fops);
}
void spi_nor_debugfs_shutdown(void)
--
2.53.0
^ permalink raw reply related
* [PATCH v4 17/27] mtd: spi-nor: debugfs: Add locking support
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
The ioctl output may be counter intuitive in some cases. Asking for a
"locked status" over a region that is only partially locked will return
"unlocked" whereas in practice maybe the biggest part is actually
locked.
Knowing what is the real software locking state through debugfs would be
very convenient for development/debugging purposes, hence this proposal
for adding an extra block at the end of the file: a "locked sectors"
array which lists every section, if it is locked or not, showing both
the address ranges and the sizes in numbers of blocks.
Here is an example of output, what is after the "sector map" is new.
$ cat /sys/kernel/debug/spi-nor/spi0.0/params
name (null)
id ef a0 20 00 00 00
size 64.0 MiB
write size 1
page size 256
address nbytes 4
flags HAS_SR_TB | 4B_OPCODES | HAS_4BAIT | HAS_LOCK | HAS_16BIT_SR | HAS_SR_TB_BIT6 | HAS_4BIT_BP | SOFT_RESET | NO_WP
opcodes
read 0xec
dummy cycles 6
erase 0xdc
program 0x34
8D extension none
protocols
read 1S-4S-4S
write 1S-1S-4S
register 1S-1S-1S
erase commands
21 (4.00 KiB) [1]
dc (64.0 KiB) [3]
c7 (64.0 MiB)
sector map
region (in hex) | erase mask | overlaid
------------------+------------+---------
00000000-03ffffff | [ 3] | no
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03ffffff | unlocked | 1024
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
Here are below more examples of output with various situations. The full
output of the "params" content has been manually removed to only show
what has been added and how it behaves.
$ flash_lock -l /dev/mtd0 0x3f00000 16
$ cat /sys/kernel/debug/spi-nor/spi0.0/params
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03efffff | unlocked | 1008
03f00000-03ffffff | locked | 16
$
$ flash_lock -u /dev/mtd0 0x3f00000 8
$ cat /sys/kernel/debug/spi-nor/spi0.0/params
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03f7ffff | unlocked | 1016
03f80000-03ffffff | locked | 8
$
$ flash_lock -u /dev/mtd0
$ cat /sys/kernel/debug/spi-nor/spi0.0/params
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03ffffff | unlocked | 1024
$
$ flash_lock -l /dev/mtd0
$ cat /sys/kernel/debug/spi-nor/spi0.0/params
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-03ffffff | locked | 1024
$
$ flash_lock -u /dev/mtd0 0x20000 1022
$ cat /sys/kernel/debug/spi-nor/spi0.0/params
locked sectors
region (in hex) | status | #blocks
------------------+----------+--------
00000000-0001ffff | locked | 2
00020000-03ffffff | unlocked | 1022
---
drivers/mtd/spi-nor/core.h | 5 +++++
drivers/mtd/spi-nor/debugfs.c | 27 +++++++++++++++++++++++++++
drivers/mtd/spi-nor/swp.c | 16 ++++++++++++----
3 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 091eb934abe4..8717a0ad90f0 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -673,6 +673,7 @@ int spi_nor_post_bfpt_fixups(struct spi_nor *nor,
const struct sfdp_bfpt *bfpt);
void spi_nor_init_default_locking_ops(struct spi_nor *nor);
+bool spi_nor_has_default_locking_ops(struct spi_nor *nor);
void spi_nor_try_unlock_all(struct spi_nor *nor);
void spi_nor_cache_sr_lock_bits(struct spi_nor *nor, u8 *sr);
void spi_nor_set_mtd_locking_ops(struct spi_nor *nor);
@@ -707,6 +708,10 @@ static inline bool spi_nor_needs_sfdp(const struct spi_nor *nor)
return !nor->info->size;
}
+u64 spi_nor_get_min_prot_length_sr(struct spi_nor *nor);
+void spi_nor_get_locked_range_sr(struct spi_nor *nor, const u8 *sr, loff_t *ofs, u64 *len);
+bool spi_nor_is_locked_sr(struct spi_nor *nor, loff_t ofs, u64 len, const u8 *sr);
+
#ifdef CONFIG_DEBUG_FS
void spi_nor_debugfs_register(struct spi_nor *nor);
void spi_nor_debugfs_shutdown(void);
diff --git a/drivers/mtd/spi-nor/debugfs.c b/drivers/mtd/spi-nor/debugfs.c
index d0191eb9f879..298ce3d9e905 100644
--- a/drivers/mtd/spi-nor/debugfs.c
+++ b/drivers/mtd/spi-nor/debugfs.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/debugfs.h>
+#include <linux/math64.h>
#include <linux/mtd/spi-nor.h>
#include <linux/spi/spi.h>
#include <linux/spi/spi-mem.h>
@@ -77,10 +78,12 @@ static void spi_nor_print_flags(struct seq_file *s, unsigned long flags,
static int spi_nor_params_show(struct seq_file *s, void *data)
{
struct spi_nor *nor = s->private;
+ unsigned int min_prot_len = spi_nor_get_min_prot_length_sr(nor);
struct spi_nor_flash_parameter *params = nor->params;
struct spi_nor_erase_map *erase_map = ¶ms->erase_map;
struct spi_nor_erase_region *region = erase_map->regions;
const struct flash_info *info = nor->info;
+ loff_t lock_start, lock_length;
char buf[16], *str;
unsigned int i;
@@ -159,6 +162,30 @@ static int spi_nor_params_show(struct seq_file *s, void *data)
region[i].overlaid ? "yes" : "no");
}
+ if (!spi_nor_has_default_locking_ops(nor))
+ return 0;
+
+ seq_puts(s, "\nlocked sectors\n");
+ seq_puts(s, " region (in hex) | status | #blocks\n");
+ seq_puts(s, " ------------------+----------+--------\n");
+
+ spi_nor_get_locked_range_sr(nor, nor->dfs_sr_cache, &lock_start, &lock_length);
+ if (!lock_length || lock_length == params->size) {
+ seq_printf(s, " %08llx-%08llx | %s | %llu\n", 0ULL, params->size - 1,
+ lock_length ? " locked" : "unlocked",
+ div_u64(params->size, min_prot_len));
+ } else if (!lock_start) {
+ seq_printf(s, " %08llx-%08llx | %s | %llu\n", 0ULL, lock_length - 1,
+ " locked", div_u64(lock_length, min_prot_len));
+ seq_printf(s, " %08llx-%08llx | %s | %llu\n", lock_length, params->size - 1,
+ "unlocked", div_u64(params->size - lock_length, min_prot_len));
+ } else {
+ seq_printf(s, " %08llx-%08llx | %s | %llu\n", 0ULL, lock_start - 1,
+ "unlocked", div_u64(lock_start, min_prot_len));
+ seq_printf(s, " %08llx-%08llx | %s | %llu\n", lock_start, params->size - 1,
+ " locked", div_u64(lock_length, min_prot_len));
+ }
+
return 0;
}
DEFINE_SHOW_ATTRIBUTE(spi_nor_params);
diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
index 7a6c2b8ef921..d75ed83eb787 100644
--- a/drivers/mtd/spi-nor/swp.c
+++ b/drivers/mtd/spi-nor/swp.c
@@ -32,7 +32,7 @@ static u8 spi_nor_get_sr_tb_mask(struct spi_nor *nor)
return SR_TB_BIT5;
}
-static u64 spi_nor_get_min_prot_length_sr(struct spi_nor *nor)
+u64 spi_nor_get_min_prot_length_sr(struct spi_nor *nor)
{
unsigned int bp_slots, bp_slots_needed;
/*
@@ -53,8 +53,8 @@ static u64 spi_nor_get_min_prot_length_sr(struct spi_nor *nor)
return sector_size;
}
-static void spi_nor_get_locked_range_sr(struct spi_nor *nor, const u8 *sr, loff_t *ofs,
- u64 *len)
+void spi_nor_get_locked_range_sr(struct spi_nor *nor, const u8 *sr, loff_t *ofs,
+ u64 *len)
{
u64 min_prot_len;
u8 bp_mask = spi_nor_get_sr_bp_mask(nor);
@@ -112,7 +112,7 @@ static bool spi_nor_check_lock_status_sr(struct spi_nor *nor, loff_t ofs,
return (ofs >= lock_offs_max) || (offs_max <= lock_offs);
}
-static bool spi_nor_is_locked_sr(struct spi_nor *nor, loff_t ofs, u64 len, const u8 *sr)
+bool spi_nor_is_locked_sr(struct spi_nor *nor, loff_t ofs, u64 len, const u8 *sr)
{
return spi_nor_check_lock_status_sr(nor, ofs, len, sr, true);
}
@@ -410,6 +410,9 @@ static int spi_nor_sr_is_locked(struct spi_nor *nor, loff_t ofs, u64 len)
* -is_locked(): Checks if the region is *fully* locked, returns false otherwise.
* This feeback may be misleading because users may get an "unlocked"
* status even though a subpart of the region is effectively locked.
+ *
+ * If in doubt during development, check-out the debugfs output which tries to
+ * be more user friendly.
*/
static const struct spi_nor_locking_ops spi_nor_sr_locking_ops = {
.lock = spi_nor_sr_lock,
@@ -422,6 +425,11 @@ void spi_nor_init_default_locking_ops(struct spi_nor *nor)
nor->params->locking_ops = &spi_nor_sr_locking_ops;
}
+bool spi_nor_has_default_locking_ops(struct spi_nor *nor)
+{
+ return nor->params->locking_ops == &spi_nor_sr_locking_ops;
+}
+
static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, u64 len)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
--
2.53.0
^ permalink raw reply related
* [PATCH v4 16/27] mtd: spi-nor: Create a local SR cache
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
In order to be able to generate debugfs output without having to
actually reach the flash, create a SPI NOR local cache of the status
registers. What matters in our case are all the bits related to sector
locking. As such, in order to make it clear that this cache is not
intended to be used anywhere else, we zero the irrelevant bits.
The cache is initialized once during the early init, and then maintained
every time the write protection scheme is updated.
Suggested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/spi-nor/core.c | 6 +++++-
drivers/mtd/spi-nor/core.h | 1 +
drivers/mtd/spi-nor/swp.c | 35 +++++++++++++++++++++++++++++++++--
include/linux/mtd/spi-nor.h | 2 ++
4 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index f007bd6b389a..eb7744926e44 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3328,8 +3328,12 @@ static int spi_nor_init(struct spi_nor *nor)
*/
if (IS_ENABLED(CONFIG_MTD_SPI_NOR_SWP_DISABLE) ||
(IS_ENABLED(CONFIG_MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE) &&
- nor->flags & SNOR_F_SWP_IS_VOLATILE))
+ nor->flags & SNOR_F_SWP_IS_VOLATILE)) {
spi_nor_try_unlock_all(nor);
+ } else {
+ /* In the other cases, make sure the debugfs SR cache is up to date */
+ spi_nor_cache_sr_lock_bits(nor, NULL);
+ }
if (nor->addr_nbytes == 4 &&
nor->read_proto != SNOR_PROTO_8_8_8_DTR &&
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 3dc9ba3bc6da..091eb934abe4 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -674,6 +674,7 @@ int spi_nor_post_bfpt_fixups(struct spi_nor *nor,
void spi_nor_init_default_locking_ops(struct spi_nor *nor);
void spi_nor_try_unlock_all(struct spi_nor *nor);
+void spi_nor_cache_sr_lock_bits(struct spi_nor *nor, u8 *sr);
void spi_nor_set_mtd_locking_ops(struct spi_nor *nor);
void spi_nor_set_mtd_otp_ops(struct spi_nor *nor);
diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
index c3dbc8832025..7a6c2b8ef921 100644
--- a/drivers/mtd/spi-nor/swp.c
+++ b/drivers/mtd/spi-nor/swp.c
@@ -160,6 +160,25 @@ static int spi_nor_build_sr(struct spi_nor *nor, const u8 *old_sr, u8 *new_sr,
return 0;
}
+/*
+ * Keep a local cache containing all lock-related bits for debugfs use only.
+ * This way, debugfs never needs to access the flash directly.
+ */
+void spi_nor_cache_sr_lock_bits(struct spi_nor *nor, u8 *sr)
+{
+ u8 bp_mask = spi_nor_get_sr_bp_mask(nor);
+ u8 tb_mask = spi_nor_get_sr_tb_mask(nor);
+
+ if (!sr) {
+ if (spi_nor_read_sr(nor, nor->bouncebuf))
+ return;
+
+ sr = nor->bouncebuf;
+ }
+
+ nor->dfs_sr_cache[0] = sr[0] & (bp_mask | tb_mask | SR_SRWD);
+}
+
/*
* 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
@@ -269,7 +288,13 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
(ofs_old < ofs_new || (ofs_new + len_new) < (ofs_old + len_old)))
return -EINVAL;
- return spi_nor_write_sr_and_check(nor, status_new[0]);
+ ret = spi_nor_write_sr_and_check(nor, status_new[0]);
+ if (ret)
+ return ret;
+
+ spi_nor_cache_sr_lock_bits(nor, status_new);
+
+ return 0;
}
/*
@@ -351,7 +376,13 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
(ofs_new < ofs_old || (ofs_old + len_old) < (ofs_new + len_new)))
return -EINVAL;
- return spi_nor_write_sr_and_check(nor, status_new[0]);
+ ret = spi_nor_write_sr_and_check(nor, status_new[0]);
+ if (ret)
+ return ret;
+
+ spi_nor_cache_sr_lock_bits(nor, status_new);
+
+ return 0;
}
/*
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 90a0cf583512..9ad77f9e76c2 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -371,6 +371,7 @@ struct spi_nor_flash_parameter;
* @reg_proto: the SPI protocol for read_reg/write_reg/erase operations
* @sfdp: the SFDP data of the flash
* @debugfs_root: pointer to the debugfs directory
+ * @dfs_sr_cache: Status Register cached value for debugfs use only
* @controller_ops: SPI NOR controller driver specific operations.
* @params: [FLASH-SPECIFIC] SPI NOR flash parameters and settings.
* The structure includes legacy flash parameters and
@@ -409,6 +410,7 @@ struct spi_nor {
enum spi_nor_cmd_ext cmd_ext_type;
struct sfdp *sfdp;
struct dentry *debugfs_root;
+ u8 dfs_sr_cache[2];
const struct spi_nor_controller_ops *controller_ops;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 15/27] mtd: spi-nor: swp: Cosmetic changes
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
As a final preparation step for the introduction of CMP support, make
a few more cosmetic changes to simplify the reading of the diff when
adding the CMP feature. In particular, define "min_prot_len" earlier as
it will be reused and move the definition of the "ret" variable at the
end of the stack just because it looks better.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/spi-nor/swp.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
index c45a9ddd5788..c3dbc8832025 100644
--- a/drivers/mtd/spi-nor/swp.c
+++ b/drivers/mtd/spi-nor/swp.c
@@ -195,14 +195,14 @@ static int spi_nor_build_sr(struct spi_nor *nor, const u8 *old_sr, u8 *new_sr,
*/
static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
{
- u64 min_prot_len;
- int ret;
+ u64 min_prot_len = spi_nor_get_min_prot_length_sr(nor);
u8 status_old[1] = {}, status_new[1] = {};
loff_t ofs_old, ofs_new;
u64 len_old, len_new;
loff_t lock_len;
bool can_be_top = true, can_be_bottom = nor->flags & SNOR_F_HAS_SR_TB;
bool use_top;
+ int ret;
u8 pow;
ret = spi_nor_read_sr(nor, nor->bouncebuf);
@@ -236,12 +236,10 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
else
lock_len = ofs + len;
- if (lock_len == nor->params->size) {
+ if (lock_len == nor->params->size)
pow = (nor->flags & SNOR_F_HAS_4BIT_BP) ? GENMASK(3, 0) : GENMASK(2, 0);
- } else {
- min_prot_len = spi_nor_get_min_prot_length_sr(nor);
+ else
pow = ilog2(lock_len) - ilog2(min_prot_len) + 1;
- }
ret = spi_nor_build_sr(nor, status_old, status_new, pow, use_top);
if (ret)
@@ -281,7 +279,7 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
*/
static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
{
- u64 min_prot_len;
+ u64 min_prot_len = spi_nor_get_min_prot_length_sr(nor);
int ret;
u8 status_old[1], status_new[1];
loff_t ofs_old, ofs_new;
@@ -329,14 +327,11 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
else
lock_len = ofs;
- if (lock_len == 0) {
+ if (lock_len == 0)
pow = 0; /* fully unlocked */
- } else {
- min_prot_len = spi_nor_get_min_prot_length_sr(nor);
+ else
pow = ilog2(lock_len) - ilog2(min_prot_len) + 1;
- }
-
ret = spi_nor_build_sr(nor, status_old, status_new, pow, use_top);
if (ret)
return ret;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 14/27] mtd: spi-nor: swp: Simplify checking the locked/unlocked range
From: Miquel Raynal @ 2026-04-03 16:09 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano,
Richard Weinberger, Vignesh Raghavendra, Jonathan Corbet
Cc: Sean Anderson, Thomas Petazzoni, Steam Lin, linux-mtd,
linux-kernel, linux-doc, Miquel Raynal
In-Reply-To: <20260403-winbond-v6-18-rc1-spi-nor-swp-v4-0-833dab5e7288@bootlin.com>
In both the locking/unlocking steps, at the end we verify whether we do
not lock/unlock more than requested (in which case an error must be
returned).
While being possible to do that with very simple mask comparisons, it
does not scale when adding extra locking features such as the CMP
possibility. In order to make these checks slightly easier to read and
more future proof, use existing helpers to read the (future) status
register, extract the covered range, and compare it with very usual
algebric comparisons.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/spi-nor/swp.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi-nor/swp.c b/drivers/mtd/spi-nor/swp.c
index e2e423b20989..c45a9ddd5788 100644
--- a/drivers/mtd/spi-nor/swp.c
+++ b/drivers/mtd/spi-nor/swp.c
@@ -198,7 +198,8 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
u64 min_prot_len;
int ret;
u8 status_old[1] = {}, status_new[1] = {};
- u8 bp_mask = spi_nor_get_sr_bp_mask(nor);
+ loff_t ofs_old, ofs_new;
+ u64 len_old, len_new;
loff_t lock_len;
bool can_be_top = true, can_be_bottom = nor->flags & SNOR_F_HAS_SR_TB;
bool use_top;
@@ -246,10 +247,6 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
if (ret)
return ret;
- /* Don't "lock" with no region! */
- if (!(status_new[0] & bp_mask))
- return -EINVAL;
-
/*
* Disallow further writes if WP# pin is neither left floating nor
* wrongly tied to GND (that includes internal pull-downs).
@@ -262,8 +259,16 @@ static int spi_nor_sr_lock(struct spi_nor *nor, loff_t ofs, u64 len)
if (status_new[0] == status_old[0])
return 0;
+ spi_nor_get_locked_range_sr(nor, status_old, &ofs_old, &len_old);
+ spi_nor_get_locked_range_sr(nor, status_new, &ofs_new, &len_new);
+
+ /* Don't "lock" with no region! */
+ if (!len_new)
+ return -EINVAL;
+
/* Only modify protection if it will not unlock other areas */
- if ((status_new[0] & bp_mask) < (status_old[0] & bp_mask))
+ if (len_old &&
+ (ofs_old < ofs_new || (ofs_new + len_new) < (ofs_old + len_old)))
return -EINVAL;
return spi_nor_write_sr_and_check(nor, status_new[0]);
@@ -279,7 +284,8 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
u64 min_prot_len;
int ret;
u8 status_old[1], status_new[1];
- u8 bp_mask = spi_nor_get_sr_bp_mask(nor);
+ loff_t ofs_old, ofs_new;
+ u64 len_old, len_new;
loff_t lock_len;
bool can_be_top = true, can_be_bottom = nor->flags & SNOR_F_HAS_SR_TB;
bool use_top;
@@ -344,7 +350,10 @@ static int spi_nor_sr_unlock(struct spi_nor *nor, loff_t ofs, u64 len)
return 0;
/* Only modify protection if it will not lock other areas */
- if ((status_new[0] & bp_mask) > (status_old[0] & bp_mask))
+ spi_nor_get_locked_range_sr(nor, status_old, &ofs_old, &len_old);
+ spi_nor_get_locked_range_sr(nor, status_new, &ofs_new, &len_new);
+ if (len_old && len_new &&
+ (ofs_new < ofs_old || (ofs_old + len_old) < (ofs_new + len_new)))
return -EINVAL;
return spi_nor_write_sr_and_check(nor, status_new[0]);
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox