Hi,

quoted

On the AM335x board, the CPSW MDIO and PRUSS MDIO signals are routed to the same
physical
pins (as shown in the schematic, see page 10 “MII_MUX” in
tmdxice3359_sch_3h0013_v2_1a.pdf
from https://www.ti.com/lit/zip/TIDR336 ). Because of this shared routing, the
pinmux
configuration applied by U-Boot for CPSW MDIO remains active even if the CPSW
MDIO node is
later disabled in Linux, and Linux does not automatically revert the pins to
their reset state.

It is generally a bad idea to rely on the bootloader. I would make the
CPSW MDIO configure the pins how it needs it. The PRUSS MDIO should
also configure the pins how it needs them. However, it is not as
simple as that...

On AM335x, the MDIO interface is selected by a hardware jumper before the
bootloader runs. The selection is latched in hardware, so only one MDIO
controller (CPSW or PRUSS) is active at a time.

Since the hardware choice is fixed prior to Linux boot, we decided to ensure
in U-Boot that the pins are configured according to the selected hardware latch.
Linux still configures the active MDIO controller as required via its DT and
pinctrl settings. The U‑Boot change ensures a clean initial state that matches
the hardware latched configuration, and we have this prepared as a patch that
will be submitted to mainline U‑Boot shortly.

Looking at the schematic, what you have is ugly. You literally wire
the outputs together, without a hardware mux. For MDC you assume one
is Hi-Z, while the other drives the line. For MDIO it does not matter,
both are inputs. so Hi-Z.

Although the schematic shows the signals tied together without an explicit mux,
the hardware jumper selects RMII (CPSW) or MII (PRUSS) before boot. Only the
selected block is enabled, and the other remains inactive, so the lines are never
driven concurrently.

I actually think you might need to represent this in Linux, with
something i would call a pinmux-mux. You give it two sets of pinmux
configurations. The active device claims the mux and gets it to set
the two sets of pinmux as needed. Also, just setting the pinmux to
GPIO is not sufficient, you also need to ensure the GPIO is configured
for input, so the lines go Hi-Z. Often pinmux and GPIO controllers are
interconnected, so the pinmux subsystem might be able to do that for
you.

I don't know if a pinmux-mux already exists in Linux. You probably
want to ask on the pinmux mailing list, or they might have a different
idea how to cleanly do this.

Andrew

In this case, the selection is static and determined by hardware via a jumper,
not switchable at runtime. Linux reflects this by choosing the Device Tree
configuration corresponding to the latched jumper, it enables the selected
MDIO controller and sets up its pinmux, while the other MDIO controller
remains disabled.

We will update the patches by removing the CPSW pin reset configuration in
ICSS context and post the next version shortly.

Thanks and Regards,
Parvathi