Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2016-02-04 at 09:52 -0800, Ben Greear wrote:
> On 02/04/2016 01:02 AM, Johannes Berg wrote:
> > On Tue, 2016-01-26 at 07:19 -0800, Ben Greear wrote:
> > 
> > > As far as I can tell, that will not work, because I want to have
> > > multiple station devices per radio, and have each of them be able
> > > to
> > > use a different configuration.  So, one station may be /g, and
> > > another /n and another /AC.  Same with APs.  In addition, some
> > > stations may want to use all available rates for their mode, and
> > > others may want to use a fixed rate or subset of available rates.
> > 
> > So let's agree that we're splitting the *used* rates (which we have
> > today) and the *advertised* rates/modes/...
> 
> Yes, I think that will work well, and unless I mis-understand, that
> is basically what I implemented so far.

Yes.

> Copied state might be tricky.  I think if we hold any copies of
> capabilities data in the sdata, then it should be logically compared
> with a mask and then treated as an AND with whatever the wiphy has.

Not sure what you're saying here. I was thinking we'd simply do one of
these two:

1) sdata->sband[5GHZ].vht = wiphy->sband[5GHZ].vht & user-config
   (semantically, not implementation of course)
2) sdata->sband[5GHZ].vht = wiphy->sband[5GHZ].vht

and change mac80211 to use sdata->sband instead of wiphy->sband
wherever the latter is used today. That way, we can avoid touching all
these things.

I think, for example, that you missed TDLS in your changes. Changing
everything throughout would mean that grepping for "wiphy->sband" would
immediately show such bugs, making it far easier to maintain.

>   I'm reluctant to propose any serious mac80211 change at this point,
> though perhaps as more of this type of features are added, then it
> will become more obvious how to nicely consolidate things in
> mac80211.

I don't really think this would be a "serious" change? It's basically
pointering changes, you could (and perhaps should, to catch it all) use
an spatch to make the initial change.

> To be honest, I thought my -v2 patches were fairly non-invasive
> compared to my normal hackings :)
> 

:)

johannes