summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-21net: ethernet: adi: Add a driver for the ADIN1140 MACPHYCiprian Regus
Add a driver for ADIN1140. The device is a 10BASE-T1S MAC-PHY (integrated in the same package) that connects to a CPU over an SPI bus, and implements the Open Alliance TC6 protocol for control and frame transfers. As such, this driver relies on oa_tc6 for the communication with the device. The device has an alternative name (AD3306), so the driver can be probed using one of the two compatible strings. For control transactions, ADIN1140 only implements the protected mode. The driver has a custom implementation for the mii_bus access methods as a workaround for hardware issues: 1. The OA TC6 standard defines the direct and indirect access modes for MDIO transactions. The ADIN1140 incorrectly advertises indirect mode only (supported capabilities register - 0x2, bit 9), while actually implementing just the direct mode. We cannot rely on the CAP register to choose an access method (which oa_tc6 does by default, even though it only implements the direct mode), so the driver has to use its own. 2. The ADIN1140 cannot access the C22 register space of the internal PHY, while the PHY is busy receiving frames. If that happens, the CONFIG0 and CONFIG2 registers of the MAC will get corrupted and the data transfer will stop. Those two registers configure settings for the transfer protocol between the MAC and host, so the value for some of their subfields shouldn't be changed while the netdev is up. Since we know the PHY is internal, the MAC driver can implement a custom mii_bus, which can intercept C22 accesses. Most of the registers mapped in the 0x0 - 0x3 range (the only ones the PHY offers) are read only, and their value can be read from somewhere else (e.g the PHYID 1 & 2 have the same value as 0x1 in the MAC memory map). For the fields that are R/W (loopback and AN/reset) in the control register, the PHY driver already implements the set_loopback() and config_aneg() functions. The C22 write function of the driver is a no-op and is used to protect against the ioctl MDIO access path. C45 accesses do not cause this issue, so we can properly implement them. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-13-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: phy: Add support for the ADIN1140 PHYCiprian Regus
Add a driver for the ADIN1140's internal 10BASE-T1S PHY. The device doesn't implement autonegotiation, so the link is always reported as being up. The device implements both C22 and C45 MDIO access methods, but can only be discovered over C22, since the C45 MMD devices lack the MDIO_DEVID1 and MDIO_DEVID2 registers. The indirect C45 over C22 feature is not supported. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-12-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: phy: microchip-t1s: use generic C45 MMD access helpersCiprian Regus
Replace the driver specific lan865x_phy_read_mmd() and lan865x_phy_write_mmd() with the shared genphy_read_mmd_c45() and genphy_write_mmd_c45() helpers. No functional change. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-11-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: phy: add generic helpers for direct C45 MMD accessCiprian Regus
Some PHYs support direct C45 register access but not C22 indirect MMD access (registers 0xD and 0xE). When discovered via C22, phylib routes MMD access through the indirect path, which won't work on these devices. Add genphy_read_mmd_c45() and genphy_write_mmd_c45() as read_mmd/ write_mmd callbacks that bypass the C22 indirect path and use the bus C45 accessors directly. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-10-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: ethernet: oa_tc6: Add new register address definesCiprian Regus
Add macro defines for the CONFIG2 register and the MMS1 memory map. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-9-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: ethernet: oa_tc6: Use the read_mms/write_mms functions for C45Ciprian Regus
Accessing PHY MMD devices requires control transactions to registers in a memory map other than 0. Replace the current formatting of the register addresses with the oa_tc6_{read,write}_register_mms() functions. While we're here, introduce the mms variable to store the memory map returned by oa_tc6_get_phy_c45_mms() instead of ret, in order to improve the code readability. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-8-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: ethernet: oa_tc6: Add read_mms/write_mms register access functionsCiprian Regus
The Open Alliance TC6 standard defines multiple memory maps for the MAC-PHY's register space. These are used to separate standard, vendor and PHY MMD specific registers. Define register access functions that allow the caller to specify the MMS. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-7-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: ethernet: oa_tc6: Add the OA_TC6_ prefix to standard registersCiprian Regus
The OA TC6 standard registers are currently exported in a header file. Add the OA_TC6_ prefix to the register address and subfield mask macros to avoid future naming conflicts. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-6-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: ethernet: oa_tc6: Export standard defined registersCiprian Regus
Move defines for standard Open Alliance TC6 register addresses and subfields in the oa_tc6's header. As such, other ethernet drivers that rely on oa_tc6 can use them directly. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-5-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: ethernet: oa_tc6: Export the C45 access functionsCiprian Regus
The C45 access functions can still be used by some Ethernet drivers which set the OA_TC6_BROKEN_PHY flag. Export them. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-4-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: ethernet: oa_tc6: add OA_TC6_BROKEN_PHY quirk flagCiprian Regus
Some MAC-PHY devices need custom MDIO bus access functions to work around hardware issues. Add the OA_TC6_BROKEN_PHY quirk flag so drivers can opt in to skip oa_tc6's internal PHY init and manage the PHY themselves. When the flag is set, oa_tc6 skips MDIO bus registration, PHY discovery and PHY connection, leaving these to the driver. Drivers that do not set the flag retain the existing behavior. Update lan865x and the framework documentation accordingly. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-3-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: ethernet: oa_tc6: Handle the OA TC6 SPI protected modeCiprian Regus
Implement the OA TC6 standard defined protected mode for control (register access) transactions. In addition to the current register access formats the oa_tc6 driver handles, 1's complement values of the data field are included (by both the host and the MACPHY) in the SPI transfer frames. This feature acts as an integrity check. Control write transactions look like this: |<- 32 bits ->|<--- data_size --->|<- 32 bits ->| MOSI: | ctrl header | reg write data | ignored | MISO: | (discard) | echoed ctrl hdr | echoed data | data_size (LEN = number of registers to read in a sequence): Unprotected: 32 x (LEN + 1) bits Protected: 2 x 32 x (LEN + 1) bits Control read transaction: |<- 32 bits ->|<--- 32 bits --> |<- data_size ->| MOSI: | ctrl header | ignored ... | MISO: | (discard) | echoed ctrl hdr | reg read data | data_size (LEN = number of registers to read in a sequence): Unprotected: 32 x (LEN + 1) bits Protected: 2 x 32 x (LEN + 1) bits Register data format ("reg write data" and "reg read data"): Unprotected: | W1 (normal) | W2 (normal) | ... | Wx (normal) | Protected: | W1 (normal) | W1 (complement) | ... | Wx (normal) | Wx (complement)| The protected mode state can be read from the bit 5 of CONFIG0 (0x4) register, and this setting is usually only configured during the MACPHY's reset (depending on the device it can be done by setting the state of a pin). We can read the protected mode configuration before any other register access and since the SPI transfer is initially sized for an unprotected read, the MACPHY's complement words are never clocked out and no checking is required. The data transactions (Ethernet frames) remain unchanged. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-2-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21dt-bindings: net: Add ADIN1140Ciprian Regus
The ADIN1140 is a single port 10BASE-T1S Ethernet controller that includes both the MAC and a PHY in the same package. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-1-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21platform/x86: uniwill-laptop: Remove single color keyboard detectionArmin Wolf
Having a ad-hoc device whitelist inside uniwill_kbd_led_init() to work around unreliable KBD_WHITE_ONLY values conflicts with the idea of the device descriptor infrastructure. Remove the ad-hoc device whitelist and use the device descriptor infrastructure instead. Suggested-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260720132611.374073-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-21platform/x86: uniwill-laptop: Split uniwill_kbd_led_init()Armin Wolf
The function uniwill_kbd_led_init() is quite large and doing multiple things at once: - general hardware initialisation - single color keyboard backlight registration - RGB keyboard backlight registration Move the last two things into separate functions to increase the maintainability of uniwill_kbd_led_init(). Suggested-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260720132611.374073-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-21openvswitch: fix GSO userspace truncation underflowKyle Zeng
OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it. Fixes: f2a4d086ed4c ("openvswitch: Add packet truncation support.") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Kyle Zeng <kylebot@openai.com> Reviewed-by: Ilya Maximets <i.maximets@ovn.org> Reviewed-by: Aaron Conole <aconole@redhat.com> Link: https://patch.msgid.link/20260707221635.27489-1-kylebot@openai.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21drm/i915/bw: Update bw calculation to account for 16 channelsUma Shankar
Wa_16030862157: Update Bandwidth Calculation to account for 16channel memory config. v2: Logical separation of changes (Suraj, Vinod) WA: 16030862157, 16030875223 Bspec: 69131, 68859 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patch.msgid.link/20260715143243.4141208-3-uma.shankar@intel.com
2026-07-21drm/i915/dram: Interpret 0xF populated-channel count as 16Uma Shankar
Wa_16030862157: Interpret 0xF populated-channel count as 16 The register MEM_SS_INFO_GLOBAL [Number of populated channels] field definition is updated with an encoding for 16 channels. For 16-channel configuration, program 1111b. A programmed value of 1111b must be interpreted as 16 channels for memory bandwidth calculations. The MEM_SS_INFO_GLOBAL populated-channel field is only 4 bits and cannot encode 16, so on Xe3p the BIOS programs the saturated field value (0xf) to indicate the fully-populated 16-channel config (4 memory controllers x 4 channels). Interpret it as 16 and let the bandwidth math handle the larger channel count. v2: Limit the WA only till NVL (Suraj) Logical separation of WA (Vinod) WA: 16030862157, 16030875223 Bspec: 69131, 79482 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patch.msgid.link/20260715143243.4141208-2-uma.shankar@intel.com
2026-07-21irqchip/gic-v3-its: Fix grammar and replace a bit number with its symbolKemeng Shi
Fix grammatical errors in comments and simplify the comment about reading GITS_BASER_INDIRECT to check two-level support. Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Radu Rendec <radu@rendec.net> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260721063241.52549-3-shikemeng@huaweicloud.com
2026-07-21irqchip/gic-v3-its: Prevent leak in its_vpe_irq_domain_alloc()Kemeng Shi
When its_irq_gic_domain_alloc() fails, the following its_vpe_irq_domain_free() fails to invoke its_vep_teardown() for the corresponding interrupt, which leaks the resource. Invoke its_vpe_teardown() in the error handling path to avoid the leak. [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1ad ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260721063241.52549-2-shikemeng@huaweicloud.com
2026-07-21net: sparx5: configure TAS port link speedRobert Marko
On the TSN and RED variants of LAN969x and SparX-5i TAS (Time-Aware Shaper) is present in the silicon. Currently, the driver does not use configure it at all, which means that the TAS_PROFILE_CONFIG.LINK_SPEED[1] value is left at the default of 3 which means that its configured for 1 Gbps. So, running iperf between two 10G switch ports will result in only 940-ish Mbps while we should be getting around 9.3 Gbps. Correctly populating the TAS_PROFILE_CONFIG.LINK_SPEED[1] with the current port speed fixes this issue and we achieve around 9.4 Gbps between two 10G switch ports. So, port the TAS port link speed setting from the vendor BSP 6.18 kernel[2] [1] https://microchip-ung.github.io/lan969x-industrial_reginfo/reginfo_LAN969x-Industrial.html?select=hsch,tas_profile_cfg,tas_profile_config,link_speed [2] https://github.com/microchip-ung/linux/tree/bsp-6.18-2026 Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://patch.msgid.link/20260707170531.1129866-1-robert.marko@sartura.hr Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21ALSA: hda/realtek - Add quirk for Dell Pro QC1255Kailang Yang
Vendor want to add more machine on this workaround. Fixes: 97272a5704bf ("ALSA: hda/realtek - Fixed Headphone noise issue for Dell QCM1255") Signed-off-by: Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/e13d08e96ac449b6994d56dfe6ce3f5c@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-07-21arm64: versal-net: Switch Versal NET to firmware clock interfaceMichal Simek
Switch Versal NET from using fixed clocks to the firmware-based clock interface (versal-net-clk.dtsi). This enables proper clock management through the platform firmware instead of relying on static fixed-clock definitions. Add DT macro headers for Versal NET and base Versal clocks, power domains and mandatory resets required by the clock dtsi. Link: https://patch.msgid.link/77e6234f6cef3f78fb1c6c97142fa8055982e14e.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-07-21dt-bindings: clock: versal-clk: Fix Versal NET clock validationMichal Simek
The Versal NET clock controller compatible is specified as: compatible = "xlnx,versal-net-clk", "xlnx,versal-clk"; with xlnx,versal-clk listed as fallback. The original binding had two separate if/then blocks - one matching xlnx,versal-clk (2 clocks) and another matching xlnx,versal-net-clk (3 clocks). Since both compatible strings are present, both conditions matched simultaneously and JSON Schema applied the more restrictive 2-clock constraint, causing false "too long" validation errors for Versal NET. Define clock-names at the top-level and use if/then only to constrain the clock count (2 for Versal, 3 for Versal NET). Add a dedicated example for the Versal NET 3-clock configuration. Fixes: 39118392d19a ("dt-bindings: Remove alt_ref from versal") Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/202e448e57cf979e1b5be61da0bad7778defdd4e.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-07-21dt-bindings: clock: Move xlnx,zynqmp-clk to its own schemaMichal Simek
The ZynqMP clock controller binding shares only #clock-cells with the Versal bindings. Move it to a dedicated xlnx,zynqmp-clk.yaml schema. Also remove "(Optional clock)" from clock description because it is visible from schema itself. Also update versal-firmware example to match changes in xlnx,zynqmp-firmware.yaml. Suggested-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/973a8a5441cf13622594b95dd0dd20a5f42ccece.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-07-21dt-bindings: clock: versal-clk: Fix mio_clk index range in clock-names patternMichal Simek
The clock-names pattern "^mio_clk[00-77]+.*$" was intended to constrain the MIO index to the valid range 00..77 (ZynqMP has 78 MIO pins), but a regex character class cannot express a multi-digit decimal range. Replace the bogus character class with an explicit alternation that enumerates the two-digit decimal values 00..77. Fixes: 03d4a1004053 ("dt-bindings: clock: versal: Convert the xlnx,zynqmp-clk.txt to yaml") Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/e742b7da70c2bf10650a81e537f1b90d76799416.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-07-21dt-bindings: firmware: xilinx: Add missing example for ZynqMPMichal Simek
Document clock-controller under zynqmp-firmware in the binding example so ZynqMP DTs validate against xlnx,versal-clk.yaml (Versal example already did). Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/12dba601a8b631e565dd98e52a89b0ec18fcdce2.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-07-21net: airoha: fix MIB stats collection to be losslessAniket Negi
REG_FE_GDM_MIB_CLEAR after every read creates a race window where packets arriving between read and clear are lost from statistics. Switch to a delta-based approach instead: - 64-bit H+L registers (ok pkts/bytes, E64..L1023): read absolute hardware total directly into a local variable; clamp with max(new, old) to prevent torn-read regression when the counter carries between the two reads. - 32-bit registers (drops, bc, mc, errors, runt, long): accumulate (u32)(curr - prev) into a 64-bit software counter; unsigned subtraction handles wrap-around transparently. - tx/rx_len[0] ([0,64] bucket): combines RUNT_CNT (32-bit, delta via tx_runt/rx_runt) and E64_CNT (64-bit, absolute) into a single local accumulator; max(new, old) applied here too to guard against a torn read of E64 when the RUNT accumulator is unchanged between polls. MIB counters are zeroed by the SCU FE reset (EN7581_FE_RST) asserted in airoha_hw_init() at module load, so no explicit MIB clear is needed in airoha_fe_init(). Merge airoha_dev_get_hw_stats() into airoha_update_hw_stats() and move stats_lock inside. Plain spin_lock() is correct: the function is only called from ndo_get_stats64() in process context. Each dev refreshes only its own MIB counters; sibling devs on a shared GDM3/4 port are polled when their own netdev is queried. Fixes: 8f4695fb67b2 ("net: airoha: better handle MIBs for GDM ports with multiple devs attached") Signed-off-by: Aniket Negi <aniket.negi03@gmail.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260707152639.105628-1-aniket.negi03@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21mm/slub: prevent pfmemalloc objects from entering the barnShengming Hu
kmem_cache_return_sheaf() may refill a partially consumed sheaf before placing it in the barn. Without an explicit restriction, this refill may draw objects from pfmemalloc slabs and consume emergency reserves. Add __GFP_NOMEMALLOC so that returned sheaves are refilled only from non-pfmemalloc slabs. Also add __GFP_NOWARN, as suggested by Hao Li, because this refill is a best-effort attempt and failure is acceptable. If the refill fails, flush and free the sheaf instead. Fixes: 1ce20c28eafd ("slab: handle pfmemalloc slabs properly with sheaves") Cc: stable@vger.kernel.org Signed-off-by: Shengming Hu <hu.shengming@zte.com.cn> Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org> Reviewed-by: Hao Li <hao.li@linux.dev> Link: https://patch.msgid.link/20260721084522552ZPa16p1SRj3PYat3sqxuN@zte.com.cn Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-07-21Merge branch 'geneve-make-geneve_fill_info-rtnl-less'Paolo Abeni
Eric Dumazet says: ==================== geneve: make geneve_fill_info() RTNL-less This series makes geneve_fill_info() independent of the RTNL lock by converting the device configuration to an RCU-protected pointer. Historically, geneve_changelink() updated the device configuration by copying the new configuration over the old one using memcpy() under RTNL. To prevent the transmit/receive data paths from reading torn values during the copy, geneve_quiesce() was used to pause the data path and wait for a synchronize_net(), causing packet loss and latency. By converting the configuration to an RCU-protected pointer, we can perform atomic updates via RCU swap. This allows data path readers to safely access the configuration locklessly under RCU read lock, and removes the need to stop the data path during changelink. With the RCU infrastructure in place, geneve_fill_info() is then updated to read the configuration under RCU read lock, removing its dependency on RTNL. v1: https://lore.kernel.org/netdev/20260701120454.3533252-1-edumazet@google.com/T/#m887804321856d9b5c7142107e81b52553e60e6ab ==================== Link: https://patch.msgid.link/20260707145331.3717941-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21geneve: make geneve_fill_info() RTNL independentEric Dumazet
Now that geneve->cfg is an RCU-protected pointer, update geneve_fill_info() to read the configuration under RCU read lock instead of relying on RTNL. Also add const qualifiers to the dereferenced pointers where appropriate and fix local variable declaration ordering. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260707145331.3717941-4-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21geneve: convert config to RCU-protected pointerEric Dumazet
geneve_changelink() currently updates configuration by copying it over the old one using memcpy() under RTNL, forcing data path pause via geneve_quiesce() and synchronize_net() to avoid reading torn values. Convert geneve->cfg to an RCU-protected pointer, allowing lockless and safe reads under RCU read lock without synchronization overhead. Key changes: - Introduced geneve_config_alloc/free() helpers for lifecycle. - geneve_configure() allocates config and publishes it via RCU. - Setting dev->priv_destructor = geneve_free_dev handles config cleanup if register_netdevice() fails or during netdev unregistration. - geneve_changelink() performs RCU swap; old config is freed via call_rcu_hurry(). - Allocates new dst_cache during changelink to prevent pcpu sharing. - Removed geneve_quiesce/unquiesce() and synchronize_net() from changelink. - Added rcu_barrier() to module exit to wait for pending callbacks. - Updated data path to use rcu_dereference(). - Updated geneve_fill_info() to use rtnl_dereference() for now. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260707145331.3717941-3-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21geneve: pass geneve_config pointer to helper functionsEric Dumazet
In preparation for converting geneve->cfg to an RCU-protected pointer, update helper functions to explicitly accept a const struct geneve_config pointer instead of dereferencing geneve->cfg directly. Signed-off-by: Eric Dumazet <edumazet@google.com> Suggested-by: Paolo Abeni <pabeni@redhat.com> Link: https://patch.msgid.link/20260707145331.3717941-2-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21drm/gpusvm: Zero HMM PFNs before scanning rangesStanislav Kinsburskii
drm_gpusvm_scan_mm() asks HMM to report the current CPU page-table state without faulting missing entries by leaving default_flags set to zero. The HMM PFN array is still caller-owned input/output state, and the framework may preserve input bits while filling entries. It is not safe for the caller to hand HMM an uninitialized array and then treat entries without HMM_PFN_VALID as an authoritative unpopulated result. Use kvcalloc() for the temporary PFN array so entries that are not reported as valid start from the documented zero state. This prevents random stack or heap contents from being interpreted as HMM PFN flags or PFN values during the scan. Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state") Cc: stable@vger.kernel.org Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/178406967042.1113483.2116704310277917086.stgit@skinsburskii
2026-07-21drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evictMatthew Brost
If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260714170025.3487974-1-matthew.brost@intel.com
2026-07-21net/iucv: fix use-after-free of a severed iucv_pathBryam Vargas
af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued. Fixes: f0703c80e515 ("[AF_IUCV]: postpone receival of iucv-packets") Closes: https://sashiko.dev/#/patchset/20260705-b4-disp-fc79c0dc-v1-1-d2cdcb57afa9@proton.me?part=1 Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260707-b4-disp-783fedbb-v1-1-463b9dbda2ea@proton.me Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21Merge branch ↵Paolo Abeni
'net-stmmac-eic7700-add-eth1-variant-support-and-update-delay-bindings' Zhi Li says: ==================== net: stmmac: eic7700: add eth1 variant support and update delay bindings This series updates Ethernet support for the ESWIN EIC7700 SoC, including support for the eth1 MAC variant. The series includes DT binding updates and stmmac glue driver updates for the EIC7700 Ethernet controller. The changes include: - Update the tx-internal-delay-ps binding property from a fixed enum list to a range-based definition, and make it optional with the corresponding driver update. - Add support for the EIC7700 eth1 MAC variant, which has silicon-specific RX sampling behavior and TX timing characteristics. A dedicated compatible string is introduced for this hardware variant, and the driver applies the required RX clock inversion handling and timing adjustments. Due to silicon characteristics, the eth1 interface has a fixed TX internal delay of approximately 2 ns and an RX sampling skew of 4-5 ns that cannot be compensated solely by standard RGMII delay settings. The binding models the effective TX delay range of this variant, while the driver handles the required hardware-specific timing configuration. Only the DT bindings and driver patches are included in this series. The DTS changes are intentionally omitted for the following reasons: - The HSP bus infrastructure is being introduced by Pinkesh Vaghela's DT series [0], currently under review. - The HSPCRG clock/reset series [1] provides additional infrastructure for the HSP subsystem. Once these dependencies are merged, a follow-up DT series will enable Ethernet, USB, eMMC, and SD across the HSP bus. Reference: [0] https://lore.kernel.org/lkml/20260706081055.1126275-1-pinkesh.vaghela@einfochips.com/ [1] https://lore.kernel.org/all/20260605060730.1605-1-dongxuyang@eswincomputing.com/ ==================== Link: https://patch.msgid.link/20260707064033.1265-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: stmmac: eic7700: add support for eth1 clock inversion variantZhi Li
The eth1 MAC exhibits silicon-inherent RX and TX timing behavior that differs from the eth0 implementation. At 1000Mbps, RX sampling requires clock inversion due to a fixed MAC input skew that cannot be compensated by standard RGMII delay settings. The TX path includes a fixed ~2ns internal delay introduced by the MAC silicon. This delay is always present and is already accounted for in the device tree tx-internal-delay-ps property as part of the effective output timing. The tx-internal-delay-ps property describes the effective delay seen at the MAC output. Since the hardware register controls only the programmable portion of the delay, the driver subtracts the fixed silicon-inherent component before programming the delay register. Use compatible-specific match data to identify the eth1 variant and apply RX clock inversion only at 1000Mbps. The PHY interface mode is adjusted via phy_fix_phy_mode_for_mac_delays() to avoid double-application of RGMII delays when MAC-side delays are already present. Link speed dependency means RX sampling configuration is applied in the fix_mac_speed callback after negotiation. No behavior changes for the existing eth0 controller. Signed-off-by: Zhi Li <lizhi2@eswincomputing.com> Link: https://patch.msgid.link/20260707064234.1333-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: stmmac: eic7700: make RGMII delay properties optionalZhi Li
Make rx-internal-delay-ps and tx-internal-delay-ps optional in the EIC7700 DWMAC driver. The driver previously required both properties to be present and would fail probe when they were missing. This restricts valid hardware configurations where RGMII timing is instead provided by the PHY or board design. Update the driver to treat missing delay properties as zero delay, allowing systems without explicit MAC-side delay tuning to operate correctly. This aligns the driver behavior with the updated device tree binding and provides a safe default configuration when MAC-side delay programming is not required. Signed-off-by: Zhi Li <lizhi2@eswincomputing.com> Link: https://patch.msgid.link/20260707064218.1316-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21dt-bindings: ethernet: eswin: add EIC7700 eth1 RX clock inversion variantZhi Li
The EIC7700 SoC integrates two GMAC instances. The eth1 MAC exhibits different RX clock sampling characteristics due to silicon-inherent timing behavior. The eth1 MAC has a fixed, non-configurable RX clock-to-data skew at the MAC input in the order of 4-5 ns. This cannot be compensated solely by the standard MAC internal delay configuration and PHY delay, and RX clock inversion is required at 1000Mbps for correct sampling. The eth1 TX path also includes a fixed silicon-inherent delay of approximately 2 ns. This delay is always present and cannot be disabled. It is therefore part of the effective transmit timing observed on the wire. For the eth1 variant, the valid tx-internal-delay-ps values include this fixed delay component. Consequently, the effective range becomes 2000-4540 ps (approximately 2000 ps fixed delay plus 0-2540 ps programmable delay). Introduce a dedicated compatible string "eswin,eic7700-qos-eth-clk-inversion" to represent the eth1 variant, allowing the driver to apply RX clock inversion only when required by hardware variant selection. This keeps SoC-level differentiation without exposing silicon-fixed skew as configurable device tree parameters. To reflect this, model the TX internal delay as a base 0-4540 ps range, and constrain valid values per compatible using conditional schema rules. Update the binding schema as follows: - Define tx-internal-delay-ps as a base range: 0-4540 ps - Add compatible-specific constraints using if/then rules: * eswin,eic7700-qos-eth: max 2540 ps * eswin,eic7700-qos-eth-clk-inversion: minimum 2000 ps (effective range 2000-4540 ps) No functional change for existing "eswin,eic7700-qos-eth" users. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Zhi Li <lizhi2@eswincomputing.com> Link: https://patch.msgid.link/20260707064159.1299-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21dt-bindings: ethernet: eswin: relax internal delay model to range-based ↵Zhi Li
constraints Relax internal delay constraints for EIC7700 Ethernet binding. Replace fixed enumeration of rx-internal-delay-ps and tx-internal-delay-ps with a range-based definition (0-2540 ps, 20 ps steps) to reflect actual hardware capability. Mark rx/tx internal delay properties as optional, as they are board- specific tuning parameters rather than mandatory configuration. Update the device tree example to align with the relaxed constraint model and remove delay properties from the example to avoid implying they are required. No functional change to existing DT users. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Zhi Li <lizhi2@eswincomputing.com> Link: https://patch.msgid.link/20260707064131.1282-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-20riscv: defconfig: thead: enable PCA953X GPIO driverMarek Szyprowski
Enable PCA953X GPIO driver to properly probe Wifi pwrseq driver on LicheePi4a board. Reviewed-by: Drew Fustini <fustini@kernel.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Drew Fustini <fustini@kernel.org>
2026-07-21btrfs: raid56: fix scrub read assembly submitting no readsMykola Lysenko
Commit 5387bd958180 ("btrfs: raid56: remove sector_ptr structure") converted the bio-list membership checks from sector pointers to physical addresses. The two conversions in rmw_assemble_write_bios() kept their polarity (skip the sector when it is NOT in the bio list, i.e. when there is nothing to write), but scrub_assemble_read_bios() has the opposite polarity -- skip the sector when it IS in the bio list, because then there is nothing to read -- and the conversion flipped it: - sector = sector_in_rbio(rbio, stripe, sectornr, 1); - if (sector) + paddr = sector_paddr_in_rbio(rbio, stripe, sectornr, 1); + if (paddr == INVALID_PADDR) continue; Since a parity-scrub rbio's bio list only holds the empty completion bio, the result is that scrub_assemble_read_bios() submits no reads at all. finish_parity_scrub() then compares the parity it computes from the (cached, correct) data stripes against whatever happens to be in the freshly allocated, uninitialized stripe pages: - if the garbage differs from the computed parity, the sector is "repaired" and written back -- accidentally producing the correct on-disk result; - if a recycled page happens to still hold the old (correct) parity content, the sector is deemed clean, dropped from dbitmap, and the actually-corrupt on-disk parity is left in place. (Scrub reports no errors either way: there is no counter for P/Q corruption by design, so the bug here is purely the failure to read and repair.) The second case is intermittent because it depends on page-allocator recycling. Observed with fstests btrfs/297 (raid5, 2 devices): the corrupted P stripe intermittently stays corrupt after a scrub -- roughly 1/10 runs on x86-64 KVM and up to 7/8 on a UML build whose timing favors page reuse. Since the bio-list check can never be true for a parity-scrub rbio -- raid56_parity_alloc_scrub_rbio() adds a single empty completion bio (asserting bi_size == 0), bio_paddrs[] is only populated by index_rbio_pages() which is never called for BTRFS_RBIO_PARITY_SCRUB, and rbio_can_merge() refuses to merge rbios of different operations -- remove the dead check entirely and assert the invariant instead, as suggested by Qu Wenruo. After this fix the injected corruption is read, detected and repaired in every run (8/8 UML, 10/10 KVM), and the new assertion never fires across the full fstests raid group. Fixes: 5387bd958180 ("btrfs: raid56: remove sector_ptr structure") CC: stable@vger.kernel.org # 7.1+ Suggested-by: Qu Wenruo <quwenruo.btrfs@gmx.com> Assisted-by: Claude:claude-fable-5 Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Mykola Lysenko <nickolay.lysenko@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-07-21btrfs: zoned: skip fully truncated ordered extents at zone finishJohannes Thumshirn
A fully truncated ordered extent (truncated_len == 0) wrote no data, so its ->csum_list is empty and btrfs_finish_ordered_zoned() trips: assertion failed: !list_empty(&ordered->csum_list), in fs/btrfs/zoned.c:2141 Since commit 66ff4d366e7e a short or cancelled direct IO write finishes the unsubmitted ordered extent as truncated with uptodate = true instead of setting BTRFS_ORDERED_IOERR, so it now reaches btrfs_finish_ordered_zoned() rather than being skipped by the IOERR check in btrfs_finish_ordered_io(). generic/208 hits this on a zoned filesystem. Return early for these, like the BTRFS_ORDERED_PREALLOC case; there is no zone append result to record and btrfs_finish_one_ordered() skips them too. Fixes: 66ff4d366e7e ("btrfs: fix false IO failure after falling back to buffered write") Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-07-21btrfs: initialize 'args' to avoid compiler warning in btrfs_ioctl_get_csums()Paul E. McKenney
[COMPILER WARNING] With GCC 11.5.0 and KASAN enabled on ARM, the following warning is triggered during compiling: In file included from ./include/asm-generic/rwonce.h:26, from ./arch/arm64/include/asm/rwonce.h:81, from ./include/linux/compiler.h:369, from ./include/linux/array_size.h:5, from ./include/linux/kernel.h:16, from fs/btrfs/ioctl.c:6: In function ‘instrument_copy_from_user_before’, inlined from ‘_inline_copy_from_user’ at ./include/linux/uaccess.h:184:2, inlined from ‘copy_from_user’ at ./include/linux/uaccess.h:222:9, inlined from ‘btrfs_ioctl_get_csums.isra’ at fs/btrfs/ioctl.c:5220:6: ./include/linux/kasan-checks.h:38:27: warning: ‘args’ may be used uninitialized [-Wmaybe-uninitialized] 38 | #define kasan_check_write __kasan_check_write ./include/linux/instrumented.h:146:9: note: in expansion of macro ‘kasan_check_write’ 146 | kasan_check_write(to, n); | ^~~~~~~~~~~~~~~~~ fs/btrfs/ioctl.c: In function ‘btrfs_ioctl_get_csums.isra’: ./include/linux/kasan-checks.h:20:6: note: by argument 1 of type ‘const volatile void *’ to ‘__kasan_check_write’ declared here 20 | bool __kasan_check_write(const volatile void *p, unsigned int size); | ^~~~~~~~~~~~~~~~~~~ fs/btrfs/ioctl.c:5201:43: note: ‘args’ declared here 5201 | struct btrfs_ioctl_get_csums_args args; | ^~~~ [POSSIBLE FALSE ALERTS] This seems to be a false alert from certain GCC versions. The @args is immediately over-written by copy_from_user(), and there is no code touching that @args until copy_from_user() finished correctly. [WORKAROUND] Initialize 'args' to zero, which suppresses the warning. Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-07-21btrfs: zoned: fix missing chunk metadata reservationGuanghui Yang
reserve_chunk_space() stores the return value of btrfs_zoned_activate_one_bg() in ret. The helper can return 1 after successfully activating a block group, but ret is later used to decide whether to reserve metadata for chunk tree updates. As a result, successful activation skips btrfs_block_rsv_add() and leaves trans->chunk_bytes_reserved unchanged. Use a separate variable for the activation result so positive success does not affect the later reservation. Keep activation failures in ret instead of returning early so the function uses the common tail path. Fixes: b6a98021e401 ("btrfs: zoned: activate necessary block group") CC: stable@vger.kernel.org Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Guanghui Yang <3497809730@qq.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-07-21btrfs: raid56: fix an incorrect csum skip during scrubQu Wenruo
Commit 7425a2894019 ("btrfs: introduce btrfs_bio_for_each_block_all() helper") uses the new helper to replace the nested loop inside verify_bio_data_sectors(), which simplifies the code. However that also changed the behavior of "continue" when a block has no data checksum. Previously the "continue" would skip the old for() loop, which would also increase @total_sector_nr. Now the "continue" will skip the new btrfs_bio_for_each_block_all() loop, which doesn't update @total_sector_nr. This means if we hit a block that has no data checksum, we will skip all the remaining blocks no matter if they have data checksum. As @total_sector_nr will never be updated, and that test_bit() will always return false. Fix it by increasing @total_sector_nr before calling "continue". Fixes: 7425a2894019 ("btrfs: introduce btrfs_bio_for_each_block_all() helper") Reviewed-by: Daniel Vacek <neelx@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-07-21btrfs: report missing raid stripe tree root during lookupDongjiang Zhu
When rescue=ibadroots ignores a failure to load the raid stripe tree root, fs_info->stripe_root remains NULL. After the rescue mount proceeds, reading file data that requires the raid stripe tree reaches btrfs_get_raid_extent_offset(). Currently btrfs_search_slot() handles the NULL root and returns -EINVAL. This avoids a NULL pointer dereference, but provides no diagnostic and incorrectly describes missing filesystem metadata as an invalid argument. Check stripe_root before allocating a path, emit a rate-limited error with the logical address, and return -EUCLEAN. Lookups with a valid stripe root are unchanged. Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Dongjiang Zhu <zhudongjiang@fnnas.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-07-21btrfs: skip global block reserve accounting for rescue mountsDongjiang Zhu
[BUG] Mounting with rescue=ibadroots after corrupting the block group tree root triggers a NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 0000000000000100 RIP: 0010:btrfs_update_global_block_rsv+0x9d/0x1c0 [btrfs] Call Trace: fill_dummy_bgs+0xd4/0x120 [btrfs] open_ctree+0xc6e/0x1ca0 [btrfs] btrfs_get_tree+0x50d/0xa40 [btrfs] The same crash occurs with a corrupted raid stripe tree root, via btrfs_read_block_groups() instead of fill_dummy_bgs(). [CAUSE] With rescue=ibadroots, btrfs_read_roots() allows the mount to continue when either root cannot be read, leaving the corresponding root pointer NULL while its on-disk feature bit remains set. btrfs_update_global_block_rsv() then dereferences the missing root based on the feature bit alone. [FIX] Rescue mounts are fully read-only and cannot start transactions, so the global reserve is never consumed. Under btrfs_is_full_ro(), mark the reserve as full and return before performing the accounting. And since we need to check if the fs is mount fully RO, export fs_is_full_ro() as btrfs_is_full_ro(), and move it to fs.h. Fixes: 8dbfc14fc736 ("btrfs: account block group tree when calculating global reserve size") Fixes: 515020900d44 ("btrfs: read raid stripe tree from disk") Suggested-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Dongjiang Zhu <zhudongjiang@fnnas.com> [ Squash the fs_is_full_ro() export commit into this one. ] Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2026-07-21btrfs: zoned: reset meta_write_pointer on zone resetJohannes Thumshirn
btrfs_reset_unused_block_groups() resets a block group's zone and sets alloc_offset back to 0 so the space can be reused, but it leaves meta_write_pointer pointing at the previous end of the zone. Once the block group is reactivated and reused for metadata, newly allocated tree blocks live before that stale write pointer. btrfs_check_meta_write_pointer() then sees them behind the write pointer, so they can never be written out in sequential order: the dirty extent buffers are stranded and pin their btree_inode folios until unmount. Reset meta_write_pointer back to the start of the block group for metadata and system block groups. Fixes: 453a73c3069a ("btrfs: zoned: reclaim unused zone by zone resetting") Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-06 06:51:20 +0000