Needs to support more Ethernet PHY chips

[wdx04]

Hi,

I recently updated to the latest version of Mbed CE.

Unfortunately, I found the Ethernet interface on many of my custom STM32 boards refused to work. After some debugging I found it was blocked by the strict PHY ID checking in GenericEthPhy.cpp. Currently, LAN8742 is the default and only supported PHY in PhyDrivers.cpp. But my custom boards usually have LAN8720 or DP83848 PHY chips on them. If I comment out the code checking the PHY ID, then the Ethernet interface will continue to work.

As far as I know, LAN87xx and DP83848 are almost idential in software, except DP83848's PHY address is 1, while LAN87xx uses PHY address 0. In the past, I only need to override the "stm32-emac.eth-phy-address" in the mbed_app.json5 to make them work.

According to CompositeEMAC.md, the recommened way to support another Ethernet PHY is to derive a class from GenericEthPhy and override the get_eth_phy_driver function. The problem is where should I place the code. If I place the code at the custom target level, then the custom target library would have to link with the mbed-emac library. If I place the code at application level, then I have to copy/paste it into every existing applications that uses the Ethernet interface. Neither way feels good. It would be nice to have an option to bypass the PHY ID checking, to minimize the impact on existing applications. Alternatively, can we add support for more commonly-used Ethernet PHY chips out of box?

Thanks,

[multiplemonomials]

Ah yeah, I can see how that's an issue. I'd love to merge support for those phys into Mbed -- could you submit a PR?
It was actually on my list to add DP83848 anyway as that's what's used on the LPC1768 board.

[wdx04]

Ah yeah, I can see how that's an issue. I'd love to merge support for those phys into Mbed -- could you submit a PR? It was actually on my list to add DP83848 anyway as that's what's used on the LPC1768 board.

OK. I think I can submit a PR.
But actually I don't want to introduce a new class for LAN8720, because LAN8720 is software-compatible with LAN8742, as long as the MCO feature of LAN8742 is not used. And LAN8720 and LAN8742 have the same OUI(0x1F0), though their model numbers are different(0x0F vs 0x13).
DP83848 has similar problems, the datasheet from TI website says DP83848C/I/VYB/YB has OUI=0x80017 and Model=0x0A, but the DP83848 chip on my board is DP83848VV which has OUI=0x80017 and Model=0x09.
I think its reasonable to support a range of models with the same OUI in a single PHY Config class, better than creating a separate Config class for each specific model.

[multiplemonomials]

That makes sense to me. Maybe we could turn the model number into an array of model numbers which are accepted by the PHY driver, and then we could rename the LAN8742 driver to like LAN874x