* Re: [PATCH V4 0/7] PCI: imx6: Integrate pwrctrl API and update device trees
From: Frank.Li @ 2026-06-30 15:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, lpieralisi,
kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach,
Sherry Sun (OSS)
Cc: Frank Li, imx, linux-pci, linux-arm-kernel, devicetree,
linux-kernel, sherry.sun
In-Reply-To: <20260630060710.3294811-1-sherry.sun@oss.nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Tue, 30 Jun 2026 14:07:03 +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> This series integrates the PCI pwrctrl framework into the pci-imx6
> driver and updates i.MX EVK board device trees to support it.
>
> Patches 2-8 update device trees for i.MX EVK boards which maintained
> by NXP to move power supply properties from the PCIe controller node
> to the Root Port child node, which is required for pwrctrl framework.
> Affected boards:
> - i.MX6Q/DL SABRESD
> - i.MX6SX SDB
> - i.MX8MM EVK
> - i.MX8MP EVK
> - i.MX8MQ EVK
> - i.MX8DXL/QM/QXP EVK
> - i.MX95 15x15/19x19 EVK
>
> [...]
Applied, thanks!
[1/7] arm: dts: imx6qdl-sabresd: Move power supply property to Root Port node
commit: b16fded592305f04ae40764f5fa91d5ac6f02a65
[2/7] arm: dts: imx6sx-sdb: Move power supply property to Root Port node
commit: a1af6cf5a6ce526ea41d4686fa14580a48b2e768
[3/7] arm64: dts: imx8mm-evk: Move power supply property to Root Port node
commit: b6a38d70bcbf0893ce5493f3daf0cb19e5102269
[4/7] arm64: dts: imx8mp-evk: Move power supply properties to Root Port node
commit: fde093c386a64c820a704abaab9ffd9ec738cd4d
[5/7] arm64: dts: imx8mq-evk: Move power supply properties to Root Port node
commit: 78610987333b0811a456f9a4782472fad00f4a19
[6/7] arm64: dts: imx8dxl/qm/qxp: Move power supply properties to Root Port node
commit: 240950f3ad76761066ffe399f62670321c1be1f1
[7/7] arm64: dts: imx95: Move power supply properties to Root Port node
commit: 6e53e8b854bc6f8330d07905b73e53ad02aff62b
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Mostafa Saleh @ 2026-06-30 15:33 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: Nicolin Chen, will, robin.murphy, jgg, joro, kees, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, stable, jamien
In-Reply-To: <akPX_N0P2EcI_jbV@google.com>
On Tue, Jun 30, 2026 at 02:51:40PM +0000, Pranjal Shrivastava wrote:
> On Tue, Jun 30, 2026 at 01:17:30PM +0000, Mostafa Saleh wrote:
> > On Mon, Jun 29, 2026 at 11:15:33PM -0700, Nicolin Chen wrote:
> > > When transitioning to a kdump kernel, the primary kernel might have crashed
> > > while endpoint devices were actively bus-mastering DMA. Currently, the SMMU
> > > driver aggressively resets the hardware during probe by clearing CR0_SMMUEN
> > > and setting the Global Bypass Attribute (GBPA) to ABORT.
> > >
> > > In a kdump scenario, this aggressive reset is highly destructive:
> > > a) If GBPA is set to ABORT, in-flight DMA will be aborted, generating fatal
> > > PCIe AER or SErrors that may panic the kdump kernel
> >
> > Can you please clarify more on those errors, what conditions will
> > trigger that?
> > For example, patch 4 disables the EVTQ to avoid events as there might
> > be a lot, why are they not fatal also?
> >
> > > b) If GBPA is set to BYPASS, in-flight DMA targeting some IOVAs will bypass
> > > the SMMU and corrupt the physical memory at those 1:1 mapped IOVAs.
> > >
> > > To safely absorb in-flight DMA, the kdump kernel must leave SMMUEN=1 intact
> > > and avoid modifying STRTAB_BASE. This allows HW to continue translating in-
> > > flight DMA using the crashed kernel's page tables until the endpoint device
> > > drivers probe and quiesce their respective hardware.
> > >
> > > However, the ARM SMMUv3 architecture specification states that updating the
> > > SMMU_STRTAB_BASE register while SMMUEN == 1 is UNPREDICTABLE or ignored.
> > >
> > > This leaves a kdump kernel no choice but to adopt the stream table from the
> > > crashed kernel.
> >
> > In many cases the patches assume that the CDs/STE might be corrupted,
> > but still attempt to retrieve them with some validation
> > (log2size/split...)
> > However, the base address might be broken, TLBs state is unknown...
> >
> > IMO, although that might improve the status quo, there are still
> > heuristics, in addition to noticeable complexity to transition the
> > stream tables. I wonder if FW can deal with AER in that case before
> > booting the kdump kernel.
>
> I guess we're reading the base address from the HW register itself so
> that should be fine? CDs are in-memory so that's why they could be
> corrupted?
For example patch#1 verifies log2size and split and both are read
from HW registers. Same for the base address or other addresses as
the page tables, they might be corrupted due to a buggy driver.
My point is that, it is really hard to assume that the previous state
of registers/STE/page-tables were valid or even consistent, when the
kernel crashed and did not transition the state gracefully.
>
> About the TLB state, I'm not sure what might pollute it, since this is a
> kexec, I don't expect any non-kernel entity to gain program control
> before the kdump kernel.. Hence, IMO, we can't configure FW to deal with
> AER here..
Similarly for TLBs, the kernel might have panicked in the middle of an
unmap or free domain. (not to mention what that means for RPM where
a device reset with unknown TLBs)
Why can't the FW deal with it? As I mentioned above in the previous
reply I am not sure I understand what situation leads into this, when
does a device trigger SError to the system vs when not which is observed
as an event in that case.
Thanks,
Mostafa
>
> Thanks,
> Praan
^ permalink raw reply
* Re: [PATCH 05/11] pinctrl: freescale: IMXRT: Remove NOMMU platform support
From: Rob Herring (Arm) @ 2026-06-30 15:37 UTC (permalink / raw)
To: Frank.Li
Cc: Piotr Wojtaszczyk, Krzysztof Kozlowski, Kees Cook,
linux-arm-kernel, linux-gpio, Gustavo A. R. Silva, Jacky Bai,
Dong Aisheng, Michael Turquette, Brian Masney, Sascha Hauer,
Stefan Agner, imx, Pengutronix Kernel Team, Abel Vesa, Frank Li,
Peng Fan, Stephen Boyd, linux-hardening, Arnd Bergmann,
NXP S32 Linux Team, Fabio Estevam, devicetree, Linus Walleij,
linux-clk, linux-kernel, Vladimir Zapolskiy, Conor Dooley,
Russell King
In-Reply-To: <20260619-dts_cleanup_arm_mcore-v1-5-0101795a2662@nxp.com>
On Fri, 19 Jun 2026 11:41:02 -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Commercial users and hardware vendors migrated to Zephyr or other RTOS
> solutions years ago, leaving the NOMMU platform support effectively
> unused and unmaintained.
>
> Remove the obsolete support to reduce maintenance burden and simplify the
> i.MX platform code.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../devicetree/bindings/pinctrl/fsl,imxrt1050.yaml | 79 -----
> .../devicetree/bindings/pinctrl/fsl,imxrt1170.yaml | 77 -----
> drivers/pinctrl/freescale/Kconfig | 16 -
> drivers/pinctrl/freescale/Makefile | 2 -
> drivers/pinctrl/freescale/pinctrl-imxrt1050.c | 309 ------------------
> drivers/pinctrl/freescale/pinctrl-imxrt1170.c | 349 ---------------------
> 6 files changed, 832 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 0/3] Add devicetree for the Graperain G3568 v2
From: Coia Prant @ 2026-06-30 15:38 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Coia Prant
Changes in v2:
- Fix trailing whitespaces and other formatting issues.
Notes/Unchanged from v1:
- ADC keys have been verified with evtest and works fine; kept unchanged.
- The 'regulator-off-in-suspend' property for vqmmc-supply is retained.
This is a known issue shared by most similar boards and should be
addressed globally later.
Planned future changes (to be both with the similar X3568 v4 board series):
- Replace the legacy 'gpio' label with 'gpios'.
- Add the Bluetooth UART child node.
Coia Prant (3):
dt-bindings: vendor-prefixes: Add graperain
dt-bindings: arm: rockchip: Add Graperain G3568 series
arm64: dts: rockchip: Add devicetree for the Graperain G3568 v2
.../devicetree/bindings/arm/rockchip.yaml | 6 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../rockchip/rk3568-graperain-g3568-v2.dts | 894 ++++++++++++++++++
4 files changed, 903 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-graperain-g3568-v2.dts
--
2.47.3
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add graperain
From: Coia Prant @ 2026-06-30 15:38 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Coia Prant
In-Reply-To: <20260630153810.3574714-2-coiaprant@gmail.com>
Add graperain to the vendor prefixes.
Link: https://www.graperain.cn/ (China)
Link: https://www.graperain.com/ (Global)
Signed-off-by: Coia Prant <coiaprant@gmail.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 396044f368e7c..641a37c0debc9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -682,6 +682,8 @@ patternProperties:
description: Goramo Gorecki
"^gplus,.*":
description: GPLUS
+ "^graperain,.*":
+ description: Shenzhen Graperain Technology Co., Ltd.
"^grinn,.*":
description: Grinn
"^grmn,.*":
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: arm: rockchip: Add Graperain G3568 series
From: Coia Prant @ 2026-06-30 15:38 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Coia Prant
In-Reply-To: <20260630153810.3574714-2-coiaprant@gmail.com>
Document Graperain G3568 v2
which is a development board based on RK3568 SoC.
This series also have an SBC series with the suffix "box".
This board is development board series, not SBC series.
Link: https://www.graperain.cn/RK3568/RK3568-Development/ (China)
Link: https://www.graperain.com/ARM-Embedded-RK3568-Development-Board/ (Global)
Link: https://image.chukouplus.com/upload/C_153/product_file/20211022/6daddec9e400458816dd4c57ba807fc3.pdf
Signed-off-by: Coia Prant <coiaprant@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1a9dde18626d0..9eb2f66ba3856 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -684,6 +684,12 @@ properties:
- const: google,veyron
- const: rockchip,rk3288
+ - description: Graperain G3568 series board
+ items:
+ - enum:
+ - graperain,g3568-v2
+ - const: rockchip,rk3568
+
- description: H96 Max V58 TV Box
items:
- const: haochuangyi,h96-max-v58
--
2.47.3
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: rockchip: Add devicetree for the Graperain G3568 v2
From: Coia Prant @ 2026-06-30 15:38 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Coia Prant
In-Reply-To: <20260630153810.3574714-2-coiaprant@gmail.com>
The Graperain G3568 v2 is an RK3568-based development board, just like
the RK3568-EVB.
It always uses soldered connections between the GR3568CV2 core board and
the RK3568BV2/GR3568BV2 I/O board.
The G3568 board has multiple hardware revisions, and we currently
support v2 (I/O board).
Specification:
- SoC: RockChip RK3568 ARM64 (4 cores)
- eMMC: 16-128 GB
- RAM: 2-16 GB
- Power: DC 12V 2A
- Ethernet: 2x RTL8211F RGMII (10/100/1000 Mbps)
- Wireless radio: 802.11b/g/n/ac dual-band
- LED:
Power: AlwaysOn
User: GPIO
- Button:
ESC: SARADC/0 <1100k µV>
MENU: SARADC/0 <1400k µV>
VOL-: SARADC/0 <430k µV>
VOL+: SARADC/0 <50k µV>
Power/Reset: PMIC RK809
- CAN
CAN/1: 4-pin (PH 2.0)
- PWM
PWM/4: Backlight
PWM/5: Backlight
PWM/7: IR Receiver
- UART:
UART/2: Debug TTL - 1500000 8N1 (1.25mm)
UART/3: TTL (PH 2.0)
UART/4: TTL (PH 2.0)
UART/8: AP6356S Bluetooth
UART/9: TTL (PH 2.0)
- I2C:
I2C/0: PMIC RK809
I2C/1: Touchscreen
I2C/4: Camera
I2C/5: RTC@51 PCF8563
- I2S:
I2S/0: HDMI Sound
I2S/1: RK809 Audio Codec
I2S/3: AP6356S Bluetooth Sound
- SDMMC:
SDMMC/0: microSD (TF) slot
SDMMC/2: AP6356S SDIO WiFi card
- Camera: 1x CSI
- Video: HDMI / DSI0 (MIPI/LVDS) / DSI1 (MIPI/EDP)
- Audio: HDMI / MIC / Speaker / SPDIF / 3.5mm Headphones / AP6356S Bluetooth
- USB:
USB 2.0 HOST x2
USB 2.0 OTG x1 (shared with USB 3.0 OTG/HOST)
USB 3.0 HOST x1
USB 3.0 OTG/HOST x1
- SATA: 1x SATA 3.0 with Power/4-pin
- PCIe: 1x PCIe 3.0 x2 (x4 connecter)
Link:
- https://image.chukouplus.com/upload/C_153/product_file/20211022/6daddec9e400458816dd4c57ba807fc3.pdf
- https://blog.gov.cooking/archives/research-graperain-g3568-v2-and-flash.html
Signed-off-by: Coia Prant <coiaprant@gmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../rockchip/rk3568-graperain-g3568-v2.dts | 894 ++++++++++++++++++
2 files changed, 895 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-graperain-g3568-v2.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 761d82b4f4f2a..6e9d049e8ddaf 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -144,6 +144,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-easepi-r1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r66s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r68s.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-graperain-g3568-v2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-hinlink-h66k.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-hinlink-h68k.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-lubancat-2.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-graperain-g3568-v2.dts b/arch/arm64/boot/dts/rockchip/rk3568-graperain-g3568-v2.dts
new file mode 100644
index 0000000000000..221992d6c6003
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-graperain-g3568-v2.dts
@@ -0,0 +1,894 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3568.dtsi"
+
+/ {
+ model = "Graperain G3568 v2";
+ compatible = "graperain,g3568-v2", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc0;
+ mmc2 = &sdmmc2;
+ rtc0 = &rtc0;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ button-esc {
+ label = "esc";
+ linux,code = <KEY_ESC>;
+ press-threshold-microvolt = <1250000>;
+ };
+
+ button-menu {
+ label = "menu";
+ linux,code = <KEY_MENU>;
+ press-threshold-microvolt = <1600000>;
+ };
+
+ button-vol-down {
+ label = "volume down";
+ linux,code = <KEY_VOLUMEDOWN>;
+ press-threshold-microvolt = <600000>;
+ };
+
+ button-vol-up {
+ label = "volume up";
+ linux,code = <KEY_VOLUMEUP>;
+ press-threshold-microvolt = <100000>;
+ };
+ };
+
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_work: led-0 {
+ gpios = <&gpio0 RK_PC0 GPIO_ACTIVE_HIGH>;
+ function = LED_FUNCTION_HEARTBEAT;
+ color = <LED_COLOR_ID_BLUE>;
+ linux,default-trigger = "heartbeat";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_work_en>;
+ };
+ };
+
+ rk809-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "Analog RK809";
+ simple-audio-card,mclk-fs = <256>;
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1_8ch>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&rk809>;
+ };
+ };
+
+ pdm_codec: pdm-codec {
+ compatible = "dmic-codec";
+ num-channels = <2>;
+ #sound-dai-cells = <0>;
+ };
+
+ pdm_sound: pdm-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "microphone";
+
+ simple-audio-card,cpu {
+ sound-dai = <&pdm>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&pdm_codec>;
+ };
+ };
+
+ spdif_dit: spdif-dit {
+ compatible = "linux,spdif-dit";
+ #sound-dai-cells = <0>;
+ };
+
+ spdif_sound: spdif-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "SPDIF";
+
+ simple-audio-card,cpu {
+ sound-dai = <&spdif>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&spdif_dit>;
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rk809 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable>;
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <300>;
+ reset-gpios = <&gpio3 RK_PD5 GPIO_ACTIVE_LOW>;
+ };
+
+ dc_12v: regulator-dc-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ };
+
+ pcie30_avdd0v9: regulator-pcie30-avdd0v9 {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie30_avdd0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ pcie30_avdd1v8: regulator-pcie30-avdd1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "pcie30_avdd1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc3v3_sys: regulator-vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcc3v3_pcie: regulator-vcc3v3-pcie {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PC3 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc3v3_pcie_en_pin>;
+ regulator-name = "vcc3v3_pcie";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <5000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcc5v0_usb: regulator-vcc5v0-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_usb";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcc5v0_usb_host: regulator-vcc5v0-usb-host {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_usb_host_en>;
+ regulator-name = "vcc5v0_usb_host";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v0_usb>;
+ };
+
+ vcc5v0_usb_otg: regulator-vcc5v0-usb-otg {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_usb_otg_en>;
+ regulator-name = "vcc5v0_usb_otg";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v0_usb>;
+ };
+};
+
+&can1 {
+ assigned-clocks = <&cru CLK_CAN1>;
+ assigned-clock-rates = <150000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&can1m1_pins>;
+ status = "okay";
+};
+
+/* used for usb_host0_xhci */
+&combphy0 {
+ status = "okay";
+};
+
+/* used for usb_host1_xhci */
+&combphy1 {
+ status = "okay";
+};
+
+/* connected to sata2 */
+&combphy2 {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&gmac0 {
+ assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>;
+ assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>;
+ assigned-clock-rates = <0>, <125000000>;
+ clock_in_out = "output";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac0_miim
+ &gmac0_tx_bus2
+ &gmac0_rx_bus2
+ &gmac0_rgmii_clk
+ &gmac0_rgmii_bus>;
+ phy-handle = <&rgmii_phy0>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+};
+
+&gmac1 {
+ assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
+ assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>;
+ assigned-clock-rates = <0>, <125000000>;
+ clock_in_out = "output";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac1m1_miim
+ &gmac1m1_tx_bus2
+ &gmac1m1_rx_bus2
+ &gmac1m1_rgmii_clk
+ &gmac1m1_rgmii_bus>;
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&hdmi {
+ avdd-0v9-supply = <&vdda0v9_image>;
+ avdd-1v8-supply = <&vcca1v8_image>;
+ status = "okay";
+};
+
+&hdmi_in {
+ hdmi_in_vp0: endpoint {
+ remote-endpoint = <&vp0_out_hdmi>;
+ };
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ vdd_cpu: regulator@1c {
+ compatible = "tcs,tcs4525";
+ reg = <0x1c>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
+ assigned-clocks = <&cru I2S1_MCLKOUT_TX>;
+ assigned-clock-parents = <&cru CLK_I2S1_8CH_TX>;
+ #clock-cells = <1>;
+ clock-names = "mclk";
+ clocks = <&cru I2S1_MCLKOUT_TX>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int>, <&i2s1m0_mclk>;
+ system-power-controller;
+ #sound-dai-cells = <0>;
+ vcc1-supply = <&vcc3v3_sys>;
+ vcc2-supply = <&vcc3v3_sys>;
+ vcc3-supply = <&vcc3v3_sys>;
+ vcc4-supply = <&vcc3v3_sys>;
+ vcc5-supply = <&vcc3v3_sys>;
+ vcc6-supply = <&vcc3v3_sys>;
+ vcc7-supply = <&vcc3v3_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc3v3_sys>;
+ wakeup-source;
+
+ regulators {
+ vdd_logic: DCDC_REG1 {
+ regulator-name = "vdd_logic";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: DCDC_REG2 {
+ regulator-name = "vdd_gpu";
+ regulator-always-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vdd_npu: DCDC_REG4 {
+ regulator-name = "vdd_npu";
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG5 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v9_image: LDO_REG1 {
+ regulator-name = "vdda0v9_image";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v9: LDO_REG2 {
+ regulator-name = "vdda_0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v9_pmu: LDO_REG3 {
+ regulator-name = "vdda0v9_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ vccio_acodec: LDO_REG4 {
+ regulator-name = "vccio_acodec";
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd: LDO_REG5 {
+ regulator-name = "vccio_sd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_pmu: LDO_REG6 {
+ regulator-name = "vcc3v3_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcca_1v8: LDO_REG7 {
+ regulator-name = "vcca_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pmu: LDO_REG8 {
+ regulator-name = "vcca1v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcca1v8_image: LDO_REG9 {
+ regulator-name = "vcca1v8_image";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v3: SWITCH_REG1 {
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_sd: SWITCH_REG2 {
+ regulator-name = "vcc3v3_sd";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+
+ codec {
+ rockchip,mic-in-differential;
+ };
+ };
+};
+
+&i2c5 {
+ status = "okay";
+
+ rtc0: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ };
+};
+
+&i2s0_8ch {
+ status = "okay";
+};
+
+&i2s1_8ch {
+ pinctrl-0 = <&i2s1m0_sclktx &i2s1m0_lrcktx &i2s1m0_sdi0 &i2s1m0_sdo0>;
+ rockchip,trcm-sync-tx-only;
+ status = "okay";
+};
+
+/* used for AP6356S Bluetooth Sound */
+&i2s3_2ch {
+ status = "okay";
+};
+
+&mdio0 {
+ rgmii_phy0: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_LOW>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+ };
+ };
+};
+
+&mdio1 {
+ rgmii_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_LOW>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ default-state = "keep";
+ };
+ };
+ };
+};
+
+&pcie30phy {
+ status = "okay";
+};
+
+&pcie3x2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_reset_pin>;
+ reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_pcie>;
+ status = "okay";
+};
+
+&pdm {
+ status = "okay";
+};
+
+&pinctrl {
+ leds {
+ led_work_en: led_work_en {
+ rockchip,pins = <0 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int: pmic_int {
+ rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ sdio-pwrseq {
+ wifi_enable: wifi-enable {
+ rockchip,pins = <3 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb {
+ vcc5v0_usb_host_en: vcc5v0_usb_host_en {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ vcc5v0_usb_otg_en: vcc5v0_usb_otg_en {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pcie {
+ pcie_reset_pin: pcie-reset-pin {
+ rockchip,pins = <2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ vcc3v3_pcie_en_pin: vcc3v3-pcie-en-pin {
+ rockchip,pins = <3 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pmu_io_domains {
+ pmuio1-supply = <&vcc3v3_pmu>;
+ pmuio2-supply = <&vcc3v3_pmu>;
+ vccio1-supply = <&vccio_acodec>;
+ vccio2-supply = <&vcc_1v8>;
+ vccio3-supply = <&vccio_sd>;
+ vccio4-supply = <&vcc_1v8>;
+ vccio5-supply = <&vcc_3v3>;
+ vccio6-supply = <&vcc_1v8>;
+ vccio7-supply = <&vcc_3v3>;
+ status = "okay";
+};
+
+&pwm4 {
+ status = "okay";
+};
+
+&pwm5 {
+ status = "okay";
+};
+
+/* Required remotectl for IR receiver */
+&pwm7 {
+ status = "disabled";
+};
+
+&saradc {
+ vref-supply = <&vcca_1v8>;
+ status = "okay";
+};
+
+&sata2 {
+ status = "okay";
+};
+
+/* used for eMMC */
+&sdhci {
+ bus-width = <8>;
+ max-frequency = <200000000>;
+ mmc-hs200-1_8v;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
+ status = "okay";
+};
+
+/* used for microSD (TF) Slot */
+&sdmmc0 {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vccio_sd>;
+ status = "okay";
+};
+
+/* used for AP6356S WiFi */
+&sdmmc2 {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc2m0_bus4 &sdmmc2m0_cmd &sdmmc2m0_clk>;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sys>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&spdif {
+ status = "okay";
+};
+
+&tsadc {
+ rockchip,hw-tshut-mode = <1>;
+ rockchip,hw-tshut-polarity = <0>;
+ status = "okay";
+};
+
+/* used for Debug */
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-0 = <&uart3m1_xfer>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-0 = <&uart4m1_xfer>;
+ status = "okay";
+};
+
+/* used for WiFi/BT AP6356S */
+&uart8 {
+ pinctrl-0 = <&uart8m0_xfer &uart8m0_ctsn>;
+ status = "okay";
+};
+
+&uart9 {
+ pinctrl-0 = <&uart9m1_xfer>;
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host0_xhci {
+ extcon = <&usb2phy0>;
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usb_host1_xhci {
+ status = "okay";
+};
+
+&usb2phy0 {
+ status = "okay";
+};
+
+&usb2phy0_host {
+ phy-supply = <&vcc5v0_usb_host>;
+ status = "okay";
+};
+
+&usb2phy0_otg {
+ phy-supply = <&vcc5v0_usb_otg>;
+ status = "okay";
+};
+
+&usb2phy1 {
+ status = "okay";
+};
+
+&usb2phy1_host {
+ phy-supply = <&vcc5v0_usb_host>;
+ status = "okay";
+};
+
+&usb2phy1_otg {
+ phy-supply = <&vcc5v0_usb_host>;
+ status = "okay";
+};
+
+&vop {
+ assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+ assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+ status = "okay";
+};
+
+&vop_mmu {
+ status = "okay";
+};
+
+&vp0 {
+ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+ reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+ remote-endpoint = <&hdmi_in_vp0>;
+ };
+};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Maxime Chevallier @ 2026-06-30 15:42 UTC (permalink / raw)
To: Nazle Asmade, Muhammad Nazim Amirul, Andrew Lunn
Cc: dinguyen@kernel.org, rmk+kernel@armlinux.org.uk,
krzk+dt@kernel.org, conor+dt@kernel.org, robh@kernel.org,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <b6c52ac8-32dc-4a58-83ec-ef600b306448@altera.com>
On 6/30/26 17:13, Nazle Asmade, Muhammad Nazim Amirul wrote:
> Yes, Agilex5 has the same concept. The GMII-to-RGMII converter is a
> Quartus soft IP instantiated in the FPGA fabric — equivalent to the
> CycloneV EMAC splitter. The XGMAC outputs GMII signals to the FPGA
> fabric, the soft IP converts them to RGMII, and the RGMII signals then
> go through the FPGA HVIO pins to the external Marvell 88E1512 PHY.
Does this converter need any special config, and does it expose any
control registers ? or is it fully autonomous ?
If it's fully autonomous, can you detect its presence through some
capability registers or something like that ?
Maxime
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix max receive size configuration
From: Paolo Abeni @ 2026-06-30 15:44 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In-Reply-To: <20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d@kernel.org>
On 6/25/26 8:49 AM, Lorenzo Bianconi wrote:
> Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally
> during hardware initialization instead of updating it according to the
> configured MTU. This avoids dropping incoming frames that exceed the
> current MTU but could still be processed by the networking stack, which
> is able to fragment the reply on the TX side (e.g. ICMP echo requests).
> Move the per-port MTU configuration to the PPE egress path where it
> belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size()
> to dynamically track the maximum MTU across running interfaces sharing
> the same PPE instance.
> Fix the PPE MTU register addressing to pack two port entries per
> register word and add WAN_MTU0 configuration for non-LAN GDM devices.
>
> Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
PW bot is on holiday, no automated notifications for a while.
Applied, thanks!
/P
^ permalink raw reply
* Re: [PATCH v2 0/4] ASoC: meson: aiu: align I2S design to the AXG one
From: Mark Brown @ 2026-06-30 11:27 UTC (permalink / raw)
To: Jerome Brunet, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Valerio Setti
Cc: linux-kernel, linux-sound, linux-arm-kernel, linux-amlogic
In-Reply-To: <20260610-reshape-aiu-as-axg-v2-0-cac3663a8b51@baylibre.com>
On Wed, 10 Jun 2026 23:29:24 +0200, Valerio Setti wrote:
> ASoC: meson: aiu: align I2S design to the AXG one
>
> The goal of this series is to reshape Amlogic GX's AIU implementation for
> I2S to let it follow the same design as in AXG's TDM. Keeping the same
> design allows for unifying the two platform implementations in the future
> and it also allows for an easy addition of I2S input.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.3
Thanks!
[1/4] ASoC: meson: gx: add gx-formatter and gx-interface
https://git.kernel.org/broonie/sound/c/a295be8d6210
[2/4] ASoC: meson: aiu-encoder-i2s: prepare for multiple streams
https://git.kernel.org/broonie/sound/c/9335117a221a
[3/4] ASoC: meson: aiu: introduce I2S output formatter
https://git.kernel.org/broonie/sound/c/2cbb32d8dce0
[4/4] ASoC: meson: aiu: use aiu-formatter-i2s to format I2S output data
https://git.kernel.org/broonie/sound/c/83b83024cdbf
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 1/4] spi: atcspi200: return error from failed controller suspend
From: Mark Brown @ 2026-06-30 11:38 UTC (permalink / raw)
To: Jiawen Liu
Cc: cl634, william.zhang, kursad.oney, jonas.gorski,
bcm-kernel-feedback-list, anand.gore, f.fainelli, rafal, olteanv,
han.xu, haibo.chen, yogeshgaur.83, linux-spi, linux-kernel,
linux-arm-kernel, imx
In-Reply-To: <tencent_306FA547FD68D10EE4B2AE9C132060F12F06@qq.com>
On Sat, 20 Jun 2026 12:39:28 +0400, Jiawen Liu wrote:
> spi: atcspi200: return error from failed controller suspend
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.3
Thanks!
[1/4] spi: atcspi200: return error from failed controller suspend
https://git.kernel.org/broonie/spi/c/f4b14e67baff
[2/4] spi: bcmbca-hsspi: return error from failed controller suspend
https://git.kernel.org/broonie/spi/c/faa878d4805c
[3/4] spi: fsl-dspi: clean up after failed suspend and resume
https://git.kernel.org/broonie/spi/c/2543355f3da5
[4/4] spi: nxp-fspi: disable runtime PM on probe failures
https://git.kernel.org/broonie/spi/c/5d14285d60ba
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH V4 0/7] PCI: imx6: Integrate pwrctrl API and update device trees
From: Frank Li @ 2026-06-30 15:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, s.hauer, kernel, festevam, lpieralisi,
kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach,
Sherry Sun (OSS)
Cc: Frank Li, imx, linux-pci, linux-arm-kernel, devicetree,
linux-kernel, sherry.sun
In-Reply-To: <178283343009.3269775.506226017892254973.b4-ty@b4>
On Tue, Jun 30, 2026 at 11:31:10AM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
>
> On Tue, 30 Jun 2026 14:07:03 +0800, Sherry Sun (OSS) wrote:
> > From: Sherry Sun <sherry.sun@nxp.com>
> >
> > This series integrates the PCI pwrctrl framework into the pci-imx6
> > driver and updates i.MX EVK board device trees to support it.
> >
> > Patches 2-8 update device trees for i.MX EVK boards which maintained
> > by NXP to move power supply properties from the PCIe controller node
> > to the Root Port child node, which is required for pwrctrl framework.
> > Affected boards:
> > - i.MX6Q/DL SABRESD
> > - i.MX6SX SDB
> > - i.MX8MM EVK
> > - i.MX8MP EVK
> > - i.MX8MQ EVK
> > - i.MX8DXL/QM/QXP EVK
> > - i.MX95 15x15/19x19 EVK
> >
> > [...]
>
> Applied, thanks!
>
> [1/7] arm: dts: imx6qdl-sabresd: Move power supply property to Root Port node
> commit: b16fded592305f04ae40764f5fa91d5ac6f02a65
> [2/7] arm: dts: imx6sx-sdb: Move power supply property to Root Port node
> commit: a1af6cf5a6ce526ea41d4686fa14580a48b2e768
> [3/7] arm64: dts: imx8mm-evk: Move power supply property to Root Port node
> commit: b6a38d70bcbf0893ce5493f3daf0cb19e5102269
> [4/7] arm64: dts: imx8mp-evk: Move power supply properties to Root Port node
> commit: fde093c386a64c820a704abaab9ffd9ec738cd4d
> [5/7] arm64: dts: imx8mq-evk: Move power supply properties to Root Port node
> commit: 78610987333b0811a456f9a4782472fad00f4a19
> [6/7] arm64: dts: imx8dxl/qm/qxp: Move power supply properties to Root Port node
> commit: 240950f3ad76761066ffe399f62670321c1be1f1
> [7/7] arm64: dts: imx95: Move power supply properties to Root Port node
> commit: 6e53e8b854bc6f8330d07905b73e53ad02aff62b
Sorry, I have to drop again because miss consider back compatible problem.
All old platform, 1 - 6, need keep both under pcie and root port.
iMX95, you can move under root becasue it is new platform, it should be
fine to break compatible since development phase.
Frank
>
> Best regards,
> --
> Frank Li <Frank.Li@nxp.com>
>
^ permalink raw reply
* Re: [PATCH v5 1/2] arm64: dts: imx94: Add Root Port node
From: Frank.Li @ 2026-06-30 16:00 UTC (permalink / raw)
To: sherry.sun, robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam,
hongxing.zhu
Cc: Frank Li, kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu
In-Reply-To: <20260630023006.3247578-1-hongxing.zhu@oss.nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Tue, 30 Jun 2026 10:30:05 +0800, hongxing.zhu@oss.nxp.com wrote:
> Since describing the PCIe PERST# property under Host Bridge node is now
> deprecated, it is recommended to add it to the Root Port node, so
> creating the Root Port node and pave the path to add the reset-gpios
> and so on properties in Root Port later.
Applied, thanks!
[1/2] arm64: dts: imx94: Add Root Port node
commit: c1a9a0e59055d22c8faa57f0cda444d8eafc1a4b
[2/2] arm64: dts: imx943-evk: Add Root Port node and according properties
commit: aba2fbe63163e82db8c82fa5c305dca58a89b4b0
Change commit message and add broke back compatible judgement.
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Geert Uytterhoeven @ 2026-06-30 16:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Linus Walleij, Bartosz Golaszewski,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, open list:GPIO SUBSYSTEM, dri-devel, linux-i2c,
linux-iio, linux-input, linux-mmc @ vger . kernel . org,
linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <ff4d7043-1929-4fa1-ba5e-f28403ad6fcc@app.fastmail.com>
Hi Arnd,
On Mon, 29 Jun 2026 at 19:54, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jun 29, 2026, at 17:29, Geert Uytterhoeven wrote:
> > On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
> >> From: Arnd Bergmann <arnd@arndb.de>
> >>
> >> Most remaining users of desc_to_gpio() only call it for printing debug
> >> information.
> >>
> >> Replace this with a new gpiod_name() helper that returns the
> >> gpio_desc->name string after checking the gpio_desc pointer.
> >>
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >> --- a/drivers/gpio/gpio-aggregator.c
> >> +++ b/drivers/gpio/gpio-aggregator.c
> >> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
> >>
> >> fwd->descs[offset] = desc;
> >>
> >> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
> >> - desc_to_gpio(desc), gpiod_to_irq(desc));
> >> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
> >> + gpiod_name(desc), gpiod_to_irq(desc));
> >>
> >> return 0;
> >> }
> >
> > Before, this printed:
> >
> > gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
> > gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
> >
> > After, this prints:
> >
> > gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
> > gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
> >
> > Same results for instantiation using sysfs or configfs[1], although
> > the latter does have optional support for specifying the name.
>
> I wonder how many of the other instances have the same problem
> then. Would it be appropriate for gpiochip_fwd_desc_add() to set
> a name itself to address this one?
I don't think it would be appropriate for the GPIO aggregator to set
that name. What we want to print here (for debugging) is the physical
GPIO that an aggregator's GPIO is mapped to, not some consumer or line
name (which is not guaranteed to be unique).
E.g. "<chip-name>.<offset>" would be fine. As gpiod_name() can only
return a fixed string or an existing string, it can't return such a
formatted string, though. And consumers don't have access to chip info?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 03/20] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
From: Jason Gunthorpe @ 2026-06-30 16:02 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley, Cheloha, Scott
In-Reply-To: <25155bd6-4348-4aa8-ba70-0a882fc84db9@amd.com>
On Thu, Jun 18, 2026 at 12:39:21PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 18/6/26 01:41, Jason Gunthorpe wrote:
> > On Wed, Jun 17, 2026 at 10:50:39AM +1000, Alexey Kardashevskiy wrote:
> > > > @@ -193,16 +193,31 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> > > > dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> > > > {
> > > > bool remap = false, set_uncached = false;
> > > > - bool mark_mem_decrypt = true;
> > > > + bool mark_mem_decrypt = false;
> > > > struct page *page;
> > > > void *ret;
> > > > + /*
> > > > + * DMA_ATTR_CC_SHARED is not a caller-visible dma_alloc_*()
> > > > + * attribute. The direct allocator uses it internally after it has
> > > > + * decided that the backing pages must be shared/decrypted, so the
> > > > + * rest of the allocation path can consistently select DMA addresses,
> > > > + * choose compatible pools and restore encryption on free.
> > >
> > > Why this limit?
> > >
> > > Context: I am looking for a memory pool for a few shared pages (to
> > > do some guest<->host communication), SWIOTLB seems like the right
> > > fit but swiotlb_alloc() is not exported and
> > > dma_direct_alloc(DMA_ATTR_CC_SHARED) is not allowed. Thanks,
> >
> > Then setup your struct device so that the DMA API knows the
> > guest<->host channel requires unecrypted and it will work correctly.
> >
> > I think this is a reasonable API to use for that, and I was just
> > advocating that hyperv should be using it too.
> >
> > But it all relies on a properly setup struct device.
>
> Sounds good but how do I do that in practice?
I think we haven't got there yet, I understood Dan's plan was to add a
bit in the struct device that signals if the device must be
unencrypted or can support all memory.
Currently the dma api assumes all devices must have unencrypted by
default so it should be fine already, shouldn't it?
> not externally available so I'll have to trick the DMA layer into
> using SWIOTLB (which is still all shared, right?) as I specifically
> want to skip page conversions. Setting low DMA mask won't guarantee
> that the DMA layer won't allocate a page outside of SWIOTLB and
> convert it. Manually do
Why so particular? Any address that satisifies the constraints should
be good enough?
Jason
^ permalink raw reply
* Re: [PATCH v2 05/13] KVM: arm64: Detect (via ACPI) and initialize HACDBSIRQ
From: Oliver Upton @ 2026-06-30 16:03 UTC (permalink / raw)
To: Leonardo Bras
Cc: Catalin Marinas, Will Deacon, Marc Zyngier, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki,
Len Brown, Saket Dumbre, Paolo Bonzini, Jonathan Cameron,
Chengwen Feng, Kees Cook, Mikołaj Lenczewski, James Morse,
Zeng Heng, mrigendrachaubey, Thomas Huth, Ryan Roberts,
Yeoreum Yun, Mark Brown, Kevin Brodsky, James Clark, Fuad Tabba,
Raghavendra Rao Ananta, Lorenzo Pieralisi, Sascha Bischoff,
Anshuman Khandual, Tian Zheng, linux-arm-kernel, linux-kernel,
kvmarm, linux-acpi, acpica-devel, kvm
In-Reply-To: <akPXqZQBKET1SyvN@LeoBrasDK>
On Tue, Jun 30, 2026 at 03:50:17PM +0100, Leonardo Bras wrote:
> On Mon, Jun 29, 2026 at 10:22:12AM -0700, Oliver Upton wrote:
> > If we need to initialize the IRQ I'd really like to see device tree
> > bindings for HACDBSIRQ as well. Pretty much any system us plebs can get
> > our hands on is gonna be DT anyway.
>
> Agree. I started out with ACPI because that's what the main target is, as
> dirty-logging is focused in Live Migration, which is usually more
> appreciated in the server space, which generally uses ACPI.
>
> I spoke to some people, and I could not hear of anyone releasing a product
> based in DT that would implement this yet, so I postponed the DT
> enablement.
Nested virt is always a good example. In some distant future KVM could
expose FEAT_HACDBS to the L1 hypervisor, and the VMM may be using DT
instead of ACPI (like kvmtool).
> >
> > > +static irqreturn_t hacdbsirq_handler(int irq, void *pcpu)
> > > +{
> > > + u64 cons = read_sysreg_s(SYS_HACDBSCONS_EL2);
> > > + unsigned long err = FIELD_GET(HACDBSCONS_EL2_ERR_REASON, cons);
> > > +
> > > + switch (err) {
> > > + case HACDBSCONS_EL2_ERR_REASON_NOF:
> > > + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> > > + break;
> > > + case HACDBSCONS_EL2_ERR_REASON_IPAHACF:
> > > + /* When size not a power of two >= 4k, exit with reserved TTLW */
> > > + int index = FIELD_GET(HACDBSCONS_EL2_INDEX, cons);
> > > +
> > > + if (index >= this_cpu_read(hacdbs_pcp.size)) {
> > > + this_cpu_write(hacdbs_pcp.status, HACDBS_IDLE);
> > > + break;
> > > + }
> > > + fallthrough;
> > > + case HACDBSCONS_EL2_ERR_REASON_STRUCTF:
> > > + case HACDBSCONS_EL2_ERR_REASON_IPAF:
> > > + this_cpu_write(hacdbs_pcp.status, HACDBS_ERROR);
> > > + break;
> > > + }
> > > +
> > > + return IRQ_HANDLED;
> > > +}
> >
> > I have a pretty extreme distaste for creating a state machine between
> > the callsite and the IRQ handler. The callsite should poll HACDBS for
> > completion. The thread has nothing better to do anyway.
>
> Well, there is one argument it could just wait and save some energy, but I
> agree it is not relevant in server space.
I wouldn't suggest polling in a tight loop :) I'd say use something like
__mdelay() to get the core into a low-power state w/o using a naked WFI.
In fact, that already uses WFxT under the hood.
> The main reason I did this is
> because I am planning on later doing an improved version of this that would
> clean the dirty-bit *while* running the guest, and having the IRQ is needed
> for exiting guest so we can notify userspace the cleaning is done. So I
> laid the HACDBSIRQ infra here so we don't have both polling and IRQ options
> happening.
>
> That idea would require us to add new API (a return value for 'cleaned'),
> and also a new flag for the clean ioctl. We also need the VMM to
> implement that, but then we get a proper cpu usage of cleaning time.
>
> I wanted to start with a backwards compatible version, and do the above
> idea once I put my hands in hardware that implements HACDBS, so I can
> properly measure how much performance we get on above strategy.
>
> What do you think?
Yeah, I'd want to see some extremely compelling performance numbers for
this approach before considering it, alongside the necessary VMM patches
to actually activate it.
Seems likely to me that the VMM will want the background thread back
ASAP that calls the clean ioctl so you'll need to work out how to cope
with idle vCPUs in that case.
Even still, with this hypothetical approach I'd expect KVM to inspect
the HACDBS state on every exit. The IRQ is just a convenient kick back
out to the main KVM_RUN loop.
Thanks,
Oliver
^ permalink raw reply
* Re: [Linux-stm32] [PATCH v6 10/16] arm64: dts: st: add sai1 pins for stm32mp25
From: Olivier MOYSAN @ 2026-06-30 16:09 UTC (permalink / raw)
To: Dario Binacchi, linux-kernel
Cc: Rob Herring, Conor Dooley, devicetree, francesco.utel,
domenico.acri, Maxime Coquelin, Krzysztof Kozlowski, michael,
linux-amarula, linux-stm32, linux-arm-kernel
In-Reply-To: <20260630092628.1695560-11-dario.binacchi@amarulasolutions.com>
Hi Dario,
On 6/30/26 11:24, Dario Binacchi wrote:
> Add the sai1 pins used on MicroGEA-STM32MP257-RMM board.
>
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
> ---
>
> (no changes since v1)
>
> arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi | 45 +++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
> index 695c9d771853..002fbc724b9d 100644
> --- a/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/st/stm32mp25-pinctrl.dtsi
> @@ -520,6 +520,51 @@ pins {
> };
> };
>
> + /omit-if-no-ref/
> + sai1a_pins_a: sai1a-0 {
> + pins1 {
> + pinmux = <STM32_PINMUX('D', 9, AF3)>, /* SAI1_SD_A */
> + <STM32_PINMUX('D', 8, AF3)>, /* SAI1_FS_A */
> + <STM32_PINMUX('D', 10, AF3)>; /* SAI1_SCK_A */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <1>;
> + };
> + pins2 {
> + pinmux = <STM32_PINMUX('D', 11, AF3)>; /* SAI1_MCLK_A */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <2>;
> + };
> + };
> +
> + /omit-if-no-ref/
> + sai1a_sleep_pins_a: sai1a-sleep-0 {
> + pins {
> + pinmux = <STM32_PINMUX('D', 9, ANALOG)>, /* SAI1_SD_A */
> + <STM32_PINMUX('D', 8, ANALOG)>, /* SAI1_FS_A */
> + <STM32_PINMUX('D', 10, ANALOG)>, /* SAI1_SCK_A */
> + <STM32_PINMUX('D', 11, ANALOG)>; /* SAI1_MCLK_A */
> + };
> + };
> +
> + /omit-if-no-ref/
> + sai1b_pins_a: sai1b-0 {
> + pins {
> + pinmux = <STM32_PINMUX('D', 4, AF4)>; /* SAI1_SD_B */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + };
> +
> + /omit-if-no-ref/
> + sai1b_sleep_pins_a: sai1b-sleep-0 {
> + pins {
> + pinmux = <STM32_PINMUX('D', 4, ANALOG)>; /* SAI1_SD_B */
> + };
> + };
> +
> /omit-if-no-ref/
> sdmmc1_b4_pins_a: sdmmc1-b4-0 {
> pins1 {
You can add Reviewed-by: Olivier Moysan <olivier.moysan@foss.st.com>
Thanks & Regards
Olivier
^ permalink raw reply
* Re: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Rob Herring @ 2026-06-30 16:13 UTC (permalink / raw)
To: Nas Chung
Cc: mchehab, hverkuil, krzk+dt, conor+dt, shawnguo, s.hauer,
linux-media, devicetree, linux-kernel, linux-imx,
linux-arm-kernel, jackson.lee, lafley.kim, marek.vasut
In-Reply-To: <20260624072043.238-3-nas.chung@chipsnmedia.com>
On Wed, Jun 24, 2026 at 04:20:36PM +0900, Nas Chung wrote:
> Add documentation for the Chips&Media Wave6 video codec on NXP i.MX SoCs.
>
> The hardware contains one control register region and four interface
> register regions for a shared video processing engine. The control region
> manages shared resources such as firmware memory, while each interface
> region has its own MMIO range and interrupt.
>
> The control region and each interface region are distinct DMA requesters
> and can be associated with separate IOMMU stream IDs. Represent the
> control region as the parent node and the interface register regions as
> child nodes to describe these resources.
>
> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> ---
> .../bindings/media/nxp,imx95-vpu.yaml | 163 ++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 170 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
> new file mode 100644
> index 000000000000..9a5ca53e15a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
> @@ -0,0 +1,163 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/nxp,imx95-vpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Chips&Media Wave6 Series multi-standard codec IP on NXP i.MX SoCs
> +
> +maintainers:
> + - Nas Chung <nas.chung@chipsnmedia.com>
> + - Jackson Lee <jackson.lee@chipsnmedia.com>
> +
> +description:
> + The Chips&Media Wave6 codec IP is a multi-standard video encoder/decoder.
> + On NXP i.MX SoCs, the Wave6 codec IP exposes one control register region and
> + four interface register regions for a shared video processing engine.
> + The parent node describes the control region, which has its own MMIO range and
> + manages shared resources such as firmware memory. The child nodes describe the
> + interface register regions. Each interface region has its own MMIO range and
> + interrupt.
> + The control region and the interface regions are distinct DMA requesters.
> + The control region and each interface region can be associated with separate
> + IOMMU stream IDs, allowing DMA isolation between them.
> +
> +properties:
> + compatible:
> + enum:
> + - nxp,imx95-vpu
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: VPU core clock
> + - description: VPU associated block clock
> +
> + clock-names:
> + items:
> + - const: core
> + - const: vpublk
> +
> + power-domains:
> + items:
> + - description: Main VPU power domain
> + - description: Performance power domain
> +
> + power-domain-names:
> + items:
> + - const: vpu
> + - const: perf
> +
> + memory-region:
> + maxItems: 1
> +
> + sram:
> + $ref: /schemas/types.yaml#/definitions/phandle
Already has a type. You just need to define how many phandles (maxItems: 1).
> + description:
> + phandle to the SRAM node used to store reference data, reducing DMA
> + memory bandwidth.
Drop 'phandle to the SRAM node'
Rob
^ permalink raw reply
* Re: [PATCH v6 00/20] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Jason Gunthorpe @ 2026-06-30 16:18 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Aneesh Kumar K.V, Catalin Marinas, iommu, linux-arm-kernel,
linux-kernel, linux-coco, Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <9f20ce61-1edd-411e-a7c3-be541fb89cb4@amd.com>
On Mon, Jun 22, 2026 at 10:58:23AM +1000, Alexey Kardashevskiy wrote:
> > I think it was a big mistake for the AMD SME stuff to overload the
> > decrypted/encrypted CC stuff which should mean shared/private in a
> > guest context to also mean things about physical memory encryption in
> > the host. It is really confusing.
>
> It is a bit in the PTE which says "encrypted", what do you mean by overloaded?...
Encrypted meaning I'm using DRAM encryption on the host and Encrypted
meaning this page is private and inaccessible to the hypervisor are
very different things with very different requirements and is
confusing they have been overloaded in Linux :(
> > The SME side is just a bad arch choice, the real world doesn't work
> > well if you set high address bits in your dma_addr_t. I think AMD
> > needs to use those restricted swiotlb pool where it allocates this
> > very special "SME Disabled" memory that will have a low
> > dma_addr_t.
>
> The generic __init iommu_subsys_init(void) calls
> iommu_set_default_translated() if CC_ATTR_MEM_ENCRYPT (==force the
> use of IOMMU) and eliminates the bouncing by default, pretty
> much.
Sure, I know, it is a gross solution to a self inflict error.
> We (AMD) do not really want to force Cbit in DMA handles and
> it is not happening unless "iommu=pt".
Lots of real HW won't work will because of this, so yeah you pretty
much have to. But also there is HW that is fine, like you can use a
mlx5 device and it will handle the C bit just fine.
It is pretty hacky to globally force the iommu mode because some
devices end up not working.
> > Then alloc and bouncing will get memory with a suitable
> > dma_addr_t. This has nothing to do with force_dma_unencrypted() which
> > is only a CC guest concept and nothing else in the OS should ever
> > touch decrypted memory.
>
> True.
>
> Although, with "iommu=pt" enabled, dma handles from swiotlb should
> not have Cbit so these swiotlb pages have to be unencrypted.
That is how it should ideall work, in this case the purpose of the
swiotlb pool is to provide low dma address memory because the device
cannot reach the normal linux dram addresses.
> As you mentioned in another mail in the thread, DMAing to
> unencrypted memory with mem_encrypt=on make no sense security
> wise.
Yes, pretty much.
> May be enforce either mem_encrypt=on or iommu=pt is allowed at
> the same time but not both? I am worried though that some weirdo
> still has a use case for it.
Arguably it should be done per device. The problem is the iommu layer
doesn't know what the dma mask is until the driver binds so it can't
detect a device that is unable to reach any dram and switch away from
identity automatically. That would be much cleaner.
> > > I am looking for a way to set up my "sev-guest" device such as when
> >
> > Whats a "sev-guest" device?
>
> It is a platform device, presented in SNP VMs as /dev/sev-guest and
> the guest userspace calls ioctls on it when it needs VM attestation
> report/certificates/etc.
>
> The sev-guest driver makes calls to the HV (GHCB protocol) to:
> 1) get report/certificates/measurements from the HV <- this is done
> via shared memory as the HV writes to it;
> 2) asks the HV to get the digests from the PSP <- this is done via
> encrypted memory (buuuut it is software encrypted and as far as the
> hw is concerned - it is shared - no Cbit, no RMP - these buffers
> contain plaintext headers of the PSP requests and cyphertext of the
> request/response body).
Ok, but here you have overloaded the word encrypted again :( Decrypted
memory containing ciphertext I think you mean
> > > dma_alloc_attrs(snp_dev->dev,...) happens, it allocates a page from
> > > the shared swiotlb pool (with no actual bouncing) and there is no
> > > obvious way to trick the DMA layer into doing that.
> >
> > Why do you need this?
>
> /dev/sev-guest uses only shared memory (from the HW standpoint), and
> it is normally lot less than 1MB. If hugepages are used, then today
> it allocates 4K pages (they come encrypted and likely backed with a
> 2M page), the driver converts them to shared to make that GHCB
> call. The conversion smashes backing 2M page to 4K pages (+RMP
> +IOPDE as there is possible ongoing DMA), which is a problem (I have
> mentioned it as "TMPM" before - a hw/fw helper to do the smashing).
Okay, but this has nothing to do with sev-guest at all, and should not
be solved uniquely for it.
The DMA API in general has a problem spraying allocations all over
system memory and fragmenting the RMP/GPT/etc and yes it needs a
solution, but it should be entirely in the DMA API and have no
special involvment with sev-guest. sev-guest should just make coherent
allocations and use them in the normal way.
> The idea here is that if swiotlb is already shared, the sev-guest
> could use that memory pool.
dma_alloc_coherent using the swiotlb pool instead of allocating and
converting in general is a reasonable proposal, IMHO. Again, nothing
to do with sev-guest.
Jason
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix max receive size configuration
From: Lorenzo Bianconi @ 2026-06-30 16:19 UTC (permalink / raw)
To: Paolo Abeni
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Simon Horman, linux-arm-kernel, linux-mediatek, netdev,
Madhur Agrawal
In-Reply-To: <94901706-e7f3-4ff7-9b19-9965f593e228@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Jun 30, Paolo Abeni wrote:
> On 6/25/26 8:49 AM, Lorenzo Bianconi wrote:
> > Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally
> > during hardware initialization instead of updating it according to the
> > configured MTU. This avoids dropping incoming frames that exceed the
> > current MTU but could still be processed by the networking stack, which
> > is able to fragment the reply on the TX side (e.g. ICMP echo requests).
> > Move the per-port MTU configuration to the PPE egress path where it
> > belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size()
> > to dynamically track the maximum MTU across running interfaces sharing
> > the same PPE instance.
> > Fix the PPE MTU register addressing to pack two port entries per
> > register word and add WAN_MTU0 configuration for non-LAN GDM devices.
> >
> > Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> > Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> PW bot is on holiday, no automated notifications for a while.
It's too hot even for the bot :)
Regards,
Lorenzo
>
> Applied, thanks!
>
> /P
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v5 0/2] media: nxp: imx8-isi: Add virtual channel and frame descriptor support
From: Frank Li @ 2026-06-30 16:20 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Guoniu Zhou, Frank Li, Aisheng Dong, linux-media,
imx, linux-arm-kernel, linux-kernel, Guoniu Zhou
In-Reply-To: <20260629202302.GK3054459@killaraus.ideasonboard.com>
On Mon, Jun 29, 2026 at 11:23:02PM +0300, Laurent Pinchart wrote:
> On Mon, Jun 29, 2026 at 03:42:31PM -0400, Frank.Li@oss.nxp.com wrote:
> > From: Frank Li <Frank.Li@nxp.com>
> >
> >
> > On Thu, 21 May 2026 17:10:03 +0800, Guoniu Zhou wrote:
> > > This patch series enhances the i.MX ISI driver's with virtual channel
> > > support and adds frame descriptor capabilities to the crossbar subdevice.
> >
> > Applied, thanks!
> >
> > [1/2] media: imx8-isi: crossbar: Add get_frame_desc operation
> > commit: 3e15a3510908c990ee352aa206d5f9c23d4b216e
>
> Is this a mistake ? Patch 1/2 has no R-b tag, and you're not listed as
> maintainer for this driver.
Sorry, I missed checking Maintainer files, in media summit, agree on I pick
imx's media drivers, but forget finalize the file\dir list. Can you help
summery which files\dir I should take care?
If you have concern about this patch, I can drop it.
Frank
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 1/4] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Manivannan Sadhasivam @ 2026-06-30 16:22 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Marc Zyngier, Rob Herring,
devicetree, linux-arm-kernel, linux-doc, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260618220427.14325-2-marek.vasut+renesas@mailbox.org>
On Fri, Jun 19, 2026 at 12:01:59AM +0200, Marek Vasut wrote:
> In case MSI are enabled, but DWC built-in iMSI-RX is not in use, the
> MSI are handled via GIC ITS. Configure all controller MSI registers
> fully.
>
> Set or clear MSI capability register MSICAP0 MSI enable MSIE bit and
> PCIe Interrupt Status 0 Enable register PCIEINTSTS0EN MSI interrupt
> enable MSI_CTRL_INT bit according to MSI enable state, set both bits
> if MSI are enabled, clear both bits if MSI are disabled.
>
> If MSI are disabled, or MSI are enabled and iMSI-RX is used, then
> deconfigure AXIINTCADDR and AXIINTCCONT to 0, which disables any
> pass through of MSI TLPs onto the AXI bus and then further into
> GIC ITS translation registers.
>
> If MSI are enabled and iMSI-RX is not used, the configure AXIINTCADDR
> with target address of GIC ITS translation registers, and configure
> AXIINTCCONT to enable MSI TLP pass through onto AXI bus and into the
> GIC ITS. This specific configuration allows handling of MSI via the
> GIC ITS instead of integrated iMSI-RX.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Same as patch 3, SoB chain is broken. Rest LGTM!
- Mani
> ---
> NOTE: This would not be possible without prior work from Shimoda-san
> ---
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Pull GITS_TRANSLATER address from DT, which also fixes missing +0x40
> offset of the GITS_TRANSLATER register
> ---
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 118 +++++++++++++++++++-
> 1 file changed, 113 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index 8b03c42f8c84c..6300ab4dc38b3 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> @@ -13,8 +13,11 @@
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/iopoll.h>
> +#include <linux/irqchip/arm-gic-v3.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> #include <linux/pci.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> @@ -31,6 +34,10 @@
> #define DEVICE_TYPE_RC BIT(4)
> #define BIFUR_MOD_SET_ON BIT(0)
>
> +/* MSI Capability */
> +#define MSICAP0 0x0050
> +#define MSICAP0_MSIE BIT(16)
> +
> /* PCIe Interrupt Status 0 */
> #define PCIEINTSTS0 0x0084
>
> @@ -55,6 +62,14 @@
> #define APP_HOLD_PHY_RST BIT(16)
> #define APP_LTSSM_ENABLE BIT(0)
>
> +/* INTC address */
> +#define AXIINTCADDR 0x0a00
> +
> +/* INTC control & mask */
> +#define AXIINTCCONT 0x0a04
> +#define INTC_EN BIT(31)
> +#define INTC_MASK GENMASK(11, 2)
> +
> /* PCIe Power Management Control */
> #define PCIEPWRMNGCTRL 0x0070
> #define APP_CLK_REQ_N BIT(11)
> @@ -305,13 +320,103 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
> return rcar;
> }
>
> +static int rcar_gen4_pcie_host_msi_addr(struct dw_pcie_rp *pp, u32 *msi_addr)
> +{
> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> + struct device_node *msi_node = NULL;
> + struct device *dev = dw->dev;
> + struct resource res;
> + u64 addr;
> + int ret;
> +
> + /*
> + * Either the "msi-parent" or the "msi-map" phandle needs to exist
> + * to obtain the MSI node.
> + */
> + of_msi_xlate(dev, &msi_node, 0);
> + if (!msi_node)
> + return -ENODEV;
> +
> + /* Check if "msi-parent" or the "msi-map" points to ARM GICv3 ITS. */
> + if (!of_device_is_compatible(msi_node, "arm,gic-v3-its"))
> + return dev_err_probe(dev, -ENODEV, "Compatible MSI controller not found\n");
> +
> + /* Derive GITS_TRANSLATER address from GICv3 */
> + ret = of_address_to_resource(msi_node, 0, &res);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "MSI controller resources not obtained\n");
> +
> + addr = res.start + GITS_TRANSLATER;
> + if (addr >= SZ_4G)
> + return dev_err_probe(dev, -EINVAL, "MSI controller address above 32bit range\n");
> +
> + *msi_addr = addr;
> + return 0;
> +}
> +
> +static int rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> + u32 val;
> + int ret;
> +
> + /* Make sure MSICAP0 MSIE is configured. */
> + val = dw_pcie_readl_dbi(dw, MSICAP0);
> + if (pci_msi_enabled())
> + val |= MSICAP0_MSIE;
> + else
> + val &= ~MSICAP0_MSIE;
> + dw_pcie_writel_dbi(dw, MSICAP0, val);
> +
> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
> + /* Clear AXIINTC mapping. */
> + writel(0, rcar->base + AXIINTCADDR);
> + writel(0, rcar->base + AXIINTCCONT);
> + } else {
> + ret = rcar_gen4_pcie_host_msi_addr(pp, &val);
> + if (ret)
> + goto err;
> +
> + /* Point AXIINTC to GIC ITS and enable. */
> + writel(val, rcar->base + AXIINTCADDR);
> + writel(INTC_EN | INTC_MASK, rcar->base + AXIINTCCONT);
> + }
> +
> + /* Configure MSI interrupt signal */
> + val = readl(rcar->base + PCIEINTSTS0EN);
> + if (pci_msi_enabled())
> + val |= MSI_CTRL_INT;
> + else
> + val &= ~MSI_CTRL_INT;
> + writel(val, rcar->base + PCIEINTSTS0EN);
> +
> + return 0;
> +
> +err:
> + /* Deconfigure MSICAP0 MSIE. */
> + val = dw_pcie_readl_dbi(dw, MSICAP0);
> + val &= ~MSICAP0_MSIE;
> + dw_pcie_writel_dbi(dw, MSICAP0, val);
> +
> + /* Clear AXIINTC mapping. */
> + writel(0, rcar->base + AXIINTCADDR);
> + writel(0, rcar->base + AXIINTCCONT);
> +
> + /* Deconfigure MSI interrupt signal */
> + val = readl(rcar->base + PCIEINTSTS0EN);
> + val &= ~MSI_CTRL_INT;
> + writel(val, rcar->base + PCIEINTSTS0EN);
> +
> + return ret;
> +}
> +
> /* Host mode */
> static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
> {
> struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> int ret;
> - u32 val;
>
> gpiod_set_value_cansleep(dw->pe_rst, 1);
>
> @@ -328,16 +433,19 @@ static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
> dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_0, 0x0);
> dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_1, 0x0);
>
> - /* Enable MSI interrupt signal */
> - val = readl(rcar->base + PCIEINTSTS0EN);
> - val |= MSI_CTRL_INT;
> - writel(val, rcar->base + PCIEINTSTS0EN);
> + ret = rcar_gen4_pcie_host_msi_init(pp);
> + if (ret)
> + goto err;
>
> msleep(PCIE_T_PVPERL_MS); /* pe_rst requires 100msec delay */
>
> gpiod_set_value_cansleep(dw->pe_rst, 0);
>
> return 0;
> +
> +err:
> + rcar_gen4_pcie_common_deinit(rcar);
> + return ret;
> }
>
> static void rcar_gen4_pcie_host_deinit(struct dw_pcie_rp *pp)
> --
> 2.53.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH 1/1] MAINTAINERS: media: nxp: imx8-isi: Add Frank Li as reviewer and i.MX mailing list
From: Frank.Li @ 2026-06-30 16:34 UTC (permalink / raw)
To: laurent.pinchart, mchehab, kernel, estevam, linux-media, imx,
linux-arm-kernel, linux-kernel
Cc: Frank Li
From: Frank Li <Frank.Li@nxp.com>
Add Frank Li as a reviewer and the i.MX mailing list for the i.MX8 ISI
driver. This helps ensure patches receive review by the NXP i.MX
maintainers.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 361a4f447277c..62ed60238b1cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19470,7 +19470,9 @@ F: drivers/iio/adc/vf610_adc.c
NXP i.MX 8M ISI DRIVER
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+R: Frank Li <Frank.Li@nxp.com>
L: linux-media@vger.kernel.org
+L: imx@lists.linux.dev
S: Maintained
F: Documentation/devicetree/bindings/media/fsl,imx8*-isi.yaml
F: Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] printk: nbcon: deprecate boot_delay in favour of printk_delay
From: Andrew Murray @ 2026-06-30 16:35 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Andrew Morton, Sebastian Andrzej Siewior, Clark Williams,
Randy Dunlap, Linus Torvalds, Greg Kroah-Hartman
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
linux-rt-devel, Andrew Murray
The boot_delay (BOOT_PRINTK_DELAY) kernel parameter and printk_delay
sysctl are two distinct mechanisms for providing similar functionality
which add a delay prior to each printed printk message.
boot_delay provides a kernel parameter for delaying printk output from
kernel start through to boot (SYSTEM_RUNNING), whereas printk_delay is
configurable only via sysctl and thus is only used post boot.
However, since the introduction of nbcon and the legacy printer thread
for PREEMPT_RT kernels, printk records are now emited to the console
asynchronously to the caller of printk. Thus, any printk delay added by
boot_delay/printk_delay continues to slow down the calling process but
may not have any impact to the rate in which records are emited to the
console, especially for slow consoles.
To address these issues, let's deprecate boot_delay, extend printk_delay
to be useable from kernel start and ensure that delays occur at the point
where console messages are printed rather than queued.
Please note that this patchset results in delays occuring after a message
is printed rather than, as it is now, before.
Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
---
Please see the following related work for additional context:
- https://lore.kernel.org/all/20260503214214.3475670-1-rdunlap@infradead.org/
- https://lore.kernel.org/all/20260505-printk_delay-v1-1-5dba51d7f17c@thegoodpenguin.co.uk/
- https://lore.kernel.org/r/20260601-deprecate_boot_delay-v1-0-c34c187142a6@thegoodpenguin.co.uk (v1)
---
Changes in v2:
- Rebased onto v7.2-rc1
- Correctly handle negative values for printk_delay_msec (patch 2)
- Add missing newline in pr_warn (patch 2)
- Improved patch descriptions for (patches 2 and 3)
- Use new emitted flag in nbcon_context/nbcon_write_context in place of backlog && wctxt.len checks (patch 3)
- Use unsigned char for unsafe_takeover field instead of bool in nbcon_write_context (patch 3)
- Move printk_delay_msec and printk_delay from printk.h to internal.h (patch 3)
- Revert regression added in v1 to __nbcon_atomic_flush_pending_con (patch 3)
- Move printk_delay later in console_emit_next_record ensuring delay is always after emit (across nbcon/legacy) (patch 3)
- Fixed typo in documentation s/boot_delay/printk_delay/g in printk_delay= section (patch 4)
- Link to v1: https://lore.kernel.org/r/20260601-deprecate_boot_delay-v1-0-c34c187142a6@thegoodpenguin.co.uk
---
Andrew Murray (4):
printk: remove BOOT_PRINTK_DELAY config option
printk: deprecate boot_delay in favour of printk_delay
printk: nbcon: move printk_delay to console emiting code
Documentation/kernel-parameters: add/update printk_delay/boot_delay
Documentation/admin-guide/kernel-parameters.txt | 31 +++++++--
arch/arm/configs/bcm2835_defconfig | 1 -
include/linux/console.h | 5 +-
include/linux/printk.h | 1 -
kernel/printk/internal.h | 6 ++
kernel/printk/nbcon.c | 13 ++++
kernel/printk/printk.c | 84 +++++++++++++++----------
lib/Kconfig.debug | 18 ------
8 files changed, 101 insertions(+), 58 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260515-deprecate_boot_delay-72516da3845a
Best regards,
--
Andrew Murray <amurray@thegoodpenguin.co.uk>
^ permalink raw reply
* [PATCH v2 1/4] printk: remove BOOT_PRINTK_DELAY config option
From: Andrew Murray @ 2026-06-30 16:35 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Petr Mladek, Steven Rostedt, John Ogness, Sergey Senozhatsky,
Andrew Morton, Sebastian Andrzej Siewior, Clark Williams,
Randy Dunlap, Linus Torvalds, Greg Kroah-Hartman
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-rpi-kernel,
linux-rt-devel, Andrew Murray
In-Reply-To: <20260630-deprecate_boot_delay-v2-0-f9883d36aa4b@thegoodpenguin.co.uk>
The boot_delay (BOOT_PRINTK_DELAY) kernel parameter and printk_delay sysctl
are two distinct mechanisms for providing similar functionality which add a
delay prior to each printed printk message.
In preparation of combining them into a single configurable feature, let's
first remove the kconfig option BOOT_PRINTK_DELAY.
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/arm/configs/bcm2835_defconfig | 1 -
kernel/printk/printk.c | 2 +-
lib/Kconfig.debug | 18 ------------------
4 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b5493a7f8f22812833308b22f2cc35b0a42e55b2..2884103b93bca7b76cd3a93946276074cf62d0a1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -651,7 +651,7 @@ Kernel parameters
boot_delay= [KNL,EARLY]
Milliseconds to delay each printk during boot.
- Only works if CONFIG_BOOT_PRINTK_DELAY is enabled,
+ Only works if GENERIC_CALIBRATE_DELAY is enabled,
and you may also have to specify "lpj=". Boot_delay
values larger than 10 seconds (10000) are assumed
erroneous and ignored.
diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 4a8ac09843d73280cc42dbbf63fe3cc9f31dacd2..51a1e94d5aa6c22202778082b877a202a6b9c04d 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -174,7 +174,6 @@ CONFIG_NLS_UTF8=y
CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=32
CONFIG_PRINTK_TIME=y
-CONFIG_BOOT_PRINTK_DELAY=y
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
# CONFIG_ENABLE_MUST_CHECK is not set
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 2fe9a963c823a41e7df10c29939a2abb55462859..77f53eaed13216c6c3946adabc0c8fdba6401d91 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1289,7 +1289,7 @@ static bool suppress_message_printing(int level)
return (level >= console_loglevel && !ignore_loglevel);
}
-#ifdef CONFIG_BOOT_PRINTK_DELAY
+#ifdef CONFIG_GENERIC_CALIBRATE_DELAY
static int boot_delay; /* msecs delay after each printk during bootup */
static unsigned long long loops_per_msec; /* based on boot_delay */
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 1244dcac2294ad99fda37fa6767c9e76f16a4d14..b552ea51cd53b79cf5d58b8c4deff409b1982862 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -99,24 +99,6 @@ config MESSAGE_LOGLEVEL_DEFAULT
by default. To change that, use loglevel=<x> in the kernel bootargs,
or pick a different CONSOLE_LOGLEVEL_DEFAULT configuration value.
-config BOOT_PRINTK_DELAY
- bool "Delay each boot printk message by N milliseconds"
- depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY
- help
- This build option allows you to read kernel boot messages
- by inserting a short delay after each one. The delay is
- specified in milliseconds on the kernel command line,
- using "boot_delay=N".
-
- It is likely that you would also need to use "lpj=M" to preset
- the "loops per jiffy" value.
- See a previous boot log for the "lpj" value to use for your
- system, and then set "lpj=M" before setting "boot_delay=N".
- NOTE: Using this option may adversely affect SMP systems.
- I.e., processors other than the first one may not boot up.
- BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect
- what it believes to be lockup conditions.
-
config DYNAMIC_DEBUG
bool "Enable dynamic printk() support"
default n
--
2.34.1
^ 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