Re: [PATCH net-next v13 09/11] net: mdio: realtek-rtl9300: Add support for RTL838x

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Omitting C45 read/write callbacks causes C45-over-C22 fallback, which races with the hardware polling engine and silently corrupts PHY MMD registers.
--

--- Patch [9]: [PATCH net-next v13 09/11] net: mdio: realtek-rtl9300: Add support for RTL838x ---
commit d55bec9024e95e7ae2bc08007789dc929916fc94
Author: Markus Stockhausen <markus.stockhausen@gmx.de>

net: mdio: realtek-rtl9300: Add support for RTL838x

This commit adds support for the RTL838x (maple) series to the RTL9300
MDIO driver. It introduces new hardware definitions, C22 access functions,
and controller setup for RTL8380.

[ ... ]

> @@ -868,6 +927,26 @@ static int otto_emdio_probe(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +static const struct otto_emdio_info otto_emdio_8380_info = {
> +	.addr_map_base = RTL8380_SMI_PORT0_5_ADDR_CTRL,
> +	.cmd_fail = RTL8380_PHY_CTRL_FAIL,
> +	.cmd_read = RTL8380_PHY_CTRL_READ,
> +	.cmd_write = RTL8380_PHY_CTRL_WRITE,
> +	.cmd_regs = {
> +		.c22_data = RTL8380_SMI_ACCESS_PHY_CTRL_1,
> +		.c45_data = RTL8380_SMI_ACCESS_PHY_CTRL_3,
> +		.io_data = RTL8380_SMI_ACCESS_PHY_CTRL_2,
> +		.port_mask_low = RTL8380_SMI_ACCESS_PHY_CTRL_0,
> +	},
> +	.num_buses = RTL8380_NUM_BUSES,
> +	.num_pages = RTL8380_NUM_PAGES,
> +	.num_ports = RTL8380_NUM_PORTS,
> +	.poll_ctrl = RTL8380_SMI_POLL_CTRL,
> +	.setup_controller = otto_emdio_8380_setup_controller,
> +	.read_c22 = otto_emdio_8380_read_c22,
> +	.write_c22 = otto_emdio_8380_write_c22,
> +};

[Severity: High]
Will omitting the .read_c45 and .write_c45 callbacks here cause the PHY
subsystem to automatically use the C45-over-C22 software fallback via
mmd_phy_indirect() when MMD registers are accessed?

The commit message mentions keeping the C45 helpers out of the driver until
needed. However, if any kernel PHY code (like EEE initialization) or userspace
tool accesses MMD registers, the software fallback performs multiple non-atomic
C22 writes to registers 13 and 14.

Since the hardware polling engine autonomously and continuously writes to these
same registers in the background, could the software fallback interleave with
the polling engine and silently corrupt the PHY MMD configuration?

If C45 access should be disabled for now, would it be safer to provide dummy
C45 callbacks that return an error, or to have otto_emdio_write_c22() intercept
and reject writes to registers 13 and 14?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807171058.522833-1-markus.stockhausen@gmx.de?part=9