Re: [PATCH net-next v7 08/10] net: dsa: realtek: rtl8365mb: re-latch the family D SerDes

["Alvin Šipraga" <alvin.sipraga@analog.com>]

On Mon, Nov 02, 2026 at 03:43:45PM +0100, Mieczyslaw Nalewaj wrote:
> The family D receiver latches on the DISABLE -> HSGMII edge in SDS_MISC
> rather than on the value, and it will not latch until the MAC at the

I don't understand this at all, should it be obvious what you mean by
"edge" and "latch" here? I would assume you are talking about interrupts
but it's not clear.

> other end of the trunk has brought its own half of the link up. If it
> does not latch, the trunk reports 2.5Gbps/Full on both sides but moves
> no frames: the CPU MAC transmits, the switch CPU port counts no octets,
> and there are no CRC, alignment or FIFO errors.
> 
> The two ends can be seconds apart, e.g. on an IPQ5018 board:
> 
>   5.27  rtl8365mb: configuring for fixed/2500base-x   <- pcs_config()
>   7.72  ipq5018-gmac-dwmac eth0: configuring for fixed/2500base-x
>   8.02  ipq5018-gmac-dwmac eth0: Link is Up - 2.5Gbps/Full
>   8.56  SerDes latches
> 
> pcs_config() runs seconds before the far-end MAC even starts
> configuring, so a single edge driven from there is not enough: the
> receiver has nothing to latch onto yet. Neither is pcs_link_up(),
> which is seconds early for the same reason. phylink does not help
> either - it never calls rtl8365mb_pcs_get_state() for this port in
> the first place, since mb->pcs.poll only arms phylink's own poll for
> in-band links, and this CPU port is a fixed link.

OK, I'm out of the loop regarding the SerDes stuff. But I find this
patch quite baroque and the reasoning hard to follow, with a lot of
strange terminology (episode, latch, "value"?). Maybe it's just me.

Is the shortcoming/issue you are addressing one of DSA when a SerDes is
used in the CPU link? Or is it rather some hardware oddity?

Can we use interrupts instead of polling?

The notifier block, extra locking, etc. gives me the creeps and seems
like a lot of infrastructure to solve something I don't
understand. Sorry if my questions are dumb, but I need a better
explanation of the whole problem to review this properly.

> 
> There is no local signal that predicts when the far-end MAC will
> bring up its half of the link (bit 8 of the SDS link-status word
> does not change ahead of it), so the work cannot wait for it; it can
> only tell afterwards, from the link-status bit, whether an edge took.

You talk about "it" and "work" but it is unclear what you mean. You've
added some scheduled work in this patch but you do not make that
apparent in the commit message here.

> 
> The far-end MAC starts when its conduit is brought up, which DSA
> reports through ->conduit_state_change(), so an episode of re-latch
> attempts starts there. Only the conduit of the CPU port that carries
> the SerDes (port 6) is considered: the chip can have a second CPU
> port on RGMII, and its conduit says nothing about the SerDes link.
> pcs_config() only arms the work, and starts an episode itself if that
> conduit is already up. The work re-arms itself after each edge; the
> next run checks whether the edge took, rather than waiting on a poll
> that will not come. When the conduit goes down the work is stopped, so
> a link without a far end is not reported as lost and not parked every
> 10 s.

I'm basically wondering here if this is not something that DSA or
phylink could help with?

[...]

Cutting the rest for now!

Kind regards,
Alvin