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:   Wed, 28 Sep 2022 14:28:27 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Michael Walle <michael@...le.cc>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org
Subject: Re: PHY firmware update method

On Wed, Sep 28, 2022 at 01:27:13PM +0200, Michael Walle wrote:
> Hi,
> 
> There are PHYs whose firmware can be updated. Usually, they have
> an internal ROM and you can add patches on top of that, or there
> might be an external flash device which can have a more recent
> firmware version installed which can be programmed in-place
> through the PHY.
> 
> The firmware update for a PHY is usually quite simple, but there
> seems to be no infrastructure in the kernel for that. There is the
> ETHTOOL_FLASHDEV ioctl for upgrading the firmware of a NIC it seems.
> Other than that I haven't found anything. And before going in a wrong
> directions I'd like to hear your thoughts on how to do it. I.e. how
> should the interface to the userspace look like.
> 
> Also I think the PHY should be taken offline, similar to the cable
> test.

I've seen a few different ways of doing this.

One is to load the firmware from disk every boot using
request_firmware(). Then parse the header, determine if it is newer
than what the PHY is already using, and if so, upgrade the PHY. If you
do this during probe, it should be transparent, no user interaction
required.

I've also seen the FLASH made available as just another mtd
device. User space can then write to it, and then do a {cold} boot.

devlink has become the standard way for upgrading firmware on complex
network devices, like NICs and TOR switches. That is probably a good
solution here. The problem is, what devlink instance to use. Only a
few MAC drivers are using devlink, so it is unlikely the MAC driver
the PHY is attached to has a devlink instance. Do we create a devlink
instance for the PHY?

You might want to talk to Jiri about this.

The other issue is actually getting the firmware. Many manufactures
seem reluctant to allow redistribution as required by linux-firmware.
There is no point adding firmware upgrade if you cannot redistribute
the firmware.

    Andrew