* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Luis R. Rodriguez @ 2017-01-29 17:10 UTC (permalink / raw)
To: Pali Rohár
Cc: Kalle Valo, Arend Van Spriel, Ming Lei, Luis R. Rodriguez,
Greg Kroah-Hartman, David Gnedt, Michal Kazior, Daniel Wagner,
Tony Lindgren, Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Grazvydas Ignotas, linux-kernel, linux-wireless,
netdev
In-Reply-To: <20170127131146.GI24223@pali>
On Fri, Jan 27, 2017 at 02:11:46PM +0100, Pali Rohár wrote:
> So there are only two options:
>
> 1) Disallow it and so these users will have non-working wifi.
>
> 2) Allow those data to be used as fallback mechanism.
There is one "custom fallback" user in kernel which we recently
determined was a total mistake. A sysfs interface should have
been defined to enable custom LED settings. Can't a series of
sysfs interfaces be used to enable override ? So is that not a
third option worth consideration?
Luis
^ permalink raw reply
* [PATCH] ath10k: Add debugfs support to get per peer tids log via tracing
From: c_mkenna @ 2017-01-30 6:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, mkenna, Maharaja Kennadyrajan
From: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
This patch provides support to get per peer tids log.
echo 1 > /sys/kernel/debug/ieee80211/phyX/netdev\:wlanX/stations/
XX:XX/peer_debug_trigger
These logs will be the part of FWLOGS which we collect the logs
via tracing interface. Here we will get the peer tigd logs only
once(not repeatedly) when we write 1 to the debugfs file.
Signed-off-by: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 65 +++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 1 +
2 files changed, 66 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index fce6f81..7353e7e 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -306,6 +306,69 @@ static ssize_t ath10k_dbg_sta_write_delba(struct file *file,
.llseek = default_llseek,
};
+static ssize_t ath10k_dbg_sta_read_peer_debug_trigger(struct file *file,
+ char __user *user_buf,
+ size_t count,
+ loff_t *ppos)
+{
+ struct ieee80211_sta *sta = file->private_data;
+ struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+ struct ath10k *ar = arsta->arvif->ar;
+ char buf[8];
+ int len = 0;
+
+ mutex_lock(&ar->conf_mutex);
+ len = scnprintf(buf, sizeof(buf) - len,
+ "Write 1 to once trigger the debug logs\n");
+ mutex_unlock(&ar->conf_mutex);
+
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t
+ath10k_dbg_sta_write_peer_debug_trigger(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ieee80211_sta *sta = file->private_data;
+ struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+ struct ath10k *ar = arsta->arvif->ar;
+ u8 peer_debug_trigger;
+ int ret;
+
+ if (kstrtou8_from_user(user_buf, count, 0, &peer_debug_trigger))
+ return -EINVAL;
+
+ if (peer_debug_trigger != 1)
+ return -EINVAL;
+
+ mutex_lock(&ar->conf_mutex);
+
+ if (ar->state != ATH10K_STATE_ON) {
+ ret = -ENETDOWN;
+ goto out;
+ }
+
+ ret = ath10k_wmi_peer_set_param(ar, arsta->arvif->vdev_id, sta->addr,
+ WMI_PEER_DEBUG, peer_debug_trigger);
+ if (ret) {
+ ath10k_warn(ar, "failed to set param to trigger peer tid logs for station ret: %d\n",
+ ret);
+ goto out;
+ }
+out:
+ mutex_unlock(&ar->conf_mutex);
+ return count;
+}
+
+static const struct file_operations fops_peer_debug_trigger = {
+ .open = simple_open,
+ .read = ath10k_dbg_sta_read_peer_debug_trigger,
+ .write = ath10k_dbg_sta_write_peer_debug_trigger,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
void ath10k_sta_add_debugfs(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_sta *sta, struct dentry *dir)
{
@@ -314,4 +377,6 @@ void ath10k_sta_add_debugfs(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
debugfs_create_file("addba", S_IWUSR, dir, sta, &fops_addba);
debugfs_create_file("addba_resp", S_IWUSR, dir, sta, &fops_addba_resp);
debugfs_create_file("delba", S_IWUSR, dir, sta, &fops_delba);
+ debugfs_create_file("peer_debug_trigger", 0600, dir, sta,
+ &fops_peer_debug_trigger);
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 861c2d8..1b1c1ef 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -5811,6 +5811,7 @@ enum wmi_peer_param {
WMI_PEER_CHAN_WIDTH = 0x4,
WMI_PEER_NSS = 0x5,
WMI_PEER_USE_4ADDR = 0x6,
+ WMI_PEER_DEBUG = 0xa,
WMI_PEER_DUMMY_VAR = 0xff, /* dummy parameter for STA PS workaround */
};
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2] ath10k: fix boot failure in UTF mode/testmode
From: c_traja @ 2017-01-30 8:45 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, stable, tamizhchelvam, Tamizh chelvam
From: Tamizh chelvam <c_traja@qti.qualcomm.com>
Rx filter reset and the dynamic tx switch mode (EXT_RESOURCE_CFG)
configuration are causing the following errors when UTF firmware
is loaded to the target.
Error message 1:
[ 598.015629] ath10k_pci 0001:01:00.0: failed to ping firmware: -110
[ 598.020828] ath10k_pci 0001:01:00.0: failed to reset rx filter: -110
[ 598.141556] ath10k_pci 0001:01:00.0: failed to start core (testmode): -110
Error message 2:
[ 668.615839] ath10k_ahb a000000.wifi: failed to send ext resource cfg command : -95
[ 668.618902] ath10k_ahb a000000.wifi: failed to start core (testmode): -95
Avoiding these configurations while bringing the target in
testmode is solving the problem.
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
---
v2:
*Added stable@vger.kernel.org in cc list
drivers/net/wireless/ath/ath10k/core.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 874c2a7..0d12761 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1922,7 +1922,8 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
ath10k_dbg(ar, ATH10K_DBG_BOOT, "firmware %s booted\n",
ar->hw->wiphy->fw_version);
- if (test_bit(WMI_SERVICE_EXT_RES_CFG_SUPPORT, ar->wmi.svc_map)) {
+ if (test_bit(WMI_SERVICE_EXT_RES_CFG_SUPPORT, ar->wmi.svc_map) &&
+ mode == ATH10K_FIRMWARE_MODE_NORMAL) {
val = 0;
if (ath10k_peer_stats_enabled(ar))
val = WMI_10_4_PEER_STATS;
@@ -1975,10 +1976,13 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
* possible to implicitly make it correct by creating a dummy vdev and
* then deleting it.
*/
- status = ath10k_core_reset_rx_filter(ar);
- if (status) {
- ath10k_err(ar, "failed to reset rx filter: %d\n", status);
- goto err_hif_stop;
+ if (mode == ATH10K_FIRMWARE_MODE_NORMAL) {
+ status = ath10k_core_reset_rx_filter(ar);
+ if (status) {
+ ath10k_err(ar,
+ "failed to reset rx filter: %d\n", status);
+ goto err_hif_stop;
+ }
}
/* If firmware indicates Full Rx Reorder support it must be used in a
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCHv2] ath10k: fix boot failure in UTF mode/testmode
From: Greg KH @ 2017-01-30 9:06 UTC (permalink / raw)
To: c_traja; +Cc: ath10k, linux-wireless, stable, tamizhchelvam
In-Reply-To: <1485765958-26802-1-git-send-email-c_traja@qti.qualcomm.com>
On Mon, Jan 30, 2017 at 02:15:58PM +0530, c_traja@qti.qualcomm.com wrote:
> From: Tamizh chelvam <c_traja@qti.qualcomm.com>
>
> Rx filter reset and the dynamic tx switch mode (EXT_RESOURCE_CFG)
> configuration are causing the following errors when UTF firmware
> is loaded to the target.
>
> Error message 1:
> [ 598.015629] ath10k_pci 0001:01:00.0: failed to ping firmware: -110
> [ 598.020828] ath10k_pci 0001:01:00.0: failed to reset rx filter: -110
> [ 598.141556] ath10k_pci 0001:01:00.0: failed to start core (testmode): -110
>
> Error message 2:
> [ 668.615839] ath10k_ahb a000000.wifi: failed to send ext resource cfg command : -95
> [ 668.618902] ath10k_ahb a000000.wifi: failed to start core (testmode): -95
>
> Avoiding these configurations while bringing the target in
> testmode is solving the problem.
>
> Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
> ---
> v2:
> *Added stable@vger.kernel.org in cc list
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: [PATCH] rt2x00: fix clk_get call
From: Stanislaw Gruszka @ 2017-01-30 9:54 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Helmut Schaa, Daniel Golle, Felix Fietkau
In-Reply-To: <87vasxgbnx.fsf@purkki.adurom.net>
On Sun, Jan 29, 2017 at 04:53:38PM +0200, Kalle Valo wrote:
> Stanislaw Gruszka <sgruszka@redhat.com> writes:
>
> > clk_get() takes two arguments and might return ERR_PTR(), so we
> > have to nullify pointer on that case, to do not break further call
> > to clk_get_rate().
> >
> > Reported-by: Felix Fietkau <nbd@nbd.name>
> > Fixes: 34db70b92fae5 ("rt2x00: add copy of clk for soc devices")
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
>
> The commit id looks wrong, I think it should be:
>
> Fixes: 34db70b92fae ("rt2x00: add copy of clk for soc devices")
Yes, this one is correct.
> I can fix that during commit.
Please do, thanks.
Stanislaw
^ permalink raw reply
* [PATCH] iwlwifi: alloc memory dynamically also for DVM
From: Luca Coelho @ 2017-01-30 10:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Sara Sharon, Luca Coelho
In-Reply-To: <87efzmt11g.fsf@kamboji.qca.qualcomm.com>
From: Sara Sharon <sara.sharon@intel.com>
For old firmwares the memory wasn't allocated, resulting in panic.
Make it dynamically allocated as well. Allow any order of functions
call.
Fixes: eef187a7b8a1 ("iwlwifi: enlarge number of ucode sections")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
Kalle,
Could you test this patch to see if it solves the problem?
Thanks!
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index 1d1af4bc1530..d22821501676 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -291,11 +291,33 @@ static struct fw_sec *get_sec(struct iwl_firmware_pieces *pieces,
return &pieces->img[type].sec[sec];
}
+static void alloc_sec_data(struct iwl_firmware_pieces *pieces,
+ enum iwl_ucode_type type,
+ int sec)
+{
+ struct fw_img_parsing *img = &pieces->img[type];
+ struct fw_sec *sec_memory;
+ int size = sec + 1;
+ size_t alloc_size = sizeof(*img->sec) * size;
+
+ if (img->sec && img->sec_counter >= size)
+ return;
+
+ sec_memory = krealloc(img->sec, alloc_size, GFP_KERNEL);
+ if (!sec_memory)
+ return;
+
+ img->sec = sec_memory;
+ img->sec_counter = size;
+}
+
static void set_sec_data(struct iwl_firmware_pieces *pieces,
enum iwl_ucode_type type,
int sec,
const void *data)
{
+ alloc_sec_data(pieces, type, sec);
+
pieces->img[type].sec[sec].data = data;
}
@@ -304,6 +326,8 @@ static void set_sec_size(struct iwl_firmware_pieces *pieces,
int sec,
size_t size)
{
+ alloc_sec_data(pieces, type, sec);
+
pieces->img[type].sec[sec].size = size;
}
@@ -319,6 +343,8 @@ static void set_sec_offset(struct iwl_firmware_pieces *pieces,
int sec,
u32 offset)
{
+ alloc_sec_data(pieces, type, sec);
+
pieces->img[type].sec[sec].offset = offset;
}
--
2.11.0
^ permalink raw reply related
* [PATCH v2] rt2800: enable rt3290 unconditionally on pci probe
From: Stanislaw Gruszka @ 2017-01-30 11:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa
When we restart system using sysrq RT3290 device do not initalize
properly, hance always enable it via WLAN_FUN_CTRL register on
probe.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=85461
Reported-and-tested-by: Giedrius Statkevičius <edrius.statkevicius@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 560b696..c6e64cc 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -373,9 +373,6 @@ static int rt2800_enable_wlan_rt3290(struct rt2x00_dev *rt2x00dev)
int i, count;
rt2800_register_read(rt2x00dev, WLAN_FUN_CTRL, ®);
- if (rt2x00_get_field32(reg, WLAN_EN))
- return 0;
-
rt2x00_set_field32(®, WLAN_GPIO_OUT_OE_BIT_ALL, 0xff);
rt2x00_set_field32(®, FRC_WL_ANT_SET, 1);
rt2x00_set_field32(®, WLAN_CLK_EN, 0);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] iwlwifi: alloc memory dynamically also for DVM
From: Kalle Valo @ 2017-01-30 11:40 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Sara Sharon, Luca Coelho
In-Reply-To: <20170130103432.24613-1-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> From: Sara Sharon <sara.sharon@intel.com>
>
> For old firmwares the memory wasn't allocated, resulting in panic.
> Make it dynamically allocated as well. Allow any order of functions
> call.
>
> Fixes: eef187a7b8a1 ("iwlwifi: enlarge number of ucode sections")
> Signed-off-by: Sara Sharon <sara.sharon@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
>
> Kalle,
>
> Could you test this patch to see if it solves the problem?
It does, thank you for quickly fixing this.
Tested-by: Kalle Valo <kvalo@codeaurora.org>
As this is a serious regression can I apply this directly to
wireless-drivers-next?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] iwlwifi: alloc memory dynamically also for DVM
From: Luca Coelho @ 2017-01-30 11:42 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Sara Sharon
In-Reply-To: <87poj4srmg.fsf@kamboji.qca.qualcomm.com>
On Mon, 2017-01-30 at 13:40 +0200, Kalle Valo wrote:
> Luca Coelho <luca@coelho.fi> writes:
>
> > From: Sara Sharon <sara.sharon@intel.com>
> >
> > For old firmwares the memory wasn't allocated, resulting in panic.
> > Make it dynamically allocated as well. Allow any order of functions
> > call.
> >
> > Fixes: eef187a7b8a1 ("iwlwifi: enlarge number of ucode sections")
> > Signed-off-by: Sara Sharon <sara.sharon@intel.com>
> > Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> > ---
> >
> > Kalle,
> >
> > Could you test this patch to see if it solves the problem?
>
> It does, thank you for quickly fixing this.
>
> Tested-by: Kalle Valo <kvalo@codeaurora.org>
Great! Thanks a lot for testing it quickly. :)
> As this is a serious regression can I apply this directly to
> wireless-drivers-next?
Yes, please go ahead.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] wireless-regdb: Remove DFS requirement for India (IN)
From: Jouni Malinen @ 2017-01-30 12:08 UTC (permalink / raw)
To: Seth Forshee; +Cc: wireless-regdb, linux-wireless
The "Indoor Use of low power wireless equipment in the frequency band 5
GHz (Exemption from Licensing Requirement) Rules, 2005" notification by
Ministry of Communications and Information Technology (Wireless Planning
and Coordination Wing) (New Delhi, the 28th January 2005) does not
mandate use of DFS, so remove the DFS flag from the 5250-5330 MHz band
in India.
In addition, increase the TX power limit to 23 dBm to match the 200 mW
maximum mentioned in the same notification. Also use the exact ranges
from that notification and enable use of 160 MHz channels in the
5150-5350 MHz band.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
db.txt | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/db.txt b/db.txt
index 7964cfb..05108e0 100644
--- a/db.txt
+++ b/db.txt
@@ -580,11 +580,10 @@ country IL: DFS-ETSI
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (200 mW), NO-OUTDOOR, DFS, AUTO-BW
-country IN: DFS-JP
+country IN:
(2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (20), AUTO-BW
- (5250 - 5330 @ 80), (20), DFS, AUTO-BW
- (5735 - 5835 @ 80), (20)
+ (5150 - 5350 @ 160), (23)
+ (5725 - 5875 @ 80), (23)
country IR: DFS-JP
(2402 - 2482 @ 40), (20)
--
2.7.4
^ permalink raw reply related
* [PATCH] wlcore: let AP support allmulticast for MDNS. It can be enabled by bringing up the interface with ip command with the argument allmulticast on
From: Iain Hunter @ 2017-01-30 12:54 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Iain Hunter
Let AP support allmulticast for MDNS.
It can be enabled by bringing up the interface with ip command with the argument allmulticast on
Signed-off-by: Iain Hunter <i-hunter1@ti.com>
---
drivers/net/wireless/ti/wlcore/main.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..1ab0561ab13 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -3281,6 +3281,20 @@ static void wl1271_op_configure_filter(struct ieee80211_hw *hw,
if (ret < 0)
goto out_sleep;
}
+
+ /*
+ * If interface in AP mode and created with allmulticast then disable
+ * the firmware filters so that all multicast packets are passed
+ * This is mandatory for MDNS based discovery protocols
+ */
+ if (wlvif->bss_type == BSS_TYPE_AP_BSS) {
+ if (*total & FIF_ALLMULTI)
+ ret = wl1271_acx_group_address_tbl(wl, wlvif,
+ false,
+ NULL, 0);
+
+ }
+
}
/*
--
2.11.0
^ permalink raw reply related
* [PATCH] wlcore: let AP support allmulticast for MDNS. It can be enabled by bringing up the interface with ip command with the argument allmulticast on
From: Iain Hunter @ 2017-01-30 12:37 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Iain Hunter
Let AP support allmulticast for MDNS.
It can be enabled by bringing up the interface with ip command and the argument allmulticast on
Signed-off-by: Iain Hunter <i-hunter1@ti.com>
---
drivers/net/wireless/ti/wlcore/main.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..1ab0561ab13 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -3281,6 +3281,20 @@ static void wl1271_op_configure_filter(struct ieee80211_hw *hw,
if (ret < 0)
goto out_sleep;
}
+
+ /*
+ * If interface in AP mode and created with allmulticast then disable
+ * the firmware filters so that all multicast packets are passed
+ * This is mandatory for MDNS based discovery protocols
+ */
+ if (wlvif->bss_type == BSS_TYPE_AP_BSS) {
+ if (*total & FIF_ALLMULTI)
+ ret = wl1271_acx_group_address_tbl(wl, wlvif,
+ false,
+ NULL, 0);
+
+ }
+
}
/*
--
2.11.0
^ permalink raw reply related
* [PATCH] wlcore: disable multicast filter in AP mode
From: Iain Hunter @ 2017-01-30 14:49 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Iain Hunter
Enable AP support allmulticast for MDNS. It can be enabled by bringing up
the interface with ip command with the argument allmulticast on
Signed-off-by: Iain Hunter <i-hunter1@ti.com>
---
drivers/net/wireless/ti/wlcore/main.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..1ab0561ab13 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -3281,6 +3281,20 @@ static void wl1271_op_configure_filter(struct ieee80211_hw *hw,
if (ret < 0)
goto out_sleep;
}
+
+ /*
+ * If interface in AP mode and created with allmulticast then disable
+ * the firmware filters so that all multicast packets are passed
+ * This is mandatory for MDNS based discovery protocols
+ */
+ if (wlvif->bss_type == BSS_TYPE_AP_BSS) {
+ if (*total & FIF_ALLMULTI)
+ ret = wl1271_acx_group_address_tbl(wl, wlvif,
+ false,
+ NULL, 0);
+
+ }
+
}
/*
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] wlcore: let AP support allmulticast for MDNS. It can be enabled by bringing up the interface with ip command with the argument allmulticast on
From: Kalle Valo @ 2017-01-30 14:24 UTC (permalink / raw)
To: Iain Hunter; +Cc: linux-wireless, Iain Hunter
In-Reply-To: <20170130125417.6188-1-i-hunter1@ti.com>
Iain Hunter <drhunter95@gmail.com> writes:
> Let AP support allmulticast for MDNS.
> It can be enabled by bringing up the interface with ip command with the argument allmulticast on
>
> Signed-off-by: Iain Hunter <i-hunter1@ti.com>
I see your patch now in patchwork (twice actually):
https://patchwork.kernel.org/patch/9545223/
But there's a problem with the title, you just copied the commit log as
the title. The format should be something like this (also please word
wrap the commit log):
----------------------------------------------------------------------
wlcore: disable firmware multicast filter in AP mode
Let AP support allmulticast for MDNS. It can be enabled by bringing up
the interface with ip command with the argument allmulticast on.
Signed-off-by: Ed Example <ed@example.org>
----------------------------------------------------------------------
You can see examples from patchwork, like this iwlwifi patch:
https://patchwork.kernel.org/patch/9544763/
--
Kalle Valo
^ permalink raw reply
* [PATCH 2/2] brcmfmac: be more verbose when PSM's watchdog fires
From: Rafał Miłecki @ 2017-01-30 15:09 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170130150952.7133-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
It's important to inform user so he knows things went wrong. He may also
want to get memory dump for further debugging purposes.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
index 6f8a4b074c31..f4644cf371c7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
@@ -58,10 +58,18 @@ static int brcmf_debug_psm_watchdog_notify(struct brcmf_if *ifp,
const struct brcmf_event_msg *evtmsg,
void *data)
{
+ int err;
+
brcmf_dbg(TRACE, "enter: bsscfgidx=%d\n", ifp->bsscfgidx);
- return brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
- evtmsg->datalen);
+ brcmf_err("PSM's watchdog has fired!\n");
+
+ err = brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
+ evtmsg->datalen);
+ if (err)
+ brcmf_err("Failed to get memory dump, %d\n", err);
+
+ return err;
}
void brcmf_debugfs_init(void)
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] brcmfmac: check brcmf_bus_get_memdump result for error
From: Rafał Miłecki @ 2017-01-30 15:09 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
This method may be unsupported (see: USB bus) or may just fail (see:
SDIO bus).
While at it rework logic in brcmf_sdio_bus_get_memdump function to avoid
too many conditional code nesting levels.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../wireless/broadcom/brcm80211/brcmfmac/debug.c | 23 +++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
index e64557c35553..6f8a4b074c31 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
@@ -32,16 +32,25 @@ static int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
{
void *dump;
size_t ramsize;
+ int err;
ramsize = brcmf_bus_get_ramsize(bus);
- if (ramsize) {
- dump = vzalloc(len + ramsize);
- if (!dump)
- return -ENOMEM;
- memcpy(dump, data, len);
- brcmf_bus_get_memdump(bus, dump + len, ramsize);
- dev_coredumpv(bus->dev, dump, len + ramsize, GFP_KERNEL);
+ if (!ramsize)
+ return -ENOTSUPP;
+
+ dump = vzalloc(len + ramsize);
+ if (!dump)
+ return -ENOMEM;
+
+ memcpy(dump, data, len);
+ err = brcmf_bus_get_memdump(bus, dump + len, ramsize);
+ if (err) {
+ vfree(dump);
+ return err;
}
+
+ dev_coredumpv(bus->dev, dump, len + ramsize, GFP_KERNEL);
+
return 0;
}
--
2.11.0
^ permalink raw reply related
* Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Klaus Kinski @ 2017-01-30 15:57 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hello all,
this is a blast from the past, but something that still bothers me.
I have two systems with Atheros/QCA cards:
System A:
OS and driver: Linux 3.18.36 with last Madwifi/sample code from trunk
WLAN card: AR5413 (Senao EMP-8602 PLUS-S)
System B:
OS and driver: Linux 3.18.36 with mac80211/minstrel and ath9k from backports-4.2
WLAN card: AR9280 (Compex WLE200NX)
While doing the performance measurements both systems are connected to a reference system
with a HF cable, so there should be no outside influences.
Both systems are running in 802.11a mode on channel 40.
The following table shows 802.11 data packets sent from system A and B generated by
iperf in UDP mode over a 2s interval:
Data rate madwifi %of total ath9k minstrel %of total
6.0 855 2,31 37 0,12
9.0 0 0,00 22 0,07
12.0 0 0,00 23 0,07
18.0 0 0,00 20 0,06
24.0 9 0,02 21 0,07
36.0 855 2,31 20 0,06
48.0 856 2,31 24 0,08
54.0 34413 93,04 31566 99,47
total 36988 100,00 31733 100,00
It shows how many packets where sent at what data rate and the percentage of these packets
from the total. Both stacks are sending most packets with 54Mbit/s (93% and 99%).
Overall Madwifi sends 36988 (= 100%) data packets whereas mac80211 only sends 31733 (= 85%) data packets.
Does anybody know where this difference comes from? It's not the CPU; both systems
have plenty enough for the task. I'm pretty sure that the reason is in the stack,
probably mac80211.
I have asked basically the same question almost 6 years ago (see http://narkive.com/F8xI8bUp.1 ).
An interesting proposal at that time came from Adrian Chadd in http://narkive.com/F8xI8bUp.15:
does madwifi have that net80211 "aggressive mode" by default, where it
overrides the best-effort WME queue parameters to allow for bursting?
I could not find a mac80211 option to control this "aggressive mode". Is there one? Or a patch
to test it out?
Thanks in advance
Joerg
^ permalink raw reply
* Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Toke Høiland-Jørgensen @ 2017-01-30 16:17 UTC (permalink / raw)
To: Klaus Kinski; +Cc: linux-wireless
In-Reply-To: <HE1PR0701MB1803E46BC8EC38D682361523FC4B0@HE1PR0701MB1803.eurprd07.prod.outlook.com>
Klaus Kinski <jpo234-1ViLX0X+lBKELgA04lAiVw@public.gmane.org> writes:
> Hello all,
>
> this is a blast from the past, but something that still bothers me.
> I have two systems with Atheros/QCA cards:
>
> System A:
> OS and driver: Linux 3.18.36 with last Madwifi/sample code from trunk
>
> WLAN card: AR5413 (Senao EMP-8602 PLUS-S)
>
> System B:
> OS and driver: Linux 3.18.36 with mac80211/minstrel and ath9k from backports-4.2
>
> WLAN card: AR9280 (Compex WLE200NX)
>
> While doing the performance measurements both systems are connected to a reference system
>
> with a HF cable, so there should be no outside influences.
>
> Both systems are running in 802.11a mode on channel 40.
> The following table shows 802.11 data packets sent from system A and B generated by
>
> iperf in UDP mode over a 2s interval:
What version of iperf, and configured to which rate? Some versions of
iperf will send its traffic in very large bursts (see
http://burntchrome.blogspot.se/2016/09/iperf3-and-microbursts.html?m=1)
which could cause the queue inside ath9k to overflow (it is only 123
packets pre-4.10).
Did you try the latest mac80211/ath9k from 4.10? The queueing structure
changed dramatically, which would impact this, at least if it's a queue
overflow problem...
-Toke
^ permalink raw reply
* Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Dave Taht @ 2017-01-30 16:49 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: Klaus Kinski, linux-wireless
In-Reply-To: <87lgtsjz6o.fsf@toke.dk>
On Mon, Jan 30, 2017 at 8:17 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@tok=
e.dk> wrote:
> Klaus Kinski <jpo234-1ViLX0X+lBKELgA04lAiVw@public.gmane.org> writes:
>
>> Hello all,
>>
>> this is a blast from the past, but something that still bothers me.
>> I have two systems with Atheros/QCA cards:
>>
>> System A:
>> OS and driver: Linux 3.18.36 with last Madwifi/sample code from trunk
>>
>> WLAN card: AR5413 (Senao EMP-8602 PLUS-S)
>>
>> System B:
>> OS and driver: Linux 3.18.36 with mac80211/minstrel and ath9k from bac=
kports-4.2
>>
>> WLAN card: AR9280 (Compex WLE200NX)
>>
>> While doing the performance measurements both systems are connected to a=
reference system
>>
>> with a HF cable, so there should be no outside influences.
>>
>> Both systems are running in 802.11a mode on channel 40.
>> The following table shows 802.11 data packets sent from system A and B g=
enerated by
>>
>> iperf in UDP mode over a 2s interval:
>
> What version of iperf, and configured to which rate? Some versions of
> iperf will send its traffic in very large bursts (see
> http://burntchrome.blogspot.se/2016/09/iperf3-and-microbursts.html?m=3D1)
> which could cause the queue inside ath9k to overflow (it is only 123
> packets pre-4.10).
>
> Did you try the latest mac80211/ath9k from 4.10? The queueing structure
> changed dramatically, which would impact this, at least if it's a queue
> overflow problem...
Packet captures would be helpful. Aircaps, if possible, also.
> -Toke
--=20
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* [PATCH] rtlwifi: rtl8192ce: Fix loading of incorrect firmware
From: Larry Finger @ 2017-01-30 17:40 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Larry Finger, Jurij Smakov, Stable
In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
d86e64768859, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE.
Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
---
Kalle,
This patch should be pushed upstream as soon as possible. Note that it
does not cause a kernel panic. It does, however, reduce the reliability
of the wireless connection.
Larry
---
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
index b875a72..9a94e45 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
@@ -96,7 +96,7 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
- char *fw_name = "rtlwifi/rtl8192cfwU.bin";
+ char *fw_name;
rtl8192ce_bt_reg_init(hw);
@@ -167,8 +167,13 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
}
/* request fw */
- if (IS_81XXC_VENDOR_UMC_B_CUT(rtlhal->version))
+ if (IS_VENDOR_UMC_A_CUT(rtlhal->version) &&
+ !IS_92C_SERIAL(rtlhal->version))
+ fw_name = "rtlwifi/rtl8192cfwU.bin";
+ else if (IS_81XXC_VENDOR_UMC_B_CUT(rtlhal->version))
fw_name = "rtlwifi/rtl8192cfwU_B.bin";
+ else
+ fw_name = "rtlwifi/rtl8192cfw.bin";
rtlpriv->max_fw_size = 0x4000;
pr_info("Using firmware %s\n", fw_name);
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Tony Lindgren @ 2017-01-30 17:53 UTC (permalink / raw)
To: Pavel Machek
Cc: Kalle Valo, Pali Rohár, Arend Van Spriel, Ming Lei,
Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt, Michal Kazior,
Daniel Wagner, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127194012.GE20571@amd>
* Pavel Machek <pavel@ucw.cz> [170127 11:41]:
> On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
> > Pali Rohár <pali.rohar@gmail.com> writes:
> >
> > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> > >> Pali Rohár <pali.rohar@gmail.com> writes:
> > >>
> > >> > 2) It was already tested that example NVS data can be used for N900 e.g.
> > >> > for SSH connection. If real correct data are not available it is better
> > >> > to use at least those example (and probably log warning message) so user
> > >> > can connect via SSH and start investigating where is problem.
> > >>
> > >> I disagree. Allowing default calibration data to be used can be
> > >> unnoticed by user and left her wondering why wifi works so badly.
> > >
> > > So there are only two options:
> > >
> > > 1) Disallow it and so these users will have non-working wifi.
> > >
> > > 2) Allow those data to be used as fallback mechanism.
> > >
> > > And personally I'm against 1) because it will break wifi support for
> > > *all* Nokia N900 devices right now.
> >
> > All two of them? :)
>
> Umm. You clearly want a flock of angry penguins at your doorsteps :-).
Well this silly issue of symlinking and renaming nvs files in a standard
Linux distro was also hitting me on various devices with wl12xx/wl18xx
trying to use the same rootfs.
Why don't we just set a custom compatible property for n900 that then
picks up some other nvs file instead of the default?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-30 18:03 UTC (permalink / raw)
To: Tony Lindgren
Cc: Pavel Machek, Kalle Valo, Arend Van Spriel, Ming Lei,
Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt, Michal Kazior,
Daniel Wagner, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170130175309.GY7403@atomide.com>
[-- Attachment #1: Type: Text/Plain, Size: 1925 bytes --]
On Monday 30 January 2017 18:53:09 Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [170127 11:41]:
> > On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
> > > Pali Rohár <pali.rohar@gmail.com> writes:
> > > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> > > >> Pali Rohár <pali.rohar@gmail.com> writes:
> > > >> > 2) It was already tested that example NVS data can be used
> > > >> > for N900 e.g. for SSH connection. If real correct data are
> > > >> > not available it is better to use at least those example
> > > >> > (and probably log warning message) so user can connect via
> > > >> > SSH and start investigating where is problem.
> > > >>
> > > >> I disagree. Allowing default calibration data to be used can
> > > >> be unnoticed by user and left her wondering why wifi works so
> > > >> badly.
> > > >
> > > > So there are only two options:
> > > >
> > > > 1) Disallow it and so these users will have non-working wifi.
> > > >
> > > > 2) Allow those data to be used as fallback mechanism.
> > > >
> > > > And personally I'm against 1) because it will break wifi
> > > > support for *all* Nokia N900 devices right now.
> > >
> > > All two of them? :)
> >
> > Umm. You clearly want a flock of angry penguins at your doorsteps
> > :-).
>
> Well this silly issue of symlinking and renaming nvs files in a
> standard Linux distro was also hitting me on various devices with
> wl12xx/wl18xx trying to use the same rootfs.
wl12xx/wl18xx have probably exactly same problem as wl1251.
> Why don't we just set a custom compatible property for n900 that then
> picks up some other nvs file instead of the default?
But that still does not solve this problem correctly. Every n900 device
have different NVS file. If we allow to load firmware directly from VFS
without userspace helper we would see again same problem.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Searching new home for ath[59]k-devel mailing lists
From: Michael Renzmann @ 2017-01-30 18:40 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <877f5g7lwd.fsf@kamboji.qca.qualcomm.com>
Kalle Valo wrote:
>>> Are you planning to update the MAINTAINERS file or should I?
>> It would be great if you could take care of that.
> Ok, I'll send a patch.
Thanks!
>> [1] https://wireless.wiki.kernel.org/en/users/Drivers/ath9k
> I updated that now.
I've applied similar changes to the ath9k_htc and ath5k pages.
Bye, Mike
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8192ce: Fix loading of incorrect firmware
From: Kalle Valo @ 2017-01-30 19:10 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Jurij Smakov, Stable
In-Reply-To: <20170130174057.7681-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
> d86e64768859, an error in the edit results in the wrong firmware
> being loaded for some models of the RTL8188/8192CE.
>
> Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
> Signed-off-by: Jurij Smakov <jurij@wooyd.org>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
This patch is written by Jurij, right? So then there should be a From
line in the commit log making him the author. An example here from Luca
where Sara is the author:
https://patchwork.kernel.org/patch/9544763/
> Cc: Stable <stable@vger.kernel.org>
You could add "# 4.9" here to make Greg's life easier. And no need to CC
stable in the email headers, having it in the commit log is enough.
> Kalle,
>
> This patch should be pushed upstream as soon as possible. Note that it
> does not cause a kernel panic. It does, however, reduce the reliability
> of the wireless connection.
Yeah, this looks like to be valid for 4.10 still. But please mention in
the commit log about the bug symptoms (reliability problems etc).
--
Kalle Valo
^ permalink raw reply
* Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Toke Høiland-Jørgensen @ 2017-01-30 19:43 UTC (permalink / raw)
To: Klaus Kinski; +Cc: Dave Taht, linux-wireless
In-Reply-To: <HE1PR0701MB1803A03DD96F300119936D0EFC4B0@HE1PR0701MB1803.eurprd07.prod.outlook.com>
Klaus Kinski <jpo234@outlook.de> writes:
> The captures I used to create the statistics are here:
> https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>
> An obvious difference is, that Madwifi sends 5 packets in a row
> without waiting for an ACK whereas ath9k/mac80211 always seems to wait
> for an ACK. This seems to point to the "net80211 aggressive mode
> theory" https://wiki.freebsd.org/WifiAggressiveMode, IMHO.
I'm not too familiar with that part of the stack, but that seems
reasonable, yeah. AFAIK the "aggresive mode" is a pre-802.11n feature,
though, which is why you won't see that in ath9k. In 802.11n this kind
of bursting was replaced by aggregation, which you're not getting any of
since you're running in 802.11a mode, obviously.
The lack of bursting will translate to slightly lower throughput, which
will be why you see fewer packets transmitted by ath9k. Of course, if
your receiver supported aggregation, the numbers would look dramatically
better in ath9k's favour... ;)
-Toke
^ 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