On Thu, 9 Oct 2025 11:54:37 -0400 Sasha Levin sashal@kernel.org wrote:
Hi,
From: Chen-Yu Tsai wens@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@gmail.com Link: https://patch.msgid.link/20250908181059.1785605-4-wens@kernel.org Signed-off-by: Chen-Yu Tsai wens@csie.org Signed-off-by: Sasha Levin sashal@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.
It's pointless, any kernel before v6.15 will not boot on any A523 device, so support for any kind of A523 MAC is irrelevant. For newer kernels, this would be tied to the GMAC1 enablement, which is also a new feature, so not a candidate for stable.
Cheers, Andre
- 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);