From: Jakub Kicinski <kuba@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>, Jacob Keller <jacob.e.keller@intel.com>
Cc: Jiri Pirko <jiri@resnulli.us>, Michael Walle <michael@walle.cc>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
netdev@vger.kernel.org
Subject: Re: PHY firmware update method
Date: Fri, 30 Sep 2022 07:45:46 -0700 [thread overview]
Message-ID: <20220930074546.0873af1d@kernel.org> (raw)
In-Reply-To: <Yzbi335GQGbGLL4k@lunn.ch>
On Fri, 30 Sep 2022 14:36:47 +0200 Andrew Lunn wrote:
> > 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
>
> That was my first suggestion. One problem is getting the version from
> the binary blob firmware. But this seems like a generic problem for
> linux-firmware, so maybe somebody has worked on a standardised header
> which can be preppended with this meta data?
Not that I know, perhaps the folks that do laptop FW upgrade have some
thoughts https://fwupd.org/
Actually maybe there's something in DMTF, does PLDM have standard image
format? Adding Jake. Not sure if PHYs would use it tho :S
What's the interface that the PHY FW exposes? Ben H was of the opinion
that we should just expose the raw mtd devices.. just saying..
next prev parent reply other threads:[~2022-09-30 14:45 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
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 [this message]
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=20220930074546.0873af1d@kernel.org \
--to=kuba@kernel.org \
--cc=andrew@lunn.ch \
--cc=hkallweit1@gmail.com \
--cc=jacob.e.keller@intel.com \
--cc=jiri@resnulli.us \
--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.