Re: PHY firmware update method

[Michael Walle <michael@walle.cc>]

[sorry for the very late response, but I was working on getting an
acceptable license for the PHY binary in the meantime]

>> 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?

In my case, the firmware binary blob has some static offset to get
firmware version (I need to double check that one with the vendor).
Of course we could put that PLDM thingy around it. But it seems we are
mangling with the binary provided by the vendor before putting it into
linux-firmware.git. If I understand Jacob correct, Intel will already
provide the binaries in PLDM format.

Another problem I see is how we can determine if a firmware update
is possible at all - or if we just try it anyway if that is possible.
In my case there is already an integrated firmware and the external
flash is optional. The PHY will try to boot from external flash and
fall back to the internal one. AFAIK you can read out where the PHY
was booted from. If the external flash is empty, you cannot detect if
you could update the firmware.

So if you'd do this during the PHY probe, it might try to update the
firmware on every boot and fail. Would that be acceptable?

How long could can a firmware update during probe run? Do we need
to do it in the background with the PHY being offline. Sounds like
not something we want.

-michael