* [PATCH 4/5] ath10k: set CTS protection VDEV param only if VDEV is up
From: Bartosz Markowski @ 2016-12-07 17:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
The cts protection vdev parameter, in new QCA9377 TF2.0 firmware,
requires bss peer to be created for the STATION vdev type.
bss peer is being allocated by the firmware after vdev_start/_up commands.
mac80211 may call the cts protection setup at any time, so the
we needs to track the situation and defer the cts configuration
to prevent firmware asserts, like below:
[00]: 0x05020001 0x000015B3 0x0099ACE2 0x00955B31
[04]: 0x0099ACE2 0x00060730 0x00000004 0x00000000
[08]: 0x0044C754 0x00412C10 0x00000000 0x00409C54
[12]: 0x00000009 0x00000000 0x00952F6C 0x00952F77
[16]: 0x00952CC4 0x00910712 0x00000000 0x00000000
[20]: 0x4099ACE2 0x0040E858 0x00421254 0x004127F4
[24]: 0x8099B9B2 0x0040E8B8 0x00000000 0xC099ACE2
[28]: 0x800B75CB 0x0040E8F8 0x00000007 0x00005008
[32]: 0x809B048A 0x0040E958 0x00000010 0x00433B10
[36]: 0x809AFBBC 0x0040E9A8 0x0042BB74 0x0042BBBC
[40]: 0x8091D252 0x0040E9C8 0x0042BBBC 0x00000001
[44]: 0x809FFA45 0x0040EA78 0x0043D3E4 0x0042C2C8
[48]: 0x809FCEF4 0x0040EA98 0x0043D3E4 0x00000001
[52]: 0x80911210 0x0040EAE8 0x00000010 0x004041D0
[56]: 0x80911154 0x0040EB28 0x00400000 0x00000000
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 51 +++++++++++++++++++++++++++++------
1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d06a12d548fd..6f1825964177 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1227,6 +1227,36 @@ static int ath10k_monitor_recalc(struct ath10k *ar)
return ath10k_monitor_stop(ar);
}
+static bool ath10k_mac_can_set_cts_prot(struct ath10k_vif *arvif)
+{
+ struct ath10k *ar = arvif->ar;
+
+ lockdep_assert_held(&ar->conf_mutex);
+
+ if (!arvif->is_started) {
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "defer cts setup, vdev is not ready yet\n");
+ return false;
+ }
+
+ return true;
+}
+
+static int ath10k_mac_set_cts_prot(struct ath10k_vif *arvif)
+{
+ struct ath10k *ar = arvif->ar;
+ u32 vdev_param;
+
+ lockdep_assert_held(&ar->conf_mutex);
+
+ vdev_param = ar->wmi.vdev_param->protection_mode;
+
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_protection %d\n",
+ arvif->vdev_id, arvif->use_cts_prot);
+
+ return ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
+ arvif->use_cts_prot ? 1 : 0);
+}
+
static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif)
{
struct ath10k *ar = arvif->ar;
@@ -5329,20 +5359,18 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_ERP_CTS_PROT) {
arvif->use_cts_prot = info->use_cts_prot;
- ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_prot %d\n",
- arvif->vdev_id, info->use_cts_prot);
ret = ath10k_recalc_rtscts_prot(arvif);
if (ret)
ath10k_warn(ar, "failed to recalculate rts/cts prot for vdev %d: %d\n",
arvif->vdev_id, ret);
- vdev_param = ar->wmi.vdev_param->protection_mode;
- ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
- info->use_cts_prot ? 1 : 0);
- if (ret)
- ath10k_warn(ar, "failed to set protection mode %d on vdev %i: %d\n",
- info->use_cts_prot, arvif->vdev_id, ret);
+ if (ath10k_mac_can_set_cts_prot(arvif)) {
+ ret = ath10k_mac_set_cts_prot(arvif);
+ if (ret)
+ ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n",
+ arvif->vdev_id, ret);
+ }
}
if (changed & BSS_CHANGED_ERP_SLOT) {
@@ -7365,6 +7393,13 @@ ath10k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
arvif->is_up = true;
}
+ if (ath10k_mac_can_set_cts_prot(arvif)) {
+ ret = ath10k_mac_set_cts_prot(arvif);
+ if (ret)
+ ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n",
+ arvif->vdev_id, ret);
+ }
+
mutex_unlock(&ar->conf_mutex);
return 0;
--
2.1.2
^ permalink raw reply related
* [PATCH 3/5] ath10k: decrease num of peers support
From: Bartosz Markowski @ 2016-12-07 17:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
The correct number for QCA9377 chip is 33 VDEVs.
This impacts also QCA6174 chip and it's max VDEV number.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/hw.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 883547f3347c..7feffec531cc 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -512,7 +512,7 @@ ath10k_rx_desc_get_l3_pad_bytes(struct ath10k_hw_params *hw,
/* Target specific defines for WMI-TLV firmware */
#define TARGET_TLV_NUM_VDEVS 4
#define TARGET_TLV_NUM_STATIONS 32
-#define TARGET_TLV_NUM_PEERS 35
+#define TARGET_TLV_NUM_PEERS 33
#define TARGET_TLV_NUM_TDLS_VDEVS 1
#define TARGET_TLV_NUM_TIDS ((TARGET_TLV_NUM_PEERS) * 2)
#define TARGET_TLV_NUM_MSDU_DESC (1024 + 32)
--
2.1.2
^ permalink raw reply related
* [PATCH 1/5] ath10k: fix IRAM banks number for QCA9377
From: Bartosz Markowski @ 2016-12-07 17:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
QCA9377 firmware shall alloc 4 IRAM banks
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 0457e315d336..983f65bbb7fb 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1973,7 +1973,7 @@ static int ath10k_pci_get_num_banks(struct ath10k *ar)
}
break;
case QCA9377_1_0_DEVICE_ID:
- return 2;
+ return 4;
}
ath10k_warn(ar, "unknown number of banks, assuming 1\n");
--
2.1.2
^ permalink raw reply related
* [PATCH 2/5] ath10k: override CE5 config for QCA9377
From: Bartosz Markowski @ 2016-12-07 17:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
Similarly to QCA6174, QCA9377 requires the CE5 configuration to be
available for other feature. Use the ath10k_pci_override_ce_config()
for it as well.
This is required for TF2.0 firmware. Previous FW revisions were
working fine without this patch.
Fixes: a70587b3389a ("ath10k: configure copy engine 5 for HTT messages")
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 983f65bbb7fb..85367006a80a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3132,7 +3132,7 @@ int ath10k_pci_setup_resource(struct ath10k *ar)
setup_timer(&ar_pci->rx_post_retry, ath10k_pci_rx_replenish_retry,
(unsigned long)ar);
- if (QCA_REV_6174(ar))
+ if (QCA_REV_6174(ar) || QCA_REV_9377(ar))
ath10k_pci_override_ce_config(ar);
ret = ath10k_pci_alloc_pipes(ar);
--
2.1.2
^ permalink raw reply related
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Larry Finger @ 2016-12-07 16:41 UTC (permalink / raw)
To: Dan Carpenter, Kalle Valo; +Cc: Greg KH, devel, Ping-Ke Shih, linux-wireless
In-Reply-To: <20161207133219.GM8176@mwanda>
On 12/07/2016 07:32 AM, Dan Carpenter wrote:
> On Wed, Dec 07, 2016 at 02:16:06PM +0200, Kalle Valo wrote:
>> We have disccused this before, but for wireless it's not really that
>> simple. AFAIK with dyndbg you can only control the messages per line
>> (painful to enable group of messages) or per file (enables too many
>> messages). In wireless we have cases when we need to enable group of
>> messages, but not all.
>
> You can turn them on by the function or a range of lines, then disable
> the spammy lines. With these new debug macros you can't do that so this
> is a step backwards.
>
> If I'm totally honest, I've never seen uglier macros than these. I work
> in staging and I've spent a lot of time in ancient code but these ones
> really take the cake.
They will be coming out. The Realtek engineer and I are learning more about the
various options to see what to use. The dynamic debugging options seem to be the
best at the moment.
Larry
^ permalink raw reply
* Re: [v3,3/3] mt76: add driver code for MT76x2e
From: Felix Fietkau @ 2016-12-07 14:13 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20161004164509.4DC5B61AF5@smtp.codeaurora.org>
On 2016-10-04 18:45, Kalle Valo wrote:
> Felix Fietkau <nbd@nbd.name> wrote:
>> From: Felix Fietkau <nbd@openwrt.org>
>>
>> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>
> I already asked this in v2, but what about firmware images? Will they be
> available from linux-firmware.git?
Seems that I forgot to submit it to linux-firmware@. I already had
permission from MediaTek to do so, so I just took sent it out.
- Felix
^ permalink raw reply
* Re: [v3,3/3] mt76: add driver code for MT76x2e
From: Felix Fietkau @ 2016-12-07 14:11 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20161004163457.08D6861A06@smtp.codeaurora.org>
On 2016-10-04 18:34, Kalle Valo wrote:
> Felix Fietkau <nbd@nbd.name> wrote:
>> From: Felix Fietkau <nbd@openwrt.org>
>>
>> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>
> A summary of what feature work would be nice to have. Also if there's something
> notable which is not working it's good also to mention that.
>
> I don't know why I didn't see this earlier but this fails to build for me:
>
> ERROR: "mtd_read" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
> ERROR: "put_mtd_device" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
> ERROR: "get_mtd_device_nm" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
>
> Dependency to mtd missing?
Will fix the #ifdef in v4.
- Felix
^ permalink raw reply
* Re: [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/
From: David Howells @ 2016-12-07 13:45 UTC (permalink / raw)
To: Kalle Valo
Cc: dhowells, linux-kernel, gnomes, minyard, netdev, linux-wireless,
linux-security-module, keyrings
In-Reply-To: <8737i6syzq.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> wrote:
> Via which tree are you planning to submit this, should I take it to
> wireless-drivers or will someone else handle it? I didn't get the cover
> letter so I have no idea.
I'll see if I can get patch 1 (which defines the macros) in a window prior to
the others - or maybe I can get Linus to apply all of these together.
David
^ permalink raw reply
* Re: [PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization
From: Bob Copeland @ 2016-12-07 13:33 UTC (permalink / raw)
To: Masashi Honma; +Cc: Johannes Berg, Thomas Pedersen, linux-wireless
In-Reply-To: <9197b711-3d48-071a-57d8-53e2a11c26de@gmail.com>
On Wed, Dec 07, 2016 at 09:55:41PM +0900, Masashi Honma wrote:
> >It's called mesh_sync_offset_adjust_tbtt() which matches more closely
> >"TBTT adjustment" than "neighbor offset synchronization"?
>
> I think so. Because there is not any code creating "TBTT Adjustment Request
> frame" even though the frame is required by "TBTT adjustment".
This mesh_sync_offset_adjust_tbtt is definitely doing offset
synchronization, so probably "tbtt" should be renamed "tsf" here.
> >The code
> >looks more like offset synchronization though. Perhaps there's some
> >confusing and it's kinda doing both?
>
> In theory, updating the flag with 1) looks not correct because it is not
> clearly defined in spec.
>
> In practice, I could consider extending the meaning of the flag over the
> spec to use it to avoid referring the updating TSF value by peer as Thomas
> said. I have took the statistics how many TSF drift
> (ifmsh->sync_offset_clockdrift_max) happens. The attached file shows the
> stats. The horizontal axis shows TSF drift time(usec) and vertical axis
> shows how many time the drift occurred. The graph shows almost drifts are
> under 20usec. In contrast, 2) could causes more than 1000usec drift. So 1)
> looks not so large enough to protect with the flag.
Yes, offset synchronization is (given decent clocks) supposed to be only
for small tweaks. We will do it up to .8 ms drift though -- above .8 ms, we
just reset drift to zero and adopt the new timing offset. You can see this
kind of large "drift" by restarting a station.
Actually, looking at the code now it doesn't make a lot of sense to set
this flag for offset sync because TOFFSET_KNOWN flag is completely cleared
whenever that is set, so we have to be forgetting the current t_offset all
the time?
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Dan Carpenter @ 2016-12-07 13:32 UTC (permalink / raw)
To: Kalle Valo; +Cc: Greg KH, devel, Ping-Ke Shih, linux-wireless, Larry Finger
In-Reply-To: <871sxkdjeh.fsf@kamboji.qca.qualcomm.com>
On Wed, Dec 07, 2016 at 02:16:06PM +0200, Kalle Valo wrote:
> We have disccused this before, but for wireless it's not really that
> simple. AFAIK with dyndbg you can only control the messages per line
> (painful to enable group of messages) or per file (enables too many
> messages). In wireless we have cases when we need to enable group of
> messages, but not all.
You can turn them on by the function or a range of lines, then disable
the spammy lines. With these new debug macros you can't do that so this
is a step backwards.
If I'm totally honest, I've never seen uglier macros than these. I work
in staging and I've spent a lot of time in ancient code but these ones
really take the cake.
regards,
dan carpenter
^ permalink raw reply
* [patch] adm80211: return an error if adm8211_alloc_rings() fails
From: Dan Carpenter @ 2016-12-07 11:21 UTC (permalink / raw)
To: Kalle Valo, Michael Wu
Cc: Alexey Khoroshilov, Johannes Berg, linux-wireless,
kernel-janitors
We accidentally return success when adm8211_alloc_rings() fails but we
should preserve the error code.
Fixes: cc0b88cf5ecf ("[PATCH] Add adm8211 802.11b wireless driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/wireless/admtek/adm8211.c b/drivers/net/wireless/admtek/adm8211.c
index 2b4a3eb38dfa..098c814e22c8 100644
--- a/drivers/net/wireless/admtek/adm8211.c
+++ b/drivers/net/wireless/admtek/adm8211.c
@@ -1863,7 +1863,8 @@ static int adm8211_probe(struct pci_dev *pdev,
priv->rx_ring_size = rx_ring_size;
priv->tx_ring_size = tx_ring_size;
- if (adm8211_alloc_rings(dev)) {
+ err = adm8211_alloc_rings(dev);
+ if (err) {
printk(KERN_ERR "%s (adm8211): Cannot allocate TX/RX ring\n",
pci_name(pdev));
goto err_iounmap;
^ permalink raw reply related
* Re: [PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization
From: Masashi Honma @ 2016-12-07 12:55 UTC (permalink / raw)
To: Johannes Berg, Thomas Pedersen; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <1481102652.4092.33.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
On 2016年12月07日 18:24, Johannes Berg wrote:
>>> And the flag is refered by 1) as you said.
>>>
>>>
>>> The purpose of the flag is to prevent 1) while 2) is ongoing.
>>>
>>> In other words, 1) has only read access authority to the flag.
>>> However,
>>> previous code updated the flag in 1). In addition, there is no code
>>> for
>>> 2). So I just remove the invalid accessing codes.
>>
>> I don't think 1) has read only access to that flag. A TSF adjust will
>> by definition move the TBTT as well.
>
> It seems that the wording in the spec disagrees with that - it says
> (twice) to set the bit only while the TBTT adjustment procedure is
> ongoing, which isn't the case here?
>
> Then again, what exactly *is* this code doing?
>
> It's called mesh_sync_offset_adjust_tbtt() which matches more closely
> "TBTT adjustment" than "neighbor offset synchronization"?
I think so. Because there is not any code creating "TBTT Adjustment
Request frame" even though the frame is required by "TBTT adjustment".
> The code
> looks more like offset synchronization though. Perhaps there's some
> confusing and it's kinda doing both?
In theory, updating the flag with 1) looks not correct because it is not
clearly defined in spec.
In practice, I could consider extending the meaning of the flag over the
spec to use it to avoid referring the updating TSF value by peer as
Thomas said. I have took the statistics how many TSF drift
(ifmsh->sync_offset_clockdrift_max) happens. The attached file shows the
stats. The horizontal axis shows TSF drift time(usec) and vertical axis
shows how many time the drift occurred. The graph shows almost drifts
are under 20usec. In contrast, 2) could causes more than 1000usec drift.
So 1) looks not so large enough to protect with the flag.
Masashi Honma.
[-- Attachment #2: clockdrift.png --]
[-- Type: image/png, Size: 7951 bytes --]
^ permalink raw reply
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Kalle Valo @ 2016-12-07 12:16 UTC (permalink / raw)
To: Greg KH; +Cc: Larry Finger, Dan Carpenter, devel, Ping-Ke Shih, linux-wireless
In-Reply-To: <20161206071340.GB10292@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Mon, Dec 05, 2016 at 04:34:08PM -0600, Larry Finger wrote:
>> On 12/05/2016 03:34 PM, Dan Carpenter wrote:
>> > On Thu, Dec 01, 2016 at 07:48:29PM -0600, Larry Finger wrote:
>> > > --- wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
>> > > +++ wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
>> > > @@ -27,6 +27,29 @@
>> > >
>> > > #include "../wifi.h"
>> > >
>> > > +#ifdef CONFIG_RTLWIFI_DEBUG
>> > > +
>> > > +#define BTC_SPRINTF(ptr, ...) snprintf(ptr, ##__VA_ARGS__)
>> > > +#define BTC_TRACE(fmt) \
>> > > +do { \
>> > > + struct rtl_priv *rtlpriv = gl_bt_coexist.adapter; \
>> > > + if (!rtlpriv) \
>> > > + break; \
>> > > + RT_TRACE_STRING(rtlpriv, COMP_COEX, DBG_LOUD, fmt); \
>> > > +} while (0)
>> > > +
>> >
>> > This sort of macro is exactly when the rtl drivers spent so long in
>> > staging... Subsystems should not invent their own tracing but in
>> > particular these macros are so very very ugly.
>> >
>> > It's just super frustrating to even look at this...
>> >
>> > There are a lot of staging drivers I feel good about when they leave.
>> > The HyperV drivers. The IIO stuff. A lot of the media stuff and
>> > generally the media tree is getting better and better. I like comedi
>> > and unisys, those are in staging, but they are great and could move out
>> > any time as far as I'm concerned.
>> >
>> > But this patch just makes me super discouraged. What are we doing???
>>
>> Dan,
>>
>> It would not matter to me if these drivers got moved to staging, but there
>> are a lot of users whose distros do not build staging drivers that would be
>> very unhappy.
>>
>> Can you point me to a driver with a better way to conditionally dump a
>> debugging string to the logs?
>
> Just use 'dev_dbg()', or 'pr_debug()' if you don't have a device pointer
> (hint, all drivers should have that pointer). That can be turned on or
> off by a user dynamically as the kernel runs. No need to invent fancy
> custom macros for things we have already for many many years.
We have disccused this before, but for wireless it's not really that
simple. AFAIK with dyndbg you can only control the messages per line
(painful to enable group of messages) or per file (enables too many
messages). In wireless we have cases when we need to enable group of
messages, but not all. For example, some of the messages can slow down
the system so much that the bug is not reproducable anymore. So unless
dyndbg gets some sort of grouping support logging wrappers are needed
with wireless code.
(I'm talking in general here, I haven't looked at rtlwifi patches in
detail yet.)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/1] net: wireless: intersil: fix improper return value
From: Kalle Valo @ 2016-12-07 12:00 UTC (permalink / raw)
To: Pan Bian; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1480760572-4444-1-git-send-email-bianpan2016@163.com>
Pan Bian <bianpan2016@163.com> writes:
> Function orinoco_ioctl_commit() returns 0 (indicates success) when the
> call to orinoco_lock() fails. Thus, the return value is inconsistent with
> the execution status. It may be better to return "-EBUSY" when the call
> to orinoco_lock() fails.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188671
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> ---
> drivers/net/wireless/intersil/orinoco/wext.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Please use prefix "orinoco:", more info:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject_name
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] iwlegacy: make il3945_mac_ops __ro_after_init
From: Stanislaw Gruszka @ 2016-12-07 10:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20161207063646.30969-1-johannes@sipsolutions.net>
On Wed, Dec 07, 2016 at 07:36:46AM +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> There's no need for this to be only __read_mostly, since
> it's only written in a single way depending on the module
> parameter, so that can be moved into the module's __init
> function, and the ops can be __ro_after_init.
>
> This is a little bit safer since it means the ops can't
> be overwritten (accidentally or otherwise), which would
> otherwise cause an arbitrary function or bad pointer to
> be called.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [PATCH 1/4] cfg80211: Add support to enable or disable btcoex
From: Tamizh chelvam @ 2016-12-07 11:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: c_traja, linux-wireless, ath10k
In-Reply-To: <1480949161.31788.23.camel@sipsolutions.net>
Hi Johannes,
Thanks for the comments.
On 2016-12-05 20:16, Johannes Berg wrote:
> On Tue, 2016-11-08 at 18:45 +0530, c_traja@qti.qualcomm.com wrote:
>> From: Tamizh chelvam <c_traja@qti.qualcomm.com>
>>
>> This patch adds support to enable or disable btcoex by
>> adding NL80211_ATTR_WIPHY_BTCOEX_ENABLE attribute in
>> NL80211_CMD_SET_WIPHY command. By default BTCOEX disabled in driver.
>
> I think overloading SET_WIPHY even more is a mistake - why not group
> this with the new command you're introducing in the second patch?
>
Sure.
> Also, can have a flag attribute to enable/disable, or better even
> disable when you're not setting any other parameters.
BTCOEX will be disabled by default. I will use
NL80211_ATTR_WIPHY_BTCOEX_ENABLE
attribute to enable/disable BTCOEX.
^ permalink raw reply
* RE: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
From: Amitkumar Karwar @ 2016-12-07 10:52 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, briannorris@google.com,
dmitry.torokhov@gmail.com, Xinming Hu
In-Reply-To: <20161205110906.28C706034F@smtp.codeaurora.org>
SGkgS2FsbGUsDQoNCj4gRnJvbTogbGludXgtd2lyZWxlc3Mtb3duZXJAdmdlci5rZXJuZWwub3Jn
IFttYWlsdG86bGludXgtd2lyZWxlc3MtDQo+IG93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVo
YWxmIE9mIEthbGxlIFZhbG8NCj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAwNSwgMjAxNiA0OjM5
IFBNDQo+IFRvOiBBbWl0a3VtYXIgS2Fyd2FyDQo+IENjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtl
cm5lbC5vcmc7IENhdGh5IEx1bzsgTmlzaGFudCBTYXJtdWthZGFtOw0KPiByYWphdGphQGdvb2ds
ZS5jb207IGJyaWFubm9ycmlzQGdvb2dsZS5jb207IGRtaXRyeS50b3Jva2hvdkBnbWFpbC5jb207
DQo+IFhpbm1pbmcgSHU7IEFtaXRrdW1hciBLYXJ3YXINCj4gU3ViamVjdDogUmU6IFsxLzJdIG13
aWZpZXg6IGNvZGUgcmVhcnJhbmdlbWVudCBpbiBwY2llLmMgYW5kIHNkaW8uYw0KPiANCj4gQW1p
dGt1bWFyIEthcndhciA8YWthcndhckBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+ID4gRnJvbTogWGlu
bWluZyBIdSA8aHV4bUBtYXJ2ZWxsLmNvbT4NCj4gPg0KPiA+IE5leHQgcGF0Y2ggaW4gdGhpcyBz
ZXJpZXMgaXMgZ29pbmcgdG8gdXNlIG13aWZpZXhfcmVhZF9yZWcoKSBpbg0KPiByZW1vdmUNCj4g
PiBoYW5kbGVycy4gVGhlIGNoYW5nZXMgaGVyZSBhcmUgcHJlcmVxdWlzaXRlcyB0byBhdm9pZCBm
b3J3YXJkDQo+ID4gZGVjbGFyYXRpb25zLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogWGlubWlu
ZyBIdSA8aHV4bUBtYXJ2ZWxsLmNvbT4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBBbWl0a3VtYXIgS2Fy
d2FyIDxha2Fyd2FyQG1hcnZlbGwuY29tPg0KPiANCj4gRmFpbGVkIHRvIGFwcGx5Og0KPiANCj4g
ZmF0YWw6IHNoYTEgaW5mb3JtYXRpb24gaXMgbGFja2luZyBvciB1c2VsZXNzDQo+IChkcml2ZXJz
L25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvcGNpZS5jKS4NCj4gQXBwbHlpbmc6IG13aWZp
ZXg6IGdldCByaWQgb2YgZ2xvYmFsIHVzZXJfcm1tb2QgZmxhZyBSZXBvc2l0b3J5IGxhY2tzDQo+
IG5lY2Vzc2FyeSBibG9icyB0byBmYWxsIGJhY2sgb24gMy13YXkgbWVyZ2UuDQo+IENhbm5vdCBm
YWxsIGJhY2sgdG8gdGhyZWUtd2F5IG1lcmdlLg0KPiBQYXRjaCBmYWlsZWQgYXQgMDAwMSBtd2lm
aWV4OiBnZXQgcmlkIG9mIGdsb2JhbCB1c2VyX3JtbW9kIGZsYWcNCj4gDQo+IDIgcGF0Y2hlcyBz
ZXQgdG8gQ2hhbmdlcyBSZXF1ZXN0ZWQuDQo+IA0KPiA5NDU0NDkxIFsxLzJdIG13aWZpZXg6IGNv
ZGUgcmVhcnJhbmdlbWVudCBpbiBwY2llLmMgYW5kIHNkaW8uYw0KPiA5NDU0NDkzIFsyLzJdIG13
aWZpZXg6IGdldCByaWQgb2YgZ2xvYmFsIHVzZXJfcm1tb2QgZmxhZw0KPiANCj4gLS0NCj4gaHR0
cHM6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wYXRjaC85NDU0NDkxLw0KPiANCj4gRG9jdW1lbnRh
dGlvbiBhYm91dCBzdWJtaXR0aW5nIHdpcmVsZXNzIHBhdGNoZXMgYW5kIGNoZWNraW5nIHN0YXR1
cw0KPiBmcm9tIHBhdGNod29yazoNCj4gDQo+IGh0dHBzOi8vd2lyZWxlc3Mud2lraS5rZXJuZWwu
b3JnL2VuL2RldmVsb3BlcnMvZG9jdW1lbnRhdGlvbi9zdWJtaXR0aW5nDQo+IHBhdGNoZXMNCg0K
DQpUaGVzZSB0d28gcGF0Y2hlcyBoYXZlIGRlcGVuZGVuY3kgd2l0aCBvdGhlciBwYXRjaCBzZXJp
ZXMuIEkgd2FudCB5b3UgdG8gY29uc2lkZXIgcGF0Y2hlcyBpbiBmb2xsb3dpbmcgb3JkZXIoZmly
c3QgYmVpbmcgcmVjZW50KS4NCg0KbXdpZmlleDogc2RpbzogZml4IHVzZSBhZnRlciBmcmVlIGlz
c3VlIGZvciBzYXZlX2FkYXB0ZXINCm13aWZpZXg6IHVzZSBtb2R1bGVfKl9kcml2ZXIgaGVscGVy
IG1hY3Jvcw0KDQpbMi8yXSBtd2lmaWV4OiBnZXQgcmlkIG9mIGdsb2JhbCB1c2VyX3JtbW9kIGZs
YWcNClsxLzJdIG13aWZpZXg6IGNvZGUgcmVhcnJhbmdlbWVudCBpbiBwY2llLmMgYW5kIHNkaW8u
Yw0KDQpbdjMsNS81XSBtd2lmaWV4OiBtb3ZlIHBjaWVfd29yayBhbmQgcmVsYXRlZCB2YXJpYWJs
ZXMgaW5zaWRlIGNhcmQgLS0tLS0tLS0gVGhpcyBzZXJpZXMgY2FuIGJlIGFjY2VwdGVkIGlmIHRo
ZXJlIGFyZSBubyBmdXJ0aGVyIGNvbmNlcm5zL2NvbW1lbnRzIGZyb20gQnJpYW4vRG1pdHJ5LiAN
Clt2Myw0LzVdIG13aWZpZXg6IHdhaXQgZmlybXdhcmUgZHVtcCBjb21wbGV0ZSBkdXJpbmcgY2Fy
ZCByZW1vdmUgcHJvY2Vzcw0KW3YzLDMvNV0gbXdpZmlleDogZ2V0IHJpZCBvZiBkcnZfaW5mbyog
YWRhcHRlciB2YXJpYWJsZXMNClt2MywyLzVdIG13aWZpZXg6IGRvIG5vdCBmcmVlIGZpcm13YXJl
IGR1bXAgbWVtb3J5IGluIHNodXRkb3duX2Rydg0KW3YzLDEvNV0gbXdpZmlleDogZG9uJ3Qgd2Fp
dCBmb3IgbWFpbl9wcm9jZXNzIGluIHNodXRkb3duX2Rydg0KDQpSZWdhcmRzLA0KQW1pdGt1bWFy
DQo=
^ permalink raw reply
* RE: [PATCH] mac80211: Ensure enough headroom when forwarding mesh pkt
From: Cedric Izoard @ 2016-12-07 9:57 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org; +Cc: Laurent Trarieux
In-Reply-To: <1481103603.4092.38.camel@sipsolutions.net>
PiA+IC0JZndkX3NrYiA9IHNrYl9jb3B5KHNrYiwgR0ZQX0FUT01JQyk7DQo+ID4gKwlpZiAoc2ti
X2hlYWRyb29tKHNrYikgPj0gbG9jYWwtPnR4X2hlYWRyb29tKQ0KPiA+ICsJCWZ3ZF9za2IgPSBz
a2JfY29weShza2IsIEdGUF9BVE9NSUMpOw0KPiA+ICsJZWxzZQ0KPiA+ICsJCWZ3ZF9za2IgPSBz
a2JfY29weV9leHBhbmQoc2tiLCBsb2NhbC0+dHhfaGVhZHJvb20sDQo+ID4gKwkJCQkJwqDCoDAs
IEdGUF9BVE9NSUMpOw0KPiANCj4gV2h5IGJvdGhlciBtYWtpbmcgdGhpcyBjb25kaXRpb25hbD8g
SXQgc2VlbXMgdGhhdCBhbHdheXMgdXNpbmcNCj4gc2tiX2NvcHlfZXhwYW5kKCkgc2hvdWxkIGJl
IHN1ZmZpY2llbnQ/IFRoZSBjb2RlIGJldHdlZW4gdGhlIHR3byAoc2tiX2NvcHksDQo+IHNrYl9j
b3B5X2V4cGFuZCkgaXMgYWxtb3N0IGlkZW50aWNhbCBhbnl3YXksIGFwYXJ0IGZyb20gdGhlIGxh
dHRlciBzZXR0aW5nDQo+IHRoZSBoZWFkcm9vbSAoYW5kIHRhaWxyb29tKS4NCg0KSW5kZWVkLCBj
YWxsaW5nIHNrYl9jb3B5X2V4cGFuZCgpIHdvdWxkIHdvcmsgaW4gYW55IGNhc2UuDQpJIHdpbGwg
c2VuZCBuZXcgcGF0Y2gNCg0KY2VkcmljDQo=
^ permalink raw reply
* [PATCH v2] mac80211: Ensure enough headroom when forwarding mesh pkt
From: Cedric Izoard @ 2016-12-07 9:59 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
When a buffer is duplicated during MESH packet forwarding,
this patch ensures that the new buffer has enough headroom.
Signed-off-by: Cedric Izoard <cedric.izoard@ceva-dsp.com>
---
net/mac80211/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index d2a00f2..bfa5f4d 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2468,7 +2468,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
if (!ifmsh->mshcfg.dot11MeshForwarding)
goto out;
- fwd_skb = skb_copy(skb, GFP_ATOMIC);
+ fwd_skb = skb_copy_expand(skb, local->tx_headroom, 0, GFP_ATOMIC);
if (!fwd_skb) {
net_info_ratelimited("%s: failed to clone mesh frame\n",
sdata->name);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Andrew Zaborowski @ 2016-12-07 9:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: Denis Kenzior, linux-wireless
In-Reply-To: <1481091554.4092.7.camel@sipsolutions.net>
On 7 December 2016 at 07:19, Johannes Berg <johannes@sipsolutions.net> wrote:
>> Possibly Johanness refers to the fact that if you use
>> CMD_AUTHENTICATE, or if you use CMD_CONNECT but the driver implements
>> the SME -- doesn't use the cfg80211 software SME -- then
>> cfg80211_disconnect won't do anything if we're not associated, only
>> authenticated. Currently cfg80211 doesn't have knowledge of whether
>> it is authenticated and where to.
>
> We used to track it, but it was a nightmare and just always buggy :)
>
>> With the software SME current_bss would be set from the moment the
>> authentication attempt starts,
>
> I'm almost certain this isn't true, what makes you think so?
Ok, I think I misread the code, indeed it looks consistent between the
driver SME and cfg80211 SME.
I'm fine only adding the socket owner flag to CMD_ASSOCIATE and
CMD_CONNECT. I'll need to store the bssid of the association in
progress so we can send the Deauthenticate if the socket is closed
before association finishes.
>
>> so there seems to be an inconsistency
>> which would affect for example the NL80211_BSS_STATUS_ASSOCIATED
>> flags in the result of CMD_GET_SCAN.
>
> Thus this can't be the case.
>
>> Perhaps this can be fixed by always
>> setting current_bss on auth attempt start, with flags to indicate
>> whether authentication has happened and whether association happened.
>
> No! That would be wrong!
>
>> At the very least with this patch if you set the socket owner during
>> CMD_AUTHENTICATE and then separately associate, you'd get the
>> expected deauthentication.
>
> That would *NOT* be expected. There's no need to even authenticate
> through CMD_AUTHENTICATE at all to connect to (another) AP!
>
> You need to think beyond the 1996 version of 802.11 ;-)
Best regards
^ permalink raw reply
* Re: [PATCH] mac80211: Ensure enough headroom when forwarding mesh pkt
From: Johannes Berg @ 2016-12-07 9:40 UTC (permalink / raw)
To: Cedric Izoard, linux-wireless@vger.kernel.org; +Cc: Laurent Trarieux
In-Reply-To: <356db1fcf788467f9145abc10e218d66@ceva-dsp.com>
> - fwd_skb = skb_copy(skb, GFP_ATOMIC);
> + if (skb_headroom(skb) >= local->tx_headroom)
> + fwd_skb = skb_copy(skb, GFP_ATOMIC);
> + else
> + fwd_skb = skb_copy_expand(skb, local->tx_headroom,
> + 0, GFP_ATOMIC);
Why bother making this conditional? It seems that always using
skb_copy_expand() should be sufficient? The code between the two
(skb_copy, skb_copy_expand) is almost identical anyway, apart from the
latter setting the headroom (and tailroom).
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: Show pending txqlen in debugfs.
From: Johannes Berg @ 2016-12-07 9:36 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1480964310-16698-2-git-send-email-greearb@candelatech.com>
On Mon, 2016-12-05 at 10:58 -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Could be useful for debugging memory consumption issues,
> and perhaps power-save as well.
Applied this one, but I tend to agree with Felix about the ethtool
stuff, so I've dropped that.
FWIW, we have cfg80211_get_station() now (maybe we could extend that
and provide an iterator as well), so instead of carrying patches you
could also have a small additional module that uses the existing APIs
to get the data, since nl80211 seems to somehow be so problematic for
you.
johannes
^ permalink raw reply
* RE: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Vamsi, Krishna @ 2016-12-07 9:33 UTC (permalink / raw)
To: Johannes Berg, Malinen, Jouni; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1481102727.4092.34.camel@sipsolutions.net>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2hhbm5lcyBCZXJnIFttYWls
dG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0NCg0KPiBXaGF0IGFib3V0IEFyZW5kJ3MgY29t
bWVudCByZWdhcmRpbmcgdGhpcyBmdW5jdGlvbmFsaXR5IG92ZXJsYXBwaW5nIHdpdGggdGhlDQo+
IEJTUyBzZWxlY3Rpb24gb2ZmbG9hZCBjb25maWd1cmF0aW9uPw0KPiANCj4gRG8geW91IHRoaW5r
IHRoZXJlJ3MgYW55IGFiaWxpdHkgdG8gc2hhcmUgYXR0cmlidXRlcy9mdW5jdGlvbmFsaXR5Pw0K
DQpIaSBKb2hhbm5lcywNCg0KSSB0aGluayB0aGUgbGF0ZXIgY29tbWVudCBmcm9tIEx1Y2Egb24g
dGhpcyB3aGljaCBJIHBhc3RlZCBiZWxvdyBpcyBtb3JlIGFncmVlYWJsZS4NCg0KWWVzLCBzaW1p
bGFyIGJ1dCBub3QgcXVpdGUgdGhlIHNhbWUuICBUaGUgZXhpc3RpbmcgY2FzZSBpcyBmb3IgZmlu
ZGluZyBCU1NzIHRoYXQgYXJlIHdvcnRoIHdha2luZyB0aGUgaG9zdCB1cCBmb3IgKHdoaWxlIGRp
c2Nvbm5lY3RlZCksIHNvIGl0IG5lZWRzIHRvIGJlIGJldHRlciB0aGFuIHRoZSBSU1NJIHBhc3Nl
ZCAoYWJzb2x1dGUgbnVtYmVyKS4gIE5vdyB0aGlzIGlzIGFib3V0IHJlbGF0aXZlIFJTU0kgYXMg
Y29tcGFyZWQgdG8gdGhlIGN1cnJlbnQgY29ubmVjdGlvbiwgc28gUkVMQVRJVkVfUlNTSSBpcyBk
aWZmZXJlbnQgdGhhbiBSU1NJIGFuZCBJIHRoaW5rIHRoZSBzYW1lIGF0dHJpYnV0ZSBzaG91bGQg
bm90IGJlIHVzZWQsIHRvIGF2b2lkIGNvbmZ1c2lvbi4NCg0KVGhhbmtzLA0KVmFtc2kNCg==
^ permalink raw reply
* Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Johannes Berg @ 2016-12-07 9:25 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1480715949-20169-2-git-send-email-jouni@qca.qualcomm.com>
> v2: address comments from Luca, Arend, and Johannes
What about Arend's comment regarding this functionality overlapping
with the BSS selection offload configuration?
Do you think there's any ability to share attributes/functionality?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization
From: Johannes Berg @ 2016-12-07 9:24 UTC (permalink / raw)
To: Thomas Pedersen, Masashi Honma; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <CADjYELw=-LEqDra0pM+3FjtJDve+NiNYEMz5=F0i5Ge-5k3LaA@mail.gmail.com>
Hi,
I'm not sure what to do with this now :)
> > There are two functionalities.
> >
> > 1) 13.13.2.2 Neighbor offset synchronization method
> > 2) 13.13.4.4 TBTT adjustment
Yes, this much is obvious.
> > The flag is updated by 2).
Yes, the definition of the flag says:
"The TBTT Adjusting subfield is set to 1 while the TBTT adjustment
procedure is ongoing, and is set to 0 otherwise. (See 13.13.4.4.3.)"
(802.11-2012 8.4.2.100.8 Mesh Capability)
> > 13.13.4.4.3 TBTT scanning and adjustment procedures:
> > The mesh STA shall set the TBTT Adjusting field in the Mesh
> > Configuration element to 1 in order to announce that the TBTT
> > adjustment procedure is ongoing.
That's saying the same thing again, I guess :)
> > And the flag is refered by 1) as you said.
> >
> >
> > The purpose of the flag is to prevent 1) while 2) is ongoing.
> >
> > In other words, 1) has only read access authority to the flag.
> > However,
> > previous code updated the flag in 1). In addition, there is no code
> > for
> > 2). So I just remove the invalid accessing codes.
>
> I don't think 1) has read only access to that flag. A TSF adjust will
> by definition move the TBTT as well.
It seems that the wording in the spec disagrees with that - it says
(twice) to set the bit only while the TBTT adjustment procedure is
ongoing, which isn't the case here?
Then again, what exactly *is* this code doing?
It's called mesh_sync_offset_adjust_tbtt() which matches more closely
"TBTT adjustment" than "neighbor offset synchronization"? The code
looks more like offset synchronization though. Perhaps there's some
confusing and it's kinda doing both?
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox