netdev - Re: PHY firmware update method

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:   Thu, 29 Sep 2022 16:53:11 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Jiri Pirko <jiri@...nulli.us>, Michael Walle <michael@...le.cc>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org
Subject: Re: PHY firmware update method

On Thu, Sep 29, 2022 at 07:12:09AM -0700, Jakub Kicinski wrote:
> On Thu, 29 Sep 2022 14:28:13 +0200 Andrew Lunn wrote:
> > If we want to make the PHY a component of an existing devlink for a
> > MAC, we somehow have to find that devlink instance. A PHY is probably
> > a property of a port, so we can call netdev_to_devlink_port(), which
> > gives us a way into devlink.
> > 
> > However, the majority of MAC drivers don't have a devlink
> > instance. What do we do then? Have phylib create the devlink instance
> > for the MAC driver? That seems very wrong.
> > 
> > Which is why i was thinking the PHY should have its own devlink
> > instance.
> 
> Tricky stuff, how would you expose the topology of the system to 
> the user? My initial direction would also be component. Although 
> it may be weird if MAC has a way to flash "all" components in one go,
> and that did not flash the PHY :S

~/linux/drivers/net$ grep -r PHYLIB | wc
    114     394    4791

~/linux/drivers/net$ grep -r NET_DEVLINK | wc
     20      60     945

And, of those 20 using DEVLINK, only 4 appear to use PHYLIB.

> Either way I don't think we can avoid MACs having a devlink instance
> because there needs to be some form of topology formed.

In the past, we have tried to make PHYLIB features just work, without
MAC changes. It does not scale otherwise. Cable testing just works if
the PHY supports it, without the MAC driver being changed. PHY stats
work without MAC changes. PHY based PTP works without MAC changes, SFP
module EEPROM dumping works without MAC changes. Why should PHY
firmware upgrade need MAC changes? The MAC does not even care. All it
should see is that the link is down while the upgrade happens.

Maybe devlink is the wrong interface, if it is going to force us to
make MAC changes for most devices to actual make use of this PHY
feature.

     Andrew