linux-kernel - Re: [PATCH v1] lan743x: correctly handle chips with internal PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 4 Nov 2020 16:52:28 -0500
From:   Sven Van Asbroeck <thesven73@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Bryan Whitehead <bryan.whitehead@...rochip.com>,
        David S Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Roelof Berg <rberg@...g-solutions.de>,
        netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] lan743x: correctly handle chips with internal PHY

Andrew,

On Wed, Nov 4, 2020 at 11:55 AM Andrew Lunn <andrew@...n.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