If the PHY doesn't have MDIO or it has multiple physical interfaces, then it will require a different code. Otherwise for the standard (R)MII/MDIO PHYs all of the basic functionality is standardized, including software reset, power down, speed/duplex mode selection, auto-negotiation and link state. The only typically necessary thing, that is not standardized, is extended status register, which returns the auto-negotiation result. Those are the three constants to adapt for a particular standard PHY. And, as I said, manufacturers typically keep those registers and bits compatible between their own devices. Of course the Microchip's LAN*** and KSZ*** series have different implementations, because those series come from different manufacturers they acquired, but still the new devices continue the trend of either one or the other series.
The fact that ST cannot make the basic Ethernet and lwIP working for 15 years and counting, but implemented 1000+ code line "chip specific" driver for a functionality that is standardized, just shows how far from the real life usage their incompetent software developers are.
And yes, I know what I'm talking because I actually read the documentation and develop code, not just click CubeMX bloatware generator. Here is an useful information on Ethernet related problems with ST's code:
https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32
https://community.st.com/s/question/0D50X0000AhNBoWSQW/actually-working-stm32-ethernet-and-lwip-demonstration-firmware
The most ironic thing is when the people believe that, for example, PHY driver, which really is simple, is "not that simple", but then are completely OK with using ST's totally broken ETH MAC driver and lwIP integration code, both of which indeed are not that simple...
