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

[Alvin Šipraga]

On Thu, Nov 05, 2026 at 04:27:22PM +0100, Mieczyslaw Nalewaj wrote:
> On Thu, Nov 05, 2026 at 01:39:53PM +0100, Alvin Šipraga wrote:
> > During your work on the D family, did you find that the vendor driver
> > is programming the same values?
> >
> > One thing I'm wondering is: for the other C family chips, is some extra
> > RGMII TX delay being silently added by the jam table we already have?
> > [...]
> 
> I did not diff the vendor family D init table against the family C one,
> so I cannot say they are identical. I only know this register: our table
> writes 0x0090 to 0x13f9, which leaves the EXT1 RGMII TX delay field at
> 2, and the vendor RGMII setup for EXT1 on family D clears that field. I
> do not know what the field does on family C.
> 
> > Anyway, if the jam table the vendor driver uses is indeed the same for
> > both families, maybe it's best to keep it explicit like you have
> > done.
> 
> OK, I will keep it as it is.
> 
> > Do you have a datasheet I can look at? I couldn't find one.
> 
> No, I do not have one either. Everything about family D comes from the
> vendor RTL8367D API.
> 
> > I'm also a bit confused by what it means for MAC4 to "own" EXT1. Are we
> > talking about physical pin muxing [...] or is this internal muxing? And
> > since you say MAC4 is a UTP port, I don't understand how it can also be
> > associated with EXT1 [...].
> 
> I cannot answer that. "Owns" was my shorthand for the bit. All I have is
> this check in the vendor RGMII setup for port 7:
> 
>     /* Configure RGMII/MII mux to port 7 if UTP_PORT4 is not RGMII mode */
>     if ((retVal = rtl8367d_getAsicRegBit(RTL8367D_REG_TOP_CON0,
>             RTL8367D_MAC4_SEL_EXT1_OFFSET, &mux)) != RT_ERR_OK)
>         return retVal;
> 
> I did not verify anything beyond it, so I do not know whether this is a
> physical or an internal mux.

Looking at the vendor driver, it seems you can mux what they call MAC4,
to either a copper PHY, a SerDes, or an RGMII interface (EXT1). They
call port it a "combo port" (see RTK_CHK_PORT_IS_COMBO()). The other
port, MAC7, can also use EXT1. Or it can use a SerDes. But not copper.

The vendor driver is predictably quite confusing in its terminology,
calling port 4 a UTP port while also allowing RGMII etc. But whatever.

So if I understood correctly it looks something like this:

     UTP        EXT1 (RMII/RGMII)   SerDes(1?)
      |             ___|___         ___|___
      |            /       \       /       \
      |            |_______|       |_______|
      |              |   |           |   |
      |  .-----------'   |           |   |
      |  |  .------------------------'   |
   ___|__|__|___         |     .---------'
  |             |     ___|_____|___
  \_____________/    |             |
         |           \_____________/
       MAC4                 |
                          MAC7

> 
> > Since MAC7_SEL_EXT1 is writable, I would guess that so is
> > MAC4_SEL_EXT1. Could we not instead keep it configurable, and do some
> > bookkeeping in the driver to see who has requested these pins? [...]
> 
> The vendor code only reads MAC4_SEL_EXT1 in this path, and I have not
> verified that writing it is safe or what it does to UTP port 4. The
> driver has no code path that selects MAC4 for EXT1, so port 7 would be
> the only requester.

If you look at dal_rtl8367d_port_phyComboPortMedia_set(), it actually
writes MAC4_SEL_EXT1 = 1. So this is configurable.

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?

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. Maybe add a comment where
you write 1 to MAC7_SEL_EXT1 that a mux is being configured which is
also shared with MAC4 somehow, but that this feature is unsupported.

Does that make sense?

> 
> I can implement the bookkeeping in v9, but I would need to know how you
> want the MAC4 side handled. Alternatively, I can read the bit once in
> rtl8365mb_setup() and refuse RGMII on port 7 when it is set.

Bookkeeping is overkill. Let's just not support MAC4 as anything other
than UTP. If someone wants to add that support later, then it would make
sense to add bookkeeping.

Kind regards,
Alvin