Date:	Fri, 25 Jul 2014 17:36:26 +0000
From:	"Nelson, Shannon" <shannon.nelson@...el.com>
To:	"amirv@...lanox.com" <amirv@...lanox.com>,
	Ben Greear <greearb@...delatech.com>,
	netdev <netdev@...r.kernel.org>
CC:	Yevgeny Petrilin <yevgenyp@...lanox.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	"tzahio@...lanox.com" <tzahio@...lanox.com>
Subject: RE: How to load config info before loading firmware?

> From: Amir Vadai [mailto:amirv.mellanox@...il.com]
> Sent: Sunday, June 29, 2014 7:45 AM
> 
> 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

Thanks, Amir, for pointing this discussion at me.  Sorry I'm so late at getting back, I was on vacation, etc...

Yes, the configfs constructs are part of the "correct" solution as GregKH pointed out to us.  This can take care of several of the situations we had thought about, but not all.  This works fine for the port-specific configurations where the driver creates the port instance, and then userland has some opportunity to configure via udev event driven scripts before enabling the communication link.  This doesn't work for configuration info needed before the driver can create a configfs object.

The real problem we were trying to solve with our (ab)use of the request_firmware() infrastructure was how to do very early driver configuration.  There are some early driver initialization steps (PCI setup options, interrupt reservations, certain HW init) that could use configuration information long before the udev, sysfs, network stack, or other connections can be made.  This is what the module parameters historically gave us.  With the de-emphasis of module parameters, we're lacking a similar early configuration opportunity.

In our case, we found ways to work around and do without it, tho' we're still missing a couple of things.  Perhaps forcing a change in design models is a good thing, but I believe there are still valid situations where this kind of early config would be beneficial.  

sln

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

Powered by blists - more mailing lists