Re: [PATCH] RFC: net: phy: of phys probe/reset issue

On 10/28/2020 12:32 PM, Grygorii Strashko wrote:

hi Andrew,

On 23/10/2020 23:10, Andrew Lunn wrote:

quoted

quoted

Yes there is: have your Ethernet PHY compatible string be of the form
"ethernetAAAA.BBBB" and then there is no need for such hacking.
of_get_phy_id() will parse that compatible and that will trigger
of_mdiobus_register_phy() to take the phy_device_create() path.

Yep. That does seem like the cleanest way to do this. Let the PHY
driver deal with the resources it needs.

Thanks you for your comments.

huh. I gave it try and some thinking. it works as W/A, but what does it
mean in the long term?

I believe this was made clearer before: this is the only forward that
works across all subsystems, independently of the PHY and MDIO layers.

Neither Linux documentation, neither DT bindings suggest such solution
in any way
(and there is *Zero* users of ""ethernet-phy-id%4x.%4x" in the current
LKML).
And the main reason for this RFC is really bad customer experience while
migrating to the new kernels, as
mdio reset does not support multi-phys and phy resets are not working.

It is documented in the binding, but the binding is a document about a
contract, not about how Linux implements things, so I suppose you are
right that we are missing additional documentation to describe how it is
useful:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/ethernet-phy.yaml#n30

Following your comments, my understanding for the long term (to avoid
user's confusions) is:
"for OF case the usage of 'ethernet-phy-id%4x.%4x' compatibly is became
mandatory for PHYs
to avoid PHY resets dependencies from board design and bootloader".

Which in turn means - update all reference boards by adding
""ethernet-phy-id%4x.%4x" and add
new DT board files for boards which are differ by only PHY version.

Well, you can have the boot loader absorb some of those board specific
details, after all, the entire point of moving ARM towards Device Tree
was to do just that. The appended DTB was offered as an interim solution.
-- 
Florian