--- /dev/null
+From 94ad504e67cd3be94fa1b2fed0cb87da0d8f9396 Mon Sep 17 00:00:00 2001
+From: Nicolas Ferre <nicolas.ferre@microchip.com>
+Date: Fri, 2 Jan 2026 18:01:31 +0100
+Subject: ARM: dts: microchip: sama7d65: fix size-cells property for i2c3
+
+From: Nicolas Ferre <nicolas.ferre@microchip.com>
+
+commit 94ad504e67cd3be94fa1b2fed0cb87da0d8f9396 upstream.
+
+Fix the #size-cells property for i2c3 node and remove the dtbs_check
+error telling that "#size-cells: 0 was expected" from schema
+atmel,at91sam-i2c.yaml and i2c-controller.yaml.
+
+Fixes: b51e4aea3ecf ("ARM: dts: microchip: sama7d65: Add FLEXCOMs to sama7d65 SoC")
+Cc: stable@vger.kernel.org # 6.16+
+Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
+Link: https://lore.kernel.org/r/20260102170135.70717-3-nicolas.ferre@microchip.com
+Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/microchip/sama7d65.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi
+index 5f3a7b178aa7..868045c650a7 100644
+--- a/arch/arm/boot/dts/microchip/sama7d65.dtsi
++++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi
+@@ -527,7 +527,7 @@ i2c3: i2c@600 {
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 37>;
+ #address-cells = <1>;
+- #size-cells = <1>;
++ #size-cells = <0>;
+ dmas = <&dma0 AT91_XDMAC_DT_PERID(12)>,
+ <&dma0 AT91_XDMAC_DT_PERID(11)>;
+ dma-names = "tx", "rx";
+--
+2.52.0
+
--- /dev/null
+From aabc977aa472ccf756372ae594d890022c19c9c8 Mon Sep 17 00:00:00 2001
+From: Hari Prasath Gujulan Elango <hari.prasathge@microchip.com>
+Date: Fri, 2 Jan 2026 18:01:30 +0100
+Subject: ARM: dts: microchip: sama7d65: fix the ranges property for flx9
+
+From: Hari Prasath Gujulan Elango <hari.prasathge@microchip.com>
+
+commit aabc977aa472ccf756372ae594d890022c19c9c8 upstream.
+
+Update the ranges property for the flexcom9 as per the datasheet and
+align with the reg property.
+
+Fixes: b51e4aea3ecf ("ARM: dts: microchip: sama7d65: Add FLEXCOMs to sama7d65 SoC")
+Cc: stable@vger.kernel.org # 6.16+
+Signed-off-by: Hari Prasath Gujulan Elango <hari.prasathge@microchip.com>
+Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
+Link: https://lore.kernel.org/r/20260102170135.70717-2-nicolas.ferre@microchip.com
+Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/microchip/sama7d65.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi
+index cd2cf9a6f40b..5f3a7b178aa7 100644
+--- a/arch/arm/boot/dts/microchip/sama7d65.dtsi
++++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi
+@@ -676,7 +676,7 @@ i2c8: i2c@600 {
+ flx9: flexcom@e2820000 {
+ compatible = "microchip,sama7d65-flexcom", "atmel,sama5d2-flexcom";
+ reg = <0xe2820000 0x200>;
+- ranges = <0x0 0xe281c000 0x800>;
++ ranges = <0x0 0xe2820000 0x800>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 43>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+--
+2.52.0
+
--- /dev/null
+From 3e4a81881c0929b21a0577bc6e69514c09da5c3f Mon Sep 17 00:00:00 2001
+From: Alexey Charkov <alchark@gmail.com>
+Date: Mon, 29 Dec 2025 14:11:59 +0400
+Subject: arm64: dts: rockchip: Configure MCLK for analog sound on NanoPi M5
+
+From: Alexey Charkov <alchark@gmail.com>
+
+commit 3e4a81881c0929b21a0577bc6e69514c09da5c3f upstream.
+
+NanoPi M5 derives its analog sound signal from SAI2 in M0 pin mode, so the
+MCLK pin should be configured accordingly for the sound codec to get its
+I2S signal from the SoC. Request the required pin config.
+
+The clock itself should also be CLK_SAI2_MCLKOUT_TO_IO for the sound to
+work (otherwise there is only silence out of the audio out jack).
+
+Fixes: 96cbdfdd3ac2 ("arm64: dts: rockchip: Add FriendlyElec NanoPi M5 support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Alexey Charkov <alchark@gmail.com>
+Link: https://patch.msgid.link/20251229-rk3576-sound-v1-2-2f59ef0d19b1@gmail.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts
+index 37184913f918..bb2cc2814b83 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts
+@@ -201,6 +201,7 @@ sound {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_det_l>;
+
++ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,hp-det-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_LOW>;
+ simple-audio-card,mclk-fs = <256>;
+@@ -218,8 +219,9 @@ simple-audio-card,codec {
+ sound-dai = <&rt5616>;
+ };
+
+- simple-audio-card,cpu {
++ masterdai: simple-audio-card,cpu {
+ sound-dai = <&sai2>;
++ system-clock-frequency = <12288000>;
+ };
+ };
+ };
+@@ -727,10 +729,12 @@ &i2c5 {
+ rt5616: audio-codec@1b {
+ compatible = "realtek,rt5616";
+ reg = <0x1b>;
+- assigned-clocks = <&cru CLK_SAI2_MCLKOUT>;
++ assigned-clocks = <&cru CLK_SAI2_MCLKOUT_TO_IO>;
+ assigned-clock-rates = <12288000>;
+- clocks = <&cru CLK_SAI2_MCLKOUT>;
++ clocks = <&cru CLK_SAI2_MCLKOUT_TO_IO>;
+ clock-names = "mclk";
++ pinctrl-0 = <&sai2m0_mclk>;
++ pinctrl-names = "default";
+ #sound-dai-cells = <0>;
+ };
+ };
+--
+2.52.0
+
--- /dev/null
+From 5ab3dd9d0a63af66377f58633fec9dad650e6827 Mon Sep 17 00:00:00 2001
+From: Alexey Charkov <alchark@gmail.com>
+Date: Mon, 29 Dec 2025 14:11:58 +0400
+Subject: arm64: dts: rockchip: Fix headphones widget name on NanoPi M5
+
+From: Alexey Charkov <alchark@gmail.com>
+
+commit 5ab3dd9d0a63af66377f58633fec9dad650e6827 upstream.
+
+Fix the mismatch between the simple-audio-card routing table vs. widget
+names, which caused the following error at boot preventing the sound
+card from getting added:
+
+[ 6.625634] asoc-simple-card sound: ASoC: DAPM unknown pin Headphones
+[ 6.627247] asoc-simple-card sound: ASoC: Failed to add route HPOL -> Headphones(*)
+[ 6.627988] asoc-simple-card sound: ASoC: Failed to add route HPOR -> Headphones(*)
+
+Fixes: 96cbdfdd3ac2 ("arm64: dts: rockchip: Add FriendlyElec NanoPi M5 support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Alexey Charkov <alchark@gmail.com>
+Link: https://patch.msgid.link/20251229-rk3576-sound-v1-1-2f59ef0d19b1@gmail.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts
+index cce34c541f7c..37184913f918 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts
+@@ -211,7 +211,7 @@ sound {
+ "Headphones", "HPOR",
+ "IN1P", "Microphone Jack";
+ simple-audio-card,widgets =
+- "Headphone", "Headphone Jack",
++ "Headphone", "Headphones",
+ "Microphone", "Microphone Jack";
+
+ simple-audio-card,codec {
+--
+2.52.0
+
--- /dev/null
+From cd8967ea3105d30adb878a9fea0e34a9378df610 Mon Sep 17 00:00:00 2001
+From: Quentin Schulz <quentin.schulz@cherry.de>
+Date: Mon, 15 Dec 2025 17:45:56 +0100
+Subject: arm64: dts: rockchip: fix unit-address for RK3588 NPU's core1 and core2's IOMMU
+
+From: Quentin Schulz <quentin.schulz@cherry.de>
+
+commit cd8967ea3105d30adb878a9fea0e34a9378df610 upstream.
+
+The Device Tree specification specifies[1] that
+
+"""
+Each node in the devicetree is named according to the following
+convention:
+ node-name@unit-address
+[...]
+The unit-address must match the first address specified in the reg
+property of the node.
+"""
+
+The first address in the reg property is fdaXa000 and not fdaX9000. This
+is likely a copy-paste error as the IOMMU for core0 has two entries in
+the reg property, the first one being fdab9000 and the second fdaba000.
+
+Let's fix this oversight to match what the spec is expecting.
+
+[1] https://github.com/devicetree-org/devicetree-specification/releases/download/v0.4/devicetree-specification-v0.4.pdf 2.2.1 Node Names
+
+Fixes: a31dfc060a74 ("arm64: dts: rockchip: Add nodes for NPU and its MMU to rk3588-base")
+Cc: stable@vger.kernel.org
+Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
+Link: https://patch.msgid.link/20251215-npu-dt-node-address-v1-1-840093e8a2bf@cherry.de
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+index 2a7921793020..7ab12d1054a7 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+@@ -1200,7 +1200,7 @@ rknn_core_1: npu@fdac0000 {
+ status = "disabled";
+ };
+
+- rknn_mmu_1: iommu@fdac9000 {
++ rknn_mmu_1: iommu@fdaca000 {
+ compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
+ reg = <0x0 0xfdaca000 0x0 0x100>;
+ interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH 0>;
+@@ -1230,7 +1230,7 @@ rknn_core_2: npu@fdad0000 {
+ status = "disabled";
+ };
+
+- rknn_mmu_2: iommu@fdad9000 {
++ rknn_mmu_2: iommu@fdada000 {
+ compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
+ reg = <0x0 0xfdada000 0x0 0x100>;
+ interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH 0>;
+--
+2.52.0
+
--- /dev/null
+From 5497ffe305b2ea31ae62d4a311d7cabfb671f54a Mon Sep 17 00:00:00 2001
+From: Ondrej Jirman <megi@xff.cz>
+Date: Mon, 24 Nov 2025 19:47:03 -0800
+Subject: arm64: dts: rockchip: Fix voltage threshold for volume keys for Pinephone Pro
+
+From: Ondrej Jirman <megi@xff.cz>
+
+commit 5497ffe305b2ea31ae62d4a311d7cabfb671f54a upstream.
+
+Previously sometimes pressing the volume-down button would register as
+a volume-up button. Match the thresholds as shown in the Pinephone Pro
+schematic.
+
+Tests:
+
+~ $ evtest
+ // Mashed the volume down ~100 times with varying intensity
+ Event: time xxx, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
+ Event: time xxx, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
+ // Mashed the volume up ~100 times with varying intensity
+ Event: time xxx, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
+ Event: time xxx, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
+
+Fixes: d3150ed53580 ("arm64: dts: rockchip: Add support for volume keys to rk3399-pinephone-pro")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ondrej Jirman <megi@xff.cz>
+Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
+Reviewed-by: Pavel Machek <pavel@ucw.cz>
+Link: https://patch.msgid.link/20251124-ppp_light_accel_mag_vol-down-v5-4-f9a10a0a50eb@gmail.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
+@@ -40,13 +40,13 @@
+ button-up {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+- press-threshold-microvolt = <100000>;
++ press-threshold-microvolt = <2000>;
+ };
+
+ button-down {
+ label = "Volume Down";
+ linux,code = <KEY_VOLUMEDOWN>;
+- press-threshold-microvolt = <600000>;
++ press-threshold-microvolt = <300000>;
+ };
+ };
+
--- /dev/null
+From 0368e4afcf20f377c81fa77b1c7d0dee4a625a44 Mon Sep 17 00:00:00 2001
+From: Geraldo Nascimento <geraldogabriel@gmail.com>
+Date: Mon, 17 Nov 2025 18:47:43 -0300
+Subject: arm64: dts: rockchip: remove dangerous max-link-speed from helios64
+
+From: Geraldo Nascimento <geraldogabriel@gmail.com>
+
+commit 0368e4afcf20f377c81fa77b1c7d0dee4a625a44 upstream.
+
+Shawn Lin from Rockchip strongly discourages attempts to use their
+RK3399 PCIe core at 5.0 GT/s speed, citing concerns about catastrophic
+failures that may happen. Even if the odds are low, drop from last user
+of this non-default property for the RK3399 platform, helios64 board
+dts.
+
+Fixes: 755fff528b1b ("arm64: dts: rockchip: add variables for pcie completion to helios64")
+Link: https://lore.kernel.org/all/e8524bf8-a90c-423f-8a58-9ef05a3db1dd@rock-chips.com/
+Cc: stable@vger.kernel.org
+Reported-by: Shawn Lin <shawn.lin@rock-chips.com>
+Reviewed-by: Dragan Simic <dsimic@manjaro.org>
+Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
+Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
+Link: https://patch.msgid.link/43bb639c120f599106fca2deee6c6599b2692c5c.1763415706.git.geraldogabriel@gmail.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
+@@ -424,7 +424,6 @@
+
+ &pcie0 {
+ ep-gpios = <&gpio2 RK_PD4 GPIO_ACTIVE_HIGH>;
+- max-link-speed = <2>;
+ num-lanes = <2>;
+ pinctrl-names = "default";
+ status = "okay";
--- /dev/null
+From ce652c98a7bfa0b7c675ef5cd85c44c186db96af Mon Sep 17 00:00:00 2001
+From: Geraldo Nascimento <geraldogabriel@gmail.com>
+Date: Mon, 17 Nov 2025 18:47:59 -0300
+Subject: arm64: dts: rockchip: remove redundant max-link-speed from nanopi-r4s
+
+From: Geraldo Nascimento <geraldogabriel@gmail.com>
+
+commit ce652c98a7bfa0b7c675ef5cd85c44c186db96af upstream.
+
+This is already the default in rk3399-base.dtsi, remove redundant
+declaration from rk3399-nanopi-r4s.dtsi.
+
+Fixes: db792e9adbf8 ("rockchip: rk3399: Add support for FriendlyARM NanoPi R4S")
+Cc: stable@vger.kernel.org
+Reported-by: Dragan Simic <dsimic@manjaro.org>
+Reviewed-by: Dragan Simic <dsimic@manjaro.org>
+Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
+Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
+Link: https://patch.msgid.link/6694456a735844177c897581f785cc00c064c7d1.1763415706.git.geraldogabriel@gmail.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
+@@ -71,7 +71,6 @@
+ };
+
+ &pcie0 {
+- max-link-speed = <1>;
+ num-lanes = <1>;
+ vpcie3v3-supply = <&vcc3v3_sys>;
+ };
--- /dev/null
+From 10d28cffb3f6ec7ad67f0a4cd32c2afa92909452 Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Wed, 3 Dec 2025 16:24:38 +0000
+Subject: comedi: Fix getting range information for subdevices 16 to 255
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 10d28cffb3f6ec7ad67f0a4cd32c2afa92909452 upstream.
+
+The `COMEDI_RANGEINFO` ioctl does not work properly for subdevice
+indices above 15. Currently, the only in-tree COMEDI drivers that
+support more than 16 subdevices are the "8255" driver and the
+"comedi_bond" driver. Making the ioctl work for subdevice indices up to
+255 is achievable. It needs minor changes to the handling of the
+`COMEDI_RANGEINFO` and `COMEDI_CHANINFO` ioctls that should be mostly
+harmless to user-space, apart from making them less broken. Details
+follow...
+
+The `COMEDI_RANGEINFO` ioctl command gets the list of supported ranges
+(usually with units of volts or milliamps) for a COMEDI subdevice or
+channel. (Only some subdevices have per-channel range tables, indicated
+by the `SDF_RANGETYPE` flag in the subdevice information.) It uses a
+`range_type` value and a user-space pointer, both supplied by
+user-space, but the `range_type` value should match what was obtained
+using the `COMEDI_CHANINFO` ioctl (if the subdevice has per-channel
+range tables) or `COMEDI_SUBDINFO` ioctl (if the subdevice uses a
+single range table for all channels). Bits 15 to 0 of the `range_type`
+value contain the length of the range table, which is the only part that
+user-space should care about (so it can use a suitably sized buffer to
+fetch the range table). Bits 23 to 16 store the channel index, which is
+assumed to be no more than 255 if the subdevice has per-channel range
+tables, and is set to 0 if the subdevice has a single range table. For
+`range_type` values produced by the `COMEDI_SUBDINFO` ioctl, bits 31 to
+24 contain the subdevice index, which is assumed to be no more than 255.
+But for `range_type` values produced by the `COMEDI_CHANINFO` ioctl,
+bits 27 to 24 contain the subdevice index, which is assumed to be no
+more than 15, and bits 31 to 28 contain the COMEDI device's minor device
+number for some unknown reason lost in the mists of time. The
+`COMEDI_RANGEINFO` ioctl extract the length from bits 15 to 0 of the
+user-supplied `range_type` value, extracts the channel index from bits
+23 to 16 (only used if the subdevice has per-channel range tables),
+extracts the subdevice index from bits 27 to 24, and ignores bits 31 to
+28. So for subdevice indices 16 to 255, the `COMEDI_SUBDINFO` or
+`COMEDI_CHANINFO` ioctl will report a `range_type` value that doesn't
+work with the `COMEDI_RANGEINFO` ioctl. It will either get the range
+table for the subdevice index modulo 16, or will fail with `-EINVAL`.
+
+To fix this, always use bits 31 to 24 of the `range_type` value to hold
+the subdevice index (assumed to be no more than 255). This affects the
+`COMEDI_CHANINFO` and `COMEDI_RANGEINFO` ioctls. There should not be
+anything in user-space that depends on the old, broken usage, although
+it may now see different values in bits 31 to 28 of the `range_type`
+values reported by the `COMEDI_CHANINFO` ioctl for subdevices that have
+per-channel subdevices. User-space should not be trying to decode bits
+31 to 16 of the `range_type` values anyway.
+
+Fixes: ed9eccbe8970 ("Staging: add comedi core")
+Cc: stable@vger.kernel.org #5.17+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://patch.msgid.link/20251203162438.176841-1-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/comedi/comedi_fops.c | 2 +-
+ drivers/comedi/range.c | 2 +-
+ include/uapi/linux/comedi.h | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/comedi/comedi_fops.c
++++ b/drivers/comedi/comedi_fops.c
+@@ -1099,7 +1099,7 @@ static int do_chaninfo_ioctl(struct come
+ for (i = 0; i < s->n_chan; i++) {
+ int x;
+
+- x = (dev->minor << 28) | (it->subdev << 24) | (i << 16) |
++ x = (it->subdev << 24) | (i << 16) |
+ (s->range_table_list[i]->length);
+ if (put_user(x, it->rangelist + i))
+ return -EFAULT;
+--- a/drivers/comedi/range.c
++++ b/drivers/comedi/range.c
+@@ -52,7 +52,7 @@ int do_rangeinfo_ioctl(struct comedi_dev
+ const struct comedi_lrange *lr;
+ struct comedi_subdevice *s;
+
+- subd = (it->range_type >> 24) & 0xf;
++ subd = (it->range_type >> 24) & 0xff;
+ chan = (it->range_type >> 16) & 0xff;
+
+ if (!dev->attached)
+--- a/include/uapi/linux/comedi.h
++++ b/include/uapi/linux/comedi.h
+@@ -640,7 +640,7 @@ struct comedi_chaninfo {
+
+ /**
+ * struct comedi_rangeinfo - used to retrieve the range table for a channel
+- * @range_type: Encodes subdevice index (bits 27:24), channel index
++ * @range_type: Encodes subdevice index (bits 31:24), channel index
+ * (bits 23:16) and range table length (bits 15:0).
+ * @range_ptr: Pointer to array of @struct comedi_krange to be filled
+ * in with the range table for the channel or subdevice.
--- /dev/null
+From bdcdf968be314b6fc8835b99fb4519e7619671e6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>
+Date: Wed, 21 Jan 2026 10:10:47 +0100
+Subject: drm, drm/xe: Fix xe userptr in the absence of CONFIG_DEVICE_PRIVATE
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+
+commit bdcdf968be314b6fc8835b99fb4519e7619671e6 upstream.
+
+CONFIG_DEVICE_PRIVATE is not selected by default by some distros,
+for example Fedora, and that leads to a regression in the xe driver
+since userptr support gets compiled out.
+
+It turns out that DRM_GPUSVM, which is needed for xe userptr support
+compiles also without CONFIG_DEVICE_PRIVATE, but doesn't compile
+without CONFIG_ZONE_DEVICE.
+Exclude the drm_pagemap files from compilation with !CONFIG_ZONE_DEVICE,
+and remove the CONFIG_DEVICE_PRIVATE dependency from CONFIG_DRM_GPUSVM and
+the xe driver's selection of it, re-enabling xe userptr for those configs.
+
+v2:
+- Don't compile the drm_pagemap files unless CONFIG_ZONE_DEVICE is set.
+- Adjust the drm_pagemap.h header accordingly.
+
+Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm")
+Cc: Matthew Auld <matthew.auld@intel.com>
+Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
+Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Cc: Matthew Brost <matthew.brost@intel.com>
+Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Cc: dri-devel@lists.freedesktop.org
+Cc: <stable@vger.kernel.org> # v6.18+
+Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Reviewed-by: Matthew Auld <matthew.auld@intel.com>
+Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Link: https://patch.msgid.link/20260121091048.41371-2-thomas.hellstrom@linux.intel.com
+(cherry picked from commit 1e372b246199ca7a35f930177fea91b557dac16e)
+Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/Kconfig | 2 +-
+ drivers/gpu/drm/Makefile | 4 +++-
+ drivers/gpu/drm/xe/Kconfig | 2 +-
+ include/drm/drm_pagemap.h | 19 +++++++++++++++++--
+ 4 files changed, 22 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/Kconfig
++++ b/drivers/gpu/drm/Kconfig
+@@ -210,7 +210,7 @@ config DRM_GPUVM
+
+ config DRM_GPUSVM
+ tristate
+- depends on DRM && DEVICE_PRIVATE
++ depends on DRM
+ select HMM_MIRROR
+ select MMU_NOTIFIER
+ help
+--- a/drivers/gpu/drm/Makefile
++++ b/drivers/gpu/drm/Makefile
+@@ -106,8 +106,10 @@ obj-$(CONFIG_DRM_EXEC) += drm_exec.o
+ obj-$(CONFIG_DRM_GPUVM) += drm_gpuvm.o
+
+ drm_gpusvm_helper-y := \
+- drm_gpusvm.o\
++ drm_gpusvm.o
++drm_gpusvm_helper-$(CONFIG_ZONE_DEVICE) += \
+ drm_pagemap.o
++
+ obj-$(CONFIG_DRM_GPUSVM) += drm_gpusvm_helper.o
+
+ obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
+--- a/drivers/gpu/drm/xe/Kconfig
++++ b/drivers/gpu/drm/xe/Kconfig
+@@ -39,7 +39,7 @@ config DRM_XE
+ select DRM_TTM
+ select DRM_TTM_HELPER
+ select DRM_EXEC
+- select DRM_GPUSVM if !UML && DEVICE_PRIVATE
++ select DRM_GPUSVM if !UML
+ select DRM_GPUVM
+ select DRM_SCHED
+ select MMU_NOTIFIER
+--- a/include/drm/drm_pagemap.h
++++ b/include/drm/drm_pagemap.h
+@@ -209,6 +209,19 @@ struct drm_pagemap_devmem_ops {
+ struct dma_fence *pre_migrate_fence);
+ };
+
++#if IS_ENABLED(CONFIG_ZONE_DEVICE)
++
++struct drm_pagemap *drm_pagemap_page_to_dpagemap(struct page *page);
++
++#else
++
++static inline struct drm_pagemap *drm_pagemap_page_to_dpagemap(struct page *page)
++{
++ return NULL;
++}
++
++#endif /* IS_ENABLED(CONFIG_ZONE_DEVICE) */
++
+ /**
+ * struct drm_pagemap_devmem - Structure representing a GPU SVM device memory allocation
+ *
+@@ -233,6 +246,8 @@ struct drm_pagemap_devmem {
+ struct dma_fence *pre_migrate_fence;
+ };
+
++#if IS_ENABLED(CONFIG_ZONE_DEVICE)
++
+ int drm_pagemap_migrate_to_devmem(struct drm_pagemap_devmem *devmem_allocation,
+ struct mm_struct *mm,
+ unsigned long start, unsigned long end,
+@@ -243,8 +258,6 @@ int drm_pagemap_evict_to_ram(struct drm_
+
+ const struct dev_pagemap_ops *drm_pagemap_pagemap_ops_get(void);
+
+-struct drm_pagemap *drm_pagemap_page_to_dpagemap(struct page *page);
+-
+ void drm_pagemap_devmem_init(struct drm_pagemap_devmem *devmem_allocation,
+ struct device *dev, struct mm_struct *mm,
+ const struct drm_pagemap_devmem_ops *ops,
+@@ -256,4 +269,6 @@ int drm_pagemap_populate_mm(struct drm_p
+ struct mm_struct *mm,
+ unsigned long timeslice_ms);
+
++#endif /* IS_ENABLED(CONFIG_ZONE_DEVICE) */
++
+ #endif
--- /dev/null
+From f9a49aa302a05e91ca01f69031cb79a0ea33031f Mon Sep 17 00:00:00 2001
+From: Joanne Koong <joannelkoong@gmail.com>
+Date: Mon, 5 Jan 2026 13:17:27 -0800
+Subject: fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Joanne Koong <joannelkoong@gmail.com>
+
+commit f9a49aa302a05e91ca01f69031cb79a0ea33031f upstream.
+
+Above the while() loop in wait_sb_inodes(), we document that we must wait
+for all pages under writeback for data integrity. Consequently, if a
+mapping, like fuse, traditionally does not have data integrity semantics,
+there is no need to wait at all; we can simply skip these inodes.
+
+This restores fuse back to prior behavior where syncs are no-ops. This
+fixes a user regression where if a system is running a faulty fuse server
+that does not reply to issued write requests, this causes wait_sb_inodes()
+to wait forever.
+
+Link: https://lkml.kernel.org/r/20260105211737.4105620-2-joannelkoong@gmail.com
+Fixes: 0c58a97f919c ("fuse: remove tmp folio for writebacks and internal rb tree")
+Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
+Reported-by: Athul Krishna <athul.krishna.kr@protonmail.com>
+Reported-by: J. Neuschäfer <j.neuschaefer@gmx.net>
+Reviewed-by: Bernd Schubert <bschubert@ddn.com>
+Tested-by: J. Neuschäfer <j.neuschaefer@gmx.net>
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: Bernd Schubert <bschubert@ddn.com>
+Cc: Bonaccorso Salvatore <carnil@debian.org>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: David Hildenbrand <david@kernel.org>
+Cc: Jan Kara <jack@suse.cz>
+Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
+Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Mike Rapoport <rppt@kernel.org>
+Cc: Miklos Szeredi <miklos@szeredi.hu>
+Cc: Suren Baghdasaryan <surenb@google.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fs-writeback.c | 7 ++++++-
+ fs/fuse/file.c | 4 +++-
+ include/linux/pagemap.h | 11 +++++++++++
+ 3 files changed, 20 insertions(+), 2 deletions(-)
+
+--- a/fs/fs-writeback.c
++++ b/fs/fs-writeback.c
+@@ -2729,8 +2729,13 @@ static void wait_sb_inodes(struct super_
+ * The mapping can appear untagged while still on-list since we
+ * do not have the mapping lock. Skip it here, wb completion
+ * will remove it.
++ *
++ * If the mapping does not have data integrity semantics,
++ * there's no need to wait for the writeout to complete, as the
++ * mapping cannot guarantee that data is persistently stored.
+ */
+- if (!mapping_tagged(mapping, PAGECACHE_TAG_WRITEBACK))
++ if (!mapping_tagged(mapping, PAGECACHE_TAG_WRITEBACK) ||
++ mapping_no_data_integrity(mapping))
+ continue;
+
+ spin_unlock_irq(&sb->s_inode_wblist_lock);
+--- a/fs/fuse/file.c
++++ b/fs/fuse/file.c
+@@ -3146,8 +3146,10 @@ void fuse_init_file_inode(struct inode *
+
+ inode->i_fop = &fuse_file_operations;
+ inode->i_data.a_ops = &fuse_file_aops;
+- if (fc->writeback_cache)
++ if (fc->writeback_cache) {
+ mapping_set_writeback_may_deadlock_on_reclaim(&inode->i_data);
++ mapping_set_no_data_integrity(&inode->i_data);
++ }
+
+ INIT_LIST_HEAD(&fi->write_files);
+ INIT_LIST_HEAD(&fi->queued_writes);
+--- a/include/linux/pagemap.h
++++ b/include/linux/pagemap.h
+@@ -213,6 +213,7 @@ enum mapping_flags {
+ AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM = 9,
+ AS_KERNEL_FILE = 10, /* mapping for a fake kernel file that shouldn't
+ account usage to user cgroups */
++ AS_NO_DATA_INTEGRITY = 11, /* no data integrity guarantees */
+ /* Bits 16-25 are used for FOLIO_ORDER */
+ AS_FOLIO_ORDER_BITS = 5,
+ AS_FOLIO_ORDER_MIN = 16,
+@@ -348,6 +349,16 @@ static inline bool mapping_writeback_may
+ return test_bit(AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM, &mapping->flags);
+ }
+
++static inline void mapping_set_no_data_integrity(struct address_space *mapping)
++{
++ set_bit(AS_NO_DATA_INTEGRITY, &mapping->flags);
++}
++
++static inline bool mapping_no_data_integrity(const struct address_space *mapping)
++{
++ return test_bit(AS_NO_DATA_INTEGRITY, &mapping->flags);
++}
++
+ static inline gfp_t mapping_gfp_mask(const struct address_space *mapping)
+ {
+ return mapping->gfp_mask;
--- /dev/null
+From e351836a54e3b0b4483f896abcd6a0dc71097693 Mon Sep 17 00:00:00 2001
+From: Yixun Lan <dlan@kernel.org>
+Date: Thu, 22 Jan 2026 07:52:00 +0800
+Subject: i2c: spacemit: drop IRQF_ONESHOT flag from IRQ request
+
+From: Yixun Lan <dlan@kernel.org>
+
+commit e351836a54e3b0b4483f896abcd6a0dc71097693 upstream.
+
+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
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-k1.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/i2c/busses/i2c-k1.c
++++ b/drivers/i2c/busses/i2c-k1.c
+@@ -566,7 +566,7 @@ static int spacemit_i2c_probe(struct pla
+ return dev_err_probe(dev, i2c->irq, "failed to get irq resource");
+
+ ret = devm_request_irq(i2c->dev, i2c->irq, spacemit_i2c_irq_handler,
+- IRQF_NO_SUSPEND | IRQF_ONESHOT, dev_name(i2c->dev), i2c);
++ IRQF_NO_SUSPEND, dev_name(i2c->dev), i2c);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to request irq");
+
--- /dev/null
+From c34e2e2d67b3bb8d5a6d09b0d6dac845cdd13fb3 Mon Sep 17 00:00:00 2001
+From: Francesco Lavra <flavra@baylibre.com>
+Date: Mon, 1 Dec 2025 11:00:10 +0100
+Subject: iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detection
+
+From: Francesco Lavra <flavra@baylibre.com>
+
+commit c34e2e2d67b3bb8d5a6d09b0d6dac845cdd13fb3 upstream.
+
+The st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULL
+event_spec field, indicating support for IIO events. However, event
+detection is not supported for all sensors, and if userspace tries to
+configure accelerometer wakeup events on a sensor device that does not
+support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULL
+pointer when trying to write to the wakeup register.
+Define an additional struct iio_chan_spec array whose members have a NULL
+event_spec field, and use this array instead of st_lsm6dsx_acc_channels for
+sensors without event detection capability.
+
+Fixes: b5969abfa8b8 ("iio: imu: st_lsm6dsx: add motion events")
+Signed-off-by: Francesco Lavra <flavra@baylibre.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
+Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 15 +++++++++++----
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
++++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
+@@ -101,6 +101,13 @@ static const struct iio_chan_spec st_lsm
+ IIO_CHAN_SOFT_TIMESTAMP(3),
+ };
+
++static const struct iio_chan_spec st_lsm6ds0_acc_channels[] = {
++ ST_LSM6DSX_CHANNEL(IIO_ACCEL, 0x28, IIO_MOD_X, 0),
++ ST_LSM6DSX_CHANNEL(IIO_ACCEL, 0x2a, IIO_MOD_Y, 1),
++ ST_LSM6DSX_CHANNEL(IIO_ACCEL, 0x2c, IIO_MOD_Z, 2),
++ IIO_CHAN_SOFT_TIMESTAMP(3),
++};
++
+ static const struct iio_chan_spec st_lsm6dsx_gyro_channels[] = {
+ ST_LSM6DSX_CHANNEL(IIO_ANGL_VEL, 0x22, IIO_MOD_X, 0),
+ ST_LSM6DSX_CHANNEL(IIO_ANGL_VEL, 0x24, IIO_MOD_Y, 1),
+@@ -142,8 +149,8 @@ static const struct st_lsm6dsx_settings
+ },
+ .channels = {
+ [ST_LSM6DSX_ID_ACC] = {
+- .chan = st_lsm6dsx_acc_channels,
+- .len = ARRAY_SIZE(st_lsm6dsx_acc_channels),
++ .chan = st_lsm6ds0_acc_channels,
++ .len = ARRAY_SIZE(st_lsm6ds0_acc_channels),
+ },
+ [ST_LSM6DSX_ID_GYRO] = {
+ .chan = st_lsm6ds0_gyro_channels,
+@@ -1449,8 +1456,8 @@ static const struct st_lsm6dsx_settings
+ },
+ .channels = {
+ [ST_LSM6DSX_ID_ACC] = {
+- .chan = st_lsm6dsx_acc_channels,
+- .len = ARRAY_SIZE(st_lsm6dsx_acc_channels),
++ .chan = st_lsm6ds0_acc_channels,
++ .len = ARRAY_SIZE(st_lsm6ds0_acc_channels),
+ },
+ [ST_LSM6DSX_ID_GYRO] = {
+ .chan = st_lsm6dsx_gyro_channels,
--- /dev/null
+From 2934325f56150ad8dab8ab92cbe2997242831396 Mon Sep 17 00:00:00 2001
+From: feng <alec.jiang@gmail.com>
+Date: Sat, 24 Jan 2026 21:44:12 -0800
+Subject: Input: i8042 - add quirk for ASUS Zenbook UX425QA_UM425QA
+
+From: feng <alec.jiang@gmail.com>
+
+commit 2934325f56150ad8dab8ab92cbe2997242831396 upstream.
+
+The ASUS Zenbook UX425QA_UM425QA fails to initialize the keyboard after
+a cold boot.
+
+A quirk already exists for "ZenBook UX425", but some Zenbooks report
+"Zenbook" with a lowercase 'b'. Since DMI matching is case-sensitive,
+the existing quirk is not applied to these "extra special" Zenbooks.
+
+Testing confirms that this model needs the same quirks as the ZenBook
+UX425 variants.
+
+Signed-off-by: feng <alec.jiang@gmail.com>
+Link: https://patch.msgid.link/20260122013957.11184-1-alec.jiang@gmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/serio/i8042-acpipnpio.h | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/input/serio/i8042-acpipnpio.h
++++ b/drivers/input/serio/i8042-acpipnpio.h
+@@ -116,6 +116,17 @@ static const struct dmi_system_id i8042_
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_NEVER)
+ },
+ {
++ /*
++ * ASUS Zenbook UX425QA_UM425QA
++ * Some Zenbooks report "Zenbook" with a lowercase b.
++ */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Zenbook UX425QA_UM425QA"),
++ },
++ .driver_data = (void *)(SERIO_QUIRK_PROBE_DEFER | SERIO_QUIRK_RESET_NEVER)
++ },
++ {
+ /* ASUS ZenBook UX425UA/QA */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
--- /dev/null
+From 19a5d9ba6208e9006a2a9d5962aea4d6e427d8ab Mon Sep 17 00:00:00 2001
+From: gongqi <550230171hxy@gmail.com>
+Date: Thu, 22 Jan 2026 23:54:59 +0800
+Subject: Input: i8042 - add quirks for MECHREVO Wujie 15X Pro
+
+From: gongqi <550230171hxy@gmail.com>
+
+commit 19a5d9ba6208e9006a2a9d5962aea4d6e427d8ab upstream.
+
+The MECHREVO Wujie 15X Pro requires several i8042 quirks to function
+correctly. Specifically, NOMUX, RESET_ALWAYS, NOLOOP, and NOPNP are
+needed to ensure the keyboard and touchpad work reliably.
+
+Signed-off-by: gongqi <550230171hxy@gmail.com>
+Link: https://patch.msgid.link/20260122155501.376199-3-550230171hxy@gmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/serio/i8042-acpipnpio.h | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/input/serio/i8042-acpipnpio.h
++++ b/drivers/input/serio/i8042-acpipnpio.h
+@@ -1176,6 +1176,13 @@ static const struct dmi_system_id i8042_
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
+ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
+ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "WUJIE Series-X5SP4NAG"),
++ },
++ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
++ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
++ },
+ /*
+ * A lot of modern Clevo barebones have touchpad and/or keyboard issues
+ * after suspend fixable with the forcenorestore quirk.
--- /dev/null
+From 10dc959398175736e495f71c771f8641e1ca1907 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Tue, 20 Jan 2026 07:42:50 -0700
+Subject: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit 10dc959398175736e495f71c771f8641e1ca1907 upstream.
+
+Currently this is checked before running the pending work. Normally this
+is quite fine, as work items either end up blocking (which will create a
+new worker for other items), or they complete fairly quickly. But syzbot
+reports an issue where io-wq takes seemingly forever to exit, and with a
+bit of debugging, this turns out to be because it queues a bunch of big
+(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't
+support ->read_iter(), loop_rw_iter() ends up handling them. Each read
+returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of
+these pending, processing the whole chain can take a long time. Easily
+longer than the syzbot uninterruptible sleep timeout of 140 seconds.
+This then triggers a complaint off the io-wq exit path:
+
+INFO: task syz.4.135:6326 blocked for more than 143 seconds.
+ Not tainted syzkaller #0
+ Blocked by coredump.
+"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
+task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000
+Call Trace:
+ <TASK>
+ context_switch kernel/sched/core.c:5256 [inline]
+ __schedule+0x1139/0x6150 kernel/sched/core.c:6863
+ __schedule_loop kernel/sched/core.c:6945 [inline]
+ schedule+0xe7/0x3a0 kernel/sched/core.c:6960
+ schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75
+ do_wait_for_common kernel/sched/completion.c:100 [inline]
+ __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121
+ io_wq_exit_workers io_uring/io-wq.c:1328 [inline]
+ io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356
+ io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203
+ io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651
+ io_uring_files_cancel include/linux/io_uring.h:19 [inline]
+ do_exit+0x2ce/0x2bd0 kernel/exit.c:911
+ do_group_exit+0xd3/0x2a0 kernel/exit.c:1112
+ get_signal+0x2671/0x26d0 kernel/signal.c:3034
+ arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337
+ __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]
+ exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75
+ __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
+ syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
+ syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]
+ syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]
+ do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+RIP: 0033:0x7fa02738f749
+RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
+RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749
+RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098
+RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
+R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98
+
+There's really nothing wrong here, outside of processing these reads
+will take a LONG time. However, we can speed up the exit by checking the
+IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will
+exit the ring after queueing up all of these reads. Then once the first
+item is processed, io-wq will simply cancel the rest. That should avoid
+syzbot running into this complaint again.
+
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/all/68a2decc.050a0220.e29e5.0099.GAE@google.com/
+Reported-by: syzbot+4eb282331cab6d5b6588@syzkaller.appspotmail.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/io-wq.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/io_uring/io-wq.c
++++ b/io_uring/io-wq.c
+@@ -598,9 +598,9 @@ static void io_worker_handle_work(struct
+ __releases(&acct->lock)
+ {
+ struct io_wq *wq = worker->wq;
+- bool do_kill = test_bit(IO_WQ_BIT_EXIT, &wq->state);
+
+ do {
++ bool do_kill = test_bit(IO_WQ_BIT_EXIT, &wq->state);
+ struct io_wq_work *work;
+
+ /*
--- /dev/null
+From ca1a47cd3f5f4c46ca188b1c9a27af87d1ab2216 Mon Sep 17 00:00:00 2001
+From: "David Hildenbrand (Red Hat)" <david@kernel.org>
+Date: Tue, 23 Dec 2025 22:40:34 +0100
+Subject: mm/hugetlb: fix hugetlb_pmd_shared()
+
+From: David Hildenbrand (Red Hat) <david@kernel.org>
+
+commit ca1a47cd3f5f4c46ca188b1c9a27af87d1ab2216 upstream.
+
+Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using
+mmu_gather)", v3.
+
+One functional fix, one performance regression fix, and two related
+comment fixes.
+
+I cleaned up my prototype I recently shared [1] for the performance fix,
+deferring most of the cleanups I had in the prototype to a later point.
+While doing that I identified the other things.
+
+The goal of this patch set is to be backported to stable trees "fairly"
+easily. At least patch #1 and #4.
+
+Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing
+Patch #2 + #3 are simple comment fixes that patch #4 interacts with.
+Patch #4 is a fix for the reported performance regression due to excessive
+IPI broadcasts during fork()+exit().
+
+The last patch is all about TLB flushes, IPIs and mmu_gather.
+Read: complicated
+
+There are plenty of cleanups in the future to be had + one reasonable
+optimization on x86. But that's all out of scope for this series.
+
+Runtime tested, with a focus on fixing the performance regression using
+the original reproducer [2] on x86.
+
+
+This patch (of 4):
+
+We switched from (wrongly) using the page count to an independent shared
+count. Now, shared page tables have a refcount of 1 (excluding
+speculative references) and instead use ptdesc->pt_share_count to identify
+sharing.
+
+We didn't convert hugetlb_pmd_shared(), so right now, we would never
+detect a shared PMD table as such, because sharing/unsharing no longer
+touches the refcount of a PMD table.
+
+Page migration, like mbind() or migrate_pages() would allow for migrating
+folios mapped into such shared PMD tables, even though the folios are not
+exclusive. In smaps we would account them as "private" although they are
+"shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the
+pagemap interface.
+
+Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().
+
+Link: https://lkml.kernel.org/r/20251223214037.580860-1-david@kernel.org
+Link: https://lkml.kernel.org/r/20251223214037.580860-2-david@kernel.org
+Link: https://lore.kernel.org/all/8cab934d-4a56-44aa-b641-bfd7e23bd673@kernel.org/ [1]
+Link: https://lore.kernel.org/all/8cab934d-4a56-44aa-b641-bfd7e23bd673@kernel.org/ [2]
+Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count")
+Signed-off-by: David Hildenbrand (Red Hat) <david@kernel.org>
+Reviewed-by: Rik van Riel <riel@surriel.com>
+Reviewed-by: Lance Yang <lance.yang@linux.dev>
+Tested-by: Lance Yang <lance.yang@linux.dev>
+Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
+Tested-by: Laurence Oberman <loberman@redhat.com>
+Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Acked-by: Oscar Salvador <osalvador@suse.de>
+Cc: Liu Shixin <liushixin2@huawei.com>
+Cc: Uschakow, Stanislav" <suschako@amazon.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/hugetlb.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/hugetlb.h
++++ b/include/linux/hugetlb.h
+@@ -1323,7 +1323,7 @@ static inline __init void hugetlb_cma_re
+ #ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING
+ static inline bool hugetlb_pmd_shared(pte_t *pte)
+ {
+- return page_count(virt_to_page(pte)) > 1;
++ return ptdesc_pmd_is_shared(virt_to_ptdesc(pte));
+ }
+ #else
+ static inline bool hugetlb_pmd_shared(pte_t *pte)
--- /dev/null
+From 16aca2c98a6fdf071e5a1a765a295995d7c7e346 Mon Sep 17 00:00:00 2001
+From: Yosry Ahmed <yosry.ahmed@linux.dev>
+Date: Fri, 16 Jan 2026 20:52:47 +0000
+Subject: mm: restore per-memcg proactive reclaim with !CONFIG_NUMA
+
+From: Yosry Ahmed <yosry.ahmed@linux.dev>
+
+commit 16aca2c98a6fdf071e5a1a765a295995d7c7e346 upstream.
+
+Commit 2b7226af730c ("mm/memcg: make memory.reclaim interface generic")
+moved proactive reclaim logic from memory.reclaim handler to a generic
+user_proactive_reclaim() helper to be used for per-node proactive reclaim.
+
+However, user_proactive_reclaim() was only defined under CONFIG_NUMA, with
+a stub always returning 0 otherwise. This broke memory.reclaim on
+!CONFIG_NUMA configs, causing it to report success without actually
+attempting reclaim.
+
+Move the definition of user_proactive_reclaim() outside CONFIG_NUMA, and
+instead define a stub for __node_reclaim() in the !CONFIG_NUMA case.
+__node_reclaim() is only called from user_proactive_reclaim() when a write
+is made to sys/devices/system/node/nodeX/reclaim, which is only defined
+with CONFIG_NUMA.
+
+Link: https://lkml.kernel.org/r/20260116205247.928004-1-yosry.ahmed@linux.dev
+Fixes: 2b7226af730c ("mm/memcg: make memory.reclaim interface generic")
+Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
+Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Axel Rasmussen <axelrasmussen@google.com>
+Cc: David Hildenbrand <david@kernel.org>
+Cc: Davidlohr Bueso <dave@stgolabs.net>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Liam Howlett <liam.howlett@oracle.com>
+Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Cc: Mike Rapoport <rppt@kernel.org>
+Cc: Qi Zheng <zhengqi.arch@bytedance.com>
+Cc: Suren Baghdasaryan <surenb@google.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Wei Xu <weixugc@google.com>
+Cc: Yuanchu Xie <yuanchu@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/internal.h | 8 --------
+ mm/vmscan.c | 13 +++++++++++--
+ 2 files changed, 11 insertions(+), 10 deletions(-)
+
+--- a/mm/internal.h
++++ b/mm/internal.h
+@@ -538,16 +538,8 @@ extern unsigned long highest_memmap_pfn;
+ bool folio_isolate_lru(struct folio *folio);
+ void folio_putback_lru(struct folio *folio);
+ extern void reclaim_throttle(pg_data_t *pgdat, enum vmscan_throttle_state reason);
+-#ifdef CONFIG_NUMA
+ int user_proactive_reclaim(char *buf,
+ struct mem_cgroup *memcg, pg_data_t *pgdat);
+-#else
+-static inline int user_proactive_reclaim(char *buf,
+- struct mem_cgroup *memcg, pg_data_t *pgdat)
+-{
+- return 0;
+-}
+-#endif
+
+ /*
+ * in mm/rmap.c:
+--- a/mm/vmscan.c
++++ b/mm/vmscan.c
+@@ -7740,6 +7740,17 @@ int node_reclaim(struct pglist_data *pgd
+ return ret;
+ }
+
++#else
++
++static unsigned long __node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask,
++ unsigned long nr_pages,
++ struct scan_control *sc)
++{
++ return 0;
++}
++
++#endif
++
+ enum {
+ MEMORY_RECLAIM_SWAPPINESS = 0,
+ MEMORY_RECLAIM_SWAPPINESS_MAX,
+@@ -7847,8 +7858,6 @@ int user_proactive_reclaim(char *buf,
+ return 0;
+ }
+
+-#endif
+-
+ /**
+ * check_move_unevictable_folios - Move evictable folios to appropriate zone
+ * lru list
--- /dev/null
+From a8682d500f691b6dfaa16ae1502d990aeb86e8be Mon Sep 17 00:00:00 2001
+From: "David Hildenbrand (Red Hat)" <david@kernel.org>
+Date: Tue, 23 Dec 2025 22:40:36 +0100
+Subject: mm/rmap: fix two comments related to huge_pmd_unshare()
+
+From: David Hildenbrand (Red Hat) <david@kernel.org>
+
+commit a8682d500f691b6dfaa16ae1502d990aeb86e8be upstream.
+
+PMD page table unsharing no longer touches the refcount of a PMD page
+table. Also, it is not about dropping the refcount of a "PMD page" but
+the "PMD page table".
+
+Let's just simplify by saying that the PMD page table was unmapped,
+consequently also unmapping the folio that was mapped into this page.
+
+This code should be deduplicated in the future.
+
+Link: https://lkml.kernel.org/r/20251223214037.580860-4-david@kernel.org
+Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count")
+Signed-off-by: David Hildenbrand (Red Hat) <david@kernel.org>
+Reviewed-by: Rik van Riel <riel@surriel.com>
+Tested-by: Laurence Oberman <loberman@redhat.com>
+Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Acked-by: Oscar Salvador <osalvador@suse.de>
+Cc: Liu Shixin <liushixin2@huawei.com>
+Cc: Harry Yoo <harry.yoo@oracle.com>
+Cc: Lance Yang <lance.yang@linux.dev>
+Cc: "Uschakow, Stanislav" <suschako@amazon.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/rmap.c | 20 ++++----------------
+ 1 file changed, 4 insertions(+), 16 deletions(-)
+
+--- a/mm/rmap.c
++++ b/mm/rmap.c
+@@ -2027,14 +2027,8 @@ static bool try_to_unmap_one(struct foli
+ flush_tlb_range(vma,
+ range.start, range.end);
+ /*
+- * The ref count of the PMD page was
+- * dropped which is part of the way map
+- * counting is done for shared PMDs.
+- * Return 'true' here. When there is
+- * no other sharing, huge_pmd_unshare
+- * returns false and we will unmap the
+- * actual page and drop map count
+- * to zero.
++ * The PMD table was unmapped,
++ * consequently unmapping the folio.
+ */
+ goto walk_done;
+ }
+@@ -2416,14 +2410,8 @@ static bool try_to_migrate_one(struct fo
+ range.start, range.end);
+
+ /*
+- * The ref count of the PMD page was
+- * dropped which is part of the way map
+- * counting is done for shared PMDs.
+- * Return 'true' here. When there is
+- * no other sharing, huge_pmd_unshare
+- * returns false and we will unmap the
+- * actual page and drop map count
+- * to zero.
++ * The PMD table was unmapped,
++ * consequently unmapping the folio.
+ */
+ page_vma_mapped_walk_done(&pvmw);
+ break;
--- /dev/null
+From 25150715e0b049b99df664daf05dab12f41c3e13 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Thu, 15 Jan 2026 14:31:11 -0600
+Subject: platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+commit 25150715e0b049b99df664daf05dab12f41c3e13 upstream.
+
+The GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfs
+attributes:
+
+1. Off-by-one error: The loop condition used '<=' instead of '<',
+ causing access beyond array bounds. Since array indices are 0-based
+ and go from 0 to instances_count-1, the loop should use '<'.
+
+2. Missing NULL check: The code dereferenced attr_name_kobj->name
+ without checking if attr_name_kobj was NULL, causing a null pointer
+ dereference in min_length_show() and other attribute show functions.
+
+The panic occurred when fwupd tried to read BIOS configuration attributes:
+
+ Oops: general protection fault [#1] SMP KASAN NOPTI
+ KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
+ RIP: 0010:min_length_show+0xcf/0x1d0 [hp_bioscfg]
+
+Add a NULL check for attr_name_kobj before dereferencing and corrects
+the loop boundary to match the pattern used elsewhere in the driver.
+
+Cc: stable@vger.kernel.org
+Fixes: 5f94f181ca25 ("platform/x86: hp-bioscfg: bioscfg-h")
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Link: https://patch.msgid.link/20260115203725.828434-3-mario.limonciello@amd.com
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/hp/hp-bioscfg/bioscfg.h | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/platform/x86/hp/hp-bioscfg/bioscfg.h
++++ b/drivers/platform/x86/hp/hp-bioscfg/bioscfg.h
+@@ -10,6 +10,7 @@
+
+ #include <linux/wmi.h>
+ #include <linux/types.h>
++#include <linux/string.h>
+ #include <linux/device.h>
+ #include <linux/module.h>
+ #include <linux/kernel.h>
+@@ -285,8 +286,9 @@ enum hp_wmi_data_elements {
+ { \
+ int i; \
+ \
+- for (i = 0; i <= bioscfg_drv.type##_instances_count; i++) { \
+- if (!strcmp(kobj->name, bioscfg_drv.type##_data[i].attr_name_kobj->name)) \
++ for (i = 0; i < bioscfg_drv.type##_instances_count; i++) { \
++ if (bioscfg_drv.type##_data[i].attr_name_kobj && \
++ !strcmp(kobj->name, bioscfg_drv.type##_data[i].attr_name_kobj->name)) \
+ return i; \
+ } \
+ return -EIO; \
--- /dev/null
+From fdee1b09721605f532352628d0a24623e7062efb Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Thu, 15 Jan 2026 14:31:10 -0600
+Subject: platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+commit fdee1b09721605f532352628d0a24623e7062efb upstream.
+
+The hp-bioscfg driver attempts to register kobjects with empty names when
+the HP BIOS returns attributes with empty name strings. This causes
+multiple kernel warnings:
+
+ kobject: (00000000135fb5e6): attempted to be registered with empty name!
+ WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310
+
+Add validation in hp_init_bios_buffer_attribute() to check if the
+attribute name is empty after parsing it from the WMI buffer. If empty,
+log a debug message and skip registration of that attribute, allowing the
+module to continue processing other valid attributes.
+
+Cc: stable@vger.kernel.org
+Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg")
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Link: https://patch.msgid.link/20260115203725.828434-2-mario.limonciello@amd.com
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/hp/hp-bioscfg/bioscfg.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/platform/x86/hp/hp-bioscfg/bioscfg.c
++++ b/drivers/platform/x86/hp/hp-bioscfg/bioscfg.c
+@@ -10,6 +10,8 @@
+ #include <linux/fs.h>
+ #include <linux/module.h>
+ #include <linux/kernel.h>
++#include <linux/printk.h>
++#include <linux/string.h>
+ #include <linux/wmi.h>
+ #include "bioscfg.h"
+ #include "../../firmware_attributes_class.h"
+@@ -781,6 +783,12 @@ static int hp_init_bios_buffer_attribute
+ if (ret < 0)
+ goto buff_attr_exit;
+
++ if (strlen(str) == 0) {
++ pr_debug("Ignoring attribute with empty name\n");
++ ret = 0;
++ goto buff_attr_exit;
++ }
++
+ if (attr_type == HPWMI_PASSWORD_TYPE ||
+ attr_type == HPWMI_SECURE_PLATFORM_TYPE)
+ temp_kset = bioscfg_drv.authentication_dir_kset;
--- /dev/null
+From f40ddcc0c0ca1a0122a7f4440b429f97d5832bdf Mon Sep 17 00:00:00 2001
+From: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+Date: Tue, 13 Jan 2026 17:24:58 -0300
+Subject: Revert "nfc/nci: Add the inconsistency check between the input data length and count"
+
+From: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+
+commit f40ddcc0c0ca1a0122a7f4440b429f97d5832bdf upstream.
+
+This reverts commit 068648aab72c9ba7b0597354ef4d81ffaac7b979.
+
+NFC packets may have NUL-bytes. Checking for string length is not a correct
+assumption here. As long as there is a check for the length copied from
+copy_from_user, all should be fine.
+
+The fix only prevented the syzbot reproducer from triggering the bug
+because the packet is not enqueued anymore and the code that triggers the
+bug is not exercised.
+
+The fix even broke
+testing/selftests/nci/nci_dev, making all tests there fail. After the
+revert, 6 out of 8 tests pass.
+
+Fixes: 068648aab72c ("nfc/nci: Add the inconsistency check between the input data length and count")
+Cc: stable@vger.kernel.org
+Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+Link: https://patch.msgid.link/20260113202458.449455-1-cascardo@igalia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nfc/virtual_ncidev.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/nfc/virtual_ncidev.c
++++ b/drivers/nfc/virtual_ncidev.c
+@@ -125,10 +125,6 @@ static ssize_t virtual_ncidev_write(stru
+ kfree_skb(skb);
+ return -EFAULT;
+ }
+- if (strnlen(skb->data, count) != count) {
+- kfree_skb(skb);
+- return -EINVAL;
+- }
+
+ nci_recv_frame(vdev->ndev, skb);
+ return count;
--- /dev/null
+From 2c28769a51deb6022d7fbd499987e237a01dd63a Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Wed, 14 Jan 2026 22:03:23 +0000
+Subject: rxrpc: Fix recvmsg() unconditional requeue
+
+From: David Howells <dhowells@redhat.com>
+
+commit 2c28769a51deb6022d7fbd499987e237a01dd63a upstream.
+
+If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at
+the front of the recvmsg queue already has its mutex locked, it requeues
+the call - whether or not the call is already queued. The call may be on
+the queue because MSG_PEEK was also passed and so the call was not dequeued
+or because the I/O thread requeued it.
+
+The unconditional requeue may then corrupt the recvmsg queue, leading to
+things like UAFs or refcount underruns.
+
+Fix this by only requeuing the call if it isn't already on the queue - and
+moving it to the front if it is already queued. If we don't queue it, we
+have to put the ref we obtained by dequeuing it.
+
+Also, MSG_PEEK doesn't dequeue the call so shouldn't call
+rxrpc_notify_socket() for the call if we didn't use up all the data on the
+queue, so fix that also.
+
+Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
+Reported-by: Faith <faith@zellic.io>
+Reported-by: Pumpkin Chang <pumpkin@devco.re>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Acked-by: Marc Dionne <marc.dionne@auristor.com>
+cc: Nir Ohfeld <niro@wiz.io>
+cc: Willy Tarreau <w@1wt.eu>
+cc: Simon Horman <horms@kernel.org>
+cc: linux-afs@lists.infradead.org
+cc: stable@kernel.org
+Link: https://patch.msgid.link/95163.1768428203@warthog.procyon.org.uk
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/trace/events/rxrpc.h | 4 ++++
+ net/rxrpc/recvmsg.c | 19 +++++++++++++++----
+ 2 files changed, 19 insertions(+), 4 deletions(-)
+
+--- a/include/trace/events/rxrpc.h
++++ b/include/trace/events/rxrpc.h
+@@ -322,6 +322,7 @@
+ EM(rxrpc_call_put_kernel, "PUT kernel ") \
+ EM(rxrpc_call_put_poke, "PUT poke ") \
+ EM(rxrpc_call_put_recvmsg, "PUT recvmsg ") \
++ EM(rxrpc_call_put_recvmsg_peek_nowait, "PUT peek-nwt") \
+ EM(rxrpc_call_put_release_recvmsg_q, "PUT rls-rcmq") \
+ EM(rxrpc_call_put_release_sock, "PUT rls-sock") \
+ EM(rxrpc_call_put_release_sock_tba, "PUT rls-sk-a") \
+@@ -340,6 +341,9 @@
+ EM(rxrpc_call_see_input, "SEE input ") \
+ EM(rxrpc_call_see_notify_released, "SEE nfy-rlsd") \
+ EM(rxrpc_call_see_recvmsg, "SEE recvmsg ") \
++ EM(rxrpc_call_see_recvmsg_requeue, "SEE recv-rqu") \
++ EM(rxrpc_call_see_recvmsg_requeue_first, "SEE recv-rqF") \
++ EM(rxrpc_call_see_recvmsg_requeue_move, "SEE recv-rqM") \
+ EM(rxrpc_call_see_release, "SEE release ") \
+ EM(rxrpc_call_see_userid_exists, "SEE u-exists") \
+ EM(rxrpc_call_see_waiting_call, "SEE q-conn ") \
+--- a/net/rxrpc/recvmsg.c
++++ b/net/rxrpc/recvmsg.c
+@@ -518,7 +518,8 @@ try_again:
+ if (rxrpc_call_has_failed(call))
+ goto call_failed;
+
+- if (!skb_queue_empty(&call->recvmsg_queue))
++ if (!(flags & MSG_PEEK) &&
++ !skb_queue_empty(&call->recvmsg_queue))
+ rxrpc_notify_socket(call);
+ goto not_yet_complete;
+
+@@ -549,11 +550,21 @@ error_unlock_call:
+ error_requeue_call:
+ if (!(flags & MSG_PEEK)) {
+ spin_lock_irq(&rx->recvmsg_lock);
+- list_add(&call->recvmsg_link, &rx->recvmsg_q);
+- spin_unlock_irq(&rx->recvmsg_lock);
++ if (list_empty(&call->recvmsg_link)) {
++ list_add(&call->recvmsg_link, &rx->recvmsg_q);
++ rxrpc_see_call(call, rxrpc_call_see_recvmsg_requeue);
++ spin_unlock_irq(&rx->recvmsg_lock);
++ } else if (list_is_first(&call->recvmsg_link, &rx->recvmsg_q)) {
++ spin_unlock_irq(&rx->recvmsg_lock);
++ rxrpc_put_call(call, rxrpc_call_see_recvmsg_requeue_first);
++ } else {
++ list_move(&call->recvmsg_link, &rx->recvmsg_q);
++ spin_unlock_irq(&rx->recvmsg_lock);
++ rxrpc_put_call(call, rxrpc_call_see_recvmsg_requeue_move);
++ }
+ trace_rxrpc_recvmsg(call_debug_id, rxrpc_recvmsg_requeue, 0);
+ } else {
+- rxrpc_put_call(call, rxrpc_call_put_recvmsg);
++ rxrpc_put_call(call, rxrpc_call_put_recvmsg_peek_nowait);
+ }
+ error_no_call:
+ release_sock(&rx->sk);
--- /dev/null
+From 9eacec5d18f98f89be520eeeef4b377acee3e4b8 Mon Sep 17 00:00:00 2001
+From: Long Li <longli@microsoft.com>
+Date: Fri, 16 Jan 2026 17:03:02 -0800
+Subject: scsi: storvsc: Process unsupported MODE_SENSE_10
+
+From: Long Li <longli@microsoft.com>
+
+commit 9eacec5d18f98f89be520eeeef4b377acee3e4b8 upstream.
+
+The Hyper-V host does not support MODE_SENSE_10 and MODE_SENSE. The
+driver handles MODE_SENSE as unsupported command, but not for
+MODE_SENSE_10. Add MODE_SENSE_10 to the same handling logic and return
+correct code to SCSI layer.
+
+Fixes: 89ae7d709357 ("Staging: hv: storvsc: Move the storage driver out of the staging area")
+Cc: stable@kernel.org
+Signed-off-by: Long Li <longli@microsoft.com>
+Reviewed-by: Michael Kelley <mhklinux@outlook.com>
+Link: https://patch.msgid.link/20260117010302.294068-1-longli@linux.microsoft.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/storvsc_drv.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/storvsc_drv.c
++++ b/drivers/scsi/storvsc_drv.c
+@@ -1144,7 +1144,7 @@ static void storvsc_on_io_completion(str
+ * The current SCSI handling on the host side does
+ * not correctly handle:
+ * INQUIRY command with page code parameter set to 0x80
+- * MODE_SENSE command with cmd[2] == 0x1c
++ * MODE_SENSE and MODE_SENSE_10 command with cmd[2] == 0x1c
+ * MAINTENANCE_IN is not supported by HyperV FC passthrough
+ *
+ * Setup srb and scsi status so this won't be fatal.
+@@ -1154,6 +1154,7 @@ static void storvsc_on_io_completion(str
+
+ if ((stor_pkt->vm_srb.cdb[0] == INQUIRY) ||
+ (stor_pkt->vm_srb.cdb[0] == MODE_SENSE) ||
++ (stor_pkt->vm_srb.cdb[0] == MODE_SENSE_10) ||
+ (stor_pkt->vm_srb.cdb[0] == MAINTENANCE_IN &&
+ hv_dev_is_fc(device))) {
+ vstor_packet->vm_srb.scsi_status = 0;
--- /dev/null
+From 901a5f309daba412e2a30364d7ec1492fa11c32c Mon Sep 17 00:00:00 2001
+From: Abdun Nihaal <nihaal@cse.iitm.ac.in>
+Date: Tue, 23 Dec 2025 12:00:11 +0530
+Subject: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()
+
+From: Abdun Nihaal <nihaal@cse.iitm.ac.in>
+
+commit 901a5f309daba412e2a30364d7ec1492fa11c32c upstream.
+
+Memory allocated for struct vscsiblk_info in scsiback_probe() is not
+freed in scsiback_remove() leading to potential memory leaks on remove,
+as well as in the scsiback_probe() error paths. Fix that by freeing it
+in scsiback_remove().
+
+Cc: stable@vger.kernel.org
+Fixes: d9d660f6e562 ("xen-scsiback: Add Xen PV SCSI backend driver")
+Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Link: https://patch.msgid.link/20251223063012.119035-1-nihaal@cse.iitm.ac.in
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/xen/xen-scsiback.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/xen/xen-scsiback.c
++++ b/drivers/xen/xen-scsiback.c
+@@ -1262,6 +1262,7 @@ static void scsiback_remove(struct xenbu
+ gnttab_page_cache_shrink(&info->free_pages, 0);
+
+ dev_set_drvdata(&dev->dev, NULL);
++ kfree(info);
+ }
+
+ static int scsiback_probe(struct xenbus_device *dev,
comedi-dmm32at-serialize-use-of-paged-registers.patch
w1-therm-fix-off-by-one-buffer-overflow-in-alarms_store.patch
w1-fix-redundant-counter-decrement-in-w1_attach_slave_device.patch
+revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch
+input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch
+input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch
+scsi-storvsc-process-unsupported-mode_sense_10.patch
+scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch
+i2c-spacemit-drop-irqf_oneshot-flag-from-irq-request.patch
+arm-dts-microchip-sama7d65-fix-the-ranges-property-for-flx9.patch
+arm-dts-microchip-sama7d65-fix-size-cells-property-for-i2c3.patch
+arm64-dts-rockchip-remove-redundant-max-link-speed-from-nanopi-r4s.patch
+arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch
+arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch
+arm64-dts-rockchip-fix-unit-address-for-rk3588-npu-s-core1-and-core2-s-iommu.patch
+arm64-dts-rockchip-fix-headphones-widget-name-on-nanopi-m5.patch
+arm64-dts-rockchip-configure-mclk-for-analog-sound-on-nanopi-m5.patch
+slab-fix-kmalloc_nolock-context-check-for-preempt_rt.patch
+rxrpc-fix-recvmsg-unconditional-requeue.patch
+x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch
+comedi-fix-getting-range-information-for-subdevices-16-to-255.patch
+fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes.patch
+drm-drm-xe-fix-xe-userptr-in-the-absence-of-config_device_private.patch
+platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch
+platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch
+mm-hugetlb-fix-hugetlb_pmd_shared.patch
+mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch
+mm-restore-per-memcg-proactive-reclaim-with-config_numa.patch
+timekeeping-adjust-the-leap-state-for-the-correct-auxiliary-timekeeper.patch
+io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch
+iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch
--- /dev/null
+From 99a3e3a1cfc93b8fe318c0a3a5cfb01f1d4ad53c Mon Sep 17 00:00:00 2001
+From: Swaraj Gaikwad <swarajgaikwad1925@gmail.com>
+Date: Tue, 13 Jan 2026 20:36:39 +0530
+Subject: slab: fix kmalloc_nolock() context check for PREEMPT_RT
+
+From: Swaraj Gaikwad <swarajgaikwad1925@gmail.com>
+
+commit 99a3e3a1cfc93b8fe318c0a3a5cfb01f1d4ad53c upstream.
+
+On PREEMPT_RT kernels, local_lock becomes a sleeping lock. The current
+check in kmalloc_nolock() only verifies we're not in NMI or hard IRQ
+context, but misses the case where preemption is disabled.
+
+When a BPF program runs from a tracepoint with preemption disabled
+(preempt_count > 0), kmalloc_nolock() proceeds to call
+local_lock_irqsave() which attempts to acquire a sleeping lock,
+triggering:
+
+ BUG: sleeping function called from invalid context
+ in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128
+ preempt_count: 2, expected: 0
+
+Fix this by checking !preemptible() on PREEMPT_RT, which directly
+expresses the constraint that we cannot take a sleeping lock when
+preemption is disabled. This encompasses the previous checks for NMI
+and hard IRQ contexts while also catching cases where preemption is
+disabled.
+
+Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")
+Reported-by: syzbot+b1546ad4a95331b2101e@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=b1546ad4a95331b2101e
+Signed-off-by: Swaraj Gaikwad <swarajgaikwad1925@gmail.com>
+Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Acked-by: Alexei Starovoitov <ast@kernel.org>
+Acked-by: Harry Yoo <harry.yoo@oracle.com>
+Link: https://patch.msgid.link/20260113150639.48407-1-swarajgaikwad1925@gmail.co
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/slub.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/mm/slub.c
++++ b/mm/slub.c
+@@ -5692,8 +5692,12 @@ void *kmalloc_nolock_noprof(size_t size,
+ if (unlikely(!size))
+ return ZERO_SIZE_PTR;
+
+- if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq()))
+- /* kmalloc_nolock() in PREEMPT_RT is not supported from irq */
++ if (IS_ENABLED(CONFIG_PREEMPT_RT) && !preemptible())
++ /*
++ * kmalloc_nolock() in PREEMPT_RT is not supported from
++ * non-preemptible context because local_lock becomes a
++ * sleeping lock on RT.
++ */
+ return NULL;
+ retry:
+ if (unlikely(size > KMALLOC_MAX_CACHE_SIZE))
--- /dev/null
+From e806f7dde8ba28bc72a7a0898589cac79f6362ac Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>
+Date: Tue, 20 Jan 2026 07:55:55 +0100
+Subject: timekeeping: Adjust the leap state for the correct auxiliary timekeeper
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
+
+commit e806f7dde8ba28bc72a7a0898589cac79f6362ac upstream.
+
+When __do_ajdtimex() was introduced to handle adjtimex for any
+timekeeper, this reference to tk_core was not updated. When called on an
+auxiliary timekeeper, the core timekeeper would be updated incorrectly.
+
+This gets caught by the lock debugging diagnostics because the
+timekeepers sequence lock gets written to without holding its
+associated spinlock:
+
+WARNING: include/linux/seqlock.h:226 at __do_adjtimex+0x394/0x3b0, CPU#2: test/125
+aux_clock_adj (kernel/time/timekeeping.c:2979)
+__do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173)
+do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
+entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)
+
+Update the correct auxiliary timekeeper.
+
+Fixes: 775f71ebedd3 ("timekeeping: Make do_adjtimex() reusable")
+Fixes: ecf3e7030491 ("timekeeping: Provide adjtimex() for auxiliary clocks")
+Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
+Signed-off-by: Thomas Gleixner <tglx@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260120-timekeeper-auxclock-leapstate-v1-1-5b358c6b3cfd@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/time/timekeeping.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/time/timekeeping.c
++++ b/kernel/time/timekeeping.c
+@@ -2721,7 +2721,7 @@ static int __do_adjtimex(struct tk_data
+ timekeeping_update_from_shadow(tkd, TK_CLOCK_WAS_SET);
+ result->clock_set = true;
+ } else {
+- tk_update_leap_state_all(&tk_core);
++ tk_update_leap_state_all(tkd);
+ }
+
+ /* Update the multiplier immediately if frequency was set directly */
--- /dev/null
+From b505f1944535f83d369ae68813e7634d11b990d3 Mon Sep 17 00:00:00 2001
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+Date: Tue, 6 Jan 2026 18:04:26 +0000
+Subject: x86/kfence: avoid writing L1TF-vulnerable PTEs
+
+From: Andrew Cooper <andrew.cooper3@citrix.com>
+
+commit b505f1944535f83d369ae68813e7634d11b990d3 upstream.
+
+For native, the choice of PTE is fine. There's real memory backing the
+non-present PTE. However, for XenPV, Xen complains:
+
+ (XEN) d1 L1TF-vulnerable L1e 8010000018200066 - Shadowing
+
+To explain, some background on XenPV pagetables:
+
+ Xen PV guests are control their own pagetables; they choose the new
+ PTE value, and use hypercalls to make changes so Xen can audit for
+ safety.
+
+ In addition to a regular reference count, Xen also maintains a type
+ reference count. e.g. SegDesc (referenced by vGDT/vLDT), Writable
+ (referenced with _PAGE_RW) or L{1..4} (referenced by vCR3 or a lower
+ pagetable level). This is in order to prevent e.g. a page being
+ inserted into the pagetables for which the guest has a writable mapping.
+
+ For non-present mappings, all other bits become software accessible,
+ and typically contain metadata rather a real frame address. There is
+ nothing that a reference count could sensibly be tied to. As such, even
+ if Xen could recognise the address as currently safe, nothing would
+ prevent that frame from changing owner to another VM in the future.
+
+ When Xen detects a PV guest writing a L1TF-PTE, it responds by
+ activating shadow paging. This is normally only used for the live phase
+ of migration, and comes with a reasonable overhead.
+
+KFENCE only cares about getting #PF to catch wild accesses; it doesn't
+care about the value for non-present mappings. Use a fully inverted PTE,
+to avoid hitting the slow path when running under Xen.
+
+While adjusting the logic, take the opportunity to skip all actions if the
+PTE is already in the right state, half the number PVOps callouts, and
+skip TLB maintenance on a !P -> P transition which benefits non-Xen cases
+too.
+
+Link: https://lkml.kernel.org/r/20260106180426.710013-1-andrew.cooper3@citrix.com
+Fixes: 1dc0da6e9ec0 ("x86, kfence: enable KFENCE for x86")
+Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
+Tested-by: Marco Elver <elver@google.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Marco Elver <elver@google.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Jann Horn <jannh@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/kfence.h | 29 ++++++++++++++++++++++++-----
+ 1 file changed, 24 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/include/asm/kfence.h
++++ b/arch/x86/include/asm/kfence.h
+@@ -42,10 +42,34 @@ static inline bool kfence_protect_page(u
+ {
+ unsigned int level;
+ pte_t *pte = lookup_address(addr, &level);
++ pteval_t val;
+
+ if (WARN_ON(!pte || level != PG_LEVEL_4K))
+ return false;
+
++ val = pte_val(*pte);
++
++ /*
++ * protect requires making the page not-present. If the PTE is
++ * already in the right state, there's nothing to do.
++ */
++ if (protect != !!(val & _PAGE_PRESENT))
++ return true;
++
++ /*
++ * Otherwise, invert the entire PTE. This avoids writing out an
++ * L1TF-vulnerable PTE (not present, without the high address bits
++ * set).
++ */
++ set_pte(pte, __pte(~val));
++
++ /*
++ * If the page was protected (non-present) and we're making it
++ * present, there is no need to flush the TLB at all.
++ */
++ if (!protect)
++ return true;
++
+ /*
+ * We need to avoid IPIs, as we may get KFENCE allocations or faults
+ * with interrupts disabled. Therefore, the below is best-effort, and
+@@ -53,11 +77,6 @@ static inline bool kfence_protect_page(u
+ * lazy fault handling takes care of faults after the page is PRESENT.
+ */
+
+- if (protect)
+- set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT));
+- else
+- set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT));
+-
+ /*
+ * Flush this CPU's TLB, assuming whoever did the allocation/free is
+ * likely to continue running on this CPU.
projects / thirdparty / kernel / stable-queue.git / commitdiff
