[PATCH 0/5] serial: mcf: add devicetree support

[PATCH 0/5] serial: mcf: add devicetree support

[Greg Ungerer]

This patch series is designed to add devicetree support to the ColdFire
serial driver (mcf.c). The m68k/ColdFire arch support is not devicetree
capable itself yet, but this is an important first step.

The first patch is a cleanup, the second is about normalizing the existing
platform device setup. The third changes the driver to always use dynamic
memory allocation for devices, the forth and fifth patches add the
devicetree support itself.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 b/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml |   43 ++
 b/arch/m68k/coldfire/device.c                                |  179 +++++++----
 b/arch/m68k/include/asm/mcfuart.h                            |   10 
 b/drivers/tty/serial/mcf.c                                   |    4 
 drivers/tty/serial/mcf.c                                     |   93 +++--
 5 files changed, 235 insertions(+), 94 deletions(-)

[PATCH 1/5] serial: mcf: update author email address

[Greg Ungerer]

The copyright and author email address of gerg@uclinux.org is no longer
valid. Change to a current valid email address, gerg@linux-m68k.org.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 drivers/tty/serial/mcf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/mcf.c b/drivers/tty/serial/mcf.c
index 93e7dda4d39a..2b862dfe39ab 100644
--- a/drivers/tty/serial/mcf.c
+++ b/drivers/tty/serial/mcf.c
@@ -4,7 +4,7 @@
 /*
  *	mcf.c -- Freescale ColdFire UART driver
  *
- *	(C) Copyright 2003-2007, Greg Ungerer <gerg@uclinux.org>
+ *	(C) Copyright 2003-2007, Greg Ungerer <gerg@linux-m68k.org>
  */
 
 /****************************************************************************/
@@ -654,7 +654,7 @@ static void __exit mcf_exit(void)
 module_init(mcf_init);
 module_exit(mcf_exit);
 
-MODULE_AUTHOR("Greg Ungerer <gerg@uclinux.org>");
+MODULE_AUTHOR("Greg Ungerer <gerg@linux-m68k.org>");
 MODULE_DESCRIPTION("Freescale ColdFire UART driver");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:mcfuart");
-- 
2.55.0

[PATCH 2/5] serial: mcf: convert to use proper platform resources

[Greg Ungerer]

The ColdFire SoC device setup code supplies a non-standard array of
hardware address information (memory address and IRQ) for initializing
the UARTS - which it does as a single blob. The mcf serial probe
function processes the whole set in one go from a single platform entry.

Convert this setup to use the proper resource structures, with one for
each UART present on a platform. Modify the probe function to process
a single platform device per call, and use the proper platform resource
API to get the memory and IRQ addresses. This results in the proper
entries now being present in /proc/iomem.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 arch/m68k/coldfire/device.c     | 179 +++++++++++++++++++++++---------
 arch/m68k/include/asm/mcfuart.h |  10 --
 drivers/tty/serial/mcf.c        |  45 ++++----
 3 files changed, 154 insertions(+), 80 deletions(-)

diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
index 9a0258acd998..e32bc3322c97 100644
--- a/arch/m68k/coldfire/device.c
+++ b/arch/m68k/coldfire/device.c
@@ -18,8 +18,8 @@
 #include <asm/traps.h>
 #include <asm/coldfire.h>
 #include <asm/mcfsim.h>
-#include <asm/mcfuart.h>
 #include <asm/mcfqspi.h>
+#include <linux/platform_device.h>
 #include <linux/platform_data/edma.h>
 #include <linux/platform_data/dma-mcf-edma.h>
 #include <linux/platform_data/mmc-esdhc-mcf.h>
@@ -27,71 +27,125 @@
 /*
  *	All current ColdFire parts contain from 2, 3, 4 or 10 UARTS.
  */
-static struct mcf_platform_uart mcf_uart_platform_data[] = {
-	{
-		.mapbase	= MCFUART_BASE0,
-		.irq		= MCF_IRQ_UART0,
-	},
-	{
-		.mapbase	= MCFUART_BASE1,
-		.irq		= MCF_IRQ_UART1,
-	},
+static struct resource mcf_uart0_resources[] = {
+	DEFINE_RES_MEM(MCFUART_BASE0, 0x80),
+	DEFINE_RES_IRQ(MCF_IRQ_UART0),
+};
+static struct platform_device mcf_uart0 = {
+	.name			= "mcfuart",
+	.id			= 0,
+	.num_resources		= ARRAY_SIZE(mcf_uart0_resources),
+	.resource		= mcf_uart0_resources,
+};
+
+#ifdef MCFUART_BASE1
+static struct resource mcf_uart1_resources[] = {
+	DEFINE_RES_MEM(MCFUART_BASE1, 0x80),
+	DEFINE_RES_IRQ(MCF_IRQ_UART1),
+};
+static struct platform_device mcf_uart1 = {
+	.name			= "mcfuart",
+	.id			= 1,
+	.num_resources		= ARRAY_SIZE(mcf_uart1_resources),
+	.resource		= mcf_uart1_resources,
+};
+#endif
 #ifdef MCFUART_BASE2
-	{
-		.mapbase	= MCFUART_BASE2,
-		.irq		= MCF_IRQ_UART2,
-	},
+static struct resource mcf_uart2_resources[] = {
+	DEFINE_RES_MEM(MCFUART_BASE2, 0x80),
+	DEFINE_RES_IRQ(MCF_IRQ_UART2),
+};
+static struct platform_device mcf_uart2 = {
+	.name			= "mcfuart",
+	.id			= 2,
+	.num_resources		= ARRAY_SIZE(mcf_uart2_resources),
+	.resource		= mcf_uart2_resources,
+};
 #endif
 #ifdef MCFUART_BASE3
-	{
-		.mapbase	= MCFUART_BASE3,
-		.irq		= MCF_IRQ_UART3,
-	},
+static struct resource mcf_uart3_resources[] = {
+	DEFINE_RES_MEM(MCFUART_BASE3, 0x80),
+	DEFINE_RES_IRQ(MCF_IRQ_UART3),
+};
+static struct platform_device mcf_uart3 = {
+	.name			= "mcfuart",
+	.id			= 3,
+	.num_resources		= ARRAY_SIZE(mcf_uart3_resources),
+	.resource		= mcf_uart3_resources,
+};
 #endif
 #ifdef MCFUART_BASE4
-	{
-		.mapbase	= MCFUART_BASE4,
-		.irq		= MCF_IRQ_UART4,
-	},
+static struct resource mcf_uart4_resources[] = {
+	DEFINE_RES_MEM(MCFUART_BASE4, 0x80),
+	DEFINE_RES_IRQ(MCF_IRQ_UART4),
+};
+static struct platform_device mcf_uart4 = {
+	.name			= "mcfuart",
+	.id			= 4,
+	.num_resources		= ARRAY_SIZE(mcf_uart4_resources),
+	.resource		= mcf_uart4_resources,
+};
 #endif
 #ifdef MCFUART_BASE5
-	{
-		.mapbase	= MCFUART_BASE5,
-		.irq		= MCF_IRQ_UART5,
-	},
+static struct resource mcf_uart5_resources[] = {
+	DEFINE_RES_MEM(MCFUART_BASE5, 0x80),
+	DEFINE_RES_IRQ(MCF_IRQ_UART5),
+};
+static struct platform_device mcf_uart5 = {
+	.name			= "mcfuart",
+	.id			= 5,
+	.num_resources		= ARRAY_SIZE(mcf_uart5_resources),
+	.resource		= mcf_uart5_resources,
+};
 #endif
 #ifdef MCFUART_BASE6
-	{
-		.mapbase	= MCFUART_BASE6,
-		.irq		= MCF_IRQ_UART6,
-	},
+static struct resource mcf_uart6_resources[] = {
+	DEFINE_RES_MEM(MCFUART_BASE6, 0x80),
+	DEFINE_RES_IRQ(MCF_IRQ_UART6),
+};
+static struct platform_device mcf_uart6 = {
+	.name			= "mcfuart",
+	.id			= 6,
+	.num_resources		= ARRAY_SIZE(mcf_uart6_resources),
+	.resource		= mcf_uart6_resources,
+};
 #endif
 #ifdef MCFUART_BASE7
-	{
-		.mapbase	= MCFUART_BASE7,
-		.irq		= MCF_IRQ_UART7,
-	},
+static struct resource mcf_uart7_resources[] = {
+	DEFINE_RES_MEM(MCFUART_BASE7, 0x80),
+	DEFINE_RES_IRQ(MCF_IRQ_UART7),
+};
+static struct platform_device mcf_uart7 = {
+	.name			= "mcfuart",
+	.id			= 7,
+	.num_resources		= ARRAY_SIZE(mcf_uart7_resources),
+	.resource		= mcf_uart7_resources,
+};
 #endif
 #ifdef MCFUART_BASE8
-	{
-		.mapbase	= MCFUART_BASE8,
-		.irq		= MCF_IRQ_UART8,
-	},
+static struct resource mcf_uart8_resources[] = {
+	DEFINE_RES_MEM(MCFUART_BASE8, 0x80),
+	DEFINE_RES_IRQ(MCF_IRQ_UART8),
+};
+static struct platform_device mcf_uart8 = {
+	.name			= "mcfuart",
+	.id			= 8,
+	.num_resources		= ARRAY_SIZE(mcf_uart8_resources),
+	.resource		= mcf_uart8_resources,
+};
 #endif
 #ifdef MCFUART_BASE9
-	{
-		.mapbase	= MCFUART_BASE9,
-		.irq		= MCF_IRQ_UART9,
-	},
-#endif
-	{ },
+static struct resource mcf_uart9_resources[] = {
+	DEFINE_RES_MEM(MCFUART_BASE9, 0x80),
+	DEFINE_RES_IRQ(MCF_IRQ_UART9),
 };
-
-static struct platform_device mcf_uart = {
+static struct platform_device mcf_uart9 = {
 	.name			= "mcfuart",
-	.id			= 0,
-	.dev.platform_data	= mcf_uart_platform_data,
+	.id			= 9,
+	.num_resources		= ARRAY_SIZE(mcf_uart9_resources),
+	.resource		= mcf_uart9_resources,
 };
+#endif
 
 #ifdef MCFFEC_BASE0
 
@@ -623,7 +677,34 @@ static struct platform_device mcf_flexcan0 = {
 #endif /* MCFFLEXCAN_SIZE */
 
 static struct platform_device *mcf_devices[] __initdata = {
-	&mcf_uart,
+	&mcf_uart0,
+#ifdef MCFUART_BASE1
+	&mcf_uart1,
+#endif
+#ifdef MCFUART_BASE2
+	&mcf_uart2,
+#endif
+#ifdef MCFUART_BASE3
+	&mcf_uart3,
+#endif
+#ifdef MCFUART_BASE4
+	&mcf_uart4,
+#endif
+#ifdef MCFUART_BASE5
+	&mcf_uart5,
+#endif
+#ifdef MCFUART_BASE6
+	&mcf_uart6,
+#endif
+#ifdef MCFUART_BASE7
+	&mcf_uart7,
+#endif
+#ifdef MCFUART_BASE8
+	&mcf_uart8,
+#endif
+#ifdef MCFUART_BASE9
+	&mcf_uart9,
+#endif
 #ifdef MCFFEC_BASE0
 	&mcf_fec0,
 #endif
diff --git a/arch/m68k/include/asm/mcfuart.h b/arch/m68k/include/asm/mcfuart.h
index a1f35352f328..c80b022c1ebb 100644
--- a/arch/m68k/include/asm/mcfuart.h
+++ b/arch/m68k/include/asm/mcfuart.h
@@ -13,16 +13,6 @@
 #define	mcfuart_h
 /****************************************************************************/
 
-#include <linux/serial_core.h>
-#include <linux/platform_device.h>
-
-struct mcf_platform_uart {
-	unsigned long	mapbase;	/* Physical address base */
-	void __iomem	*membase;	/* Virtual address if mapped */
-	unsigned int	irq;		/* Interrupt vector */
-	unsigned int	uartclk;	/* UART clock rate */
-};
-
 /*
  *	Define the ColdFire UART register set addresses.
  */
diff --git a/drivers/tty/serial/mcf.c b/drivers/tty/serial/mcf.c
index 2b862dfe39ab..3651910dff99 100644
--- a/drivers/tty/serial/mcf.c
+++ b/drivers/tty/serial/mcf.c
@@ -570,31 +570,34 @@ static struct uart_driver mcf_driver = {
 
 static int mcf_probe(struct platform_device *pdev)
 {
-	struct mcf_platform_uart *platp = dev_get_platdata(&pdev->dev);
 	struct uart_port *port;
-	int i;
+	struct resource *res;
 
-	for (i = 0; ((i < MCF_MAXPORTS) && (platp[i].mapbase)); i++) {
-		port = &mcf_ports[i].port;
+	if (pdev->id >= MCF_MAXPORTS)
+		return -ENODEV;
+	port = &mcf_ports[pdev->id].port;
 
-		port->line = i;
-		port->type = PORT_MCF;
-		port->mapbase = platp[i].mapbase;
-		port->membase = (platp[i].membase) ? platp[i].membase :
-			(unsigned char __iomem *) platp[i].mapbase;
-		port->dev = &pdev->dev;
-		port->iotype = SERIAL_IO_MEM;
-		port->irq = platp[i].irq;
-		port->uartclk = MCF_BUSCLK;
-		port->ops = &mcf_uart_ops;
-		port->flags = UPF_BOOT_AUTOCONF;
-		port->rs485_config = mcf_config_rs485;
-		port->rs485_supported = mcf_rs485_supported;
-		port->has_sysrq = IS_ENABLED(CONFIG_SERIAL_MCF_CONSOLE);
-
-		uart_add_one_port(&mcf_driver, port);
-	}
+	port->membase = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(port->membase))
+		return PTR_ERR(port->membase);
+	port->mapbase = res->start;
+
+	port->irq = platform_get_irq(pdev, 0);
+	if (port->irq < 0)
+		return port->irq;
 
+	port->line = pdev->id;
+	port->type = PORT_MCF;
+	port->dev = &pdev->dev;
+	port->iotype = SERIAL_IO_MEM;
+	port->uartclk = MCF_BUSCLK;
+	port->ops = &mcf_uart_ops;
+	port->flags = UPF_BOOT_AUTOCONF;
+	port->rs485_config = mcf_config_rs485;
+	port->rs485_supported = mcf_rs485_supported;
+	port->has_sysrq = IS_ENABLED(CONFIG_SERIAL_MCF_CONSOLE);
+
+	uart_add_one_port(&mcf_driver, port);
 	return 0;
 }
 
-- 
2.55.0

[PATCH 3/5] serial: mcf: dynamically allocate memory

[Greg Ungerer]

Modify the ColdFire serial driver to dynamically allocate the local uart
port structures as required at init time. Currently it uses a fixed
size array - a little wasteful of memory on most parts with only a
couple of UARTs.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 drivers/tty/serial/mcf.c | 36 ++++++++++++++++++++++++------------
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/tty/serial/mcf.c b/drivers/tty/serial/mcf.c
index 3651910dff99..7cbe43cbe3a0 100644
--- a/drivers/tty/serial/mcf.c
+++ b/drivers/tty/serial/mcf.c
@@ -55,6 +55,14 @@ struct mcf_uart {
 	unsigned char		imr;		/* Local IMR mirror */
 };
 
+/*
+ * Define maximum number of UARTs this driver will support.
+ * This is set to maximum number on any known ColdFire SoC.
+ */
+#define MCF_MAXPORTS            10
+
+static struct mcf_uart *mcf_ports[MCF_MAXPORTS];
+
 /****************************************************************************/
 
 static unsigned int mcf_tx_empty(struct uart_port *port)
@@ -462,19 +470,19 @@ static const struct uart_ops mcf_uart_ops = {
 	.verify_port	= mcf_verify_port,
 };
 
-static struct mcf_uart mcf_ports[10];
-
-#define	MCF_MAXPORTS	ARRAY_SIZE(mcf_ports)
-
 /****************************************************************************/
 #if defined(CONFIG_SERIAL_MCF_CONSOLE)
 /****************************************************************************/
 
 static void mcf_console_putc(struct console *co, const char c)
 {
-	struct uart_port *port = &(mcf_ports + co->index)->port;
+	struct uart_port *port;
 	int i;
 
+	if ((co->index < 0) || (co->index >= MCF_MAXPORTS))
+		co->index = 0;
+	port = &mcf_ports[co->index]->port;
+
 	for (i = 0; (i < 0x10000); i++) {
 		if (readb(port->membase + MCFUART_USR) & MCFUART_USR_TXREADY)
 			break;
@@ -509,9 +517,9 @@ static int __init mcf_console_setup(struct console *co, char *options)
 
 	if ((co->index < 0) || (co->index >= MCF_MAXPORTS))
 		co->index = 0;
-	port = &mcf_ports[co->index].port;
-	if (port->membase == 0)
+	if (mcf_ports[co->index] == NULL)
 		return -ENODEV;
+	port = &mcf_ports[co->index]->port;
 
 	if (options)
 		uart_parse_options(options, &baud, &parity, &bits, &flow);
@@ -572,10 +580,16 @@ static int mcf_probe(struct platform_device *pdev)
 {
 	struct uart_port *port;
 	struct resource *res;
+	struct mcf_uart *mp;
 
 	if (pdev->id >= MCF_MAXPORTS)
 		return -ENODEV;
-	port = &mcf_ports[pdev->id].port;
+
+	mp = devm_kzalloc(&pdev->dev, sizeof(*mp), GFP_KERNEL);
+	if (mp == NULL)
+		return -ENOMEM;
+	mcf_ports[pdev->id] = mp;
+	port = &mp->port;
 
 	port->membase = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
 	if (IS_ERR(port->membase))
@@ -605,13 +619,11 @@ static int mcf_probe(struct platform_device *pdev)
 
 static void mcf_remove(struct platform_device *pdev)
 {
-	struct uart_port *port;
 	int i;
 
 	for (i = 0; (i < MCF_MAXPORTS); i++) {
-		port = &mcf_ports[i].port;
-		if (port)
-			uart_remove_one_port(&mcf_driver, port);
+		if (mcf_ports[i])
+			uart_remove_one_port(&mcf_driver, &mcf_ports[i]->port);
 	}
 }
 
-- 
2.55.0

[PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Greg Ungerer]

Create documentation for a new binding to support the Freescale ColdFire
UART hardware block. This is found on pretty much all variants of the
M68K derived Freescale ColdFire family of System-on-Chip devices.

It is not compatible with any other known UARTs.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 .../bindings/serial/fsl,mcf-uart.yaml         | 43 +++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml

diff --git a/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml b/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml
new file mode 100644
index 000000000000..d1dba518f67a
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/fsl-mcf-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale ColdFire UART
+
+maintainers:
+  - Greg Ungerer <gerg@linux-m68k.org>
+
+allof:
+  - $ref: serial.yaml#
+
+properties:
+  compatible:
+    const: fsl,mcf-uart
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    uart0: serial@fc060000 {
+        compatible = "fsl,mcf-uart";
+        reg = <0xfc060000 0x80>;
+        interrupts = <90>;
+        clocks = <&coreclk>;
+    };
-- 
2.55.0

[PATCH 5/5] serial: mcf: add devicetree support

[Greg Ungerer]

Add basic support for probing the ColdFire UARTs via a devicetree.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
 drivers/tty/serial/mcf.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/tty/serial/mcf.c b/drivers/tty/serial/mcf.c
index 7cbe43cbe3a0..01b3ab6e7dba 100644
--- a/drivers/tty/serial/mcf.c
+++ b/drivers/tty/serial/mcf.c
@@ -21,6 +21,7 @@
 #include <linux/io.h>
 #include <linux/uaccess.h>
 #include <linux/platform_device.h>
+#include <linux/of.h>
 #include <asm/coldfire.h>
 #include <asm/mcfsim.h>
 #include <asm/mcfuart.h>
@@ -62,6 +63,7 @@ struct mcf_uart {
 #define MCF_MAXPORTS            10
 
 static struct mcf_uart *mcf_ports[MCF_MAXPORTS];
+static int mcf_numports;
 
 /****************************************************************************/
 
@@ -582,6 +584,8 @@ static int mcf_probe(struct platform_device *pdev)
 	struct resource *res;
 	struct mcf_uart *mp;
 
+	if (pdev->id == -1)
+		pdev->id = mcf_numports;
 	if (pdev->id >= MCF_MAXPORTS)
 		return -ENODEV;
 
@@ -612,6 +616,8 @@ static int mcf_probe(struct platform_device *pdev)
 	port->has_sysrq = IS_ENABLED(CONFIG_SERIAL_MCF_CONSOLE);
 
 	uart_add_one_port(&mcf_driver, port);
+
+	mcf_numports++;
 	return 0;
 }
 
@@ -629,11 +635,17 @@ static void mcf_remove(struct platform_device *pdev)
 
 /****************************************************************************/
 
+static const struct of_device_id mcf_uart_dt_ids[] = {
+	{ .compatible = "fsl,mcf-uart", },
+	{ }
+};
+
 static struct platform_driver mcf_platform_driver = {
 	.probe		= mcf_probe,
 	.remove		= mcf_remove,
 	.driver		= {
 		.name	= "mcfuart",
+		.of_match_table = mcf_uart_dt_ids,
 	},
 };
 
-- 
2.55.0

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Krzysztof Kozlowski]

On Tue, Oct 13, 2026 at 10:07:02PM +1000, Greg Ungerer wrote:
> Create documentation for a new binding to support the Freescale ColdFire
> UART hardware block. This is found on pretty much all variants of the
> M68K derived Freescale ColdFire family of System-on-Chip devices.
> 
> It is not compatible with any other known UARTs.

You never tested this, so limited review.

> 
> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
> ---
>  .../bindings/serial/fsl,mcf-uart.yaml         | 43 +++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml
> 
> diff --git a/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml b/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml
> new file mode 100644
> index 000000000000..d1dba518f67a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/serial/fsl-mcf-uart.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale ColdFire UART
> +
> +maintainers:
> +  - Greg Ungerer <gerg@linux-m68k.org>
> +
> +allof:
> +  - $ref: serial.yaml#
> +
> +properties:
> +  compatible:
> +    const: fsl,mcf-uart

What is the SoC name? MCF? Compatibles must be specific (see writing
bindings doc).

> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    uart0: serial@fc060000 {

Drop unused label

Best regards,
Krzysztof

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Greg Ungerer]

On 14/10/26 21:24, Krzysztof Kozlowski wrote:
> On Tue, Oct 13, 2026 at 10:07:02PM +1000, Greg Ungerer wrote:
>> Create documentation for a new binding to support the Freescale ColdFire
>> UART hardware block. This is found on pretty much all variants of the
>> M68K derived Freescale ColdFire family of System-on-Chip devices.
>>
>> It is not compatible with any other known UARTs.
> 
> You never tested this, so limited review.

It is tested. It is working and running on multiple ColdFire platforms.


>> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
>> ---
>>  .../bindings/serial/fsl,mcf-uart.yaml         | 43 +++++++++++++++++++
>>  1 file changed, 43 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml b/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml
>> new file mode 100644
>> index 000000000000..d1dba518f67a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml
>> @@ -0,0 +1,43 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/serial/fsl-mcf-uart.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Freescale ColdFire UART
>> +
>> +maintainers:
>> +  - Greg Ungerer <gerg@linux-m68k.org>
>> +
>> +allof:
>> +  - $ref: serial.yaml#
>> +
>> +properties:
>> +  compatible:
>> +    const: fsl,mcf-uart
> 
> What is the SoC name? MCF? Compatibles must be specific (see writing
> bindings doc).

Yes. MCF = "Motorola ColdFire". It is the SoC prefix used for naming of all
ColdFire parts (which is dozens of variants):

   MCF5206
   MCF5208
   MCF5307
   MCF54415
   etc

Even when Motorola became Freescale they stuck with MCF on all ColdFire parts.


>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  interrupts:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - interrupts
>> +  - clocks
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> +  - |
>> +    uart0: serial@fc060000 {
> 
> Drop unused label

Ok, will drop.

Thanks for the review.

Regards
Greg

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Krzysztof Kozlowski]

On Wed, Oct 14, 2026 at 10:48:41PM +1000, Greg Ungerer wrote:
> 
> On 14/10/26 21:24, Krzysztof Kozlowski wrote:
> > On Tue, Oct 13, 2026 at 10:07:02PM +1000, Greg Ungerer wrote:
> >> Create documentation for a new binding to support the Freescale ColdFire
> >> UART hardware block. This is found on pretty much all variants of the
> >> M68K derived Freescale ColdFire family of System-on-Chip devices.
> >>
> >> It is not compatible with any other known UARTs.
> > 
> > You never tested this, so limited review.
> 
> It is tested. It is working and running on multiple ColdFire platforms.

You cannot run a binding. It's impossible, otherwise show me how do you
execute that code.

But as proven already on the lists, no it WAS NOT tested. You have clear
a warning.

Otherwise you claim that tests shown errors and then you decided to
still send it with errors, so then th enext question: why do you send
code which your tests tell it is wrong?

Also, this misses to cc actual maintainers, so I don't have it even in
my mailbox except Patchwork.

Best regards,
Krzysztof

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Geert Uytterhoeven]

Hi Greg,

On Wed, 14 Oct 2026 at 14:56, Greg Ungerer <gerg@linux-m68k.org> wrote:
> On 14/10/26 21:24, Krzysztof Kozlowski wrote:
> > On Tue, Oct 13, 2026 at 10:07:02PM +1000, Greg Ungerer wrote:
> >> Create documentation for a new binding to support the Freescale ColdFire
> >> UART hardware block. This is found on pretty much all variants of the
> >> M68K derived Freescale ColdFire family of System-on-Chip devices.
> >>
> >> It is not compatible with any other known UARTs.
> >
> > You never tested this, so limited review.
>
> It is tested. It is working and running on multiple ColdFire platforms.
>
> >> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>

> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml

> >> +properties:
> >> +  compatible:
> >> +    const: fsl,mcf-uart
> >
> > What is the SoC name? MCF? Compatibles must be specific (see writing
> > bindings doc).
>
> Yes. MCF = "Motorola ColdFire". It is the SoC prefix used for naming of all
> ColdFire parts (which is dozens of variants):
>
>    MCF5206
>    MCF5208
>    MCF5307
>    MCF54415
>    etc
>
> Even when Motorola became Freescale they stuck with MCF on all ColdFire parts.

I guess you want:

    items:
      - enum:
          - fsl,mcf5206
          - fsl,mcf5208
          - fsl,mcf5307
            [...]
      - const: fsl,mcf-uart

As no new (possibly incompatible) Coldfire parts will appear, a generic
fallback looks reasonable to me.

An "mcf" vs. "motorola" vendor prefix might still be a discussion point ;-)

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

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Krzysztof Kozlowski]

On Thu, Oct 15, 2026 at 11:19:31AM +0200, Geert Uytterhoeven wrote:
> I guess you want:
> 
>     items:
>       - enum:
>           - fsl,mcf5206
>           - fsl,mcf5208
>           - fsl,mcf5307
>             [...]
>       - const: fsl,mcf-uart
> 
> As no new (possibly incompatible) Coldfire parts will appear, a generic
> fallback looks reasonable to me.

Yes, although still preference is to use one device as a fallback.

> 
> An "mcf" vs. "motorola" vendor prefix might still be a discussion point ;-)

Best regards,
Krzysztof

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Greg Ungerer]

On 15/10/26 18:56, Krzysztof Kozlowski wrote:
> On Wed, Oct 14, 2026 at 10:48:41PM +1000, Greg Ungerer wrote:
>>
>> On 14/10/26 21:24, Krzysztof Kozlowski wrote:
>>> On Tue, Oct 13, 2026 at 10:07:02PM +1000, Greg Ungerer wrote:
>>>> Create documentation for a new binding to support the Freescale ColdFire
>>>> UART hardware block. This is found on pretty much all variants of the
>>>> M68K derived Freescale ColdFire family of System-on-Chip devices.
>>>>
>>>> It is not compatible with any other known UARTs.
>>>
>>> You never tested this, so limited review.
>>
>> It is tested. It is working and running on multiple ColdFire platforms.
> 
> You cannot run a binding. It's impossible, otherwise show me how do you
> execute that code.

Of course you cannot run a binding. I took your statement to mean that
this series as a whole was not tested. Which is wrong.


> But as proven already on the lists, no it WAS NOT tested. You have clear
> a warning.
> 
> Otherwise you claim that tests shown errors and then you decided to
> still send it with errors, so then th enext question: why do you send
> code which your tests tell it is wrong?

Sorry, I have no idea what you are talking about.

This series of 5 patches was tested before sending, on multiple targets
that use this code (obviously all m68k/ColdFire platforms).

Just in case I missed something I re-ran testing with a fresh 7.3-rc7
code base. All 5 patches applied cleanly, with a clean compile. My testing
showed no new problems in normal operation. Granted sashkio did find a 
couple of error case checking issues that you just do not normally encounter
in practice (but I will of course fix those for v2).

So, no, I didn't just send it knowing that it was failing any tests.

Regards
Greg

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Geert Uytterhoeven]

Hi Greg,

On Thu, 15 Oct 2026 at 14:53, Greg Ungerer <gerg@linux-m68k.org> wrote:
> On 15/10/26 18:56, Krzysztof Kozlowski wrote:
> > But as proven already on the lists, no it WAS NOT tested. You have clear
> > a warning.
> >
> > Otherwise you claim that tests shown errors and then you decided to
> > still send it with errors, so then th enext question: why do you send
> > code which your tests tell it is wrong?
>
> Sorry, I have no idea what you are talking about.
>
> This series of 5 patches was tested before sending, on multiple targets
> that use this code (obviously all m68k/ColdFire platforms).
>
> Just in case I missed something I re-ran testing with a fresh 7.3-rc7
> code base. All 5 patches applied cleanly, with a clean compile. My testing
> showed no new problems in normal operation. Granted sashkio did find a
> couple of error case checking issues that you just do not normally encounter
> in practice (but I will of course fix those for v2).

make dt_binding_check dtbs_check

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

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Greg Ungerer]

Hi Geert,

On 15/10/26 19:19, Geert Uytterhoeven wrote:
> On Wed, 14 Oct 2026 at 14:56, Greg Ungerer <gerg@linux-m68k.org> wrote:
>> On 14/10/26 21:24, Krzysztof Kozlowski wrote:
>>> On Tue, Oct 13, 2026 at 10:07:02PM +1000, Greg Ungerer wrote:
>>>> Create documentation for a new binding to support the Freescale ColdFire
>>>> UART hardware block. This is found on pretty much all variants of the
>>>> M68K derived Freescale ColdFire family of System-on-Chip devices.
>>>>
>>>> It is not compatible with any other known UARTs.
>>>
>>> You never tested this, so limited review.
>>
>> It is tested. It is working and running on multiple ColdFire platforms.
>>
>>>> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
> 
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml
> 
>>>> +properties:
>>>> +  compatible:
>>>> +    const: fsl,mcf-uart
>>>
>>> What is the SoC name? MCF? Compatibles must be specific (see writing
>>> bindings doc).
>>
>> Yes. MCF = "Motorola ColdFire". It is the SoC prefix used for naming of all
>> ColdFire parts (which is dozens of variants):
>>
>>    MCF5206
>>    MCF5208
>>    MCF5307
>>    MCF54415
>>    etc
>>
>> Even when Motorola became Freescale they stuck with MCF on all ColdFire parts.
> 
> I guess you want:
> 
>     items:
>       - enum:
>           - fsl,mcf5206
>           - fsl,mcf5208
>           - fsl,mcf5307
>             [...]
>       - const: fsl,mcf-uart
> 
> As no new (possibly incompatible) Coldfire parts will appear, a generic
> fallback looks reasonable to me.

It will be a long list of variants - thanks Freescale. Quite a few of the SoC
parts have sub-parts with different single digits, for example:

    mcf54410, mcf54415, mcf54416, mcf54417, mcf54118

At a quick count I can see about 42 variants. 
I don't mind adding the full list if that is preferred.


> An "mcf" vs. "motorola" vendor prefix might still be a discussion point ;-)

At least they didn't rename the chip part numbers when they renamed the company ;-)

Regards
Greg

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Greg Ungerer]

Hi Geert,

On 15/10/26 23:06, Geert Uytterhoeven wrote:
> Hi Greg,
> 
> On Thu, 15 Oct 2026 at 14:53, Greg Ungerer <gerg@linux-m68k.org> wrote:
>> On 15/10/26 18:56, Krzysztof Kozlowski wrote:
>>> But as proven already on the lists, no it WAS NOT tested. You have clear
>>> a warning.
>>>
>>> Otherwise you claim that tests shown errors and then you decided to
>>> still send it with errors, so then th enext question: why do you send
>>> code which your tests tell it is wrong?
>>
>> Sorry, I have no idea what you are talking about.
>>
>> This series of 5 patches was tested before sending, on multiple targets
>> that use this code (obviously all m68k/ColdFire platforms).
>>
>> Just in case I missed something I re-ran testing with a fresh 7.3-rc7
>> code base. All 5 patches applied cleanly, with a clean compile. My testing
>> showed no new problems in normal operation. Granted sashkio did find a
>> couple of error case checking issues that you just do not normally encounter
>> in practice (but I will of course fix those for v2).
> 
> make dt_binding_check dtbs_check

I wasn't aware of that. Thanks for pointing it out!  Makes more sense now.

I can see that running it throws up the same 2 errors that sashiko found,
so easily fixed for v2.

Regards
Greg

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Finn Thain]

On Thu, 15 Oct 2026, Geert Uytterhoeven wrote:

> 
> An "mcf" vs. "motorola" vendor prefix might still be a discussion point ;-)
> 

Motorola Solutions is still trading under that name. Sure, that entity is 
unrelated to the Coldfire silicon presently marketed NXP, but I would not 
presume that Motorola Solutions has no interest in this namespace.

Re: [PATCH 4/5] dt-bindings: serial: create binding for mcf-uart

[Rob Herring]

On Thu, Oct 15, 2026 at 11:14:26PM +1000, Greg Ungerer wrote:
> Hi Geert,
> 
> On 15/10/26 19:19, Geert Uytterhoeven wrote:
> > On Wed, 14 Oct 2026 at 14:56, Greg Ungerer <gerg@linux-m68k.org> wrote:
> >> On 14/10/26 21:24, Krzysztof Kozlowski wrote:
> >>> On Tue, Oct 13, 2026 at 10:07:02PM +1000, Greg Ungerer wrote:
> >>>> Create documentation for a new binding to support the Freescale ColdFire
> >>>> UART hardware block. This is found on pretty much all variants of the
> >>>> M68K derived Freescale ColdFire family of System-on-Chip devices.
> >>>>
> >>>> It is not compatible with any other known UARTs.
> >>>
> >>> You never tested this, so limited review.
> >>
> >> It is tested. It is working and running on multiple ColdFire platforms.
> >>
> >>>> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
> > 
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/serial/fsl,mcf-uart.yaml
> > 
> >>>> +properties:
> >>>> +  compatible:
> >>>> +    const: fsl,mcf-uart
> >>>
> >>> What is the SoC name? MCF? Compatibles must be specific (see writing
> >>> bindings doc).
> >>
> >> Yes. MCF = "Motorola ColdFire". It is the SoC prefix used for naming of all
> >> ColdFire parts (which is dozens of variants):
> >>
> >>    MCF5206
> >>    MCF5208
> >>    MCF5307
> >>    MCF54415
> >>    etc
> >>
> >> Even when Motorola became Freescale they stuck with MCF on all ColdFire parts.
> > 
> > I guess you want:
> > 
> >     items:
> >       - enum:
> >           - fsl,mcf5206
> >           - fsl,mcf5208
> >           - fsl,mcf5307
> >             [...]
> >       - const: fsl,mcf-uart
> > 
> > As no new (possibly incompatible) Coldfire parts will appear, a generic
> > fallback looks reasonable to me.
> 
> It will be a long list of variants - thanks Freescale. Quite a few of the SoC
> parts have sub-parts with different single digits, for example:
> 
>     mcf54410, mcf54415, mcf54416, mcf54417, mcf54118

I imagine all of those are just package or marketing differences. 
Freescale did not have the money to tapeout 5 different parts. Just 
using one compatible for all of them is fine. 

> At a quick count I can see about 42 variants. 
> I don't mind adding the full list if that is preferred.

Just add what you care about or know people use. I imagine that's a much 
smaller subset.

Probably not many users today of the 5272 I worked on which was designed 
for ISDN modems.

Rob