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

From: Linus Walleij

Date: Wed Sep 30 2026 - 06:16:35 EST


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

> From: Fil Dunsky <filipp.dunsky@xxxxxxxxx>
>
> 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@xxxxxxxxx>

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