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]

Message-ID: <Yzan3ZgAw3ImHfeK@nanopsycho>
Date:   Fri, 30 Sep 2022 10:25:01 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Jakub Kicinski <kuba@...nel.org>, 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

Thu, Sep 29, 2022 at 04:53:11PM CEST, andrew@...n.ch wrote:
>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.

Yeah, I tend to agree here. I believe that phylib should probably find a
separate way to to the flash.

But perhaps it could be a non-user-facing flash. I mean, what if phylib
has internal routine to:
1) do query phy fw version
2) load a fw bin related for this phy (easy phy driver may provide the
				       path/name of the file)
3) flash if there is a newer version available

I'm not saying this is complete solution, but it could be first step and
perhaps sufficient. For example, this pattern works for ordinary mlxsw
user who just updates the kernel/linux-firmware parkages - the driver
does flashing implicitly during init when never version is found.