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:   Sun, 2 Aug 2020 22:42:28 +0530
From:   Rahul Lakkireddy <>
To:     Jakub Kicinski <>
Cc:     Ganji Aravind <>,,,
Subject: Re: [PATCH net-next] cxgb4: Add support to flash firmware config

On Saturday, August 08/01/20, 2020 at 21:22:02 -0700, Jakub Kicinski wrote:
> On Sat, 1 Aug 2020 02:47:38 +0530 Rahul Lakkireddy wrote:
> > I thought /lib/firmware is where firmware related files need to be
> > placed and ethtool --flash needs to be used to program them to
> > their respective locations on adapter's flash.
> Our goal is to provide solid, common interfaces for Linux users to rely
> on. Not give way to vendor specific "solutions" like uploading ini files
> to perform device configuration.
> > Note that we don't have devlink support in our driver yet. And,
> > we're a bit confused here on why this already existing ethtool
> > feature needs to be duplicated to devlink.
> To be clear - I'm suggesting the creation of a more targeted APIs 
> to control the settings you have encoded _inside_ the ini file. 
> Not a new interface for an whole sale config upload.
> Worst case scenario - if the settings are really device specific 
> you can try to use devlink device parameters.

The config file contains very low-level firmware and device specific
params and most of them are dependent on the type of Chelsio NIC.
The params are mostly device dependent register-value pairs.
We don't see users messing around with the params on their own
without consultation. The users only need some mechanism to flash
the custom config file shared by us on to their adapter. After
device restart, the firmware will automatically pick up the flashed
config file and redistribute the resources, as per their requested

We're already foreseeing very long awkward list (more than 50 params)
for mapping the config file to devlink-dev params and are hoping this
is fine. Here's a sample on how it would look.


and so on.


Powered by blists - more mailing lists