summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-22drm/panthor: Add tracepoint for hardware utilisation changesNicolas Frattaroli
Mali GPUs have three registers that indicate which parts of the hardware are powered at any moment. These take the form of bitmaps. In the case of SHADER_READY for example, a high bit indicates that the shader core corresponding to that bit index is powered on. These bitmaps aren't solely contiguous bits, as it's common to have holes in the sequence of shader core indices, and the actual set of which cores are present is defined by the "shader present" register. When the GPU finishes a power state transition, it fires a GPU_IRQ_POWER_CHANGED_ALL interrupt. After such an interrupt is received, the _READY registers will contain new interesting data. During power transitions, the GPU_IRQ_POWER_CHANGED interrupt will fire, and the registers will likewise contain potentially changed data. This is not to be confused with the PWR_IRQ_POWER_CHANGED_ALL interrupt, which is something related to Mali v14+'s power control logic. The _READY registers and corresponding interrupts are already available in v9 and onwards. Expose the data as a tracepoint to userspace. This allows users to debug various scenarios and gather interesting information, such as: knowing how much hardware is lit up at any given time, correlating graphics corruption with a specific powered shader core, measuring when hardware is allowed to go to a powered off state again, and so on. The registration/unregistration functions for the tracepoint go through a wrapper in panthor_hw.c, so that v14+ can implement the same tracepoint by adding its hardware specific IRQ on/off callbacks to the panthor_hw.ops member. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260116-panthor-tracepoints-v10-3-d925986e3d1b@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2026-01-22drm/panthor: Extend IRQ helpers for mask modification/restorationNicolas Frattaroli
The current IRQ helpers do not guarantee mutual exclusion that covers the entire transaction from accessing the mask member and modifying the mask register. This makes it hard, if not impossible, to implement mask modification helpers that may change one of these outside the normal suspend/resume/isr code paths. Add a spinlock to struct panthor_irq that protects both the mask member and register. Acquire it in all code paths that access these, but drop it before processing the threaded handler function. Then, add the aforementioned new helpers: enable_events, and disable_events. They work by ORing and NANDing the mask bits. resume is changed to no longer have a mask passed, as pirq->mask is supposed to be the user-requested mask now, rather than a mirror of the INT_MASK register contents. Users of the resume helper are adjusted accordingly, including a rather painful refactor in panthor_mmu.c. In panthor_mmu.c, the bespoke mask modification is excised, and replaced with enable_events/disable_events in as_enable/as_disable. Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260116-panthor-tracepoints-v10-2-d925986e3d1b@collabora.com
2026-01-22drm/panthor: Rework panthor_irq::suspended into panthor_irq::stateNicolas Frattaroli
To deal with the threaded interrupt handler and a suspend action overlapping, the boolean panthor_irq::suspended is not sufficient. Rework it into taking several different values depending on the current state, and check it and set it within the IRQ helper functions. Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20260116-panthor-tracepoints-v10-1-d925986e3d1b@collabora.com
2026-01-22mtd: parsers: Fix memory leak in mtd_parser_tplink_safeloader_parse()Zilin Guan
The function mtd_parser_tplink_safeloader_parse() allocates buf via mtd_parser_tplink_safeloader_read_table(). If the allocation for parts[idx].name fails inside the loop, the code jumps to the err_free label without freeing buf, leading to a memory leak. Fix this by freeing the temporary buffer buf in the err_free label. Compile tested only. Issue found using a prototype static analysis tool and code review. Fixes: 00a3588084be ("mtd: parsers: add TP-Link SafeLoader partitions table parser") Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22dt-bindings: mtd: partitions: Combine simple partition bindingsRob Herring (Arm)
Several partition node bindings are just a compatible plus properties defined in partition.yaml. Move all of these bindings to a single schema file. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22dt-bindings: mtd: partitions: Convert brcm,trx to DT schemaRob Herring (Arm)
Convert the brcm,trx partition binding to DT schema format. As the "linksys,ns-firmware" compatible also uses "brcm,trx" as a fallback, move it to the converted binding. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22dt-bindings: mtd: fixed-partitions: Restrict undefined propertiesRob Herring (Arm)
The fixed-partitions schema allowed undefined properties in order to avoid warnings when there are nested fixed-partitions. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22dt-bindings: mtd: Ensure partition node properties are documentedRob Herring (Arm)
Partition nodes without a compatible have no restrictions on additional properties. Fix this by ensuring 'unevaluatedProperties' is set when there's no compatible property. If there is a compatible property, then there should be a specific schema for it which will enforce 'unevaluatedProperties'. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22dt-bindings: mtd: partitions: Drop partitions.yamlRob Herring (Arm)
The partitions.yaml schema is an unusual structure in that it includes all possible partition types, and it disables the normal matching by compatible strings. As partitions.yaml has nothing to match on, it is only applied when explicitly referenced. The use of "oneOf" also results in misleading warnings which are difficult to understand. Drop partitions.yaml and rely on the standard compatible matching instead. The "mmc-card" case previously allowed any partition type, but now only allows "fixed-partitions". There aren't any users and the original intent appeared to be only for "fixed-partitions". Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22dt-bindings: mtd: partitions: Define "#{address,size}-cells" in specific schemasRob Herring (Arm)
Whether "#address-cells" and "#size-cells" are used or not depends on the specific partition type, so drop them from partitions.yaml and define them in the specific partition schemas as needed. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22dt-bindings: mtd: partitions: Allow "nvmem-layout" in generic partition nodesRob Herring (Arm)
An "nvmem-layout" node can be used in any partition node, so add it. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22dt-bindings: mtd: partitions: Move "sercomm,scpart-id" to partition.yamlRob Herring (Arm)
Defining child node properties specific to the parent schema doesn't work unless all the child node properties are known. They aren't known because any partition can define its own properties. The solution to this is typically something like spi-peripheral-props.yaml, but that's overkill for this single property. Just move it to partition.yaml instead. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22dt-bindings: mtd: fixed-partitions: Move "compression" to partition nodeRob Herring (Arm)
The "compression" property is defined in the wrong place as it applies to individual partitions nodes, not all nodes. Fixes: 8baba8d52ff5 ("dt-bindings: mtd: fixed-partitions: Add compression property") Reviewed-by: Simon Glass <simon.glass@canonical.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22dt-bindings: mtd: brcm,brcmnand: Drop "brcm,brcmnand" compatible for iProcRob Herring (Arm)
Some users of "brcm,nand-iproc" include "brcm,brcmnand" and some don't. The "brcm,brcmnand" compatible is not useful for iProc systems as there's a separate driver for iProc. So drop it as a fallback. Reviewed-by: William Zhang <william.zhang@broadcom.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22mtd: jedec_probe: fix shift-out-of-bounds UB in JEDEC ID maskingChenxi Hou
UBSAN reports shift-out-of-bounds in jedec_read_mfr() and jedec_read_id():   UBSAN: shift-out-of-bounds in drivers/mtd/chips/jedec_probe.c:1924:13   shift exponent 32 is too large for 32-bit type 'int'   UBSAN: shift-out-of-bounds in drivers/mtd/chips/jedec_probe.c:1940:12   shift exponent 32 is too large for 32-bit type 'int' The JEDEC manufacturer/device ID masking uses:   (1 << (cfi->device_type * 8)) - 1 When cfi->device_type is 4, this evaluates to 1 << 32. Since the literal '1' has type int, this is a 32-bit shift and is undefined behavior. Fix it by using a 64-bit literal (1ULL) so the shift is performed in a 64-bit type. Co-developed-by: Hui Peng <benquike@gmail.com> Signed-off-by: Hui Peng <benquike@gmail.com> Co-developed-by: Zhihao Yao (Zephyr) <zhihao.yao@njit.edu> Signed-off-by: Zhihao Yao (Zephyr) <zhihao.yao@njit.edu> Signed-off-by: Chenxi Hou <ch395@njit.edu> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2026-01-22i2c: designware: Remove an unnecessary conditionHeikki Krogerus
Writing also the high speed timing registers unconditionally. The reset value for these registers is 0, so this should always be safe. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260120130729.1679560-5-heikki.krogerus@linux.intel.com
2026-01-22i2c: designware: Enable mode swappingHeikki Krogerus
The DesignWare I2C can not be operated as I2C master and I2C slave simultaneously, but that does not actually mean master and slave modes can not be supported at the same time. It just means an explicit mode swap needs to be executed when the mode is changed. The DesignWare I2C documentation actually describes a couple of cases where the mode is excepted to be changed. The I2C master will now always be supported. Both modes are now always configured in i2c_dw_configure(), but the slave mode will continue to be available only when the Kconfig option I2C_SLAVE is enabled. The driver will now start in master mode and then swap to slave mode when a slave device is registered. After a slave device is registered, the controller is swapped to master mode when a transfer in master mode is started and then back to slave mode again after the transfer is completed. The DesignWare I2C can now be used with protocols such as MCTP (drivers/net/mctp/mctp-i2c.c) and IPMI (drivers/char/ipmi/) that require support for both I2C master and I2C slave. It is now also possible to support the SMBus Host Notification Protocol as I2C master if needed. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260120130729.1679560-4-heikki.krogerus@linux.intel.com
2026-01-22i2c: designware: Combine the init functionsHeikki Krogerus
Providing a single function for controller initialisation. The controller initialisation has the same steps for master and slave modes, except the timing parameters are only needed in master mode. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260120130729.1679560-3-heikki.krogerus@linux.intel.com
2026-01-22i2c: designware: Combine some of the common functionsHeikki Krogerus
The adapter can be registered just in the core instead of separately in the master and slave drivers. The same applies to the interrupt. The dedicated "target only" (slave only) configuration for this controller will be removed so that host mode (master mode) will always be supported together with the target mode. Therefore the descrption for the "target only" configuration that appears in the "name" sysfs attribute file is also dropped while at it. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260120130729.1679560-2-heikki.krogerus@linux.intel.com
2026-01-22kselftest/arm64: Add HWCAP test for FEAT_LS64Yicong Yang
Add tests for FEAT_LS64. Issue related instructions if feature presents, no SIGILL should be received. When such instructions operate on Device memory or non-cacheable memory, we may received a SIGBUS during the test (w/o FEAT_LS64WB). Just ignore it since we only tested whether the instruction itself can be issued as expected on platforms declaring the support of such features. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22arm64: Add support for FEAT_{LS64, LS64_V}Yicong Yang
Armv8.7 introduces single-copy atomic 64-byte loads and stores instructions and its variants named under FEAT_{LS64, LS64_V}. These features are identified by ID_AA64ISAR1_EL1.LS64 and the use of such instructions in userspace (EL0) can be trapped. As st64bv (FEAT_LS64_V) and st64bv0 (FEAT_LS64_ACCDATA) can not be tell apart, FEAT_LS64 and FEAT_LS64_ACCDATA which will be supported in later patch will be exported to userspace, FEAT_LS64_V will be enabled only in kernel. In order to support the use of corresponding instructions in userspace: - Make ID_AA64ISAR1_EL1.LS64 visbile to userspace - Add identifying and enabling in the cpufeature list - Expose these support of these features to userspace through HWCAP3 and cpuinfo ld64b/st64b (FEAT_LS64) and st64bv (FEAT_LS64_V) is intended for special memory (device memory) so requires support by the CPU, system and target memory location (device that support these instructions). The HWCAP3_LS64, implies the support of CPU and system (since no identification method from system, so SoC vendors should advertise support in the CPU if system also support them). Otherwise for ld64b/st64b the atomicity may not be guaranteed or a DABT will be generated, so users (probably userspace driver developer) should make sure the target memory (device) also have the support. For st64bv 0xffffffffffffffff will be returned as status result for unsupported memory so user should check it. Document the restrictions along with HWCAP3_LS64. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guestYicong Yang
Using FEAT_{LS64, LS64_V} instructions in a guest is also controlled by HCRX_EL2.{EnALS, EnASR}. Enable it if guest has related feature. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1Yicong Yang
Instructions introduced by FEAT_{LS64, LS64_V} is controlled by HCRX_EL2.{EnALS, EnASR}. Configure all of these to allow usage at EL0/1. This doesn't mean these instructions are always available in EL0/1 if provided. The hypervisor still have the control at runtime. Acked-by: Will Deacon <will@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memoryYicong Yang
If FEAT_LS64WB not supported, FEAT_LS64* instructions only support to access Device/Uncacheable memory, otherwise a data abort for unsupported Exclusive or atomic access (0x35, UAoEF) is generated per spec. It's implementation defined whether the target exception level is routed and is possible to implemented as route to EL2 on a VHE VM according to DDI0487L.b Section C3.2.6 Single-copy atomic 64-byte load/store. If it's implemented as generate the DABT to the final enabled stage (stage-2), inject the UAoEF back to the guest after checking the memslot is valid. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22KVM: arm64: Add documentation for KVM_EXIT_ARM_LDST64BMarc Zyngier
Add a bit of documentation for KVM_EXIT_ARM_LDST64B so that userspace knows what to expect. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22KVM: arm64: Add exit to userspace on {LD,ST}64B* outside of memslotsMarc Zyngier
The main use of {LD,ST}64B* is to talk to a device, which is hopefully directly assigned to the guest and requires no additional handling. However, this does not preclude a VMM from exposing a virtual device to the guest, and to allow 64 byte accesses as part of the programming interface. A direct consequence of this is that we need to be able to forward such access to userspace. Given that such a contraption is very unlikely to ever exist, we choose to offer a limited service: userspace gets (as part of a new exit reason) the ESR, the IPA, and that's it. It is fully expected to handle the full semantics of the instructions, deal with ACCDATA, the return values and increment PC. Much fun. A canonical implementation can also simply inject an abort and be done with it. Frankly, don't try to do anything else unless you have time to waste. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Oliver Upton <oupton@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22i2c: designware: Use device_is_compatible() instead of custom approachAndy Shevchenko
We use MODEL_MSCC_OCELOT effectively as a flag for comparing against "compatible" property. Use device_is_compatible() directly to make it clear. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260114081954.252160-3-andriy.shevchenko@linux.intel.com
2026-01-22i2c: spacemit: drop IRQF_ONESHOT flag from IRQ requestYixun Lan
In commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler")[1], it will check IRQF_ONESHOT flag in IRQ request, and gives a warning if there is no threaded handler. Drop this flag to fix this warning. Link: https://lore.kernel.org/r/20260112134013.eQWyReHR@linutronix.de/ [1] Fixes: 5ea558473fa3 ("i2c: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Yixun Lan <dlan@kernel.org> Cc: <stable@vger.kernel.org> # v6.15+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260122-05-k1-i2c-irq-v1-1-9b8d94bbcd22@kernel.org
2026-01-22apparmor: make str table more generic and be able to have multiple entriesJohn Johansen
The strtable is currently limited to a single entry string on unpack even though domain has the concept of multiple entries within it. Make this a reality as it will be used for tags and more advanced domain transitions. Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-22apparmor: Fix & Optimize table creation from possibly unaligned memoryHelge Deller
Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses. - Added Fixes tag - Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Signed-off-by: Helge Deller <deller@gmx.de> [jj: remove duplicate word "convert" in comment trigger checkpatch warning] Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-22AppArmor: Allow apparmor to handle unaligned dfa tablesHelge Deller
The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-22apparmor: Replace deprecated strcpy with memcpy in gen_symlink_nameThorsten Blum
strcpy() is deprecated; use memcpy() instead. Unlike strcpy(), memcpy() does not copy the NUL terminator from the source string, which would be overwritten anyway on every iteration when using strcpy(). snprintf() then ensures that 'char *s' is NUL-terminated. Replace the hard-coded path length to remove the magic number 6, and add a comment explaining the extra 11 bytes. Closes: https://github.com/KSPP/linux/issues/88 Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-22apparmor: fix NULL sock in aa_sock_file_permJohn Johansen
Deal with the potential that sock and sock-sk can be NULL during socket setup or teardown. This could lead to an oops. The fix for NULL pointer dereference in __unix_needs_revalidation shows this is at least possible for af_unix sockets. While the fix for af_unix sockets applies for newer mediation this is still the fall back path for older af_unix mediation and other sockets, so ensure it is covered. Fixes: 56974a6fcfef6 ("apparmor: add base infastructure for socket mediation") Reviewed-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
2026-01-22ALSA: hda/realtek: ALC269 fixup for Lenovo Yoga Book 9i 13IRU8 audioMartin Hamilton
The amp/speakers on the Lenovo Yoga Book 9i 13IRU8 laptop aren't fully powered up, resulting in horrible tinny sound by default. The kernel has an existing quirk for PCI SSID 0x17aa3843 which matches this machine and several others. The quirk applies the ALC287_FIXUP_IDEAPAD_BASS_SPK_AMP fixup, however the fixup does not work on this machine. This patch modifies the existing quirk by adding a check for the subsystem ID 0x17aa3881. If present, ALC287_FIXUP_TAS2781_I2C will be applied instead of ALC287_FIXUP_IDEAPAD_BASS_SPK_AMP. With this change the TAS2781 amp is powered up, firmware is downloaded and recognised by HDA/SOF - i.e. all is good, and we can boogie. Code is re-used from alc298_fixup_lenovo_c940_duet7(), which fixes a similar problem with two other Lenovo laptops. Cross checked against ALSA cardinfo database for potential clashes. Tested against 6.18.5 kernel built with Arch Linux default options. Tested in HDA mode and SOF mode. Note: Possible further work required to address quality of life issues caused by the firmware's agressive power saving, and to improve ALSA control mappings. Signed-off-by: Martin Hamilton <m@martinh.net> Link: https://patch.msgid.link/20260122-alc269-yogabook9i-fixup-v1-1-a6883429400f@martinh.net Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-01-22ALSA: hda/realtek: Add quirk for Samsung 730QED to fix headphoneZhang Heng
After applying this quirk for the ALC256 audio codec, the headphone audio path functions normally; otherwise, headphones produce no sound. Link: https://bugzilla.kernel.org/show_bug.cgi?id=220574 Cc: <stable@vger.kernel.org> Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260122085240.3163975-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-01-22net: atp: drop ancient parallel-port Ethernet driverEthan Nelson-Moore
This driver is old and almost certainly entirely unused. The two other parallel port Ethernet drivers (de600/de620) were removed by Paul Gortmaker in commit 168e06ae26dd ("drivers/net: delete old parallel port de600/de620 drivers"), but this driver remained. Drop it - Paul's reasoning applies here as well. To quote him: "The parallel port is largely replaced by USB [...] Let us not pretend that anyone cares about these drivers anymore, or worse - pretend that anyone is using them on a modern kernel." Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Acked-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260121084532.60606-1-enelsonmoore@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22mmc: sdhci-of-dwcmshc: Fix DMA 128MB boundary for Eswin EIC7700Huan He
This DWC MSHC has a 128MB limitation where the data buffer size and start address must not exceed the 128MB boundary. Registering the missing 'adma_write_desc' callback function. Signed-off-by: Huan He <hehuan1@eswincomputing.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: 32b2633219d3 ("mmc: sdhci-of-dwcmshc: Add support for Eswin EIC7700") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-01-22mmc: sdhci-of-dwcmshc: Fix init for AXI clock for Eswin EIC7700Huan He
Accessing the High-Speed registers requires the AXI clock to be enabled. Signed-off-by: Huan He <hehuan1@eswincomputing.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: 32b2633219d3 ("mmc: sdhci-of-dwcmshc: Add support for Eswin EIC7700") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-01-22net: fec: account for VLAN header in frame length calculationsClemens Gruber
The MAX_FL (maximum frame length) and related calculations used ETH_HLEN, which does not account for the 4-byte VLAN tag in tagged frames. This caused the hardware to reject valid VLAN frames as oversized, resulting in RX errors and dropped packets. Use VLAN_ETH_HLEN instead of ETH_HLEN in the MAX_FL register setup, cut-through mode threshold, buffer allocation, and max_mtu calculation. Cc: stable@kernel.org # v6.18+ Fixes: 62b5bb7be7bc ("net: fec: update MAX_FL based on the current MTU") Fixes: d466c16026e9 ("net: fec: enable the Jumbo frame support for i.MX8QM") Fixes: 59e9bf037d75 ("net: fec: add change_mtu to support dynamic buffer allocation") Fixes: ec2a1681ed4f ("net: fec: use a member variable for maximum buffer size") Signed-off-by: Clemens Gruber <mail@clemensgruber.at> Reviewed-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260121083751.66997-1-mail@clemensgruber.at Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22xen/netfront: Use u64_stats_t with u64_stats_sync properlyDavid Yang
On 64bit arches, struct u64_stats_sync is empty and provides no help against load/store tearing. Convert to u64_stats_t to ensure atomic operations. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260121082550.2389249-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22net: ifb: use u64_stats_t with u64_stats_sync properlyDavid Yang
On 64bit arches, struct u64_stats_sync is empty and provides no help against load/store tearing. Convert to u64_stats_t to ensure atomic operations. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20260121082348.2388314-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22net: openvswitch: fix data race in ovs_vport_get_upcall_statsDavid Yang
In ovs_vport_get_upcall_stats(), some statistics protected by u64_stats_sync, are read and accumulated in ignorance of possible u64_stats_fetch_retry() events. These statistics are already accumulated by u64_stats_inc(). Fix this by reading them into temporary variables first. Fixes: 1933ea365aa7 ("net: openvswitch: Add support to count upcall packets") Signed-off-by: David Yang <mmyangfl@gmail.com> Acked-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Aaron Conole <aconole@redhat.com> Link: https://patch.msgid.link/20260121072932.2360971-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22kselftest/arm64: Use syscall() macro over nolibc my_syscall()Thomas Weißschuh
The my_syscall*() macros are internal implementation details of nolibc. Nolibc also provides the regular syscall(2), which is also a macro and directly expands to the correct my_syscall(). Use syscall() instead. As a side-effect this fixes some return value checks, as my_syscall() returns the raw value as set by the kernel and does not set errno. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22arm64: mm: warn once for ioremap attempts on RAM mappingsBreno Leitao
Replace WARN_ON with WARN_ONCE when detecting attempts to ioremap RAM. This prevents log spam when a misbehaving driver repeatedly tries to map RAM via ioremap. A single warning is more than enough to show the broken code path, and extra reports don't add extra information. Warning floods have been seen in production environments where broken external drivers hit this code path thousand of times, causing unnecessary messages to be printed and pressure on the serial console. Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22arm64: topology: Do not warn on missing AMU in cpuhp_topology_online()Geert Uytterhoeven
When CONFIG_CPUMASK_OFFSTACK is not enabled, and resuming from s2ram on Renesas R-Car H3 (big.LITTLE 4x Cortex-A57 + 4x Cortex-A53), during enabling of the first little core, a warning message is printed: AMU: CPU[4] doesn't support AMU counters This confuses users, as during boot amu_fie_setup() does not print such a message, unless debugging is enabled (freq_counters_valid() prints "CPU%d: counters are not supported.\n" at debug level in that case). Hence drop the warning, freq_counters_valid() has already printed a debug message anyway. Fixes: 6fd9be0b7b2e ("arm64: topology: Handle AMU FIE setup on CPU hotplug") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-22cipso: harden use of skb_cow() in cipso_v4_skbuff_setattr()Will Rosenberg
If skb_cow() is passed a headroom <= -NET_SKB_PAD, it will trigger a BUG. As a result, use cases should avoid calling with a headroom that is negative to prevent triggering this issue. This is the same code pattern fixed in Commit 58fc7342b529 ("ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()"). In cipso_v4_skbuff_setattr(), len_delta can become negative, leading to a negative headroom passed to skb_cow(). However, the BUG is not triggerable because the condition headroom <= -NET_SKB_PAD cannot be satisfied due to limits on the IPv4 options header size. Avoid potential problems in the future by only using skb_cow() to grow the skb headroom. Signed-off-by: Will Rosenberg <whrosenb@asu.edu> Acked-by: Paul Moore <paul@paul-moore.com> Link: https://patch.msgid.link/20260120155738.982771-1-whrosenb@asu.edu Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22drm/xe: Select CONFIG_DEVICE_PRIVATE when DRM_XE_GPUSVM is selectedThomas Hellström
CONFIG_DEVICE_PRIVATE is a prerequisite for DRM_XE_GPUSVM. Explicitly select it so that DRM_XE_GPUSVM is not unintentionally left out from distro configs not explicitly enabling CONFIG_DEVICE_PRIVATE. v2: - Select also CONFIG_ZONE_DEVICE since it's needed by CONFIG_DEVICE_PRIVATE. v3: - Depend on CONFIG_ZONE_DEVICE rather than selecting it. Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260121091048.41371-3-thomas.hellstrom@linux.intel.com (cherry picked from commit 9386f49316074d2d76fd78d6bd359996de42fb7f) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-22t Merge branch 'a-series-of-minor-optimizations-of-the-bonding-module'Paolo Abeni
Tonghao Zhang says: ==================== A series of minor optimizations of the bonding module These patches mainly target the peer notify mechanism of the bonding module. Including updates of peer notify, lock races, etc. For more information, please refer to the patch. Cc: Jay Vosburgh <jv@jvosburgh.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: Nikolay Aleksandrov <razor@blackwall.org> Cc: Hangbin Liu <liuhangbin@gmail.com> Cc: Jason Xing <kerneljasonxing@gmail.com> ==================== Link: https://patch.msgid.link/cover.1768709239.git.tonghao@bamaicloud.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22net: bonding: add the READ_ONCE/WRITE_ONCE for outside lock accessingTonghao Zhang
Although operations on the variable send_peer_notif are already within a lock-protected critical section, there are cases where it is accessed outside the lock. Therefore, READ_ONCE() and WRITE_ONCE() should be added to it. Cc: Jay Vosburgh <jv@jvosburgh.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: Nikolay Aleksandrov <razor@blackwall.org> Cc: Hangbin Liu <liuhangbin@gmail.com> Cc: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Tonghao Zhang <tonghao@bamaicloud.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/c1dcc53442f4d0f67beb9e0a3e7a7a6a2c94c47f.1768709239.git.tonghao@bamaicloud.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-01-22net: bonding: skip the 2nd trylock when first one failTonghao Zhang
After the first trylock fail, retrying immediately is not advised as there is a high probability of failing to acquire the lock again. This optimization makes sense. Cc: Jay Vosburgh <jv@jvosburgh.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: Nikolay Aleksandrov <razor@blackwall.org> Cc: Hangbin Liu <liuhangbin@gmail.com> Cc: Jason Xing <kerneljasonxing@gmail.com> Signed-off-by: Tonghao Zhang <tonghao@bamaicloud.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/9aba44f02163e8fe8dbaba63ff2df921bc2b114e.1768709239.git.tonghao@bamaicloud.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>