* RE: [PATCH] tty: serial: samsung: add dedicated compatible for exynosauto SoCs
From: Alim Akhtar @ 2026-04-26 17:18 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', gregkh, jirislaby
Cc: linux-serial, linux-samsung-soc, linux-kernel
In-Reply-To: <6916bf87-4c40-42c5-988f-92a57a6fc658@kernel.org>
Hi Krzysztof
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Friday, April 24, 2026 9:42 PM
> To: Alim Akhtar <alim.akhtar@samsung.com>; gregkh@linuxfoundation.org;
> jirislaby@kernel.org
> Cc: linux-serial@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] tty: serial: samsung: add dedicated compatible for
> exynosauto SoCs
>
> On 24/04/2026 12:18, Alim Akhtar wrote:
> > Currently Exynosautov-{9,920} getting probed based on exynos850
> > fallback. It is recommended to have a dedicated compatible for proper
> > driver binding.
>
> Unfortunately it is not. Dedicated compatible you have. However you are not
> adding dedicated compatible. You added dedicated driver match entry and
> we, and especially me, gave reviews many times that it is *not
> recommended* to have dedicated driver match entry.
>
Ok, I might have missed your earlier comments on *not* having a dedicated driver match entry, fair enough.
> Entire reasoning for doing this patch is wrong. And patch itself is NOOP (at
> least by quick look).
Thanks for a quick review, Can you please check the part of the patch which adds OF_EARLYCON_DECLARE
to add earlycon support?
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v6 6/6] ARM: zte: defconfig: Add a zx29 defconfig file
From: Stefan Dösinger @ 2026-04-26 11:54 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This enables existing drivers for hardware that is present on this board
even if it is not present in the DT yet.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changes: v5 to v6: Regenerate the file with make savedefconfig.
An open question: What's the appropriate name? zx29_defconfig?
zte_defconfig? zte_zx29_defconfig? There's e.g. stm32_defconfig without
an extra mention of STMicro in the name.
---
MAINTAINERS | 1 +
arch/arm/configs/zx29_defconfig | 54 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6f51ba1c5ada..5dc52b84cc09 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3776,6 +3776,7 @@ ARM/ZTE ZX29 SOC SUPPORT
M: Stefan Dösinger <stefandoesinger@gmail.com>
F: Documentation/devicetree/bindings/arm/zte.yaml
F: arch/arm/boot/dts/zte/
+F: arch/arm/configs/zx29_defconfig
F: arch/arm/mach-zte/
ARM/ZYNQ ARCHITECTURE
diff --git a/arch/arm/configs/zx29_defconfig b/arch/arm/configs/zx29_defconfig
new file mode 100644
index 000000000000..54fa62ed56e7
--- /dev/null
+++ b/arch/arm/configs/zx29_defconfig
@@ -0,0 +1,54 @@
+CONFIG_SYSVIPC=y
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_EXPERT=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_ARCH_ZTE=y
+CONFIG_ARM_PSCI=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="console=ttyAMA0 earlyprintk root=/dev/ram rw"
+CONFIG_CPU_FREQ=y
+CONFIG_CPUFREQ_DT_PLATDEV=y
+# CONFIG_SUSPEND is not set
+CONFIG_PM=y
+CONFIG_BINFMT_FLAT=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_ALLOW_DEV_COREDUMP is not set
+CONFIG_MTD=y
+CONFIG_MTD_BLOCK=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_SRAM=y
+CONFIG_KEYBOARD_GPIO_POLLED=y
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_SERIAL_AMBA_PL011=y
+CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_DEV_BUS=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_PINCTRL=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_GENERIC_PLATFORM=y
+CONFIG_POWER_RESET=y
+CONFIG_MFD_SYSCON=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+# CONFIG_HID is not set
+CONFIG_USB_DWC2=y
+CONFIG_USB_GADGET=y
+CONFIG_MMC=y
+CONFIG_MMC_DW=y
+CONFIG_RESET_CONTROLLER=y
+CONFIG_RESET_SIMPLE=y
+CONFIG_JFFS2_FS=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
--
2.53.0
^ permalink raw reply related
* [PATCH v6 5/6] ARM: dts: zte: Add D-Link DWR-932M support
From: Stefan Dösinger @ 2026-04-26 11:54 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This adds base DT definition for zx297520v3 and one board that consumes it.
The stock kernel does not use the armv7 timer, but it seems to work
fine. The board has other board-specific timers that would need a driver
and I see no reason to bother with them since the arm standard timer
works.
The caveat is the non-standard GIC setup needed to handle the timer's
level-low PPI. This is the responsibility of the boot loader and
documented in Documentation/arch/arm/zte/zx297520v3.rst.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changes in
v6: Squash board + timer + uart patches into one
v5: Prepend the SoC name in the device specific DTS filename.
v4:
Declare all uarts
Remove the UART aliases for now. I can revisit this when I get my
hands on a board that exposes two UARTs.
---
MAINTAINERS | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/zte/Makefile | 3 +
arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts | 22 +++++
arch/arm/boot/dts/zte/zx297520v3.dtsi | 103 +++++++++++++++++++++
5 files changed, 130 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e707176c2114..6f51ba1c5ada 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3775,6 +3775,7 @@ F: drivers/video/fbdev/wmt_ge_rops.*
ARM/ZTE ZX29 SOC SUPPORT
M: Stefan Dösinger <stefandoesinger@gmail.com>
F: Documentation/devicetree/bindings/arm/zte.yaml
+F: arch/arm/boot/dts/zte/
F: arch/arm/mach-zte/
ARM/ZYNQ ARCHITECTURE
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index efe38eb25301..28fba538d552 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -39,3 +39,4 @@ subdir-y += unisoc
subdir-y += vt8500
subdir-y += xen
subdir-y += xilinx
+subdir-y += zte
diff --git a/arch/arm/boot/dts/zte/Makefile b/arch/arm/boot/dts/zte/Makefile
new file mode 100644
index 000000000000..f052cfbd636c
--- /dev/null
+++ b/arch/arm/boot/dts/zte/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+dtb-$(CONFIG_SOC_ZX297520V3) += \
+ zx297520v3-dlink-dwr932m.dtb
diff --git a/arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts b/arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts
new file mode 100644
index 000000000000..1700f46aba86
--- /dev/null
+++ b/arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Stefan Dösinger <stefandoesinger@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "zx297520v3.dtsi"
+
+/ {
+ model = "D-Link DWR-932M";
+ compatible = "dlink,dwr932m", "zte,zx297520v3";
+
+ memory@20000000 {
+ device_type = "memory";
+ reg = <0x20000000 0x04000000>;
+ };
+};
+
+&uart1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
new file mode 100644
index 000000000000..ca65797ed926
--- /dev/null
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2026 Stefan Dösinger <stefandoesinger@gmail.com>
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0>;
+ };
+ };
+
+ /* Base bus clock and default for the UART. It will be replaced once a clock driver has
+ * been added.
+ */
+ uartclk: uartclk: uartclk-26000000 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <26000000>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ clock-frequency = <26000000>;
+ interrupt-parent = <&gic>;
+ /* I don't think uboot sets CNTVOFF and the stock kernel doesn't use the
+ * arm timer at all. Since this is a single CPU system I don't think it
+ * really matters that the offset is random though.
+ */
+ arm,cpu-registers-not-fw-configured;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+ ranges;
+
+ /* The GIC has a non-standard way of configuring ints between level-low/level
+ * high or rising edge/falling edge at 0xf2202070 and onwards. See AP_INT_MODE_BASE
+ * and AP_PPI_MODE_REG in the ZTE kernel, although the offsets in the kernel source
+ * seem wrong.
+ *
+ * Everything defaults to active-high/rising edge, but the timer is active-low. We
+ * currently rely on the boot loader to change timer IRQs to active-low for us for
+ * now.
+ */
+ gic: interrupt-controller@f2000000 {
+ compatible = "arm,gic-v3";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xf2000000 0x10000>,
+ <0xf2040000 0x20000>;
+ };
+
+ uart0: serial@131000 {
+ compatible = "arm,primecell";
+ arm,primecell-periphid = <0x0018c011>;
+ reg = <0x00131000 0x1000>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&uartclk>;
+ clock-names = "uartclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart1: serial@1408000 {
+ compatible = "arm,pl011", "arm,primecell";
+ arm,primecell-periphid = <0x0018c011>;
+ reg = <0x01408000 0x1000>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&uartclk>;
+ clock-names = "uartclk", "apb_pclk";
+ status = "disabled";
+ };
+
+ uart2: serial@140d000 {
+ compatible = "arm,primecell";
+ arm,primecell-periphid = <0x0018c011>;
+ reg = <0x0140d000 0x1000>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&uartclk>, <&uartclk>;
+ clock-names = "uartclk", "apb_pclk";
+ status = "disabled";
+ };
+ };
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 4/6] amba/serial: amba-pl011: Bring back zx29 UART support
From: Stefan Dösinger @ 2026-04-26 11:54 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This is based on code removed in commit 89d4f98ae90d ("ARM: remove zte
zx platform"). I did not bring back the zx29-uart .compatible as the
arm,primecell-periphid does the job.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changes since v4:
Use ZTE's JEDEC ID instead of 0xfe for the DT-Provided AMBA ID.
---
drivers/tty/serial/amba-pl011.c | 42 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7f17d288c807..f24cc403d9e0 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -216,6 +216,38 @@ static struct vendor_data vendor_st = {
.get_fifosize = get_fifosize_st,
};
+static const u16 pl011_zte_offsets[REG_ARRAY_SIZE] = {
+ [REG_DR] = ZX_UART011_DR,
+ [REG_FR] = ZX_UART011_FR,
+ [REG_LCRH_RX] = ZX_UART011_LCRH,
+ [REG_LCRH_TX] = ZX_UART011_LCRH,
+ [REG_IBRD] = ZX_UART011_IBRD,
+ [REG_FBRD] = ZX_UART011_FBRD,
+ [REG_CR] = ZX_UART011_CR,
+ [REG_IFLS] = ZX_UART011_IFLS,
+ [REG_IMSC] = ZX_UART011_IMSC,
+ [REG_RIS] = ZX_UART011_RIS,
+ [REG_MIS] = ZX_UART011_MIS,
+ [REG_ICR] = ZX_UART011_ICR,
+ [REG_DMACR] = ZX_UART011_DMACR,
+};
+
+static unsigned int get_fifosize_zte(struct amba_device *dev)
+{
+ return 16;
+}
+
+static struct vendor_data vendor_zte = {
+ .reg_offset = pl011_zte_offsets,
+ .access_32b = true,
+ .ifls = UART011_IFLS_RX4_8 | UART011_IFLS_TX4_8,
+ .fr_busy = ZX_UART01x_FR_BUSY,
+ .fr_dsr = ZX_UART01x_FR_DSR,
+ .fr_cts = ZX_UART01x_FR_CTS,
+ .fr_ri = ZX_UART011_FR_RI,
+ .get_fifosize = get_fifosize_zte,
+};
+
/* Deals with DMA transactions */
struct pl011_dmabuf {
@@ -3081,6 +3113,16 @@ static const struct amba_id pl011_ids[] = {
.mask = 0x00ffffff,
.data = &vendor_st,
},
+ {
+ /* This is an invented ID. The actual hardware that contains
+ * these ZTE UARTs (zx29 boards) has no AMBA PIDs stored. ZTE
+ * JEDEC ID (ignoring banks) and the "011" part number as used
+ * by ARM.
+ */
+ .id = 0x0008c011,
+ .mask = 0x000fffff,
+ .data = &vendor_zte,
+ },
{ 0, 0 },
};
--
2.53.0
^ permalink raw reply related
* [PATCH v6 3/6] ARM: zte: Add support for zx29 low level debug
From: Stefan Dösinger @ 2026-04-26 11:54 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This is based on the removed zx29 code. A separate (more complicated)
patch will re-add the register map to the pl011 serial driver.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
I am unsure about the virtual address. It doesn't seem to matter, as
long as it is a valid address. This address is based on the old removed
code. Is there a rule-of-thumb physical to virtual mapping I can use to
give a sensible default value?
---
arch/arm/Kconfig.debug | 12 ++++++++++++
arch/arm/include/debug/pl01x.S | 7 +++++++
2 files changed, 19 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 366f162e147d..98d8a5a60048 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1331,6 +1331,16 @@ choice
This option selects UART0 on VIA/Wondermedia System-on-a-chip
devices, including VT8500, WM8505, WM8650 and WM8850.
+ config DEBUG_ZTE_ZX
+ bool "Kernel low-level debugging via zx29 UART"
+ select DEBUG_UART_PL01X
+ depends on ARCH_ZTE
+ help
+ Say Y here if you are enabling ZTE zx297520v3 SOC and need
+ debug UART support. This UART is a PL011 with different
+ register addresses. The UART for boot messages on zx29 boards
+ is usually UART1 and is operating at 921600 8N1.
+
config DEBUG_ZYNQ_UART0
bool "Kernel low-level debugging on Xilinx Zynq using UART0"
depends on ARCH_ZYNQ
@@ -1545,6 +1555,7 @@ config DEBUG_UART_8250
config DEBUG_UART_PHYS
hex "Physical base address of debug UART"
+ default 0x01408000 if DEBUG_ZTE_ZX
default 0x01c28000 if DEBUG_SUNXI_UART0
default 0x01c28400 if DEBUG_SUNXI_UART1
default 0x01d0c000 if DEBUG_DAVINCI_DA8XX_UART1
@@ -1701,6 +1712,7 @@ config DEBUG_UART_VIRT
default 0xf31004c0 if DEBUG_MESON_UARTAO
default 0xf4090000 if DEBUG_LPC32XX
default 0xf4200000 if DEBUG_GEMINI
+ default 0xf4708000 if DEBUG_ZTE_ZX
default 0xf6200000 if DEBUG_PXA_UART1
default 0xf7000000 if DEBUG_SUN9I_UART0
default 0xf7000000 if DEBUG_S3C64XX_UART && DEBUG_S3C_UART0
diff --git a/arch/arm/include/debug/pl01x.S b/arch/arm/include/debug/pl01x.S
index c7e02d0628bf..0c7bfa4c10db 100644
--- a/arch/arm/include/debug/pl01x.S
+++ b/arch/arm/include/debug/pl01x.S
@@ -8,6 +8,13 @@
*/
#include <linux/amba/serial.h>
+#ifdef CONFIG_DEBUG_ZTE_ZX
+#undef UART01x_DR
+#undef UART01x_FR
+#define UART01x_DR 0x04
+#define UART01x_FR 0x14
+#endif
+
#ifdef CONFIG_DEBUG_UART_PHYS
.macro addruart, rp, rv, tmp
ldr \rp, =CONFIG_DEBUG_UART_PHYS
--
2.53.0
^ permalink raw reply related
* [PATCH v6 2/6] ARM: zte: Add zx297520v3 platform support
From: Stefan Dösinger @ 2026-04-26 11:54 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
and sold by ISPs themselves. They are widespread in Africa, China,
Russia and Eastern Europe.
This SoC is a relative of the zx296702 and zx296718 that had some
upstream support until commit 89d4f98ae90d ("ARM: remove zte zx
platform"). My eventual goal is to enable OpenWRT to run on these
devices.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Documentation/arch/arm/zte/zx297520v3.rst | 158 ++++++++++++++++++++++++++++++
MAINTAINERS | 1 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/mach-zte/Kconfig | 26 +++++
arch/arm/mach-zte/Makefile | 2 +
arch/arm/mach-zte/zx297520v3.c | 19 ++++
7 files changed, 209 insertions(+)
diff --git a/Documentation/arch/arm/zte/zx297520v3.rst b/Documentation/arch/arm/zte/zx297520v3.rst
new file mode 100644
index 000000000000..6621ea72769f
--- /dev/null
+++ b/Documentation/arch/arm/zte/zx297520v3.rst
@@ -0,0 +1,158 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+====================================
+Booting Linux on ZTE zx297520v3 SoCs
+====================================
+
+...............................................................................
+
+Author: Stefan Dösinger
+
+Date : 27 Jan 2026
+
+1. Hardware description
+---------------------------
+Zx297520v3 SoCs use a 64 bit capable Cortex-A53 CPU and GICv3, although they
+run in arm32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
+it seems to lack VFP and NEON.
+
+The SoC is used in a number of cheap LTE to WiFi routers, both battery powered
+MiFis and stationary CPEs. In addition to the CPU these devices usually have
+64 MB Ram (although some is shared with the LTE chip), 128 MB NAND flash, an
+SDIO connected RTL8192-type Wifi chip limited to 2.4 ghz operation, USB 2,
+and buttons. Devices with as low as 32 MB or as high as 128 MB ram exist, as
+do devices with 8 or 16 MB of NOR flash.
+
+Some devices, especially the stationary ones, have 100 mbit Ethernet and an
+Ethernet switch.
+
+Usually the devices have LEDs for status indication, although some have SPI or
+I2C connected displays
+
+Some have an SD card slot. If it exists, it is a better choice for the root
+file system because it easily outperforms the built-in NAND.
+
+The LTE interface runs on a separate DSP called ZSP880. It is probably derived
+from LSI ZSPs and has an undocumented instruction set. The ZSP communicates
+with the main CPU via SRAM and DRAM and a mailbox hardware that can generate
+IRQs on either ends.
+
+There is also a Cortex M0 CPU, which is responsible for early HW initialization
+and starting the Cortex A53 CPU. It does not have any essential purpose once
+U-Boot is started. A SRAM-Based handover protocol exists to run custom code on
+this CPU.
+
+2. Booting via USB
+---------------------------
+
+The Boot ROM has support for booting custom code via USB. This mode can be
+entered by connecting a Boot PIN to GND or by modifying the third byte on NAND
+(set it to anything other than 0x5A aka 'Z'). A free software tool to start
+custom U-Boot and kernels can be found here:
+
+https://github.com/zx297520v3-mainline/zx297520v3-loader
+
+If USB download mode is entered but no boot commands are sent through USB, the
+device will proceed to boot normally after a few seconds. It is therefore
+possible to enable USB boot permanently and still leave the default boot files
+in place.
+
+3. Building for built-in U-Boot
+---------------------------
+The devices come with an ancient U-Boot that loads legacy uImages from NAND and
+boots them without a chance for the user to interrupt. The images are stored in
+files ap_cpuap.bin and ap_recovery.bin on a jffs2 partition named imagefs,
+usually mtd4. A file named "fotaflag" switches between the two modes.
+
+In addition to the uImage header, those files have a 384 byte signature header,
+which is used for authenticating the images on some devices. Most devices have
+this authentication disabled and it is enough to pad the uImage files with 384
+zero bytes.
+
+Builtin U-Boot also poorly sets up the CPU. Read the next section for details
+on this. It has no support for loading DTBs, so CONFIG_ARM_APPENDED_DTB is
+needed.
+
+So to build an image that boots from NAND the following steps are necessary:
+
+1) Patch the assembly code from section 3 into arch/arm/kernel/head.S.
+2) make zx29_defconfig
+3) make [-j x]
+4) cat arch/arm/boot/zImage arch/arm/boot/dts/zte/[device].dtb > kernel+dtb
+5) mkimage -A arm -O linux -T kernel -C none -a 0x20008000 -d kernel+dtb uimg
+6) dd if=/dev/zero bs=1 count=384 of=ap_recovery.bin
+7) cat uimg >> ap_recovery.bin
+8) Place this file onto imagefs on the device. Delete ap_cpuap.bin if the
+free space is not enough.
+9) Create the file fotaflag: echo -n FOTA-RECOVERY > fotaflag
+
+For development, booting ap_recovery.bin is recommended because the normal boot
+mode arms the watchdog before starting the kernel.
+
+4. CPU and GIC Setup
+---------------------------
+
+Generally CPU and GICv3 need to be set up according to the requirements spelled
+out in Documentation/arch/arm64/booting.rst. For zx297520v3 this means:
+
+1. GICD_CTLR.DS=1 to disable GIC security
+2. Enable access to ICC_SRE
+3. Disable trapping IRQs into monitor mode
+4. Configure EL2 and below to run in insecure mode.
+5. Configure timer PPIs to active-low.
+
+The kernel sources provided by ZTE do not boot either (interrupts do not work
+at all). They are incomplete in other aspects too, so it is assumed that there
+is some workaround similar to the one described in this document somewhere in
+the binary blobs.
+
+The assembly code below is given as an example of how to achieve this:
+
+```
+#include <linux/irqchip/arm-gic-v3.h>
+#include <asm/assembler.h>
+#include <asm/cp15.h>
+
+@ This allows EL1 to handle ints hat are normally handled by EL2/3.
+ldr r3, =0xf2000000
+ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
+str r4, [r3]
+
+cps #MON_MODE
+
+@ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
+@ seems to respond only to non-secure addresses. I have taken insipiration from
+@ Raspberry pi's armstub7.S here.
+@
+@ ARM docs say modify this bit in monitor mode only...
+mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
+ @ Allow hypervisor call.
+mcr p15, 0, r3, c1, c1, 0
+
+@ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
+ldr r3, =0xF22020a8
+ldr r4, =0x50
+str r4, [r3]
+ldr r3, =0xF22020ac
+ldr r4, =0x14
+str r4, [r3]
+
+@ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
+@ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
+mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
+orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
+mcr p15, 6, r3, c12, c12, 5
+mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
+orr r3, #(ICC_SRE_EL1_SRE)
+mcr p15, 0, r3, c12, c12, 5
+
+@ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
+@ for EL2.
+mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
+orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
+mcr p15, 4, r3, c12, c9, 5
+isb
+
+@ Back to SVC mode. TODO: Doesn't safe_svcmode_maskall do this for us anyway?
+cps #SVC_MODE
+```
diff --git a/MAINTAINERS b/MAINTAINERS
index b768b9da37a4..e707176c2114 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3775,6 +3775,7 @@ F: drivers/video/fbdev/wmt_ge_rops.*
ARM/ZTE ZX29 SOC SUPPORT
M: Stefan Dösinger <stefandoesinger@gmail.com>
F: Documentation/devicetree/bindings/arm/zte.yaml
+F: arch/arm/mach-zte/
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@amd.com>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ec33376f8e2b..4217ed704e48 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -464,6 +464,8 @@ source "arch/arm/mach-versatile/Kconfig"
source "arch/arm/mach-vt8500/Kconfig"
+source "arch/arm/mach-zte/Kconfig"
+
source "arch/arm/mach-zynq/Kconfig"
# ARMv7-M architecture
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index b7de4b6b284c..573813ef5e77 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -223,6 +223,7 @@ machine-$(CONFIG_ARCH_SUNXI) += sunxi
machine-$(CONFIG_ARCH_TEGRA) += tegra
machine-$(CONFIG_ARCH_U8500) += ux500
machine-$(CONFIG_ARCH_VT8500) += vt8500
+machine-$(CONFIG_ARCH_ZTE) += zte
machine-$(CONFIG_ARCH_ZYNQ) += zynq
machine-$(CONFIG_PLAT_VERSATILE) += versatile
machine-$(CONFIG_PLAT_SPEAR) += spear
diff --git a/arch/arm/mach-zte/Kconfig b/arch/arm/mach-zte/Kconfig
new file mode 100644
index 000000000000..2e3abee94994
--- /dev/null
+++ b/arch/arm/mach-zte/Kconfig
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: GPL-2.0-only
+menuconfig ARCH_ZTE
+ bool "ZTE zx family"
+ depends on ARCH_MULTI_V7
+ help
+ Support for ZTE zx-based family of processors.
+
+if ARCH_ZTE
+
+config SOC_ZX297520V3
+ default y if ARCH_ZTE
+ bool "zx297520v3"
+ select ARM_GIC_V3
+ select ARM_AMBA
+ select HAVE_ARM_ARCH_TIMER
+ select PM_GENERIC_DOMAINS if PM
+ help
+ Support for ZTE zx297520v3 SoC. It is a single core SoC used in cheap
+ LTE to WiFi routers. These devices can be identified by the occurrence
+ of the string "zx297520v3" in the boot output and /proc/cpuinfo of
+ their stock firmware.
+
+ Please read Documentation/arch/arm/zte/zx297520v3.rst on how to boot
+ the kernel.
+
+endif
diff --git a/arch/arm/mach-zte/Makefile b/arch/arm/mach-zte/Makefile
new file mode 100644
index 000000000000..1bfe4fddd6af
--- /dev/null
+++ b/arch/arm/mach-zte/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_SOC_ZX297520V3) += zx297520v3.o
diff --git a/arch/arm/mach-zte/zx297520v3.c b/arch/arm/mach-zte/zx297520v3.c
new file mode 100644
index 000000000000..c11c7e836f91
--- /dev/null
+++ b/arch/arm/mach-zte/zx297520v3.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2026 Stefan Dösinger
+ */
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+
+static const char *const zx297520v3_dt_compat[] __initconst = {
+ "zte,zx297520v3",
+ NULL,
+};
+
+DT_MACHINE_START(ZX, "ZTE zx297520v3 (Device Tree)")
+ .dt_compat = zx297520v3_dt_compat,
+MACHINE_END
--
2.53.0
^ permalink raw reply related
* [PATCH v6 1/6] dt-bindings: arm: zte: Add D-Link DWR932M board based on zx297520v3 SoC
From: Stefan Dösinger @ 2026-04-26 11:54 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260426-send-v6-0-d49efa72bb09@gmail.com>
This adds a new binding file for ZTE, containing their zx297520v3 SoC
and one board (D-Link DWR-932M) based on it.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changelog:
v6:
Removed extra boards, I'll add them when submitting their individual
DTS files. Rephrase the subject to add "zte" and remove the redundant
use of "binding".
Moved the devicetree bindings patch ahead of the implementation patches.
Moved the MAINTAINERS section from "ZX29" to "ARM/ZTE".
---
Documentation/devicetree/bindings/arm/zte.yaml | 26 ++++++++++++++++++++++++++
MAINTAINERS | 4 ++++
2 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/zte.yaml b/Documentation/devicetree/bindings/arm/zte.yaml
new file mode 100644
index 000000000000..f028d2cec7ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/zte.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/zte.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ZTE zx platforms
+
+maintainers:
+ - Stefan Dösinger <stefandoesinger@gmail.com>
+
+description: |
+ ARM platforms using SoCs designed by ZTE. Currently this supports devices
+ based on the zx297520v3 SoC which is found in LTE routers.
+
+properties:
+ $nodename:
+ const: "/"
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - dlink,dwr932m
+ - const: zte,zx297520v3
+
+additionalProperties: true
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..b768b9da37a4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3772,6 +3772,10 @@ F: drivers/video/fbdev/vt8500lcdfb.*
F: drivers/video/fbdev/wm8505fb*
F: drivers/video/fbdev/wmt_ge_rops.*
+ARM/ZTE ZX29 SOC SUPPORT
+M: Stefan Dösinger <stefandoesinger@gmail.com>
+F: Documentation/devicetree/bindings/arm/zte.yaml
+
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@amd.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
2.53.0
^ permalink raw reply related
* [PATCH v6 0/6] Add support for ZTE zx297520v3
From: Stefan Dösinger @ 2026-04-26 11:54 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
Hi,
This is a follow-up on my RFC patches from January [0] for ZTE's
zx297520v3 chipset. This chipset is popular in cheap LTE-to-wifi routers
sold in developing countries. My goal is to run OpenWRT on them. I made
more progress in more work on this SoC and it is time to get serious
about code review and upstreaming.
Since my version in January I managed to get more hardware running: SPI,
I2C, PMIC with real time clock and voltage regulators, Watchdog. LTE is
not working yet, but I am able to start the coprocessor that handles it
and talk to it via mailbox + shared memory. Wifi is working on a few
more devices. Since WiFi, USB and Ethernet are working, the devices can
have actual use with OpenWRT even without LTE.
Another hacker created a free software program to talk to the USB loader
[1] and boot U-Boot and Linux without modifying the on disk files. At
the moment it needs a proprietary blob, so my documentation is
emphasising booting with the on-device U-Boot.
This patchset here is mostly unmodified from the version I sent in
January. It is the bare minimum to get an interactive shell working on
the UART. Future patches can be found on my git repository [2] for those
curious to peek ahead. The first 30 patches are in reasonable shape, but
the further you go the more cleanup is necessary. I expect all of the
patches go require a few rounds of feedback though.
My plan for upstreaming is largly this:
1) This bare minimum boot patchset
2) Add clock and pinctrl drivers
3) Add standard hardware to the device tree
4) Add zx29 specific drivers one by one: Watchdog, spi, i2c, DMA, PMIC,
battery
5) SDIO backend for rtl8xxxu
6) rproc, mailbox and rpmsg
I am willing to maintain support for the SoC within reason. My patches
add myself as maintainer. This is a hobby project for me though, keep
that in mind if you want to ship a commercial product with these SoCs
and upstreaming Linux.
Cheers,
Stefan
0: https://lists.infradead.org/pipermail/linux-arm-kernel/2026-January/1099306.html
1: https://github.com/zx297520v3-mainline/zx297520v3-loader
2: https://gitlab.com/stefandoesinger/zx297520-kernel/
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Patch changelog:
Changes in v6:
Squashed DT commits into one
Removed for-now unused board DT bindings
Add "zte" to DT patch subject
Regenerate the defconfig with make savedefconfig
- Link to v5: https://lore.kernel.org/r/20260421-send-v5-0-ace038e63515@gmail.com
v5:
Spelling fixes
Renamed dlink-dwr-932m.dts to zx297520v3-dlink-dwr932m.dts
DT binding indentation fixes
Use a manufacturer 0x8b for the UART, fix patch prefix
Declare all UARTs, remove uart aliases for now
Consistent license declarations. I made every new file except the DT
binding GPL-2.0-only but I don't particularly mind GPL-2.0-or-later
either.
- Link to v4: https://lore.kernel.org/r/20260416-send-v4-0-e19d02b944ec@gmail.com
v4: rename zx29.yaml to zte.yaml and add board enums
v3: Remove [RFC] tag, add defconfig
v2: checkpatch.pl fixes
---
Stefan Dösinger (6):
dt-bindings: arm: zte: Add D-Link DWR932M board based on zx297520v3 SoC
ARM: zte: Add zx297520v3 platform support
ARM: zte: Add support for zx29 low level debug
amba/serial: amba-pl011: Bring back zx29 UART support
ARM: dts: zte: Add D-Link DWR-932M support
ARM: zte: defconfig: Add a zx29 defconfig file
Documentation/arch/arm/zte/zx297520v3.rst | 158 +++++++++++++++++++++
Documentation/devicetree/bindings/arm/zte.yaml | 26 ++++
MAINTAINERS | 7 +
arch/arm/Kconfig | 2 +
arch/arm/Kconfig.debug | 12 ++
arch/arm/Makefile | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/zte/Makefile | 3 +
arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts | 22 +++
arch/arm/boot/dts/zte/zx297520v3.dtsi | 103 ++++++++++++++
arch/arm/configs/zx29_defconfig | 54 +++++++
arch/arm/include/debug/pl01x.S | 7 +
arch/arm/mach-zte/Kconfig | 26 ++++
arch/arm/mach-zte/Makefile | 2 +
arch/arm/mach-zte/zx297520v3.c | 19 +++
drivers/tty/serial/amba-pl011.c | 42 ++++++
16 files changed, 485 insertions(+)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260416-send-5c08e095e5c9
Best regards,
--
Stefan Dösinger <stefandoesinger@gmail.com>
^ permalink raw reply
* [PATCH] serial: 8250_dw: Clean up register macros and error handling
From: Artem Shimko @ 2026-04-24 21:05 UTC (permalink / raw)
To: sashal, miquel.raynal, phil.edworthy, Ilpo Järvinen,
Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby
Cc: Artem Shimko, linux-kernel, linux-serial
Align register offset definitions for DW_UART_USR, DW_UART_DMASA,
OCTEON_UART_USR, RZN1_UART_TDMACR and RZN1_UART_RDMACR to improve
readability. Replace raw shift with FIELD_PREP() and GENMASK() for
RZN1_UART_xDMACR burst field definitions — this documents that the
field occupies bits [2:1] and prevents accidental overflow when new
burst values are added.
Simplify ENXIO handling in dw8250_probe(): instead of explicitly
zeroing 'err' and then checking it, use a single conditional that
allows -ENXIO (no interrupt, fall back to polling) while treating
any other error as fatal. No functional change intended.
Signed-off-by: Artem Shimko <a.shimko.dev@gmail.com>
---
Hi,
This small cleanup patch addresses a few minor style and robustness
issues I noticed while working with the driver.
Thank you.
--
Regards,
Artem
drivers/tty/serial/8250/8250_dw.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index 94beadb4024d..3e7b79154d9d 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -35,13 +35,13 @@
#include "8250_dwlib.h"
/* Offsets for the DesignWare specific registers */
-#define DW_UART_USR 0x1f /* UART Status Register */
-#define DW_UART_DMASA 0xa8 /* DMA Software Ack */
+#define DW_UART_USR 0x1f /* UART Status Register */
+#define DW_UART_DMASA 0xa8 /* DMA Software Ack */
-#define OCTEON_UART_USR 0x27 /* UART Status Register */
+#define OCTEON_UART_USR 0x27 /* UART Status Register */
-#define RZN1_UART_TDMACR 0x10c /* DMA Control Register Transmit Mode */
-#define RZN1_UART_RDMACR 0x110 /* DMA Control Register Receive Mode */
+#define RZN1_UART_TDMACR 0x10c /* DMA Control Register Transmit Mode */
+#define RZN1_UART_RDMACR 0x110 /* DMA Control Register Receive Mode */
/* DesignWare specific register fields */
#define DW_UART_IIR_IID GENMASK(3, 0)
@@ -52,9 +52,10 @@
/* Renesas specific register fields */
#define RZN1_UART_xDMACR_DMA_EN BIT(0)
-#define RZN1_UART_xDMACR_1_WORD_BURST (0 << 1)
-#define RZN1_UART_xDMACR_4_WORD_BURST (1 << 1)
-#define RZN1_UART_xDMACR_8_WORD_BURST (2 << 1)
+#define RZN1_UART_xDMACR_BURST_MASK GENMASK(2, 1)
+#define RZN1_UART_xDMACR_1_WORD_BURST FIELD_PREP(RZN1_UART_xDMACR_BURST_MASK, 0)
+#define RZN1_UART_xDMACR_4_WORD_BURST FIELD_PREP(RZN1_UART_xDMACR_BURST_MASK, 1)
+#define RZN1_UART_xDMACR_8_WORD_BURST FIELD_PREP(RZN1_UART_xDMACR_BURST_MASK, 2)
#define RZN1_UART_xDMACR_BLK_SZ(x) ((x) << 3)
/* Quirks */
@@ -729,9 +730,7 @@ static int dw8250_probe(struct platform_device *pdev)
err = uart_read_port_properties(p);
/* no interrupt -> fall back to polling */
- if (err == -ENXIO)
- err = 0;
- if (err)
+ if (err && err != -ENXIO)
return err;
switch (p->iotype) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] tty: serial: samsung: add dedicated compatible for exynosauto SoCs
From: Krzysztof Kozlowski @ 2026-04-24 16:12 UTC (permalink / raw)
To: Alim Akhtar, gregkh, jirislaby
Cc: linux-serial, linux-samsung-soc, linux-kernel
In-Reply-To: <20260424101835.2125970-1-alim.akhtar@samsung.com>
On 24/04/2026 12:18, Alim Akhtar wrote:
> Currently Exynosautov-{9,920} getting probed based on exynos850
> fallback. It is recommended to have a dedicated compatible for
> proper driver binding.
Unfortunately it is not. Dedicated compatible you have. However you are
not adding dedicated compatible. You added dedicated driver match entry
and we, and especially me, gave reviews many times that it is *not
recommended* to have dedicated driver match entry.
Entire reasoning for doing this patch is wrong. And patch itself is NOOP
(at least by quick look).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/9] serial: core: use uart_iotype_*() to simplify code
From: Hugo Villeneuve @ 2026-04-24 15:30 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <716918cf-b240-43cc-a702-9b3d94dc75d2@linux.intel.com>
On Fri, 24 Apr 2026 14:13:02 +0300 (EEST)
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> On Thu, 23 Apr 2026, Hugo Villeneuve wrote:
>
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Make use of new functions uart_iotype_mmio() and uart_iotype_legacy_io()
> > to simplify and improve code readability.
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > ---
> > drivers/tty/serial/serial_core.c | 24 +++++++++---------------
> > 1 file changed, 9 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> > index b1cf45a8fc854cd97e349ff077d83b42e3ef8b16..fc273f8f9e75de89dca1ac1aca3589567bcf8a18 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -3221,23 +3221,17 @@ bool uart_match_port(const struct uart_port *port1,
> > {
> > if (port1->iotype != port2->iotype)
> > return false;
> > -
> > - switch (port1->iotype) {
> > - case UPIO_PORT:
> > - return port1->iobase == port2->iobase;
> > - case UPIO_HUB6:
> > - return port1->iobase == port2->iobase &&
> > - port1->hub6 == port2->hub6;
> > - case UPIO_MEM:
> > - case UPIO_MEM16:
> > - case UPIO_MEM32:
> > - case UPIO_MEM32BE:
> > - case UPIO_AU:
> > - case UPIO_TSI:
> > + else if (uart_iotype_mmio(port1->iotype))
> > return port1->mapbase == port2->mapbase;
> > - default:
> > + else if (uart_iotype_legacy_io(port1->iotype))
> > + if (port1->iobase != port2->iobase)
> > + return false;
> > + else if (port1->iotype == UPIO_HUB6 && port1->hub6 != port2->hub6)
>
> I suggest placing the entire hub6 related check (including the iobase
> check) into own function in 8250_hub6.c and add a stub for the case when
> hub6 code is not even built into kernel into 8250.h.
Neat. I will make a separate commit for that in V2. This
simplifies uart_match_port() even more...
Thank you,
Hugo.
>
> > + return false;
> > + else
> > + return true;
> > + else
> > return false;
> > - }
> > }
> > EXPORT_SYMBOL(uart_match_port);
> >
> >
> >
>
> --
> i.
>
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v4 2/4] serial: 8250_dw: build Renesas RZN1 CPR value from DW_UART_CPR_* definitions
From: Andy Shevchenko @ 2026-04-24 15:16 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Jia Wang, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <363a636d-f014-cc29-6be4-ec3041f43855@linux.intel.com>
On Fri, Apr 24, 2026 at 05:09:46PM +0300, Ilpo Järvinen wrote:
> On Fri, 24 Apr 2026, Andy Shevchenko wrote:
> > On Fri, Apr 24, 2026 at 02:38:56PM +0300, Ilpo Järvinen wrote:
> > > On Fri, 24 Apr 2026, Jia Wang wrote:
...
> > > Hmm, maybe there should also be macro also for this one which takes the
> > > fifosize as input and converts it to CPR field vlaue (effectively, the
> > > macro is an inverse of DW_UART_CPR_FIFO_SIZE()). It would be more readable
> > > than the literal.
> >
> > But this can be done separately, right?
>
> It's logically part of the cpr_value literal to defines conversion (of
> course one could introduce it in own patch without users but I don't see
> much benefit from that).
No objections.
> > > Also include BUILD_BUG_ON(!IS_ALIGNED(fifosize, 16) + bounds checks)
> > > inside that macro to catch invalid fifo sizes (+ don't forget the
> > > necessary headers for those two new things).
> >
> > Hmm... Some devices may have FIFO = 8 or 4 bytes (Intel Quark IIRC has less
> > than 16 and it's DW IP).
>
> Perhaps but according the DW databook I've at hand, there are no values in
> FIFO_MODE field for such FIFO sizes. So what would CPR contain in those
> cases for FIFO_MODE field?
On real HW it returns 0s for all registers above 0x07 (multiplied by 4 as
a stride). But I also checked the values of xmit_fifo_size and it shows 16.
What 8 is it is the DMA max_burst. Hence the proposed assertion should work.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 6/9] serial: core: prevent irrelevant I/O infos display for UPIO_BUS
From: Hugo Villeneuve @ 2026-04-24 14:24 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <96429741-16d0-3e4b-b42f-d273a2adfba7@linux.intel.com>
On Fri, 24 Apr 2026 13:51:52 +0300 (EEST)
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> On Thu, 23 Apr 2026, Hugo Villeneuve wrote:
>
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > It doesn't make sense to display irrelevant MMIO or legacy I/O information
> > for serial devices on I2C or SPI busses. Now that we have a separate I/O
> > type for these types of devices, prevent display of I/O information for
> > them. Using uart_iotype_*() functions to do so also addresses the now
> > invalid check for "iotype >= UPIO_MEM".
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > ---
> > drivers/tty/serial/serial_core.c | 50 ++++++++++++++++++----------------------
> > 1 file changed, 22 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> > index 0bfdb69817e4259681fbc4658c9a68200aa2b65f..42559eda6fc134de77c3a7b850d565ebdc89e216 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -2011,13 +2011,18 @@ static void uart_line_info(struct seq_file *m, struct uart_state *state)
> > if (!uport)
> > return;
> >
> > - mmio = uport->iotype >= UPIO_MEM;
> > - seq_printf(m, "%u: uart:%s %s%08llX irq:%u",
> > - uport->line, uart_type(uport),
> > - mmio ? "mmio:0x" : "port:",
> > - mmio ? (unsigned long long)uport->mapbase
> > - : (unsigned long long)uport->iobase,
> > - uport->irq);
> > + seq_printf(m, "%u: uart:%s", uport->line, uart_type(uport));
> > +
> > + mmio = uart_iotype_mmio(uport->iotype);
> > +
> > + if (mmio || uart_iotype_legacy_io(uport->iotype)) {
> > + seq_printf(m, " %s%08llX",
> > + mmio ? "mmio:0x" : "port:",
> > + mmio ? (unsigned long long)uport->mapbase
> > + : (unsigned long long)uport->iobase);
>
> This should align to ?
Ok, my auto-indent is not working for that.
Will change it to:
seq_printf(m, " %s%08llX", mmio ? "mmio:0x" : "port:",
mmio ? (unsigned long long)uport->mapbase
: (unsigned long long)uport->iobase);
>
> > + }
> > +
> > + seq_printf(m, "irq:%u", uport->irq);
> >
> > if (uport->type == PORT_UNKNOWN) {
> > seq_putc(m, '\n');
> > @@ -2482,31 +2487,20 @@ EXPORT_SYMBOL(uart_resume_port);
> > static inline void
> > uart_report_port(struct uart_driver *drv, struct uart_port *port)
> > {
> > - char address[64];
> > + char address[64] = "";
> >
> > - switch (port->iotype) {
> > - case UPIO_PORT:
> > - snprintf(address, sizeof(address), "I/O 0x%lx", port->iobase);
> > - break;
> > - case UPIO_HUB6:
> > + if (uart_iotype_mmio(port->iotype))
> > snprintf(address, sizeof(address),
> > - "I/O 0x%lx offset 0x%x", port->iobase, port->hub6);
> > - break;
> > - case UPIO_MEM:
> > - case UPIO_MEM16:
> > - case UPIO_MEM32:
> > - case UPIO_MEM32BE:
> > - case UPIO_AU:
> > - case UPIO_TSI:
> > - snprintf(address, sizeof(address),
> > - "MMIO 0x%llx", (unsigned long long)port->mapbase);
> > - break;
> > - default:
> > - strscpy(address, "*unknown*", sizeof(address));
> > - break;
> > + " at MMIO 0x%llx", (unsigned long long)port->mapbase);
> > + else if (uart_iotype_legacy_io(port->iotype)) {
> > + if (port->iotype == UPIO_PORT)
> > + snprintf(address, sizeof(address), " at I/O 0x%lx", port->iobase);
> > + else if (port->iotype == UPIO_HUB6)
> > + snprintf(address, sizeof(address),
> > + " at I/O 0x%lx offset 0x%x", port->iobase, port->hub6);
>
> Please use scnprintf() so we could perhaps one day get rid of snprintf()
> entirely.
Ok will do.
>
> > }
> >
> > - pr_info("%s%s%s at %s (irq = %u, base_baud = %u) is a %s\n",
> > + pr_info("%s%s%s%s (irq = %u, base_baud = %u) is a %s\n",
> > port->dev ? dev_name(port->dev) : "",
> > port->dev ? ": " : "",
> > port->name,
> >
> >
>
> --
> i.
>
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v4 2/4] serial: 8250_dw: build Renesas RZN1 CPR value from DW_UART_CPR_* definitions
From: Ilpo Järvinen @ 2026-04-24 14:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jia Wang, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <aetv2ljDOpH_Hs4s@ashevche-desk.local>
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]
On Fri, 24 Apr 2026, Andy Shevchenko wrote:
> On Fri, Apr 24, 2026 at 02:38:56PM +0300, Ilpo Järvinen wrote:
> > On Fri, 24 Apr 2026, Jia Wang wrote:
>
> ...
>
> > Hmm, maybe there should also be macro also for this one which takes the
> > fifosize as input and converts it to CPR field vlaue (effectively, the
> > macro is an inverse of DW_UART_CPR_FIFO_SIZE()). It would be more readable
> > than the literal.
>
> But this can be done separately, right?
It's logically part of the cpr_value literal to defines conversion (of
course one could introduce it in own patch without users but I don't see
much benefit from that).
> > Also include BUILD_BUG_ON(!IS_ALIGNED(fifosize, 16) + bounds checks)
> > inside that macro to catch invalid fifo sizes (+ don't forget the
> > necessary headers for those two new things).
>
> Hmm... Some devices may have FIFO = 8 or 4 bytes (Intel Quark IIRC has less
> than 16 and it's DW IP).
Perhaps but according the DW databook I've at hand, there are no values in
FIFO_MODE field for such FIFO sizes. So what would CPR contain in those
cases for FIFO_MODE field?
--
i.
^ permalink raw reply
* Re: [PATCH v4 2/4] serial: 8250_dw: build Renesas RZN1 CPR value from DW_UART_CPR_* definitions
From: Andy Shevchenko @ 2026-04-24 13:27 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Jia Wang, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <4548483c-cbba-899e-6b1a-1290d36b59cd@linux.intel.com>
On Fri, Apr 24, 2026 at 02:38:56PM +0300, Ilpo Järvinen wrote:
> On Fri, 24 Apr 2026, Jia Wang wrote:
...
> Hmm, maybe there should also be macro also for this one which takes the
> fifosize as input and converts it to CPR field vlaue (effectively, the
> macro is an inverse of DW_UART_CPR_FIFO_SIZE()). It would be more readable
> than the literal.
But this can be done separately, right?
> Also include BUILD_BUG_ON(!IS_ALIGNED(fifosize, 16) + bounds checks)
> inside that macro to catch invalid fifo sizes (+ don't forget the
> necessary headers for those two new things).
Hmm... Some devices may have FIFO = 8 or 4 bytes (Intel Quark IIRC has less
than 16 and it's DW IP).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] dt-bindings: serial: Add compatible for Qualcomm Nord SoC
From: Shawn Guo @ 2026-04-24 12:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Praveen Talari, Konrad Dybcio, Dmitry Baryshkov,
Bartosz Golaszewski, Deepti Jaggi, linux-serial, devicetree,
linux-arm-msm, linux-kernel
In-Reply-To: <20260421-spotted-fiery-crab-4defd7@quoll>
On Tue, Apr 21, 2026 at 12:34:33PM +0200, Krzysztof Kozlowski wrote:
> On Mon, Apr 20, 2026 at 02:05:24PM +0800, Shawn Guo wrote:
> > From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> >
> > Document compatibles for QUP GENI UART controller on Nord SoC with
> > fallback on SA8255P compatibles.
> >
> > Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> > Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> > ---
> > .../bindings/serial/qcom,sa8255p-geni-uart.yaml | 13 ++++++++++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Thank you, Krzysztof!
As explained to Rob [1], I would like to send a new version by using
'sa8797p' instead of 'nord-auto' in the compatible strings. I intend
to keep your review tag, but please let me know if you want to withdraw
the tag.
Shawn
[1] https://lore.kernel.org/all/aeowYpvA6MegAX6w@QCOM-aGQu4IUr3Y/
^ permalink raw reply
* Re: [PATCH v4 2/4] serial: 8250_dw: build Renesas RZN1 CPR value from DW_UART_CPR_* definitions
From: Ilpo Järvinen @ 2026-04-24 11:38 UTC (permalink / raw)
To: Jia Wang
Cc: Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <20260424-ultrarisc-serial-v4-2-1765a0b4c4a0@ultrarisc.com>
On Fri, 24 Apr 2026, Jia Wang wrote:
> Replace the magic CPR value for Renesas RZ/N1 with a composition using
> DW_UART_CPR_* bit/field definitions and FIELD_PREP_CONST().
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> ---
> drivers/tty/serial/8250/8250_dw.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> index 467755bf0092..d3c2c9c84d9f 100644
> --- a/drivers/tty/serial/8250/8250_dw.c
> +++ b/drivers/tty/serial/8250/8250_dw.c
> @@ -937,7 +937,15 @@ static const struct dw8250_platform_data dw8250_armada_38x_data = {
>
> static const struct dw8250_platform_data dw8250_renesas_rzn1_data = {
> .usr_reg = DW_UART_USR,
> - .cpr_value = 0x00012f32,
> + .cpr_value = FIELD_PREP_CONST(DW_UART_CPR_ABP_DATA_WIDTH, 2) |
> + DW_UART_CPR_AFCE_MODE |
> + DW_UART_CPR_THRE_MODE |
> + DW_UART_CPR_ADDITIONAL_FEATURES |
> + DW_UART_CPR_FIFO_ACCESS |
> + DW_UART_CPR_FIFO_STAT |
> + DW_UART_CPR_SHADOW |
> + DW_UART_CPR_DMA_EXTRA |
> + FIELD_PREP_CONST(DW_UART_CPR_FIFO_MODE, 0x01),
Hmm, maybe there should also be macro also for this one which takes the
fifosize as input and converts it to CPR field vlaue (effectively, the
macro is an inverse of DW_UART_CPR_FIFO_SIZE()). It would be more readable
than the literal.
Also include BUILD_BUG_ON(!IS_ALIGNED(fifosize, 16) + bounds checks)
inside that macro to catch invalid fifo sizes (+ don't forget the
necessary headers for those two new things).
--
i.
^ permalink raw reply
* Re: [PATCH 0/9] serial: add new I/O type for SPI and I2C bus devices
From: Ilpo Järvinen @ 2026-04-24 11:24 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <20260423-tty-upio-v1-0-baf82d3b86d1@dimonoff.com>
[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]
On Thu, 23 Apr 2026, Hugo Villeneuve wrote:
> Hello,
> this patch series add a new I/O type for serial devices on a SPI/I2C bus.
>
> These changes are based on a suggestion [1] made by Ilpo Järvinen during
> past sc16is7xx driver patches review.
Hehe, I didn't even recall suggesting this (nor why) :-).
I like this series. Some, relatively minor, comments on the individual
patches. Thanks for looking into solving this properly.
--
i.
> I decided to use UPIO_BUS/SERIAL_IO_BUS names but maybe other names would
> be more appropriate:
> UPIO_SBUS / SERIAL_IO_SBUS
> UPIO_SERBUS / SERIAL_IO_SERBUS
> UPIO_EXT / SERIAL_IO_EXT
> UPIO_CUSTOM / SERIAL_IO_CUSTOM
> UPIO_REGMAP / SERIAL_IO_REGMAP /* Maybe not always true in future? */
> ...
>
> Tested on a imx6 board with two SC16is752 using SPI mode, and a dummy
> device-tree entry for a MAX3100:
> dmesg -t | grep "base_baud"
> 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 197, base_baud = 5000000) is a IMX
> 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 198, base_baud = 5000000) is a IMX
> spi1.0: ttySC0 (irq = 165, base_baud = 1500000) is a SC16IS752
> spi1.0: ttySC1 (irq = 165, base_baud = 1500000) is a SC16IS752
> spi3.0: ttySC2 (irq = 37, base_baud = 1500000) is a SC16IS752
> spi3.0: ttySC3 (irq = 37, base_baud = 1500000) is a SC16IS752
> spi3.1: ttyMAX0 (irq = 0, base_baud = 0) is a MAX3100
> Note that before these patches, max3100 silently failed in uart_configure_port()
> because membase/iobase/mapbase were zero.
>
> For max310x and SC16is7xx in i2c mode, tested only that driver is properly
> registered by using i2c-stub.
>
> Also tested on a custom board with a Renesas RZ/G2L cpu (sh-sci driver) to
> confirm there is no regression:
> dmesg -t | grep "base_baud"
> 1004b800.serial: ttySC0 at MMIO 0x1004b800 (irq = 35, base_baud = 0) is a scif
> 1004bc00.serial: ttySC1 at MMIO 0x1004bc00 (irq = 40, base_baud = 0) is a scif
>
> Maybe some of the patches could be merged together, but for now I decided
> to keep them separate to help the review process.
>
> Thank you.
>
> [1] https://lore.kernel.org/lkml/2936e18f-44ea-faed-9fa0-2ddefe7c3194@linux.intel.com/raw
>
> ---
> Hugo Villeneuve (9):
> serial: core: add uart_iotype_mmio/legacy_io helper functions
> serial: core: use uart_iotype_*() to simplify code
> serial: 8250: use uart_iotype_*() to simplify code
> serial: core: fix indentation/alignment
> serial: core: add new I/O type for SPI and I2C bus devices
> serial: core: prevent irrelevant I/O infos display for UPIO_BUS
> serial: sc16is7xx: use new UPIO_BUS as iotype
> serial: max310x: use new UPIO_BUS as iotype
> serial: max3100: use new UPIO_BUS as iotype
>
> drivers/tty/serial/8250/8250_port.c | 33 ++--------
> drivers/tty/serial/max3100.c | 1 +
> drivers/tty/serial/max310x.c | 9 +--
> drivers/tty/serial/sc16is7xx.c | 9 +--
> drivers/tty/serial/serial_core.c | 121 ++++++++++++++++++++----------------
> include/linux/serial_core.h | 5 ++
> include/uapi/linux/serial.h | 1 +
> 7 files changed, 83 insertions(+), 96 deletions(-)
> ---
> base-commit: 2e68039281932e6dc37718a1ea7cbb8e2cda42e6
> change-id: 20260423-tty-upio-c8b66a0a593e
>
> Best regards,
>
^ permalink raw reply
* Re: [PATCH v5 1/8] ARM: zte: Add zx297520v3 platform support
From: Stefan Dösinger @ 2026-04-24 11:23 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <CAD++jL=am0f+sgBSFYQCdcFOvFWgPETn_pSgVdzETJ3_yUNqgw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
> Am 24.04.2026 um 10:06 schrieb Linus Walleij <linusw@kernel.org>:
>
> On Tue, Apr 21, 2026 at 10:24 PM Stefan Dösinger
> <stefandoesinger@gmail.com> wrote:
>
>> This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
>> DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
>> and sold by ISPs themselves. They are widespread in Africa, China,
>> Russia and Eastern Europe.
>>
>> This SoC is a relative of the zx296702 and zx296718 that had some
>> upstream support until commit 89d4f98ae90d ("ARM: remove zte zx
>> platform"). My eventual goal is to enable OpenWRT to run on these
>> devices.
>>
>> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> Didn't I review this already? I don't remember, anyway:
> Reviewed-by: Linus Walleij <linusw@kernel.org>
Yes, you did, but the previous version, and after I sent this one.
And if I understand the b4 docs correctly, the Reviewed-by tags are sort of handled client side: I have to tell b4 to fetch trailers, and then it will add it when I send my v6 with Krzysztof's request to squash patches.
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/9] serial: core: use uart_iotype_*() to simplify code
From: Ilpo Järvinen @ 2026-04-24 11:13 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <20260423-tty-upio-v1-2-baf82d3b86d1@dimonoff.com>
On Thu, 23 Apr 2026, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Make use of new functions uart_iotype_mmio() and uart_iotype_legacy_io()
> to simplify and improve code readability.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> drivers/tty/serial/serial_core.c | 24 +++++++++---------------
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index b1cf45a8fc854cd97e349ff077d83b42e3ef8b16..fc273f8f9e75de89dca1ac1aca3589567bcf8a18 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3221,23 +3221,17 @@ bool uart_match_port(const struct uart_port *port1,
> {
> if (port1->iotype != port2->iotype)
> return false;
> -
> - switch (port1->iotype) {
> - case UPIO_PORT:
> - return port1->iobase == port2->iobase;
> - case UPIO_HUB6:
> - return port1->iobase == port2->iobase &&
> - port1->hub6 == port2->hub6;
> - case UPIO_MEM:
> - case UPIO_MEM16:
> - case UPIO_MEM32:
> - case UPIO_MEM32BE:
> - case UPIO_AU:
> - case UPIO_TSI:
> + else if (uart_iotype_mmio(port1->iotype))
> return port1->mapbase == port2->mapbase;
> - default:
> + else if (uart_iotype_legacy_io(port1->iotype))
> + if (port1->iobase != port2->iobase)
> + return false;
> + else if (port1->iotype == UPIO_HUB6 && port1->hub6 != port2->hub6)
I suggest placing the entire hub6 related check (including the iobase
check) into own function in 8250_hub6.c and add a stub for the case when
hub6 code is not even built into kernel into 8250.h.
> + return false;
> + else
> + return true;
> + else
> return false;
> - }
> }
> EXPORT_SYMBOL(uart_match_port);
>
>
>
--
i.
^ permalink raw reply
* Re: [PATCH 6/9] serial: core: prevent irrelevant I/O infos display for UPIO_BUS
From: Ilpo Järvinen @ 2026-04-24 10:51 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, LKML, linux-serial,
Hugo Villeneuve
In-Reply-To: <20260423-tty-upio-v1-6-baf82d3b86d1@dimonoff.com>
On Thu, 23 Apr 2026, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> It doesn't make sense to display irrelevant MMIO or legacy I/O information
> for serial devices on I2C or SPI busses. Now that we have a separate I/O
> type for these types of devices, prevent display of I/O information for
> them. Using uart_iotype_*() functions to do so also addresses the now
> invalid check for "iotype >= UPIO_MEM".
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> drivers/tty/serial/serial_core.c | 50 ++++++++++++++++++----------------------
> 1 file changed, 22 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 0bfdb69817e4259681fbc4658c9a68200aa2b65f..42559eda6fc134de77c3a7b850d565ebdc89e216 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -2011,13 +2011,18 @@ static void uart_line_info(struct seq_file *m, struct uart_state *state)
> if (!uport)
> return;
>
> - mmio = uport->iotype >= UPIO_MEM;
> - seq_printf(m, "%u: uart:%s %s%08llX irq:%u",
> - uport->line, uart_type(uport),
> - mmio ? "mmio:0x" : "port:",
> - mmio ? (unsigned long long)uport->mapbase
> - : (unsigned long long)uport->iobase,
> - uport->irq);
> + seq_printf(m, "%u: uart:%s", uport->line, uart_type(uport));
> +
> + mmio = uart_iotype_mmio(uport->iotype);
> +
> + if (mmio || uart_iotype_legacy_io(uport->iotype)) {
> + seq_printf(m, " %s%08llX",
> + mmio ? "mmio:0x" : "port:",
> + mmio ? (unsigned long long)uport->mapbase
> + : (unsigned long long)uport->iobase);
This should align to ?
> + }
> +
> + seq_printf(m, "irq:%u", uport->irq);
>
> if (uport->type == PORT_UNKNOWN) {
> seq_putc(m, '\n');
> @@ -2482,31 +2487,20 @@ EXPORT_SYMBOL(uart_resume_port);
> static inline void
> uart_report_port(struct uart_driver *drv, struct uart_port *port)
> {
> - char address[64];
> + char address[64] = "";
>
> - switch (port->iotype) {
> - case UPIO_PORT:
> - snprintf(address, sizeof(address), "I/O 0x%lx", port->iobase);
> - break;
> - case UPIO_HUB6:
> + if (uart_iotype_mmio(port->iotype))
> snprintf(address, sizeof(address),
> - "I/O 0x%lx offset 0x%x", port->iobase, port->hub6);
> - break;
> - case UPIO_MEM:
> - case UPIO_MEM16:
> - case UPIO_MEM32:
> - case UPIO_MEM32BE:
> - case UPIO_AU:
> - case UPIO_TSI:
> - snprintf(address, sizeof(address),
> - "MMIO 0x%llx", (unsigned long long)port->mapbase);
> - break;
> - default:
> - strscpy(address, "*unknown*", sizeof(address));
> - break;
> + " at MMIO 0x%llx", (unsigned long long)port->mapbase);
> + else if (uart_iotype_legacy_io(port->iotype)) {
> + if (port->iotype == UPIO_PORT)
> + snprintf(address, sizeof(address), " at I/O 0x%lx", port->iobase);
> + else if (port->iotype == UPIO_HUB6)
> + snprintf(address, sizeof(address),
> + " at I/O 0x%lx offset 0x%x", port->iobase, port->hub6);
Please use scnprintf() so we could perhaps one day get rid of snprintf()
entirely.
> }
>
> - pr_info("%s%s%s at %s (irq = %u, base_baud = %u) is a %s\n",
> + pr_info("%s%s%s%s (irq = %u, base_baud = %u) is a %s\n",
> port->dev ? dev_name(port->dev) : "",
> port->dev ? ": " : "",
> port->name,
>
>
--
i.
^ permalink raw reply
* Re: [PATCH v4 1/4] serial: 8250_dwlib: move DesignWare register definitions to header
From: Andy Shevchenko @ 2026-04-24 10:02 UTC (permalink / raw)
To: Jia Wang
Cc: Ilpo Järvinen, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-serial,
linux-riscv, devicetree
In-Reply-To: <20260424-ultrarisc-serial-v4-1-1765a0b4c4a0@ultrarisc.com>
On Fri, Apr 24, 2026 at 01:39:28PM +0800, Jia Wang wrote:
> Move the DW_UART_* register offsets and CPR bit/field definitions from
> 8250_dwlib.c into 8250_dwlib.h so they can be shared by 8250_dw and
> 8250_dwlib users.
>
> Add an include guard for 8250_dwlib.h.
...
> -/* DesignWare specific register fields */
> -#define DW_UART_IIR_IID GENMASK(3, 0)
> -
> -#define DW_UART_MCR_SIRE BIT(6)
> -
> -#define DW_UART_USR_BUSY BIT(0)
> -
One nit-pick, though, these three need the similar comments in the header and a
blank line between them.
...
> +/* Offsets for the DesignWare specific registers */
> +#define DW_UART_USR 0x1f /* UART Status Register */
> +#define DW_UART_DMASA 0xa8 /* DMA Software Ack */
> +#define DW_UART_TCR 0xac /* Transceiver Control Register (RS485) */
> +#define DW_UART_DE_EN 0xb0 /* Driver Output Enable Register */
> +#define DW_UART_RE_EN 0xb4 /* Receiver Output Enable Register */
> +#define DW_UART_DLF 0xc0 /* Divisor Latch Fraction Register */
> +#define DW_UART_RAR 0xc4 /* Receive Address Register */
> +#define DW_UART_TAR 0xc8 /* Transmit Address Register */
> +#define DW_UART_LCR_EXT 0xcc /* Line Extended Control Register */
> +#define DW_UART_CPR 0xf4 /* Component Parameter Register */
> +#define DW_UART_UCV 0xf8 /* UART Component Version */
> +
> +/* Receive / Transmit Address Register bits */
> +#define DW_UART_ADDR_MASK GENMASK(7, 0)
> +/* Line Status Register bits */
> +#define DW_UART_LSR_ADDR_RCVD BIT(8)
Like this one, the IIR. MCR, and USR bits should be commented. Also preserve
the sorting by the register offset, so the groups of bits follow the above list
of registers, where USR bits, for example, should go before TCR.
> +/* Transceiver Control Register bits */
> +#define DW_UART_TCR_RS485_EN BIT(0)
> +#define DW_UART_TCR_RE_POL BIT(1)
> +#define DW_UART_TCR_DE_POL BIT(2)
> +#define DW_UART_TCR_XFER_MODE GENMASK(4, 3)
> +#define DW_UART_TCR_XFER_MODE_DE_DURING_RE FIELD_PREP(DW_UART_TCR_XFER_MODE, 0)
> +#define DW_UART_TCR_XFER_MODE_SW_DE_OR_RE FIELD_PREP(DW_UART_TCR_XFER_MODE, 1)
> +#define DW_UART_TCR_XFER_MODE_DE_OR_RE FIELD_PREP(DW_UART_TCR_XFER_MODE, 2)
> +
> +/* Line Extended Control Register bits */
> +#define DW_UART_LCR_EXT_DLS_E BIT(0)
> +#define DW_UART_LCR_EXT_ADDR_MATCH BIT(1)
> +#define DW_UART_LCR_EXT_SEND_ADDR BIT(2)
> +#define DW_UART_LCR_EXT_TRANSMIT_MODE BIT(3)
> +
> +/* Component Parameter Register bits */
> +#define DW_UART_CPR_ABP_DATA_WIDTH GENMASK(1, 0)
> +#define DW_UART_CPR_AFCE_MODE BIT(4)
> +#define DW_UART_CPR_THRE_MODE BIT(5)
> +#define DW_UART_CPR_SIR_MODE BIT(6)
> +#define DW_UART_CPR_SIR_LP_MODE BIT(7)
> +#define DW_UART_CPR_ADDITIONAL_FEATURES BIT(8)
> +#define DW_UART_CPR_FIFO_ACCESS BIT(9)
> +#define DW_UART_CPR_FIFO_STAT BIT(10)
> +#define DW_UART_CPR_SHADOW BIT(11)
> +#define DW_UART_CPR_ENCODED_PARMS BIT(12)
> +#define DW_UART_CPR_DMA_EXTRA BIT(13)
> +#define DW_UART_CPR_FIFO_MODE GENMASK(23, 16)
> +/* DesignWare specific register fields */
> +#define DW_UART_IIR_IID GENMASK(3, 0)
> +#define DW_UART_MCR_SIRE BIT(6)
> +#define DW_UART_USR_BUSY BIT(0)
I.o.w. uncouple these as per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] tty: serial: samsung: add dedicated compatible for exynosauto SoCs
From: Alim Akhtar @ 2026-04-24 10:18 UTC (permalink / raw)
To: krzk, gregkh, jirislaby
Cc: linux-serial, linux-samsung-soc, linux-kernel, Alim Akhtar
In-Reply-To: <CGME20260424100201epcas5p371dd69955076938ee41ed0d823433056@epcas5p3.samsung.com>
Currently Exynosautov-{9,920} getting probed based on exynos850
fallback. It is recommended to have a dedicated compatible for
proper driver binding.
Add specific platfrom_device_id and of_device_id for
unique identification and proper driver binding.
While at it, also declare earlycon for these SoC which is helpful
in debugging early kernel crashes which might occures before
serial driver initialization.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
drivers/tty/serial/samsung_tty.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index e27806bf2cf3..49409cb6fd25 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2500,6 +2500,12 @@ static const struct s3c24xx_serial_drv_data exynos8895_serial_drv_data = {
.fifosize = { 0 },
};
+static const struct s3c24xx_serial_drv_data exynosauto_serial_drv_data = {
+ EXYNOS_COMMON_SERIAL_DRV_DATA,
+ /* samsung,uart-fifosize must be specified in the device tree. */
+ .fifosize = { 0 },
+};
+
static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
.info = {
.name = "Google GS101 UART",
@@ -2531,6 +2537,7 @@ static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
#define EXYNOS5433_SERIAL_DRV_DATA (&exynos5433_serial_drv_data)
#define EXYNOS850_SERIAL_DRV_DATA (&exynos850_serial_drv_data)
#define EXYNOS8895_SERIAL_DRV_DATA (&exynos8895_serial_drv_data)
+#define EXYNOSAUTO_SERIAL_DRV_DATA (&exynosauto_serial_drv_data)
#define GS101_SERIAL_DRV_DATA (&gs101_serial_drv_data)
#else
@@ -2538,6 +2545,7 @@ static const struct s3c24xx_serial_drv_data gs101_serial_drv_data = {
#define EXYNOS5433_SERIAL_DRV_DATA NULL
#define EXYNOS850_SERIAL_DRV_DATA NULL
#define EXYNOS8895_SERIAL_DRV_DATA NULL
+#define EXYNOSAUTO_SERIAL_DRV_DATA NULL
#define GS101_SERIAL_DRV_DATA NULL
#endif
@@ -2621,6 +2629,12 @@ static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
}, {
.name = "exynos850-uart",
.driver_data = (kernel_ulong_t)EXYNOS850_SERIAL_DRV_DATA,
+ }, {
+ .name = "exynosautov9-uart",
+ .driver_data = (kernel_ulong_t)EXYNOSAUTO_SERIAL_DRV_DATA,
+ }, {
+ .name = "exynosautov920-uart",
+ .driver_data = (kernel_ulong_t)EXYNOSAUTO_SERIAL_DRV_DATA,
}, {
.name = "artpec8-uart",
.driver_data = (kernel_ulong_t)ARTPEC8_SERIAL_DRV_DATA,
@@ -2649,6 +2663,10 @@ static const struct of_device_id s3c24xx_uart_dt_match[] = {
.data = S5L_SERIAL_DRV_DATA },
{ .compatible = "samsung,exynos850-uart",
.data = EXYNOS850_SERIAL_DRV_DATA },
+ { .compatible = "samsung,exynosautov9-uart",
+ .data = EXYNOSAUTO_SERIAL_DRV_DATA },
+ { .compatible = "samsung,exynosautov920-uart",
+ .data = EXYNOSAUTO_SERIAL_DRV_DATA },
{ .compatible = "axis,artpec8-uart",
.data = ARTPEC8_SERIAL_DRV_DATA },
{ .compatible = "google,gs101-uart",
@@ -2826,6 +2844,10 @@ OF_EARLYCON_DECLARE(artpec8, "axis,artpec8-uart",
s5pv210_early_console_setup);
OF_EARLYCON_DECLARE(exynos850, "samsung,exynos850-uart",
s5pv210_early_console_setup);
+OF_EARLYCON_DECLARE(exynosauto, "samsung,exynosautov9-uart",
+ s5pv210_early_console_setup);
+OF_EARLYCON_DECLARE(exynosauto, "samsung,exynosautov920-uart",
+ s5pv210_early_console_setup);
static int __init gs101_early_console_setup(struct earlycon_device *device,
const char *opt)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 0/4] serial: 8250_dw: Add support for UltraRISC DP1000 UART
From: Andy Shevchenko @ 2026-04-24 9:58 UTC (permalink / raw)
To: Jia Wang
Cc: Ilpo Järvinen, Greg Kroah-Hartman, Jiri Slaby, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-serial,
linux-riscv, devicetree, Conor Dooley
In-Reply-To: <20260424-ultrarisc-serial-v4-0-1765a0b4c4a0@ultrarisc.com>
On Fri, Apr 24, 2026 at 01:39:27PM +0800, Jia Wang wrote:
> This patch series adds support for the UltraRISC DP1000 UART controller.
>
> The series includes four patches. The first two are preparatory cleanups;
> the last two add the DP1000 compatible and fixed CPR handling.
>
> The patches have been tested on an UltraRISC DP1000 development board with
> Linux v7.0-rc7, verifying basic UART functionality.
Now it looks good to me, thanks!
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(except DT bindings, not an expert, no tag)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] serial: 8250_hub6: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-24 8:54 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Guangshuo Li, Russell King,
linux-kernel, linux-serial
In-Reply-To: <20260415185339.3804023-1-lgs201920130244@gmail.com>
Hi,
Please disregard this patch.
On Thu, 16 Apr 2026 at 02:53, Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
> When platform_device_register() fails in hub6_init(), the embedded
> struct device in hub6_device has already been initialized by
> device_initialize(), but the failure path returns the error without
> dropping the device reference for the current platform device:
>
> hub6_init()
> -> platform_device_register(&hub6_device)
> -> device_initialize(&hub6_device.dev)
> -> setup_pdev_dma_masks(&hub6_device)
> -> platform_device_add(&hub6_device)
>
> This leads to a reference leak when platform_device_register() fails.
> Fix this by calling platform_device_put() before returning the error.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Fixes: ec9f47cd6a14c ("[PATCH] Serial: Split 8250 port table")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/tty/serial/8250/8250_hub6.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_hub6.c b/drivers/tty/serial/8250/8250_hub6.c
> index 273f59b9bca5..005dd6bec3da 100644
> --- a/drivers/tty/serial/8250/8250_hub6.c
> +++ b/drivers/tty/serial/8250/8250_hub6.c
> @@ -43,9 +43,14 @@ static struct platform_device hub6_device = {
>
> static int __init hub6_init(void)
> {
> - return platform_device_register(&hub6_device);
> -}
> + int ret;
> +
> + ret = platform_device_register(&hub6_device);
> + if (ret)
> + platform_device_put(&hub6_device);
>
> + return ret;
> +}
> module_init(hub6_init);
>
> MODULE_AUTHOR("Russell King");
> --
> 2.43.0
>
After re-checking it, hub6_device is a static platform_device and it does
not provide a dev.release callback. Therefore calling
platform_device_put() on the platform_device_register() failure path is
not appropriate here and can trigger the missing release callback
warning.
This falls into the same static platform_device pattern pointed out in
the other reviews, so I will drop this patch.
Sorry for the noise.
Best regards,
Guangshuo Li
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox