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  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:   Mon, 28 Nov 2022 15:45:45 -0800
From:   Shannon Nelson <shnelson@....com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Shannon Nelson <snelson@...sando.io>, netdev@...r.kernel.org,
        davem@...emloft.net, mst@...hat.com, jasowang@...hat.com,
        virtualization@...ts.linux-foundation.org, drivers@...sando.io,
        Jacob Keller <jacob.e.keller@...el.com>
Subject: Re: [RFC PATCH net-next 06/19] pds_core: add FW update feature to
 devlink

On 11/28/22 3:33 PM, Jakub Kicinski wrote:
> On Mon, 28 Nov 2022 14:25:46 -0800 Shannon Nelson wrote:
>> I don't think Intel selects which FW image to boot, but it looks like
>> mlxsw and nfp use the PARAM_GENERIC_FW_LOAD_POLICY to select between
>> DRIVER, FLASH, or DISK.  Shall I add a couple of generic SLOT_x items to
>> the enum devlink_param_fw_load_policy_value and use this API?  For example:
>>
>>        DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_SLOT_0,
>>        DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_SLOT_1,
>>        DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_SLOT_2,
>>        DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_SLOT_3,
> 
> Not the worst idea, although I presume normal FW flashing should switch
> between slots to activate the new image by default? Which means the
> action of fw flashing would alter the policy set by the user. A little
> awkward from an API purist standpoint.

Yes, the action of flashing will set the new bank/slot to use on the 
next boot.  However, we have the ability to select from multiple valid 
images and we want to pass this flexibility to the user rather than 
force them to go through a whole flash sequence just to get to the other 
bank.

> 
> I'd just expose the active "bank" via netlink directly.
> 
>> I could then modify the devlink dev info printed to refer to fw_slot_0,
>> fw.slot_1, and fw.slot_2 instead of our vendor specific names.
> 
> Jake, didn't you have a similar capability in ice?
> 
> Knowing my memory I may have acquiesced to something in another driver
> already. That said - I think it's cleaner if we just list the stored
> versions per bank, no?

We are listing the stored images in the devlink dev info output, just 
want to let the user choose which of those valid images to use next.

Cheers,
sln

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ