Andrew,
On Wed, Nov 4, 2020 at 11:55 AM Andrew Lunn <and...@lunn.ch> wrote:
> If you look at that patch, you see:
>
> - ret = phy_connect_direct(netdev, phydev,
> - lan743x_phy_link_status_change,
> - PHY_INTERFACE_MODE_GMII);
> - if (ret)
> - goto return_error;
>
>
> That was added as part of the first commit for the lan743x
> driver. Changing that now seems dangerous.
I think there's a misunderstanding on my part, and it flows from the
following bit of the commit message in 6f197fb63850
("lan743x: Added fixed link and RGMII support"):
> . The device tree entry phy-connection-type is supported now with
> the modes RGMII or (G)MII (default).
I interpreted that to mean "if phy-connection-type is omitted, it will default
to G(MII)". However I now notice that the code in that patch does no such
thing: if that prop is omitted, the mode is actually silently set to
PHY_INTERFACE_MODE_NA, which is probably not great.
In summary, 6f197fb63850 behaves as follows:
1. if a devnode is present, attempts to configure the phy from devicetree,
but silently breaks if phy-connection-type is omitted
2. if no devicetree node present, tries to connect to an internal phy using
(G)MII (which silently breaks if an internal phy chip has a devicenode)
This proposed patch replaces this with:
1. attempts to configure the phy from devicetree, fails if no correct devicetree
description present (phy-connection-type is required)
2. if (1) fails, tries to connect to an internal phy using (G)MII
As far as I can see, this doesn't appear to introduce any breaking changes?
It's of course quite possible that I've overlooked something, I am definitely
not a netdev/phy expert.
Sven
