[PATCH 2/2] mwifiex: increase dwell time for active scan
It's been observed that sometimes AP's probe response is
received after scan duration gets completed for the channel.
This happens especially when wildcard scan is performed
along with specific SSID scan.
We will increase the time from 30 msecs to 40 msecs.
Signed-off-by: Amitkumar Karwar
---
drivers/net/wireless/marvell/mwifiex/main.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h
b/drivers/net/wireless/marvell/mwifiex/main.h
index 4c742a5..0207af0 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -111,8 +111,8 @@ enum {
#define SCAN_BEACON_ENTRY_PAD 6
#define MWIFIEX_PASSIVE_SCAN_CHAN_TIME 110
-#define MWIFIEX_ACTIVE_SCAN_CHAN_TIME 30
-#define MWIFIEX_SPECIFIC_SCAN_CHAN_TIME30
+#define MWIFIEX_ACTIVE_SCAN_CHAN_TIME 40
+#define MWIFIEX_SPECIFIC_SCAN_CHAN_TIME40
#define MWIFIEX_DEF_SCAN_CHAN_GAP_TIME 50
#define SCAN_RSSI(RSSI)(0x100 -
((u8)(RSSI)))
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mwifiex: disable channel filtering feature in firmware
As 2.4Ghz channels are overlapping, sometimes AP responds to
probe request even if it's operating on neighbouring channel.
Currently firmware drops those scan entries, as current channel
doesn't match with APs channel.
This patch enables MWIFIEX_DISABLE_CHAN_FILT flag in scan
command to disable the feature so that better scan results
will be received in 2.4Ghz band.
Signed-off-by: Amitkumar Karwar
---
drivers/net/wireless/marvell/mwifiex/scan.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c
b/drivers/net/wireless/marvell/mwifiex/scan.c
index 36cc9cc..bc5e52c 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -498,11 +498,13 @@ mwifiex_scan_create_channel_list(struct mwifiex_private
*priv,
&= ~MWIFIEX_PASSIVE_SCAN;
scan_chan_list[chan_idx].chan_number =
(u32) ch->hw_value;
+
+ scan_chan_list[chan_idx].chan_scan_mode_bitmap
+ |= MWIFIEX_DISABLE_CHAN_FILT;
+
if (filtered_scan) {
scan_chan_list[chan_idx].max_scan_time =
cpu_to_le16(adapter->specific_scan_time);
- scan_chan_list[chan_idx].chan_scan_mode_bitmap
- |= MWIFIEX_DISABLE_CHAN_FILT;
}
chan_idx++;
}
@@ -1060,9 +1062,8 @@ mwifiex_config_scan(struct mwifiex_private *priv,
scan_chan_list[chan_idx].chan_scan_mode_bitmap
&= ~MWIFIEX_PASSIVE_SCAN;
- if (*filtered_scan)
- scan_chan_list[chan_idx].chan_scan_mode_bitmap
- |= MWIFIEX_DISABLE_CHAN_FILT;
+ scan_chan_list[chan_idx].chan_scan_mode_bitmap
+ |= MWIFIEX_DISABLE_CHAN_FILT;
if (user_scan_in->chan_list[chan_idx].scan_time) {
scan_dur = (u16) user_scan_in->
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
我的个人主页是
你的老朋友邀你来Q群:343257759
抢优惠券N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
[PATCH] Staging: wilc1000: Freed memory in case of error
This patch frees memory allocated inside wilc_wlan_txq_add_cfg_pkt()
in case wilc_wlan_txq_add_to_head() fails.
Signed-off-by: Claudiu Beznea
---
drivers/staging/wilc1000/wilc_wlan.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan.c
b/drivers/staging/wilc1000/wilc_wlan.c
index 7da3b4a..11e16d5 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -325,8 +325,11 @@ static int wilc_wlan_txq_add_cfg_pkt(struct wilc_vif *vif,
u8 *buffer,
tqe->priv = NULL;
tqe->tcp_pending_ack_idx = NOT_TCP_ACK;
- if (wilc_wlan_txq_add_to_head(vif, tqe))
+ if (wilc_wlan_txq_add_to_head(vif, tqe)) {
+ kfree(tqe);
return 0;
+ }
+
return 1;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm
Hi Andrew, On Thu, Apr 14, 2016 at 06:42:50AM +1000, Andrew Worsley wrote: > The only time I am getting the IRQ 17 nobody cared message is on > suspend / resume. A fresh boot always had below the 100k interrupt > threshold level. > > I tried your new patch and the number is even lower < 30,000 over two boots. Hm, that's still way too much. You should have < 100 interrupts on IRQ 17 on *every* boot, anything else isn't satisfactory. I'm working on a patch that runs before EFI ExitBootServices() but will need a little longer to find an optimal solution. > Have you any insights on fixing suspend to disk / resume paths which > presumably face the same issue of being passed live hardware on boot > up? Suspend to disk involves two kernels, the boot kernel and the image kernel. Perhaps these two are not the same on your machine and you've only compiled the patch into one of them? Best regards, Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PCI: Add Broadcom 4331 reset quirk to prevent IRQ storm
Hi, On Sat, Apr 09, 2016 at 01:00:55PM +0100, Matt Fleming wrote: > On Wed, 06 Apr, at 11:30:29PM, Lukas Wunner wrote: > > (2) Find out exactly which EFI boot services area is used for DMA and > > amend arch/x86/platform/efi/quirks.c:efi_apply_memmap_quirks() to > > assign that area a different type if dmi_match(DMI_SYS_VENDOR, > > "Apple Inc."). That way it's not freed by efi_free_boot_services(). > > Add a late_initcall which calls free_bootmem() for that area. > > If it is possible to find out which boot services region is the > problematic one, this would be the best solution. If there's any way > to tie it into the PCI quirk, that would be even better so we don't > need to maintain the blacklist in two places. I've since cooked up an experimental patch which resets the Broadcom 4331 wireless card from arch/x86/kernel/early-quirks.c, and another which does the same from arch/x86/boot/compressed/eboot.c. Both approaches stopped the spurious interrupts for me and should also stop the DMA'ing. In the latter case, the machine locked up immediately after resetting the card. Suspecting that the EFI driver doesn't digest the reset well, I tried kicking it off the card with DisconnectController() first. This worked, although it returns EFI_NOT_FOUND, which is strange as that error isn't defined for DisconnectController() per the spec. I then tested if DisconnectController() alone is already sufficient (i.e. without resetting the card by writing to its mmio). Guess what, it is. So the EFI driver seems to leave the card in a sane state if it's unloaded. I then realized that the Simple Network protocol is supported for both the wireless card as well as the Ethernet card built into my MacBook Pro. What I'll try next is to iterate over all handles that support that protocol and just Stop() the interface if it's been brought up by EFI. Perhaps OS X supports some kind of connection handover from EFI. That would explain why they leave the card enabled. Best regards, Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
