* [PATCH 1/9] serial: core: add uart_iotype_mmio/legacy_io helper functions
From: Hugo Villeneuve @ 2026-04-23 20:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, ilpo.jarvinen, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260423-tty-upio-v1-0-baf82d3b86d1@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
To help simplify code that check on the io type mode of the port.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
Will also be used by future commit that add UPIO_BUS.
---
drivers/tty/serial/serial_core.c | 28 ++++++++++++++++++++++++++++
include/linux/serial_core.h | 4 ++++
2 files changed, 32 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 89cebdd278410a5a97f3f5ee1b9c171715145067..b1cf45a8fc854cd97e349ff077d83b42e3ef8b16 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1966,6 +1966,34 @@ static const char *uart_type(struct uart_port *port)
return str;
}
+bool uart_iotype_mmio(enum uart_iotype iotype)
+{
+ switch (iotype) {
+ case UPIO_MEM:
+ case UPIO_MEM32:
+ case UPIO_AU:
+ case UPIO_TSI:
+ case UPIO_MEM32BE:
+ case UPIO_MEM16:
+ return true;
+ default:
+ return false;
+ }
+}
+EXPORT_SYMBOL_GPL(uart_iotype_mmio);
+
+bool uart_iotype_legacy_io(enum uart_iotype iotype)
+{
+ switch (iotype) {
+ case UPIO_PORT:
+ case UPIO_HUB6:
+ return true;
+ default:
+ return false;
+ }
+}
+EXPORT_SYMBOL_GPL(uart_iotype_legacy_io);
+
#ifdef CONFIG_PROC_FS
static void uart_line_info(struct seq_file *m, struct uart_state *state)
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 666430b4789977ae19641442b369eb1c773233f4..fc3f5ebe389658c197ffc105ce4ac11cacef59bb 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -1306,4 +1306,8 @@ static inline int uart_handle_break(struct uart_port *port)
!((cflag) & CLOCAL))
int uart_get_rs485_mode(struct uart_port *port);
+
+bool uart_iotype_mmio(enum uart_iotype iotype);
+bool uart_iotype_legacy_io(enum uart_iotype iotype);
+
#endif /* LINUX_SERIAL_CORE_H */
--
2.47.3
^ permalink raw reply related
* [PATCH 4/9] serial: core: fix indentation/alignment
From: Hugo Villeneuve @ 2026-04-23 20:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, ilpo.jarvinen, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260423-tty-upio-v1-0-baf82d3b86d1@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Fixes the following checkpatch warnings:
CHECK: Alignment should match open parenthesis
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
Without this, the next patch will have a checkpatch warning.
---
drivers/tty/serial/serial_core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index fc273f8f9e75de89dca1ac1aca3589567bcf8a18..cb5da344305e397b42f47bdbc2c053fc487ed784 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2507,10 +2507,10 @@ uart_report_port(struct uart_driver *drv, struct uart_port *port)
}
pr_info("%s%s%s at %s (irq = %u, base_baud = %u) is a %s\n",
- port->dev ? dev_name(port->dev) : "",
- port->dev ? ": " : "",
- port->name,
- address, port->irq, port->uartclk / 16, uart_type(port));
+ port->dev ? dev_name(port->dev) : "",
+ port->dev ? ": " : "",
+ port->name,
+ address, port->irq, port->uartclk / 16, uart_type(port));
/* The magic multiplier feature is a bit obscure, so report it too. */
if (port->flags & UPF_MAGIC_MULTIPLIER)
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] dt-bindings: qcom: geni-se-qup: Add compatible for Nord SoC
From: Shawn Guo @ 2026-04-23 14:44 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, 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: <CAL_Jsq+2oJF4GG=PDsW1y6Cz7-+Qp2DUz1jXEXxD54PoO9zRRQ@mail.gmail.com>
On Thu, Apr 23, 2026 at 07:08:15AM -0500, Rob Herring wrote:
> On Thu, Apr 23, 2026 at 6:07 AM Shawn Guo
> <shengchao.guo@oss.qualcomm.com> wrote:
> >
> > On Mon, Apr 20, 2026 at 02:44:01PM +0800, Shawn Guo wrote:
> > > From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> > >
> > > Add compatibles for GENI Serial Engine QUP Wrapper 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>
> > > ---
> > > .../soc/qcom/qcom,sa8255p-geni-se-qup.yaml | 20 +++++++++++++++----
> > > 1 file changed, 16 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
> > > index 352af3426d34..d73f9edcbbdb 100644
> > > --- a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
> > > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
> > > @@ -19,7 +19,12 @@ description:
> > >
> > > properties:
> > > compatible:
> > > - const: qcom,sa8255p-geni-se-qup
> > > + oneOf:
> > > + - enum:
> > > + - qcom,sa8255p-geni-se-qup
> > > + - items:
> > > + - const: qcom,nord-auto-geni-se-qup
> >
> > AUTO variant of Nord is SA8797P, so it makes more sense to use
> > 'qcom,sa8797p-geni-se-qup' which is more consistent to
> > 'qcom,sa8255p-geni-se-qup'. Will update in the next version.
>
> I thought QCom moved to these codenames because the chips are the same
> with different part#'s by market/application.
Hi Rob,
Your observation is correct! We did move to using code names. But we
hadn't needed to use part number along with code name until Nord SA8797P
(and Lemans SA8255P), where platform resources like clock, regulator,
interconnect, powerdomain and PHY are handled in firmware through SCMI.
Those resources will be present in Nord's DT but not in SA8797P's for
some devices, e.g. geni-se-qup. That said, SA8797P has a different
programming model from Nord for these devices. In case of geni-se-qup,
Nord is compatible with 'qcom,geni-se-qup' while SA8797P is compatible
with 'qcom,sa8255p-geni-se-qup'.
Hope it clarifies the thing a bit. And I will update subject and commit log
to make it clear that we are actually documenting geni-se-qup for SA8797P.
Shawn
^ permalink raw reply
* Re: [PATCH] dt-bindings: qcom: geni-se-qup: Add compatible for Nord SoC
From: Rob Herring @ 2026-04-23 12:08 UTC (permalink / raw)
To: Shawn Guo
Cc: Bjorn Andersson, 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: <aen9U_3jMRagJwgp@QCOM-aGQu4IUr3Y>
On Thu, Apr 23, 2026 at 6:07 AM Shawn Guo
<shengchao.guo@oss.qualcomm.com> wrote:
>
> On Mon, Apr 20, 2026 at 02:44:01PM +0800, Shawn Guo wrote:
> > From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> >
> > Add compatibles for GENI Serial Engine QUP Wrapper 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>
> > ---
> > .../soc/qcom/qcom,sa8255p-geni-se-qup.yaml | 20 +++++++++++++++----
> > 1 file changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
> > index 352af3426d34..d73f9edcbbdb 100644
> > --- a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
> > @@ -19,7 +19,12 @@ description:
> >
> > properties:
> > compatible:
> > - const: qcom,sa8255p-geni-se-qup
> > + oneOf:
> > + - enum:
> > + - qcom,sa8255p-geni-se-qup
> > + - items:
> > + - const: qcom,nord-auto-geni-se-qup
>
> AUTO variant of Nord is SA8797P, so it makes more sense to use
> 'qcom,sa8797p-geni-se-qup' which is more consistent to
> 'qcom,sa8255p-geni-se-qup'. Will update in the next version.
I thought QCom moved to these codenames because the chips are the same
with different part#'s by market/application.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: qcom: geni-se-qup: Add compatible for Nord SoC
From: Shawn Guo @ 2026-04-23 11:06 UTC (permalink / raw)
To: Bjorn Andersson
Cc: 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: <20260420064401.1248833-1-shengchao.guo@oss.qualcomm.com>
On Mon, Apr 20, 2026 at 02:44:01PM +0800, Shawn Guo wrote:
> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>
> Add compatibles for GENI Serial Engine QUP Wrapper 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>
> ---
> .../soc/qcom/qcom,sa8255p-geni-se-qup.yaml | 20 +++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
> index 352af3426d34..d73f9edcbbdb 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
> @@ -19,7 +19,12 @@ description:
>
> properties:
> compatible:
> - const: qcom,sa8255p-geni-se-qup
> + oneOf:
> + - enum:
> + - qcom,sa8255p-geni-se-qup
> + - items:
> + - const: qcom,nord-auto-geni-se-qup
AUTO variant of Nord is SA8797P, so it makes more sense to use
'qcom,sa8797p-geni-se-qup' which is more consistent to
'qcom,sa8255p-geni-se-qup'. Will update in the next version.
Shawn
> + - const: qcom,sa8255p-geni-se-qup
>
> reg:
> description: QUP wrapper common register address and length.
> @@ -67,9 +72,16 @@ patternProperties:
>
> properties:
> compatible:
> - enum:
> - - qcom,sa8255p-geni-uart
> - - qcom,sa8255p-geni-debug-uart
> + oneOf:
> + - enum:
> + - qcom,sa8255p-geni-uart
> + - qcom,sa8255p-geni-debug-uart
> + - items:
> + - const: qcom,nord-auto-geni-uart
> + - const: qcom,sa8255p-geni-uart
> + - items:
> + - const: qcom,nord-auto-geni-debug-uart
> + - const: qcom,sa8255p-geni-debug-uart
>
> required:
> - compatible
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: arm: amlogic: add A311Y3 support
From: Xianwei Zhao via B4 Relay @ 2026-04-23 9:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Greg Kroah-Hartman, Jiri Slaby
Cc: devicetree, linux-kernel, linux-serial, linux-arm-kernel,
linux-amlogic, Xianwei Zhao, Krzysztof Kozlowski
In-Reply-To: <20260423-a9-baisc-dts-v4-0-c26b480a068c@amlogic.com>
From: Xianwei Zhao <xianwei.zhao@amlogic.com>
Add bindings for the Amlogic BY401 board, using A311Y3 Soc from
Amlogic A9 family chip.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index a885278bc4e2..9f73a0054fb2 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -234,6 +234,12 @@ properties:
- amlogic,av400
- const: amlogic,a5
+ - description: Boards with the Amlogic A9 A311Y3 SoC
+ items:
+ - enum:
+ - amlogic,by401
+ - const: amlogic,a9
+
- description: Boards with the Amlogic C3 C302X/C308L SoC
items:
- enum:
--
2.52.0
^ permalink raw reply related
* [PATCH v4 0/2] basic devicetree support for Amlogic A9
From: Xianwei Zhao via B4 Relay @ 2026-04-23 9:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Greg Kroah-Hartman, Jiri Slaby
Cc: devicetree, linux-kernel, linux-serial, linux-arm-kernel,
linux-amlogic, Xianwei Zhao, Krzysztof Kozlowski
Add the new A9 SoC/board device tree and related bindings.
Since the serial submission has removed this patch as a separate patch.
The dtb check needs to be relied upon for serial submission mereged, or
check failed, when run "make ARCH=arm64 dtbs_check W=1".
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
Changes in v4:
- Rebase code, modfiy size of gic reg, and drop cpu_mask for timer node due to GICv3.
- Link to v3: https://lore.kernel.org/r/20260303-a9-baisc-dts-v3-0-4bf21001f05c@amlogic.com
Changes in v3:
- Remove serial bindings from this patches and will send it independently.
- Link to v2: https://lore.kernel.org/r/20260228-a9-baisc-dts-v2-0-47489d5cc1a8@amlogic.com
Changes in v2:
- Move default interrupt-parent into dtsi.
- Link to v1: https://lore.kernel.org/r/20260205-a9-baisc-dts-v1-0-1212b46f95a7@amlogic.com
---
Xianwei Zhao (2):
dt-bindings: arm: amlogic: add A311Y3 support
arm64: dts: add support for A9 based Amlogic BY401
Documentation/devicetree/bindings/arm/amlogic.yaml | 6 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/amlogic-a9-a311y3-by401.dts | 40 +++++++
arch/arm64/boot/dts/amlogic/amlogic-a9.dtsi | 128 +++++++++++++++++++++
4 files changed, 175 insertions(+)
---
base-commit: 8b379d5e9eb7933c73e77e768d95f11ef2833c26
change-id: 20260205-a9-baisc-dts-cbbbe2e01f80
Best regards,
--
Xianwei Zhao <xianwei.zhao@amlogic.com>
^ permalink raw reply
* [PATCH v4 2/2] arm64: dts: add support for A9 based Amlogic BY401
From: Xianwei Zhao via B4 Relay @ 2026-04-23 9:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Greg Kroah-Hartman, Jiri Slaby
Cc: devicetree, linux-kernel, linux-serial, linux-arm-kernel,
linux-amlogic, Xianwei Zhao
In-Reply-To: <20260423-a9-baisc-dts-v4-0-c26b480a068c@amlogic.com>
From: Xianwei Zhao <xianwei.zhao@amlogic.com>
Add basic support for the A9 based Amlogic BY401 board, which describes
the following components: CPU, GIC, IRQ, Timer and UART.
These are capable of booting up into the serial console.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/amlogic-a9-a311y3-by401.dts | 40 +++++++
arch/arm64/boot/dts/amlogic/amlogic-a9.dtsi | 128 +++++++++++++++++++++
3 files changed, 169 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 15f9c817e502..57bc440fa55c 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_MESON) += amlogic-a4-a113l2-ba400.dtb
dtb-$(CONFIG_ARCH_MESON) += amlogic-a5-a113x2-av400.dtb
+dtb-$(CONFIG_ARCH_MESON) += amlogic-a9-a311y3-by401.dtb
dtb-$(CONFIG_ARCH_MESON) += amlogic-c3-c302x-aw409.dtb
dtb-$(CONFIG_ARCH_MESON) += amlogic-c3-c308l-aw419.dtb
dtb-$(CONFIG_ARCH_MESON) += amlogic-s6-s905x5-bl209.dtb
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-a9-a311y3-by401.dts b/arch/arm64/boot/dts/amlogic/amlogic-a9-a311y3-by401.dts
new file mode 100644
index 000000000000..a6b380ca47a5
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/amlogic-a9-a311y3-by401.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Amlogic, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "amlogic-a9.dtsi"
+/ {
+ model = "Amlogic A311DY3 BY401 Development Board";
+ compatible = "amlogic,by401", "amlogic,a9";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart_b;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x80000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 35 MiB reserved for ARM Trusted Firmware */
+ secmon_reserved: secmon@5000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x05000000 0x0 0x2300000>;
+ no-map;
+ };
+ };
+};
+
+&uart_b {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-a9.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-a9.dtsi
new file mode 100644
index 000000000000..660c8556a864
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/amlogic-a9.dtsi
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Amlogic, Inc. All rights reserved.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ interrupt-parent = <&gic>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x200>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x300>;
+ enable-method = "psci";
+ };
+
+ cpu4: cpu@400 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x400>;
+ enable-method = "psci";
+ };
+
+ cpu5: cpu@500 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x500>;
+ enable-method = "psci";
+ };
+
+ cpu6: cpu@600 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a78";
+ reg = <0x0 0x600>;
+ enable-method = "psci";
+ };
+
+ cpu7: cpu@700 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a78";
+ reg = <0x0 0x700>;
+ enable-method = "psci";
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-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>;
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ xtal: xtal-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "xtal";
+ #clock-cells = <0>;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller@ff800000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x0 0xff800000 0 0x10000>,
+ <0x0 0xff840000 0 0x100000>;
+ interrupts = <GIC_PPI 9 0xf04>;
+ };
+
+ aobus: bus@ffa00000 {
+ compatible = "simple-bus";
+ reg = <0x0 0xffa00000 0x0 0x100000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x0 0x0 0xffa00000 0x0 0x100000>;
+
+ uart_b: serial@1e000 {
+ compatible = "amlogic,a9-uart",
+ "amlogic,meson-s4-uart";
+ reg = <0x0 0x1e000 0x0 0x18>;
+ interrupts = <GIC_SPI 66 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&xtal>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+ };
+ };
+};
--
2.52.0
^ permalink raw reply related
* [PATCH] MEDIATEK: serial: 8250_mtk: Add ACPI support
From: Zhiyong Tao @ 2026-04-23 6:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-kernel, linux-serial, linux-arm-kernel, linux-mediatek,
Project_Global_Digits_Upstream_Group, zhiyong.tao, liguo.zhang,
Vasanth.Reddy, Yenchia Chen
In-Reply-To: <20260423062345.2473300-1-zhiyong.tao@mediatek.com>
Add ACPI support to 8250_mtk driver. This makes it possible to
use UART on ARM-based desktops with EDK2 UEFI firmware.
Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com>
Signed-off-by: Zhiyong Tao <zhiyong.tao@mediatek.com>
---
drivers/tty/serial/8250/8250_mtk.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index 5875a7b9b4b10..e6a56cf54ae0c 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -19,6 +19,7 @@
#include <linux/dma-mapping.h>
#include <linux/tty.h>
#include <linux/tty_flip.h>
+#include <linux/units.h>
#include "8250.h"
@@ -521,6 +522,7 @@ static int mtk8250_probe(struct platform_device *pdev)
struct mtk8250_data *data;
struct resource *regs;
int irq, err;
+ struct fwnode_handle *fwnode = dev_fwnode(&pdev->dev);
irq = platform_get_irq(pdev, 0);
if (irq < 0)
@@ -543,12 +545,13 @@ static int mtk8250_probe(struct platform_device *pdev)
data->clk_count = 0;
- if (pdev->dev.of_node) {
+ if (is_of_node(fwnode)) {
err = mtk8250_probe_of(pdev, &uart.port, data);
if (err)
return err;
- } else
+ } else if (!fwnode) {
return -ENODEV;
+ }
spin_lock_init(&uart.port.lock);
uart.port.mapbase = regs->start;
@@ -564,14 +567,18 @@ static int mtk8250_probe(struct platform_device *pdev)
uart.port.startup = mtk8250_startup;
uart.port.set_termios = mtk8250_set_termios;
uart.port.uartclk = clk_get_rate(data->uart_clk);
+ if (!uart.port.uartclk)
+ uart.port.uartclk = 26 * HZ_PER_MHZ;
#ifdef CONFIG_SERIAL_8250_DMA
if (data->dma)
uart.dma = data->dma;
#endif
- /* Disable Rate Fix function */
- writel(0x0, uart.port.membase +
+ if (is_of_node(fwnode)) {
+ /* Disable Rate Fix function */
+ writel(0x0, uart.port.membase +
(MTK_UART_RATE_FIX << uart.port.regshift));
+ }
platform_set_drvdata(pdev, data);
@@ -649,11 +656,19 @@ static const struct of_device_id mtk8250_of_match[] = {
};
MODULE_DEVICE_TABLE(of, mtk8250_of_match);
+static const struct acpi_device_id mtk8250_acpi_match[] = {
+ { "MTKI0511" },
+ { "NVDA0240" },
+ {}
+};
+MODULE_DEVICE_TABLE(acpi, mtk8250_acpi_match);
+
static struct platform_driver mtk8250_platform_driver = {
.driver = {
.name = "mt6577-uart",
.pm = &mtk8250_pm_ops,
.of_match_table = mtk8250_of_match,
+ .acpi_match_table = mtk8250_acpi_match,
},
.probe = mtk8250_probe,
.remove = mtk8250_remove,
--
2.45.2
^ permalink raw reply related
* [PATCH v2 0/1] Mediatek uart patch
From: Zhiyong Tao @ 2026-04-23 6:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-kernel, linux-serial, linux-arm-kernel, linux-mediatek,
Project_Global_Digits_Upstream_Group, zhiyong.tao, liguo.zhang,
Vasanth.Reddy
This series includes 1 patch:
Add ACPI support on 8250_mtk driver
Changes in patch v2:
1)Change pacth name from 'zhiyong.tao<zhiyong.tao@mediatek.com>'
to 'Zhiyong Tao <zhiyong.tao@mediatek.com>'.
2)Resend the UART upstream patch based on the latest Linux
kernel version(from 'tag: next-20251118' to 'tag: next-20260417').
There is no code change compare to v1.
Zhiyong Tao (1):
MEDIATEK: serial: 8250_mtk: Add ACPI support
drivers/tty/serial/8250/8250_mtk.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH] tty: n_gsm: fix memory leak in gsm_activate_mux
From: Minu Jin @ 2026-04-22 18:33 UTC (permalink / raw)
To: gregkh, jirislaby
Cc: daniel.starke, linux-kernel, linux-serial, Minu Jin,
syzbot+b5d1f455d385b2c7da3c
syzbot reported a memory leak in gsm_activate_mux().
The root cause is a missing cleanup path when gsm_register_devices()
fails. In this case, the previously allocated DLCI 0
and its associated kfifo remain allocated, leading to a memory leak.
And gsm_dlci_alloc() does not check for already allocated DLCIs.
Repeated calls to gsm_activate_mux() would overwrite the existing pointer
in gsm->dlci[addr], causing the original memory to be lost.
Fix this by:
1. Adding gsm_dlci_free() in the error path of gsm_activate_mux().
2. Adding a check in gsm_dlci_alloc() to return the existing DLCI
if it is already allocated.
Reported-by: syzbot+b5d1f455d385b2c7da3c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b5d1f455d385b2c7da3c
Tested-by: syzbot+b5d1f455d385b2c7da3c@syzkaller.appspotmail.com
Fixes: 01aecd917114 ("tty: n_gsm: fix tty registration before control channel open")
Signed-off-by: Minu Jin <s9430939@naver.com>
---
drivers/tty/n_gsm.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c13e050de83b..de3d30eac86e 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2645,7 +2645,12 @@ static int gsm_dlci_config(struct gsm_dlci *dlci, struct gsm_dlci_config *dc, in
static struct gsm_dlci *gsm_dlci_alloc(struct gsm_mux *gsm, int addr)
{
- struct gsm_dlci *dlci = kzalloc_obj(struct gsm_dlci, GFP_ATOMIC);
+ struct gsm_dlci *dlci;
+
+ if (gsm->dlci[addr])
+ return gsm->dlci[addr];
+
+ dlci = kzalloc_obj(struct gsm_dlci, GFP_ATOMIC);
if (dlci == NULL)
return NULL;
spin_lock_init(&dlci->lock);
@@ -3196,8 +3201,10 @@ static int gsm_activate_mux(struct gsm_mux *gsm)
gsm->receive = gsm1_receive;
ret = gsm_register_devices(gsm_tty_driver, gsm->num);
- if (ret)
+ if (ret) {
+ gsm_dlci_free(&dlci->port);
return ret;
+ }
gsm->has_devices = true;
gsm->dead = false; /* Tty opens are now permissible */
--
2.43.0
^ permalink raw reply related
* Re: [syzbot] [serial?] memory leak in gsm_activate_mux
From: syzbot @ 2026-04-22 18:04 UTC (permalink / raw)
To: gregkh, linux-kernel, linux-serial, s9430939, syzkaller-bugs
In-Reply-To: <aekHPX4zEYZoZFOp@JMW-Ubuntu>
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-by: syzbot+b5d1f455d385b2c7da3c@syzkaller.appspotmail.com
Tested-by: syzbot+b5d1f455d385b2c7da3c@syzkaller.appspotmail.com
Tested on:
commit: 6596a02b Merge tag 'drm-next-2026-04-22' of https://gi..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17b574ce580000
kernel config: https://syzkaller.appspot.com/x/.config?x=943968b43250a7da
dashboard link: https://syzkaller.appspot.com/bug?extid=b5d1f455d385b2c7da3c
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch: https://syzkaller.appspot.com/x/patch.diff?x=1117ac36580000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply
* [PATCH] tty: n_gsm: fix memory leak in gsm_activate_mux
From: Minu Jin @ 2026-04-22 17:37 UTC (permalink / raw)
To: syzbot+b5d1f455d385b2c7da3c; +Cc: gregkh, linux-serial, linux-kernel
I found a memory leak in gsm_activate_mux() from the syzbot dashboard.
I have analyzed the root cause and created a fix.
Please test the following patch.
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-next
---
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c13e050de83b..de3d30eac86e 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2645,7 +2645,12 @@ static int gsm_dlci_config(struct gsm_dlci *dlci, struct gsm_dlci_config *dc, in
static struct gsm_dlci *gsm_dlci_alloc(struct gsm_mux *gsm, int addr)
{
- struct gsm_dlci *dlci = kzalloc_obj(struct gsm_dlci, GFP_ATOMIC);
+ struct gsm_dlci *dlci;
+
+ if (gsm->dlci[addr])
+ return gsm->dlci[addr];
+
+ dlci = kzalloc_obj(struct gsm_dlci, GFP_ATOMIC);
if (dlci == NULL)
return NULL;
spin_lock_init(&dlci->lock);
@@ -3196,8 +3201,10 @@ static int gsm_activate_mux(struct gsm_mux *gsm)
gsm->receive = gsm1_receive;
ret = gsm_register_devices(gsm_tty_driver, gsm->num);
- if (ret)
+ if (ret) {
+ gsm_dlci_free(&dlci->port);
return ret;
+ }
gsm->has_devices = true;
gsm->dead = false; /* Tty opens are now permissible */
^ permalink raw reply related
* [PATCH] tty: serial: qcom-geni: re-arm RX DMA on spurious zero-length interrupt
From: Vynnie Von Diktus via B4 Relay @ 2026-04-22 16:13 UTC (permalink / raw)
To: linux-serial; +Cc: linux-kernel, Vynnie Von Diktus
From: Vynnie Von Diktus <vyndiktus@gmail.com>
qcom_geni_serial_handle_rx_dma() returns early when SE_DMA_RX_LEN_IN
reads as zero, interpreting it as a spurious interrupt. The early return
skips geni_se_rx_dma_prep(), leaving the RX DMA descriptor permanently
unarmed. All subsequently received bytes are silently dropped until the
port is closed and reopened.
On cold boots, chip startup transients on the UART lines can produce a
genuine spurious DMA interrupt with a zero-length count. The bug is
invisible on warm reboots (the UART stays powered and stable, so no
spurious interrupt fires), which makes it appear as an intermittent
failure only on power-cycle reboots.
Fix by restructuring the zero-length check to fall through to
geni_se_rx_dma_prep() in all cases. Only the data processing
(handle_rx_uart) is skipped when no bytes arrived.
Tested on SM8150 (Snapdragon 855) with a WCN3990 BT UART — Bluetooth
firmware download now succeeds on every cold boot without
"Frame reassembly failed" errors.
The same GENI serial IP block is used across SDM845, SM8150, SM8250,
SM8350 and many other Snapdragon SoCs; the bug and fix are expected to
apply to all of them.
Signed-off-by: Vynnie Von Diktus <vyndiktus@gmail.com>
---
drivers/tty/serial/qcom_geni_serial.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index 69a632fef..3c950bdc0 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -837,11 +837,9 @@ static void qcom_geni_serial_handle_rx_dma(struct uart_port *uport, bool drop)
rx_in = readl(uport->membase + SE_DMA_RX_LEN_IN);
if (!rx_in) {
dev_warn(uport->dev, "serial engine reports 0 RX bytes in!\n");
- return;
- }
-
- if (!drop)
+ } else if (!drop) {
handle_rx_uart(uport, rx_in, drop);
+ }
ret = geni_se_rx_dma_prep(&port->se, port->rx_buf,
DMA_RX_BUF_SIZE,
---
base-commit: 4a8d8848356e9e4c41e22de9b1ef1507ea21734a
change-id: 20260422-qcom-geni-uart-dma-rearm-a5df83e164ff
Best regards,
--
Vynnie Von Diktus <vyndiktus@gmail.com>
^ permalink raw reply related
* Re: [PATCH] serial: sh-sci: optimize max_freq determination
From: Hugo Villeneuve @ 2026-04-22 14:09 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Geert Uytterhoeven, Greg Kroah-Hartman, Jiri Slaby,
Hugo Villeneuve, biju.das.jz, linux-kernel, linux-serial
In-Reply-To: <20260420121205.f52ae2515cb9ff093c19c6e2@hugovil.com>
On Mon, 20 Apr 2026 12:12:05 -0400
Hugo Villeneuve <hugo@hugovil.com> wrote:
> Hi Geert,
>
> On Mon, 20 Apr 2026 09:23:55 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > Hi Hugo,
> >
> > On Sat, 18 Apr 2026 at 07:24, Hugo Villeneuve <hugo@hugovil.com> wrote:
> > > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > >
> > > Follow example of rsci driver to avoid code duplication and useless
> > > max_freq search when port->uartclk is set to zero.
> > >
> > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/tty/serial/sh-sci.c
> > > +++ b/drivers/tty/serial/sh-sci.c
> > > @@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> > > * setup the baud rate generator hardware for us already.
> > > */
> > > if (!port->uartclk) {
> > > - baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> > > - goto done;
> >
> > There was no "useless max_freq search", due to this goto?
>
> You are right, this part of the comment is wrong.
>
> >
> > > + max_freq = 115200;
> > > + } else {
> > > + for (i = 0; i < SCI_NUM_CLKS; i++)
> > > + max_freq = max(max_freq, s->clk_rates[i]);
> > > +
> > > + max_freq /= min_sr(s);
> > > }
> > >
> > > - for (i = 0; i < SCI_NUM_CLKS; i++)
> > > - max_freq = max(max_freq, s->clk_rates[i]);
> > > -
> > > - baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
> > > + baud = uart_get_baud_rate(port, termios, old, 0, max_freq);
> > > if (!baud)
> > > goto done;
> > >
> >
> > Due to removing the goto above (for the casual reader: this is the
> > earlyprintk case, when port->uartclk is zero), the code will now
> > continue here, calculating transmission parameters and setting best_clk,
> > and overwriting the register configuration done by the bootloader.
>
> Yes, I see it now for sh-sci where we have "if (best_clk >= 0) {"... to
> not configure the registers.
>
> However, for the rsci driver, I think that, even after Biju's cleanup
> serie V3, we still overwrite the register configuration done by the
> bootloader?
>
> Maybe configure only "if (!port->uartclk) {" ?
Argh :) I meant configure only "if (port->uartclk) {" ?
Hugo.
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v3 2/3] serial: sh-sci: Drop check for zero baud rate from uart_get_baud_rate()
From: Hugo Villeneuve @ 2026-04-22 14:05 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Biju Das, biju.das.au, Greg Kroah-Hartman, Jiri Slaby,
Prabhakar Mahadev Lad, Thierry Bultel,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <CAMuHMdUfGY6VwW09zQX8T3_JkRHwKGRUyNGRXvQaD4e58OV8qA@mail.gmail.com>
Hi,
On Wed, 22 Apr 2026 10:59:23 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Biju,
>
> On Wed, 22 Apr 2026 at 09:26, Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > On Mon, 20 Apr 2026 at 16:04, Biju <biju.das.au@gmail.com> wrote:
> > > > From: Biju Das <biju.das.jz@bp.renesas.com>
> > > >
> > > > On DT systems, a zero baud rate from uart_get_baud_rate() is not
The fact that uart_get_baud_rate() cannot return zero is not related
to the system using DT or not, so I would drop this "On DT systems, "
from the commit message.
> > > > possible even earlycon derives its bit rate from chosen/stdout-path.
> > > > The zero baud guard and its associated done label are therefore dead code. So remove it.
> > > >
> > > > Also drop the unused done label from rsci_set_termios().
> > > >
> > > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > >
> > > > --- a/drivers/tty/serial/sh-sci.c
> > > > +++ b/drivers/tty/serial/sh-sci.c
> > > > @@ -2719,8 +2719,6 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> > > > max_freq = max(max_freq, s->clk_rates[i]);
> > > >
> > > > baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
> > > > - if (!baud)
> > > > - goto done;
> > > >
> > > > /*
> > > > * There can be multiple sources for the sampling clock. Find
> > > > the one
> > >
> > > I am afraid you are missing that sh-sci is also used on SH, without DT?
> >
> > Ok, please share your thoughts to handle divide_by_zero fault for
> > SH platforms on the code path after done label??
>
> Someone has to check on an SH platform (or qemu rts7751r2d) if
> this can happen. It might have been broken along the road, as people
> only use earlyprintk when debugging a problem that requires it.
Geert: this "goto done" is not related to the earlyprintk block, which
is untouched by this patch?
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH v3 2/2] serial: 8250_dw: Use a fixed CPR value for UltraRISC DP1000 UART
From: Jia Wang @ 2026-04-22 9:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jia Wang, Ilpo Järvinen, 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: <aeiYLLXTprlzmcpF@ashevche-desk.local>
On 2026-04-22 12:43 +0300, Andy Shevchenko wrote:
> On Wed, Apr 22, 2026 at 05:39:41PM +0800, Jia Wang wrote:
> > On 2026-04-22 11:46 +0300, Andy Shevchenko wrote:
> > > On Wed, Apr 22, 2026 at 11:45:44AM +0300, Andy Shevchenko wrote:
> > > > On Wed, Apr 22, 2026 at 08:57:56AM +0800, Jia Wang wrote:
>
> ...
>
> > > > > Just to confirm: since you mentioned that the preparatory patch moving
> > > > > the DW_UART register defines is already in place, I don't need to move
> > > > > them again, correct?
> > > > >
> > > > > I will update my patch to use the DW_UART_CPR_* macros and
> > > > > FIELD_PREP_CONST() accordingly, and I’m happy to add a separate patch in
> > > > > the next revision to convert the Renesas .cpr_value as well.
> > > >
> > > > My understanding that you want to send a patch series of 3 patches:
> > > > - moving DW_UART_CPR_* values from C-file to h-file
> > > > - modify existing Renesas case
> > >
> > > - DT binding for new HW (patch 1 of this series)
> > >
> > > > - add support for your HW (this patch in updated form)
> >
> > Yes, I will follow this order and resend the series in v4.
>
> Thanks, and since Ilpo mentioned, move all DW_UART_* register offsets/bitfields
> to the header file (in patch 1 of a new series).
>
Thanks, got it. I’ll follow this in v4.
> > > And I forgot that you have a DT binging one... So 4 patches after all.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
Regards,
Jia Wang
^ permalink raw reply
* Re: [PATCH v3 2/2] serial: 8250_dw: Use a fixed CPR value for UltraRISC DP1000 UART
From: Jia Wang @ 2026-04-22 9:45 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Jia Wang, 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: <446bf928-002a-456a-ae50-28220883dade@linux.intel.com>
On 2026-04-22 12:01 +0300, Ilpo Järvinen wrote:
> On Wed, 22 Apr 2026, Jia Wang wrote:
>
> > On 2026-04-21 15:18 +0300, Ilpo Järvinen wrote:
> > > On Tue, 21 Apr 2026, Jia Wang wrote:
> > >
> > > > The UltraRISC DP1000 UART does not provide the standard CPR register used
> > > > by 8250_dw to discover port capabilities.
> > > >
> > > > Provide a fixed CPR value for the DP1000-specific compatible so the
> > > > driver can configure the port correctly.
> > > >
> > > > Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> > > > ---
> > > > drivers/tty/serial/8250/8250_dw.c | 7 +++++++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> > > > index 94beadb4024d..ca6dbdf75918 100644
> > > > --- a/drivers/tty/serial/8250/8250_dw.c
> > > > +++ b/drivers/tty/serial/8250/8250_dw.c
> > > > @@ -962,6 +962,12 @@ static const struct dw8250_platform_data dw8250_intc10ee = {
> > > > .quirks = DW_UART_QUIRK_IER_KICK,
> > > > };
> > > >
> > > > +static const struct dw8250_platform_data dw8250_ultrarisc_dp1000_data = {
> > > > + .usr_reg = DW_UART_USR,
> > > > + .cpr_value = 0x00022022,
> > >
> > > Hi,
> > >
> > > Please construct the cpr_value by ORing DW_UART_CPR_* defines together.
> > > For fields, FIELD_PREP_CONST() may be useful.
> > >
> > > In order to be able to use the DW_UART_CPR_* defines, they need to be
> > > moved into 8250_dwlib.h (I'd move all DW_UART register defines in a
> > > preparatory patch).
> > >
> > > I know the existing Renesas' .cpr_value doesn't follow this convention but
> > > that could be converted as well (in another patch, or leave the Renesas
> > > entry conversion to me if you don't want to do that).
> > >
> >
> > Thanks for the review.
> >
> > Just to confirm: since you mentioned that the preparatory patch moving
> > the DW_UART register defines is already in place, I don't need to move
> > them again, correct?
>
> I'm not sure where that preparatory patch is. Those defines still appear
> in 8250_dwlib.c AFAICT.
>
> To be clear, DW_UART_CPR_* defines are in 8250_dwlib.c but you're
> modifying 8250_dw.c file here so you cannot use those pre-existing defines
> as is in 8250_dw.c. To solve that, please add a preparatory patch into
> your series which relocates all those defines from 8250_dwlib.c to
> 8250_dwlib.h. If there's a patch which does that already, it has missed my
> radar.
>
> And my suggestion is to move not just DW_UART_CPR_* defines into
> 8250_dwlib.h but all DW UART specific register defines to keep them in
> the same place.
>
> Hopefully this clears up any misunderstanding.
>
>
> My main point all along is that do not do the define move in the same
> patch where you're adding UltraRISC DP1000 UART (which is a common pitfall
> to many submitters so I try to give pro-active instructions while
> reviewing to avoid extra versions because of them).
>
Thanks.
Understood. I will add a preparatory patch to move all DW_UART register
defines into 8250_dwlib.h, and update the UltraRISC DP1000 support accordingly.
I will also follow the ordering suggested during review and resend the
series as v4.
> > I will update my patch to use the DW_UART_CPR_* macros and
> > FIELD_PREP_CONST() accordingly, and I’m happy to add a separate patch in
> > the next revision to convert the Renesas .cpr_value as well.
>
> Great, thanks.
>
> > > > + .quirks = DW_UART_QUIRK_CPR_VALUE,
> > > > +};
>
> --
> i.
Regards,
Jia Wang
^ permalink raw reply
* Re: [PATCH v3 2/2] serial: 8250_dw: Use a fixed CPR value for UltraRISC DP1000 UART
From: Andy Shevchenko @ 2026-04-22 9:43 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, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <177685078199.768471.14774992461649696859.b4-reply@b4>
On Wed, Apr 22, 2026 at 05:39:41PM +0800, Jia Wang wrote:
> On 2026-04-22 11:46 +0300, Andy Shevchenko wrote:
> > On Wed, Apr 22, 2026 at 11:45:44AM +0300, Andy Shevchenko wrote:
> > > On Wed, Apr 22, 2026 at 08:57:56AM +0800, Jia Wang wrote:
...
> > > > Just to confirm: since you mentioned that the preparatory patch moving
> > > > the DW_UART register defines is already in place, I don't need to move
> > > > them again, correct?
> > > >
> > > > I will update my patch to use the DW_UART_CPR_* macros and
> > > > FIELD_PREP_CONST() accordingly, and I’m happy to add a separate patch in
> > > > the next revision to convert the Renesas .cpr_value as well.
> > >
> > > My understanding that you want to send a patch series of 3 patches:
> > > - moving DW_UART_CPR_* values from C-file to h-file
> > > - modify existing Renesas case
> >
> > - DT binding for new HW (patch 1 of this series)
> >
> > > - add support for your HW (this patch in updated form)
>
> Yes, I will follow this order and resend the series in v4.
Thanks, and since Ilpo mentioned, move all DW_UART_* register offsets/bitfields
to the header file (in patch 1 of a new series).
> > And I forgot that you have a DT binging one... So 4 patches after all.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 2/2] serial: 8250_dw: Use a fixed CPR value for UltraRISC DP1000 UART
From: Jia Wang @ 2026-04-22 9:39 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jia Wang, Ilpo Järvinen, 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: <aeiK-350Uozq3pVa@ashevche-desk.local>
On 2026-04-22 11:46 +0300, Andy Shevchenko wrote:
> On Wed, Apr 22, 2026 at 11:45:44AM +0300, Andy Shevchenko wrote:
> > On Wed, Apr 22, 2026 at 08:57:56AM +0800, Jia Wang wrote:
>
> ...
>
> > > Just to confirm: since you mentioned that the preparatory patch moving
> > > the DW_UART register defines is already in place, I don't need to move
> > > them again, correct?
> > >
> > > I will update my patch to use the DW_UART_CPR_* macros and
> > > FIELD_PREP_CONST() accordingly, and I’m happy to add a separate patch in
> > > the next revision to convert the Renesas .cpr_value as well.
> >
> > My understanding that you want to send a patch series of 3 patches:
> > - moving DW_UART_CPR_* values from C-file to h-file
> > - modify existing Renesas case
>
> - DT binding for new HW (patch 1 of this series)
>
> > - add support for your HW (this patch in updated form)
>
Yes, I will follow this order and resend the series in v4.
> And I forgot that you have a DT binging one... So 4 patches after all.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
Regards,
Jia Wang
^ permalink raw reply
* Re: [PATCH v3 2/2] serial: 8250_dw: Use a fixed CPR value for UltraRISC DP1000 UART
From: Ilpo Järvinen @ 2026-04-22 9:01 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: <177681947637.2697678.10937675549830278979.b4-reply@b4>
[-- Attachment #1: Type: text/plain, Size: 3124 bytes --]
On Wed, 22 Apr 2026, Jia Wang wrote:
> On 2026-04-21 15:18 +0300, Ilpo Järvinen wrote:
> > On Tue, 21 Apr 2026, Jia Wang wrote:
> >
> > > The UltraRISC DP1000 UART does not provide the standard CPR register used
> > > by 8250_dw to discover port capabilities.
> > >
> > > Provide a fixed CPR value for the DP1000-specific compatible so the
> > > driver can configure the port correctly.
> > >
> > > Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> > > ---
> > > drivers/tty/serial/8250/8250_dw.c | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> > > index 94beadb4024d..ca6dbdf75918 100644
> > > --- a/drivers/tty/serial/8250/8250_dw.c
> > > +++ b/drivers/tty/serial/8250/8250_dw.c
> > > @@ -962,6 +962,12 @@ static const struct dw8250_platform_data dw8250_intc10ee = {
> > > .quirks = DW_UART_QUIRK_IER_KICK,
> > > };
> > >
> > > +static const struct dw8250_platform_data dw8250_ultrarisc_dp1000_data = {
> > > + .usr_reg = DW_UART_USR,
> > > + .cpr_value = 0x00022022,
> >
> > Hi,
> >
> > Please construct the cpr_value by ORing DW_UART_CPR_* defines together.
> > For fields, FIELD_PREP_CONST() may be useful.
> >
> > In order to be able to use the DW_UART_CPR_* defines, they need to be
> > moved into 8250_dwlib.h (I'd move all DW_UART register defines in a
> > preparatory patch).
> >
> > I know the existing Renesas' .cpr_value doesn't follow this convention but
> > that could be converted as well (in another patch, or leave the Renesas
> > entry conversion to me if you don't want to do that).
> >
>
> Thanks for the review.
>
> Just to confirm: since you mentioned that the preparatory patch moving
> the DW_UART register defines is already in place, I don't need to move
> them again, correct?
I'm not sure where that preparatory patch is. Those defines still appear
in 8250_dwlib.c AFAICT.
To be clear, DW_UART_CPR_* defines are in 8250_dwlib.c but you're
modifying 8250_dw.c file here so you cannot use those pre-existing defines
as is in 8250_dw.c. To solve that, please add a preparatory patch into
your series which relocates all those defines from 8250_dwlib.c to
8250_dwlib.h. If there's a patch which does that already, it has missed my
radar.
And my suggestion is to move not just DW_UART_CPR_* defines into
8250_dwlib.h but all DW UART specific register defines to keep them in
the same place.
Hopefully this clears up any misunderstanding.
My main point all along is that do not do the define move in the same
patch where you're adding UltraRISC DP1000 UART (which is a common pitfall
to many submitters so I try to give pro-active instructions while
reviewing to avoid extra versions because of them).
> I will update my patch to use the DW_UART_CPR_* macros and
> FIELD_PREP_CONST() accordingly, and I’m happy to add a separate patch in
> the next revision to convert the Renesas .cpr_value as well.
Great, thanks.
> > > + .quirks = DW_UART_QUIRK_CPR_VALUE,
> > > +};
--
i.
^ permalink raw reply
* Re: [PATCH v3 2/3] serial: sh-sci: Drop check for zero baud rate from uart_get_baud_rate()
From: Geert Uytterhoeven @ 2026-04-22 8:59 UTC (permalink / raw)
To: Biju Das
Cc: biju.das.au, Greg Kroah-Hartman, Jiri Slaby,
Prabhakar Mahadev Lad, Thierry Bultel,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TY3PR01MB113464AE43A23A0B69BCC5675862D2@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Hi Biju,
On Wed, 22 Apr 2026 at 09:26, Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > On Mon, 20 Apr 2026 at 16:04, Biju <biju.das.au@gmail.com> wrote:
> > > From: Biju Das <biju.das.jz@bp.renesas.com>
> > >
> > > On DT systems, a zero baud rate from uart_get_baud_rate() is not
> > > possible even earlycon derives its bit rate from chosen/stdout-path.
> > > The zero baud guard and its associated done label are therefore dead code. So remove it.
> > >
> > > Also drop the unused done label from rsci_set_termios().
> > >
> > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > > --- a/drivers/tty/serial/sh-sci.c
> > > +++ b/drivers/tty/serial/sh-sci.c
> > > @@ -2719,8 +2719,6 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> > > max_freq = max(max_freq, s->clk_rates[i]);
> > >
> > > baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
> > > - if (!baud)
> > > - goto done;
> > >
> > > /*
> > > * There can be multiple sources for the sampling clock. Find
> > > the one
> >
> > I am afraid you are missing that sh-sci is also used on SH, without DT?
>
> Ok, please share your thoughts to handle divide_by_zero fault for
> SH platforms on the code path after done label??
Someone has to check on an SH platform (or qemu rts7751r2d) if
this can happen. It might have been broken along the road, as people
only use earlyprintk when debugging a problem that requires it.
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 v3 2/2] serial: 8250_dw: Use a fixed CPR value for UltraRISC DP1000 UART
From: Andy Shevchenko @ 2026-04-22 8:46 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, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <aeiKsv3bFPJ94InI@ashevche-desk.local>
On Wed, Apr 22, 2026 at 11:45:44AM +0300, Andy Shevchenko wrote:
> On Wed, Apr 22, 2026 at 08:57:56AM +0800, Jia Wang wrote:
...
> > Just to confirm: since you mentioned that the preparatory patch moving
> > the DW_UART register defines is already in place, I don't need to move
> > them again, correct?
> >
> > I will update my patch to use the DW_UART_CPR_* macros and
> > FIELD_PREP_CONST() accordingly, and I’m happy to add a separate patch in
> > the next revision to convert the Renesas .cpr_value as well.
>
> My understanding that you want to send a patch series of 3 patches:
> - moving DW_UART_CPR_* values from C-file to h-file
> - modify existing Renesas case
- DT binding for new HW (patch 1 of this series)
> - add support for your HW (this patch in updated form)
And I forgot that you have a DT binging one... So 4 patches after all.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 2/2] serial: 8250_dw: Use a fixed CPR value for UltraRISC DP1000 UART
From: Andy Shevchenko @ 2026-04-22 8:45 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, LKML, linux-serial,
linux-riscv, devicetree
In-Reply-To: <177681947637.2697678.10937675549830278979.b4-reply@b4>
On Wed, Apr 22, 2026 at 08:57:56AM +0800, Jia Wang wrote:
> On 2026-04-21 15:18 +0300, Ilpo Järvinen wrote:
> > On Tue, 21 Apr 2026, Jia Wang wrote:
...
> > > +static const struct dw8250_platform_data dw8250_ultrarisc_dp1000_data = {
> > > + .usr_reg = DW_UART_USR,
> > > + .cpr_value = 0x00022022,
> >
> > Please construct the cpr_value by ORing DW_UART_CPR_* defines together.
> > For fields, FIELD_PREP_CONST() may be useful.
> >
> > In order to be able to use the DW_UART_CPR_* defines, they need to be
> > moved into 8250_dwlib.h (I'd move all DW_UART register defines in a
> > preparatory patch).
> >
> > I know the existing Renesas' .cpr_value doesn't follow this convention but
> > that could be converted as well (in another patch, or leave the Renesas
> > entry conversion to me if you don't want to do that).
>
> Thanks for the review.
>
> Just to confirm: since you mentioned that the preparatory patch moving
> the DW_UART register defines is already in place, I don't need to move
> them again, correct?
>
> I will update my patch to use the DW_UART_CPR_* macros and
> FIELD_PREP_CONST() accordingly, and I’m happy to add a separate patch in
> the next revision to convert the Renesas .cpr_value as well.
My understanding that you want to send a patch series of 3 patches:
- moving DW_UART_CPR_* values from C-file to h-file
- modify existing Renesas case
- add support for your HW (this patch in updated form)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* RE: [PATCH v3 2/3] serial: sh-sci: Drop check for zero baud rate from uart_get_baud_rate()
From: Biju Das @ 2026-04-22 7:26 UTC (permalink / raw)
To: geert, biju.das.au
Cc: Greg Kroah-Hartman, Jiri Slaby, Prabhakar Mahadev Lad,
Thierry Bultel, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <CAMuHMdXQi7eSZg71=01dYjpmgHRXS+L9hXZMN_dR-mtM6sLKNw@mail.gmail.com>
Hi Geert,
Thanks for the feedback.
> -----Original Message-----
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 22 April 2026 08:05
> Subject: Re: [PATCH v3 2/3] serial: sh-sci: Drop check for zero baud rate from uart_get_baud_rate()
>
> Hi Biju,
>
> On Mon, 20 Apr 2026 at 16:04, Biju <biju.das.au@gmail.com> wrote:
> > From: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > On DT systems, a zero baud rate from uart_get_baud_rate() is not
> > possible even earlycon derives its bit rate from chosen/stdout-path.
> > The zero baud guard and its associated done label are therefore dead code. So remove it.
> >
> > Also drop the unused done label from rsci_set_termios().
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
>
> Thanks for your patch!
>
> > --- a/drivers/tty/serial/sh-sci.c
> > +++ b/drivers/tty/serial/sh-sci.c
> > @@ -2719,8 +2719,6 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> > max_freq = max(max_freq, s->clk_rates[i]);
> >
> > baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
> > - if (!baud)
> > - goto done;
> >
> > /*
> > * There can be multiple sources for the sampling clock. Find
> > the one
>
> I am afraid you are missing that sh-sci is also used on SH, without DT?
Ok, please share your thoughts to handle divide_by_zero fault for
SH platforms on the code path after done label??
Eg:
1) uart_update_timeout(port, termios->c_cflag, baud);
2) s->rx_frame = (10000 * bits) / (baud / 100);
Cheers,
Biju
^ 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