Re: [v4,3/3] mwifiex: Enable WoWLAN for both sdio and pcie

Hi brian, On 07/07/2017 08:53 AM, Brian Norris wrote: On Mon, Jul 03, 2017 at 06:46:21PM +0800, Jeffy Chen wrote: Hi guys, with this patch, the pci device's irq might be override by this wakeup irq when not using msi: Hmm, good point. I believe I noticed this one at some point and then didn'

Re: [v4,3/3] mwifiex: Enable WoWLAN for both sdio and pcie

On Mon, Jul 03, 2017 at 06:46:21PM +0800, Jeffy Chen wrote: > Hi guys, > > with this patch, the pci device's irq might be override by this > wakeup irq when not using msi: Hmm, good point. I believe I noticed this one at some point and then didn't get to investigate further... It kind of seems l

[PATCH 4/4] cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES

From: Srinivas Dasari validate_scan_freqs() retrieves frequencies from attributes nested in the attribute NL80211_ATTR_SCAN_FREQUENCIES with nla_get_u32(), which reads 4 bytes from each attribute without validating the size of data received. Attributes nested in NL80211_ATTR_SCAN_FREQUENCIES don'

[PATCH 3/4] cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE

From: Srinivas Dasari Buffer overread may happen as nl80211_set_station() reads 4 bytes from the attribute NL80211_ATTR_LOCAL_MESH_POWER_MODE without validating the size of data received when userspace sends less than 4 bytes of data with NL80211_ATTR_LOCAL_MESH_POWER_MODE. Define nla_policy for

[PATCH 1/4] cfg80211: Check if PMKID attribute is of expected size

From: Srinivas Dasari nla policy checks for only maximum length of the attribute data when the attribute type is NLA_BINARY. If userspace sends less data than specified, the wireless drivers may access illegal memory. When type is NLA_UNSPEC, nla policy check ensures that userspace sends minimum

[PATCH 2/4] cfg80211: Check if NAN service ID is of expected size

From: Srinivas Dasari nla policy checks for only maximum length of the attribute data when the attribute type is NLA_BINARY. If userspace sends less data than specified, cfg80211 may access illegal memory. When type is NLA_UNSPEC, nla policy check ensures that userspace sends minimum specified le

Re: [PATCH] brcmfmac: buffer overflow in brcmf_cfg80211_mgmt_tx()

On Thu, Jul 6, 2017 at 10:11 AM, Arend van Spriel wrote: > > Looks fine to me so ... I really think that if we can't trust 'len', then we have to check against the lower bound of DOT11_MGMT_HDR_LEN too, because otherwise we'll just have a big 16-bit number instead. And we should do that brcmf_er

[Patch net] wl1251: add a missing spin_lock_init()

This fixes the following kernel warning: [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745 [ 5668.771850] lock: 0xce63ef20, .magic: , .owner: /-1, .owner_cpu: 0 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: GW 4.12.0-03002-gec979a4-dirty #4

Re: ath10k: ret used but uninitialized (was: Re: ath10k: add initial SDIO support)

With gcc 4.1.2: drivers/net/wireless/ath/ath10k/sdio.c: In function ‘ath10k_sdio_mbox_rxmsg_pending_handler’: drivers/net/wireless/ath/ath10k/sdio.c:676: warning: ‘ret’ may be used uninitialized in this function + + *done = true; + + /* Copy the lookahead obtained from the HTC regis

Re: brcmfmac4356-pci device not seeing 2.4Ghz channel 12 and 13

On 06-07-17 21:23, Hans de Goede wrote: > Hi, > > On 28-06-17 14:35, Arend Van Spriel wrote: >> Op 28 jun. 2017 12:07 schreef "Hans de Goede" > >: >> > >> > Hi, >> > >> > I noticed today that my GPD Win (x86 clamshell mini laptop) >> > which uses a brcmfmac4356-pci

Re: brcmfmac4356-pci device not seeing 2.4Ghz channel 12 and 13

Hi, On 28-06-17 14:35, Arend Van Spriel wrote: Op 28 jun. 2017 12:07 schreef "Hans de Goede" mailto:hdego...@redhat.com>>: > > Hi, > > I noticed today that my GPD Win (x86 clamshell mini laptop) > which uses a brcmfmac4356-pci wifi does not see an APs which > is using channel 13. > > I'v

Re: [PATCH v2] mwifiex: uninit wakeup info in the error handling

On Thu, Jul 06, 2017 at 03:55:28PM +0800, Jeffy Chen wrote: > We inited wakeup info at the beginning of mwifiex_add_card, so we need > to uninit it in the error handling. > > It's much the same as what we did in: > 36908c4 mwifiex: uninit wakeup info when removing device > > Signed-off-by: Jeffy

Re: Command equivalent in iw

On 06-07-17 16:36, Ben Greear wrote: > > > On 07/06/2017 12:38 AM, Emmanuel Grumbach wrote: >> On Thu, Jul 6, 2017 at 5:51 AM, Larry Finger >> wrote: >>> >>> Someone using the rtlwifi code that is posted at GitHub wants to know >>> the iw equivalent of "iwpriv wlan0 bandcfg" to limit the wireles

Re: [PATCH] mwifiex: fix compile warning of unused variable

On Thu, Jul 06, 2017 at 03:50:33PM +0800, Shawn Lin wrote: > We got a compile warning shows below: > > drivers/net/wireless/marvell/mwifiex/sdio.c: In function > 'mwifiex_sdio_remove': > drivers/net/wireless/marvell/mwifiex/sdio.c:377:6: warning: variable > 'ret' set but not used [-Wunused-but-set

Re: [PATCH] brcmfmac: buffer overflow in brcmf_cfg80211_mgmt_tx()

On 06-07-17 10:41, Dan Carpenter wrote: > The lower level networking code ensures that "len" is between 25 and > NL80211_ATTR_FRAME (2304). We subtract DOT11_MGMT_HDR_LEN (24) from > "len" so thats's max of 2280. But the action_frame->data[] buffer is > only BRCMF_FIL_ACTION_FRAME_SIZE (1800) byt

[PATCH] nfc: nxp-nci: constify acpi_device_id.

acpi_device_id are not supposed to change at runtime. All functions working with acpi_device_id provided by work with const acpi_device_id. So mark the non-const structs as const. File size before: textdata bss dec hex filename 2208 400 02608 a30 drivers/nf

Re: [v2 11/20] rsi: management frame descriptor preparation cleanup

On Thu, Jun 29, 2017 at 12:06 AM, Kalle Valo wrote: > Kalle Valo writes: > >> Amitkumar Karwar writes: >> >>> From: "pavani.muthyala" >>> >>> Currently this descriptor is prepared with the help of __le16 >>> pointer. This patch makes use of a structure to prepare the >>> descriptor in a cleaner

Re: [v2 07/20] rsi: correct the logic of deriving queue number

On Thu, Jun 29, 2017 at 12:02 AM, Kalle Valo wrote: > Amitkumar Karwar writes: > >> Maximum valid queue number is 0x5. So anding with 0x7 should be >> ok here. >> >> Signed-off-by: Amitkumar Karwar > > The separate From header is missing which you had in v1. Thanks. This is corrected in v3. Re

Re: [v2 01/20] rsi: changes in eeprom read frame

On Thu, Jun 29, 2017 at 12:10 AM, Kalle Valo wrote: > Amitkumar Karwar writes: > >> From: Prameela Rani Garnepudi >> >> EEPROM read frame is sent during device initialization to read mac address. >> The format of the frame is modified in firmware to include eeprom length >> and offset. This fram

[v3 21/21] rsi: Rename mutex tx_rxlock to the tx_lock.

From: Karun Eagalapati We have now added separate lock for Rx. This lock is used to protect tx path only Signed-off-by: Karun Eagalapati Signed-off-by: Amitkumar Karwar Signed-off-by: Prameela Rani Garnepudi --- drivers/net/wireless/rsi/rsi_91x_core.c | 10 +- drivers/net/wireless/rs

[v3 19/21] rsi: SDIO Rx packet processing enhancement

From: Karun Eagalapati Newer firmware sends information about number of blocks through interrupt only. We don't need to read extra register for this. This patch adds needed driver changes for this enhancment. The change here is backward compatible Signed-off-by: Karun Eagalapati Signed-off-by:

[v3 20/21] rsi: use separate mutex lock for receive thread

From: Karun Eagalapati Deadlock issue is observed during our stress tests. The root cause for the issue is same lock is used between tx and rx threads. This patch adds a separate mutex lock for rx thread to resolve the problem. Signed-off-by: Karun Eagalapati Signed-off-by: Amitkumar Karwar S

[v3 18/21] rsi: Optimise sdio claim and release host

From: Karun Eagalapati SDIO host is already claimed in our interrupt handler. Some lower level APIs claims host while performing SDIO read or write operations. Let's use sdio_irq_task variable to check if we are in interrupt context and claim/release the host accordingly. Signed-off-by: Karun Ea

[v3 16/21] rsi: separate function for data packet descriptor

From: Pavani Muthyala Data packet descriptor preparation code is moved a separate function. Signed-off-by: Pavani Muthyala Signed-off-by: Amitkumar Karwar Signed-off-by: Prameela Rani Garnepudi --- drivers/net/wireless/rsi/rsi_91x_hal.c | 51 +++--- 1 file changed

[v3 14/21] rsi: data packet descriptor code cleanup

From: Pavani Muthyala Currently this descriptor is prepared with the help of __le16 pointer. This patch makes use of a structure to prepare the descriptor in a cleaner way. Signed-off-by: Pavani Muthyala Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_hal.c | 41 +

[v3 17/21] rsi: rename variable in_sdio_litefi_irq

From: Karun Eagalapati The variable in_sdio_litefi_irq is renamed to sdio_irq_task, as it is more relevant here. Signed-off-by: Karun Eagalapati Signed-off-by: Amitkumar Karwar Signed-off-by: Prameela Rani Garnepudi --- drivers/net/wireless/rsi/rsi_sdio.h | 2 +- 1 file changed, 1 insertion(

[v3 15/21] rsi: data packet descriptor enhancements

From: Pavani Muthyala This patch covers some enhancements in data packet descriptor preparation especially for EAPOL, multicast/broadcast packets. Signed-off-by: Pavani Muthyala Signed-off-by: Amitkumar Karwar Signed-off-by: Prameela Rani Garnepudi --- drivers/net/wireless/rsi/rsi_91x_hal.c

[v3 13/21] rsi: separate function for management packet descriptor

From: Prameela Rani Garnepudi Management descriptor preparation is move to a separate function as it will be called from a different context in upcoming patches. Signed-off-by: Prameela Rani Garnepudi --- drivers/net/wireless/rsi/rsi_91x_hal.c | 132 + drivers/n

[v3 08/21] rsi: correct the logic of deriving queue number

From: Amitkumar Karwar Maximum valid queue number is 0x5. So anding with 0x7 should be ok here. Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c b/drivers/net/w

[v3 12/21] rsi: management frame descriptor preparation cleanup

From: Pavani Muthyala Currently this descriptor is prepared with the help of __le16 pointer. This patch makes use of a structure to prepare the descriptor in a cleaner way. Signed-off-by: Pavani Muthyala Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_hal.c | 37 +

[v3 10/21] rsi: choose correct endpoint based on queue.

From: Karun Eagalapati Till now only management packets were handled. Let's enhance the logic for choosing endpoint to accommodate other packets. Signed-off-by: Karun Eagalapati Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_usb.c | 3 ++- 1 file changed, 2 insertions(+)

[v3 07/21] rsi: USB tx headroom cleanup

From: Karun Eagalapati USB headroom is added while submitting the data to URB as per firmware's requirement. This logic is moved to rsi_usb_card_write() so that caller need not worry about it. Signed-off-by: Karun Eagalapati Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x

[v3 11/21] rsi: set immediate wakeup bit

From: Karun Eagalapati immediate wakeup bit is set while sending internal management frame to the firmware. Signed-off-by: Karun Eagalapati Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_hal.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/rsi/r

[v3 06/21] rsi: card reset for USB interface

From: Karun Eagalapati We need to reset the chip in teardown path so that it can work next time when driver is loaded. This patch adds support for this reset configuration for USB. Signed-off-by: Karun Eagalapati Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_usb.c | 72

[v3 09/21] rsi: rename USB endpoint macros

From: Karun Eagalapati These endpoints are for WLAN and BT protocols. Signed-off-by: Karun Eagalapati Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_usb.c | 2 +- drivers/net/wireless/rsi/rsi_usb.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --gi

[v3 05/21] rsi: correct SDIO disconnect path handling

From: Karun Eagalapati Sometimes it's observed that we get interrupt/Rx frame when device is already detached from mac80211. In this case couple of error messages are displayed in dmesg log. This patch corrects the order so that disconnection will happen cleanly Signed-off-by: Karun Eagalapati

[v3 02/21] rsi: changes in eeprom read frame

From: Prameela Rani Garnepudi EEPROM read frame is sent during device initialization to read mac address. The format of the frame is modified in firmware to include eeprom length and offset. This frame does not return firmware version now. Also same frame is sent again to read rf type and band in

[v3 01/21] rsi: use BUILD_BUG_ON check for fsm_state

From: Amitkumar Karwar Whenever new fsm_state enum element is added, fsm_state array also needs to be updated. If this change is missed, we may end up doing invalid access in array. BUILD_BUG_ON check will help to avoid this problem. Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi

[v3 03/21] rsi: fix sdio card reset problem

From: Karun Eagalapati card reset is not working with recent kernels. Using host->card->ocr instead of host->ocr_avail solved the problem. Signed-off-by: Karun Eagalapati Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_sdio.c | 26 +- 1 file change

[v3 04/21] rsi: chip reset for SDIO interface

From: Karun Eagalapati We need to reset the chip in teardown path so that it can work next time when driver is loaded. This patch adds support for this reset configuration for SDIO. Signed-off-by: Karun Eagalapati Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_sdio.c | 8

[v3 00/21] rsi driver enhancements

From: Amitkumar Karwar This patch series includes some fixes and enhancements in Tx and Rx data paths. Connection in open security and data traffic has been verified with SDIO and USB variants of 9113 chipset. Changes in v3 series: 1/21: Newly added patch in v3 which makes use of BUILD_BUG_ON to

Re: Command equivalent in iw

On 07/06/2017 12:38 AM, Emmanuel Grumbach wrote: On Thu, Jul 6, 2017 at 5:51 AM, Larry Finger wrote: Someone using the rtlwifi code that is posted at GitHub wants to know the iw equivalent of "iwpriv wlan0 bandcfg" to limit the wireless interface to 802.11b, 802.11g, or 802.11n. I only use

Re: ath10k: Increase buffer len to print all wmi services.

c_tr...@qti.qualcomm.com wrote: > All wmi_services are not printing when we give below command. > > cat /sys/kernel/debug/ieee80211/phyX/ath10k/wmi_services > > This patch increases the buffer_len to 8192 to print all the wmi_services. > > Signed-off-by: Tamizh chelvam > Signed-off-by: Kalle V

Re: [1/2] ath10k: Make CE layer bus agnostic

Govind Singh wrote: > Remove bus specific dependencies from CE layer > to have common CE layer across multiple targets. > This is required for adding support for WCN3990 > chipset support as WCN3990 chipset uses SNOC > bus interface with Copy Engine endpoint. > > Signed-off-by: Govind Singh > S

Re: ath10k: fix indenting in ath10k_wmi_update_noa()

Kalle Valo wrote: > Commit 59ae1d127ac0 ("networking: introduce and use skb_put_data()") > introduced > a new checkpatch warning: > > drivers/net/wireless/ath/ath10k/wmi.c:3308: code indent should use tabs where > possible > > Fix that. > > Signed-off-by: Kalle Valo Patch applied to ath-ne

[PATCH v3 2/2] ath10k: add initial USB support

From: Erik Stromdahl Chipsets like QCA9377 have support for USB so add initial USB bus support to ath10k. With this patch we have the low level HIF and HTC protocol working and it's possible to boot the firmware, but it's still not possible to connect or anything like. More changes are needed fo

[PATCH v3 1/2] ath10k: various usb related definitions

From: Erik Stromdahl Definitions for USB based chipsets Signed-off-by: Erik Stromdahl Patchwork-Id: 9738771 Signed-off-by: Kalle Valo --- drivers/net/wireless/ath/ath10k/core.c |1 + drivers/net/wireless/ath/ath10k/core.h |3 +++ drivers/net/wireless/ath/ath10k/debug.h |2 ++ 3

[PATCH v3 0/2] ath10k usb support

Here's v3 of usb support patches. I mostly cosmetic changes to follow the style used elsewhere in ath10k. Only compile tested, but it should still work :) I think these are now ready for commit. I did have few open questions (but they don't prevent committing these): * why atomic allocations? *

[bug report] rtlwifi: Fill ap_num field by driver

Hello Ping-Ke Shih, The patch c76ab8e75442: "rtlwifi: Fill ap_num field by driver" from Jun 21, 2017, leads to the following static checker warning: drivers/net/wireless/realtek/rtlwifi/base.c:1741 rtl_scan_list_expire() error: dereferencing freed memory 'entry' drivers/net/wirel

Re: [RFC v2 0/3] ath10k usb support

Erik Stromdahl writes: > This is the 2nd version of the ath10k USB RFC. There are only minor updates > since last version. > > The main difference when compared to the previous RFC is that the > high latency stuff that is common between USB and SDIO has been moved out > of this patchset and into

Re: [PATCH] mwifiex: uninit wakeup info when failed to add card

Hi brian, On 07/06/2017 02:08 AM, Brian Norris wrote: On Mon, Jul 03, 2017 at 03:54:30PM +0800, Jeffy Chen wrote: We inited wakeup info at the beginning of mwifiex_add_card, so we need to uninit it in the error handling. It's much the same as what we did in: 36908c4 mwifiex: uninit wakeup info

[PATCH] brcmfmac: buffer overflow in brcmf_cfg80211_mgmt_tx()

The lower level networking code ensures that "len" is between 25 and NL80211_ATTR_FRAME (2304). We subtract DOT11_MGMT_HDR_LEN (24) from "len" so thats's max of 2280. But the action_frame->data[] buffer is only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can overflow.

ath10k: ret used but uninitialized (was: Re: ath10k: add initial SDIO support)

On Wed, Jul 5, 2017 at 9:52 PM, Linux Kernel Mailing List wrote: > Web: > https://git.kernel.org/torvalds/c/d96db25d20256208ce47d71b9f673a1de4c6fd7e > Commit: d96db25d20256208ce47d71b9f673a1de4c6fd7e > Parent: f008d1537bf88396cf41a7c7a831e3acd1ee92a1 > Refname:refs/heads/master

Re: [PATCH] mwifiex: fix compile warning of unused variable

Hi Kalle, On 2017/7/6 15:57, Kalle Valo wrote: Shawn Lin writes: We got a compile warning shows below: drivers/net/wireless/marvell/mwifiex/sdio.c: In function 'mwifiex_sdio_remove': drivers/net/wireless/marvell/mwifiex/sdio.c:377:6: warning: variable 'ret' set but not used [-Wunused-but-set

Re: [PATCH] mwifiex: fix compile warning of unused variable

Shawn Lin writes: > We got a compile warning shows below: > > drivers/net/wireless/marvell/mwifiex/sdio.c: In function > 'mwifiex_sdio_remove': > drivers/net/wireless/marvell/mwifiex/sdio.c:377:6: warning: variable > 'ret' set but not used [-Wunused-but-set-variable] > > Per the code, it didn't c

[PATCH v2] mwifiex: uninit wakeup info in the error handling

We inited wakeup info at the beginning of mwifiex_add_card, so we need to uninit it in the error handling. It's much the same as what we did in: 36908c4 mwifiex: uninit wakeup info when removing device Signed-off-by: Jeffy Chen --- Changes in v2: Uninit wakeup when _mwifiex_fw_dpc failed too.

[PATCH] mwifiex: fix compile warning of unused variable

We got a compile warning shows below: drivers/net/wireless/marvell/mwifiex/sdio.c: In function 'mwifiex_sdio_remove': drivers/net/wireless/marvell/mwifiex/sdio.c:377:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] Per the code, it didn't check if mwifiex_sdio_read_fw_statu

Re: [PATCH] ath10k: set a-mpdu reference number in ath10k (receiver)

Matthias Frei writes: > Set the a-mpdu reference number in ath10k to make it accessible in the > receivers radiotap header. Implemented as in ath9k. > The reference number is needed for troubleshooting and research at the > receivers site (e.g. to identify mpdu's that were aggregated in an a-m

Re: Command equivalent in iw

On Thu, Jul 6, 2017 at 5:51 AM, Larry Finger wrote: > > Someone using the rtlwifi code that is posted at GitHub wants to know the iw > equivalent of "iwpriv wlan0 bandcfg" to limit the wireless interface to > 802.11b, 802.11g, or 802.11n. I only use simple iw commands, and I could not > answer