Re: PHY firmware update method

[Michael Walle <michael@walle.cc>]

Am 2023-01-31 17:29, schrieb Russell King (Oracle):
> On Tue, Jan 31, 2023 at 05:10:08PM +0100, Michael Walle wrote:
>> Am 2023-01-24 21:42, schrieb Andrew Lunn:
>> > One device being slow to probe will slow down the probe of that
>> > bus. But probe of other busses should be unaffected. I _guess_ it
>> > might have a global affect on EPROBE_DEFER, the next cycle could be
>> > delayed?  Probably a question for GregKH, or reading the code.
>> >
>> > If it going to be really slow, then i would suggest making use of
>> > devlink and it being a user initiated operation.
>> 
>> One concern which raised internally was that you'll always do
>> the update (unconditionally) if there is a newer version. You seem
>> to make life easier for the user, because the update just runs
>> automatically. OTHO, what if a user doesn't want to update (for
>> whatever reason) to the particular version in linux-firmware.git.
>> I'm undecided on that.
> 
> On one hand, the user should always be asked whether they want to
> upgrade the firmware on their systems, but there is the argument
> about whether a user has sufficient information to make an informed
> choice about it.
> 
> Then there's the problem that a newer firmware might introduce a
> bug, but the user wants to use an older version (which is something
> I do with some WiFi setups, and it becomes a pain when linux-firmware
> is maintained by the distro, but you don't want to use that provided
> version.
> 
> I really don't like the idea of the kernel automatically updating
> non-volatile firmware - that sounds to me like a recipe for all
> sorts of disasters.

I agree. That leaves us with the devlink solution, right?

Where would the firmware be stored, fwupd.org was mentioned by
Jakub, or is it the users responsibility to fetch it from the
vendor? Andrew was against adding a firmware update mechanism
without having the binaries.

-michael