Per radio configuration

[Ben Greear]

On 03/03/2016 07:35 AM, Valo, Kalle wrote:
> Ben Greear <greearb at candelatech.com> 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.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com