netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 4 Nov 2020 12:10:33 -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

On Wed, Nov 4, 2020 at 11:55 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/ethernet/microchip/lan743x_main.c?h=v5.9.3&id=6f197fb63850b26ef8f70f1bfe5900e377910a5a
>
> 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.

My knowledge of netdev/phy is extremely limited, so bear with me.

The code quoted above (the first commit for lan743x) has been reinstated
in my patch. It's literally identical - in the case the kernel can't find any
available/sensible devicetree phy description.

In the case of devicetree phys, which have been added recently,
the 'phy-connection-type' prop appeared to have been optional,
defaulting to (G)MII. My patch removes that devicetree default.

So I guess my question is this - is there really a need for a
devicetree default for 'phy-connection-type'? If not, no code
duplication or mdio refactoring is required.