All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFCv2 6/6] mac80211: IBSS setup correctly BW for VHT
Date: Fri, 16 Jan 2015 13:18:24 +0100	[thread overview]
Message-ID: <1421410704.9214.10.camel@sipsolutions.net> (raw)
In-Reply-To: <CALhHN=pkvz9qiQNWvXF6xwfhpmmhbUaW0PVnOWDhgWYT0nVY=w@mail.gmail.com> (sfid-20150116_130825_163251_43ACF8D0)

On Fri, 2015-01-16 at 13:08 +0100, Janusz Dziedzic wrote:
> On 16 January 2015 at 11:55, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Fri, 2015-01-16 at 11:38 +0100, Janusz Dziedzic wrote:
> >
> >> +                             /* we both use VHT */
> >> +                             struct ieee80211_vht_cap vhtcap_ie;
> >> +                             struct ieee80211_sta_vht_cap vht_cap = sta->sta.vht_cap;
> >> +
> >> +                             ieee80211_vht_oper_to_chandef(channel,
> >> +                                                           elems->vht_operation,
> >> +                                                           &chandef);
> >
> > Ok maybe I'm missing something - but can't this erroneously configure
> > the local HW to 160 MHz when it doesn't even support it, or so?
> >
> I will check this more. But seems chandef (sta chandef) is a local
> variable here, not used by the way.
> So, our chandef is form cfg80211 (sdata->u.ibss.chandef) and we don't
> change this.
> Orginaly this sta chandef was used to compare with ibss->chandef.
> 
> -                       if (chandef.center_freq1 !=
> -                           sdata->u.ibss.chandef.center_freq1)
> -                               htcap_ie.cap_info &=
> -
> cpu_to_le16(~IEEE80211_HT_CAP_SUP_WIDTH_20_40);
> 
> But for me this check seems as not needed, eg.
> We support VHT80 and other ibss have only HT40 support - so we will
> have different center_freq1 - but still could operate, while sta_add
> and correct rates for sta configured.
> One I think we could check here is, if our chandef and sta chandef overlap.
> 
> Anyway, I am not sure I understand your question correctly, you mean eg.
> we work in VHT80 mode and other ibss join in VHT160 mode? Does it
> really matter while we will use sta_add for this new V160 "station"
> and configure supported rates for this station?

Well like I said - I might not understand this correctly. But the
ieee80211_vht_oper_to_chandef() function doesn't - iirc - take into
account local capabilities. As a consequence, if a VHT160 station joins
the chandef might be 160 while we're only supporting 80?

But anyway - I see that at least what I originally thought was wrong -
this code isn't concerned with picking up the channel from the peer to
join the networks together, I guess. That's what I was worried about.
That code I haven't seen and checked though - so perhaps you can look
there if it correctly handles trying to form a network when the peer has
higher capabilities than the local hw.

johannes


  reply	other threads:[~2015-01-16 12:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16 10:38 [RFCv2 1/6] mac80211: ibss, fix chandef setup for HT40 Janusz Dziedzic
2015-01-16 10:38 ` [RFCv2 2/6] cfg80211: add VHT support for IBSS Janusz Dziedzic
2015-01-16 10:38 ` [RFCv2 3/6] mac80211: " Janusz Dziedzic
2015-01-16 10:52   ` Johannes Berg
2015-01-16 10:38 ` [RFCv2 4/6] mac80211: IBSS fix scan request Janusz Dziedzic
2015-01-16 10:38 ` [RFCv2 5/6] mac80211: ibss/mesh move bw checking Janusz Dziedzic
2015-01-16 10:38 ` [RFCv2 6/6] mac80211: IBSS setup correctly BW for VHT Janusz Dziedzic
2015-01-16 10:55   ` Johannes Berg
2015-01-16 12:08     ` Janusz Dziedzic
2015-01-16 12:18       ` Johannes Berg [this message]
2015-01-16 12:48         ` Janusz Dziedzic
2015-01-16 10:49 ` [RFCv2 1/6] mac80211: ibss, fix chandef setup for HT40 Johannes Berg
2015-01-16 11:24   ` Janusz Dziedzic
2015-01-16 11:47     ` Johannes Berg
2015-01-16 12:18       ` Janusz Dziedzic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1421410704.9214.10.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=janusz.dziedzic@tieto.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.