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  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, 29 Jun 2014 17:45:21 +0300
From:	Amir Vadai <>
To:	Ben Greear <>,
	netdev <>
CC:	Yevgeny Petrilin <>,
	Or Gerlitz <>,,
	Shannon Nelson <>
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


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


[1] -
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists