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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 30 Sep 2022 16:49:44 +0000
From:   "Keller, Jacob E" <>
To:     Jakub Kicinski <>, Andrew Lunn <>
CC:     Jiri Pirko <>, Michael Walle <>,
        "Heiner Kallweit" <>,
        Russell King <>,
        "" <>
Subject: RE: PHY firmware update method

> -----Original Message-----
> From: Jakub Kicinski <>
> Sent: Friday, September 30, 2022 7:46 AM
> To: Andrew Lunn <>; Keller, Jacob E <>
> Cc: Jiri Pirko <>; Michael Walle <>; Heiner
> Kallweit <>; Russell King <>;
> 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
> Actually maybe there's something in DMTF, does PLDM have standard image
> format? Adding Jake. Not sure if PHYs would use it tho :S

PLDM for Firmware does indeed specify a standardized header for binary images and could be used for PHY firmware. The PLDM header itself describes things as components, where each component gets a record which indicates the version of that component and where in the binary that component exists. Then there are a series of records which determine which sets of components go together and for which devices. I don't think the ice firmware files use the full standard as they always have only a single device record, though the lib/pldmfw codes does try to allow the more expressive ability to support multiple device types from a single binary. Specifying a PHY component would be possible, and you could fairly easily prepend a PLDM firmware header on top of an arbitrary binary.


> 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