From: Jiri Pirko <jiri@resnulli.us>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Michael Walle <michael@walle.cc>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
netdev@vger.kernel.org, kuba@kernel.org
Subject: Re: PHY firmware update method
Date: Thu, 29 Sep 2022 09:04:07 +0200 [thread overview]
Message-ID: <YzVDZ4qrBnANEUpm@nanopsycho> (raw)
In-Reply-To: <YzQ96z73MneBIfvZ@lunn.ch>
Wed, Sep 28, 2022 at 02:28:27PM CEST, andrew@lunn.ch wrote:
>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?
Ccing Jakub. I don't think it is good idea to create a devlink instance
per-PHY. However, on the other hand, we have a devlink instance per
devlink linecard now. The devlink linecard however has devlink
representation, which PHY does not have.
Perhaps now is the time to dust-off my devlink components implementation
and use it for PHYs? IDF. Jakub, WDYT.
>
>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
next prev parent reply other threads:[~2022-09-29 7:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-28 11:27 PHY firmware update method Michael Walle
2022-09-28 12:28 ` Andrew Lunn
2022-09-29 7:04 ` Jiri Pirko [this message]
2022-09-29 12:28 ` Andrew Lunn
2022-09-29 14:12 ` Jakub Kicinski
2022-09-29 14:53 ` Andrew Lunn
2022-09-30 8:25 ` Jiri Pirko
2022-09-30 12:36 ` Andrew Lunn
2022-09-30 14:45 ` Jakub Kicinski
2022-09-30 16:49 ` Keller, Jacob E
2022-10-03 12:18 ` Russell King (Oracle)
2022-10-03 14:42 ` Jakub Kicinski
2022-10-03 17:53 ` Keller, Jacob E
2022-10-03 18:04 ` Jacob Keller
2023-01-24 17:13 ` Michael Walle
2023-01-24 17:11 ` Michael Walle
2023-01-24 20:42 ` Andrew Lunn
2023-01-31 16:10 ` Michael Walle
2023-01-31 16:29 ` Russell King (Oracle)
2023-01-31 17:48 ` Michael Walle
2023-01-31 18:36 ` Jacob Keller
2023-01-31 18:41 ` Jakub Kicinski
2023-01-31 19:56 ` Jacob Keller
2023-01-31 21:07 ` Jakub Kicinski
2023-01-24 22:28 ` Jacob Keller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YzVDZ4qrBnANEUpm@nanopsycho \
--to=jiri@resnulli.us \
--cc=andrew@lunn.ch \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux@armlinux.org.uk \
--cc=michael@walle.cc \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.