* [PATCH v2 0/3] Subject: [PATCH 0/3] Add Shikra (QCM2390) display support
From: Nabige Aala @ 2026-06-04 12:30 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krishna Manikandan,
Loic Poulain, Bjorn Andersson, Konrad Dybcio, Will Deacon,
Robin Murphy, Joerg Roedel (AMD)
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
iommu, linux-arm-kernel, Nabige Aala
Shikra (QCM2390) is a Qualcomm SoC based on the QCM2290 family that
reuses the same MDSS/DPU 6.5 hardware as QCM2290. This series enables
the display subsystem for Shikra by adding DT binding updates for MDSS,
DSI controller and DPU, arm64 defconfig enablement for the ILI7807S DSI
panel, and UBWC configuration mapping Shikra to qcm2290_data.
Driver and SMMU support are covered by the existing qcom,qcm2290-mdss
fallback compatible string — no separate drm/msm or IOMMU patches are
required.
Tested on Shikra CQM EVK board with ILI7807S DSI panel. Display
pipeline probes cleanly and panel renders correctly.
Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
---
Nabige Aala (3):
dt-bindings: display: msm: qcm2290: Add Shikra MDSS
arm64: defconfig: Enable ILI7807S DSI panel driver
soc: qcom: ubwc: Add Shikra UBWC config
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 +
Documentation/devicetree/bindings/display/msm/qcom,qcm2290-dpu.yaml | 4 +++-
Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 34 +++++++++++++++++++++++++++-------
arch/arm64/configs/defconfig | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
drivers/soc/qcom/ubwc_config.c | 1 +
5 files changed, 33 insertions(+), 8 deletions(-)
---
Prerequisite-Message-Id: <20260518-ili7807s-panel-v1-0-d7b048163b1c@oss.qualcomm.com>
---
Changes in v2:
- Drop drm/msm/mdss: Shikra support patch; driver reuse is handled via
the qcom,qcm2290-mdss fallback compatible string (per Dmitry's review)
- Drop iommu/arm-smmu: Shikra SMMU client table patch; not required with
fallback compatible approach
- Fix UBWC config to map qcom,shikra to qcm2290_data instead of
no_ubwc_data; Shikra shares UBWC support with QCM2290
- Refactor series from 5 patches to 3 patches
- Link to v1: https://patch.msgid.link/20260603-shikra-display-v1-0-aeac1b94faa7@oss.qualcomm.com
---
Nabige Aala (3):
dt-bindings: display: msm: qcm2290: Add Shikra MDSS
arm64: defconfig: Enable ILI7807S DSI panel driver
soc: qcom: ubwc: Add Shikra UBWC config
.../bindings/display/msm/dsi-controller-main.yaml | 1 +
.../bindings/display/msm/qcom,qcm2290-dpu.yaml | 7 ++--
.../bindings/display/msm/qcom,qcm2290-mdss.yaml | 38 ++++++++++++++++++----
arch/arm64/configs/defconfig | 1 +
drivers/soc/qcom/ubwc_config.c | 1 +
5 files changed, 39 insertions(+), 9 deletions(-)
---
base-commit: 3a34f9c13cc0688f8db2a0db8506bf8c0d90737d
change-id: 20260603-shikra-display-07767208fa90
Best regards,
--
Nabige Aala <nabige.aala@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v8 5/5] arm64: defconfig: enable Exynos ACPM thermal support
From: Peter Griffin @ 2026-06-04 12:25 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Kees Cook,
Gustavo A. R. Silva, André Draszik, Alim Akhtar, jyescas,
linux-kernel, linux-samsung-soc, linux-pm, devicetree,
linux-hardening, linux-arm-kernel
In-Reply-To: <20260603-acpm-tmu-v8-5-0f1810a356e6@linaro.org>
On Wed, 3 Jun 2026 at 14:00, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Enable the Exynos ACPM thermal driver (CONFIG_EXYNOS_ACPM_THERMAL)
> to allow temperature monitoring and thermal management on Samsung
> Exynos SoCs (like Google GS101), used on pixel phones.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index d905a0777f93..3fe76a4c2633 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -793,6 +793,7 @@ CONFIG_BCM2711_THERMAL=m
> CONFIG_BCM2835_THERMAL=m
> CONFIG_BRCMSTB_THERMAL=m
> CONFIG_EXYNOS_THERMAL=y
> +CONFIG_EXYNOS_ACPM_THERMAL=m
> CONFIG_TEGRA_SOCTHERM=m
> CONFIG_TEGRA_BPMP_THERMAL=m
> CONFIG_GENERIC_ADC_THERMAL=m
>
> --
> 2.54.0.1013.g208068f2d8-goog
>
^ permalink raw reply
* Re: [RFC PATCH 00/20] mshv: enable kexec with Hyper-V donated pages and partitions
From: Mike Rapoport @ 2026-06-04 12:17 UTC (permalink / raw)
To: Jork Loeser
Cc: linux-hyperv, linux-mm, kexec, K. Y. Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Pasha Tatashin, Pratyush Yadav,
Alexander Graf, Jason Miu, Andrew Morton, David Hildenbrand,
Muchun Song, Oscar Salvador, Baoquan He, Catalin Marinas,
Will Deacon, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Kees Cook, Ran Xiaokai,
Justinien Bouron, Sourabh Jain, Pingfan Liu, Rafael J. Wysocki,
Mario Limonciello, linux-arm-kernel, x86, linux-kernel,
Michael Kelley
In-Reply-To: <3197c9c9-9e4f-c592-bb7-ac422f89115@linux.microsoft.com>
On Wed, Jun 03, 2026 at 10:25:58AM -0700, Jork Loeser wrote:
>
>
> On Wed, 3 Jun 2026, Mike Rapoport wrote:
>
> > On Mon, Jun 01, 2026 at 01:09:41PM -0700, Jork Loeser wrote:
> > > On Sun, 31 May 2026, Mike Rapoport wrote:
> > >
> > > > > Patch 19: Export kexec_in_progress for modules
> > > >
> > > > Isn't there another way to differentiate kexec reboot?
> >
> > There's that "kexec reboot" string passed as the cmd to the reboot
> > notifier.
> > Maybe we can make it somehow more well defined API and use it?
>
> A string? Dear my - the compiler won't flag it on an API change then, not
> ideal clearly. What's wrong with exporting kexec_in_progress()?
The policy in general is avoid exports unless strictly necessary.
A string can be declared as const char *KEXEC_REBOOT = "kexec reboot" and
used in both kexec and mshv. Not ideal, but still better.
No strong feelings from my side, just EXPORT_SYMBOL there felt a bit off.
> Best,
> Jork
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH v2 02/11] iio: adc: change from %ld to %pe for PTR_ERR() printing
From: Vojtěch Krátký @ 2026-06-04 11:59 UTC (permalink / raw)
To: linux-iio
Cc: Vojtěch Krátký, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Sakari Ailus, Linus Walleij, Wolfram Sang,
linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <20260604120201.116925-1-vo.kratky@seznam.cz>
Replace numeric PTR_ERR() logging with the %pe format specifier
so that error values are printed in a more readable form.
This change was identified using a Coccinelle semantic patch.
No functional change intended.
Signed-off-by: Vojtěch Krátký <vo.kratky@seznam.cz>
---
drivers/iio/adc/sun4i-gpadc-iio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
index 479115ea50bf..5d7a61abcaea 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -508,7 +508,7 @@ static int sun4i_gpadc_probe_dt(struct platform_device *pdev,
&sun4i_gpadc_regmap_config);
if (IS_ERR(info->regmap)) {
ret = PTR_ERR(info->regmap);
- dev_err(&pdev->dev, "failed to init regmap: %d\n", ret);
+ dev_err(&pdev->dev, "failed to init regmap: %pe\n", info->regmap);
return ret;
}
@@ -639,8 +639,8 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
*/
if (IS_ERR(info->tzd) && PTR_ERR(info->tzd) != -ENODEV) {
dev_err(&pdev->dev,
- "could not register thermal sensor: %ld\n",
- PTR_ERR(info->tzd));
+ "could not register thermal sensor: %pe\n",
+ info->tzd);
return PTR_ERR(info->tzd);
}
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v8 3/5] MAINTAINERS: Add entry for Samsung Exynos ACPM thermal driver
From: Peter Griffin @ 2026-06-04 11:57 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Kees Cook,
Gustavo A. R. Silva, André Draszik, Alim Akhtar, jyescas,
linux-kernel, linux-samsung-soc, linux-pm, devicetree,
linux-hardening, linux-arm-kernel, Krzysztof Kozlowski
In-Reply-To: <20260603-acpm-tmu-v8-3-0f1810a356e6@linaro.org>
On Wed, 3 Jun 2026 at 14:00, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Add a MAINTAINERS entry for the Samsung Exynos ACPM thermal driver.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e8218c2749b7..6a8521270daf 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23661,6 +23661,14 @@ F: drivers/clk/samsung/clk-acpm.c
> F: drivers/firmware/samsung/exynos-acpm*
> F: include/linux/firmware/samsung/exynos-acpm-protocol.h
>
> +SAMSUNG EXYNOS ACPM THERMAL DRIVER
> +M: Tudor Ambarus <tudor.ambarus@linaro.org>
> +L: linux-kernel@vger.kernel.org
> +L: linux-samsung-soc@vger.kernel.org
> +S: Supported
> +F: Documentation/devicetree/bindings/thermal/google,gs101-tmu-top.yaml
> +F: drivers/thermal/samsung/acpm-tmu.c
> +
> SAMSUNG EXYNOS MAILBOX DRIVER
> M: Tudor Ambarus <tudor.ambarus@linaro.org>
> L: linux-kernel@vger.kernel.org
>
> --
> 2.54.0.1013.g208068f2d8-goog
>
^ permalink raw reply
* [PATCH v1 1/3] dt-bindings: arm: sunxi: Add NetCube Systems OpenNMC (dobermann)
From: Lukas Schmid @ 2026-06-04 11:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Maxime Ripard
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
In-Reply-To: <20260604115241.1358528-1-lukas.schmid@netcube.li>
The OpenNMC is an open replacement for APC SmartSlot management cards
based on the Nagami System-on-Module.
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index e6443c266fa1..8e2c9b8fe121 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -600,6 +600,7 @@ properties:
- enum:
- netcube,nagami-basic-carrier
- netcube,nagami-keypad-carrier
+ - netcube,dobermann
- const: netcube,nagami
- const: allwinner,sun8i-t113s
--
2.47.3
^ permalink raw reply related
* [PATCH v1 2/3] riscv: dts: allwinner: d1s-t113: Add uart4 pinctrl required by NetCube Systems OpenNMC
From: Lukas Schmid @ 2026-06-04 11:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Maxime Ripard
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
In-Reply-To: <20260604115241.1358528-1-lukas.schmid@netcube.li>
Added the "uart4_pb_pins" pinctrl used by the OpenNMC
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
---
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi b/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
index 82cc85acccb1..00fddedfa36f 100644
--- a/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
+++ b/arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi
@@ -191,6 +191,12 @@ uart3_pb_pins: uart3-pb-pins {
pins = "PB6", "PB7";
function = "uart3";
};
+
+ /omit-if-no-ref/
+ uart4_pb_pins: uart4-pb-pins {
+ pins = "PB2", "PB3";
+ function = "uart4";
+ };
};
ccu: clock-controller@2001000 {
--
2.47.3
^ permalink raw reply related
* [PATCH v1 3/3] ARM: dts: sunxi: add support for NetCube Systems OpenNMC (dobermann)
From: Lukas Schmid @ 2026-06-04 11:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Maxime Ripard
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
In-Reply-To: <20260604115241.1358528-1-lukas.schmid@netcube.li>
NetCube Systems OpenNMC is an open replacement for APC SmartSlot Management
Cards. It is based on the Nagami System-on-Module. It breaks out the
following interfaces:
- 10/100 Mbps Ethernet
- USB Type-C OTG using a TUSB320 (usb0)
- USB Type-C Console Port using a CH340 (uart3)
- USB Type-A Host with internal CH334 USB-Hub (usb1)
- MicroSD Slot with Card-Detect (mmc0)
- WiFi/Bluetooth using the modules built-in ESP32
- SmartSlot serial interface (uart4)
- DS3232 RTC with CR1220 Battery Backup
- Extension connector providing SPI,I2C,USB,CAN,UART for future use.
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
---
.../sun8i-t113s-netcube-dobermann.dts | 149 ++++++++++++++++++
1 file changed, 149 insertions(+)
create mode 100644 arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts
diff --git a/arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts b/arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts
new file mode 100644
index 000000000000..97dd4b950dd8
--- /dev/null
+++ b/arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 Lukas Schmid <lukas.schmid@netcube.li>
+ */
+
+/dts-v1/;
+#include "sun8i-t113s-netcube-nagami.dtsi"
+
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "NetCube Systems OpenNMC (dobermann)";
+ compatible = "netcube,dobermann", "netcube,nagami",
+ "allwinner,sun8i-t113s";
+
+ aliases {
+ serial2 = &uart4; // UART on SmartSlot
+ rtc0 = &ds3232;
+ rtc1 = &rtc; // not battery backed
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_heartbeat_green: led-heartbeat-green {
+ gpios = <&pio 6 14 GPIO_ACTIVE_HIGH>; /* PG14 */
+ linux,default-trigger = "heartbeat";
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_HEARTBEAT;
+ };
+ };
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+
+ tusb320: typec@60 {
+ compatible = "ti,tusb320";
+ reg = <0x60>;
+ interrupts-extended = <&pio 3 22 IRQ_TYPE_LEVEL_LOW>; /* PD22 */
+ };
+
+ ds3232: rtc@68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ };
+};
+
+/* microSD Card Slot on the board */
+&mmc0 {
+ vmmc-supply = <®_vcc3v3>;
+ disable-wp;
+ bus-width = <4>;
+ cd-gpios = <&pio 6 15 GPIO_ACTIVE_LOW>; /* PG15 */
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&pio {
+ gpio-line-names = "", "", "", "", // PA
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "SMART_TX", "SMART_RX", // PB
+ "EXT_IO3", "EXT_IO2", "CONSOLE_TX", "CONSOLE_RX",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "eMMC_CLK", "eMMC_CMD", // PC
+ "eMMC_D2", "eMMC_D1", "eMMC_D0", "eMMC_D3",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "", // PD
+ "", "", "", "",
+ "", "USB_SEC_EN", "EXT_SPI_nCS", "EXT_SPI_SCK",
+ "EXT_SPI_MOSI", "EXT_SPI_MISO", "EXT_IO5", "EXT_IO4",
+ "SMART_SEL", "", "", "",
+ "I2C3_SCL", "I2C3_SDA", "TUSB320_nINT", "",
+ "", "", "", "",
+ "", "", "", "",
+ "ETH_CRSDV", "ETH_RXD0", "ETH_RXD1", "ETH_TXCK", // PE
+ "ETH_TXD0", "ETH_TXD1", "ETH_TXEN", "",
+ "ETH_MDC", "ETH_MDIO", "I2C3_nINT", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "uSD_D1", "uSD_D0", "uSD_CLK", "uSD_CLK", // PF
+ "uSD_D3", "uSD_D2", "TUSB320_ID", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "ESP_CLK", "ESP_CMD", "ESP_D0", "ESP_D1", // PG
+ "ESP_D2", "ESP_D3", "ESP_TXD", "ESP_RXD",
+ "ESP_nBOOT", "ESP_nRST", "I2C2_SCL", "I2C2_SDA",
+ "EXT_IO1", "EXT_IO0", "LED_HEARTBEAT", "SD_DETECT",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+};
+
+/* SmartSlot serial */
+&uart4 {
+ pinctrl-0 = <&uart4_pb_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usb_otg {
+ extcon = <&tusb320 0>;
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ status = "okay";
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/3] Add support for NetCube Systems OpenNMC (dobermann)
From: Lukas Schmid @ 2026-06-04 11:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Maxime Ripard
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
This series adds support for the NetCube Systems OpenNMC
Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
---
Lukas Schmid (3):
dt-bindings: arm: sunxi: Add NetCube Systems OpenNMC (dobermann)
riscv: dts: allwinner: d1s-t113: Add uart4 pinctrl required by NetCube
Systems OpenNMC
ARM: dts: sunxi: add support for NetCube Systems OpenNMC (dobermann)
.../devicetree/bindings/arm/sunxi.yaml | 1 +
.../sun8i-t113s-netcube-dobermann.dts | 149 ++++++++++++++++++
.../boot/dts/allwinner/sunxi-d1s-t113.dtsi | 6 +
3 files changed, 156 insertions(+)
create mode 100644 arch/arm/boot/dts/allwinner/sun8i-t113s-netcube-dobermann.dts
--
2.47.3
^ permalink raw reply
* Re: [PATCH v19 00/14] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
From: Bartosz Golaszewski @ 2026-06-04 11:50 UTC (permalink / raw)
To: Vinod Koul
Cc: Bartosz Golaszewski, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Bjorn Andersson, Peter Ujfalusi,
Michal Simek, Frank Li, Andy Gross, Neil Armstrong, dmaengine,
linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Dmitry Baryshkov,
Konrad Dybcio, Stephan Gerhold
In-Reply-To: <aiFScCW_NEY3CsEf@vaman>
On Thu, 4 Jun 2026 12:24:48 +0200, Vinod Koul <vkoul@kernel.org> said:
> On 02-06-26, 18:38, Stephan Gerhold wrote:
>> On Tue, May 26, 2026 at 03:10:48PM +0200, Bartosz Golaszewski wrote:
>> > I feel like I fell into the trap of trying to address pre-existing
>> > issues reported by sashiko and in the process provoking more reports so
>> > let this be the last iteration where I do this. Vinod can we get this
>> > queued for v7.2 now and iron out any previously existing problems in
>> > tree?
>>
>> Thanks a lot for working on fixing all these issues!
>>
>> I agree there is no point addressing all the "pre-existing issues"
>> pointed out by Sashiko, but have you looked through the other comments
>> for new issues pointed out for your patches?
>
> I hope Bart and Qualcomm can fix these driver issues as well
>>
>> Out of curiosity, I was looking a bit at the comments for [PATCH v19
>> 06/14] dmaengine: qcom: bam_dma: add support for BAM locking [1]. There
>> are 8 open comments there (Critical: 1, High: 6 and Medium: 1). From a
>> quick look I would say most of these could be valid. The critical one
>> about the usage of dma_cookie_assign() sounds a bit concerning to me, if
>> it is true we would be basically breaking parts of the dmaengine API for
>> consumers by inserting the lock descriptor in front of everything else.
>
> Yes this seems to be a valid one. Attaching another descriptor for lock
> does not sound right to me, as in this case causes descriptor to be
> marked 'done' prematurely.
>
Yes, I have a fix for this queued.
> Honestly, I am not quite happy with the way lock is being handled here.
> I would hope we can have some better suggestions. Adding a descriptor
> for lock does not look right to me. We are adding odd hardware/firmware
> behaviour on engine apis.
>
> I had earlier suggested to lock always or lock only for hw/sw versions
> supported inside the driver, that might be simplist solution without the
> complexity added here
>
I'm not sure what you mean here. Several iterations ago it was deferred to
consumer drivers. Mani objected and Bjorn and you agreed. I reworked it to move
the locking logic into the DMA driver as requested.
Bart
^ permalink raw reply
* Re: [PATCH v2 03/12] drm/bridge: synopsys: dw-dp: Simplify driver data setting
From: Andy Yan @ 2026-06-04 11:32 UTC (permalink / raw)
To: Sebastian Reichel, Sandy Huang, Heiko Stübner,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Airlie, Simona Vetter, Dmitry Baryshkov,
Luca Ceresoli
Cc: Cristian Ciocaltea, Damon Ding, Dmitry Baryshkov, Alexey Charkov,
dri-devel, linux-rockchip, linux-kernel, devicetree, kernel,
linux-arm-kernel
In-Reply-To: <20260501-synopsys-dw-dp-improvements-v2-3-d7e7f6bac77f@collabora.com>
Hello,
On 5/1/26 06:20, Sebastian Reichel wrote:
> There is no need to get the platform device just for setting up
> the driver data. Simplify the logic.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Andy Yan <andy.yan@rock-chips.com>
> ---
> drivers/gpu/drm/rockchip/dw_dp-rockchip.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
> index 150c2da8fee5..52e956bffb12 100644
> --- a/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_dp-rockchip.c
> @@ -74,7 +74,6 @@ static const struct drm_encoder_helper_funcs dw_dp_encoder_helper_funcs = {
>
> static int dw_dp_rockchip_bind(struct device *dev, struct device *master, void *data)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> const struct dw_dp_plat_data *plat_data;
> struct drm_device *drm_dev = data;
> struct rockchip_dw_dp *dp;
> @@ -87,7 +86,7 @@ static int dw_dp_rockchip_bind(struct device *dev, struct device *master, void *
> return -ENOMEM;
>
> dp->dev = dev;
> - platform_set_drvdata(pdev, dp);
> + dev_set_drvdata(dev, dp);
>
> plat_data = of_device_get_match_data(dev);
> if (!plat_data)
>
^ permalink raw reply
* Re: [PATCH v8 1/5] dt-bindings: thermal: Add Google GS101 TMU
From: Peter Griffin @ 2026-06-04 11:23 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Kees Cook,
Gustavo A. R. Silva, André Draszik, Alim Akhtar, jyescas,
linux-kernel, linux-samsung-soc, linux-pm, devicetree,
linux-hardening, linux-arm-kernel, Krzysztof Kozlowski
In-Reply-To: <20260603-acpm-tmu-v8-1-0f1810a356e6@linaro.org>
On Wed, 3 Jun 2026 at 14:00, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Document the Thermal Management Unit (TMU) found on the Google GS101 SoC.
>
> The GS101 TMU utilizes a hybrid control model shared between the
> Application Processor (AP) and the ACPM (Alive Clock and Power Manager)
> firmware. This hybrid ACPM TMU architecture is also present on other
> Samsung Exynos SoCs (e.g., AutoV920, Exynos850).
>
> While the TMU is a standard memory-mapped IP block, on this platform
> the AP's direct register access is restricted to the interrupt pending
> (INTPEND) registers for event identification. High-level functional
> tasks, such as sensor initialization, threshold programming, and
> temperature reads, are delegated to the ACPM firmware.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> .../bindings/thermal/google,gs101-tmu-top.yaml | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/thermal/google,gs101-tmu-top.yaml b/Documentation/devicetree/bindings/thermal/google,gs101-tmu-top.yaml
> new file mode 100644
> index 000000000000..75560ebca48d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/google,gs101-tmu-top.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/thermal/google,gs101-tmu-top.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung Exynos ACPM Thermal Management Unit (TMU)
> +
> +maintainers:
> + - Tudor Ambarus <tudor.ambarus@linaro.org>
> +
> +description:
> + The Samsung Exynos ACPM TMU is a thermal sensor block found on Exynos
> + based platforms (such as Google GS101 and Exynos850). It supports
> + both direct register-level access and firmware-mediated management
> + via the ACPM (Alive Clock and Power Manager) firmware.
> +
> + On these platforms, the hardware is managed in a hybrid fashion. The
> + Application Processor (AP) maintains direct memory-mapped access
> + exclusively to the interrupt pending registers to identify thermal
> + events. All other functional aspects - including sensor
> + initialization, threshold configuration, and temperature acquisition
> + - are handled by the ACPM firmware. The AP coordinates these
> + operations through the ACPM IPC protocol.
> +
> +properties:
> + compatible:
> + const: google,gs101-tmu-top
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: APB peripheral clock (PCLK) for TMU register access.
> +
> + interrupts:
> + maxItems: 1
> +
> + "#thermal-sensor-cells":
> + const: 1
> +
> + samsung,acpm-ipc:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: Phandle to the ACPM IPC node.
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> + - "#thermal-sensor-cells"
> + - samsung,acpm-ipc
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/google,gs101.h>
> +
> + thermal-sensor@100a0000 {
> + compatible = "google,gs101-tmu-top";
> + reg = <0x100a0000 0x800>;
> + clocks = <&cmu_misc CLK_GOUT_MISC_TMU_TOP_PCLK>;
> + interrupts = <GIC_SPI 769 IRQ_TYPE_LEVEL_HIGH 0>;
> + #thermal-sensor-cells = <1>;
> + samsung,acpm-ipc = <&acpm_ipc>;
> + };
>
> --
> 2.54.0.1013.g208068f2d8-goog
>
^ permalink raw reply
* [PATCH 02/11] iio: adc: change from %ld to %pe for PTR_ERR() printing
From: Vojtěch Krátký @ 2026-06-04 11:19 UTC (permalink / raw)
To: linux-iio
Cc: Vojtěch Krátký, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Wolfram Sang, Sakari Ailus, Linus Walleij,
linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <20260604111921.106936-1-vo.kratky@seznam.cz>
Found by Coccinelle.
No functional change intended.
Signed-off-by: Vojtěch Krátký <vo.kratky@seznam.cz>
---
drivers/iio/adc/sun4i-gpadc-iio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
index 479115ea50bf..5d7a61abcaea 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -508,7 +508,7 @@ static int sun4i_gpadc_probe_dt(struct platform_device *pdev,
&sun4i_gpadc_regmap_config);
if (IS_ERR(info->regmap)) {
ret = PTR_ERR(info->regmap);
- dev_err(&pdev->dev, "failed to init regmap: %d\n", ret);
+ dev_err(&pdev->dev, "failed to init regmap: %pe\n", info->regmap);
return ret;
}
@@ -639,8 +639,8 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
*/
if (IS_ERR(info->tzd) && PTR_ERR(info->tzd) != -ENODEV) {
dev_err(&pdev->dev,
- "could not register thermal sensor: %ld\n",
- PTR_ERR(info->tzd));
+ "could not register thermal sensor: %pe\n",
+ info->tzd);
return PTR_ERR(info->tzd);
}
}
--
2.54.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: realtek: Add I/O level detector
From: Yu-Chun Lin @ 2026-06-04 11:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, tychang
Cc: eleanor.lin, cy.huang, stanley_chang, james.tai, afaerber,
devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc
In-Reply-To: <20260604111821.975624-1-eleanor.lin@realtek.com>
Add io-level-detector node with pinctrl configurations for 1.8V/3.3V
voltage selection on RGMII, SDIO, CSI, SD, UART1, AIO, and eMMC.
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
This patch depends on this pinctrl node patch [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?id=50d92732d10e
---
arch/arm64/boot/dts/realtek/kent-pinctrl.dtsi | 108 ++++++++++++++++++
arch/arm64/boot/dts/realtek/kent.dtsi | 28 +++++
2 files changed, 136 insertions(+)
create mode 100644 arch/arm64/boot/dts/realtek/kent-pinctrl.dtsi
diff --git a/arch/arm64/boot/dts/realtek/kent-pinctrl.dtsi b/arch/arm64/boot/dts/realtek/kent-pinctrl.dtsi
new file mode 100644
index 000000000000..ec7e33034b96
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/kent-pinctrl.dtsi
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+/*
+ * Copyright (c) 2022-2026 Realtek Semiconductor Corp.
+ */
+
+&iso_pinctrl {
+ aio_vsel_1v8_pins: aio-vsel-1v8-pins {
+ pins = "gpio_98", "gpio_99", "gpio_100", "gpio_101", "gpio_102", "gpio_103",
+ "gpio_104", "gpio_105", "gpio_106", "gpio_107", "gpio_108", "gpio_109",
+ "gpio_110", "gpio_111", "gpio_112";
+ power-source = <0>;
+ input-threshold-voltage-microvolt = <1800000>;
+ };
+
+ aio_vsel_3v3_pins: aio-vsel-3v3-pins {
+ pins = "gpio_98", "gpio_99", "gpio_100", "gpio_101", "gpio_102", "gpio_103",
+ "gpio_104", "gpio_105", "gpio_106", "gpio_107", "gpio_108", "gpio_109",
+ "gpio_110", "gpio_111", "gpio_112";
+ power-source = <1>;
+ input-threshold-voltage-microvolt = <3300000>;
+ };
+
+ csi_vsel_1v8_pins: csi-vsel-1v8-pins {
+ pins = "csi_vdsel";
+ function = "csi_1v8";
+ };
+
+ csi_vsel_3v3_pins: csi-vsel-3v3-pins {
+ pins = "csi_vdsel";
+ function = "csi_3v3";
+ };
+
+ rgmii_vsel_1v8_pins: rgmii-vsel-1v8-pins {
+ pins = "rgmii_vdsel";
+ function = "rgmii_1v8";
+ };
+
+ rgmii_vsel_3v3_pins: rgmii-vsel-3v3-pins {
+ pins = "rgmii_vdsel";
+ function = "rgmii_3v3";
+ };
+
+ sdio_vsel_1v8_pins: sdio-vsel-1v8-pins {
+ pins = "gpio_45", "gpio_46", "gpio_47", "gpio_48", "gpio_49", "gpio_50";
+ power-source = <0>;
+ };
+
+ sdio_vsel_3v3_pins: sdio-vsel-3v3-pins {
+ pins = "gpio_45", "gpio_46", "gpio_47", "gpio_48", "gpio_49", "gpio_50";
+ power-source = <1>;
+ };
+
+ uart1_vsel_1v8_pins: uart1-vsel-1v8-pins {
+ pins = "gpio_8", "gpio_9", "gpio_10", "gpio_11";
+ power-source = <0>;
+ input-threshold-voltage-microvolt = <1800000>;
+ };
+
+ uart1_vsel_3v3_pins: uart1-vsel-3v3-pins {
+ pins = "gpio_8", "gpio_9", "gpio_10", "gpio_11";
+ power-source = <1>;
+ input-threshold-voltage-microvolt = <3300000>;
+ };
+};
+
+&main2_pinctrl {
+ emmc_vsel_1v8_pins: emmc-vsel-1v8-pins {
+ pins = "emmc_rst_n",
+ "emmc_dd_sb",
+ "emmc_clk",
+ "emmc_cmd",
+ "emmc_data_0",
+ "emmc_data_1",
+ "emmc_data_2",
+ "emmc_data_3",
+ "emmc_data_4",
+ "emmc_data_5",
+ "emmc_data_6",
+ "emmc_data_7";
+ power-source = <0>;
+ };
+
+ emmc_vsel_3v3_pins: emmc-vsel-3v3-pins {
+ pins = "emmc_rst_n",
+ "emmc_dd_sb",
+ "emmc_clk",
+ "emmc_cmd",
+ "emmc_data_0",
+ "emmc_data_1",
+ "emmc_data_2",
+ "emmc_data_3",
+ "emmc_data_4",
+ "emmc_data_5",
+ "emmc_data_6",
+ "emmc_data_7";
+ power-source = <1>;
+ };
+
+ sd_vsel_1v8_pins: sd-vsel-1v8-pins {
+ pins = "gpio_40", "gpio_41", "hif_clk", "hif_data", "hif_en", "hif_rdy";
+ power-source = <0>;
+ };
+
+ sd_vsel_3v3_pins: sd-vsel-3v3-pins {
+ pins = "gpio_40", "gpio_41", "hif_clk", "hif_data", "hif_en", "hif_rdy";
+ power-source = <1>;
+ };
+};
diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi b/arch/arm64/boot/dts/realtek/kent.dtsi
index 8d4293cd4c03..f18b975c3593 100644
--- a/arch/arm64/boot/dts/realtek/kent.dtsi
+++ b/arch/arm64/boot/dts/realtek/kent.dtsi
@@ -125,6 +125,32 @@ psci: psci {
method = "smc";
};
+ io_level_detector: io-level-detector {
+ compatible = "realtek,rtd1625-io-detect";
+ pinctrl-names = "rgmii_1v8", "rgmii_3v3",
+ "sdio_1v8", "sdio_3v3",
+ "csi_1v8", "csi_3v3",
+ "sd_1v8", "sd_3v3",
+ "uart1_1v8", "uart1_3v3",
+ "aio_1v8", "aio_3v3",
+ "emmc_1v8", "emmc_3v3";
+ pinctrl-0 = <&rgmii_vsel_1v8_pins>;
+ pinctrl-1 = <&rgmii_vsel_3v3_pins>;
+ pinctrl-2 = <&sdio_vsel_1v8_pins>;
+ pinctrl-3 = <&sdio_vsel_3v3_pins>;
+ pinctrl-4 = <&csi_vsel_1v8_pins>;
+ pinctrl-5 = <&csi_vsel_3v3_pins>;
+ pinctrl-6 = <&sd_vsel_1v8_pins>;
+ pinctrl-7 = <&sd_vsel_3v3_pins>;
+ pinctrl-8 = <&uart1_vsel_1v8_pins>;
+ pinctrl-9 = <&uart1_vsel_3v3_pins>;
+ pinctrl-10 = <&aio_vsel_1v8_pins>;
+ pinctrl-11 = <&aio_vsel_3v3_pins>;
+ pinctrl-12 = <&emmc_vsel_1v8_pins>;
+ pinctrl-13 = <&emmc_vsel_3v3_pins>;
+ realtek,iso-pinctrl = <&iso_pinctrl>;
+ };
+
soc@0 {
compatible = "simple-bus";
ranges = <0x0 0x0 0x0 0x40000>, /* boot code */
@@ -184,3 +210,5 @@ gic: interrupt-controller@ff100000 {
};
};
};
+
+#include "kent-pinctrl.dtsi"
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] soc: realtek: Add driver for DHC I/O level detector
From: Yu-Chun Lin @ 2026-06-04 11:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, tychang
Cc: eleanor.lin, cy.huang, stanley_chang, james.tai, afaerber,
devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc
In-Reply-To: <20260604111821.975624-1-eleanor.lin@realtek.com>
From: Tzuyi Chang <tychang@realtek.com>
Add driver support for the Realtek DHC I/O level detector.
The driver reads hardware registers to determine the current I/O voltage
levels (e.g., 1.8V or 3.3V) for specific IP blocks. Based on the
detection results, it selects and applies the appropriate pinctrl states
to ensure the correct pad configurations are used.
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
MAINTAINERS | 1 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/realtek/Kconfig | 21 ++++
drivers/soc/realtek/Makefile | 2 +
drivers/soc/realtek/rtd-io-detect.c | 152 ++++++++++++++++++++++++++++
6 files changed, 178 insertions(+)
create mode 100644 drivers/soc/realtek/Kconfig
create mode 100644 drivers/soc/realtek/Makefile
create mode 100644 drivers/soc/realtek/rtd-io-detect.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9ec290e38b44..6121eb4f904e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3379,6 +3379,7 @@ F: arch/arm/boot/dts/realtek/
F: arch/arm/mach-realtek/
F: arch/arm64/boot/dts/realtek/
F: drivers/pinctrl/realtek/
+F: drivers/soc/realtek/
ARM/RISC-V/RENESAS ARCHITECTURE
M: Geert Uytterhoeven <geert+renesas@glider.be>
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index a2d65adffb80..d63b9d4dc042 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -20,6 +20,7 @@ source "drivers/soc/microchip/Kconfig"
source "drivers/soc/nuvoton/Kconfig"
source "drivers/soc/pxa/Kconfig"
source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/realtek/Kconfig"
source "drivers/soc/renesas/Kconfig"
source "drivers/soc/rockchip/Kconfig"
source "drivers/soc/samsung/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index c9e689080ceb..8678b1001183 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -26,6 +26,7 @@ obj-y += nuvoton/
obj-y += pxa/
obj-y += amlogic/
obj-y += qcom/
+obj-y += realtek/
obj-y += renesas/
obj-y += rockchip/
obj-$(CONFIG_SOC_SAMSUNG) += samsung/
diff --git a/drivers/soc/realtek/Kconfig b/drivers/soc/realtek/Kconfig
new file mode 100644
index 000000000000..4c5796c7f9f7
--- /dev/null
+++ b/drivers/soc/realtek/Kconfig
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Realtek SoC drivers
+#
+menu "Realtek SoC drivers"
+ depends on ARCH_REALTEK || COMPILE_TEST
+
+config RTD_IO_LEVEL_DETECT
+ tristate "Realtek DHC I/O Level Detector"
+ depends on PINCTRL_RTD
+ select MFD_SYSCON
+ default ARCH_REALTEK
+ help
+ Enable support for the Realtek DHC I/O level detector.
+
+ This driver handles the auto-detection of I/O signaling levels
+ (such as 1.8V and 3.3V) and dynamically configures the pad states
+ for specific IP blocks.
+
+endmenu
+
diff --git a/drivers/soc/realtek/Makefile b/drivers/soc/realtek/Makefile
new file mode 100644
index 000000000000..c307e5bdb52d
--- /dev/null
+++ b/drivers/soc/realtek/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_RTD_IO_LEVEL_DETECT) += rtd-io-detect.o
diff --git a/drivers/soc/realtek/rtd-io-detect.c b/drivers/soc/realtek/rtd-io-detect.c
new file mode 100644
index 000000000000..84ef8ea23cb5
--- /dev/null
+++ b/drivers/soc/realtek/rtd-io-detect.c
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Realtek DHC I/O Level Detect driver
+ *
+ * Copyright (c) 2026 Realtek Semiconductor Corp.
+ */
+
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+
+struct rtd_io_detect_desc_info {
+ const char *name;
+ const char *state_1v8;
+ const char *state_3v3;
+ unsigned int reg_offset;
+ unsigned int en_offset;
+ unsigned int status_offset;
+};
+
+struct rtd_io_detect_descs {
+ const struct rtd_io_detect_desc_info *info;
+ int num_descs;
+};
+
+struct rtd_io_detect_data {
+ const struct rtd_io_detect_descs *descs;
+ struct regmap *base;
+ struct device *dev;
+};
+
+#define RTD_IO_DETECT_DESC(_name, _reg_off, _en_off, _st_off) \
+ { \
+ .name = #_name, \
+ .state_1v8 = #_name "_1v8", \
+ .state_3v3 = #_name "_3v3", \
+ .reg_offset = _reg_off, \
+ .en_offset = _en_off, \
+ .status_offset = _st_off, \
+ }
+
+static const struct rtd_io_detect_desc_info rtd1625_io_detect_desc[] = {
+ RTD_IO_DETECT_DESC(rgmii, 0x1a0, 8, 1),
+ RTD_IO_DETECT_DESC(sd, 0x1a0, 9, 2),
+ RTD_IO_DETECT_DESC(csi, 0x1a0, 10, 3),
+ RTD_IO_DETECT_DESC(sdio, 0x1a0, 11, 4),
+ RTD_IO_DETECT_DESC(uart1, 0x1a0, 12, 5),
+ RTD_IO_DETECT_DESC(aio, 0x1a0, 13, 6),
+ RTD_IO_DETECT_DESC(emmc, 0x1a0, 14, 7),
+};
+
+static const struct rtd_io_detect_descs rtd1625_io_detect_descs = {
+ .info = rtd1625_io_detect_desc,
+ .num_descs = ARRAY_SIZE(rtd1625_io_detect_desc),
+};
+
+static void detect_io_set(struct pinctrl *pinctrl,
+ const struct rtd_io_detect_desc_info *desc,
+ struct rtd_io_detect_data *data)
+{
+ struct pinctrl_state *state_1v8;
+ struct pinctrl_state *state_3v3;
+ unsigned int val;
+ int ret;
+
+ state_1v8 = pinctrl_lookup_state(pinctrl, desc->state_1v8);
+ if (IS_ERR(state_1v8)) {
+ dev_err(data->dev, "Failed to lookup %s state: %ld\n",
+ desc->state_1v8, PTR_ERR(state_1v8));
+ return;
+ }
+
+ state_3v3 = pinctrl_lookup_state(pinctrl, desc->state_3v3);
+ if (IS_ERR(state_3v3)) {
+ dev_err(data->dev, "Failed to lookup %s state: %ld\n",
+ desc->state_3v3, PTR_ERR(state_3v3));
+ return;
+ }
+
+ regmap_update_bits(data->base, desc->reg_offset,
+ BIT(desc->en_offset), BIT(desc->en_offset));
+
+ regmap_read(data->base, desc->reg_offset, &val);
+
+ ret = pinctrl_select_state(pinctrl,
+ (val & BIT(desc->status_offset)) ? state_3v3 : state_1v8);
+ if (ret)
+ dev_err(data->dev, "Failed to select pinctrl state\n");
+}
+
+static int rtd_io_detect_probe(struct platform_device *pdev)
+{
+ struct rtd_io_detect_data *data;
+ struct device *dev = &pdev->dev;
+ struct device_node *pinctrl_np;
+ struct pinctrl *pinctrl;
+ int i;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ pinctrl_np = of_parse_phandle(dev->of_node, "realtek,iso-pinctrl", 0);
+ if (!pinctrl_np) {
+ dev_err(dev, "Failed to find ISO pinctrl node\n");
+ return -ENODEV;
+ }
+
+ data->base = device_node_to_regmap(pinctrl_np);
+ of_node_put(pinctrl_np);
+
+ if (IS_ERR(data->base))
+ return dev_err_probe(dev, PTR_ERR(data->base), "Failed to get regmap\n");
+
+ data->descs = device_get_match_data(dev);
+ if (!data->descs)
+ return -EINVAL;
+
+ pinctrl = devm_pinctrl_get(dev);
+ if (IS_ERR(pinctrl))
+ return dev_err_probe(dev, PTR_ERR(pinctrl), "Failed to get pinctrl\n");
+
+ data->dev = dev;
+
+ for (i = 0; i < data->descs->num_descs; i++)
+ detect_io_set(pinctrl, &data->descs->info[i], data);
+
+ return 0;
+}
+
+static const struct of_device_id rtd_io_detect_of_matches[] = {
+ { .compatible = "realtek,rtd1625-io-detect", .data = &rtd1625_io_detect_descs },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rtd_io_detect_of_matches);
+
+static struct platform_driver rtd_io_detect_driver = {
+ .driver = {
+ .name = "rtd_io_level_detect",
+ .of_match_table = rtd_io_detect_of_matches,
+ },
+ .probe = rtd_io_detect_probe,
+};
+module_platform_driver(rtd_io_detect_driver);
+
+MODULE_DESCRIPTION("Realtek DHC SoC I/O Level Detect driver");
+MODULE_LICENSE("GPL");
+
--
2.43.0
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: soc: realtek: Add Realtek DHC I/O level detector
From: Yu-Chun Lin @ 2026-06-04 11:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, tychang
Cc: eleanor.lin, cy.huang, stanley_chang, james.tai, afaerber,
devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc
In-Reply-To: <20260604111821.975624-1-eleanor.lin@realtek.com>
From: Tzuyi Chang <tychang@realtek.com>
Add device tree binding documentation for the Realtek DHC I/O level
detector.
This hardware block is responsible for detecting the I/O signaling
levels (e.g., 1.8V or 3.3V) of various interfaces (RGMII, SDIO, eMMC,
etc.) and applying the corresponding pad configurations via pinctrl
states.
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
.../realtek/realtek,rtd1625-io-detect.yaml | 77 +++++++++++++++++++
1 file changed, 77 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/realtek/realtek,rtd1625-io-detect.yaml
diff --git a/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1625-io-detect.yaml b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1625-io-detect.yaml
new file mode 100644
index 000000000000..badf27212dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/realtek/realtek,rtd1625-io-detect.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2026 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/realtek/realtek,rtd1625-io-detect.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC I/O Level Detector
+
+maintainers:
+ - Tzuyi Chang <tychang@realtek.com>
+
+description: |
+ The Realtek DHC I/O Level Detector is a hardware block that detects I/O
+ signaling levels (such as 1.8V or 3.3V) to determine the correct pad
+ configurations for specific IP blocks.
+
+properties:
+ compatible:
+ const: realtek,rtd1625-io-detect
+
+ pinctrl-names:
+ items:
+ - const: rgmii_1v8
+ - const: rgmii_3v3
+ - const: sdio_1v8
+ - const: sdio_3v3
+ - const: csi_1v8
+ - const: csi_3v3
+ - const: sd_1v8
+ - const: sd_3v3
+ - const: uart1_1v8
+ - const: uart1_3v3
+ - const: aio_1v8
+ - const: aio_3v3
+ - const: emmc_1v8
+ - const: emmc_3v3
+
+ realtek,iso-pinctrl:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Pinctrl phandle containing I/O detection registers.
+
+required:
+ - compatible
+ - pinctrl-names
+ - realtek,iso-pinctrl
+
+additionalProperties: false
+
+examples:
+ - |
+ io-detect {
+ compatible = "realtek,rtd1625-io-detect";
+ pinctrl-names = "rgmii_1v8", "rgmii_3v3",
+ "sdio_1v8", "sdio_3v3",
+ "csi_1v8", "csi_3v3",
+ "sd_1v8", "sd_3v3",
+ "uart1_1v8", "uart1_3v3",
+ "aio_1v8", "aio_3v3",
+ "emmc_1v8", "emmc_3v3";
+ pinctrl-0 = <&rgmii_vsel_1v8_pins>;
+ pinctrl-1 = <&rgmii_vsel_3v3_pins>;
+ pinctrl-2 = <&sdio_vsel_1v8_pins>;
+ pinctrl-3 = <&sdio_vsel_3v3_pins>;
+ pinctrl-4 = <&csi_vsel_1v8_pins>;
+ pinctrl-5 = <&csi_vsel_3v3_pins>;
+ pinctrl-6 = <&sd_vsel_1v8_pins>;
+ pinctrl-7 = <&sd_vsel_3v3_pins>;
+ pinctrl-8 = <&uart1_vsel_1v8_pins>;
+ pinctrl-9 = <&uart1_vsel_3v3_pins>;
+ pinctrl-10 = <&aio_vsel_1v8_pins>;
+ pinctrl-11 = <&aio_vsel_3v3_pins>;
+ pinctrl-12 = <&emmc_vsel_1v8_pins>;
+ pinctrl-13 = <&emmc_vsel_3v3_pins>;
+ realtek,iso-pinctrl = <&iso_pinctrl>;
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] soc: realtek: Add Realtek DHC I/O level detector support
From: Yu-Chun Lin @ 2026-06-04 11:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, tychang
Cc: eleanor.lin, cy.huang, stanley_chang, james.tai, afaerber,
devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc
Hi all,
This patch series introduces support for the Realtek DHC I/O level detector.
The Realtek DHC I/O level detector is a hardware block responsible for
detecting the I/O signaling levels (1.8V or 3.3V) of various IP blocks
such as RGMII, SDIO, eMMC, CSI, SD, UART1, and AIO.
The driver reads the hardware registers to determine the current I/O voltage
levels. Based on these detection results, it dynamically selects and applies
the appropriate pinctrl states to ensure the correct pad configurations are
used for each interface.
Thanks,
Yu-Chun
Tzuyi Chang (2):
dt-bindings: soc: realtek: Add Realtek DHC I/O level detector
soc: realtek: Add driver for DHC I/O level detector
Yu-Chun Lin (1):
arm64: dts: realtek: Add I/O level detector
.../realtek/realtek,rtd1625-io-detect.yaml | 77 +++++++++
MAINTAINERS | 1 +
arch/arm64/boot/dts/realtek/kent-pinctrl.dtsi | 108 +++++++++++++
arch/arm64/boot/dts/realtek/kent.dtsi | 28 ++++
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/realtek/Kconfig | 21 +++
drivers/soc/realtek/Makefile | 2 +
drivers/soc/realtek/rtd-io-detect.c | 152 ++++++++++++++++++
9 files changed, 391 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/realtek/realtek,rtd1625-io-detect.yaml
create mode 100644 arch/arm64/boot/dts/realtek/kent-pinctrl.dtsi
create mode 100644 drivers/soc/realtek/Kconfig
create mode 100644 drivers/soc/realtek/Makefile
create mode 100644 drivers/soc/realtek/rtd-io-detect.c
--
2.43.0
^ permalink raw reply
* [PATCH] KVM: arm64: Sanitise host vCPU fields in flush_hyp_vcpu()
From: Hyunwoo Kim @ 2026-06-04 11:18 UTC (permalink / raw)
To: maz, oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, imv4bel
flush_hyp_vcpu() copies the host vCPU context and vGIC state into the
hyp's private vCPU on every run. ctxt_to_vcpu() expects a guest context
to have a NULL __hyp_running_vcpu, which is only ever set on the host
context, so that it resolves the vCPU via container_of(). The vGIC list
register save and restore expect used_lrs to stay within the number of
implemented list registers. While this is generally the case,
flush_hyp_vcpu() copies both fields verbatim from the host vCPU and
enforces neither expectation.
Fix by clearing __hyp_running_vcpu and clamping used_lrs after the copy.
Fixes: be66e67f1750 ("KVM: arm64: Use the pKVM hyp vCPU structure in handle___kvm_vcpu_run()")
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 06db299c37a89..ef9318ff0c25e 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -7,6 +7,7 @@
#include <hyp/adjust_pc.h>
#include <hyp/switch.h>
+#include <asm/arch_gicv3.h>
#include <asm/pgtable-types.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_emulate.h>
@@ -128,6 +129,9 @@ static void flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
hyp_vcpu->vcpu.arch.ctxt = host_vcpu->arch.ctxt;
+ /* A guest context must keep a NULL __hyp_running_vcpu. */
+ hyp_vcpu->vcpu.arch.ctxt.__hyp_running_vcpu = NULL;
+
hyp_vcpu->vcpu.arch.mdcr_el2 = host_vcpu->arch.mdcr_el2;
hyp_vcpu->vcpu.arch.hcr_el2 &= ~(HCR_TWI | HCR_TWE);
hyp_vcpu->vcpu.arch.hcr_el2 |= READ_ONCE(host_vcpu->arch.hcr_el2) &
@@ -139,6 +143,13 @@ static void flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
hyp_vcpu->vcpu.arch.vgic_cpu.vgic_v3 = host_vcpu->arch.vgic_cpu.vgic_v3;
+ /* Bound the host-provided used_lrs by the implemented list registers. */
+ if (static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
+ hyp_vcpu->vcpu.arch.vgic_cpu.vgic_v3.used_lrs =
+ min_t(unsigned int,
+ hyp_vcpu->vcpu.arch.vgic_cpu.vgic_v3.used_lrs,
+ (read_gicreg(ICH_VTR_EL2) & 0xf) + 1);
+
hyp_vcpu->vcpu.arch.pid = host_vcpu->arch.pid;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v1] KVM: arm64: Restore POR_EL0 access to host EL0
From: Joey Gouly @ 2026-06-04 10:54 UTC (permalink / raw)
To: kvmarm
Cc: joey.gouly, Marc Zyngier, Oliver Upton, Suzuki K Poulose,
Zenghui Yu, Steffen Eiden, linux-arm-kernel
CPTR_EL2.E0POE was being cleared in __deactivate_cptr_traps_vhe(), which meant
that any accesses to POR_EL0 from host EL0 would trap and be reported to
userspace as an Illegal instruction. This would happen after running any VM,
regardless if it used POE or not.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Link: https://sashiko.dev/#/patchset/20260602155430.2088142-1-maz@kernel.org?part=1
---
Tested by (paraphrased):
$ ./read_por_el0
$ ./lkvm run -f kvm-unit-tests/timer.flat
$ ./read_por_el0 # This gets "Illegal instruction"
Also ran the above flow in a nested VM.
arch/arm64/kvm/hyp/include/hyp/switch.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index 320cd45d49c5..e9b36a3b27bb 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -181,6 +181,8 @@ static inline void __deactivate_cptr_traps_vhe(struct kvm_vcpu *vcpu)
val |= CPACR_EL1_ZEN;
if (cpus_have_final_cap(ARM64_SME))
val |= CPACR_EL1_SMEN;
+ if (cpus_have_final_cap(ARM64_HAS_S1POE))
+ val |= CPACR_EL1_E0POE;
write_sysreg(val, cpacr_el1);
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2 0/3] pinctrl: sunxi: a523: fix GPIO IRQ operation
From: Andre Przywara @ 2026-06-04 10:54 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, Linus Walleij
In-Reply-To: <20260327113006.3135663-1-andre.przywara@arm.com>
On Fri, 27 Mar 2026 11:30:03 +0000
Andre Przywara <andre.przywara@arm.com> wrote:
Hi,
> this is the minimal fix version for the GPIO IRQ operation on the
> Allwinner A523/A527/T527 SoCs. SD card detection is broken as a result,
> which is a major annoyance. Those patches here fix that problem, and
> should go into v7.0 still, if possible.
what is the status of this series, please? We missed v7.0 back then, but
please can we take this now, for v7.1? There are review tags for every
patch, and this fixes SD card operation on all A523/A527/T572 boards.
The series still applies cleanly on current master, if I should resend
anyway, please let me know.
Cheers,
Andre
> I dropped the more involved fixes from v1, the risk for regressions is
> now very low:
> - The quirk flag is just dropped from the A523, not the other SoCs. I
> confirmed this again with an experiment, for both the primary and
> secondary pincontroller. This avoids fixing the workaround code for
> now, which is more involved, but for now unneeded.
> - The DT patch just adds the missing interrupt. The IRQ association was
> always wrong and never worked, so this can't make it possibly worse.
> Together those two patches (plus the required binding change) fix the
> problem, I would appreciate if this could be taken ASAP, into v7.0 still.
> The generic pinctrl code is now untouched, which makes this also much
> easier to backport, and drops the dependencies on other v7.0-rc fixes.
>
> Bases on v7.0-rc1, but applies on later revisions as well.
>
> Please have a look and test, especially on A523/A527/T527 boards!
>
> Changelog v1 .. v2:
> - drop generic pinctrl fixes (for now)
> - drop quirk removal from other SoCs (for now)
> - add Chen-Yu's tag
>
> Cheers,
> Andre
>
> Andre Przywara (3):
> pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
> dt-bindings: pinctrl: sun55i-a523: increase IRQ banks number
> arm64: dts: allwinner: a523: Add missing GPIO interrupt
>
> .../bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml | 8 ++++----
> arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi | 3 ++-
> drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 1 -
> drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c | 1 -
> 4 files changed, 6 insertions(+), 7 deletions(-)
>
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Sudeep Holla @ 2026-06-04 10:55 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Aneesh Kumar K.V (Arm), linux-coco, linux-arm-kernel,
linux-kernel, Sudeep Holla, Catalin Marinas, Greg KH,
Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland,
Will Deacon, Steven Price
In-Reply-To: <bee6166c-f63e-4692-a874-b80b7a6f6dc4@arm.com>
On Thu, Jun 04, 2026 at 11:24:05AM +0100, Suzuki K Poulose wrote:
> On 04/06/2026 10:21, Sudeep Holla wrote:
> > On Wed, May 27, 2026 at 03:32:32PM +0530, Aneesh Kumar K.V (Arm) wrote:
> > > The Arm CCA guest TSM provider currently binds through the arm-cca-dev
> > > platform device. Like arm-smccc-trng, this device is not an independent
> > > platform resource; it is a software representation of the RSI firmware
> > > service discovered through SMCCC.
> > >
> > > Move RSI discovery into the SMCCC firmware driver. When the SMCCC conduit
> > > is SMC and the RSI ABI version check succeeds, create an arm-rsi-dev SMCCC
> > > device. Convert the Arm CCA guest TSM provider to an SMCCC driver so it
> > > binds to that discovered RSI service and keeps module autoloading through
> > > the SMCCC device id table.
> > >
> > > Keep the old arm-cca-dev platform-device registration for now. Userspace
> > > has used that device as a Realm-guest indicator, so removing it is left to
> > > a follow-up patch that adds a replacement sysfs ABI.
> > >
> > > Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> > > ---
> > > arch/arm64/include/asm/rsi.h | 2 +-
> > > arch/arm64/kernel/rsi.c | 2 +-
> > > drivers/firmware/smccc/Makefile | 4 ++
> > > drivers/firmware/smccc/rmm.c | 25 ++++++++
> > > drivers/firmware/smccc/rmm.h | 17 ++++++
> > > drivers/firmware/smccc/smccc.c | 8 +++
> > > drivers/virt/coco/arm-cca-guest/Kconfig | 1 +
> > > drivers/virt/coco/arm-cca-guest/Makefile | 2 +
> > > .../{arm-cca-guest.c => arm-cca.c} | 60 +++++++++----------
> > > 9 files changed, 89 insertions(+), 32 deletions(-)
> > > create mode 100644 drivers/firmware/smccc/rmm.c
> > > create mode 100644 drivers/firmware/smccc/rmm.h
> > > rename drivers/virt/coco/arm-cca-guest/{arm-cca-guest.c => arm-cca.c} (85%)
> > >
> > > diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
> > > index 88b50d660e85..2d2d363aaaee 100644
> > > --- a/arch/arm64/include/asm/rsi.h
> > > +++ b/arch/arm64/include/asm/rsi.h
> > > @@ -10,7 +10,7 @@
> > > #include <linux/jump_label.h>
> > > #include <asm/rsi_cmds.h>
> > > -#define RSI_PDEV_NAME "arm-cca-dev"
> > > +#define RSI_DEV_NAME "arm-rsi-dev"
> > > DECLARE_STATIC_KEY_FALSE(rsi_present);
> > > diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
> > > index 92160f2e57ff..da440f71bb64 100644
> > > --- a/arch/arm64/kernel/rsi.c
> > > +++ b/arch/arm64/kernel/rsi.c
> > > @@ -161,7 +161,7 @@ void __init arm64_rsi_init(void)
> > > }
> > > static struct platform_device rsi_dev = {
> > > - .name = RSI_PDEV_NAME,
> > > + .name = "arm-cca-dev",
> > > .id = PLATFORM_DEVID_NONE
> > > };
> > > diff --git a/drivers/firmware/smccc/Makefile b/drivers/firmware/smccc/Makefile
> > > index 40d19144a860..33c850aaff4d 100644
> > > --- a/drivers/firmware/smccc/Makefile
> > > +++ b/drivers/firmware/smccc/Makefile
> > > @@ -2,3 +2,7 @@
> > > #
> > > obj-$(CONFIG_HAVE_ARM_SMCCC_DISCOVERY) += smccc.o kvm_guest.o
> > > obj-$(CONFIG_ARM_SMCCC_SOC_ID) += soc_id.o
> > > +
> > > +ifeq ($(CONFIG_HAVE_ARM_SMCCC_DISCOVERY),y)
> > > +obj-$(CONFIG_ARM64) += rmm.o
> > > +endif
> > > diff --git a/drivers/firmware/smccc/rmm.c b/drivers/firmware/smccc/rmm.c
> > > new file mode 100644
> > > index 000000000000..d572f47e955c
> > > --- /dev/null
> > > +++ b/drivers/firmware/smccc/rmm.c
> > > @@ -0,0 +1,25 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Copyright (C) 2026 Arm Limited
> > > + */
> > > +
> > > +#include <linux/arm-smccc-bus.h>
> > > +#include <linux/err.h>
> > > +#include <linux/printk.h>
> > > +
> > > +#include "rmm.h"
> > > +
> > > +void __init register_rsi_device(void)
> > > +{
> > > + unsigned long ret;
> > > +
> > > + if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
> > > + return;
> > > +
> > > + ret = rsi_request_version(RSI_ABI_VERSION, NULL, NULL);
> > > + if (ret != RSI_SUCCESS)
> > > + return;
> > > +
> > > + if (IS_ERR(arm_smccc_device_register(RSI_DEV_NAME)))
> > > + pr_err("%s: could not register device\n", RSI_DEV_NAME);
> > > +}
> >
> > OK, I had something else in my mind when I started looking at 1/4. I didn't
> > expect each device added on this bus comes up with it's own way to enumerate
> > it. IMO, it defeats the purpose of building the smccc bus. We may find the
> > specs for each feature deviated a bit but we can have a generic probe
> > IMO, let's try that before exploring per feature probe function.
>
> I guess this is ideal, but see below.
>
> >
> > I have a brief sketch of what I think we should aim for(uncompiled/untested)
> > below. Let me know if that makes sense. I just based it on your bus code.
> >
> > Regards,
> > Sudeep
> >
> > -->8
> >
> > diff --git c/drivers/firmware/smccc/smccc.c w/drivers/firmware/smccc/smccc.c
> > index 695c920a8087..450605ddfab6 100644
> > --- c/drivers/firmware/smccc/smccc.c
> > +++ w/drivers/firmware/smccc/smccc.c
> > @@ -9,21 +9,58 @@
> > #include <linux/init.h>
> > #include <linux/arm-smccc.h>
> > #include <linux/kernel.h>
> > -#include <linux/platform_device.h>
> > #include <linux/arm-smccc-bus.h>
> > #include <linux/idr.h>
> > #include <linux/slab.h>
> >
> > -#include <asm/archrandom.h>
> > -
> > static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
> > static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
> > static DEFINE_IDA(arm_smccc_bus_id);
> >
> > -bool __ro_after_init smccc_trng_available = false;
> > +struct smccc_device_info {
> > + u32 func_id;
> > + bool requires_smc;
I wanted to ask this but just forgot.
RSI uses SMC because the Realm is calling the RMM, not the host hypervisor.
Using HVC would make RSI look like a hypervisor ABI and would blur the trust
boundary, is that right assumption ?
I assume the conduit derived from PSCI node for the realms will always be
SMC and it shouldn't be a problem. I mean there won't be a case where you
would need HVC as conduit within the realm VM kernel ?
> > + unsigned long min_return;
>
> Is this viable for all ? There may be additional restrictions around
> the return values and further SMC calls ?
Fair enough, but do you have examples currently ?
> Which brings us to call backs and we kind of have a variant of that here.
>
I am fine with callback but need to keep the scope of it as minimum as
possible IMO. For me it's simple if that main FID for that feature is
implemented we create SMCCC device and probe can deal with all the extra
details, why won't that work ? Just trying to understand why the core
SMCCC bus need to know more or must provide a callback.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2 31/39] KVM: arm64: gic-v5: Add GICv5 SPI injection to irqfd
From: Vladimir Murzin @ 2026-06-04 10:51 UTC (permalink / raw)
To: Sascha Bischoff, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, kvm@vger.kernel.org
Cc: nd, maz@kernel.org, oliver.upton@linux.dev, Joey Gouly,
Suzuki Poulose, yuzenghui@huawei.com, peter.maydell@linaro.org,
lpieralisi@kernel.org, Timothy Hayes
In-Reply-To: <20260521144846.1899475-32-sascha.bischoff@arm.com>
Hi Sascha,
On 5/21/26 15:59, Sascha Bischoff wrote:
> Now that there is support for GICv5 SPIs in KVM, update
> vgic_irqfd_set_irq() to translate irqchip pins into GICv5 SPI IntIDs
> before injecting them.
>
> Also adjust IRQCHIP route validation for GICv5: use the configured SPI
> count, fall back to the default SPI count before VGIC init, and cap
> the accepted pin range to the generic irq routing table size.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> ---
> arch/arm64/kvm/vgic/vgic-irqfd.c | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-irqfd.c b/arch/arm64/kvm/vgic/vgic-irqfd.c
> index b9b86e3a6c862..3644516811214 100644
> --- a/arch/arm64/kvm/vgic/vgic-irqfd.c
> +++ b/arch/arm64/kvm/vgic/vgic-irqfd.c
> @@ -19,7 +19,12 @@ static int vgic_irqfd_set_irq(struct kvm_kernel_irq_routing_entry *e,
> struct kvm *kvm, int irq_source_id,
> int level, bool line_status)
> {
> - unsigned int spi_id = e->irqchip.pin + VGIC_NR_PRIVATE_IRQS;
> + unsigned int spi_id;
> +
> + if (kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V5)
> + spi_id = vgic_v5_make_spi(e->irqchip.pin);
> + else
> + spi_id = e->irqchip.pin + VGIC_NR_PRIVATE_IRQS;
>
> if (!vgic_valid_spi(kvm, spi_id))
> return -EINVAL;
> @@ -39,15 +44,24 @@ int kvm_set_routing_entry(struct kvm *kvm,
> struct kvm_kernel_irq_routing_entry *e,
> const struct kvm_irq_routing_entry *ue)
> {
> + unsigned int nr_pins = KVM_IRQCHIP_NUM_PINS;
> int r = -EINVAL;
>
> + if (vgic_is_v5(kvm)) {
> + nr_pins = kvm->arch.vgic.nr_spis;
> + if (!nr_pins)
> + nr_pins = VGIC_V5_DEFAULT_NR_SPIS;
> +
> + nr_pins = min(nr_pins, KVM_IRQCHIP_NUM_PINS);
> + }
> +
I have a few questions about these checks.
IIUC, there are two paths that can lead us here:
vgic_init()
-> kvm_vgic_setup_default_irq_routing()
-> kvm_set_irq_routing()
-> setup_routing_entry()
-> kvm_set_routing_entry()
where vgic_init() sets nr_spis to the default value if it has not
been configured already.
And:
kvm_vm_ioctl(KVM_SET_GSI_ROUTING)
-> kvm_set_irq_routing()
-> setup_routing_entry()
-> kvm_set_routing_entry()
where nr_spis would still be 0 if KVM_SET_GSI_ROUTING is used
before the vGIC is initialized. In that case, how much harm
processing with nr_spis set to 0? Wouldn't the routing be
overwritten once the vGIC is initialized anyway?
Also, IIUC, this is not specific to vGICv5 and appears to be
equally applicable to vGICv2/v3. If so, shouldn't we apply the
same validation logic to the non-vGICv5 cases as well?
Finally, it seems the core already enforces KVM_MAX_IRQ_ROUTES,
and we lower that limit to KVM_IRQCHIP_NUM_PINS. IIUC, nr_spis
limit for vGICv5 is FIELD_MAX(GICV5_IRS_IDR5_SPI_RANGE) which
exceeds both core and our private limit.
Would it be simpler/cleaner to reject nr_spis values provided
through KVM_DEV_ARM_VGIC_GRP_NR_IRQS rather than allowing them
and later capping the accepted pin range?
Thanks
Vladimir
> switch (ue->type) {
> case KVM_IRQ_ROUTING_IRQCHIP:
> e->set = vgic_irqfd_set_irq;
> e->irqchip.irqchip = ue->u.irqchip.irqchip;
> e->irqchip.pin = ue->u.irqchip.pin;
> - if ((e->irqchip.pin >= KVM_IRQCHIP_NUM_PINS) ||
> - (e->irqchip.irqchip >= KVM_NR_IRQCHIPS))
> + if (e->irqchip.pin >= nr_pins ||
> + e->irqchip.irqchip >= KVM_NR_IRQCHIPS)
> goto out;
> break;
> case KVM_IRQ_ROUTING_MSI:
> -- 2.34.1
>
^ permalink raw reply
* [GIT PULL] Apple SoC DT changes for v7.2
From: Sven Peter @ 2026-06-04 10:25 UTC (permalink / raw)
To: soc; +Cc: asahi, linux-arm-kernel, linux-kernel, Sven Peter
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux.git tags/apple-soc-dt-7.2
for you to fetch changes up to c65ab4905e5874a1a489c72da4d6e78a6c9b5943:
arm64: dts: apple: Initial t8122 (M3) device trees (2026-06-01 21:25:24 +0200)
----------------------------------------------------------------
Apple SoC DT update for 7.2
Add minimal device trees for all t8122 / base M3 based devices and some
required new compatibles to the dt-bindings. These are enough to boot
Linux on these devices to a simple serial console but future work is
required to make these machines useful for end users.
Signed-off-by: Sven Peter <sven@kernel.org>
----------------------------------------------------------------
Janne Grunau (5):
dt-bindings: arm: apple: apple,pmgr: Add t8122 compatible
dt-bindings: power: apple,pmgr-pwrstate: Add t8122 compatible
dt-bindings: pwm: apple,s5l-fpwm: Add t8122 compatible
dt-bindings: arm: apple: Add M3 based devices
arm64: dts: apple: Initial t8122 (M3) device trees
Documentation/devicetree/bindings/arm/apple.yaml | 18 +
.../devicetree/bindings/arm/apple/apple,pmgr.yaml | 4 +-
.../bindings/power/apple,pmgr-pwrstate.yaml | 4 +-
.../devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 1 +
arch/arm64/boot/dts/apple/Makefile | 5 +
arch/arm64/boot/dts/apple/t8122-j433.dts | 19 +
arch/arm64/boot/dts/apple/t8122-j434.dts | 19 +
arch/arm64/boot/dts/apple/t8122-j504.dts | 37 +
arch/arm64/boot/dts/apple/t8122-j613.dts | 35 +
arch/arm64/boot/dts/apple/t8122-j615.dts | 35 +
arch/arm64/boot/dts/apple/t8122-jxxx.dtsi | 48 +
arch/arm64/boot/dts/apple/t8122-pmgr.dtsi | 1149 ++++++++++++++++++++
arch/arm64/boot/dts/apple/t8122-usbpd-i2c.dtsi | 32 +
arch/arm64/boot/dts/apple/t8122.dtsi | 444 ++++++++
14 files changed, 1848 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/apple/t8122-j433.dts
create mode 100644 arch/arm64/boot/dts/apple/t8122-j434.dts
create mode 100644 arch/arm64/boot/dts/apple/t8122-j504.dts
create mode 100644 arch/arm64/boot/dts/apple/t8122-j613.dts
create mode 100644 arch/arm64/boot/dts/apple/t8122-j615.dts
create mode 100644 arch/arm64/boot/dts/apple/t8122-jxxx.dtsi
create mode 100644 arch/arm64/boot/dts/apple/t8122-pmgr.dtsi
create mode 100644 arch/arm64/boot/dts/apple/t8122-usbpd-i2c.dtsi
create mode 100644 arch/arm64/boot/dts/apple/t8122.dtsi
^ permalink raw reply
* Re: [PATCH v19 00/14] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
From: Vinod Koul @ 2026-06-04 10:24 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Bartosz Golaszewski, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Bjorn Andersson, Peter Ujfalusi,
Michal Simek, Frank Li, Andy Gross, Neil Armstrong, dmaengine,
linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <ah8G_ajPS1KhgPP_@linaro.org>
On 02-06-26, 18:38, Stephan Gerhold wrote:
> On Tue, May 26, 2026 at 03:10:48PM +0200, Bartosz Golaszewski wrote:
> > I feel like I fell into the trap of trying to address pre-existing
> > issues reported by sashiko and in the process provoking more reports so
> > let this be the last iteration where I do this. Vinod can we get this
> > queued for v7.2 now and iron out any previously existing problems in
> > tree?
>
> Thanks a lot for working on fixing all these issues!
>
> I agree there is no point addressing all the "pre-existing issues"
> pointed out by Sashiko, but have you looked through the other comments
> for new issues pointed out for your patches?
I hope Bart and Qualcomm can fix these driver issues as well
>
> Out of curiosity, I was looking a bit at the comments for [PATCH v19
> 06/14] dmaengine: qcom: bam_dma: add support for BAM locking [1]. There
> are 8 open comments there (Critical: 1, High: 6 and Medium: 1). From a
> quick look I would say most of these could be valid. The critical one
> about the usage of dma_cookie_assign() sounds a bit concerning to me, if
> it is true we would be basically breaking parts of the dmaengine API for
> consumers by inserting the lock descriptor in front of everything else.
Yes this seems to be a valid one. Attaching another descriptor for lock
does not sound right to me, as in this case causes descriptor to be
marked 'done' prematurely.
Honestly, I am not quite happy with the way lock is being handled here.
I would hope we can have some better suggestions. Adding a descriptor
for lock does not look right to me. We are adding odd hardware/firmware
behaviour on engine apis.
I had earlier suggested to lock always or lock only for hw/sw versions
supported inside the driver, that might be simplist solution without the
complexity added here
--
~Vinod
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Suzuki K Poulose @ 2026-06-04 10:24 UTC (permalink / raw)
To: Sudeep Holla, Aneesh Kumar K.V (Arm)
Cc: linux-coco, linux-arm-kernel, linux-kernel, Catalin Marinas,
Greg KH, Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi,
Mark Rutland, Will Deacon, Steven Price
In-Reply-To: <20260603-determined-bumblebee-of-promise-e633d6@sudeepholla>
On 04/06/2026 10:21, Sudeep Holla wrote:
> On Wed, May 27, 2026 at 03:32:32PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> The Arm CCA guest TSM provider currently binds through the arm-cca-dev
>> platform device. Like arm-smccc-trng, this device is not an independent
>> platform resource; it is a software representation of the RSI firmware
>> service discovered through SMCCC.
>>
>> Move RSI discovery into the SMCCC firmware driver. When the SMCCC conduit
>> is SMC and the RSI ABI version check succeeds, create an arm-rsi-dev SMCCC
>> device. Convert the Arm CCA guest TSM provider to an SMCCC driver so it
>> binds to that discovered RSI service and keeps module autoloading through
>> the SMCCC device id table.
>>
>> Keep the old arm-cca-dev platform-device registration for now. Userspace
>> has used that device as a Realm-guest indicator, so removing it is left to
>> a follow-up patch that adds a replacement sysfs ABI.
>>
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> ---
>> arch/arm64/include/asm/rsi.h | 2 +-
>> arch/arm64/kernel/rsi.c | 2 +-
>> drivers/firmware/smccc/Makefile | 4 ++
>> drivers/firmware/smccc/rmm.c | 25 ++++++++
>> drivers/firmware/smccc/rmm.h | 17 ++++++
>> drivers/firmware/smccc/smccc.c | 8 +++
>> drivers/virt/coco/arm-cca-guest/Kconfig | 1 +
>> drivers/virt/coco/arm-cca-guest/Makefile | 2 +
>> .../{arm-cca-guest.c => arm-cca.c} | 60 +++++++++----------
>> 9 files changed, 89 insertions(+), 32 deletions(-)
>> create mode 100644 drivers/firmware/smccc/rmm.c
>> create mode 100644 drivers/firmware/smccc/rmm.h
>> rename drivers/virt/coco/arm-cca-guest/{arm-cca-guest.c => arm-cca.c} (85%)
>>
>> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
>> index 88b50d660e85..2d2d363aaaee 100644
>> --- a/arch/arm64/include/asm/rsi.h
>> +++ b/arch/arm64/include/asm/rsi.h
>> @@ -10,7 +10,7 @@
>> #include <linux/jump_label.h>
>> #include <asm/rsi_cmds.h>
>>
>> -#define RSI_PDEV_NAME "arm-cca-dev"
>> +#define RSI_DEV_NAME "arm-rsi-dev"
>>
>> DECLARE_STATIC_KEY_FALSE(rsi_present);
>>
>> diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
>> index 92160f2e57ff..da440f71bb64 100644
>> --- a/arch/arm64/kernel/rsi.c
>> +++ b/arch/arm64/kernel/rsi.c
>> @@ -161,7 +161,7 @@ void __init arm64_rsi_init(void)
>> }
>>
>> static struct platform_device rsi_dev = {
>> - .name = RSI_PDEV_NAME,
>> + .name = "arm-cca-dev",
>> .id = PLATFORM_DEVID_NONE
>> };
>>
>> diff --git a/drivers/firmware/smccc/Makefile b/drivers/firmware/smccc/Makefile
>> index 40d19144a860..33c850aaff4d 100644
>> --- a/drivers/firmware/smccc/Makefile
>> +++ b/drivers/firmware/smccc/Makefile
>> @@ -2,3 +2,7 @@
>> #
>> obj-$(CONFIG_HAVE_ARM_SMCCC_DISCOVERY) += smccc.o kvm_guest.o
>> obj-$(CONFIG_ARM_SMCCC_SOC_ID) += soc_id.o
>> +
>> +ifeq ($(CONFIG_HAVE_ARM_SMCCC_DISCOVERY),y)
>> +obj-$(CONFIG_ARM64) += rmm.o
>> +endif
>> diff --git a/drivers/firmware/smccc/rmm.c b/drivers/firmware/smccc/rmm.c
>> new file mode 100644
>> index 000000000000..d572f47e955c
>> --- /dev/null
>> +++ b/drivers/firmware/smccc/rmm.c
>> @@ -0,0 +1,25 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2026 Arm Limited
>> + */
>> +
>> +#include <linux/arm-smccc-bus.h>
>> +#include <linux/err.h>
>> +#include <linux/printk.h>
>> +
>> +#include "rmm.h"
>> +
>> +void __init register_rsi_device(void)
>> +{
>> + unsigned long ret;
>> +
>> + if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
>> + return;
>> +
>> + ret = rsi_request_version(RSI_ABI_VERSION, NULL, NULL);
>> + if (ret != RSI_SUCCESS)
>> + return;
>> +
>> + if (IS_ERR(arm_smccc_device_register(RSI_DEV_NAME)))
>> + pr_err("%s: could not register device\n", RSI_DEV_NAME);
>> +}
>
> OK, I had something else in my mind when I started looking at 1/4. I didn't
> expect each device added on this bus comes up with it's own way to enumerate
> it. IMO, it defeats the purpose of building the smccc bus. We may find the
> specs for each feature deviated a bit but we can have a generic probe
> IMO, let's try that before exploring per feature probe function.
I guess this is ideal, but see below.
>
> I have a brief sketch of what I think we should aim for(uncompiled/untested)
> below. Let me know if that makes sense. I just based it on your bus code.
>
> Regards,
> Sudeep
>
> -->8
>
> diff --git c/drivers/firmware/smccc/smccc.c w/drivers/firmware/smccc/smccc.c
> index 695c920a8087..450605ddfab6 100644
> --- c/drivers/firmware/smccc/smccc.c
> +++ w/drivers/firmware/smccc/smccc.c
> @@ -9,21 +9,58 @@
> #include <linux/init.h>
> #include <linux/arm-smccc.h>
> #include <linux/kernel.h>
> -#include <linux/platform_device.h>
> #include <linux/arm-smccc-bus.h>
> #include <linux/idr.h>
> #include <linux/slab.h>
>
> -#include <asm/archrandom.h>
> -
> static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
> static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
> static DEFINE_IDA(arm_smccc_bus_id);
>
> -bool __ro_after_init smccc_trng_available = false;
> +struct smccc_device_info {
> + u32 func_id;
> + bool requires_smc;
> + unsigned long min_return;
Is this viable for all ? There may be additional restrictions around
the return values and further SMC calls ? Which brings us to call backs
and we kind of have a variant of that here.
Suzuki
> + const char *device_name;
> +};
> +
> +bool __ro_after_init smccc_trng_available;
> s32 __ro_after_init smccc_soc_id_version = SMCCC_RET_NOT_SUPPORTED;
> s32 __ro_after_init smccc_soc_id_revision = SMCCC_RET_NOT_SUPPORTED;
>
> +static const struct smccc_device_info smccc_devices[] __initconst = {
> + {
> + .func_id = ARM_SMCCC_TRNG_VERSION,
> + .requires_smc = false,
> + .min_return = ARM_SMCCC_TRNG_MIN_VERSION,
> + .device_name = "arm-smccc-trng",
> + },
> +};
> +
> +static bool __init
> +smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
> +{
> + struct arm_smccc_res res;
> + unsigned long ret;
> +
> + if (!IS_ENABLED(CONFIG_ARM64))
> + return false;
> +
> + if (smccc_conduit == SMCCC_CONDUIT_NONE)
> + return false;
> +
> + if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
> + return false;
> +
> + arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
> + ret = res.a0;
> +
> + if ((s32)ret < 0)
> + return false;
> +
> + return ret >= smccc_dev->min_return;
> +}
> +
> void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> {
> struct arm_smccc_res res;
> @@ -31,7 +68,7 @@ void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
> smccc_version = version;
> smccc_conduit = conduit;
>
> - smccc_trng_available = smccc_probe_trng();
> + smccc_trng_available = smccc_probe_smccc_device(&smccc_devices[0]);
>
> if ((smccc_version >= ARM_SMCCC_VERSION_1_2) &&
> (smccc_conduit != SMCCC_CONDUIT_NONE)) {
> @@ -241,14 +278,20 @@ subsys_initcall(arm_smccc_bus_init);
>
> static int __init smccc_devices_init(void)
> {
> - struct platform_device *pdev;
> -
> - if (smccc_trng_available) {
> - pdev = platform_device_register_simple("smccc_trng", -1,
> - NULL, 0);
> - if (IS_ERR(pdev))
> - pr_err("smccc_trng: could not register device: %ld\n",
> - PTR_ERR(pdev));
> + const struct smccc_device_info *smccc_dev;
> + struct arm_smccc_device *sdev;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
> + smccc_dev = &smccc_devices[i];
> +
> + if (!smccc_probe_smccc_device(smccc_dev))
> + continue;
> +
> + sdev = arm_smccc_device_register(smccc_dev->device_name);
> + if (IS_ERR(sdev))
> + pr_err("%s: could not register device: %ld\n",
> + smccc_dev->device_name, PTR_ERR(sdev));
> }
>
> return 0;
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox