netdev - Re: How to load config info before loading firmware?

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]

Message-ID: <53B02681.3080304@gmail.com>
Date:	Sun, 29 Jun 2014 17:45:21 +0300
From:	Amir Vadai <amirv.mellanox@...il.com>
To:	Ben Greear <greearb@...delatech.com>,
	netdev <netdev@...r.kernel.org>
CC:	Yevgeny Petrilin <yevgenyp@...lanox.com>,
	Or Gerlitz <ogerlitz@...lanox.com>, tzahio@...lanox.com,
	Shannon Nelson <shannon.nelson@...el.com>
Subject: Re: How to load config info before loading firmware?

On 6/16/2014 7:02 PM, Ben Greear wrote:
> It would be nice to be able to configure some info before
> loading firmware on at least the ath10k NIC.  The problem is,
> there is no debugfs available before loading firmware, ethtool
> would at best require restarting the NIC/firmware, and loading
> binary config blobs attached to firmware is unpleasant.
> 
> Module parameters are generally frowned upon and may be difficult
> to implement properly if we have multiple NICs with different
> desired configuration in a single machine.
> 
> Are there any suggestions on how to do this sort of config?
> 
> Any other drivers currently allowing such things?
> 
> Thanks,
> Ben
> 

Hi,

Yes, we're hitting the same problem in our drivers (mlx4_en, mlx4_core
and mlx4_ib).
There are some settings that need to be set before our NIC is
initialized, and currently the only way to pass it is using module
parameters.
As you, I need to understand if this is a common problem to other
vendors, or something we need to solve in the scope of our driver.

We're scratching our heads for months now to find a solution.
Shannon Nelson from Intel suggested in the past [1] to use a mechanism
similar to request_firmware() to load persistent configuration. It was
rejected by Greg K-H, saying it is abusing the request_firmware() and
shouldn't use "configuration files" for kernel.
Greg suggested to use configfs for that.

It seems that there is a need for a generic solution to have persistent
configurations (like module param), while fixing the problems of module
params, in which the most important as I see it is to have configuration
for a device and not for a driver - could have few
  NIC's with different configurations using the same driver.

We started playing with a POC to use configfs for that, in a similar way
usb gadgets are doing.

For example: the user wants to set a parameter ('dmfs' for instance) on
a device (identified by 11:22:33) that uses the device driver mlx4_core.

# mkdir /sys/kernel/config/devices/mlx4.11:22:33
# ls /sys/kernel/config/devices/mlx4.11:22:33/
dmfs port_type
# echo 1 > /sys/kernel/config/devices/mlx4.11:22:33/dmfs
# modprobe mlx4_core

Explanation: when mkdir is called in config/devices, the device
configuration API will call request_module('dev_c_mlx4') - name of
module is extracted from the directory name.
dev_c_mlx4 will specify the configfs tree for this type of device,  do
the necessary validations on user inputs and supply a query function to
the main driver (mlx4_core) to access those parameters.

This is the general scheme of the solution we thought of.
I would be happy to get feedback about this approach before starting to
do a more in depth design.

Thanks,
Amir

[1] - https://lkml.org/lkml/2013/1/10/606
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html