Re: [PATCH 0/5] Support both Ethernet interfaces on i.MX6UL and i.MX7

[Peter Maydell]

On Tue, 18 Apr 2023 at 16:18, Guenter Roeck <linux@roeck-us.net> wrote:
> On 4/18/23 07:46, Peter Maydell wrote:
> > I guess I don't understand what the topology is for these specific
> > SoCs, then. If there's only one master that might be connected
> > to multiple PHYs, why does one ethernet device in QEMU need to
> > know about the other one? Are the PHYs connected to just that
> > first ethernet device, or to both? This bit in your cover letter
> > makes it sound like "both ethernet interfaces connect to the same
> > MDIO bus which has both PHYs on it":
> >
>
> Yes, that is exactly how it is, similar to the configuration in the picture
> at prodigytechno.com. I don't recall what I wrote in the cover letter, but
> "Both Ethernet PHYs connect to the same MDIO bus which is connected to one
> of the Ethernet MACs" would be the most accurate description I can think of.

> Each MAC (Ethernet interface, instance of TYPE_IMX_FEC in qemu) has its own
> MDIO bus. Currently QEMU assumes that each PHY is connected to the MDIO bus
> on its associated MAC interface. That is not the case on the emulated boards,
> where all PHYs are connected to a single MDIO bus.

So looking again at that diagram on that website, I think I understand
now: for data transfer to/from the outside world, MAC1 talks only through
PHY1 and MAC2 only through PHY2 (over the links marked "MII/GMII/XGMII"),
but the "control" connection is via MDIO, and on these boards you have to
configure PHY2 by doing the MDIO reads and writes via MAC1, even though
MAC1 has nothing otherwise to do with PHY2 ? (And MAC2 has no devices on
its MDIO bus at all.)

> Userspace, when talking to the Ethernet controllers, knows that the PHY
> of the second Ethernet controller is connected to the MDIO bus on the first
> Ethernet controller. QEMU has to be told about that and otherwise misses that
> MDIO commands sent to the second PHY (on the first Ethernet controller)
> influence the second MAC interface.
>
>  From this exchange I can only assume that my implementation is unacceptable.

Not at all -- I'm just trying to understand what the hardware we're
modelling is doing, so I can figure out what we "ought" in theory
to be doing and whether that's too much pain to do right now...

thanks
-- PMM