Re: [PATCH net-next v7 04/10] net: dsa: realtek: rtl8365mb: set RGMII mode for family D

From: Mieczyslaw Nalewaj

Date: Fri Nov 06 2026 - 09:59:30 EST


Subject: Re: [PATCH net-next v7 04/10] net: dsa: realtek: rtl8365mb: set RGMII mode for family D

On Fri, Nov 06, 2026 at 02:50:46PM +0100, Alvin Šipraga wrote:
> If you look at dal_rtl8367d_port_phyComboPortMedia_set(), it actually
> writes MAC4_SEL_EXT1 = 1. So this is configurable.

Thanks for the pointer and for the diagram, that makes the mux clear.

> But for the sake of the Linux driver, we don't care about MAC4 being
> anything other than connected to the UTP (internal PHY), right?

Right, nothing in the driver selects MAC4 for EXT1.

> So maybe just check in the switch registers, when it comes out of reset,
> whether the default state of MAC4_SEL_EXT1 is 0. If yes then I think we
> can just ignore this problem altogether, advertise RGMII capability on
> port 7 (i.e. use EXT1), and be done with it.

I do not have the hardware, so I cannot read the reset default of
MAC4_SEL_EXT1 myself. Could someone with a board read bit 12 of
TOP_CON0 (0x1d70) right after reset and confirm it is 0? If it is,
the check is unnecessary and I will drop it.

Until that is confirmed I kept a single read of that bit, and RGMII is
not advertised on port 7 if MAC4 owns the pins. It costs one register
read, does not touch MAC4, and avoids driving the shared pins from two
blocks if the default turns out to be different. It is not bookkeeping:
nothing tracks who requested EXT1, and MAC4 on EXT1 stays unsupported.

> Bookkeeping is overkill. Let's just not support MAC4 as anything other
> than UTP.

Agreed.

Kind regards,
Mieczyslaw