| Message ID | 20230315145248.1639364-1-linux@roeck-us.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Support both Ethernet interfaces on i.MX6UL and i.MX7 | expand |
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
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(-)