[PATCH] ath10k: Enable hw checksum for wcn3990

From: Rakesh Pillai By default ath10k driver enables the support for HW_CHECKSUM (NETIF_F_HW_CSUM). Since the TCP/UDP checksum calculation is not enabled in the wcn3990 firmware the checksum is incorrect in the TCP/UDP packets and all patckets are dropped. But due note

Re: [PATCH] wcn36xx: Add missing fall through comment in smd.c

On Thu 05 Apr 04:51 PDT 2018, Loic Poulain wrote: > This prevents GCC warning. > Acked-by: Bjorn Andersson Regards, Bjorn > Reported-by: Dan Carpenter > Signed-off-by: Loic Poulain > --- >

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

i have some comments about your check warnings. some of them are bogus. for instance they advise to use "unsigned int" instead of "unsigned". this might be better, but the original kernel header uses "unsigned" as api definition. so i decided to use the same declarations here. for the rest

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

On 4/5/2018 3:10 PM, Kalle Valo wrote: Ulf Hansson writes: On 20 March 2018 at 10:55, Kalle Valo wrote: Arend van Spriel writes: If I get it right, you mean something like this: mmc3: mmc@1c12000 { ...

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

On 5 April 2018 at 15:10, Kalle Valo wrote: > Ulf Hansson writes: > >> On 20 March 2018 at 10:55, Kalle Valo wrote: >>> Arend van Spriel writes: >>> >> If I get it right, you mean something

Re: [PATCH 07/12] brcmfmac: Convert ALLFFMAC to ether_broadcast_addr

On 3/31/2018 9:05 AM, Joe Perches wrote: Remove the local ALLFFMAC extern array and use the new global instead. I stumbled upon this one couple of weeks ago. I moved the definition to flowring.c although I considered for a moment to pick up the task you took here valiantly. Miscellanea:

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

Am 05.04.2018 um 16:44 schrieb Kalle Valo: s.gottsch...@dd-wrt.com writes: Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based chipsets with on chipset connected led's using WMI Firmware API. The LED device will get available named as "ath10k-phyX" at sysfs and can be

PATCH [1/1]: wireless: mac80211_hwsim: support/ignore power state changes

From: Bjoern Johansson Indicate support for power state changes and handle them by calling an empty function. The important part is "ieee80211_hw_set(hw, SUPPORTS_PS);" at the bottom of the diff. Without this upper layers in the kernel will return an error code when trying to

Re: [PATCH] qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler

Hi Sergey, On 04/05/2018 11:31 AM, Sergey Matyukevich wrote: Hello Gustavo, In case memory resources for fw were succesfully allocated, release them before jumping to fw_load_fail. Addresses-Coverity-ID: 1466092 ("Resource leak") Fixes: c3b2f7ca4186 ("qtnfmac: implement asynchronous firmware

Re: [PATCH] qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler

Hello Gustavo, > In case memory resources for fw were succesfully allocated, release > them before jumping to fw_load_fail. > > Addresses-Coverity-ID: 1466092 ("Resource leak") > Fixes: c3b2f7ca4186 ("qtnfmac: implement asynchronous firmware loading") > Signed-off-by: Gustavo A. R. Silva

[PATCH] qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler

In case memory resources for fw were succesfully allocated, release them before jumping to fw_load_fail. Addresses-Coverity-ID: 1466092 ("Resource leak") Fixes: c3b2f7ca4186 ("qtnfmac: implement asynchronous firmware loading") Signed-off-by: Gustavo A. R. Silva ---

Re: PATCH [1/1]: wireless: mac80211_hwsim: support/ignore power state changes

On Thu, Apr 5, 2018 at 1:35 AM Johannes Berg wrote: > > indicate power state support. This in turn causes VTS failures because > > the WiFi HAL can't enable power saving mode. The remaining code is > > just there to deal with the incoming state change request. >

iwlwifi: FW error in SYNC CMD TIME_QUOTA_CMD

Hey guys, after upgrading to 4608f064532c ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next") my kernel log gets constantly flooded with the below message and wireless stops working ... just in case you haven't had a report on this yet. Downgrading back to older v4.16-rcX

Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets

s.gottsch...@dd-wrt.com writes: > Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 > based chipsets with on chipset connected led's using WMI Firmware API. > The LED device will get available named as "ath10k-phyX" at sysfs and > can be controlled with various triggers. adds

Re: [PATCH 00/12] Ethernet: Add and use ether__addr globals

On 2018-04-05 15:51, Joe Perches wrote: >> You have to factor in >> not just the .text size, but the fact that referencing an exported >> symbol needs a .reloc entry as well, which also eats up some space (at >> least when the code is being built as module). > > Thanks, the modules I built got

Re: [PATCH 00/12] Ethernet: Add and use ether__addr globals

On Thu, 2018-04-05 at 15:27 +0200, Felix Fietkau wrote: > On 2018-03-31 09:05, Joe Perches wrote: > > There are many local static and non-static arrays that are used for > > Ethernet broadcast address output or comparison. > > > > Centralize the array into a single separate file and remove the

Re: [PATCH] iwlwifi: mvm: query regdb for wmm rule if needed

Luca Coelho writes: > From: Haim Dreyfuss > > Since our device is regulatory self managed it maintains its regulatory > rules by its own. However the wmm_rules values can't be set by the > device itself but only the indication about the need to set it. >

Re: [PATCH 00/12] Ethernet: Add and use ether__addr globals

On 2018-03-31 09:05, Joe Perches wrote: > There are many local static and non-static arrays that are used for > Ethernet broadcast address output or comparison. > > Centralize the array into a single separate file and remove the local > arrays. I suspect that for many targets and configurations,

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

Ulf Hansson writes: > On 20 March 2018 at 10:55, Kalle Valo wrote: >> Arend van Spriel writes: >> > If I get it right, you mean something like this: > > mmc3: mmc@1c12000 { > ... >

Re: [PATCH 06/12] wireless: Convert simple uses of a static const Ethernet broadcast address

Kalle Valo writes: > Joe Perches writes: > >> Use the new ether_broadcast_addr global instead to save some object code. >> >> Signed-off-by: Joe Perches >> --- >> drivers/net/wireless/admtek/adm8211.c | 3 +-- >>

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

On Thu, 2018-04-05 at 11:24 +, Jouni Malinen wrote: > > The "any" trigger sounds like a reasonable thing to use, It really depends what you're after. The "any" trigger means you want to wake up on all kinds of things, basically everything that would normally give you an interrupt in regular

Re: [PATCH 06/12] wireless: Convert simple uses of a static const Ethernet broadcast address

Joe Perches writes: > Use the new ether_broadcast_addr global instead to save some object code. > > Signed-off-by: Joe Perches > --- > drivers/net/wireless/admtek/adm8211.c | 3 +-- > drivers/net/wireless/ath/carl9170/mac.c | 4 +--- >

Re: [PATCH] wireless: rt2x00: rt2800: add antenna diversity for RT5370G

On Thu, Apr 05, 2018 at 02:22:32PM +0200, Xose Vazquez Perez wrote: > RT5370G has hardware RX antenna diversity like RT5390R. > Based on DPO_RT5572_LinuxSTA_2.6.1.3_20121022.tar.bz2 manufacturer driver: >

Re: [PATCH] rsi: Free the unaligned pointer

Johannes Berg writes: > On Thu, 2018-04-05 at 14:41 +0300, Dan Carpenter wrote: >> On Thu, Apr 05, 2018 at 02:39:31PM +0300, Dan Carpenter wrote: >> > On Thu, Apr 05, 2018 at 01:30:35PM +0200, Johannes Berg wrote: >> > > On Thu, 2018-04-05 at 14:23 +0300, Dan Carpenter

[PATCH] wireless: rt2x00: rt2800: add antenna diversity for RT5370G

RT5370G has hardware RX antenna diversity like RT5390R. Based on DPO_RT5572_LinuxSTA_2.6.1.3_20121022.tar.bz2 manufacturer driver: https://d86o2zu8ugzlg.cloudfront.net/mediatek-craft/drivers/DPO_RT5572_LinuxSTA_2.6.1.3_20121022.tar.bz2 Cc: Stanislaw Gruszka Cc: Helmut Schaa

[PATCH] wcn36xx: Add missing fall through comment in smd.c

This prevents GCC warning. Reported-by: Dan Carpenter Signed-off-by: Loic Poulain --- drivers/net/wireless/ath/wcn36xx/smd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c

Re: [PATCH] rsi: Free the unaligned pointer

On Thu, 2018-04-05 at 14:41 +0300, Dan Carpenter wrote: > On Thu, Apr 05, 2018 at 02:39:31PM +0300, Dan Carpenter wrote: > > On Thu, Apr 05, 2018 at 01:30:35PM +0200, Johannes Berg wrote: > > > On Thu, 2018-04-05 at 14:23 +0300, Dan Carpenter wrote: > > > > The problem here is that we allocate

Re: [PATCH] rsi: Free the unaligned pointer

On Thu, Apr 05, 2018 at 02:39:31PM +0300, Dan Carpenter wrote: > On Thu, Apr 05, 2018 at 01:30:35PM +0200, Johannes Berg wrote: > > On Thu, 2018-04-05 at 14:23 +0300, Dan Carpenter wrote: > > > The problem here is that we allocate "data". Then we do > > > "data = PTR_ALIGN(data, 8);" and then we

Re: [PATCH] rsi: Free the unaligned pointer

On Thu, Apr 05, 2018 at 01:30:35PM +0200, Johannes Berg wrote: > On Thu, 2018-04-05 at 14:23 +0300, Dan Carpenter wrote: > > The problem here is that we allocate "data". Then we do > > "data = PTR_ALIGN(data, 8);" and then we free the aligned pointer and > > not the one we allocated. > > That

Re: [PATCH] rsi: Free the unaligned pointer

On Thu, 2018-04-05 at 14:23 +0300, Dan Carpenter wrote: > The problem here is that we allocate "data". Then we do > "data = PTR_ALIGN(data, 8);" and then we free the aligned pointer and > not the one we allocated. That seems pretty pointless, since kmalloc guarantees such alignment for sure.

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

On Thu, Apr 05, 2018 at 10:07:04AM +0200, Arend van Spriel wrote: > On 4/5/2018 9:59 AM, Johannes Berg wrote: > >There's the "any" trigger that might be appropriate for that, or a > >"disconnect" trigger. > > > >But I'm basically thinking the same as Steve - if you're never going to > >wake up the

[PATCH] rsi: Free the unaligned pointer

The problem here is that we allocate "data". Then we do "data = PTR_ALIGN(data, 8);" and then we free the aligned pointer and not the one we allocated. I don't know if it causes an issue in real life, but it seems like a reasonable thing to free the same pointer that we allocated.

[PATCH] mwifiex: pcie: tighten a check in mwifiex_pcie_process_event_ready()

If "evt_len" is 1 then we try to memcpy() negative 3 bytes and it would cause memory corruption. Fixes: d930faee141b ("mwifiex: add support for Marvell pcie8766 chipset") Signed-off-by: Dan Carpenter diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c

Re: PATCH [1/1]: wireless: mac80211_hwsim: support/ignore power state changes

> indicate power state support. This in turn causes VTS failures because > the WiFi HAL can't enable power saving mode. The remaining code is > just there to deal with the incoming state change request. What's VTS? johannes

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

On 4/5/2018 9:59 AM, Johannes Berg wrote: On Thu, 2018-04-05 at 09:41 +0200, Arend van Spriel wrote: So for a full-mac device or a mac80211 device with certain offloads (that we may already have, eg. 4way-hs offloads) you could keep up the connection for a while, but if it is receiving data it

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

On Thu, 2018-04-05 at 09:41 +0200, Arend van Spriel wrote: > > So for a full-mac device or a mac80211 device with certain offloads > (that we may already have, eg. 4way-hs offloads) you could keep up the > connection for a while, but if it is receiving data it probably wants to > wake-up the

Re: Wi-Fi Disconnection on Suspend for no wowlan triggers

On 4/3/2018 6:55 PM, Steve deRosier wrote: Hi Sunil, On Tue, Apr 3, 2018 at 5:39 AM, Sunil Dutt Undekari wrote: Hi All , I would like to discuss on the commit 8125696991194aacb1173b6e8196d19098b44e17 (cfg80211/mac80211: disconnect on suspend) which triggers the STA