* Re: [PATCH v4 4/4] arm64: escalate smp_send_stop() to an SDEI NMI as a last resort
From: Catalin Marinas @ 2026-06-26 17:08 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel, Kiryl Shutsemau (Meta)
In-Reply-To: <97a870d0670b7e1c2fb9f5142f6e36c594282017.1781709543.git.kas@kernel.org>
On Wed, Jun 17, 2026 at 08:20:05PM +0100, Kiryl Shutsemau wrote:
> +void sdei_nmi_stop_cpus(const cpumask_t *mask)
> +{
> + unsigned int cpu;
> +
> + WRITE_ONCE(sdei_nmi_stopping, true);
> +
> + /*
> + * Publish the flag before signalling. The SMC is a context-sync
> + * event, not a barrier, so WRITE_ONCE() alone could let the store be
> + * observed after the event it triggers. The barrier is cumulative: a
> + * target that sees the event is guaranteed to see the flag.
> + */
> + smp_wmb();
> +
> + for_each_cpu(cpu, mask)
> + sdei_nmi_fire(cpu);
> +}
The smp_wmb() is not sufficient here. In the GIC IPI code we use a
dsb(ishst). It should be similar here. I think TF-A does this already
but it's unclear from the SDEI spec that it is mandated.
--
Catalin
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: ti: Add support for the phyCORE-AM67x
From: Nathan Morrisson @ 2026-06-26 16:10 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: afd, sashiko-reviews, linux-arm-kernel, devicetree, linux-kernel,
upstream
In-Reply-To: <20260626161014.1146128-1-nmorrisson@phytec.com>
Add support for the PHYTEC phyCORE-AM67x SoM [1] and the
corresponding phyBOARD-Rigel carrier board [2]. The phyCORE-AM67x SoM
uses the TI AM67x SoC and can come with different sizes and models of
DDR, eMMC, and SPI NOR Flash.
Supported features:
* Audio playback and recording
* CAN
* Debug UART
* eMMC
* Ethernet
* GPIO buttons
* Heartbeat LED
* I2C Current sensor
* I2C EEPROM
* I2C Light sensor
* I2C RTC
* Micro SD card
* PCIe
* SPI NOR flash
* USB
[1] https://www.phytec.com/product/phycore-am67x/
[2] https://www.phytec.com/product/phyboard-am67x-development-kit/
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
---
Changes in v2:
* Move k3-j722s.dtsi include from the phyboard to phycore dts
* Remove cpsw_port2 node because it was already disabled
* Remove mcasp1 because it is used by HDMI, and HDMI is not included in this dts
* Fix typo in audio codec properties ai3xx-micbias-vg -> ai31xx-micbias-vg
* Use IRQ_TYPE_EDGE_FALLING instead of IRQ_TYPE_LEVEL_LOW for gpio expanders
arch/arm64/boot/dts/ti/Makefile | 1 +
.../boot/dts/ti/k3-am67-phycore-som.dtsi | 325 ++++++++++++
.../boot/dts/ti/k3-am6754-phyboard-rigel.dts | 478 ++++++++++++++++++
3 files changed, 804 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 371f9a043fe5..623ee2369132 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -184,6 +184,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
# Boards with J722s SoC
+dtb-$(CONFIG_ARCH_K3) += k3-am6754-phyboard-rigel.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
diff --git a/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
new file mode 100644
index 000000000000..1bbd6d024c60
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2026 PHYTEC America LLC
+ * Author: Nathan Morrisson <nmorrisson@phytec.com>
+ */
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "k3-j722s.dtsi"
+
+/ {
+ compatible = "phytec,am67-phycore-som", "ti,j722s";
+ model = "PHYTEC phyCORE-AM67";
+
+ aliases {
+ ethernet0 = &cpsw_port1;
+ gpio0 = &main_gpio0;
+ mmc0 = &sdhci0;
+ rtc0 = &i2c_som_rtc;
+ rtc1 = &wkup_rtc0;
+ spi0 = &ospi0;
+ };
+
+ memory@80000000 {
+ /* 4G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+ <0x00000008 0x80000000 0x00000000 0x80000000>;
+ device_type = "memory";
+ bootph-all;
+ };
+
+ reserved_memory: reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_tfa_ddr: tfa@9e780000 {
+ reg = <0x00 0x9e780000 0x00 0x80000>;
+ no-map;
+ };
+
+ secure_ddr: optee@9e800000 {
+ reg = <0x00 0x9e800000 0x00 0x01800000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_dma_memory_region: memory@a0000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa0000000 0x00 0x100000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_memory_region: memory@a0100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa0100000 0x00 0xf00000>;
+ no-map;
+ };
+ };
+
+ vcc_5v0_som: regulator-vcc-5v0-som {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_5V0_SOM";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_pins_default>;
+
+ led-0 {
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&main_gpio0 13 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ function = LED_FUNCTION_HEARTBEAT;
+ };
+ };
+};
+
+&main_pmx0 {
+ leds_pins_default: leds-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x034, PIN_OUTPUT, 7) /* (K22) OSPI0_CSN2.GPIO0_13 */
+ >;
+ };
+
+ mdio_pins_default: mdio-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AC24) MDIO0_MDC */
+ J722S_IOPAD(0x015c, PIN_INPUT, 0) /* (AD25) MDIO0_MDIO */
+ >;
+ bootph-all;
+ };
+
+ ospi0_pins_default: ospi0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x000, PIN_OUTPUT, 0) /* (L24) OSPI0_CLK */
+ J722S_IOPAD(0x02c, PIN_OUTPUT, 0) /* (K26) OSPI0_CSn0 */
+ J722S_IOPAD(0x00c, PIN_INPUT, 0) /* (K27) OSPI0_D0 */
+ J722S_IOPAD(0x010, PIN_INPUT, 0) /* (L27) OSPI0_D1 */
+ J722S_IOPAD(0x014, PIN_INPUT, 0) /* (L26) OSPI0_D2 */
+ J722S_IOPAD(0x018, PIN_INPUT, 0) /* (L25) OSPI0_D3 */
+ J722S_IOPAD(0x01c, PIN_INPUT, 0) /* (L21) OSPI0_D4 */
+ J722S_IOPAD(0x020, PIN_INPUT, 0) /* (M26) OSPI0_D5 */
+ J722S_IOPAD(0x024, PIN_INPUT, 0) /* (N27) OSPI0_D6 */
+ J722S_IOPAD(0x028, PIN_INPUT, 0) /* (M27) OSPI0_D7 */
+ J722S_IOPAD(0x008, PIN_INPUT, 0) /* (L22) OSPI0_DQS */
+ J722S_IOPAD(0x038, PIN_INPUT, 7) /* (J22) OSPI0_CSn3.GPIO0_14 */
+ >;
+ bootph-all;
+ };
+
+ pmic_irq_pins_default: pmic-irq-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x030, PIN_INPUT, 7) /* (K23) OSPI0_CSN1.GPIO0_12 */
+ >;
+ };
+
+ rgmii1_pins_default: rgmii1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x014c, PIN_INPUT, 0) /* (AC25) RGMII1_RD0 */
+ J722S_IOPAD(0x0150, PIN_INPUT, 0) /* (AD27) RGMII1_RD1 */
+ J722S_IOPAD(0x0154, PIN_INPUT, 0) /* (AE24) RGMII1_RD2 */
+ J722S_IOPAD(0x0158, PIN_INPUT, 0) /* (AE26) RGMII1_RD3 */
+ J722S_IOPAD(0x0148, PIN_INPUT, 0) /* (AE27) RGMII1_RXC */
+ J722S_IOPAD(0x0144, PIN_INPUT, 0) /* (AD23) RGMII1_RX_CTL */
+ J722S_IOPAD(0x0134, PIN_OUTPUT, 0) /* (AF27) RGMII1_TD0 */
+ J722S_IOPAD(0x0138, PIN_OUTPUT, 0) /* (AE23) RGMII1_TD1 */
+ J722S_IOPAD(0x013c, PIN_OUTPUT, 0) /* (AG25) RGMII1_TD2 */
+ J722S_IOPAD(0x0140, PIN_OUTPUT, 0) /* (AF24) RGMII1_TD3 */
+ J722S_IOPAD(0x0130, PIN_OUTPUT, 0) /* (AG26) RGMII1_TXC */
+ J722S_IOPAD(0x012c, PIN_OUTPUT, 0) /* (AF25) RGMII1_TX_CTL */
+ >;
+ bootph-all;
+ };
+};
+
+&mcu_pmx0 {
+ wkup_i2c0_pins_default: wkup-i2c0-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x04c, PIN_INPUT_PULLUP, 0) /* (B9) WKUP_I2C0_SCL */
+ J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0) /* (D11) WKUP_I2C0_SDA */
+ >;
+ bootph-all;
+ };
+};
+
+&cpsw3g {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&cpsw3g_mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins_default>;
+ status = "okay";
+
+ cpsw3g_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,min-output-impedance;
+ };
+};
+
+&cpsw_port1 {
+ phy-mode = "rgmii-id";
+ phy-handle = <&cpsw3g_phy1>;
+ status = "okay";
+};
+
+&ospi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ospi0_pins_default>;
+ bootph-all;
+ status = "okay";
+
+ serial_flash: flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <25000000>;
+ vcc-supply = <&vdd_1v8>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <0>;
+ };
+};
+
+&sdhci0 {
+ non-removable;
+ bootph-all;
+ ti,driver-strength-ohm = <50>;
+ status = "okay";
+};
+
+&wkup_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_i2c0_pins_default>;
+ clock-frequency = <400000>;
+ bootph-all;
+ status = "okay";
+
+ pmic@30 {
+ compatible = "ti,tps65219";
+ reg = <0x30>;
+ buck1-supply = <&vcc_5v0_som>;
+ buck2-supply = <&vcc_5v0_som>;
+ buck3-supply = <&vcc_5v0_som>;
+ ldo1-supply = <&vdd_3v3>;
+ ldo2-supply = <&vdd_1v8>;
+ ldo3-supply = <&vdd_3v3>;
+ ldo4-supply = <&vdd_3v3>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_irq_pins_default>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ system-power-controller;
+ ti,power-button;
+
+ regulators {
+ vdd_3v3: buck1 {
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_1v8: buck2 {
+ regulator-name = "VDD_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_lpddr4: buck3 {
+ regulator-name = "VDD_LPDDR4";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vddshv_sdio: ldo1 {
+ regulator-name = "VDDSHV_SDIO";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allow-bypass;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_1v2: ldo2 {
+ regulator-name = "VDD_1V2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdda_1v8_phy: ldo3 {
+ regulator-name = "VDDA_1V8_PHY";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd_1v8_pll: ldo4 {
+ regulator-name = "VDD_1V8_PLL";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+
+ vdd_core: regulator-vdd-core@44 {
+ compatible = "ti,tps62873";
+ reg = <0x44>;
+ bootph-pre-ram;
+ regulator-name = "VDD_CORE";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c32";
+ reg = <0x50>;
+ pagesize = <32>;
+ };
+
+ som_eeprom_opt: eeprom@51 {
+ compatible = "atmel,24c32";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+
+ i2c_som_rtc: rtc@52 {
+ compatible = "microcrystal,rv3028";
+ reg = <0x52>;
+ };
+};
+
+#include "k3-j722s-ti-ipc-firmware.dtsi"
diff --git a/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
new file mode 100644
index 000000000000..e6e74910e0bb
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
@@ -0,0 +1,478 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2026 PHYTEC America LLC
+ * Author: Nathan Morrisson <nmorrisson@phytec.com>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/phy/phy.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "k3-serdes.h"
+#include "k3-am67-phycore-som.dtsi"
+
+/ {
+ compatible = "phytec,am6754-phyboard-rigel",
+ "phytec,am67-phycore-som", "ti,j722s";
+ model = "PHYTEC phyBOARD-Rigel AM67";
+
+ aliases {
+ gpio1 = &main_gpio1;
+ mmc1 = &sdhci1;
+ serial2 = &main_uart0;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ };
+
+ can_tc0: can-phy0 {
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <8000000>;
+ standby-gpios = <&gpio_exp1 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ usb0_connector: connector {
+ compatible = "gpio-usb-b-connector", "usb-b-connector";
+ label = "USB-C";
+ data-role = "dual";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_usbc_power_pins_default>;
+
+ id-gpios = <&main_gpio1 15 GPIO_ACTIVE_HIGH>;
+
+ port {
+ usb0_con: endpoint {
+ remote-endpoint = <&usb0_ep>;
+ };
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_keys_pins_default>;
+
+ key-home {
+ label = "home";
+ linux,code = <KEY_HOME>;
+ gpios = <&main_gpio1 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ key-menu {
+ label = "menu";
+ linux,code = <KEY_MENU>;
+ gpios = <&gpio_exp1 4 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ pcie_refclk0: pcie-refclk0 {
+ compatible = "gpio-gate-clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_pcie_usb_sel_pins_default>;
+ clocks = <&serdes_refclk>;
+ #clock-cells = <0>;
+ enable-gpios = <&main_gpio0 22 GPIO_ACTIVE_LOW>;
+ };
+
+ vcc_1v8: regulator-vcc-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_3v3_aud: regulator-vcc-3v3-aud {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_AUD";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_3v3_mmc: regulator-vcc-3v3-mmc {
+ /* TPS22963C OUTPUT */
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_MMC";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_3v3_sw: regulator-vcc-3v3-sw {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_SW";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vcc_speaker: regulator-vcc-speaker {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_SPEAKER";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,widgets =
+ "Microphone", "Mic Jack",
+ "Headphone", "Headphone Jack",
+ "Line", "Stereo Jack",
+ "Speaker", "L SPKR",
+ "Speaker", "R SPKR";
+ simple-audio-card,routing =
+ "MIC1RP", "Mic Jack",
+ "Mic Jack", "MICBIAS",
+ "Headphone Jack", "HPL",
+ "Headphone Jack", "HPR",
+ "MIC1LM", "Stereo Jack",
+ "MIC1LP", "Stereo Jack",
+ "SPL", "L SPKR",
+ "SPR", "R SPKR";
+ simple-audio-card,name = "phyBOARD-Rigel";
+ simple-audio-card,format = "dsp_b";
+ simple-audio-card,bitclock-master = <&sound_master>;
+ simple-audio-card,frame-master = <&sound_master>;
+ simple-audio-card,bitclock-inversion;
+
+ simple-audio-card,cpu {
+ sound-dai = <&mcasp0>;
+ };
+
+ sound_master: simple-audio-card,codec {
+ sound-dai = <&audio_codec>;
+ clocks = <&audio_refclk1>;
+ };
+ };
+};
+
+&main_pmx0 {
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0a0, PIN_OUTPUT, 1) /* (N24) GPMC0_WPn.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+
+ gpio_exp0_int_pins_default: gpio-exp0-int-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0054, PIN_INPUT, 7) /* (T21) GPMC0_AD6.GPIO0_21 */
+ >;
+ };
+
+ gpio_exp1_int_pins_default: gpio-exp1-int-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0244, PIN_INPUT, 7) /* (A24) MMC1_SDWP.GPIO1_49 */
+ >;
+ };
+
+ gpio_exp2_int_pins_default: gpio-exp2-int-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0050, PIN_INPUT, 7) /* (T24) GPMC0_AD5.GPIO0_20 */
+ >;
+ };
+
+ gpio_keys_pins_default: gpio-keys-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01d4, PIN_INPUT, 7) /* (B21) UART0_RTSn.GPIO1_23 */
+ >;
+ };
+
+ main_i2c0_pins_default: main-i2c0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D23) I2C0_SCL */
+ J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
+ >;
+ bootph-all;
+ };
+
+ main_i2c1_pins_default: main-i2c1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01e8, PIN_INPUT_PULLUP, 0) /* (C24) I2C1_SCL */
+ J722S_IOPAD(0x01ec, PIN_INPUT_PULLUP, 0) /* (A22) I2C1_SDA */
+ >;
+ bootph-all;
+ };
+
+ main_mcan0_pins_default: main-mcan0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x1dc, PIN_INPUT, 0) /* (C22) MCAN0_RX */
+ J722S_IOPAD(0x1d8, PIN_OUTPUT, 0) /* (D22) MCAN0_TX */
+ >;
+ };
+
+ main_mcasp0_pins_default: main-mcasp0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x1a8, PIN_INPUT, 0) /* (C26) MCASP0_AFSX */
+ J722S_IOPAD(0x1a4, PIN_INPUT, 0) /* (D25) MCASP0_ACLKX */
+ J722S_IOPAD(0x198, PIN_OUTPUT, 0) /* (A26) MCASP0_AXR2 */
+ J722S_IOPAD(0x194, PIN_INPUT, 0) /* (A25) MCASP0_AXR3 */
+ >;
+ };
+
+ main_mmc1_pins_default: main-mmc1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x023c, PIN_INPUT, 0) /* (H22) MMC1_CMD */
+ J722S_IOPAD(0x0234, PIN_INPUT, 0) /* (H24) MMC1_CLK */
+ J722S_IOPAD(0x0230, PIN_INPUT, 0) /* (H23) MMC1_DAT0 */
+ J722S_IOPAD(0x022c, PIN_INPUT, 0) /* (H20) MMC1_DAT1 */
+ J722S_IOPAD(0x0228, PIN_INPUT, 0) /* (J23) MMC1_DAT2 */
+ J722S_IOPAD(0x0224, PIN_INPUT, 0) /* (H25) MMC1_DAT3 */
+ J722S_IOPAD(0x0240, PIN_INPUT, 0) /* (B24) MMC1_SDCD */
+ >;
+ bootph-all;
+ };
+
+ main_pcie_pins_default: main-pcie-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x07c, PIN_INPUT, 7) /* (T23) GPMC0_CLK.GPIO0_31 */
+ >;
+ };
+
+ main_pcie_usb_sel_pins_default: main-pcie-usb-sel-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x058, PIN_INPUT, 7) /* (T22) GPMC0_AD7.GPIO0_22 */
+ >;
+ };
+
+ main_uart0_pins_default: main-uart0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01c8, PIN_INPUT, 0) /* (F19) UART0_RXD */
+ J722S_IOPAD(0x01cc, PIN_OUTPUT, 0) /* (F20) UART0_TXD */
+ >;
+ bootph-all;
+ };
+
+ main_usbc_power_pins_default: main-usbc-power-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x1b4, PIN_INPUT, 7) /* (B20) SPI0_CS0.GPIO1_15 */
+ >;
+ };
+};
+
+&audio_refclk1 {
+ assigned-clock-rates = <25000000>;
+};
+
+&main_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c0_pins_default>;
+ clock-frequency = <400000>;
+ status = "okay";
+
+ veml6030: light-sensor@10 {
+ compatible = "vishay,veml6030";
+ reg = <0x10>;
+ vdd-supply = <&vcc_3v3_sw>;
+ };
+};
+
+&main_i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c1_pins_default>;
+ clock-frequency = <100000>;
+ status = "okay";
+
+ audio_codec: audio-codec@18 {
+ compatible = "ti,tlv320aic3110";
+ reg = <0x18>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+ #sound-dai-cells = <0>;
+ ai31xx-micbias-vg = <2>;
+ reset-gpios = <&gpio_exp1 7 GPIO_ACTIVE_LOW>;
+
+ HPVDD-supply = <&vcc_3v3_aud>;
+ SPRVDD-supply = <&vcc_speaker>;
+ SPLVDD-supply = <&vcc_speaker>;
+ AVDD-supply = <&vcc_3v3_aud>;
+ IOVDD-supply = <&vcc_3v3_aud>;
+ DVDD-supply = <&vcc_1v8>;
+ };
+
+ gpio_exp0: gpio@20 {
+ compatible = "nxp,pcf8574";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_exp0_int_pins_default>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <21 IRQ_TYPE_EDGE_FALLING>;
+ gpio-line-names = "CSI3_STROBE", "CSI3_TRIGGER",
+ "CSI3_SHUTTER", "CSI3_OE",
+ "CSI2_STROBE", "CSI2_TRIGGER",
+ "CSI2_SHUTTER", "CSI2_OE";
+ };
+
+ gpio_exp1: gpio@21 {
+ compatible = "nxp,pcf8574";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_exp1_int_pins_default>;
+ interrupt-parent = <&main_gpio1>;
+ interrupts = <49 IRQ_TYPE_EDGE_FALLING>;
+ gpio-line-names = "GPIO0_HDMI_RST", "GPIO1_CAN_nEN",
+ "GPIO2_LED", "GPIO3_MCU_CAN0_nEN",
+ "GPIO4_BUT2", "GPIO5_MCU_CAN1_nEN",
+ "GPIO6_AUDIO_GPIO", "GPIO7_AUDIO_USER_RESET";
+ };
+
+ gpio_exp2: gpio@23 {
+ compatible = "nxp,pcf8574";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_exp2_int_pins_default>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
+ gpio-line-names = "CSI1_STROBE", "CSI1_TRIGGER",
+ "CSI1_SHUTTER", "CSI1_OE",
+ "CSI0_STROBE", "CSI0_TRIGGER",
+ "CSI0_SHUTTER", "CSI0_OE";
+ };
+
+ current-sensor@40 {
+ compatible = "ti,ina233";
+ reg = <0x40>;
+ shunt-resistor = <18000>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c02";
+ reg = <0x51>;
+ pagesize = <16>;
+ };
+};
+
+&main_mcan0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcan0_pins_default>;
+ phys = <&can_tc0>;
+ status = "okay";
+};
+
+&main_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart0_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&mcasp0 {
+ #sound-dai-cells = <0>;
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcasp0_pins_default>;
+ tdm-slots = <2>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 2
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+ status = "okay";
+};
+
+&pcie0_rc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_pcie_pins_default>;
+ num-lanes = <1>;
+ phys = <&serdes1_pcie_link>;
+ phy-names = "pcie-phy";
+ reset-gpios = <&main_gpio0 31 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&sdhci1 {
+ /* SD/MMC */
+ vmmc-supply = <&vcc_3v3_mmc>;
+ vqmmc-supply = <&vddshv_sdio>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc1_pins_default>;
+ disable-wp;
+ no-1-8-v;
+ bootph-all;
+ status = "okay";
+};
+
+&serdes_ln_ctrl {
+ idle-states = <J722S_SERDES0_LANE0_USB>,
+ <J722S_SERDES1_LANE0_PCIE0_LANE0>;
+};
+
+&serdes0 {
+ status = "okay";
+
+ serdes0_usb_link: phy@0 {
+ reg = <0>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_USB3>;
+ resets = <&serdes_wiz0 1>;
+ };
+};
+
+&serdes_wiz0 {
+ status = "okay";
+};
+
+&serdes1 {
+ status = "okay";
+
+ serdes1_pcie_link: phy@0 {
+ reg = <0>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ cdns,phy-type = <PHY_TYPE_PCIE>;
+ resets = <&serdes_wiz1 1>;
+ };
+};
+
+&serdes_wiz1 {
+ clocks = <&k3_clks 280 0>, <&k3_clks 280 1>, <&pcie_refclk0>;
+ status = "okay";
+};
+
+&usbss0 {
+ ti,vbus-divider;
+ status = "okay";
+};
+
+&usb0 {
+ dr_mode = "otg";
+ usb-role-switch;
+ maximum-speed = "high-speed";
+
+ port {
+ usb0_ep: endpoint {
+ remote-endpoint = <&usb0_con>;
+ };
+ };
+};
+
+&usbss1 {
+ ti,vbus-divider;
+ status = "okay";
+};
+
+&usb1 {
+ dr_mode = "host";
+ phys = <&serdes0_usb_link>;
+ phy-names = "cdns3,usb3-phy";
+ maximum-speed = "super-speed";
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] fpga: xilinx-pr-decoupler: Use devm_clk_get_prepared()
From: Xu Yilun @ 2026-06-26 17:22 UTC (permalink / raw)
To: Pandey, Radhey Shyam
Cc: Michal Simek, linux-kernel, monstr, git, Moritz Fischer, Tom Rix,
Xu Yilun, moderated list:ARM/ZYNQ ARCHITECTURE,
open list:FPGA MANAGER FRAMEWORK
In-Reply-To: <5bd0f7db-7ec0-4390-b6ea-1edca46e1ca7@amd.com>
On Tue, Jun 23, 2026 at 04:31:28PM +0530, Pandey, Radhey Shyam wrote:
> > The driver keeps the "aclk" clock prepared but disabled in its idle
> > state, toggling only the atomic clk_enable()/clk_disable() around
> > register accesses in the bridge enable_set/enable_show callbacks.
> >
> > At probe time this was open-coded as clk_prepare_enable() immediately
> > followed by clk_disable(), leaving the clock prepared, with a matching
> > clk_unprepare() in the error path and in remove().
> >
> > devm_clk_get_prepared() expresses exactly this: it gets and prepares the
> > clock and unprepares it automatically on driver detach.
> >
> > Use it to drop the manual prepare/disable dance, the error-path
> > unprepare, and the now-empty clock teardown in remove().
> >
> > Signed-off-by: Michal Simek <michal.simek@amd.com>
>
> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Reviewed-by: Xu Yilun <yilun.xu@intel.com>
Will apply to for-next when 7.2-rc1 comes.
^ permalink raw reply
* Re: [PATCH] media: meson: vdec: fix use-after-free of prev_frame in codec_vp9_rm_noshow_frame()
From: Dan Carpenter @ 2026-06-26 17:29 UTC (permalink / raw)
To: Doruk Tan Ozturk
Cc: Neil Armstrong, Greg Kroah-Hartman, Mauro Carvalho Chehab,
Hans Verkuil, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-media, linux-amlogic, linux-staging, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260626164025.52694-1-doruk@0sec.ai>
On Fri, Jun 26, 2026 at 06:40:25PM +0200, Doruk Tan Ozturk wrote:
> codec_vp9_rm_noshow_frame() frees the first non-shown reference frame on
> ref_frames_list without excluding vp9->prev_frame. When the previously
> decoded frame was a non-show (alt-ref) frame and the current frame is a
> non-show inter frame, the freed object is the one vp9->prev_frame still
> points to; codec_vp9_set_mpred_mv() then dereferences the stale pointer
> (use_prev_frame_mvs and codec_vp9_get_frame_mv_paddr()), a use-after-free.
>
> The sibling cleanup codec_vp9_show_frame() already guards this pointer
> (tmp == vp9->prev_frame); rm_noshow_frame() simply omits the same check.
> Add it.
>
> The fields that drive this path (show_frame, frame_type, intra_only) are
> parsed from the VP9 bitstream, so a crafted stream fed to the stateless
> decoder can trigger the free-then-use.
>
> Found by static analysis; not yet runtime-reproduced (Amlogic Meson
> hardware required).
>
> Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
>
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
> ---
> drivers/staging/media/meson/vdec/codec_vp9.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/staging/media/meson/vdec/codec_vp9.c b/drivers/staging/media/meson/vdec/codec_vp9.c
> index 8e80ecf84..572f418c9 100644
> --- a/drivers/staging/media/meson/vdec/codec_vp9.c
> +++ b/drivers/staging/media/meson/vdec/codec_vp9.c
> @@ -1247,6 +1247,15 @@ static void codec_vp9_rm_noshow_frame(struct amvdec_session *sess)
> if (tmp->show)
> continue;
>
> + /*
> + * prev_frame is still referenced by the MV predictor in
> + * codec_vp9_set_mpred_mv(); the sibling codec_vp9_show_frame()
> + * already excludes it before freeing. Do the same here to avoid
> + * a use-after-free of vp9->prev_frame.
> + */
> + if (tmp == vp9->prev_frame)
> + continue;
I have not looked at this code before so I'm speaking from a position
of ignorance but codec_vp9_show_frame() checks vp9->cur_frame as well.
Shouldn't we check that here as well?
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v5 0/8] can: flexcan: Add NXP S32N79 SoC support
From: Ciprian Marian Costea @ 2026-06-26 17:34 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam, Vincent Mailhol
In-Reply-To: <20260609142954.1807421-1-ciprianmarian.costea@oss.nxp.com>
On 6/9/2026 5:29 PM, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
Hello Marc,
I just want to ping for the status of this series.
Please let me know if you expect any more changes.
Best Regards,
Ciprian
>
> This patch series adds FlexCAN support for the NXP S32N79 SoC.
>
> The S32N79 is an automotive-grade processor from NXP with multiple
> FlexCAN instances. The FlexCAN IP integration on S32N79 differs from
> other SoCs in the interrupt routing - it uses two separate interrupt
> lines:
> - one interrupt for mailboxes 0-127
> - one interrupt for bus error detection and device state changes
>
> The CAN controllers are connected through an irqsteer interrupt
> controller in the RCU (Resource Control Unit) domain.
>
> This series:
> 1. Splits flexcan_irq() into dedicated handlers for multi-IRQ platforms
> 2. Adds dt-bindings documentation for S32N79 FlexCAN
> 3. Introduces FLEXCAN_QUIRK_IRQ_BERR to handle the two-interrupt
> configuration
> 4. Adds S32N79 device data and compatible string to the driver
> 5. Adds FlexCAN device tree nodes for S32N79 SoC
> 6. Enables FlexCAN devices on the S32N79-RDB board
>
> Tested on S32N79-RDB board with CAN and CAN FD communication.
>
> v5 -> v4
> - Simplified splitting rx/tx masks per mailbox IRQ line
>
> v4 -> v3
> - flexcan_chip_interrupts_enable(): disable/enable all IRQ lines
> (not just dev->irq) during IMASK register writes
> - Split rx/tx masks per mailbox IRQ line (struct flexcan_mb_irq) so
> each handler on S32G2 only processes its own MB range
> - Added received Acked-by tag on DT bindings patch
>
> v3 -> v2
> - Split flexcan_irq() into dedicated handlers (flexcan_irq_mb,
> flexcan_irq_boff, flexcan_irq_berr) to fix duplicate event
> processing when multiple IRQ lines run concurrently (new patch).
> - Added flexcan_irq_esr() handler composing state + berr for S32N79
> - Ordered quirks used by s32n devtype data by value.
>
> v2 -> v1
> - Renamed FLEXCAN_QUIRK_NR_IRQ_2 to FLEXCAN_QUIRK_IRQ_BERR to better
> describe the actual hardware feature
> - Appended new quirk at the end
> - Switched from platform_get_irq to platform_get_irq_byname usage
> - Updated interrupt description in dt-bindings
>
> Ciprian Marian Costea (8):
> can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
> can: flexcan: disable all IRQ lines in
> flexcan_chip_interrupts_enable()
> can: flexcan: split rx/tx masks per mailbox IRQ line
> dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support
> can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
> can: flexcan: add NXP S32N79 SoC support
> arm64: dts: s32n79: add FlexCAN nodes
> arm64: dts: s32n79: enable FlexCAN devices
>
> .../bindings/net/can/fsl,flexcan.yaml | 30 ++-
> arch/arm64/boot/dts/freescale/s32n79-rdb.dts | 12 +
> arch/arm64/boot/dts/freescale/s32n79.dtsi | 50 ++++
> drivers/net/can/flexcan/flexcan-core.c | 227 +++++++++++++++---
> drivers/net/can/flexcan/flexcan.h | 2 +
> 5 files changed, 292 insertions(+), 29 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v4 3/4] drivers/firmware: add SDEI cross-CPU NMI service for arm64
From: Catalin Marinas @ 2026-06-26 17:11 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel, Kiryl Shutsemau (Meta)
In-Reply-To: <ab745689c0bfd01438d98ed1c79328bf2121be3b.1781709543.git.kas@kernel.org>
On Wed, Jun 17, 2026 at 08:20:04PM +0100, Kiryl Shutsemau wrote:
> +/*
> + * Raise callback for nmi_trigger_cpumask_backtrace(): signal event 0
> + * at every CPU still pending in @mask. The framework excludes the local
> + * CPU from @mask before calling us.
> + */
> +static void sdei_nmi_raise_backtrace(cpumask_t *mask)
> +{
> + unsigned int cpu;
> +
> + for_each_cpu(cpu, mask)
> + sdei_nmi_fire(cpu);
> +}
Does this need a barrier as in patch 4? Sashiko spotted that
backtrace_mask won't be visible without a dsb(ishst). Again, as per my
comment in patch 4, we get away with this because of the TF-A
implementation but that's not guaranteed (we could ask for the SDEI spec
to be updated assuming all firmware implementations do this).
--
Catalin
^ permalink raw reply
* Re: [PATCH] soc: imx8m: fix clock reference leak in imx8m_soc_prepare()
From: Frank Li @ 2026-06-26 16:17 UTC (permalink / raw)
To: Felix Gu
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Marco Felsch, Peng Fan, Shawn Guo, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260626-soc-imx8m-v1-1-62657e3376dc@gmail.com>
On Fri, Jun 26, 2026 at 10:37:35PM +0800, Felix Gu wrote:
> When clk_prepare_enable() fails, the error path does not release the
> clock reference obtained by of_clk_get_by_name(). Add clk_put() to
> the error path before iounmap().
>
> Fixes: 390c01073f5d ("soc: imx8m: Cleanup with adding imx8m_soc_[un]prepare")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
Thanks for your fix
> drivers/soc/imx/soc-imx8m.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c
> index fc080e56f50d..de19972435f9 100644
> --- a/drivers/soc/imx/soc-imx8m.c
> +++ b/drivers/soc/imx/soc-imx8m.c
> @@ -150,10 +150,12 @@ static int imx8m_soc_prepare(struct platform_device *pdev, const char *ocotp_com
>
> ret = clk_prepare_enable(drvdata->clk);
> if (ret)
> - goto err_clk;
> + goto put_clk;
imx8m_soc_prepare() call be from probe(), can your use
devm_clk_get_enabled() to combine clk get and enable together.
And use new patch change ioremap() to devm_ioremap().
Frank
>
> return 0;
>
> +put_clk:
> + clk_put(drvdata->clk);
> err_clk:
> iounmap(drvdata->ocotp_base);
> return ret;
>
> ---
> base-commit: 30ffa8de54e5cc80d93fd211ca134d1764a7011f
> change-id: 20260626-soc-imx8m-938e89104044
>
> Best regards,
> --
> Felix Gu <ustc.gu@gmail.com>
>
>
^ permalink raw reply
* Re: [PATCH 5.15.y] selftests: arm64: signal: skip SVE VL change test with single VL
From: Sasha Levin @ 2026-06-26 17:54 UTC (permalink / raw)
To: stable, gregkh
Cc: Sasha Levin, shuah, linux-kernel, will, catalin.marinas, broonie,
linux-arm-kernel, linux-kselftest, cristian.marussi, Yijia Wang
In-Reply-To: <20260626-b4-arm64-515-preview-clean-v1-1-ad19e286e322@bytedance.com>
> [PATCH 5.15.y] selftests: arm64: signal: skip SVE VL change test with single VL
Can we keep the commit message the same as upstream? Is there a reason to
rewrite it?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: Chris Lu (陸稚泓) @ 2026-06-26 17:56 UTC (permalink / raw)
To: luiz.dentz@gmail.com, i@rong.moe
Cc: marcel@holtmann.org, AngeloGioacchino Del Regno,
SS Wu (巫憲欣), linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-bluetooth@vger.kernel.org,
patchwork-bot+bluetooth@kernel.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <CABBYNZ+rR71SKUEuZBTf+E3SwRNzV2-s-zt8EwNJM3PSx9qB_A@mail.gmail.com>
Hi Rong and Luiz,
On Fri, 2026-06-26 at 12:54 -0400, Luiz Augusto von Dentz wrote:
> Hi,
>
>
> On Fri, Jun 26, 2026 at 7:19 AM Rong Zhang <i@rong.moe> wrote:
> >
> > Hi Chris,
> >
> > 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)"
> > <Chris.Lu@mediatek.com> 写道：
> > > Hi Luiz,
> > >
> > > Could we revert this change?
> >
> > Please don't. The fundamental goal of the patch is to make
> > MT7922/MT7925 *usable* on affected platforms.
> >
> > Moreover, almost all recent AMD platforms ship with MT7922/MT7925,
> > reverting this patch affects quite a lot of users. Almost every AMD
> > platform I've met suffers from the issue, and there are plenty of
> > bug reports.
> >
> > Intel platforms never ship with MTK WLAN NICs, so I can't tell if
> > the issue is reproducible on them.
>
We still have non-AMD platforms with MT7922/7925, where
"wakeup by Bluetooth" is an essential feature. In other word, this
change will have a serious impact to them.
> We cannot really remove it anymore, since it has already been pulled.
> Therefore, I strongly prefer that the issue is fixed somehow or if
> there is no other way then a proper revert patch must be sent, since
> I
> don't have any hardware with this controller I cannot really test
> this
> myself.
>
Got it.
> > >
> > > Sorry, MediaTek wasn't aware someone submitted this change and it
> > > had
> > > already been merged.
> > >
> > > MTK believes this issue is strongly related to the platform's USB
> > > hub
> > > behavior,
> >
> > Still, I believe that there are some interoperability issues in
> > MT7922/MT7925's hardware or firmware, as reinitializing the XHCI
> > root hub (by logically removing it from the PCI bus and probing it
> > again) doesn't make it recover at all.
> >
> > > The product lines MTK directly support haven't reported such
> > > issue.
> >
> > ...or did you mean none of the existing AMD platforms are supported
> > by MTK?
> >
I'll report it to corresponding department to see if they have such
issue. (I'm not from Bluetooth with AMD platform support team)
> > >
> > > Disable wake capability would severely impact wake on Bluetooth
> > > on
> > > MTK's official product lines.
> >
> > Could you kindly explain "MTK's official product lines"?
> >
Some products are module makers selling our modules to downstream
customers directly.
> > > Furthermore, this patch looks like a
> > > workaround. There should be a better way to handle this issue. We
> > > hope
> > > this change can be reverted.
> >
> > The issue is severe on affected platforms by making the Bluetooth
> > interface completely gone. IMHO, we must figure out the "better
> > way" before reverting it, or else it's more like burying your head
> > into sand by shouting "works fine on our platforms" (TM).
> >
> > That being said, I think we can narrow the range of the quirk down
> > to AMD platforms only. Does it make sense to you? If so, I will
> > submit a patch for this.
>
As I mentioned above, we have many platforms using the kernel driver,
not just AMD,
If this change can be limited to specific platform , it would be the
best way so far.
> Ok, then you guys please coordinate. I don't want to start requiring
> Sign-Off-By (SOB) from driver authors because this instance shows
> that
> response time can be very long. Therefore, the best way forward in my
> opinion, is to have the issue fixed in a way that works for both of
> you.
Of course, Mediatek BT team also agree that any issue need to be
resolved, However, original issue for this change requires further
verification of Hardware/firmware and even USB behavior. A device that
can reproduce the issue stably is required in order to experiment and
identify the root cause.
As mentioned, I'll deliver internally to relate support team. If they
have similar settings, MTK will attempt to reproduce it and provide an
official solution.
Thanks very much for your input and understanding.
Best Regards,
Chris Lu
^ permalink raw reply
* [PATCH v2 03/17] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-26 18:00 UTC (permalink / raw)
To: Linus Torvalds, Greg Kroah-Hartman
Cc: Nicolas Frattaroli, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Heiko Stuebner, linux-rockchip, linux-sound,
linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1782490566.git.u.kleine-koenig@baylibre.com>
Currently that header is only included via:
<sound/dmaengine_pcm.h> ->
<sound/soc.h> ->
<linux/platform_device.h>
which doesn't look reliable, still more in the presence of the comment:
/* For the current users of sound/soc.h to avoid build issues */
in <sound/soc.h>.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
sound/soc/rockchip/rockchip_sai.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
index a195e96fed0a..37e81d56bc16 100644
--- a/sound/soc/rockchip/rockchip_sai.c
+++ b/sound/soc/rockchip/rockchip_sai.c
@@ -11,6 +11,7 @@
#include <linux/delay.h>
#include <linux/of_device.h>
#include <linux/clk.h>
+#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
#include <linux/reset.h>
--
2.47.3
^ permalink raw reply related
* [PATCH 1/1] dt-bindings: mfd: st,stmpe: document st,stmpe610 compatible
From: Frank.Li @ 2026-06-26 18:31 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Coquelin, Alexandre Torgue, Linus Walleij,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
Cc: imx, Frank Li
From: Frank Li <Frank.Li@nxp.com>
The STMPE610 has long been supported by the STMPE I2C MFD driver, but its
compatible string was never documented.
Add the missing st,stmpe610 compatible string to fix below CHECK_DTBS
warnings:
imx53-m53evk.dtb: /soc/bus@60000000/i2c@63fc4000/touchscreen@41: failed to match any schema with compatible: ['st,stmpe610']
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Documentation/devicetree/bindings/mfd/st,stmpe.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
index 4bb05d544901c..70afdf68a0546 100644
--- a/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stmpe.yaml
@@ -21,6 +21,7 @@ properties:
compatible:
enum:
- st,stmpe601
+ - st,stmpe610
- st,stmpe801
- st,stmpe811
- st,stmpe1600
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] irqchip/gic-v3-its: Fix OF node reference leak
From: 최유호 @ 2026-06-26 18:37 UTC (permalink / raw)
To: Marc Zyngier; +Cc: Thomas Gleixner, linux-arm-kernel, linux-kernel
In-Reply-To: <867bnlqv0e.wl-maz@kernel.org>
Thanks for the review, Marc.
> Please keep this on a single line. I find nothing more irritating than
> these split assignments.
>
> Worth taking this opportunity to fix the indentation here.
I will fix the assignment formatting and indentation and send v3.
Thanks,
Yuho
^ permalink raw reply
* Re: [PATCH v4 2/2] tracing: Remove trace_printk.h from kernel.h
From: Nathan Chancellor @ 2026-06-26 19:03 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260626045119.659d1e6b@fedora>
On Fri, Jun 26, 2026 at 04:51:19AM -0400, Steven Rostedt wrote:
> On Thu, 25 Jun 2026 16:41:58 -0700
> Nathan Chancellor <nathan@kernel.org> wrote:
>
>
> > The following diff resolves it for me, should I send it as a separate
> > patch or do you want to just fold it in with a note?
> >
> > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> > index 621566345406..2301a701ffbb 100644
> > --- a/include/linux/lockdep.h
> > +++ b/include/linux/lockdep.h
> > @@ -10,6 +10,7 @@
> > #ifndef __LINUX_LOCKDEP_H
> > #define __LINUX_LOCKDEP_H
> >
> > +#include <linux/instruction_pointer.h>
>
> Ah, so the reason for this breakage is because lockdep was relying on
> instruction_pointer.h, that just happened to be included in kernel.h
> via trace_printk.h.
Correct.
> This is a separate issue, so it should be a separate patch. I'll add it
> as patch 1 of this series.
Sounds good, thanks!
> Can you send me the config you used. This didn't trigger in my tests.
It is a plain allmodconfig, for example on arm:
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- allmodconfig lib/test_context-analysis.o
In file included from include/linux/local_lock_internal.h:8,
from include/linux/local_lock.h:5,
from lib/test_context-analysis.c:9:
include/linux/local_lock_internal.h: In function 'local_lock_acquire':
include/linux/lockdep.h:541:87: error: '_THIS_IP_' undeclared (first use in this function)
541 | #define lock_map_acquire(l) lock_acquire_exclusive(l, 0, 0, NULL, _THIS_IP_)
| ^~~~~~~~~
include/linux/lockdep.h:509:88: note: in definition of macro 'lock_acquire_exclusive'
509 | #define lock_acquire_exclusive(l, s, t, n, i) lock_acquire(l, s, t, 0, 1, n, i)
| ^
include/linux/local_lock_internal.h:46:9: note: in expansion of macro 'lock_map_acquire'
46 | lock_map_acquire(&l->dep_map);
| ^~~~~~~~~~~~~~~~
include/linux/lockdep.h:541:87: note: each undeclared identifier is reported only once for each function it appears in
...
I also reproduced it on top of allnoconfig:
$ cat allno.config
CONFIG_CONTEXT_ANALYSIS_TEST=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_EXPERT=y
CONFIG_MMU=y
CONFIG_RUNTIME_TESTING_MENU=y
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=1 clean allnoconfig lib/test_context-analysis.o
<same error as above>
--
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH V3 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Frank Li @ 2026-06-26 19:40 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl, imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-2-sherry.sun@oss.nxp.com>
On Fri, Jun 26, 2026 at 10:31:19AM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> suspend to preserve wakeup capability of the devices and also not to power
> on the devices in the init path.
Need empty line here.
> This allows controller power-off to be skipped when some devices(e.g. M.2
> cards key E without auxiliary power) required to support PCIe L2 link state
> and wake-up mechanisms.
>
> Move pci_pwrctrl_create_devices() to imx_pcie_probe() so that it is only
> called once during probe, similar to other regulator_get calls.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 43 ++++++++++++++++-----------
> 1 file changed, 25 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 0fa716d1ed75..0685573fee71 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -1382,16 +1382,12 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> }
> }
>
> - ret = pci_pwrctrl_create_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to create pwrctrl devices\n");
> - goto err_reg_disable;
> - }
> -
Please two patch do that. one patch move pci_pwrctrl_create_devices() to
probe
one patch check skip_power_off.
> - ret = pci_pwrctrl_power_on_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to power on pwrctrl devices\n");
> - goto err_pwrctrl_destroy;
> + if (!pp->skip_pwrctrl_off) {
> + ret = pci_pwrctrl_power_on_devices(dev);
> + if (ret) {
> + dev_err(dev, "failed to power on pwrctrl devices\n");
> + goto err_reg_disable;
> + }
> }
>
> ret = imx_pcie_clk_enable(imx_pcie);
> @@ -1460,10 +1456,8 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> err_clk_disable:
> imx_pcie_clk_disable(imx_pcie);
> err_pwrctrl_power_off:
> - pci_pwrctrl_power_off_devices(dev);
> -err_pwrctrl_destroy:
> - if (ret != -EPROBE_DEFER)
> - pci_pwrctrl_destroy_devices(dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(dev);
> err_reg_disable:
> if (imx_pcie->vpcie)
> regulator_disable(imx_pcie->vpcie);
> @@ -1482,7 +1476,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp *pp)
> }
> imx_pcie_clk_disable(imx_pcie);
>
> - pci_pwrctrl_power_off_devices(pci->dev);
> + if (!pci->pp.skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(pci->dev);
> if (imx_pcie->vpcie)
> regulator_disable(imx_pcie->vpcie);
> }
> @@ -1954,11 +1949,15 @@ static int imx_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = pci_pwrctrl_create_devices(dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to create pwrctrl devices\n");
> +
> pci->use_parent_dt_ranges = true;
> if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> ret = imx_add_pcie_ep(imx_pcie, pdev);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> /*
> * FIXME: Only single Device (EPF) is supported due to the
> @@ -1973,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device *pdev)
> pci->pp.use_atu_msg = true;
> ret = dw_pcie_host_init(&pci->pp);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> if (pci_msi_enabled()) {
> u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
> @@ -1985,16 +1984,24 @@ static int imx_pcie_probe(struct platform_device *pdev)
> }
>
> return 0;
> +
> +err_pwrctrl_destroy:
> + if (ret != -EPROBE_DEFER)
> + pci_pwrctrl_destroy_devices(dev);
> + return ret;
Mani said he will fix DEFER problem soon.
Frank
> }
>
> static void imx_pcie_shutdown(struct platform_device *pdev)
> {
> struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> + struct dw_pcie *pci = imx_pcie->pci;
> + struct dw_pcie_rp *pp = &pci->pp;
>
> /* bring down link, so bootloader gets clean state in case of reboot */
> imx_pcie_assert_core_reset(imx_pcie);
> imx_pcie_assert_perst(imx_pcie, true);
> - pci_pwrctrl_power_off_devices(&pdev->dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(&pdev->dev);
> pci_pwrctrl_destroy_devices(&pdev->dev);
> }
>
> --
> 2.50.1
>
>
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Kiryl Shutsemau @ 2026-06-26 19:40 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <aj6xvvY4AA-fQG2X@arm.com>
On Fri, Jun 26, 2026 at 06:07:10PM +0100, Catalin Marinas wrote:
> On Wed, Jun 17, 2026 at 08:20:01PM +0100, Kiryl Shutsemau wrote:
> > - A CPU stopped by the SDEI rung is parked, not powered off via PSCI
> > CPU_OFF. Reaching and dumping the wedged CPU -- the point of the
> > series -- works, and it matches the shared stop path's own park
> > fallback when CPU_OFF is unavailable. The consequence is that an SMP
> > crash-capture kernel cannot re-online such a CPU (it stays "already
> > on"); the capture kernel boots and runs on the remaining CPUs.
> > Powering the stopped CPU off so a capture kernel can reclaim it
> > requires completing the SDEI event and then CPU_OFF, which hit a
> > firmware-specific issue still under investigation; it is left as a
> > follow-up and does not affect the dump's contents.
>
> Just to understand, your firmware cannot cope with a PSCI CPU_OFF from
> the SDEI handler? This is one of the required calls to be supported.
I did chase it a fair bit. Bisecting on Grace: completing the event and
parking (no CPU_OFF) works, and so does the stack-switch + C-call setup
on its own. The hang only appears once I call PSCI CPU_OFF after the
event -- and it persists even with DAIF masked and the GIC PMR reset
first, so it isn't leftover interrupt/priority state from the dispatch.
It's a silent wedge: no TF-A exception report, nothing after the
last console line.
But I have not tried calling CPU_OFF directly, without completing the
event. I assumed it is required. Will give it a try when I have time.
Either way this is a side quest: it only lets a crash kernel reclaim the
stopped CPU. The dump itself is complete, so it's nice-to-have, not
required for the series.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v4 4/4] arm64: escalate smp_send_stop() to an SDEI NMI as a last resort
From: Kiryl Shutsemau @ 2026-06-26 19:46 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <aj6yGbnPDjUpboFZ@arm.com>
On Fri, Jun 26, 2026 at 06:08:41PM +0100, Catalin Marinas wrote:
> On Wed, Jun 17, 2026 at 08:20:05PM +0100, Kiryl Shutsemau wrote:
> > +void sdei_nmi_stop_cpus(const cpumask_t *mask)
> > +{
> > + unsigned int cpu;
> > +
> > + WRITE_ONCE(sdei_nmi_stopping, true);
> > +
> > + /*
> > + * Publish the flag before signalling. The SMC is a context-sync
> > + * event, not a barrier, so WRITE_ONCE() alone could let the store be
> > + * observed after the event it triggers. The barrier is cumulative: a
> > + * target that sees the event is guaranteed to see the flag.
> > + */
> > + smp_wmb();
> > +
> > + for_each_cpu(cpu, mask)
> > + sdei_nmi_fire(cpu);
> > +}
>
> The smp_wmb() is not sufficient here. In the GIC IPI code we use a
> dsb(ishst). It should be similar here. I think TF-A does this already
> but it's unclear from the SDEI spec that it is mandated.
You're right, I'll switch it to dsb(ishst) to match gic_ipi_send_mask().
And as you pointed, the xame fix is needed in 3/4: the backtrace path
publishes backtrace_mask before signalling and currently has no barrier
at all (as the bot spotted), so it needs the dsb(ishst) there too.
I'll also drop the now-incorrect "cumulative wmb" comment.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [RFC] drm/imx: upstream direction for i.MX95 display support
From: Piyush Patle @ 2026-06-26 19:53 UTC (permalink / raw)
To: Liu Ying
Cc: dri-devel, imx, linux-arm-kernel, marex, daniel.baluta, Frank.Li,
shawnguo, tzimmermann, maarten.lankhorst, mripard, airlied,
simona
In-Reply-To: <aj5MNiKSCiEDvDzL@raspi>
On Fri, Jun 26, 2026 at 3:22 PM Liu Ying <victor.liu@nxp.com> wrote:
>
> On Wed, Jun 24, 2026 at 03:33:18PM +0530, Piyush Patle wrote:
>
> [...]
>
> > The current dc/ implementation is a multi-device component driver with one
> > platform_driver per block bound via the component framework. The downstream
> > i.MX95 driver is a single monolithic platform_driver mapping all blocks from
> > one register base. Unifying appears to require reconciling two bind models,
> > rather than only adding match_data.
>
Hi Liu,
Thanks for the detailed reply.
> I think that upstream i.MX95 display controller driver would also be based
> on the component helper. That's something for sure.
>
> [...]
That answers the biggest question I had. Knowing that upstream i.MX95 should
follow the component helper makes the overall direction much clearer.
>
> > There is also anticipated divergence which is not yet upstream (i.MX8QXP
> > prefetch/PRG, LTS and tiling modifiers, and the downstream i.MX95 blit
> > engine), although mainline dc/ is KMS-only today.
>
> Just want to point out that I sent out v5 patch set[2] to add i.MX8QXP
> prefetch engine(DPRC + PRG) support for KMS. That changes the driver's
> mode setting code a lot.
>
> [2] https://lore.kernel.org/all/20251027-imx8-dc-prefetch-v5-0-4ecb6c6d4941@nxp.com/
>
> [...]
Thanks for pointing that out. I went through the v5 series together with the
downstream i.MX95 driver. Although the modesetting paths are diverging, many of
the common display blocks still appear to share very similar register
programming, with most differences being SoC-specific data such as register
offsets and tables.
>
> > One question for Liu Ying is whether the separate-driver plus shared
> > helper-library approach is still the preferred direction, and where the
> > helper boundary would be drawn (which blocks/ops are shared versus
> > implemented per driver).
>
> Yes, separate DRM drivers + a helper library approach is still the direction
> I want. I think that the drivers and library would sit in the same
> directory drivers/gpu/drm/imx/dc/.
>
> The purpose to add a library is to share code to reduce overall code lines.
> I'd assume that shared blocks or common part of slightly different blocks
> should be covered by the library.
>
> [...]
Thanks for confirming that.
Based on that comparison, my current plan is to prepare a refactoring series
that shares the common implementations for ConstFrame, ExtDst, LayerBlend,
FrameGen and the FetchUnit base through a helper library, while keeping the
i.MX95-specific blocks as separate component drivers.
One implementation detail I'd like to clarify: would you prefer the shared
code to remain in the existing dc-*.c files with additional i.MX95 match
data, or would you rather see it extracted into separate helper source files?
>
> > how the component and monolithic driver models
> > would be reconciled given the differences described above.
>
> Like I said above, I don't think upstream driver would be monolithic.
>
Understood. I'll treat the downstream monolithic driver as a reference
and follow these plan for the upstream implementation.
I'll start by preparing a refactoring series for the shared blocks. If the
approach looks reasonable, I'd be happy to post the series for review before
working on the i.MX95 driver itself.
Thanks again for the guidance.
Regards,
Piyush Patle
> --
> Regards,
> Liu Ying
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: Rong Zhang @ 2026-06-26 19:56 UTC (permalink / raw)
To: Chris Lu (陸稚泓), luiz.dentz@gmail.com
Cc: marcel@holtmann.org, AngeloGioacchino Del Regno,
SS Wu (巫憲欣), linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-bluetooth@vger.kernel.org,
patchwork-bot+bluetooth@kernel.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <fd8587e97a48e49332a4ad36e51e18739d000250.camel@mediatek.com>
Hi Chris, Luiz,
On Fri, 2026-06-26 at 17:56 +0000, Chris Lu (陸稚泓) wrote:
> Hi Rong and Luiz,
>
> On Fri, 2026-06-26 at 12:54 -0400, Luiz Augusto von Dentz wrote:
> > Hi,
> >
> >
> > On Fri, Jun 26, 2026 at 7:19 AM Rong Zhang <i@rong.moe> wrote:
> > >
> > > Hi Chris,
> > >
> > > 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)"
> > > <Chris.Lu@mediatek.com> 写道：
> > > > Hi Luiz,
> > > >
> > > > Could we revert this change?
> > >
> > > Please don't. The fundamental goal of the patch is to make
> > > MT7922/MT7925 *usable* on affected platforms.
> > >
> > > Moreover, almost all recent AMD platforms ship with MT7922/MT7925,
> > > reverting this patch affects quite a lot of users. Almost every AMD
> > > platform I've met suffers from the issue, and there are plenty of
> > > bug reports.
> > >
> > > Intel platforms never ship with MTK WLAN NICs, so I can't tell if
> > > the issue is reproducible on them.
> >
> We still have non-AMD platforms with MT7922/7925, where
> "wakeup by Bluetooth" is an essential feature. In other word, this
> change will have a serious impact to them.
Oh, perhaps I missed something before. Your words were a bit unclear to
me at first glance.
You previous reply said "wake on Bluetooth". I interpreted it as USB
remote wakeup upon Bluetooch device connection.
"Wakeup by Bluetooth" is clearer. You meant using the Bluetooth
interface as a wakeup source to wake up the system from sleep, right?
Hmm, it makes more sense to me.
My patch was inspired by commit f4292e2faf52 ("Bluetooth: btusb: Make
the CSR clone chip force-suspend workaround more generic"). The
mentioned commit is correct as the quirky chips can't perform remote
wakeup at all.
If MT7922/MT7925 can reliably wake up the system from sleep, my patch
could be a burden. I won't insist anymore if you'd like to revert it.
>
> > We cannot really remove it anymore, since it has already been pulled.
> > Therefore, I strongly prefer that the issue is fixed somehow or if
> > there is no other way then a proper revert patch must be sent, since
> > I
> > don't have any hardware with this controller I cannot really test
> > this
> > myself.
> >
> Got it.
> > > >
> > > > Sorry, MediaTek wasn't aware someone submitted this change and it
> > > > had
> > > > already been merged.
> > > >
> > > > MTK believes this issue is strongly related to the platform's USB
> > > > hub
> > > > behavior,
> > >
> > > Still, I believe that there are some interoperability issues in
> > > MT7922/MT7925's hardware or firmware, as reinitializing the XHCI
> > > root hub (by logically removing it from the PCI bus and probing it
> > > again) doesn't make it recover at all.
> > >
> > > > The product lines MTK directly support haven't reported such
> > > > issue.
> > >
> > > ...or did you mean none of the existing AMD platforms are supported
> > > by MTK?
> > >
> I'll report it to corresponding department to see if they have such
> issue. (I'm not from Bluetooth with AMD platform support team)
>
> > > >
> > > > Disable wake capability would severely impact wake on Bluetooth
> > > > on
> > > > MTK's official product lines.
> > >
> > > Could you kindly explain "MTK's official product lines"?
> > >
> Some products are module makers selling our modules to downstream
> customers directly.
>
> > > > Furthermore, this patch looks like a
> > > > workaround. There should be a better way to handle this issue. We
> > > > hope
> > > > this change can be reverted.
> > >
> > > The issue is severe on affected platforms by making the Bluetooth
> > > interface completely gone. IMHO, we must figure out the "better
> > > way" before reverting it, or else it's more like burying your head
> > > into sand by shouting "works fine on our platforms" (TM).
> > >
> > > That being said, I think we can narrow the range of the quirk down
> > > to AMD platforms only. Does it make sense to you? If so, I will
> > > submit a patch for this.
> >
> As I mentioned above, we have many platforms using the kernel driver,
> not just AMD,
>
> If this change can be limited to specific platform , it would be the
> best way so far.
I plan to submit another patch to properly fix it next week. In general,
I will:
- narrow the quirk down to AMD platforms only
- disable USB remote wakeup for runtime autosuspend only
- leave the wakeup source as is, so users can enable "wakeup by
Bluetooth" even on AMD platforms if they really want it
Hopefully it will minimize the impact of the workaround.
Thanks,
Rong
>
> > Ok, then you guys please coordinate. I don't want to start requiring
> > Sign-Off-By (SOB) from driver authors because this instance shows
> > that
> > response time can be very long. Therefore, the best way forward in my
> > opinion, is to have the issue fixed in a way that works for both of
> > you.
>
> Of course, Mediatek BT team also agree that any issue need to be
> resolved, However, original issue for this change requires further
> verification of Hardware/firmware and even USB behavior. A device that
> can reproduce the issue stably is required in order to experiment and
> identify the root cause.
>
> As mentioned, I'll deliver internally to relate support team. If they
> have similar settings, MTK will attempt to reproduce it and provide an
> official solution.
>
> Thanks very much for your input and understanding.
>
> Best Regards,
> Chris Lu
^ permalink raw reply
* Re: [PATCH] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop
From: Martin Blumenstingl @ 2026-06-26 20:41 UTC (permalink / raw)
To: Christian Hewitt
Cc: Jerome Brunet, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, linux-sound,
linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260626080422.4191435-1-christianshewitt@gmail.com>
On Fri, Jun 26, 2026 at 10:04 AM Christian Hewitt
<christianshewitt@gmail.com> wrote:
>
> The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 +
> AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream
> vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent:
> it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed,
> producing the "machine gun noise" buffer underrun - on start when switching
> outputs, and on stop when playback ends. The latter is audible on devices
> with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2).
>
> The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on
> both enable and disable (audio_hw_958_enable), and when reconfiguring
> (audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same:
> reset before enabling the DCU on start, and after disabling it on stop.
>
> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
This matches the vendor driver, references:
- fast-reset SPDIF is triggered on enable and disable: [0]
- fast-reset SPDIF is triggered after all of the configuration is
written, then DCU_FF_CTRL is enabled: [1]
[...]
> case SNDRV_PCM_TRIGGER_SUSPEND:
> case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> case SNDRV_PCM_TRIGGER_STOP:
> fifo_spdif_dcu_enable(component, false);
> + snd_soc_component_write(component, AIU_RST_SOFT,
> + AIU_RST_SOFT_958_FAST);
It doesn't seem to make any difference, so just for the record:
The vendor driver first triggers AIU_RST_SOFT_958_FAST then disables DCU: [2]
Best regards,
Martin
[0] https://github.com/endlessm/linux-s905x/blob/c1391ba1116aed801aaabfd9c7bbb76fda9801ec/sound/soc/aml/m8/aml_audio_hw.c#L1016
[1] https://github.com/endlessm/linux-s905x/blob/c1391ba1116aed801aaabfd9c7bbb76fda9801ec/sound/soc/aml/m8/aml_audio_hw.c#L979-L983
[2] https://github.com/endlessm/linux-s905x/blob/c1391ba1116aed801aaabfd9c7bbb76fda9801ec/sound/soc/aml/m8/aml_audio_hw.c#L1016-L1018
^ permalink raw reply
* [PATCH v8 02/29] phy: rockchip: usbdp: Update mode_change after error handling
From: Sebastian Reichel @ 2026-06-26 20:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel, Sashiko
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
If rk_udphy_init() or rk_udphy_setup() fails, the reinit will not be
tried again. Fix this by only updating the variable after all potential
errors have been handled.
Note, that no errors have been seen on real hardware and failures would
most likely be fatal and require at least a full reboot as the function
already asserts the PHY reset lines. So this is more of a theoretical
issue.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-phy/20260612163835.8D5471F000E9@smtp.kernel.org/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index fba35510d88c..a5ffdf7a6e76 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1000,15 +1000,14 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
}
if (udphy->status == UDPHY_MODE_NONE) {
- udphy->mode_change = false;
ret = rk_udphy_setup(udphy);
if (ret)
return ret;
if (udphy->mode & UDPHY_MODE_USB)
rk_udphy_u3_port_disable(udphy, false);
- } else if (udphy->mode_change) {
udphy->mode_change = false;
+ } else if (udphy->mode_change) {
udphy->status = UDPHY_MODE_NONE;
if (udphy->mode == UDPHY_MODE_DP)
rk_udphy_u3_port_disable(udphy, true);
@@ -1017,6 +1016,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
ret = rk_udphy_setup(udphy);
if (ret)
return ret;
+ udphy->mode_change = false;
}
udphy->status |= mode;
--
2.53.0
^ permalink raw reply related
* [PATCH v8 04/29] phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check
From: Sebastian Reichel @ 2026-06-26 20:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel, Sashiko
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
If devm_clk_bulk_get_all() returns -EPROBE_DEFER, it is replaced with
-ENODEV, permanently failing the driver probe instead of allowing it to
defer. Avoid masking the error code to fix the issue.
This effectively drops returning -ENODEV in case no clocks are being
described in DT. This special case will now be handled by the follow-up
check searching for "refclk" and exit with -EINVAL.
None of this will be hit in practice, since the driver is only used by
RK3588 and RK3576 - on these platforms the DT is validated to contain
the clocks and the clock driver is force probed early. Thus there is
no need to backport this.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 12dfdd470a78..2845a012eafc 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -427,8 +427,8 @@ static int rk_udphy_clk_init(struct rk_udphy *udphy, struct device *dev)
int i;
udphy->num_clks = devm_clk_bulk_get_all(dev, &udphy->clks);
- if (udphy->num_clks < 1)
- return -ENODEV;
+ if (udphy->num_clks < 0)
+ return udphy->num_clks;
/* used for configure phy reference clock frequency */
for (i = 0; i < udphy->num_clks; i++) {
--
2.53.0
^ permalink raw reply related
* [PATCH v8 03/29] phy: rockchip: usbdp: Do not lose USB3 PHY status
From: Sebastian Reichel @ 2026-06-26 20:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
By default (i.e. without manually enabling runtime PM) DWC3 requests the
USB3 PHY once and keeps it enabled all the time. When DisplayPort is
being requested later on, a mode change is needed. This re-initializes
the PHY. During re-initialization the status variable has incorrectly
been cleared, which means the tracking information for USB3 is lost.
This is not an immediate problem, since the DP side keeps the PHY
enabled. But once DP is toggled off, the whole PHY will be disabled.
This is a problem, because the USB side still needs it powered.
Fix things by not clearing the status flags.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index a5ffdf7a6e76..12dfdd470a78 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1008,7 +1008,6 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
rk_udphy_u3_port_disable(udphy, false);
udphy->mode_change = false;
} else if (udphy->mode_change) {
- udphy->status = UDPHY_MODE_NONE;
if (udphy->mode == UDPHY_MODE_DP)
rk_udphy_u3_port_disable(udphy, true);
--
2.53.0
^ permalink raw reply related
* [PATCH v8 00/29] phy: rockchip: usbdp: Fixes, DP 1-lane support and cleanups
From: Sebastian Reichel @ 2026-06-26 20:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel, Sashiko, William Wu
This series overhauls the Rockchip USBDP driver; apart from a
a bunch of cleanups and small improvements the main goal is to
get the driver ready for proper USB-C DP AltMode support. At
the moment it only contains a semi-working state.
Once this series has landed, it unblocks enabling proper USB-C
DP AltMode on the RK3588 and RK3576 platforms incl. runtime PM
for the Synopsys DesignWare DisplayPort controller.
Apart from this series, further changes are required on the
DRM side. There are no compile-time dependencies between the
DRM side and the PHY side, but the PHY side must be applied
to avoid SErrors once runtime PM is added to the DisplayPort
controller driver. Thus it would be really good to land this
series ASAP as it blocks the DRM side.
Apart from that it also fixes a bunch of issues pointed out by
Sashiko (mostly harmless), as well as some real problems. Among
other things it should help drastically with orientation switch
problems and potential SErrors when a USB-C device is hot-plugged.
With this series applied, I did not notice any SErrors. What I do see is
cmn ana lcpll lock timeouts after a few replugs, which are permanent
(i.e. it still happens when re-trying to init the PHY after running into
the timeout). After a reboot the problem is gone. It seems the dynamic
USB3 disabling increased the chance a lot to hit this problem. I think
this is better than the current status where Serrors can appear on hotplug
due to the re-init. Unfortunately LCPLL is more or less undocumented in
the TRM, so it is hard to figure out what is going on exactly.
Changes in v8:
- Link to v7: https://lore.kernel.org/r/20260625-rockchip-usbdp-cleanup-v7-0-38eb3cf654fd@collabora.com
- Move patch "Limit DP lane count to muxed lanes" after single lane
support, which introduces dp_lanes variable to make sure series
is bi-sectable (Sashiko)
- Force disable HPD in "Drop seamless DP takeover" patch and update
patch description to mention potential issues with SErrors for
bootloaders really keeping the DW-DP on. As mentioned in the new
commit message this is untested as I'm not aware of such a
bootloader anyways; this also means we need to keep the HPD GRF
register defines in the 'Drop DP HPD handling' patch (Sashiko)
- Fix mode logic in "Properly handle TYPEC_STATE_SAFE and
TYPEC_STATE_USB" patch; I blame the heat (Sashiko)
- Improve "Support going from DP-only mode to USB mode" patch to
better handle starting in DP only mode; due to TypeC logic
starting delayed this does not really happen, though (Sashiko)
- Improve "Support going from DP-only mode to USB mode" to avoid
checking previous state and instead power on USB state based
on previous requested state to avoid effects from the flip
callback (Sashiko)
- Update the debug message patch to include some more info
- Ad one more patch, which disables USB3 at startup and drops
the -EPROBE_DEFER logic
Changes in v7:
- Link to v6: https://lore.kernel.org/r/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com
- Add new patch handling missing clock-names in DT gracefully (Sashiko)
- Add new patch handling rk_udphy_reset_deassert_all errors in init check (Sashiko)
- Add new patch to handle Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB (Sashiko)
- Add new patch to avoid xHCI SErrors
Changes in v6:
- Link to v5: https://lore.kernel.org/r/20260612-rockchip-usbdp-cleanup-v5-0-efc83069869f@collabora.com
- Add explicit <linux/string_choices.h> include in last patch (Sashiko)
- Add new patch moving mode_change update after error handling (Sashiko)
- Add new patch fixing error masking of devm_clk_bulk_get_all() (Sashiko)
- Add new patch dropping seamless DP takeover as it is non-functional and buggy (Sashiko)
- Add new patch limiting DP lane count to muxed lanes (Sashiko)
- Add error handling in the patch that keeps clocks running on PHY re-init (Sashiko)
- Also look for DP being configured to second lane for the flip config
in DP single-lane mode, which should at least keep USB working for
this super unusual config (Sashiko)
- Drop useless ret variable in patch introducing guard() for the mutex
- Add error handling for PHY re-enablement in the patch fixing support for
DP-only -> USB mode (Sashiko)
Changes in v5:
- Link to v4: https://lore.kernel.org/r/20260428-rockchip-usbdp-cleanup-v4-0-7775671ece22@collabora.com
- Picked up Acked-by from Rob Herring for DT binding
- Fix typos in commit messages/comments
- Add Fixes tag to "Do not looe USB3 PHY status" patch
- Collect Reviewed-by: Neil Armstrong for multiple patches
- Drop now unused code from "Drop DP HPD handling" patch (Sashiko)
- Ignore mux events not involving DP AltMode (Sashiko)
- Add new patch to support going back from DP only mode to USB combo
mode; technically this is a fix, but DP mode does not yet work
upstream, so it does not matter (Sashiko)
- Add new patch adding a few debug messages, which are useful
to investigate potential hotplug issues in the future
- Sashiko comments about the DT binding and property usage
are wrong as the first port is for the superspeed lanes
used for DP and USB, while the last port is just about
DP aux. I ignored them.
- There is a pre-existing bug, that can already be hit with the
upstream kernel and that the series doesn't fix properly:
Accessing the USB3 controller registers requires the USB PHY
running, since it provides a clock. Re-initializing the PHY
means there is a race-condition - if the system tries to access
the USB3 controller in parallel to the re-init, the system will
hang and/or fail with an SError. By keeping the clocks running
and only asserting the resets this time is minimized by this
series. A proper fix for this will be looked into independently
from this series.
- I used v7.1-rc6 as base, but the driver has no changes since
6.18 even in linux-next and there are no pending patches for
it on the mailinglist either, so it applies to *any* recent
kernel branch.
Changes in v4:
- Link to v3: https://lore.kernel.org/r/20260313-rockchip-usbdp-cleanup-v3-0-3e8fe89a35b5@collabora.com
- rebased to v7.1-rc1 (no changes)
- Update DRM bridge registration patch to avoid registration when DP aux
port is not connected to anything, since this results in errors and some
boards use USBDP instances for USB3 only.
- Add patch renaming mode_change into phy_needs_reinit
- Add patch to re-init PHY on orientation change
- Add patch to factor out lane_mux_sel setup
- Add patch to handle mutex via guard functions
Changes in v3:
- Link to v2: https://lore.kernel.org/r/20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com
- Add patch to register the USBDP PHY as DRM bridge
- Add patch to describe ports in DT binding (used by the DRM bridge)
- Add patch to drop HPD handling from the PHY
Changes in v2:
- Link to v1: https://lore.kernel.org/r/20260203-rockchip-usbdp-cleanup-v1-0-16a6f92ed176@collabora.com
- Added new patches to fix USB3 SError
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
Frank Wang (1):
phy: rockchip: usbdp: Amend SSC modulation deviation
Sebastian Reichel (26):
dt-bindings: phy: rockchip-usbdp: add improved ports scheme
phy: rockchip: usbdp: Update mode_change after error handling
phy: rockchip: usbdp: Do not lose USB3 PHY status
phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check
phy: rockchip: usbdp: Handle missing clock-names DT property gracefully
phy: rockchip: usbdp: Drop seamless DP takeover
phy: rockchip: usbdp: Handle rk_udphy_reset_deassert_all errors in init check
phy: rockchip: usbdp: Keep clocks running on PHY re-init
phy: rockchip: usbdp: Add missing mode_change update
phy: rockchip: usbdp: Limit DP lane count to muxed lanes
phy: rockchip: usbdp: Rename DP lane functions
phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST
phy: rockchip: usbdp: Cleanup DP lane selection function
phy: rockchip: usbdp: Register DP aux bridge
phy: rockchip: usbdp: Drop DP HPD handling
phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit
phy: rockchip: usbdp: Re-init the PHY on orientation change
phy: rockchip: usbdp: Factor out lane_mux_sel setup
phy: rockchip: usbdp: Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB
phy: rockchip: usbdp: Use guard functions for mutex
phy: rockchip: usbdp: Support going from DP-only mode to USB mode
phy: rockchip: usbdp: Clear USB status on PHY exit
phy: rockchip: usbdp: Hold mutex in DP PHY configure
phy: rockchip: usbdp: Add some extra debug messages
phy: rockchip: usbdp: Avoid xHCI SErrors
phy: rockchip: usbdp: Disable USB3 on probe
William Wu (1):
phy: rockchip: usbdp: Fix LFPS detect threshold control
Zhang Yubing (1):
phy: rockchip: usbdp: Support single-lane DP
.../bindings/phy/phy-rockchip-usbdp.yaml | 23 ++
drivers/phy/rockchip/Kconfig | 2 +
drivers/phy/rockchip/phy-rockchip-usbdp.c | 427 ++++++++++-----------
3 files changed, 231 insertions(+), 221 deletions(-)
---
base-commit: 4edcdefd4083ae04b1a5656f4be6cd83ae919ef4
change-id: 20260203-rockchip-usbdp-cleanup-5b59dfb561a3
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* [PATCH v8 01/29] dt-bindings: phy: rockchip-usbdp: add improved ports scheme
From: Sebastian Reichel @ 2026-06-26 20:54 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
Currently the Rockchip USBDP PHY is missing a documented port scheme.
Meanwhile upstream RK3588 DTS files are a bit messy and use different
port schemes. The upstream USBDP PHY Linux kernel driver does not yet
parse the ports at all and thus does not create any implicit ABI either.
But with the current mess it is not possible to properly support USB-C
DP AltMode. Thus this introduces a proper port scheme following roughly
the ports design of the Qualcomm QMP USB4-USB3-DP PHY controller binding
with a slight difference that there is an additional port for the
USB-C SBU port as the Rockchip USB-DP PHY also contains the SBU mux.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
.../bindings/phy/phy-rockchip-usbdp.yaml | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
index 8b7059d5b182..f728acf057e4 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
@@ -114,6 +114,29 @@ properties:
A port node to link the PHY to a TypeC controller for the purpose of
handling orientation switching.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output endpoint of the PHY for USB (or DP when configured into 4 lane
+ mode), which should point to the superspeed port of a USB connector.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the USB controller
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the DisplayPort controller
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output endpoint of the PHY for DP, which should either point to the
+ SBU port of a USB-C connector or a DisplayPort connector input port.
+
required:
- compatible
- reg
--
2.53.0
^ permalink raw reply related
* [PATCH v8 08/29] phy: rockchip: usbdp: Keep clocks running on PHY re-init
From: Sebastian Reichel @ 2026-06-26 20:55 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
When a mode change is required rk_udphy_power_on() disables
the clocks and then calls rk_udphy_setup(), which then enables
all the clocks again before continuing with rk_udphy_init().
Considering that rk_udphy_init() does assert the reset lines,
re-enabling the clocks is just delaying things. Avoid it by
directly calling rk_udphy_init().
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index b8de0a47a616..7fb7e4669f9d 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1020,8 +1020,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
if (udphy->mode == UDPHY_MODE_DP)
rk_udphy_u3_port_disable(udphy, true);
- rk_udphy_disable(udphy);
- ret = rk_udphy_setup(udphy);
+ ret = rk_udphy_init(udphy);
if (ret)
return ret;
udphy->mode_change = false;
--
2.53.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