* 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: 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: [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 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: 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: [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: 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: 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: 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: 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: [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: 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: [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: [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
* [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/
From: David Howells @ 2016-12-01 12:32 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, netdev, linux-wireless, dhowells,
linux-security-module, keyrings, Kalle Valo
In-Reply-To: <148059537897.31612.9461043954611464597.stgit@warthog.procyon.org.uk>
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/net/wireless/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Kalle Valo <kvalo@codeaurora.org>
cc: linux-wireless@vger.kernel.org
cc: netdev@vger.kernel.org
---
drivers/net/wireless/cisco/airo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/cisco/airo.c b/drivers/net/wireless/cisco/airo.c
index 69b826d229c5..53d43c93a284 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -246,8 +246,8 @@ MODULE_DESCRIPTION("Support for Cisco/Aironet 802.11 wireless ethernet cards. "
"Direct support for ISA/PCI/MPI cards and support for PCMCIA when used with airo_cs.");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_SUPPORTED_DEVICE("Aironet 4500, 4800 and Cisco 340/350");
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
module_param_array(rates, int, NULL, 0);
module_param_array(ssids, charp, NULL, 0);
module_param(auto_wep, int, 0);
^ permalink raw reply related
* mac802_hwsim: libnl does not detect genl hwsim protocol in default ns
From: Benjamin Beichler @ 2016-12-01 12:37 UTC (permalink / raw)
To: linux-wireless
Hi,
I got a strange problem with newer kernel (post 4.8 stable) with hwsim.
Our current code works like this:
modprobe mac80211_hwsim radios=10
./costum_wmediumd
This will create all hwsim_interfaces in the first hwsim "netgroup"
within the default network namespace. But the code to lookup the genl
"MAC80211_HWSIM" protocol fails. Moreover some calls fails, other not ...
//family = genl_ctrl_search_by_name(cache, "MAC80211_HWSIM"); -->
fails directly (return NULL)
int hwsim_netlink_id = genl_ctrl_resolve(sock,"MAC80211_HWSIM");
if (hwsim_netlink_id == 0)
{
printf("Family MAC80211_HWSIM ID not found\n");
exit(EXIT_FAILURE);
}
printf("Family ID found (%d), search for structure
\n\n",hwsim_netlink_id);
family = genl_ctrl_search(cache, hwsim_netlink_id);
if (family == NULL)
{
printf("Family MAC80211_HWSIM family not found\n");
exit(EXIT_FAILURE);
}
this will output:
"Family ID found (28), seatch for structure
Family MAC80211_HWSIM family not found"
But when I start the code in some network namespace, it works (but works
with no interfaces, as they stay in default network namespace). Of
course a workaround is easy, but it definitely breaks some legacy code,
working the same way. I reviewed the recent changes of hwsim regarding
namespaces, but I found no bug. The initial hwsim-devices are created in
netgroup 0 and the default namespace and I don't see any differentiation
of the netlink protocol registration, which depends on network
namespaces. Maybe there is a bug in libnl, but currently I have no Idea,
how to track down the issue.
Any suggestions ?
^ permalink raw reply
* [PATCH] mwifiex: use module_*_driver helper macros
From: Amitkumar Karwar @ 2016-12-01 13:08 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
After user_rmmod global flag removal, *_init_module() and
*_cleanup_module() have become just a wrapper functions.
We will get rid of them with the help of module_*_driver() macros.
For pcie, existing ".init_if" handler has same name as what
module_pcie_driver() macro will create. Let's rename it to
avoid conflict.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 47 ++++-------------------------
drivers/net/wireless/marvell/mwifiex/sdio.c | 29 +-----------------
drivers/net/wireless/marvell/mwifiex/usb.c | 35 +--------------------
3 files changed, 8 insertions(+), 103 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 079bb09..462f014 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2754,7 +2754,7 @@ static void mwifiex_pcie_device_dump(struct mwifiex_adapter *adapter)
* - Allocate command response ring buffer
* - Allocate sleep cookie buffer
*/
-static int mwifiex_pcie_init(struct mwifiex_adapter *adapter)
+static int mwifiex_init_pcie(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
int ret;
@@ -2863,7 +2863,7 @@ static int mwifiex_pcie_init(struct mwifiex_adapter *adapter)
* - Command response ring buffer
* - Sleep cookie buffer
*/
-static void mwifiex_pcie_cleanup(struct mwifiex_adapter *adapter)
+static void mwifiex_cleanup_pcie(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
struct pci_dev *pdev = card->dev;
@@ -3063,7 +3063,7 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
* - Allocate event BD ring buffers
* - Allocate command response ring buffer
* - Allocate sleep cookie buffer
- * Part of mwifiex_pcie_init(), not reset the PCIE registers
+ * Part of mwifiex_init_pcie(), not reset the PCIE registers
*/
static void mwifiex_pcie_up_dev(struct mwifiex_adapter *adapter)
{
@@ -3146,8 +3146,8 @@ static void mwifiex_pcie_down_dev(struct mwifiex_adapter *adapter)
}
static struct mwifiex_if_ops pcie_ops = {
- .init_if = mwifiex_pcie_init,
- .cleanup_if = mwifiex_pcie_cleanup,
+ .init_if = mwifiex_init_pcie,
+ .cleanup_if = mwifiex_cleanup_pcie,
.check_fw_status = mwifiex_check_fw_status,
.check_winner_status = mwifiex_check_winner_status,
.prog_fw = mwifiex_prog_fw_w_helper,
@@ -3173,42 +3173,7 @@ static void mwifiex_pcie_down_dev(struct mwifiex_adapter *adapter)
.up_dev = mwifiex_pcie_up_dev,
};
-/*
- * This function initializes the PCIE driver module.
- *
- * This registers the device with PCIE bus.
- */
-static int mwifiex_pcie_init_module(void)
-{
- int ret;
-
- pr_debug("Marvell PCIe Driver\n");
-
- ret = pci_register_driver(&mwifiex_pcie);
- if (ret)
- pr_err("Driver register failed!\n");
- else
- pr_debug("info: Driver registered successfully!\n");
-
- return ret;
-}
-
-/*
- * This function cleans up the PCIE driver.
- *
- * The following major steps are followed for cleanup -
- * - Resume the device if its suspended
- * - Disconnect the device if connected
- * - Shutdown the firmware
- * - Unregister the device from PCIE bus.
- */
-static void mwifiex_pcie_cleanup_module(void)
-{
- pci_unregister_driver(&mwifiex_pcie);
-}
-
-module_init(mwifiex_pcie_init_module);
-module_exit(mwifiex_pcie_cleanup_module);
+module_pci_driver(mwifiex_pcie);
MODULE_AUTHOR("Marvell International Ltd.");
MODULE_DESCRIPTION("Marvell WiFi-Ex PCI-Express Driver version " PCIE_VERSION);
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 9a16e61..db01794 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2698,34 +2698,7 @@ static void mwifiex_sdio_device_dump(struct mwifiex_adapter *adapter)
.deaggr_pkt = mwifiex_deaggr_sdio_pkt,
};
-/*
- * This function initializes the SDIO driver.
- *
- * This registers the device with SDIO bus.
- */
-static int
-mwifiex_sdio_init_module(void)
-{
- return sdio_register_driver(&mwifiex_sdio);
-}
-
-/*
- * This function cleans up the SDIO driver.
- *
- * The following major steps are followed for cleanup -
- * - Resume the device if its suspended
- * - Disconnect the device if connected
- * - Shutdown the firmware
- * - Unregister the device from SDIO bus.
- */
-static void
-mwifiex_sdio_cleanup_module(void)
-{
- sdio_unregister_driver(&mwifiex_sdio);
-}
-
-module_init(mwifiex_sdio_init_module);
-module_exit(mwifiex_sdio_cleanup_module);
+module_driver(mwifiex_sdio, sdio_register_driver, sdio_unregister_driver);
MODULE_AUTHOR("Marvell International Ltd.");
MODULE_DESCRIPTION("Marvell WiFi-Ex SDIO Driver version " SDIO_VERSION);
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
index 53881c4..9cf3334 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -1200,40 +1200,7 @@ static void mwifiex_usb_submit_rem_rx_urbs(struct mwifiex_adapter *adapter)
.is_port_ready = mwifiex_usb_is_port_ready,
};
-/* This function initializes the USB driver module.
- *
- * This registers the device with USB bus.
- */
-static int mwifiex_usb_init_module(void)
-{
- int ret;
-
- pr_debug("Marvell USB8797 Driver\n");
-
- ret = usb_register(&mwifiex_usb_driver);
- if (ret)
- pr_err("Driver register failed!\n");
- else
- pr_debug("info: Driver registered successfully!\n");
-
- return ret;
-}
-
-/* This function cleans up the USB driver.
- *
- * The following major steps are followed in .disconnect for cleanup:
- * - Resume the device if its suspended
- * - Disconnect the device if connected
- * - Shutdown the firmware
- * - Unregister the device from USB bus.
- */
-static void mwifiex_usb_cleanup_module(void)
-{
- usb_deregister(&mwifiex_usb_driver);
-}
-
-module_init(mwifiex_usb_init_module);
-module_exit(mwifiex_usb_cleanup_module);
+module_usb_driver(mwifiex_usb_driver);
MODULE_AUTHOR("Marvell International Ltd.");
MODULE_DESCRIPTION("Marvell WiFi-Ex USB Driver version" USB_VERSION);
--
1.9.1
^ permalink raw reply related
* RE: [PATCH 2/2] mwifiex: get rid of global user_rmmod flag
From: Amitkumar Karwar @ 2016-12-01 13:11 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, briannorris@google.com, Xinming Hu
In-Reply-To: <20161130183853.GD31934@dtor-ws>
Hi Dmitry,
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Thursday, December 01, 2016 12:09 AM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> rajatja@google.com; briannorris@google.com; Xinming Hu
> Subject: Re: [PATCH 2/2] mwifiex: get rid of global user_rmmod flag
>
> Hi Amitkumar,
>
> On Wed, Nov 30, 2016 at 08:22:17PM +0530, Amitkumar Karwar wrote:
> > @@ -3177,9 +3184,6 @@ static int mwifiex_pcie_init_module(void)
> >
> > pr_debug("Marvell PCIe Driver\n");
> >
> > - /* Clear the flag in case user removes the card. */
> > - user_rmmod = 0;
> > -
> > ret = pci_register_driver(&mwifiex_pcie);
> > if (ret)
> > pr_err("Driver register failed!\n"); @@ -3200,9 +3204,6 @@
> static
> > int mwifiex_pcie_init_module(void)
> > */
> > static void mwifiex_pcie_cleanup_module(void) {
> > - /* Set the flag as user is removing this module. */
> > - user_rmmod = 1;
> > -
> > pci_unregister_driver(&mwifiex_pcie);
> > }
>
> Now that your module init/exit code turns into wrapper around bus
> driver registration calls, please consider using module_pci_driver(),
> module_usb_driver(). Note that I do not see module_sdio_driver, but you
> could still use
>
> module_driver(mwifiex_sdio, sdio_register_driver,
> sdio_unregister_driver);
>
Thanks for review.
I just submitted a separate patch which handles this cleanup.
https://patchwork.kernel.org/patch/9456135/
Regards,
Amitkumar
^ permalink raw reply
* [PATCH] mwifiex: sdio: fix use after free issue for save_adapter
From: Amitkumar Karwar @ 2016-12-01 13:53 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
If we have sdio work requests received when sdio card reset is
happening, we may end up accessing older save_adapter pointer
later which is already freed during card reset.
This patch solves the problem by cancelling those pending requests.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index db01794..44eb65a 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2229,6 +2229,12 @@ static void mwifiex_recreate_adapter(struct sdio_mmc_card *card)
mmc_hw_reset(func->card->host);
sdio_release_host(func);
+ /* Previous save_adapter won't be valid after this. We will cancel
+ * pending work requests.
+ */
+ clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags);
+ clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &iface_work_flags);
+
mwifiex_sdio_probe(func, device_id);
}
--
1.9.1
^ permalink raw reply related
* Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
From: Andy Gross @ 2016-12-01 14:21 UTC (permalink / raw)
To: Valo, Kalle
Cc: Bjorn Andersson, k.eugene.e@gmail.com,
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: <87r35srm0c.fsf@kamboji.qca.qualcomm.com>
On 1 December 2016 at 04:17, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
> 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.
>>>>>> >
>>>>>> > 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>
>>>>>>
>>>>>> For some reason this fails to compile now. Can you take a look, please?
>>>>>>
>>>>>> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn36xx.ko] undefined!
>>>>>> make[1]: *** [__modpost] Error 1
>>>>>> make: *** [modules] Error 2
>>>>>>
>>>>>> 5 patches set to Changes Requested.
>>>>>>
>>>>>> 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=n,
>>>>> QCOM_WCNSS_CTRL=n and WCN36XX=y) 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 pending
>> head: 1ea16a1c457939b4564643f7637d5cc639a8d3b7
>> commit: 5eb09c672b01460804fd49b1c9cc7d1072a102f0 [96/99] wcn36xx: Transition 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=i386
>>
>> All errors (new ones prefixed by >>):
>>
>>>> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn36xx.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-drivers-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.
The qcom-drivers-for-4.10 tag was already merged into arm-soc. But
having you pull it as well won't cause issues so long as you are using
the tag (which you are). I don't see any issues with this approach.
Andy
^ permalink raw reply
* RE: [PATCH v3 4/5] mwifiex: wait firmware dump complete during card remove process
From: Amitkumar Karwar @ 2016-12-01 14:02 UTC (permalink / raw)
To: Brian Norris
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, dmitry.torokhov@gmail.com, Xinming Hu
In-Reply-To: <20161130183339.GA11358@google.com>
Hi Brian,
> From: Brian Norris [mailto:briannorris@chromium.org]
> Sent: Thursday, December 01, 2016 12:04 AM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> rajatja@google.com; dmitry.torokhov@gmail.com; Xinming Hu
> Subject: Re: [PATCH v3 4/5] mwifiex: wait firmware dump complete during
> card remove process
>
> On Wed, Nov 30, 2016 at 12:39:11PM +0000, Amitkumar Karwar wrote:
>
> > > Ugh, yet another band-aid? You might do better to still cancel any
> > > pending work, just don't do it synchronously. i.e., do
> cancel_work()
> > > after you've removed the card. It doesn't make sense to do a FW
> dump
> > > on the "new" adapter when it was requested for the old one.
> >
> > I could not find async version of cancel_work().
>
> cancel_work() *is* asynchronous. It does not synchronize with the last
> event, so you won't have the deadlock. (Remember: the synchronous
> version is cancel_work_sync().)
My bad! What I meant is "I could not find async version of cancel_work_sync()"
cancel_work() isn't available in http://lxr.free-electrons.com/source/kernel/workqueue.c
Anyways, clear_bit() after remove() during card reset would address the problem.
>
> > We can fix this problem with below change at the end of
> > mwifiex_sdio_work(). All pending work requests would be ignored.
> >
> > --------
> > @ -2571,6 +2571,8 @@ static void mwifiex_sdio_work(struct work_struct
> *work)
> > if (test_and_clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET,
> > &iface_work_flags))
> > mwifiex_sdio_card_reset_work(save_adapter);
> > + clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags);
> > + clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &iface_work_flags);
> > }
> > ----------
>
> I don't think that's exactly what you want. That might lose events,
> won't it? I'd rather this sort of hack go into
> mwifiex_recreate_adapter(), in between the remove() and probe() calls,
> where you don't expect any new events to trigger. And maybe include a
> comment as to why.
Right. I have just posted a patch for this.
>
> > > I think I've asked elsewhere but didn't receive an answer: why is
> > > SDIO's mwifiex_recreate_adapter() so much different from PCIe's
> > > mwifiex_do_flr()? It seems like the latter should be refactored to
> > > remove some of the PCIe-specific cruft from main.c and then reused
> > > for SDIO.
> >
> > Our initial SDIO card reset implementation was based on MMC APIs
> where
> > remove() and probe() would automatically get called by MMC subsystem
> > after power cycle.
> > https://www.spinics.net/lists/linux-wireless/msg98435.html
> > Later it was improved by Andreas Fenkart by replacing those power
> > cycle APIs with mmc_hw_reset().
>
> Right.
>
> > For PCIe, function level reset is standard feature. We implemented
> > ".reset_notify" handler which gets called after and before FLR.
>
> OK.
>
> > You are right. We can have SDIO's handling similar to PCIe and avoid
> > destroying+recreating adapter/card.
>
> So all in all, you're saying it's just an artifact of history, and
> there's no good reason they are so different? If so, then this looks
> like another instance where you would have done well to refactor and
> improve the existing mechanisms at the same time as you added new
> features (i.e., PCIe FLR). I've seen this problem already several
> times, where it seems development for your SDIO/PCIe/USB interface
> drivers occur almost in isolation. IMO, it'd do you well to notice
> these patterns while implementing features in the first place. The more
> code you can share, the fewer bugs you (or I) will have to chase down.
Thanks for your guidance. I'll follow this for future development.
Regards,
Amitkumar
^ permalink raw reply
* Re: [PATCH 2/2] net: rfkill: Add rfkill-any LED trigger
From: kbuild test robot @ 2016-12-01 17:29 UTC (permalink / raw)
To: Michał Kępień
Cc: kbuild-all, Johannes Berg, David S . Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20161130120317.11851-2-kernel@kempniu.pl>
[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]
Hi Michał,
[auto build test ERROR on mac80211-next/master]
[also build test ERROR on v4.9-rc7 next-20161201]
[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/Micha-K-pie/net-rfkill-Cleanup-error-handling-in-rfkill_init/20161202-002119
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
config: i386-randconfig-x004-201648 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/rfkill/core.c: In function 'rfkill_set_block':
>> net/rfkill/core.c:354:2: error: implicit declaration of function '__rfkill_any_led_trigger_event' [-Werror=implicit-function-declaration]
__rfkill_any_led_trigger_event();
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/rfkill/core.c: In function 'rfkill_init':
net/rfkill/core.c:1349:1: warning: label 'error_led_trigger' defined but not used [-Wunused-label]
error_led_trigger:
^~~~~~~~~~~~~~~~~
At top level:
net/rfkill/core.c:243:13: warning: 'rfkill_any_led_trigger_unregister' defined but not used [-Wunused-function]
static void rfkill_any_led_trigger_unregister(void)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/rfkill/core.c:238:12: warning: 'rfkill_any_led_trigger_register' defined but not used [-Wunused-function]
static int rfkill_any_led_trigger_register(void)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/__rfkill_any_led_trigger_event +354 net/rfkill/core.c
348 rfkill->state &= ~RFKILL_BLOCK_SW_SETCALL;
349 rfkill->state &= ~RFKILL_BLOCK_SW_PREV;
350 curr = rfkill->state & RFKILL_BLOCK_SW;
351 spin_unlock_irqrestore(&rfkill->lock, flags);
352
353 rfkill_led_trigger_event(rfkill);
> 354 __rfkill_any_led_trigger_event();
355
356 if (prev != curr)
357 rfkill_event(rfkill);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26068 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] net: rfkill: Add rfkill-any LED trigger
From: kbuild test robot @ 2016-12-01 18:06 UTC (permalink / raw)
To: Michał Kępień
Cc: kbuild-all, Johannes Berg, David S . Miller, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20161130120317.11851-2-kernel@kempniu.pl>
[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]
Hi Michał,
[auto build test WARNING on mac80211-next/master]
[also build test WARNING on v4.9-rc7 next-20161201]
[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/Micha-K-pie/net-rfkill-Cleanup-error-handling-in-rfkill_init/20161202-002119
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All warnings (new ones prefixed by >>):
>> WARNING: net/rfkill/rfkill.o(.init.text+0xa2): Section mismatch in reference from the function _init_module() to the function .exit.text:_rfkill_handler_exit()
The function __init _init_module() references
a function __exit _rfkill_handler_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __exit annotation of
_rfkill_handler_exit() so it may be used outside an exit section.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 42125 bytes --]
^ permalink raw reply
* pull-request: wireless-drivers-next 2016-12-01
From: Kalle Valo @ 2016-12-01 18:33 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's another pull request for net-next. Nothing special to mention
about, the details are in the signed tag below.
This time there's a trivial conflict in
drivers/net/wireless/ath/ath10k/mac.c:
<<<<<<< HEAD
ieee80211_hw_set(ar->hw, SUPPORTS_TX_FRAG);
=======
ieee80211_hw_set(ar->hw, REPORTS_LOW_ACK);
>>>>>>> d5fb3a138048798ce4cc4b4ced47d07d1794c577
We want to have both flags enabled in ath10k.
I'm planning to submit at least one more pull request, if Linus gives us
one more week I might send even two. For example there are patches to
convert wcn36xx to use the real SMD bus subsystem but they depend on few
arm-soc patches. I'll send a separate email about that, they are not
part of this pull request.
Please let me know if there are any problems.
Kalle
The following changes since commit 159a55a64d44acbbd6f0d8f3c082e628d6d75670:
rt2800: disable CCK rates on HT (2016-11-23 17:38:53 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2016-12-01
for you to fetch changes up to d5fb3a138048798ce4cc4b4ced47d07d1794c577:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2016-12-01 15:09:14 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 4.10
Major changes:
rsi
* filter rx frames
* configure tx power
* make it possible to select antenna
* support 802.11d
brcmfmac
* cleanup of scheduled scan code
* support for bcm43341 chipset with different chip id
* support rev6 of PCIe device interface
ath10k
* add spectral scan support for QCA6174 and QCA9377 families
* show used tx bitrate with 10.4 firmware
wil6210
* add power save mode support
* add abort scan functionality
* add support settings retry limit for short frames
bcma
* add Dell Inspiron 3148
----------------------------------------------------------------
Anilkumar Kolli (2):
ath10k: add per peer htt tx stats support for 10.4
ath10k: add support for per sta tx bitrate
Anthony Romano (2):
mt7601u: wait for clear rxq when stopping mac
ath9k_htc: don't use HZ for usb msg timeouts
Arend Van Spriel (11):
brcmfmac: add support for 43341 chip
brcmfmac: move pno helper functions in separate source file
brcmfmac: fix handling ssids in .sched_scan_start() callback
brcmfmac: change prototype for brcmf_do_escan()
brcmfmac: make internal escan more generic
brcmfmac: split up brcmf_pno_config() function
brcmfmac: move scheduled scan activation to pno source file
brcmfmac: use provided channels for scheduled scan
brcmfmac: remove restriction from .sched_scan_start() callback
brcmfmac: use requested scan interval in scheduled scan
brcmfmac: fix scheduled scan result handling for newer chips
Barry Day (1):
rtl8xxxu: tx rate reported before set
Ben Greear (1):
ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL
Bhumika Goyal (1):
ath9k: constify ath_bus_ops structure
Brian Norris (3):
mwifiex: cleanup wake-IRQ handling if suspend fails
mwifiex: avoid double-disable_irq() race
mwifiex: pcie: implement timeout loop for FW programming doorbell
Dedy Lansky (1):
wil6210: fix net queue stop/wake
Erik Stromdahl (1):
ath10k: fix TLV set regdomain command
Franky Lin (1):
brcmfmac: add pcie host dongle interface rev6 support
Geliang Tang (1):
ath5k: drop duplicate header vmalloc.h
Jes Sorensen (7):
rtl8xxxu: Fix memory leak in handling rxdesc16 packets
rtl8xxxu: Fix big-endian problem reporting mactime
rtl8xxxu: Fix rtl8723bu driver reload issue
rtl8xxxu: Fix rtl8192eu driver reload issue
rtl8xxxu: Obtain RTS rates from mac80211
rtl8xxxu: Pass tx_info to fill_txdesc in order to have access to retry count
rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting
Jiri Slaby (1):
bcma: add Dell Inspiron 3148
Kalle Valo (1):
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karthik D A (1):
mwifiex: Disable adhoc feature based on firmware capability
Kirtika Ruchandani (7):
mwifiex: Removed unused mwifiex_private* 'priv' variable
mwifiex: Remove unused 'chan_num' variable
mwifiex: Remove unused 'sta_ptr' variable
mwifiex: Remove unused 'adapter'variable
mwifiex: Remove unused 'pm_flag' variable
mwifiex: Removed unused 'pkt_type' variable
mwifiex: Remove unused 'bcd_usb' variable
Larry Finger (1):
rtlwifi: Fix enter/exit power_save
Lior David (6):
wil6210: fix deadlock when using fw_no_recovery option
wil6210: align to latest auto generated wmi.h
wil6210: support NL80211_ATTR_WIPHY_RETRY_SHORT
wil6210: delay remain on channel when scan is active
wil6210: add debugfs blobs for UCODE code and data
wil6210: align to latest auto generated wmi.h
Manoharan, Rajkumar (1):
ath10k: fix monitor vdev for receiving other bss frames
Matthias Schiffer (1):
ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success
Maya Erez (3):
wil6210: add support for power save enable / disable
wil6210: add support for abort scan
wil6210: validate wil_pmc_alloc parameters
Miaoqing Pan (1):
ath9k: fix NULL pointer dereference
Michal Kazior (2):
ath10k: fix null deref on wmi-tlv when trying spectral scan
ath10k: add spectral scan support to wmi-tlv
Mohammed Shafi Shajakhan (2):
ath10k: fix soft lockup during firmware crash/hw-restart
ath10k: fix Tx DMA alloc failure during continuous wifi down/up
Pedersen, Thomas (2):
ath10k: implement offset_tsf ieee80211_op
ath10k: remove set/get_tsf ieee80211_ops
Prameela Rani Garnepudi (4):
rsi: Add support to filter rx frames
rsi: Add support for configuring tx power
rsi: Add support for antenna selection
rsi: Add support for 802.11d
Rajkumar Manoharan (1):
ath10k: advertize hardware packet loss mechanism
Tobias Regnery (1):
brcmsmac: fix array out-of-bounds access in qm_log10
Wei Yongjun (1):
rtl8xxxu: Fix non static symbol warning
Zefir Kurtisi (1):
ath9k: feed only active spectral / dfs-detector
drivers/bcma/host_pci.c | 1 +
drivers/net/wireless/ath/ath10k/core.c | 8 +-
drivers/net/wireless/ath/ath10k/core.h | 24 +
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 13 +
drivers/net/wireless/ath/ath10k/htt.c | 2 +
drivers/net/wireless/ath/ath10k/htt.h | 31 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 125 +++++
drivers/net/wireless/ath/ath10k/htt_tx.c | 54 +-
drivers/net/wireless/ath/ath10k/mac.c | 51 +-
drivers/net/wireless/ath/ath10k/wmi-ops.h | 6 +
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 77 ++-
drivers/net/wireless/ath/ath10k/wmi.c | 8 +-
drivers/net/wireless/ath/ath10k/wmi.h | 18 +-
drivers/net/wireless/ath/ath5k/debug.c | 1 -
drivers/net/wireless/ath/ath9k/ahb.c | 2 +-
drivers/net/wireless/ath/ath9k/common-spectral.c | 8 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 9 +-
drivers/net/wireless/ath/ath9k/hif_usb.h | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/ath/ath9k/recv.c | 17 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 129 ++++-
drivers/net/wireless/ath/wil6210/main.c | 100 ++--
drivers/net/wireless/ath/wil6210/netdev.c | 2 +-
drivers/net/wireless/ath/wil6210/p2p.c | 160 ++++--
drivers/net/wireless/ath/wil6210/pmc.c | 55 +-
drivers/net/wireless/ath/wil6210/txrx.c | 110 +++-
drivers/net/wireless/ath/wil6210/wil6210.h | 25 +-
drivers/net/wireless/ath/wil6210/wil_crash_dump.c | 6 +
drivers/net/wireless/ath/wil6210/wmi.c | 160 +++++-
drivers/net/wireless/ath/wil6210/wmi.h | 586 ++++++++++++++++----
.../wireless/broadcom/brcm80211/brcmfmac/Makefile | 3 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 10 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 381 +++++--------
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 4 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 23 +
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 38 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.h | 4 +
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 171 +++---
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 242 ++++++++
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.h | 40 ++
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 +
.../broadcom/brcm80211/brcmsmac/phy/phy_qmath.c | 5 +-
.../broadcom/brcm80211/include/brcm_hw_ids.h | 1 +
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 12 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/main.c | 3 -
drivers/net/wireless/marvell/mwifiex/main.h | 9 +-
drivers/net/wireless/marvell/mwifiex/pcie.c | 17 +-
drivers/net/wireless/marvell/mwifiex/scan.c | 8 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 6 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 38 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 3 +-
drivers/net/wireless/mediatek/mt7601u/init.c | 14 +-
drivers/net/wireless/mediatek/mt7601u/regs.h | 3 +
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 31 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 10 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 4 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 122 ++--
drivers/net/wireless/realtek/rtlwifi/base.c | 8 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 9 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 14 +-
drivers/net/wireless/realtek/rtlwifi/ps.c | 36 +-
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 156 +++++-
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 129 ++++-
drivers/net/wireless/rsi/rsi_main.h | 4 +
drivers/net/wireless/rsi/rsi_mgmt.h | 23 +-
66 files changed, 2581 insertions(+), 794 deletions(-)
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.h
^ permalink raw reply
* Fwd: Ralink RT3290 Specification/ Programming guide
From: Abhiroop Dabral @ 2016-12-01 18:56 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAKuLJhD+X=Q5D-4dUw0xCEzWyX4yd3Fi7QtJnHe2Hif_40uhmA@mail.gmail.com>
Hi,
This is kind of little bit off topic. But I was looking for the
programming / specification guide for Ralink RT3290. I tried googling
for it but no luck.
I will really appreciate if any one can help me out in finding a guide
for the same.
Thanks
Abhi
^ 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