Re: [PATCH] of: of_mdio: Handle properties for non-phy mdio devices

On Wed, 17 Feb 2021 at 03:50, Florian Fainelli [off-list ref] wrote:

On 2/16/2021 5:06 AM, Andrew Lunn wrote:

quoted

On Mon, Feb 15, 2021 at 07:02:18AM +0000, Nathan Rossi wrote:

quoted

From: Nathan Rossi <redacted>

The documentation for MDIO bindings describes the "broken-turn-around",
"reset-assert-us", and "reset-deassert-us" properties such that any MDIO
device can define them. Other MDIO devices may require these properties
in order to correctly function on the MDIO bus.

Enable the parsing and configuration associated with these properties by
moving the associated OF parsing to a common function
of_mdiobus_child_parse and use it to apply these properties for both
PHYs and other MDIO devices.

Hi Nathan

What device are you using this with?

The Marvell Switch driver does its own GPIO reset handling. It has a
better idea when a hardware reset should be applied than what the
phylib core has. It will also poll the EEPROM busy bit after a
reset. How long a pause you need after the reset depends on how full
the EEPROM is.

And i've never had problems with broken-turn-around with Marvell
switches.

The patch does make sense though, Broadcom 53125 switches have a broken
turn around and are mdio_device instances, the broken behavior may not
show up with all MDIO controllers used to interface though. For the

Yes the reason we needed this change was to enable broken turn around,
specifically with a Marvell 88E6390.

reset, I would agree with you this is better delegated to the switch
driver, given that unlike PHY devices, we have no need to know the
mdio_device ID prior to binding the device and the driver together.

quoted

Given the complexity of an Ethernet switch, it is probably better if
it handles its own reset.

We are not using the reset assert, I included this as part of the
change to match the existing phy parsing behavior. I can update this
change to only handle broken turn around, or is it also preferred that
broken turn around is handled by the e.g. switch driver?

Thanks,
Nathan