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  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:   Mon, 14 Sep 2020 16:47:13 -0700
From:   Shannon Nelson <>
To:     Jakub Kicinski <>,
        Jacob Keller <>
Subject: Re: [PATCH v3 net-next 2/2] ionic: add devlink firmware update

On 9/14/20 4:36 PM, Jakub Kicinski wrote:
> On Mon, 14 Sep 2020 16:15:28 -0700 Jacob Keller wrote:
>> On 9/10/2020 10:56 AM, Jakub Kicinski wrote:
>>> IOW drop the component parameter from the normal helper, cause almost
>>> nobody uses that. The add a more full featured __ version, which would
>>> take the arg struct, the struct would include the timeout value.
>> I would point out that the ice driver does use it to help indicate which
>> section of the flash is currently being updated.
>> i.e.
>> $ devlink dev flash pci/0000:af:00.0 file firmware.bin
>> Preparing to flash
>> [fw.mgmt] Erasing
>> [fw.mgmt] Erasing done
>> [fw.mgmt] Flashing 100%
>> [fw.mgmt] Flashing done 100%
>> [fw.undi] Erasing
>> [fw.undi] Erasing done
>> [fw.undi] Flashing 100%
>> [fw.undi] Flashing done 100%
>> [fw.netlist] Erasing
>> [fw.netlist] Erasing done
>> [fw.netlist] Flashing 100%
>> [fw.netlist] Flashing done 100%
>> I'd like to keep that, as it helps tell which component is currently
>> being updated. If we drop this, then either I have to manually build
>> strings which include the component name, or we lose this information on
>> display.
> Thanks for pointing that out. My recollection was that ice and netdevsim
> were the only two users, so I thought those could use the full __*
> helper and pass an arg struct. But no strong feelings.

Thanks, both.

I'd been going back and forth all morning about whether a simple single 
timeout or a timeout for each "chunk" would be appropriate. I'll try to 
be back in another day or three with an RFC.


Powered by blists - more mailing lists