* Re: [PATCH v6 2/4] mac80211: filter multicast data packets on AP / AP_VLAN
From: Johannes Berg @ 2016-10-12 12:16 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan, netdev
In-Reply-To: <1476119543-24509-2-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-10 at 19:12 +0200, Michael Braun wrote:
> This patch adds filtering for multicast data packets on AP_VLAN
> interfaces
>
[...]
Applied patches 1 and 2 for now, I'll look at the others again later.
johannes
^ permalink raw reply
* [PATCH] mac80211: preserve more bits when building QoS header
From: Johannes Berg @ 2016-10-12 12:19 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Michael Braun reported that when trying to inject A-MSDUs over
monitor interfaces, the frame doesn't come out right since the
QoS header A-MSDU bit is overwritten.
Rather than adding that bit specifically simply preserve those
bits that we don't set here, since we typically get here with
a zeroed-out QoS header anyway.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/wme.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index 9eb0aee9105b..3e3d3014e9ab 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -236,26 +236,35 @@ void ieee80211_set_qos_hdr(struct ieee80211_sub_if_data *sdata,
{
struct ieee80211_hdr *hdr = (void *)skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ u8 tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
+ u8 flags;
u8 *p;
- u8 ack_policy, tid;
if (!ieee80211_is_data_qos(hdr->frame_control))
return;
p = ieee80211_get_qos_ctl(hdr);
- tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
- /* preserve EOSP bit */
- ack_policy = *p & IEEE80211_QOS_CTL_EOSP;
+ /* set up the first byte */
+
+ /*
+ * preserve everything but the TID and ACK policy
+ * (which we both write here)
+ */
+ flags = *p & ~(IEEE80211_QOS_CTL_TID_MASK |
+ IEEE80211_QOS_CTL_ACK_POLICY_MASK);
if (is_multicast_ether_addr(hdr->addr1) ||
sdata->noack_map & BIT(tid)) {
- ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
+ flags |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
info->flags |= IEEE80211_TX_CTL_NO_ACK;
}
- /* qos header is 2 bytes */
- *p++ = ack_policy | tid;
+ *p = flags | tid;
+
+ /* set up the second byte */
+ p++;
+
if (ieee80211_vif_is_mesh(&sdata->vif)) {
/* preserve RSPI and Mesh PS Level bit */
*p &= ((IEEE80211_QOS_CTL_RSPI |
--
2.8.1
^ permalink raw reply related
* USB WiFi driver for AP mode
From: Simon Wunderlich @ 2016-10-12 12:19 UTC (permalink / raw)
To: linux-wireless, bb; +Cc: Pannirselvam Kanagaratnam
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
Hi,
we are looking for well supported USB WiFi chips/modules with the following
requirements
* Be able to support AP mode
* Support at least 20 concurrent clients (stations)
* Support multiple SSIDs
* (preferred, optional: Support 2x2 802.11gn)
We did a survey through the various wiki pages and online information, but
didn't find anything yet matching those requirements (and only found out
limitations after trying ...). Any pointers are appreciated. :)
Thanks!
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Luca Coelho @ 2016-10-12 12:24 UTC (permalink / raw)
To: Chris Rorvick, Paul Bolle
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <CAEUsAPbEf=hr1ki267qKpenWW_UBO93KY8q6-EdqWpk15Yhcnw@mail.gmail.com>
On Tue, 2016-10-11 at 23:32 -0500, Chris Rorvick wrote:
> On Tue, Oct 11, 2016 at 5:11 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> > For what it's worth, on my machine I have twenty (!) SPLX entries, all
> > reading:
> > Name (SPLX, Package (0x04)
> > {
> > Zero,
> > Package (0x03)
> > {
> > 0x80000000,
> > 0x80000000,
> > 0x80000000
> > },
> >
> > Package (0x03)
> > {
> > 0x80000000,
> > 0x80000000,
> > 0x80000000
> > },
> >
> > Package (0x03)
> > {
> > 0x80000000,
> > 0x80000000,
> > 0x80000000
> > }
> > })
>
>
> I actually see exactly the same on my Dell XPS 13 (9350) when I use
> acpidump, etc. I typed the entry I included in the commit log by hand
> based on what the driver gets back from the SPLC method (I added a
> function to dump the returned object.)
Okay... Actually this is a structure in the BIOS and the actual method
we call is SPLC. The SPLC method may return one item from this table,
or something entirely different, possible one of the three values
depending on a configuration option or so.
Can you to find and send me the actual SPLC method that we call, from
your BIOS?
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v2] mac80211: fix A-MSDU outer SA/DA
From: Johannes Berg @ 2016-10-12 12:25 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan, Felix Fietkau
In-Reply-To: <1476269870-32007-1-git-send-email-michael-dev@fami-braun.de>
On Wed, 2016-10-12 at 12:57 +0200, Michael Braun wrote:
> According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer
> SA/DA of A-MSDU frames need to be changed depending on FromDS/ToDS
> values.
actually ...
> struct ieee80211_hdr *hdr;
802.11 header
> - struct ethhdr amsdu_hdr;
> + struct ethhdr *amsdu_hdr;
> int hdr_len = fast_tx->hdr_len - sizeof(rfc1042_header);
802.11 header length
> + data = skb_push(skb, sizeof(*amsdu_hdr));
push ethernet header in
> + memmove(data, data + sizeof(*amsdu_hdr), hdr_len);
move 802.11 header from back to front
> + hdr = data;
hdr is at the beginning of the frame
> + amsdu_hdr = data + hdr_len;
amsdu_hdr is actually the *inner* header after all.
So, I actually think my first instinct that you were erroneously
changing the inner header *was* right.
Seems like this code should be inserted towards the end of
ieee80211_amsdu_aggregate() instead, where it's adding the RFC 1042
header?
Need Felix to take a look, I guess.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix sequence number allocation regression
From: Bob Copeland @ 2016-10-12 12:37 UTC (permalink / raw)
To: Johannes Berg
Cc: Felix Fietkau, linux-wireless, Toke Høiland-Jørgensen
In-Reply-To: <1476254985.5271.1.camel@sipsolutions.net>
On Wed, Oct 12, 2016 at 08:49:45AM +0200, Johannes Berg wrote:
> On Tue, 2016-10-11 at 11:28 +0200, Felix Fietkau wrote:
> > The recent commit that moved around TX handlers dropped the sequence
> > number allocation at the end of ieee80211_tx_dequeue and calls
> > ieee80211_tx_h_sequence instead (for the non-fast-xmit case).
> > However, it did not change the fast-xmit sequence allocation
> > condition
> > in ieee80211_xmit_fast_finish, which skipped seqno alloc if
> > intermediate
> > tx queues are being used.
> >
> > Drop the now obsolete condition.
>
> Hm. I don't know what tree you're looking at, but it looks like I *did*
> in fact resolve this correctly; the (now) erroneous condition doesn't
> exist in mac80211 nor in mac80211-next (nor net, net-next, linux).
>
> It does seem to exist in wireless-testing, but that's not something I
> can control.
Sorry about that, I should've rechecked this after Johannes did the merge.
I applied this patch (to wireless-testing) and pushed tag wt-2016-10-12.
Let me know of any further issues.
As a check I also diffed against mac80211-next/master and found additional
merge damage in the diff which I fixed up. Once the merge window closes
in a few days, I'll resync to the masters of all the trees.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Paul Bolle @ 2016-10-12 12:36 UTC (permalink / raw)
To: Luca Coelho, Chris Rorvick
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <1476275099.7776.28.camel@coelho.fi>
On Wed, 2016-10-12 at 15:24 +0300, Luca Coelho wrote:
> Okay... Actually this is a structure in the BIOS and the actual method
> we call is SPLC. The SPLC method may return one item from this table,
> or something entirely different, possible one of the three values
> depending on a configuration option or so.
>
> Can you to find and send me the actual SPLC method that we call, from
> your BIOS?
It seems Chris and I basically have identical setups, so I'll answer.
There are 20 SPLC methods in the BIOS. The first reads
Method (SPLC, 0, Serialized)
{
DerefOf (SPLX [One]) [Zero] = DOM1 /* \DOM1 */
DerefOf (SPLX [One]) [One] = LIM1 /* \LIM1 */
DerefOf (SPLX [One]) [0x02] = TIM1 /* \TIM1 */
DerefOf (SPLX [0x02]) [Zero] = DOM2 /* \DOM2 */
DerefOf (SPLX [0x02]) [One] = LIM2 /* \LIM2 */
DerefOf (SPLX [0x02]) [0x02] = TIM2 /* \TIM2 */
DerefOf (SPLX [0x03]) [Zero] = DOM3 /* \DOM3 */
DerefOf (SPLX [0x03]) [One] = LIM3 /* \LIM3 */
DerefOf (SPLX [0x03]) [0x02] = TIM3 /* \TIM3 */
Return (SPLX) /* \_SB_.PCI0.RP01.PXSX.SPLX */
}
The only difference is in the last comment. Ie, RP01 is increased until
it reaches RP20. (The machine has 20 PCI devices according to lspci. I
have no clue how to match that RPxx number to the 20 devices showing up
in lspci, sorry.)
Paul Bolle
^ permalink raw reply
* Re: [v2] rt2x00: add support for mac addr from device tree
From: Kalle Valo @ 2016-10-12 12:53 UTC (permalink / raw)
To: Mathias Kresin; +Cc: linux-wireless, devicetree
In-Reply-To: <87shskwaxh.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
>> I thought about _adding_ a devicetree binding document before sending
>> the patch. But in the end it would be an empty file, since I neither
>> add any bindings nor introduce a compatible string. I'm just add
>> support for the generic of_get_mac_address() devicetree property,
>> which is meant to be used via a devicetree pci childnode.
>>
>> I grepped though the 4.7 code and found a few driver using
>> of_get_mac_address() without having a devicetree binding document:
>>
>> - drivers/net/usb/smsc95xx.c
>> - drivers/net/usb/smsc75xx.c
>> - drivers/net/ethernet/marvell/sky2.c
>> - drivers/net/ethernet/cavium/thunder/thunder_bgx.c
>> - drivers/net/ethernet/wiznet/w5100-spi.c
>> - drivers/net/ethernet/arc/emac_main.c
>>
>> Just let me know if you are still the opinion that a devicetree
>> binding document is required to get this patch accepted.
>
> I'm not familiar enough device tree to really comment. Can someone from
> the device tree list (CCed) help?
>
> Full patch here:
>
> https://patchwork.kernel.org/patch/9300893/
I didn't get any comments so I guess we don't need to document the use
of mac-address in the driver binding document. At least
Documentation/devicetree/bindings/net/ethernet.txt supports that, even
if rt2x00 is a wireless driver.
Unless I get any objections I'm planning to apply this to
wireless-drivers-next (once it's open again).
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.
From: Purushottam Kushwaha @ 2016-10-12 12:57 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, pkushwah
This commit enhances the current beacon interval validation to also consider
the "radar_detect" and "num_different_channels".
Rename "cfg80211_validate_beacon_int" to "cfg80211_validate_beacon_combination"
as the validation considers other parameters.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
net/wireless/core.h | 7 +++++--
net/wireless/mesh.c | 7 +++++++
net/wireless/nl80211.c | 32 ++++++++++++++-----------------
net/wireless/util.c | 51 +++++++++++++++++++++++++++++++++++++++++++++-----
4 files changed, 72 insertions(+), 25 deletions(-)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 21e3188..e39c8a9 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -474,8 +474,11 @@ int ieee80211_get_ratemask(struct ieee80211_supported_band *sband,
const u8 *rates, unsigned int n_rates,
u32 *mask);
-int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- enum nl80211_iftype iftype, u32 beacon_int);
+int
+cfg80211_validate_beacon_combination(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
+ struct cfg80211_chan_def *chandef,
+ u32 beacon_int);
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index fa2066b..1d864b4 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -178,6 +178,13 @@ int __cfg80211_join_mesh(struct cfg80211_registered_device *rdev,
NL80211_IFTYPE_MESH_POINT))
return -EINVAL;
+ err = cfg80211_validate_beacon_combination(rdev,
+ NL80211_IFTYPE_MESH_POINT,
+ &setup->chandef,
+ setup->beacon_interval);
+ if (err)
+ return err;
+
err = rdev_join_mesh(rdev, dev, conf, setup);
if (!err) {
memcpy(wdev->ssid, setup->mesh_id, setup->mesh_id_len);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 903cd5a..eb2bfae 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3807,11 +3807,6 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
params.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
- err = cfg80211_validate_beacon_int(rdev, dev->ieee80211_ptr->iftype,
- params.beacon_interval);
- if (err)
- return err;
-
/*
* In theory, some of these attributes should be required here
* but since they were not used when the command was originally
@@ -3899,6 +3894,13 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
wdev->iftype))
return -EINVAL;
+ err = cfg80211_validate_beacon_combination(rdev,
+ dev->ieee80211_ptr->iftype,
+ ¶ms.chandef,
+ params.beacon_interval);
+ if (err)
+ return err;
+
if (info->attrs[NL80211_ATTR_TX_RATES]) {
err = nl80211_parse_tx_bitrate_mask(info, ¶ms.beacon_rate);
if (err)
@@ -8157,11 +8159,6 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
ibss.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_ADHOC,
- ibss.beacon_interval);
- if (err)
- return err;
-
if (!rdev->ops->join_ibss)
return -EOPNOTSUPP;
@@ -8188,6 +8185,12 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
if (err)
return err;
+ err = cfg80211_validate_beacon_combination(rdev, NL80211_IFTYPE_ADHOC,
+ &ibss.chandef,
+ ibss.beacon_interval);
+ if (err)
+ return err;
+
if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef,
NL80211_IFTYPE_ADHOC))
return -EINVAL;
@@ -9419,17 +9422,10 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
nla_get_u32(info->attrs[NL80211_ATTR_MCAST_RATE])))
return -EINVAL;
- if (info->attrs[NL80211_ATTR_BEACON_INTERVAL]) {
+ if (info->attrs[NL80211_ATTR_BEACON_INTERVAL])
setup.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev,
- NL80211_IFTYPE_MESH_POINT,
- setup.beacon_interval);
- if (err)
- return err;
- }
-
if (info->attrs[NL80211_ATTR_DTIM_PERIOD]) {
setup.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 3f3d684..a5810ba 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1558,15 +1558,21 @@ bool ieee80211_chandef_to_operating_class(struct cfg80211_chan_def *chandef,
}
EXPORT_SYMBOL(ieee80211_chandef_to_operating_class);
-int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- enum nl80211_iftype iftype,
- u32 beacon_int)
+int
+cfg80211_validate_beacon_combination(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
+ struct cfg80211_chan_def *chandef,
+ u32 beacon_int)
{
struct wireless_dev *wdev;
- int res = 0;
+ int res = 0, i;
u32 bi_prev, tmp_bi;
+ struct ieee80211_channel *ch;
+ enum cfg80211_chan_mode chmode;
+ struct ieee80211_channel
+ *used_channels[CFG80211_MAX_NUM_DIFFERENT_CHANNELS];
struct iface_combination_params params = {
- .num_different_channels = 0,
+ .num_different_channels = 1,
.radar_detect = 0,
.iftype_num = {0},
.beacon_gcd = beacon_int, /* GCD(n) = n */
@@ -1576,11 +1582,46 @@ int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
if (beacon_int < 10 || beacon_int > 10000)
return -EINVAL;
+ used_channels[0] = chandef->chan;
params.iftype_num[iftype] = 1;
+
+ res = cfg80211_chandef_dfs_required(&rdev->wiphy, chandef, iftype);
+ if (res < 0)
+ return res;
+ if (res)
+ params.radar_detect = BIT(chandef->width);
+
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (!wdev->beacon_interval)
continue;
+ mutex_lock_nested(&wdev->mtx, 1);
+ __acquire(wdev->mtx);
+ cfg80211_get_chan_state(wdev, &ch, &chmode,
+ ¶ms.radar_detect);
+ wdev_unlock(wdev);
+
+ switch (chmode) {
+ case CHAN_MODE_UNDEFINED:
+ break;
+ case CHAN_MODE_SHARED:
+ for (i = 0; i < CFG80211_MAX_NUM_DIFFERENT_CHANNELS; i++)
+ if (!used_channels[i] || used_channels[i] == ch)
+ break;
+
+ if (i == CFG80211_MAX_NUM_DIFFERENT_CHANNELS)
+ return -EBUSY;
+
+ if (!used_channels[i]) {
+ used_channels[i] = ch;
+ params.num_different_channels++;
+ }
+ break;
+ case CHAN_MODE_EXCLUSIVE:
+ params.num_different_channels++;
+ break;
+ }
+
params.iftype_num[wdev->iftype]++;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v10] cfg80211: Provision to allow the support for different beacon intervals
From: Purushottam Kushwaha @ 2016-10-12 12:56 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, pkushwah
This commit provides a mechanism for the host drivers to advertise the
support for different beacon intervals among the respective interface
combinations in a group, through beacon_int_min_gcd (u32).
This beacon_int_min_gcd will be compared against GCD of all beaconing
interfaces of matching combinations.
Following sets the expectation for beacon_int_min_gcd.
= 0 - all beacon intervals for different interfaces must be same.
> 0 - any beacon interval for the interface part of this combination AND
*GCD* of all beacon intervals from beaconing interfaces of this
combination must be greator or equal to this value.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +++
include/net/cfg80211.h | 14 +++++++-
include/uapi/linux/nl80211.h | 8 +++--
net/wireless/core.h | 2 +-
net/wireless/nl80211.c | 14 ++++++--
net/wireless/util.c | 37 ++++++++++++++++++++--
6 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 44e1c70..2624569 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -421,6 +421,8 @@ static int brcmf_vif_change_validate(struct brcmf_cfg80211_info *cfg,
.num_different_channels = 1,
.radar_detect = 0,
.iftype_num = {0},
+ .beacon_gcd = 0,
+ .diff_bi = false,
};
list_for_each_entry(pos, &cfg->vif_list, list)
@@ -446,6 +448,8 @@ static int brcmf_vif_add_validate(struct brcmf_cfg80211_info *cfg,
.num_different_channels = 1,
.radar_detect = 0,
.iftype_num = {0},
+ .beacon_gcd = 0,
+ .diff_bi = false,
};
list_for_each_entry(pos, &cfg->vif_list, list)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 21bbe44..f0bcd55 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -784,11 +784,15 @@ struct cfg80211_csa_settings {
* @iftype_num: array with the numbers of interfaces of each interface
* type. The index is the interface type as specified in &enum
* nl80211_iftype.
+ * @beacon_gcd: a value specifying GCD of all beaconing interfaces.
+ * @diff_bi: a flag which denotes beacon intervals are different or same.
*/
struct iface_combination_params {
int num_different_channels;
u8 radar_detect;
int iftype_num[NUM_NL80211_IFTYPES];
+ u32 beacon_gcd;
+ bool diff_bi;
};
/**
@@ -3100,6 +3104,12 @@ struct ieee80211_iface_limit {
* only in special cases.
* @radar_detect_widths: bitmap of channel widths supported for radar detection
* @radar_detect_regions: bitmap of regions supported for radar detection
+ * @beacon_int_min_gcd: This interface combination supports different
+ * beacon intervals.
+ * = 0 - all beacon intervals for different interface must be same.
+ * > 0 - any beacon interval for the interface part of this combination AND
+ * *GCD* of all beacon intervals from beaconing interfaces of this
+ * combination must be greator or equal to this value.
*
* With this structure the driver can describe which interface
* combinations it supports concurrently.
@@ -3120,7 +3130,7 @@ struct ieee80211_iface_limit {
* };
*
*
- * 2. Allow #{AP, P2P-GO} <= 8, channels = 1, 8 total:
+ * 2. Allow #{AP, P2P-GO} <= 8, BI min gcd = 10, channels = 1, 8 total:
*
* struct ieee80211_iface_limit limits2[] = {
* { .max = 8, .types = BIT(NL80211_IFTYPE_AP) |
@@ -3131,6 +3141,7 @@ struct ieee80211_iface_limit {
* .n_limits = ARRAY_SIZE(limits2),
* .max_interfaces = 8,
* .num_different_channels = 1,
+ * .beacon_int_min_gcd = 10,
* };
*
*
@@ -3158,6 +3169,7 @@ struct ieee80211_iface_combination {
bool beacon_int_infra_match;
u8 radar_detect_widths;
u8 radar_detect_regions;
+ u32 beacon_int_min_gcd;
};
struct ieee80211_txrx_stypes {
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 56368e9..3c19cca 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4280,6 +4280,9 @@ enum nl80211_iface_limit_attrs {
* of supported channel widths for radar detection.
* @NL80211_IFACE_COMB_RADAR_DETECT_REGIONS: u32 attribute containing the bitmap
* of supported regulatory regions for radar detection.
+ * @NL80211_IFACE_COMB_BI_MIN_GCD: u32 attribute specifying the minimum GCD of
+ * different beacon intervals supported by all the interface combinations
+ * in this group (if not present, all beacon interval must match).
* @NUM_NL80211_IFACE_COMB: number of attributes
* @MAX_NL80211_IFACE_COMB: highest attribute number
*
@@ -4287,8 +4290,8 @@ enum nl80211_iface_limit_attrs {
* limits = [ #{STA} <= 1, #{AP} <= 1 ], matching BI, channels = 1, max = 2
* => allows an AP and a STA that must match BIs
*
- * numbers = [ #{AP, P2P-GO} <= 8 ], channels = 1, max = 8
- * => allows 8 of AP/GO
+ * numbers = [ #{AP, P2P-GO} <= 8 ], BI min gcd, channels = 1, max = 8,
+ * => allows 8 of AP/GO that can have BI gcd >= min gcd
*
* numbers = [ #{STA} <= 2 ], channels = 2, max = 2
* => allows two STAs on different channels
@@ -4314,6 +4317,7 @@ enum nl80211_if_combination_attrs {
NL80211_IFACE_COMB_NUM_CHANNELS,
NL80211_IFACE_COMB_RADAR_DETECT_WIDTHS,
NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
+ NL80211_IFACE_COMB_BI_MIN_GCD,
/* keep last */
NUM_NL80211_IFACE_COMB,
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 08d2e94..21e3188 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -475,7 +475,7 @@ int ieee80211_get_ratemask(struct ieee80211_supported_band *sband,
u32 *mask);
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- u32 beacon_int);
+ enum nl80211_iftype iftype, u32 beacon_int);
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c510810..903cd5a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1075,6 +1075,10 @@ static int nl80211_put_iface_combinations(struct wiphy *wiphy,
nla_put_u32(msg, NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
c->radar_detect_regions)))
goto nla_put_failure;
+ if (c->beacon_int_min_gcd &&
+ nla_put_u32(msg, NL80211_IFACE_COMB_BI_MIN_GCD,
+ c->beacon_int_min_gcd))
+ goto nla_put_failure;
nla_nest_end(msg, nl_combi);
}
@@ -3803,7 +3807,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
params.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
- err = cfg80211_validate_beacon_int(rdev, params.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, dev->ieee80211_ptr->iftype,
+ params.beacon_interval);
if (err)
return err;
@@ -8152,7 +8157,8 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
ibss.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, ibss.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_ADHOC,
+ ibss.beacon_interval);
if (err)
return err;
@@ -9417,7 +9423,9 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
setup.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, setup.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev,
+ NL80211_IFTYPE_MESH_POINT,
+ setup.beacon_interval);
if (err)
return err;
}
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 0d69b25..3f3d684 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1559,24 +1559,49 @@ bool ieee80211_chandef_to_operating_class(struct cfg80211_chan_def *chandef,
EXPORT_SYMBOL(ieee80211_chandef_to_operating_class);
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
u32 beacon_int)
{
struct wireless_dev *wdev;
int res = 0;
+ u32 bi_prev, tmp_bi;
+ struct iface_combination_params params = {
+ .num_different_channels = 0,
+ .radar_detect = 0,
+ .iftype_num = {0},
+ .beacon_gcd = beacon_int, /* GCD(n) = n */
+ .diff_bi = false,
+ };
if (beacon_int < 10 || beacon_int > 10000)
return -EINVAL;
+ params.iftype_num[iftype] = 1;
+ list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
+ if (!wdev->beacon_interval)
+ continue;
+
+ params.iftype_num[wdev->iftype]++;
+ }
+
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (!wdev->beacon_interval)
continue;
if (wdev->beacon_interval != beacon_int) {
- res = -EINVAL;
+ params.diff_bi = true;
+ /* Get the GCD */
+ bi_prev = wdev->beacon_interval;
+ while (bi_prev != 0) {
+ tmp_bi = bi_prev;
+ bi_prev = params.beacon_gcd % bi_prev;
+ params.beacon_gcd = tmp_bi;
+ }
break;
}
}
- return res;
+ res = cfg80211_check_combinations(&rdev->wiphy, ¶ms);
+ return (res < 0) ? res : 0;
}
int cfg80211_iter_combinations(struct wiphy *wiphy,
@@ -1652,6 +1677,14 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
if ((all_iftypes & used_iftypes) != used_iftypes)
goto cont;
+ if (params->beacon_gcd) {
+ if (c->beacon_int_min_gcd &&
+ params->beacon_gcd < c->beacon_int_min_gcd)
+ return -EINVAL;
+ if (!c->beacon_int_min_gcd && params->diff_bi)
+ goto cont;
+ }
+
/* This combination covered all interface types and
* supported the requested numbers, so we're good.
*/
--
1.9.1
^ permalink raw reply related
* [PATCH v2] cfg80211: Create structure for combination check/iter function parameters
From: Purushottam Kushwaha @ 2016-10-12 12:55 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, pkushwah
Move growing parameter list to a structure for check/iter combination
functions in cfg80211 and mac80211.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 26 ++++++-----
include/net/cfg80211.h | 46 ++++++++++----------
net/mac80211/util.c | 50 +++++++++++-----------
net/wireless/util.c | 28 ++++++------
4 files changed, 78 insertions(+), 72 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b777e1b..44e1c70 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -414,23 +414,26 @@ static int brcmf_vif_change_validate(struct brcmf_cfg80211_info *cfg,
struct brcmf_cfg80211_vif *vif,
enum nl80211_iftype new_type)
{
- int iftype_num[NUM_NL80211_IFTYPES];
struct brcmf_cfg80211_vif *pos;
bool check_combos = false;
int ret = 0;
+ struct iface_combination_params params = {
+ .num_different_channels = 1,
+ .radar_detect = 0,
+ .iftype_num = {0},
+ };
- memset(&iftype_num[0], 0, sizeof(iftype_num));
list_for_each_entry(pos, &cfg->vif_list, list)
if (pos == vif) {
- iftype_num[new_type]++;
+ params.iftype_num[new_type]++;
} else {
/* concurrent interfaces so need check combinations */
check_combos = true;
- iftype_num[pos->wdev.iftype]++;
+ params.iftype_num[pos->wdev.iftype]++;
}
if (check_combos)
- ret = cfg80211_check_combinations(cfg->wiphy, 1, 0, iftype_num);
+ ret = cfg80211_check_combinations(cfg->wiphy, ¶ms);
return ret;
}
@@ -438,15 +441,18 @@ static int brcmf_vif_change_validate(struct brcmf_cfg80211_info *cfg,
static int brcmf_vif_add_validate(struct brcmf_cfg80211_info *cfg,
enum nl80211_iftype new_type)
{
- int iftype_num[NUM_NL80211_IFTYPES];
struct brcmf_cfg80211_vif *pos;
+ struct iface_combination_params params = {
+ .num_different_channels = 1,
+ .radar_detect = 0,
+ .iftype_num = {0},
+ };
- memset(&iftype_num[0], 0, sizeof(iftype_num));
list_for_each_entry(pos, &cfg->vif_list, list)
- iftype_num[pos->wdev.iftype]++;
+ params.iftype_num[pos->wdev.iftype]++;
- iftype_num[new_type]++;
- return cfg80211_check_combinations(cfg->wiphy, 1, 0, iftype_num);
+ params.iftype_num[new_type]++;
+ return cfg80211_check_combinations(cfg->wiphy, ¶ms);
}
static void convert_key_from_CPU(struct brcmf_wsec_key *key,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index fe78f02..21bbe44 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -772,6 +772,26 @@ struct cfg80211_csa_settings {
};
/**
+ * struct iface_combination_params - input parameters for interface combinations
+ *
+ * Used to pass interface combination parameters
+ *
+ * @num_different_channels: the number of different channels we want
+ * to use for verification
+ * @radar_detect: a bitmap where each bit corresponds to a channel
+ * width where radar detection is needed, as in the definition of
+ * &struct ieee80211_iface_combination.@radar_detect_widths
+ * @iftype_num: array with the numbers of interfaces of each interface
+ * type. The index is the interface type as specified in &enum
+ * nl80211_iftype.
+ */
+struct iface_combination_params {
+ int num_different_channels;
+ u8 radar_detect;
+ int iftype_num[NUM_NL80211_IFTYPES];
+};
+
+/**
* enum station_parameters_apply_mask - station parameter values to apply
* @STATION_PARAM_APPLY_UAPSD: apply new uAPSD parameters (uapsd_queues, max_sp)
* @STATION_PARAM_APPLY_CAPABILITY: apply new capability
@@ -5575,36 +5595,20 @@ void cfg80211_report_wowlan_wakeup(struct wireless_dev *wdev,
* cfg80211_check_combinations - check interface combinations
*
* @wiphy: the wiphy
- * @num_different_channels: the number of different channels we want
- * to use for verification
- * @radar_detect: a bitmap where each bit corresponds to a channel
- * width where radar detection is needed, as in the definition of
- * &struct ieee80211_iface_combination.@radar_detect_widths
- * @iftype_num: array with the numbers of interfaces of each interface
- * type. The index is the interface type as specified in &enum
- * nl80211_iftype.
+ * @params: the interface combinations parameter
*
* This function can be called by the driver to check whether a
* combination of interfaces and their types are allowed according to
* the interface combinations.
*/
int cfg80211_check_combinations(struct wiphy *wiphy,
- const int num_different_channels,
- const u8 radar_detect,
- const int iftype_num[NUM_NL80211_IFTYPES]);
+ struct iface_combination_params *params);
/**
* cfg80211_iter_combinations - iterate over matching combinations
*
* @wiphy: the wiphy
- * @num_different_channels: the number of different channels we want
- * to use for verification
- * @radar_detect: a bitmap where each bit corresponds to a channel
- * width where radar detection is needed, as in the definition of
- * &struct ieee80211_iface_combination.@radar_detect_widths
- * @iftype_num: array with the numbers of interfaces of each interface
- * type. The index is the interface type as specified in &enum
- * nl80211_iftype.
+ * @params: the interface combinations parameter
* @iter: function to call for each matching combination
* @data: pointer to pass to iter function
*
@@ -5613,9 +5617,7 @@ int cfg80211_check_combinations(struct wiphy *wiphy,
* purposes.
*/
int cfg80211_iter_combinations(struct wiphy *wiphy,
- const int num_different_channels,
- const u8 radar_detect,
- const int iftype_num[NUM_NL80211_IFTYPES],
+ struct iface_combination_params *params,
void (*iter)(const struct ieee80211_iface_combination *c,
void *data),
void *data);
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 545c79a..cfec67d 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -3308,10 +3308,13 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
struct ieee80211_local *local = sdata->local;
struct ieee80211_sub_if_data *sdata_iter;
enum nl80211_iftype iftype = sdata->wdev.iftype;
- int num[NUM_NL80211_IFTYPES];
struct ieee80211_chanctx *ctx;
- int num_different_channels = 0;
int total = 1;
+ struct iface_combination_params params = {
+ .num_different_channels = 0,
+ .radar_detect = radar_detect,
+ .iftype_num = {0},
+ };
lockdep_assert_held(&local->chanctx_mtx);
@@ -3322,9 +3325,6 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
!chandef->chan))
return -EINVAL;
- if (chandef)
- num_different_channels = 1;
-
if (WARN_ON(iftype >= NUM_NL80211_IFTYPES))
return -EINVAL;
@@ -3335,24 +3335,26 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
return 0;
}
- memset(num, 0, sizeof(num));
+ if (chandef)
+ params.num_different_channels = 1;
if (iftype != NL80211_IFTYPE_UNSPECIFIED)
- num[iftype] = 1;
+ params.iftype_num[iftype] = 1;
list_for_each_entry(ctx, &local->chanctx_list, list) {
if (ctx->replace_state == IEEE80211_CHANCTX_WILL_BE_REPLACED)
continue;
- radar_detect |= ieee80211_chanctx_radar_detect(local, ctx);
+ params.radar_detect |=
+ ieee80211_chanctx_radar_detect(local, ctx);
if (ctx->mode == IEEE80211_CHANCTX_EXCLUSIVE) {
- num_different_channels++;
+ params.num_different_channels++;
continue;
}
if (chandef && chanmode == IEEE80211_CHANCTX_SHARED &&
cfg80211_chandef_compatible(chandef,
&ctx->conf.def))
continue;
- num_different_channels++;
+ params.num_different_channels++;
}
list_for_each_entry_rcu(sdata_iter, &local->interfaces, list) {
@@ -3365,16 +3367,14 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
local->hw.wiphy->software_iftypes & BIT(wdev_iter->iftype))
continue;
- num[wdev_iter->iftype]++;
+ params.iftype_num[wdev_iter->iftype]++;
total++;
}
- if (total == 1 && !radar_detect)
+ if (total == 1 && !params.radar_detect)
return 0;
- return cfg80211_check_combinations(local->hw.wiphy,
- num_different_channels,
- radar_detect, num);
+ return cfg80211_check_combinations(local->hw.wiphy, ¶ms);
}
static void
@@ -3390,12 +3390,14 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
int ieee80211_max_num_channels(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata;
- int num[NUM_NL80211_IFTYPES] = {};
struct ieee80211_chanctx *ctx;
- int num_different_channels = 0;
- u8 radar_detect = 0;
u32 max_num_different_channels = 1;
int err;
+ struct iface_combination_params params = {
+ .num_different_channels = 0,
+ .radar_detect = 0,
+ .iftype_num = {0},
+ };
lockdep_assert_held(&local->chanctx_mtx);
@@ -3403,17 +3405,17 @@ int ieee80211_max_num_channels(struct ieee80211_local *local)
if (ctx->replace_state == IEEE80211_CHANCTX_WILL_BE_REPLACED)
continue;
- num_different_channels++;
+ params.num_different_channels++;
- radar_detect |= ieee80211_chanctx_radar_detect(local, ctx);
+ params.radar_detect |=
+ ieee80211_chanctx_radar_detect(local, ctx);
}
list_for_each_entry_rcu(sdata, &local->interfaces, list)
- num[sdata->wdev.iftype]++;
+ params.iftype_num[sdata->wdev.iftype]++;
- err = cfg80211_iter_combinations(local->hw.wiphy,
- num_different_channels, radar_detect,
- num, ieee80211_iter_max_chans,
+ err = cfg80211_iter_combinations(local->hw.wiphy, ¶ms,
+ ieee80211_iter_max_chans,
&max_num_different_channels);
if (err < 0)
return err;
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 8edce22..0d69b25 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1580,9 +1580,7 @@ int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
}
int cfg80211_iter_combinations(struct wiphy *wiphy,
- const int num_different_channels,
- const u8 radar_detect,
- const int iftype_num[NUM_NL80211_IFTYPES],
+ struct iface_combination_params *params,
void (*iter)(const struct ieee80211_iface_combination *c,
void *data),
void *data)
@@ -1593,7 +1591,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
int num_interfaces = 0;
u32 used_iftypes = 0;
- if (radar_detect) {
+ if (params->radar_detect) {
rcu_read_lock();
regdom = rcu_dereference(cfg80211_regdomain);
if (regdom)
@@ -1602,8 +1600,8 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
}
for (iftype = 0; iftype < NUM_NL80211_IFTYPES; iftype++) {
- num_interfaces += iftype_num[iftype];
- if (iftype_num[iftype] > 0 &&
+ num_interfaces += params->iftype_num[iftype];
+ if (params->iftype_num[iftype] > 0 &&
!(wiphy->software_iftypes & BIT(iftype)))
used_iftypes |= BIT(iftype);
}
@@ -1617,7 +1615,7 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
if (num_interfaces > c->max_interfaces)
continue;
- if (num_different_channels > c->num_different_channels)
+ if (params->num_different_channels > c->num_different_channels)
continue;
limits = kmemdup(c->limits, sizeof(limits[0]) * c->n_limits,
@@ -1632,16 +1630,17 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
all_iftypes |= limits[j].types;
if (!(limits[j].types & BIT(iftype)))
continue;
- if (limits[j].max < iftype_num[iftype])
+ if (limits[j].max < params->iftype_num[iftype])
goto cont;
- limits[j].max -= iftype_num[iftype];
+ limits[j].max -= params->iftype_num[iftype];
}
}
- if (radar_detect != (c->radar_detect_widths & radar_detect))
+ if (params->radar_detect !=
+ (c->radar_detect_widths & params->radar_detect))
goto cont;
- if (radar_detect && c->radar_detect_regions &&
+ if (params->radar_detect && c->radar_detect_regions &&
!(c->radar_detect_regions & BIT(region)))
goto cont;
@@ -1675,14 +1674,11 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
}
int cfg80211_check_combinations(struct wiphy *wiphy,
- const int num_different_channels,
- const u8 radar_detect,
- const int iftype_num[NUM_NL80211_IFTYPES])
+ struct iface_combination_params *params)
{
int err, num = 0;
- err = cfg80211_iter_combinations(wiphy, num_different_channels,
- radar_detect, iftype_num,
+ err = cfg80211_iter_combinations(wiphy, params,
cfg80211_iter_sum_ifcombs, &num);
if (err)
return err;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 0/7] ath9k: EEPROM swapping improvements
From: Kalle Valo @ 2016-10-12 13:18 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, linux-wireless, ath9k-devel, devicetree, arnd,
chunkeey, nbd
In-Reply-To: <20161002222913.12223-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> There are two types of swapping the EEPROM data in the ath9k driver.
> Before this series one type of swapping could not be used without the
> other.
>
> The first type of swapping looks at the "magic bytes" at the start of
> the EEPROM data and performs swab16 on the EEPROM contents if needed.
> The second type of swapping is EEPROM format specific and swaps
> specific fields within the EEPROM itself (swab16, swab32 - depends on
> the EEPROM format).
>
> With this series the second part now looks at the EEPMISC register
> inside the EEPROM, which uses a bit to indicate if the EEPROM data
> is Big Endian (this is also done by the FreeBSD kernel).
> This has a nice advantage: currently there are some out-of-tree hacks
> (in OpenWrt and LEDE) where the EEPROM has a Big Endian header on a
> Big Endian system (= no swab16 is performed) but the EEPROM itself
> indicates that it's data is Little Endian. Until now the out-of-tree
> code simply did a swab16 before passing the data to ath9k, so ath9k
> first did the swab16 - this also enabled the format specific swapping.
> These out-of-tree hacks are still working with the new logic, but it
> is recommended to remove them. This implementation is based on a
> discussion with Arnd Bergmann who raised concerns about the
> robustness and portability of the swapping logic in the original OF
> support patch review, see [0].
>
> After a second round of patches (= v1 of this series) neither Arnd
> Bergmann nor I were really happy with the complexity of the EEPROM
> swapping logic. Based on a discussion (see [1] and [2]) we decided
> that ath9k should use a defined format (specifying the endianness
> of the data - I went with __le16 and __le32) when accessing the
> EEPROM fields. A benefit of this is that we enable the EEPMISC based
> swapping logic by default, just like the FreeBSD driver, see [3]. On
> the devices which I have tested (see below) ath9k now works without
> having to specify the "endian_check" field in ath9k_platform_data (or
> a similar logic which could provide this via devicetree) as ath9k now
> detects the endianness automatically. Only EEPROMs which are mangled
> by some out-of-tree code still need the endian_check flag (or one can
> simply remove that mangling from the out-of-tree code).
>
> Testing:
> - tested by myself on AR9287 with Big Endian EEPROM
> - tested by myself on AR9227 with Little Endian EEPROM
> - tested by myself on AR9381 (using the ar9003_eeprom implementation,
> which did not suffer from this whole problem)
> - how do we proceed with testing? maybe we could keep this in a
> feature-branch and add these patches to LEDE once we have an ACK to
> get more people to test this
>
> This series depends on my other series (v7):
> "add devicetree support to ath9k" - see [4]
I think this looks pretty good. If there's a bug somewhere it should be
quite easy to fix so I'm not that worried and would be willing to take
these as soon as I have applied the dependency series. IIRC your
devicetree patches will have at least one more review round so that will
take some time still. In the meantime it would be great if LEDE folks
could take a look at these and comment (or test).
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Luca Coelho @ 2016-10-12 13:06 UTC (permalink / raw)
To: Paul Bolle, Chris Rorvick
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <1476275787.9670.12.camel@tiscali.nl>
On Wed, 2016-10-12 at 14:36 +0200, Paul Bolle wrote:
> On Wed, 2016-10-12 at 15:24 +0300, Luca Coelho wrote:
> > Okay... Actually this is a structure in the BIOS and the actual method
> > we call is SPLC. The SPLC method may return one item from this table,
> > or something entirely different, possible one of the three values
> > depending on a configuration option or so.
> >
> > Can you to find and send me the actual SPLC method that we call, from
> > your BIOS?
>
>
> It seems Chris and I basically have identical setups, so I'll answer.
Thanks! Yeah, I implied any of you two. ;)
> There are 20 SPLC methods in the BIOS. The first reads
> Method (SPLC, 0, Serialized)
> {
> DerefOf (SPLX [One]) [Zero] = DOM1 /* \DOM1 */
> DerefOf (SPLX [One]) [One] = LIM1 /* \LIM1 */
> DerefOf (SPLX [One]) [0x02] = TIM1 /* \TIM1 */
> DerefOf (SPLX [0x02]) [Zero] = DOM2 /* \DOM2 */
> DerefOf (SPLX [0x02]) [One] = LIM2 /* \LIM2 */
> DerefOf (SPLX [0x02]) [0x02] = TIM2 /* \TIM2 */
> DerefOf (SPLX [0x03]) [Zero] = DOM3 /* \DOM3 */
> DerefOf (SPLX [0x03]) [One] = LIM3 /* \LIM3 */
> DerefOf (SPLX [0x03]) [0x02] = TIM3 /* \TIM3 */
> Return (SPLX) /* \_SB_.PCI0.RP01.PXSX.SPLX */
> }
>
> The only difference is in the last comment. Ie, RP01 is increased until
> it reaches RP20. (The machine has 20 PCI devices according to lspci. I
> have no clue how to match that RPxx number to the 20 devices showing up
> in lspci, sorry.)
No problem, these BIOSes are usually quite cryptic. :) But what you're
saying makes sense. They have added the SPLC method to all PCI root-
ports (which is what RP stands for here).
And, the values in the SPLX structs are being changed here, to DOM1,
LIM1, TIM1 etc., before being returned. This also matches your
description that, at runtime, you got something different than the pure
dump. If you follow these DOM*, LIM*, TIM* symbols, you'll probably
end up getting the values you observed at runtime.
Basically this tells me that indeed 3 "structs" are being returned (as
your dumps already showed). And, according to the specs that I found
(which unfortunately are confidential, so I can't share) this is
correct and the driver code is broken.
I'll send you a patch for testing soon.
Thanks for all the help!
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH v3 1/2] ath10k: clean up HTT tx buffer allocation and free
From: Mohammed Shafi Shajakhan @ 2016-10-12 13:26 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
cleanup 'ath10k_htt_tx_alloc' by introducing the API's
'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
re-use them whereever needed
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_tx.c | 75 ++++++++++++++++++++----------
1 file changed, 50 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index ae5b33f..ab2ee90 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -229,6 +229,32 @@ void ath10k_htt_tx_free_msdu_id(struct ath10k_htt *htt, u16 msdu_id)
idr_remove(&htt->pending_tx, msdu_id);
}
+static void ath10k_htt_tx_free_cont_txbuf(struct ath10k_htt *htt)
+{
+ struct ath10k *ar = htt->ar;
+ size_t size;
+
+ if (!htt->txbuf.vaddr)
+ return;
+
+ size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+ dma_free_coherent(ar->dev, size, htt->txbuf.vaddr, htt->txbuf.paddr);
+}
+
+static int ath10k_htt_tx_alloc_cont_txbuf(struct ath10k_htt *htt)
+{
+ struct ath10k *ar = htt->ar;
+ size_t size;
+
+ size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+ htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size, &htt->txbuf.paddr,
+ GFP_KERNEL);
+ if (!htt->txbuf.vaddr)
+ return -ENOMEM;
+
+ return 0;
+}
+
static void ath10k_htt_tx_free_cont_frag_desc(struct ath10k_htt *htt)
{
size_t size;
@@ -310,10 +336,26 @@ static int ath10k_htt_tx_alloc_txq(struct ath10k_htt *htt)
return 0;
}
+static void ath10k_htt_tx_free_txdone_fifo(struct ath10k_htt *htt)
+{
+ WARN_ON(!kfifo_is_empty(&htt->txdone_fifo));
+ kfifo_free(&htt->txdone_fifo);
+}
+
+static int ath10k_htt_tx_alloc_txdone_fifo(struct ath10k_htt *htt)
+{
+ int ret;
+ size_t size;
+
+ size = roundup_pow_of_two(htt->max_num_pending_tx);
+ ret = kfifo_alloc(&htt->txdone_fifo, size, GFP_KERNEL);
+ return ret;
+}
+
int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
{
struct ath10k *ar = htt->ar;
- int ret, size;
+ int ret;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt tx max num pending tx %d\n",
htt->max_num_pending_tx);
@@ -321,13 +363,9 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
spin_lock_init(&htt->tx_lock);
idr_init(&htt->pending_tx);
- size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
- htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size,
- &htt->txbuf.paddr,
- GFP_KERNEL);
- if (!htt->txbuf.vaddr) {
- ath10k_err(ar, "failed to alloc tx buffer\n");
- ret = -ENOMEM;
+ ret = ath10k_htt_tx_alloc_cont_txbuf(htt);
+ if (ret) {
+ ath10k_err(ar, "failed to alloc cont tx buffer: %d\n", ret);
goto free_idr_pending_tx;
}
@@ -343,8 +381,7 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
goto free_frag_desc;
}
- size = roundup_pow_of_two(htt->max_num_pending_tx);
- ret = kfifo_alloc(&htt->txdone_fifo, size, GFP_KERNEL);
+ ret = ath10k_htt_tx_alloc_txdone_fifo(htt);
if (ret) {
ath10k_err(ar, "failed to alloc txdone fifo: %d\n", ret);
goto free_txq;
@@ -359,10 +396,7 @@ free_frag_desc:
ath10k_htt_tx_free_cont_frag_desc(htt);
free_txbuf:
- size = htt->max_num_pending_tx *
- sizeof(struct ath10k_htt_txbuf);
- dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
- htt->txbuf.paddr);
+ ath10k_htt_tx_free_cont_txbuf(htt);
free_idr_pending_tx:
idr_destroy(&htt->pending_tx);
@@ -388,22 +422,13 @@ static int ath10k_htt_tx_clean_up_pending(int msdu_id, void *skb, void *ctx)
void ath10k_htt_tx_free(struct ath10k_htt *htt)
{
- int size;
-
idr_for_each(&htt->pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
idr_destroy(&htt->pending_tx);
- if (htt->txbuf.vaddr) {
- size = htt->max_num_pending_tx *
- sizeof(struct ath10k_htt_txbuf);
- dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
- htt->txbuf.paddr);
- }
-
+ ath10k_htt_tx_free_cont_txbuf(htt);
ath10k_htt_tx_free_txq(htt);
ath10k_htt_tx_free_cont_frag_desc(htt);
- WARN_ON(!kfifo_is_empty(&htt->txdone_fifo));
- kfifo_free(&htt->txdone_fifo);
+ ath10k_htt_tx_free_txdone_fifo(htt);
}
void ath10k_htt_htc_tx_complete(struct ath10k *ar, struct sk_buff *skb)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 2/2] ath10k: Remove extraneous error message in tx alloc
From: Mohammed Shafi Shajakhan @ 2016-10-12 13:26 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1476278778-4253-1-git-send-email-mohammed@qca.qualcomm.com>
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Remove extraneous error message in 'ath10k_htt_tx_alloc_cont_frag_desc'
as the caller 'ath10k_htt_tx_alloc' already dumps a proper error
message
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_tx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index ab2ee90..ccbc8c03 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -282,10 +282,8 @@ static int ath10k_htt_tx_alloc_cont_frag_desc(struct ath10k_htt *htt)
htt->frag_desc.vaddr = dma_alloc_coherent(ar->dev, size,
&htt->frag_desc.paddr,
GFP_KERNEL);
- if (!htt->frag_desc.vaddr) {
- ath10k_err(ar, "failed to alloc fragment desc memory\n");
+ if (!htt->frag_desc.vaddr)
return -ENOMEM;
- }
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Kalle Valo @ 2016-10-12 13:34 UTC (permalink / raw)
To: Vittorio Gambaletta (VittGam)
Cc: linux-wireless, ath9k-devel, ath9k-devel, stable
In-Reply-To: <cd3ff141b0ba69399a377a96a9ae75fb@vittgam.net>
"Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
> Hello,
>
> On 04/10/2016 17:46:44 CEST, Kalle Valo wrote:
>> "Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
>>
>>> If generic entries are positioned above specific ones, then the
>>> former will be matched first and used instead of the latter.
>>>
>>> Cc: <linux-wireless@vger.kernel.org>
>>> Cc: <ath9k-devel@qca.qualcomm.com>
>>> Cc: <ath9k-devel@lists.ath9k.org>
>>> Cc: <stable@vger.kernel.org>
>>> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
>>
>> Why? What kind of bug you are fixing? You are not really describing the
>> problem you are trying fix.
>
> The active_high LED of my Wistron DNMA-92 is still being recognized as
> active_low on 4.7.6 mainline.
This kind of information is important, always add that to the commit log
so that we don't need to guess.
> When I was preparing my former patch to fix that, I initially added the
> PCI_DEVICE_SUB section for 0x0029/0x2096 above the PCI_VDEVICE section
> for 0x0029; but then I moved the former below the latter after seeing
> how 0x002A sections were sorted in the file.
>
> I must have somehow messed up with testing, because I tested the final
> version of that patch before sending it, and it was apparently working;
> but now it is not working on 4.7.6 mainline.
>
> With this patch, 0x0029/0x2096 has finally got active_high LED on
> 4.7.6.
I'm confused, are you now saying that this patch doesn't work?
> So, after seeing that the rest of the file is sorted this way (generic
> section after the specific ones), I concluded that the 0x002A sorting
> was wrong in the first place, and so is 0x0029. Then I sent this patch
> to fix this.
I can't see how changing the order in ath_pci_id_table[] would make any
difference in functionality, but I might be missing something.
>> And your email headers look weird:
>>
>> To: <kvalo@codeaurora.org>
>> Cc: <linux-wireless@vger.kernel.org>
>> Cc: <ath9k-devel@qca.qualcomm.com>
>> Cc: <ath9k-devel@venema.h4ckr.net>
>> Cc: <stable@vger.kernel.org>
>> Date: Mon, 3 Oct 2016 12:00:56 +0200
>>
>> What software are you using to send this? Only one CC header is valid
>> according to the spec (thanks to Luca for checking) even though mailers
>> seem to handle multiple CC headers. But for example my patchwork script
>> fails with this and uses only the first CC header.
>
> Sorry about this, I used a custom mailer to send the patch since I was
> having problems with git-send-email...
Ok, that explains it.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4
From: Yeoh Chun-Yeow @ 2016-10-12 13:36 UTC (permalink / raw)
To: Valo, Kalle
Cc: Kolli, Anilkumar, akolli@codeaurora.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <87r37mgo1n.fsf@kamboji.qca.qualcomm.com>
>
> My understanding is that 10.2 branch does not have this feature,
> unfortunately.
>
Alright, noted.
Is QCA988X going to have firmware 10.4 support?
---
Chun-Yeow
^ permalink raw reply
* Re: QCA9887 Firmware Memory Usage
From: Valo, Kalle @ 2016-10-12 13:51 UTC (permalink / raw)
To: David Hutchison
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <CA+i30h8YsG7mce5FMwGw2fRNAn3USYV6K==QMjMQVeSGB0dj=w@mail.gmail.com>
David Hutchison <dhutchison@bluemesh.net> writes:
> I am using a Mikrotik hAP AC Lite which has a QCA9887 radio. It
> appears to be working; however ath10k ( or the qca9887 firmware ) is
> utilizing 15 - 20mb of memory. I applied the kfree(caldata) patch, to
> insure there is no memory leak.
>
> It doesn't appear to be leaking, and it will run Ok with the high
> memory footprint. However the Mikrotik hAP AC Lite is only a 64mb
> platform; so when I initialize the 2nd radio with ath9k I get OOMs.
>
> It just doesn't seem right that when ath10k + qca9887 is in AP mode
> that it's utilizing as much memory as it is. I don't think the issue
> is with ath10k, I think it's the qca9887 firmware (
> firmware-5.bin_10.2.4-1.0-00013 ).
>
> Is there a newer build available that may potentially fix these memory
> issues? The latest one available on
> https://github.com/kvalo/ath10k-firmware/blob/master/QCA9887/hw1.0/firmwa=
re-5.bin_10.2.4-1.0-00013
> is 2 months old. Perhaps there is a newer build to test that may have
> the fix?
>
> Any thoughts as to what it could be? I can provide more information if ne=
eded.
64MB of RAM nowadays is not much and ath10k is not really tested in such
setups AFAIK. I guess you could try if reducing TARGET_10X_NUM_MSDU_DESC
helps with the memory consumption, but no idea if that would even work
without further modifications to ath10k.
Also if you have fq-codel&co enabled that might increase memory
consumption. Adding linux-wireless as people there might have better
ideas.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4
From: Valo, Kalle @ 2016-10-12 13:59 UTC (permalink / raw)
To: Yeoh Chun-Yeow
Cc: Kolli, Anilkumar, akolli@codeaurora.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <CAEFj9859-wSpMGJrr+Fzr8QZASBs2r-W3XByH+PD_5h8zMS-rQ@mail.gmail.com>
Yeoh Chun-Yeow <yeohchunyeow@gmail.com> writes:
>> My understanding is that 10.2 branch does not have this feature,
>> unfortunately.
>>
>
> Alright, noted.
>
> Is QCA988X going to have firmware 10.4 support?
I wish it would have but I don't know the current status.
--=20
Kalle Valo=
^ permalink raw reply
* Re: QCA9887 Firmware Memory Usage
From: Sebastian Gottschall @ 2016-10-12 14:12 UTC (permalink / raw)
To: Valo, Kalle, David Hutchison
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <8760oxfzg4.fsf@kamboji.qca.qualcomm.com>
Am 12.10.2016 um 15:51 schrieb Valo, Kalle:
> David Hutchison <dhutchison@bluemesh.net> writes:
>
>> I am using a Mikrotik hAP AC Lite which has a QCA9887 radio. It
>> appears to be working; however ath10k ( or the qca9887 firmware ) is
>> utilizing 15 - 20mb of memory. I applied the kfree(caldata) patch, to
>> insure there is no memory leak.
>>
>> It doesn't appear to be leaking, and it will run Ok with the high
>> memory footprint. However the Mikrotik hAP AC Lite is only a 64mb
>> platform; so when I initialize the 2nd radio with ath9k I get OOMs.
>>
>> It just doesn't seem right that when ath10k + qca9887 is in AP mode
>> that it's utilizing as much memory as it is. I don't think the issue
>> is with ath10k, I think it's the qca9887 firmware (
>> firmware-5.bin_10.2.4-1.0-00013 ).
>>
>> Is there a newer build available that may potentially fix these memory
>> issues? The latest one available on
>> https://github.com/kvalo/ath10k-firmware/blob/master/QCA9887/hw1.0/firmware-5.bin_10.2.4-1.0-00013
>> is 2 months old. Perhaps there is a newer build to test that may have
>> the fix?
>>
>> Any thoughts as to what it could be? I can provide more information if needed.
> 64MB of RAM nowadays is not much and ath10k is not really tested in such
> setups AFAIK. I guess you could try if reducing TARGET_10X_NUM_MSDU_DESC
> helps with the memory consumption, but no idea if that would even work
> without further modifications to ath10k.
>
> Also if you have fq-codel&co enabled that might increase memory
> consumption. Adding linux-wireless as people there might have better
the high memory consumption is a very common old problem. and no, 64 mb
might not by much. but consider that qca9880 cards for instance are only
used on embedded devices.
there is not even a windows driver available for it. its mainly used in
routers and 64 mb ram is not uncommon here.
the problem with qca9887 sounds similar here. and the best. it only
occures on ath10k. with the closed source qca driver it will work on
embedded platforms. since
it was mentioned that this problem is caused by the firmware itself. so
there wont be a solution until qca is finally getting in touch with this
problem
> ideas.
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Sergey Senozhatsky @ 2016-10-12 14:12 UTC (permalink / raw)
To: Johannes Berg
Cc: Sergey Senozhatsky, Andy Lutomirski, David S. Miller,
linux-wireless, netdev, linux-kernel, Sergey Senozhatsky,
linux-next, Stephen Rothwell, Herbert Xu
In-Reply-To: <1476263106.5271.23.camel@sipsolutions.net>
Hello,
On (10/12/16 11:05), Johannes Berg wrote:
> Sorry - I meant to look into this yesterday but forgot.
>
> > Andy, can this be related to CONFIG_VMAP_STACK?
>
> I think it is.
yeah, the system works fine with !CONFIG_VMAP_STACK.
> > > current -git kills my system.
>
> Can you elaborate on how exactly it kills your system?
the last time I saw it it was a NULL deref at ieee80211_aes_ccm_decrypt.
-ss
^ permalink raw reply
* Re: [PATCH] rsi: fix memory lean in module unload
From: Kalle Valo @ 2016-10-12 14:14 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk
In-Reply-To: <1474437546-6590-1-git-send-email-prameela.j04cs@gmail.com>
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
> Moved debugfs entry removal under CONFIG_RSI_DEBUGFS flag
> Added freeing of below structures
> * channels list in each supported band
> * rsi debugfs info
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
There are four similar patches without any version information:
[ 1] rsi: fix memory leak in debugfs entry and supported bands 2016-09-19 Prameela Ran Deferred
[ 2] [1/1] rsi: fix memory leak in debugfs entry and supported... 2016-09-20 Prameela Ran Deferred
[ 3] rsi: fix memory lean in module unload 2016-09-21 Prameela Ran Deferred
[ 4] rsi: fix memory leak in module unload 2016-09-21 Prameela Ran Deferred
When sending a new version of the patch please add a version number to
it. See the instructions for more:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject_name
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Vittorio Gambaletta (VittGam) @ 2016-10-12 14:13 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath9k-devel, ath9k-devel, stable
In-Reply-To: <87eg3lg07d.fsf@kamboji.qca.qualcomm.com>
Hello,
On 12/10/2016 15:34:46 CEST, Kalle Valo wrote:
> "Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
>
>> Hello,
>>
>> On 04/10/2016 17:46:44 CEST, Kalle Valo wrote:
>>> "Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
>>>
>>>> If generic entries are positioned above specific ones, then the
>>>> former will be matched first and used instead of the latter.
>>>>
>>>> Cc: <linux-wireless@vger.kernel.org>
>>>> Cc: <ath9k-devel@qca.qualcomm.com>
>>>> Cc: <ath9k-devel@lists.ath9k.org>
>>>> Cc: <stable@vger.kernel.org>
>>>> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
>>>
>>> Why? What kind of bug you are fixing? You are not really describing the
>>> problem you are trying fix.
>>
>> The active_high LED of my Wistron DNMA-92 is still being recognized as
>> active_low on 4.7.6 mainline.
>
> This kind of information is important, always add that to the commit log
> so that we don't need to guess.
Okay, sorry about missing that before.
>> When I was preparing my former patch to fix that, I initially added the
>> PCI_DEVICE_SUB section for 0x0029/0x2096 above the PCI_VDEVICE section
>> for 0x0029; but then I moved the former below the latter after seeing
>> how 0x002A sections were sorted in the file.
>>
>> I must have somehow messed up with testing, because I tested the final
>> version of that patch before sending it, and it was apparently working;
>> but now it is not working on 4.7.6 mainline.
>>
>> With this patch, 0x0029/0x2096 has finally got active_high LED on
>> 4.7.6.
>
> I'm confused, are you now saying that this patch doesn't work?
No: the previous patch (which is already merged and added the LED driver_data
for my card) doesn't work. This one does work.
>> So, after seeing that the rest of the file is sorted this way (generic
>> section after the specific ones), I concluded that the 0x002A sorting
>> was wrong in the first place, and so is 0x0029. Then I sent this patch
>> to fix this.
>
> I can't see how changing the order in ath_pci_id_table[] would make any
> difference in functionality, but I might be missing something.
It does: I've looked through the relevant code, and found that PCI device
matching from that table is done sequentially in pci_match_id() from
drivers/pci/pci-driver.c.
So if a generic PCI_VDEVICE entry (that has both subvendor and subdevice IDs
set to PCI_ANY_ID) is put before a more specific one (PCI_DEVICE_SUB), then
the generic PCI_VDEVICE entry will match first and will be used.
>>> And your email headers look weird:
>>>
>>> To: <kvalo@codeaurora.org>
>>> Cc: <linux-wireless@vger.kernel.org>
>>> Cc: <ath9k-devel@qca.qualcomm.com>
>>> Cc: <ath9k-devel@venema.h4ckr.net>
>>> Cc: <stable@vger.kernel.org>
>>> Date: Mon, 3 Oct 2016 12:00:56 +0200
>>>
>>> What software are you using to send this? Only one CC header is valid
>>> according to the spec (thanks to Luca for checking) even though mailers
>>> seem to handle multiple CC headers. But for example my patchwork script
>>> fails with this and uses only the first CC header.
>>
>> Sorry about this, I used a custom mailer to send the patch since I was
>> having problems with git-send-email...
>
> Ok, that explains it.
^ permalink raw reply
* Re: [PATCH] rsi: fix memory leak in module unload
From: Kalle Valo @ 2016-10-12 14:22 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, xypron.glpk,
prameela.garnepudi
In-Reply-To: <1474447162-19956-1-git-send-email-prameela.j04cs@gmail.com>
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> writes:
> debugfs entry removal statement moved inside CONFIG_RSI_DEBUGSFS flag
> added freeing of below structures
> * channel list for each supported band
> * rsi debugfs info
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
[...]
> --- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> @@ -194,6 +194,7 @@ static void rsi_register_rates_channels(struct rsi_hw *adapter, int band)
> void rsi_mac80211_detach(struct rsi_hw *adapter)
> {
> struct ieee80211_hw *hw = adapter->hw;
> + enum nl80211_band band;
>
> if (hw) {
> ieee80211_stop_queues(hw);
> @@ -201,7 +202,17 @@ void rsi_mac80211_detach(struct rsi_hw *adapter)
> ieee80211_free_hw(hw);
> }
>
> + for (band = 0; band < 2; band++) {
> + struct ieee80211_supported_band *sband =
> + &adapter->sbands[band];
> +
> + kfree(sband->channels);
> + }
Like Arend already mentioned[1] you should use NUM_NL80211_BANDS here
instead of hardcoded value. Yes, that will also go through
NL80211_BAND_60GHZ item but it doesn't matter as it should be empty
anyway.
[1] https://patchwork.kernel.org/patch/9341095/
--
Kalle Valo
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-12 14:22 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andy Lutomirski, David S. Miller, linux-wireless, netdev,
linux-kernel, Sergey Senozhatsky, linux-next, Stephen Rothwell,
Herbert Xu
In-Reply-To: <20161012141245.GA436@swordfish>
> > Can you elaborate on how exactly it kills your system?
>
> the last time I saw it it was a NULL deref at
> ieee80211_aes_ccm_decrypt.
Hm. I was expecting something within the crypto code would cause the
crash, this seems strange.
Anyway, I'm surely out of my depth wrt. the actual cause. Something
like the patch below probably works around it, but it's horribly
inefficient due to the locking and doesn't cover CMAC/GMAC either.
johannes
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 103187ca9474..e820f437f02e 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -27,6 +27,7 @@
#include <linux/leds.h>
#include <linux/idr.h>
#include <linux/rhashtable.h>
+#include <crypto/aes.h>
#include <net/ieee80211_radiotap.h>
#include <net/cfg80211.h>
#include <net/mac80211.h>
@@ -1224,6 +1225,10 @@ struct ieee80211_local {
spinlock_t rx_path_lock;
+ /* temporary buffers for software crypto */
+ u8 aad[2 * AES_BLOCK_SIZE];
+ u8 b_0[AES_BLOCK_SIZE];
+
/* Station data */
/*
* The mutex only protects the list, hash table and
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index b48c1e13e281..a3f17a710b85 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -405,8 +405,8 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb,
u8 *pos;
u8 pn[6];
u64 pn64;
- u8 aad[2 * AES_BLOCK_SIZE];
- u8 b_0[AES_BLOCK_SIZE];
+ u8 *aad = tx->local->aad;
+ u8 *b_0 = tx->local->b_0;
if (info->control.hw_key &&
!(info->control.hw_key->flags & IEEE80211_KEY_FLAG_GENERATE_IV) &&
@@ -460,9 +460,11 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb,
return 0;
pos += IEEE80211_CCMP_HDR_LEN;
+ spin_lock_bh(&tx->local->rx_path_lock);
ccmp_special_blocks(skb, pn, b_0, aad);
ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, b_0, aad, pos, len,
skb_put(skb, mic_len), mic_len);
+ spin_unlock_bh(&tx->local->rx_path_lock);
return 0;
}
@@ -534,8 +536,9 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
}
if (!(status->flag & RX_FLAG_DECRYPTED)) {
- u8 aad[2 * AES_BLOCK_SIZE];
- u8 b_0[AES_BLOCK_SIZE];
+ u8 *aad = rx->local->aad;
+ u8 *b_0 = rx->local->b_0;
+
/* hardware didn't decrypt/verify MIC */
ccmp_special_blocks(skb, pn, b_0, aad);
@@ -639,8 +642,8 @@ static int gcmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
u8 *pos;
u8 pn[6];
u64 pn64;
- u8 aad[2 * AES_BLOCK_SIZE];
- u8 j_0[AES_BLOCK_SIZE];
+ u8 *aad = tx->local->aad;
+ u8 *j_0 = tx->local->b_0;
if (info->control.hw_key &&
!(info->control.hw_key->flags & IEEE80211_KEY_FLAG_GENERATE_IV) &&
@@ -695,9 +698,11 @@ static int gcmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
return 0;
pos += IEEE80211_GCMP_HDR_LEN;
+ spin_lock_bh(&tx->local->rx_path_lock);
gcmp_special_blocks(skb, pn, j_0, aad);
ieee80211_aes_gcm_encrypt(key->u.gcmp.tfm, j_0, aad, pos, len,
skb_put(skb, IEEE80211_GCMP_MIC_LEN));
+ spin_unlock_bh(&tx->local->rx_path_lock);
return 0;
}
@@ -764,8 +769,9 @@ ieee80211_crypto_gcmp_decrypt(struct ieee80211_rx_data *rx)
}
if (!(status->flag & RX_FLAG_DECRYPTED)) {
- u8 aad[2 * AES_BLOCK_SIZE];
- u8 j_0[AES_BLOCK_SIZE];
+ u8 *aad = rx->local->aad;
+ u8 *j_0 = rx->local->b_0;
+
/* hardware didn't decrypt/verify MIC */
gcmp_special_blocks(skb, pn, j_0, aad);
^ permalink raw reply related
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