Re: [PATCH] bcma: Kconfig: Let it depend on PCI
Sorry for my carelessness, I deleted the original reply mail to me (may also deleted another mails to me, too). The hotmail is not stable, I am just struggling with it (it can not work well with linux-ker...@vger.kernel.org). Could you forward your original reply to me again? Thanks. On 3/4/15 05:16, Chen Gang wrote: > bcma also needs PCI, just like IOMEM and DMA, so let it depend on PCI, > or will cause building break for allmodconfig under c6x: > > CC [M] drivers/bcma/driver_pcie2.o > drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up': > drivers/bcma/driver_pcie2.c:196:8: error: implicit declaration of function > 'pcie_set_readrq' [-Werror=implicit-function-declaration] > err = pcie_set_readrq(dev, pcie2->reqsize); > ^ > > Signed-off-by: Chen Gang > --- > drivers/bcma/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig > index 0ee48be..8be284e 100644 > --- a/drivers/bcma/Kconfig > +++ b/drivers/bcma/Kconfig > @@ -1,6 +1,6 @@ > config BCMA_POSSIBLE > bool > - depends on HAS_IOMEM && HAS_DMA > + depends on HAS_IOMEM && HAS_DMA && PCI > default y > > menu "Broadcom specific AMBA" > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- 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] bcma: Kconfig: Let it depend on PCI
On 3 March 2015 at 22:16, Chen Gang wrote: > bcma also needs PCI, just like IOMEM and DMA, so let it depend on PCI, > or will cause building break for allmodconfig under c6x: > > CC [M] drivers/bcma/driver_pcie2.o > drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up': > drivers/bcma/driver_pcie2.c:196:8: error: implicit declaration of function > 'pcie_set_readrq' [-Werror=implicit-function-declaration] > err = pcie_set_readrq(dev, pcie2->reqsize); > ^ > > Signed-off-by: Chen Gang > --- > drivers/bcma/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig > index 0ee48be..8be284e 100644 > --- a/drivers/bcma/Kconfig > +++ b/drivers/bcma/Kconfig > @@ -1,6 +1,6 @@ > config BCMA_POSSIBLE > bool > - depends on HAS_IOMEM && HAS_DMA > + depends on HAS_IOMEM && HAS_DMA && PCI > default y > > menu "Broadcom specific AMBA" > -- > 1.9.3 Hm, I'm not sure how to ideally handle this. Cc-ing few ppl, maybe they have something to add. In fact there are SoCs (not using PCI host code obviously) with everything embedded (without any PCI host mode cores). So note following info about driver_pci.c and driver_pcie2.c: 1) For BCMA_HOST_PCI They are required, because of needed host-related PCI(e) core initialization. 2) For BCMA_HOST_SOC They are needed only if your SoC has PCI(e) host cores and you want to use them. So I guess in theory we could have BCMA_DRIVER_PCI and *require* it for BCMA_HOST_PCI only. This could save some little amount of space for users of some SoCs like (ancient) BCM5352E, BCM5354 or (newer) BCM5357B0, BCM5358, BCM47186B0, BCM5357C0, BCM5356C0, BCM4716B0. -- Rafał -- 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 v2] iw: display allowable channel bandwidth information
We already have allowable channel bandwidth information at userspace.
Display this information with 'iw list'. Excerpt of iw list command
Frequencies:
* 5180 MHz [36] (17.0 dBm)
(10MHZ, 20MHZ, HT40+, VHT80, VHT160)
* 5200 MHz [40] (17.0 dBm)
(10MHZ, 20MHZ, HT40-, HT40+, VHT80, VHT160)
Signed-off-by: Ashok Raj Nagarajan
---
v2:
Display channel bw information in separate line (Johannes)
Updated commit log to reflect above change.
info.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/info.c b/info.c
index 1df503f..728cb87 100644
--- a/info.c
+++ b/info.c
@@ -189,6 +189,31 @@ next:
printf(")");
printf("\n");
+ if
(!tb_freq[NL80211_FREQUENCY_ATTR_DISABLED]) {
+ open = 0;
+ printf("\t\t\t ");
+ if
(!tb_freq[NL80211_FREQUENCY_ATTR_NO_10MHZ])
+ print_flag("10MHz",
&open);
+
+ if
(!tb_freq[NL80211_FREQUENCY_ATTR_NO_20MHZ])
+ print_flag("20MHz",
&open);
+
+ if
(!tb_freq[NL80211_FREQUENCY_ATTR_NO_HT40_MINUS])
+ print_flag("HT40-",
&open);
+
+ if
(!tb_freq[NL80211_FREQUENCY_ATTR_NO_HT40_PLUS])
+ print_flag("HT40+",
&open);
+
+ if
(!tb_freq[NL80211_FREQUENCY_ATTR_NO_80MHZ])
+ print_flag("VHT80",
&open);
+
+ if
(!tb_freq[NL80211_FREQUENCY_ATTR_NO_160MHZ])
+ print_flag("VHT160",
&open);
+ if (open)
+ printf(")");
+ printf("\n");
+ }
+
if
(!tb_freq[NL80211_FREQUENCY_ATTR_DISABLED] &&
tb_freq[NL80211_FREQUENCY_ATTR_DFS_STATE]) {
enum nl80211_dfs_state state =
nla_get_u32(tb_freq[NL80211_FREQUENCY_ATTR_DFS_STATE]);
unsigned long time;
--
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
[PATCH v2 1/2] ath10k: fix rts profile for second rate series
By default rts protection is enabled in firmware for the second rateset. Currently ath10k selects RTS profile (only for software retries), when legacy stations are associated or asked by mac80211. On congested environment, when AP is running in HT/VHT mode and there are no legacy clients associated, this will impact the robustness. Also enabling RTS protection only for second rateset will not impact performance on clear environment. Fix that. Signed-off-by: Rajkumar Manoharan --- drivers/net/wireless/ath/ath10k/mac.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 84a243e..37141b3 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -798,12 +798,14 @@ static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif) vdev_param = ar->wmi.vdev_param->enable_rtscts; - if (arvif->use_cts_prot || arvif->num_legacy_stations > 0) - rts_cts |= SM(WMI_RTSCTS_ENABLED, WMI_RTSCTS_SET); + rts_cts |= SM(WMI_RTSCTS_ENABLED, WMI_RTSCTS_SET); if (arvif->num_legacy_stations > 0) rts_cts |= SM(WMI_RTSCTS_ACROSS_SW_RETRIES, WMI_RTSCTS_PROFILE); + else + rts_cts |= SM(WMI_RTSCTS_FOR_SECOND_RATESERIES, + WMI_RTSCTS_PROFILE); return ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param, rts_cts); -- 2.3.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
[PATCH v2 2/2] ath10k: increase station kickout threshold
Since the station kickout threshold is also counting software reries (Default sw count in firmware is 16), increasing the threshold to try with atleast 20 data frames before kicking out the station. Signed-off-by: Rajkumar Manoharan --- drivers/net/wireless/ath/ath10k/core.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index 7cba781..e43c453 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -50,8 +50,8 @@ #define ATH10K_MAX_NUM_MGMT_PENDING 128 -/* number of failed packets */ -#define ATH10K_KICKOUT_THRESHOLD 50 +/* number of failed packets (20 packets with 16 sw reties each) */ +#define ATH10K_KICKOUT_THRESHOLD (20 * 16) /* * Use insanely high numbers to make sure that the firmware implementation -- 2.3.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
[PATCH 2/2] ath5k: fix reset race
To prepare for reset ath5k should finish all asynchronous tasks. At
first, it disables the interrupt generation, then it waits for the
interrupt handler and tasklets completion, and then proceeds to the HW
configuration update. But it does not consider that the interrupt
handler or tasklet re-enables the interrupt generation. And we fall in a
situation when ath5k assumes that interrupts are disabled, but it is
not.
This can lead to different consequences, such as reception of the frame,
when we do not expect it. Under certain circumstances, this can lead to
the following warning:
WARNING: at ath5k/base.c:589 ath5k_tasklet_rx+0x318/0x6ec [ath5k]()
invalid hw_rix: 1a
[..]
Call Trace:
[<802656a8>] show_stack+0x48/0x70
[<802dd92c>] warn_slowpath_common+0x88/0xbc
[<802dd98c>] warn_slowpath_fmt+0x2c/0x38
[<81b51be8>] ath5k_tasklet_rx+0x318/0x6ec [ath5k]
[<8028ac64>] tasklet_action+0x8c/0xf0
[<80075804>] __do_softirq+0x180/0x32c
[<80196ce8>] irq_exit+0x54/0x70
[<80041848>] ret_from_irq+0x0/0x4
[<80182fdc>] ioread32+0x4/0xc
[<81b4c42c>] ath5k_hw_set_sleep_clock+0x2ec/0x474 [ath5k]
[<81b4cf28>] ath5k_hw_reset+0x50/0xeb8 [ath5k]
[<81b50900>] ath5k_reset+0xd4/0x310 [ath5k]
[<81b557e8>] ath5k_config+0x4c/0x104 [ath5k]
[<80d01770>] ieee80211_hw_config+0x2f4/0x35c [mac80211]
[<80d09aa8>] ieee80211_scan_work+0x2e4/0x414 [mac80211]
[<8022c3f4>] process_one_work+0x28c/0x400
[<802df8f8>] worker_thread+0x258/0x3c0
[<801b5710>] kthread+0xe0/0xec
[<800418a8>] ret_from_kernel_thread+0x14/0x1c
Fix this issue by adding a new status flag, which forbids to re-enable
the interrupt generation until the HW configuration is completed.
Note: previous patch, which reorders the Rx disable code helps to avoid
the above warning, but not fixes the root cause of unexpected frame
receiving.
CC: Jiri Slaby
CC: Nick Kossifidis
CC: Luis R. Rodriguez
Reported-by: Christophe Prevotaux
Tested-by: Christophe Prevotaux
Tested-by: Eric Bree
Signed-off-by: Sergey Ryazanov
---
drivers/net/wireless/ath/ath5k/ath5k.h | 1 +
drivers/net/wireless/ath/ath5k/base.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h
b/drivers/net/wireless/ath/ath5k/ath5k.h
index 1ed7a88..7ca0d6f 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1283,6 +1283,7 @@ struct ath5k_hw {
#define ATH_STAT_PROMISC 1
#define ATH_STAT_LEDSOFT 2 /* enable LED gpio status */
#define ATH_STAT_STARTED 3 /* opened & irqs enabled */
+#define ATH_STAT_RESET 4 /* hw reset */
unsigned intfilter_flags; /* HW flags, AR5K_RX_FILTER_* */
unsigned intfif_filter_flags; /* Current FIF_* filter flags
*/
diff --git a/drivers/net/wireless/ath/ath5k/base.c
b/drivers/net/wireless/ath/ath5k/base.c
index 34b2f15..41848e1 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1523,6 +1523,9 @@ ath5k_set_current_imask(struct ath5k_hw *ah)
enum ath5k_int imask;
unsigned long flags;
+ if (test_bit(ATH_STAT_RESET, ah->status))
+ return;
+
spin_lock_irqsave(&ah->irqlock, flags);
imask = ah->imask;
if (ah->rx_pending)
@@ -2862,6 +2865,8 @@ ath5k_reset(struct ath5k_hw *ah, struct ieee80211_channel
*chan,
ATH5K_DBG(ah, ATH5K_DEBUG_RESET, "resetting\n");
+ __set_bit(ATH_STAT_RESET, ah->status);
+
ath5k_hw_set_imr(ah, 0);
synchronize_irq(ah->irq);
ath5k_stop_tasklets(ah);
@@ -2952,6 +2957,8 @@ ath5k_reset(struct ath5k_hw *ah, struct ieee80211_channel
*chan,
*/
/* ath5k_chan_change(ah, c); */
+ __clear_bit(ATH_STAT_RESET, ah->status);
+
ath5k_beacon_config(ah);
/* intrs are enabled by ath5k_beacon_config */
--
2.0.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 0/2] ath5k: reset path fixes
Couple of patches for the reset code path to address the "invalid hw_rix" warning and to make reset more robust. Patch 1 helps to avoid warning by fixing the order of rx disable and channel update actions. Patch 2 fixes the root cause, which is interrupt disable/enable race between tasklet and reset function. The second patch contains a more generic fix, which is enough to prevent the warning. But I think that the first patch should be applied too, just in case. If no one has any objections. Sergey Ryazanov (2): ath5k: channel change fix ath5k: fix reset race drivers/net/wireless/ath/ath5k/ath5k.h | 1 + drivers/net/wireless/ath/ath5k/base.c | 31 --- drivers/net/wireless/ath/ath5k/reset.c | 24 3 files changed, 29 insertions(+), 27 deletions(-) -- 2.0.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] ath5k: channel change fix
ath5k updates the channel pointer and after that it stops the Rx logic
and apply channel to HW. In case of channel switch, such sequence
creates a small window when a frame, which is received on the old
channel is considered as a frame received on the new one.
The most notable consequence of this situation occurs during the switch
from 2 GHz band (CCK+OFDM) to the 5GHz band (OFDM-only). Frame received
with CCK rate, e.g. beacon received at the 1mbps, causes the following
warning:
WARNING: at ath5k/base.c:589 ath5k_tasklet_rx+0x318/0x6ec [ath5k]()
invalid hw_rix: 1a
[..]
Call Trace:
[<802656a8>] show_stack+0x48/0x70
[<802dd92c>] warn_slowpath_common+0x88/0xbc
[<802dd98c>] warn_slowpath_fmt+0x2c/0x38
[<81b51be8>] ath5k_tasklet_rx+0x318/0x6ec [ath5k]
[<8028ac64>] tasklet_action+0x8c/0xf0
[<80075804>] __do_softirq+0x180/0x32c
[<80196ce8>] irq_exit+0x54/0x70
[<80041848>] ret_from_irq+0x0/0x4
[<80182fdc>] ioread32+0x4/0xc
[<81b4c42c>] ath5k_hw_set_sleep_clock+0x2ec/0x474 [ath5k]
[<81b4cf28>] ath5k_hw_reset+0x50/0xeb8 [ath5k]
[<81b50900>] ath5k_reset+0xd4/0x310 [ath5k]
[<81b557e8>] ath5k_config+0x4c/0x104 [ath5k]
[<80d01770>] ieee80211_hw_config+0x2f4/0x35c [mac80211]
[<80d09aa8>] ieee80211_scan_work+0x2e4/0x414 [mac80211]
[<8022c3f4>] process_one_work+0x28c/0x400
[<802df8f8>] worker_thread+0x258/0x3c0
[<801b5710>] kthread+0xe0/0xec
[<800418a8>] ret_from_kernel_thread+0x14/0x1c
The easiest way to reproduce this warning is to run scan with dualband
NIC in noisy environments, when the channel 11 runs multiple APs. In my
tests if the APs num >= 12, the warning appears in the first few
seconds of scanning.
In order to fix this, the Rx disable code moved to a higher level and
placed before the channel pointer update. This is also makes the code a
bit more symmetrical, since we disable and enable the Rx in the same
function.
In fact, at the pointer update time new frames should not appear,
because interrupt generation at this point should already be disabled.
The next patch should address this issue.
CC: Jiri Slaby
CC: Nick Kossifidis
CC: Luis R. Rodriguez
Reported-by: Christophe Prevotaux
Tested-by: Christophe Prevotaux
Tested-by: Eric Bree
Signed-off-by: Sergey Ryazanov
---
drivers/net/wireless/ath/ath5k/base.c | 24 +---
drivers/net/wireless/ath/ath5k/reset.c | 24
2 files changed, 21 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c
b/drivers/net/wireless/ath/ath5k/base.c
index bc9cb35..34b2f15 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2858,7 +2858,7 @@ ath5k_reset(struct ath5k_hw *ah, struct ieee80211_channel
*chan,
{
struct ath_common *common = ath5k_hw_common(ah);
int ret, ani_mode;
- bool fast;
+ bool fast = chan && modparam_fastchanswitch ? 1 : 0;
ATH5K_DBG(ah, ATH5K_DEBUG_RESET, "resetting\n");
@@ -2876,11 +2876,29 @@ ath5k_reset(struct ath5k_hw *ah, struct
ieee80211_channel *chan,
* so we should also free any remaining
* tx buffers */
ath5k_drain_tx_buffs(ah);
+
+ /* Stop PCU */
+ ath5k_hw_stop_rx_pcu(ah);
+
+ /* Stop DMA
+*
+* Note: If DMA didn't stop continue
+* since only a reset will fix it.
+*/
+ ret = ath5k_hw_dma_stop(ah);
+
+ /* RF Bus grant won't work if we have pending
+* frames
+*/
+ if (ret && fast) {
+ ATH5K_DBG(ah, ATH5K_DEBUG_RESET,
+ "DMA didn't stop, falling back to normal reset\n");
+ fast = false;
+ }
+
if (chan)
ah->curchan = chan;
- fast = ((chan != NULL) && modparam_fastchanswitch) ? 1 : 0;
-
ret = ath5k_hw_reset(ah, ah->opmode, ah->curchan, fast, skip_pcu);
if (ret) {
ATH5K_ERR(ah, "can't reset hardware (%d)\n", ret);
diff --git a/drivers/net/wireless/ath/ath5k/reset.c
b/drivers/net/wireless/ath/ath5k/reset.c
index b9b651e..99e62f9 100644
--- a/drivers/net/wireless/ath/ath5k/reset.c
+++ b/drivers/net/wireless/ath/ath5k/reset.c
@@ -1169,30 +1169,6 @@ ath5k_hw_reset(struct ath5k_hw *ah, enum nl80211_iftype
op_mode,
if (ah->ah_version == AR5K_AR5212)
ath5k_hw_set_sleep_clock(ah, false);
- /*
-* Stop PCU
-*/
- ath5k_hw_stop_rx_pcu(ah);
-
- /*
-* Stop DMA
-*
-* Note: If DMA didn't stop continue
-* since only a reset will fix it.
-*/
- ret = ath5k_hw_dma_stop(ah);
-
- /* RF Bus grant won't work if we have pending
-* frames */
- if (ret && fast) {
- ATH5K_DBG(ah, ATH5K_DEBUG_RESET,
- "DMA didn't stop, falling back to normal reset\n");
- fast = false;
- /* Non fatal, just continue with
-* normal reset */
- ret =
[PATCH] mac80211_hwsim: fix beacon timers
From: Johannes Berg
Jouni reported that certain combinations of hwsim test cases failed,
and we found that beaconing was erroneously enabled too early on any
channel switch, which lead to the BI of 2000 TU from the first test
case to leak into the second one, which then didn't beacon properly.
To fix this, set data->beacon_int to zero when all stop beaconing so
that beaconing cannot be started (which was intended as 'restarted')
elsewhere.
Additionally, Jouni found that due to this 'restart' and the beacon
interval handling station interfaces would also have a needlessly
running beacon timer all the time, of course not doing anything.
To also fix the latter case only use the beacon interval when it's
actually needed, i.e. when beaconing gets enabled.
Reported-by: Jouni Malinen
Tested-by: Jouni Malinen
Signed-off-by: Johannes Berg
---
drivers/net/wireless/mac80211_hwsim.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 32bd2f02c164..941925991476 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -1595,21 +1595,16 @@ static void mac80211_hwsim_bss_info_changed(struct
ieee80211_hw *hw,
vp->aid = info->aid;
}
- if (changed & BSS_CHANGED_BEACON_INT) {
- wiphy_debug(hw->wiphy, " BCNINT: %d\n", info->beacon_int);
- data->beacon_int = info->beacon_int * 1024;
- }
-
if (changed & BSS_CHANGED_BEACON_ENABLED) {
- wiphy_debug(hw->wiphy, " BCN EN: %d\n", info->enable_beacon);
+ wiphy_debug(hw->wiphy, " BCN EN: %d (BI=%u)\n",
+ info->enable_beacon, info->beacon_int);
vp->bcn_en = info->enable_beacon;
if (data->started &&
!hrtimer_is_queued(&data->beacon_timer.timer) &&
info->enable_beacon) {
u64 tsf, until_tbtt;
u32 bcn_int;
- if (WARN_ON(!data->beacon_int))
- data->beacon_int = 1000 * 1024;
+ data->beacon_int = info->beacon_int * 1024;
tsf = mac80211_hwsim_get_tsf(hw, vif);
bcn_int = data->beacon_int;
until_tbtt = bcn_int - do_div(tsf, bcn_int);
@@ -1623,8 +1618,10 @@ static void mac80211_hwsim_bss_info_changed(struct
ieee80211_hw *hw,
mac80211_hwsim_bcn_en_iter, &count);
wiphy_debug(hw->wiphy, " beaconing vifs remaining: %u",
count);
- if (count == 0)
+ if (count == 0) {
tasklet_hrtimer_cancel(&data->beacon_timer);
+ data->beacon_int = 0;
+ }
}
}
--
2.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] bcma: Kconfig: Let it depend on PCI
bcma also needs PCI, just like IOMEM and DMA, so let it depend on PCI, or will cause building break for allmodconfig under c6x: CC [M] drivers/bcma/driver_pcie2.o drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up': drivers/bcma/driver_pcie2.c:196:8: error: implicit declaration of function 'pcie_set_readrq' [-Werror=implicit-function-declaration] err = pcie_set_readrq(dev, pcie2->reqsize); ^ Signed-off-by: Chen Gang --- drivers/bcma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig index 0ee48be..8be284e 100644 --- a/drivers/bcma/Kconfig +++ b/drivers/bcma/Kconfig @@ -1,6 +1,6 @@ config BCMA_POSSIBLE bool - depends on HAS_IOMEM && HAS_DMA + depends on HAS_IOMEM && HAS_DMA && PCI default y menu "Broadcom specific AMBA" -- 1.9.3 -- 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 v3] brcmfmac: avoid duplicated suspend/resume operation
On 03/02/15 16:08, Kalle Valo wrote: Arend van Spriel writes: Now that there is not 3.20 version. My understanding is that this patch will be in linus' tree 4.1-rc1, right? Yes. It will go into linux-next first, which you can consider to be an incubator where all stuff for the next release is integrated. Stuff will be added there until 4.0 is released. At that moment the merge window starts which moves all the stuff from linux-next into the mainline linux repo to prepare 4.1-rc1. Now regarding your patch I have to give a heads up. Our pending patches have been applied by Kalle and includes similar fix. Yeah, Zhonghui's patch doesn't apply anymore. There is similar code in wireless-drivers-next but still a bit different. So what should we do? Is the driver ok now? The idea of Zhonghui's patch was to avoid entering suspend and resume callbacks twice. The current behavior is same as his patch intended so yes the driver is ok (pending undiscovered bugs :-p ). Regards, Arend -- 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 net-next 13/14] wireless: Use eth__addr instead of memset
From: Joe Perches Date: Tue, 03 Mar 2015 11:03:17 -0800 > On Tue, 2015-03-03 at 13:57 -0500, David Miller wrote: >> From: Johannes Berg >> Date: Tue, 03 Mar 2015 09:16:57 +0100 >> >> > Other than that, I guess I'll apply this, but I really wish there was a >> > way to distinguish more easily which of these require alignment and >> > which don't. >> >> You can't apply "this" without the dependency patch #1. >> >> Therefore this should probably all go through my tree. > > Hey David. > > The eth__addr functions already exist so > 1/14 isn't a dependency. > > It's just a trivial improvement on existing code > with CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and > at least the arm 4.6.3 compiler. You're right. But I think we're skipping this series for now, see my other reply. If GCC can't emit as good an inline memset as we can come up with for 6 byte constant lengths, that's a GCC bug that should be fixed. -- 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 net-next 13/14] wireless: Use eth__addr instead of memset
On Tue, 2015-03-03 at 13:57 -0500, David Miller wrote: > From: Johannes Berg > Date: Tue, 03 Mar 2015 09:16:57 +0100 > > > Other than that, I guess I'll apply this, but I really wish there was a > > way to distinguish more easily which of these require alignment and > > which don't. > > You can't apply "this" without the dependency patch #1. Actually, this is the first time I see patch #1, but since it depends on HAVE_EFFICIENT_UNALIGNED_ACCESS it doesn't really matter, the functions already exist. I'm not even sure that the memset in patch #1 really gets more efficient with the u32/u16 write (and if it does, why doesn't the compiler know it) so I guess I'm not even sure I see much point in patch #1, but that doesn't really matter. Anyway, I don't mind if you want to take this directly either, just let me know. johannes -- 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 net-next 13/14] wireless: Use eth__addr instead of memset
On Tue, 2015-03-03 at 13:57 -0500, David Miller wrote: > From: Johannes Berg > Date: Tue, 03 Mar 2015 09:16:57 +0100 > > > Other than that, I guess I'll apply this, but I really wish there was a > > way to distinguish more easily which of these require alignment and > > which don't. > > You can't apply "this" without the dependency patch #1. > > Therefore this should probably all go through my tree. Hey David. The eth__addr functions already exist so 1/14 isn't a dependency. It's just a trivial improvement on existing code with CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and at least the arm 4.6.3 compiler. -- 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 net-next 13/14] wireless: Use eth__addr instead of memset
From: Johannes Berg Date: Tue, 03 Mar 2015 09:16:57 +0100 > Other than that, I guess I'll apply this, but I really wish there was a > way to distinguish more easily which of these require alignment and > which don't. You can't apply "this" without the dependency patch #1. Therefore this should probably all go through my tree. -- 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 2/2] ath10k: increase station kickout threshold
On 03/03/2015 04:20 AM, Rajkumar Manoharan wrote: Since the station kickout threshold is also counting software reries (Default sw count in firmware is 16), increasing the threshold to try with already 20 data frames before kicking out the station. Signed-off-by: Rajkumar Manoharan --- drivers/net/wireless/ath/ath10k/core.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index 7cba781..5a0b7cb 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -50,8 +50,8 @@ #define ATH10K_MAX_NUM_MGMT_PENDING 128 -/* number of failed packets */ -#define ATH10K_KICKOUT_THRESHOLD 50 +/* number of failed packets (includes sw reties) */ +#define ATH10K_KICKOUT_THRESHOLD (20 * 16) Maybe add comment about '20 packets with 16 retries each', so that users know what number is what? Thanks, Ben /* * Use insanely high numbers to make sure that the firmware implementation -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- 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
Google Summer of Code 2015 - We were not selected this year
Hi, unfortunately, the Linux Foundation was not selected as mentoring organization by Google this year. So we cannot run student projects funded by Google this year. Till -- 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: 8188e: possible recursive locking detected on linux-3.18.7
On 03/03/2015 02:22 AM, Brilliantov Kirill Vladimirovich wrote:
Hello!
I work with linux-3.18.7 on board with FreeScale iMX287 ARM CPU, for tests I use
USB TP-Link TL-WN725N on RTL8188e chip.
[7.802249] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[7.982221] Chip Version Info:
CHIP_8188E_Normal_Chip_TSMC_D_CUT_1T1R_RomVer(0)
ifconfig wlan0 up
[ 50.193673] MAC Address = e8:de:27:a3:ee:9d
iwlist wlan0 scan
[ 56.633485]
[ 56.635036] =
[ 56.640453] [ INFO: possible recursive locking detected ]
[ 56.645876] 3.18.7+ #40 Not tainted
[ 56.649379] -
[ 56.654794] RTW_CMD_THREAD/84 is trying to acquire lock:
[ 56.660118] (&(&(pqueue->lock))->rlock){+.-...}, at: []
_rtw_alloc_network+0x14/0xc4
[ 56.668948]
[ 56.668948] but task is already holding lock:
[ 56.674801] (&(&(pqueue->lock))->rlock){+.-...}, at: []
rtw_update_scanned_network+0x18/0x250
[ 56.684378]
[ 56.684378] other info that might help us debug this:
[ 56.690924] Possible unsafe locking scenario:
[ 56.690924]
[ 56.696858]CPU0
[ 56.699313]
[ 56.701766] lock(&(&(pqueue->lock))->rlock);
[ 56.706244] lock(&(&(pqueue->lock))->rlock);
[ 56.710721]
[ 56.710721] *** DEADLOCK ***
[ 56.710721]
[ 56.716662] May be due to missing lock nesting notation
[ 56.716662]
[ 56.723474] 2 locks held by RTW_CMD_THREAD/84:
[ 56.727927] #0: (&(&(pmlmepriv->lock))->rlock){+.}, at: []
rtw_survey_event_callback+0x7c/0x1c4
[ 56.738115] #1: (&(&(pqueue->lock))->rlock){+.-...}, at: []
rtw_update_scanned_network+0x18/0x250
[ 56.748125]
[ 56.748125] stack backtrace:
[ 56.752516] CPU: 0 PID: 84 Comm: RTW_CMD_THREAD Not tainted 3.18.7+ #40
[ 56.759198] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 56.767002] [] (show_stack) from []
(validate_chain+0xd14/0x1154)
[ 56.774878] [] (validate_chain) from []
(__lock_acquire+0x560/0xbb0)
[ 56.783011] [] (__lock_acquire) from []
(lock_acquire+0x64/0x78)
[ 56.790804] [] (lock_acquire) from []
(_raw_spin_lock_bh+0x44/0x58)
[ 56.798865] [] (_raw_spin_lock_bh) from []
(_rtw_alloc_network+0x14/0xc4)
[ 56.807442] [] (_rtw_alloc_network) from []
(rtw_update_scanned_network+0x98/0x250)
[ 56.816881] [] (rtw_update_scanned_network) from []
(rtw_survey_event_callback+0xf8/0x1c4)
[ 56.826922] [] (rtw_survey_event_callback) from []
(mlme_evt_hdl+0x5c/0xec)
[ 56.835658] [] (mlme_evt_hdl) from []
(rtw_cmd_thread+0x110/0x348)
[ 56.843623] [] (rtw_cmd_thread) from []
(kthread+0xb8/0xd4)
[ 56.850972] [] (kthread) from []
(ret_from_fork+0x14/0x34)
I get network list success.
This problem fixed in next linux versions?
Thank you and excuse me for my bad english.
There is no 8188e driver. Do you mean r8188eu, 8188eu, or rtl8188ee? I think you
mean one of the first two. Because your kernel is not tainted with "O", I think
you are using r8188eu, which is the in-kernel driver for the RTL8188EU chip.
That is a known bug in the driver; however, it is benign. I have worked at
clearing that recursive lock, only to run into another one. Unfortunately, I
have not found the time to complete an analysis of the locking.
Patches are welcome.
Larry
--
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
randconfig build error with next-20150303, in drivers/bcma/driver_pcie2.c
Building with the attached random configuration file, drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up': drivers/bcma/driver_pcie2.c:196:2: error: implicit declaration of function 'pcie_set_readrq' [-Werror=implicit-function-declaration] err = pcie_set_readrq(dev, pcie2->reqsize); ^ cc1: some warnings being treated as errors scripts/Makefile.build:258: recipe for target 'drivers/bcma/driver_pcie2.o' failed make[2]: *** [drivers/bcma/driver_pcie2.o] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.0.0-rc1 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_KTHREAD_PRIO=0 # CONFIG_RCU_EXPEDITE_BOOT is not set # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y # CONFIG_MEMCG_SWAP is not set CONFIG_MEMCG_KMEM=y CONFIG_CGROUP_HUGETLB=y # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set CONFIG_CHECKPOINT_RESTORE=y # CONFIG_NAMESPACES is not set CONFIG_SCHED_AUTOGROUP=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_LTO_MENU=y # CONFIG_LTO_DISABLE is not set CONFIG_LTO=y # CONFIG_LTO_DEBUG is not set CONFIG_LTO_CP_CLONE=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_MULTIUSER=y CONFIG_SGETMASK_SYSCALL=y # CONFIG_SYSFS_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set # CONFIG_BUG is not set # CONFIG_ELF_CORE is not set CONFIG_PCSPKR_PLATFORM=y # CONFIG_BASE_FULL is not set CO
Re: [PATCH][FIX][RESEND] b43: fix support for 5 GHz only BCM43228 model
Jonas Gorski writes: > On Tue, Mar 3, 2015 at 4:49 PM, Jonas Gorski wrote: >> If that's enough for you, feel free to add a Reviewed-By from me. > > Obviously you can't since you already applied it, so just add it in > your head ;-) Yeah, the train has left the station. But thanks for double checking, I can sleep safer now :) -- Kalle Valo -- 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][FIX][RESEND] b43: fix support for 5 GHz only BCM43228 model
On Tue, Mar 3, 2015 at 4:49 PM, Jonas Gorski wrote: > If that's enough for you, feel free to add a Reviewed-By from me. Obviously you can't since you already applied it, so just add it in your head ;-) Jonas -- 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][FIX][RESEND] b43: fix support for 5 GHz only BCM43228 model
On Tue, Mar 3, 2015 at 4:44 PM, Kalle Valo wrote: > Jonas Gorski writes: > >> On Tue, Mar 3, 2015 at 4:05 PM, Kalle Valo wrote: RESEND: It seems patchwork didn't catch my patch. Trying again. >>> >>> Odd, I still don't see it in patchwork. I wonder what caused that? >> >> I also see it neither in my b43-dev nor linux-wireless archives, nor >> does google find it (only your reply). > > Ok, that explains why patchwork didn't catch it (it scans patches from > the linux-wireless mailing list). I already applied the patch to > wireless-drivers.git but I would appreciate if people would still review > it: > > commit 0ff66cffde47de51c155ebdd2356403276c04cc4 > Author: Rafał Miłecki > Date: Mon Mar 2 17:18:55 2015 +0100 > > b43: fix support for 5 GHz only BCM43228 model > > It was incorrectly detected as 2 GHz device. > > Signed-off-by: Rafał Miłecki > Cc: sta...@vger.kernel.org # 3.17+ > Signed-off-by: Kalle Valo > > diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c > index ccbdb05b28cd..75345c1e8c34 100644 > --- a/drivers/net/wireless/b43/main.c > +++ b/drivers/net/wireless/b43/main.c > @@ -5370,6 +5370,7 @@ static void b43_supported_bands(struct b43_wldev *dev, > bool *have_2ghz_phy, > case 0x432a: /* BCM4321 */ > case 0x432d: /* BCM4322 */ > case 0x4352: /* BCM43222 */ > + case 0x435a: /* BCM43228 */ Broadcom agrees with that (taken from a broadcom sdk for bcm47xx): #define BCM43228_D11N_ID0x4359 /* 43228 802.11n DualBand device */ #define BCM43228_D11N5G_ID 0x435a /* 43228 802.11n 5GHz device */ If that's enough for you, feel free to add a Reviewed-By from me. Jonas -- 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][FIX][RESEND] b43: fix support for 5 GHz only BCM43228 model
Jonas Gorski writes: > On Tue, Mar 3, 2015 at 4:05 PM, Kalle Valo wrote: >>> RESEND: It seems patchwork didn't catch my patch. Trying again. >> >> Odd, I still don't see it in patchwork. I wonder what caused that? > > I also see it neither in my b43-dev nor linux-wireless archives, nor > does google find it (only your reply). Ok, that explains why patchwork didn't catch it (it scans patches from the linux-wireless mailing list). I already applied the patch to wireless-drivers.git but I would appreciate if people would still review it: commit 0ff66cffde47de51c155ebdd2356403276c04cc4 Author: Rafał Miłecki Date: Mon Mar 2 17:18:55 2015 +0100 b43: fix support for 5 GHz only BCM43228 model It was incorrectly detected as 2 GHz device. Signed-off-by: Rafał Miłecki Cc: sta...@vger.kernel.org # 3.17+ Signed-off-by: Kalle Valo diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c index ccbdb05b28cd..75345c1e8c34 100644 --- a/drivers/net/wireless/b43/main.c +++ b/drivers/net/wireless/b43/main.c @@ -5370,6 +5370,7 @@ static void b43_supported_bands(struct b43_wldev *dev, bool *have_2ghz_phy, case 0x432a: /* BCM4321 */ case 0x432d: /* BCM4322 */ case 0x4352: /* BCM43222 */ + case 0x435a: /* BCM43228 */ case 0x4333: /* BCM4331 */ case 0x43a2: /* BCM4360 */ case 0x43b3: /* BCM4352 */ -- Kalle Valo -- 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][FIX][RESEND] b43: fix support for 5 GHz only BCM43228 model
On Tue, Mar 3, 2015 at 4:05 PM, Kalle Valo wrote: >> RESEND: It seems patchwork didn't catch my patch. Trying again. > > Odd, I still don't see it in patchwork. I wonder what caused that? I also see it neither in my b43-dev nor linux-wireless archives, nor does google find it (only your reply). Jonas -- 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: rtlwifi: Improve handling of IPv6 packets
> Routine rtl_is_special_data() is supposed to identify packets that need to > use a low bit rate so that the probability of successful transmission is > high. The current version has a bug that causes all IPv6 packets to be > labelled as special, with a corresponding low rate of transmission. A > complete fix will be quite intrusive, but until that is available, all > IPv6 packets are identified as regular. > > This patch also removes a magic number. > > Reported-and-tested-by: Alan Fisher > Signed-off-by: Larry Finger > Cc: Stable [3.18+] > Cc: Alan Fisher Thanks, applied to wireless-drivers.git. Kalle Valo -- 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][FIX][RESEND] b43: fix support for 5 GHz only BCM43228 model
Rafał Miłecki writes: > It was incorrectly detected as 2 GHz device. > > Signed-off-by: Rafał Miłecki > Cc: sta...@vger.kernel.org # 3.17+ > --- > Kalle: can you take it for 3.20, please? Thanks, applied to wireless-drivers.git. > RESEND: It seems patchwork didn't catch my patch. Trying again. Odd, I still don't see it in patchwork. I wonder what caused that? -- Kalle Valo -- 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] ath9k_htc: avoid memcpy when downloading firmware
Fred Chou writes: >> Are you sure usb_control_msg() accepts vmalloc()ed buffers ? >> >> My guess is the answer is no. >> >> > > I agree, and I would like to drop the patch. Thanks. I dropped it from my queue. -- Kalle Valo -- 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] ath9k_htc: avoid memcpy when downloading firmware
On 3/3/2015 2:00 PM, Eric Dumazet wrote:
> On Tue, 2015-03-03 at 12:24 +0800, Fred Chou wrote:
>> From: Fred Chou
>>
>> The temporary buffer to hold firmware data is not really needed,
>> and memcpy can be avoided by using data pointer instead.
>>
>> Signed-off-by: Fred Chou
>> ---
>> drivers/net/wireless/ath/ath9k/hif_usb.c | 12 ++--
>> 1 file changed, 2 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
>> b/drivers/net/wireless/ath/ath9k/hif_usb.c
>> index 10c02f5..0bc35a8 100644
>> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
>> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
>> @@ -986,30 +986,22 @@ static int ath9k_hif_usb_download_fw(struct
>> hif_device_usb *hif_dev)
>> const void *data = hif_dev->fw_data;
>
> Here data can be vmalloc() backed.
>
>> size_t len = hif_dev->fw_size;
>> u32 addr = AR9271_FIRMWARE;
>> -u8 *buf = kzalloc(4096, GFP_KERNEL);
>
> Here buf is kmalloc() backed.
>
>> u32 firm_offset;
>>
>> -if (!buf)
>> -return -ENOMEM;
>> -
>> while (len) {
>> transfer = min_t(size_t, len, 4096);
>> -memcpy(buf, data, transfer);
>>
>> err = usb_control_msg(hif_dev->udev,
>>usb_sndctrlpipe(hif_dev->udev, 0),
>>FIRMWARE_DOWNLOAD, 0x40 | USB_DIR_OUT,
>> - addr >> 8, 0, buf, transfer, HZ);
>
>
> Are you sure usb_control_msg() accepts vmalloc()ed buffers ?
>
> My guess is the answer is no.
>
>
I agree, and I would like to drop the patch. Thanks.
--
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] bcma: gpio: enable GPIO IRQ domain on BCM5301X
Rafał Miłecki writes: > Just like on BCM47XX arch, BCM5301X also has ChipCommon with IRQ for > GPIOs. Now we have interrupts working on BCM5301X we can finally make > use of it. This has been successfully tested on 5 different devices > (Buffalo, Luxul, Netgear). > > Signed-off-by: Rafał Miłecki Thanks, applied to wireless-drivers-next.git. -- Kalle Valo -- 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] ssb: Silence warning for unknown backplane revision
Larry Finger writes: > When using a BCM4318 in a PCMCIA format, I get a startup message that the > device uses backplane revision 0xF00. Next a WARNING is logged. Despite > the message, the device works fine, This patch silences the warning. > > Cc: Rafał Miłecki > Signed-off-by: Larry Finger Thanks, applied to wireless-drivers-next.git. -- Kalle Valo -- 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: wil6210: increase cmd buffer size to avoid sscanf buffer overflow
> From: Colin Ian King > > cppcheck detected a buffer overflow: > > [drivers/net/wireless/ath/wil6210/debugfs.c:634]: (error) Width 8 > given in format string (no. 1) is larger than destination buffer > 'cmd[8]', use %7s to prevent overflowing it. > > For the current %8s sscanf we require cmd to be 9 chars long > so increase it by 1 byte to prevent the sscan overflow (rather > than reduce the %8s specifier to %7s as cppcheck recommends). > > Signed-off-by: Colin Ian King > Acked-by: Vladimir Kondratiev Thanks, applied to wireless-drivers-next.git. Kalle Valo -- 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: [1/6] ath9k: Remove useless return value check
> From: Sujith Manoharan > > ath_init_btcoex_timer() always returns 0, so > checking for error conditions is not required. > > Signed-off-by: Sujith Manoharan Thanks, 6 patches applied to wireless-drivers-next.git: 44b9b56e5095 ath9k: Remove useless return value check 510baea1e46d ath9k: Initialize MCI state correctly e1ff147d878a ath9k: Fix MCI scheme initialization 30b818989100 ath9k: Fix wlan-active gpio for the AR9003 family c7266e99b1b0 ath9k: Handle timers for MCI 6e6dd08dd320 ath9k: Fix issues in the main btcoex timer Kalle Valo -- 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: rtlwifi: rtl8192cu: Add case in rtl92cu_get_hw_reg
> Add HAL_DEF_WOWLAN case in rtl92cu_get_hw_reg > > Signed-off-by: Taehee Yoo > Acked-by: Larry Finger Thanks, applied to wireless-drivers-next.git. Kalle Valo -- 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: mwifiex: do not initialize ext_scan in mwifiex_init_adapter
> Features which are device specific are already updated in > interface specific initialization e.g. register_dev. > We should not initialize them in mwifiex_init_adapter(); > else this would overwrite earlier settings. > > Signed-off-by: Avinash Patil > Signed-off-by: Amitkumar Karwar Thanks, applied to wireless-drivers-next.git. Kalle Valo -- 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: rtlwifi: rtl8188ee: missing curly braces in handle_branch1()
> From the indenting, it seems like the READ_NEXT_PAIR() was supposed to > be inside the while loop. > > Signed-off-by: Dan Carpenter > Acked-by: Larry Finger Thanks, applied to wireless-drivers-next.git. Kalle Valo -- 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: rtlwifi: rtl8821ae: Remove duplicate hex prefixes
> The # flag in %X means print a 0X prefix. Remove the extra 0x prefix. > > Signed-off-by: Rasmus Villemoes Thanks, applied to wireless-drivers-next.git. Kalle Valo -- 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: [1/2] ath9k: add per-vif TX power capability
> Configure the HW with highest TX power among all vif when HW TPC has been > enabled in order to add support to per-vif TX power capability. Use lowest > configured power among all interfaces when TPC is disabled > > Signed-off-by: Lorenzo Bianconi Thanks, 2 patches applied to wireless-drivers-next.git: 283dd11994cd ath9k: add per-vif TX power capability 97bf861572ad ath9k: add per-vif TX power capability to TX path Kalle Valo -- 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: [v3,1/7] rtlwifi: Remove unused defines from rtl8192cu driver
> Signed-off-by: Priit Laes Thanks, 7 patches applied to wireless-drivers-next.git: b4926aff3ece rtlwifi: Remove unused defines from rtl8192cu driver 6e7c1baa973a rtlwifi: Remove unused defines from driver-specific def.h 6d4007fd6a4b rtlwifi: Remove unused RF6052_MAX_REG define 8a09dd2ed2bc rtlwifi: Remove unused defines from cam.h 44a56d6c81d3 rtlwifi: Remove unused defines from base.h baeeb3ca934d rtlwifi: Remove unused defines from efuse.h be1f8d31c93b rtlwifi: Remove unused RTL_SUPPORTED_CTRL_FILTER define Kalle Valo -- 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 next] bcma: add missing includes
Rafał Miłecki writes:
> On 3 March 2015 at 13:14, Kalle Valo wrote:
>> Rafał Miłecki writes:
>>
>>> Signed-off-by: Rafał Miłecki
>>
>> Please, no empty commit logs. I don't (yet) require that with all
>> patches, but this definitely needs one. Is this ok:
>>
>> bcma: add missing includes
>>
>> kbuild found out that commit 804e27dee49e ("bcma: support bringing up
>> bus hosted on PCIe Gen 2") broke the build on m68k:
>>
>>drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up':
drivers/bcma/driver_pcie2.c:196:2: error: implicit declaration of function
'pcie_set_readrq' [-Werror\
>> =implicit-function-declaration]
>> err = pcie_set_readrq(dev, pcie2->reqsize);
>> ^
>>cc1: some warnings being treated as errors
>>
>> Reported-by: kbuild test robot
>> Signed-off-by: Rafał Miłecki
>
> You're right, I could to better :| Yes, your version looks OK.
Thanks, I applied with my modifications.
--
Kalle Valo
--
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 next] bcma: add missing includes
On 3 March 2015 at 13:14, Kalle Valo wrote:
> Rafał Miłecki writes:
>
>> Signed-off-by: Rafał Miłecki
>
> Please, no empty commit logs. I don't (yet) require that with all
> patches, but this definitely needs one. Is this ok:
>
> bcma: add missing includes
>
> kbuild found out that commit 804e27dee49e ("bcma: support bringing up
> bus hosted on PCIe Gen 2") broke the build on m68k:
>
>drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up':
>>> drivers/bcma/driver_pcie2.c:196:2: error: implicit declaration of function
>>> 'pcie_set_readrq' [-Werror\
> =implicit-function-declaration]
> err = pcie_set_readrq(dev, pcie2->reqsize);
> ^
>cc1: some warnings being treated as errors
>
> Reported-by: kbuild test robot
> Signed-off-by: Rafał Miłecki
You're right, I could to better :| Yes, your version looks OK.
--
Rafał
--
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: [1/9] ath9k: Move MCI registers to reg_mci.h
> From: Sujith Manoharan > > Signed-off-by: Sujith Manoharan Thanks, 9 patches applied to wireless-drivers-next.git: ae55099f5b6f ath9k: Move MCI registers to reg_mci.h 7d1805e194dc ath9k: Remove useless check in MCI reset d1d07813bb3e ath9k: Add new MCI configuration parameters e18e164e9af5 ath9k: Handle 2-ANT AR9565 in MCI reset d808ecd8743c ath9k: Fix MCI TX control 4d9f7c68b78d ath9k: Setup MCI statistics properly bc80d526d302 ath9k: Prepare MCI interface correctly ad1dc638725d ath9k: Fix GPM initialization 2f890caba6dd ath9k: Mute BT properly Kalle Valo -- 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 3/4] mwifiex: remove_bss_prio_lock
Avinash Patil writes:
> From: Zhaoyang Liu
>
> This patch does away with spinlock in
> mwifiex_wmm_get_highest_priolist_ptr in order to improve TP.
>
> Signed-off-by: Zhaoyang Liu
> Signed-off-by: Shengzhen Li
> Signed-off-by: Cathy Luo
> Signed-off-by: Amitkumar Karwar
> Signed-off-by: Avinash Patil
[...]
> @@ -727,6 +730,25 @@ static int mwifiex_deinit_priv_params(struct
> mwifiex_private *priv)
> }
>
> mwifiex_deauthenticate(priv, NULL);
> +
> + spin_lock_irqsave(&adapter->main_proc_lock, flags);
> + adapter->main_locked = true;
> + if (adapter->mwifiex_processing) {
> + spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
> + flush_workqueue(adapter->workqueue);
> + } else {
> + spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
> + }
> +
> + spin_lock_irqsave(&adapter->rx_proc_lock, flags);
> + adapter->rx_locked = true;
> + if (adapter->rx_processing) {
> + spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
> + flush_workqueue(adapter->rx_workqueue);
> + } else {
> + spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
> + }
And here the horrible hack just grows to other functions.
--
Kalle Valo
--
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 1/4] mwifiex: avoid queue_work while work is ongoing
Avinash Patil writes:
> From: Marc Yang
>
> Current code does not check whether main_work_queue or
> rx_work_queue is running when preparing to do queue_work,
> this code fix add check before calling queue_work, reducing
> unnecessary queue_work switch.
>
> This change instead sets more_task flag to ensure we run main_process
> superloop once again.
>
> Signed-off-by: Marc Yang
> Signed-off-by: Zhaoyang Liu
> Signed-off-by: Shengzhen Li
> Signed-off-by: Cathy Luo
> Signed-off-by: Amitkumar Karwar
> Signed-off-by: Avinash Patil
Really, it took six persons to write this patch? Or do you just dump the
same names to each patch?
> +void mwifiex_queue_main_work(struct mwifiex_adapter *adapter)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&adapter->main_proc_lock, flags);
> + if (adapter->mwifiex_processing) {
> + adapter->more_task_flag = true;
> + spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
> + } else {
> + spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
> + queue_work(adapter->workqueue, &adapter->main_work);
> + }
> +}
> +EXPORT_SYMBOL_GPL(mwifiex_queue_main_work);
> +
> +static void mwifiex_queue_rx_work(struct mwifiex_adapter *adapter)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&adapter->rx_proc_lock, flags);
> + if (adapter->rx_processing) {
> + spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
> + } else {
> + spin_unlock_irqrestore(&adapter->rx_proc_lock, flags);
> + queue_work(adapter->rx_workqueue, &adapter->rx_work);
> + }
> +}
I can apply this patch, but to me this looks like a horrible hack.
--
Kalle Valo
--
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 trivial/resend 8/9] iwlegacy: 4965-rs: Remove bogus colon after newline from debug message
+ linux-wireless Geert Uytterhoeven writes: > Signed-off-by: Geert Uytterhoeven > Cc: Kalle Valo > --- > Resending trivial patches submitted in 2014. Thanks, applied to wireless-drivers-next.git. -- Kalle Valo -- 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
[RFC 2/2] mac80211: store low ack threshold in bss config
Store the low ack threshold configured by user in BSS config.
This will be used by driver for triggering low ack event whenever
the station is not ACKing the number of frames mentioned in
threshold.
Signed-off-by: Rajkumar Manoharan
---
include/net/mac80211.h | 3 +++
net/mac80211/cfg.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d52914b..ec769dd 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -383,6 +383,8 @@ enum ieee80211_rssi_event {
* userspace), whereas TPC is disabled if %txpower_type is set to
* NL80211_TX_POWER_FIXED (use value configured from userspace)
* @p2p_noa_attr: P2P NoA attribute for P2P powersave
+ * @low_ack_threshold: Number of consecutive packet loss to trigger low ack
+ * event by driver.
*/
struct ieee80211_bss_conf {
const u8 *bssid;
@@ -419,6 +421,7 @@ struct ieee80211_bss_conf {
int txpower;
enum nl80211_tx_power_setting txpower_type;
struct ieee80211_p2p_noa_attr p2p_noa_attr;
+ int low_ack_threshold;
};
/**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index dd4ff36..514d3ab 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -772,6 +772,7 @@ static int ieee80211_start_ap(struct wiphy *wiphy, struct
net_device *dev,
sdata->vif.bss_conf.beacon_int = params->beacon_interval;
sdata->vif.bss_conf.dtim_period = params->dtim_period;
sdata->vif.bss_conf.enable_beacon = true;
+ sdata->vif.bss_conf.low_ack_threshold = params->low_ack_threshold;
sdata->vif.bss_conf.ssid_len = params->ssid_len;
if (params->ssid_len)
--
2.3.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
[RFC 1/2] nl80211: Add support to configure low ack threshold
Add a new nl80211 attribute to configure low ack threshold (number of
consecutive frames) not being acked by station. This threshold is used
to kickout station by driver through low ack event. This allows user to
tune the parameter to improve robustness under noisy environment.
Signed-off-by: Rajkumar Manoharan
---
include/net/cfg80211.h | 3 +++
include/uapi/linux/nl80211.h | 8 +++-
net/wireless/nl80211.c | 6 ++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 64e09e1..29edb79 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -678,6 +678,8 @@ struct cfg80211_acl_data {
* @p2p_opp_ps: P2P opportunistic PS
* @acl: ACL configuration used by the drivers which has support for
* MAC address based access control
+ * @low_ack_threshold: number of consecutive frames not being ACKed by
+ * station, used to trigger low_ack event.
*/
struct cfg80211_ap_settings {
struct cfg80211_chan_def chandef;
@@ -696,6 +698,7 @@ struct cfg80211_ap_settings {
u8 p2p_ctwindow;
bool p2p_opp_ps;
const struct cfg80211_acl_data *acl;
+ int low_ack_threshold;
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 68b294e..40df4b1 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -219,7 +219,8 @@
* %NL80211_ATTR_CIPHER_GROUP, %NL80211_ATTR_WPA_VERSIONS,
* %NL80211_ATTR_AKM_SUITES, %NL80211_ATTR_PRIVACY,
* %NL80211_ATTR_AUTH_TYPE, %NL80211_ATTR_INACTIVITY_TIMEOUT,
- * %NL80211_ATTR_ACL_POLICY and %NL80211_ATTR_MAC_ADDRS.
+ * %NL80211_ATTR_ACL_POLICY and %NL80211_ATTR_MAC_ADDRS
+ * %NL80211_ATTR_LOW_ACK_THRESH.
* The channel to use can be set on the interface or be given using the
* %NL80211_ATTR_WIPHY_FREQ and the attributes determining channel width.
* @NL80211_CMD_NEW_BEACON: old alias for %NL80211_CMD_START_AP
@@ -1740,6 +1741,9 @@ enum nl80211_commands {
* @NL80211_ATTR_SCHED_SCAN_DELAY: delay before a scheduled scan (or a
* WoWLAN net-detect scan) is started, u32 in seconds.
*
+ * @NL80211_ATTR_LOW_ACK_THRESH: number of consecutive frames that are not
ACKed
+ * by station. This threshold is used to generate low ack event by driver.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2107,6 +2111,8 @@ enum nl80211_attrs {
NL80211_ATTR_SCHED_SCAN_DELAY,
+ NL80211_ATTR_LOW_ACK_THRESH,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e9ad9d9..80a90c7 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -399,6 +399,7 @@ static const struct nla_policy
nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_WIPHY_SELF_MANAGED_REG] = { .type = NLA_FLAG },
[NL80211_ATTR_NETNS_FD] = { .type = NLA_U32 },
[NL80211_ATTR_SCHED_SCAN_DELAY] = { .type = NLA_U32 },
+ [NL80211_ATTR_LOW_ACK_THRESH] = { .type = NLA_U16 },
};
/* policy for the key attributes */
@@ -3434,6 +3435,11 @@ static int nl80211_start_ap(struct sk_buff *skb, struct
genl_info *info)
params.smps_mode = NL80211_SMPS_OFF;
}
+ if (info->attrs[NL80211_ATTR_LOW_ACK_THRESH]) {
+ params.low_ack_threshold = nla_get_u16(
+ info->attrs[NL80211_ATTR_LOW_ACK_THRESH]);
+ }
+
wdev_lock(wdev);
err = rdev_start_ap(rdev, dev, ¶ms);
if (!err) {
--
2.3.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
[PATCH 1/2] ath10k: fix rts profile for second rate series
By default rts protection is enabled in firmware for the second rateset. Currently ath10k selects RTS profile (only for software retries), when legacy stations are associated or asked by mac80211. On congested environment, when AP is running in HT/VHT mode and there are no legacy clients associated, this will impact the robustness. Also enabling RTS protection only for second rateset will not impact performance on clear environment. Fix that. Signed-off-by: Rajkumar Manoharan --- drivers/net/wireless/ath/ath10k/mac.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 84a243e..37141b3 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -798,12 +798,14 @@ static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif) vdev_param = ar->wmi.vdev_param->enable_rtscts; - if (arvif->use_cts_prot || arvif->num_legacy_stations > 0) - rts_cts |= SM(WMI_RTSCTS_ENABLED, WMI_RTSCTS_SET); + rts_cts |= SM(WMI_RTSCTS_ENABLED, WMI_RTSCTS_SET); if (arvif->num_legacy_stations > 0) rts_cts |= SM(WMI_RTSCTS_ACROSS_SW_RETRIES, WMI_RTSCTS_PROFILE); + else + rts_cts |= SM(WMI_RTSCTS_FOR_SECOND_RATESERIES, + WMI_RTSCTS_PROFILE); return ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param, rts_cts); -- 2.3.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
[PATCH 2/2] ath10k: increase station kickout threshold
Since the station kickout threshold is also counting software reries (Default sw count in firmware is 16), increasing the threshold to try with already 20 data frames before kicking out the station. Signed-off-by: Rajkumar Manoharan --- drivers/net/wireless/ath/ath10k/core.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h index 7cba781..5a0b7cb 100644 --- a/drivers/net/wireless/ath/ath10k/core.h +++ b/drivers/net/wireless/ath/ath10k/core.h @@ -50,8 +50,8 @@ #define ATH10K_MAX_NUM_MGMT_PENDING 128 -/* number of failed packets */ -#define ATH10K_KICKOUT_THRESHOLD 50 +/* number of failed packets (includes sw reties) */ +#define ATH10K_KICKOUT_THRESHOLD (20 * 16) /* * Use insanely high numbers to make sure that the firmware implementation -- 2.3.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 next] bcma: add missing includes
Rafał Miłecki writes:
> Signed-off-by: Rafał Miłecki
Please, no empty commit logs. I don't (yet) require that with all
patches, but this definitely needs one. Is this ok:
bcma: add missing includes
kbuild found out that commit 804e27dee49e ("bcma: support bringing up
bus hosted on PCIe Gen 2") broke the build on m68k:
drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up':
>> drivers/bcma/driver_pcie2.c:196:2: error: implicit declaration of function
>> 'pcie_set_readrq' [-Werror\
=implicit-function-declaration]
err = pcie_set_readrq(dev, pcie2->reqsize);
^
cc1: some warnings being treated as errors
Reported-by: kbuild test robot
Signed-off-by: Rafał Miłecki
--
Kalle Valo
--
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: pull request: iwlwifi-next 2015-03-01
"Grumbach, Emmanuel" writes: > Hi Kalle, > > This is a pull request for 4.1. As usual the details are in the tag. > Please note that I have another set of 30-ish patch already after this > pull request. A dependency in mac80211 was solved, so I can now finally > send lots of work that has been made long ago. But that's for the next > pull request. > > I also have bits for 4.0 but that will wait since your tree isn't ready > yet for accepting patches for 4.0. > > Thanks and let me know if you have issues! > > > The following changes since commit f5af19d10d151c5a2afae3306578f485c244db25: > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-02-17 > 17:41:19 -0800) > > are available in the git repository at: > > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git > tags/iwlwifi-next-for-kalle-2015-03-01 Thanks, pulled. -- Kalle Valo -- 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 RFC 00/14] shrink skb cb to 44 bytes
David Miller wrote: > From: Eric Dumazet > Date: Mon, 02 Mar 2015 20:02:05 -0800 > > > About the GRO layout change, reason why 'struct sk_buff *last;' is at > > the end of struct napi_gro_cb is that this field is not used in fast > > path. > > Understood. Moved it back to end, thanks! > While reviewing this I noticed that the jiffies timestamp in GRO cb > could really be u32 if we want instead of full "unsigned long". Made it an u16 at the moment -- then __packed is no longer needed and it fits in 40 bytes. > > Note : We could try to use one bit in skb to advertise zero shinfo(skb). > > > > Many skbs have a zeroed shinfo() (but shinfo->dataref == 1) , and > > dereferencing skb_shinfo adds a cache line miss. > > > > -> We could avoid memset(shinfo, 0, offsetof(struct skb_shared_info, > > dataref)) & atomic_set(&shinfo->dataref, 1); > > > > in alloc_skb() and friends completely. > > > > Unfortunately this kind of change would be quite invasive... > > Right, all these kinds of things touch everything. Indeed, but thanks for the hint Eric -- I'll investigate. -- 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] mac80211: disable u-APSD queues by default
On Tue, Mar 3, 2015 at 3:58 PM, Michal Kazior wrote: > On 3 March 2015 at 11:15, Krishna Chaitanya wrote: >> On Tue, Mar 3, 2015 at 3:06 PM, Johannes Berg >> wrote: >>> >> Cisco 4410N originally forced us to enable VO by >> default only because it treated non-VO ACs as >> legacy. >>> Mixed mode (uapsd + legacy) is not really the optimal configuration, where we expect STA to send trigger frames periodically to retrieve the DL packets (especially very first packet). But still if we want power save, i suggest going for All u-apsd (0xF), so that AP will inform us by setting the TIM bit and we can retrieve the first frame. (We have this patch internally and it works well). >>> >>> Except where it doesn't work, like on the Cisco 4410N - see above. >> But for that single AP, we are forced to lose efficient power savings >> unless user configured explicitly. > > Correct me if I'm wrong, but u-APSD makes sense only if you have > userspace apps aware of it. I don't know any. VoIP traffic uses and it > works just because it generate bi-directional traffic in most cases so > you have implicit trigger frames generated when you Tx, but that's > probably as far as the practical use-case goes, no? You'd still need > netfilter rules to reclassify your traffic anyway, wouldn't you? If > you mainly wait for data you need to send trigger frames periodically > and only userspace app knows what Rx latency is tolerated (that's why > relying on driver/firmware auto-trigger generation doesn't cut it). Agree u-apsd is tightly coupled with the applications. But there is a provision in the protocol to deliver buffered frames without sending explicit triggers (which is quite waste of tx power). So it might be optimized for each application, but overall it will not break the functionality for those drivers who do not send explicit triggers frames periodically. Even for unidirectional protocol has a provison when All AC's are delivery enabled, it will still set the TIM bit, so using which we can start sending trigger frames. So either disabling/enabling u-apsd is fine aslong as we do it for all AC's together, mixed mode is useless. > > Anyway I don't think you can ask users to do the opposite (i.e. > disable u-APSD if they experience problems with APs). Wi-Fi should > Just Work. Joys of IOT.. May be in utopia ;-). -- Thanks, Regards, Chaitanya T K. -- 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 net-next 13/14] wireless: Use eth__addr instead of memset
On Tue, 2015-03-03 at 02:29 -0800, Joe Perches wrote: > Nope, you simply misunderstood what I did write. > > What I said was that the arguments were likely > already aligned(2), not that the alignment was > a requirement. Fair enough. That's not actually true/guaranteed though as far as this patch is concerned. johannes -- 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 net-next 13/14] wireless: Use eth__addr instead of memset
On Tue, 2015-03-03 at 10:00 +0100, Johannes Berg wrote: > On Tue, 2015-03-03 at 00:52 -0800, Joe Perches wrote: > > > > > My guess is the eth_zero_addr and eth_broadcast functions > > > > are always taking aligned(2) arguments, just like all the > > > > is__ether_addr functions. > > > > > > Err, are you serious??? > > > > Yes. > > > > > That *clearly* isn't true, and if it was then > > > this patch wouldn't be safe at all. > > > > And why is that? > > > > Until patch 1 of this series, eth_zero_addr and > > eth_broadcast_addr was just an inline for a memset. > > > > Even after patch 1, it's effectively still memset. > > Exactly. It therefore *doesn't* require an aligned(2) argument, unlike > what you stated above, hence my question if you're serious (and perhaps > looking at some other code that I don't have). Nope, you simply misunderstood what I did write. What I said was that the arguments were likely already aligned(2), not that the alignment was a requirement. -- 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] mac80211: disable u-APSD queues by default
On 3 March 2015 at 11:15, Krishna Chaitanya wrote: > On Tue, Mar 3, 2015 at 3:06 PM, Johannes Berg > wrote: >> >>> >> Cisco 4410N originally forced us to enable VO by >>> >> default only because it treated non-VO ACs as >>> >> legacy. >> >>> Mixed mode (uapsd + legacy) is not really the optimal >>> configuration, where we expect STA to send trigger frames periodically >>> to retrieve the DL packets (especially very first packet). >>> >>> But still if we want power save, i suggest going for >>> All u-apsd (0xF), so that AP will inform us by setting the TIM bit >>> and we can retrieve the first frame. >>> (We have this patch internally and it works well). >> >> Except where it doesn't work, like on the Cisco 4410N - see above. > But for that single AP, we are forced to lose efficient power savings > unless user configured explicitly. Correct me if I'm wrong, but u-APSD makes sense only if you have userspace apps aware of it. I don't know any. VoIP traffic uses and it works just because it generate bi-directional traffic in most cases so you have implicit trigger frames generated when you Tx, but that's probably as far as the practical use-case goes, no? You'd still need netfilter rules to reclassify your traffic anyway, wouldn't you? If you mainly wait for data you need to send trigger frames periodically and only userspace app knows what Rx latency is tolerated (that's why relying on driver/firmware auto-trigger generation doesn't cut it). Anyway I don't think you can ask users to do the opposite (i.e. disable u-APSD if they experience problems with APs). Wi-Fi should Just Work. Joys of IOT.. Michał -- 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] mac80211: disable u-APSD queues by default
On Tue, Mar 3, 2015 at 3:06 PM, Johannes Berg wrote: > >> >> Cisco 4410N originally forced us to enable VO by >> >> default only because it treated non-VO ACs as >> >> legacy. > >> Mixed mode (uapsd + legacy) is not really the optimal >> configuration, where we expect STA to send trigger frames periodically >> to retrieve the DL packets (especially very first packet). >> >> But still if we want power save, i suggest going for >> All u-apsd (0xF), so that AP will inform us by setting the TIM bit >> and we can retrieve the first frame. >> (We have this patch internally and it works well). > > Except where it doesn't work, like on the Cisco 4410N - see above. But for that single AP, we are forced to lose efficient power savings unless user configured explicitly. -- 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 v2 3/4] mac80211: initialize rate control earlier for tdls station
On Tue, Mar 3, 2015 at 12:06 PM, Johannes Berg wrote: > On Tue, 2015-03-03 at 12:02 +0200, Arik Nemtsov wrote: >> On Tue, Mar 3, 2015 at 11:18 AM, Johannes Berg >> wrote: >> > On Sun, 2015-03-01 at 10:21 +0200, Arik Nemtsov wrote: >> > >> >> > Arik, you have a similar patch handling only NSS. Does this one look >> >> > fine to you, and would it solve the problem your other patch solved? >> >> >> >> Well currently iwlmvm requires the NSS to be set before >> >> IEEE80211_STA_ASSOC (earlier), so this doesn't help directly. >> >> I could change mvm a bit to make it work, but I don't really see a >> >> good reason for it :) >> >> >> >> The patch looks good. Shouldn't introduce new issues (at least for >> >> iwlwifi). >> > >> > Ok, thanks. Do you think it would be possible to move all of this before >> > ASSOC? >> >> We can probably move his rate_control_rate_init() to assoc, since we have >> this: > > And doing so would also address the nss problem, right? IIRC that's done > in the rate control init inline. Right. Arik -- 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 v2 3/4] mac80211: initialize rate control earlier for tdls station
On Tue, 2015-03-03 at 12:02 +0200, Arik Nemtsov wrote: > On Tue, Mar 3, 2015 at 11:18 AM, Johannes Berg > wrote: > > On Sun, 2015-03-01 at 10:21 +0200, Arik Nemtsov wrote: > > > >> > Arik, you have a similar patch handling only NSS. Does this one look > >> > fine to you, and would it solve the problem your other patch solved? > >> > >> Well currently iwlmvm requires the NSS to be set before > >> IEEE80211_STA_ASSOC (earlier), so this doesn't help directly. > >> I could change mvm a bit to make it work, but I don't really see a > >> good reason for it :) > >> > >> The patch looks good. Shouldn't introduce new issues (at least for > >> iwlwifi). > > > > Ok, thanks. Do you think it would be possible to move all of this before > > ASSOC? > > We can probably move his rate_control_rate_init() to assoc, since we have > this: And doing so would also address the nss problem, right? IIRC that's done in the rate control init inline. johannes -- 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 v2 3/4] mac80211: initialize rate control earlier for tdls station
On Tue, Mar 3, 2015 at 11:18 AM, Johannes Berg
wrote:
> On Sun, 2015-03-01 at 10:21 +0200, Arik Nemtsov wrote:
>
>> > Arik, you have a similar patch handling only NSS. Does this one look
>> > fine to you, and would it solve the problem your other patch solved?
>>
>> Well currently iwlmvm requires the NSS to be set before
>> IEEE80211_STA_ASSOC (earlier), so this doesn't help directly.
>> I could change mvm a bit to make it work, but I don't really see a
>> good reason for it :)
>>
>> The patch looks good. Shouldn't introduce new issues (at least for iwlwifi).
>
> Ok, thanks. Do you think it would be possible to move all of this before
> ASSOC?
We can probably move his rate_control_rate_init() to assoc, since we have this:
/*
* TDLS -- everything follows authorized, but
* only becoming authorized is possible, not
* going back
*/
if (set & BIT(NL80211_STA_FLAG_AUTHORIZED)) {
set |= BIT(NL80211_STA_FLAG_AUTHENTICATED) |
BIT(NL80211_STA_FLAG_ASSOCIATED);
mask |= BIT(NL80211_STA_FLAG_AUTHENTICATED) |
BIT(NL80211_STA_FLAG_ASSOCIATED);
}
--
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 00/16] Various patches from our internal tree
On Tue, 2015-03-03 at 10:47 +0100, Johannes Berg wrote: > All applied, except for > > > Arik Nemtsov (4): > > mac80211: update TDLS sta spatial streams before auth > > this one where I'm trying to see if it can be combined with another > patch. And patch 15 broke the TI driver build, so I've dropped that. johannes -- 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 1/2] mesh_plink: use msecs_to_jiffies for proper time conversion
Both applied, thanks. johannes -- 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 v2] mac80211: send station PMF configuration to driver
On Mon, 2015-03-02 at 13:29 +0530, SenthilKumar Jegadeesan wrote: > Add support to provide station PMF configuration to driver. > > Some device drivers, offload part of aggregation including ADDBa/DELBa > negotiations to low layers. In such scenario, PMF configuration of > station needs to be provided to driver to enable encryption of > ADDBa/DELBa action frames. Applied, with some small changes. Why did you write ADDBa rather than AddBA? :) johannes -- 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 00/16] Various patches from our internal tree
All applied, except for > Arik Nemtsov (4): > mac80211: update TDLS sta spatial streams before auth this one where I'm trying to see if it can be combined with another patch. johannes -- 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] mac80211: disable u-APSD queues by default
> >> Cisco 4410N originally forced us to enable VO by > >> default only because it treated non-VO ACs as > >> legacy. > Mixed mode (uapsd + legacy) is not really the optimal > configuration, where we expect STA to send trigger frames periodically > to retrieve the DL packets (especially very first packet). > > But still if we want power save, i suggest going for > All u-apsd (0xF), so that AP will inform us by setting the TIM bit > and we can retrieve the first frame. > (We have this patch internally and it works well). Except where it doesn't work, like on the Cisco 4410N - see above. johannes -- 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] mac80211: disable u-APSD queues by default
On Tue, Mar 3, 2015 at 2:46 PM, Johannes Berg wrote: > On Tue, 2015-02-10 at 12:48 +0100, Michal Kazior wrote: >> Some APs experience problems when working with >> U-APSD. Decreasing the probability of that >> happening by using legacy mode for all ACs but VO >> isn't enough. >> >> Cisco 4410N originally forced us to enable VO by >> default only because it treated non-VO ACs as >> legacy. >> >> However some APs (notably Netgear R7000) silently >> reclassify packets to different ACs. Since u-APSD >> ACs require trigger frames for frame retrieval >> clients would never see some frames (e.g. ARP >> responses) or would fetch them accidentally after >> a long time. > > This makes me a little sad, but I've applied this and even added a Cc > stable tag due to the interoperability issues. > Mixed mode (uapsd + legacy) is not really the optimal configuration, where we expect STA to send trigger frames periodically to retrieve the DL packets (especially very first packet). But still if we want power save, i suggest going for All u-apsd (0xF), so that AP will inform us by setting the TIM bit and we can retrieve the first frame. (We have this patch internally and it works well). -- 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 v2 1/2] cfg80211: Allow NL80211_ATTR_IFINDEX to be added to vendor events
Both applied, thanks. I changed this code:
> + if (wdev) {
> + if (nla_put_u64(skb, NL80211_ATTR_WDEV,
> + wdev_id(wdev)))
> + goto nla_put_failure;
> + if (wdev->netdev) {
> + if (nla_put_u32(skb, NL80211_ATTR_IFINDEX,
> + wdev->netdev->ifindex))
> + goto nla_put_failure;
> + }
> + }
to just
+ if (wdev) {
+ if (nla_put_u64(skb, NL80211_ATTR_WDEV,
+ wdev_id(wdev)))
+ goto nla_put_failure;
+ if (wdev->netdev &&
+ nla_put_u32(skb, NL80211_ATTR_IFINDEX,
+ wdev->netdev->ifindex))
+ goto nla_put_failure;
+ }
though.
johannes
--
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 3/3] mac80211: add VHT support for IBSS
On Sat, 2015-02-21 at 16:52 +0100, Janusz Dziedzic wrote:
> @@ -1055,17 +1074,36 @@ static void ieee80211_rx_bss_info(struct
> ieee80211_sub_if_data *sdata,
>
> memcpy(&htcap_ie, elems->ht_cap_elem, sizeof(htcap_ie));
>
> - /*
> - * fall back to HT20 if we don't use or use
> - * the other extension channel
> - */
> - if (chandef.center_freq1 !=
> - sdata->u.ibss.chandef.center_freq1)
> - htcap_ie.cap_info &=
> -
> cpu_to_le16(~IEEE80211_HT_CAP_SUP_WIDTH_20_40);
> -
> rates_updated |= ieee80211_ht_cap_ie_to_sta_ht_cap(
> sdata, sband, &htcap_ie, sta);
> +
> + if (elems->vht_operation && elems->vht_cap_elem &&
> + width != NL80211_CHAN_WIDTH_20 &&
> + width != NL80211_CHAN_WIDTH_40) {
> + /* we both use VHT */
> + vht_cap = sta->sta.vht_cap;
> + vht_oper = elems->vht_operation;
> +
> + ieee80211_vht_oper_to_chandef(channel, vht_oper,
> + &chandef);
> + memcpy(&vhtcap_ie, elems->vht_cap_elem,
> +sizeof(vhtcap_ie));
> + ieee80211_vht_cap_ie_to_sta_vht_cap(sdata,
> + sband,
> + &vhtcap_ie,
> + sta);
> + if (memcmp(&vht_cap, &sta->sta.vht_cap,
> +sizeof(vht_cap)))
> + rates_updated |= true;
Some refactoring would be great, with expressions and argument lists
like this.
> + if (!
> cfg80211_chandef_compatible(&sdata->u.ibss.chandef,
> +&chandef))
> + /* TODO handle incompatible chandefs
> */
> + WARN_ON_ONCE(1);
That seems like an unaddressed TODO? I don't think you should warn on a
remote problem.
johannes
--
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 2/3] mac80211: IBSS fix scan request
On Sat, 2015-02-21 at 16:52 +0100, Janusz Dziedzic wrote:
> In case of wide bandwidth scan all channels we have
> in chandef, not only control one.
I think you should say why :)
> @@ -1381,11 +1450,18 @@ static void ieee80211_sta_find_ibss(struct
> ieee80211_sub_if_data *sdata)
> /* Selected IBSS not found in current scan results - try to
> scan */
> if (time_after(jiffies, ifibss->last_scan_completed +
> IEEE80211_SCAN_INTERVAL)) {
> + struct ieee80211_channel *channels[8];
> + unsigned int num = 0;
no need to initialize 'num' here.
johannes
--
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 1/3] cfg80211: add VHT support for IBSS
On Sat, 2015-02-21 at 16:52 +0100, Janusz Dziedzic wrote: > Add NL80211_EXT_FEATURE_VHT_IBSS flag and VHT > support for IBSS. Applied. johannes -- 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 v2 3/4] mac80211: initialize rate control earlier for tdls station
On Sun, 2015-03-01 at 10:21 +0200, Arik Nemtsov wrote: > > Arik, you have a similar patch handling only NSS. Does this one look > > fine to you, and would it solve the problem your other patch solved? > > Well currently iwlmvm requires the NSS to be set before > IEEE80211_STA_ASSOC (earlier), so this doesn't help directly. > I could change mvm a bit to make it work, but I don't really see a > good reason for it :) > > The patch looks good. Shouldn't introduce new issues (at least for iwlwifi). Ok, thanks. Do you think it would be possible to move all of this before ASSOC? (if not, why not, and how is it that we have valid NSS if we don't have the remaining data valid?) johannes -- 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 RFC 05/14] drivers: wireless: ar5523: use container_of
On 2015-03-02 18:40, Florian Westphal wrote: Compile tested only due to lack of hw. If we want to shrink skb->cb then we'd have to see about reducing struct ieee80211_tx_info, which gets embedded inside skb->cb[]. It provides a scratch space to be used by wireless drivers. ar5523 uses the maximum space available today (40 bytes), but it seems we don't need this -- data->skb pointer seems to always point back to the skb whose cb buffer the data structure resides, iow, given a pointer to the embedded control buffer we can infer the skb address. Cc: linux-wireless@vger.kernel.org Signed-off-by: Florian Westphal Tested-by: Pontus Fuchs -- 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] mac80211: disable u-APSD queues by default
On Tue, 2015-02-10 at 12:48 +0100, Michal Kazior wrote: > Some APs experience problems when working with > U-APSD. Decreasing the probability of that > happening by using legacy mode for all ACs but VO > isn't enough. > > Cisco 4410N originally forced us to enable VO by > default only because it treated non-VO ACs as > legacy. > > However some APs (notably Netgear R7000) silently > reclassify packets to different ACs. Since u-APSD > ACs require trigger frames for frame retrieval > clients would never see some frames (e.g. ARP > responses) or would fetch them accidentally after > a long time. This makes me a little sad, but I've applied this and even added a Cc stable tag due to the interoperability issues. johannes -- 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 v2 2/2] cfg80211: add support for connecting to PBSS network type
On Sun, 2015-02-08 at 15:52 +0200, Dedy Lansky wrote: > @@ -961,6 +961,12 @@ int cfg80211_connect(struct cfg80211_registered_device > *rdev, > memcpy(wdev->ssid, connect->ssid, connect->ssid_len); > wdev->ssid_len = connect->ssid_len; > > + wdev->conn_bss_type = IEEE80211_BSS_TYPE_ESS; > + if (connect->channel && > + connect->channel->band == IEEE80211_BAND_60GHZ && > + wdev->iftype == NL80211_IFTYPE_P2P_CLIENT) > + wdev->conn_bss_type = IEEE80211_BSS_TYPE_PBSS; This looks wrong, what if the driver did channel selection? Then all of this breaks. Perhaps it'd be better to punt this to drivers by introducing cfg80211_connect_result_bss() along with the existing cfg80211_roamed_bss(), so drivers can just look up and pass the correct BSS entry. johannes -- 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 v2 1/2] cfg80211: add bss_type and privacy arguments in cfg80211_get_bss()
On Sun, 2015-02-08 at 15:52 +0200, Dedy Lansky wrote: > Background: 802.11ad adds new network type (PBSS) and changes "capability" > field interpretation for the DMG (60G) band. > Same 2 bits that was interpreted as "ESS" and "IBSS", are re-used as > 2-bit field with 3 valid values (and 1 reserved). Valid values are: > "IBSS", "PBSS" (new) and "AP". > > New enum added into cfg80211.h - ieee80211_bss_type with valid network types. > When searching for particular network type in cfg80211_get_bss, > "capa_mask" and "capa_val" would not work due to difference described above. > Thus, need to decouple network type (bss_type) and handle it separately. > > Remaining bits in "capa_mask" and "capa_val" are used only for PRIVACY > matching > so replace those two with privacy enum. Applied, with minor changes. johannes -- 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 net-next 13/14] wireless: Use eth__addr instead of memset
On Tue, 2015-03-03 at 00:52 -0800, Joe Perches wrote: > > > My guess is the eth_zero_addr and eth_broadcast functions > > > are always taking aligned(2) arguments, just like all the > > > is__ether_addr functions. > > > > Err, are you serious??? > > Yes. > > > That *clearly* isn't true, and if it was then > > this patch wouldn't be safe at all. > > And why is that? > > Until patch 1 of this series, eth_zero_addr and > eth_broadcast_addr was just an inline for a memset. > > Even after patch 1, it's effectively still memset. Exactly. It therefore *doesn't* require an aligned(2) argument, unlike what you stated above, hence my question if you're serious (and perhaps looking at some other code that I don't have). My argument/complaint is that it isn't obvious from these which ones do require aligned(2) argument. Therefore, it's not obvious without going back to the definitions where the conversion is safe and where it isn't. Clearly, for example, memcmp() cannot always be replaced with ether_addr_equal(). johannes -- 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 net-next 13/14] wireless: Use eth__addr instead of memset
On Tue, 2015-03-03 at 09:44 +0100, Johannes Berg wrote: > > > Other than that, I guess I'll apply this, but I really wish there was a > > > way to distinguish more easily which of these require alignment and > > > which don't. > > > > My guess is the eth_zero_addr and eth_broadcast functions > > are always taking aligned(2) arguments, just like all the > > is__ether_addr functions. > > Err, are you serious??? Yes. > That *clearly* isn't true, and if it was then > this patch wouldn't be safe at all. And why is that? Until patch 1 of this series, eth_zero_addr and eth_broadcast_addr was just an inline for a memset. Even after patch 1, it's effectively still memset. -- 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 iw] phy: Allow set netns by fd
On Sat, 2015-02-14 at 09:33 +0200, Vadim Kochan wrote: > From: Vadim Kochan > > Added possibility to change network namespace > for phy device by network namespace name from > /var/run/netns or by absolute file path: > > iw phy XXX set netns name > > iw tries to open fd of given nsname from /var/run/netns > or by absoute path if nsname contains "/". Applied, thanks. johannes -- 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 net-next 13/14] wireless: Use eth__addr instead of memset
> > Other than that, I guess I'll apply this, but I really wish there was a > > way to distinguish more easily which of these require alignment and > > which don't. > > My guess is the eth_zero_addr and eth_broadcast functions > are always taking aligned(2) arguments, just like all the > is__ether_addr functions. Err, are you serious??? That *clearly* isn't true, and if it was then this patch wouldn't be safe at all. > > eth_zero_addr() doesn,t but is_zero_ether_addr() does. So does > > ether_addr_copy(). Frankly, it's getting a bit confusing, so I can't > > really fault anyone for using memset()/memcpy(). > > I suspect more than anything else all these are historic. I'd expect a mix here, certainly. Not all of them are really old though. johannes -- 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] iw: display allowable channel bandwidth information
On Mon, 2015-02-09 at 13:06 +0530, Ashok Raj Nagarajan wrote: > We already have allowable channel bandwidth information at userspace. > Display this information with 'iw list'. Excerpt of iw list command > > Frequencies: > * 5180 MHz [36] (17.0 dBm) (HT40+, VHT80, VHT160) I think I would prefer this to be printed on a separate line, like the radar information. There's also no-20 and no-10, which perhaps you should handle? johannes -- 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] iw: print human readable radar events
Applied. johannes -- 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 net-next 13/14] wireless: Use eth__addr instead of memset
On Tue, 2015-03-03 at 09:16 +0100, Johannes Berg wrote: > On Mon, 2015-03-02 at 19:54 -0800, Joe Perches wrote: > > Use the built-in function instead of memset. > > Please don't use in the title, especially not if the patch only > introduces usage of eth_zero_addr(). It's easier to look for in the > commit log without it. > > Other than that, I guess I'll apply this, but I really wish there was a > way to distinguish more easily which of these require alignment and > which don't. My guess is the eth_zero_addr and eth_broadcast functions are always taking aligned(2) arguments, just like all the is__ether_addr functions. > eth_zero_addr() doesn,t but is_zero_ether_addr() does. So does > ether_addr_copy(). Frankly, it's getting a bit confusing, so I can't > really fault anyone for using memset()/memcpy(). I suspect more than anything else all these are historic. -- 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] mac80211: drop unencrypted frames in mesh fwding
On Mon, 2015-03-02 at 14:28 -0500, Bob Copeland wrote: > The mesh forwarding path was not checking that data > frames were protected when running an encrypted network; > add the necessary check. Applied, thanks Bob. johannes -- 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
8188e: possible recursive locking detected on linux-3.18.7
Hello!
I work with linux-3.18.7 on board with FreeScale iMX287 ARM CPU, for
tests I use USB TP-Link TL-WN725N on RTL8188e chip.
[7.802249] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[7.982221] Chip Version Info:
CHIP_8188E_Normal_Chip_TSMC_D_CUT_1T1R_RomVer(0)
ifconfig wlan0 up
[ 50.193673] MAC Address = e8:de:27:a3:ee:9d
iwlist wlan0 scan
[ 56.633485]
[ 56.635036] =
[ 56.640453] [ INFO: possible recursive locking detected ]
[ 56.645876] 3.18.7+ #40 Not tainted
[ 56.649379] -
[ 56.654794] RTW_CMD_THREAD/84 is trying to acquire lock:
[ 56.660118] (&(&(pqueue->lock))->rlock){+.-...}, at: []
_rtw_alloc_network+0x14/0xc4
[ 56.668948]
[ 56.668948] but task is already holding lock:
[ 56.674801] (&(&(pqueue->lock))->rlock){+.-...}, at: []
rtw_update_scanned_network+0x18/0x250
[ 56.684378]
[ 56.684378] other info that might help us debug this:
[ 56.690924] Possible unsafe locking scenario:
[ 56.690924]
[ 56.696858]CPU0
[ 56.699313]
[ 56.701766] lock(&(&(pqueue->lock))->rlock);
[ 56.706244] lock(&(&(pqueue->lock))->rlock);
[ 56.710721]
[ 56.710721] *** DEADLOCK ***
[ 56.710721]
[ 56.716662] May be due to missing lock nesting notation
[ 56.716662]
[ 56.723474] 2 locks held by RTW_CMD_THREAD/84:
[ 56.727927] #0: (&(&(pmlmepriv->lock))->rlock){+.}, at:
[] rtw_survey_event_callback+0x7c/0x1c4
[ 56.738115] #1: (&(&(pqueue->lock))->rlock){+.-...}, at:
[] rtw_update_scanned_network+0x18/0x250
[ 56.748125]
[ 56.748125] stack backtrace:
[ 56.752516] CPU: 0 PID: 84 Comm: RTW_CMD_THREAD Not tainted 3.18.7+ #40
[ 56.759198] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 56.767002] [] (show_stack) from []
(validate_chain+0xd14/0x1154)
[ 56.774878] [] (validate_chain) from []
(__lock_acquire+0x560/0xbb0)
[ 56.783011] [] (__lock_acquire) from []
(lock_acquire+0x64/0x78)
[ 56.790804] [] (lock_acquire) from []
(_raw_spin_lock_bh+0x44/0x58)
[ 56.798865] [] (_raw_spin_lock_bh) from []
(_rtw_alloc_network+0x14/0xc4)
[ 56.807442] [] (_rtw_alloc_network) from []
(rtw_update_scanned_network+0x98/0x250)
[ 56.816881] [] (rtw_update_scanned_network) from
[] (rtw_survey_event_callback+0xf8/0x1c4)
[ 56.826922] [] (rtw_survey_event_callback) from
[] (mlme_evt_hdl+0x5c/0xec)
[ 56.835658] [] (mlme_evt_hdl) from []
(rtw_cmd_thread+0x110/0x348)
[ 56.843623] [] (rtw_cmd_thread) from []
(kthread+0xb8/0xd4)
[ 56.850972] [] (kthread) from []
(ret_from_fork+0x14/0x34)
I get network list success.
This problem fixed in next linux versions?
Thank you and excuse me for my bad english.
--
Best regards,
Brilliantov Kirill Vladimirovich
--
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 net-next 13/14] wireless: Use eth__addr instead of memset
On Mon, 2015-03-02 at 19:54 -0800, Joe Perches wrote: > Use the built-in function instead of memset. Please don't use in the title, especially not if the patch only introduces usage of eth_zero_addr(). It's easier to look for in the commit log without it. Other than that, I guess I'll apply this, but I really wish there was a way to distinguish more easily which of these require alignment and which don't. eth_zero_addr() doesn,t but is_zero_ether_addr() does. So does ether_addr_copy(). Frankly, it's getting a bit confusing, so I can't really fault anyone for using memset()/memcpy(). johannes -- 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
