| Message ID | 1456180974-21062-1-git-send-email-greearb@candelatech.com (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Johannes Berg |
| Headers | show |
Hi Ben, On Tue, Feb 23, 2016 at 9:42 AM, <greearb@candelatech.com> wrote: > From: Ben Greear <greearb@candelatech.com> > > ath10k supports VHT on 2.4Ghz band. > If supplicant and hostapd and radio think > VHT should be allowed, then kernel should let them > try. > > Signed-off-by: Ben Greear <greearb@candelatech.com> > --- > net/mac80211/mlme.c | 16 ---------------- > net/mac80211/util.c | 13 +------------ > net/mac80211/vht.c | 15 --------------- > 3 files changed, 1 insertion(+), 43 deletions(-) > > diff --git a/net/mac80211/util.c b/net/mac80211/util.c > index f8eb0f8..cabe16f 100644 > --- a/net/mac80211/util.c > +++ b/net/mac80211/util.c > @@ -1604,17 +1603,7 @@ static int ieee80211_build_preq_ies_band(struct ieee80211_local *local, > *offset = noffset; > } > > - /* Check if any channel in this sband supports at least 80 MHz */ > - for (i = 0; i < sband->n_channels; i++) { > - if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED | > - IEEE80211_CHAN_NO_80MHZ)) > - continue; > - > - have_80mhz = true; > - break; > - } > - > - if (sband->vht_cap.vht_supported && have_80mhz && !disable_vht) { > + if (sband->vht_cap.vht_supported && /*have_80mhz &&*/ !disable_vht) { Do you want to actually remove have_80mhz here? We do have git history if this needs to be put back. Thanks,
On 02/22/2016 02:48 PM, Julian Calaby wrote: > Hi Ben, > > On Tue, Feb 23, 2016 at 9:42 AM, <greearb@candelatech.com> wrote: >> From: Ben Greear <greearb@candelatech.com> >> >> ath10k supports VHT on 2.4Ghz band. >> If supplicant and hostapd and radio think >> VHT should be allowed, then kernel should let them >> try. >> >> Signed-off-by: Ben Greear <greearb@candelatech.com> >> --- >> net/mac80211/mlme.c | 16 ---------------- >> net/mac80211/util.c | 13 +------------ >> net/mac80211/vht.c | 15 --------------- >> 3 files changed, 1 insertion(+), 43 deletions(-) >> >> diff --git a/net/mac80211/util.c b/net/mac80211/util.c >> index f8eb0f8..cabe16f 100644 >> --- a/net/mac80211/util.c >> +++ b/net/mac80211/util.c >> @@ -1604,17 +1603,7 @@ static int ieee80211_build_preq_ies_band(struct ieee80211_local *local, >> *offset = noffset; >> } >> >> - /* Check if any channel in this sband supports at least 80 MHz */ >> - for (i = 0; i < sband->n_channels; i++) { >> - if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED | >> - IEEE80211_CHAN_NO_80MHZ)) >> - continue; >> - >> - have_80mhz = true; >> - break; >> - } >> - >> - if (sband->vht_cap.vht_supported && have_80mhz && !disable_vht) { >> + if (sband->vht_cap.vht_supported && /*have_80mhz &&*/ !disable_vht) { > > Do you want to actually remove have_80mhz here? We do have git history > if this needs to be put back. Yes, I just missed that when cleaning up my patch. I'll wait for some other feedback and then do a -v2. Thanks, Ben
On Tue, Feb 23, 2016 at 12:42 AM, <greearb@candelatech.com> wrote: > > From: Ben Greear <greearb@candelatech.com> > > ath10k supports VHT on 2.4Ghz band. > If supplicant and hostapd and radio think > VHT should be allowed, then kernel should let them > try. Removing the 80Mhz check entirely is not the right way to go IMO. The check is there because there are countries where VHT rates are not allowed, even on 20MHz channels. We use the fact these countries have no 80MHz-allowed ranges as a crude regulatory hint to disable VHT entirely. I'm not sure about the regulatory landscape in these countries regarding VHT in 2.4GHz, but please don't break compliance for the 5Ghz use-case. Arik -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/23/2016 02:47 AM, Arik Nemtsov wrote: > On Tue, Feb 23, 2016 at 12:42 AM, <greearb@candelatech.com> wrote: >> >> From: Ben Greear <greearb@candelatech.com> >> >> ath10k supports VHT on 2.4Ghz band. >> If supplicant and hostapd and radio think >> VHT should be allowed, then kernel should let them >> try. > > Removing the 80Mhz check entirely is not the right way to go IMO. The > check is there because there are countries where VHT rates are not > allowed, even on 20MHz channels. We use the fact these countries have > no 80MHz-allowed ranges as a crude regulatory hint to disable VHT > entirely. I'm not sure about the regulatory landscape in these > countries regarding VHT in 2.4GHz, but please don't break compliance > for the 5Ghz use-case. Maybe someone can fix the regulatory logic then? Add a no-vht flag or whatever? Any idea which countries this applies to? Thanks, Ben
On Mon, 2016-02-22 at 14:42 -0800, greearb@candelatech.com wrote: > From: Ben Greear <greearb@candelatech.com> > > ath10k supports VHT on 2.4Ghz band. It can't. At least not formally, as this sentence is written, since VHT per the spec requires operating on the 5 GHz band, and it also requires 80 MHz bandwidth which isn't even available in 2.4 GHz in many countries. What you really "want" is to use VHT modulations, mostly for the dubious purpose of marketing benchmarks to reach 256-QAM modulations. I think the de-facto standard for this would be to use IEs similar to VHT ones, encapsulated in some (Broadcom?) vendor IE. We may have to work with that, but that's not what this patch does. Jouni had some better idea how this worked, I think. Also, as written, this patch has practically no effect because no driver can or should advertise real VHT support on 2.4 GHz band, even if the code structure were to allow that. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/23/2016 06:10 AM, Johannes Berg wrote: > On Mon, 2016-02-22 at 14:42 -0800, greearb@candelatech.com wrote: >> From: Ben Greear <greearb@candelatech.com> >> >> ath10k supports VHT on 2.4Ghz band. > > It can't. At least not formally, as this sentence is written, since VHT > per the spec requires operating on the 5 GHz band, and it also requires > 80 MHz bandwidth which isn't even available in 2.4 GHz in many > countries. > > What you really "want" is to use VHT modulations, mostly for the > dubious purpose of marketing benchmarks to reach 256-QAM modulations. > > I think the de-facto standard for this would be to use IEs similar to > VHT ones, encapsulated in some (Broadcom?) vendor IE. We may have to > work with that, but that's not what this patch does. Jouni had some > better idea how this worked, I think. > > Also, as written, this patch has practically no effect because no > driver can or should advertise real VHT support on 2.4 GHz band, even > if the code structure were to allow that. I don't recall making any changes to ath10k driver or firmware that would enable VHT on 2.4, but it is there anyway in the 4.4 kernel. I tested my patch, and I see 600Mbps tx rates (and other VHT encodings) reported, and vht_capa shows up as expected, so I think it must be at least partially working. [root@ben-ota2 lanforge]# iw phy wiphy0 info Wiphy wiphy0 max # scan SSIDs: 16 max scan IEs length: 195 bytes max # sched scan SSIDs: 0 max # match sets: 0 Retry short limit: 7 Retry long limit: 4 Coverage class: 0 (up to 0m) Device supports RSN-IBSS. Device supports AP-side u-APSD. Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP (00-0f-ac:4) * CMAC (00-0f-ac:6) Available Antennas: TX 0x7 RX 0x7 Configured Antennas: TX 0x7 RX 0x7 Supported interface modes: * IBSS * managed * AP * AP/VLAN * monitor * mesh point * P2P-client * P2P-GO * P2P-device Band 1: Capabilities: 0x19ef RX LDPC HT20/HT40 SM Power Save disabled RX HT20 SGI RX HT40 SGI TX STBC RX STBC 1-stream Max AMSDU length: 7935 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 8 usec (0x06) HT TX/RX MCS rate indexes supported: 0-23 VHT Capabilities (0x338001b2): Max MPDU length: 11454 Supported Channel Width: neither 160 nor 80+80 RX LDPC short GI (80 MHz) TX STBC RX antenna pattern consistency TX antenna pattern consistency VHT RX MCS set: 1 streams: MCS 0-9 2 streams: MCS 0-9 3 streams: MCS 0-9 4 streams: not supported 5 streams: not supported 6 streams: not supported 7 streams: not supported 8 streams: not supported VHT RX highest supported: 0 Mbps VHT TX MCS set: 1 streams: MCS 0-9 2 streams: MCS 0-9 3 streams: MCS 0-9 4 streams: not supported 5 streams: not supported 6 streams: not supported 7 streams: not supported 8 streams: not supported VHT TX highest supported: 0 Mbps Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps (short preamble supported) * 5.5 Mbps (short preamble supported) * 11.0 Mbps (short preamble supported) * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 2412 MHz [1] (30.0 dBm) * 2417 MHz [2] (30.0 dBm) * 2422 MHz [3] (30.0 dBm) * 2427 MHz [4] (30.0 dBm) * 2432 MHz [5] (30.0 dBm) * 2437 MHz [6] (30.0 dBm) * 2442 MHz [7] (30.0 dBm) * 2447 MHz [8] (30.0 dBm) * 2452 MHz [9] (30.0 dBm) * 2457 MHz [10] (30.0 dBm) * 2462 MHz [11] (30.0 dBm) * 2467 MHz [12] (disabled) * 2472 MHz [13] (disabled) * 2484 MHz [14] (disabled) Band 2: Capabilities: 0x19ef RX LDPC HT20/HT40 SM Power Save disabled RX HT20 SGI RX HT40 SGI TX STBC RX STBC 1-stream Max AMSDU length: 7935 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 8 usec (0x06) HT TX/RX MCS rate indexes supported: 0-23 VHT Capabilities (0x338001b2): Max MPDU length: 11454 Supported Channel Width: neither 160 nor 80+80 RX LDPC short GI (80 MHz) TX STBC RX antenna pattern consistency TX antenna pattern consistency VHT RX MCS set: 1 streams: MCS 0-9 2 streams: MCS 0-9 3 streams: MCS 0-9 4 streams: not supported 5 streams: not supported 6 streams: not supported 7 streams: not supported 8 streams: not supported VHT RX highest supported: 0 Mbps VHT TX MCS set: 1 streams: MCS 0-9 2 streams: MCS 0-9 3 streams: MCS 0-9 4 streams: not supported 5 streams: not supported 6 streams: not supported 7 streams: not supported 8 streams: not supported VHT TX highest supported: 0 Mbps Bitrates (non-HT): * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 5180 MHz [36] (17.0 dBm) * 5200 MHz [40] (17.0 dBm) * 5220 MHz [44] (17.0 dBm) * 5240 MHz [48] (17.0 dBm) * 5260 MHz [52] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 49710 sec) DFS CAC time: 60000 ms * 5280 MHz [56] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 49710 sec) DFS CAC time: 60000 ms * 5300 MHz [60] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 49710 sec) DFS CAC time: 60000 ms * 5320 MHz [64] (23.0 dBm) (no IR, radar detection) DFS state: usable (for 49710 sec) DFS CAC time: 60000 ms * 5500 MHz [100] (disabled) * 5520 MHz [104] (disabled) * 5540 MHz [108] (disabled) * 5560 MHz [112] (disabled) * 5580 MHz [116] (disabled) * 5600 MHz [120] (disabled) * 5620 MHz [124] (disabled) * 5640 MHz [128] (disabled) * 5660 MHz [132] (disabled) * 5680 MHz [136] (disabled) * 5700 MHz [140] (disabled) * 5720 MHz [144] (disabled) * 5745 MHz [149] (30.0 dBm) * 5765 MHz [153] (30.0 dBm) * 5785 MHz [157] (30.0 dBm) * 5805 MHz [161] (30.0 dBm) * 5825 MHz [165] (30.0 dBm) Supported commands: * new_interface * set_interface * new_key * start_ap * new_station * new_mpath * set_mesh_config * set_bss * authenticate * associate * deauthenticate * disassociate * join_ibss * join_mesh * remain_on_channel * set_tx_bitrate_mask * frame * frame_wait_cancel * set_wiphy_netns * set_channel * set_wds_peer * probe_client * set_noack_map * register_beacons * start_p2p_device * set_mcast_rate * testmode * channel_switch * set_qos_map * connect * disconnect Supported TX frame types: * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 Supported RX frame types: * IBSS: 0x40 0xb0 0xc0 0xd0 * managed: 0x40 0xd0 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * mesh point: 0xb0 0xc0 0xd0 * P2P-client: 0x40 0xd0 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * P2P-device: 0x40 0xd0 software interface modes (can always be added): * AP/VLAN * monitor valid interface combinations: * #{ managed, P2P-client } <= 64, #{ P2P-GO } <= 3, #{ AP } <= 7, #{ IBSS } <= 1, total <= 64, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz } HT Capability overrides: * MCS: ff ff ff ff ff ff ff ff ff ff * maximum A-MSDU length * supported channel width * short GI for 40 MHz * max A-MPDU length exponent * min MPDU start spacing Device supports TX status socket option. Device supports HT-IBSS. Device supports SAE with AUTHENTICATE command Device supports scan flush. Device supports per-vif TX power setting Driver supports a userspace MPM Driver/device bandwidth changes during BSS lifetime (AP/GO mode) Device supports static SMPS Device supports configuring vdev MAC-addr on create. Device supports VHT-IBSS. [root@ben-ota2 lanforge]# Thanks, Ben
On Tue, 2016-02-23 at 06:18 -0800, Ben Greear wrote: > [root@ben-ota2 lanforge]# iw phy wiphy0 info > Wiphy wiphy0 > > Band 1: [...] > VHT Capabilities (0x338001b2): > Max MPDU length: 11454 > Supported Channel Width: neither 160 nor 80+80 > RX LDPC > short GI (80 MHz) > TX STBC > RX antenna pattern consistency > TX antenna pattern consistency > VHT RX MCS set: > 1 streams: MCS 0-9 > 2 streams: MCS 0-9 > 3 streams: MCS 0-9 > 4 streams: not supported > 5 streams: not supported > 6 streams: not supported > 7 streams: not supported > 8 streams: not supported > VHT RX highest supported: 0 Mbps > VHT TX MCS set: > 1 streams: MCS 0-9 > 2 streams: MCS 0-9 > 3 streams: MCS 0-9 > 4 streams: not supported > 5 streams: not supported > 6 streams: not supported > 7 streams: not supported > 8 streams: not supported > VHT TX highest supported: 0 Mbps > Frequencies: > * 2412 MHz [1] (30.0 dBm) > [...] Oops. Well, the driver isn't supposed to do that, this is certainly non-spec behaviour. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/23/2016 06:22 AM, Johannes Berg wrote: > On Tue, 2016-02-23 at 06:18 -0800, Ben Greear wrote: > >> [root@ben-ota2 lanforge]# iw phy wiphy0 info >> Wiphy wiphy0 >> >> Band 1: > [...] >> VHT Capabilities (0x338001b2): >> Max MPDU length: 11454 >> Supported Channel Width: neither 160 nor 80+80 >> RX LDPC >> short GI (80 MHz) >> TX STBC >> RX antenna pattern consistency >> TX antenna pattern consistency >> VHT RX MCS set: >> 1 streams: MCS 0-9 >> 2 streams: MCS 0-9 >> 3 streams: MCS 0-9 >> 4 streams: not supported >> 5 streams: not supported >> 6 streams: not supported >> 7 streams: not supported >> 8 streams: not supported >> VHT RX highest supported: 0 Mbps >> VHT TX MCS set: >> 1 streams: MCS 0-9 >> 2 streams: MCS 0-9 >> 3 streams: MCS 0-9 >> 4 streams: not supported >> 5 streams: not supported >> 6 streams: not supported >> 7 streams: not supported >> 8 streams: not supported >> VHT TX highest supported: 0 Mbps > >> Frequencies: >> * 2412 MHz [1] (30.0 dBm) >> > [...] > > Oops. Well, the driver isn't supposed to do that, this is certainly > non-spec behaviour. Is there any harm though? There is at least one other AP manufacturer that really wants to test this feature, so I guess there will be products on the market soon enough that support VHT in 2.4Ghz band. Some day soon-ish, we'll benchmark this in an isolation chamber & over-the-air to see how it actually performs. Thanks, Ben
On Tue, Feb 23, 2016 at 03:10:27PM +0100, Johannes Berg wrote: > What you really "want" is to use VHT modulations, mostly for the > dubious purpose of marketing benchmarks to reach 256-QAM modulations. > > I think the de-facto standard for this would be to use IEs similar to > VHT ones, encapsulated in some (Broadcom?) vendor IE. We may have to > work with that, but that's not what this patch does. Jouni had some > better idea how this worked, I think. hostapd has code to negotiate this using the vendor specific element. I think we ended up getting this working with AP side (i.e., ath10k on the AP) and if I've understood correctly, this does not need any additional changes on top of what is available in upstream kernel and hostapd. Station mode is something that may have been left open since this issue of what and how to advertise as capabilities came up and there was not strong enough push at the time to get more than AP side functional..
On 02/23/2016 01:08 PM, Jouni Malinen wrote: > On Tue, Feb 23, 2016 at 03:10:27PM +0100, Johannes Berg wrote: >> What you really "want" is to use VHT modulations, mostly for the >> dubious purpose of marketing benchmarks to reach 256-QAM modulations. >> >> I think the de-facto standard for this would be to use IEs similar to >> VHT ones, encapsulated in some (Broadcom?) vendor IE. We may have to >> work with that, but that's not what this patch does. Jouni had some >> better idea how this worked, I think. > > hostapd has code to negotiate this using the vendor specific element. I > think we ended up getting this working with AP side (i.e., ath10k on the > AP) and if I've understood correctly, this does not need any additional > changes on top of what is available in upstream kernel and hostapd. > > Station mode is something that may have been left open since this issue > of what and how to advertise as capabilities came up and there was not > strong enough push at the time to get more than AP side functional.. Hostapd and supplicant did not need any changes in my testing. But, you *have* to modify the kernel or it will disable VHT no matter what supplicant says... Thanks, Ben
On Tue, Feb 23, 2016 at 3:46 PM, Ben Greear <greearb@candelatech.com> wrote: > > > On 02/23/2016 02:47 AM, Arik Nemtsov wrote: >> >> On Tue, Feb 23, 2016 at 12:42 AM, <greearb@candelatech.com> wrote: >>> >>> >>> From: Ben Greear <greearb@candelatech.com> >>> >>> ath10k supports VHT on 2.4Ghz band. >>> If supplicant and hostapd and radio think >>> VHT should be allowed, then kernel should let them >>> try. >> >> >> Removing the 80Mhz check entirely is not the right way to go IMO. The >> check is there because there are countries where VHT rates are not >> allowed, even on 20MHz channels. We use the fact these countries have >> no 80MHz-allowed ranges as a crude regulatory hint to disable VHT >> entirely. I'm not sure about the regulatory landscape in these >> countries regarding VHT in 2.4GHz, but please don't break compliance >> for the 5Ghz use-case. > > > Maybe someone can fix the regulatory logic then? > > Add a no-vht flag or whatever? This is more tricky that it looks at first - basically current regulatory "hooks" concern channel width and location, transmit power etc. Here regulatory compliance means never emitting the VHT IE in probe requests etc. So a "no vht" flag would be useless to the reg.c code - it currently never looks at IEs. Some cards even generate them at the FW level. All in all I think the current small bit of ugliness is justified for regulatory compliance. Also it's pretty easy to just leave the code there and condition the check on the 5GHz band. There's no need to remove it. > > Any idea which countries this applies to? I know Russia is one such country. Not sure about others. Arik -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/24/2016 12:40 AM, Arik Nemtsov wrote: > On Tue, Feb 23, 2016 at 3:46 PM, Ben Greear <greearb@candelatech.com> wrote: >> >> >> On 02/23/2016 02:47 AM, Arik Nemtsov wrote: >>> >>> On Tue, Feb 23, 2016 at 12:42 AM, <greearb@candelatech.com> wrote: >>>> >>>> >>>> From: Ben Greear <greearb@candelatech.com> >>>> >>>> ath10k supports VHT on 2.4Ghz band. >>>> If supplicant and hostapd and radio think >>>> VHT should be allowed, then kernel should let them >>>> try. >>> >>> >>> Removing the 80Mhz check entirely is not the right way to go IMO. The >>> check is there because there are countries where VHT rates are not >>> allowed, even on 20MHz channels. We use the fact these countries have >>> no 80MHz-allowed ranges as a crude regulatory hint to disable VHT >>> entirely. I'm not sure about the regulatory landscape in these >>> countries regarding VHT in 2.4GHz, but please don't break compliance >>> for the 5Ghz use-case. >> >> >> Maybe someone can fix the regulatory logic then? >> >> Add a no-vht flag or whatever? > > This is more tricky that it looks at first - basically current > regulatory "hooks" concern channel width and location, transmit power > etc. Here regulatory compliance means never emitting the VHT IE in > probe requests etc. So a "no vht" flag would be useless to the reg.c > code - it currently never looks at IEs. Some cards even generate them > at the FW level. > All in all I think the current small bit of ugliness is justified for > regulatory compliance. > > Also it's pretty easy to just leave the code there and condition the > check on the 5GHz band. There's no need to remove it. Ok, so I can enable VHT on any band as long as the 5Ghz band exists and allows 80Mhz? Thanks, Ben > >> >> Any idea which countries this applies to? > > I know Russia is one such country. Not sure about others. > > Arik >
On Wed, Feb 24, 2016 at 3:24 PM, Ben Greear <greearb@candelatech.com> wrote: >> Also it's pretty easy to just leave the code there and condition the >> check on the 5GHz band. There's no need to remove it. > > > Ok, so I can enable VHT on any band as long as the 5Ghz band exists and > allows 80Mhz? > No idea about that. I'm not sure how/if rate modulation is regulated on 2GHz. The ISM band itself is supposed to be open (microwave heating etc.) so it seems fine to me. But don't take me up on that. This is lawyer domain. Arik -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/24/2016 05:32 AM, Arik Nemtsov wrote: > On Wed, Feb 24, 2016 at 3:24 PM, Ben Greear <greearb@candelatech.com> wrote: >>> Also it's pretty easy to just leave the code there and condition the >>> check on the 5GHz band. There's no need to remove it. >> >> >> Ok, so I can enable VHT on any band as long as the 5Ghz band exists and >> allows 80Mhz? >> > > No idea about that. I'm not sure how/if rate modulation is regulated > on 2GHz. The ISM band itself is supposed to be open (microwave heating > etc.) so it seems fine to me. > But don't take me up on that. This is lawyer domain. I'm trying to understand your suggestion. Maybe you mean I change my patch to only disable VHT if band == 5Ghz AND 80Mhz is not available? Thanks, Ben
On Wed, Feb 24, 2016 at 3:37 PM, Ben Greear <greearb@candelatech.com> wrote: > > > On 02/24/2016 05:32 AM, Arik Nemtsov wrote: >> >> On Wed, Feb 24, 2016 at 3:24 PM, Ben Greear <greearb@candelatech.com> >> wrote: >>>> >>>> Also it's pretty easy to just leave the code there and condition the >>>> check on the 5GHz band. There's no need to remove it. >>> >>> >>> >>> Ok, so I can enable VHT on any band as long as the 5Ghz band exists and >>> allows 80Mhz? >>> >> >> No idea about that. I'm not sure how/if rate modulation is regulated >> on 2GHz. The ISM band itself is supposed to be open (microwave heating >> etc.) so it seems fine to me. >> But don't take me up on that. This is lawyer domain. > > > I'm trying to understand your suggestion. > > Maybe you mean I change my patch to only disable VHT if band == 5Ghz AND > 80Mhz is not available? Yes. But I'm not saying you can enable 2.4GHz VHT in that case. I don't know about that. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 6f079ca..7719867 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -4233,8 +4233,6 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata, struct ieee80211_supported_band *sband; struct cfg80211_chan_def chandef; int ret; - u32 i; - bool have_80mhz; sband = local->hw.wiphy->bands[cbss->channel->band]; @@ -4285,20 +4283,6 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata, } } - /* Allow VHT if at least one channel on the sband supports 80 MHz */ - have_80mhz = false; - for (i = 0; i < sband->n_channels; i++) { - if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED | - IEEE80211_CHAN_NO_80MHZ)) - continue; - - have_80mhz = true; - break; - } - - if (!have_80mhz) - ifmgd->flags |= IEEE80211_STA_DISABLE_VHT; - ifmgd->flags |= ieee80211_determine_chantype(sdata, sband, cbss->channel, ht_cap, ht_oper, vht_oper, diff --git a/net/mac80211/util.c b/net/mac80211/util.c index f8eb0f8..cabe16f 100644 --- a/net/mac80211/util.c +++ b/net/mac80211/util.c @@ -1475,7 +1475,6 @@ static int ieee80211_build_preq_ies_band(struct ieee80211_local *local, int ext_rates_len; int shift; u32 rate_flags; - bool have_80mhz = false; *offset = 0; @@ -1604,17 +1603,7 @@ static int ieee80211_build_preq_ies_band(struct ieee80211_local *local, *offset = noffset; } - /* Check if any channel in this sband supports at least 80 MHz */ - for (i = 0; i < sband->n_channels; i++) { - if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED | - IEEE80211_CHAN_NO_80MHZ)) - continue; - - have_80mhz = true; - break; - } - - if (sband->vht_cap.vht_supported && have_80mhz && !disable_vht) { + if (sband->vht_cap.vht_supported && /*have_80mhz &&*/ !disable_vht) { if (end - pos < 2 + sizeof(struct ieee80211_vht_cap)) goto out_err; pos = ieee80211_ie_build_vht_cap(pos, &sband->vht_cap, diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c index c38b2f0..58887b3 100644 --- a/net/mac80211/vht.c +++ b/net/mac80211/vht.c @@ -120,7 +120,6 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct ieee80211_sub_if_data *sdata, struct ieee80211_sta_vht_cap *vht_cap = &sta->sta.vht_cap; struct ieee80211_sta_vht_cap own_cap; u32 cap_info, i; - bool have_80mhz; memset(vht_cap, 0, sizeof(*vht_cap)); @@ -130,20 +129,6 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct ieee80211_sub_if_data *sdata, if (!vht_cap_ie || !sband->vht_cap.vht_supported) return; - /* Allow VHT if at least one channel on the sband supports 80 MHz */ - have_80mhz = false; - for (i = 0; i < sband->n_channels; i++) { - if (sband->channels[i].flags & (IEEE80211_CHAN_DISABLED | - IEEE80211_CHAN_NO_80MHZ)) - continue; - - have_80mhz = true; - break; - } - - if (!have_80mhz) - return; - /* * A VHT STA must support 40 MHz, but if we verify that here * then we break a few things - some APs (e.g. Netgear R6300v2