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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200803141304.79a7d05f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 3 Aug 2020 14:13:04 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Rahul Lakkireddy <rahul.lakkireddy@...lsio.com>
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 Sun, 2 Aug 2020 22:42:28 +0530 Rahul Lakkireddy wrote:
> 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.

I have no details on what you're actually storing in the config, 
and I don't care what your format is.

If it's a configuration parameter - it needs a proper API.

If it's a low level board param or such - it doesn't need a separate
flashable partition and can come with the rest of FW.

I know the firmware flashing interface is a lovely, binary, opaque
interface which vendors love. We'll not entertain this kind of abuse.

Nacked-by: Jakub Kicinski <kuba@...nel.org>