aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-01-30clk: microchip: core: update include to use pic32.h from platform_dataBrian Masney1-1/+1
Use the linux/platform_data/pic32.h include instead of asm/mach-pic32/pic32.h so that the asm variant can be dropped. This is in preparation for allowing some drivers to be compiled on other architectures with COMPILE_TEST enabled. Signed-off-by: Brian Masney <bmasney@redhat.com> Acked-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-01-30MIPS: update include to use pic32.h from platform_dataBrian Masney4-5/+4
Use the linux/platform_data/pic32.h include instead of asm/mach-pic32/pic32.h so that the asm variant can be dropped. This is in preparation for allowing some drivers to be compiled on other architectures with COMPILE_TEST enabled. Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-01-30MAINTAINERS: add include/linux/platform_data/pic32.h to MIPS entryBrian Masney1-0/+1
Add the file include/linux/platform_data/pic32.h to the MIPS maintainer entry. Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-01-30MIPS: copy pic32.h header file from asm/mach-pic32/ to include/platform-data/Brian Masney1-0/+39
There are currently some pic32 MIPS drivers that are in tree, and are only configured to be compiled on the pic32 platform. There's a risk of breaking some of these drivers when migrating drivers away from legacy APIs. It happened to me with a pic32 clk driver. Let's go ahead and copy the MIPS pic32.h header to include/linux/platform_data/, and make a minor update to allow compiling this on other architectures. This will make it easier, and cleaner to enable COMPILE_TEST for some of these pic32 drivers. The asm variant of the header file will be dropped once all drivers have been updated. Link: https://lore.kernel.org/linux-clk/CABx5tq+eOocJ41X-GSgkGy6S+s+Am1yCS099wqP695NtwALTmg@mail.gmail.com/T/ Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-01-30MIPS: pic32: drop unused include linux/io.h from pic32.hBrian Masney1-1/+0
The linux/io.h include is not used, so let's drop it from pic32.h. Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-01-30MIPS: pic32: include linux/types.h on pic32.hBrian Masney1-0/+1
The pic32.h header file currently includes linux/io.h, however that header is not actually used. The only header that's needed by this C file is linux/types.h. Let's include it so that linux/io.h can be dropped. Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-01-30MIPS: pic32: include linux/io.h header on several filesBrian Masney3-0/+3
The pic32.h header includes linux/io.h, however nothing from that include file is directly used by pic32.h. Several C files that include pic32.h indirectly depend on linux/io.h, so let's go ahead and add the missing include so that linux/io.h can be dropped from pic32.h. Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-01-30mips: LOONGSON32: drop a dangling Kconfig symbolRandy Dunlap1-1/+0
CPU_HAS_LOAD_STORE_LR is not used anywhere in the kernel sources, so drop it. Fixes: 85c4354076ca ("MIPS: loongson32: Switch to generic core") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Keguang Zhang <keguang.zhang@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-01-30MIPS: Loongson: Make cpumask_of_node() robust against NUMA_NO_NODEJohn Garry1-1/+1
The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which is a valid index - so add a check for this. Signed-off-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2026-01-30mtd: spinand: Disable continuous read during probeDavid LaPorte1-0/+8
Macronix serial NAND devices with continuous read support do not clear the configuration register on soft reset and lack a hardware reset pin. When continuous read is interrupted (e.g., during reboot), the feature remains enabled at the device level. With continuous read enabled, the OOB area becomes inaccessible and all reads are instead directed to the main area. As a result, during partition allocation as part of MTD device registration, the first two bytes of the main area for the master block are read and indicate that the block is bad. This process repeats for every subsequent block for the partition. All reads and writes that reference the BBT find no good blocks and fail. The only paths for recovery from this state are triggering the continuous read feature by way of raw MTD reads or through a NAND device power drain. Disable continuous read explicitly during spinand probe to ensure quiescent feature state. Fixes: 631cfdd0520d ("mtd: spi-nand: Add continuous read support") Cc: stable@vger.kernel.org Signed-off-by: David LaPorte <dalaport@amazon.com> Reviewed-by: Gunnar Kudrjavets <gunnarku@amazon.com> Reviewed-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-30ASoC: codecs: max98390: Check return value of devm_gpiod_get_optional() in ↵Chen Ni1-0/+3
max98390_i2c_probe() The devm_gpiod_get_optional() function may return an error pointer (ERR_PTR) in case of a genuine failure during GPIO acquisition, not just NULL which indicates the legitimate absence of an optional GPIO. Add an IS_ERR() check after the function call to catch such errors and propagate them to the probe function, ensuring the driver fails to load safely rather than proceeding with an invalid pointer. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://patch.msgid.link/20260130091904.3426149-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-30spi: tegra210-quad: Protect curr_xfer check in IRQ handlerBreno Leitao1-0/+20
Now that all other accesses to curr_xfer are done under the lock, protect the curr_xfer NULL check in tegra_qspi_isr_thread() with the spinlock. Without this protection, the following race can occur: CPU0 (ISR thread) CPU1 (timeout path) ---------------- ------------------- if (!tqspi->curr_xfer) // sees non-NULL spin_lock() tqspi->curr_xfer = NULL spin_unlock() handle_*_xfer() spin_lock() t = tqspi->curr_xfer // NULL! ... t->len ... // NULL dereference! With this patch, all curr_xfer accesses are now properly synchronized. Although all accesses to curr_xfer are done under the lock, in tegra_qspi_isr_thread() it checks for NULL, releases the lock and reacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer(). There is a potential for an update in between, which could cause a NULL pointer dereference. To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared curr_xfer, the handler will safely return without dereferencing the NULL pointer. Fixes: b4e002d8a7ce ("spi: tegra210-quad: Fix timeout handling") Signed-off-by: Breno Leitao <leitao@debian.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260126-tegra_xfer-v2-6-6d2115e4f387@debian.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-30spi: tegra210-quad: Protect curr_xfer clearing in ↵Breno Leitao1-0/+3
tegra_qspi_non_combined_seq_xfer Protect the curr_xfer clearing in tegra_qspi_non_combined_seq_xfer() with the spinlock to prevent a race with the interrupt handler that reads this field to check if a transfer is in progress. Fixes: b4e002d8a7ce ("spi: tegra210-quad: Fix timeout handling") Signed-off-by: Breno Leitao <leitao@debian.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260126-tegra_xfer-v2-5-6d2115e4f387@debian.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-30spi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xferBreno Leitao1-0/+5
The curr_xfer field is read by the IRQ handler without holding the lock to check if a transfer is in progress. When clearing curr_xfer in the combined sequence transfer loop, protect it with the spinlock to prevent a race with the interrupt handler. Protect the curr_xfer clearing at the exit path of tegra_qspi_combined_seq_xfer() with the spinlock to prevent a race with the interrupt handler that reads this field. Without this protection, the IRQ handler could read a partially updated curr_xfer value, leading to NULL pointer dereference or use-after-free. Fixes: b4e002d8a7ce ("spi: tegra210-quad: Fix timeout handling") Signed-off-by: Breno Leitao <leitao@debian.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260126-tegra_xfer-v2-4-6d2115e4f387@debian.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-30spi: tegra210-quad: Protect curr_xfer assignment in ↵Breno Leitao1-0/+3
tegra_qspi_setup_transfer_one When the timeout handler processes a completed transfer and signals completion, the transfer thread can immediately set up the next transfer and assign curr_xfer to point to it. If a delayed ISR from the previous transfer then runs, it checks if (!tqspi->curr_xfer) (currently without the lock also -- to be fixed soon) to detect stale interrupts, but this check passes because curr_xfer now points to the new transfer. The ISR then incorrectly processes the new transfer's context. Protect the curr_xfer assignment with the spinlock to ensure the ISR either sees NULL (and bails out) or sees the new value only after the assignment is complete. Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller") Signed-off-by: Breno Leitao <leitao@debian.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260126-tegra_xfer-v2-3-6d2115e4f387@debian.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-30spi: tegra210-quad: Move curr_xfer read inside spinlockBreno Leitao1-2/+4
Move the assignment of the transfer pointer from curr_xfer inside the spinlock critical section in both handle_cpu_based_xfer() and handle_dma_based_xfer(). Previously, curr_xfer was read before acquiring the lock, creating a window where the timeout path could clear curr_xfer between reading it and using it. By moving the read inside the lock, the handlers are guaranteed to see a consistent value that cannot be modified by the timeout path. Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller") Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Thierry Reding <treding@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260126-tegra_xfer-v2-2-6d2115e4f387@debian.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-30spi: tegra210-quad: Return IRQ_HANDLED when timeout already processed transferBreno Leitao1-2/+17
When the ISR thread wakes up late and finds that the timeout handler has already processed the transfer (curr_xfer is NULL), return IRQ_HANDLED instead of IRQ_NONE. Use a similar approach to tegra_qspi_handle_timeout() by reading QSPI_TRANS_STATUS and checking the QSPI_RDY bit to determine if the hardware actually completed the transfer. If QSPI_RDY is set, the interrupt was legitimate and triggered by real hardware activity. The fact that the timeout path handled it first doesn't make it spurious. Returning IRQ_NONE incorrectly suggests the interrupt wasn't for this device, which can cause issues with shared interrupt lines and interrupt accounting. Fixes: b4e002d8a7ce ("spi: tegra210-quad: Fix timeout handling") Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Usama Arif <usamaarif642@gmail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20260126-tegra_xfer-v2-1-6d2115e4f387@debian.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-30EDAC/r82600: Remove this obsolete driverEthan Nelson-Moore5-440/+1
This driver supports the Radisys 82600 embedded chipset, which was used with Pentium III-era CPUs. It is highly unlikely that it is still used. Besides its own documentation, the only information I was able to find about the R82600, after looking through many pages of Google results, was that it was used in a Nokia 2G GSM base station. The original author said: "This was after Bluesmoke (watch was out-of-tree), and was pay of the first set of in tree edac drivers (a fresh design as far as I remember). This particular driver did apparently get used by Akamai quite heavily and widely  but all ancient history now. The Radisys r82600 edac driver  r82600_edac.c was closely related hardware from the same era, and can probably go too (although being embedded hardware, it's possible its production lifespan was considerably longer). Tim." Mail is https://lore.kernel.org/r/01BCCA37-F6A2-458B-BFE7-99C7724CDDEA@buttersideup.com but lkml drops html mail so quoting the relevant info here too. [ bp: Massage and extend commit message. ] Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260130052633.13119-1-enelsonmoore@gmail.com
2026-01-30gfs2: Fix use-after-free in iomap inline data write pathDeepanshu Kartikey1-1/+12
The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().] Reported-by: syzbot+ea1cd4aa4d1e98458a55@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ea1cd4aa4d1e98458a55 Fixes: d0a22a4b03b8 ("gfs2: Fix iomap write page reclaim deadlock") Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2026-01-30pkcs7, x509: Add ML-DSA supportDavid Howells4-2/+64
Add support for ML-DSA keys and signatures to the CMS/PKCS#7 and X.509 implementations. ML-DSA-44, -65 and -87 are all supported. For X.509 certificates, the TBSCertificate is required to be signed directly; for CMS, direct signing of the data is preferred, though use of SHA512 (and only that) as an intermediate hash of the content is permitted with signedAttrs. Signed-off-by: David Howells <dhowells@redhat.com> cc: Lukas Wunner <lukas@wunner.de> cc: Ignat Korchagin <ignat@cloudflare.com> cc: Stephan Mueller <smueller@chronox.de> cc: Eric Biggers <ebiggers@kernel.org> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: keyrings@vger.kernel.org cc: linux-crypto@vger.kernel.org
2026-01-30pkcs7: Allow the signing algo to do whatever digestion it wants itselfDavid Howells5-20/+51
Allow the data to be verified in a PKCS#7 or CMS message to be passed directly to an asymmetric cipher algorithm (e.g. ML-DSA) if it wants to do whatever passes for hashing/digestion itself. The normal digestion of the data is then skipped as that would be ignored unless another signed info in the message has some other algorithm that needs it. The 'data to be verified' may be the content of the PKCS#7 message or it will be the authenticatedAttributes (signedAttrs if CMS), modified, if those are present. This is done by: (1) Make ->m and ->m_size point to the data to be verified rather than making public_key_verify_signature() access the data directly. This is so that keyctl(KEYCTL_PKEY_VERIFY) will still work. (2) Add a flag, ->algo_takes_data, to indicate that the verification algorithm wants to access the data to be verified directly rather than having it digested first. (3) If the PKCS#7 message has authenticatedAttributes (or CMS signedAttrs), then the digest contained therein will be validated as now, and the modified attrs blob will either be digested or assigned to ->m as appropriate. (4) If present, always copy and modify the authenticatedAttributes (or signedAttrs) then digest that in one go rather than calling the shash update twice (once for the tag and once for the rest). (5) For ML-DSA, point ->m to the TBSCertificate instead of digesting it and using the digest. Note that whilst ML-DSA does allow for an "external mu", CMS doesn't yet have that standardised. Signed-off-by: David Howells <dhowells@redhat.com> cc: Lukas Wunner <lukas@wunner.de> cc: Ignat Korchagin <ignat@cloudflare.com> cc: Stephan Mueller <smueller@chronox.de> cc: Eric Biggers <ebiggers@kernel.org> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: keyrings@vger.kernel.org cc: linux-crypto@vger.kernel.org
2026-01-30pkcs7, x509: Rename ->digest to ->mDavid Howells7-29/+26
Rename ->digest and ->digest_len to ->m and ->m_size to represent the input to the signature verification algorithm, reflecting that ->digest may no longer actually *be* a digest. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> cc: Lukas Wunner <lukas@wunner.de> cc: Ignat Korchagin <ignat@cloudflare.com> cc: Stephan Mueller <smueller@chronox.de> cc: Eric Biggers <ebiggers@kernel.org> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: keyrings@vger.kernel.org cc: linux-crypto@vger.kernel.org
2026-01-30x509: Separately calculate sha256 for blacklistDavid Howells2-9/+15
Calculate the SHA256 hash for blacklisting purposes independently of the signature hash (which may be something other than SHA256). This is necessary because when ML-DSA is used, no digest is calculated. Note that this represents a change of behaviour in that the hash used for the blacklist check would previously have been whatever digest was used for, say, RSA-based signatures. It may be that this is inadvisable. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> cc: Lukas Wunner <lukas@wunner.de> cc: Ignat Korchagin <ignat@cloudflare.com> cc: Stephan Mueller <smueller@chronox.de> cc: Eric Biggers <ebiggers@kernel.org> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: keyrings@vger.kernel.org cc: linux-crypto@vger.kernel.org
2026-01-30pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domainsXu Yang1-1/+1
Fix out-of-range access of bc->domains in imx8m_blk_ctrl_remove(). Fixes: 2684ac05a8c4 ("soc: imx: add i.MX8M blk-ctrl driver") Cc: stable@kernel.org Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-01-30irqchip/gic-v5: Check if impl is virt capableSascha Bischoff3-0/+16
Now that there is support for creating a GICv5-based guest with KVM, check that the hardware itself supports virtualisation, skipping the setting of struct gic_kvm_info if not. Note: If native GICv5 virt is not supported, then nor is FEAT_GCIE_LEGACY, so we are able to skip altogether. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20260128175919.3828384-33-sascha.bischoff@arm.com [maz: cosmetic changes] Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-30KVM: arm64: gic: Set vgic_model before initing private IRQsSascha Bischoff1-4/+4
Different GIC types require the private IRQs to be initialised differently. GICv5 is the culprit as it supports both a different number of private IRQs, and all of these are PPIs (there are no SGIs). Moreover, as GICv5 uses the top bits of the interrupt ID to encode the type, the intid also needs to computed differently. Up until now, the GIC model has been set after initialising the private IRQs for a VCPU. Move this earlier to ensure that the GIC model is available when configuring the private IRQs. While we're at it, also move the setting of the in_kernel flag and implementation revision to keep them grouped together as before. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20260128175919.3828384-7-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-30arm64/sysreg: Drop ICH_HFGRTR_EL2.ICC_HAPR_EL1 and make RES1Sascha Bischoff2-2/+1
The GICv5 architecture is dropping the ICC_HAPR_EL1 and ICV_HAPR_EL1 system registers. These registers were never added to the sysregs, but the traps for them were. Drop the trap bit from the ICH_HFGRTR_EL2 and make it Res1 as per the upcoming GICv5 spec change. Additionally, update the EL2 setup code to not attempt to set that bit. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20260128175919.3828384-4-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-30KVM: arm64: gic-v3: Switch vGIC-v3 to use generated ICH_VMCR_EL2Sascha Bischoff4-95/+51
The VGIC-v3 code relied on hand-written definitions for the ICH_VMCR_EL2 register. This register, and the associated fields, is now generated as part of the sysreg framework. Move to using the generated definitions instead of the hand-written ones. There are no functional changes as part of this change. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20260128175919.3828384-3-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-30pwm: Remove redundant check in pwm_ops_check()Ben Zong-You Xie1-2/+1
ops->write_waveform is already known to be non-NULL so there is no need to check it a second time. The superflous check was introduced in commit 17e40c25158f ("pwm: New abstraction for PWM waveforms"). Signed-off-by: Ben Zong-You Xie <ben717@andestech.com> Link: https://patch.msgid.link/20260129-fix-pwm-ops-check-v1-1-6f0b7952c875@andestech.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-01-30KVM: arm64: Fix various commentsZenghui Yu (Huawei)3-3/+3
Use tab instead of whitespaces, as well as 2 minor typo fixes. Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Link: https://patch.msgid.link/20260128075208.23024-1-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-30KVM: arm64: nv: Add trap config for DBGWCR<15>_EL1Zenghui Yu (Huawei)1-0/+1
Seems that it was missed when MDCR_EL2 was first added to the trap forwarding infrastructure. Add it back. Fixes: cb31632c4452 ("KVM: arm64: nv: Add trap forwarding for MDCR_EL2") Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev> Link: https://patch.msgid.link/20260130094435.39942-1-zenghui.yu@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-01-30xfs: add sysfs stats for zoned GCChristoph Hellwig3-1/+18
Add counters of read, write and zone_reset operations as well as GC written bytes to sysfs. This way they can be easily used for monitoring tools and test cases. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: give the defer_relog stat a xs_ prefixChristoph Hellwig3-5/+5
Make this counter naming consistent with all the others. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: add zone reset error injectionChristoph Hellwig2-4/+15
Add a new errortag to test that zone reset errors are handled correctly. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: refactor zone reset handlingChristoph Hellwig1-21/+28
Include the actual bio submission in the common zone reset handler to share more code and prepare for adding error injection for zone reset. Note the I plan to refactor the block layer submit_bio_wait and bio_await_chain code in the next merge window to remove some of the code duplication added here. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: don't mark all discard issued by zoned GC as syncChristoph Hellwig1-1/+2
Discard are not usually sync when issued from zoned garbage collection, so drop the REQ_SYNC flag. Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: allow setting errortags at mount timeChristoph Hellwig4-1/+55
Add an errortag mount option that enables an errortag with the default injection frequency. This allows injecting errors into the mount process instead of just on live file systems, and thus test mount error handling. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: use WRITE_ONCE/READ_ONCE for m_errortagChristoph Hellwig1-9/+14
There is no synchronization for updating m_errortag, which is fine as it's just a debug tool. It would still be nice to fully avoid the theoretical case of torn values, so use WRITE_ONCE and READ_ONCE to access the members. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: move the guts of XFS_ERRORTAG_DELAY out of lineChristoph Hellwig2-12/+24
Mirror what is done for the more common XFS_ERRORTAG_TEST version, and also only look at the error tag value once now that we can easily have a local variable. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: don't validate error tags in the I/O pathChristoph Hellwig3-30/+12
We can trust XFS developers enough to not pass random stuff to XFS_ERROR_TEST/DELAY. Open code the validity check in xfs_errortag_add, which is the only place that receives unvalidated error tag values from user space, and drop the now pointless xfs_errortag_enabled helper. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: allocate m_errortag earlyChristoph Hellwig2-25/+13
Ensure the mount structure always has a valid m_errortag for debug builds. This removes the NULL checking from the runtime code, and prepares for allowing to set errortags from mount. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: fix the errno sign for the xfs_errortag_{add,clearall} stubsChristoph Hellwig1-2/+2
All errno values should be negative in the kernel. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30xfs: validate log record version against superblock log versionRaphael Pinsonneault-Thibeault1-11/+16
Syzbot creates a fuzzed record where xfs_has_logv2() but the xlog_rec_header h_version != XLOG_VERSION_2. This causes a KASAN: slab-out-of-bounds read in xlog_do_recovery_pass() -> xlog_recover_process() -> xlog_cksum(). Fix by adding a check to xlog_valid_rec_header() to abort journal recovery if the xlog_rec_header h_version does not match the super block log version. A file system with a version 2 log will only ever set XLOG_VERSION_2 in its headers (and v1 will only ever set V_1), so if there is any mismatch, either the journal or the superblock has been corrupted and therefore we abort processing with a -EFSCORRUPTED error immediately. Also, refactor the structure of the validity checks for better readability. At the default error level (LOW), XFS_IS_CORRUPT() emits the condition that failed, the file and line number it is located at, then dumps the stack. This gives us everything we need to know about the failure if we do a single validity check per XFS_IS_CORRUPT(). Reported-by: syzbot+9f6d080dece587cfdd4c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9f6d080dece587cfdd4c Tested-by: syzbot+9f6d080dece587cfdd4c@syzkaller.appspotmail.com Fixes: 45cf976008dd ("xfs: fix log recovery buffer allocation for the legacy h_size fixup") Signed-off-by: Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-01-30platform/chrome: lightbar: Add support for large sequenceGwendal Grignou2-27/+74
Current sequences are limited to 192 bytes. Increase support to whatever the EC support. If the sequence is too long, the EC will return an OVERFLOW error. Test: Check sending a large sequence is received by the EC. Signed-off-by: Gwendal Grignou <gwendal@google.com> Link: https://lore.kernel.org/r/20260130081351.487517-2-gwendal@google.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2026-01-30platform/chrome: lightbar: Report number of segmentsGwendal Grignou2-0/+54
Add attribue `num_segments` to return the number of exposed LED segments in the lightbar. It can be smaller than the number of physical leds in the lightbar. Test: Check the attribute is present and returns a value when read. Signed-off-by: Gwendal Grignou <gwendal@google.com> Link: https://lore.kernel.org/r/20260130081351.487517-1-gwendal@google.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2026-01-30crypto: inside-secure/eip93 - unregister only available algorithmAleksander Jan Bajkowski1-39/+53
EIP93 has an options register. This register indicates which crypto algorithms are implemented in silicon. Supported algorithms are registered on this basis. Unregister algorithms on the same basis. Currently, all algorithms are unregistered, even those not supported by HW. This results in panic on platforms that don't have all options implemented in silicon. Fixes: 9739f5f93b78 ("crypto: eip93 - Add Inside Secure SafeXcel EIP-93 crypto engine support") Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Acked-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-01-30crypto: ccp - Fix a crash due to incorrect cleanup usage of kfreeElla Ma1-1/+1
Annotating a local pointer variable, which will be assigned with the kmalloc-family functions, with the `__cleanup(kfree)` attribute will make the address of the local variable, rather than the address returned by kmalloc, passed to kfree directly and lead to a crash due to invalid deallocation of stack address. According to other places in the repo, the correct usage should be `__free(kfree)`. The code coincidentally compiled because the parameter type `void *` of kfree is compatible with the desired type `struct { ... } **`. Fixes: a71475582ada ("crypto: ccp - reduce stack usage in ccp_run_aes_gcm_cmd") Signed-off-by: Ella Ma <alansnape3058@gmail.com> Acked-by: Tom Lendacky <thomas.lendacky@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-01-30crypto: stm32 - Remove unnecessary checks before calling memcpyThorsten Blum1-4/+2
memcpy() can be safely called with size 0, which is a no-op. Remove the unnecessary checks before calling memcpy(). Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-01-30crypto: omap - Use sysfs_emit in sysfs show functionsThorsten Blum2-3/+5
Replace sprintf() with sysfs_emit() in sysfs show functions. sysfs_emit() is preferred to format sysfs output as it provides better bounds checking. No functional changes. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-01-30platform/chrome: cros_ec_lightbar: Fix response size initializationTzung-Bi Shih1-1/+1
Commit 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command") meant to set smaller values for both request and response sizes. However, it incorrectly assigned the response size to the `result` field instead of `insize`. Fix it. Reported-by: Gwendal Grignou <gwendal@google.com> Closes: https://lore.kernel.org/chrome-platform/CAMHSBOVrrYaB=1nEqZk09VkczCrj=6B-P8Fe29TpPdSDgT2CCQ@mail.gmail.com Fixes: 1e7913ff5f9f ("platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command") Link: https://lore.kernel.org/r/20260130040335.361997-1-tzungbi@kernel.org Reviewed-by: Gwendal Grignou <gwendal@google.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>