On Monday, August 08/03/20, 2020 at 14:13:04 -0700, Jakub Kicinski wrote: > 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 <k...@kernel.org>
Sure, will drop the patch for now and revisit again, as part of devlink or better API. Thanks, Rahul