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

[Mieczyslaw Nalewaj <namiltd@yahoo.com>]

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.

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

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.

Kind regards,
Mieczyslaw