Re: [PATCH] brcmfmac: add support for external 32khz clock

Hi, > Kalle Valo hat am 7. November 2017 um 03:18 > geschrieben: > > > Stefan Wahren writes: > > >> Simon Shields hat am 4. November 2017 um 14:24 > >> geschrieben: > >> > >> > >> Some boards use an external 32khz clock

Re: Need support for Intel new wifi module 9462NGW

Hi Luca, I just tried the firmware but seems still something wrong. dmesg shows me the following [ 17.786041] Intel(R) Wireless WiFi driver for Linux [ 17.786042] Copyright(c) 2003- 2015 Intel Corporation [ 18.120052] iwlwifi :00:0c.0: loaded firmware version 33.610294.0 op_mode

Re: [PATCH 3/3] mwifiex: cleanup rx_reorder_tbl_lock usage

Hi, I haven't reviewed this patch in its entirety, but I'm pretty sure you're introducing a reliable AA deadlock. See below. Are you sure you're actually testing these codepaths? On Tue, Oct 31, 2017 at 03:12:47PM +0530, Ganapathi Bhat wrote: > From: Karthik Ananthapadmanabha

Re: [PATCH] brcmfmac: add support for external 32khz clock

Stefan Wahren writes: >> Simon Shields hat am 4. November 2017 um 14:24 >> geschrieben: >> >> >> Some boards use an external 32khz clock for low-power >> mode timing. Make sure the clock is powered on while the chipset >> is active. >> >>

Re: [EXT] Re: [PATCH 1/3] mwifiex: cleanup rx_pkt_lock usage in 11n_rxreorder.c

Hi, Please take the review below with a grain of salt since I'm not terribly familiar with this driver. I thought I might be able to help since I had previously looked at some of the spinlock stuff, but after digging through the below I'm not 100% convinced I understand this driver enough to do

[PATCH] rsi: rsi_91x_ps: remove redundant code in str_psstate

"INVALID_STATE" is already being returned in the default case and this code cannot be reached. Addresses-Coverity-ID: 1398384 Signed-off-by: Gustavo A. R. Silva --- drivers/net/wireless/rsi/rsi_91x_ps.c | 1 - 1 file changed, 1 deletion(-) diff --git

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

On 11/06/2017 01:02 AM, Sven Eckelmann wrote: On Montag, 6. November 2017 09:28:42 CET Sebastian Gottschall wrote: Am 06.11.2017 um 09:23 schrieb Sven Eckelmann: On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote: the assumption made in this patch is obviously wrong (at

Re: [PATCH 13/17] iwlwifi: mvm: Convert timers to use timer_setup()

On Mon, Nov 6, 2017 at 11:48 AM, Luca Coelho wrote: > On Mon, 2017-11-06 at 11:45 -0800, Kees Cook wrote: >> On Sun, Oct 29, 2017 at 5:28 AM, Luca Coelho wrote: >> > From: Kees Cook >> > >> > In preparation for unconditionally passing the

RE: [PATCH] mac80211: Update last_ack status for all except probing frames

> >>> Update last_ack status for all except station probing frames (i.e > >>> null data). Otherwise the station inactivity duration is cleared > >>> whenever AP is checking presence of idle stations by sending null > >>> data frame for every inactive threshold (ap_max_inactivity). > >> > >> You

Re: [PATCH] mac80211: Update last_ack status for all except probing frames

On 11/06/2017 09:44 AM, Rajkumar Manoharan wrote: On Mon, 2017-10-30 at 17:29 -0700, Rajkumar Manoharan wrote: Update last_ack status for all except station probing frames (i.e null data). Otherwise the station inactivity duration is cleared whenever AP is checking presence of idle stations by

Re: [PATCH 13/17] iwlwifi: mvm: Convert timers to use timer_setup()

On Mon, 2017-11-06 at 11:45 -0800, Kees Cook wrote: > On Sun, Oct 29, 2017 at 5:28 AM, Luca Coelho wrote: > > From: Kees Cook > > > > In preparation for unconditionally passing the struct timer_list > > pointer to > > all timer callbacks, switch to using

Re: [PATCH 13/17] iwlwifi: mvm: Convert timers to use timer_setup()

On Sun, Oct 29, 2017 at 5:28 AM, Luca Coelho wrote: > From: Kees Cook > > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer

Re: [PATCH] brcmfmac: add support for external 32khz clock

Hi Simon, > Simon Shields hat am 4. November 2017 um 14:24 > geschrieben: > > > Some boards use an external 32khz clock for low-power > mode timing. Make sure the clock is powered on while the chipset > is active. > > Signed-off-by: Simon Shields >

RE: [PATCH] mac80211: Update last_ack status for all except probing frames

> On Mon, 2017-10-30 at 17:29 -0700, Rajkumar Manoharan wrote: > > Update last_ack status for all except station probing frames (i.e null > > data). Otherwise the station inactivity duration is cleared whenever > > AP is checking presence of idle stations by sending null data frame > > for every

Soft lockup in rt2x00usb_work_rxdone()

Hi, I get a soft lock-up while unbinding the USB driver on a TP-Link TL-WN727Nv3 (chipset 5370): # echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:3:308] CPU: 0 PID: 308 Comm: kworker/u2:3 Not tainted 4.14.0-rc8 #11 Hardware name: Atmel

Re: [PATCH 1/3] rtlwifi: fix uninitialized rtlhal->last_suspend_sec time

On 11/06/2017 07:55 AM, Arnd Bergmann wrote: We set rtlhal->last_suspend_sec to an uninitialized stack variable, but unfortunately gcc never warned about this, I only found it while working on another patch. I opened a gcc bug for this. Presumably the value of rtlhal->last_suspend_sec is not

[PATCH] rt2x00: use monotonic timestamps for frame dump

rt2x00 uses the deprecated do_gettimeofday() function to get a timestamp for its debugfs "dump" file interface. The timestamp is using an unsigned 32-bit value, so we could make it work until 2106 by using ktime_get_real_ts64(), but it seems better to use monotonic times, as we normally want for

[PATCH 3/3] rtlwifi: drop unused ppsc->last_wakeup_time

The calculation of ppsc->last_wakeup_time is not y2038-safe, but the variable is not used at all, so we can simply drop it. Signed-off-by: Arnd Bergmann --- drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 - drivers/net/wireless/realtek/rtlwifi/wifi.h | 2 --

[PATCH 2/3] rtlwifi: use ktime_get_real_seconds() for suspend time

do_gettimeofday() is deprecated and slower than necessary for the purpose of reading the seconds. This changes rtl_op_suspend/resume to use ktime_get_real_seconds() instead, which is simpler and avoids confusion about whether it is y2038-safe or not. Signed-off-by: Arnd Bergmann

[PATCH 1/3] rtlwifi: fix uninitialized rtlhal->last_suspend_sec time

We set rtlhal->last_suspend_sec to an uninitialized stack variable, but unfortunately gcc never warned about this, I only found it while working on another patch. I opened a gcc bug for this. Presumably the value of rtlhal->last_suspend_sec is not all that important, but it does get used, so we

Re: rtl8821ae dbi read question

On 11/05/2017 10:09 PM, Nik Nyby wrote: On 11/05/2017 09:09 PM, Larry Finger wrote: Disabling all of _rtl8821ae_enable_aspm_back_door() may not be wise. We tried that patch as part of debugging. That routine consists of two mdio r/w sequences, and 3 dbi r/w sequences. The third one of the

Re: [PATCH] brcmfmac: add support for external 32khz clock

On Mon, Nov 06, 2017 at 11:59:37AM +0100, Arend van Spriel wrote: > On 11/4/2017 2:24 PM, Simon Shields wrote: > > Some boards use an external 32khz clock for low-power > > mode timing. Make sure the clock is powered on while the chipset > > is active. > > Do you have such a board? With the

Re: [PATCH] brcmfmac: add support for external 32khz clock

On 11/4/2017 2:24 PM, Simon Shields wrote: Some boards use an external 32khz clock for low-power mode timing. Make sure the clock is powered on while the chipset is active. Do you have such a board? With the little documentation I can get my hands on here I wonder whether the clock needs to

Re: [PATCH] brcmfmac: add support for external 32khz clock

Simon Shields writes: > Some boards use an external 32khz clock for low-power > mode timing. Make sure the clock is powered on while the chipset > is active. > > Signed-off-by: Simon Shields Then you submit a new version please always increase the

Re: pull-request: iwlwifi-next 2017-11-03

Luca Coelho writes: > Here's the final set of patches intended for v4.15. It's not too > important to get them into v4.15 if there is no time anymore. There > are a few new PCI IDs that can be added in the rc series or stable > (they need to go to other stable releases anyway).

Re: [PATCH] brcmfmac: add support for external 32khz clock

Some boards use an external 32khz clock for low-power mode timing. Make sure the clock is powered on while the chipset is active. Signed-off-by: Simon Shields --- .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 ++

Re: [PATCH] mac80211: Update last_ack status for all except probing frames

On Mon, 2017-10-30 at 17:29 -0700, Rajkumar Manoharan wrote: > Update last_ack status for all except station probing frames > (i.e null data). Otherwise the station inactivity duration is > cleared whenever AP is checking presence of idle stations by sending > null data frame for every inactive

Re: [PATCH] brcmfmac: add support for external 32khz clock

Simon Shields writes: > Some boards use an external 32khz clock for low-power > mode timing. Make sure the clock is powered on while the chipset > is active. > > Signed-off-by: Simon Shields > --- >

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

On Montag, 6. November 2017 09:28:42 CET Sebastian Gottschall wrote: > Am 06.11.2017 um 09:23 schrieb Sven Eckelmann: > > On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote: > >> the assumption made in this patch is obviously wrong (at least for more > >> recent firmwares and

Re: [PATCH v6] brcmfmac: add CLM download support

On 10/5/2017 9:31 AM, Wright Feng wrote: From: Chung-Hsien Hsu The firmware for brcmfmac devices includes information regarding regulatory constraints. For certain devices this information is kept separately in a binary form that needs to be downloaded to the device.

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

Am 06.11.2017 um 09:23 schrieb Sven Eckelmann: On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote: the assumption made in this patch is obviously wrong (at least for more recent firmwares and 9984) my log is flooded with messages like [208802.803537] ath10k_pci 0001:03:00.0:

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

On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote: > the assumption made in this patch is obviously wrong (at least for more > recent firmwares and 9984) > my log is flooded with messages like > [208802.803537] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats >

[PATCHv2 2/2] ath10k: handle tdls peer events

From: Manikanta Pubbisetty Handle tdls peer events from the target. TDLS events for the peer could be discover, teardown, etc. As of now, adding the logic to handle tdls teardown events alone. Teardown due to peer traffic indication(PTR) timeout is one such teardown

[PATCHv2 1/2] ath10k: update tdls teardown state to target

From: Manikanta Pubbisetty It is required to update the teardown state of the peer when a tdls link with that peer is terminated. This information is useful for the target to perform some cleanups wrt the tdls peer. Without proper cleanup, target assumes that the peer

[PATCHv2 0/2] ath10k: more on tdls support for 10.4 firmwares

From: Manikanta Pubbisetty This patchset includes a bug fix and an enhancement of tdls functionality for 10.4 firmwares. First patch in this series is a bug fix, second one is an enhancement. Manikanta Pubbisetty (2): ath10k: update tdls teardown state to target