netdev - Re: [PATCH net-next] cxgb4: Add support to flash firmware config image

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:   Sun, 2 Aug 2020 22:42:28 +0530
From:   Rahul Lakkireddy <rahul.lakkireddy@...lsio.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Ganji Aravind <ganji.aravind@...lsio.com>, netdev@...r.kernel.org,
        davem@...emloft.net, vishal@...lsio.com
Subject: Re: [PATCH net-next] cxgb4: Add support to flash firmware config
 image

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
use-case.

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.

hw_sge_reg_1008=0x40800
hw_sge_reg_100c=0x22222222
hw_sge_reg_10a0=0x01040810
hw_tp_reg_7d04=0x00010000
hw_tp_reg_7dc0=0x0e2f8849

and so on.

Thanks,
Rahul