Re: [PATCH v3 2/2] net: dsa: mxl-gsw1xx: Support R(G)MII slew rate configuration

On Tue, Jan 06, 2026 at 09:41:13AM +0000, Sverdlin, Alexander wrote:

Hello Vladimir, Rob!

On Mon, 2026-01-05 at 22:00 +0100, Alexander Sverdlin wrote:

quoted

quoted

quoted

+	return regmap_update_bits(gsw1xx_priv->shell, GSW1XX_SHELL_RGMII_SLEW_CFG,
+				  RGMII_SLEW_CFG_DRV_TXD | RGMII_SLEW_CFG_DRV_TXC,
+				  (RGMII_SLEW_CFG_DRV_TXD | RGMII_SLEW_CFG_DRV_TXC) * rate);

I don't have a particularly strong EE background, but my understanding
is this:

RGMII MACs provide individual slew rate configuration for TXD[3:0] and
for TX_CLK because normally, you'd want to focus on the TX_CLK slew rate
(in the sense of reducing EMI) more than on the TXD[3:0] slew rate.
This is for 2 reasons:
(1) the EMI noise produced by TX_CLK is in a much narrower spectrum
    (runs at fixed 125/25/2.5 MHz) than TXD[3:0] (pseudo-random data).
(2) reducing the slew rate for TXD[3:0] risks introducing inter-symbol
    interference, risk which does not exist for TX_CLK

Your dt-binding does not permit configuring the slew rates separately,
even though the hardware permits that. Was it intentional?

thanks for the hint! This is definitely something I need to discuss with HW
colleagues and get back to you!

Vladimir, according to the responsible HW colleague, it's OK and is desired
to have TXD in "slow" as long as Setup-/Hold-Timing is in spec.

I do understand, that this is board-specific. Do you propose to introduce
two separate properties?

Rob, in such case just "slew-rate" probably wouldn't fit any longer and
I'd need to go back to "maxlinear,slew-rate-txd" and "maxlinear,slew-rate-txc"
probably?

I see Rob has reviewed the binding in this form already, but I think the
rule of thumb that we could apply in this case is to still describe the
clock and data slew rates separately. Like Russell points out in a separate
thread, it's simpler to do this from the beginning rather than end up
with 3 properties you'd have to maintain, if you later need individual
control.
https://lore.kernel.org/netdev/aTB0x6JGcGUM04UX@shell.armlinux.org.uk/ (local)

Sadly I don't have the expertise to give any advice on how that would
translate into dt-bindings. Does it make sense to implement a full pin
controller device driver for the registers GPIO_DRIVE0_CFG -> RGMII_SLEW_CFG?