On 03/15/2016 07:15 AM, Johannes Berg wrote:
On Thu, 2016-03-10 at 09:56 -0800, Ben Greear wrote:
First, are you proposing that I make a copy of the entire local-
hw.wiphy->bands array and store it locally in sdata?
No, I think it should be pointers there, say
sdata->bands[X] pointing to the same thing as local->hw.wiphy->bands[X]
is pointing to.
So the first patch would introduce that, and replace each and every use
of local->hw.wiphy->bands[] with sdata->bands[], if necessary
annotating the remaining ones with why they're OK and should stay.
And then, I would provide some API to modify the bands[i]->bitrates
and other variables to properly select the advertised features?
Kinda. You'd provide some kind of helper function or API to take the
local->hw.wiphy->bands[X] and duplicate it into a newly allocated
buffer, modifying it along the way, before assigning it to the per-
sdata stuff in sdata->bands[X].
I am a bit concerned about making copies (and then changing) the
driver's bitrates array. Likely it will work with ath10k, but it
seems fragile at best.
That's an interesting point, we currently use the rate *index* a lot,
so we have to find some way of preserving that. Perhaps we need to
introduce a flag indicating a given rate is disabled?
The logic I wrote is basically exactly this. It uses the configured rates to
specify which of the hardware's rates are allowed and disabled.
I will look more at providing some accessor functions or otherwise abstracting
it without making copies of the driver's ratesets.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
