[PATCH] mac80211: fix failed to set smps
From: Miaoqing Pan
Signed-off-by: Miaoqing Pan
---
net/mac80211/debugfs_netdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index 4d7473f..9aeb50d 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -276,7 +276,8 @@ static ssize_t ieee80211_if_parse_smps(struct
ieee80211_sub_if_data *sdata,
enum ieee80211_smps_mode mode;
for (mode = 0; mode < IEEE80211_SMPS_NUM_MODES; mode++) {
- if (strncmp(buf, smps_modes[mode], buflen) == 0) {
+ if (strncmp(buf, smps_modes[mode],
+ strlen(smps_modes[mode])) == 0) {
int err = ieee80211_set_smps(sdata, mode);
if (!err)
return buflen;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AP mode failed on wandboard with brcm4329 chip
Hi Arend van Spriel, On 03/26/2015 10:30 PM, Arend van Spriel wrote: > On 03/26/15 12:55, Varka Bhadram wrote: >> On 03/25/2015 10:22 AM, Varka Bhadram wrote: >>> Hi, >>> >>> I am trying setup wandboard-quad as Access Point. It has BRCM4329 >>> WiFi chip on it. >>> >>> As a client is working fine. But facing problem as a AP >>> >>> I did following steps... >>> >>> *1*. Linux kernel Configuration: Linux-3.19 >>> >>> *i.**Device Drivers> Network device support> Wireless LAN* >>> Broadcom IEEE802.11n embedded FullMAC WLAN driver >>> [*] SDIO bus interface support for FullMAC driver >>> [ ] USB bus interface support for FullMAC driver >>> [ ] PCIE bus interface support for FullMAC driver >>> [ ] Broadcom device tracing >>> [*] Broadcom driver debug functions >>> <*>IEEE 802.11 for Host AP (Prism2/2.5/3 and WEP/TKIP/CCMP) >>> [*] Support downloading firmware images with Host AP driver >>> [*] Support for non-volatile firmware download >>> < > Host AP driver for Prism2/2.5/3 in PLX9052 PCI adaptors >>> < > Host AP driver for Prism2.5 PCI adaptors >>> >>> *ii.** Networking support> Wireless* >>> cfg80211 - wireless configuration API >>> [*] nl80211 testmode command >>> [*] enable developer warnings >>> [ ] cfg80211 regulatory debugging >>> [ ] cfg80211 certification onus >>> [ ] enable powersave by default >>> [ ] cfg80211 DebugFS entries >>> [ ] use statically compiled regulatory rules database >>> [ ] cfg80211 wireless extensions compatibility >>> [*] lib80211 debugging messages >>> < >Generic IEEE 802.11 Networking Stack (mac80211) >>> >>> *2*. Copied brcm4329 firmware and nvram txt file into >>> lib/firmware/brcm/ >>> >>> *3*. hostapd.conf >>> interface=wlan0 >>> driver=nl80211 >>> logger_stdout=-1 >>> logger_stdout_level=2 >>> ssid=Service_Location >>> hw_mode=g >>> channel=1 >>> auth_algs=3 >>> max_num_sta=5 >>> wpa=2 >>> wpa_passphrase=scient12 >>> wpa_key_mgmt=WPA-PSK >>> wpa_pairwise=CCMP TKIP >>> rsn_pairwise=CCMP >>> #wme_enabled=1 >>> #ieee80211n=1 >>> #ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40] >>> *4*. After booting into the wandboard, did the following operations >>> >>> $ modprobe brcmfmac >>> >>> $ dmesg >>> [9.147276] cfg80211: Calling CRDA to update world regulatory domain >>> [9.171600] brcmfmac: F1 signature read @0x1800=0x9934329 >>> [9.172649] brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive >>> strength init donefor chip 4329 rev 3 pmurev 6 >>> [9.379309] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = >>> wl0: Sep 2 2011 14:48:19 version 4.220.48 >>> [9.398690] brcmfmac: brcmf_setup_wiphybands: rxchain error (-52) >>> >>> $ hostapd -B hostapd.conf >>> Configuration file: hostapd.conf >>> Failed to create interface mon.wlan0: -95 (Operation not supported) >>> wlan0: Could not connect to kernel driver >>> Using interface wlan0 with hwaddr 40:2c:f4:ae:10:64 and >>> ssid"Service_Location" >>> random: Cannot read from /dev/random: Resource temporarily unavailable >>> random: Only 0/20 bytes of strong random data available from >>> /dev/random >>> random: Not enough entropy pool availablefor secure operations >>> WPA: Not enough entropy in random poolfor secure operations - >>> update keys later when the first station connects >>> Failed to set beacon parameters >>> wlan0: Could not connect to kernel driver >>> Interface initialization failed >>> wlan0: interface state UNINITIALIZED->DISABLED >>> wlan0: AP-DISABLED >>> wlan0: Unable to setup interface. >>> wlan0: interface state DISABLED->DISABLED >>> wlan0: AP-DISABLED >>> hostapd_free_hapd_data: Interface wlan0 wasn't started >>> nl80211: deinit ifname=wlan0 disabled_11b_rates=0 >>> >>> $ dmesg >>> [ 30.870671] brcmfmac: _brcmf_set_multicast_list: Setting >>> BRCMF_C_SET_PROMISC failed, -52 >>> [ 30.997372]*brcmfmac: brcmf_cfg80211_start_ap: setting AP mode >>> failed -52* >>> [ 31.171152] brcmfmac: _brcmf_set_multicast_list: Setting >>> BRCMF_C_SET_PROMISC failed, -52 >>> >>> >>> >>> Thanks >>> -- >>> Varka Bhadram >> Ping...? Am i missing anything...? > > I am not sure what happened with the initial email, but I never > received it. My best bet is that the firmware is not supporting AP > mode. Could you execute the following: > > $ hexdump /lib/firmware/brcm/brcmfmac4329-sdio.bin | tail -20 > > Where did this firmware come from? > > Regards, > Arend Thanks for responding.. I used firmware which is there in linux-firmware[1] git tree. $ hexdump /lib/firmware/brcm/brcmfmac4329-sdio.bin | tail -20 003de10 00f0 0200 4500 006f 4f13 8702 e728 1300 003de20 014f 60bc 0213 a117 0200 025e 00f0 02d3 003de30 a887 00e7 4c13 0801 6740 0a00 0139 e087 003de40 4705 392a 8801 0260 3703 00a2 5e02 f002 003de50 d900 8701 0560 2a47 0039 de02 f002 003de60 8600 61d6 0483 30dc 2800 003de70 614f 194e 235b 2215 555
[RFC] mac80211: check A-MSDU inner frame source address on AP interfaces.
When using WPA security, the station and thus the required key is identified by its mac address when packets are received. So a station usually cannot spoof its source mac address. But when a station sends an A-MSDU frame, port control and crypto is done using the outer mac address, while the packets delivered and forwarded use the inner mac address. IEEE 802.11-2012 mandates that the outer source mac address should match the inner source address (section 8.3.2.2). For the destination mac address, matching is not required (section 10.23.15). So I was wondering whether some checking would be useful? Signed-off-by: Michael Braun --- net/mac80211/rx.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index 944bdc0..e34e0b2 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -2023,6 +2023,12 @@ static bool ieee80211_frame_allowed(struct ieee80211_rx_data *rx, __le16 fc) ether_addr_equal(ehdr->h_dest, pae_group_addr))) return true; + /* Do not allow source MAC spoofing */ + if (rx->sdata && (rx->sdata->vif.type == NL80211_IFTYPE_AP || + rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN) && + rx->sta && !ether_addr_equal(ehdr->h_source, rx->sta->sta.addr)) + return false; + if (ieee80211_802_1x_port_control(rx) || ieee80211_drop_unencrypted(rx, fc)) return false; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] brcm: firmware drop for brcmfmac driver
On 03/26/15 15:35, Jocky Wilson wrote: Arend van Spriel writes: This series adds firmware files for a number of "new" devices. Admittedly there was bit of backlog. For BCM4354 SDIO this series has firmware upgrade. Arend, will there be a firmware for the BCM4324 SDIO rev 6 pmurev 17 which is built in Lenovo Thinkpad Tablet 8 and 10-series, any time soon? On its way. Pending internal review. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ANNOUNCEMENT: Netdev 01 materials posted
Folks, We are pleased to announce that _most_ papers are now available off the netdev website. A few are missing but we are working to get the authors to submit them. Most if not all slides are available. A few videos are also up. Harout is vigilantly working on getting the videos for most sessions uploaded as soon as they are transformed and as soon as we get permission from the authors. And without further ado, here is the url: https://www.netdev01.org/sessions Enjoy! cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: vt6656: vnt_rf_setpower: fix missing rate RATE_12M
On Thu, Mar 26, 2015 at 06:33:18PM +, Malcolm Priestley wrote: > > > On 26/03/15 15:22, Luis Henriques wrote: > >Hi Malcolm, > > > >On Sat, Mar 07, 2015 at 04:36:37PM +, Malcolm Priestley wrote: > >>When the driver sets this rate a power of zero value is set causing > >>data flow stoppage until another rate is tried. > >> > >>Signed-off-by: Malcolm Priestley > >>Cc: # v3.17+ > > > >Is there a reason for this patch being tagged for stable v3.17+ ? > Hi Luis > > Sorry I thought it wouldn't apply to 3.16. > > I need to do a backport patch for earlier kernels. > Awesome, thanks for the quick reply. Commit 163fe301b9f78b6de57d0014eafe504fd20c0cd4 is a clean cherry-pick to 3.16 kernel, but I haven't check which other kernels it should also be applied to. Cheers, -- Luís > Regards > > Malcolm > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: vt6656: vnt_rf_setpower: fix missing rate RATE_12M
On 26/03/15 15:22, Luis Henriques wrote: Hi Malcolm, On Sat, Mar 07, 2015 at 04:36:37PM +, Malcolm Priestley wrote: When the driver sets this rate a power of zero value is set causing data flow stoppage until another rate is tried. Signed-off-by: Malcolm Priestley Cc: # v3.17+ Is there a reason for this patch being tagged for stable v3.17+ ? Hi Luis Sorry I thought it wouldn't apply to 3.16. I need to do a backport patch for earlier kernels. Regards Malcolm -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DFS ETSI conformance for weather channels (again)
"Jean-Pierre Tosoni" writes: > I will check the wireless-regdb list instead. But it looks like the > current python script that generates regulatory.bin was not updated > for CAC time yet :-( IIRC CAC patches for CRDA were not accepted or something. But it should work with kernel internal regdb. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: DFS ETSI conformance for weather channels (again)
Thanks Kalle, I will check the wireless-regdb list instead. But it looks like the current python script that generates regulatory.bin was not updated for CAC time yet :-( Cheers, Jean-Pierre -Message d'origine- De : Kalle Valo [mailto:kv...@codeaurora.org] Envoyé : jeudi 26 mars 2015 17:06 À : Jean-Pierre TOSONI Cc : linux-wireless@vger.kernel.org Objet : Re: DFS ETSI conformance for weather channels (again) "Jean-Pierre TOSONI" writes: > Hi list, > > I just stumbled on this patch that IMHO was rejected for a bad reason: > > [PATCH v3 4/4] cfg80211: DFS use 10 minutes CAC when weather channels > At http://www.spinics.net/lists/linux-wireless/msg115296.html > > The reason given is the "unachievable" requirement in the ETSI norm of > 99.99% detection success. It was even considered disabling the weather > channels. > > *But the norm (ETSI EN 301 893 V1.7.1) does not say this.* It states > that 99.99% is the target performance: > > - during conformance tests only, (5.3.8.1.1 paragraph 5) > - specifically *not* a requirement with specific real life radars, > (5.3.8.1.1 paragraph 5) > - on a limited series of 20 tests, (5.3.8.2.1.2 item g) > - with a pulse power at +10dB above other pulse detection tests, > (5.3.8.2.1.2 item f) > - with some patterns excluded from the test. (5.3.8.2.1.2 item g) > > Hence it is very possible that existing products can achieve the > conformance test target. > > That being said, would it be possible to reexamine that dropped patch > and apply it? Don't we support this by getting the CAC time in the regulatory database? commit 31559f35c5724976fd975e5d7e90cdb693b8dd27 Author: Janusz Dziedzic Date: Fri Feb 21 19:46:13 2014 +0100 cfg80211: DFS get CAC time from regulatory database Send Channel Availability Check time as a parameter of start_radar_detection() callback. Get CAC time from regulatory database. Signed-off-by: Janusz Dziedzic Signed-off-by: Johannes Berg -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AP mode failed on wandboard with brcm4329 chip
On 03/26/15 12:55, Varka Bhadram wrote: On 03/25/2015 10:22 AM, Varka Bhadram wrote: Hi, I am trying setup wandboard-quad as Access Point. It has BRCM4329 WiFi chip on it. As a client is working fine. But facing problem as a AP I did following steps... *1*. Linux kernel Configuration: Linux-3.19 *i.**Device Drivers> Network device support> Wireless LAN* Broadcom IEEE802.11n embedded FullMAC WLAN driver [*] SDIO bus interface support for FullMAC driver [ ] USB bus interface support for FullMAC driver [ ] PCIE bus interface support for FullMAC driver [ ] Broadcom device tracing [*] Broadcom driver debug functions <*>IEEE 802.11 for Host AP (Prism2/2.5/3 and WEP/TKIP/CCMP) [*] Support downloading firmware images with Host AP driver [*] Support for non-volatile firmware download < > Host AP driver for Prism2/2.5/3 in PLX9052 PCI adaptors < > Host AP driver for Prism2.5 PCI adaptors *ii.** Networking support> Wireless* cfg80211 - wireless configuration API [*] nl80211 testmode command [*] enable developer warnings [ ] cfg80211 regulatory debugging [ ] cfg80211 certification onus [ ] enable powersave by default [ ] cfg80211 DebugFS entries [ ] use statically compiled regulatory rules database [ ] cfg80211 wireless extensions compatibility [*] lib80211 debugging messages < >Generic IEEE 802.11 Networking Stack (mac80211) *2*. Copied brcm4329 firmware and nvram txt file into lib/firmware/brcm/ *3*. hostapd.conf interface=wlan0 driver=nl80211 logger_stdout=-1 logger_stdout_level=2 ssid=Service_Location hw_mode=g channel=1 auth_algs=3 max_num_sta=5 wpa=2 wpa_passphrase=scient12 wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP TKIP rsn_pairwise=CCMP #wme_enabled=1 #ieee80211n=1 #ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40] *4*. After booting into the wandboard, did the following operations $ modprobe brcmfmac $ dmesg [9.147276] cfg80211: Calling CRDA to update world regulatory domain [9.171600] brcmfmac: F1 signature read @0x1800=0x9934329 [9.172649] brcmfmac: brcmf_sdio_drivestrengthinit: No SDIO Drive strength init donefor chip 4329 rev 3 pmurev 6 [9.379309] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 2 2011 14:48:19 version 4.220.48 [9.398690] brcmfmac: brcmf_setup_wiphybands: rxchain error (-52) $ hostapd -B hostapd.conf Configuration file: hostapd.conf Failed to create interface mon.wlan0: -95 (Operation not supported) wlan0: Could not connect to kernel driver Using interface wlan0 with hwaddr 40:2c:f4:ae:10:64 and ssid"Service_Location" random: Cannot read from /dev/random: Resource temporarily unavailable random: Only 0/20 bytes of strong random data available from /dev/random random: Not enough entropy pool availablefor secure operations WPA: Not enough entropy in random poolfor secure operations - update keys later when the first station connects Failed to set beacon parameters wlan0: Could not connect to kernel driver Interface initialization failed wlan0: interface state UNINITIALIZED->DISABLED wlan0: AP-DISABLED wlan0: Unable to setup interface. wlan0: interface state DISABLED->DISABLED wlan0: AP-DISABLED hostapd_free_hapd_data: Interface wlan0 wasn't started nl80211: deinit ifname=wlan0 disabled_11b_rates=0 $ dmesg [ 30.870671] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -52 [ 30.997372]*brcmfmac: brcmf_cfg80211_start_ap: setting AP mode failed -52* [ 31.171152] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -52 Thanks -- Varka Bhadram Ping...? Am i missing anything...? I am not sure what happened with the initial email, but I never received it. My best bet is that the firmware is not supporting AP mode. Could you execute the following: $ hexdump /lib/firmware/brcm/brcmfmac4329-sdio.bin | tail -20 Where did this firmware come from? Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mediatek mt7630e and ksoftirqd CPU load
Thank you Larry for the prompt reply. This is very clear. Regards, George On Thu, Mar 26, 2015 at 6:44 PM, Larry Finger wrote: > On 03/26/2015 11:12 AM, George Moutsopoulos wrote: >> >> Dear developers, >> >> if this is not the right place to post this, sorry for the spam. I >> haven't filed a bug report yet. Tell me if I should. I am not sure if >> the problem is something kernel developers can solve. >> >> On a laptop ASUS TP500LN, I have a wireless pcie card mt7630e from >> mediatek. It is a wifi/bluetooth combo. >> >> The driver is not in the kernel, but mediatek provides it for linux >> from the download site >> http://www.mediatek.com/en/downloads/ >> >> The driver does not support kernel 3.16 and above. I followed the >> instructions at >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1220146 >> >> The module compiles and loads succesfully. I followed the post by >> tobias bora from the ubuntu bug. It compiles on kernel version 3.16 >> and above (tried up to 3.19). >> >> Like the rest on the ubuntu bug list, the wifi works and I connect >> succesfully, but ksoftirqd gets 100% cpu on one of the cores. >> >> Shall I open a bug report? I have contacted mediatek twice but they >> haven't replied. I hope it is something you can look at. > > > Due to the fact that the driver is not in the kernel, it is not possible to > file a bug with anyone but the vendor. > > It is possible that someone on this list with Mediatek experience may be > able to help you, but there is no certainty. That is the downside of using a > vendor driver. > > As the specs for that computer specify "integrated 802.11 b/g/n", it is > probably not possible to change that device. I suggest that you purchase an > inexpensive USB wifi stick to provide wifi on this computer. If you do so, > you will be aware enough to check for Linux compatibility. > > Larry > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mediatek mt7630e and ksoftirqd CPU load
On 03/26/2015 11:12 AM, George Moutsopoulos wrote: Dear developers, if this is not the right place to post this, sorry for the spam. I haven't filed a bug report yet. Tell me if I should. I am not sure if the problem is something kernel developers can solve. On a laptop ASUS TP500LN, I have a wireless pcie card mt7630e from mediatek. It is a wifi/bluetooth combo. The driver is not in the kernel, but mediatek provides it for linux from the download site http://www.mediatek.com/en/downloads/ The driver does not support kernel 3.16 and above. I followed the instructions at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1220146 The module compiles and loads succesfully. I followed the post by tobias bora from the ubuntu bug. It compiles on kernel version 3.16 and above (tried up to 3.19). Like the rest on the ubuntu bug list, the wifi works and I connect succesfully, but ksoftirqd gets 100% cpu on one of the cores. Shall I open a bug report? I have contacted mediatek twice but they haven't replied. I hope it is something you can look at. Due to the fact that the driver is not in the kernel, it is not possible to file a bug with anyone but the vendor. It is possible that someone on this list with Mediatek experience may be able to help you, but there is no certainty. That is the downside of using a vendor driver. As the specs for that computer specify "integrated 802.11 b/g/n", it is probably not possible to change that device. I suggest that you purchase an inexpensive USB wifi stick to provide wifi on this computer. If you do so, you will be aware enough to check for Linux compatibility. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
mediatek mt7630e and ksoftirqd CPU load
Dear developers, if this is not the right place to post this, sorry for the spam. I haven't filed a bug report yet. Tell me if I should. I am not sure if the problem is something kernel developers can solve. On a laptop ASUS TP500LN, I have a wireless pcie card mt7630e from mediatek. It is a wifi/bluetooth combo. The driver is not in the kernel, but mediatek provides it for linux from the download site http://www.mediatek.com/en/downloads/ The driver does not support kernel 3.16 and above. I followed the instructions at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1220146 The module compiles and loads succesfully. I followed the post by tobias bora from the ubuntu bug. It compiles on kernel version 3.16 and above (tried up to 3.19). Like the rest on the ubuntu bug list, the wifi works and I connect succesfully, but ksoftirqd gets 100% cpu on one of the cores. Shall I open a bug report? I have contacted mediatek twice but they haven't replied. I hope it is something you can look at. Many regards, George -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DFS ETSI conformance for weather channels (again)
"Jean-Pierre TOSONI" writes: > Hi list, > > I just stumbled on this patch that IMHO was rejected for a bad reason: > > [PATCH v3 4/4] cfg80211: DFS use 10 minutes CAC when weather channels > At http://www.spinics.net/lists/linux-wireless/msg115296.html > > The reason given is the "unachievable" requirement in the ETSI norm of > 99.99% detection success. It was even considered disabling the weather > channels. > > *But the norm (ETSI EN 301 893 V1.7.1) does not say this.* It states > that 99.99% is the target performance: > > - during conformance tests only, (5.3.8.1.1 paragraph 5) > - specifically *not* a requirement with specific real life radars, > (5.3.8.1.1 paragraph 5) > - on a limited series of 20 tests, (5.3.8.2.1.2 item g) > - with a pulse power at +10dB above other pulse detection tests, > (5.3.8.2.1.2 item f) > - with some patterns excluded from the test. (5.3.8.2.1.2 item g) > > Hence it is very possible that existing products can achieve the > conformance test target. > > That being said, would it be possible to reexamine that dropped patch > and apply it? Don't we support this by getting the CAC time in the regulatory database? commit 31559f35c5724976fd975e5d7e90cdb693b8dd27 Author: Janusz Dziedzic Date: Fri Feb 21 19:46:13 2014 +0100 cfg80211: DFS get CAC time from regulatory database Send Channel Availability Check time as a parameter of start_radar_detection() callback. Get CAC time from regulatory database. Signed-off-by: Janusz Dziedzic Signed-off-by: Johannes Berg -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] rtlwifi: rtl8192cu: Add new device ID
On 03/25/2015 08:16 PM, Marek Vasut wrote:
Add new ID for ASUS N10 WiFi dongle.
Signed-off-by: Marek Vasut
Tested-by: Marek Vasut
Cc: Larry Finger
Cc: John W. Linville
Acked-by: Larry Finger
Thanks,
Larry
---
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
1 file changed, 1 insertion(+)
V2: - Move the ID into correct position
- Add my Tested-by to indicate this change was tested on real HW
- Drop the confusing USB device listing from the diffstat section
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index 90a714c..252eb76 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -321,6 +321,7 @@ static struct usb_device_id rtl8192c_usb_ids[] = {
{RTL_USB_DEVICE(0x07b8, 0x8188, rtl92cu_hal_cfg)}, /*Abocom - Abocom*/
{RTL_USB_DEVICE(0x07b8, 0x8189, rtl92cu_hal_cfg)}, /*Funai - Abocom*/
{RTL_USB_DEVICE(0x0846, 0x9041, rtl92cu_hal_cfg)}, /*NetGear WNA1000M*/
+ {RTL_USB_DEVICE(0x0b05, 0x17ba, rtl92cu_hal_cfg)}, /*ASUS-Edimax*/
{RTL_USB_DEVICE(0x0bda, 0x5088, rtl92cu_hal_cfg)}, /*Thinkware-CC&C*/
{RTL_USB_DEVICE(0x0df6, 0x0052, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/
{RTL_USB_DEVICE(0x0df6, 0x005c, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: vt6656: vnt_rf_setpower: fix missing rate RATE_12M
Hi Malcolm, On Sat, Mar 07, 2015 at 04:36:37PM +, Malcolm Priestley wrote: > When the driver sets this rate a power of zero value is set causing > data flow stoppage until another rate is tried. > > Signed-off-by: Malcolm Priestley > Cc: # v3.17+ Is there a reason for this patch being tagged for stable v3.17+ ? I'm asking because there's a similar commit for vt6655 (40c8790bcb7a "vt6655: RFbSetPower fix missing rate RATE_12M") which was tagged for stable without the "v3.17+", and thus I assume applicable to other trees as well (e.g. 3.16). Cheers, -- Luís > --- > drivers/staging/vt6656/rf.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c > index c42cde5..c4286cc 100644 > --- a/drivers/staging/vt6656/rf.c > +++ b/drivers/staging/vt6656/rf.c > @@ -640,6 +640,7 @@ int vnt_rf_setpower(struct vnt_private *priv, u32 rate, > u32 channel) > break; > case RATE_6M: > case RATE_9M: > + case RATE_12M: > case RATE_18M: > case RATE_24M: > case RATE_36M: > -- > 2.1.4 > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: replenish htc tx credits always
On 03/26/2015 04:22 AM, Michal Kazior wrote: > There's always at most 2 credits and it makes > little sense to set the > ATH10K_HTC_FLAG_NEED_CREDIT_UPDATE flag > conditionally. > > This seems to fix some random issues with tx > credit starvation on WLAN.RM.2.0-00073 I've been > seeing. Note: this isn't related to wmi mgmt tx. Good to see this in. This will help when using CT firmware as well, since it makes better use of tx-credits-update than stock 10.1.467 at least. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] brcm: firmware drop for brcmfmac driver
Arend van Spriel writes: > > This series adds firmware files for a number of "new" devices. > Admittedly there was bit of backlog. For BCM4354 SDIO this > series has firmware upgrade. > Arend, will there be a firmware for the BCM4324 SDIO rev 6 pmurev 17 which is built in Lenovo Thinkpad Tablet 8 and 10-series, any time soon? Cheers JockyW -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] NFC: Add Intel FieldsPeak NFC solution driver
On Tue, Feb 24, 2015 at 12:01:52PM +0200, Robert Dolca wrote:
> +static struct i2c_device_id fdp_nci_i2c_id_table[] = {
> + {"INT339A", 0},
If this is ACPI only device you can remove the above line.
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, fdp_nci_i2c_id_table);
And this as well.
> +
> +
> +static const struct acpi_device_id fdp_nci_i2c_acpi_match[] = {
> + {"INT339A", 0},
> + {}
> +};
> +
> +static struct i2c_driver fdp_nci_i2c_driver = {
> + .driver = {
> +.name = FDP_NCI_I2C_DRIVER_NAME,
> +.owner = THIS_MODULE,
> +.acpi_match_table = ACPI_PTR(fdp_nci_i2c_acpi_match),
> + },
> + .id_table = fdp_nci_i2c_id_table,
> + .probe = fdp_nci_i2c_probe,
> + .remove = fdp_nci_i2c_remove,
> +};
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[mac80211]synchronize_net call in ieee_tx_ba_session_handle_start
The synchronize_net called in function ieee_tx_ba_session_handle_start generate a jiter after the association. I can observe a long period (100ms or more) where no data are sent because mac80211 is blocked in synchronize_net. My product has several network interface and processor with 4 cores. If I understood correctly, in case we use the ath9k driver, the function drv_ampdu_action will call the ath_tx_aggr_start and this function will flush the tx pending packet and return the next sequence number. So in this case it is not necessary to call this function. Is it possible to remove this function, or I need to consider another case? Thanks for your help. Cedric Voncken. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/15] staging: rtl8723au: Reformat whitespace to increase readability
On Thu, Mar 19, 2015 at 12:39:04AM -0400, M. Vefa Bicakci wrote: > Adjust the whitespace in the signature, local variable declaration and > initialization parts of a number of functions to increase readability > in rtl8723au's rtw_security.c. > > v2: Make sure that the arcfour_encrypt function's argument list is split > according to the kernel code style. The "v2" stuff here should go below the --- line, otherwise it will show up in the changelog :( Please fix these all up and resend. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DFS ETSI conformance for weather channels (again)
Hi list, I just stumbled on this patch that IMHO was rejected for a bad reason: [PATCH v3 4/4] cfg80211: DFS use 10 minutes CAC when weather channels At http://www.spinics.net/lists/linux-wireless/msg115296.html The reason given is the "unachievable" requirement in the ETSI norm of 99.99% detection success. It was even considered disabling the weather channels. *But the norm (ETSI EN 301 893 V1.7.1) does not say this.* It states that 99.99% is the target performance: - during conformance tests only, (5.3.8.1.1 paragraph 5) - specifically *not* a requirement with specific real life radars, (5.3.8.1.1 paragraph 5) - on a limited series of 20 tests, (5.3.8.2.1.2 item g) - with a pulse power at +10dB above other pulse detection tests, (5.3.8.2.1.2 item f) - with some patterns excluded from the test. (5.3.8.2.1.2 item g) Hence it is very possible that existing products can achieve the conformance test target. That being said, would it be possible to reexamine that dropped patch and apply it? Best regards, Jean-Pierre Tosoni -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath10k: replenish htc tx credits always
There's always at most 2 credits and it makes
little sense to set the
ATH10K_HTC_FLAG_NEED_CREDIT_UPDATE flag
conditionally.
This seems to fix some random issues with tx
credit starvation on WLAN.RM.2.0-00073 I've been
seeing. Note: this isn't related to wmi mgmt tx.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/htc.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c
b/drivers/net/wireless/ath/ath10k/htc.c
index d33d5c4397f6..0eab8a2ffefe 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -86,21 +86,6 @@ static void ath10k_htc_notify_tx_completion(struct
ath10k_htc_ep *ep,
ep->ep_ops.ep_tx_complete(ep->htc->ar, skb);
}
-/* assumes tx_lock is held */
-static bool ath10k_htc_ep_need_credit_update(struct ath10k_htc_ep *ep)
-{
- struct ath10k *ar = ep->htc->ar;
-
- if (!ep->tx_credit_flow_enabled)
- return false;
- if (ep->tx_credits >= ep->tx_credits_per_max_message)
- return false;
-
- ath10k_dbg(ar, ATH10K_DBG_HTC, "HTC: endpoint %d needs credit update\n",
- ep->eid);
- return true;
-}
-
static void ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep *ep,
struct sk_buff *skb)
{
@@ -111,13 +96,10 @@ static void ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep
*ep,
hdr->eid = ep->eid;
hdr->len = __cpu_to_le16(skb->len - sizeof(*hdr));
hdr->flags = 0;
+ hdr->flags |= ATH10K_HTC_FLAG_NEED_CREDIT_UPDATE;
spin_lock_bh(&ep->htc->tx_lock);
hdr->seq_no = ep->seq_no++;
-
- if (ath10k_htc_ep_need_credit_update(ep))
- hdr->flags |= ATH10K_HTC_FLAG_NEED_CREDIT_UPDATE;
-
spin_unlock_bh(&ep->htc->tx_lock);
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] NFC: Add Intel FieldsPeak NFC solution driver
Robert,
Another comment:
On Tue, Feb 24, 2015 at 12:01:52PM +0200, Robert Dolca wrote:
> +static struct i2c_device_id fdp_nci_i2c_id_table[] = {
> + {"INT339A", 0},
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, fdp_nci_i2c_id_table);
> +
> +
> +static const struct acpi_device_id fdp_nci_i2c_acpi_match[] = {
> + {"INT339A", 0},
> + {}
> +};
Why don't we have a MODULE_DEVICE_TABLE(acpi, fdp_nci_i2c_acpi_match);
here ?
Cheers,
Samuel.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] NFC: nxp-nci: Add support for NXP-NCI NFC controllers
Hi Clément, On Mon, Mar 09, 2015 at 11:12:02AM +0100, clement.perroch...@effinnov.com wrote: > From: Clément Perrochaud > > This patch brings support for the NXP-NCI NFC controllers family. > > It has been successfully tested on the following SoC boards: > - BeagleBone > - BeagleBone Black > - Raspberry Pi B > - Raspberry Pi B+ > > The submission is broken into three patches: > - The first one adds firmware download support to NCI ; > - The second one adds the NXP-NCI driver's core ; > - The third one adds I2C support to the driver. All 3 patches applied to nfc-next, many thanks. Cheers, Samuel. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath10k: fix insufficient tracing buffer size
Some trace messages were truncated and a kernel
splat could be seen in the log:
WARNING: CPU: 3 PID: 0 at
/devel/src/linux/drivers/net/wireless/ath/ath10k/./trace.h:114
ftrace_raw_event_ath10k_log_dbg+0x20e/0x220 [ath10k_core]()
Modules linked in: ath10k_pci(O) ath10k_core(O) ath iwldvm iwlwifi [last
unloaded: iwlwifi]
CPU: 3 PID: 0 Comm: swapper/3 Tainted: GW O4.0.0-rc3-wl-ath+ #703
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.7.5-20140531_083030-gandalf 04/01/2014
a01d4cb0 88001fd83998 8191b86c 81e3b718
88001fd839d8 8105573a 88001c0a5528
88001bea9ae0 88001c3dd940 000d0018 88001fd83a80
Call Trace:
[] dump_stack+0x45/0x57
[] warn_slowpath_common+0x8a/0xc0
[] warn_slowpath_null+0x1a/0x20
[] ftrace_raw_event_ath10k_log_dbg+0x20e/0x220
[ath10k_core]
[] ath10k_dbg+0xbb/0xd0 [ath10k_core]
[] ? trace_clock_local+0x9/0x10
[] ath10k_wmi_event_service_ready+0x479/0x520 [ath10k_core]
[] ? trace_buffer_unlock_commit+0x50/0x60
[] ath10k_wmi_tlv_op_rx+0x6b3/0x8b0 [ath10k_core]
This could be reproduced with:
trace-cmd record -e ath10k
ifconfig wlan0 down
ifconfig wlan0 up
Fixes: 5c01aa3de918 ("ath10k: deduplicate wmi service ready logic")
Fixes: ca996ec56608 ("ath10k: implement wmi-tlv backend")
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/trace.h
b/drivers/net/wireless/ath/ath10k/trace.h
index 5407887380ab..71dfcd96354b 100644
--- a/drivers/net/wireless/ath/ath10k/trace.h
+++ b/drivers/net/wireless/ath/ath10k/trace.h
@@ -46,7 +46,7 @@ static inline void trace_ ## name(proto) {}
#undef TRACE_SYSTEM
#define TRACE_SYSTEM ath10k
-#define ATH10K_MSG_MAX 200
+#define ATH10K_MSG_MAX 400
DECLARE_EVENT_CLASS(ath10k_log_event,
TP_PROTO(struct ath10k *ar, struct va_format *vaf),
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] ath10k: unify tx mode and dispatch
On 26 March 2015 at 10:27, Michal Kazior wrote: > On 20 March 2015 at 12:02, Marek Puzyniak wrote: >> From: Michal Kazior >> >> There are a few different tx paths depending on >> firmware and frame itself. >> >> Creating a uniform decision will make it possible >> to switch between different txmode easier, both >> for testing and for future features as well. >> >> Signed-off-by: Michal Kazior >> Signed-off-by: Marek Puzyniak > [...] > > This patch apparently breaks AP operation. I need to investigate this. Ok - htt.freq missed clearing and in some cases it contained garbage leading to HTT discarding packets. @Kalle: I've posted a patch `ath10k: clear htt.freq` which addresses the problem separately. Please apply it _before_ you apply TDLS patches (which are fine, including this patch) to avoid breakage in-between commits. Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath10k: clear htt.freq
If htt.freq isn't cleared and contains garbage fw
may discard tx packets. Prevent this from
happening by clearing htt.freq properly.
Possible manifestation of the problem could be not
being able to send auth request/response frames on
firmware with HTT >= 3.4 (when freq param was
introduced), e.g. on qca6174.
Fixes: 8d6d36243610 ("ath10k: fix offchan reliability")
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/mac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 9b8313dcb888..36a244187b9c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2927,6 +2927,7 @@ static void ath10k_tx(struct ieee80211_hw *hw,
ath10k_dbg(ar, ATH10K_DBG_MAC,
"IEEE80211_TX_CTL_NO_CCK_RATE\n");
ATH10K_SKB_CB(skb)->htt.is_offchan = false;
+ ATH10K_SKB_CB(skb)->htt.freq = 0;
ATH10K_SKB_CB(skb)->htt.tid = ath10k_tx_h_get_tid(hdr);
ATH10K_SKB_CB(skb)->vdev_id = ath10k_tx_h_get_vdev_id(ar, vif);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dynamic channel Access
On 26/03/15 07:30, Michal Kazior wrote: > On 25 March 2015 at 16:34, Jose Antonio Delgado Alfonso > wrote: >> Hi all, >> >> I would like to ask Qualcomm's collaborators about this topic. >> >> We are trying to certify a AP product which uses QCA988x radio module. >> We are using the ath10k driver (kernel v3.17.8) and firmware from Ben >> Greear. We are trying to pass the Dynamic Channel test, which consists >> in setting the radio at 80MHz and, at the same time, setting other >> signal in the secondary channel. So far, the radio module does not >> reduce the bandwidth and remains transmitting at 80MHz. >> >> Please, Does someone know if Dynamic Channel Access is really supported >> by ath10k driver in newest kernel versions? > You haven't really defined what kind of "other signal" you set up. > ath10k sets/enables dynamic_bw wmi parameter in ath10k_start(). From > what I know dynamic_bw does enable fw/hw to downgrade traffic from > 80MHz to 40MHz in case there's other 802.11 traffic on the subband > happening at least on 10.1.467 - not sure about non-802.11 traffic. I > suppose newer firmware revisions do that too. I'm not sure about > 999.999.0.636 though. > > > Michał > > ___ > ath10k mailing list > ath...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k I tested with other AP and also with a signal generator emitting a flat noise of 20 MHz continuously. I will check how function ath10k_start is implemented in my kernel tree and if that parameter is really enabled on my setup. Thanks. Jose A. Delgado -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] ath10k: unify tx mode and dispatch
On 20 March 2015 at 12:02, Marek Puzyniak wrote: > From: Michal Kazior > > There are a few different tx paths depending on > firmware and frame itself. > > Creating a uniform decision will make it possible > to switch between different txmode easier, both > for testing and for future features as well. > > Signed-off-by: Michal Kazior > Signed-off-by: Marek Puzyniak [...] This patch apparently breaks AP operation. I need to investigate this. Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
