Re: pull-request: wireless-drivers 2017-08-25

2017-08-25 Thread David Miller
From: Kalle Valo Date: Fri, 25 Aug 2017 16:37:57 +0300 > here's pull request to net tree for 4.13, more info in the signed > tag below. Please let me know if there are any problems. Pulled, thanks Kalle.

Re: rtlwifi handling of sequence numbers with aggregation

2017-08-25 Thread Larry Finger
On 08/25/2017 12:51 PM, Jes Sorensen wrote: Hi, Looking at some bits in rtlwifi I came across a discrepancy between the PCI and USB code. Consider the following code: In rtl_pci_tx(): if (ieee80211_is_data_qos(fc)) { tid = rtl_get_tid(skb); if (sta) {

Re: [PATCH 31/35] wireless: realtek: rtl8187: constify usb_device_id

2017-08-25 Thread Hin-Tak Leung
On Tue, 8/8/17, Arvind Yadav wrote: Subject: [PATCH 31/35] wireless: realtek: rtl8187: constify usb_device_id To: kv...@codeaurora.org, her...@canonical.com, ht...@users.sourceforge.net, larry.fin...@lwfinger.net Cc:

Re: [PATCH v2] rt2800: fix TX_PIN_CFG setting for non MT7620 chips

2017-08-25 Thread Daniel Golle
On Fri, Aug 25, 2017 at 05:04:15PM +0200, Stanislaw Gruszka wrote: > Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not > initialize TX_PIN_CFG setting. This cause breakage at least on some > RT3573 devices. To fix the problem patch restores previous behaviour > for non MT7620

rtlwifi handling of sequence numbers with aggregation

2017-08-25 Thread Jes Sorensen
Hi, Looking at some bits in rtlwifi I came across a discrepancy between the PCI and USB code. Consider the following code: In rtl_pci_tx(): if (ieee80211_is_data_qos(fc)) { tid = rtl_get_tid(skb); if (sta) { sta_entry = (struct

Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

2017-08-25 Thread Jörg Krause
Hi Hans, On Fri, 2017-08-25 at 16:03 +0200, Hans de Goede wrote: > Hi, > > On 25-08-17 15:55, Jörg Krause wrote: > > Hi, > > > > On Fri, 2017-06-16 at 15:14 +0200, Hans de Goede wrote: > > > The brcm43430 chip needs different firmware files for chip revision 0 > > > and 1. The file currently in

Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

2017-08-25 Thread Jörg Krause
Hi, On Fri, 2017-06-16 at 15:14 +0200, Hans de Goede wrote: > The brcm43430 chip needs different firmware files for chip revision 0 > and 1. The file currently in linux-firmware is for revision 1 only. > > This commit makes brcmfmac request brcmfmac43430a0-sdio.bin instead > of

Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

2017-08-25 Thread Jörg Krause
Hi, On Fri, 2017-06-16 at 15:14 +0200, Hans de Goede wrote: > The brcm43430 chip needs different firmware files for chip revision 0 > and 1. The file currently in linux-firmware is for revision 1 only. > > This commit makes brcmfmac request brcmfmac43430a0-sdio.bin instead > of

[PATCH v2] rt2800: fix TX_PIN_CFG setting for non MT7620 chips

2017-08-25 Thread Stanislaw Gruszka
Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not initialize TX_PIN_CFG setting. This cause breakage at least on some RT3573 devices. To fix the problem patch restores previous behaviour for non MT7620 chips. Fixes: 41977e86c984 ("rt2x00: add support for MT7620") Bugzilla:

Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

2017-08-25 Thread Hans de Goede
Hi, On 25-08-17 16:49, Jörg Krause wrote: Thanks for the files! I've tested with brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020 and brcmfmac is happy: brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jul 1 2016 18:02:40 version 7.10.1 (A0 Station/P2P feature) FWID 01-bae8afee

Re: [PATCH] rt2800: fix TX_PIN_CFG setting for non MT7620 chips

2017-08-25 Thread Stanislaw Gruszka
On Fri, Aug 25, 2017 at 02:15:08PM +0200, Daniel Golle wrote: > Hi Stanislaw, > > On Fri, Aug 25, 2017 at 01:38:29PM +0200, Stanislaw Gruszka wrote: > > Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not > > initialize TX_PIN_CFG setting. This cause breakage at least on some >

[PATCH] rtlwifi: rtl8822be: Add firmware for new driver/device

2017-08-25 Thread Larry Finger
A driver for the RTL8822BE has been added to staging. This commit supplies the firmware for it. Signed-off-by: Larry Finger --- WHENCE | 9 + rtlwifi/rtl8822befw.bin | Bin 0 -> 127496 bytes 2 files changed, 9 insertions(+) create mode

Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip

2017-08-25 Thread Hans de Goede
Hi, On 25-08-17 15:55, Jörg Krause wrote: Hi, On Fri, 2017-06-16 at 15:14 +0200, Hans de Goede wrote: The brcm43430 chip needs different firmware files for chip revision 0 and 1. The file currently in linux-firmware is for revision 1 only. This commit makes brcmfmac request

pull-request: wireless-drivers 2017-08-25

2017-08-25 Thread Kalle Valo
Hi Dave, here's pull request to net tree for 4.13, more info in the signed tag below. Please let me know if there are any problems. Kalle The following changes since commit e9bf53ab1ee34bb05c104bbfd2b77c844773f8e6: brcmfmac: feature check for multi-scheduled scan fails on bcm4343x devices

Re: [PATCH] rt2800: fix TX_PIN_CFG setting for non MT7620 chips

2017-08-25 Thread Daniel Golle
Hi Stanislaw, On Fri, Aug 25, 2017 at 01:38:29PM +0200, Stanislaw Gruszka wrote: > Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not > initialize TX_PIN_CFG setting. This cause breakage at least on some > RT3573 devices. To fix the problem patch restores previous behaviour >

Submit patches for 4.14 NOW

2017-08-25 Thread Kalle Valo
Hi, Linus will likely release 4.13-rc7 on Sunday so we are getting very close for 4.14 merge window. So if there's something you want to have in 4.14 better submit them now or you risk missing the merge window. -- Kalle Valo

[PATCH] rt2800: fix TX_PIN_CFG setting for non MT7620 chips

2017-08-25 Thread Stanislaw Gruszka
Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not initialize TX_PIN_CFG setting. This cause breakage at least on some RT3573 devices. To fix the problem patch restores previous behaviour for non MT7620 chips. Fixes: 41977e86c984 ("rt2x00: add support for MT7620") Bugzilla:

[PATCH 1/2] rsi: missing unlocks on error paths

2017-08-25 Thread Dan Carpenter
There is a missing unlock if rsi_find_sta() fails in rsi_mac80211_ampdu_action() or if we hit the -EINVAL path in rsi_mac80211_sta_add(). Fixes: 3528608f3a79 ("rsi: handle station connection in AP mode") Signed-off-by: Dan Carpenter diff --git

[PATCH 2/2] rsi: update some comments

2017-08-25 Thread Dan Carpenter
These functions don't return -1 on failure. Signed-off-by: Dan Carpenter diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c index 25331aa16e8e..e78e87e99804 100644 --- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c

[PATCH 0/2] iwlwifi: updates intended for v4.14 2017-08-25

2017-08-25 Thread Luca Coelho
From: Luca Coelho Hi, A very tiny set of patches for v4.14. :) Nothing is backlogged in our internal tree anymore and this has been a very slow week due to vacations in our team. These are the changes: * Fix a queue hang problem due to 11w behavior * Fix a warning

[PATCH 2/2] iwlwifi: mvm: Avoid deffering non bufferable frames

2017-08-25 Thread Luca Coelho
From: David Spinadel Use bcast station for all non bufferable frames on AP and AD-HOC. The host is no longer aware of STAs PS status because of buffer station offload, so we can't rely on mac80211 to toggle on IEEE80211_TX_CTL_NO_PS_BUFFER bit. A possible issue with

[PATCH 1/2] iwlwifi: fix long debug print

2017-08-25 Thread Luca Coelho
From: Liad Kaufman There is a debug print that sometimes reaches over 110 chars, thus generating a warning in those cases. Split the print into two to prevent these cases. Fixes: 92b0f7b26b31 ("iwlwifi: split the regulatory rules when the bandwidth flags require it")

[PATCH] mac80211: Complete ampdu work schedule during session tear down

2017-08-25 Thread Luca Coelho
From: Ilan Peer Commit 7a7c0a6438b8 ("mac80211: fix TX aggregation start/stop callback race") added a cancellation of the ampdu work after the loop that stopped the Tx and Rx BA sessions. However, in some cases, e.g., during HW reconfig, the low level driver might call