Hi Johannes,
On Fri, May 24, 2013 at 2:59 PM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> Sorry for leaving this open for so long. I think it didn't hurt since
> the merge window was open anyway.
>
>> + * @basic_rates: per-band bitmap of basic rates to use when creating the mesh
>
> Does per-band really make sense? The mesh channel is also determined at
> join time.
>
>> static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
>> {
>> struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> @@ -7460,6 +7487,22 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
>> nla_get_u32(info->attrs[NL80211_ATTR_MCAST_RATE])))
>> return -EINVAL;
>>
>> + if (info->attrs[NL80211_ATTR_BSS_BASIC_RATES]) {
>
> I think you should consider allowing this attribute only if the channel
> is also specified (NL80211_ATTR_WIPHY_FREQ, parsed below), and not make
> it nested with rates for both bands but just the selected band.
>
Yes, I think by this approach, we eliminate the need for the user to
provide rates for both bands and also not require to have a per-band
for basic_rates.
Said that, I am wondering why give mcast_rate for both bands, but
basic_rates only for one band?
> johannes
>
--
Ashok Raj Nagarajan,
cozybit Inc.
http://www.cozybit.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
