[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220930074546.0873af1d@kernel.org>
Date: Fri, 30 Sep 2022 07:45:46 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Andrew Lunn <andrew@...n.ch>,
Jacob Keller <jacob.e.keller@...el.com>
Cc: Jiri Pirko <jiri@...nulli.us>, 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
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..
Powered by blists - more mailing lists