Re: AP mode with Broadcom 4330

Arend, Did this bug ever get fixed, or are 4330's still ending up advertising BCRM_TEST_SSID when they're put into AP mode with mainline kernels? It would be good to know whether I can drop my patch for this from my kernel tree and still have working AP mode. Thanks. On Mon, Jul 31, 2017 at

iwlwifi 8265 firmware crash vith v34 on linux 4.14

Running a Lenovo Yoga 720 with kernel 4.14, I pulled the: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2017-11-03 to try the new fw version 34 on my: 3f:00.0 Network controller [0280]: Intel Corporation Wireless 8265 / 8275 [8086:24fd] (rev 78)

Re: iwlwifi 8265 firmware crash vith v34 on linux 4.14

Hi Thomas, On Tue, 2017-11-14 at 21:49 +0200, Thomas Backlund wrote: > Running a Lenovo Yoga 720 with kernel 4.14, I pulled the: > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux- > firmware.git > tags/iwlwifi-fw-2017-11-03 > > to try the new fw version 34 on my: > 3f:00.0 Network

Re: iwlwifi 8265 firmware crash vith v34 on linux 4.14

Den 14.11.2017 kl. 22:04, skrev Luciano Coelho: Hi Thomas, On Tue, 2017-11-14 at 21:49 +0200, Thomas Backlund wrote: Running a Lenovo Yoga 720 with kernel 4.14, I pulled the: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux- firmware.git tags/iwlwifi-fw-2017-11-03 to try the new fw

Re: [v2] ath9k: add MSI support

On Tue, Nov 14, 2017 at 8:15 PM, Kalle Valo wrote: >> Can't be fixed in firmware, but it would be good to have confirmation >> of the hardware behavivour, and maybe some other solution is possible? >> Are you following this up within Qualcomm? > > No time to do that right

[PATCH 0/8] rsi: add bluetooth and coex support

From: Amitkumar Karwar This patch series adds new bluetooth driver and coex enhancments in existing wlan driver for RSI chipsets. As per our architecture, both wlan and bluetooth drivers talk over same SDIO interface to device. Separate endpoint will be used in

[PATCH 7/8] rsi: add module parameter operating mode

From: Prameela Rani Garnepudi Operating mode determines the support for other protocols. This is made as module parameter for better usage. Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Siva Rebbagondla

[PATCH 8/8] rsi: sdio changes to support BT

From: Prameela Rani Garnepudi Queue number is correctly updated for BT traffic. Also, kzalloc instead of kmalloc is used for Rx packet allocation. Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Amitkumar Karwar

[PATCH 6/8] rsi: handle BT traffic in driver

From: Siva Rebbagondla BT frames are passed through coex and hal modules to BUS. After firmware is loaded, based on the operating mode CARD READY frame comes for each protocol. When BT card ready is received, BT attach is called. Protocol operations are

[PATCH 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

From: Prameela Rani Garnepudi Redpine bluetooth driver is a thin driver which depends on 'rsi_91x' driver for transmitting and receiving packets to/from device. It creates hci interface when attach() is called from 'rsi_91x' module. Signed-off-by: Prameela Rani

[PATCH 2/8] rsi: add bluetooth rx endpoint

From: Siva Rebbagondla USB endpoint 1 is used for WLAN which is presently in use. USB endpoint 2 is introduced for BT Rx traffic. Enumeration of Rx BT endpoint and submitting Rx BT URB are added. Signed-off-by: Prameela Rani Garnepudi

[PATCH 4/8] rsi: add coex support

From: Prameela Rani Garnepudi With BT support, driver has to handle two streams of data (i.e. wlan and BT). Actual coex implementation is in firmware. Coex module just schedule the packets to firmware by taking them from the corresponding paths. Structures for module

[PATCH 3/8] rsi: add header file rsi_header

From: Prameela Rani Garnepudi The common parameters used by wlan and bt modules are added to a new header file "rsi_header.h" defined in '/include/linux' Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Siva Rebbagondla

[PATCH 1/8] rsi: add rx control block to handle rx packets in USB

From: Prameela Rani Garnepudi Rx bluetooth endpoint shall be added in further patches. Rx control block is introduced here to handle Rx packets properly. Separate function is written to initialize the RX control blocks. Signed-off-by: Prameela Rani Garnepudi

Re: [PATCH] wcn36xx: Set BTLE coexistence related configuration values to defaults

Hi Eyal, Thank you for the patch! Yet something to improve: [auto build test ERROR on wireless-drivers-next/master] [also build test ERROR on v4.14 next-20171114] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

Re: Slow connection with rtl8xxxu and 8192eu chipset

On 14.11.2017 14:42, Kalle Valo wrote: > Nikolay Borisov writes: > >> (Please CC as I'm not subscribed) >> >> Hello, >> >> I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as >> >> Bus 001 Device 003: ID 2357:0108 >> >> Unfortunately with the in-kernel

[PATCH v3 02/12] wil6210: print human readable names of WMI commands and events

From: Dedy Lansky Upon sending/receiving WMI commands/events, print human readable names in addition to id for easier debugging. Signed-off-by: Dedy Lansky Signed-off-by: Maya Erez ---

[PATCH v3 00/12] wil6210 patches

Changes from v2: - Additional fixes to "wil6210: run-time PM when interface down" Changes from v1: - Fix static buffer allocation in "wil6210: update statistics for suspend" - Fix kbuild bot error on "wil6210: run-time PM when interface down" The following patches include: - Bug fixes - run-time

[PATCH v3 06/12] wil6210: add block size checks during FW load

From: Lior David When loading FW from file add block size checks to ensure a corrupted FW file will not cause the driver to write outside the device memory. Signed-off-by: Lior David Signed-off-by: Maya Erez

[PATCH v3 03/12] wil6210: refresh FW capabilities during interface up

From: Lior David FW capabilities are currently retrieved only during module initialization, but userspace can replace the firmware while interface is down, so refresh the FW capabilities when interface is up (after FW is loaded) to ensure driver functionality matches

[PATCH v3 08/12] wil6210: missing length check in wil_cfg80211_mgmt_tx

From: Lior David Add a length check in wil_cfg80211_mgmt_tx to detect unsigned integer overflow. Signed-off-by: Lior David Signed-off-by: Maya Erez --- drivers/net/wireless/ath/wil6210/cfg80211.c | 10

[PATCH v3 07/12] wil6210: missing length check in wmi_set_ie

From: Lior David Add a length check in wmi_set_ie to detect unsigned integer overflow. Signed-off-by: Lior David Signed-off-by: Maya Erez --- drivers/net/wireless/ath/wil6210/wmi.c | 8 +++- 1 file

[PATCH v3 12/12] wil6210: update statistics for suspend

From: Lazar Alexei Currently the statistics show how many successful/failed suspend/resume operations the system had. Update the statistics by splitting each successful/failed suspend/resume operations to radio on/off. Signed-off-by: Lazar Alexei

[PATCH v3 05/12] wil6210: fix length check in __wmi_send

From: Lior David The current length check: sizeof(cmd) + len > r->entry_size will allow very large values of len (> U16_MAX - sizeof(cmd)) and can cause a buffer overflow. Fix the check to cover this case. In addition, ensure the mailbox entry_size is not too small,

[PATCH v3 10/12] wil6210: fix PCIe bus mastering in case of interface down

From: Lazar Alexei In case of interface down, radio is turned off but PCIe mastering is not cleared. This can cause unexpected PCIe access to the shutdown device. Fix this by clearing PCIe mastering also in case interface is down Signed-off-by: Lazar Alexei

[PATCH v3 11/12] wil6210: remove suspend time statistics

From: Lazar Alexei Currently suspend time statistics are showed through debugfs. Remove time statistics in suspend state since the timing may not be accurate in that state. Signed-off-by: Lazar Alexei Signed-off-by: Maya Erez

Re: [v2] ath9k: add MSI support

Daniel Drake writes: > On Mon, Nov 13, 2017 at 4:48 PM, Kalle Valo wrote: >> Enabling MSI by default is just too invasive, ath9k is used in so many >> different enviroments that risk of regressions is high. MSI needs a lot >> of testing before we can

Re: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

> + if (tmp_old[0] == WLAN_EID_VENDOR_SPECIFIC) { > + if (!memcmp(tmp_old + 2, tmp + 2, 5)) { > + /* same vendor ie, copy from new ie */ > + memcpy(pos, tmp, tmp[1] + 2); > +

Re: Slow connection with rtl8xxxu and 8192eu chipset

Nikolay Borisov writes: > (Please CC as I'm not subscribed) > > Hello, > > I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as > > Bus 001 Device 003: ID 2357:0108 > > Unfortunately with the in-kernel rtl8xxxu driver I don't get very good > results: > >

Re: [PATCH] iwlwifi: fix firmware names for 9xxx and a0 series hw

On Tue, 2017-11-14 at 12:48 +0100, Greg KH wrote: > On Tue, Nov 14, 2017 at 01:38:20PM +0200, Luciano Coelho wrote: > > On Tue, 2017-11-14 at 13:29 +0200, Thomas Backlund wrote: > > > Den 14-11-2017 kl. 12:52, skrev Luca Coelho: > > > > On Tue, 2017-11-14 at 12:37 +0200, Thomas Backlund wrote: > >

Re: [PATCH] iwlwifi: fix firmware names for 9xxx and a0 series hw

On Tue, 2017-11-14 at 12:37 +0200, Thomas Backlund wrote: > iwlwifi 9xxx and a0 series hw contains an extra dash in firmware file > name > as seeen in modinfo output for kernel 4.14: > > firmware: iwlwifi-9260-th-b0-jf-b0--34.ucode > firmware: iwlwifi-9260-th-a0-jf-a0--34.ucode >

Re: [PATCH] iwlwifi: fix firmware names for 9xxx and a0 series hw

On Tue, 2017-11-14 at 13:29 +0200, Thomas Backlund wrote: > Den 14-11-2017 kl. 12:52, skrev Luca Coelho: > > On Tue, 2017-11-14 at 12:37 +0200, Thomas Backlund wrote: > > > iwlwifi 9xxx and a0 series hw contains an extra dash in firmware > > > file > > > name > > > as seeen in modinfo output for

Slow connection with rtl8xxxu and 8192eu chipset

(Please CC as I'm not subscribed) Hello, I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as Bus 001 Device 003: ID 2357:0108 Unfortunately with the in-kernel rtl8xxxu driver I don't get very good results: wifi1 IEEE 802.11 ESSID:"HOME" Mode:Managed

Re: [linux-sunxi] rtl8188eu driver and hostapd

Hi Ishraq, On Tue, Nov 14, 2017 at 9:24 PM, Ishraq Ibne Ashraf wrote: > Hi, > > In our system we use the hostapd release version 2.6 from, > https://w1.fi/cgit/hostap/snapshot/hostap_2_6.tar.bz2. > Everything works fine with the kernel and rtl8188eu driver from

[PATCH] iwlwifi: fix firmware names for 9xxx and a0 series hw

iwlwifi 9xxx and a0 series hw contains an extra dash in firmware file name as seeen in modinfo output for kernel 4.14: firmware: iwlwifi-9260-th-b0-jf-b0--34.ucode firmware: iwlwifi-9260-th-a0-jf-a0--34.ucode firmware: iwlwifi-9000-pu-a0-jf-b0--34.ucode firmware:

Re: [PATCH] rtlwifi: Convert individual interrupt results to struct

Hi Larry, On Mon, Nov 13, 2017 at 7:06 AM, Larry Finger wrote: > With the RTL8822BE and later devices, the number of interrupt vectors > has grown from 2 to 4. At this point, saving and passing those vectors > in a struct makes more sense than using individual scaler

Re: Slow connection with rtl8xxxu and 8192eu chipset

On 14.11.2017 11:26, Nikolay Borisov wrote: > (Please CC as I'm not subscribed) > > Hello, > > I have the tp-link tl-wn822N usb wifi dongle. lsbusb reports it as > > Bus 001 Device 003: ID 2357:0108 > > Unfortunately with the in-kernel rtl8xxxu driver I don't get very good > results: > >

Re: [PATCH] iwlwifi: fix firmware names for 9xxx and a0 series hw

Den 14-11-2017 kl. 12:52, skrev Luca Coelho: On Tue, 2017-11-14 at 12:37 +0200, Thomas Backlund wrote: iwlwifi 9xxx and a0 series hw contains an extra dash in firmware file name as seeen in modinfo output for kernel 4.14: firmware: iwlwifi-9260-th-b0-jf-b0--34.ucode firmware:

Re: [PATCH] iwlwifi: fix firmware names for 9xxx and a0 series hw

On Tue, Nov 14, 2017 at 01:38:20PM +0200, Luciano Coelho wrote: > On Tue, 2017-11-14 at 13:29 +0200, Thomas Backlund wrote: > > Den 14-11-2017 kl. 12:52, skrev Luca Coelho: > > > On Tue, 2017-11-14 at 12:37 +0200, Thomas Backlund wrote: > > > > iwlwifi 9xxx and a0 series hw contains an extra dash

mwifiex: how to restrict txpower per channel and regulatory region?

Hi All For (worldwide) regulatory compliance / WiFi certification I need to restrict/limit the txpower dependent on channels and regulatory region code. At the moment I can restrict it generally via e.g. "iw dev mlan0 set txpower fixed 800". Furthermore I can specify the allowed

RE: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

> > > + if (tmp_old[0] == WLAN_EID_VENDOR_SPECIFIC) { > > + if (!memcmp(tmp_old + 2, tmp + 2, 5)) { > > + /* same vendor ie, copy from new ie > */ > > + memcpy(pos, tmp, tmp[1] + 2); >

Re: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

On Tue, 2017-11-14 at 14:20 +, Peng Xu wrote: > > > > > + if (tmp_old[0] == WLAN_EID_VENDOR_SPECIFIC) { > > > + if (!memcmp(tmp_old + 2, tmp + 2, 5)) { > > > + /* same vendor ie, copy from new ie > > > > */ > > > +

Re: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

On Tue, Nov 14, 2017 at 02:39:31PM +, Peng Xu wrote: > > I'm not even sure why this is necessary anyway though, do we really think > > vendors will expect to be able to put vendor IEs inside the subelements and > > override the ones outside? > > > > Is there even any point for the WFA ones?

RE: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

> > Right, not really. > > I'm not even sure why this is necessary anyway though, do we really think > vendors will expect to be able to put vendor IEs inside the subelements and > override the ones outside? > > Is there even any point for the WFA ones? It seems WMM really ought to be > the

RE: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

> > > > It is OUI + type + subTye. > > Ah, right, type/subtype. > > Still, this is problematic, because there's nothing that says that the vendor > IE > must have OUI + type + subtype, the spec only says OUI + vendor specific > data. > > This may be right for the WFA/Microsoft OUI, but not

Re: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

> > > > This may be right for the WFA/Microsoft OUI, but not necessary anything > > else? > > > > Right, I only considered the most common cases since I did not find a > generic way to compare two vendor elements. Any suggestion? Right, not really. I'm not even sure why this is necessary

[PATCH] mac80211: fix the update of path metric for RANN frame

The previous path metric update from RANN frame has not considered the own link metric toward the transmitting mesh STA. Fix this. Reported-by: Michael65535 Signed-off-by: Chun-Yeow Yeoh --- net/mac80211/mesh_hwmp.c | 15 +-- 1 file changed, 9 insertions(+),

[PATCH] rtlwifi: rtl818x: remove redundant check for cck_power > 15

From: Colin Ian King cck_poweri cannot be greated than 15 as is derived from the bottom 4 bits from riv->channels[channel - 1].hw_value & 0xf. Hence the check for it being greater than 15 is redundant and can be removed. Detected by CoverityScan, CID#744303

Re: [PATCH] mac80211: fix the update of path metric for RANN frame

Thanks Chun-Yeow, this is a good change. On Tue, Nov 14, 2017 at 7:20 AM, Chun-Yeow Yeoh wrote: > The previous path metric update from RANN frame has not considered > the own link metric toward the transmitting mesh STA. Fix this. > > Reported-by: Michael65535 >

[PATCH] ath10k: Fix invalid STS_CAP_OFFSET_MASK.

From: Ben Greear The 10.4 firmware defines this as a 3-bit field, as does the mac80211 stack. The 4th bit is defined as CONF_IMPLICIT_BF at least in the firmware header I have seen. This patch fixes the ath10k wmi header to match the firmware. Signed-off-by: Ben

RE: [RFC] cfg80211: Implement Multiple BSSID capability in scanning

> On Tue, Nov 14, 2017 at 02:39:31PM +, Peng Xu wrote: > > > I'm not even sure why this is necessary anyway though, do we really > > > think vendors will expect to be able to put vendor IEs inside the > > > subelements and override the ones outside? > > > > > > Is there even any point for the

Re: [PATCH] ath10k: Fix invalid STS_CAP_OFFSET_MASK.

Am 14.11.2017 um 18:16 schrieb gree...@candelatech.com: From: Ben Greear The 10.4 firmware defines this as a 3-bit field, as does the mac80211 stack. The 4th bit is defined as CONF_IMPLICIT_BF at least in the firmware header I have seen. This patch fixes the ath10k