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
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
>
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
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
/
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
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
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:
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
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
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
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
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/
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
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
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
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
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
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
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
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
_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 [
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,
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
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
> >>
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
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
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>
---
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
> &
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
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
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
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.
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)
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
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:
> > > &
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
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.
>
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
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
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
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
>
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
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
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
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
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.
> >
>
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
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
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
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
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
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
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/
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>
---
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
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
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
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
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
> >
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
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
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>
---
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
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/
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
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
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
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
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.
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
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>
---
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
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
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
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
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,
> >>
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
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>
> >
> >
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
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
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
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
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
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,
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
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
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
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
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
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
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,
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
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
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
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
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
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
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:
> >>
>
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
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 - 100 of 191 matches
Mail list logo