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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 30 Sep 2022 07:45:46 -0700
From:   Jakub Kicinski <>
To:     Andrew Lunn <>,
        Jacob Keller <>
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

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