The SOC on i.MX6UL and i.MX7 has 2 Ethernet interfaces. The PHY on each may
be connected to separate MDIO busses, or both may be connected on the same
MDIO bus using different PHY addresses. Commit 461c51ad4275 ("Add a phy-num
property to the i.MX FEC emulator") added support for specifying PHY
addresses, but it did not provide support for linking the second PHY on
a given MDIO bus to the other Ethernet interface.

To be able to support two PHY instances on a single MDIO bus, two properties
are needed: First, there needs to be a flag indicating if the MDIO bus on
a given Ethernet interface is connected. If not, attempts to read from this
bus must always return 0xffff. Implement this property as phy-connected.
Second, if the MDIO bus on an interface is active, it needs a link to the
consumer interface to be able to provide PHY access for it. Implement this
property as phy-consumer.

The first patch of the series implements support in hw/net/imx_fec.c.
Patches 2..5 set the necessary properties in i.MX6UL and i.MX7 emulations.
With this series in place, both Ethernet interfaces on affected emulations
are functional.

----------------------------------------------------------------
Guenter Roeck (5):
      hw/net/imx_fec: Support two Ethernet interfaces connected to single MDIO bus
      fsl-imx6ul: Add fec[12]-phy-connected properties
      arm/mcimx6ul-evk: Set fec1-phy-connected property to false
      fsl-imx7: Add fec[12]-phy-connected properties
      arm/mcimx7d-sabre: Set fec2-phy-connected property to false

 hw/arm/fsl-imx6ul.c         | 20 ++++++++++++++++++++
 hw/arm/fsl-imx7.c           | 20 ++++++++++++++++++++
 hw/arm/mcimx6ul-evk.c       |  2 ++
 hw/arm/mcimx7d-sabre.c      |  2 ++
 hw/net/imx_fec.c            | 27 +++++++++++++++++++++++----
 include/hw/arm/fsl-imx6ul.h |  1 +
 include/hw/arm/fsl-imx7.h   |  1 +
 include/hw/net/imx_fec.h    |  2 ++
 8 files changed, 71 insertions(+), 4 deletions(-)

On Wed, 15 Mar 2023 at 14:52, Guenter Roeck <linux@roeck-us.net> wrote:
>
> The SOC on i.MX6UL and i.MX7 has 2 Ethernet interfaces. The PHY on each may
> be connected to separate MDIO busses, or both may be connected on the same
> MDIO bus using different PHY addresses. Commit 461c51ad4275 ("Add a phy-num
> property to the i.MX FEC emulator") added support for specifying PHY
> addresses, but it did not provide support for linking the second PHY on
> a given MDIO bus to the other Ethernet interface.
>
> To be able to support two PHY instances on a single MDIO bus, two properties
> are needed: First, there needs to be a flag indicating if the MDIO bus on
> a given Ethernet interface is connected. If not, attempts to read from this
> bus must always return 0xffff. Implement this property as phy-connected.
> Second, if the MDIO bus on an interface is active, it needs a link to the
> consumer interface to be able to provide PHY access for it. Implement this
> property as phy-consumer.

So I was having a look at this to see if it was reasonably easy to
split out the PHY into its own device object, and I'm a bit confused.
I know basically 0 about MDIO, but wikipedia says that MDIO buses
have one master (the ethernet MAC) and potentially multiple PHYs.
However it looks like this patchset has configurations where
multiple MACs talk to the same MDIO bus. Am I confused about the
patchset, about the hardware, or about what MDIO supports?

thanks
-- PMM

On 4/18/23 05:10, Peter Maydell wrote:
> On Wed, 15 Mar 2023 at 14:52, Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> The SOC on i.MX6UL and i.MX7 has 2 Ethernet interfaces. The PHY on each may
>> be connected to separate MDIO busses, or both may be connected on the same
>> MDIO bus using different PHY addresses. Commit 461c51ad4275 ("Add a phy-num
>> property to the i.MX FEC emulator") added support for specifying PHY
>> addresses, but it did not provide support for linking the second PHY on
>> a given MDIO bus to the other Ethernet interface.
>>
>> To be able to support two PHY instances on a single MDIO bus, two properties
>> are needed: First, there needs to be a flag indicating if the MDIO bus on
>> a given Ethernet interface is connected. If not, attempts to read from this
>> bus must always return 0xffff. Implement this property as phy-connected.
>> Second, if the MDIO bus on an interface is active, it needs a link to the
>> consumer interface to be able to provide PHY access for it. Implement this
>> property as phy-consumer.
> 
> So I was having a look at this to see if it was reasonably easy to
> split out the PHY into its own device object, and I'm a bit confused.
> I know basically 0 about MDIO, but wikipedia says that MDIO buses
> have one master (the ethernet MAC) and potentially multiple PHYs.
> However it looks like this patchset has configurations where
> multiple MACs talk to the same MDIO bus. Am I confused about the
> patchset, about the hardware, or about what MDIO supports?
> 

It is quite similar to I2C, a serial interface with one master/controller
and a number of devices (PHYs) connected to it. There is a nice graphic
example at https://prodigytechno.com/mdio-management-data-input-output/.
Not sure I understand what is confusing about it. Can you explain ?

Thanks,
Guenter

On Tue, 18 Apr 2023 at 15:42, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 4/18/23 05:10, Peter Maydell wrote:
> > On Wed, 15 Mar 2023 at 14:52, Guenter Roeck <linux@roeck-us.net> wrote:
> > So I was having a look at this to see if it was reasonably easy to
> > split out the PHY into its own device object, and I'm a bit confused.
> > I know basically 0 about MDIO, but wikipedia says that MDIO buses
> > have one master (the ethernet MAC) and potentially multiple PHYs.
> > However it looks like this patchset has configurations where
> > multiple MACs talk to the same MDIO bus. Am I confused about the
> > patchset, about the hardware, or about what MDIO supports?
> >
>
> It is quite similar to I2C, a serial interface with one master/controller
> and a number of devices (PHYs) connected to it. There is a nice graphic
> example at https://prodigytechno.com/mdio-management-data-input-output/.
> Not sure I understand what is confusing about it. Can you explain ?

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":

>> The SOC on i.MX6UL and i.MX7 has 2 Ethernet interfaces. The PHY on each may
>> be connected to separate MDIO busses, or both may be connected on the same
>> MDIO bus using different PHY addresses.

but maybe I'm misreading it.

thanks
-- PMM

On 4/18/23 07:46, Peter Maydell wrote:
> On Tue, 18 Apr 2023 at 15:42, Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 4/18/23 05:10, Peter Maydell wrote:
>>> On Wed, 15 Mar 2023 at 14:52, Guenter Roeck <linux@roeck-us.net> wrote:
>>> So I was having a look at this to see if it was reasonably easy to
>>> split out the PHY into its own device object, and I'm a bit confused.
>>> I know basically 0 about MDIO, but wikipedia says that MDIO buses
>>> have one master (the ethernet MAC) and potentially multiple PHYs.
>>> However it looks like this patchset has configurations where
>>> multiple MACs talk to the same MDIO bus. Am I confused about the
>>> patchset, about the hardware, or about what MDIO supports?
>>>
>>
>> It is quite similar to I2C, a serial interface with one master/controller
>> and a number of devices (PHYs) connected to it. There is a nice graphic
>> example at https://prodigytechno.com/mdio-management-data-input-output/.
>> Not sure I understand what is confusing about it. Can you explain ?
> 
> 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.

>>> The SOC on i.MX6UL and i.MX7 has 2 Ethernet interfaces. The PHY on each may
>>> be connected to separate MDIO busses, or both may be connected on the same
>>> MDIO bus using different PHY addresses.
> 

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.

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.
All I can say is that it works.

Thanks,
Guenter

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

On 4/18/23 08:32, Peter Maydell wrote:
> 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.)
> 

Correct.

Thanks,
Guenter

On Tue, 18 Apr 2023 at 17:55, Guenter Roeck <linux@roeck-us.net> wrote:
> On 4/18/23 08:32, Peter Maydell wrote:
> > 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.)
> >
>
> Correct.

Thanks. Now that I understand how the hardware is put together,
I had a think about what the theoretically 'correct' design
would be. We could do it, but it's a bit of a pain -- among
other things, QEMU's architecture doesn't really consider
the idea of devices that are on more than one bus (as the
PHY is on both the MDIO and the MII), so you have to pick
one as the 'real' bus and then use property links or similar
for the other. And we get into having to look at all the
other uses of PHYs in QEMU so we can design the interface
to be general enough to be usable elsewhere. All of which is
more effort than seems worthwhile for just these imx devices.

So I'm going to take this series into target-arm.next;
if anybody in future wants to properly model the MAC-PHY
interface we can feed this use-case in as one of the
requirement then...

-- PMM