[PATCH RFC 00/10] ARM: Add support for Cortina Systems CS75xx and Securifi Almond+

[PATCH RFC 00/10] ARM: Add support for Cortina Systems CS75xx and Securifi Almond+

[Fil Dunsky via B4 Relay]

This series adds initial support for the Cortina Systems CS75xx
("Goldengate G2") network processors and the first board using one, the
Securifi Almond+ touchscreen Wi-Fi router (CS7542, 2x Cortex-A9 r2p1,
PL310 r3p2, 512 MiB DDR3, 512 MiB NAND).

There is no public documentation for the SoC. The register information
comes from the GPL vendor kernels (Linux 2.6.36 for the Almond+, Linux
4.9 for the Verizon FiOS G1100 which uses the same SoC) and from
disassembly of the stock U-Boot 2009.11. A full out-of-tree port
(clock, irqchip, GPIO, I2C, RTC, NAND, PCIe, MDIO and the packet engine)
runs on Linux 6.18 in OpenWrt; this series is the first, minimal step to
get the platform into mainline:

  - bindings: vendor prefix, SoC/board compatibles, an SMP enable method
    and the UART,
  - the platform Kconfig and SMP bring-up (the generic DT machine is
    used, there is no DT_MACHINE_START),
  - DEBUG_LL for UART0,
  - a UART driver with console and earlycon support,
  - SoC dtsi and board dts describing the CPUs, GIC, SCU, timers, L2,
    UARTs and memory,
  - multi_v7_defconfig and MAINTAINERS updates.

Patches 6-7 (serial binding and driver) do not depend on the rest and
can go through the tty tree.

Testing: build tested with multi_v7_defconfig (GCC 14 and Clang 21,
W=1) and checked with dt_binding_check/dtbs_check. On a Securifi
Almond+ this series boots next-20260929 to an initramfs shell with
both CPUs online ("smp: Brought up 1 node, 2 CPUs"; IPIs and the TWD
timer tick on both cores); the L2C-310, the global and TWD timers and
the UART driver (ttyCS0) come up. The kernel was started from a
running OpenWrt system with a small kexec-style loader rather than
from the stock U-Boot, because U-Boot enters the kernel with the MMU
on (see 2 below).

Things I would like feedback on, hence the RFC:

1. The stock U-Boot arms the CPU0 private (TWD) watchdog before
   starting the kernel; without a driver the board resets after ~300
   seconds. The OpenWrt port disarms it in init_early, which I did not
   want to propose here. Instead, a driver for "arm,cortex-a9-twd-wdt"
   (the binding exists, but there is currently no driver for it) that
   takes over the running watchdog on all CPUs is written and tested
   on this board; I will post it with the follow-up series. Until
   then, this series on its own boots but resets after ~5 minutes.
   Is a TWD watchdog driver the preferred way to deal with this?

2. The same U-Boot enters the kernel with the MMU and data cache
   enabled (identity map with XN set, dirty lines left in the D-cache),
   which breaks the decompressor. The OpenWrt port carries a small
   workaround at the start of arch/arm/boot/compressed/head.S that
   cleans the cache and turns the MMU off. It is not part of this series.
   Replacing the bootloader is possible but risky for users of this
   (discontinued) device. Would a quirk of that kind be acceptable in
   head.S at all, or should this be solved outside the kernel (e.g. a
   chain-loaded bootloader)? For the tests below the kernel was started
   from a running Linux with the MMU off, so this was not an issue.

3. The APB clock is 100, 150 or 170 MHz depending on the boot strap pins.
   It is modelled as a fixed-clock with the rate set in the board dts.
   A clock driver for the global control block, which also contains the
   strap, pinmux and reset registers, will follow and replace it.

4. The Cortex-A9 r2p1 is also affected by errata 742230, 742231, 743622
   and 751472, whose workarounds are not available on multiplatform
   kernels because they are expected to be applied by the bootloader.
   The stock U-Boot does not apply them. Is there a preferred way to
   deal with this?

5. The UART ports are named ttyCS to avoid clashing with the 8250 driver
   in multi_v7_defconfig, and PORT_GENERIC is used instead of a new port
   type. The FIFO depth is not documented; the driver assumes 16.

6. The top 64 MiB of RAM are reserved: the vendor firmware gives them to
   the packet engine queue manager and the stock kernel is booted with
   mem=448M. The reservation will be referenced by the network driver
   later; I kept it now so that the memory is not handed out and later
   claimed.

Planned follow-ups, as separate series: the regbus interrupt
controller, GPIO, I2C and TWD watchdog (ready, tested on this board),
then the global control block/clock, RTC, NAND,
PCIe (DesignWare glue), MDIO, the Ethernet/packet engine and a fix for
the SX8650 touchscreen.

---
Fil Dunsky (10):
      dt-bindings: vendor-prefixes: Add Securifi
      dt-bindings: arm: Add Cortina Systems CS7542 and Securifi Almond+
      dt-bindings: arm: cpus: Add Cortina Systems CS7542 enable method
      ARM: cortina: Add support for the CS75xx SoC family
      ARM: debug: Add Cortina Systems CS75xx UART0 support
      dt-bindings: serial: Add Cortina Systems CS7542 UART
      tty: serial: Add Cortina Systems CS75xx UART driver
      ARM: dts: cortina: Add CS7542 SoC and Securifi Almond+ board
      ARM: multi_v7_defconfig: Enable Cortina Systems CS75xx support
      MAINTAINERS: Add entry for Cortina Systems CS75xx

 Documentation/devicetree/bindings/arm/cortina.yaml |  31 ++
 Documentation/devicetree/bindings/arm/cpus.yaml    |   2 +
 .../bindings/serial/cortina,cs7542-uart.yaml       |  50 ++
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 MAINTAINERS                                        |  11 +
 arch/arm/Kconfig                                   |   2 +
 arch/arm/Kconfig.debug                             |  16 +-
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/cortina/Makefile                 |   3 +
 .../dts/cortina/cs7542-securifi-almondplus.dts     |  55 +++
 arch/arm/boot/dts/cortina/cs7542.dtsi              | 127 +++++
 arch/arm/configs/multi_v7_defconfig                |   3 +
 arch/arm/include/debug/cs75xx.S                    |  36 ++
 arch/arm/mach-cortina/Kconfig                      |  18 +
 arch/arm/mach-cortina/Makefile                     |   2 +
 arch/arm/mach-cortina/platsmp.c                    |  71 +++
 drivers/tty/serial/Kconfig                         |  24 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/cs75xx-uart.c                   | 546 +++++++++++++++++++++
 20 files changed, 1000 insertions(+), 2 deletions(-)
---
base-commit: 6474fa070f2b8013b4b87350b775b8c3be6e8aac
change-id: 20260930-b4-cs75xx-033a2c047508

Best regards,
--  
Fil Dunsky <filipp.dunsky@gmail.com>

[PATCH RFC 01/10] dt-bindings: vendor-prefixes: Add Securifi

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

Securifi Ltd. makes the Almond series of touchscreen Wi-Fi routers.
Add a vendor prefix for it.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 5ddeae3a697..71e6f82a71f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1497,6 +1497,8 @@ patternProperties:
     description: SDMC Technology Co., Ltd
   "^seagate,.*":
     description: Seagate Technology PLC
+  "^securifi,.*":
+    description: Securifi Ltd.
   "^seeed,.*":
     description: Seeed Technology Co., Ltd
   "^seirobotics,.*":

-- 
2.53.0

Re: [PATCH RFC 01/10] dt-bindings: vendor-prefixes: Add Securifi

[Linus Walleij]

On Wed, Sep 30, 2026 at 9:00 AM Fil Dunsky via B4 Relay
<devnull+filipp.dunsky.gmail.com@kernel.org> wrote:

> From: Fil Dunsky <filipp.dunsky@gmail.com>
>
> Securifi Ltd. makes the Almond series of touchscreen Wi-Fi routers.
> Add a vendor prefix for it.
>
> Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>

Reviewed-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij

[PATCH RFC 02/10] dt-bindings: arm: Add Cortina Systems CS7542 and Securifi Almond+

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

Add the top-level binding for boards built around the Cortina Systems
CS7542 ("Goldengate G2") network processor, a dual Cortex-A9 SoC, and
the first such board, the Securifi Almond+ touchscreen router.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 Documentation/devicetree/bindings/arm/cortina.yaml | 31 ++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cortina.yaml b/Documentation/devicetree/bindings/arm/cortina.yaml
new file mode 100644
index 00000000000..1c04b178159
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cortina.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/cortina.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cortina Systems CS75xx platforms
+
+maintainers:
+  - Fil Dunsky <filipp.dunsky@gmail.com>
+
+description:
+  The CS75xx ("Goldengate G2") family are network processors from Cortina
+  Systems. The CS7542 has two Cortex-A9 cores with an SCU, GIC, private
+  timers and a PL310 L2 cache controller, a packet processing engine, three
+  PCIe root ports, a NAND flash controller and low speed peripherals.
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - description: CS7542 based boards
+        items:
+          - enum:
+              - securifi,almondplus
+          - const: cortina,cs7542
+
+additionalProperties: true
+
+...

-- 
2.53.0

Re: [PATCH RFC 02/10] dt-bindings: arm: Add Cortina Systems CS7542 and Securifi Almond+

[Linus Walleij]

On Wed, Sep 30, 2026 at 9:00 AM Fil Dunsky via B4 Relay
<devnull+filipp.dunsky.gmail.com@kernel.org> wrote:

> From: Fil Dunsky <filipp.dunsky@gmail.com>
>
> Add the top-level binding for boards built around the Cortina Systems
> CS7542 ("Goldengate G2") network processor, a dual Cortex-A9 SoC, and
> the first such board, the Securifi Almond+ touchscreen router.
>
> Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>

Reviewed-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij

[PATCH RFC 03/10] dt-bindings: arm: cpus: Add Cortina Systems CS7542 enable method

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

On the CS7542 the bootloader parks the secondary Cortex-A9 core in a loop
that waits for an event and then jumps to the address found in a global
software register. Add the "cortina,cs7542-smp" enable method for it and,
as with the other release-address based methods, require cpu-release-addr
to point at that register.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 Documentation/devicetree/bindings/arm/cpus.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 96136b70dac..7a394c500d6 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -269,6 +269,7 @@ properties:
           - brcm,bcm63138
           - brcm,bcm-nsp-smp
           - brcm,brahma-b15
+          - cortina,cs7542-smp
           - marvell,armada-375-smp
           - marvell,armada-380-smp
           - marvell,armada-390-smp
@@ -484,6 +485,7 @@ allOf:
         enable-method:
           enum:
             - spin-table
+            - cortina,cs7542-smp
             - renesas,r9a06g032-smp
       required:
         - enable-method

-- 
2.53.0

Re: [PATCH RFC 03/10] dt-bindings: arm: cpus: Add Cortina Systems CS7542 enable method

[Linus Walleij]

On Wed, Sep 30, 2026 at 9:00 AM Fil Dunsky via B4 Relay
<devnull+filipp.dunsky.gmail.com@kernel.org> wrote:

> From: Fil Dunsky <filipp.dunsky@gmail.com>
>
> On the CS7542 the bootloader parks the secondary Cortex-A9 core in a loop
> that waits for an event and then jumps to the address found in a global
> software register. Add the "cortina,cs7542-smp" enable method for it and,
> as with the other release-address based methods, require cpu-release-addr
> to point at that register.
>
> Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>

Reviewed-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij

[PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

The Cortina Systems CS75xx ("Goldengate G2") are network processors
with two Cortex-A9 cores, an SCU, GIC, the Cortex-A9 global and private
timers and a PL310 L2 cache controller. The CS7542 is used, among others,
in the Securifi Almond+ router.

The generic DT machine is sufficient for the platform, so only the SMP
bring-up needs code: the bootloader parks the secondary core in a WFE
loop that polls a global software register, so boot it by writing the
physical address of secondary_startup to the register named by the
cpu-release-addr property and issuing SEV.

The CPU is a Cortex-A9 r2p1, so select the errata workarounds that apply
to that revision and can be enabled on a multiplatform kernel. The PL310
is r3p2 and needs none of the PL310 workarounds.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm/Kconfig                |  2 ++
 arch/arm/Makefile               |  1 +
 arch/arm/mach-cortina/Kconfig   | 18 +++++++++++
 arch/arm/mach-cortina/Makefile  |  2 ++
 arch/arm/mach-cortina/platsmp.c | 71 +++++++++++++++++++++++++++++++++++++++++
 5 files changed, 94 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0cc289a7184..c4bfdc115ec 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -377,6 +377,8 @@ source "arch/arm/mach-berlin/Kconfig"
 
 source "arch/arm/mach-clps711x/Kconfig"
 
+source "arch/arm/mach-cortina/Kconfig"
+
 source "arch/arm/mach-davinci/Kconfig"
 
 source "arch/arm/mach-digicolor/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 573813ef5e7..f8a7090d047 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -181,6 +181,7 @@ machine-$(CONFIG_ARCH_AXXIA)		+= axxia
 machine-$(CONFIG_ARCH_BCM)		+= bcm
 machine-$(CONFIG_ARCH_BERLIN)		+= berlin
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
+machine-$(CONFIG_ARCH_CORTINA_CS75XX)	+= cortina
 machine-$(CONFIG_ARCH_DAVINCI)		+= davinci
 machine-$(CONFIG_ARCH_DIGICOLOR)	+= digicolor
 machine-$(CONFIG_ARCH_DOVE)		+= dove
diff --git a/arch/arm/mach-cortina/Kconfig b/arch/arm/mach-cortina/Kconfig
new file mode 100644
index 00000000000..9d2fc0e3de1
--- /dev/null
+++ b/arch/arm/mach-cortina/Kconfig
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config ARCH_CORTINA_CS75XX
+	bool "Cortina Systems CS75xx (Goldengate G2)"
+	depends on ARCH_MULTI_V7
+	select ARM_ERRATA_754322
+	select ARM_ERRATA_764369 if SMP
+	select ARM_GIC
+	select ARM_GLOBAL_TIMER
+	select CACHE_L2X0
+	select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+	select HAVE_ARM_SCU if SMP
+	select HAVE_ARM_TWD if SMP
+	help
+	  Support for the Cortina Systems CS75xx (Goldengate G2) family of
+	  network processors, such as the CS7542 used in the Securifi
+	  Almond+ router. These SoCs have two Cortex-A9 cores with a PL310
+	  L2 cache controller, a packet processing engine, PCIe, NAND and
+	  the usual low speed peripherals.
diff --git a/arch/arm/mach-cortina/Makefile b/arch/arm/mach-cortina/Makefile
new file mode 100644
index 00000000000..b839201c980
--- /dev/null
+++ b/arch/arm/mach-cortina/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_SMP)	+= platsmp.o
diff --git a/arch/arm/mach-cortina/platsmp.c b/arch/arm/mach-cortina/platsmp.c
new file mode 100644
index 00000000000..7cd23ee56be
--- /dev/null
+++ b/arch/arm/mach-cortina/platsmp.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * SMP support for the Cortina Systems CS75xx SoCs
+ *
+ * The bootloader parks the secondary core in a WFE loop that polls a
+ * global software register and jumps to the address found there once it
+ * becomes non-zero. The register is described by the cpu-release-addr
+ * property of the secondary CPU node.
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/smp.h>
+#include <asm/smp_plat.h>
+#include <asm/smp_scu.h>
+
+static int cs75xx_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+	struct device_node *np;
+	void __iomem *release;
+	u64 addr;
+	int ret;
+
+	np = of_get_cpu_node(cpu, NULL);
+	if (!np)
+		return -ENODEV;
+
+	ret = of_property_read_u64(np, "cpu-release-addr", &addr);
+	of_node_put(np);
+	if (ret) {
+		pr_err("CPU%u: missing cpu-release-addr\n", cpu);
+		return ret;
+	}
+
+	release = ioremap(addr, sizeof(u32));
+	if (!release)
+		return -ENOMEM;
+
+	writel(__pa_symbol(secondary_startup), release);
+	iounmap(release);
+
+	/* The secondary core waits in WFE, wake it up */
+	dsb_sev();
+
+	return 0;
+}
+
+static void __init cs75xx_smp_prepare_cpus(unsigned int max_cpus)
+{
+	struct device_node *np;
+	void __iomem *scu_base;
+
+	np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
+	scu_base = of_iomap(np, 0);
+	of_node_put(np);
+	if (!scu_base) {
+		pr_err("failed to map SCU\n");
+		return;
+	}
+
+	scu_enable(scu_base);
+	iounmap(scu_base);
+}
+
+static const struct smp_operations cs75xx_smp_ops __initconst = {
+	.smp_prepare_cpus	= cs75xx_smp_prepare_cpus,
+	.smp_boot_secondary	= cs75xx_boot_secondary,
+};
+
+CPU_METHOD_OF_DECLARE(cs7542_smp, "cortina,cs7542-smp", &cs75xx_smp_ops);

-- 
2.53.0

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Linus Walleij]

On Wed, Sep 30, 2026 at 9:00 AM Fil Dunsky via B4 Relay
<devnull+filipp.dunsky.gmail.com@kernel.org> wrote:

> From: Fil Dunsky <filipp.dunsky@gmail.com>
>
> The Cortina Systems CS75xx ("Goldengate G2") are network processors
> with two Cortex-A9 cores, an SCU, GIC, the Cortex-A9 global and private
> timers and a PL310 L2 cache controller. The CS7542 is used, among others,
> in the Securifi Almond+ router.
>
> The generic DT machine is sufficient for the platform, so only the SMP
> bring-up needs code: the bootloader parks the secondary core in a WFE
> loop that polls a global software register, so boot it by writing the
> physical address of secondary_startup to the register named by the
> cpu-release-addr property and issuing SEV.
>
> The CPU is a Cortex-A9 r2p1, so select the errata workarounds that apply
> to that revision and can be enabled on a multiplatform kernel. The PL310
> is r3p2 and needs none of the PL310 workarounds.
>
> Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>

It's a bit weird to have a mach-cortina when mach-gemini is actually
also a Cortina SoC.

Could we call it mach-goldengate?

> +++ b/arch/arm/mach-cortina/platsmp.c
> @@ -0,0 +1,71 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * SMP support for the Cortina Systems CS75xx SoCs
> + *
> + * The bootloader parks the secondary core in a WFE loop that polls a
> + * global software register and jumps to the address found there once it
> + * becomes non-zero. The register is described by the cpu-release-addr
> + * property of the secondary CPU node.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/smp.h>
> +#include <asm/smp_plat.h>
> +#include <asm/smp_scu.h>
> +
> +static int cs75xx_boot_secondary(unsigned int cpu, struct task_struct *idle)
> +{
> +       struct device_node *np;
> +       void __iomem *release;
> +       u64 addr;
> +       int ret;
> +
> +       np = of_get_cpu_node(cpu, NULL);
> +       if (!np)
> +               return -ENODEV;
> +
> +       ret = of_property_read_u64(np, "cpu-release-addr", &addr);
> +       of_node_put(np);
> +       if (ret) {
> +               pr_err("CPU%u: missing cpu-release-addr\n", cpu);
> +               return ret;
> +       }
> +
> +       release = ioremap(addr, sizeof(u32));
> +       if (!release)
> +               return -ENOMEM;
> +
> +       writel(__pa_symbol(secondary_startup), release);
> +       iounmap(release);
> +
> +       /* The secondary core waits in WFE, wake it up */
> +       dsb_sev();
> +
> +       return 0;
> +}
> +
> +static void __init cs75xx_smp_prepare_cpus(unsigned int max_cpus)
> +{
> +       struct device_node *np;
> +       void __iomem *scu_base;
> +
> +       np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
> +       scu_base = of_iomap(np, 0);
> +       of_node_put(np);
> +       if (!scu_base) {
> +               pr_err("failed to map SCU\n");
> +               return;
> +       }
> +
> +       scu_enable(scu_base);
> +       iounmap(scu_base);
> +}
> +
> +static const struct smp_operations cs75xx_smp_ops __initconst = {
> +       .smp_prepare_cpus       = cs75xx_smp_prepare_cpus,
> +       .smp_boot_secondary     = cs75xx_boot_secondary,
> +};
> +
> +CPU_METHOD_OF_DECLARE(cs7542_smp, "cortina,cs7542-smp", &cs75xx_smp_ops);

I am OK with this because it's not like we will add hundreds of these,
I just note that ARM64 has abstracted the spin table handling into a single
driver used by all such systems:
arch/arm64/kernel/smp_spin_table.c

But implementing it for ARM is probably overzealous and just a waste
of everyone's time.

Yours,
Linus Walleij

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Fil Dunsky]

On Wed, Sep 30, 2026 at 12:11 PM Linus Walleij <linusw@kernel.org> wrote:
> It's a bit weird to have a mach-cortina when mach-gemini is actually
> also a Cortina SoC.
>
> Could we call it mach-goldengate?

Sure, that is also what the vendor kernel called it. I will rename it
to arch/arm/mach-goldengate in v2.

Should the Kconfig symbol follow as ARCH_GOLDENGATE, or is
ARCH_CORTINA_CS75XX fine? I would keep the "cortina," compatible
prefix and the arch/arm/boot/dts/cortina directory as they are.

> I am OK with this because it's not like we will add hundreds of these,
> I just note that ARM64 has abstracted the spin table handling into a single
> driver used by all such systems:
> arch/arm64/kernel/smp_spin_table.c
>
> But implementing it for ARM is probably overzealous and just a waste
> of everyone's time.

Agreed, I will leave it as is.

Thanks for the reviews,
Fil

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Krzysztof Kozlowski]

On 30/09/2026 09:00, Fil Dunsky via B4 Relay wrote:
> From: Fil Dunsky <filipp.dunsky@gmail.com>
> 
> The Cortina Systems CS75xx ("Goldengate G2") are network processors
> with two Cortex-A9 cores, an SCU, GIC, the Cortex-A9 global and private
> timers and a PL310 L2 cache controller. The CS7542 is used, among others,
> in the Securifi Almond+ router.
> 
> The generic DT machine is sufficient for the platform, so only the SMP
> bring-up needs code: the bootloader parks the secondary core in a WFE
> loop that polls a global software register, so boot it by writing the
> physical address of secondary_startup to the register named by the
> cpu-release-addr property and issuing SEV.
> 
> The CPU is a Cortex-A9 r2p1, so select the errata workarounds that apply
> to that revision and can be enabled on a multiplatform kernel. The PL310
> is r3p2 and needs none of the PL310 workarounds.

How is it different from Cortina Gemini?

> 
> Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
> ---
>  arch/arm/Kconfig                |  2 ++
>  arch/arm/Makefile               |  1 +
>  arch/arm/mach-cortina/Kconfig   | 18 +++++++++++
>  arch/arm/mach-cortina/Makefile  |  2 ++
>  arch/arm/mach-cortina/platsmp.c | 71 +++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 94 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 0cc289a7184..c4bfdc115ec 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -377,6 +377,8 @@ source "arch/arm/mach-berlin/Kconfig"
>  
>  source "arch/arm/mach-clps711x/Kconfig"
>  
> +source "arch/arm/mach-cortina/Kconfig"
> +
>  source "arch/arm/mach-davinci/Kconfig"
>  
>  source "arch/arm/mach-digicolor/Kconfig"
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 573813ef5e7..f8a7090d047 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -181,6 +181,7 @@ machine-$(CONFIG_ARCH_AXXIA)		+= axxia
>  machine-$(CONFIG_ARCH_BCM)		+= bcm
>  machine-$(CONFIG_ARCH_BERLIN)		+= berlin
>  machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
> +machine-$(CONFIG_ARCH_CORTINA_CS75XX)	+= cortina

Arch should be rather per entire family, not one SoC.

Best regards,
Krzysztof

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Fil Dunsky]

On 30/09/2026 12:20, Krzysztof Kozlowski wrote:
> How is it different from Cortina Gemini?

Apart from the vendor, they have little in common. Gemini (SL3516/
CS3516) is a single ARMv4 FA526 with Faraday peripherals (FTINTC010,
FTTMR010, FTGPIO010, a 16550 UART) and builds for ARCH_MULTI_V4. The
CS75xx ("Goldengate G2") is an ARMv7 dual Cortex-A9 MPCore with GIC,
SCU, TWD/global timer and a PL310, and its UART, GPIO, interrupt
controller and NAND controller are different blocks from the Gemini
ones. So it cannot share mach-gemini or its drivers.

>> +machine-$(CONFIG_ARCH_CORTINA_CS75XX)	+= cortina
>
> Arch should be rather per entire family, not one SoC.

CS75xx is meant as the family (the vendor kernel covers the CS7522 and
CS7542 with one ARCH_GOLDENGATE), but I see the name reads like a
single part. Following Linus' suggestion of mach-goldengate, v2 will
use ARCH_GOLDENGATE and arch/arm/mach-goldengate for the whole family.

Thanks,
Fil

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Linus Walleij]

On Wed, Sep 30, 2026 at 12:57 PM Fil Dunsky <filipp.dunsky@gmail.com> wrote:
> On 30/09/2026 12:20, Krzysztof Kozlowski wrote:

> > How is it different from Cortina Gemini?
>
> Apart from the vendor, they have little in common. Gemini (SL3516/
> CS3516) is a single ARMv4 FA526 with Faraday peripherals (FTINTC010,
> FTTMR010, FTGPIO010, a 16550 UART) and builds for ARCH_MULTI_V4. The
> CS75xx ("Goldengate G2") is an ARMv7 dual Cortex-A9 MPCore with GIC,
> SCU, TWD/global timer and a PL310, and its UART, GPIO, interrupt
> controller and NAND controller are different blocks from the Gemini
> ones. So it cannot share mach-gemini or its drivers.
>
> >> +machine-$(CONFIG_ARCH_CORTINA_CS75XX)       += cortina
> >
> > Arch should be rather per entire family, not one SoC.
>
> CS75xx is meant as the family (the vendor kernel covers the CS7522 and
> CS7542 with one ARCH_GOLDENGATE), but I see the name reads like a
> single part. Following Linus' suggestion of mach-goldengate, v2 will
> use ARCH_GOLDENGATE and arch/arm/mach-goldengate for the whole family.

Put the rationale into the commit message, that's exactly what we want to
see in there.

Thanks!
Linus Walleij

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Arnd Bergmann]

On Wed, Sep 30, 2026, at 13:01, Linus Walleij wrote:
> On Wed, Sep 30, 2026 at 12:57 PM Fil Dunsky <filipp.dunsky@gmail.com> wrote:
>> On 30/09/2026 12:20, Krzysztof Kozlowski wrote:
>
>> > How is it different from Cortina Gemini?
>>
>> Apart from the vendor, they have little in common. Gemini (SL3516/
>> CS3516) is a single ARMv4 FA526 with Faraday peripherals (FTINTC010,
>> FTTMR010, FTGPIO010, a 16550 UART) and builds for ARCH_MULTI_V4. The
>> CS75xx ("Goldengate G2") is an ARMv7 dual Cortex-A9 MPCore with GIC,
>> SCU, TWD/global timer and a PL310, and its UART, GPIO, interrupt
>> controller and NAND controller are different blocks from the Gemini
>> ones. So it cannot share mach-gemini or its drivers.

https://wikidevi.wi-cat.ru/Cortina explains a little more about the
timeline here.

As far as I can tell, both the Storlink/Storm Gemini SL351x/CS351x and
the original Cortina Systems CS75xx ended up in Cortina Access
when Realtek bought that business unit in 2015, but got discontinued
in the meantime:

https://web.archive.org/web/20150729020021/http://www.cortina-access.com/dhp

The rest of what was Cortina Systems at the time remained up in
Inphy and later in Marvell, who I assume hold the naming rights.

>> >> +machine-$(CONFIG_ARCH_CORTINA_CS75XX)       += cortina
>> >
>> > Arch should be rather per entire family, not one SoC.
>>
>> CS75xx is meant as the family (the vendor kernel covers the CS7522 and
>> CS7542 with one ARCH_GOLDENGATE), but I see the name reads like a
>> single part. Following Linus' suggestion of mach-goldengate, v2 will
>> use ARCH_GOLDENGATE and arch/arm/mach-goldengate for the whole family.
>
> Put the rationale into the commit message, that's exactly what we want to
> see in there.

How about making this one ARCH_CORTINA_ACCESS to match the 64-bit port
(saturn, venus) that Jason posted at
https://lore.kernel.org/linux-arm-kernel/20260610112821.3030099-5-jason.li@cortina-access.com/

I think this would be consistent with how we deal with other
acquisitions (storm->cortina, freescale->nxp, ...). I would
leave Gemini as-is because changing the name only causes problems,
but for the new platform I would use the current name of the company
that last sold them.
 
      Arnd

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Fil Dunsky]

On Wed, Sep 30, 2026 at 01:36:32PM +0200, Arnd Bergmann wrote:
> How about making this one ARCH_CORTINA_ACCESS to match the 64-bit port
> (saturn, venus) that Jason posted at
> https://lore.kernel.org/linux-arm-kernel/20260610112821.3030099-5-jason.li@cortina-access.com/
>
> I think this would be consistent with how we deal with other
> acquisitions (storm->cortina, freescale->nxp, ...). I would
> leave Gemini as-is because changing the name only causes problems,
> but for the new platform I would use the current name of the company
> that last sold them.

Thanks for digging out the history, that makes sense. I will use
ARCH_CORTINA_ACCESS for v2 and keep arch/arm/mach-goldengate as the
directory name, as Linus suggested.

Should the DT side follow as well? That would mean a "cortina-access,"
vendor prefix (added by this series, as Jason's has not landed yet),
"cortina-access,cs7542" and "cortina-access,cs7542-uart" instead of
"cortina,...", and arch/arm/boot/dts/cortina-access/ for the dts. I
have no preference, I would just like to change it only once.

Thanks,
Fil

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Arnd Bergmann]

On Wed, Sep 30, 2026, at 13:43, Fil Dunsky wrote:
> On Wed, Sep 30, 2026 at 01:36:32PM +0200, Arnd Bergmann wrote:
>> How about making this one ARCH_CORTINA_ACCESS to match the 64-bit port
>> (saturn, venus) that Jason posted at
>> https://lore.kernel.org/linux-arm-kernel/20260610112821.3030099-5-jason.li@cortina-access.com/
>>
>> I think this would be consistent with how we deal with other
>> acquisitions (storm->cortina, freescale->nxp, ...). I would
>> leave Gemini as-is because changing the name only causes problems,
>> but for the new platform I would use the current name of the company
>> that last sold them.
>
> Thanks for digging out the history, that makes sense. I will use
> ARCH_CORTINA_ACCESS for v2 and keep arch/arm/mach-goldengate as the
> directory name, as Linus suggested.

I think I would go with mach-cortina here. Or even better would be
to find a way not to need any code. If you control the boot loader,
you could just implement the psci ops there and actually bring
up the CPU from EL3. If that doesn't work, maybe it is time to
actually have a generic spin-table implementation on arm32 the
way we do on arm64. As far as I can tell, your code is just
a copy of that anyway, though we have so far never added this to
common arm32 code in order to encourage SoC vendors to use psci.

> Should the DT side follow as well? That would mean a "cortina-access,"
> vendor prefix (added by this series, as Jason's has not landed yet),
> "cortina-access,cs7542" and "cortina-access,cs7542-uart" instead of
> "cortina,...", and arch/arm/boot/dts/cortina-access/ for the dts. I
> have no preference, I would just like to change it only once.

I don't have a strong preference either. If nobody else has a clear
guidance, changing to "cortina-access,..." would seems the most consistent
to me.

    Arnd

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Fil Dunsky]

On Wed, Sep 30, 2026 at 02:02:43PM +0200, Arnd Bergmann wrote:
> I think I would go with mach-cortina here. Or even better would be
> to find a way not to need any code. If you control the boot loader,
> you could just implement the psci ops there and actually bring
> up the CPU from EL3. If that doesn't work, maybe it is time to
> actually have a generic spin-table implementation on arm32 the
> way we do on arm64. As far as I can tell, your code is just
> a copy of that anyway, though we have so far never added this to
> common arm32 code in order to encourage SoC vendors to use psci.

The boot loader is the stock U-Boot 2009.11 from the router vendor, and
replacing it on these devices is risky enough that I would rather not
depend on it, so PSCI is not really an option here.

A generic spin-table for arm32 would work for me, with two differences
from the arm64 one that it would have to cover: the release address
here is an MMIO register in the global control block, not a word in
memory, so it has to be written with writel() through an ioremap(), and
the Cortex-A9 SCU gets enabled in smp_prepare_cpus() (I have not
checked whether the stock U-Boot already does that). If that sounds
acceptable, I can post it as a separate patch in v2 and drop the
enable method binding and mach directory from this series; otherwise
I will keep the small platsmp.c under the name you and Linus agree on.

> I don't have a strong preference either. If nobody else has a clear
> guidance, changing to "cortina-access,..." would seems the most consistent
> to me.

OK, unless the DT maintainers object I will switch to "cortina-access,"
in v2.

Thanks,
Fil

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Arnd Bergmann]

On Wed, Sep 30, 2026, at 14:11, Fil Dunsky wrote:
> On Wed, Sep 30, 2026 at 02:02:43PM +0200, Arnd Bergmann wrote:
>
> The boot loader is the stock U-Boot 2009.11 from the router vendor, and
> replacing it on these devices is risky enough that I would rather not
> depend on it, so PSCI is not really an option here.

Right, makes sense.

> A generic spin-table for arm32 would work for me, with two differences
> from the arm64 one that it would have to cover: the release address
> here is an MMIO register in the global control block, not a word in
> memory, so it has to be written with writel() through an ioremap(), and
> the Cortex-A9 SCU gets enabled in smp_prepare_cpus() (I have not
> checked whether the stock U-Boot already does that). If that sounds
> acceptable, I can post it as a separate patch in v2 and drop the
> enable method binding and mach directory from this series; otherwise
> I will keep the small platsmp.c under the name you and Linus agree on.

It sounds to me like this is different enough from the generic
spin-table that we should keep your current version then.

       Arnd

Re: [PATCH RFC 04/10] ARM: cortina: Add support for the CS75xx SoC family

[Fil Dunsky]

On Wed, Sep 30, 2026 at 02:55:43PM +0200, Arnd Bergmann wrote:
> It sounds to me like this is different enough from the generic
> spin-table that we should keep your current version then.

OK, I will keep platsmp.c then.

That leaves the directory name: Linus suggested mach-goldengate since
mach-gemini is a Cortina SoC too, you would go with mach-cortina.
Linus, with the symbol now being ARCH_CORTINA_ACCESS, is mach-cortina
fine with you, or should it stay mach-goldengate? I will use whatever
you two settle on.

Thanks,
Fil

[PATCH RFC 05/10] ARM: debug: Add Cortina Systems CS75xx UART0 support

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

Add low-level debug output through UART0 of the Cortina Systems CS75xx
SoCs. The UART is mapped at a fixed virtual address by the generic
debug_ll_io_init(), so no platform map_io is needed.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm/Kconfig.debug          | 16 ++++++++++++++--
 arch/arm/include/debug/cs75xx.S | 36 ++++++++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index abcf14f1027..61cd64fc152 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -308,6 +308,15 @@ choice
 		  Say Y here if you want the debug print routines to direct
 		  their output to the second serial port on these devices.
 
+	config DEBUG_CS75XX_UART0
+		bool "Kernel low-level debugging messages via CS75xx UART0"
+		depends on ARCH_CORTINA_CS75XX
+		help
+		  Say Y here if you want the debug print routines to direct
+		  their output to UART0 of Cortina Systems CS75xx SoCs. This
+		  is the console port on the Securifi Almond+. The UART is
+		  expected to be set up by the bootloader.
+
 	config DEBUG_DAVINCI_DA8XX_UART1
 		bool "Kernel low-level debugging on DaVinci DA8XX using UART1"
 		depends on ARCH_DAVINCI_DA8XX
@@ -1531,6 +1540,7 @@ config DEBUG_LL_INCLUDE
 	default "debug/vt8500.S" if DEBUG_VT8500_UART0
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "debug/bcm63xx.S" if DEBUG_BCM63XX_UART || DEBUG_BCMBCA
+	default "debug/cs75xx.S" if DEBUG_CS75XX_UART0
 	default "debug/digicolor.S" if DEBUG_DIGICOLOR_UA0
 	default "debug/brcmstb.S" if DEBUG_BRCMSTB_UART
 	default "mach/debug-macro.S"
@@ -1632,6 +1642,7 @@ config DEBUG_UART_PHYS
 	default 0xe8008000 if DEBUG_R7S72100_SCIF2 || DEBUG_R7S9210_SCIF2
 	default 0xe8009000 if DEBUG_R7S9210_SCIF4
 	default 0xf0000000 if DEBUG_DIGICOLOR_UA0
+	default 0xf0070110 if DEBUG_CS75XX_UART0
 	default 0xf1012000 if DEBUG_MVEBU_UART0_ALTERNATE
 	default 0xf1012100 if DEBUG_MVEBU_UART1_ALTERNATE
 	default 0xf7fc9000 if DEBUG_BERLIN_UART
@@ -1670,7 +1681,7 @@ config DEBUG_UART_PHYS
 		DEBUG_RMOBILE_SCIFA4 || \
 		DEBUG_S3C64XX_UART || \
 		DEBUG_BCM63XX_UART || DEBUG_BCMBCA || DEBUG_ASM9260_UART || \
-		DEBUG_DIGICOLOR_UA0 || \
+		DEBUG_CS75XX_UART0 || DEBUG_DIGICOLOR_UA0 || \
 		DEBUG_AT91_UART || DEBUG_STM32_UART || \
 		DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 || \
 		DEBUG_STIH418_SBC_ASC0
@@ -1708,6 +1719,7 @@ config DEBUG_UART_VIRT
 	default 0xf7000800 if DEBUG_S3C64XX_UART && DEBUG_S3C_UART2
 	default 0xf7000c00 if DEBUG_S3C64XX_UART && DEBUG_S3C_UART3
 	default 0xf7020000 if DEBUG_AT91_SAMA5D2_UART1
+	default 0xf7070110 if DEBUG_CS75XX_UART0
 	default 0xf7fc9000 if DEBUG_BERLIN_UART
 	default 0xf8007000 if DEBUG_HIP04_UART
 	default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9
@@ -1772,7 +1784,7 @@ config DEBUG_UART_VIRT
 		DEBUG_QCOM_UARTDM || \
 		DEBUG_S3C64XX_UART || \
 		DEBUG_BCM63XX_UART || DEBUG_BCMBCA || DEBUG_ASM9260_UART || \
-		DEBUG_DIGICOLOR_UA0 || \
+		DEBUG_CS75XX_UART0 || DEBUG_DIGICOLOR_UA0 || \
 		DEBUG_AT91_UART || DEBUG_STM32_UART || \
 		DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 || \
 		DEBUG_STIH418_SBC_ASC0
diff --git a/arch/arm/include/debug/cs75xx.S b/arch/arm/include/debug/cs75xx.S
new file mode 100644
index 00000000000..d840384cc32
--- /dev/null
+++ b/arch/arm/include/debug/cs75xx.S
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Debugging macro include header for the Cortina Systems CS75xx UART
+ */
+
+#define CS75XX_UART_TXDAT		0x10
+#define CS75XX_UART_INFO		0x18
+#define CS75XX_UART_INFO_TX_FULL	(1 << 2)
+#define CS75XX_UART_INFO_TX_EMPTY	(1 << 3)
+
+		.macro	addruart, rp, rv, tmp
+		ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+		ldr	\rv, =CONFIG_DEBUG_UART_VIRT
+		.endm
+
+		.macro	senduart, rd, rx
+		ARM_BE8(rev \rd, \rd)
+		str	\rd, [\rx, #CS75XX_UART_TXDAT]
+		.endm
+
+		.macro	waituartcts, rd, rx
+		.endm
+
+		.macro	waituarttxrdy, rd, rx
+1001:		ldr	\rd, [\rx, #CS75XX_UART_INFO]
+		ARM_BE8(rev \rd, \rd)
+		tst	\rd, #CS75XX_UART_INFO_TX_FULL
+		bne	1001b
+		.endm
+
+		.macro	busyuart, rd, rx
+1002:		ldr	\rd, [\rx, #CS75XX_UART_INFO]
+		ARM_BE8(rev \rd, \rd)
+		tst	\rd, #CS75XX_UART_INFO_TX_EMPTY
+		beq	1002b
+		.endm

-- 
2.53.0

Re: [PATCH RFC 05/10] ARM: debug: Add Cortina Systems CS75xx UART0 support

[Linus Walleij]

Hi Filipp,

thanks for your patch!

On Wed, Sep 30, 2026 at 9:00 AM Fil Dunsky via B4 Relay
<devnull+filipp.dunsky.gmail.com@kernel.org> wrote:

> +++ b/arch/arm/include/debug/cs75xx.S
> @@ -0,0 +1,36 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Debugging macro include header for the Cortina Systems CS75xx UART
> + */
> +
> +#define CS75XX_UART_TXDAT              0x10
> +#define CS75XX_UART_INFO               0x18
> +#define CS75XX_UART_INFO_TX_FULL       (1 << 2)
> +#define CS75XX_UART_INFO_TX_EMPTY      (1 << 3)

I looked through the other serial drivers but this appears to actually
be unique and
not derived from some other serial port, so:

Reviewed-by: Linus Walleij <linusw@kernel.org>

Sashiko is blathering about big endian support, I think that can be
safely ignored.

Yours,
Linus Walleij

[PATCH RFC 06/10] dt-bindings: serial: Add Cortina Systems CS7542 UART

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

Add the binding for the UART found in the Cortina Systems CS75xx
(Goldengate G2) SoCs such as the CS7542.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 .../bindings/serial/cortina,cs7542-uart.yaml       | 50 ++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/cortina,cs7542-uart.yaml b/Documentation/devicetree/bindings/serial/cortina,cs7542-uart.yaml
new file mode 100644
index 00000000000..2f8bda97ff8
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/cortina,cs7542-uart.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/cortina,cs7542-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cortina Systems CS7542 UART
+
+maintainers:
+  - Fil Dunsky <filipp.dunsky@gmail.com>
+
+description:
+  The UART found in the Cortina Systems CS75xx (Goldengate G2) SoCs. It has
+  transmit and receive FIFOs and a 24-bit baud rate divider running from the
+  peripheral (APB) clock.
+
+allOf:
+  - $ref: serial.yaml#
+
+properties:
+  compatible:
+    const: cortina,cs7542-uart
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    serial@f0070110 {
+        compatible = "cortina,cs7542-uart";
+        reg = <0xf0070110 0x30>;
+        interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&apb_clk>;
+    };

-- 
2.53.0

[PATCH RFC 07/10] tty: serial: Add Cortina Systems CS75xx UART driver

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

Add a driver for the UARTs of the Cortina Systems CS75xx (Goldengate G2)
SoCs. The block has transmit and receive FIFOs with full/empty status,
a 24-bit baud rate divider clocked from the peripheral (APB) clock, a
receive sampling point register and one interrupt line per port with
per-cause enable and write-one-to-clear status registers.

The driver is a rewrite of the vendor driver shipped with the Linux
2.6.36 and 4.9 based vendor kernels, using the current serial core API
(uart_port_tx(), port lock helpers, deferred sysrq handling) and devm
resource management. It supports the system console and earlycon.
Hardware flow control is not supported.

The ports are named ttyCS so that the driver can coexist with the 8250
driver in multiplatform kernels, and PORT_GENERIC is used rather than
allocating a new port type.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 drivers/tty/serial/Kconfig       |  24 ++
 drivers/tty/serial/Makefile      |   1 +
 drivers/tty/serial/cs75xx-uart.c | 546 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 571 insertions(+)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index bf680d22199..c4239c42190 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1359,6 +1359,30 @@ config SERIAL_CONEXANT_DIGICOLOR_CONSOLE
 	  If you have enabled the USART serial port on Conexant Digicolor
 	  SoCs, you can make it the console by answering Y to this option.
 
+config SERIAL_CS75XX
+	tristate "Cortina Systems CS75xx UART support"
+	depends on ARCH_CORTINA_CS75XX || COMPILE_TEST
+	depends on OF
+	select SERIAL_CORE
+	help
+	  Support for the on-chip UARTs of the Cortina Systems CS75xx
+	  (Goldengate G2) SoCs, such as the CS7542. The ports are named
+	  ttyCS0 to ttyCS3.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called cs75xx-uart.
+
+config SERIAL_CS75XX_CONSOLE
+	bool "Console on Cortina Systems CS75xx UART"
+	depends on SERIAL_CS75XX=y
+	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
+	help
+	  Say Y here to use a Cortina Systems CS75xx UART as the system
+	  console. This also enables the early console, which can be
+	  selected with "earlycon" on the kernel command line when the
+	  device tree chosen node has a stdout-path pointing at the UART.
+
 config SERIAL_ST_ASC
 	tristate "ST ASC serial port support"
 	select SERIAL_CORE
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index bba7b21a4a1..81bb5e39aa2 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_SERIAL_BCM63XX)		+= bcm63xx_uart.o
 obj-$(CONFIG_SERIAL_CLPS711X)		+= clps711x.o
 obj-$(CONFIG_SERIAL_CPM)		+= cpm_uart.o
 obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
+obj-$(CONFIG_SERIAL_CS75XX)		+= cs75xx-uart.o
 obj-$(CONFIG_SERIAL_DZ)			+= dz.o
 obj-$(CONFIG_SERIAL_FSL_LINFLEXUART)	+= fsl_linflexuart.o
 obj-$(CONFIG_SERIAL_FSL_LPUART)		+= fsl_lpuart.o
diff --git a/drivers/tty/serial/cs75xx-uart.c b/drivers/tty/serial/cs75xx-uart.c
new file mode 100644
index 00000000000..c15e2227b97
--- /dev/null
+++ b/drivers/tty/serial/cs75xx-uart.c
@@ -0,0 +1,546 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * UART driver for the Cortina Systems CS75xx (Goldengate G2) SoCs
+ *
+ * Based on the Cortina Systems vendor driver.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/console.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+
+#define CS75XX_UART_CFG			0x00
+#define   CS75XX_UART_CFG_BAUD		GENMASK(31, 8)
+#define   CS75XX_UART_CFG_EN		BIT(7)
+#define   CS75XX_UART_CFG_RX_EN		BIT(6)
+#define   CS75XX_UART_CFG_TX_EN		BIT(5)
+#define   CS75XX_UART_CFG_PARITY_EN	BIT(4)
+#define   CS75XX_UART_CFG_PARITY_EVEN	BIT(3)
+#define   CS75XX_UART_CFG_STOP_2BIT	BIT(2)
+#define   CS75XX_UART_CFG_CHAR		GENMASK(1, 0)
+#define CS75XX_UART_RX_SAMPLE		0x08
+#define CS75XX_UART_TXDAT		0x10
+#define CS75XX_UART_RXDAT		0x14
+#define   CS75XX_UART_RXDAT_VALID	BIT(8)
+#define   CS75XX_UART_RXDAT_DATA	GENMASK(7, 0)
+#define CS75XX_UART_INFO		0x18
+#define   CS75XX_UART_INFO_TX_EMPTY	BIT(3)
+#define   CS75XX_UART_INFO_TX_FULL	BIT(2)
+#define   CS75XX_UART_INFO_RX_EMPTY	BIT(1)
+#define CS75XX_UART_IE			0x1c
+#define CS75XX_UART_INT			0x24
+
+/* Interrupt bits, shared by the IE and INT registers */
+#define CS75XX_UART_IRQ_RX_NONEMPTY	BIT(6)
+#define CS75XX_UART_IRQ_TX_EMPTY	BIT(5)
+#define CS75XX_UART_IRQ_RX_OVERRUN	BIT(3)
+#define CS75XX_UART_IRQ_RX_PARITY	BIT(2)
+#define CS75XX_UART_IRQ_RX_STOP		BIT(1)
+#define CS75XX_UART_IRQ_ALL		GENMASK(6, 0)
+
+#define CS75XX_UART_DIV_MIN		16
+#define CS75XX_UART_DIV_MAX		FIELD_MAX(CS75XX_UART_CFG_BAUD)
+
+#define CS75XX_UART_NR_PORTS		4
+#define CS75XX_UART_FIFO_SIZE		16
+#define CS75XX_UART_POLL_TIMEOUT_US	10000
+
+struct cs75xx_uart_port {
+	struct uart_port port;
+	struct clk *clk;
+};
+
+static struct cs75xx_uart_port *cs75xx_uart_ports[CS75XX_UART_NR_PORTS];
+
+static void cs75xx_uart_ie_update(struct uart_port *port, u32 clear, u32 set)
+{
+	u32 ie = readl(port->membase + CS75XX_UART_IE);
+
+	writel((ie & ~clear) | set, port->membase + CS75XX_UART_IE);
+}
+
+static void __maybe_unused cs75xx_uart_putchar(struct uart_port *port,
+					       unsigned char ch)
+{
+	u32 info;
+
+	readl_poll_timeout_atomic(port->membase + CS75XX_UART_INFO, info,
+				  !(info & CS75XX_UART_INFO_TX_FULL), 1,
+				  CS75XX_UART_POLL_TIMEOUT_US);
+	writel(ch, port->membase + CS75XX_UART_TXDAT);
+}
+
+static unsigned int cs75xx_uart_tx_empty(struct uart_port *port)
+{
+	u32 info = readl(port->membase + CS75XX_UART_INFO);
+
+	return (info & CS75XX_UART_INFO_TX_EMPTY) ? TIOCSER_TEMT : 0;
+}
+
+static void cs75xx_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+}
+
+static unsigned int cs75xx_uart_get_mctrl(struct uart_port *port)
+{
+	return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+}
+
+static void cs75xx_uart_stop_tx(struct uart_port *port)
+{
+	cs75xx_uart_ie_update(port, CS75XX_UART_IRQ_TX_EMPTY, 0);
+}
+
+static void cs75xx_uart_tx_chars(struct uart_port *port)
+{
+	u8 ch;
+
+	uart_port_tx(port, ch,
+		     !(readl(port->membase + CS75XX_UART_INFO) &
+		       CS75XX_UART_INFO_TX_FULL),
+		     writel(ch, port->membase + CS75XX_UART_TXDAT));
+}
+
+static void cs75xx_uart_start_tx(struct uart_port *port)
+{
+	cs75xx_uart_ie_update(port, 0, CS75XX_UART_IRQ_TX_EMPTY);
+
+	/*
+	 * The TX empty interrupt only fires when the FIFO drains, so prime
+	 * the FIFO here.
+	 */
+	cs75xx_uart_tx_chars(port);
+}
+
+static void cs75xx_uart_stop_rx(struct uart_port *port)
+{
+	cs75xx_uart_ie_update(port, CS75XX_UART_IRQ_RX_NONEMPTY, 0);
+}
+
+static void cs75xx_uart_break_ctl(struct uart_port *port, int break_state)
+{
+}
+
+static void cs75xx_uart_rx_chars(struct uart_port *port, u32 status)
+{
+	struct tty_port *tport = &port->state->port;
+	u32 data;
+
+	if (status & CS75XX_UART_IRQ_RX_OVERRUN) {
+		port->icount.overrun++;
+		tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+	}
+	if (status & CS75XX_UART_IRQ_RX_PARITY)
+		port->icount.parity++;
+	if (status & CS75XX_UART_IRQ_RX_STOP)
+		port->icount.frame++;
+
+	while (!(readl(port->membase + CS75XX_UART_INFO) &
+		 CS75XX_UART_INFO_RX_EMPTY)) {
+		u8 ch;
+
+		data = readl(port->membase + CS75XX_UART_RXDAT);
+		if (!(data & CS75XX_UART_RXDAT_VALID))
+			continue;
+
+		port->icount.rx++;
+		ch = FIELD_GET(CS75XX_UART_RXDAT_DATA, data);
+
+		if (port->ignore_status_mask & CS75XX_UART_RXDAT_VALID)
+			continue;
+		if (uart_prepare_sysrq_char(port, ch))
+			continue;
+
+		tty_insert_flip_char(tport, ch, TTY_NORMAL);
+	}
+
+	tty_flip_buffer_push(tport);
+}
+
+static irqreturn_t cs75xx_uart_isr(int irq, void *dev_id)
+{
+	struct uart_port *port = dev_id;
+	u32 status;
+
+	uart_port_lock(port);
+
+	status = readl(port->membase + CS75XX_UART_INT);
+	writel(status, port->membase + CS75XX_UART_INT);
+
+	cs75xx_uart_rx_chars(port, status);
+	cs75xx_uart_tx_chars(port);
+
+	uart_unlock_and_check_sysrq(port);
+
+	return IRQ_HANDLED;
+}
+
+static int cs75xx_uart_startup(struct uart_port *port)
+{
+	unsigned long flags;
+	u32 cfg;
+	int ret;
+
+	writel(0, port->membase + CS75XX_UART_IE);
+	writel(CS75XX_UART_IRQ_ALL, port->membase + CS75XX_UART_INT);
+
+	ret = request_irq(port->irq, cs75xx_uart_isr, 0, dev_name(port->dev),
+			  port);
+	if (ret)
+		return ret;
+
+	uart_port_lock_irqsave(port, &flags);
+
+	cfg = readl(port->membase + CS75XX_UART_CFG);
+	cfg |= CS75XX_UART_CFG_EN | CS75XX_UART_CFG_RX_EN | CS75XX_UART_CFG_TX_EN;
+	writel(cfg, port->membase + CS75XX_UART_CFG);
+
+	writel(CS75XX_UART_IRQ_RX_NONEMPTY, port->membase + CS75XX_UART_IE);
+
+	uart_port_unlock_irqrestore(port, flags);
+
+	return 0;
+}
+
+static void cs75xx_uart_shutdown(struct uart_port *port)
+{
+	unsigned long flags;
+
+	uart_port_lock_irqsave(port, &flags);
+	writel(0, port->membase + CS75XX_UART_IE);
+	uart_port_unlock_irqrestore(port, flags);
+
+	free_irq(port->irq, port);
+}
+
+static void cs75xx_uart_set_termios(struct uart_port *port,
+				    struct ktermios *termios,
+				    const struct ktermios *old)
+{
+	unsigned int baud, div;
+	unsigned long flags;
+	u32 cfg;
+
+	/* No hardware flow control or mark/space parity support */
+	termios->c_cflag &= ~(CRTSCTS | CMSPAR);
+
+	baud = uart_get_baud_rate(port, termios, old,
+				  DIV_ROUND_UP(port->uartclk, CS75XX_UART_DIV_MAX),
+				  port->uartclk / CS75XX_UART_DIV_MIN);
+	div = DIV_ROUND_CLOSEST(port->uartclk, baud);
+
+	cfg = FIELD_PREP(CS75XX_UART_CFG_BAUD, div) | CS75XX_UART_CFG_EN |
+	      CS75XX_UART_CFG_RX_EN | CS75XX_UART_CFG_TX_EN;
+	cfg |= FIELD_PREP(CS75XX_UART_CFG_CHAR,
+			  tty_get_char_size(termios->c_cflag) - 5);
+	if (termios->c_cflag & CSTOPB)
+		cfg |= CS75XX_UART_CFG_STOP_2BIT;
+	if (termios->c_cflag & PARENB) {
+		cfg |= CS75XX_UART_CFG_PARITY_EN;
+		if (!(termios->c_cflag & PARODD))
+			cfg |= CS75XX_UART_CFG_PARITY_EVEN;
+	}
+
+	uart_port_lock_irqsave(port, &flags);
+
+	port->ignore_status_mask = 0;
+	if (!(termios->c_cflag & CREAD))
+		port->ignore_status_mask |= CS75XX_UART_RXDAT_VALID;
+
+	uart_update_timeout(port, termios->c_cflag, baud);
+
+	writel(cfg, port->membase + CS75XX_UART_CFG);
+	/* Sample the received bits in the middle of the bit time */
+	writel(div / 2, port->membase + CS75XX_UART_RX_SAMPLE);
+
+	uart_port_unlock_irqrestore(port, flags);
+
+	if (tty_termios_baud_rate(termios))
+		tty_termios_encode_baud_rate(termios, baud, baud);
+}
+
+static const char *cs75xx_uart_type(struct uart_port *port)
+{
+	return port->type == PORT_GENERIC ? "CS75XX" : NULL;
+}
+
+static void cs75xx_uart_release_port(struct uart_port *port)
+{
+}
+
+static int cs75xx_uart_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+static void cs75xx_uart_config_port(struct uart_port *port, int flags)
+{
+	if (flags & UART_CONFIG_TYPE)
+		port->type = PORT_GENERIC;
+}
+
+static int cs75xx_uart_verify_port(struct uart_port *port,
+				   struct serial_struct *serinfo)
+{
+	if (serinfo->type != PORT_UNKNOWN && serinfo->type != PORT_GENERIC)
+		return -EINVAL;
+	if (serinfo->irq != port->irq)
+		return -EINVAL;
+
+	return 0;
+}
+
+#ifdef CONFIG_CONSOLE_POLL
+static int cs75xx_uart_poll_get_char(struct uart_port *port)
+{
+	if (readl(port->membase + CS75XX_UART_INFO) & CS75XX_UART_INFO_RX_EMPTY)
+		return NO_POLL_CHAR;
+
+	return FIELD_GET(CS75XX_UART_RXDAT_DATA,
+			 readl(port->membase + CS75XX_UART_RXDAT));
+}
+
+static void cs75xx_uart_poll_put_char(struct uart_port *port, unsigned char c)
+{
+	cs75xx_uart_putchar(port, c);
+}
+#endif
+
+static const struct uart_ops cs75xx_uart_ops = {
+	.tx_empty	= cs75xx_uart_tx_empty,
+	.set_mctrl	= cs75xx_uart_set_mctrl,
+	.get_mctrl	= cs75xx_uart_get_mctrl,
+	.stop_tx	= cs75xx_uart_stop_tx,
+	.start_tx	= cs75xx_uart_start_tx,
+	.stop_rx	= cs75xx_uart_stop_rx,
+	.break_ctl	= cs75xx_uart_break_ctl,
+	.startup	= cs75xx_uart_startup,
+	.shutdown	= cs75xx_uart_shutdown,
+	.set_termios	= cs75xx_uart_set_termios,
+	.type		= cs75xx_uart_type,
+	.release_port	= cs75xx_uart_release_port,
+	.request_port	= cs75xx_uart_request_port,
+	.config_port	= cs75xx_uart_config_port,
+	.verify_port	= cs75xx_uart_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+	.poll_get_char	= cs75xx_uart_poll_get_char,
+	.poll_put_char	= cs75xx_uart_poll_put_char,
+#endif
+};
+
+#ifdef CONFIG_SERIAL_CS75XX_CONSOLE
+static void cs75xx_uart_console_write(struct console *co, const char *s,
+				      unsigned int count)
+{
+	struct uart_port *port = &cs75xx_uart_ports[co->index]->port;
+	unsigned long flags;
+	bool locked = true;
+	u32 ie, info;
+
+	if (oops_in_progress)
+		locked = uart_port_trylock_irqsave(port, &flags);
+	else
+		uart_port_lock_irqsave(port, &flags);
+
+	ie = readl(port->membase + CS75XX_UART_IE);
+	writel(ie & ~CS75XX_UART_IRQ_TX_EMPTY, port->membase + CS75XX_UART_IE);
+
+	uart_console_write(port, s, count, cs75xx_uart_putchar);
+
+	readl_poll_timeout_atomic(port->membase + CS75XX_UART_INFO, info,
+				  info & CS75XX_UART_INFO_TX_EMPTY, 1,
+				  CS75XX_UART_POLL_TIMEOUT_US);
+	writel(ie, port->membase + CS75XX_UART_IE);
+
+	if (locked)
+		uart_port_unlock_irqrestore(port, flags);
+}
+
+static int __init cs75xx_uart_console_setup(struct console *co, char *options)
+{
+	struct cs75xx_uart_port *up;
+	int baud = 115200;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index < 0 || co->index >= CS75XX_UART_NR_PORTS)
+		return -ENODEV;
+
+	up = cs75xx_uart_ports[co->index];
+	if (!up)
+		return -ENODEV;
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(&up->port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver cs75xx_uart_driver;
+
+static struct console cs75xx_uart_console = {
+	.name	= "ttyCS",
+	.write	= cs75xx_uart_console_write,
+	.device	= uart_console_device,
+	.setup	= cs75xx_uart_console_setup,
+	.flags	= CON_PRINTBUFFER,
+	.index	= -1,
+	.data	= &cs75xx_uart_driver,
+};
+
+static void cs75xx_uart_earlycon_write(struct console *co, const char *s,
+				       unsigned int count)
+{
+	struct earlycon_device *dev = co->data;
+
+	uart_console_write(&dev->port, s, count, cs75xx_uart_putchar);
+}
+
+static int __init cs75xx_uart_earlycon_setup(struct earlycon_device *dev,
+					     const char *options)
+{
+	if (!dev->port.membase)
+		return -ENODEV;
+
+	dev->con->write = cs75xx_uart_earlycon_write;
+
+	return 0;
+}
+
+OF_EARLYCON_DECLARE(cs75xx, "cortina,cs7542-uart", cs75xx_uart_earlycon_setup);
+
+#define CS75XX_UART_CONSOLE	(&cs75xx_uart_console)
+#else
+#define CS75XX_UART_CONSOLE	NULL
+#endif
+
+static struct uart_driver cs75xx_uart_driver = {
+	.owner		= THIS_MODULE,
+	.driver_name	= "cs75xx-uart",
+	.dev_name	= "ttyCS",
+	.nr		= CS75XX_UART_NR_PORTS,
+	.cons		= CS75XX_UART_CONSOLE,
+};
+
+static int cs75xx_uart_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct cs75xx_uart_port *up;
+	struct uart_port *port;
+	struct resource *res;
+	int id, ret;
+
+	id = of_alias_get_id(dev->of_node, "serial");
+	if (id < 0) {
+		for (id = 0; id < CS75XX_UART_NR_PORTS; id++)
+			if (!cs75xx_uart_ports[id])
+				break;
+	}
+	if (id >= CS75XX_UART_NR_PORTS)
+		return dev_err_probe(dev, -EINVAL, "invalid port index %d\n", id);
+	if (cs75xx_uart_ports[id])
+		return dev_err_probe(dev, -EBUSY, "port %d already in use\n", id);
+
+	up = devm_kzalloc(dev, sizeof(*up), GFP_KERNEL);
+	if (!up)
+		return -ENOMEM;
+
+	port = &up->port;
+
+	port->membase = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
+	if (IS_ERR(port->membase))
+		return PTR_ERR(port->membase);
+
+	port->irq = platform_get_irq(pdev, 0);
+	if (port->irq < 0)
+		return port->irq;
+
+	up->clk = devm_clk_get_enabled(dev, NULL);
+	if (IS_ERR(up->clk))
+		return dev_err_probe(dev, PTR_ERR(up->clk), "failed to get clock\n");
+
+	port->uartclk = clk_get_rate(up->clk);
+	if (!port->uartclk)
+		return dev_err_probe(dev, -EINVAL, "clock rate is zero\n");
+
+	port->dev = dev;
+	port->mapbase = res->start;
+	port->mapsize = resource_size(res);
+	port->iotype = UPIO_MEM32;
+	port->ops = &cs75xx_uart_ops;
+	port->line = id;
+	port->fifosize = CS75XX_UART_FIFO_SIZE;
+	port->flags = UPF_BOOT_AUTOCONF;
+	port->has_sysrq = IS_ENABLED(CONFIG_SERIAL_CS75XX_CONSOLE);
+
+	cs75xx_uart_ports[id] = up;
+	platform_set_drvdata(pdev, up);
+
+	ret = uart_add_one_port(&cs75xx_uart_driver, port);
+	if (ret) {
+		cs75xx_uart_ports[id] = NULL;
+		return ret;
+	}
+
+	return 0;
+}
+
+static void cs75xx_uart_remove(struct platform_device *pdev)
+{
+	struct cs75xx_uart_port *up = platform_get_drvdata(pdev);
+
+	uart_remove_one_port(&cs75xx_uart_driver, &up->port);
+	cs75xx_uart_ports[up->port.line] = NULL;
+}
+
+static const struct of_device_id cs75xx_uart_of_match[] = {
+	{ .compatible = "cortina,cs7542-uart" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, cs75xx_uart_of_match);
+
+static struct platform_driver cs75xx_uart_platform_driver = {
+	.probe	= cs75xx_uart_probe,
+	.remove	= cs75xx_uart_remove,
+	.driver	= {
+		.name		= "cs75xx-uart",
+		.of_match_table	= cs75xx_uart_of_match,
+	},
+};
+
+static int __init cs75xx_uart_init(void)
+{
+	int ret;
+
+	ret = uart_register_driver(&cs75xx_uart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&cs75xx_uart_platform_driver);
+	if (ret)
+		uart_unregister_driver(&cs75xx_uart_driver);
+
+	return ret;
+}
+module_init(cs75xx_uart_init);
+
+static void __exit cs75xx_uart_exit(void)
+{
+	platform_driver_unregister(&cs75xx_uart_platform_driver);
+	uart_unregister_driver(&cs75xx_uart_driver);
+}
+module_exit(cs75xx_uart_exit);
+
+MODULE_DESCRIPTION("Cortina Systems CS75xx UART driver");
+MODULE_LICENSE("GPL");

-- 
2.53.0

Re: [PATCH RFC 07/10] tty: serial: Add Cortina Systems CS75xx UART driver

[Greg Kroah-Hartman]

On Wed, Sep 30, 2026 at 10:00:06AM +0300, Fil Dunsky via B4 Relay wrote:
> From: Fil Dunsky <filipp.dunsky@gmail.com>
> 
> Add a driver for the UARTs of the Cortina Systems CS75xx (Goldengate G2)
> SoCs. The block has transmit and receive FIFOs with full/empty status,
> a 24-bit baud rate divider clocked from the peripheral (APB) clock, a
> receive sampling point register and one interrupt line per port with
> per-cause enable and write-one-to-clear status registers.
> 
> The driver is a rewrite of the vendor driver shipped with the Linux
> 2.6.36 and 4.9 based vendor kernels, using the current serial core API
> (uart_port_tx(), port lock helpers, deferred sysrq handling) and devm
> resource management. It supports the system console and earlycon.
> Hardware flow control is not supported.
> 
> The ports are named ttyCS so that the driver can coexist with the 8250
> driver in multiplatform kernels, and PORT_GENERIC is used rather than
> allocating a new port type.

But even if you build a multi-platform kernel, only one of the uarts is
going to be on the system, so why have a new name for it?  Can't you
just use the "default" name instead?  If you do that, what happens?


> 
> Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
> ---
>  drivers/tty/serial/Kconfig       |  24 ++
>  drivers/tty/serial/Makefile      |   1 +
>  drivers/tty/serial/cs75xx-uart.c | 546 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 571 insertions(+)
> 
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index bf680d22199..c4239c42190 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1359,6 +1359,30 @@ config SERIAL_CONEXANT_DIGICOLOR_CONSOLE
>  	  If you have enabled the USART serial port on Conexant Digicolor
>  	  SoCs, you can make it the console by answering Y to this option.
>  
> +config SERIAL_CS75XX
> +	tristate "Cortina Systems CS75xx UART support"
> +	depends on ARCH_CORTINA_CS75XX || COMPILE_TEST
> +	depends on OF
> +	select SERIAL_CORE
> +	help
> +	  Support for the on-chip UARTs of the Cortina Systems CS75xx
> +	  (Goldengate G2) SoCs, such as the CS7542. The ports are named
> +	  ttyCS0 to ttyCS3.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called cs75xx-uart.
> +
> +config SERIAL_CS75XX_CONSOLE
> +	bool "Console on Cortina Systems CS75xx UART"
> +	depends on SERIAL_CS75XX=y
> +	select SERIAL_CORE_CONSOLE
> +	select SERIAL_EARLYCON
> +	help
> +	  Say Y here to use a Cortina Systems CS75xx UART as the system
> +	  console. This also enables the early console, which can be
> +	  selected with "earlycon" on the kernel command line when the
> +	  device tree chosen node has a stdout-path pointing at the UART.
> +
>  config SERIAL_ST_ASC
>  	tristate "ST ASC serial port support"
>  	select SERIAL_CORE
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index bba7b21a4a1..81bb5e39aa2 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_SERIAL_BCM63XX)		+= bcm63xx_uart.o
>  obj-$(CONFIG_SERIAL_CLPS711X)		+= clps711x.o
>  obj-$(CONFIG_SERIAL_CPM)		+= cpm_uart.o
>  obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
> +obj-$(CONFIG_SERIAL_CS75XX)		+= cs75xx-uart.o
>  obj-$(CONFIG_SERIAL_DZ)			+= dz.o
>  obj-$(CONFIG_SERIAL_FSL_LINFLEXUART)	+= fsl_linflexuart.o
>  obj-$(CONFIG_SERIAL_FSL_LPUART)		+= fsl_lpuart.o
> diff --git a/drivers/tty/serial/cs75xx-uart.c b/drivers/tty/serial/cs75xx-uart.c
> new file mode 100644
> index 00000000000..c15e2227b97
> --- /dev/null
> +++ b/drivers/tty/serial/cs75xx-uart.c
> @@ -0,0 +1,546 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * UART driver for the Cortina Systems CS75xx (Goldengate G2) SoCs
> + *
> + * Based on the Cortina Systems vendor driver.
> + */

No copyright info?

> +static void cs75xx_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> +}

Why an empty function?  Can't you just leave it out?

> +static void cs75xx_uart_break_ctl(struct uart_port *port, int break_state)
> +{
> +}

Same here.

> +static void cs75xx_uart_release_port(struct uart_port *port)
> +{
> +}

This feels wrong.

> +static int cs75xx_uart_request_port(struct uart_port *port)
> +{
> +	return 0;
> +}

As does this.

thanks,

greg k-h

Re: [PATCH RFC 07/10] tty: serial: Add Cortina Systems CS75xx UART driver

[Fil Dunsky]

On Wed, Sep 30, 2026 at 09:14:34AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Sep 30, 2026 at 10:00:06AM +0300, Fil Dunsky via B4 Relay wrote:
> > The ports are named ttyCS so that the driver can coexist with the 8250
> > driver in multiplatform kernels, and PORT_GENERIC is used rather than
> > allocating a new port type.
>
> But even if you build a multi-platform kernel, only one of the uarts is
> going to be on the system, so why have a new name for it?  Can't you
> just use the "default" name instead?  If you do that, what happens?

I tried it on the board: multi_v7_defconfig with the driver renamed to
ttyS. The 8250 driver registers its runtime ports (ttyS0..ttyS4) even
though there is no 8250 on this SoC, so the probe fails:

  sysfs: cannot create duplicate filename '/class/tty/ttyS0'
  ...
  cs75xx-uart f0070110.serial: Cannot register tty device on line 0
  Warning: unable to open an initial console.

That is why I went with a separate name, like ttyAMA or ttymxc. If
there is a better way to share ttyS with 8250 I am happy to change it.

> > +/*
> > + * UART driver for the Cortina Systems CS75xx (Goldengate G2) SoCs
> > + *
> > + * Based on the Cortina Systems vendor driver.
> > + */
>
> No copyright info?

The vendor file (serial_cortina.c) carries no copyright notice, only the
GPL-2.0 statement and MODULE_AUTHOR("Cortina-Systems"). I will add mine
and name the vendor file as the origin in v2.

> > +static void cs75xx_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
> > +{
> > +}
>
> Why an empty function?  Can't you just leave it out?

The block has no modem control lines. serial_core calls ->set_mctrl()
without a NULL check (uart_update_mctrl() and others), so it has to
exist. I will add a comment saying so.

> > +static void cs75xx_uart_break_ctl(struct uart_port *port, int break_state)
> > +{
> > +}
>
> Same here.

That one is optional, I will drop it.

> > +static void cs75xx_uart_release_port(struct uart_port *port)
> > +{
> > +}
>
> This feels wrong.
>
> > +static int cs75xx_uart_request_port(struct uart_port *port)
> > +{
> > +     return 0;
> > +}
>
> As does this.

Both are optional and the resources are managed in probe, so I will
drop them in v2.

Thanks for the review,
Fil

Re: [PATCH RFC 07/10] tty: serial: Add Cortina Systems CS75xx UART driver

[Linus Walleij]

Hi Filipp,

thanks for your patch!

On Wed, Sep 30, 2026 at 9:00 AM Fil Dunsky via B4 Relay
<devnull+filipp.dunsky.gmail.com@kernel.org> wrote:

> From: Fil Dunsky <filipp.dunsky@gmail.com>
>
> Add a driver for the UARTs of the Cortina Systems CS75xx (Goldengate G2)
> SoCs. The block has transmit and receive FIFOs with full/empty status,
> a 24-bit baud rate divider clocked from the peripheral (APB) clock, a
> receive sampling point register and one interrupt line per port with
> per-cause enable and write-one-to-clear status registers.
>
> The driver is a rewrite of the vendor driver shipped with the Linux
> 2.6.36 and 4.9 based vendor kernels, using the current serial core API
> (uart_port_tx(), port lock helpers, deferred sysrq handling) and devm
> resource management. It supports the system console and earlycon.
> Hardware flow control is not supported.
>
> The ports are named ttyCS so that the driver can coexist with the 8250
> driver in multiplatform kernels, and PORT_GENERIC is used rather than
> allocating a new port type.
>
> Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>

Look at this in your Linux tree:
git log -p b61c8bf4694b5115766849378dcb8787ff54e65e

This is essentially a resurrection of that driver. It was deleted again
because it was merged prematurely. Cortina never came back to revise
the driver. (People run out of steam. Such things happen.)

Anyways, clearly this driver is not just for CS75xx so name it
cortina-uart.c simply, and update symbols accordingly. Kconfig
should be SERIAL_CORTINA etc.

Maybe
even the DT compatible should be something more generic.

Yours,
Linus Walleij

Re: [PATCH RFC 07/10] tty: serial: Add Cortina Systems CS75xx UART driver

[Arnd Bergmann]

On Wed, Sep 30, 2026, at 12:57, Linus Walleij wrote:
> On Wed, Sep 30, 2026 at 9:00 AM Fil Dunsky via B4 Relay
> <devnull+filipp.dunsky.gmail.com@kernel.org> wrote:
>>
>>
>> The ports are named ttyCS so that the driver can coexist with the 8250
>> driver in multiplatform kernels, and PORT_GENERIC is used rather than
>> allocating a new port type.
>>
>> Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
>
> Look at this in your Linux tree:
> git log -p b61c8bf4694b5115766849378dcb8787ff54e65e
>
> This is essentially a resurrection of that driver. It was deleted again
> because it was merged prematurely. Cortina never came back to revise
> the driver. (People run out of steam. Such things happen.)

Jason actually came back this summer to try again, see
https://lore.kernel.org/linux-arm-kernel/20260610112821.3030099-1-jason.li@cortina-access.com/

> Anyways, clearly this driver is not just for CS75xx so name it
> cortina-uart.c simply, and update symbols accordingly. Kconfig
> should be SERIAL_CORTINA etc.

I think we clearly want a driver that works for both the Cortina
Systems CS75xx and the Cortina Access CA82xx, hopefully that
would also support the ones inbetween (CS80xx, CA81xx).

There do seem to be a few minor differences in the register
set, but I would expect that this can be dealt with based on
the compatible string.

   Arnd

Re: [PATCH RFC 07/10] tty: serial: Add Cortina Systems CS75xx UART driver

[Fil Dunsky]

On Wed, Sep 30, 2026 at 01:08:07PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 30, 2026, at 12:57, Linus Walleij wrote:
>> Look at this in your Linux tree:
>> git log -p b61c8bf4694b5115766849378dcb8787ff54e65e
>>
>> This is essentially a resurrection of that driver.
>
> Jason actually came back this summer to try again, see
> https://lore.kernel.org/linux-arm-kernel/20260610112821.3030099-1-jason.li@cortina-access.com/

Thanks, I was not aware of either. Comparing the two, it is the same
IP: the offsets of CFG, RX_SAMPLE, TX_DAT, RX_DAT, INFO, IE and INT
and the bit layout of CFG, INFO and the interrupt registers are
identical. The Cortina Access version additionally has a flow control
register at 0x04, RT_TUNE at 0x0c, STATUS at 0x2c and three more
interrupt causes (break, RX underrun, TX overrun).

>> Anyways, clearly this driver is not just for CS75xx so name it
>> cortina-uart.c simply, and update symbols accordingly. Kconfig
>> should be SERIAL_CORTINA etc.
>
> I think we clearly want a driver that works for both the Cortina
> Systems CS75xx and the Cortina Access CA82xx, hopefully that
> would also support the ones inbetween (CS80xx, CA81xx).

Agreed. For v2 I will rename it to drivers/tty/serial/cortina-uart.c
with SERIAL_CORTINA and SERIAL_CORTINA_CONSOLE, and name the binding
so that it can take the other parts. I would keep SoC specific
compatibles ("cortina,cs7542-uart", later e.g.
"cortina-access,ca8289-uart"), so that the flow control and the extra
interrupt causes can be enabled per compatible.

I can only test on the CS7542. Jason, would you be fine with adding
the CA82xx on top of this driver instead of a separate one? I am happy
to add the compatible and the bits you need if you can test them.

Thanks,
Fil

Re: [PATCH RFC 07/10] tty: serial: Add Cortina Systems CS75xx UART driver

[Arnd Bergmann]

On Wed, Sep 30, 2026, at 13:24, Fil Dunsky wrote:
> On Wed, Sep 30, 2026 at 01:08:07PM +0200, Arnd Bergmann wrote:
>> On Wed, Sep 30, 2026, at 12:57, Linus Walleij wrote:
>>> Look at this in your Linux tree:
>>> git log -p b61c8bf4694b5115766849378dcb8787ff54e65e
>>>
>>> This is essentially a resurrection of that driver.
>>
>> Jason actually came back this summer to try again, see
>> https://lore.kernel.org/linux-arm-kernel/20260610112821.3030099-1-jason.li@cortina-access.com/
>
> Thanks, I was not aware of either. Comparing the two, it is the same
> IP: the offsets of CFG, RX_SAMPLE, TX_DAT, RX_DAT, INFO, IE and INT
> and the bit layout of CFG, INFO and the interrupt registers are
> identical. The Cortina Access version additionally has a flow control
> register at 0x04, RT_TUNE at 0x0c, STATUS at 0x2c and three more
> interrupt causes (break, RX underrun, TX overrun).

Ok, thanks for checking.

>>> Anyways, clearly this driver is not just for CS75xx so name it
>>> cortina-uart.c simply, and update symbols accordingly. Kconfig
>>> should be SERIAL_CORTINA etc.
>>
>> I think we clearly want a driver that works for both the Cortina
>> Systems CS75xx and the Cortina Access CA82xx, hopefully that
>> would also support the ones inbetween (CS80xx, CA81xx).
>
> Agreed. For v2 I will rename it to drivers/tty/serial/cortina-uart.c
> with SERIAL_CORTINA and SERIAL_CORTINA_CONSOLE, and name the binding
> so that it can take the other parts. I would keep SoC specific
> compatibles ("cortina,cs7542-uart", later e.g.
> "cortina-access,ca8289-uart"), so that the flow control and the extra
> interrupt causes can be enabled per compatible.

Sounds good. The important bit here is to ensure the structure can
work with both variants.

    Arnd

[PATCH RFC 08/10] ARM: dts: cortina: Add CS7542 SoC and Securifi Almond+ board

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

Add a minimal description of the Cortina Systems CS7542 SoC: the two
Cortex-A9 cores, SCU, GIC, global timer, private timer and watchdog,
PL310 L2 cache controller and the four on-chip UARTs.

The peripheral clock (APB) runs at 100, 150 or 170 MHz depending on the
boot strap pins. Until there is a driver for the global control block
that reads the straps, model it as a fixed clock whose rate is provided
by the board.

The Securifi Almond+ is a touchscreen Wi-Fi router with 512 MiB of DDR3,
512 MiB of NAND flash, a QCA8337 switch, QCA9880 and AR9580 Wi-Fi and an
ASM1042 USB 3.0 controller behind the SoC PCIe root ports. For now,
describe the memory, the console UART and a ramoops region, and reserve
the top 64 MiB of RAM which the vendor firmware hands to the packet
engine queue manager.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/cortina/Makefile                 |   3 +
 .../dts/cortina/cs7542-securifi-almondplus.dts     |  55 +++++++++
 arch/arm/boot/dts/cortina/cs7542.dtsi              | 127 +++++++++++++++++++++
 4 files changed, 186 insertions(+)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 28fba538d55..cf4433001dd 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -12,6 +12,7 @@ subdir-y += broadcom
 subdir-y += calxeda
 subdir-y += cirrus
 subdir-y += cnxt
+subdir-y += cortina
 subdir-y += gemini
 subdir-y += hisilicon
 subdir-y += hpe
diff --git a/arch/arm/boot/dts/cortina/Makefile b/arch/arm/boot/dts/cortina/Makefile
new file mode 100644
index 00000000000..42ca2f511cc
--- /dev/null
+++ b/arch/arm/boot/dts/cortina/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_CORTINA_CS75XX) += \
+	cs7542-securifi-almondplus.dtb
diff --git a/arch/arm/boot/dts/cortina/cs7542-securifi-almondplus.dts b/arch/arm/boot/dts/cortina/cs7542-securifi-almondplus.dts
new file mode 100644
index 00000000000..e2988c68765
--- /dev/null
+++ b/arch/arm/boot/dts/cortina/cs7542-securifi-almondplus.dts
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Device Tree Source for the Securifi Almond+ router
+ */
+
+/dts-v1/;
+
+#include "cs7542.dtsi"
+
+/ {
+	model = "Securifi Almond+";
+	compatible = "securifi,almondplus", "cortina,cs7542";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x00000000 0x20000000>;
+	};
+
+	reserved-memory {
+		ranges;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		ramoops@1bf00000 {
+			compatible = "ramoops";
+			reg = <0x1bf00000 0x100000>;
+			record-size = <0x20000>;
+			console-size = <0x80000>;
+			ecc-size = <16>;
+			no-map;
+		};
+
+		/* Reserved for the packet engine queue manager */
+		qm-buffer@1c000000 {
+			reg = <0x1c000000 0x4000000>;
+			no-map;
+		};
+	};
+};
+
+&apb_clk {
+	clock-frequency = <150000000>;
+};
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/cortina/cs7542.dtsi b/arch/arm/boot/dts/cortina/cs7542.dtsi
new file mode 100644
index 00000000000..29b0b7da866
--- /dev/null
+++ b/arch/arm/boot/dts/cortina/cs7542.dtsi
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Device Tree Source for the Cortina Systems CS7542 SoC
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	interrupt-parent = <&gic>;
+
+	/* Rate is selected by the boot strap pins, set by the board */
+	apb_clk: clock-apb {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-output-names = "apb";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+			next-level-cache = <&l2>;
+		};
+
+		cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <1>;
+			enable-method = "cortina,cs7542-smp";
+			cpu-release-addr = <0 0xf00000b8>;
+			next-level-cache = <&l2>;
+		};
+	};
+
+	soc {
+		compatible = "simple-bus";
+		ranges;
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		uart0: serial@f0070110 {
+			compatible = "cortina,cs7542-uart";
+			reg = <0xf0070110 0x30>;
+			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&apb_clk>;
+
+			status = "disabled";
+		};
+
+		uart1: serial@f0070140 {
+			compatible = "cortina,cs7542-uart";
+			reg = <0xf0070140 0x30>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&apb_clk>;
+
+			status = "disabled";
+		};
+
+		uart2: serial@f0070170 {
+			compatible = "cortina,cs7542-uart";
+			reg = <0xf0070170 0x30>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&apb_clk>;
+
+			status = "disabled";
+		};
+
+		uart3: serial@f00701a0 {
+			compatible = "cortina,cs7542-uart";
+			reg = <0xf00701a0 0x30>;
+			interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&apb_clk>;
+
+			status = "disabled";
+		};
+
+		l2: cache-controller@f5010000 {
+			compatible = "arm,pl310-cache";
+			reg = <0xf5010000 0x1000>;
+			cache-unified;
+			cache-level = <2>;
+			arm,shared-override;
+			arm,tag-latency = <1 1 1>;
+			arm,data-latency = <1 1 2>;
+		};
+
+		scu@f8000000 {
+			compatible = "arm,cortex-a9-scu";
+			reg = <0xf8000000 0x100>;
+		};
+
+		timer@f8000200 {
+			compatible = "arm,cortex-a9-global-timer";
+			reg = <0xf8000200 0x20>;
+			interrupts = <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>;
+			clocks = <&apb_clk>;
+		};
+
+		timer@f8000600 {
+			compatible = "arm,cortex-a9-twd-timer";
+			reg = <0xf8000600 0x20>;
+			interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>;
+			clocks = <&apb_clk>;
+		};
+
+		watchdog@f8000620 {
+			compatible = "arm,cortex-a9-twd-wdt";
+			reg = <0xf8000620 0x20>;
+			interrupts = <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>;
+			clocks = <&apb_clk>;
+		};
+
+		gic: interrupt-controller@f8001000 {
+			compatible = "arm,cortex-a9-gic";
+			reg = <0xf8001000 0x1000>,
+			      <0xf8000100 0x100>;
+			#interrupt-cells = <3>;
+			interrupt-controller;
+		};
+	};
+};

-- 
2.53.0

[PATCH RFC 09/10] ARM: multi_v7_defconfig: Enable Cortina Systems CS75xx support

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

Enable the Cortina Systems CS75xx platform and its UART driver with
console support, as used on the Securifi Almond+ router.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 arch/arm/configs/multi_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 069d5a49f01..5f0b10b1f18 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -43,6 +43,7 @@ CONFIG_ARCH_BERLIN=y
 CONFIG_MACH_BERLIN_BG2=y
 CONFIG_MACH_BERLIN_BG2CD=y
 CONFIG_MACH_BERLIN_BG2Q=y
+CONFIG_ARCH_CORTINA_CS75XX=y
 CONFIG_ARCH_DIGICOLOR=y
 CONFIG_ARCH_EXYNOS=y
 CONFIG_ARCH_HIGHBANK=y
@@ -396,6 +397,8 @@ CONFIG_SERIAL_FSL_LPUART=y
 CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
 CONFIG_SERIAL_CONEXANT_DIGICOLOR=y
 CONFIG_SERIAL_CONEXANT_DIGICOLOR_CONSOLE=y
+CONFIG_SERIAL_CS75XX=y
+CONFIG_SERIAL_CS75XX_CONSOLE=y
 CONFIG_SERIAL_ST_ASC=y
 CONFIG_SERIAL_ST_ASC_CONSOLE=y
 CONFIG_SERIAL_STM32=y

-- 
2.53.0

[PATCH RFC 10/10] MAINTAINERS: Add entry for Cortina Systems CS75xx

[Fil Dunsky via B4 Relay]

From: Fil Dunsky <filipp.dunsky@gmail.com>

Add an entry covering the Cortina Systems CS75xx platform code, device
trees, bindings and UART driver.

Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
---
 MAINTAINERS | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2d137a33994..7ef9de36ffc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2914,6 +2914,17 @@ F:	tools/perf/tests/shell/coresight/*
 F:	tools/perf/util/cs-etm-decoder/*
 F:	tools/perf/util/cs-etm.*
 
+ARM/CORTINA SYSTEMS CS75XX ARM ARCHITECTURE
+M:	Fil Dunsky <filipp.dunsky@gmail.com>
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+F:	Documentation/devicetree/bindings/arm/cortina.yaml
+F:	Documentation/devicetree/bindings/serial/cortina,cs7542-uart.yaml
+F:	arch/arm/boot/dts/cortina/
+F:	arch/arm/include/debug/cs75xx.S
+F:	arch/arm/mach-cortina/
+F:	drivers/tty/serial/cs75xx-uart.c
+
 ARM/CORTINA SYSTEMS GEMINI ARM ARCHITECTURE
 M:	Hans Ulli Kroll <ulli.kroll@googlemail.com>
 M:	Linus Walleij <linusw@kernel.org>

-- 
2.53.0

Re: [PATCH RFC 00/10] ARM: Add support for Cortina Systems CS75xx and Securifi Almond+

[Linus Walleij]

Hi Filipp,

On Wed, Sep 30, 2026 at 9:00 AM Fil Dunsky via B4 Relay
<devnull+filipp.dunsky.gmail.com@kernel.org> wrote:

> There is no public documentation for the SoC. The register information
> comes from the GPL vendor kernels (Linux 2.6.36 for the Almond+, Linux
> 4.9 for the Verizon FiOS G1100 which uses the same SoC) and from
> disassembly of the stock U-Boot 2009.11. A full out-of-tree port
> (clock, irqchip, GPIO, I2C, RTC, NAND, PCIe, MDIO and the packet engine)
> runs on Linux 6.18 in OpenWrt

Is this OpenWrt fork public?

Actually what I'm most curious about is the packet engine, which may or
may not be related to drivers/net/ethernet/cortina/*

On the Gemini that was the only part of the SoC that was actually made
by StorLink (later acquired by Cortina) while the rest of Gemini was
Faraday IP blocks.

Yours,
Linus Walleij

Re: [PATCH RFC 00/10] ARM: Add support for Cortina Systems CS75xx and Securifi Almond+

[Fil Dunsky]

On Wed, Sep 30, 2026 at 12:39 PM Linus Walleij <linusw@kernel.org> wrote:
> Is this OpenWrt fork public?

Yes, it is under review in OpenWrt:
https://github.com/openwrt/openwrt/pull/25033
The sources are in target/linux/cortina/files/, the Ethernet part in
drivers/net/ethernet/cortina/cs752x_ne.c (plus cs752x_fe.c,
cs752x_sch_tm.c and drivers/net/mdio/mdio-cs75xx.c).

> Actually what I'm most curious about is the packet engine, which may or
> may not be related to drivers/net/ethernet/cortina/*

As far as I can tell it is not derived from the Gemini GMAC/TOE: the
vendor driver has no StorLink or Gemini references, and the engine is
split into a network interface (NI) with per-port MACs, a DMA/LSO
block, a queue manager with its buffers in the top 64 MiB of DRAM, a
traffic manager/scheduler and a forwarding engine with packet buffers
in on-chip XRAM, which does not map onto the gemini.c register layout.
I have not compared the descriptor formats in detail though. The
OpenWrt driver only uses the NI/DMA path, all forwarding in software.

Thanks,
Fil

Re: [PATCH RFC 00/10] ARM: Add support for Cortina Systems CS75xx and Securifi Almond+

[Linus Walleij]

On Wed, Sep 30, 2026 at 12:57 PM Fil Dunsky <filipp.dunsky@gmail.com> wrote:
> On Wed, Sep 30, 2026 at 12:39 PM Linus Walleij <linusw@kernel.org> wrote:

> > Is this OpenWrt fork public?
>
> Yes, it is under review in OpenWrt:
> https://github.com/openwrt/openwrt/pull/25033
> The sources are in target/linux/cortina/files/, the Ethernet part in
> drivers/net/ethernet/cortina/cs752x_ne.c (plus cs752x_fe.c,
> cs752x_sch_tm.c and drivers/net/mdio/mdio-cs75xx.c).
>
> > Actually what I'm most curious about is the packet engine, which may or
> > may not be related to drivers/net/ethernet/cortina/*
>
> As far as I can tell it is not derived from the Gemini GMAC/TOE: the
> vendor driver has no StorLink or Gemini references, and the engine is
> split into a network interface (NI) with per-port MACs, a DMA/LSO
> block, a queue manager with its buffers in the top 64 MiB of DRAM, a
> traffic manager/scheduler and a forwarding engine with packet buffers
> in on-chip XRAM, which does not map onto the gemini.c register layout.
> I have not compared the descriptor formats in detail though. The
> OpenWrt driver only uses the NI/DMA path, all forwarding in software.

OK once this is merged post the network engine under
drivers/net/ethernet/cortina/* and I will help out to review it and
get it merged.

I agree it's a good idea to merge this upstream first to offburden
OpenWrt, that was the approach taken for Gemini and IXP4xx
and those are extremely lightweight for OpenWrt to maintain
since then.

Yours,
Linus Walleij