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

[Mieczyslaw Nalewaj <namiltd@yahoo.com>]

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

On Fri, Nov 06, 2026 at 03:28:30PM +0100, Alvin Šipraga wrote:
> 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.

Sorry, the wording was unclear, and no interrupts are involved. "Edge"
is the SDS_MISC mode field changing from DISABLE to HSGMII, and "latch"
is the SerDes receiver locking onto the incoming signal. It locks on
that change, not on the value, and only if the far end is already
sending.

> 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?

As far as I can tell, a hardware oddity. If the change happens before
the far-end MAC is up, the receiver does not lock and nothing retries.
Both ends then report 2.5Gbps/Full while no frames pass.

> Can we use interrupts instead of polling?

I do not know. I have no datasheet, and the vendor API I have does not
expose an interrupt for the SerDes state.

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

pcs_config() and pcs_link_up() run seconds before the far-end MAC
starts, and phylink never calls rtl8365mb_pcs_get_state() for this
port: mb->pcs.poll only arms polling for in-band links, and the CPU
port is a fixed link. The only event I found that tells the driver the
far end is starting is the CPU conduit coming up, reported through
->conduit_state_change().

> You've added some scheduled work in this patch but you do not make
> that apparent in the commit message here.

Right, the commit message does not say it. The work repeats the
DISABLE -> HSGMII change every 10 s until the link-status bit shows
that the receiver locked.

Kind regards,
Mieczyslaw