On Fri, Jul 6, 2012 at 9:59 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
> On Thu, 2012-07-05 at 14:25 +0300, Arik Nemtsov wrote:
>
>> > Yuck. Why use the union at all? You could just put the ht_cap_invalid
>> > into the ht_cap struct, and it wouldn't even take space, there's
>> > padding :-)
>>
>> The point is - we still want to use ht_cap.ht_supported, even when
>> ht_cap is invalid. I was afraid there would be some confusion, hence
>> one can set:
>> band.ht_supported = true;
>> band.ht_cap_invalid = false;
>>
>> And the union means we don't have to change old drivers.
>>
>> Also putting ht_cap_invalid inside the struct creates strange corner
>> cases. One could mark the vif ht_cap as invalid as well, but the code
>> would just ignore it.
>
> Good point. But then let's just move it out and change drivers ...
> that's much cleaner I think.
You mean move out ht_supported?
>
>
>> >> @@ -30,13 +31,16 @@ rdev_freq_to_chan(struct cfg80211_registered_device *rdev,
>> >> chan->flags & IEEE80211_CHAN_NO_HT40PLUS)
>> >> return NULL;
>> >>
>> >> - ht_cap = &rdev->wiphy.bands[chan->band]->ht_cap;
>> >> + sband = rdev->wiphy.bands[chan->band];
>> >> + ht_cap = &sband->ht_cap;
>> >>
>> >> if (channel_type != NL80211_CHAN_NO_HT) {
>> >> - if (!ht_cap->ht_supported)
>> >> + if (!sband->ht_supported)
>> >> return NULL;
>> >>
>> >> - if (channel_type != NL80211_CHAN_HT20 &&
>> >> + /* this check is ignored when per-band HT caps are not used */
>> >> + if (!sband->ht_cap_invalid &&
>> >> + channel_type != NL80211_CHAN_HT20 &&
>> >
>> > This is also major confusion, it seems you should roll 2/3 into one
>> > patch?
>>
>> I'm not sure that would help. rdev_freq_to_chan doesn't get the
>> net_device, so it can't get the HT caps. I guess I can add the
>> net_device as an optional argument where it is used and check the
>> caps. OTOH it seem like a sanity check we can do without?
>
> I don't think we should do without that check? If you request say AP
> operation on 40 MHz then you absolutely rely on that happening or
> returning an error, not randomly operating in legacy mode!
Sure. I'll send the netdev to the function where possible (I think
everywhere except the virtual monitor).
--
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
