Configuring KSZ8081 PHY drivers at run time

[DCoffey-CLN]

Hi, I have a custom board with an NXP IMXRT1176 mcu and a Microchip KSZ8081RNB ethernet phy. This board has been through a revision: in the first revision the reference clock for the phy was a 50MHz clock generated by the microcontroller, and in the later revision an external 25MHz crystal is used instead. A group of pullup/pulldown resistors connected to gpio pins allow for the checking of the board revision at run time. The goal is to have a single firmware image which supports both revisions, but there is some complication involved in making this work with the KSZ8081 phy driver included in zephyr.

When the phy is initialized, the driver resets it via the reset pin on the phy, before writing settings based on the device tree node for the phy to the registers using the MDIO interface. Specifically, the PHY Control 2 register "RMII reference clock select" bit is written based on whether the phy is configured to use RMII mode. In my use case it would be necessary to write or clear this bit based on whether the board is using a 25MHz or 50MHz clock.

I already have a sys init call to check the board rev and generate the 50MHz clock from the mcu if it is needed. The problem with setting the phy bit here is that the phy will subsequently be reset by its own driver. The issue with changing the bit after the phy setup (the method that we were using for this board in zephyr 3.6 using the eth_mcux driver from NXP) is that the KSZ8081 driver takes a long time to time out on autonegotiation failure (which it inevitably will when the clock is incorrect).

Is there an elegant solution to handle this setup which doesn't involve modifying the phy drivers for just this specific board?

Thanks!

[DerekSnell]

Hi @DCoffey-CLN ,
You are referencing the older Zephyr version v3.6, which is no longer maintained.
But looking at the latest KSZ8081 driver, I see what you mean there. The CTRL2_REG is configured from the devicetree, not dynamically by the app.
@decsny and @stanislav-poboril , do you have suggestions for how to manage this?

[decsny]

I was actually already looking into trying to change that blocking in the configure function, because you're not the only person to be bringing it up all the sudden recently, but this type of change will have to go into 4.3 release by now. However you can always cherry pick patches to your fork

[DCoffey-CLN]

Thanks, @decsny, that's much appreciated. As it's somewhat related to this issue with regards to 25MHz vs 50MHz clocks on the phy - it's worth noting also that the drivers don't currently do anything with the "rmii-25Mhz" config option as far as I can tell. I believe this would just be a case of setting the RMII override in the OMSO register but not setting the clock select bit in the phy control 2 register for this config option. In our use-case we'd be defaulting to 25MHz and setting to 50MHz (in phy control 2) in app code if necessary, so will be useful to have this option. I have patched for now but thought it was worth flagging up.

[decsny]

@DCoffey-CLN would it make sense to upstream your patch for that?

[DCoffey-CLN]

Happy to do that, yes.

[decsny]

@DCoffey-CLN maybe this PR now helps #93118