[PATCH] ath9k: turn on btcoex_enable as default

Without btcoex_enable, WiFi activies make both WiFi and Bluetooth unstable if there's a bluetooth connection. Enable this option when bt_ant_diversity is disabled. BugLink: https://bugs.launchpad.net/bugs/1746164 Signed-off-by: Kai-Heng Feng ---

Re: [PATCH] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

On Wed, 2018-02-07 at 12:51 -0800, Matthias Kaehlcke wrote: > El Wed, Feb 07, 2018 at 02:35:59PM -0600 Larry Finger ha dit: > > > On 02/07/2018 02:26 PM, Matthias Kaehlcke wrote: > > > In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal > > > is assigned to itself in an if ...

Re: [PATCH] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

El Wed, Feb 07, 2018 at 02:35:59PM -0600 Larry Finger ha dit: > On 02/07/2018 02:26 PM, Matthias Kaehlcke wrote: > > In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal > > is assigned to itself in an if ... else statement, apparently only to > > document that the branch

Re: [PATCH] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

On 02/07/2018 02:26 PM, Matthias Kaehlcke wrote: In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal is assigned to itself in an if ... else statement, apparently only to document that the branch condition is handled and that a previously read value should be returned

[PATCH] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal is assigned to itself in an if ... else statement, apparently only to document that the branch condition is handled and that a previously read value should be returned unmodified. The self-assignment causes clang to raise the

Re: [PATCH v2] ieee80211: Increase the PMK maximum length to 64 bytes

On Wed, 2018-02-07 at 20:35 +0100, Arend van Spriel wrote: > On 2/7/2018 5:20 PM, Srinivas Dasari wrote: > > This is needed to cover the case of DPP with the NIST P-521 and > > brainpoolP512r1 curves which derive a PMK that is longer than the > > previously used limit. > > So how are driver

Re: [PATCH v2] ieee80211: Increase the PMK maximum length to 64 bytes

On 2/7/2018 5:20 PM, Srinivas Dasari wrote: This is needed to cover the case of DPP with the NIST P-521 and brainpoolP512r1 curves which derive a PMK that is longer than the previously used limit. So how are driver supposed to deal with this longer PMK. Maybe if you could elaborate on what

[PATCH v2] ieee80211: Increase the PMK maximum length to 64 bytes

This is needed to cover the case of DPP with the NIST P-521 and brainpoolP512r1 curves which derive a PMK that is longer than the previously used limit. Signed-off-by: Srinivas Dasari --- include/linux/ieee80211.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH] ath9k: break out of irq handler after 5 jiffies

On 02/07/2018 02:55 AM, Johannes Berg wrote: On Wed, 2018-02-07 at 10:16 +0100, Felix Fietkau wrote: On 2018-02-07 00:05, gree...@candelatech.com wrote: From: Ben Greear In case where the system is sluggish, we should probably break out early. Maybe this will fix

Re: [PATCH] Revert "ath10k: add sanity check to ie_len before parsing fw/board ie"

On 7 February 2018 at 13:51, Kalle Valo wrote: > From: Ryan Hsu > > This reverts commit 9ed4f91628737c820af6a1815b65bc06bd31518f. > > The commit introduced a regression that over read the ie with > the padding. > > - the expected IE information > >

Re: ath9k_htc: add Altai WA1011N-GU

Oleksij Rempel wrote: > as reported in: > https://github.com/qca/open-ath9k-htc-firmware/pull/71#issuecomment-361100070 > > Signed-off-by: Oleksij Rempel > Signed-off-by: Kalle Valo Patch applied to ath-current branch of

Re: ath10k: fix kernel panic issue during pci probe

Yu Wang wrote: > If device gone during chip reset, ar->normal_mode_fw.board is not > initialized, but ath10k_debug_print_hwfw_info() will try to access its > member, which will cause 'kernel NULL pointer' issue. This was found > using a faulty device (pci link went down

Re: ath9k: Fix get channel default noise floor

Wojciech Dubowik wrote: > Commit 8da58553cc63 ("ath9k: Use calibrated noise floor value > when available") introduced regression in ath9k_hw_getchan_noise > where per chain nominal noise floor has been taken instead default > for channel. > Revert to original

Re: [v3,1/2] pci: Add vendor id of Ubiquiti Networks

Tobias Schramm wrote: > Acked-by: Bjorn Helgaas > Signed-off-by: Tobias Schramm > Signed-off-by: Kalle Valo 2 patches applied to ath-current branch of ath.git, thanks. d5cc61119343 PCI: Add Ubiquiti

Re: ath10k: correct the length of DRAM dump for QCA6174 hw3.x/QCA9377 hw1.1

Yu Wang wrote: > The length of DRAM dump for QCA6174 hw3.0/hw3.2 and QCA9377 hw1.1 > are less than the actual value, some coredump contents are missed. > To fix it, change the length from 0x9 to 0xa8000. > > Fixes: 703f261dd77f ("ath10k: add memory dump support for

[PATCH] Revert "ath10k: add sanity check to ie_len before parsing fw/board ie"

From: Ryan Hsu This reverts commit 9ed4f91628737c820af6a1815b65bc06bd31518f. The commit introduced a regression that over read the ie with the padding. - the expected IE information ath10k_pci :03:00.0: found firmware features ie (1 B) ath10k_pci :03:00.0:

Re: rtlwifi: rtl8821ae: Fix connection lost problem correctly

Larry Finger wrote: > There has been a coding error in rtl8821ae since it was first introduced, > namely that an 8-bit register was read using a 16-bit read in > _rtl8821ae_dbi_read(). This error was fixed with commit 40b368af4b75 > ("rtlwifi: Fix alignment issues");

Re: [PATCH 5/6] qtnfmac: implement asynchronous firmware loading

Hi Arend, Qsr10g devices support loading firmware not only from the host over PCIe but also from on-board flash. Firmware start-up sequence and the following handshake are common for PCIe and flash boot modes. They take much more time (about 10 seconds) than the firmware upload process. To

Re: [PATCH] ath9k: break out of irq handler after 5 jiffies

On Wed, 2018-02-07 at 10:16 +0100, Felix Fietkau wrote: > On 2018-02-07 00:05, gree...@candelatech.com wrote: > > From: Ben Greear > > > > In case where the system is sluggish, we should probably break out > > early. Maybe this will fix issues where the OS thinks the

Re: [PATCH] ath9k: break out of irq handler after 5 jiffies

On 2018-02-07 00:05, gree...@candelatech.com wrote: > From: Ben Greear > > In case where the system is sluggish, we should probably break out > early. Maybe this will fix issues where the OS thinks the IRQ handler > is not responding and disables the IRQ because 'nobody