Re: rsi_91x: Failed to read status register on failed authentication

On Tue, Dec 5, 2017 at 9:41 PM, Alexey Brodkin wrote: > Hi Amit, > > I'm seeing quite a strange behavior of RedPine module. > It connects perfectly fine to one of access points but fails > to connect to another. > > Moreover after that failure RSI driver starts to

Re: [RFC PATCH 2/2] nl80211: implement beacon change notifier

Hello Johannes, > > In our case, we are experimenting with applications running along with > > hostapd and enabling band steering and client roaming functionality. > > As I mentioned, various approaches are being examined, including > > both pure nl80211-based approach as well as adding direct

pull-request: iwlwifi-next 2017-12-05

Hi Kalle, This is my second batch of patches intended for v4.16. As I mentioned in the patchset thread, I moved patches 5/15 and 6/16 to iwlwifi-fixes. Otherwise nothing major here, just the usual continued development. More details about the contents in the tag description. I have sent this

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

From: David Ahern Date: Tue, 5 Dec 2017 11:15:29 -0700 > Is the patch I sent as an attachment good or should I re-send > standalone? (don't see it in patchwork) Patchwork has been wonky laterly, please resubmit as a fresh email for rewiew. Thanks.

Re: [PATCH v4 1/3] mwifiex: refactor device dump code to make it generic for usb interface

Hi, On Mon, Dec 04, 2017 at 08:18:42PM +0800, Xinming Hu wrote: > This patch refactor current device dump code to make it generic > for subsequent implementation on usb interface. I still think you're making the spaghetti worse. I only have a few specific suggestions for improving your spaghetti

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

On 12/5/17 10:40 AM, David Miller wrote: > From: Johannes Berg > Date: Tue, 05 Dec 2017 18:30:10 +0100 > >> On Tue, 2017-12-05 at 11:41 -0500, David Miller wrote: >>> >>> There is no reasonable interpretation for what that application is >>> doing, so I think we can

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

From: Johannes Berg Date: Tue, 05 Dec 2017 18:30:10 +0100 > On Tue, 2017-12-05 at 11:41 -0500, David Miller wrote: >> >> There is no reasonable interpretation for what that application is >> doing, so I think we can safely call that case as buggy. >> >> We are only

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

On Tue, 2017-12-05 at 11:41 -0500, David Miller wrote: > > There is no reasonable interpretation for what that application is > doing, so I think we can safely call that case as buggy. > > We are only trying to handle the situation where a U8 attribute > is presented as a bonafide U32 or a

iwlwifi 0000:01:00.0: fail to flush all tx fifo queues Q 0

Hello, dmesg: [17361.70] iwlwifi :01:00.0: fail to flush all tx fifo queues Q 0 [17361.733401] iwlwifi :01:00.0: Queue 0 is active on fifo 3 and stuck for 0 ms. SW [72, 73] HW [72, 73] FH TRB=0x080300048 Regards, -- Cristian 00:00.0 Host bridge [0600]: Intel Corporation 2nd

iwlwifi 0000:01:00.0: RF_KILL bit toggled to disable radio.

Hello, dmesg: [20164.665033] iwlwifi :01:00.0: RF_KILL bit toggled to disable radio. [20164.665037] iwlwifi :01:00.0: reporting RF_KILL (radio disabled) [20168.544323] iwlwifi :01:00.0: RF_KILL bit toggled to enable radio. [20168.544328] iwlwifi :01:00.0: reporting RF_KILL (radio

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

From: David Ahern Date: Tue, 5 Dec 2017 09:41:21 -0700 > On 12/5/17 9:34 AM, Johannes Berg wrote: >> On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote: >>> We could try to fix up the big endian problem here, but we don't know *how* userspace misbehaved - if using

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

On 12/5/17 9:34 AM, Johannes Berg wrote: > On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote: >> >>> We could try to fix up the big endian problem here, but we >>> don't know *how* userspace misbehaved - if using nla_put_u32 >>> then we could, but we also found a debug tool (which we'll >>>

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

From: Johannes Berg Date: Tue, 05 Dec 2017 17:34:21 +0100 > On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote: >> >> > We could try to fix up the big endian problem here, but we >> > don't know *how* userspace misbehaved - if using nla_put_u32 >> > then we could,

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote: > > > We could try to fix up the big endian problem here, but we > > don't know *how* userspace misbehaved - if using nla_put_u32 > > then we could, but we also found a debug tool (which we'll > > ignore for the purposes of this regression)

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

From: Johannes Berg Date: Sat, 2 Dec 2017 21:23:31 +0100 > From: Johannes Berg > > This netlink type is used only for backwards compatibility > with broken userspace that used the wrong size for a given > u8 attribute, which is now rejected.

Re: [PATCH 03/10] qtnfmac: add support for radar detection and CAC

> >> +int qtnf_cmd_start_cac(const struct qtnf_vif *vif, > >> + const struct cfg80211_chan_def *chdef, > >> + u32 cac_time_ms) > >> +{ > >> +struct qtnf_bus *bus = vif->mac->bus; > >> +struct sk_buff *cmd_skb; > >> +struct qlink_cmd_start_cac *cmd; >

Re: [PATCH 02/10] qtnfmac: pass complete channel data between driver and firmware

Hello Kalle, > > Center frequency is not enough to describe the channel in HT and VHT > > modes. For 40MHz and 80MHz channels both primary channel and center > > frequency should be specified in order to qualify channel completely. > > This change adds primary channel info into qlink_chandef

rsi_91x: Failed to read status register on failed authentication

Hi Amit, I'm seeing quite a strange behavior of RedPine module. It connects perfectly fine to one of access points but fails to connect to another. Moreover after that failure RSI driver starts to flood me with messages saying: ->8 rsi_91x:

Re: [PATCH 10/10] qtnfmac: support MAC address based access control

Hello Kalle, > Sergey Matyukevich writes: > > > From: Vasily Ulyanov > > > > This allows a running AP to blacklist STAs by their MAC addresses > > respecting the configured policy (either accept or deny unless listed). > > It can be

Re: AP6335 with mainline kernel

On Ter, 2017-12-05 at 10:06 +0100, Arend Van Spriel wrote: > On Mon, Dec 4, 2017 at 8:00 PM, Vanessa Maegima com> wrote: > > > > Hi Arend, > > > > On Qui, 2017-11-30 at 13:31 +0100, Arend van Spriel wrote: > > > > > > On 11/23/2017 4:24 PM, Vanessa Maegima wrote: > > > >

pull-request: iwlwifi 2017-12-05

Hi Kalle, Here is my third set of fixes for 4.15. The most important fixes are for the new 9000 series where we were not handling some offloads correctly and secure connections were totally broken. There is also 4 new PCI IDs and an ROC fix on P2P. More details in the tag description. I have

[PATCH] ath9k_htc: Add a sanity check in ath9k_htc_ampdu_action()

Smatch generates a warning here: drivers/net/wireless/ath/ath9k/htc_drv_main.c:1688 ath9k_htc_ampdu_action() error: buffer overflow 'ista->tid_state' 8 <= 15 I don't know if it's a real bug or not but the other paths through this function all ensure that "tid" is less than

[PATCHv2 3/3] ath10k: add per peer tx stats support for 10.2.4

From: Anilkumar Kolli 10.2.4 firmware branch (used in QCA988X) does not support HTT_10_4_T2H_MSG_TYPE_PEER_STATS and that's why ath10k does not provide tranmission rate statistics to user space, instead it just shows hardcoded 6 Mbit/s. But pktlog firmware facility

[PATCHv2 1/3] ath10k: remove MAC80211_DEBUGFS dependency on ath10k_sta_statistics

From: Anilkumar Kolli Remove CONFIG_MAC80211_DEBUGFS dependency on ath10k_sta_statistics(). ath10k_sta_statistics() has per sta tx/rx stats and this should not be dependent on MAC80211_DEBUGFS. No changes in functionality. Signed-off-by: Anilkumar Kolli

[PATCHv2 2/3] ath10k: move pktlog_filter out of ath10k_debug

From: Anilkumar Kolli Move pktlog_filter from struct ath10k_debug to struct ath10k so that pktlog can be enabled even when debugfs is not enabled, needed to enable peer tx stats for 10.2.4. No changes in functionality. Signed-off-by: Anilkumar Kolli

[PATCHv2 0/3] ath10k: tx stats for 10.2.4

From: Anilkumar Kolli Add tx stats supoort for QCA988X. Parse peer stats from pktlog packets and update the tx rate information per STA. This way user space can query about transmit rate with iw. V2: - Added patch ath10k: remove MAC80211_DEBUGFS dependency on

Re: MWIFIEX still unstable after two years on MS Surface Pro 3

Hi Rene, On Tue, Dec 5, 2017 at 1:31 PM, René Rebe wrote: > Hi Marek, > > thank you for your blazingly fast reply. np. > > On 12/05/2017 12:41 PM, Belisko Marek wrote: >> >> Hi Rene, >> >> On Tue, Dec 5, 2017 at 12:06 PM, René Rebe wrote: >>> >>> Hi all,

Re: MWIFIEX still unstable after two years on MS Surface Pro 3

Hi Marek, thank you for your blazingly fast reply. On 12/05/2017 12:41 PM, Belisko Marek wrote: Hi Rene, On Tue, Dec 5, 2017 at 12:06 PM, René Rebe wrote: Hi all, I write to start a discussion about the state of the mwifiex driver. For over two years many other and me

Re: MWIFIEX still unstable after two years on MS Surface Pro 3

Hi Rene, On Tue, Dec 5, 2017 at 12:06 PM, René Rebe wrote: > Hi all, > > I write to start a discussion about the state of the mwifiex driver. > For over two years many other and me wait that the driver finally becomes > "stable". However, even with kernel 4.14.2 it still

MWIFIEX still unstable after two years on MS Surface Pro 3

Hi all, I write to start a discussion about the state of the mwifiex driver. For over two years many other and me wait that the driver finally becomes "stable". However, even with kernel 4.14.2 it still fails after some minutes, or latest after some hours. With various stray errors in the

[PATCH 1/2] wireless: replace usage of hexdump with od/sed

From: Johannes Berg Since od/sed are in posix, hopefully there's a better chance people will have them, over hexdump. Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking") Signed-off-by: Johannes Berg --- net/wireless/Makefile |

[PATCH 2/2] wireless: don't write C files on failures

From: Johannes Berg Change the scripting inside the shipped/extra certs C code generation to not write the file when there are any failures. That way, if the build aborts due to failures, we don't get into a situation where a dummy file has been created and the next

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

Dear Johannes, On 12/05/17 11:31, Johannes Berg wrote: Ah, here we go - you probably don't have "hexdump" installed on this system? Well, I didn’t, but got the error, that hexdump couldn’t be found. After installing it, I got the error above, and sent the message. Ah, ok. Removing the

Re: 4.15.0-rc1-next-20171201: WARNING: .... at net/mac80211/agg-tx.c:315

Pavel Machek writes: > This is quite annoying: repeated > > [ 4169.591529] ---[ end trace e65d97cf1d20b84d ]--- > [ 4169.591565] WARNING: CPU: 0 PID: 5472 at net/mac80211/agg-tx.c:315 > ___ieee80211_stop_tx_\ > ba_session+0x158/0x1f0 > > Hardware is thinkpad x60. Git blame says

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

Hi, > > Ah, here we go - you probably don't have "hexdump" installed on this > > system? > > Well, I didn’t, but got the error, that hexdump couldn’t be found. After > installing it, I got the error above, and sent the message. Ah, ok. > Removing the file `net/wireless/shipped-certs.c`, and

4.15.0-rc1-next-20171201: WARNING: .... at net/mac80211/agg-tx.c:315

Hi! This is quite annoying: repeated [ 4169.591529] ---[ end trace e65d97cf1d20b84d ]--- [ 4169.591565] WARNING: CPU: 0 PID: 5472 at net/mac80211/agg-tx.c:315 ___ieee80211_stop_tx_\ ba_session+0x158/0x1f0 Hardware is thinkpad x60. Git blame says cfcdbde35 introduced the test.

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

Dear Johannes, On 12/05/17 11:03, Johannes Berg wrote: On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote: ``` $ git describe v4.15-rc2-79-gfd6d2e506ce6 $ git log --oneline -1 fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux $ time ARCH=i386 make deb-pkg -j50 […]

Re: [PATCH v8 0/3] mt76: add new wireless driver for MediaTek MT76x2 PCIe chips

Felix Fietkau writes: > On 2017-12-04 16:04, Kalle Valo wrote: >> Felix Fietkau writes: >> >>> Changes since v7: >>> - Fix build errors >>> >>> Changes since v6: >>> - DT documentation fixes >>> - Add LED configuration >>> - PHY gain calibration fixes >>> - Endian

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote: > > > ``` > $ git describe > v4.15-rc2-79-gfd6d2e506ce6 > $ git log --oneline -1 > fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux > $ time ARCH=i386 make deb-pkg -j50 > […] > net/wireless/shipped-certs.c:2:1: error:

net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

Dear Linux folks, Building the Linux kernel fails with the error below on Debian Sid/unstable with gcc (Debian 7.2.0-8) 7.2.0. ``` $ git describe v4.15-rc2-79-gfd6d2e506ce6 $ git log --oneline -1 fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux $ time ARCH=i386 make

Re: [v1] brcmfmac: Avoid build error with make W=1

Andy Shevchenko wrote: > When I run make W=1 on gcc (Debian 7.2.0-16) 7.2.0 I got an error for > the first run, all next ones are okay. > > CC [M] drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o >

Re: ath10k: Fix reported HT MCS rates with NSS > 1

On Dienstag, 21. November 2017 11:43:36 CET ako...@codeaurora.org wrote: [...] > > I think we should add a special case to not print the warning if mcs == > > 15 until we figure out what it means. > > Fix identified in Firmware and will push ASAP. Is it known when this will be released and for

Re: AP6335 with mainline kernel

On Mon, Dec 4, 2017 at 8:00 PM, Vanessa Maegima wrote: > Hi Arend, > > On Qui, 2017-11-30 at 13:31 +0100, Arend van Spriel wrote: >> On 11/23/2017 4:24 PM, Vanessa Maegima wrote: >> > >> > > >> > > > >> > > > > >> > > > > > >> > > > > > > >> > > > > > > Buildroot: >> > >