* [PATCH v2] pinctrl: qcom: Make important drivers default
From: Krzysztof Kozlowski @ 2026-04-28 16:35 UTC (permalink / raw)
To: Russell King, Bjorn Andersson, Konrad Dybcio, Linus Walleij,
linux-arm-kernel, linux-kernel, linux-arm-msm, linux-gpio
Cc: Krzysztof Kozlowski, Konrad Dybcio
The main SoC TLMM (Top-Level Multiplexer) pin controller drivers are
essential for booting up SoCs and are not really optional for a given
platform. Kernel should not ask users choice of drivers when that
choice is obvious and known to the developers that answer should be
'yes' or 'module'.
Switch all Qualcomm TLMM pin controller drivers to a default 'yes' for
ARCH_QCOM. This has impact:
1. arm64 defconfig: enable PINCTRL_SM7150, PINCTRL_IPQ9650 and
PINCTRL_HAWI, which were not selected before but should be, because
these platforms need them for proper boot.
2. arm qcom_defconfig: no changes.
3. arm multi_v7 defconfig: enable drivers necessary to boot ARM 32-bit
platforms, which are already enabled on qcom_defconfig.
4. COMPILE_TEST builds: enable by default all drivers for arm or arm64
builds, whenever ARCH_QCOM is selected. This has impact on build
time and feels logical, because if one selects ARCH_QCOM then
probably by default wants to build test it entirely. Kernels with
COMPILE_TEST are not supposed to be used for booting.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I did similar change for clocks and I will be continuing with
interconnect and other missing pieces.
Changes in v2:
1. Rebase on Linus W. devel branch. This should go with pinctrl, I
think.
2. Add tags.
3. Update also PINCTRL_IPQ9650.
---
arch/arm/configs/multi_v7_defconfig | 8 ----
arch/arm/configs/qcom_defconfig | 15 -------
arch/arm64/configs/defconfig | 46 ----------------------
drivers/pinctrl/qcom/Kconfig | 1 +
drivers/pinctrl/qcom/Kconfig.msm | 61 +++++++++++++++++++++++++++++
5 files changed, 62 insertions(+), 69 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index bcc9aabc1202..3847a6c17193 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -483,14 +483,6 @@ CONFIG_PINCTRL_PALMAS=y
CONFIG_PINCTRL_STMFX=y
CONFIG_PINCTRL_OWL=y
CONFIG_PINCTRL_S500=y
-CONFIG_PINCTRL_MSM=y
-CONFIG_PINCTRL_APQ8064=y
-CONFIG_PINCTRL_APQ8084=y
-CONFIG_PINCTRL_IPQ8064=y
-CONFIG_PINCTRL_MSM8660=y
-CONFIG_PINCTRL_MSM8960=y
-CONFIG_PINCTRL_MSM8X74=y
-CONFIG_PINCTRL_MSM8916=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
CONFIG_PINCTRL_RZA2=y
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 29a1dea500f0..03309b89ea4c 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -123,22 +123,7 @@ CONFIG_I2C_QUP=y
CONFIG_SPI=y
CONFIG_SPI_QUP=y
CONFIG_SPMI=y
-CONFIG_PINCTRL_MSM=y
-CONFIG_PINCTRL_APQ8064=y
-CONFIG_PINCTRL_APQ8084=y
-CONFIG_PINCTRL_IPQ4019=y
-CONFIG_PINCTRL_IPQ8064=y
-CONFIG_PINCTRL_MSM8226=y
-CONFIG_PINCTRL_MSM8660=y
-CONFIG_PINCTRL_MSM8960=y
-CONFIG_PINCTRL_MDM9607=y
-CONFIG_PINCTRL_MDM9615=y
-CONFIG_PINCTRL_MSM8X74=y
-CONFIG_PINCTRL_MSM8909=y
-CONFIG_PINCTRL_MSM8916=y
CONFIG_GPIOLIB=y
-CONFIG_PINCTRL_SDX55=y
-CONFIG_PINCTRL_SDX65=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
CONFIG_GPIO_SYSFS=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d905a0777f93..dde8b61338e3 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -651,53 +651,7 @@ CONFIG_PINCTRL_IMX8ULP=y
CONFIG_PINCTRL_IMX91=y
CONFIG_PINCTRL_IMX93=y
CONFIG_PINCTRL_IMX_SCMI=y
-CONFIG_PINCTRL_MSM=y
-CONFIG_PINCTRL_ELIZA=y
-CONFIG_PINCTRL_GLYMUR=y
-CONFIG_PINCTRL_IPQ5018=y
-CONFIG_PINCTRL_IPQ5210=y
-CONFIG_PINCTRL_IPQ5332=y
-CONFIG_PINCTRL_IPQ5424=y
-CONFIG_PINCTRL_IPQ8074=y
-CONFIG_PINCTRL_IPQ6018=y
-CONFIG_PINCTRL_IPQ9574=y
-CONFIG_PINCTRL_KAANAPALI=y
-CONFIG_PINCTRL_MSM8916=y
-CONFIG_PINCTRL_MSM8953=y
-CONFIG_PINCTRL_MSM8976=y
-CONFIG_PINCTRL_MSM8994=y
-CONFIG_PINCTRL_MSM8996=y
-CONFIG_PINCTRL_MSM8998=y
-CONFIG_PINCTRL_QCM2290=y
-CONFIG_PINCTRL_QCS404=y
-CONFIG_PINCTRL_QCS615=y
-CONFIG_PINCTRL_QCS8300=y
-CONFIG_PINCTRL_QDF2XXX=y
-CONFIG_PINCTRL_QDU1000=y
CONFIG_PINCTRL_RP1=m
-CONFIG_PINCTRL_SA8775P=y
-CONFIG_PINCTRL_SC7180=y
-CONFIG_PINCTRL_SC7280=y
-CONFIG_PINCTRL_SC8180X=y
-CONFIG_PINCTRL_SC8280XP=y
-CONFIG_PINCTRL_SDM660=y
-CONFIG_PINCTRL_SDM670=y
-CONFIG_PINCTRL_SDM845=y
-CONFIG_PINCTRL_SDX75=y
-CONFIG_PINCTRL_SM4450=y
-CONFIG_PINCTRL_SM6115=y
-CONFIG_PINCTRL_SM6125=y
-CONFIG_PINCTRL_SM6350=y
-CONFIG_PINCTRL_SM6375=y
-CONFIG_PINCTRL_MILOS=y
-CONFIG_PINCTRL_SM8150=y
-CONFIG_PINCTRL_SM8250=y
-CONFIG_PINCTRL_SM8350=y
-CONFIG_PINCTRL_SM8450=y
-CONFIG_PINCTRL_SM8550=y
-CONFIG_PINCTRL_SM8650=y
-CONFIG_PINCTRL_SM8750=y
-CONFIG_PINCTRL_X1E80100=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_PINCTRL_LPASS_LPI=m
CONFIG_PINCTRL_MILOS_LPASS_LPI=m
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 3accf0b489bb..156ba1c853ba 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -6,6 +6,7 @@ config PINCTRL_MSM
depends on GPIOLIB
# OF for pinconf_generic_dt_node_to_map_group() from GENERIC_PINCONF
depends on OF
+ default ARCH_QCOM
select QCOM_SCM
select PINMUX
select GENERIC_PINMUX_FUNCTIONS
diff --git a/drivers/pinctrl/qcom/Kconfig.msm b/drivers/pinctrl/qcom/Kconfig.msm
index b78d6410ed2e..f171ae0d891f 100644
--- a/drivers/pinctrl/qcom/Kconfig.msm
+++ b/drivers/pinctrl/qcom/Kconfig.msm
@@ -4,6 +4,7 @@ if PINCTRL_MSM
config PINCTRL_APQ8064
tristate "Qualcomm APQ8064 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm APQ8064 platform.
@@ -11,6 +12,7 @@ config PINCTRL_APQ8064
config PINCTRL_APQ8084
tristate "Qualcomm APQ8084 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm APQ8084 platform.
@@ -18,6 +20,7 @@ config PINCTRL_APQ8084
config PINCTRL_ELIZA
tristate "Qualcomm Eliza pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc Top Level Mode Multiplexer block (TLMM)
@@ -28,6 +31,7 @@ config PINCTRL_ELIZA
config PINCTRL_GLYMUR
tristate "Qualcomm Glymur pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc Top Level Mode Multiplexer block (TLMM)
@@ -38,6 +42,7 @@ config PINCTRL_GLYMUR
config PINCTRL_HAWI
tristate "Qualcomm Hawi pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc Top Level Mode Multiplexer block (TLMM)
@@ -48,6 +53,7 @@ config PINCTRL_HAWI
config PINCTRL_IPQ4019
tristate "Qualcomm IPQ4019 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm IPQ4019 platform.
@@ -55,6 +61,7 @@ config PINCTRL_IPQ4019
config PINCTRL_IPQ5018
tristate "Qualcomm IPQ5018 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -64,6 +71,7 @@ config PINCTRL_IPQ5018
config PINCTRL_IPQ8064
tristate "Qualcomm IPQ8064 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm IPQ8064 platform.
@@ -71,6 +79,7 @@ config PINCTRL_IPQ8064
config PINCTRL_IPQ5210
tristate "Qualcomm IPQ5210 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -79,6 +88,7 @@ config PINCTRL_IPQ5210
config PINCTRL_IPQ5332
tristate "Qualcomm IPQ5332 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -87,6 +97,7 @@ config PINCTRL_IPQ5332
config PINCTRL_IPQ5424
tristate "Qualcomm IPQ5424 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -96,6 +107,7 @@ config PINCTRL_IPQ5424
config PINCTRL_IPQ8074
tristate "Qualcomm IPQ8074 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -105,6 +117,7 @@ config PINCTRL_IPQ8074
config PINCTRL_IPQ6018
tristate "Qualcomm IPQ6018 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -114,6 +127,7 @@ config PINCTRL_IPQ6018
config PINCTRL_IPQ9574
tristate "Qualcomm IPQ9574 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -123,6 +137,7 @@ config PINCTRL_IPQ9574
config PINCTRL_IPQ9650
tristate "Qualcomm IPQ9650 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for
the Qualcomm Technologies Inc. TLMM block found on the
@@ -132,6 +147,7 @@ config PINCTRL_IPQ9650
config PINCTRL_KAANAPALI
tristate "Qualcomm Kaanapali pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -140,6 +156,7 @@ config PINCTRL_KAANAPALI
config PINCTRL_MSM8226
tristate "Qualcomm 8226 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -148,6 +165,7 @@ config PINCTRL_MSM8226
config PINCTRL_MSM8660
tristate "Qualcomm 8660 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 8660 platform.
@@ -155,12 +173,14 @@ config PINCTRL_MSM8660
config PINCTRL_MSM8960
tristate "Qualcomm 8960 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 8960 platform.
config PINCTRL_MDM9607
tristate "Qualcomm 9607 pin controller driver"
+ default ARCH_QCOM if ARM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 9607 platform.
@@ -168,6 +188,7 @@ config PINCTRL_MDM9607
config PINCTRL_MDM9615
tristate "Qualcomm 9615 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 9615 platform.
@@ -175,6 +196,7 @@ config PINCTRL_MDM9615
config PINCTRL_MSM8X74
tristate "Qualcomm 8x74 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 8974 platform.
@@ -182,12 +204,14 @@ config PINCTRL_MSM8X74
config PINCTRL_MSM8909
tristate "Qualcomm 8909 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found on the Qualcomm MSM8909 platform.
config PINCTRL_MSM8916
tristate "Qualcomm 8916 pin controller driver"
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found on the Qualcomm 8916 platform.
@@ -201,6 +225,7 @@ config PINCTRL_MSM8917
config PINCTRL_MSM8953
tristate "Qualcomm 8953 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found on the Qualcomm MSM8953 platform.
@@ -210,6 +235,7 @@ config PINCTRL_MSM8953
config PINCTRL_MSM8976
tristate "Qualcomm 8976 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found on the Qualcomm MSM8976 platform.
@@ -219,6 +245,7 @@ config PINCTRL_MSM8976
config PINCTRL_MSM8994
tristate "Qualcomm 8994 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 8994 platform. The
@@ -227,6 +254,7 @@ config PINCTRL_MSM8994
config PINCTRL_MSM8996
tristate "Qualcomm MSM8996 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm MSM8996 platform.
@@ -234,6 +262,7 @@ config PINCTRL_MSM8996
config PINCTRL_MSM8998
tristate "Qualcomm MSM8998 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm MSM8998 platform.
@@ -241,6 +270,7 @@ config PINCTRL_MSM8998
config PINCTRL_QCM2290
tristate "Qualcomm QCM2290 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
TLMM block found in the Qualcomm QCM2290 platform.
@@ -248,6 +278,7 @@ config PINCTRL_QCM2290
config PINCTRL_QCS404
tristate "Qualcomm QCS404 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
TLMM block found in the Qualcomm QCS404 platform.
@@ -255,6 +286,7 @@ config PINCTRL_QCS404
config PINCTRL_QCS615
tristate "Qualcomm QCS615 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
TLMM block found on the Qualcomm QCS615 platform.
@@ -262,6 +294,7 @@ config PINCTRL_QCS615
config PINCTRL_QCS8300
tristate "Qualcomm QCS8300 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux and pinconf driver for the Qualcomm
TLMM block found on the Qualcomm QCS8300 platform.
@@ -269,6 +302,7 @@ config PINCTRL_QCS8300
config PINCTRL_QDF2XXX
tristate "Qualcomm QDF2xxx pin controller driver"
depends on ACPI
+ default ARCH_QCOM if ARM64
help
This is the GPIO driver for the TLMM block found on the
Qualcomm Technologies QDF2xxx SOCs.
@@ -276,6 +310,7 @@ config PINCTRL_QDF2XXX
config PINCTRL_QDU1000
tristate "Qualcomm QDU1000/QRU1000 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf, and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -284,6 +319,7 @@ config PINCTRL_QDU1000
config PINCTRL_SA8775P
tristate "Qualcomm SA8775P pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux and pinconf driver for the Qualcomm
TLMM block found on the Qualcomm SA8775P platforms.
@@ -299,6 +335,7 @@ config PINCTRL_SAR2130P
config PINCTRL_SC7180
tristate "Qualcomm SC7180 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -307,6 +344,7 @@ config PINCTRL_SC7180
config PINCTRL_SC7280
tristate "Qualcomm SC7280 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -316,6 +354,7 @@ config PINCTRL_SC8180X
tristate "Qualcomm SC8180x pin controller driver"
depends on (OF || ACPI)
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -324,6 +363,7 @@ config PINCTRL_SC8180X
config PINCTRL_SC8280XP
tristate "Qualcomm SC8280xp pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -332,6 +372,7 @@ config PINCTRL_SC8280XP
config PINCTRL_SDM660
tristate "Qualcomm SDM660 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -340,6 +381,7 @@ config PINCTRL_SDM660
config PINCTRL_SDM670
tristate "Qualcomm SDM670 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -349,6 +391,7 @@ config PINCTRL_SDM845
tristate "Qualcomm SDM845 pin controller driver"
depends on (OF || ACPI)
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -357,6 +400,7 @@ config PINCTRL_SDM845
config PINCTRL_SDX55
tristate "Qualcomm SDX55 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -365,6 +409,7 @@ config PINCTRL_SDX55
config PINCTRL_SDX65
tristate "Qualcomm SDX65 pin controller driver"
depends on ARM || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -373,6 +418,7 @@ config PINCTRL_SDX65
config PINCTRL_SDX75
tristate "Qualcomm SDX75 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -381,6 +427,7 @@ config PINCTRL_SDX75
config PINCTRL_SM4450
tristate "Qualcomm SM4450 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -389,6 +436,7 @@ config PINCTRL_SM4450
config PINCTRL_SM6115
tristate "Qualcomm SM6115,SM4250 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -397,6 +445,7 @@ config PINCTRL_SM6115
config PINCTRL_SM6125
tristate "Qualcomm SM6125 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -405,6 +454,7 @@ config PINCTRL_SM6125
config PINCTRL_SM6350
tristate "Qualcomm SM6350 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -413,6 +463,7 @@ config PINCTRL_SM6350
config PINCTRL_SM6375
tristate "Qualcomm SM6375 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -421,6 +472,7 @@ config PINCTRL_SM6375
config PINCTRL_SM7150
tristate "Qualcomm SM7150 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -429,6 +481,7 @@ config PINCTRL_SM7150
config PINCTRL_MILOS
tristate "Qualcomm Milos pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -437,6 +490,7 @@ config PINCTRL_MILOS
config PINCTRL_SM8150
tristate "Qualcomm SM8150 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -445,6 +499,7 @@ config PINCTRL_SM8150
config PINCTRL_SM8250
tristate "Qualcomm SM8250 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -453,6 +508,7 @@ config PINCTRL_SM8250
config PINCTRL_SM8350
tristate "Qualcomm SM8350 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -461,6 +517,7 @@ config PINCTRL_SM8350
config PINCTRL_SM8450
tristate "Qualcomm SM8450 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -469,6 +526,7 @@ config PINCTRL_SM8450
config PINCTRL_SM8550
tristate "Qualcomm SM8550 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -477,6 +535,7 @@ config PINCTRL_SM8550
config PINCTRL_SM8650
tristate "Qualcomm SM8650 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -485,6 +544,7 @@ config PINCTRL_SM8650
config PINCTRL_SM8750
tristate "Qualcomm SM8750 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc TLMM block found on the Qualcomm
@@ -493,6 +553,7 @@ config PINCTRL_SM8750
config PINCTRL_X1E80100
tristate "Qualcomm X1E80100 pin controller driver"
depends on ARM64 || COMPILE_TEST
+ default ARCH_QCOM
help
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm Technologies Inc Top Level Mode Multiplexer block (TLMM)
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shenwei Wang @ 2026-04-28 16:36 UTC (permalink / raw)
To: Padhi, Beleswar, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Mathieu Poirier, Frank Li, Sascha Hauer
Cc: Shuah Khan, linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski, Andrew Lunn
In-Reply-To: <8c8cefaa-7d9e-4b73-b92f-40cb52b37f2e@ti.com>
> -----Original Message-----
> From: Padhi, Beleswar <b-padhi@ti.com>
> Sent: Tuesday, April 28, 2026 10:53 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Linus Walleij
> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shuah Khan <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>; Andrew Lunn <andrew@lunn.ch>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> >>
> >> Nothing extra in my opinion. rpmsg_create_ept() just creates a
> >> dynamic local endpoint address for Linux's usage. The firmware just
> >> has to make sure to reply to the same endpoint address where it
> >> received the message. This should already be in place IMO, because
> >> currently you are sending all messages in the default
> > Since rpmsg_create_ept creates a new local endpoint address on the
> > Linux side, how is the remote system expected to learn and use this
> > new address for communication if no additional logic is added on the remote
> side?
>
>
> Remote side learns the endpoint when it receives any message from Linux from
> the dynamic endpoint.
>
> Lets say rpmsg_create_ept() allocates a dynamic local ept of 1026. When you
> send the message from this endpoint, the standard rpmsg header would have:
>
> 85 struct rpmsg_hdr {
> 86 __rpmsg32 src; // 1026
> 87 __rpmsg32 dst; // rpdev->dst (e.g. 400)
> 88 __rpmsg32 reserved;
> 89 __rpmsg16 len;
> 90 __rpmsg16 flags;
> 91 u8 data[];
> 92 } __packed;
>
> Remote side tracks the dynamic endpoint by reading src = 1026. And while
> sending the response it fills the header as:
>
> 85 struct rpmsg_hdr {
> 86 __rpmsg32 src; // 400
> 87 __rpmsg32 dst; // 1026
> 88 __rpmsg32 reserved;
> 89 __rpmsg16 len;
> 90 __rpmsg16 flags;
> 91 u8 data[];
> 92 } __packed;
>
This explains how reply messages work in this scenario: the remote side can simply send
the response back to the source address of the incoming message.
How does this work for notification messages initiated by the remote side? Should the remote
system need to add additional logic to track the source address based on the GPIO instance?
Thanks,
Shenwei
> Note: Remote firmware can also send messages from dynamically created
> endpoints on its side, and Linux can learn those in the same manner. The dynamic
> endpoint address is passed to the callback as 'u32 src'. So you could pass on the
> 'src' from rpmsg_gpio_channel_callback() to
> rpmsg_gpio_send_message() as 'dst' and call rpmsg_sendto(port->ept, msg,
> sizeof(*msg), dst) to reply to the dynamic endpoint on firmware's side.
>
> Thanks,
> Beleswar
>
> >
> > Is this handled automatically by the rpmsg stack software, or does it
> > require explicit support on the remote system to exchange and track endpoint
> addresses?
> >
> > Thanks,
> > Shenwei
> >
> >> endpoint (rpdev->ept) which is also dynamic[1] and is created when
> >> the channel is created. And you receive the responses correctly.
> >> (Unless you have hard-coded the default ept address in the firmware)
> >>
> >> [1]:
> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> >>
> hub.co%2F&data=05%7C02%7Cshenwei.wang%40nxp.com%7C057bf7f0976749
> 5bcc3
> >>
> 108dea53e43f7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63912
> 98840
> >>
> 26686251%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI
> wLjAu
> >>
> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
> %7C
> >>
> &sdata=iSxGWEvYSyu29loP9b1R2bw8bvwR7pbzQ7D%2FGeB%2BUYE%3D&reser
> ved=0
> >>
> m%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Frpmsg%2Frpmsg_core.
> >>
> c%23L480&data=05%7C02%7Cshenwei.wang%40nxp.com%7C4ec06bf01bb14dd
> >>
> 2625708dea5387471%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
> >>
> 39129859078622527%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> >>
> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> >>
> 3D%7C0%7C%7C%7C&sdata=OUmjqOdWqiXSTjPDv1TUvrjKP1YTx9ji44SdGlIR2n
> >> Q%3D&reserved=0
> >> (chinfo.src is RPMSG_ADDR_ANY)
> >>
> >> Thanks,
> >> Beleswar
> >>
> >>> If the remote side does not need any extra support, this would be an
> >>> excellent
> >> solution.
> >>> Thanks,
> >>> Shenwei
> >>>
> >>>> 3. Send msgs from local ept in rpmsg_gpio_send_message() by:
> >>>> rpmsg_send(port->ept, msg, sizeof(*msg));
> >>>>
> >>>> 4. Get the port info in rpmsg_gpio_channel_callback() by:
> >>>> struct rpmsg_gpio_port *port = priv;
> >>>>
> >>>> Which also eliminates the need for struct rpdev_drvdata as you can
> >>>> just do
> >>>> rpmsg_get_rproc_node_name(rpdev) from rpmsg_gpiochip_register().
> >>>>
^ permalink raw reply
* Re: [PATCH 06/43] KVM: arm64: gic-v5: Add VPE doorbell domain
From: Marc Zyngier @ 2026-04-28 16:40 UTC (permalink / raw)
To: Sascha Bischoff
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, nd, oliver.upton@linux.dev, Joey Gouly,
Suzuki Poulose, yuzenghui@huawei.com, peter.maydell@linaro.org,
lpieralisi@kernel.org, Timothy Hayes
In-Reply-To: <20260427160547.3129448-7-sascha.bischoff@arm.com>
On Mon, 27 Apr 2026 17:08:05 +0100,
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
>
> GICv5 supports two types of doorbell - VPE doorbells and VM
> doorbells. In KVM we only support Targeted interrupts, and do not
> support 1ofN target selection. This means that we only implement VPE
> doorbells. These doorbells are implemented as host LPIs which are
> generated when a non-resident VPE has a pending interrupt of
> sufficient priority and the doorbell has been requested as part of
> making the VPE non-resident.
This is mostly a repeat of the architecture spec. I don't think we
need to paraphrase it.
>
> VPE doorbells allow KVM to wake VPEs (so, vcpus) as soon as the
> hardware determines that sufficient conditions for the interrupt to be
> signalled have been met. This simplifies the wake-up path for vcpus
> with GICv5 for LPIs and SPIs. NOTE: PPI pending state must still be
> checked explicitly as the IRS never sees them.
Drop the note, it serves no purpose here.
>
> This change introduces support for the vgic_v5 doorbell domain. One
> doorbell domain is created per GICv5 VM, and all VPEs have their own
> doorbell within this domain. When the doorbell fires, this is tracked
> (in gicv5_vpe.db_fired) and the corresponding vcpu is kicked.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> ---
> arch/arm64/kvm/vgic/vgic-init.c | 5 +-
> arch/arm64/kvm/vgic/vgic-v5.c | 143 +++++++++++++++++++++++++++++
> arch/arm64/kvm/vgic/vgic.h | 1 +
> include/kvm/arm_vgic.h | 6 ++
> include/linux/irqchip/arm-gic-v5.h | 2 +
> 5 files changed, 156 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
> index 907057881b26a..984908a271c8d 100644
> --- a/arch/arm64/kvm/vgic/vgic-init.c
> +++ b/arch/arm64/kvm/vgic/vgic-init.c
> @@ -500,8 +500,11 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm)
> dist->vgic_cpu_base = VGIC_ADDR_UNDEF;
> }
>
> - if (vgic_supports_direct_irqs(kvm))
> + if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3 &&
> + vgic_supports_direct_irqs(kvm))
> vgic_v4_teardown(kvm);
> + else if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V5)
> + vgic_v5_teardown(kvm);
nit: switch/case instead?
>
> xa_destroy(&dist->lpi_xa);
> }
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index fd3d6299a2baa..4e0d52b309628 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -7,6 +7,7 @@
>
> #include <linux/bitops.h>
> #include <linux/irqchip/arm-vgic-info.h>
> +#include <linux/irqdomain.h>
>
> #include "vgic.h"
> #include "vgic-v5-tables.h"
> @@ -162,6 +163,138 @@ int vgic_v5_probe(const struct gic_kvm_info *info)
> return 0;
> }
>
> +/*
> + * This set of irq_chip functions is specific for doorbells.
> + */
> +static struct irq_chip vgic_v5_db_irq_chip = {
const?
> + .name = "GICv5-DB",
> + .irq_mask = irq_chip_mask_parent,
> + .irq_unmask = irq_chip_unmask_parent,
> + .irq_eoi = irq_chip_eoi_parent,
> + .irq_set_affinity = irq_chip_set_affinity_parent,
> + .irq_get_irqchip_state = irq_chip_get_parent_state,
> + .irq_set_irqchip_state = irq_chip_set_parent_state,
> + .flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_SKIP_SET_WAKE |
> + IRQCHIP_MASK_ON_SUSPEND,
> +};
> +
> +static int vgic_v5_irq_db_domain_map(struct irq_domain *d, unsigned int virq,
> + u16 vpe_id)
> +{
> + int ret;
> + u32 lpi;
> + irq_hw_number_t hwirq;
> + struct irq_chip *chip = &vgic_v5_db_irq_chip;
> + struct irq_data *irqd = irq_desc_get_irq_data(irq_to_desc(virq));
> +
> + /*
> + * For the DB domain, we don't use the same hwirq as for LPIs.
> + */
> + hwirq = vpe_id;
> +
> + ret = gicv5_alloc_lpi();
NAK. Allocating LPIs is the task of the underlying domain that manages
LPIs, and absolutely not the vgic code.
> + if (ret < 0)
> + return ret;
> + lpi = ret;
> +
> + ret = irq_domain_alloc_irqs_parent(d, virq, 1, &lpi);
Why? I'd expect to see an irq_domain_alloc_irqs() for the whole VM,
and be done with it.
The whole allocation/freeing of LPIs is upside down. You really should
not have to do this, and I'd strongly suggest you align the way the
doorbell domain is constructed with the way GICv4 does it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3 10/11] drm: zynqmp_dp: switch to of_drm_get_bridge_by_endpoint()
From: Luca Ceresoli @ 2026-04-28 16:53 UTC (permalink / raw)
To: Biju Das, Andrzej Hajda, Neil Armstrong, Robert Foss,
laurent.pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Xinliang Liu,
Sumit Semwal, Yongqin Liu, John Stultz, tomi.valkeinen,
Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <TY3PR01MB113469B7764079DD361E3FE8D86372@TY3PR01MB11346.jpnprd01.prod.outlook.com>
On Tue Apr 28, 2026 at 5:37 PM CEST, Biju Das wrote:
>> @@ -2461,10 +2459,15 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub)
>> * Acquire the next bridge in the chain. Ignore errors caused by port@5
>> * not being connected for backward-compatibility with older DTs.
>> */
>> - ret = drm_of_find_panel_or_bridge(dp->dev->of_node, 5, 0, NULL,
>> - &dp->next_bridge);
>> - if (ret < 0 && ret != -ENODEV)
>> - goto err_reset;
>> + dp->bridge.next_bridge = of_drm_get_bridge_by_endpoint(dp->dev->of_node, 5, 0);
>> + if (IS_ERR(dp->bridge.next_bridge)) {
>> + if (PTR_ERR(dp->bridge.next_bridge) == -ENODEV) {
>> + dp->bridge.next_bridge;
>
>
> A warning on this patch
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c: In function ‘zynqmp_dp_probe’:
> drivers/gpu/drm/xlnx/zynqmp_dp.c:2465:35: warning: statement with no effect [-Wunused-value]
> 2465 | dp->bridge.next_bridge;
> | ~~~~~~~~~~^~~~~~~~~~~~
Ouch. Guess I should have pondered a bit longer before sending, will do
before v4...
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 6/8] KVM: arm64: Propagate stage-2 map failure on host->guest donation
From: Will Deacon @ 2026-04-28 16:57 UTC (permalink / raw)
To: Fuad Tabba
Cc: maz, oliver.upton, james.morse, suzuki.poulose, yuzenghui,
qperret, vdonnefort, catalin.marinas, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <CA+EHjTyTy2qLm=CbOOYR6rmjg5tH38PifAV+qAhbZxidY5szxQ@mail.gmail.com>
On Tue, Apr 28, 2026 at 03:36:43PM +0100, Fuad Tabba wrote:
> On Tue, 28 Apr 2026 at 14:45, Will Deacon <will@kernel.org> wrote:
> V2 will drop two patches (in addition to the HCR_EL2 one), and will be
> as follows:
>
> 1. host->guest share and host->guest donate (kept, rewritten): add a
> memcache-sufficiency check during the existing pre-check pass
> (option 1) and return -ENOMEM cleanly without touching any state.
> Restore the WARN_ON() on the subsequent kvm_pgtable_stage2_map() —
> with the topup precheck it asserts an established invariant rather
> than ignoring a reachable error.
>
> For the single-page donate, "topped up" is
> KVM_PGTABLE_LAST_LEVEL - vm->pgt.start_level (mirroring host EL1's
> kvm_mmu_cache_min_pages). For multi-page share I plan to use the
> conservative nr_pages * (LAST_LEVEL - start_level) bound and flag it
> as conservative in the commit message; happy to compute a tighter
> alignment-aware bound if you'd prefer.
For now, I think we should just check against kvm_mmu_cache_min_pages()
because that's what the host is using.
Cheers,
Will
^ permalink raw reply
* Re: [PATCH 6/8] KVM: arm64: Propagate stage-2 map failure on host->guest donation
From: Fuad Tabba @ 2026-04-28 17:03 UTC (permalink / raw)
To: Will Deacon
Cc: maz, oliver.upton, james.morse, suzuki.poulose, yuzenghui,
qperret, vdonnefort, catalin.marinas, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <afDnCiQNJrP7UI2m@willie-the-truck>
On Tue, 28 Apr 2026 at 17:57, Will Deacon <will@kernel.org> wrote:
>
> On Tue, Apr 28, 2026 at 03:36:43PM +0100, Fuad Tabba wrote:
> > On Tue, 28 Apr 2026 at 14:45, Will Deacon <will@kernel.org> wrote:
> > V2 will drop two patches (in addition to the HCR_EL2 one), and will be
> > as follows:
> >
> > 1. host->guest share and host->guest donate (kept, rewritten): add a
> > memcache-sufficiency check during the existing pre-check pass
> > (option 1) and return -ENOMEM cleanly without touching any state.
> > Restore the WARN_ON() on the subsequent kvm_pgtable_stage2_map() —
> > with the topup precheck it asserts an established invariant rather
> > than ignoring a reachable error.
> >
> > For the single-page donate, "topped up" is
> > KVM_PGTABLE_LAST_LEVEL - vm->pgt.start_level (mirroring host EL1's
> > kvm_mmu_cache_min_pages). For multi-page share I plan to use the
> > conservative nr_pages * (LAST_LEVEL - start_level) bound and flag it
> > as conservative in the commit message; happy to compute a tighter
> > alignment-aware bound if you'd prefer.
>
> For now, I think we should just check against kvm_mmu_cache_min_pages()
> because that's what the host is using.
Ack,
/fuad
>
> Cheers,
>
> Will
^ permalink raw reply
* Re: [PATCH v2] iio: adc: meson-saradc: fix calibration buffer leak on error
From: Jonathan Cameron @ 2026-04-28 17:05 UTC (permalink / raw)
To: Felix Gu
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rosen Penev,
linux-iio, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260427-meson_saradc-v2-1-8981c56fd05e@gmail.com>
On Mon, 27 Apr 2026 19:26:31 +0800
Felix Gu <ustc.gu@gmail.com> wrote:
> meson_sar_adc_temp_sensor_init() allocates a buffer with
> nvmem_cell_read(), but the old code leaked it if
> syscon_regmap_lookup_by_phandle() failed.
>
> Fix this by adding missing kfree(buf).
>
> Fixes: d6f2eac64403 ("iio: adc: meson: no devm for nvmem_cell_get")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Applied. Thanks
J
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: mediatek,mt6351: convert to DT schema
From: Manish Baing @ 2026-04-28 17:16 UTC (permalink / raw)
To: lgirdwood, broonie
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
kaichieh.chuang, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, manishbaing2789,
Krzysztof Kozlowski
Convert MediaTek MT6351 Audio CODEC bindings from text format to
YAML schema to enable dtbs_check validation.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
- Switch to unevaluatedProperties.
- Add missing #sound-dai-cells to properties and required list.
- Update example to include #sound-dai-cells.
.../bindings/sound/mediatek,mt6351-sound.yaml | 37 +++++++++++++++++++
.../devicetree/bindings/sound/mt6351.txt | 16 --------
2 files changed, 37 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt6351-sound.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/mt6351.txt
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt6351-sound.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt6351-sound.yaml
new file mode 100644
index 000000000000..b422e238b512
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt6351-sound.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt6351-sound.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6351 Audio CODEC
+
+maintainers:
+ - KaiChieh Chuang <kaichieh.chuang@mediatek.com>
+
+description:
+ MT6351 Audio CODEC is a part of the MediaTek MT6351 PMIC.
+ It communicates with the SoC through the MediaTek PMIC wrapper(pwrap).
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: mediatek,mt6351-sound
+
+ "#sound-dai-cells":
+ const: 0
+
+required:
+ - compatible
+ - "#sound-dai-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt6351-sound";
+ #sound-dai-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/mt6351.txt b/Documentation/devicetree/bindings/sound/mt6351.txt
deleted file mode 100644
index 7fb2cb99245e..000000000000
--- a/Documentation/devicetree/bindings/sound/mt6351.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Mediatek MT6351 Audio Codec
-
-The communication between MT6351 and SoC is through Mediatek PMIC wrapper.
-For more detail, please visit Mediatek PMIC wrapper documentation.
-
-Must be a child node of PMIC wrapper.
-
-Required properties:
-
-- compatible : "mediatek,mt6351-sound".
-
-Example:
-
-mt6351_snd {
- compatible = "mediatek,mt6351-sound";
-};
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] interconnect: qcom: Some defconfig/defaults cleanups and improvements
From: Krzysztof Kozlowski @ 2026-04-28 17:32 UTC (permalink / raw)
To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
Similarly to clocks and pinctrl, interconnects should not be a user
visible choice.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (3):
interconnect: qcom: Fix indentation
interconnect: qcom: Restrict drivers per ARM/ARM64
interconnect: qcom: Make important drivers default
arch/arm/configs/qcom_defconfig | 3 --
arch/arm64/configs/defconfig | 31 ------------
drivers/interconnect/qcom/Kconfig | 103 ++++++++++++++++++++++++++++++++------
3 files changed, 89 insertions(+), 48 deletions(-)
---
base-commit: 9974969c14031a097d6b45bcb7a06bb4aa525c40
change-id: 20260428-interconnect-qcom-clean-arm64-aecdaa1e531b
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/3] interconnect: qcom: Fix indentation
From: Krzysztof Kozlowski @ 2026-04-28 17:32 UTC (permalink / raw)
To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260428-interconnect-qcom-clean-arm64-v1-0-e6bc3f7832db@oss.qualcomm.com>
KConfig entries should be indented starting with one tab, so replace
spaces with it.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/interconnect/qcom/Kconfig | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig
index 786b4eda44b4..871663bfd094 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -9,22 +9,22 @@ config INTERCONNECT_QCOM_BCM_VOTER
tristate
config INTERCONNECT_QCOM_ELIZA
- tristate "Qualcomm Eliza interconnect driver"
- depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
- select INTERCONNECT_QCOM_RPMH
- select INTERCONNECT_QCOM_BCM_VOTER
- help
- This is a driver for the Qualcomm Network-on-Chip on Eliza-based
- platforms.
+ tristate "Qualcomm Eliza interconnect driver"
+ depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ select INTERCONNECT_QCOM_RPMH
+ select INTERCONNECT_QCOM_BCM_VOTER
+ help
+ This is a driver for the Qualcomm Network-on-Chip on Eliza-based
+ platforms.
config INTERCONNECT_QCOM_GLYMUR
- tristate "Qualcomm Glymur interconnect driver"
- depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
- select INTERCONNECT_QCOM_RPMH
- select INTERCONNECT_QCOM_BCM_VOTER
- help
- This is a driver for the Qualcomm Network-on-Chip on glymur-based
- platforms.
+ tristate "Qualcomm Glymur interconnect driver"
+ depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ select INTERCONNECT_QCOM_RPMH
+ select INTERCONNECT_QCOM_BCM_VOTER
+ help
+ This is a driver for the Qualcomm Network-on-Chip on glymur-based
+ platforms.
config INTERCONNECT_QCOM_KAANAPALI
tristate "Qualcomm Kaanapali interconnect driver"
--
2.51.0
^ permalink raw reply related
* [PATCH 2/3] interconnect: qcom: Restrict drivers per ARM/ARM64
From: Krzysztof Kozlowski @ 2026-04-28 17:32 UTC (permalink / raw)
To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260428-interconnect-qcom-clean-arm64-v1-0-e6bc3f7832db@oss.qualcomm.com>
There is no point to allow selecting core SoC drivers like interconnects
for Qualcomm ARMv7 SoCs when building ARM64 kernel, and vice versa.
This makes kernel configuration more difficult as many do not remember
the Qualcomm SoCs model names/numbers and their properties like
architecture. No features should be lost because:
1. There won't be a single image for ARMv7 and ARMv8/9 SoCs.
2. Newer ARMv8/9 SoCs won't be running in arm32 emulation mode.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/interconnect/qcom/Kconfig | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig
index 871663bfd094..b2c4272ae48f 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -11,6 +11,7 @@ config INTERCONNECT_QCOM_BCM_VOTER
config INTERCONNECT_QCOM_ELIZA
tristate "Qualcomm Eliza interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -20,6 +21,7 @@ config INTERCONNECT_QCOM_ELIZA
config INTERCONNECT_QCOM_GLYMUR
tristate "Qualcomm Glymur interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -29,6 +31,7 @@ config INTERCONNECT_QCOM_GLYMUR
config INTERCONNECT_QCOM_KAANAPALI
tristate "Qualcomm Kaanapali interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -39,6 +42,7 @@ config INTERCONNECT_QCOM_MSM8909
tristate "Qualcomm MSM8909 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on msm8909-based
@@ -75,6 +79,7 @@ config INTERCONNECT_QCOM_MSM8953
tristate "Qualcomm MSM8953 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on msm8953-based
@@ -84,6 +89,7 @@ config INTERCONNECT_QCOM_MSM8974
tristate "Qualcomm MSM8974 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on msm8974-based
@@ -93,6 +99,7 @@ config INTERCONNECT_QCOM_MSM8976
tristate "Qualcomm MSM8976 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on msm8976-based
@@ -102,6 +109,7 @@ config INTERCONNECT_QCOM_MSM8996
tristate "Qualcomm MSM8996 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on msm8996-based
@@ -110,6 +118,7 @@ config INTERCONNECT_QCOM_MSM8996
config INTERCONNECT_QCOM_OSM_L3
tristate "Qualcomm OSM L3 interconnect driver"
depends on INTERCONNECT_QCOM || COMPILE_TEST
+ depends on ARM64 || COMPILE_TEST
help
Say y here to support the Operating State Manager (OSM) interconnect
driver which controls the scaling of L3 caches on Qualcomm SoCs.
@@ -118,6 +127,7 @@ config INTERCONNECT_QCOM_QCM2290
tristate "Qualcomm QCM2290 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on qcm2290-based
@@ -127,6 +137,7 @@ config INTERCONNECT_QCOM_QCS404
tristate "Qualcomm QCS404 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on qcs404-based
@@ -135,6 +146,7 @@ config INTERCONNECT_QCOM_QCS404
config INTERCONNECT_QCOM_QCS615
tristate "Qualcomm QCS615 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -144,6 +156,7 @@ config INTERCONNECT_QCOM_QCS615
config INTERCONNECT_QCOM_QCS8300
tristate "Qualcomm QCS8300 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -155,6 +168,7 @@ config INTERCONNECT_QCOM_QCS8300
config INTERCONNECT_QCOM_QDU1000
tristate "Qualcomm QDU1000/QRU1000 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -178,6 +192,7 @@ config INTERCONNECT_QCOM_RPMH
config INTERCONNECT_QCOM_SA8775P
tristate "Qualcomm SA8775P interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -187,6 +202,7 @@ config INTERCONNECT_QCOM_SA8775P
config INTERCONNECT_QCOM_SAR2130P
tristate "Qualcomm SAR2130P interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -196,6 +212,7 @@ config INTERCONNECT_QCOM_SAR2130P
config INTERCONNECT_QCOM_SC7180
tristate "Qualcomm SC7180 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -205,6 +222,7 @@ config INTERCONNECT_QCOM_SC7180
config INTERCONNECT_QCOM_SC7280
tristate "Qualcomm SC7280 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -214,6 +232,7 @@ config INTERCONNECT_QCOM_SC7280
config INTERCONNECT_QCOM_SC8180X
tristate "Qualcomm SC8180X interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -223,6 +242,7 @@ config INTERCONNECT_QCOM_SC8180X
config INTERCONNECT_QCOM_SC8280XP
tristate "Qualcomm SC8280XP interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -232,6 +252,7 @@ config INTERCONNECT_QCOM_SC8280XP
config INTERCONNECT_QCOM_SDM660
tristate "Qualcomm SDM660 interconnect driver"
depends on INTERCONNECT_QCOM
+ depends on ARM64 || COMPILE_TEST
depends on QCOM_SMD_RPM
select INTERCONNECT_QCOM_SMD_RPM
help
@@ -241,6 +262,7 @@ config INTERCONNECT_QCOM_SDM660
config INTERCONNECT_QCOM_SDM670
tristate "Qualcomm SDM670 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -250,6 +272,7 @@ config INTERCONNECT_QCOM_SDM670
config INTERCONNECT_QCOM_SDM845
tristate "Qualcomm SDM845 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -259,6 +282,7 @@ config INTERCONNECT_QCOM_SDM845
config INTERCONNECT_QCOM_SDX55
tristate "Qualcomm SDX55 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -268,6 +292,7 @@ config INTERCONNECT_QCOM_SDX55
config INTERCONNECT_QCOM_SDX65
tristate "Qualcomm SDX65 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -277,6 +302,7 @@ config INTERCONNECT_QCOM_SDX65
config INTERCONNECT_QCOM_SDX75
tristate "Qualcomm SDX75 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -287,6 +313,7 @@ config INTERCONNECT_QCOM_SM6115
tristate "Qualcomm SM6115 interconnect driver"
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on sm6115-based
@@ -295,6 +322,7 @@ config INTERCONNECT_QCOM_SM6115
config INTERCONNECT_QCOM_SM6350
tristate "Qualcomm SM6350 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -304,6 +332,7 @@ config INTERCONNECT_QCOM_SM6350
config INTERCONNECT_QCOM_SM7150
tristate "Qualcomm SM7150 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -313,6 +342,7 @@ config INTERCONNECT_QCOM_SM7150
config INTERCONNECT_QCOM_MILOS
tristate "Qualcomm Milos interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -322,6 +352,7 @@ config INTERCONNECT_QCOM_MILOS
config INTERCONNECT_QCOM_SM8150
tristate "Qualcomm SM8150 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -331,6 +362,7 @@ config INTERCONNECT_QCOM_SM8150
config INTERCONNECT_QCOM_SM8250
tristate "Qualcomm SM8250 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -340,6 +372,7 @@ config INTERCONNECT_QCOM_SM8250
config INTERCONNECT_QCOM_SM8350
tristate "Qualcomm SM8350 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -349,6 +382,7 @@ config INTERCONNECT_QCOM_SM8350
config INTERCONNECT_QCOM_SM8450
tristate "Qualcomm SM8450 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -358,6 +392,7 @@ config INTERCONNECT_QCOM_SM8450
config INTERCONNECT_QCOM_SM8550
tristate "Qualcomm SM8550 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -367,6 +402,7 @@ config INTERCONNECT_QCOM_SM8550
config INTERCONNECT_QCOM_SM8650
tristate "Qualcomm SM8650 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -376,6 +412,7 @@ config INTERCONNECT_QCOM_SM8650
config INTERCONNECT_QCOM_SM8750
tristate "Qualcomm SM8750 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
@@ -385,6 +422,7 @@ config INTERCONNECT_QCOM_SM8750
config INTERCONNECT_QCOM_X1E80100
tristate "Qualcomm X1E80100 interconnect driver"
depends on INTERCONNECT_QCOM_RPMH_POSSIBLE
+ depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
help
--
2.51.0
^ permalink raw reply related
* [PATCH 3/3] interconnect: qcom: Make important drivers default
From: Krzysztof Kozlowski @ 2026-04-28 17:32 UTC (permalink / raw)
To: Georgi Djakov, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-pm, linux-kernel, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260428-interconnect-qcom-clean-arm64-v1-0-e6bc3f7832db@oss.qualcomm.com>
The interconnect drivers for Qualcomm SoC Network-on-Chip are covering a
basic or fundamental SoC feature: bandwidth management between internal
SoC blocks. SoC can boot without these, but power management or
performance will be affected. These drivers do not represent any sort
of buses visible to the board designers/configurators, thus they should
be always enabled, regardless how SoC is used in the final board.
Kernel configuration should not ask users choice of drivers when that
choice is obvious and known to the developers that answer should be
'yes' or 'module'.
Switch all almost Qualcomm interconnect drivers to a default 'yes' for
ARCH_QCOM. This has impact:
1. arm64 defconfig: enable as built-in INTERCONNECT_QCOM_SDM660,
INTERCONNECT_QCOM_SDM670, INTERCONNECT_QCOM_SM7150 and
INTERCONNECT_QCOM_SAR2130P, which were not selected before but should
be, because these platforms need them anyway.
2. arm qcom_defconfig: no changes.
3. arm multi_v7 defconfig: enable as modules drivers necessary to boot
ARM 32-bit platforms, which are already enabled on qcom_defconfig:
QCOM_RPMH, INTERCONNECT_QCOM_BCM_VOTER, INTERCONNECT_QCOM_MSM8974 and
INTERCONNECT_QCOM_SDX55.
4. COMPILE_TEST builds: enable by default all drivers for arm or arm64
builds, whenever ARCH_QCOM is selected. This has impact on build
time and feels logical, because if one selects ARCH_QCOM then
probably by default wants to build test it entirely. Kernels with
COMPILE_TEST are not supposed to be used for booting.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I propose the change to go via interconnect tree. It might conflict
around defconfigs, though.
---
arch/arm/configs/qcom_defconfig | 3 ---
arch/arm64/configs/defconfig | 31 -------------------------------
drivers/interconnect/qcom/Kconfig | 37 +++++++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+), 34 deletions(-)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 29a1dea500f0..21d225836393 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -286,9 +286,6 @@ CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2=y
CONFIG_PHY_QCOM_USB_HSIC=y
CONFIG_NVMEM_QCOM_QFPROM=y
CONFIG_INTERCONNECT=y
-CONFIG_INTERCONNECT_QCOM=y
-CONFIG_INTERCONNECT_QCOM_MSM8974=m
-CONFIG_INTERCONNECT_QCOM_SDX55=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT4_FS=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index dd1ac01ee29b..3134e11da028 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1874,37 +1874,6 @@ CONFIG_INTERCONNECT_IMX8MM=m
CONFIG_INTERCONNECT_IMX8MN=m
CONFIG_INTERCONNECT_IMX8MQ=m
CONFIG_INTERCONNECT_IMX8MP=y
-CONFIG_INTERCONNECT_QCOM=y
-CONFIG_INTERCONNECT_QCOM_ELIZA=y
-CONFIG_INTERCONNECT_QCOM_GLYMUR=y
-CONFIG_INTERCONNECT_QCOM_KAANAPALI=y
-CONFIG_INTERCONNECT_QCOM_MSM8916=m
-CONFIG_INTERCONNECT_QCOM_MSM8953=y
-CONFIG_INTERCONNECT_QCOM_MSM8996=y
-CONFIG_INTERCONNECT_QCOM_OSM_L3=m
-CONFIG_INTERCONNECT_QCOM_QCM2290=y
-CONFIG_INTERCONNECT_QCOM_QCS404=m
-CONFIG_INTERCONNECT_QCOM_QCS615=y
-CONFIG_INTERCONNECT_QCOM_QCS8300=y
-CONFIG_INTERCONNECT_QCOM_QDU1000=y
-CONFIG_INTERCONNECT_QCOM_SA8775P=y
-CONFIG_INTERCONNECT_QCOM_SC7180=y
-CONFIG_INTERCONNECT_QCOM_SC7280=y
-CONFIG_INTERCONNECT_QCOM_SC8180X=y
-CONFIG_INTERCONNECT_QCOM_SC8280XP=y
-CONFIG_INTERCONNECT_QCOM_SDM845=y
-CONFIG_INTERCONNECT_QCOM_SDX75=y
-CONFIG_INTERCONNECT_QCOM_SM6115=y
-CONFIG_INTERCONNECT_QCOM_SM6350=y
-CONFIG_INTERCONNECT_QCOM_MILOS=y
-CONFIG_INTERCONNECT_QCOM_SM8150=y
-CONFIG_INTERCONNECT_QCOM_SM8250=y
-CONFIG_INTERCONNECT_QCOM_SM8350=y
-CONFIG_INTERCONNECT_QCOM_SM8450=y
-CONFIG_INTERCONNECT_QCOM_SM8550=y
-CONFIG_INTERCONNECT_QCOM_SM8650=y
-CONFIG_INTERCONNECT_QCOM_SM8750=y
-CONFIG_INTERCONNECT_QCOM_X1E80100=y
CONFIG_COUNTER=m
CONFIG_TI_EQEP=m
CONFIG_RZ_MTU3_CNT=m
diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig
index b2c4272ae48f..56abd679e8be 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -2,6 +2,7 @@
config INTERCONNECT_QCOM
tristate "Qualcomm Network-on-Chip interconnect drivers"
depends on ARCH_QCOM
+ default ARCH_QCOM
help
Support for Qualcomm's Network-on-Chip interconnect hardware.
@@ -14,6 +15,7 @@ config INTERCONNECT_QCOM_ELIZA
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on Eliza-based
platforms.
@@ -24,6 +26,7 @@ config INTERCONNECT_QCOM_GLYMUR
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on glymur-based
platforms.
@@ -34,6 +37,7 @@ config INTERCONNECT_QCOM_KAANAPALI
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on kaanapali-based
platforms.
@@ -53,6 +57,7 @@ config INTERCONNECT_QCOM_MSM8916
depends on INTERCONNECT_QCOM
depends on QCOM_SMD_RPM
select INTERCONNECT_QCOM_SMD_RPM
+ default m if ARCH_QCOM && ARM64
help
This is a driver for the Qualcomm Network-on-Chip on msm8916-based
platforms.
@@ -81,6 +86,7 @@ config INTERCONNECT_QCOM_MSM8953
depends on QCOM_SMD_RPM
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on msm8953-based
platforms.
@@ -91,6 +97,7 @@ config INTERCONNECT_QCOM_MSM8974
depends on QCOM_SMD_RPM
depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default m if ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on msm8974-based
platforms.
@@ -111,6 +118,7 @@ config INTERCONNECT_QCOM_MSM8996
depends on QCOM_SMD_RPM
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on msm8996-based
platforms.
@@ -119,6 +127,7 @@ config INTERCONNECT_QCOM_OSM_L3
tristate "Qualcomm OSM L3 interconnect driver"
depends on INTERCONNECT_QCOM || COMPILE_TEST
depends on ARM64 || COMPILE_TEST
+ default m if ARCH_QCOM
help
Say y here to support the Operating State Manager (OSM) interconnect
driver which controls the scaling of L3 caches on Qualcomm SoCs.
@@ -129,6 +138,7 @@ config INTERCONNECT_QCOM_QCM2290
depends on QCOM_SMD_RPM
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on qcm2290-based
platforms.
@@ -139,6 +149,7 @@ config INTERCONNECT_QCOM_QCS404
depends on QCOM_SMD_RPM
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default m if ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on qcs404-based
platforms.
@@ -149,6 +160,7 @@ config INTERCONNECT_QCOM_QCS615
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on qcs615-based
platforms.
@@ -159,6 +171,7 @@ config INTERCONNECT_QCOM_QCS8300
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Technologies, Inc. Network-on-Chip
on QCS8300-based platforms. The interconnect provider collects and
@@ -171,6 +184,7 @@ config INTERCONNECT_QCOM_QDU1000
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on QDU1000-based
and QRU1000-based platforms.
@@ -195,6 +209,7 @@ config INTERCONNECT_QCOM_SA8775P
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sa8775p-based
platforms.
@@ -205,6 +220,7 @@ config INTERCONNECT_QCOM_SAR2130P
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SAR2130P-based
platforms.
@@ -215,6 +231,7 @@ config INTERCONNECT_QCOM_SC7180
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sc7180-based
platforms.
@@ -225,6 +242,7 @@ config INTERCONNECT_QCOM_SC7280
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sc7280-based
platforms.
@@ -235,6 +253,7 @@ config INTERCONNECT_QCOM_SC8180X
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sc8180x-based
platforms.
@@ -245,6 +264,7 @@ config INTERCONNECT_QCOM_SC8280XP
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SC8280XP-based
platforms.
@@ -255,6 +275,7 @@ config INTERCONNECT_QCOM_SDM660
depends on ARM64 || COMPILE_TEST
depends on QCOM_SMD_RPM
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sdm660-based
platforms.
@@ -265,6 +286,7 @@ config INTERCONNECT_QCOM_SDM670
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sdm670-based
platforms.
@@ -275,6 +297,7 @@ config INTERCONNECT_QCOM_SDM845
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sdm845-based
platforms.
@@ -285,6 +308,7 @@ config INTERCONNECT_QCOM_SDX55
depends on ARM || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default m if ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sdx55-based
platforms.
@@ -305,6 +329,7 @@ config INTERCONNECT_QCOM_SDX75
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sdx75-based
platforms.
@@ -315,6 +340,7 @@ config INTERCONNECT_QCOM_SM6115
depends on QCOM_SMD_RPM
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_SMD_RPM
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sm6115-based
platforms.
@@ -325,6 +351,7 @@ config INTERCONNECT_QCOM_SM6350
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sm6350-based
platforms.
@@ -335,6 +362,7 @@ config INTERCONNECT_QCOM_SM7150
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sm7150-based
platforms.
@@ -345,6 +373,7 @@ config INTERCONNECT_QCOM_MILOS
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on Milos-based
platforms.
@@ -355,6 +384,7 @@ config INTERCONNECT_QCOM_SM8150
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sm8150-based
platforms.
@@ -365,6 +395,7 @@ config INTERCONNECT_QCOM_SM8250
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on sm8250-based
platforms.
@@ -375,6 +406,7 @@ config INTERCONNECT_QCOM_SM8350
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SM8350-based
platforms.
@@ -385,6 +417,7 @@ config INTERCONNECT_QCOM_SM8450
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SM8450-based
platforms.
@@ -395,6 +428,7 @@ config INTERCONNECT_QCOM_SM8550
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SM8550-based
platforms.
@@ -405,6 +439,7 @@ config INTERCONNECT_QCOM_SM8650
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SM8650-based
platforms.
@@ -415,6 +450,7 @@ config INTERCONNECT_QCOM_SM8750
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on SM8750-based
platforms.
@@ -425,6 +461,7 @@ config INTERCONNECT_QCOM_X1E80100
depends on ARM64 || COMPILE_TEST
select INTERCONNECT_QCOM_RPMH
select INTERCONNECT_QCOM_BCM_VOTER
+ default ARCH_QCOM
help
This is a driver for the Qualcomm Network-on-Chip on X1E80100-based
platforms.
--
2.51.0
^ permalink raw reply related
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Easwar Hariharan @ 2026-04-28 17:38 UTC (permalink / raw)
To: Joonwon Kang
Cc: will, robin.murphy, joro, jpb, easwar.hariharan, jgg, nicolinc,
praan, kees, amhetre, Alexander.Grest, baolu.lu, smostafa,
linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <20260424085339.3503582-1-joonwonkang@google.com>
On 4/24/2026 1:53 AM, Joonwon Kang wrote:
> For SVA, the IOMMU core always allocates PASID from the global PASID
> space. The use of this global PASID space comes from the limitation of
> the ENQCMD instruction in Intel CPUs that it fetches its PASID operand
> from IA32_PASID, which is per-task.
>
> Due to this nature, SVA with ARM SMMU v3 has been found not working in
> our environment when other modules/devices compete for PASID. The
> environment looks as follows:
>
> - The device is not a PCIe device.
> - The device is to use SVA.
> - The supported SSID/PASID space is very small for the device; only 1 to
> 3 SSIDs are supported.
> - There is a custom way of transmitting the SSID from the kernel to the
> device.
>
> With this setup, when other modules have allocated all the PASIDs that
> our device is expected to use from the global PASID space via APIs like
> iommu_alloc_global_pasid() or iommu_sva_bind_device(), SVA binding to
> our device fails due to the lack of available PASIDs.
>
> Since SSID/PASID is supported per-SID in ARM SMMU v3, this commit
> leverages the fact and lifts the use of the global PASID space if
> possible. What it does includes:
>
> - Introduce a new IOMMU capability IOMMU_CAP_PER_DEV_PASID_SPACE, which
> represents whether the IOMMU supports an independent PASID space per-
> device, not shared across devices. ARM SMMU v3 is the case.
> - Open a new API iommu_attach_device_pasid_any() to allocate any
> available PASID and attach an IOMMU domain to it.
> - Opt out the use of the global PASID space for SVA if the IOMMU has
> that capability, and use the new API to allocate a PASID in that case.
>
> Signed-off-by: Joonwon Kang <joonwonkang@google.com>
> ---
> v1: Request comments for this approach, other possible approaches and/or
> other aspects to consider more. Code is not sanitized and commits are
> not separated appropriately in this version.
>
<snip>
This may be a a basic question, but how does this reconcile with the fact
that the process ID space is global? Even with PID namespacing, I understand
that each process in a PID namespace has a "parent" PID in the parent namespace,
unless I'm grossly mistaken.
Also, with the per-device PASID space, different SVA-capable devices
being used by the same process would have different PASIDs referring to the same
process address space, and would break the DSA<->IAA kind of interaction where the
device drivers can communicate the PASID among each other to operate on the same
process address space. Is that a scenario that does not matter to your use case?
Thanks,
Easwar (he/him)
^ permalink raw reply
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Jason Gunthorpe @ 2026-04-28 17:44 UTC (permalink / raw)
To: Easwar Hariharan
Cc: Joonwon Kang, will, robin.murphy, joro, jpb, nicolinc, praan,
kees, amhetre, Alexander.Grest, baolu.lu, smostafa,
linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <e9de1b01-d075-487d-a00a-e2420b909f69@linux.microsoft.com>
On Tue, Apr 28, 2026 at 10:38:37AM -0700, Easwar Hariharan wrote:
> process address space, and would break the DSA<->IAA kind of interaction where the
> device drivers can communicate the PASID among each other to operate on the same
> process address space.
That is not part of the Linux model...
Each device has to get its own SVA and it must use the returned PASID,
not just invent one from someplace else.
Jason
^ permalink raw reply
* Re: [PATCH 5/5] fpga: m10bmc-sec: switch show_canceled_csk() to using sysfs_emit()
From: Yury Norov @ 2026-04-28 18:04 UTC (permalink / raw)
To: Xu Yilun
Cc: linux-kernel, Christophe Leroy (CS GROUP), Peter Zijlstra (Intel),
Rafael J. Wysocki, Alexander Shishkin, Daniel Lezcano,
Ingo Molnar, James Clark, Kees Cook, Lukasz Luba,
Madhavan Srinivasan, Michael Ellerman, Mike Leach, Moritz Fischer,
Nicholas Piggin, Russ Weight, Shrikanth Hegde, Suki K Poulose,
Tom Rix, Thomas Weißschuh, Xu Yilun, Yury Norov, Zhang Rui,
coresight, linux-arm-kernel, linux-fpga, linux-pm, linuxppc-dev,
Jakub Kicinski
In-Reply-To: <afAqkfe8iOU1cUyQ@yilunxu-OptiPlex-7050>
On Tue, Apr 28, 2026 at 11:33:37AM +0800, Xu Yilun wrote:
> On Mon, Apr 27, 2026 at 10:56:22PM -0400, Yury Norov wrote:
> > On Wed, Mar 25, 2026 at 03:25:48PM +0800, Xu Yilun wrote:
> > > On Tue, Mar 24, 2026 at 02:38:04PM -0400, Yury Norov wrote:
> > > > On Tue, Mar 24, 2026 at 05:15:33PM +0800, Xu Yilun wrote:
> > > > > On Tue, Mar 03, 2026 at 03:08:41PM -0500, Yury Norov wrote:
> > > > > > Switch show_canceled_csk() to use the proper sysfs_emit("%*pbl").
> > > > > >
> > > > > > Reviewed-by: Russ Weight <russ.weight@linux.dev>
> > > > > > Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
> > > > > > Signed-off-by: Yury Norov <ynorov@nvidia.com>
> > > > > > ---
> > > > > > drivers/fpga/intel-m10-bmc-sec-update.c | 3 ++-
> > > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/fpga/intel-m10-bmc-sec-update.c b/drivers/fpga/intel-m10-bmc-sec-update.c
> > > > > > index 10f678b9ed36..ae364c6636eb 100644
> > > > > > --- a/drivers/fpga/intel-m10-bmc-sec-update.c
> > > > > > +++ b/drivers/fpga/intel-m10-bmc-sec-update.c
> > > > > > @@ -10,6 +10,7 @@
> > > > > > #include <linux/firmware.h>
> > > > > > #include <linux/mfd/intel-m10-bmc.h>
> > > > > > #include <linux/mod_devicetable.h>
> > > > > > +#include <linux/mm.h>
> > > > >
> > > > > Why add this header file?
> > > >
> > > > When I was preparing the series, I had build issues without this. But
> > > > now I checked it against -rc5, and it's clean. Would you like me to
> > > > resend?
> > >
> > > No need. Given that I'll pick this patch alone to fpga for-next with the
> > > fix.
> > >
> > > Reviewed-by: Xu Yilun <yilun.xu@intel.com>
> >
> > Hi Xu,
> >
> > This patch is still not applied. This is the last non-lib user of
>
> I see it is already in v7.1-rc1, what's your expectation?
Oops, sorry. It's me not moving on the tip of the tree.
Sorry for the noise.
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Andrew Lunn @ 2026-04-28 18:05 UTC (permalink / raw)
To: Padhi, Beleswar
Cc: Shenwei Wang, Linus Walleij, Bartosz Golaszewski, Jonathan Corbet,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Mathieu Poirier, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <8c8cefaa-7d9e-4b73-b92f-40cb52b37f2e@ti.com>
> Remote side learns the endpoint when it receives any message from Linux
> from the dynamic endpoint.
>
> Lets say rpmsg_create_ept() allocates a dynamic local ept of 1026. When
> you send the message from this endpoint, the standard rpmsg header
> would have:
>
> 85 struct rpmsg_hdr {
> 86 __rpmsg32 src; // 1026
> 87 __rpmsg32 dst; // rpdev->dst (e.g. 400)
> 88 __rpmsg32 reserved;
> 89 __rpmsg16 len;
> 90 __rpmsg16 flags;
> 91 u8 data[];
> 92 } __packed;
>
> Remote side tracks the dynamic endpoint by reading src = 1026. And while
> sending the response it fills the header as:
I've never used rpmsg, so this might be a FAQ. How does the remote
side know what the endpoint is to be used for? Here we are talking
about GPIO. But the same hardware implements I2C, and a few other
things. How do we indicate this endpoint is for GPIO?
Maybe also related, this hardware also supports a number of GPIO
controllers. There has been some argument about if one endpoint should
support multiple GPIO controllers. Or, like gpio-virtio, one endpoint
represents one GPIO controller, and you instantiate multiple
endpoints, one per controller. How can you tell the different
instances of GPIO endpoints apart when they are dynamically created?
Andrew
^ permalink raw reply
* [PATCH 6.1.y] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
From: Sasha Levin @ 2026-04-28 18:19 UTC (permalink / raw)
To: stable
Cc: Anshuman Khandual, Will Deacon, linux-arm-kernel, linux-kernel,
David Hildenbrand (Arm), Ryan Roberts, Catalin Marinas,
Sasha Levin
In-Reply-To: <2026042727-detonate-paging-829b@gregkh>
From: Anshuman Khandual <anshuman.khandual@arm.com>
[ Upstream commit 48478b9f791376b4b89018d7afdfd06865498f65 ]
During a memory hot remove operation, both linear and vmemmap mappings for
the memory range being removed, get unmapped via unmap_hotplug_range() but
mapped pages get freed only for vmemmap mapping. This is just a sequential
operation where each table entry gets cleared, followed by a leaf specific
TLB flush, and then followed by memory free operation when applicable.
This approach was simple and uniform both for vmemmap and linear mappings.
But linear mapping might contain CONT marked block memory where it becomes
necessary to first clear out all entire in the range before a TLB flush.
This is as per the architecture requirement. Hence batch all TLB flushes
during the table tear down walk and finally do it in unmap_hotplug_range().
Prior to this fix, it was hypothetically possible for a speculative access
to a higher address in the contiguous block to fill the TLB with shattered
entries for the entire contiguous range after a lower address had already
been cleared and invalidated. Due to the table entries being shattered, the
subsequent TLB invalidation for the higher address would not then clear the
TLB entries for the lower address, meaning stale TLB entries could persist.
Besides it also helps in improving the performance via TLBI range operation
along with reduced synchronization instructions. The time spent executing
unmap_hotplug_range() improved 97% measured over a 2GB memory hot removal
in KVM guest.
This scheme is not applicable during vmemmap mapping tear down where memory
needs to be freed and hence a TLB flush is required after clearing out page
table entry.
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Closes: https://lore.kernel.org/all/aWZYXhrT6D2M-7-N@willie-the-truck/
Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove")
Cc: stable@vger.kernel.org
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
[ replaced `__pte_clear()` with `pte_clear()` ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/mm/mmu.c | 36 ++++++++++++++++++++----------------
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index e9288b28cb1e3..cbba5e73099fe 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -925,10 +925,14 @@ static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
WARN_ON(!pte_present(pte));
pte_clear(&init_mm, addr, ptep);
- flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
- if (free_mapped)
+ if (free_mapped) {
+ /* CONT blocks are not supported in the vmemmap */
+ WARN_ON(pte_cont(pte));
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
free_hotplug_page_range(pte_page(pte),
PAGE_SIZE, altmap);
+ }
+ /* unmap_hotplug_range() flushes TLB for !free_mapped */
} while (addr += PAGE_SIZE, addr < end);
}
@@ -949,15 +953,14 @@ static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
WARN_ON(!pmd_present(pmd));
if (pmd_sect(pmd)) {
pmd_clear(pmdp);
-
- /*
- * One TLBI should be sufficient here as the PMD_SIZE
- * range is mapped with a single block entry.
- */
- flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
- if (free_mapped)
+ if (free_mapped) {
+ /* CONT blocks are not supported in the vmemmap */
+ WARN_ON(pmd_cont(pmd));
+ flush_tlb_kernel_range(addr, addr + PMD_SIZE);
free_hotplug_page_range(pmd_page(pmd),
PMD_SIZE, altmap);
+ }
+ /* unmap_hotplug_range() flushes TLB for !free_mapped */
continue;
}
WARN_ON(!pmd_table(pmd));
@@ -982,15 +985,12 @@ static void unmap_hotplug_pud_range(p4d_t *p4dp, unsigned long addr,
WARN_ON(!pud_present(pud));
if (pud_sect(pud)) {
pud_clear(pudp);
-
- /*
- * One TLBI should be sufficient here as the PUD_SIZE
- * range is mapped with a single block entry.
- */
- flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
- if (free_mapped)
+ if (free_mapped) {
+ flush_tlb_kernel_range(addr, addr + PUD_SIZE);
free_hotplug_page_range(pud_page(pud),
PUD_SIZE, altmap);
+ }
+ /* unmap_hotplug_range() flushes TLB for !free_mapped */
continue;
}
WARN_ON(!pud_table(pud));
@@ -1020,6 +1020,7 @@ static void unmap_hotplug_p4d_range(pgd_t *pgdp, unsigned long addr,
static void unmap_hotplug_range(unsigned long addr, unsigned long end,
bool free_mapped, struct vmem_altmap *altmap)
{
+ unsigned long start = addr;
unsigned long next;
pgd_t *pgdp, pgd;
@@ -1041,6 +1042,9 @@ static void unmap_hotplug_range(unsigned long addr, unsigned long end,
WARN_ON(!pgd_present(pgd));
unmap_hotplug_p4d_range(pgdp, addr, next, free_mapped, altmap);
} while (addr = next, addr < end);
+
+ if (!free_mapped)
+ flush_tlb_kernel_range(start, end);
}
static void free_empty_pte_table(pmd_t *pmdp, unsigned long addr,
--
2.53.0
^ permalink raw reply related
* [PATCH v2 00/11] firmware: arm_ffa: Fix cleanup, notification, and discovery paths
From: Sudeep Holla @ 2026-04-28 18:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Jens Wiklander, Sudeep Holla, Sebastian Ene
Hi all,
This series fixes a set of issues in the FF-A driver around init
cleanup, framework notification handling, v1.0 notifier lifetime, and
partition discovery.
The fixes are all small and localized, but together they tighten a few
important paths:
- fix the early init unwind path when RX buffer allocation fails
- align the stored RX/TX buffer size with the size actually mapped to
firmware
- ensure the framework notification handler always releases the RX
buffer correctly
- validate framework notification payload bounds before copying data out
of the shared RX buffer
- fix the partition lookup used for sched-recv callback registration
- unregister the FF-A v1.0 bus notifier during teardown
- bound the register-based partition discovery copies against the caller
buffer
- reject FF-A driver registration without an ID table
- fix per-vcpu drivers own notifications handling in workqueue
- make NPI per cpu work item to avoid collapsing already queued work
This is the outcome of the self-initiated review of the entire driver
following the oversight of Sashiko’s review on one of the patches that
was merged.
https://sashiko.dev/#/patchset/20260402113939.930221-1-sebastianene@google.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
Changes in v2:
- Addressed valid comments from sashiko
(https://sashiko.dev/#/patchset/20260423-ffa_fixes-v1-0-61189661affe@kernel.org)
- Added couple of new fixes based on the review
- Link to v1: https://patch.msgid.link/20260423-ffa_fixes-v1-0-61189661affe@kernel.org
---
Sudeep Holla (11):
firmware: arm_ffa: Check for NULL FF-A ID table while driver registration
firmware: arm_ffa: Skip free_pages on RX buffer alloc failure
firmware: arm_ffa: Avoid collapsing NPI work from different CPUs
firmware: arm_ffa: Fix per-vcpu self notifications handling in workqueue
firmware: arm_ffa: Unregister bus notifier on teardown for FF-A v1.0
firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies
firmware: arm_ffa: Keep framework RX release under lock
firmware: arm_ffa: Validate framework notification message layout
firmware: arm_ffa: Align RxTx buffer size before mapping
firmware: arm_ffa: Snapshot notifier callbacks under lock
firmware: arm_ffa: Fix sched-recv callback partition lookup
drivers/firmware/arm_ffa/bus.c | 4 +-
drivers/firmware/arm_ffa/driver.c | 138 +++++++++++++++++++++++++++-----------
2 files changed, 102 insertions(+), 40 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260423-ffa_fixes-4ad33f0ee250
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 01/11] firmware: arm_ffa: Check for NULL FF-A ID table while driver registration
From: Sudeep Holla @ 2026-04-28 18:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260428-ffa_fixes-v2-0-8595ae450034@kernel.org>
The bus match callback assumes that every FF-A driver provides an
id_table and dereferences it unconditionally. Enforce that contract at
registration time so a buggy client driver cannot crash the bus during
match.
Fixes: 92743071464f ("firmware: arm_ffa: Ensure drivers provide a probe function")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/bus.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/bus.c b/drivers/firmware/arm_ffa/bus.c
index 9576862d89c4..601c3418e0d9 100644
--- a/drivers/firmware/arm_ffa/bus.c
+++ b/drivers/firmware/arm_ffa/bus.c
@@ -26,6 +26,8 @@ static int ffa_device_match(struct device *dev, const struct device_driver *drv)
id_table = to_ffa_driver(drv)->id_table;
ffa_dev = to_ffa_dev(dev);
+ if (!id_table)
+ return 0;
while (!uuid_is_null(&id_table->uuid)) {
/*
@@ -123,7 +125,7 @@ int ffa_driver_register(struct ffa_driver *driver, struct module *owner,
{
int ret;
- if (!driver->probe)
+ if (!driver->probe || !driver->id_table)
return -EINVAL;
driver->driver.bus = &ffa_bus_type;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 02/11] firmware: arm_ffa: Skip free_pages on RX buffer alloc failure
From: Sudeep Holla @ 2026-04-28 18:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260428-ffa_fixes-v2-0-8595ae450034@kernel.org>
If the RX buffer allocation fails in ffa_init(), the error path jumps to
free_pages even though no buffer has been allocated yet. Route that case
directly to free_drv_info so the cleanup path is only used after at
least one RX/TX buffer allocation has succeeded.
Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index eb2782848283..e6a051b20cb7 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2067,7 +2067,7 @@ static int __init ffa_init(void)
drv_info->rx_buffer = alloc_pages_exact(rxtx_bufsz, GFP_KERNEL);
if (!drv_info->rx_buffer) {
ret = -ENOMEM;
- goto free_pages;
+ goto free_drv_info;
}
drv_info->tx_buffer = alloc_pages_exact(rxtx_bufsz, GFP_KERNEL);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 04/11] firmware: arm_ffa: Fix per-vcpu self notifications handling in workqueue
From: Sudeep Holla @ 2026-04-28 18:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260428-ffa_fixes-v2-0-8595ae450034@kernel.org>
Per-vcpu notification handling already runs from a per-cpu work item on
the target cpu. Routing that path back through smp_call_function_single()
re-enters the call-function IPI path and executes the notification
handler with interrupts disabled. That makes the framework path unsafe,
since it takes a mutex, allocates memory with GFP_KERNEL, and invokes
client callbacks.
Handle per-vcpu self notifications directly from the existing per-cpu
work item instead. This keeps the per-vcpu path in task context and
avoids the extra IPI hop entirely.
Fixes: 3a3e2b83e805 ("firmware: arm_ffa: Avoid queuing work when running on the worker queue")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 4e66c7325a4e..2241e851f7ae 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1543,7 +1543,7 @@ static void notif_pcpu_irq_work_fn(struct work_struct *work)
notif_pcpu_work);
struct ffa_drv_info *info = pcpu->info;
- ffa_self_notif_handle(smp_processor_id(), true, info);
+ notif_get_and_handle(info);
}
static const struct ffa_info_ops ffa_drv_info_ops = {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 06/11] firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies
From: Sudeep Holla @ 2026-04-28 18:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260428-ffa_fixes-v2-0-8595ae450034@kernel.org>
The register-based PARTITION_INFO_GET path trusted the firmware-provided
indices when copying partition descriptors into the caller buffer.
Reject inconsistent counts or index progressions so the copy loop cannot
write past the allocated array.
Fixes: ba85c644ac8d ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index a122814eb6d7..ed502486eb35 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -323,6 +323,12 @@ __ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
#define PART_INFO_ID_MASK GENMASK(15, 0)
#define PART_INFO_EXEC_CXT_MASK GENMASK(31, 16)
#define PART_INFO_PROPS_MASK GENMASK(63, 32)
+#define FFA_PART_INFO_GET_REGS_FIRST_REG 3
+#define FFA_PART_INFO_GET_REGS_REGS_PER_DESC 3
+#define FFA_PART_INFO_GET_REGS_MAX_DESC \
+ (((sizeof(ffa_value_t) / sizeof_field(ffa_value_t, a0)) - \
+ FFA_PART_INFO_GET_REGS_FIRST_REG) / \
+ FFA_PART_INFO_GET_REGS_REGS_PER_DESC)
#define PART_INFO_ID(x) ((u16)(FIELD_GET(PART_INFO_ID_MASK, (x))))
#define PART_INFO_EXEC_CXT(x) ((u16)(FIELD_GET(PART_INFO_EXEC_CXT_MASK, (x))))
#define PART_INFO_PROPERTIES(x) ((u32)(FIELD_GET(PART_INFO_PROPS_MASK, (x))))
@@ -336,7 +342,7 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
do {
__le64 *regs;
- int idx;
+ int idx, nr_desc, buf_idx;
start_idx = prev_idx ? prev_idx + 1 : 0;
@@ -354,15 +360,28 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
count = PARTITION_COUNT(partition_info.a2);
if (!buffer || !num_parts) /* count only */
return count;
+ if (count > num_parts)
+ return -EINVAL;
cur_idx = CURRENT_INDEX(partition_info.a2);
+ if (cur_idx < start_idx || cur_idx >= count)
+ return -EINVAL;
+
+ nr_desc = cur_idx - start_idx + 1;
+ if (nr_desc > FFA_PART_INFO_GET_REGS_MAX_DESC)
+ return -EINVAL;
+
+ buf_idx = buf - buffer;
+ if (buf_idx + nr_desc > num_parts)
+ return -EINVAL;
+
tag = UUID_INFO_TAG(partition_info.a2);
buf_sz = PARTITION_INFO_SZ(partition_info.a2);
if (buf_sz > sizeof(*buffer))
buf_sz = sizeof(*buffer);
regs = (void *)&partition_info.a3;
- for (idx = 0; idx < cur_idx - start_idx + 1; idx++, buf++) {
+ for (idx = 0; idx < nr_desc; idx++, buf++) {
union {
uuid_t uuid;
u64 regs[2];
--
2.43.0
^ permalink raw reply related
* [PATCH v2 07/11] firmware: arm_ffa: Keep framework RX release under lock
From: Sudeep Holla @ 2026-04-28 18:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260428-ffa_fixes-v2-0-8595ae450034@kernel.org>
The framework notification handler drops rx_lock before issuing
FFA_RX_RELEASE, leaving a window where another RX-buffer user can
start a new FF-A transaction before ownership has actually been
returned to firmware.
Move the FFA_RX_RELEASE calls so they execute while rx_lock is still
held on both the kmemdup() failure path and the normal success path.
While doing that, switch the handler to scoped_guard() to keep the
critical section explicit.
Fixes: 285a5ea0f542 ("firmware: arm_ffa: Add support for handling framework notifications")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 29 +++++++++++++----------------
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index ed502486eb35..18bcbd161805 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1494,25 +1494,22 @@ static void handle_fwk_notif_callbacks(u32 bitmap)
if (!(bitmap & FRAMEWORK_NOTIFY_RX_BUFFER_FULL))
return;
- mutex_lock(&drv_info->rx_lock);
+ scoped_guard(mutex, &drv_info->rx_lock) {
+ msg = drv_info->rx_buffer;
+ buf = kmemdup((void *)msg + msg->offset, msg->size, GFP_KERNEL);
+ if (!buf) {
+ ffa_rx_release();
+ return;
+ }
- msg = drv_info->rx_buffer;
- buf = kmemdup((void *)msg + msg->offset, msg->size, GFP_KERNEL);
- if (!buf) {
- mutex_unlock(&drv_info->rx_lock);
- return;
+ target = SENDER_ID(msg->send_recv_id);
+ if (msg->offset >= sizeof(*msg))
+ uuid_copy(&uuid, &msg->uuid);
+ else
+ uuid_copy(&uuid, &uuid_null);
+ ffa_rx_release();
}
- target = SENDER_ID(msg->send_recv_id);
- if (msg->offset >= sizeof(*msg))
- uuid_copy(&uuid, &msg->uuid);
- else
- uuid_copy(&uuid, &uuid_null);
-
- mutex_unlock(&drv_info->rx_lock);
-
- ffa_rx_release();
-
read_lock(&drv_info->notify_lock);
cb_info = notifier_hnode_get_by_vmid_uuid(notify_id, target, &uuid);
read_unlock(&drv_info->notify_lock);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 03/11] firmware: arm_ffa: Avoid collapsing NPI work from different CPUs
From: Sudeep Holla @ 2026-04-28 18:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260428-ffa_fixes-v2-0-8595ae450034@kernel.org>
Notification pending interrupts are registered as per-CPU IRQs, but the
driver queues all NPI handling through a single shared work_struct.
That allows queue_work_on() calls from different CPUs to collapse onto a
single pending work item even though the work function uses the CPU it
runs on to fetch and handle per-CPU notifications.
Move notif_pcpu_work into the per-CPU ffa_pcpu_irq state and initialize
one work item per CPU. This keeps NPI handling independent per CPU and
avoids losing notifications when multiple CPUs queue work concurrently.
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index e6a051b20cb7..4e66c7325a4e 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -87,6 +87,7 @@ static inline int ffa_to_linux_errno(int errno)
struct ffa_pcpu_irq {
struct ffa_drv_info *info;
+ struct work_struct notif_pcpu_work;
};
struct ffa_drv_info {
@@ -106,7 +107,6 @@ struct ffa_drv_info {
unsigned int cpuhp_state;
struct ffa_pcpu_irq __percpu *irq_pcpu;
struct workqueue_struct *notif_pcpu_wq;
- struct work_struct notif_pcpu_work;
struct work_struct sched_recv_irq_work;
struct xarray partition_info;
DECLARE_HASHTABLE(notifier_hash, ilog2(FFA_MAX_NOTIFICATIONS));
@@ -1539,8 +1539,9 @@ ffa_self_notif_handle(u16 vcpu, bool is_per_vcpu, void *cb_data)
static void notif_pcpu_irq_work_fn(struct work_struct *work)
{
- struct ffa_drv_info *info = container_of(work, struct ffa_drv_info,
+ struct ffa_pcpu_irq *pcpu = container_of(work, struct ffa_pcpu_irq,
notif_pcpu_work);
+ struct ffa_drv_info *info = pcpu->info;
ffa_self_notif_handle(smp_processor_id(), true, info);
}
@@ -1811,7 +1812,7 @@ static irqreturn_t notif_pend_irq_handler(int irq, void *irq_data)
struct ffa_drv_info *info = pcpu->info;
queue_work_on(smp_processor_id(), info->notif_pcpu_wq,
- &info->notif_pcpu_work);
+ &pcpu->notif_pcpu_work);
return IRQ_HANDLED;
}
@@ -1928,8 +1929,11 @@ static int ffa_init_pcpu_irq(void)
if (!irq_pcpu)
return -ENOMEM;
- for_each_present_cpu(cpu)
+ for_each_present_cpu(cpu) {
per_cpu_ptr(irq_pcpu, cpu)->info = drv_info;
+ INIT_WORK(&per_cpu_ptr(irq_pcpu, cpu)->notif_pcpu_work,
+ notif_pcpu_irq_work_fn);
+ }
drv_info->irq_pcpu = irq_pcpu;
@@ -1958,7 +1962,6 @@ static int ffa_init_pcpu_irq(void)
}
INIT_WORK(&drv_info->sched_recv_irq_work, ffa_sched_recv_irq_work_fn);
- INIT_WORK(&drv_info->notif_pcpu_work, notif_pcpu_irq_work_fn);
drv_info->notif_pcpu_wq = create_workqueue("ffa_pcpu_irq_notification");
if (!drv_info->notif_pcpu_wq)
return -EINVAL;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 05/11] firmware: arm_ffa: Unregister bus notifier on teardown for FF-A v1.0
From: Sudeep Holla @ 2026-04-28 18:33 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260428-ffa_fixes-v2-0-8595ae450034@kernel.org>
For FF-A v1.0 the driver registers a bus notifier to backfill UUID
matching, but the notifier was never unregistered on cleanup paths.
Track the registration state and unregister it during teardown and early
partition-setup failure.
Fixes: 9dd15934f60d ("firmware: arm_ffa: Move the FF-A v1.0 NULL UUID workaround to bus notifier")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 2241e851f7ae..a122814eb6d7 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -101,6 +101,7 @@ struct ffa_drv_info {
bool mem_ops_native;
bool msg_direct_req2_supp;
bool bitmap_created;
+ bool bus_notifier_registered;
bool notif_enabled;
unsigned int sched_recv_irq;
unsigned int notif_pend_irq;
@@ -1630,6 +1631,15 @@ static struct notifier_block ffa_bus_nb = {
.notifier_call = ffa_bus_notifier,
};
+static void ffa_bus_notifier_unregister(void)
+{
+ if (!drv_info->bus_notifier_registered)
+ return;
+
+ bus_unregister_notifier(&ffa_bus_type, &ffa_bus_nb);
+ drv_info->bus_notifier_registered = false;
+}
+
static int ffa_xa_add_partition_info(struct ffa_device *dev)
{
struct ffa_dev_part_info *info;
@@ -1713,6 +1723,8 @@ static void ffa_partitions_cleanup(void)
struct list_head *phead;
unsigned long idx;
+ ffa_bus_notifier_unregister();
+
/* Clean up/free all registered devices */
ffa_devices_unregister();
@@ -1740,11 +1752,14 @@ static int ffa_setup_partitions(void)
ret = bus_register_notifier(&ffa_bus_type, &ffa_bus_nb);
if (ret)
pr_err("Failed to register FF-A bus notifiers\n");
+ else
+ drv_info->bus_notifier_registered = true;
}
count = ffa_partition_probe(&uuid_null, &pbuf);
if (count <= 0) {
pr_info("%s: No partitions found, error %d\n", __func__, count);
+ ffa_bus_notifier_unregister();
return -EINVAL;
}
--
2.43.0
^ permalink raw reply related
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