[PATCH AUTOSEL 6.17-6.12] soc: sunxi: sram: add entry for a523

[Sasha Levin]

From: Chen-Yu Tsai <wens at csie.org>

[ Upstream commit 30849ab484f7397c9902082c7567ca4cd4eb03d3 ]

The A523 has two Ethernet controllers. So in the system controller
address space, there are two registers for Ethernet clock delays,
one for each controller.

Add a new entry for the A523 system controller that allows access to
the second register.

Acked-by: Jernej Skrabec <jernej.skrabec at gmail.com>
Link: https://patch.msgid.link/20250908181059.1785605-4-wens@kernel.org
Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES – this should go to stable; without it the second GMAC on A523
cannot program its clock-delay register.

- The A523 DT already instantiates the system-control syscon with an
  A523-specific compatible and wires GMAC0 (with GMAC1 expected next) to
  that syscon (`arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi:423` and
  `arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi:543`). Because the
  current driver falls back to the A64 variant,
  `sunxi_sram_regmap_accessible_reg()` only exposes a single EMAC clock
  register (`drivers/soc/sunxi/sunxi_sram.c:325`), so any attempt to use
  the second EMAC clock register at 0x34 is blocked, which makes the
  second Ethernet controller unusable on this SoC.
- The patch adds a dedicated A523 variant with `.num_emac_clocks = 2`
  and wires it into the OF match table
  (`drivers/soc/sunxi/sunxi_sram.c:313` and
  `drivers/soc/sunxi/sunxi_sram.c:438` after the change). This is the
  minimal change required to expose the second register; no other SoCs
  are affected and no behaviour changes for existing users.
- Risk is very low: the change only enlarges the allowed register window
  for the A523 system controller and mirrors the existing H616 handling.
  Without it, backporting forthcoming GMAC1 enablement (or any
  downstream board DT that already uses it) will continue to fail, so
  carrying this fix in stable keeps A523 Ethernet support from
  regressing.

Next step if you pick it up: merge alongside the GMAC1 enablement so the
second port works end-to-end.

 drivers/soc/sunxi/sunxi_sram.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c
index 2781a091a6a64..16144a0a0d371 100644
--- a/drivers/soc/sunxi/sunxi_sram.c
+++ b/drivers/soc/sunxi/sunxi_sram.c
@@ -310,6 +310,10 @@ static const struct sunxi_sramc_variant sun50i_h616_sramc_variant = {
 	.has_ths_offset = true,
 };
 
+static const struct sunxi_sramc_variant sun55i_a523_sramc_variant = {
+	.num_emac_clocks = 2,
+};
+
 #define SUNXI_SRAM_THS_OFFSET_REG	0x0
 #define SUNXI_SRAM_EMAC_CLOCK_REG	0x30
 #define SUNXI_SYS_LDO_CTRL_REG		0x150
@@ -430,6 +434,10 @@ static const struct of_device_id sunxi_sram_dt_match[] = {
 		.compatible = "allwinner,sun50i-h616-system-control",
 		.data = &sun50i_h616_sramc_variant,
 	},
+	{
+		.compatible = "allwinner,sun55i-a523-system-control",
+		.data = &sun55i_a523_sramc_variant,
+	},
 	{ },
 };
 MODULE_DEVICE_TABLE(of, sunxi_sram_dt_match);
-- 
2.51.0