Per radio configuration

Ben Greear greearb at
Thu Mar 3 08:41:49 PST 2016

On 03/03/2016 07:35 AM, Valo, Kalle wrote:
> Ben Greear <greearb at> writes:
>> Hello!
>> I'm considering a case where I have multiple ath10k NICs in
>> a system, possibly not all the same chipset.
>> I may want to have one optimized for smaller number of vdevs and more
>> peers, and another many vdevs, fewer peers, etc.  Some chipsets
>> Module options are not optimal for this since there is no easy way to
>> have different options for different NICs.
>> I'm thinking about making a loadable 'firmware' file that has
>> text-based config, something like:
>> # First radio
>> Device=05:00.0
>> 	vdev_count=8
>> 	peer_count=128
>>          firmware_name=firmware-5-b.bin
>> 	firmware_ver=5
>> # Second radio
>> Device=06:00.0
>> 	vdev_count=4
>> 	peer_count=200
>>          firmware_name=firmware-2.bin
>> 	firmware_ver=2
>> # End of file
> Ok, so basically an .ini file for the driver.
>> When parsing, Lines starting with # would be ignored.
>> Any un-known tokens would be ignored, for backwards/forwards compatibility.
>> This file would be loaded and parsed before loading other firmware
>> images so that we can use particular firmware images per radio. This
>> further lets one optimize one radio for one thing, one for another.
>> For instance, if someone requires IBSS and wants to use stock QCA
>> firmware, they can use the 'main' firmware for that radio, and the
>> most recent one for another radio that needs to be a stable AP.
>> In addition to this, we would need to store the vdev combinations
>> in RAM in the 'ar' struct, so we could get rid of all of the static,
>> hard-coded members and set the capabilities to match the requested
>> values.
>> Any opinions on this?  Something that might be worthwhile for upstream?
> I have seen lots of out-of-tree drivers having something like this but I
> doubt that something like this would be acceptable in upstream. Anyway
> this is something which should be discussed in linux-wireless with a
> wider audience, maybe even in lkml.

You are the maintainer, so, do *you* like the idea?  If you don't, then
there is no use in me putting more effort into it for upstream use.

If you do, then I will work on cleaning up a patch for upstream and post
it to a wider audience.


Ben Greear <greearb at>
Candela Technologies Inc

More information about the ath10k mailing list