RE: [PATCH] mwifiex: printk() overflow with 32-byte SSIDs

> From: Brian Norris [mailto:briannor...@chromium.org] > Sent: Wednesday, November 09, 2016 7:58 AM > To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo > Cc: linux-ker...@vger.kernel.org; linux-wireless@vger.kernel.org; Cathy > Luo; secur...@kernel.org; sta...@vger.kernel.org; Brian Norris >

Re: [PATCH v2 3/3] iwlwifi: pcie: trans: Remove unused 'shift_param'

On Tue, 2016-11-08 at 21:50 -0800, Kirtika Ruchandani wrote: > shift_param is defined and set in iwl_pcie_load_cpu_sections > but not used. Fix this to avoid -Wunused-but-set-variable > warning. > The code using it turned into dead code with commit dcab8ecd5617 > which added a separate function

Re: [PATCH v2 2/3] iwlwifi: mvm: rs: Remove unused 'mcs' variable

Another nitpick On Tue, 2016-11-08 at 21:50 -0800, Kirtika Ruchandani wrote: > Commit 5fc0f76c4 introduced Rx stats from debugfs, the function > iwl_mvm_reset_frame_stats from that commit defines and sets mcs but does not > use > it. Compiling iwlwifi with W=1 gives this warning - > >

Re: [PATCH v2 1/3] iwlwifi: mvm: rs: Remove unused 'mvmvif'/'mvmsta' variables

(removed Erarn Harary from the Cc list, since this email is not valid anymore) Hi Kirtika, Just a couple of nitpicks, nothing important, so no need to resend. On Tue, 2016-11-08 at 21:50 -0800, Kirtika Ruchandani wrote: > mvmvif is defined and set in rs_mimo_allow but not used. Compiling >

Re: [PATCH v2 0/3] Fix -Wunused-but-set-variable in iwlwifi/pcie/trans and iwlwifi/mvm/rs

On Tue, 2016-11-08 at 21:49 -0800, Kirtika Ruchandani wrote: > This patchset is part of the effort led by Arnd Bergmann to clean up > warnings in the kernel. This and following patchsets will focus on > "-Wunused-but-set-variable" as it among the noisier ones. These were > found compiling with

[PATCH v2 3/3] iwlwifi: pcie: trans: Remove unused 'shift_param'

shift_param is defined and set in iwl_pcie_load_cpu_sections but not used. Fix this to avoid -Wunused-but-set-variable warning. The code using it turned into dead code with commit dcab8ecd5617 which added a separate function iwl_pcie_load_given_ucode_8000 (then 8000b) for IWL_DEVICE_FAMILY_8000.

[PATCH v2 1/3] iwlwifi: mvm: rs: Remove unused 'mvmvif'/'mvmsta' variables

mvmvif is defined and set in rs_mimo_allow but not used. Compiling iwlwifi with W=1 gives the following warning, remove it. mvmsta is used only to obtain mvmvif so remove it as well. iwlwifi/mvm/rs.c: In function 'rs_mimo_allow': iwlwifi/mvm/rs.c:165:22: warning: variable 'mvmvif' set but not

[PATCH v2 2/3] iwlwifi: mvm: rs: Remove unused 'mcs' variable

Commit 5fc0f76c4 introduced Rx stats from debugfs, the function iwl_mvm_reset_frame_stats from that commit defines and sets mcs but does not use it. Compiling iwlwifi with W=1 gives this warning - iwlwifi/mvm/rs.c: In function ‘iwl_mvm_update_frame_stats’: iwlwifi/mvm/rs.c:3074:14: warning:

[PATCH v2 0/3] Fix -Wunused-but-set-variable in iwlwifi/pcie/trans and iwlwifi/mvm/rs

This patchset is part of the effort led by Arnd Bergmann to clean up warnings in the kernel. This and following patchsets will focus on "-Wunused-but-set-variable" as it among the noisier ones. These were found compiling with W=1. -- Changes in v2: - Made the following changes suggested by Arnd

[PATCH] mwifiex: fix memory leak in mwifiex_save_hidden_ssid_channels()

kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels(): unreferenced object 0xffc0a2914780 (size 192): comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s) hex dump (first 32 bytes): 00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40 ..GIN-2g...`l..@ 07 10

Re: [v5] ath9k: Switch to using mac80211 intermediate software queues.

> While at it, could you also add to the commit log some info how awesome this > patch is from user's point of view and how it helps. For example, before and > and after numbers and other results. That varies wildly, depending on many details of the scenario (including the wireless capabilities

[PATCH] mwifiex: printk() overflow with 32-byte SSIDs

SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length when we print them out. This can be easily noticed by connecting to a network with a 32-octet SSID: [ 3903.502925] mwifiex_pcie :01:00.0: info: trying to associate to '0123456789abcdef0123456789abcdef ' bssid

Re: [v5] ath9k: Switch to using mac80211 intermediate software queues.

Toke Høiland-Jørgensen wrote: > This switches ath9k over to using the mac80211 intermediate software > queueing mechanism for data packets. It removes the queueing inside the > driver, except for the retry queue, and instead pulls from mac80211 when > a packet is needed. The retry queue is used to

make-wifi-fast linuxplumbers talk summarized on lwn.net

and available here: https://lwn.net/SubscriberLink/705884/1bdb9c4aa048b0d5/ After the talk I discussed with several folk about applying the same debloating techniques to other chipsets. I don't remember, unfortunately, who all those folk were, nor the candidate chipsets! -- Dave Täht Let's go

Re: [v2] cw1200: Don't leak memory if krealloc failes

Johannes Thumshirn wrote: > The call to krealloc() in wsm_buf_reserve() directly assigns the newly > returned memory to buf->begin. This is all fine except when krealloc() > failes we loose the ability to free the old memory pointed to by > buf->begin. If we just create a

Re: [1/8] mwifiex: prevent register accesses after host is sleeping

Amitkumar Karwar wrote: > Following is mwifiex driver-firmware host sleep handshake. > It involves three threads. suspend handler, interrupt handler, interrupt > processing in main work queue. > > 1) Enter suspend handler > 2) Download HS_CFG command > 3) Response from

Re: [-next] mwifiex: fix missing destroy_workqueue() on error in mwifiex_add_virtual_intf()

Wei Yongjun wrote: > From: Wei Yongjun > > Add the missing destroy_workqueue() before return from > mwifiex_add_virtual_intf() in the error handling case. > > Signed-off-by: Wei Yongjun Patch applied to

Re: brcmfmac: proto: add callback for queuing TX data

Rafał Miłecki wrote: > From: Rafał Miłecki > > So far our core code was calling brcmf_fws_process_skb which wasn't > a proper thing to do. If case of devices using msgbuf protocol fwsignal > shouldn't be used. It was an unnecessary extra layer simply calling > a protocol

Re: [v2] rt2x00: add support for mac addr from device tree

Mathias Kresin wrote: > On some devices the EEPROMs of Ralink Wi-Fi chips have a default Ralink > MAC address set (RT3062F: 00:0C:43:30:62:00, RT3060F: > 00:0C:43:30:60:00). Using multiple of these devices in the same network > can cause nasty issues. > > Allow to override the

Re: [PATCH] wireless: fix bogus maybe-uninitialized warning

Arnd Bergmann writes: > The hostap_80211_rx() function is supposed to set up the mac addresses > for four possible cases, based on two bits of input data. For > some reason, gcc decides that it's possible that none of the these > four cases apply and the addresses remain

Re: [1/2] rsi: New firware loading method for RSI 91X devices

Prameela Rani Garnepudi wrote: > RSI deprecated the old firmware loading method and introduced > new method using soft boot loader for 9113 chipsets. > Current driver only supports 9113 device model hence firmware > loading method has been changed. > > In the new

Re: [3/3] rsi: Updated boot parameters

Prameela Rani Garnepudi wrote: > * Switch clock info is divided in to different clock information fields for > readability and synchronization with firmware code. > * Other parameters are added for future use and to make the frame size in sync > with latest firmware.

Re: [PATCH 2/4] ath10k: Add support to update btcoex priority value via nl80211

Hi Tamizh, [auto build test ERROR on ath6kl/ath-next] [cannot apply to v4.9-rc4 next-20161108] [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-ci/linux/commits/c_traja-qti-qualcomm-com/ath10k-Add-support

Re: [PATCH 2/4] ath10k: Add support to update btcoex priority value via nl80211

Hi Tamizh, [auto build test ERROR on ath6kl/ath-next] [cannot apply to v4.9-rc4 next-20161108] [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-ci/linux/commits/c_traja-qti-qualcomm-com/ath10k-Add-support

Re: [PATCH 1/4] ath10k: Add support to enable or disable btcoex via nl80211

Hi Tamizh, [auto build test ERROR on ath6kl/ath-next] [also build test ERROR on v4.9-rc4 next-20161108] [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-ci/linux/commits/c_traja-qti-qualcomm-com/ath10k-Add

[PATCH 4/4] ath10k: Add support to read btcoex related data from DT

From: Tamizh chelvam BTCOEX feature is not supported by all qca40xx chipsets. Since btcoex enabled by default in firmware, host needs to enable COEX support depends on the hardware. This patch is used to read btcoex_support flag and btcoex gpio pin number from DT.

[PATCH 3/4] dt: bindings: add new dt entry for BTCOEX feature in qcom,ath10k.txt

From: Tamizh chelvam There two things done in this patch. 1) 'btcoex_support' flag for BTCOEX feature support by the hardware. 2) 'wlan_btcoex_gpio' is used to fill wlan priority pin number for BTCOEX priority feature support. Signed-off-by: Tamizh chelvam

[PATCH 1/4] ath10k: Add support to enable or disable btcoex via nl80211

From: Tamizh chelvam This patch add support to enable or disable btcoex via nl80211. The firmware support this feature since 10.2.4.54 on 2G-only board, dual band or 5G boards don't support this. WMI service WMI_SERVICE_COEX_GPIO is used to identify the firmware support

[PATCH 2/4] ath10k: Add support to update btcoex priority value via nl80211

From: Tamizh chelvam This patch adds support to update btcoex priority value via nl80211. Here driver will be exposing the supported frame format for this feature via btcoex_support_flags which is a member of wiphy structure. 10.4 based firmware support this feature.

[PATCH 0/4] ath10k: Add support for BTCOEX feature.

From: Tamizh chelvam This patch set add support to enable/disable BTCOEX via nl80211, also support to update BTCOEX priority value for 10.4 based firmware. Document the dt entry in qcom,ath10k.txt and reads btcoex support flag and btcoex gpio pin detail from dt. Tamizh

[PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to support BTCOEX

From: Tamizh chelvam This change enables user to set high priority for driver supported wlan frames when BTCOEX enabled. The drivers that expose such capability make use of this priority table to decide to whom the radio should be shared (either bluetooth or WLAN). When

[PATCH 4/4] mac80211: Add support to update btcoex priority value

From: Tamizh chelvam This patch introduces a new driver callback drv_set_btcoex_priority to pass the priority value to driver. Signed-off-by: Tamizh chelvam --- include/net/mac80211.h|7 +++ net/mac80211/cfg.c|9

[PATCH 1/4] cfg80211: Add support to enable or disable btcoex

From: Tamizh chelvam This patch adds support to enable or disable btcoex by adding NL80211_ATTR_WIPHY_BTCOEX_ENABLE attribute in NL80211_CMD_SET_WIPHY command. By default BTCOEX disabled in driver. Signed-off-by: Tamizh chelvam ---

[PATCH 3/4] mac80211: Add support to enable or disable btcoex

From: Tamizh chelvam This patch introduces a new driver call back drv_set_btcoex This API will pass user space value to driver to enable or disabe btcoex. Signed-off-by: Tamizh chelvam --- include/net/mac80211.h|4

[PATCH 0/4] cfg80211: mac80211: BTCOEX feature support

From: Tamizh chelvam This patchset add support for BTCOEX feature to enable/disable btcoex and modifying btcoex priority value via nl80211. Tamizh chelvam (4): cfg80211: Add support to enable or disable btcoex cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to

RE: [PATCH v2 01/12] mwifiex: check tx_hw_pending before downloading sleep confirm

Hi > -Original Message- > From: Brian Norris [mailto:briannor...@chromium.org] > Sent: 2016年11月4日 0:12 > To: Xinming Hu > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; Amitkumar Karwar; Cathy Luo; > Shengzhen Li; Xinming Hu; Wei-Ning Huang > Subject: Re: [PATCH v2 01/12] mwifiex: check