Re: Per radio configuration

From: "Valo, Kalle" <kvalo@qca.qualcomm.com>
To: Ben Greear <greearb@candelatech.com>
Cc: ath10k <ath10k@lists.infradead.org>
Subject: Re: Per radio configuration
Date: Thu, 3 Mar 2016 15:35:48 +0000	[thread overview]
Message-ID: <877fhj3774.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <56B3BCF0.7070408@candelatech.com> (Ben Greear's message of "Thu,  4 Feb 2016 13:04:48 -0800")

Ben Greear <greearb@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.

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k