[PATCH] rtlwifi: Replace hardcode value with macro

In _rtl_init_mac80211(), hardcoded value for hw->max_listen_interval and hw->max_rate_tries are replaced by macro. --- drivers/net/wireless/realtek/rtlwifi/base.c | 6 +++--- drivers/net/wireless/realtek/rtlwifi/base.h | 2 ++ 2 files changed, 5 insertions(+), 3 deletions(-) diff --git

Re: [PATCH][net-next] qtnfmac: fix uninitialized return code in ret

On Wed, Jun 21, 2017 at 02:25:30PM +0100, Colin King wrote: > From: Colin Ian King > > The return value ret is unitialized and garbage is being returned > for the three different error conditions when setting up the PCIe > BARs. Fix this by initializing ret to -ENOMEM

Re: cfg80211_ops

On Wed, Jun 21, 2017 at 05:53:13PM -0700, Igor Mitsyanko wrote: > On 06/21/2017 05:03 PM, Tobin C. Harding wrote: > > > >Hi, > > > >Is some one able to please confirm for me that the following > >cfg80211_ops callbacks are enough to implement a minimal functioning > >Wi-Fi driver. Assume that a

ath9k wds mode unstable

all: ATH9k wds mode, station will block. No packet will receive. https://bugs.lede-project.org/index.php?do=details_id=776=ath9k%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=%5B0%5D=open%5B0%5D

[PATCH 3/3] ath9k: Use mutex_lock to avoid potential race in start/stop rng

From: Miaoqing Pan Move ath9k_rng_stop/ath9k_rng_start pair into critical section, use mutex_lock to void potential race accessing. Signed-off-by: Miaoqing Pan --- drivers/net/wireless/ath/ath9k/main.c | 8 1 file changed, 4

[PATCH 1/3] ath9k: fixed an invalid pointer dereference

From: Miaoqing Pan The bug was triggered when do suspend/resuming continuously on Dell XPS L322X/0PJHXN version 9333 (2013) with kernel 4.12.0-041200rc4-generic. But can't reproduce on DELL E5440 + AR9300 PCIE chips. The warning is caused by accessing invalid pointer

[PATCH 2/3] ath9k: avoid potential freezing

From: Miaoqing Pan In the worst case, ath9k_rng_stop() may take 10s to stop rng kthread. The time is too long for users, use wait_event_interruptible_timeout() instead of msleep_interruptible(), wakup immediately once kthread_should_stop() is true. Signed-off-by:

Re: [PATCH 0/5] rtlwifi: Neatening

On Wed, 2017-06-21 at 13:12 -0500, Larry Finger wrote: > On 06/19/2017 03:18 PM, Joe Perches wrote: [] > In general, I approve of your patches. Unfortunately, they will conflict with > a > number of changes that I am currently making. If you would like, I can merge > your patches, fix the

Re: cfg80211_ops

On 06/21/2017 05:03 PM, Tobin C. Harding wrote: Hi, Is some one able to please confirm for me that the following cfg80211_ops callbacks are enough to implement a minimal functioning Wi-Fi driver. Assume that a virtual interface is added during driver initialization. scan add_key get_key

cfg80211_ops

Hi, Is some one able to please confirm for me that the following cfg80211_ops callbacks are enough to implement a minimal functioning Wi-Fi driver. Assume that a virtual interface is added during driver initialization. scan add_key get_key del_key sat_default_key connect disconnect

Re: [RFC 3/6] mac80211: add a TXQ for other powersave-buffered frames

On 06/21/2017 04:50 PM, Johannes Berg wrote: From: Johannes Berg Some drivers may want to also use the TXQ abstraction with non-data packets that need powersave buffering, so add a hardware flag to allow this. Change ath9k/ath10k to use these by dequeuing the frames

[RFC 6/6] mac80211: always go through txqs

From: Johannes Berg Signed-off-by: Johannes Berg --- drivers/net/wireless/mac80211_hwsim.c | 1 + include/net/mac80211.h| 6 ++- net/mac80211/debugfs.c| 2 +- net/mac80211/debugfs_netdev.c | 2 +-

[RFC 3/6] mac80211: add a TXQ for other powersave-buffered frames

From: Johannes Berg Some drivers may want to also use the TXQ abstraction with non-data packets that need powersave buffering, so add a hardware flag to allow this. Change ath9k/ath10k to use these by dequeuing the frames immediately and invoking the normal TX path for

[RFC 1/6] mac80211: agg-tx: call drv_wake_tx_queue in proper context

From: Johannes Berg Since drv_wake_tx_queue() is normally called in the TX path, which is already in an RCU critical section, we should call it the same way in the aggregation code path, so if the driver expects to be able to use RCU, it'll already be protected without

[RFC 5/6] mac80211: add a general fallback TXQ

From: Johannes Berg In a number of cases, like management frames, mac80211 will not put the frame on any TXQ but immediately TX it to the driver. It'd be nicer to be able to use TXQs for all frames, so add a "fallback" TXQ. This will serve as a container to be able to

[RFC 4/6] mac80211: don't put null-data frames on the normal TXQ

From: Johannes Berg Since (QoS) NDP frames shouldn't be put into aggregation nor are assigned real sequence numbers, etc. it's better to treat them as non-data packets and not put them on the normal TXQs. Signed-off-by: Johannes Berg ---

[RFC 2/6] mac80211: fix VLAN handling with TXQs

From: Johannes Berg With TXQs, the AP_VLAN interfaces are resolved to their owner AP interface when enqueuing the frame, which makes sense since the frame really goes out on that as far as the driver is concerned. However, this introduces a problem: frames to be

Re: [PATCH] wireless: brcmfmac: initialize oob irq data before request_irq()

On 13-06-17 18:02, Michał Mirosław wrote: > This fixes spin-forever in irq handler when IRQ is already asserted > at request_irq() time. With all the patchwork misery flying by I almost forgot to respond to this. We suspect you are covering up a hardware issue here. At the time of the

Re: [PATCH 05/14] mwifiex: re-register wiphy across reset

Hi Johannes, On Fri, Jun 09, 2017 at 11:03:38AM +0200, Johannes Berg wrote: > On Mon, 2017-06-05 at 18:54 +0300, Kalle Valo wrote: > > > > BTW, since you're taking an interest in this code now, can I > > > trouble you with a question? Looking at mwifiex_uninit_sw() (after > > > this patchset),

Re: [PATCH 0/5] rtlwifi: Neatening

On 06/19/2017 03:18 PM, Joe Perches wrote: Joe Perches (5): rtlwifi: Use temporary ops variable to reduce code size rtlwifi: Use temporary variable btc_ops for rtlpriv->btcoexist.btc_ops rtlwifi: Add and use convenience macro rtl_btc realtek: btcoexist: Make the rtl_btc_ops struct

Re: [PATCH 05/14] mwifiex: re-register wiphy across reset

Hi Kalle (and Johannes; I'll reply to Johannes response separately too), On Mon, Jun 05, 2017 at 06:54:18PM +0300, Kalle Valo wrote: > Brian Norris writes: > > That's not to say that there aren't such bugs out there. I'd still be > > willing to bet there are. And IMO,

[PATCH v2 3/8] rtlwifi: Modify power mode parameters of 8723be and 8821ae.

From: Ping-Ke Shih Change the parameters suggested by FW. awake int: 2 smart_ps: 2 or 0 ps_mode: 2 (MAX -- every DTIM) Signed-off-by: Ping-Ke Shih Signed-off-by: Larry Finger Cc: Yan-Hsuan Chuang Cc:

[PATCH v2 1/8] rtlwifi: Fix a2dp choppy while BT RSSI stays on threshold.

From: Ping-Ke Shih In this case, BTC asks to enter/leave PS mode frequently to cause A2DP choppy. Signed-off-by: Ping-Ke Shih Signed-off-by: Larry Finger Cc: Yan-Hsuan Chuang Cc: Birming Chiu

[PATCH v2 2/8] rtlwifi: Do IQK only once to reduce wifi occupy antenna

From: Ping-Ke Shih Modify 8723be and 8192e only. 8812/8821 do IQK in DM, so we may do it later. Signed-off-by: Ping-Ke Shih Signed-off-by: Larry Finger Cc: Yan-Hsuan Chuang Cc: Birming Chiu

[PATCH v2 5/8] rtlwifi: Add return value to btc_set.

From: Ping-Ke Shih We will use return value to handle error case. Signed-off-by: Ping-Ke Shih Signed-off-by: Larry Finger Cc: Yan-Hsuan Chuang Cc: Birming Chiu Cc: Shaofu

[PATCH v2 8/8] rtlwifi: Add in_4way field for btcoexist

From: Ping-Ke Shih If wifi is in 4way, btcoex give wifi higher priority to use antenna. Signed-off-by: Ping-Ke Shih Signed-off-by: Larry Finger Cc: Yan-Hsuan Chuang Cc: Birming Chiu

[PATCH v2 7/8] rtlwifi: Fill ap_num field by driver

From: Ping-Ke Shih Check beacon and probe_resp frames to know ap_num Signed-off-by: Ping-Ke Shih Signed-off-by: Larry Finger Cc: Yan-Hsuan Chuang Cc: Birming Chiu Cc: Shaofu

[PATCH v2 6/8] rtlwifi: Add ap_num field for btcoexist

From: Ping-Ke Shih If there are many AP (dirty environment), we use another strategy set to resolve coex issue. Signed-off-by: Ping-Ke Shih Signed-off-by: Larry Finger Cc: Yan-Hsuan Chuang Cc: Birming

[PATCH v2 0/8] Set 2 of changes related to updates of btcoexist

To get maximum benefit of the recent changes in btcoexist, changes need to be made in the drivers for the NIC. This is set 2 of those changes. V2 - Two two patches that added vendor commands have been dropped from this submission as requested. They will be addressed later. Larry

[PATCH v2 4/8] rtlwifi: Update some cases in btc_get function -- roam, 5G, AP mode, and return value.

From: Ping-Ke Shih Return value may be false in some situations. Signed-off-by: Ping-Ke Shih Signed-off-by: Larry Finger Cc: Yan-Hsuan Chuang Cc: Birming Chiu Cc: Shaofu

Re: [PATCH] wireless: brcmfmac: initialize oob irq data before request_irq()

Michał Mirosław writes: > This fixes spin-forever in irq handler when IRQ is already asserted > at request_irq() time. > > Signed-off-by: Michał Mirosław To avoid the UTF-8 problem I skipped patchwork and applied this manually to

Re: [v2] mwifiex: fixes the unexpected be printed log by default

Caesar Wang wrote: > This patch uses WARN level is not printed by default. > > In some cases, some boards have always met the unused log be printed as > follows. > ... > [23193.523182] mwifiex_pcie :01:00.0: mwifiex_get_cfp: > cannot find cfp by band 2& channel=13

Re: [01/11] rtlwifi: btcoex: call bind to setup btcoex

Larry Finger wrote: > From: Ping-Ke Shih > > New btcoex add a function 'bind' to connect adapter, so we should call > it during initializing. > > Signed-off-by: Ping-Ke Shih > Signed-off-by: Larry Finger

Re: [v2,1/6] rsi: add usb RS9113 chipset support

amit karwar wrote: > From: Prameela Rani Garnepudi > > usb device id and vendor id for RS9113 chipset are included. > So it can be used through usb interface. > > Signed-off-by: Prameela Rani Garnepudi > Signed-off-by:

Re: mwifiex: debugfs: remove redunant check of mwifiex_dfs_dir

Shawn Lin wrote: > debugfs_remove already check mwifiex_dfs_dir, so remove it. > > Signed-off-by: Shawn Lin Patch applied to wireless-drivers-next.git, thanks. 7c26029f87a3 mwifiex: debugfs: remove redunant check of mwifiex_dfs_dir --

Re: rtlwifi: fix REG_USTIME_TSF register definition

Kevin Lo wrote: > The REG_USTIME_TSF (US Time Tuning for TSF) definition of Realtek chips > should be 0x55C. > > Signed-off-by: Kevin Lo > > diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/reg.h >

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

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 brcmfmac43430-sdio.bin for

Re: [07/10] rtlwifi: Fill ap_num filed by vendor command

Larry Finger wrote: > From: Ping-Ke Shih > > The ap_num can be filled by wpa_cli's VENDOR command. > > Signed-off-by: Ping-Ke Shih > Signed-off-by: Larry Finger > Cc: Yan-Hsuan Chuang

let me know

Hello, important charity foundation proposal to discuss with you, if you are interested please reply urgently for details. with love, CELINE

Re: [PATCH 11/11] rtlwifi: btcoexist control to enter/leave LPS

Larry Finger writes: > From: Ping-Ke Shih > > To yield better user experience, have btcoex control LPS's parameters. > > Signed-off-by: Ping-Ke Shih > Signed-off-by: Larry Finger > Cc: Yan-Hsuan

Re: [PATCH][net-next] qtnfmac: fix uninitialized return code in ret

On 21/06/17 14:54, Sergey Matyukevich wrote: >> The return value ret is unitialized and garbage is being returned >> for the three different error conditions when setting up the PCIe >> BARs. Fix this by initializing ret to -ENOMEM to indicate that >> the BARs failed to be setup correctly. >> >>

Re: [PATCH][net-next] qtnfmac: fix uninitialized return code in ret

> The return value ret is unitialized and garbage is being returned > for the three different error conditions when setting up the PCIe > BARs. Fix this by initializing ret to -ENOMEM to indicate that > the BARs failed to be setup correctly. > > Detected by CoverityScan, CID#1437563

Re: [1/2] ath9k: fix tx99 use after free

miaoqing pan wrote: > One scenario that could lead to UAF is two threads writing > simultaneously to the "tx99" debug file. One of them would > set the "start" value to true and follow to ath9k_tx99_init(). > Inside the function it would set the sc->tx99_state to true >

[PATCH][net-next] qtnfmac: fix uninitialized return code in ret

From: Colin Ian King The return value ret is unitialized and garbage is being returned for the three different error conditions when setting up the PCIe BARs. Fix this by initializing ret to -ENOMEM to indicate that the BARs failed to be setup correctly. Detected by

Re: [v3,1/3] wil6210: prevent platform callbacks after uninit

Maya Erez wrote: > After calling platform_ops.uninit() it is still possible to invoke > platform callbacks. > To prevent this, zero platform_ops right after invoking uninit. > > Signed-off-by: Dedy Lansky > Signed-off-by: Maya Erez

Re: [RFC] mac80211: support non-data TXQs

On Wed, 2017-06-21 at 11:24 +0200, Johannes Berg wrote: > On Wed, 2017-06-21 at 11:14 +0200, Johannes Berg wrote: > > On Wed, 2017-06-21 at 10:48 +0200, Arend van Spriel wrote: > > > > > > So for the sake of ath{9,10}k and possible future drivers you may > > > want  to document it clearly in

[PATCH] ath10k: add const to thermal_cooling_device_ops structure

Declare thermal_cooling_device_ops structure as const as it is only passed as an argument to the function thermal_cooling_device_register and this argument is of type const. So, declare the structure as const. Signed-off-by: Bhumika Goyal ---

Re: [RFC] mac80211: support non-data TXQs

On Wed, 2017-06-21 at 11:14 +0200, Johannes Berg wrote: > On Wed, 2017-06-21 at 10:48 +0200, Arend van Spriel wrote: > > > > So for the sake of ath{9,10}k and possible future drivers you may > > want  to document it clearly in mac80211.h(?), ie. when driver does > > not want a  separate non-data

Re: [RFC] mac80211: support non-data TXQs

On Wed, 2017-06-21 at 10:48 +0200, Arend van Spriel wrote: > > So for the sake of ath{9,10}k and possible future drivers you may > want  to document it clearly in mac80211.h(?), ie. when driver does > not want a  separate non-data txq they should use IEEE80211_NUM_TIDS. Yeah, will do. johannes

Re: [RFC] mac80211: support non-data TXQs

On 6/21/2017 10:37 AM, Johannes Berg wrote: On Wed, 2017-06-21 at 09:09 +0200, Johannes Berg wrote: On Tue, 2017-06-20 at 21:19 -0700, Igor Mitsyanko wrote: - struct ieee80211_txq *txq[IEEE80211_NUM_TIDS]; + struct ieee80211_txq *txq[IEEE80211_NUM_TIDS + 1]; Isn't that a little

[PATCH] iwlwifi: mvm: add const to thermal_cooling_device_ops structure

Declare thermal_cooling_device_ops structure as const as it is only passed as an argument to the function thermal_cooling_device_register and this argument is of type const. So, declare the structure as const. Signed-off-by: Bhumika Goyal ---

Re: [RFC] mac80211: support non-data TXQs

On Wed, 2017-06-21 at 09:09 +0200, Johannes Berg wrote: > On Tue, 2017-06-20 at 21:19 -0700, Igor Mitsyanko wrote: > > > > - struct ieee80211_txq *txq[IEEE80211_NUM_TIDS]; > > > + struct ieee80211_txq *txq[IEEE80211_NUM_TIDS + 1]; > > > > Isn't that a little confusing? Wouldn't it be better to

Re: [RFC] mac80211: support non-data TXQs

On Wed, 2017-06-21 at 00:38 -0700, Igor Mitsyanko wrote: > > > That's standard for management frames, I really didn't think that'd > > need any comment? > > You're right, for some reason I thought about "null data" frames > instead of "no data" frames. Well, the next patch actually does put

Re: [RFC] mac80211: support non-data TXQs

On 06/21/2017 12:09 AM, Johannes Berg wrote: [snip] [please trim the amount of text you quote] - txqi->txq.ac = ieee80211_ac_from_tid(tid); + if (tid == IEEE80211_NUM_TIDS + 1) + txqi->txq.ac = IEEE80211_AC_VO; Why voice, maybe commit message should

Re: [RFC] mac80211: support non-data TXQs

On Tue, 2017-06-20 at 21:19 -0700, Igor Mitsyanko wrote: > > - struct ieee80211_txq *txq[IEEE80211_NUM_TIDS]; > > + struct ieee80211_txq *txq[IEEE80211_NUM_TIDS + 1]; > > Isn't that a little confusing? Wouldn't it be better to have a > separate  member for non-data txq and name it

RE: [PATCH] mac80211: don't look at the PM bit of BAR frames

> > On 06/08/2017 04:00 AM, Emmanuel Grumbach wrote: > > When a peer sends a BAR frame with PM bit clear, we should not modify > > its PM state as madated by the spec in > > 802.11-20012 10.2.1.2. > > > > Signed-off-by: Emmanuel Grumbach > >