Re: [PATCH] mac80211: Fix possible sband related NULL pointer de-reference (fwd)

ARNING on v4.11-rc8 next-20170427] [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/Mohammed-Shafi-Shajakhan/mac80211-Fix-possible-sband-related-NULL-pointer-de-reference/20170428-120425 base: ht

Re: [PATCH] mac80211: Fix possible sband related NULL pointer de-reference

On Thu, 2017-04-27 at 12:45 +0530, Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band > even > if the channel context configuration is NULL. This crashes for >

[PATCH] mac80211: Fix possible sband related NULL pointer de-reference

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even if the channel context configuration is NULL. This crashes for chipsets which support 5 Ghz alone when it tries to access members of 'sband'. Channel c

[PATCH] ath: Fix updating radar flags for coutry code India

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> As per latest regulatory update for India, channel 52, 56, 60, 64 is no longer restricted to DFS. Enabling DFS/no infra flags in driver results in applying all DFS related restrictions (like doing CAC etc before this channel

Re: [PATCH] ath10k: Fix spectral scan for QCA99X0 family of chipsets

/ regards, shafi On 10 April 2017 at 07:26, Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> wrote: > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > spectral_bin length (number of bins per fft sample) is usually > a value where (2^n = value), n is an inte

[PATCH] ath10k: Fix spectral scan for QCA99X0 family of chipsets

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> spectral_bin length (number of bins per fft sample) is usually a value where (2^n = value), n is an integer. All of the QCA99X0 family of chipsets seems to report a spectral_bin length of 2^n + 'm' bytes, where m = 4, 12

[PATCH] ath10k: Fix compile time sanity check for CE4 buffer size

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> In 'ath10k_ce_alloc_pipe' the compile time sanity check to ensure that there is sufficient buffers in CE4 for HTT Tx MSDU descriptors, but this did not take into account of the case with 'peer flow control' enabled, fix this. Cc:

[PATCH] ath10k: Remove obselete Copy Engine comments

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Remove obselete Copy Engine comments referring to the function ath10k_ce_sendlist_send as this function was removed long time back by the commit 2e761b5a5222 ("ath10k: remove ce_sendlist_send"). Signed-off-by: Mohammed

[PATCH] ath10k: Enable a HTC debug message during insufficient tx credits

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Add an ath10k HTC debug message when insufficient tx credits are available to send the WMI commands. This is very useful in debugging issues like 'tx credit starvation' that could possibly happen with multiclient setup with co

[PATCH] ath10k: cancel coverage class work during stop and restart

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> It seems set_coverage_class_work is not cancelled anywhere, though I could not find a crash/warning with this existing design, its safer to cancel it during stop() and also before restarting the hardware. Signed-off-by: Mohammed

[PATCH] ath10k: Fix NAPI enable/disable symmetry for AHB interface

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Move NAPI enable to 'ath10k_ahb_hif_start' from 'ath10k_ahb_hif_power_up'. This is to maintain the symmetry of calling napi_enable() from ath10k_ahb_hif_start() so that it matches with napi_disable() being called from ath10k_pci_hi

[PATCH] ath10k: Fix typo in wmi header file

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Fix typo(spelling mistake) in wmi.h Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> --- drivers/net/wireless/ath/ath10k/wmi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/

[PATCH] ath10k: Fix fetching channel during potential radar detection

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Fetch target operating channel during potential radar detection when the interface is just brought up, but no channel is assigned from userspace. In this scenario rx_channel may not be having a valid pointer hence fetch the

[PATCH] ath10k: Disallow DFS simulation if DFS channel is not enabled

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> If DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall not be available for use even though the hardware may have the capability to support DFS. With this configuration (DFS disabled in hostapd) trying to bring up

[PATCH v2] ath10k: Fix a warning during channel switch with multiple vaps

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Doing a channel switch via hostapd_cli seems to update the new channel context for each VAP's appropriately as below in 'ath10k_mac_update_vif_chan', hence we can safely suppress the warning that shows up during this operation an

[PATCH] ath10k: Fix a warning during channel switch with multiple vaps

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Doing a channel switch via hostapd_cli seems to update the new channel context for each VAP's appropriately as below in 'ath10k_mac_update_vif_chan', hence we can safely suppress the warning that shows up during this operation an

Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

mm.com> writes: > > > Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> writes: > > > >> From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > >> > >> This fixes the below crash when ath10k probe firmware fails, > >> NAPI pollin

Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

Hi Kalle, sorry for the delay On Wed, Jan 25, 2017 at 01:46:28PM +, Valo, Kalle wrote: > Kalle Valo <kv...@qca.qualcomm.com> writes: > > > Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> writes: > > > >> From: Mohammed Shafi Shajakhan <moham

[PATCH] ath10k: Fix per station tx bit rate reporting

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Not clearing the previous tx bit rate status results in a ambigous tx bit rate reporting to mac80211/cfg80211, for example the previous bit rate status would have been marked as legacy rate , while the current rate would have been

Re: [PATCH] mac80211: prevent skb/txq mismatch

On Thu, Jan 12, 2017 at 03:51:20PM +0100, Johannes Berg wrote: > On Thu, 2017-01-12 at 20:15 +0530, Mohammed Shafi Shajakhan wrote: > > > > > Reported-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > Signed-off-by: Michal Kazior <michal.k

Re: [PATCH] mac80211: prevent skb/txq mismatch

_tx_dequeue [mac80211]) from > [] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core]) > [] (ath10k_mac_tx_push_txq [ath10k_core]) from > [] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core]) > [] (ath10k_htt_txrx_compl_task [ath10k_core]) > [] (ath10k_pci_napi_poll+0x54/0xe8 [

[PATCH] ath10k: Fix Tx legacy rate reporting

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Tx legacy rate is reported 10 fold, as below iw dev wlan#N station dump | grep "tx bitrate" tx bitrate: 240.0 MBit/s This is because by mistake we muliply by the hardware reported rate twice by 10,

[PATCH] ath10k: Fix wifi connectivity and warning in Rx with channel 169

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> In countries where basic operation of channel 169 is allowed, this fixes the below WARN_ON_ONCE in Rx and fixes the station connectivity failure in channel 169 as the packet is dropped in the driver as the current check limits to c

Re: [1/2] ath10k: add accounting for the extended peer statistics

Hi Christian / Kalle, On Fri, Dec 30, 2016 at 03:35:10PM +0100, Christian Lamparter wrote: > On Thu, Dec 29, 2016 at 3:11 PM, Kalle Valo wrote: > > Christian Lamparter wrote: > >> The 10.4 firmware adds extended peer information to the > >>

Re: [PATCH] ath10k: merge extended peer info data with existing peers info

Hi Christian, On Thu, Dec 22, 2016 at 06:58:41PM +0100, Christian Lamparter wrote: > Hello Shafi, > > On Thursday, December 22, 2016 9:18:01 PM CET Mohammed Shafi Shajakhan wrote: > > > On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan > > > wr

[PATCH] ath10k: Enable advertising support for channel 169, 5Ghz

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Enable advertising support for channel 169, 5Ghz so that based on the regulatory domain(country code) this channel shall be active for use. For example in countries like India this channel shall be available for use with latest regu

[PATCH] ath10k: Remove passing unused argument for ath10k_mac_tx

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> 'ath10k_mac_tx' does not seems to use the per station table entry pointer 'sta' (struct ieee80211_sta), hence remove passing this unused argument Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> ---

Re: [PATCH] ath10k: merge extended peer info data with existing peers info

Hi Christian, once again sorry for the delay > > On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote: > > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote: > > > The 10.4 firmware adds extended peer information to the > &

[PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> This fixes the below crash when ath10k probe firmware fails, NAPI polling tries to access a rx ring resource which was never allocated, fix this by disabling NAPI right away once the probe firmware fails by calling 'ath10k_hif_stop

[PATCH v2] ath10k: Fix crash during rmmod when probe firmware fails

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> This fixes the below crash when ath10k probe firmware fails, NAPI polling tries to access a rx ring resource which was never allocated, fix this by disabling NAPI right away once the probe firmware fails by calling 'ath10k_hif_stop

Re: [PATCH] ath10k: merge extended peer info data with existing peers info

On Mon, Dec 19, 2016 at 10:19:57PM +0530, Mohammed Shafi Shajakhan wrote: > Hi Christian, > > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote: > > The 10.4 firmware adds extended peer information to the > > firmware's statistics payload. This addition

Re: [PATCH] ath10k: merge extended peer info data with existing peers info

the extended peer statistics" [0] > > Mohammed Shafi Shajakhan commented that the extended peer statistics > lists are of little use:"... there is not much use in appending > the extended peer stats (which gets periodically updated) to the > linked list '>debug.

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

Hi Christian, > On Thursday, December 15, 2016 10:13:39 PM CET Mohammed Shafi Shajakhan wrote: > > I am also thinking, as of now there is not much use in appending > > the extended peer stats (which gets periodically ) to the linked list > > '>debug.fw_stats.peers_extd)

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

xtd, >debug.fw_stats.peers_extd); since rx_duration is getting updated periodically to the per sta information. Kindly let me know your thoughts about this. regards, shafi On Thu, Dec 15, 2016 at 09:56:59PM +0530, Mohammed Shafi Shajakhan wrote: > Hello Christian, > > On Wed, Dec 14

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

Hello Christian, On Wed, Dec 14, 2016 at 05:38:02PM +0100, Christian Lamparter wrote: > On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan wrote: > > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan > > > wrote: > > > &

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

On Tue, Dec 13, 2016 at 01:41:33PM +0100, Christian Lamparter wrote: > Hello, > > It looks like google put your mail into the spam-can. > I'm sorry for not answering sooner. [shafi] np, thanks for your reply ! > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Sha

Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

Hi Christian, On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote: > The 10.4 firmware adds extended peer information to the > firmware's statistics payload. This additional info is > stored as a separate data field and the elements are > stored in their own "peers_extd" list. >

[PATCH] ath10k: Avoid potential page alloc BUG_ON in tx free path

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> 'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc' have NULL pointer checks to avoid crash if they are called twice but this is as of now not sufficient as these pointers are not assigned to NULL once the cont

Re: ath10k firmware crashes in mesh mode on QCA9880

https://patchwork.kernel.org/patch/9437519/ (sorry missed this in the previous thread) On Sat, Dec 03, 2016 at 06:13:58PM +0530, Mohammed Shafi Shajakhan wrote: > Hi Benjamin, > > On Fri, Dec 02, 2016 at 05:28:02PM -0800, Benjamin Morgan wrote: > > Just tried 10.2.4.70.58 fi

Re: ath10k firmware crashes in mesh mode on QCA9880

and ath.git Also worth trying this fix in ath10k (once the next firmware version) is available. I will keep you posted. thank you ! > > ~Benjamin > > On 11/30/2016 11:09 PM, Mohammed Shafi Shajakhan wrote: > >Hi, > > > >On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjami

Re: [PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart

On Thu, Dec 01, 2016 at 10:35:38AM +, Valo, Kalle wrote: > Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> writes: > > > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > > During firmware crash (or) user requested manual restart >

Re: ath10k firmware crashes in mesh mode on QCA9880

Hi, On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote: > When we try to transmit traffic (ping) between two meshed ath10k > devices running latest lede we keep experiencing ath10k firmware > crashes. This seems to only happen when running in 802.11n/ac mode > but not in 802.11a/g

Re: [PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

egards, shafi > > > > On 30 November 2016 at 01:50, Mohammed Shafi Shajakhan > <moham...@qti.qualcomm.com> wrote: > > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > > With maximum number of vap's configured in a two radio supporte

Re: ath10k: Fix soft lockup during firmware crash/hw-restart

thanks a lot Ben. > > On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote: > >From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > >During firmware crash (or) user requested manual restart > >the system gets into a soft lock up state becaus

[PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> With maximum number of vap's configured in a two radio supported systems of ~256 Mb RAM, doing a continuous wifi down/up and intermittent traffic streaming from the connected stations results in failure to allocate contiguous

Re: ath10k: Fix soft lockup during firmware crash/hw-restart

AM, Mohammed Shafi Shajakhan wrote: > >From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > >During firmware crash (or) user requested manual restart > >the system gets into a soft lock up state because of the > >below root cause. > > >

[PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> During firmware crash (or) user requested manual restart the system gets into a soft lock up state because of the below root cause. During user requested hardware restart / firmware crash the system goes into a soft lockup

Re: Deadlock in hacked 4.9.0-rc6+ kernel.

Hi Ben, On Tue, Nov 29, 2016 at 06:50:33AM -0800, Ben Greear wrote: > > > On 11/28/2016 11:34 PM, Mohammed Shafi Shajakhan wrote: > >Hi Ben, > > > >On Mon, Nov 28, 2016 at 10:52:44AM -0800, Ben Greear wrote: > >>I ported forward my patch set to the

ath10k: Fix soft lockup during firmware crash/hw-restart

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> During firmware crash (or) user requested manual restart the system gets into a soft lock up state because of the below root cause. During user requested hardware restart / firmware crash the system goes into a soft lockup

Re: Deadlock in hacked 4.9.0-rc6+ kernel.

Hi Ben, On Mon, Nov 28, 2016 at 10:52:44AM -0800, Ben Greear wrote: > I ported forward my patch set to the 4.9 kernel, and I am seeing lockups > fairly > often. As always, could be something I added locally, but in case someone > sees > similar, then maybe I can reproduce it quicker and help

Re: Break-it testing for wifi

Hi Ben, just googled out 'wifi fuzzy testing' and found something relevant as below https://www.blackhat.com/presentations/bh-europe-07/Butti/Presentation/bh-eu-07-Butti.pdf regards, shafi On Mon, Nov 21, 2016 at 08:10:37AM -0800, Ben Greear wrote: > Hello! > > I am thinking about adding some

[PATCH] ath10k: Fix crash during rmmod when probe firmware fails

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> This fixes the below crash when ath10k probe firmware fails, NAPI polling tries to access a rx ring resource which was never allocated, fix this by disabling NAPI right away once the probe firmware fails BUG: unable to handle kerne

[PATCH v3 1/2] ath10k: clean up HTT tx buffer allocation and free

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> cleanup 'ath10k_htt_tx_alloc' by introducing the API's 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and re-use them whereever needed Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> --- drivers/net/

[PATCH v3 2/2] ath10k: Remove extraneous error message in tx alloc

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Remove extraneous error message in 'ath10k_htt_tx_alloc_cont_frag_desc' as the caller 'ath10k_htt_tx_alloc' already dumps a proper error message Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> ---

[PATCH] ath10k: Fix failure to send NULL func frame for 10.4

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> This partially reverts 'commit 2cdce425aa33 ("ath10k: Fix broken NULL func data frame status for 10.4")' Unfortunately this breaks sending NULL func and the existing issue of obtaining proper tx status for NULL functi

Re: [v2,1/2] ath10k: clean up HTT tx buffer allocation and free

Hi Kalle, On Tue, Oct 11, 2016 at 01:36:22PM +0200, Kalle Valo wrote: > Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> wrote: > > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > > cleanup 'ath10k_htt_tx_alloc' by introducing the API

[PATCH v2 1/2] ath10k: clean up HTT tx buffer allocation and free

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> cleanup 'ath10k_htt_tx_alloc' by introducing the API's 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and re-use them whereever needed Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> --- [v2 reba

[PATCH v2 2/2] ath10k: Remove extraneous error message in tx alloc

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Remove extraneous error message in 'ath10k_htt_tx_alloc_cont_frag_desc' as the caller 'ath10k_htt_tx_alloc' already dumps a proper error message Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> --- [v2 reba

Re: [1/2] ath10k: clean up HTT tx buffer allocation and free

On Thu, Oct 06, 2016 at 09:31:41AM +0200, Kalle Valo wrote: > Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> wrote: > > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > > cleanup 'ath10k_htt_tx_alloc' by introducing the API's > >

[PATCH v2] ath10k: Cleanup calling ath10k_htt_rx_h_unchain

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> 'ath10k_htt_rx_h_unchain' needs to be called only if the return value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this change makes it more explicit and avoids doing a skb_peek, fetching rx descriptor pointer, checking r

Re: ath10k: Cleanup calling ath10k_htt_rx_h_unchain

On Tue, Oct 04, 2016 at 05:30:17PM +0200, Kalle Valo wrote: > Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> wrote: > > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > > 'ath10k_htt_rx_h_unchain' is need to be called

[PATCH 2/2] ath10k: Remove extraneous error message in tx alloc

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Remove extraneous error message in 'ath10k_htt_tx_alloc_cont_frag_desc' as the caller 'ath10k_htt_tx_alloc' already dumps a proper error message Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> ---

[PATCH 0/2] ath10k: Trivial cleanup in HTT tx buffer allocation

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Pre-requisite cleanup changes for one time tx buffer allocation to avoid contigous DMA tx buffer allocation failure for tx (thanks Vasanth) for long hour stress testing with continuous wifi down/up with multiple vaps in low memory s

[PATCH 1/2] ath10k: clean up HTT tx buffer allocation and free

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> cleanup 'ath10k_htt_tx_alloc' by introducing the API's 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and re-use them whereever needed Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> --- drivers/net/

[PATCH] ath10k: Cleanup calling ath10k_htt_rx_h_unchain

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> 'ath10k_htt_rx_h_unchain' is need to be called only if the return value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this change makes it more explicit and avoids doing a skb_peek, fetching rx descriptor pointer, check

[PATCH v4] ath10k: Cleanup calling ath10k_htt_rx_h_unchain

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> 'ath10k_htt_rx_h_unchain' is need to be called only if the return value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this change makes it more explicit and avoids doing a skb_peek, fetching rx descriptor pointer, check

[PATCH] ath10k: Ignore SWBA event for a vif if its marked for no beacon

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Ignore processing further in SWBA event scheduled for a vif, if mac80211 has marked the particular vif for stop beaconing and brought the vdev down in 'ath10k_control_beaconing'. This should potentially avoid ath10k warning/error me

[PATCH] ath10k: Remove unnecessary error code assignment

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> The error assigned does not seems to be used anywhere, fixes nothing just a small cleanup Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> --- drivers/net/wireless/ath/ath10k/wmi.c | 1 - 1 file changed

[PATCH v5] ath10k: Fix broken NULL func data frame status for 10.4

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Older firmware with HTT delivers incorrect tx status for null func frames to driver, but this fixed in 10.2 and 10.4 firmware versions. Also this workaround results in reporting of incorrect null func status for 10.

Re: [PATCH 3/3] ath10k: Improve logging message.

Hi Ben, On Thu, Aug 18, 2016 at 06:26:35PM -0700, gree...@candelatech.com wrote: > From: Ben Greear > > Helps to know the sta pointer. > > Signed-off-by: Ben Greear > --- > drivers/net/wireless/ath/ath10k/mac.c | 4 ++-- > 1 file changed, 2

[PATCH] ath10k: suppress warnings when getting wmi WDS peer event id

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> 'WMI_10_4_WDS_PEER_EVENTID' is not yet handled/implemented for WDS mode, as of nowsuppress the warning message "Unknown eventid: 36903" Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> ---

[PATCH] ath10k: Remove driver log suggesting QCA9887 support is experimental

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Support for QCA9887 is no longer experimental and if there are any issues we need to address them Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> --- drivers/net/wireless/ath/ath10k/pci.c | 1 - 1 fil

[RESEND PATCH v4] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> For chipsets like QCA99X0, IPQ4019 and later we are not getting proper NULL func status (always acked/successs !!) when hostapd does a PROBE_CLIENT via nullfunc frames when the station is powered off abruptly (inactive timer probes

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

Hi Michal / Kalle / Ben, is this patch is good to go (or) should i re-work ? I had replied to Michal's comment of introducing a new firmware feature flag will not address the issue in older firmware / code. Let me know if i had missed something very obvious. On Tue, Jul 05, 2016 at 08:21:01AM

Re: [PATCH v3] ath10k: Fix 10.4 extended peer stats update

On Thu, Jun 30, 2016 at 11:09:31AM +, Valo, Kalle wrote: > Mohammed Shafi Shajakhan <moham...@codeaurora.org> writes: > > > Hi Kalle, > > > > On Thu, Jun 30, 2016 at 10:49:02AM +, Valo, Kalle wrote: > >> Kalle Valo <kv...@qca.qualcomm.com> wri

Re: [PATCH v3] ath10k: Fix 10.4 extended peer stats update

Hi Kalle, On Thu, Jun 30, 2016 at 10:49:02AM +, Valo, Kalle wrote: > Kalle Valo writes: > > >> @@ -261,6 +263,7 @@ static const struct ath10k_hw_params > >> ath10k_hw_params_list[] = { > >>.board = QCA4019_HW_1_0_BOARD_DATA_FILE, > >>

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

Hello Michal/ Kalle, On Tue, Jun 28, 2016 at 08:48:38AM +0200, Michal Kazior wrote: > On 27 June 2016 at 16:36, Mohammed Shafi Shajakhan > <moham...@codeaurora.org> wrote: > > Hi Michal, > > > > thanks for the review .. > > > > On Mon, Jun 27, 201

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

Hi Michal, thanks for the review .. On Mon, Jun 27, 2016 at 11:27:27AM +0200, Michal Kazior wrote: > On 23 June 2016 at 18:40, Mohammed Shafi Shajakhan > <moham...@qti.qualcomm.com> wrote: > > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > >

Re: [PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

Hello Ben, On Thu, Jun 23, 2016 at 10:12:01AM -0700, Ben Greear wrote: > On 06/23/2016 09:40 AM, Mohammed Shafi Shajakhan wrote: > >From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > >For chipsets like QCA99X0, IPQ4019 and later we are not getting proper

[PATCH 1/2] ath10k: Replace warning with an error message if HTT op version is unset

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Print an ath10k error message rather a call trace when HTT op version is not found from firmware META data (IE). This should be sufficient to figure out what went wrong. Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qua

[PATCH 2/2] ath10k: Fix sending NULL/ Qos NULL data frames for QCA99X0 and later

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> For chipsets like QCA99X0, IPQ4019 and later we are not getting proper NULL func status (always acked/successs !!) when hostapd does a PROBE_CLIENT via nullfunc frames when the station is powered off abruptly (inactive timer probes

Re: Bug with: ath10k: enable parsing per station rx duration for 10.4?

On Tue, Jun 21, 2016 at 07:10:28AM -0700, Ben Greear wrote: > > > On 06/20/2016 10:18 PM, Mohammed Shafi Shajakhan wrote: > >Hi Ben, > > > >thanks for reporting ... > > > >On Mon, Jun 20, 2016 at 04:06:52PM -0700, Ben Greear wrote: > >>I'm wo

Re: Bug with: ath10k: enable parsing per station rx duration for 10.4?

I somehow screwed up when rebasing [shafi] i will check this and get back to you by end of day. regards, shafi > > > Author: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> 2016-03-16 > 05:43:34 > Committer: Kalle Valo <kv...@qca.qualcomm.com> 2016-04-04

[PATCH v2] ath10k: Fix some typo in spectral code commments

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Found this obvious typo while going through the spectral code design in ath10k Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> --- drivers/net/wireless/ath/ath10k/spectral.c | 4 ++-- 1 file changed,

Re: [PATCH] ath10k: Fix a typo in spectral code commments

On Thu, Jun 16, 2016 at 11:59:59AM -0400, Bob Copeland wrote: > On Tue, Jun 14, 2016 at 11:03:54AM +0530, Mohammed Shafi Shajakhan wrote: > > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > > Found this obvious typo while going through the spectra

[PATCH] ath10k: Disable TX_STBC for tx chainmask of 1

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Disable TX_STBC for both HT and VHT if the devices tx chainmask is '1' TX_STBC is required only for devices with tx_chainmask > 1. This fixes a ping failure for QCA9887 (1x1) in HT/VHT mode Signed-off-by: Mohammed Shafi Shajakh

[PATCH] ath10k: Enable beacon loss detection support for 10.4

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Enable beacon loss detection support for 10.4 by handling roam event. With this change QCA99X0 station is able to detect beacon loss when the AP is powered off Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qua

Re: [PATCH v4 1/2] ath10k: Add support for ath10k_sta_statistics support

Hi Kalle, On Tue, Jun 14, 2016 at 01:58:25PM +, Valo, Kalle wrote: > Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> writes: > > > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > > Enable support for 'drv_sta_statistics' call

[PATCH v4 1/2] ath10k: Add support for ath10k_sta_statistics support

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Enable support for 'drv_sta_statistics' callback. Export rx_duration support if available to cfg80211/nl80211 This can also act as a placeholder for any new per STA stats support Signed-off-by: Mohammed Shafi Shajakhan

[PATCH v4 2/2] ath10k: Remove debugfs support for Per STA total rx duration

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> cfg80211/nl80211 interface changes for per STA total rx-duration and very basic 'ath10k_sta_statistics' mac80211 callback is implemented to extend support for per station statistics from the driver. Also provision in 'iw dev

[PATCH] ath10k: Fix a typo in spectral code commments

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Found this obvious typo while going through the spectral code design in ath10k Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> --- drivers/net/wireless/ath/ath10k/spectral.c |2 +- 1 file changed,

[PATCH] ath10k: Remove unneccessary WARN_ON_ONCE in rx during ACS

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> The below warning message seems to hit occasionally with the following combination (IPQ4019 + ACS scan) where we receive packets as a self peer when hostapd does ACS when we bring up AP mode . ath10k has the below fall back mec

[PATCH v2] ath10k: Fix crash during card removal

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> Usually when the firmware crashes we check for the value 'FW_IND_EVENT_PENDING' in 'FW_INDICATOR_ADDRESS' and proceed with disabling the irq and dumping firmware 'crash dump'. Now when the PCI card is unplugged from the device t

Re: [PATCH 0/2] ath10k: Add support for QCA9887

STBC && (ar->cfg_tx_chainmask > 1)) ht_cap.cap |= IEEE80211_HT_CAP_TX_STBC; if (ar->ht_cap_info & WMI_HT_CAP_RX_STBC) { -- regards, shafi On Wed, Jun 08, 2016 at 06:13:08PM +0530, Mohammed Shafi Shajakhan wrote: > On Tue, Jun 07, 2016 at 10:41:48PM +0530, Moh

Re: [PATCH 0/2] ath10k: Add support for QCA9887

On Tue, Jun 07, 2016 at 10:41:48PM +0530, Mohammed Shafi Shajakhan wrote: > Hi Sven, > > On Tue, Jun 07, 2016 at 06:54:54PM +0200, Sven Eckelmann wrote: > > On Tuesday 07 June 2016 20:20:02 Mohammed Shafi Shajakhan wrote: > > [...] > > > [shafi] it would be helpf

Re: [PATCH 0/2] ath10k: Add support for QCA9887

Hi Sven, On Tue, Jun 07, 2016 at 06:54:54PM +0200, Sven Eckelmann wrote: > On Tuesday 07 June 2016 20:20:02 Mohammed Shafi Shajakhan wrote: > [...] > > [shafi] it would be helpful if you can share your basic test results (if its > > possible to share). Have you tried to bring u

Re: [PATCH 0/2] ath10k: Add support for QCA9887

Hi Sven, On Mon, May 30, 2016 at 01:12:27PM +0200, Sven Eckelmann wrote: > On Friday 27 May 2016 12:44:52 Valo, Kalle wrote: > [...] > > > But maybe I should add that the results with the original AP147 firmware > > > also > > > wasn't better. > > > > That doesn't sound good. Maybe a

Re: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system

On Thu, Jun 02, 2016 at 08:21:41AM -0700, Ben Greear wrote: > On 06/02/2016 07:24 AM, Valo, Kalle wrote: > >Kalle Valo writes: > > > >>there's a regression in ath10k: > >> > >>https://bugzilla.kernel.org/show_bug.cgi?id=119151 > >> > >>Reporter bisected it to this: > >> >

Re: [PATCH v2 1/2] ath10k: remove duplicate and unused rx rate flags

On Thu, Jun 02, 2016 at 01:45:15PM +, Valo, Kalle wrote: > Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> writes: > > > From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> > > > > All these flags are not used and their use is completely

[PATCH v3 1/2] ath10k: remove duplicate and unused rx rate flags

From: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> All these flags are not used and their use is completely covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck', and RX_PPDU_START_RATE_FLAG Signed-off-by: Mohammed Shafi Shajakhan <moham...@qti.qualcomm.com> --- drivers/

  1   2   >