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