* Re: [1/1] rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting
From: Kalle Valo @ 2016-12-01 12:24 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless, briselec
In-Reply-To: <20161129235902.11882-2-Jes.Sorensen@redhat.com>
Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and
> 8723bu devices not being able to reconnect.
>
> Reported-by: Barry Day <briselec@gmail.com>
> Cc: <stable@vger.kernel.org> #4.8+
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
c59f13bbead4 rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting
--
https://patchwork.kernel.org/patch/9453251/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mac80211: fix Tx BA session stuck issue during sw scanning
From: Chris Chiu @ 2016-12-01 11:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux
In-Reply-To: <1480424369.10012.6.camel@sipsolutions.net>
On Tue, Nov 29, 2016 at 8:59 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2016-11-23 at 15:59 +0800, Chris Chiu wrote:
>> ieee80211_iface_work() will check if sw scanning is in progress
>> before handling block ack session. In our case, the RTL8821AE
>> operate in station mode, when tx session expired, DELBA packet
>> stuck during sw scanning and so do other data packets.
>>
>> ieee80211_scan_state_decision() will take lots of time in
>> SCAN_SUSPEND/SCAN_RESUME state due to !tx_empty or bad_latency.
>> Then the sw scanning mostly take > 20 seconds to finish or even
>> worse in our case RTL8821AE have 37 channels for 2G+5G to scan
>> and tx stalls ~300 seconds. AP side still thinks the connection
>> is alive because it still receives the QoS NULL packet from STA.
>> So the link state will never change but actually no data tx/rx
>> during this long time.
>>
>> This commit tries to send out packet in SCAN_SUSPEND state so the
>> sw scanning can complete more efficiently and less affect on Block
>> Ack session handling. Verified on RTL8821AE for > 30000 pings and
>> no Tx BA session stuck observed.
>
> The premise seems fairly reasonable, although I'm a little worried that
> if so much new traffic is coming in we never finish the scan suspend?
> Actually, the queues are still stopped, so it's only management frames
> that can come in, so that should be ok?
>
Actually it will finish scan eventually and back to SCAN_DECISION
state but almost 20~30 seconds elapsed. The local->scanning should be
cleared after all channels been scanned. However, from the debug
messages I added in ieee80211_iface_work(), it still returns when
check local->scanning and the DELBA still has no chance to be
transferred then stuck again at the next scan state machine. Supposed
to be another scan request issued but I don't know who's the killer.
Except to find who issue the next scan request, BA session have no
chance to reset in this long scan period (>20s) still need to be taken
care.
>> + test_and_clear_bit(SCAN_SUSPEND_SCANNING, &local->scanning);
>>
>
> That makes no sense, you're not checking the return value, just clear
> the bit without test.
>
>> @@ -844,6 +846,8 @@ static void ieee80211_scan_state_suspend(struct
>> ieee80211_local *local,
>> /* disable PS */
>> ieee80211_offchannel_return(local);
>>
>> + __set_bit(SCAN_SUSPEND_SCANNING, &local->scanning);
>
> Why are you using the non-atomic version here, vs. the atomic one
> above?
>
You're right. I just want to clear_bit and set_bit in this case, sorry
for that confusing. Or any better suggestion?
> johannes
^ permalink raw reply
* Re: ath5k: drop duplicate header vmalloc.h
From: Kalle Valo @ 2016-12-01 11:23 UTC (permalink / raw)
To: Geliang Tang
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Kalle Valo,
Geliang Tang, linux-wireless, netdev, linux-kernel
In-Reply-To: <15299de49216a2360976ca37ff774cae9d27d88b.1479991297.git.geliangtang@gmail.com>
Geliang Tang <geliangtang@gmail.com> wrote:
> Drop duplicate header vmalloc.h from ath5k/debug.c.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Patch applied to ath-next branch of ath.git, thanks.
384abd33d5d5 ath5k: drop duplicate header vmalloc.h
--
https://patchwork.kernel.org/patch/9445537/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/4] wil6210: delay remain on channel when scan is active
From: Kalle Valo @ 2016-12-01 11:21 UTC (permalink / raw)
To: Maya Erez; +Cc: Kalle Valo, Lior David, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1480333743-7306-2-git-send-email-qca_merez@qca.qualcomm.com>
Maya Erez <qca_merez@qca.qualcomm.com> wrote:
> From: Lior David <qca_liord@qca.qualcomm.com>
>
> Currently it was possible to call remain_on_channel(ROC)
> while scan was active and this caused a crash in the FW.
> In order to fix this problem and make the behavior
> consistent with other drivers, queue the ROC in case
> a scan is active and try it again when scan is done.
> As part of the fix, clean up some locking issues and
> return error if scan is called while ROC is active.
>
> Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
4 patches applied to ath-next branch of ath.git, thanks.
bb6743f7c2ff wil6210: delay remain on channel when scan is active
1db226ffe1c2 wil6210: validate wil_pmc_alloc parameters
615788200557 wil6210: add debugfs blobs for UCODE code and data
8ae5d62c7eba wil6210: align to latest auto generated wmi.h
--
https://patchwork.kernel.org/patch/9449393/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k_htc: don't use HZ for usb msg timeouts
From: Kalle Valo @ 2016-12-01 11:20 UTC (permalink / raw)
To: Anthony Romano; +Cc: linux-wireless, ath9k-devel, ath9k-devel
In-Reply-To: <20161128042757.8609-1-anthony.romano@coreos.com>
Anthony Romano <anthony.romano@coreos.com> wrote:
> The usb_*_msg() functions expect a timeout in msecs but are given HZ,
> which is ticks per second. If HZ=100, firmware download often times out
> when there is modest USB utilization and the device fails to initialize.
>
> Replaces HZ in usb_*_msg timeouts with 1000 msec since HZ is one second
> for timeouts in jiffies.
>
> Signed-off-by: Anthony Romano <anthony.romano@coreos.com>
> Acked-by: Oleksij Rempel <linux@rempel-privat.de>
Patch applied to ath-next branch of ath.git, thanks.
982a6151f6f1 ath9k_htc: don't use HZ for usb msg timeouts
--
https://patchwork.kernel.org/patch/9449097/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wireless: ath: ath9k: constify ath_bus_ops structure
From: Kalle Valo @ 2016-12-01 11:18 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, ath9k-devel, kvalo, linux-wireless, ath9k-devel,
netdev, linux-kernel, Bhumika Goyal
In-Reply-To: <1480266206-26732-1-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> wrote:
> Declare the structure ath_bus_ops as const as it is only passed as an
> argument to the function ath9k_init_device. This argument is of type
> const struct ath_bus_ops *, so ath_bus_ops structures with this property
> can be declared as const.
> Done using Coccinelle:
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct ath_bus_ops i@p = {...};
>
> @ok1@
> identifier r1.i;
> position p;
> expression e1,e2;
> @@
> ath9k_init_device(e1,e2,&i@p)
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> static
> +const
> struct ath_bus_ops i={...};
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct ath_bus_ops i;
>
> File size before:
> text data bss dec hex filename
> 1295 232 0 1527 5f7 ath/ath9k/ahb.o
>
> File size after:
> text data bss dec hex filename
> 1359 176 0 1535 5ff ath/ath9k/ahb.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Patch applied to ath-next branch of ath.git, thanks.
8ca5a6078d6d ath9k: constify ath_bus_ops structure
--
https://patchwork.kernel.org/patch/9448851/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL.
From: Kalle Valo @ 2016-12-01 11:16 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k, Ben Greear, linux-wireless
In-Reply-To: <1480456828-13735-1-git-send-email-greearb@candelatech.com>
Ben Greear <greearb@candelatech.com> wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> These memory chunks are often used as 'swap' by the NIC,
> so it will be both reading and writing to these areas.
>
> This seems to fix errors like this on my x86-64 machine:
>
> kernel: DMAR: DMAR:[DMA Write] Request device [05:00.0] fault addr ff5de000
> DMAR:[fault reason 05] PTE Write access is not set
>
> Tested-by: Marek Behun <kabel@blackhole.sk>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index 9fcb249..c68278a 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -4558,7 +4558,7 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 req_id,
> if (!num_units)
> return -ENOMEM;
>
> - paddr = dma_map_single(ar->dev, vaddr, pool_size, DMA_TO_DEVICE);
> + paddr = dma_map_single(ar->dev, vaddr, pool_size, DMA_BIDIRECTIONAL);
> if (dma_mapping_error(ar->dev, paddr)) {
> kfree(vaddr);
> return -ENOMEM;
Patch applied to ath-next branch of ath.git, thanks.
43ca92d380a8 ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL
--
https://patchwork.kernel.org/patch/9453173/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Fix Tx DMA alloc failure during continuous wifi down/up
From: Kalle Valo @ 2016-12-01 11:14 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1480499414-19543-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@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 memory for tx buffers. This results
> in the disappearance of all VAP's and a manual reboot is needed as
> this is not a crash (or) OOM(for OOM killer to be invoked). To address
> this allocate contiguous memory for tx buffers one time and re-use them
> until the modules are unloaded but this results in a slight increase in
> memory footprint of ath10k when the wifi is down, but the modules are
> still loaded. Also as of now we use a separate bool 'tx_mem_allocated'
> to keep track of the one time memory allocation, as we cannot come up
> with something like 'ath10k_tx_{register,unregister}' before
> 'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc'
> memory allocation is dependent on the hw_param 'continuous_frag_desc'
>
> a) memory footprint of ath10k without the change
>
> lsmod | grep ath10k
> ath10k_core 414498 1 ath10k_pci
> ath10k_pci 38236 0
>
> b) memory footprint of ath10k with the change
>
> ath10k_core 414980 1 ath10k_pci
> ath10k_pci 38236 0
>
> Memory Failure Call trace:
>
> hostapd: page allocation failure: order:6, mode:0xd0
> [<c021f150>] (__dma_alloc_buffer.isra.23) from
> [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8)
> [<c021f23c>] (__alloc_remap_buffer.isra.26) from
> [<c021f664>] (__dma_alloc+0x224/0x2b8)
> [<c021f664>] (__dma_alloc) from [<c021f810>]
> (arm_dma_alloc+0x84/0x90)
> [<c021f810>] (arm_dma_alloc) from [<bf954764>]
> (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
> [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from
> [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
> [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from
> [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core])
> [<bf947eec>] (ath10k_start [ath10k_core]) from
> [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211])
> [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>]
> (ieee80211_do_open+0x170/0x82c [mac80211])
> [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from
> [<c056afc8>] (__dev_open+0xa0/0xf4)
> [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR)
> 126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB
> 0*1024kB 0*2048kB 0*4096kB = 95276kB
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
9ec34a86195a ath10k: fix Tx DMA alloc failure during continuous wifi down/up
--
https://patchwork.kernel.org/patch/9453947/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] ath10k: Fix soft lockup during firmware crash/hw-restart
From: Kalle Valo @ 2016-12-01 11:13 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1480483769-17693-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@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 state as 'napi_synchronize'
> is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> bit) and it sleeps into infinite loop as it waits for
> 'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> 'ath10k_hif_stop' is called twice as below (resulting in calling
> 'napi_synchronize' after 'napi_disable')
>
> 'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> -> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> 'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
>
> Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> as it makes more sense before informing mac80211 to restart h/w
> Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
>
> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
c2cac2f74ab4 ath10k: fix soft lockup during firmware crash/hw-restart
--
https://patchwork.kernel.org/patch/9453609/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart
From: Mohammed Shafi Shajakhan @ 2016-12-01 11:12 UTC (permalink / raw)
To: Valo, Kalle
Cc: Shajakhan, Mohammed Shafi (Mohammed Shafi),
ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <87inr4rl6t.fsf@kamboji.qca.qualcomm.com>
On Thu, Dec 01, 2016 at 10:35:38AM +0000, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
>
> > From: Mohammed Shafi Shajakhan <mohammed@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 state as 'napi_synchronize'
> > is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> > bit) and it sleeps into infinite loop as it waits for
> > 'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> > 'ath10k_hif_stop' is called twice as below (resulting in calling
> > 'napi_synchronize' after 'napi_disable')
> >
> > 'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> > -> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> > 'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
> >
> > Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> > as it makes more sense before informing mac80211 to restart h/w
> > Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
> >
> > Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> > ---
> > [v2 Added Fixes ]
>
> I'll also add:
>
> Cc: <stable@vger.kernel.org> # v4.9
>
thank you Kalle.
regards,
shafi
^ permalink raw reply
* Re: ath10k: fix TLV set regdomain command
From: Kalle Valo @ 2016-12-01 11:09 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: linux-wireless, ath10k, Erik Stromdahl
In-Reply-To: <1480275440-9919-1-git-send-email-erik.stromdahl@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
> There is a typo bug in the current implementation of
> ath10k_wmi_tlv_op_gen_pdev_set_rd.
> The conformance test limits are not set up properly.
>
> The two arguments ctl2g and ctl5g were not used at all.
> Instead, the regdomain arguments rd2g and rd5g were used
> for the ctl settings as well.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Patch applied to ath-next branch of ath.git, thanks.
4e322f7db51a ath10k: fix TLV set regdomain command
--
https://patchwork.kernel.org/patch/9448885/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart
From: Valo, Kalle @ 2016-12-01 10:35 UTC (permalink / raw)
To: Shajakhan, Mohammed Shafi (Mohammed Shafi)
Cc: ath10k@lists.infradead.org, mohammed@codeaurora.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1480483769-17693-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
> From: Mohammed Shafi Shajakhan <mohammed@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 state as 'napi_synchronize'
> is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> bit) and it sleeps into infinite loop as it waits for
> 'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> 'ath10k_hif_stop' is called twice as below (resulting in calling
> 'napi_synchronize' after 'napi_disable')
>
> 'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> -> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> 'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
>
> Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> as it makes more sense before informing mac80211 to restart h/w
> Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
>
> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> ---
> [v2 Added Fixes ]
I'll also add:
Cc: <stable@vger.kernel.org> # v4.9
--=20
Kalle Valo=
^ permalink raw reply
* Re: ath10k: Fix soft lockup during firmware crash/hw-restart
From: Valo, Kalle @ 2016-12-01 10:34 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: Ben Greear, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org,
Shajakhan, Mohammed Shafi (Mohammed Shafi)
In-Reply-To: <20161201060612.GA8611@atheros-ThinkPad-T61>
Mohammed Shafi Shajakhan <mohammed@codeaurora.org> writes:
> On Tue, Nov 29, 2016 at 10:16:50AM -0800, Ben Greear wrote:
>> Is this something for stable? And if so, how far back should it be appl=
ied?
>
> @Kalle,
>
> [shafi] kindly suggest. If i am not wrong this is only needed for 4.9
Correct, commit 3c97f5de1f28 went to 4.9-rc1, it was not in 4.8. I'll
add CC stable to the commit log.
--=20
Kalle Valo=
^ permalink raw reply
* Re: ath9k: feed only active spectral / dfs-detector
From: Kalle Valo @ 2016-12-01 10:29 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, michal.kazior, benjamin
In-Reply-To: <1479812709-18875-1-git-send-email-zefir.kurtisi@neratec.com>
Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> Radar pulse and spectral scan reports are provided by the HW
> with the ATH9K_RXERR_PHY flag set. Those are forwarded to
> the dfs-detector and spectral module for further processing.
>
> For some older chips, the pre-conditions checked in those
> modules are ambiguous, since ATH9K_PHYERR_RADAR is used to
> tag both types. As a result, spectral frames are fed into
> the dfs-detector and vice versa.
>
> This could lead to a false radar detection on a non-DFS
> channel (which is uncritical), but more relevant it causes
> useless CPU load for processing invalid frames.
>
> This commit ensures that the dfs-detector and spectral
> collector are only fed when they are active.
>
> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Patch applied to ath-next branch of ath.git, thanks.
87fedb974e0c ath9k: feed only active spectral / dfs-detector
--
https://patchwork.kernel.org/patch/9440817/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/1] rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting
From: Kalle Valo @ 2016-12-01 10:20 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless, briselec
In-Reply-To: <20161129235902.11882-2-Jes.Sorensen@redhat.com>
Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and
> 8723bu devices not being able to reconnect.
>
> Reported-by: Barry Day <briselec@gmail.com>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Like discussed I'll add:
Cc: <stable@vger.kernel.org> #4.8+
--
https://patchwork.kernel.org/patch/9453251/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
From: Valo, Kalle @ 2016-12-01 10:17 UTC (permalink / raw)
To: Bjorn Andersson
Cc: k.eugene.e@gmail.com, Andy Gross, wcn36xx@lists.infradead.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
In-Reply-To: <874m2otenv.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>
>> "Valo, Kalle" <kvalo@qca.qualcomm.com> writes:
>>
>>> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>>>
>>>> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
>>>>
>>>>> Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
>>>>> > The correct include file for getting errno constants and ERR_PTR() =
is
>>>>> > linux/err.h, rather than linux/errno.h, so fix the include.
>>>>> >=20
>>>>> > Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled=
smem_state")
>>>>> > Acked-by: Andy Gross <andy.gross@linaro.org>
>>>>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>>>=20
>>>>> For some reason this fails to compile now. Can you take a look, pleas=
e?
>>>>>=20
>>>>> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wc=
n36xx.ko] undefined!
>>>>> make[1]: *** [__modpost] Error 1
>>>>> make: *** [modules] Error 2
>>>>>=20
>>>>> 5 patches set to Changes Requested.
>>>>>=20
>>>>> 9429045 [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
>>>>> 9429047 [v5,2/5] wcn36xx: Transition driver to SMD client
>>>>
>>>> This patch was updated with the necessary depends in Kconfig to catch
>>>> this exact issue and when I pull in your .config (which has QCOM_SMD=
=3Dn,
>>>> QCOM_WCNSS_CTRL=3Dn and WCN36XX=3Dy) I can build this just fine.
>>>>
>>>> I've tested the various combinations and it seems to work fine. Do you
>>>> have any other patches in your tree?
>>>
>>> This was with the pending branch of my ath.git tree. There are other
>>> wireless patches (ath10k etc) but I would guess they don't affect here.
>>>
>>>> Any stale objects?
>>>
>>> Not sure what you mean with this question, but I didn't run 'make clean=
'
>>> if that's what you are asking.
>>>
>>>> Would you mind retesting this, before I invest more time in trying to
>>>> reproduce the issue you're seeing?
>>>
>>> Sure, I'll take a look but that might take few days.
>>
>> I didn't find enough time to look at this in detail. I applied this to
>> my ath.git pending branch, let's see what the kbuild bot finds.
>
> It found the same problem. Interestingly I'm also building x86 with 32
> bit, maybe it's related?
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pen=
ding
> head: 1ea16a1c457939b4564643f7637d5cc639a8d3b7
> commit: 5eb09c672b01460804fd49b1c9cc7d1072a102f0 [96/99] wcn36xx: Transit=
ion driver to SMD client
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> git checkout 5eb09c672b01460804fd49b1c9cc7d1072a102f0
> # save the attached .config to linux build tree
> make ARCH=3Di386=20
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn3=
6xx.ko] undefined!
Bjorn mentioned me on IRC that this is because of a missing commit in my
tree:
daa6e41ce2b5 soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API
When I pull the tag below (which contains the above commit) wcn36xx
builds fine for me:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-dr=
ivers-for-4.10
Andy, is it ok if I pull your tag also to my ath.git tree to solve the
wcn36xx build problem? My trees go to Linus via net-next and I don't
know when exactly Dave would send a pull request to Linus, before or
after the arm trees, but as the tag seems to contain only few patches I
hope it doesn't matter.
--=20
Kalle Valo=
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Mohammed Shafi Shajakhan @ 2016-12-01 7:09 UTC (permalink / raw)
To: Benjamin Morgan; +Cc: linux-wireless, ath10k, lede-dev, agreen
In-Reply-To: <583DD564.8040704@cococorp.com>
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 mode. Also, from the station dumps it appears
> that management traffic is flowing between the devices, however when
> we try to send unicast data traffic the firmware crashes
> immediately.
[shafi] Did you get a chance to try with the below firmware as well
https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58
>
> Platform: Archer C7 AC1750 v2
> Software Image: LEDE (HEAD, r2299) Commit: https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
>
> Crypto: wpa_supplicant
> wpa_supplicant-wlan0.conf
> network={
> ssid="bmorgan_lede_mesh"
> key_mgmt=SAE
> mode=5
> frequency=5180
> psk="meshpassword"
> }
>
> Backports Verstion:
> [ 9.818007] Loading modules backported from Linux version
> wt-2016-10-03-1-g6fcb1a6
> [ 9.825736] Backport generated by backports.git
> backports-20160324-9-g0e38f5c
>
> Ath10k Initialization on Station A (dmesg)
> [ 9.896715] PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
> [ 9.902622] ath10k_pci 0000:01:00.0: pci irq legacy oper_irq_mode
> 1 irq_mode 0 reset_mode 0
> [ 10.123734] ath10k_pci 0000:01:00.0: Direct firmware load for
> ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
> [ 10.134620] ath10k_pci 0000:01:00.0: Falling back to user helper
> [ 10.287680] firmware ath10k!pre-cal-pci-0000:01:00.0.bin:
> firmware_loading_store: map pages failed
> [ 10.622789] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 10.632184] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [ 10.645231] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
> api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [ 10.655660] ath10k_pci 0000:01:00.0: Direct firmware load for
> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> [ 10.666264] ath10k_pci 0000:01:00.0: Falling back to user helper
> [ 10.747925] firmware ath10k!QCA988X!hw2.0!board-2.bin:
> firmware_loading_store: map pages failed
> [ 11.011123] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 12.155224] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> 2 cal file max-sta 128 raw 0 hwcrypto 1
>
> Station A (wlan0):
> 18:A6:F7:23:6E:66
> 10.230.5.41
>
> Station B (wlan0):
> 18:a6:f7:26:0f:21
> 10.230.5.42
>
> Station Dump on Station A before ping:
> Station 18:a6:f7:26:0f:21 (on wlan0)
> inactive time:340 ms
> rx bytes:2472
> rx packets:28
> tx bytes:1204
> tx packets:9
> tx retries:0
> tx failed:0
> rx drop misc:1
> signal: -14 dBm
> signal avg:-14 dBm
> Toffset:18142530 us
> tx bitrate:6.0 MBit/s
> rx bitrate:6.0 MBit/s
> rx duration:1524 us
> mesh llid:0
> mesh plid:0
> mesh plink:ESTAB
> mesh local PS mode:ACTIVE
> mesh peer PS mode:UNKNOWN
> mesh non-peer PS mode:ACTIVE
> authorized:yes
> authenticated:yes
> associated:yes
> preamble:long
> WMM/WME:yes
> MFP:yes
> TDLS peer:no
> DTIM period:2
> beacon interval:1000
> connected time:10 seconds
>
> Crash Log on Station B (10.230.5.42)
> [245.483888] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> 2bab5ee9-08ff-4a17-95b1-636d212acebc)
> [245.493020] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [245.502384] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [245.515436] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api
> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [245.525812] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [245.533232] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
> cal file max-sta 128 raw 0 hwcrypto 1
> [245.544876] ath10k_pci 0000:01:00.0: firmware register dump:
> [245.550633] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009A4577 0x00955B31
> [245.558676] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
> 0x00000002 0x00439E98
> [245.566715] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [245.574749] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x009A3518 0x009A3526
> [245.582793] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [245.590836] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [245.598882] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
> 0x00400000 0xC09A4577
> [245.606923] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
> 0x0044110C 0x00442074
> [245.614955] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> 0x0044110C 0x00407120
> [245.623000] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> 0x0040AC14 0x00001580
> [245.631043] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
> 0x009C643C 0x004436CC
> [245.639086] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
> 0x004208FC 0x00439E4C
> [245.647129] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
> 0x004208FC 0x00425404
> [245.655170] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
> 0x00424FE8 0x00000002
> [245.663198] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x00000004 0x004039D0
> [245.767023] ieee80211 phy0: Hardware restart was requested
> [245.772655] ath10k_pci 0000:01:00.0: failed to synchronize monitor
> vdev 1 stop: -143
> [245.780542] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
>
> With wpa_supplicant turned off:
>
> Station Dump on Station A before ping:
> Station 18:a6:f7:26:0f:21 (on wlan0)
> inactive time:60 ms
> rx bytes:3874
> rx packets:67
> tx bytes:707
> tx packets:7
> tx retries:0
> tx failed:1
> rx drop misc:3
> signal: -14 dBm
> signal avg:-14 dBm
> Toffset:18446744073684250999 us
> tx bitrate:6.0 MBit/s
> rx bitrate:6.0 MBit/s
> rx duration:1312 us
> mesh llid:24953
> mesh plid:59412
> mesh plink:ESTAB
> mesh local PS mode:ACTIVE
> mesh peer PS mode:UNKNOWN
> mesh non-peer PS mode:ACTIVE
> authorized:yes
> authenticated:yes
> associated:yes
> preamble:long
> WMM/WME:yes
> MFP:no
> TDLS peer:no
> DTIM period:2
> beacon interval:1000
> short slot time:yes
> connected time:33 seconds
>
> Firmware crash on Station A (10.230.5.41)
> [ 1040.984599] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> 42d4f6dc-0e89-4505-aefb-58cbb70d0dce)
> [ 1040.993732] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 1041.003100] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [ 1041.016144] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
> api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [ 1041.026523] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 1041.033940] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> 2 cal file max-sta 128 raw 0 hwcrypto 1
> [ 1041.045593] ath10k_pci 0000:01:00.0: firmware register dump:
> [ 1041.051336] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009A4577 0x00955B31
> [ 1041.059383] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
> 0x00000001 0x00435354
> [ 1041.067424] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [ 1041.075463] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x009A43A0 0x009A43DE
> [ 1041.083490] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [ 1041.091535] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [ 1041.099579] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
> 0x00955A00 0xC09A4577
> [ 1041.107622] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
> 0x0044110C 0x00442074
> [ 1041.115661] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> 0x0044110C 0x00407120
> [ 1041.123689] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> 0x0040AC10 0x00001580
> [ 1041.131733] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
> 0x009C643C 0x004436CC
> [ 1041.139777] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
> 0x004208FC 0x00439E4C
> [ 1041.147820] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
> 0x004208FC 0x00425758
> [ 1041.155860] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
> 0x00424FE8 0x00000002
> [ 1041.163888] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x00000004 0x004039D0
> [ 1041.267025] ieee80211 phy0: Hardware restart was requested
> [ 1041.272656] ath10k_pci 0000:01:00.0: failed to synchronize
> monitor vdev 1 stop: -143
> [ 1041.280545] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
>
>
> Thanks in advance for your time and help,
>
> ~Benjamin
>
^ permalink raw reply
* Re: [PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up
From: Mohammed Shafi Shajakhan @ 2016-12-01 6:50 UTC (permalink / raw)
To: Adrian Chadd
Cc: Mohammed Shafi Shajakhan, ath10k@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <CAJ-VmokhmPy7Bb++wRb2h5H-_g3Vu2jqLqeoh9kiP0tGdC1_vA@mail.gmail.com>
Hi Adrian,
On Wed, Nov 30, 2016 at 10:27:25AM -0800, Adrian Chadd wrote:
> Heh, I had to do something like this for freebsd too for my ath10k
> port. So thanks. :)
[shafi] thanks :):)
>
> Suggestion - take a look at where tasklets, completions, locks, etc
> are all re-allocated multiple times, once upon initial VAP bringup. I
> had to also undo this in FreeBSD, as we don't allow re-init of tasks,
> completions, callouts and locks without first freeing/zero'ing them
> appropriately. :)
>
>
[shafi] sure, I just added some basic debug prints
In ath10k_htt_tx_start and init tx_lock and pending_tx
In ath10k_htt_tx_start and tx mem allocated set to true
In ath10k_htt_tx_start and init tx_lock and pending_tx (initialized second time)
In ath10k_htt_tx_start and tx mem is already allocated
In ath10k_htt_tx_destroy and tx mem allocated set to false
But I see 'ath10k_htt_tx_stop' is called when the interface is brought down
and in that scenario we need to do 'idr_init(&htt->pending_tx) ' ?
while doing a tx_lock might be a duplicate. Also if i understand correctly
the existing ath10k already calls tx buffer allocation twice via
4 2145 core.c <<ath10k_core_probe_fw>>
ret = ath10k_core_start(ar, ATH10K_FIRMWARE_MODE_NORMAL,
5 4471 mac.c <<ath10k_start>>
ret = ath10k_core_start(ar,
ATH10K_FIRMWARE_MODE_NORMAL,
Also there is a suggestion to enhance this patch using DMA API's
(thanks Michal) and we will work on this once this goes fine
without any issues
regards,
shafi
>
>
>
> On 30 November 2016 at 01:50, Mohammed Shafi Shajakhan
> <mohammed@qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <mohammed@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 memory for tx buffers. This results
> > in the disappearance of all VAP's and a manual reboot is needed as
> > this is not a crash (or) OOM(for OOM killer to be invoked). To address
> > this allocate contiguous memory for tx buffers one time and re-use them
> > until the modules are unloaded but this results in a slight increase in
> > memory footprint of ath10k when the wifi is down, but the modules are
> > still loaded. Also as of now we use a separate bool 'tx_mem_allocated'
> > to keep track of the one time memory allocation, as we cannot come up
> > with something like 'ath10k_tx_{register,unregister}' before
> > 'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc'
> > memory allocation is dependent on the hw_param 'continuous_frag_desc'
> >
> > a) memory footprint of ath10k without the change
> >
> > lsmod | grep ath10k
> > ath10k_core 414498 1 ath10k_pci
> > ath10k_pci 38236 0
> >
> > b) memory footprint of ath10k with the change
> >
> > ath10k_core 414980 1 ath10k_pci
> > ath10k_pci 38236 0
> >
> > Memory Failure Call trace:
> >
> > hostapd: page allocation failure: order:6, mode:0xd0
> > [<c021f150>] (__dma_alloc_buffer.isra.23) from
> > [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8)
> > [<c021f23c>] (__alloc_remap_buffer.isra.26) from
> > [<c021f664>] (__dma_alloc+0x224/0x2b8)
> > [<c021f664>] (__dma_alloc) from [<c021f810>]
> > (arm_dma_alloc+0x84/0x90)
> > [<c021f810>] (arm_dma_alloc) from [<bf954764>]
> > (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
> > [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from
> > [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
> > [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from
> > [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core])
> > [<bf947eec>] (ath10k_start [ath10k_core]) from
> > [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211])
> > [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>]
> > (ieee80211_do_open+0x170/0x82c [mac80211])
> > [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from
> > [<c056afc8>] (__dev_open+0xa0/0xf4)
> > [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR)
> > 126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB
> > 0*1024kB 0*2048kB 0*4096kB = 95276kB
> >
> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> > ---
> > drivers/net/wireless/ath/ath10k/core.c | 5 +--
> > drivers/net/wireless/ath/ath10k/htt.h | 6 +++-
> > drivers/net/wireless/ath/ath10k/htt_tx.c | 54 +++++++++++++++++++++++++-------
> > 3 files changed, 51 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> > index 5bc6847..f7ea4de 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -1857,7 +1857,7 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
> > goto err_wmi_detach;
> > }
> >
> > - status = ath10k_htt_tx_alloc(&ar->htt);
> > + status = ath10k_htt_tx_start(&ar->htt);
> > if (status) {
> > ath10k_err(ar, "failed to alloc htt tx: %d\n", status);
> > goto err_wmi_detach;
> > @@ -2052,7 +2052,7 @@ void ath10k_core_stop(struct ath10k *ar)
> > ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND_AND_DISABLE_INTR);
> >
> > ath10k_hif_stop(ar);
> > - ath10k_htt_tx_free(&ar->htt);
> > + ath10k_htt_tx_stop(&ar->htt);
> > ath10k_htt_rx_free(&ar->htt);
> > ath10k_wmi_detach(ar);
> > }
> > @@ -2385,6 +2385,7 @@ void ath10k_core_destroy(struct ath10k *ar)
> > destroy_workqueue(ar->workqueue_aux);
> >
> > ath10k_debug_destroy(ar);
> > + ath10k_htt_tx_destroy(&ar->htt);
> > ath10k_wmi_free_host_mem(ar);
> > ath10k_mac_destroy(ar);
> > }
> > diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
> > index 0d2ed09..96bf7bf 100644
> > --- a/drivers/net/wireless/ath/ath10k/htt.h
> > +++ b/drivers/net/wireless/ath/ath10k/htt.h
> > @@ -1692,6 +1692,8 @@ struct ath10k_htt {
> > enum htt_tx_mode_switch_mode mode;
> > enum htt_q_depth_type type;
> > } tx_q_state;
> > +
> > + bool tx_mem_allocated;
> > };
> >
> > #define RX_HTT_HDR_STATUS_LEN 64
> > @@ -1754,7 +1756,9 @@ struct htt_rx_desc {
> > int ath10k_htt_init(struct ath10k *ar);
> > int ath10k_htt_setup(struct ath10k_htt *htt);
> >
> > -int ath10k_htt_tx_alloc(struct ath10k_htt *htt);
> > +int ath10k_htt_tx_start(struct ath10k_htt *htt);
> > +void ath10k_htt_tx_stop(struct ath10k_htt *htt);
> > +void ath10k_htt_tx_destroy(struct ath10k_htt *htt);
> > void ath10k_htt_tx_free(struct ath10k_htt *htt);
> >
> > int ath10k_htt_rx_alloc(struct ath10k_htt *htt);
> > diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
> > index ccbc8c03..27e49db 100644
> > --- a/drivers/net/wireless/ath/ath10k/htt_tx.c
> > +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
> > @@ -350,21 +350,15 @@ static int ath10k_htt_tx_alloc_txdone_fifo(struct ath10k_htt *htt)
> > return ret;
> > }
> >
> > -int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
> > +static int ath10k_htt_tx_alloc_buf(struct ath10k_htt *htt)
> > {
> > struct ath10k *ar = htt->ar;
> > int ret;
> >
> > - ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt tx max num pending tx %d\n",
> > - htt->max_num_pending_tx);
> > -
> > - spin_lock_init(&htt->tx_lock);
> > - idr_init(&htt->pending_tx);
> > -
> > ret = ath10k_htt_tx_alloc_cont_txbuf(htt);
> > if (ret) {
> > ath10k_err(ar, "failed to alloc cont tx buffer: %d\n", ret);
> > - goto free_idr_pending_tx;
> > + return ret;
> > }
> >
> > ret = ath10k_htt_tx_alloc_cont_frag_desc(htt);
> > @@ -396,6 +390,31 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
> > free_txbuf:
> > ath10k_htt_tx_free_cont_txbuf(htt);
> >
> > + return ret;
> > +}
> > +
> > +int ath10k_htt_tx_start(struct ath10k_htt *htt)
> > +{
> > + struct ath10k *ar = htt->ar;
> > + int ret;
> > +
> > + ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt tx max num pending tx %d\n",
> > + htt->max_num_pending_tx);
> > +
> > + spin_lock_init(&htt->tx_lock);
> > + idr_init(&htt->pending_tx);
> > +
> > + if (htt->tx_mem_allocated)
> > + return 0;
> > +
> > + ret = ath10k_htt_tx_alloc_buf(htt);
> > + if (ret)
> > + goto free_idr_pending_tx;
> > +
> > + htt->tx_mem_allocated = true;
> > +
> > + return 0;
> > +
> > free_idr_pending_tx:
> > idr_destroy(&htt->pending_tx);
> >
> > @@ -418,15 +437,28 @@ static int ath10k_htt_tx_clean_up_pending(int msdu_id, void *skb, void *ctx)
> > return 0;
> > }
> >
> > -void ath10k_htt_tx_free(struct ath10k_htt *htt)
> > +void ath10k_htt_tx_destroy(struct ath10k_htt *htt)
> > {
> > - idr_for_each(&htt->pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
> > - idr_destroy(&htt->pending_tx);
> > + if (!htt->tx_mem_allocated)
> > + return;
> >
> > ath10k_htt_tx_free_cont_txbuf(htt);
> > ath10k_htt_tx_free_txq(htt);
> > ath10k_htt_tx_free_cont_frag_desc(htt);
> > ath10k_htt_tx_free_txdone_fifo(htt);
> > + htt->tx_mem_allocated = false;
> > +}
> > +
> > +void ath10k_htt_tx_stop(struct ath10k_htt *htt)
> > +{
> > + idr_for_each(&htt->pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
> > + idr_destroy(&htt->pending_tx);
> > +}
> > +
> > +void ath10k_htt_tx_free(struct ath10k_htt *htt)
> > +{
> > + ath10k_htt_tx_stop(htt);
> > + ath10k_htt_tx_destroy(htt);
> > }
> >
> > void ath10k_htt_htc_tx_complete(struct ath10k *ar, struct sk_buff *skb)
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > ath10k mailing list
> > ath10k@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: ath10k: Fix soft lockup during firmware crash/hw-restart
From: Mohammed Shafi Shajakhan @ 2016-12-01 6:06 UTC (permalink / raw)
To: Ben Greear; +Cc: Mohammed Shafi Shajakhan, ath10k, linux-wireless
In-Reply-To: <1a44a3e9-3d67-30a5-0325-a65003ebe1fc@candelatech.com>
On Tue, Nov 29, 2016 at 10:16:50AM -0800, Ben Greear wrote:
> Is this something for stable? And if so, how far back should it be applied?
@Kalle,
[shafi] kindly suggest. If i am not wrong this is only needed for 4.9
>
> I'll add this patch to my 4.9 tree and test it...
>
[shafi] thanks a lot Ben.
>
> On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:
> >From: Mohammed Shafi Shajakhan <mohammed@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 state as 'napi_synchronize'
> >is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> >bit) and it sleeps into infinite loop as it waits for
> >'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> >'ath10k_hif_stop' is called twice as below (resulting in calling
> >'napi_synchronize' after 'napi_disable')
> >
> >'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> >-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> >'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
> >
> >Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> >as it makes more sense before informing mac80211 to restart h/w
> >Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
> >
> >Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >---
> >[thanks to Kalle and Michal for their inputs]
> >
> > drivers/net/wireless/ath/ath10k/core.c | 2 +-
> > drivers/net/wireless/ath/ath10k/mac.c | 1 -
> > 2 files changed, 1 insertion(+), 2 deletions(-)
> >
> >diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> >index 7005e2a..5bc6847 100644
> >--- a/drivers/net/wireless/ath/ath10k/core.c
> >+++ b/drivers/net/wireless/ath/ath10k/core.c
> >@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct *work)
> > switch (ar->state) {
> > case ATH10K_STATE_ON:
> > ar->state = ATH10K_STATE_RESTARTING;
> >- ath10k_hif_stop(ar);
> >+ ath10k_halt(ar);
> > ath10k_scan_finish(ar);
> > ieee80211_restart_hw(ar->hw);
> > break;
> >diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> >index 717b2fa..481842b 100644
> >--- a/drivers/net/wireless/ath/ath10k/mac.c
> >+++ b/drivers/net/wireless/ath/ath10k/mac.c
> >@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
> > ar->state = ATH10K_STATE_ON;
> > break;
> > case ATH10K_STATE_RESTARTING:
> >- ath10k_halt(ar);
> > ar->state = ATH10K_STATE_RESTARTED;
> > break;
> > case ATH10K_STATE_ON:
> >
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
^ permalink raw reply
* Re: pull-request: wireless-drivers 2016-11-29
From: Kalle Valo @ 2016-12-01 5:19 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20161130.143444.242053190479060640.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Tue, 29 Nov 2016 16:59:44 +0200
>
>> if there's still time here's one more patch to 3.9. I think this is good
>> to have in 3.9 as it fixes an issue where we were printing uninitialised
>> memory in mwifiex. I had this in wireless-drivers already for some time
>> as I was waiting for other fixes and nothing serious actually came up.
>>
>> If this doesn't make it to 3.9 that's not a problem, I'll just merge
>> this to wireless-drivers-next. Let me know what you prefer.
>
> Unless you are in a time-machine of some sort I assume you mean "4.9" not
> "3.9" :-)
>
> Pulled, thanks.
Hah, I have no idea where I came up with this "3.9" :) I was trying mean
"4.9" of course, thanks for pulling.
--
Kalle Valo
^ permalink raw reply
* Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
From: Valo, Kalle @ 2016-12-01 5:13 UTC (permalink / raw)
To: Bjorn Andersson
Cc: k.eugene.e@gmail.com, Andy Gross, wcn36xx@lists.infradead.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
In-Reply-To: <878ts0u7z3.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> "Valo, Kalle" <kvalo@qca.qualcomm.com> writes:
>
>> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>>
>>> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
>>>
>>>> Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
>>>> > The correct include file for getting errno constants and ERR_PTR() i=
s
>>>> > linux/err.h, rather than linux/errno.h, so fix the include.
>>>> >=20
>>>> > Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled =
smem_state")
>>>> > Acked-by: Andy Gross <andy.gross@linaro.org>
>>>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>>=20
>>>> For some reason this fails to compile now. Can you take a look, please=
?
>>>>=20
>>>> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn=
36xx.ko] undefined!
>>>> make[1]: *** [__modpost] Error 1
>>>> make: *** [modules] Error 2
>>>>=20
>>>> 5 patches set to Changes Requested.
>>>>=20
>>>> 9429045 [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
>>>> 9429047 [v5,2/5] wcn36xx: Transition driver to SMD client
>>>
>>> This patch was updated with the necessary depends in Kconfig to catch
>>> this exact issue and when I pull in your .config (which has QCOM_SMD=3D=
n,
>>> QCOM_WCNSS_CTRL=3Dn and WCN36XX=3Dy) I can build this just fine.
>>>
>>> I've tested the various combinations and it seems to work fine. Do you
>>> have any other patches in your tree?
>>
>> This was with the pending branch of my ath.git tree. There are other
>> wireless patches (ath10k etc) but I would guess they don't affect here.
>>
>>> Any stale objects?
>>
>> Not sure what you mean with this question, but I didn't run 'make clean'
>> if that's what you are asking.
>>
>>> Would you mind retesting this, before I invest more time in trying to
>>> reproduce the issue you're seeing?
>>
>> Sure, I'll take a look but that might take few days.
>
> I didn't find enough time to look at this in detail. I applied this to
> my ath.git pending branch, let's see what the kbuild bot finds.
It found the same problem. Interestingly I'm also building x86 with 32
bit, maybe it's related?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pendi=
ng
head: 1ea16a1c457939b4564643f7637d5cc639a8d3b7
commit: 5eb09c672b01460804fd49b1c9cc7d1072a102f0 [96/99] wcn36xx: Transitio=
n driver to SMD client
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 5eb09c672b01460804fd49b1c9cc7d1072a102f0
# save the attached .config to linux build tree
make ARCH=3Di386=20
All errors (new ones prefixed by >>):
>> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn36=
xx.ko] undefined!
--=20
Kalle Valo=
^ permalink raw reply
* [PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization
From: Masashi Honma @ 2016-11-30 22:44 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, me, Masashi Honma
mesh_sync_offset_adjust_tbtt() implements Extensible synchronization
framework ([1] 13.13.2 Extensible synchronization framework). It shall
not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh
Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon
collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment
procedures for detail). So this patch remove the flag operations.
[1] IEEE Std 802.11 2012
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
net/mac80211/mesh_sync.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/net/mac80211/mesh_sync.c b/net/mac80211/mesh_sync.c
index faca22c..836d791 100644
--- a/net/mac80211/mesh_sync.c
+++ b/net/mac80211/mesh_sync.c
@@ -172,11 +172,9 @@ static void mesh_sync_offset_adjust_tbtt(struct ieee80211_sub_if_data *sdata,
struct beacon_data *beacon)
{
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
- u8 cap;
WARN_ON(ifmsh->mesh_sp_id != IEEE80211_SYNC_METHOD_NEIGHBOR_OFFSET);
WARN_ON(!rcu_read_lock_held());
- cap = beacon->meshconf->meshconf_cap;
spin_lock_bh(&ifmsh->sync_offset_lock);
@@ -190,21 +188,13 @@ static void mesh_sync_offset_adjust_tbtt(struct ieee80211_sub_if_data *sdata,
"TBTT : kicking off TBTT adjustment with clockdrift_max=%lld\n",
ifmsh->sync_offset_clockdrift_max);
set_bit(MESH_WORK_DRIFT_ADJUST, &ifmsh->wrkq_flags);
-
- ifmsh->adjusting_tbtt = true;
} else {
msync_dbg(sdata,
"TBTT : max clockdrift=%lld; too small to adjust\n",
(long long)ifmsh->sync_offset_clockdrift_max);
ifmsh->sync_offset_clockdrift_max = 0;
-
- ifmsh->adjusting_tbtt = false;
}
spin_unlock_bh(&ifmsh->sync_offset_lock);
-
- beacon->meshconf->meshconf_cap = ifmsh->adjusting_tbtt ?
- IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING | cap :
- ~IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING & cap;
}
static const struct sync_method sync_methods[] = {
--
2.7.4
^ permalink raw reply related
* Re: pull-request: wireless-drivers 2016-11-29
From: David Miller @ 2016-11-30 19:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87r35utjq7.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 29 Nov 2016 16:59:44 +0200
> if there's still time here's one more patch to 3.9. I think this is good
> to have in 3.9 as it fixes an issue where we were printing uninitialised
> memory in mwifiex. I had this in wireless-drivers already for some time
> as I was waiting for other fixes and nothing serious actually came up.
>
> If this doesn't make it to 3.9 that's not a problem, I'll just merge
> this to wireless-drivers-next. Let me know what you prefer.
Unless you are in a time-machine of some sort I assume you mean "4.9" not
"3.9" :-)
Pulled, thanks.
^ permalink raw reply
* [patch] mwifiex: clean up some messy indenting
From: Dan Carpenter @ 2016-11-30 19:21 UTC (permalink / raw)
To: Amitkumar Karwar, Karthik D A
Cc: Nishant Sarmukadam, Kalle Valo, linux-wireless, kernel-janitors
These lines were indented one tab extra.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index f5dffdf..fdc6cc2 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1937,8 +1937,8 @@ int mwifiex_sta_prepare_cmd(struct mwifiex_private *priv, uint16_t cmd_no,
mwifiex_dbg(priv->adapter, ERROR,
"0x%x command not supported by firmware\n",
cmd_no);
- return -EOPNOTSUPP;
- }
+ return -EOPNOTSUPP;
+ }
/* Prepare command */
switch (cmd_no) {
^ permalink raw reply related
* Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
From: Valo, Kalle @ 2016-11-30 18:40 UTC (permalink / raw)
To: Bjorn Andersson
Cc: k.eugene.e@gmail.com, Andy Gross, wcn36xx@lists.infradead.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
In-Reply-To: <877f7vimyg.fsf@kamboji.qca.qualcomm.com>
"Valo, Kalle" <kvalo@qca.qualcomm.com> writes:
> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>
>> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
>>
>>> Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
>>> > The correct include file for getting errno constants and ERR_PTR() is
>>> > linux/err.h, rather than linux/errno.h, so fix the include.
>>> >=20
>>> > Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled s=
mem_state")
>>> > Acked-by: Andy Gross <andy.gross@linaro.org>
>>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>=20
>>> For some reason this fails to compile now. Can you take a look, please?
>>>=20
>>> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn3=
6xx.ko] undefined!
>>> make[1]: *** [__modpost] Error 1
>>> make: *** [modules] Error 2
>>>=20
>>> 5 patches set to Changes Requested.
>>>=20
>>> 9429045 [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
>>> 9429047 [v5,2/5] wcn36xx: Transition driver to SMD client
>>
>> This patch was updated with the necessary depends in Kconfig to catch
>> this exact issue and when I pull in your .config (which has QCOM_SMD=3Dn=
,
>> QCOM_WCNSS_CTRL=3Dn and WCN36XX=3Dy) I can build this just fine.
>>
>> I've tested the various combinations and it seems to work fine. Do you
>> have any other patches in your tree?
>
> This was with the pending branch of my ath.git tree. There are other
> wireless patches (ath10k etc) but I would guess they don't affect here.
>
>> Any stale objects?
>
> Not sure what you mean with this question, but I didn't run 'make clean'
> if that's what you are asking.
>
>> Would you mind retesting this, before I invest more time in trying to
>> reproduce the issue you're seeing?
>
> Sure, I'll take a look but that might take few days.
I didn't find enough time to look at this in detail. I applied this to
my ath.git pending branch, let's see what the kbuild bot finds.
--=20
Kalle Valo=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox