lists.openwall.net   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  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 <snelson@...sando.io>
To:     Jakub Kicinski <kuba@...nel.org>,
        Jacob Keller <jacob.e.keller@...el.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net
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.

sln

Powered by blists - more mailing lists