* [PATCH v2 6/7] arm64: dts: qcom: hamoa: Add inline crypto for UFS
From: Harrison Vanderbyl @ 2026-05-15 5:41 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt, Herbert Xu,
davem, neil.armstrong, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, jikos, bentiss, luzmaximilian, hansg,
ilpo.jarvinen
Cc: Douglas Anderson, Jessica Zhang, linux-arm-msm, devicetree,
linux-kernel, linux-crypto, dri-devel, linux-input,
platform-driver-x86
In-Reply-To: <cover.1778822464.git.harrison.vanderbyl@gmail.com>
Add the Inline Crypto node and wire it to ufs_mem,
enabling UFS storage encryption on x1e80100 and
derivative SOCs.
This is needed to support encrypted storage on
the Microsoft Surface Pro 12-inch.
Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 051dee076416..22420d0a323a 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -3952,6 +3952,8 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
phys = <&ufs_mem_phy>;
phy-names = "ufsphy";
+ qcom,ice = <&ice>;
+
#reset-cells = <1>;
status = "disabled";
@@ -3997,6 +3999,14 @@ opp-300000000 {
};
};
+ ice: crypto@1d88000 {
+ compatible = "qcom,x1e80100-inline-crypto-engine",
+ "qcom,inline-crypto-engine";
+ reg = <0x0 0x01d88000 0x0 0x8000>;
+
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ };
+
cryptobam: dma-controller@1dc4000 {
compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
reg = <0x0 0x01dc4000 0x0 0x28000>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 7/7] arm64: dts: qcom: Add Microsoft Surface Pro 12in
From: Harrison Vanderbyl @ 2026-05-15 5:41 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt, Herbert Xu,
davem, neil.armstrong, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, jikos, bentiss, luzmaximilian, hansg,
ilpo.jarvinen
Cc: Douglas Anderson, Jessica Zhang, linux-arm-msm, devicetree,
linux-kernel, linux-crypto, dri-devel, linux-input,
platform-driver-x86
In-Reply-To: <cover.1778822464.git.harrison.vanderbyl@gmail.com>
Initial device tree for Microsoft Surface Pro 12in
Currently supported:
- UFS
- Touchscreen
- Pen
- USB 3.2 x2 (DP Alt Mode)
- Audio
- Wifi
- Bluetooth
- CDSP
- ADSP
- GPU
Not currently supported:
- Accelerometer
- Front, Back and IR cameras
- IRIS video decoder
Tested on Surface_Pro_12in_1st_Ed_with_Snapdragon_2110
Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
---
arch/arm64/boot/dts/qcom/Makefile | 2 +
.../dts/qcom/x1p42100-microsoft-sp12in.dts | 1201 +++++++++++++++++
2 files changed, 1203 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/x1p42100-microsoft-sp12in.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 4ba8e7306419..8b6d3e4b479c 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -449,3 +449,5 @@ x1p42100-lenovo-thinkbook-16-el2-dtbs := x1p42100-lenovo-thinkbook-16.dtb x1-el2
dtb-$(CONFIG_ARCH_QCOM) += x1p42100-lenovo-thinkbook-16.dtb x1p42100-lenovo-thinkbook-16-el2.dtb
x1p64100-microsoft-denali-el2-dtbs := x1p64100-microsoft-denali.dtb x1-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += x1p64100-microsoft-denali.dtb x1p64100-microsoft-denali-el2.dtb
+x1p42100-microsoft-sp12in-el2-dtbs := x1p42100-microsoft-sp12in.dtb x1-el2.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += x1p42100-microsoft-sp12in.dtb x1p42100-microsoft-sp12in-el2.dtb
diff --git a/arch/arm64/boot/dts/qcom/x1p42100-microsoft-sp12in.dts b/arch/arm64/boot/dts/qcom/x1p42100-microsoft-sp12in.dts
new file mode 100644
index 000000000000..32b8df249791
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/x1p42100-microsoft-sp12in.dts
@@ -0,0 +1,1201 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2024, Linaro Limited
+ * Copyright (c) 2025, Jens Glathe
+ * Copyright (c) 2025, Harrison Vanderbyl
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/gpio-keys.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include <dt-bindings/clock/qcom,x1e80100-tcsr.h>
+
+#include "purwa.dtsi"
+#include "hamoa-pmics.dtsi"
+
+/delete-node/ &pmc8380_6;
+/delete-node/ &pmc8380_6_thermal;
+
+/ {
+ model = "Surface Pro 12in 1st Edition";
+ compatible = "microsoft,surface-pro-12in", "qcom,x1p42100";
+ chassis-type = "tablet";
+
+ aliases {
+ serial0 = &uart2;
+ serial1 = &uart14;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pmk8550_pwm 0 5000000>;
+
+ power-supply = <&vreg_edp_3p3>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&hall_int_n_default>, <&vol_up_n_default>, <&vol_down_n_default>;
+ pinctrl-names = "default";
+
+ switch-lid {
+ gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
+ linux,input-type = <EV_SW>;
+ linux,code = <SW_LID>;
+ wakeup-source;
+ wakeup-event-action = <EV_ACT_DEASSERTED>;
+ };
+
+ key-vol-up {
+ gpios = <&pm8550_gpios 8 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ debounce-interval = <15>;
+ linux,can-disable;
+ wakeup-source;
+ };
+
+ key-vol-down {
+ gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEDOWN>;
+ debounce-interval = <15>;
+ linux,can-disable;
+ wakeup-source;
+ };
+ };
+
+ pmic-glink {
+ compatible = "qcom,x1e80100-pmic-glink",
+ "qcom,sm8550-pmic-glink",
+ "qcom,pmic-glink";
+ orientation-gpios = <&tlmm 121 GPIO_ACTIVE_HIGH>,
+ <&tlmm 123 GPIO_ACTIVE_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Right-side upper port */
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_ss0_hs_in: endpoint {
+ remote-endpoint = <&usb_1_ss0_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss0_ss_in: endpoint {
+ remote-endpoint = <&usb_1_ss0_qmpphy_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ pmic_glink_ss0_sbu: endpoint {
+ remote-endpoint = <&usb_1_ss0_sbu_mux>;
+ };
+ };
+ };
+ };
+
+ /* Right-side lower port */
+ connector@1 {
+ compatible = "usb-c-connector";
+ reg = <1>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_ss1_hs_in: endpoint {
+ remote-endpoint = <&usb_1_ss1_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss1_ss_in: endpoint {
+ remote-endpoint = <&usb_1_ss1_qmpphy_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ pmic_glink_ss1_sbu: endpoint {
+ remote-endpoint = <&usb_1_ss1_sbu_mux>;
+ };
+ };
+ };
+ };
+ };
+
+ reserved-memory {
+ linux,cma {
+ compatible = "shared-dma-pool";
+ size = <0x0 0x20000000>;
+ reusable;
+ linux,cma-default;
+ };
+ };
+
+ vreg_edp_3p3: regulator-edp-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_EDP_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 70 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&edp_reg_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ vin-supply = <&vreg_panel_en>;
+ };
+
+ vreg_panel_en: regulator-panel-en {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_PANEL_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 29 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ regulator-enable-ramp-delay = <150000>;
+
+ pinctrl-0 = <&panel_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
+ vph_pwr: regulator-vph-pwr {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+ };
+
+ vreg_wcn_0p95: regulator-wcn-0p95 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_WCN_0P95";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <950000>;
+
+ vin-supply = <&vreg_wcn_3p3>;
+ };
+
+ vreg_wcn_1p9: regulator-wcn-1p9 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_WCN_1P9";
+ regulator-min-microvolt = <1900000>;
+ regulator-max-microvolt = <1900000>;
+
+ vin-supply = <&vreg_wcn_3p3>;
+ };
+
+ vreg_wcn_3p3: regulator-wcn-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_WCN_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 214 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&wcn_sw_en>;
+ pinctrl-names = "default";
+ };
+
+ sound {
+ compatible = "qcom,x1e80100-sndcard";
+ model = "X1P42100-Microsoft-Surface-Pro-12in";
+ audio-routing = "SpkrLeft IN", "WSA WSA_SPK1 OUT",
+ "SpkrRight IN", "WSA WSA_SPK2 OUT",
+ "VA DMIC0", "vdd-micb",
+ "VA DMIC1", "vdd-micb";
+
+ va-dai-link {
+ link-name = "VA Capture";
+
+ codec {
+ sound-dai = <&lpass_vamacro 0>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai VA_CODEC_DMA_TX_0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ wsa-dai-link {
+ link-name = "WSA Playback";
+
+ codec {
+ sound-dai = <&left_spkr>, <&right_spkr>,
+ <&swr0 0>, <&lpass_wsamacro 0>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+ };
+
+ wcn7850-pmu {
+ compatible = "qcom,wcn7850-pmu";
+
+ vdd-supply = <&vreg_wcn_0p95>;
+ vddio-supply = <&vreg_l15b_1p8>;
+ vddaon-supply = <&vreg_wcn_0p95>;
+ vdddig-supply = <&vreg_wcn_0p95>;
+ vddrfa1p2-supply = <&vreg_wcn_1p9>;
+ vddrfa1p8-supply = <&vreg_wcn_1p9>;
+
+ wlan-enable-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
+ bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&wcn_wlan_bt_en>;
+ pinctrl-names = "default";
+
+ regulators {
+ vreg_pmu_rfa_cmn: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn";
+ };
+
+ vreg_pmu_aon_0p59: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p59";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p85: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p85";
+ };
+
+ vreg_pmu_btcmx_0p85: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p85";
+ };
+
+ vreg_pmu_rfa_0p8: ldo5 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo6 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p8: ldo7 {
+ regulator-name = "vreg_pmu_rfa_1p8";
+ };
+
+ vreg_pmu_pcie_0p9: ldo8 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_pcie_1p8: ldo9 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+ };
+ };
+
+ usb-1-ss0-sbu-mux {
+ compatible = "onnn,fsusb42", "gpio-sbu-mux";
+
+ enable-gpios = <&tlmm 168 GPIO_ACTIVE_LOW>;
+ select-gpios = <&tlmm 167 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&usb_1_ss0_sbu_default>;
+ pinctrl-names = "default";
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ usb_1_ss0_sbu_mux: endpoint {
+ remote-endpoint = <&pmic_glink_ss0_sbu>;
+ };
+ };
+ };
+
+ usb-1-ss1-sbu-mux {
+ compatible = "onnn,fsusb42", "gpio-sbu-mux";
+
+ enable-gpios = <&tlmm 179 GPIO_ACTIVE_LOW>;
+ select-gpios = <&tlmm 178 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&usb_1_ss1_sbu_default>;
+ pinctrl-names = "default";
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ usb_1_ss1_sbu_mux: endpoint {
+ remote-endpoint = <&pmic_glink_ss1_sbu>;
+ };
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm8550-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd-bob1-supply = <&vph_pwr>;
+ vdd-bob2-supply = <&vph_pwr>;
+ vdd-l1-l4-l10-supply = <&vreg_s4c_1p8>;
+ vdd-l2-l13-l14-supply = <&vreg_bob1>;
+ vdd-l5-l16-supply = <&vreg_bob1>;
+ vdd-l6-l7-supply = <&vreg_bob2>;
+ vdd-l8-l9-supply = <&vreg_bob1>;
+ vdd-l12-supply = <&vreg_s5j_1p2>;
+ vdd-l15-supply = <&vreg_s4c_1p8>;
+ vdd-l17-supply = <&vreg_bob2>;
+
+ vreg_bob1: bob1 {
+ regulator-name = "vreg_bob1";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_bob2: bob2 {
+ regulator-name = "vreg_bob2";
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1b_1p8: ldo1 {
+ regulator-name = "vreg_l1b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2b_3p0: ldo2 {
+ regulator-name = "vreg_l2b_3p0";
+ regulator-min-microvolt = <3072000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4b_1p8: ldo4 {
+ regulator-name = "vreg_l4b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5b_3p0: ldo5 {
+ regulator-name = "vreg_l5b_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6b_1p8: ldo6 {
+ regulator-name = "vreg_l6b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_2p8: ldo7 {
+ regulator-name = "vreg_l7b_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-always-on;
+ };
+
+ vreg_l8b_3p0: ldo8 {
+ regulator-name = "vreg_l8b_3p0";
+ regulator-min-microvolt = <3072000>;
+ regulator-max-microvolt = <3072000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_2p9: ldo9 {
+ regulator-name = "vreg_l9b_2p9";
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l10b_1p8: ldo10 {
+ regulator-name = "vreg_l10b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12b_1p2: ldo12 {
+ regulator-name = "vreg_l12b_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l13b_3p0: ldo13 {
+ regulator-name = "vreg_l13b_3p0";
+ regulator-min-microvolt = <3072000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l14b_3p0: ldo14 {
+ regulator-name = "vreg_l14b_3p0";
+ regulator-min-microvolt = <3072000>;
+ regulator-max-microvolt = <3072000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_1p8: ldo15 {
+ regulator-name = "vreg_l15b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l16b_2p9: ldo16 {
+ regulator-name = "vreg_l16b_2p9";
+ regulator-min-microvolt = <2900000>;
+ regulator-max-microvolt = <2912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_2p5: ldo17 {
+ regulator-name = "vreg_l17b_2p5";
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <2504000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vdd-l1-supply = <&vreg_s5j_1p2>;
+ vdd-s4-supply = <&vph_pwr>;
+
+ vreg_s4c_1p8: smps4 {
+ regulator-name = "vreg_s4c_1p8";
+ regulator-min-microvolt = <1856000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1c_1p2: ldo1 {
+ regulator-name = "vreg_l1c_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2c_0p8: ldo2 {
+ regulator-name = "vreg_l2c_0p8";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3c_0p8: ldo3 {
+ regulator-name = "vreg_l3c_0p8";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-2 {
+ compatible = "qcom,pmc8380-rpmh-regulators";
+ qcom,pmic-id = "d";
+
+ vdd-l3-supply = <&vreg_s4c_1p8>;
+ vdd-s1-supply = <&vph_pwr>;
+
+ vreg_l1d_0p8: ldo1 {
+ regulator-name = "vreg_l1d_0p8";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2d_0p9: ldo2 {
+ regulator-name = "vreg_l2d_0p9";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3d_1p8: ldo3 {
+ regulator-name = "vreg_l3d_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-3 {
+ compatible = "qcom,pmc8380-rpmh-regulators";
+ qcom,pmic-id = "e";
+
+ vdd-l3-supply = <&vreg_s5j_1p2>;
+
+ vreg_l2e_0p8: ldo2 {
+ regulator-name = "vreg_l2e_0p8";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <880000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3e_1p2: ldo3 {
+ regulator-name = "vreg_l3e_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-6 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+ qcom,pmic-id = "i";
+
+ vdd-l1-supply = <&vreg_s4c_1p8>;
+ vdd-l2-supply = <&vreg_s5j_1p2>;
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+
+ vreg_s1i_0p9: smps1 {
+ regulator-name = "vreg_s1i_0p9";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s2i_1p0: smps2 {
+ regulator-name = "vreg_s2i_1p0";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1i_1p8: ldo1 {
+ regulator-name = "vreg_l1i_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2i_1p2: ldo2 {
+ regulator-name = "vreg_l2i_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3i_0p8: ldo3 {
+ regulator-name = "vreg_l3i_0p8";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <880000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-7 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+ qcom,pmic-id = "j";
+
+ vdd-l2-supply = <&vreg_s5j_1p2>;
+ vdd-s5-supply = <&vph_pwr>;
+
+ vreg_s5j_1p2: smps5 {
+ regulator-name = "vreg_s5j_1p2";
+ regulator-min-microvolt = <1256000>;
+ regulator-max-microvolt = <1304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1j_0p8: ldo1 {
+ regulator-name = "vreg_l1j_0p8";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2j_1p2: ldo2 {
+ regulator-name = "vreg_l2j_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1256000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3j_0p8: ldo3 {
+ regulator-name = "vreg_l3j_0p8";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <880000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/x1p42100/Microsoft/Surface12/qcdxkmsucpurwa.mbn";
+};
+
+&i2c8 {
+ clock-frequency = <1000000>;
+
+ status = "okay";
+
+ touchscreen@16 {
+ compatible = "hid-over-i2c";
+ reg = <0x16>;
+
+ hid-descr-addr = <0x1>;
+ interrupts-extended = <&tlmm 38 IRQ_TYPE_LEVEL_LOW>;
+ wakeup-source;
+
+ vddl-supply = <&vreg_l15b_1p8>;
+
+ pinctrl-0 = <&ts0_default>;
+ pinctrl-names = "default";
+ };
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+
+ /* MAX34417 @12 */
+ /* MAX34417 @14 */
+ /* MAX34417 @16 */
+ /* MAX34417 @18 */
+ /* MAX34417 @1a */
+
+ status = "okay";
+};
+
+&i2c9 {
+ clock-frequency = <400000>;
+
+ // NFC @28, commercial devices only
+
+ status = "okay";
+};
+
+&lpass_tlmm {
+ spkr_01_sd_n_active: spkr-01-sd-n-active-state {
+ pins = "gpio12";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-low;
+ };
+};
+
+&lpass_vamacro {
+ qcom,dmic-sample-rate = <4800000>;
+
+ vdd-micb-supply = <&vreg_l1b_1p8>;
+
+ pinctrl-0 = <&dmic01_default>;
+ pinctrl-names = "default";
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_dp0 {
+ status = "okay";
+};
+
+&mdss_dp0_out {
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
+&mdss_dp1 {
+ status = "okay";
+};
+
+&mdss_dp1_out {
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
+&mdss_dp3 {
+ /delete-property/ #sound-dai-cells;
+
+ pinctrl-0 = <&edp0_hpd_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ aux-bus {
+ panel: panel {
+ compatible = "edp-panel";
+
+ backlight = <&backlight>;
+
+ power-supply = <&vreg_edp_3p3>;
+
+ port {
+ edp_panel_in: endpoint {
+ remote-endpoint = <&mdss_dp3_out>;
+ };
+ };
+ };
+ };
+
+ ports {
+ port@1 {
+ reg = <1>;
+
+ mdss_dp3_out: endpoint {
+ data-lanes = <0 1 2 3>;
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+
+ remote-endpoint = <&edp_panel_in>;
+ };
+ };
+ };
+};
+
+&mdss_dp3_phy {
+ vdda-phy-supply = <&vreg_l3j_0p8>;
+ vdda-pll-supply = <&vreg_l2j_1p2>;
+
+ status = "okay";
+};
+
+&pcie4 {
+ pinctrl-0 = <&pcie4_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie4_phy {
+ vdda-phy-supply = <&vreg_l3i_0p8>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
+ wifi@0 {
+ compatible = "pci17cb,1107";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+ vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+ vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+ };
+};
+
+&pm8550_gpios {
+ vol_up_n_default: vol-up-n-state {
+ pins = "gpio8";
+ function = "normal";
+ power-source = <1>;
+ bias-pull-up;
+ input-enable;
+ };
+
+ vol_down_n_default: vol-down-n-state {
+ pins = "gpio6";
+ function = "normal";
+ power-source = <1>;
+ bias-pull-up;
+ input-enable;
+ };
+};
+
+&pmk8550_pwm {
+ status = "okay";
+};
+
+&qupv3_0 {
+ status = "okay";
+};
+
+&qupv3_1 {
+ status = "okay";
+};
+
+&qupv3_2 {
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/x1p42100/Microsoft/Surface12/qcadsp8380.mbn",
+ "qcom/x1p42100/Microsoft/Surface12/adsp_dtbs.elf";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/x1p42100/Microsoft/Surface12/qccdsp8380.mbn",
+ "qcom/x1p42100/Microsoft/Surface12/cdsp_dtbs.elf";
+
+ status = "okay";
+};
+
+&smb2360_0 {
+ status = "okay";
+};
+
+&smb2360_0_eusb2_repeater {
+ vdd18-supply = <&vreg_l3d_1p8>;
+ vdd3-supply = <&vreg_l2b_3p0>;
+};
+
+&smb2360_1 {
+ status = "okay";
+};
+
+&smb2360_1_eusb2_repeater {
+ vdd18-supply = <&vreg_l3d_1p8>;
+ vdd3-supply = <&vreg_l14b_3p0>;
+};
+
+&swr0 {
+ pinctrl-0 = <&wsa_swr_active>, <&spkr_01_sd_n_active>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ /* WSA8845, Left speaker */
+ left_spkr: speaker@0,0 {
+ compatible = "sdw20217020400";
+ reg = <0 0>;
+ reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "SpkrLeft";
+ vdd-1p8-supply = <&vreg_l15b_1p8>;
+ vdd-io-supply = <&vreg_l12b_1p2>;
+ qcom,port-mapping = <1 2 3 7 10 13>;
+ };
+
+ /* WSA8845, Right speaker */
+ right_spkr: speaker@0,1 {
+ compatible = "sdw20217020400";
+ reg = <0 1>;
+ reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "SpkrRight";
+ vdd-1p8-supply = <&vreg_l15b_1p8>;
+ vdd-io-supply = <&vreg_l12b_1p2>;
+ qcom,port-mapping = <4 5 6 7 11 13>;
+ };
+};
+
+&tlmm {
+ gpio-reserved-ranges = <34 2>, /* Unused */
+ <44 4>; /* SPI (TPM) */
+
+ edp_reg_en: edp-reg-en-state {
+ pins = "gpio70";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ hall_int_n_default: hall-int-n-state {
+ pins = "gpio2";
+ function = "gpio";
+ bias-disable;
+ };
+
+ panel_en: panel-en-state {
+ pins = "gpio29";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ pcie4_default: pcie4-default-state {
+ clkreq-n-pins {
+ pins = "gpio147";
+ function = "pcie4_clk";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-n-pins {
+ pins = "gpio146";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wake-n-pins {
+ pins = "gpio148";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ ssam_state: ssam-state-state {
+ pins = "gpio91";
+ function = "gpio";
+ bias-disable;
+ };
+
+ ts0_default: ts0-default-state {
+ int-n-pins {
+ pins = "gpio38";
+ function = "gpio";
+ bias-disable;
+ };
+
+ reset-n-pins {
+ pins = "gpio48";
+ function = "gpio";
+ output-high;
+ drive-strength = <16>;
+ };
+ };
+
+ wcn_sw_en: wcn-sw-en-state {
+ pins = "gpio214";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wcn_wlan_bt_en: wcn-wlan-bt-en-state {
+ pins = "gpio116", "gpio117";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ usb_1_ss0_sbu_default: usb-1-ss0-sbu-state {
+ oe-n-pins {
+ pins = "gpio168";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ sel-pins {
+ pins = "gpio167";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ };
+
+ usb_1_ss1_sbu_default: usb-1-ss1-sbu-state {
+ oe-n-pins {
+ pins = "gpio179";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ sel-pins {
+ pins = "gpio178";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+ };
+};
+
+&uart2 {
+ status = "okay";
+
+ embedded-controller {
+ compatible = "microsoft,surface-sam";
+
+ interrupts-extended = <&tlmm 91 IRQ_TYPE_EDGE_RISING>;
+
+ current-speed = <4000000>;
+
+ pinctrl-0 = <&ssam_state>;
+ pinctrl-names = "default";
+ };
+};
+
+&uart14 {
+ status = "okay";
+
+ bluetooth {
+ compatible = "qcom,wcn7850-bt";
+ max-speed = <3200000>;
+
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+ };
+};
+
+&ufs_mem_hc {
+ vcc-supply = <&vreg_l17b_2p5>;
+ vcc-max-microamp = <800000>;
+ vccq-supply = <&vreg_l2i_1p2>;
+ vccq-max-microamp = <900000>;
+
+ vdd-hba-supply = <&vreg_l3j_0p8>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ status = "okay";
+
+ vdda-phy-supply = <&vreg_l3i_0p8>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+};
+
+&usb_1_ss0_hsphy {
+ vdd-supply = <&vreg_l3j_0p8>;
+ vdda12-supply = <&vreg_l2j_1p2>;
+
+ phys = <&smb2360_0_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_1_ss0_qmpphy {
+ vdda-phy-supply = <&vreg_l2j_1p2>;
+ vdda-pll-supply = <&vreg_l1j_0p8>;
+
+ status = "okay";
+};
+
+&usb_1_ss0 {
+ dr_mode = "host";
+
+ status = "okay";
+};
+
+&usb_1_ss0_dwc3_hs {
+ remote-endpoint = <&pmic_glink_ss0_hs_in>;
+};
+
+&usb_1_ss0_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss0_ss_in>;
+};
+
+&usb_1_ss1_hsphy {
+ vdd-supply = <&vreg_l3j_0p8>;
+ vdda12-supply = <&vreg_l2j_1p2>;
+
+ phys = <&smb2360_1_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_1_ss1_qmpphy {
+ vdda-phy-supply = <&vreg_l2j_1p2>;
+ vdda-pll-supply = <&vreg_l2d_0p9>;
+
+ status = "okay";
+};
+
+&usb_1_ss1 {
+ dr_mode = "host";
+
+ status = "okay";
+};
+
+&usb_1_ss1_dwc3_hs {
+ remote-endpoint = <&pmic_glink_ss1_hs_in>;
+};
+
+&usb_1_ss1_qmpphy_out {
+ remote-endpoint = <&pmic_glink_ss1_ss_in>;
+};
--
2.53.0
^ permalink raw reply related
* Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree
From: Greg KH @ 2026-05-15 5:45 UTC (permalink / raw)
To: Eric Biggers; +Cc: lukas, ignat, jarkko, yimingqian591, stable, linux-crypto
In-Reply-To: <20260513225934.GA501859@google.com>
On Wed, May 13, 2026 at 10:59:34PM +0000, Eric Biggers wrote:
> On Wed, May 13, 2026 at 10:04:47AM -0700, Eric Biggers wrote:
> > > > A couple issues. First, this email wasn't sent to the subsystem's
> > > > mailing list (linux-crypto@vger.kernel.org in this case). That greatly
> > > > reduces the number of people who are made aware that this didn't get
> > > > automatically backported.
> > >
> > > We never send out these FAILED emails to the mailing lists, as that
> > > would make just even more noise. It's always been this way, sorry.
> >
> > Yes, this has been a problem for a long time, resulting in lots of
> > missed backports including the copy.fail ones. It's time for you to fix
> > your process.
> >
> > > > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > > > conflict. (The file being changed was renamed between 6.1 and 6.6, but
> > > > 'git cherry-pick' handles that automatically.)
> > > >
> > > > I don't know what you're doing exactly that caused it to be
> > > > unnecessarily marked as FAILED. But whatever it is, it's not working,
> > > > and it is causing backports to be missed.
> > >
> > > We don't use git for cherry-picking as we have a patch queue, so renames
> > > will often times fail, like it did here. This has always been the case
> > > in the decades we have been running the stable kernels :)
> >
> > Again, this has been a problem for a long time, and it's time for you to
> > fix your process. You can still have the patch queue; just use git for
> > the actual cherry-pick.
>
> Also I should mention that your own instructions for "reproducing" the
> conflict use 'git cherry-pick':
>
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> git checkout FETCH_HEAD
> git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> # <resolve conflicts, build, test, etc.>
> git commit -s
> git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
>
> When these instructions are followed, there is no conflict. The
> "conflict" is purely because you didn't use 'git cherry-pick' yourself.
Yes, that is true, we are showing how someone else can potentially
resolve the issue. The magic is in the line:
# <resolve conflicts, build, test, etc.>
We issue FAILED emails for any number of reasons, we don't go into the
details of why it FAILED, otherwise we would have just too much
information here.
> So just start using 'git cherry-pick', and stop asking other people to
> do it for you when there are no conflicts, please.
That does not work in our workflow at all. Given the huge flow of
patches, and all the different issues/errors, the odds that a simple
rename will resolve the problem is very low. For that I can not slow
down the whole process for all submissions.
> And please start Cc'ing the mailing lists. Linux kernel development
> isn't done in private email.
This isn't a private list, we are cc:ing the people who signed off on
the patch directly. They are the "owners" of it.
> I would have backported the copy.fail
> fixes earlier, but I never received the FAILED emails (which I'm
> guessing you sent, but only in private email to other people), so I
> didn't know they weren't being backported...
Those patches were NOT marked for stable inclusion, so they did not get
a FAILED email at all. We were lucky that Sasha's sweep of the tree for
"random patches that have a Fixes: tag only that look interesting"
actually caught them for a few branches. And for those, we NEVER send a
FAILED email either, as the maintainer did not explicitly ask us for
stable inclusion, so we are not going to bother them with extra stuff.
thanks,
greg k-h
^ permalink raw reply
* Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree
From: Greg KH @ 2026-05-15 5:46 UTC (permalink / raw)
To: Eric Biggers; +Cc: lukas, ignat, jarkko, yimingqian591, stable, linux-crypto
In-Reply-To: <20260513170445.GA2128@quark>
On Wed, May 13, 2026 at 10:04:45AM -0700, Eric Biggers wrote:
> On Wed, May 13, 2026 at 12:34:38PM +0200, Greg KH wrote:
> > On Tue, May 12, 2026 at 07:51:30PM -0700, Eric Biggers wrote:
> > > [+Cc linux-crypto@vger.kernel.org]
> > >
> > > On Tue, May 12, 2026 at 04:01:23PM +0200, gregkh@linuxfoundation.org wrote:
> > > >
> > > > The patch below does not apply to the 6.1-stable tree.
> > > > If someone wants it applied there, or to any other stable or longterm
> > > > tree, then please email the backport, including the original git commit
> > > > id to <stable@vger.kernel.org>.
> > > >
> > > > To reproduce the conflict and resubmit, you may use the following commands:
> > > >
> > > > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> > > > git checkout FETCH_HEAD
> > > > git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> > > > # <resolve conflicts, build, test, etc.>
> > > > git commit -s
> > > > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> > > >
> > > > Possible dependencies:
> > >
> > > A couple issues. First, this email wasn't sent to the subsystem's
> > > mailing list (linux-crypto@vger.kernel.org in this case). That greatly
> > > reduces the number of people who are made aware that this didn't get
> > > automatically backported.
> >
> > We never send out these FAILED emails to the mailing lists, as that
> > would make just even more noise. It's always been this way, sorry.
>
> Yes, this has been a problem for a long time, resulting in lots of
> missed backports including the copy.fail ones. It's time for you to fix
> your process.
>
> > > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > > conflict. (The file being changed was renamed between 6.1 and 6.6, but
> > > 'git cherry-pick' handles that automatically.)
> > >
> > > I don't know what you're doing exactly that caused it to be
> > > unnecessarily marked as FAILED. But whatever it is, it's not working,
> > > and it is causing backports to be missed.
> >
> > We don't use git for cherry-picking as we have a patch queue, so renames
> > will often times fail, like it did here. This has always been the case
> > in the decades we have been running the stable kernels :)
>
> Again, this has been a problem for a long time, and it's time for you to
> fix your process. You can still have the patch queue; just use git for
> the actual cherry-pick.
Doesn't work well unless we turn the patch queue into a git tree at
every step of the way :(
^ permalink raw reply
* Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree
From: Eric Biggers @ 2026-05-15 6:44 UTC (permalink / raw)
To: Greg KH; +Cc: lukas, ignat, jarkko, yimingqian591, stable, linux-crypto
In-Reply-To: <2026051530-lushness-attest-bcbb@gregkh>
On Fri, May 15, 2026 at 07:45:40AM +0200, Greg KH wrote:
> On Wed, May 13, 2026 at 10:59:34PM +0000, Eric Biggers wrote:
> > On Wed, May 13, 2026 at 10:04:47AM -0700, Eric Biggers wrote:
> > > > > A couple issues. First, this email wasn't sent to the subsystem's
> > > > > mailing list (linux-crypto@vger.kernel.org in this case). That greatly
> > > > > reduces the number of people who are made aware that this didn't get
> > > > > automatically backported.
> > > >
> > > > We never send out these FAILED emails to the mailing lists, as that
> > > > would make just even more noise. It's always been this way, sorry.
> > >
> > > Yes, this has been a problem for a long time, resulting in lots of
> > > missed backports including the copy.fail ones. It's time for you to fix
> > > your process.
> > >
> > > > > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > > > > conflict. (The file being changed was renamed between 6.1 and 6.6, but
> > > > > 'git cherry-pick' handles that automatically.)
> > > > >
> > > > > I don't know what you're doing exactly that caused it to be
> > > > > unnecessarily marked as FAILED. But whatever it is, it's not working,
> > > > > and it is causing backports to be missed.
> > > >
> > > > We don't use git for cherry-picking as we have a patch queue, so renames
> > > > will often times fail, like it did here. This has always been the case
> > > > in the decades we have been running the stable kernels :)
> > >
> > > Again, this has been a problem for a long time, and it's time for you to
> > > fix your process. You can still have the patch queue; just use git for
> > > the actual cherry-pick.
> >
> > Also I should mention that your own instructions for "reproducing" the
> > conflict use 'git cherry-pick':
> >
> > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
> > git checkout FETCH_HEAD
> > git cherry-pick -x 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> > # <resolve conflicts, build, test, etc.>
> > git commit -s
> > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> >
> > When these instructions are followed, there is no conflict. The
> > "conflict" is purely because you didn't use 'git cherry-pick' yourself.
>
> Yes, that is true, we are showing how someone else can potentially
> resolve the issue. The magic is in the line:
>
> # <resolve conflicts, build, test, etc.>
>
> We issue FAILED emails for any number of reasons, we don't go into the
> details of why it FAILED, otherwise we would have just too much
> information here.
I'm not asking for details on why it's FAILED. I'm asking for commits
that cherry-pick cleanly to not be FAILED in the first place.
> > So just start using 'git cherry-pick', and stop asking other people to
> > do it for you when there are no conflicts, please.
>
> That does not work in our workflow at all. Given the huge flow of
> patches, and all the different issues/errors, the odds that a simple
> rename will resolve the problem is very low. For that I can not slow
> down the whole process for all submissions.
I've been doing stable backports for a long time, and it's happened
*many* times that something cherry-picks cleanly for me but you say
there are "conflicts". Here's an example from just 2 weeks ago where
you spent time "resolving" a "conflict" in commits that actually
cherry-picked cleanly:
https://lore.kernel.org/linux-crypto/2026043050-drainpipe-salvage-07c1@gregkh/
> > And please start Cc'ing the mailing lists. Linux kernel development
> > isn't done in private email.
>
> This isn't a private list, we are cc:ing the people who signed off on
> the patch directly. They are the "owners" of it.
And sometimes the "owners" don't do it and other people involved in the
subsystem need to do it. Or the backports are wrong and other people
involved in the system need to point that out. It's not much different
from any other kernel development; it should be done on the lists.
- Eric
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: arm: qcom: Add Microsoft Surface Pro 12in
From: Krzysztof Kozlowski @ 2026-05-15 7:03 UTC (permalink / raw)
To: Harrison Vanderbyl
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, Herbert Xu,
davem, neil.armstrong, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, jikos, bentiss, luzmaximilian, hansg,
ilpo.jarvinen, Douglas Anderson, Jessica Zhang, linux-arm-msm,
devicetree, linux-kernel, linux-crypto, dri-devel, linux-input,
platform-driver-x86
In-Reply-To: <e54aa6c1e190b0e26d58504c5ea1b05fd09d64d3.1778822464.git.harrison.vanderbyl@gmail.com>
On Fri, May 15, 2026 at 03:41:46PM +1000, Harrison Vanderbyl wrote:
> Document the compatible string for the Microsoft Surface Pro
> 12-inch, 1st Edition with Snapdragon, based on the Qualcomm X1P42100
> SoC.
>
> Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index b4943123d2e4..aaa9a129908a 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -1168,6 +1168,10 @@ properties:
> - const: microsoft,denali
> - const: qcom,x1e80100
>
> + - items:
> + - const: microsoft,surface-pro-12in
Why isn't this part of the other enum with all devices?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: crypto: Add x1e80100 inline crypto
From: Krzysztof Kozlowski @ 2026-05-15 7:04 UTC (permalink / raw)
To: Harrison Vanderbyl
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, Herbert Xu,
davem, neil.armstrong, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, jikos, bentiss, luzmaximilian, hansg,
ilpo.jarvinen, Douglas Anderson, Jessica Zhang, linux-arm-msm,
devicetree, linux-kernel, linux-crypto, dri-devel, linux-input,
platform-driver-x86
In-Reply-To: <14cd42e3d3af4b2591c9dd8dffde11ef18666751.1778822464.git.harrison.vanderbyl@gmail.com>
On Fri, May 15, 2026 at 03:41:47PM +1000, Harrison Vanderbyl wrote:
> Add compatibility string for the x1e80100/x1p42100
> inline crypto engine.
>
> Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com>
This was posted, please do not duplicate work.
https://lore.kernel.org/all/eggp3un5ufbw2mjamxmpfccq3cs2luxabpa2sucofydzoak4vg@hy7mx3rtqfko/
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/2] authencesn: Refactor in-place decryption
From: scott_gzh @ 2026-05-15 8:36 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, Scott GUO
From: Scott GUO <scottzhguo@tencent.com>
This patch set introduced the sglist_shift_{left,right} helper
and refactor the sequence number handling for authencesn
decryption. Avoiding write to the auth part of the sg list.
Scott GUO (2):
scatterlist: Introduce sglist_shift_{left,right} helpers
authencesn: Refactor inplace-decryption with sglist shift helper
crypto/authencesn.c | 38 ++++++-----------
crypto/scatterwalk.c | 79 ++++++++++++++++++++++++++++++++++++
include/crypto/scatterwalk.h | 6 +++
3 files changed, 97 insertions(+), 26 deletions(-)
--
2.41.3
^ permalink raw reply
* [PATCH 1/2] scatterlist: Introduce sglist_shift_{left,right} helpers
From: scott_gzh @ 2026-05-15 8:36 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, Scott GUO
In-Reply-To: <20260515083645.4024574-1-scott_gzh@163.com>
From: Scott GUO <scottzhguo@tencent.com>
These helpers shifts data within sglist in a chunck by
chunck manner.
Signed-off-by: GUO Zihua <scottzhguo@tencent.com>
---
crypto/scatterwalk.c | 79 ++++++++++++++++++++++++++++++++++++
include/crypto/scatterwalk.h | 6 +++
2 files changed, 85 insertions(+)
diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index be0e24843806..958ab7e20d9d 100644
--- a/crypto/scatterwalk.c
+++ b/crypto/scatterwalk.c
@@ -180,6 +180,85 @@ void memcpy_sglist(struct scatterlist *dst, struct scatterlist *src,
}
EXPORT_SYMBOL_GPL(memcpy_sglist);
+static unsigned int sglist_total_len(struct scatterlist *sg)
+{
+ unsigned int total = 0;
+
+ for (; sg; sg = sg_next(sg))
+ total += sg->length;
+ return total;
+}
+
+/**
+ * sglist_shift_left - shift a region of data left within a scatterlist
+ * @sg: scatterlist to operate on
+ * @dst_off: destination offset in bytes (must be <= @src_off)
+ * @src_off: source offset in bytes (start of the region to move)
+ * @nbytes: number of bytes to move
+ *
+ * Moves [src_off, src_off+nbytes) to [dst_off, dst_off+nbytes).
+ * Handles overlapping regions safely by copying forward (low to high).
+ */
+void sglist_shift_left(struct scatterlist *sg, unsigned int dst_off,
+ unsigned int src_off, unsigned int nbytes)
+{
+ u8 buf[16];
+
+ if (!nbytes || dst_off == src_off)
+ return;
+ if (WARN_ON_ONCE(dst_off > src_off))
+ return;
+ if (WARN_ON_ONCE(src_off + nbytes > sglist_total_len(sg)))
+ return;
+
+ while (nbytes) {
+ unsigned int chunk = min_t(unsigned int, nbytes, sizeof(buf));
+
+ memcpy_from_sglist(buf, sg, src_off, chunk);
+ memcpy_to_sglist(sg, dst_off, buf, chunk);
+ src_off += chunk;
+ dst_off += chunk;
+ nbytes -= chunk;
+ }
+}
+EXPORT_SYMBOL_GPL(sglist_shift_left);
+
+/**
+ * sglist_shift_right - shift a region of data right within a scatterlist
+ * @sg: scatterlist to operate on
+ * @dst_off: destination offset in bytes (must be >= @src_off)
+ * @src_off: source offset in bytes (start of the region to move)
+ * @nbytes: number of bytes to move
+ *
+ * Moves [src_off, src_off+nbytes) to [dst_off, dst_off+nbytes).
+ * Handles overlapping regions safely by copying backward (high to low).
+ */
+void sglist_shift_right(struct scatterlist *sg, unsigned int dst_off,
+ unsigned int src_off, unsigned int nbytes)
+{
+ unsigned int src_end = src_off + nbytes;
+ unsigned int dst_end = dst_off + nbytes;
+ u8 buf[16];
+
+ if (!nbytes || dst_off == src_off)
+ return;
+ if (WARN_ON_ONCE(dst_off < src_off))
+ return;
+ if (WARN_ON_ONCE(dst_end > sglist_total_len(sg)))
+ return;
+
+ while (nbytes) {
+ unsigned int chunk = min_t(unsigned int, nbytes, sizeof(buf));
+
+ src_end -= chunk;
+ dst_end -= chunk;
+ memcpy_from_sglist(buf, sg, src_end, chunk);
+ memcpy_to_sglist(sg, dst_end, buf, chunk);
+ nbytes -= chunk;
+ }
+}
+EXPORT_SYMBOL_GPL(sglist_shift_right);
+
struct scatterlist *scatterwalk_ffwd(struct scatterlist dst[2],
struct scatterlist *src,
unsigned int len)
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index 624fab589c2c..eed6aee5bf9c 100644
--- a/include/crypto/scatterwalk.h
+++ b/include/crypto/scatterwalk.h
@@ -249,6 +249,12 @@ static inline void scatterwalk_map_and_copy(void *buf, struct scatterlist *sg,
memcpy_from_sglist(buf, sg, start, nbytes);
}
+void sglist_shift_left(struct scatterlist *sg, unsigned int dst_off,
+ unsigned int src_off, unsigned int nbytes);
+
+void sglist_shift_right(struct scatterlist *sg, unsigned int dst_off,
+ unsigned int src_off, unsigned int nbytes);
+
struct scatterlist *scatterwalk_ffwd(struct scatterlist dst[2],
struct scatterlist *src,
unsigned int len);
--
2.41.3
^ permalink raw reply related
* [PATCH 2/2] authencesn: Refactor inplace-decryption with sglist shift helper
From: scott_gzh @ 2026-05-15 8:36 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, Scott GUO
In-Reply-To: <20260515083645.4024574-1-scott_gzh@163.com>
From: Scott GUO <scottzhguo@tencent.com>
By using shift helpers, we shift assoc data and crypt data in-place
, avoid writing the ICV tag part during decryption.
This patch also merge the code for in-place and non-in-place
decryption together once again.
Fixes: e02494114ebf ("crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption")
Signed-off-by: GUO Zihua <scottzhguo@tencent.com>
---
crypto/authencesn.c | 38 ++++++++++++--------------------------
1 file changed, 12 insertions(+), 26 deletions(-)
diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index 522df41365d8..a81003a69a18 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -210,18 +210,14 @@ static int crypto_authenc_esn_decrypt_tail(struct aead_request *req,
struct scatterlist *src = req->src;
struct scatterlist *dst = req->dst;
u8 *ihash = ohash + crypto_ahash_digestsize(auth);
- u32 tmp[2];
+ u32 tmp;
if (!authsize)
goto decrypt;
- if (src == dst) {
- /* Move high-order bits of sequence number back. */
- scatterwalk_map_and_copy(tmp, dst, 4, 4, 0);
- scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 0);
- scatterwalk_map_and_copy(tmp, dst, 0, 8, 1);
- } else
- memcpy_sglist(dst, src, assoclen);
+ memcpy_from_sglist(&tmp, dst, assoclen + cryptlen - 4, 4);
+ sglist_shift_right(dst, 8, 4, assoclen + cryptlen - 8);
+ memcpy_to_sglist(dst, 4, &tmp, 4);
if (crypto_memneq(ihash, ohash, authsize))
return -EBADMSG;
@@ -264,7 +260,7 @@ static int crypto_authenc_esn_decrypt(struct aead_request *req)
u8 *ihash = ohash + crypto_ahash_digestsize(auth);
struct scatterlist *src = req->src;
struct scatterlist *dst = req->dst;
- u32 tmp[2];
+ u32 tmp;
int err;
if (assoclen < 8)
@@ -274,24 +270,14 @@ static int crypto_authenc_esn_decrypt(struct aead_request *req)
goto tail;
cryptlen -= authsize;
- scatterwalk_map_and_copy(ihash, req->src, assoclen + cryptlen,
- authsize, 0);
+ memcpy_from_sglist(ihash, req->src, assoclen + cryptlen, authsize);
- /* Move high-order bits of sequence number to the end. */
- scatterwalk_map_and_copy(tmp, src, 0, 8, 0);
- if (src == dst) {
- scatterwalk_map_and_copy(tmp, dst, 4, 4, 1);
- scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1);
- dst = scatterwalk_ffwd(areq_ctx->dst, dst, 4);
- } else {
- scatterwalk_map_and_copy(tmp, dst, 0, 4, 1);
- scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen - 4, 4, 1);
-
- src = scatterwalk_ffwd(areq_ctx->src, src, 8);
- dst = scatterwalk_ffwd(areq_ctx->dst, dst, 4);
- memcpy_sglist(dst, src, assoclen + cryptlen - 8);
- dst = req->dst;
- }
+ memcpy_from_sglist(&tmp, src, 4, 4);
+ if (src != dst)
+ memcpy_sglist(dst, src, assoclen + cryptlen);
+
+ sglist_shift_left(dst, 4, 8, assoclen + cryptlen - 8);
+ memcpy_to_sglist(dst, assoclen + cryptlen - 4, &tmp, 4);
ahash_request_set_tfm(ahreq, auth);
ahash_request_set_crypt(ahreq, dst, ohash, assoclen + cryptlen);
--
2.41.3
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: qcom: shikra: Add TRNG support
From: Konrad Dybcio @ 2026-05-15 8:53 UTC (permalink / raw)
To: Kuldeep Singh, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Bjorn Andersson,
Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260514-shikra_rng-v1-2-4ea721a1429a@oss.qualcomm.com>
On 5/14/26 3:16 PM, Kuldeep Singh wrote:
> Add True Random Number Generator(TRNG) node for shikra.
>
> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [GIT PULL] Crypto Fixes for 7.1
From: Herbert Xu @ 2026-05-15 9:37 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
Hi Linus:
The following changes since commit 7fd2df204f342fc17d1a0bfcd474b24232fb0f32:
Linux 7.1-rc2 (2026-05-03 14:21:25 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 tags/v7.1-p4
for you to fetch changes up to d1fa83ecac31093a550534a79a33bc7f4ba8fc10:
rhashtable: Add bucket_table_free_atomic() helper (2026-05-05 16:12:07 +0800)
----------------------------------------------------------------
This push contains the following changes:
- Fix potential dead-lock in rhashtable when used by xattr.
- Avoid calling kvfree on atomic path in rhashtable.
----------------------------------------------------------------
Mikhail Gavrilov (1):
rhashtable: drop ht->mutex in rhashtable_free_and_destroy()
Uladzislau Rezki (Sony) (2):
mm/slab: Add kvfree_atomic() helper
rhashtable: Add bucket_table_free_atomic() helper
include/linux/slab.h | 3 +++
lib/rhashtable.c | 33 ++++++++++++++++++++++++++-------
mm/slub.c | 16 ++++++++++++++++
3 files changed, 45 insertions(+), 7 deletions(-)
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] dt-bindings: crypto: qcom-qce: document the Nord crypto engine
From: Herbert Xu @ 2026-05-15 10:10 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Thara Gopinath, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-crypto,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260429081021.16380-1-bartosz.golaszewski@oss.qualcomm.com>
On Wed, Apr 29, 2026 at 10:10:20AM +0200, Bartosz Golaszewski wrote:
> Document the crypto engine on the Qualcomm Nord Platform.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 +
> 1 file changed, 1 insertion(+)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3] crypto: af_alg - Remove zero-copy support from skcipher and aead
From: Herbert Xu @ 2026-05-15 10:12 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, linux-hardening, Taeyang Lee,
Brian Pak, Juno Im, Jungwon Lim, Tim Becker, Demi Marie Obenour,
Feng Ning, stable
In-Reply-To: <20260504225328.25356-1-ebiggers@kernel.org>
On Mon, May 04, 2026 at 03:53:28PM -0700, Eric Biggers wrote:
> The zero-copy support is one of the riskiest aspects of AF_ALG. It
> allows userspace to request cryptographic operations directly on
> pagecache pages of files like the 'su' binary. It also allows userspace
> to concurrently modify the memory which is being operated on, a recipe
> for TOCTOU vulnerabilities.
>
> While zero-copy support is more valuable in other areas of the kernel
> like the frequently used networking and file I/O code, it has far less
> value in AF_ALG, which is a niche UAPI. AF_ALG primarily just exists
> for backwards compatibility with a small set of userspace programs such
> as 'iwd' that haven't yet been fixed to use userspace crypto code.
>
> Originally AF_ALG was intended to be used to access hardware crypto
> accelerators. However, it isn't an efficient interface for that anyway,
> and it turned out to be rarely used in this way in practice.
>
> Thus, the risks of the zero-copy support in AF_ALG vastly outweigh its
> benefits. Let's just remove it.
>
> This commit removes it from the "skcipher" and "aead" algorithm types.
> "hash" will be handled separately.
>
> This is a soft break, not a hard break. Even after this commit, it
> still works to use splice() or sendfile() to transfer data to an AF_ALG
> request socket from a pipe or any file, respectively. What changes is
> just that the kernel now makes an internal, stable copy of the data
> before doing the crypto operation. So performance is slightly reduced,
> but the UAPI isn't broken. And, very importantly, it's much safer.
>
> Tested with libkcapi/test.sh. All its test cases still pass. I also
> verified that this would have prevented the copy.fail exploit as well.
> I also used a custom test program to verify that sendfile() still works.
>
> Fixes: 8ff590903d5f ("crypto: algif_skcipher - User-space interface for skcipher operations")
> Fixes: 400c40cf78da ("crypto: algif - add AEAD support")
> Reported-by: Taeyang Lee <0wn@theori.io>
> Link: https://copy.fail/
> Reported-by: Feng Ning <feng@innora.ai>
> Closes: https://lore.kernel.org/r/afYcc-tZFwvZZo76@ans-MacBook-Pro.local
> Reviewed-by: Demi Marie Obenour <demiobenour@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>
> v3: improved explanation
> v2: added tags
>
> Documentation/crypto/userspace-if.rst | 31 ++----------
> crypto/af_alg.c | 73 +++++++++------------------
> crypto/algif_aead.c | 8 +--
> 3 files changed, 33 insertions(+), 79 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/2] crypto: jitterentropy - drop redundant delta check in jent_entropy_init
From: Herbert Xu @ 2026-05-15 10:13 UTC (permalink / raw)
To: Thorsten Blum
Cc: Stephan Mueller, David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <20260504082848.7194-4-thorsten.blum@linux.dev>
On Mon, May 04, 2026 at 10:28:50AM +0200, Thorsten Blum wrote:
> Since start_time = end_time - delta, start_time can only equal end_time
> when delta is 0, making the explicit end_time == start_time check
> redundant. Remove it.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> crypto/jitterentropy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hwrng: Drop unused assignment to pci driver_data
From: Herbert Xu @ 2026-05-15 10:13 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Olivia Mackall, Markus Schneider-Pargmann, Andres Salomon,
Kees Cook, linux-crypto, linux-kernel, linux-geode
In-Reply-To: <20260504092015.1955605-2-u.kleine-koenig@baylibre.com>
On Mon, May 04, 2026 at 11:20:14AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Explicitly assigning 0 to driver_data in drivers not using this member
> has no benefit. Drop these and similarly depend on the compiler to
> zero-initialize the list terminator.
>
> This is a preparation for making struct pci_device_id::driver_data an
> anonymous union (which makes initializing using a list expression fail),
> but it's also a nice cleanup by itself.
>
> It was verified on x86 and arm64 that this change doesn't introduce
> changes to the compiled drivers.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> drivers/char/hw_random/amd-rng.c | 6 +++---
> drivers/char/hw_random/cavium-rng.c | 4 ++--
> drivers/char/hw_random/geode-rng.c | 4 ++--
> 3 files changed, 7 insertions(+), 7 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Define pci_device_ids using named initializers
From: Herbert Xu @ 2026-05-15 10:13 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Tom Lendacky, John Allen, David S. Miller,
Markus Schneider-Pargmann, linux-crypto, linux-kernel
In-Reply-To: <20260504152421.2147027-2-u.kleine-koenig@baylibre.com>
On Mon, May 04, 2026 at 05:24:21PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> The .driver_data member of the struct pci_device_id array was
> initialized by list expressions. This isn't easily readable if you're
> not into PCI. Using the PCI_DEVICE macro and named initializers is more
> explicit and thus easier to parse. Also skip explicit assignment of 0
> (which the compiler then takes care of) in the terminating entry.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
>
> The secret plan is to make struct pci_device_id::driver_data an
> anonymous union (similar to
> https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
> and that requires named initializers. But IMHO it's also a nice cleanup
> on its own.
>
> The anonymous union will allow changes like the following:
>
> - { PCI_VDEVICE(AMD, 0x1537), .driver_data = (kernel_ulong_t)&dev_vdata[0] },
> + { PCI_VDEVICE(AMD, 0x1537), .driver_data_ptr = &dev_vdata[0] },
>
> (together with the respective change in the code when the value is
> used). This gets rid of a bunch of casts and thus slightly improves
> type safety.
>
> Best regards
> Uwe
>
> drivers/crypto/ccp/sp-pci.c | 28 ++++++++++++++--------------
> 1 file changed, 14 insertions(+), 14 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: Drop explicit assigment of 0 in pci_device_id array
From: Herbert Xu @ 2026-05-15 10:13 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: David S. Miller, Markus Schneider-Pargmann, George Cherian,
Srujana Challa, Bharat Bhushan, Kees Cook, Thomas Fourier,
Amit Singh Tomar, linux-crypto, linux-kernel
In-Reply-To: <20260504153221.2151136-2-u.kleine-koenig@baylibre.com>
On Mon, May 04, 2026 at 05:32:21PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Assigning .driver_data for drivers that don't use this struct member is
> just noise that can better be dropped. The same applies for an explicit
> zero in the terminating entry. Drop these.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
>
> this is a preparing change for making struct pci_device_id::driver_data an
> anonymous union (similar to
> https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/).
> This requires named initializers for .driver_data, but dropping unused
> assignments is still better and a nice cleanup on its own.
>
> Best regards
> Uwe
>
> drivers/crypto/cavium/cpt/cptvf_main.c | 4 ++--
> drivers/crypto/cavium/nitrox/nitrox_main.c | 4 ++--
> drivers/crypto/marvell/octeontx/otx_cptvf_main.c | 4 ++--
> drivers/crypto/marvell/octeontx2/otx2_cptvf_main.c | 6 +++---
> 4 files changed, 9 insertions(+), 9 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 0/4] SEV re-initialization fixes
From: Herbert Xu @ 2026-05-15 10:14 UTC (permalink / raw)
To: Tycho Andersen
Cc: Tom Lendacky, John Allen, David S. Miller, Ashish Kalra,
Borislav Petkov (AMD), linux-crypto, linux-kernel, Brijesh Singh,
Michael Roth, Alexey Kardashevskiy, Dan Williams
In-Reply-To: <20260504165147.1615643-1-tycho@kernel.org>
On Mon, May 04, 2026 at 10:51:43AM -0600, Tycho Andersen wrote:
> From: "Tycho Andersen (AMD)" <tycho@kernel.org>
>
> Here is a v2 of the HSAVE_PA clearing fixes. Changes are:
>
> * return ENODEV instead EINVAL for the re-init cases
> * note ABI breakage in patch 3's commit log
> * CC stable on all the patches
>
> v1 is here: https://lore.kernel.org/all/20260427161507.32686-1-tycho@kernel.org/
>
> Thanks,
>
> Tycho
>
> Tycho Andersen (AMD) (4):
> crypto/ccp: Do not initialize SNP for SEV ioctls
> crypto/ccp: Do not initialize SNP for ioctl(SNP_COMMIT)
> crypto/ccp: Do not initialize SNP for ioctl(SNP_VLEK_LOAD)
> crypto/ccp: Do not initialize SNP for ioctl(SNP_CONFIG)
>
> drivers/crypto/ccp/sev-dev.c | 70 ++++++------------------------------
> 1 file changed, 11 insertions(+), 59 deletions(-)
>
>
> base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
> --
> 2.54.0
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: ccp: Treat zero-length cert chain as query for blob lengths
From: Herbert Xu @ 2026-05-15 10:14 UTC (permalink / raw)
To: Sean Christopherson
Cc: Ashish Kalra, Tom Lendacky, John Allen, David S. Miller,
linux-crypto, linux-kernel
In-Reply-To: <20260504222812.2339526-1-seanjc@google.com>
On Mon, May 04, 2026 at 03:28:12PM -0700, Sean Christopherson wrote:
> When handling a PDH export, treat a zero-length userspace cert chain buffer
> as a request to query the length of the relevant blobs. Failure to account
> for the zero-length buffer trips a BUG_ON() when running with
> CONFIG_DEBUG_VIRTUAL=y due to trying to get the physical address of the
> ZERO_SIZE_PTR (returned by kzalloc() on the bogus allocation).
>
> kernel BUG at arch/x86/mm/physaddr.c:28 !
> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
> CPU: 30 UID: 0 PID: 28580 Comm: syz.2.18 Kdump: loaded
> Tainted: G W 6.18.16-smp-DEV #1 NONE
> Tainted: [W]=WARN
> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025
> RIP: 0010:__phys_addr+0x16a/0x180 arch/x86/mm/physaddr.c:28
> RSP: 0018:ffffc9008329fc80 EFLAGS: 00010293
> RAX: ffffffff8179110a RBX: 0000778000000010 RCX: ffff8884e6992600
> RDX: 0000000000000000 RSI: 0000000080000010 RDI: 0000778000000010
> RBP: ffffc9008329fdf0 R08: 0000000000000dc0 R09: 00000000ffffffff
> R10: dffffc0000000000 R11: fffffbfff126d297 R12: dffffc0000000000
> R13: 1ffff92010653fc8 R14: 0000000080000010 R15: dffffc0000000000
> FS: 0000555556bec9c0(0000) GS:ffff88aa4ce1c000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fd3159e7000 CR3: 00000004fbc44000 CR4: 0000000000350ef0
> Call Trace:
> <TASK>
> [<ffffffff853d3869>] sev_ioctl_do_pdh_export+0x559/0x7a0 drivers/crypto/ccp/sev-dev.c:2308
> [<ffffffff853d1fdd>] sev_ioctl+0x2cd/0x480 drivers/crypto/ccp/sev-dev.c:2556
> [<ffffffff82549ebc>] vfs_ioctl fs/ioctl.c:52 [inline]
> [<ffffffff82549ebc>] __do_sys_ioctl fs/ioctl.c:598 [inline]
> [<ffffffff82549ebc>] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584
> [<ffffffff8630115f>] do_syscall_x64 arch/x86/entry/syscall_64.c:64 [inline]
> [<ffffffff8630115f>] do_syscall_64+0x9f/0xf40 arch/x86/entry/syscall_64.c:98
> [<ffffffff81000136>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> RIP: 0033:0x7fd3158eac39
> </TASK>
>
> Thankfully, the bug is benign outside of CONFIG_DEBUG_VIRTUAL=y as getting
> the physical address is just arithmetic, and the PSP errors out before
> trying to write to the garbage address (which it must, otherwise querying
> the blob lengths would clobber memory at pfn=0).
>
> Fixes: 76a2b524a4b1 ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command")
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
> drivers/crypto/ccp/sev-dev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: safexcel - Remove repeated plus
From: Herbert Xu @ 2026-05-15 10:18 UTC (permalink / raw)
To: Aleksander Jan Bajkowski; +Cc: atenart, davem, linux-crypto, linux-kernel
In-Reply-To: <20260504173250.751589-1-olek2@wp.pl>
On Mon, May 04, 2026 at 07:32:47PM +0200, Aleksander Jan Bajkowski wrote:
> Remove repeated "+".
>
> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
> ---
> drivers/crypto/inside-secure/safexcel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 1/4] hwrng: core - drop unnecessary forward declarations
From: Herbert Xu @ 2026-05-15 10:18 UTC (permalink / raw)
To: Thorsten Blum
Cc: Olivia Mackall, Lianjie Wang, David Laight, Jonathan McDowell,
linux-crypto, linux-kernel
In-Reply-To: <20260505094555.158017-6-thorsten.blum@linux.dev>
On Tue, May 05, 2026 at 11:45:55AM +0200, Thorsten Blum wrote:
> The forward declarations for drop_current_rng() and rng_get_data() are
> not needed - remove them.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> No changes in patch 1/4.
> ---
> drivers/char/hw_random/core.c | 4 ----
> 1 file changed, 4 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: Move MODULE_DEVICE_TABLE next to the table itself
From: Herbert Xu @ 2026-05-15 10:19 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: George Cherian, David S. Miller, Srujana Challa, Bharat Bhushan,
linux-crypto, linux-kernel
In-Reply-To: <20260505102948.191683-2-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, May 05, 2026 at 12:29:49PM +0200, Krzysztof Kozlowski wrote:
> By convention MODULE_DEVICE_TABLE() immediately follows the ID table it
> exports, because this is easier to read and verify. It also makes more
> sense since #ifdef for ACPI or OF could hide both of them.
>
> Most of the privers already have this correctly placed, so adjust
> the missing ones. No functional impact.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> drivers/crypto/cavium/cpt/cptpf_main.c | 2 +-
> drivers/crypto/cavium/cpt/cptvf_main.c | 2 +-
> drivers/crypto/marvell/octeontx/otx_cptpf_main.c | 2 +-
> drivers/crypto/marvell/octeontx/otx_cptvf_main.c | 2 +-
> drivers/crypto/marvell/octeontx2/otx2_cptpf_main.c | 2 +-
> drivers/crypto/marvell/octeontx2/otx2_cptvf_main.c | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: drbg - Rename MAX_ADDTL => MAX_ADDTL_BYTES
From: Herbert Xu @ 2026-05-15 10:20 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, Stephan Mueller, Jason A . Donenfeld,
Joachim Vandersmissen
In-Reply-To: <20260506000217.70738-1-ebiggers@kernel.org>
On Tue, May 05, 2026 at 05:02:17PM -0700, Eric Biggers wrote:
> Give this constant a name which is clearer and consistent with
> DRBG_MAX_REQUEST_BYTES. No functional change.
>
> Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> crypto/drbg.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: drbg - Remove support for "prediction resistance"
From: Herbert Xu @ 2026-05-15 10:20 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, Stephan Mueller, Jason A . Donenfeld,
Joachim Vandersmissen
In-Reply-To: <20260506000258.70807-1-ebiggers@kernel.org>
On Tue, May 05, 2026 at 05:02:58PM -0700, Eric Biggers wrote:
> "Prediction resistance", i.e. the property that the RNG's output is
> unpredictable even after a state compromise, might sound like a nice
> property to have. In reality, it's not very practical, as it requires
> that fresh entropy be pulled on every request. (The normal Linux RNG
> doesn't provide prediction resistance.) In the case of drbg.c, that
> means pulling from "jitterentropy", which is extremely slow.
>
> For some perspective, running a simple benchmark, generating 32 random
> bytes takes the following amount of time:
>
> get_random_bytes(): 90 ns
> drbg_nopr_hmac_sha512: 3707 ns
> drbg_pr_hmac_sha512: 773082 ns
>
> So at least in this case, the "pr" (prediction-resistant) DRBG is over
> 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or
> over 8000 times slower than the normal Linux RNG. While anyone using
> drbg.c has always had to tolerate that it's slower than the normal Linux
> RNG, the "pr" DRBG is clearly at another level of slowness.
>
> Thus, the following is also entirely unsurprising:
>
> - FIPS 140-3 doesn't actually require that SP800-90A DRBG
> implementations support prediction resistance. The non-prediction
> resistant DRBGs can be, and have been, certified.
>
> - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority
> than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already
> the one actually being used in practice.
>
> Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't
> actually useful, and it essentially just existed as another curiosity in
> the museum of crypto algorithms. Remove it to simplify the code.
>
> Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> crypto/drbg.c | 82 ++++++-------------
> crypto/testmgr.c | 21 +----
> crypto/testmgr.h | 202 -----------------------------------------------
> 3 files changed, 27 insertions(+), 278 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox