* Re: [PATCH] arm64: dts: hisilicon: hi3660-hikey960: move role-switch endpoint into connector
From: Akash Sukhavasi @ 2026-06-03 18:54 UTC (permalink / raw)
To: xuwei5; +Cc: krzk+dt, robh, conor+dt, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260520215325.55353-1-akash.sukhavasi@gmail.com>
On Wed, May 20, 2026 at 04:53:25PM -0500, Akash Sukhavasi wrote:
> The rt1711h Type-C controller on the HiKey960 has the USB role-switch
> endpoint placed as a top-level 'port' node, outside the connector
> subnode. This triggers two dtbs_check warnings against
> richtek,rt1711h.yaml:
>
> - 'port' does not match any of the regexes: '^pinctrl-[0-9]+$'
> - connector:ports: 'port@0' is a required property
>
> Move the role-switch endpoint into the connector's port@0, which is
> where usb-connector.yaml expects it. Update the DWC3 remote-endpoint
> phandle accordingly.
>
> The TCPM core (tcpm.c) looks up the role switch starting from the
> connector fwnode via fwnode_usb_role_switch_get(). With the endpoint
> inside the connector's port@0, it is found through the primary lookup
> path rather than the device-level fallback.
>
> Cross-compiled for arm64. Verified with dt_binding_check and
> dtbs_check. Not runtime-tested on hardware.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
> ---
> .../boot/dts/hisilicon/hi3660-hikey960.dts | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> index c6056a85c..27fb08d34 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -550,6 +550,12 @@ usb_con: connector {
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + usb_con_hs: endpoint {
> + remote-endpoint = <&dwc3_role_switch>;
> + };
> + };
> port@1 {
> reg = <1>;
> usb_con_ss: endpoint {
> @@ -558,15 +564,6 @@ usb_con_ss: endpoint {
> };
> };
> };
> - port {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - rt1711h_ep: endpoint@0 {
> - reg = <0>;
> - remote-endpoint = <&dwc3_role_switch>;
> - };
> - };
> };
>
> adv7533: adv7533@39 {
> @@ -683,7 +680,7 @@ port {
> #size-cells = <0>;
> dwc3_role_switch: endpoint@0 {
> reg = <0>;
> - remote-endpoint = <&rt1711h_ep>;
> + remote-endpoint = <&usb_con_hs>;
> };
>
> dwc3_ss: endpoint@1 {
> --
Hi Wei,
Friendly ping on this one.
Also, is the hikey960 board still actively taking fixes?
--
Thanks,
Akash
^ permalink raw reply
* Re: [PATCH] arm: gen-mach-types: don't include absolute filename
From: Ryan Eatmon @ 2026-06-03 18:58 UTC (permalink / raw)
To: Uwe Kleine-König, Sascha Hauer
Cc: Russell King, linux-arm-kernel, linux-kernel, Marco Felsch,
Alexander Stein, kernel
In-Reply-To: <aiBDAQmQFKeN033y@monoceros>
On 6/3/2026 10:09 AM, Uwe Kleine-König wrote:
> Hello Sascha,
>
> On Wed, Jun 03, 2026 at 04:12:10PM +0200, Sascha Hauer wrote:
>> mach-types.h is part of the kapi and as such shipped in the
>> linux-headers package. The embedded build path makes that package
>> non-reproducible without going through an extra step of normalizing the
>> path. YOCTO has similar problems in the kernel debug source package.
>>
>> Make the path relative to the kernel source tree which is enough to
>> find the tool that has generated the file.
>>
>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> Compared to my old patch this is simpler, I like it.
>
> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Agreed.
Acked-by: Ryan Eatmon <reatmon@ti.com>
> Thanks
> Uwe
--
Ryan Eatmon reatmon@ti.com
-----------------------------------------
Texas Instruments, Inc. - LCPD - MGTS
^ permalink raw reply
* [PATCH v6 3/3] arm64: defconfig: Enable drivers for BeagleBadge
From: Judith Mendez @ 2026-06-03 19:23 UTC (permalink / raw)
To: Judith Mendez, Nishanth Menon, Vignesh Raghavendra
Cc: Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel, Andrew Davis,
Bryan Brattlof, Jason Kridner, Robert Nelson, Conor Dooley
In-Reply-To: <20260603192305.1347908-1-jm@ti.com>
Enable drivers used on BeagleBadge[1]:
- LED PWM Multicolor driver as a module
- MCP SPI IO Expander driver as a module
- Seven Segment display GPIO driver as module
- Temperature Sensor driver as a module
[1] https://www.beagleboard.org/boards/beaglebadge
Signed-off-by: Judith Mendez <jm@ti.com>
---
Changes since v5:
- No change
---
arch/arm64/configs/defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d905a0777f939..5cfb7f6f2ae78 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -634,6 +634,7 @@ CONFIG_PINCTRL_BRCMSTB=y
CONFIG_PINCTRL_BCM2712=y
CONFIG_PINCTRL_DA9062=m
CONFIG_PINCTRL_MAX77620=y
+CONFIG_PINCTRL_MCP23S08=m
CONFIG_PINCTRL_RK805=m
CONFIG_PINCTRL_SINGLE=y
CONFIG_PINCTRL_SX150X=m
@@ -766,6 +767,7 @@ CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_PWM_FAN=m
CONFIG_SENSORS_RASPBERRYPI_HWMON=m
CONFIG_SENSORS_SL28CPLD=m
+CONFIG_SENSORS_SHT4x=m
CONFIG_SENSORS_AMC6821=m
CONFIG_SENSORS_INA2XX=m
CONFIG_SENSORS_INA3221=m
@@ -955,6 +957,8 @@ CONFIG_VIDEO_IMX412=m
CONFIG_VIDEO_OV5640=m
CONFIG_VIDEO_OV5645=m
CONFIG_VIDEO_S5KJN1=m
+CONFIG_AUXDISPLAY=y
+CONFIG_SEG_LED_GPIO=m
CONFIG_DRM=m
CONFIG_DRM_I2C_NXP_TDA998X=m
CONFIG_DRM_HDLCD=m
@@ -1332,6 +1336,7 @@ CONFIG_LEDS_GPIO=y
CONFIG_LEDS_PWM=y
CONFIG_LEDS_SYSCON=y
CONFIG_LEDS_QCOM_FLASH=m
+CONFIG_LEDS_PWM_MULTICOLOR=m
CONFIG_LEDS_QCOM_LPG=m
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_DISK=y
--
2.54.0
^ permalink raw reply related
* [PATCH v6 2/3] arm64: dts: ti: Add k3-am62l3-beaglebadge
From: Judith Mendez @ 2026-06-03 19:23 UTC (permalink / raw)
To: Judith Mendez, Nishanth Menon, Vignesh Raghavendra
Cc: Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel, Andrew Davis,
Bryan Brattlof, Jason Kridner, Robert Nelson, Conor Dooley
In-Reply-To: <20260603192305.1347908-1-jm@ti.com>
BeagleBoard.org BeagleBadge is a compact, affordable open source
hardware single board computer based on the Texas Instruments AM62L3
SoC designed for IoT and embedded applications with low power
consumption. Expansion is provided over open standards based headers
including QWIIC and GPIO interfaces.
https://www.beagleboard.org/boards/beaglebadge
Co-developed-by: Andrew Davis <afd@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
---
Changes since v5:
- Fixed aliases/chosen nodes
- Sort Makefile items alphabetically
- Use dual license: GPL-2.0-only or MIT
---
arch/arm64/boot/dts/ti/Makefile | 1 +
.../boot/dts/ti/k3-am62l3-beaglebadge.dts | 657 ++++++++++++++++++
2 files changed, 658 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 5269c9619b65c..3f1904a5b622f 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -40,6 +40,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62a7-phyboard-lyra-rdk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am62d2-evm.dtb
# Boards with AM62Lx SoCs
+dtb-$(CONFIG_ARCH_K3) += k3-am62l3-beaglebadge.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am62l3-evm.dtb
# Boards with AM62Px SoC
diff --git a/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts b/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
new file mode 100644
index 0000000000000..ee2d562baf51a
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
@@ -0,0 +1,657 @@
+// SPDX-License-Identifier: GPL-2.0-only or MIT
+/*
+ * https://www.beagleboard.org/boards/beaglebadge
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include "k3-am62l3.dtsi"
+#include "k3-pinctrl.h"
+
+/ {
+ compatible = "beagle,am62l3-beaglebadge", "ti,am62l3";
+ model = "BeagleBoard.org BeagleBadge";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c4 = &wkup_i2c0;
+ mmc1 = &sdhci1;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ };
+
+ memory@80000000 {
+ /* 256MB */
+ reg = <0x00000000 0x80000000 0x00000000 0x10000000>;
+ device_type = "memory";
+ bootph-all;
+ };
+
+ thermal-zones {
+ wkup0-thermal {
+ polling-delay-passive = <250>; /* milliSeconds */
+ polling-delay = <500>; /* milliSeconds */
+ thermal-sensors = <&vtm0 0>;
+
+ trips {
+ crit0 {
+ temperature = <125000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
+ gpio_keys: gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ button-select {
+ label = "SELECT";
+ linux,code = <KEY_SELECT>;
+ gpios = <&gpio0 26 GPIO_ACTIVE_LOW>;
+ };
+
+ button-back {
+ label = "BACK";
+ linux,code = <KEY_BACK>;
+ gpios = <&gpio0 104 GPIO_ACTIVE_LOW>;
+ };
+
+ button-up {
+ label = "UP";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio0 32 GPIO_ACTIVE_LOW>;
+ };
+
+ button-down {
+ label = "DOWN";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio0 42 GPIO_ACTIVE_LOW>;
+ };
+
+ button-left {
+ label = "LEFT";
+ linux,code = <KEY_LEFT>;
+ gpios = <&gpio0 31 GPIO_ACTIVE_LOW>;
+ };
+
+ button-right {
+ label = "RIGHT";
+ linux,code = <KEY_RIGHT>;
+ gpios = <&gpio0 95 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ multicolor-led {
+ compatible = "pwm-leds-multicolor";
+
+ multi-led {
+ color = <LED_COLOR_ID_RGB>;
+ max-brightness = <255>;
+
+ led-red {
+ pwms = <&ecap2 0 10000000 0>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led-green {
+ pwms = <&ecap1 0 10000000 0>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led-blue {
+ pwms = <&epwm1 1 10000000 0>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+
+ seven-segment-left {
+ compatible = "gpio-7-segment";
+ segment-gpios = <&mcp23s18 0 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 1 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 2 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 3 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 4 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 5 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 6 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 7 GPIO_ACTIVE_LOW>;
+ };
+
+ seven-segment-right {
+ compatible = "gpio-7-segment";
+ segment-gpios = <&mcp23s18 8 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 9 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 10 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 11 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 12 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 13 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 14 GPIO_ACTIVE_LOW>,
+ <&mcp23s18 15 GPIO_ACTIVE_LOW>;
+ };
+
+ pwm-beeper {
+ compatible = "pwm-beeper";
+ pwms = <&epwm0 1 1000000 0>;
+ amp-supply = <&sensor_3v3>;
+ };
+
+ vsys_out: regulator-0 {
+ /* output of BQ24070 */
+ compatible = "regulator-fixed";
+ regulator-name = "VSYS_OUT";
+ regulator-min-microvolt = <4400000>;
+ regulator-max-microvolt = <4400000>;
+ regulator-always-on;
+ regulator-boot-on;
+ bootph-all;
+ };
+
+ vcc_3v3_main: regulator-1 {
+ /* output of TPS62A06 */
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_MAIN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys_out>;
+ regulator-always-on;
+ regulator-boot-on;
+ bootph-all;
+ };
+
+ vdd_3v3: regulator-2 {
+ /* output of TPS22965 */
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_3v3_main>;
+ regulator-always-on;
+ regulator-boot-on;
+ bootph-all;
+ };
+
+ vdd_3v3_sd: regulator-3 {
+ /* TPS22918DBVR */
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_3V3_SD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-boot-on;
+ enable-active-high;
+ gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vdd_3v3_sd_ena_pins_default>;
+ bootph-all;
+ };
+
+ sensor_3v3: regulator-4 {
+ /* TPS22918DBVR */
+ compatible = "regulator-fixed";
+ regulator-name = "Sensor_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-boot-on;
+ enable-active-high;
+ gpios = <&wkup_gpio0 1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sensor_3v3_ena_pins_default>;
+ bootph-all;
+ };
+};
+
+&pmx0 {
+ uart0_pins_default: uart0-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01b8, PIN_OUTPUT, 0) /* (C13) UART0_TXD */
+ AM62LX_IOPAD(0x01b4, PIN_INPUT, 0) /* (D13) UART0_RXD */
+ >;
+ bootph-all;
+ };
+
+ uart0_pins_wakeup: uart0-wakeup-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01b8, PIN_OUTPUT, 0) /* (C13) UART0_TXD */
+ AM62LX_IOPAD(0x01b4, PIN_INPUT | PIN_WKUP_EN, 0) /* (D13) UART0_RXD */
+ >;
+ bootph-all;
+ };
+
+ uart1_pins_default: uart1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x019c, PIN_OUTPUT, 2) /* (A12) MCASP0_ACLKR.UART1_TXD */
+ AM62LX_IOPAD(0x0198, PIN_INPUT, 2) /* (C11) MCASP0_AFSR.UART1_RXD */
+ AM62LX_IOPAD(0x0180, PIN_INPUT, 2) /* (A8) MCASP0_AXR3.UART1_CTSn */
+ AM62LX_IOPAD(0x0184, PIN_OUTPUT, 2) /* (B10) MCASP0_AXR2.UART1_RTSn */
+ >;
+ bootph-all;
+ };
+
+ usr_button_pins_default: usr-button-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00a4, PIN_INPUT, 7) /* (H18) GPMC0_AD11.GPIO0_26 */
+ AM62LX_IOPAD(0x01e4, PIN_INPUT, 7) /* (D16) EXT_REFCLK1.GPIO0_104 */
+ AM62LX_IOPAD(0x00c0, PIN_INPUT, 7) /* (N19) GPMC0_ADVn_ALE.GPIO0_32 */
+ AM62LX_IOPAD(0x00e8, PIN_INPUT, 7) /* (L19) GPMC0_CSn1.GPIO0_42 */
+ AM62LX_IOPAD(0x00b8, PIN_INPUT, 7) /* (L21) GPMC0_CLK.GPIO0_31 */
+ AM62LX_IOPAD(0x01c0, PIN_INPUT, 7) /* (B13) UART0_RTSn.GPIO0_95 */
+ >;
+ bootph-all;
+ };
+
+ i2c0_pins_default: i2c0-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01cc, PIN_INPUT_PULLUP, 0) /* (B7) I2C0_SCL */
+ AM62LX_IOPAD(0x01d0, PIN_INPUT_PULLUP, 0) /* (A7) I2C0_SDA */
+ >;
+ bootph-all;
+ };
+
+ i2c1_pins_default: i2c1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01d4, PIN_INPUT_PULLUP, 0) /* (D7) I2C1_SCL */
+ AM62LX_IOPAD(0x01d8, PIN_INPUT_PULLUP, 0) /* (A6) I2C1_SDA */
+ >;
+ bootph-all;
+ };
+
+ i2c2_qwiic_pins_default: i2c2-qwiic-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01dc, PIN_INPUT_PULLUP, 0) /* (B8) I2C2_SCL */
+ AM62LX_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D8) I2C2_SDA */
+ >;
+ bootph-all;
+ };
+
+ vdd_3v3_sd_ena_pins_default: vdd-3v3-sd-ena-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x07c, PIN_OUTPUT, 7) /* (L23) GPMC0_AD1.GPIO0_16 */
+ >;
+ bootph-all;
+ };
+
+ sensor_3v3_ena_pins_default: sensor-3v3-ena-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x004, PIN_OUTPUT, 7) /* (AA23) WKUP_UART0_TXD.WKUP_GPIO0_1 */
+ >;
+ bootph-all;
+ };
+
+ mmc1_pins_default: mmc1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0230, PIN_INPUT, 0) /* (Y3) MMC1_CMD */
+ AM62LX_IOPAD(0x0228, PIN_OUTPUT, 0) /* (Y2) MMC1_CLK */
+ AM62LX_IOPAD(0x0224, PIN_INPUT, 0) /* (AA1) MMC1_DAT0 */
+ AM62LX_IOPAD(0x0220, PIN_INPUT, 0) /* (Y4) MMC1_DAT1 */
+ AM62LX_IOPAD(0x021c, PIN_INPUT, 0) /* (AA2) MMC1_DAT2 */
+ AM62LX_IOPAD(0x0218, PIN_INPUT, 0) /* (AB2) MMC1_DAT3 */
+ AM62LX_IOPAD(0x0234, PIN_INPUT, 7) /* (B6) MMC1_SDCD.GPIO0_122 */
+ >;
+ bootph-all;
+ };
+
+ usb1_pins_default: usb1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0248, PIN_INPUT | PIN_DS_PULLUD_ENABLE |
+ PIN_DS_PULL_UP, 0) /* (A5) USB1_DRVVBUS */
+ >;
+ bootph-all;
+ };
+
+ pwm_beeper_pins_default: pwm-beeper-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00b0, PIN_OUTPUT, 4) /* (F22) GPMC0_AD14.EHRPWM0_B */
+ >;
+ };
+
+ pmic_irq_pins_default: pmic-irq-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x01e8, PIN_INPUT, 0) /* (C8) EXTINTn */
+ >;
+ bootph-all;
+ };
+
+ wkup_i2c0_pins_default: wkup-i2c0-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0010, PIN_INPUT_PULLUP, 0) /* (AB22) WKUP_I2C0_SCL */
+ AM62LX_IOPAD(0x0014, PIN_INPUT_PULLUP, 0) /* (AA22) WKUP_I2C0_SDA */
+ >;
+ bootph-all;
+ };
+
+ rgb_led_ecap2_pins_default: rgb-led-ecap2-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0190, PIN_OUTPUT, 2) /* (A11) MCASP0_ACLKX.ECAP2_IN_APWM_OUT */
+ >;
+ };
+
+ rgb_led_ecap1_pins_default: rgb-led-ecap1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0188, PIN_OUTPUT, 2) /* (A9) MCASP0_AXR1.ECAP1_IN_APWM_OUT */
+ >;
+ };
+
+ rgb_led_epwm1_pins_default: rgb-led-epwm1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x018c, PIN_OUTPUT, 5) /* (B9) MCASP0_AXR0.EHRPWM1_B */
+ >;
+ };
+
+ spi1_pins_default: spi1-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x008c, PIN_OUTPUT, 4) /* (H22) GPMC0_AD5.SPI1_CLK */
+ AM62LX_IOPAD(0x0088, PIN_OUTPUT, 4) /* (K23) GPMC0_AD4.SPI1_CS0 */
+ AM62LX_IOPAD(0x0080, PIN_INPUT, 4) /* (K22) GPMC0_AD2.SPI1_D0 */
+ AM62LX_IOPAD(0x0084, PIN_OUTPUT, 4) /* (J23) GPMC0_AD3.SPI1_D1 */
+ >;
+ bootph-all;
+ };
+
+ spi3_pins_default: spi3-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00d0, PIN_OUTPUT, 5) /* (P22) GPMC0_BE1n.SPI3_CLK */
+ AM62LX_IOPAD(0x00cc, PIN_OUTPUT, 5) /* (P23) GPMC0_BE0n_CLE.SPI3_CS0 */
+ AM62LX_IOPAD(0x00d4, PIN_INPUT, 5) /* (N23) GPMC0_WAIT0.SPI3_D0 */
+ AM62LX_IOPAD(0x00d8, PIN_OUTPUT, 5) /* (N22) GPMC0_WAIT1.SPI3_D1 */
+ >;
+ };
+
+ mcp23s18_reset_pins_default: mcp23s18-reset-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00a0, PIN_OUTPUT, 7) /* (H21) GPMC0_AD10.GPIO0_25 */
+ >;
+ };
+
+ epwm2_pins_default: epwm2-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00c4, PIN_OUTPUT, 4) /* (N20) GPMC0_OEn_REn.EHRPWM2_A */
+ >;
+ };
+
+ lora_control_pins_default: lora-control-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00c8, PIN_OUTPUT, 7) /* (M19) GPMC0_WEn.GPIO0_34 */
+ AM62LX_IOPAD(0x00e4, PIN_OUTPUT, 7) /* (L20) GPMC0_CSn0.GPIO0_41 */
+ AM62LX_IOPAD(0x01a4, PIN_INPUT, 7) /* (D11) SPI0_CS1.GPIO0_88 */
+ AM62LX_IOPAD(0x01bc, PIN_INPUT, 7) /* (B14) UART0_CTSn.GPIO0_94 */
+ >;
+ bootph-all;
+ };
+
+ gpio0_pins_default: gpio0-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x0078, PIN_OUTPUT, 7) /* (L22) GPMC0_AD0.GPIO0_15 */
+ AM62LX_IOPAD(0x00e0, PIN_INPUT, 7) /* (M21) GPMC0_DIR.GPIO0_40 */
+ AM62LX_IOPAD(0x00ec, PIN_OUTPUT, 7) /* (M23) GPMC0_CSn2.GPIO0_43 */
+ AM62LX_IOPAD(0x00f0, PIN_INPUT, 7) /* (M22) GPMC0_CSn3.GPIO0_44 */
+ AM62LX_IOPAD(0x0194, PIN_OUTPUT, 7) /* (B11) MCASP0_AFSX.GPIO0_84 */
+ >;
+ bootph-all;
+ };
+};
+
+&uart0 {
+ wakeup-source;
+ pinctrl-0 = <&uart0_pins_default>;
+ pinctrl-1 = <&uart0_pins_wakeup>;
+ pinctrl-names = "default", "wakeup";
+ bootph-all;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_default>;
+ bootph-all;
+ status = "okay";
+
+ /* T&H Sensor */
+ th-sensor@44 {
+ compatible = "sensirion,sht4x";
+ reg = <0x44>;
+ };
+
+ /* EEPROM */
+ eeprom@50 {
+ /* FT24C32A-ELRT */
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ };
+
+ /* Fuel Gauge */
+ fuel-gauge@55 {
+ compatible = "ti,bq27541";
+ reg = <0x55>;
+ };
+
+ /* IMU Sensor */
+ accelerometer@6a {
+ compatible = "st,lsm6ds3tr-c";
+ reg = <0x6a>;
+ vdd-supply = <&vcc_3v3_main>;
+ vddio-supply = <&vcc_3v3_main>;
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_qwiic_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&wkup_i2c0 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_i2c0_pins_default>;
+ bootph-all;
+ status = "okay";
+
+ tps65214: pmic@30 {
+ compatible = "ti,tps65214";
+ reg = <0x30>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+ buck1-supply = <&vcc_3v3_main>;
+ buck2-supply = <&vcc_3v3_main>;
+ buck3-supply = <&vcc_3v3_main>;
+ ldo1-supply = <&vcc_3v3_main>;
+ ldo2-supply = <&vcc_3v3_main>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_irq_pins_default>;
+ ti,power-button;
+ bootph-all;
+
+ regulators {
+ buck1_reg: buck1 {
+ regulator-name = "VDD_CORE";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck2_reg: buck2 {
+ regulator-name = "VDD_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck3_reg: buck3 {
+ regulator-name = "VDD_LPDDR4";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = "VDDA_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = "PMIC_VDD_RTC";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+};
+
+&gpio0 {
+ gpio-line-names = "","","","","","","","","","", /* 0-9 */
+ "","","","","","BOOST_5V_ENA","VDD_3V3_SD_ENA","","","", /* 10-19 */
+ "","","","","","MCP23S18_RESET","BTN_SELECT","","","", /* 20-29 */
+ "","BTN_LEFT","BTN_UP","","LORA_RESET","","","","","", /* 30-39 */
+ "GAUGE_BATLOW","LORA_RFSW","BTN_DOWN","USB_RST","MBUS_INT","","","","","", /* 40-49 */
+ "","WLAN_EN","","","","","","","","", /* 50-59 */
+ "","","","","","","","","","", /* 60-69 */
+ "","","","","","","","","","", /* 70-79 */
+ "","","","","MBUS_RST","","","","LORA_BUSY","", /* 80-89 */
+ "","","","","LORA_DIO","BTN_RIGHT","","","","", /* 90-99 */
+ "","","","","BTN_BACK","","","","","", /* 100-109 */
+ "","","","","","","","","","", /* 110-119 */
+ "","","SD_CD","","",""; /* 120-125 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio0_pins_default>, <&usr_button_pins_default>, <&lora_control_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&wkup_gpio0 {
+ gpio-line-names = "","SENSOR_3V3_ENA","","","","","",""; /* 0-7 */
+ bootph-all;
+ status = "okay";
+};
+
+&sdhci1 {
+ /* SD/MMC */
+ vmmc-supply = <&vdd_3v3_sd>;
+ disable-wp;
+ cd-gpios = <&gpio0 122 GPIO_ACTIVE_LOW>;
+ cd-debounce-delay-ms = <100>;
+ ti,fails-without-test-cd;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&epwm0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_beeper_pins_default>;
+ status = "okay";
+};
+
+&epwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgb_led_epwm1_pins_default>;
+ status = "okay";
+};
+
+&epwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&epwm2_pins_default>;
+ status = "okay";
+};
+
+&ecap1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgb_led_ecap1_pins_default>;
+ status = "okay";
+};
+
+&ecap2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgb_led_ecap2_pins_default>;
+ status = "okay";
+};
+
+&usbss0 {
+ ti,vbus-divider;
+ status = "okay";
+};
+
+&usb0 {
+ usb-role-switch;
+ bootph-all;
+ status = "okay";
+};
+
+&usbss1 {
+ ti,vbus-divider;
+ bootph-all;
+ status = "okay";
+};
+
+&usb1 {
+ dr_mode = "host";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&spi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins_default>;
+ status = "okay";
+
+ mcp23s18: gpio@0 {
+ compatible = "microchip,mcp23s18";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ reset-gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcp23s18_reset_pins_default>;
+ microchip,spi-present-mask = /bits/ 8 <0x01>;
+ };
+};
+
+&spi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi3_pins_default>;
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v6 1/3] dt-bindings: arm: ti: Add am62l3-beaglebadge
From: Judith Mendez @ 2026-06-03 19:23 UTC (permalink / raw)
To: Judith Mendez, Nishanth Menon, Vignesh Raghavendra
Cc: Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel, Andrew Davis,
Bryan Brattlof, Jason Kridner, Robert Nelson, Conor Dooley
In-Reply-To: <20260603192305.1347908-1-jm@ti.com>
This board is based on ti,am62l3.
https://www.beagleboard.org/boards/beaglebadge
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes since v5:
- No change
---
Documentation/devicetree/bindings/arm/ti/k3.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 2a6a9441c23de..d9cd3fb712fdd 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -40,6 +40,7 @@ properties:
- description: K3 AM62L3 SoC and Boards
items:
- enum:
+ - beagle,am62l3-beaglebadge
- ti,am62l3-evm
- const: ti,am62l3
--
2.54.0
^ permalink raw reply related
* [PATCH v6 0/3] arm64: dts/bindings: Add support for BeagleBadge
From: Judith Mendez @ 2026-06-03 19:23 UTC (permalink / raw)
To: Judith Mendez, Nishanth Menon, Vignesh Raghavendra
Cc: Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel, Andrew Davis,
Bryan Brattlof, Jason Kridner, Robert Nelson, Conor Dooley
Hi,
BeagleBoard.org BeagleBadge[1] is a compact, affordable open source
hardware [2] single board computer based on the Texas Instruments AM62L3
SoC designed for IoT and embedded applications. Add base support for
the same.
SD boot:
Link: https://gist.github.com/jmenti/e9e95848336fda0e4b5acb37f2fe64a0
This patch series adds:
- Device tree bindings update for am62l3-badge
- Device tree source for BeagleBadge board
- Defconfig: drivers for BeagleBadge
Changelog since v5:
DTS
- Fixed aliases/chosen nodes
- Sort Makefile items alphabetically
- Use dual license: GPL-2.0-only or MIT
v5
Link: https://lore.kernel.org/all/20260526235417.1326187-1-jm@ti.com/
v4
Link: https://lore.kernel.org/all/20260515153541.294698-1-jm@ti.com/
v3
Link: https://lore.kernel.org/all/20260513233447.2713737-1-jm@ti.com/
V2
Link: https://lore.kernel.org/all/20260508230341.1891450-1-jm@ti.com/
V1
Link: https://lore.kernel.org/all/20260501233148.4180391-1-jm@ti.com/
Patch series depends on:
Link: https://lore.kernel.org/all/20260513231154.2703292-1-jm@ti.com/
[1] https://www.beagleboard.org/boards/beaglebadge
[2] https://github.com/beagleboard/BeagleBadge/blob/main/design/BeagleBadge_RevA_V0.7_SCH_251107.pdf
Judith Mendez (3):
dt-bindings: arm: ti: Add am62l3-beaglebadge
arm64: dts: ti: Add k3-am62l3-beaglebadge
arm64: defconfig: Enable drivers for BeagleBadge
.../devicetree/bindings/arm/ti/k3.yaml | 1 +
arch/arm64/boot/dts/ti/Makefile | 1 +
.../boot/dts/ti/k3-am62l3-beaglebadge.dts | 657 ++++++++++++++++++
arch/arm64/configs/defconfig | 5 +
4 files changed, 664 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
--
2.54.0
^ permalink raw reply
* [PATCH 1/2] crypto: atmel-i2c - improve comment in atmel_i2c_init_ecdh_cmd
From: Thorsten Blum @ 2026-06-03 19:27 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: Thorsten Blum, linux-crypto, linux-arm-kernel, linux-kernel
Clarify that a P-256 public key is encoded as two 32-byte coordinates.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-i2c.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/atmel-i2c.c b/drivers/crypto/atmel-i2c.c
index ff19857894d0..24bded47a32b 100644
--- a/drivers/crypto/atmel-i2c.c
+++ b/drivers/crypto/atmel-i2c.c
@@ -138,9 +138,8 @@ int atmel_i2c_init_ecdh_cmd(struct atmel_i2c_cmd *cmd,
cmd->param2 = cpu_to_le16(DATA_SLOT_2);
/*
- * The device only supports NIST P256 ECC keys. The public key size will
- * always be the same. Use a macro for the key size to avoid unnecessary
- * computations.
+ * The device only supports P-256. Its public key is encoded as
+ * two 32-byte coordinates.
*/
copied = sg_copy_to_buffer(pubkey,
sg_nents_for_len(pubkey,
^ permalink raw reply related
* [PATCH 2/2] crypto: atmel-ecc - clean up and improve ECDH comments
From: Thorsten Blum @ 2026-06-03 19:27 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260603192708.1237715-4-thorsten.blum@linux.dev>
Improve the kerneldoc for struct atmel_ecdh_ctx by removing the stale
"unsupported curves" wording, since the device only supports a single
curve (P-256), and move the set_secret() constraint to the description.
In atmel_ecdh_set_secret(), clarify that the device generates the
private key, and drop the redundant "only supports NIST P256" comment.
In atmel_ecdh_done() and atmel_ecdh_generate_public_key(), clarify the
truncation comments. Also note that a P-256 public key consists of two
32-byte coordinates in atmel_ecdh_compute_shared_secret(), and remove
the unnecessary fall-through comment and other redundant comments.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-ecc.c | 37 ++++++++++++++-----------------------
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 9387eea4513d..1443e18a9cee 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -27,15 +27,15 @@ static struct atmel_ecc_driver_data driver_data;
/**
* struct atmel_ecdh_ctx - transformation context
- * @client : pointer to i2c client device
- * @fallback : used for unsupported curves or when user wants to use its own
- * private key.
- * @public_key : generated when calling set_secret(). It's the responsibility
- * of the user to not call set_secret() while
- * generate_public_key() or compute_shared_secret() are in flight.
+ * @client : I2C client device
+ * @fallback : ECDH fallback used for caller-provided private keys
+ * @public_key : cached public key corresponding to the device-generated
+ * private key
* @curve_id : elliptic curve id
- * @do_fallback: true when the device doesn't support the curve or when the user
- * wants to use its own private key.
+ * @do_fallback: true when ECDH operations should use @fallback
+ *
+ * The caller must not invoke set_secret() while generate_public_key()
+ * or compute_shared_secret() are in flight.
*/
struct atmel_ecdh_ctx {
struct i2c_client *client;
@@ -55,7 +55,7 @@ static void atmel_ecdh_done(struct atmel_i2c_work_data *work_data, void *areq,
if (status)
goto free_work_data;
- /* might want less than we've got */
+ /* copy only as much as requested, capped at 32 bytes */
n_sz = min(ATMEL_ECC_NIST_P256_N_SIZE, req->dst_len);
/* copy the shared secret */
@@ -64,15 +64,15 @@ static void atmel_ecdh_done(struct atmel_i2c_work_data *work_data, void *areq,
if (copied != n_sz)
status = -EINVAL;
- /* fall through */
free_work_data:
kfree_sensitive(work_data);
kpp_request_complete(req, status);
}
/*
- * A random private key is generated and stored in the device. The device
- * returns the pair public key.
+ * If no private key is provided, generate one in the device and cache
+ * the corresponding public key. The generated private key never leaves
+ * the device.
*/
static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
unsigned int len)
@@ -83,9 +83,7 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
struct ecdh params;
int ret = -ENOMEM;
- /* free the old public key, if any */
kfree(ctx->public_key);
- /* make sure you don't free the old public key twice */
ctx->public_key = NULL;
if (crypto_ecdh_decode_key(buf, len, ¶ms) < 0) {
@@ -94,7 +92,6 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
}
if (params.key_size) {
- /* fallback to ecdh software implementation */
ctx->do_fallback = true;
return crypto_kpp_set_secret(ctx->fallback, buf, len);
}
@@ -103,11 +100,6 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
if (!cmd)
return -ENOMEM;
- /*
- * The device only supports NIST P256 ECC keys. The public key size will
- * always be the same. Use a macro for the key size to avoid unnecessary
- * computations.
- */
public_key = kmalloc(ATMEL_ECC_PUBKEY_SIZE, GFP_KERNEL);
if (!public_key)
goto free_cmd;
@@ -120,7 +112,6 @@ static int atmel_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
if (ret)
goto free_public_key;
- /* save the public key */
memcpy(public_key, &cmd->data[RSP_DATA_IDX], ATMEL_ECC_PUBKEY_SIZE);
ctx->public_key = public_key;
@@ -149,7 +140,7 @@ static int atmel_ecdh_generate_public_key(struct kpp_request *req)
if (!ctx->public_key)
return -EINVAL;
- /* might want less than we've got */
+ /* copy only as much as requested, capped at 64 bytes */
nbytes = min(ATMEL_ECC_PUBKEY_SIZE, req->dst_len);
/* public key was saved at private key generation */
@@ -175,7 +166,7 @@ static int atmel_ecdh_compute_shared_secret(struct kpp_request *req)
return crypto_kpp_compute_shared_secret(req);
}
- /* must have exactly two points to be on the curve */
+ /* A P-256 public key must contain two 32-byte coordinates */
if (req->src_len != ATMEL_ECC_PUBKEY_SIZE)
return -EINVAL;
^ permalink raw reply related
* Re: [PATCH] char: xilinx_hwicap: replace in_be32/out_be32 with ioread32be/iowrite32be
From: Rosen Penev @ 2026-06-03 19:52 UTC (permalink / raw)
To: Michal Simek
Cc: linux-kernel, Arnd Bergmann, chleroy, Greg Kroah-Hartman,
moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <878fd338-b4d0-4e46-987c-5a0ee52989dc@amd.com>
On Mon, Jun 1, 2026 at 11:22 PM Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 6/2/26 05:57, Rosen Penev wrote:
> > Mechanical conversion of the ppc4xx-specific accessors to the generic
> > portable helpers.
> >
> > As a result, COMPILE_TEST is added for extra compile coverage.
> >
> > Assisted-by: opencode:big-pickle
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> > drivers/char/Kconfig | 2 +-
> > drivers/char/xilinx_hwicap/buffer_icap.c | 16 +++++------
> > drivers/char/xilinx_hwicap/fifo_icap.c | 34 +++++++++++-------------
> > 3 files changed, 24 insertions(+), 28 deletions(-)
>
> I don't really mind about this because I think that we can also remove the whole
> driver.
I looked into this. The problem here is that there are actual users
arch/microblaze/boot/dts/system.dts
and
arch/mips/boot/dts/xilfpga/nexys4ddr.dts
> Thanks,
> Michal
^ permalink raw reply
* Re: [PATCH 0/2] drivers/perf: hisi: Updates for HiSilicon uncore PMUs
From: Will Deacon @ 2026-06-03 19:57 UTC (permalink / raw)
To: Yushan Wang
Cc: mark.rutland, robin.murphy, linux-arm-kernel, linux-kernel,
fanghao11, linuxarm, liuyonglong, prime.zeng, wangzhou1
In-Reply-To: <001403a3-513a-4c17-b2ec-2beafbf221fd@huawei.com>
On Tue, May 19, 2026 at 04:42:32PM +0800, Yushan Wang wrote:
> Hi all, a gentle ping on this.
>
> All comments are welcomed
Sashiko has a few (some of which are bogus):
https://sashiko.dev/#/patchset/20260423152959.1458563-1-wangyushan12@huawei.com
Will
^ permalink raw reply
* Re: [PATCH v8 11/12] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Daniel Mentz @ 2026-06-03 20:28 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <20260601215909.3958732-12-praan@google.com>
On Mon, Jun 1, 2026 at 2:59 PM Pranjal Shrivastava <praan@google.com> wrote:
> @@ -2361,8 +2394,33 @@ static irqreturn_t arm_smmu_handle_gerror(struct arm_smmu_device *smmu)
> static irqreturn_t arm_smmu_gerror_handler(int irq, void *dev)
> {
> struct arm_smmu_device *smmu = dev;
> + irqreturn_t ret;
> +
> + /*
> + * Global Errors are only processed if the SMMU is active.
> + *
> + * If the STOP_FLAG is set (can_elide == true), the hardware is
> + * either already disabled or in the process of being disabled.
> + * Any errors captured during the quiesce/drain phase will be
> + * handled by the explicit arm_smmu_handle_gerror() call at the
> + * end of arm_smmu_runtime_suspend() callback. On resume, the
> + * STOP_FLAG is cleared before interrupts are re-enabled, ensuring
> + * no valid errors are missed.
> + *
> + * A lockless check is favoured here over a dynamic PM core check
> + * since the runtime_pm_get_if_active would return false during
> + * transient states like RPM_RESUMING & ignore level-triggered
> + * interrupts.
> + */
> + if (arm_smmu_cmdq_can_elide(smmu)) {
> + dev_err(smmu->dev,
> + "Ignoring gerror interrupt because the SMMU is suspended\n");
> + return IRQ_NONE;
> + }
Have you considered using arm_smmu_rpm_get() here instead?
I can see two issues with the currenlty proposal:
* Returning IRQ_NONE when an interrupt is indeed active and needs to
be handled. This might be interpreted as a spurious interrupt
* Nothing is preventing the suspend handler from running while
arm_smmu_gerror_handler is in the middle of handling an interrupt
I understand that using arm_smmu_rpm_get() also has downsides,
including an unnecessary resume operation when the SMMU is already in
RPM_SUSPENDING state. However, using arm_smmu_rpm_get() would make it
easier to ensure correctness.
> +
> + ret = arm_smmu_handle_gerror(smmu);
>
> - return arm_smmu_handle_gerror(smmu);
> + return ret;
> }
^ permalink raw reply
* Re: (subset) [PATCH v1 0/6] power: Use named initializers for platform_device_id arrays
From: Sebastian Reichel @ 2026-06-03 20:46 UTC (permalink / raw)
To: Sebastian Reichel, Uwe Kleine-König (The Capable Hub)
Cc: Kuan-Wei Chiu, Benson Leung, Guenter Roeck, Thomas Weißschuh,
Krzysztof Kozlowski, Matthias Brugger, AngeloGioacchino Del Regno,
linux-pm, linux-kernel, chrome-platform, linux-arm-kernel,
linux-mediatek, Hans de Goede, Marek Szyprowski,
Sebastian Krzyszkowiak, Purism Kernel Team, Yixun Lan,
Andreas Kemnade, Matti Vaittinen, Sven Peter, Janne Grunau,
Neal Gompa, Amit Sunil Dhamne, Samuel Kayode, linux-riscv,
spacemit, asahi, imx, Chen-Yu Tsai
In-Reply-To: <cover.1780048925.git.u.kleine-koenig@baylibre.com>
On Fri, 29 May 2026 12:18:15 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> this series targets to use named initializers for platform_device_id
> arrays. In general these are better readable for humans and more robust
> to changes in the respective struct definition.
>
> This robustness is needed as I want to do
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -610,4 +610,7 @@ struct dmi_system_id {
> struct platform_device_id {
> char name[PLATFORM_NAME_SIZE];
> - kernel_ulong_t driver_data;
> + union {
> + kernel_ulong_t driver_data;
> + const void *driver_data_ptr;
> + };
> };
>
> [...]
Applied, thanks!
[1/6] power: Drop unused assignment of platform_device_id driver data
commit: 75a0e1e0b86078687c3c6a05107a98c7e59a65a8
[2/6] power: supply: max14577: Drop driver data in of and platform device id arrays
commit: 37258ad1f3a52ea442c32b3c92ad7146e74050c7
[4/6] power: Use named initializers for platform_device_id arrays
commit: e28f7498dd819878b8acacb89c4c073a646feea0
[5/6] power: supply: mt6360_charger: Use of match table unconditionally
commit: eb7ed650e5960fc303130704d1e29d18a7d0e1df
[6/6] power: Unify code style for platform_device_id arrays
commit: e3f669bed32287ae72c05a4ddab4a6687b0e62ca
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* [PATCH v1] EDAC/synopsys: Fix cleanup on injection sysfs failure
From: Yuho Choi @ 2026-06-03 20:47 UTC (permalink / raw)
To: Borislav Petkov, Tony Luck, Michal Simek
Cc: linux-edac, linux-arm-kernel, linux-kernel, Yuho Choi
edac_create_sysfs_attributes() creates inject_data_error before
inject_data_poison. If the second file creation fails, the first file is
left behind.
The same failure path runs after edac_mc_add_mc() has registered the
memory controller with the EDAC core. Jumping directly to edac_mc_free()
skips edac_mc_del_mc() and leaves the registered controller state
unwound incorrectly.
Remove inject_data_error when inject_data_poison creation fails, and
route the probe failure through edac_mc_del_mc() before freeing mci.
Fixes: 1a81361f75d8 ("EDAC, synopsys: Add Error Injection support for ZynqMP DDR controller")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
drivers/edac/synopsys_edac.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/synopsys_edac.c b/drivers/edac/synopsys_edac.c
index 51143b3257de..c395a1e97a36 100644
--- a/drivers/edac/synopsys_edac.c
+++ b/drivers/edac/synopsys_edac.c
@@ -1120,8 +1120,10 @@ static int edac_create_sysfs_attributes(struct mem_ctl_info *mci)
if (rc < 0)
return rc;
rc = device_create_file(&mci->dev, &dev_attr_inject_data_poison);
- if (rc < 0)
+ if (rc < 0) {
+ device_remove_file(&mci->dev, &dev_attr_inject_data_error);
return rc;
+ }
return 0;
}
@@ -1431,7 +1433,7 @@ static int mc_probe(struct platform_device *pdev)
if (rc) {
edac_printk(KERN_ERR, EDAC_MC,
"Failed to create sysfs entries\n");
- goto free_edac_mc;
+ goto del_mc;
}
}
@@ -1448,6 +1450,10 @@ static int mc_probe(struct platform_device *pdev)
return rc;
+#ifdef CONFIG_EDAC_DEBUG
+del_mc:
+ edac_mc_del_mc(&pdev->dev);
+#endif
free_edac_mc:
edac_mc_free(mci);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH RFC v3 0/5] ZTE zx297520v3 clock bindings and driver
From: Stefan Dösinger @ 2026-06-03 20:49 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney, Philipp Zabel
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <5620a8969da87612a2d89578be656b5d00662635.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
Hi Philipp,
Am Mittwoch, 3. Juni 2026, 11:50:14 Ostafrikanische Zeit schrieben Sie:
> When there is no interaction required when operating the clk/reset
> bits, I prefer the reset driver sitting in drivers/reset as an aux
> device, especially when register access can be abstracted via a shared
> regmap. Some of the reset drivers under drivers/clk just predate the
> aux bus.
There are two interactions:
The register lock because all LSP and at least one TOP register contains both
clocks and resets.
Shared register definition: in the case of the LSP clocks breaking up the
composite definition would sacrifice readability.
Neither of them are insurmountable and I can certainly arrange a separation if
asked to - but my preference is to keep them together.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v3 3/5] clk: zte: Introduce a driver for zx297520v3 top clocks and resets.
From: Stefan Dösinger @ 2026-06-03 20:49 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney, Philipp Zabel
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <99743c29fe81a90d3c1f51889d42ef9d4766de3c.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
Hi,
Thanks for the comments!
Am Mittwoch, 3. Juni 2026, 12:14:21 Ostafrikanische Zeit schrieb Philipp
Zabel:
> Is this delay long enough for all potential users of reset_control_reset()?
> Are there actually any at all?
You mean drivers that are in use on this SoC that call reset_control_reset?
Afaics not, they all call reset_assert/reset_deassert, or only ever deassert a
reset that is set on boot. It isn't called at runtime and the only driver
calling it that is in use on zx297520v3 is stmmac, which only calls it if
assert/deassert aren't available.
I implemented the reset() callback because other drivers had it and grabbed
the magic usleep(100) from ZTE's USB code. It looks like I should just /dev/
null it.
> I'd move the spinlock in here ...
>
> > ```
>
> + /* This is a special case used only by USB reset */
> + if (data->resets[id].wait_mask) {
> + return readl_poll_timeout(data->resets[id].reg + 4, val,
> + val & data-
>resets[id].wait_mask, 1, 100);
> ```
>
>
> ... because this might sleep.
Ack
> + return val & data->resets[id].mask;
> ```
>
>
> This will return a negative value for bit BIT(31), I'd wrap this with a
> double negation.
Sounds good
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: Document SVE constraints on new hwcaps
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Shuah Khan, Mark Brown
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-doc,
linux-kernel
In-Reply-To: <20260522-arm64-elf-hwcaps-sve-cleanup-v1-1-07b0cedfc6fa@kernel.org>
On Fri, 22 May 2026 18:50:28 +0100, Mark Brown wrote:
> Two of the SVE hwcaps added for the SVE features in the 2025 dpISA did
> not explicitly call out their dependency on SVE in the ABI documentation.
> Do so.
>
> While we're here reorder the SVE and fature specific ID registers for
> HWCAP3_SVE_LUT6 which did have the SVE dependency but listed it second
> unlike the other SVE specific ID registers.
>
> [...]
Applied to arm64 (for-next/cpufeature), thanks!
[1/1] arm64: Document SVE constraints on new hwcaps
https://git.kernel.org/arm64/c/f20f8fe086b2
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v4 00/20] arm64+KVM: FPSIMD/SVE/SME cleanups
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, Mark Rutland
Cc: catalin.marinas, kernel-team, Will Deacon, broonie, james.morse,
maz, oupton, stable, tabba, vladimir.murzin
In-Reply-To: <20260603110630.1027435-1-mark.rutland@arm.com>
On Wed, 03 Jun 2026 12:06:10 +0100, Mark Rutland wrote:
> This series cleans up low-level FPSIMD/SVE/SME state management code,
> making it easier to maintain and extend (e.g. adding SME support to
> KVM), and enabling better debugging (e.g. by making SVE/SME save/restore
> visible to KASAN and KCSAN).
>
> The first two patches fix a couple of latent issues that don't seem to
> have occurred in practice so far, but would be good to fix for stable to
> avoid any future issues. The rest of the series is purely cleanup.
>
> [...]
Applied to arm64 (for-next/fpsimd-cleanups), thanks!
[01/20] arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()
https://git.kernel.org/arm64/c/ae24f6b06e90
[02/20] arm64: fpsimd: Fix type mismatch in sme_{save,load}_state()
https://git.kernel.org/arm64/c/247bd1539050
[03/20] KVM: arm64: Don't include <asm/fpsimdmacros.h>
https://git.kernel.org/arm64/c/79e66bb7e8b4
[04/20] KVM: arm64: Don't override FFR save/restore argument
https://git.kernel.org/arm64/c/dc2337625880
[05/20] KVM: arm64: pkvm: Save host FPMR in host cpu context
https://git.kernel.org/arm64/c/da20bb4bc5e6
[06/20] KVM: arm64: pkvm: Remove struct cpu_sve_state
https://git.kernel.org/arm64/c/afd7af2b56ec
[07/20] arm64: fpsimd: Fold sve_init_regs() into do_sve_acc()
https://git.kernel.org/arm64/c/3efb6c7f22c6
[08/20] arm64: fpsimd: Remove sve_set_vq() and sme_set_vq()
https://git.kernel.org/arm64/c/e0cde2d2bb1b
[09/20] arm64: fpsimd: Use assembler for SVE instructions
https://git.kernel.org/arm64/c/f27fe9aa2d06
[10/20] arm64: fpsimd: Use assembler for baseline SME instructions
https://git.kernel.org/arm64/c/db9d63eafeba
[11/20] arm64: fpsimd: Move sve_get_vl() and sme_get_vl() inline
https://git.kernel.org/arm64/c/3f26d7c6544c
[12/20] arm64: sysreg: Add FPCR and FPSR
https://git.kernel.org/arm64/c/36a1d1726634
[13/20] arm64: fpsimd: Split FPSR/FPCR from SVE save/restore
https://git.kernel.org/arm64/c/1277531fca43
[14/20] arm64: fpsimd: Move fpsimd save/restore inline
https://git.kernel.org/arm64/c/890712d4507b
[15/20] arm64: fpsimd: Use opaque type for SVE state
https://git.kernel.org/arm64/c/e1b163e40553
[16/20] arm64: fpsimd: Use opaque type for SME state
https://git.kernel.org/arm64/c/eb1a68a00c0a
[17/20] arm64: fpsimd: Move SVE save/restore inline
https://git.kernel.org/arm64/c/2768101b3976
[18/20] arm64: fpsimd: Move sve_flush_live() inline
https://git.kernel.org/arm64/c/18618d9ea1fb
[19/20] arm64: fpsimd: Move SME save/restore inline
https://git.kernel.org/arm64/c/bfdfafd90720
[20/20] arm64: fpsimd: Remove <asm/fpsimdmacros.h>
https://git.kernel.org/arm64/c/987ec51e1841
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] perf/arm-cmn: Fix DVM node events
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: Robin Murphy
Cc: catalin.marinas, kernel-team, Will Deacon, mark.rutland,
linux-perf-users, linux-arm-kernel, stable
In-Reply-To: <1af20ba3fb35cc507e0d74408675b50340feca39.1780065225.git.robin.murphy@arm.com>
On Fri, 29 May 2026 15:33:45 +0100, Robin Murphy wrote:
> The new DVM node events added in CMN-700 also apply to CMN S3; fix
> the model encoding so that we can expose the aliases and handle
> occupancy filtering on newer CMNs too.
>
>
Applied to will (for-next/perf), thanks!
[1/1] perf/arm-cmn: Fix DVM node events
https://git.kernel.org/will/c/5936245125f7
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH] arm64: patching: replace min_t with min in __text_poke
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: Catalin Marinas, Thorsten Blum
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-kernel
In-Reply-To: <20260531220817.738904-2-thorsten.blum@linux.dev>
On Mon, 01 Jun 2026 00:08:16 +0200, Thorsten Blum wrote:
> Use the simpler min() macro since both values are unsigned and
> compatible.
>
>
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: patching: replace min_t with min in __text_poke
https://git.kernel.org/arm64/c/6c2ccb4979b2
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v4 0/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
From: Will Deacon @ 2026-06-03 21:06 UTC (permalink / raw)
To: vladimir.murzin, xuwei5, broonie, ryan.roberts, corbet,
catalin.marinas, oupton, kevin.brodsky, maz, yeoreum.yun, skhan,
yangyicong, thuth, kuninori.morimoto.gx, lucaswei, lpieralisi,
miko.lenczewski, mark.rutland, james.clark, Zeng Heng
Cc: kernel-team, Will Deacon, wangkefeng.wang, linux-arm-kernel,
linux-kernel, linux-doc, zengheng4
In-Reply-To: <20260603062025.1504083-1-zengheng@huaweicloud.com>
On Wed, 03 Jun 2026 14:20:23 +0800, Zeng Heng wrote:
> v3: https://lore.kernel.org/all/20260601112000.1145391-1-zengheng@huaweicloud.com/
> v2: https://lore.kernel.org/all/20260529063132.766491-1-zengheng@huaweicloud.com/
> v1: https://lore.kernel.org/all/20260526015720.206854-1-zengheng@huaweicloud.com/
>
> Changes in v4:
> - Keep orthogonality for CONFIG_NVIDIA_CARMEL_CNP_ERRATUM and
> CONFIG_HISILICON_ERRATUM_162100125 within the cnp_erratum_cpus array.
>
> [...]
Applied to arm64 (for-next/errata), thanks!
[1/2] arm64: cpufeature: Add WORKAROUND_DISABLE_CNP capability
https://git.kernel.org/arm64/c/25996982ebcf
[2/2] arm64: kernel: Disable CNP on HiSilicon HIP09
https://git.kernel.org/arm64/c/f64328ecf4bf
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* [PATCH v1 0/4] iommufd: Cache invalidation hardening and SMMUv3 batching rework
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
Sashiko pointed out several issues in the iommufd invalidation path, which
also prompted a rework of the ARM SMMUv3 vIOMMU invalidation handler:
- entry_len is user-controlled and unbounded, so the trailing-zero check
for its forward-compat fields can scan gigabytes of user memory without
yielding, long enough to trip the soft-lockup watchdog.
- A large entry_num drives a backend's per-entry invalidation loop with no
reschedule, e.g. the VT-d nested path, pinning the CPU.
- The full-array copy helper copies the array twice on the equal-size fast
path: once in bulk, then again entry by entry.
- arm_vsmmu_cache_invalidate() reports converted-but-unsubmitted commands
as handled on its error paths.
- It sizes a single kernel allocation from the user-controlled entry_num.
- It rejects an empty-array data_type probe that the uAPI allows.
Fix them properly.
This is on Github:
https://github.com/nicolinc/iommufd/commits/smmuv3_fix_iommufd-v1
Nicolin Chen (4):
iommufd: Set upper bounds on cache invalidation entry_num and
entry_len
iommufd/selftest: Add invalidation entry_num and entry_len boundary
tests
iommu: Avoid copying the user array twice in the full-array copy
helper
iommu/arm-smmu-v3: Process vIOMMU invalidations in batches
include/linux/iommu.h | 1 +
.../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 91 +++++++++++--------
drivers/iommu/iommufd/hw_pagetable.c | 11 ++-
tools/testing/selftests/iommu/iommufd.c | 15 +++
4 files changed, 81 insertions(+), 37 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v1 2/4] iommufd/selftest: Add invalidation entry_num and entry_len boundary tests
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
In-Reply-To: <cover.1780521606.git.nicolinc@nvidia.com>
Test that the cache invalidation ioctl rejects an oversized entry_len and
an oversized entry_num, covering the CPU soft-lockup paths the caps close.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
tools/testing/selftests/iommu/iommufd.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/tools/testing/selftests/iommu/iommufd.c b/tools/testing/selftests/iommu/iommufd.c
index d1fe5dbc2813e..653aa251f8122 100644
--- a/tools/testing/selftests/iommu/iommufd.c
+++ b/tools/testing/selftests/iommu/iommufd.c
@@ -556,6 +556,21 @@ TEST_F(iommufd_ioas, alloc_hwpt_nested)
1, &num_inv);
assert(!num_inv);
+ /* Negative test: entry_len is bounded by PAGE_SIZE */
+ num_inv = 1;
+ test_err_hwpt_invalidate(EINVAL, nested_hwpt_id[0], inv_reqs,
+ IOMMU_HWPT_INVALIDATE_DATA_SELFTEST,
+ PAGE_SIZE + 1, &num_inv);
+ assert(!num_inv);
+
+ /* Negative test: entry_num is bounded */
+#define IOMMU_HWPT_INVALIDATE_ENTRY_NUM_MAX (1U << 19)
+ num_inv = IOMMU_HWPT_INVALIDATE_ENTRY_NUM_MAX + 1;
+ test_err_hwpt_invalidate(EINVAL, nested_hwpt_id[0], inv_reqs,
+ IOMMU_HWPT_INVALIDATE_DATA_SELFTEST,
+ sizeof(*inv_reqs), &num_inv);
+ assert(!num_inv);
+
/* Negative test: invalid flag is passed */
num_inv = 1;
inv_reqs[0].flags = 0xffffffff;
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/4] iommufd: Set upper bounds on cache invalidation entry_num and entry_len
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
In-Reply-To: <cover.1780521606.git.nicolinc@nvidia.com>
iommufd_hwpt_invalidate() takes a user-controlled entry_num and entry_len,
each bounded only by U32_MAX. An entry_len beyond the kernel's struct size
makes the copy helper verify the extra bytes are zero, scanning that excess
in one uninterruptible pass; a multi-gigabyte value over zeroed user memory
trips the soft-lockup watchdog.
A large entry_num is the other half, driving the backend invalidation loop
with no reschedule. The VT-d nested handler, for one, copies each entry and
flushes caches per iteration, pinning the CPU on a non-preemptible kernel.
Cap both in the ioctl. entry_len is held under PAGE_SIZE, above any request
struct, and entry_num under 1 << 19, the order of a hardware invalidation
queue and well beyond any real batch, bounding the per-call loop length.
Fixes: 8c6eabae3807 ("iommufd: Add IOMMU_HWPT_INVALIDATE")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/iommufd/hw_pagetable.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommufd/hw_pagetable.c b/drivers/iommu/iommufd/hw_pagetable.c
index fe789c2dc0c97..623cc608ca0cd 100644
--- a/drivers/iommu/iommufd/hw_pagetable.c
+++ b/drivers/iommu/iommufd/hw_pagetable.c
@@ -489,6 +489,9 @@ int iommufd_hwpt_get_dirty_bitmap(struct iommufd_ucmd *ucmd)
return rc;
}
+/* An arbitrary entry_num cap, far above any realistic invalidation batch */
+#define IOMMU_HWPT_INVALIDATE_ENTRY_NUM_MAX (1U << 19)
+
int iommufd_hwpt_invalidate(struct iommufd_ucmd *ucmd)
{
struct iommu_hwpt_invalidate *cmd = ucmd->cmd;
@@ -507,7 +510,13 @@ int iommufd_hwpt_invalidate(struct iommufd_ucmd *ucmd)
goto out;
}
- if (cmd->entry_num && (!cmd->data_uptr || !cmd->entry_len)) {
+ /*
+ * Bound entry_num and entry_len so a single call cannot pin the CPU;
+ * entry_len also caps the copy_struct_from_user() trailing-zero scan.
+ */
+ if (cmd->entry_num &&
+ (!cmd->data_uptr || !cmd->entry_len || cmd->entry_len > PAGE_SIZE ||
+ cmd->entry_num > IOMMU_HWPT_INVALIDATE_ENTRY_NUM_MAX)) {
rc = -EINVAL;
goto out;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v1 4/4] iommu/arm-smmu-v3: Process vIOMMU invalidations in batches
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
In-Reply-To: <cover.1780521606.git.nicolinc@nvidia.com>
arm_vsmmu_cache_invalidate() copies the entire user invalidation array into
one kernel allocation, then converts and submits those commands in batches
of CMDQ_BATCH_ENTRIES - 1. Sizing a single allocation from a user-supplied
count while tracking progress with a separate cursor is the root of several
independent problems:
- entry_num, the in/out count of successfully handled requests, is set to
"cur - cmds" on every error path. "cur" counts converted commands, not
submitted ones, so a conversion or submission failure reports the unsent
batch as handled, telling user space that invalidations which never made
it to the hardware have completed.
- The allocation is sized straight from the user's entry_num with no upper
bound and no __GFP_ACCOUNT, letting a large request drive an oversized,
unaccounted allocation and spam the page allocator.
- The -ENOMEM path returns without touching entry_num, once more reporting
the full input count as handled on a failure.
- A zero-length array, which the uAPI defines as a probe for a data_type
the kernel supports, reaches the full-array copy helper, which rejects
zero entries, so a supported type fails exactly like an unsupported one.
Rework the function to process the array one batch at a time, copying up to
CMDQ_BATCH_ENTRIES - 1 entries into a fixed-size stack buffer, converting
them in place, and issuing the batch, which removes the user-sized buffer.
A refactor is preferred over a series of smaller fixes because the problems
above are symptoms of one structure; changing the structure removes them as
a class rather than patching each in place:
- Dropping the allocation makes the size bound, the __GFP_ACCOUNT, and the
-ENOMEM accounting question moot, not three separate fixes.
- entry_num advances only as batches are issued, so the count it reports
tracks submitted commands and needs no correction on the error paths.
- The type is checked once up front, and an empty array then iterates zero
times, so the probe case falls out for free.
Each batch is still copied in one bulk transfer via the full-array helper,
iommu_copy_struct_from_full_user_array(); the whole-array copy becomes one
copy per batch that the preceding helper fix keeps to a single bulk copy.
If converting an entry fails, the already-converted prefix of the batch is
issued before the error is returned; if that issue fails, the batch is not
counted. So entry_num stays tied only to commands that actually reached the
hardware, without dropping the valid ones that preceded the failure.
Fixes: d68beb276ba2 ("iommu/arm-smmu-v3: Support IOMMU_HWPT_INVALIDATE using a VIOMMU object")
Assisted-by: Codex:GPT-5
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
.../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 91 +++++++++++--------
1 file changed, 55 insertions(+), 36 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
index ddae0b07c76b5..5574ccaecf381 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-iommufd.c
@@ -350,53 +350,72 @@ static int arm_vsmmu_convert_user_cmd(struct arm_vsmmu *vsmmu,
return 0;
}
-int arm_vsmmu_cache_invalidate(struct iommufd_viommu *viommu,
- struct iommu_user_data_array *array)
+static int arm_vsmmu_cache_invalidate_batch(struct arm_vsmmu *vsmmu,
+ struct iommu_user_data_array *array,
+ u32 *idx)
{
- struct arm_vsmmu *vsmmu = container_of(viommu, struct arm_vsmmu, core);
+ struct arm_vsmmu_invalidation_cmd cmds[CMDQ_BATCH_ENTRIES - 1];
struct arm_smmu_device *smmu = vsmmu->smmu;
- struct arm_vsmmu_invalidation_cmd *last;
- struct arm_vsmmu_invalidation_cmd *cmds;
- struct arm_vsmmu_invalidation_cmd *cur;
- struct arm_vsmmu_invalidation_cmd *end;
- int ret;
-
- cmds = kzalloc_objs(*cmds, array->entry_num);
- if (!cmds)
- return -ENOMEM;
- cur = cmds;
- end = cmds + array->entry_num;
+ struct iommu_user_data_array batch = {
+ .type = array->type,
+ .entry_len = array->entry_len,
+ };
+ unsigned int num, i;
+ int ret, issue_ret;
static_assert(sizeof(*cmds) == 2 * sizeof(u64));
+
+ /* Copy one batch of the user array in a single bulk copy */
+ num = min_t(u32, array->entry_num - *idx, ARRAY_SIZE(cmds));
+ batch.uptr = array->uptr + array->entry_len * *idx;
+ batch.entry_num = num;
ret = iommu_copy_struct_from_full_user_array(
- cmds, sizeof(*cmds), array,
+ cmds, sizeof(*cmds), &batch,
IOMMU_VIOMMU_INVALIDATE_DATA_ARM_SMMUV3);
if (ret)
- goto out;
-
- last = cmds;
- while (cur != end) {
- ret = arm_vsmmu_convert_user_cmd(vsmmu, cur);
- if (ret)
- goto out;
-
- /* FIXME work in blocks of CMDQ_BATCH_ENTRIES and copy each block? */
- cur++;
- if (cur != end && (cur - last) != CMDQ_BATCH_ENTRIES - 1)
- continue;
+ return ret;
- /* FIXME always uses the main cmdq rather than trying to group by type */
- ret = arm_smmu_cmdq_issue_cmdlist(smmu, &smmu->cmdq, last->cmd,
- cur - last, true);
+ /* Convert in place; only the converted prefix may be issued */
+ for (i = 0; i < num; i++) {
+ ret = arm_vsmmu_convert_user_cmd(vsmmu, &cmds[i]);
if (ret) {
- cur--;
- goto out;
+ num = i;
+ break;
}
- last = cur;
}
-out:
- array->entry_num = cur - cmds;
- kfree(cmds);
+ if (!num)
+ return ret;
+
+ /* FIXME always uses the main cmdq rather than trying to group by type */
+ issue_ret = arm_smmu_cmdq_issue_cmdlist(smmu, &smmu->cmdq, cmds->cmd,
+ num, true);
+ if (issue_ret)
+ return issue_ret;
+
+ *idx += num;
+ return ret;
+}
+
+int arm_vsmmu_cache_invalidate(struct iommufd_viommu *viommu,
+ struct iommu_user_data_array *array)
+{
+ struct arm_vsmmu *vsmmu = container_of(viommu, struct arm_vsmmu, core);
+ u32 issued = 0;
+ int ret = 0;
+
+ if (array->type != IOMMU_VIOMMU_INVALIDATE_DATA_ARM_SMMUV3) {
+ array->entry_num = 0;
+ return -EINVAL;
+ }
+
+ while (issued != array->entry_num) {
+ /* Process and issue the command(s) in batch */
+ ret = arm_vsmmu_cache_invalidate_batch(vsmmu, array, &issued);
+ if (ret)
+ break;
+ }
+
+ array->entry_num = issued;
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v1 3/4] iommu: Avoid copying the user array twice in the full-array copy helper
From: Nicolin Chen @ 2026-06-03 21:26 UTC (permalink / raw)
To: Will Deacon, Jason Gunthorpe, Kevin Tian
Cc: Robin Murphy, Joerg Roedel, Shuah Khan, Pranjal Shrivastava,
Kees Cook, Yi Liu, Eric Auger, linux-arm-kernel, iommu,
linux-kernel, linux-kselftest
In-Reply-To: <cover.1780521606.git.nicolinc@nvidia.com>
iommu_copy_struct_from_full_user_array() copies a whole user array into a
kernel buffer. In the common case, where user entry_len equals destination
entry size, it takes a fast path and copies the whole array with a single
copy_from_user().
That fast path does not return, so it falls through into the item-by-item
copy_struct_from_user() loop and copies every entry a second time. For an
equal entry_len that loop is just a copy_from_user() of the same bytes, so
the whole array is copied twice for no benefit.
Return right after the bulk copy. The per-item loop then runs only on the
slow path, where entry_len differs and each entry needs size adaption.
Fixes: 4f2e59ccb698 ("iommu: Add iommu_copy_struct_from_full_user_array helper")
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index e587d4ac4d331..6957144263793 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -547,6 +547,7 @@ iommu_copy_struct_from_full_user_array(void *kdst, size_t kdst_entry_size,
user_array->entry_num *
user_array->entry_len))
return -EFAULT;
+ return 0;
}
/* Copy item by item */
--
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