On 02/23/2016 03:06 AM, Johannes Berg wrote:
On Thu, 2016-02-18 at 13:54 -0800, Ben Greear wrote:
Yeah, it does, at least if you assume that the capabilities can
actually change. We assume they don't though, hostapd/wpa_s for
example will never re-query them after startup.
Restarting supplicant, even if it came to that, might be less
of an issue than having to re-create the vdev to have it grab
proper new settings from the wiphy...
Well, it would be easy enough to make a method that updated an
vdev/sdata->vht from wiphy, so could just call that as needed (ie,
when certain things set or are changed by wiphy).
Yeah, I think we'll just have to deal with this when it comes along.
This multi-antenna-sharing case (unfortunately I forgot who was talking
about it) is the only thing that comes to mind where we really may have
to deal with this.
I started looking at making these changes...and I have a few questions.
First, are you proposing that I make a copy of the entire
local->hw.wiphy->bands array
and store it locally in sdata?
And then, I would provide some API to modify the bands[i]->bitrates and other
variables to properly select the advertised features?
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.
Or, did I mis-understand your suggestion with regards to what data structures
should be copied to sdata in mac80211 and then made modifiable?
With regard to my original patch, are there any other things that I could do to
make it more acceptable without making copies of the driver data?
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
