* [PATCH 2/7] mac80211: fix tid_agg_rx NULL dereference
From: Luca Coelho @ 2016-10-18 20:12 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20161018201213.18873-1-luca@coelho.fi>
From: Johannes Berg <johannes.berg@intel.com>
On drivers setting the SUPPORTS_REORDERING_BUFFER hardware flag,
we crash when the peer sends an AddBA request while we already
have a session open on the seame TID; this is because on those
drivers, the tid_agg_rx is left NULL even though the session is
valid, and the agg_session_valid bit is set.
To fix this, store the dialog tokens outside the tid_agg_rx to
be able to compare them to the received AddBA request.
Fixes: f89e07d4cf26 ("mac80211: agg-rx: refuse ADDBA Request with timeout update")
Reported-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/agg-rx.c | 8 ++------
net/mac80211/debugfs_sta.c | 2 +-
net/mac80211/sta_info.h | 4 ++--
3 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index f6749dc..3b5fd41 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -315,11 +315,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
mutex_lock(&sta->ampdu_mlme.mtx);
if (test_bit(tid, sta->ampdu_mlme.agg_session_valid)) {
- tid_agg_rx = rcu_dereference_protected(
- sta->ampdu_mlme.tid_rx[tid],
- lockdep_is_held(&sta->ampdu_mlme.mtx));
-
- if (tid_agg_rx->dialog_token == dialog_token) {
+ if (sta->ampdu_mlme.tid_rx_token[tid] == dialog_token) {
ht_dbg_ratelimited(sta->sdata,
"updated AddBA Req from %pM on tid %u\n",
sta->sta.addr, tid);
@@ -396,7 +392,6 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
}
/* update data */
- tid_agg_rx->dialog_token = dialog_token;
tid_agg_rx->ssn = start_seq_num;
tid_agg_rx->head_seq_num = start_seq_num;
tid_agg_rx->buf_size = buf_size;
@@ -418,6 +413,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
if (status == WLAN_STATUS_SUCCESS) {
__set_bit(tid, sta->ampdu_mlme.agg_session_valid);
__clear_bit(tid, sta->ampdu_mlme.unexpected_agg);
+ sta->ampdu_mlme.tid_rx_token[tid] = dialog_token;
}
mutex_unlock(&sta->ampdu_mlme.mtx);
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index a2fcdb4..14ec63a 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -205,7 +205,7 @@ static ssize_t sta_agg_status_read(struct file *file, char __user *userbuf,
p += scnprintf(p, sizeof(buf) + buf - p, "%02d", i);
p += scnprintf(p, sizeof(buf) + buf - p, "\t\t%x", !!tid_rx);
p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.2x",
- tid_rx ? tid_rx->dialog_token : 0);
+ tid_rx ? sta->ampdu_mlme.tid_rx_token[i] : 0);
p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.3x",
tid_rx ? tid_rx->ssn : 0);
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index ed5fcb9..dd06ef0 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -184,7 +184,6 @@ struct tid_ampdu_tx {
* @ssn: Starting Sequence Number expected to be aggregated.
* @buf_size: buffer size for incoming A-MPDUs
* @timeout: reset timer value (in TUs).
- * @dialog_token: dialog token for aggregation session
* @rcu_head: RCU head used for freeing this struct
* @reorder_lock: serializes access to reorder buffer, see below.
* @auto_seq: used for offloaded BA sessions to automatically pick head_seq_and
@@ -213,7 +212,6 @@ struct tid_ampdu_rx {
u16 ssn;
u16 buf_size;
u16 timeout;
- u8 dialog_token;
bool auto_seq;
bool removed;
};
@@ -225,6 +223,7 @@ struct tid_ampdu_rx {
* to tid_tx[idx], which are protected by the sta spinlock)
* tid_start_tx is also protected by sta->lock.
* @tid_rx: aggregation info for Rx per TID -- RCU protected
+ * @tid_rx_token: dialog tokens for valid aggregation sessions
* @tid_rx_timer_expired: bitmap indicating on which TIDs the
* RX timer expired until the work for it runs
* @tid_rx_stop_requested: bitmap indicating which BA sessions per TID the
@@ -243,6 +242,7 @@ struct sta_ampdu_mlme {
struct mutex mtx;
/* rx */
struct tid_ampdu_rx __rcu *tid_rx[IEEE80211_NUM_TIDS];
+ u8 tid_rx_token[IEEE80211_NUM_TIDS];
unsigned long tid_rx_timer_expired[BITS_TO_LONGS(IEEE80211_NUM_TIDS)];
unsigned long tid_rx_stop_requested[BITS_TO_LONGS(IEEE80211_NUM_TIDS)];
unsigned long agg_session_valid[BITS_TO_LONGS(IEEE80211_NUM_TIDS)];
--
2.9.3
^ permalink raw reply related
* [PATCH 0/7] patches for mac80211/cfg80211 2016-10-18
From: Luca Coelho @ 2016-10-18 20:12 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Luca Coelho
From: Luca Coelho <luciano.coelho@intel.com>
Hi Johannes,
Here are a few patches for mac80211/cfg80211 from our internal tree.
You're probably familiar with most of them, I'm just adding a cover
letter to make it easier for you to reply "Applied all" (hopefully).:)
Cheers,
Luca.
Emmanuel Grumbach (2):
mac80211: allow the driver not to pass the tid to
ieee80211_sta_uapsd_trigger
mac80211: uapsd_queues is in QoS IE order
Ilan Peer (1):
cfg80211: Call rdev_disconnect() when connection is in progress
Johannes Berg (3):
wireless: radiotap: fix timestamp sampling position values
mac80211: fix tid_agg_rx NULL dereference
mac80211: improve RX aggregation data in debugfs
Sara Sharon (1):
mac80211: add a HW flag for supporting HW TX fragmentation
drivers/net/wireless/ath/ath10k/mac.c | 1 +
drivers/net/wireless/ti/wlcore/main.c | 1 +
include/net/cfg80211.h | 10 ++++++----
include/net/ieee80211_radiotap.h | 4 ++--
include/net/mac80211.h | 17 ++++++++++++++---
net/mac80211/agg-rx.c | 8 ++------
net/mac80211/debugfs.c | 1 +
net/mac80211/debugfs_sta.c | 9 +++++++--
net/mac80211/ieee80211_i.h | 2 ++
net/mac80211/main.c | 4 ++++
net/mac80211/mlme.c | 2 +-
net/mac80211/rx.c | 6 ++++--
net/mac80211/sta_info.c | 13 ++++++++-----
net/mac80211/sta_info.h | 4 ++--
net/mac80211/tx.c | 4 ++--
net/mac80211/util.c | 7 +++++++
net/mac80211/wpa.c | 2 +-
net/wireless/sme.c | 2 +-
18 files changed, 66 insertions(+), 31 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/7] wireless: radiotap: fix timestamp sampling position values
From: Luca Coelho @ 2016-10-18 20:12 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20161018201213.18873-1-luca@coelho.fi>
From: Johannes Berg <johannes.berg@intel.com>
The values don't match the radiotap spec, corrected that.
Reported-by: Oz Shalev <oz.shalev@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/ieee80211_radiotap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index ba07b9d..d0e7e3f 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -333,9 +333,9 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_TIMESTAMP_UNIT_NS 0x0003
#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_MASK 0x00F0
#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_BEGIN_MDPU 0x0000
-#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_EO_MPDU 0x0010
+#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_PLCP_SIG_ACQ 0x0010
#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_EO_PPDU 0x0020
-#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_PLCP_SIG_ACQ 0x0030
+#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_EO_MPDU 0x0030
#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_UNKNOWN 0x00F0
#define IEEE80211_RADIOTAP_TIMESTAMP_FLAG_64BIT 0x00
--
2.9.3
^ permalink raw reply related
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Johannes Berg @ 2016-10-18 19:56 UTC (permalink / raw)
To: Oliver Zemann, linux-wireless
In-Reply-To: <1dce4f5d-b905-9f26-17f3-d8b1ae0d1b13@gmail.com>
On Tue, 2016-10-18 at 21:44 +0200, Oliver Zemann wrote:
> Is there some way to disable the bluetooth functionality?
>
Not that I know of. It's kinda pointless though since you then wouldn't
have any functionality anyway?
I don't have the board you mentioned to Emmanuel, but I can try the
7260 on the Hummingboard.
I do know that, for example, on my old G5 powermac the newer Intel NICs
cause the system to be unable boot, so there sometimes are PCIe bus
incompatibilities.
johannes
(please quote properly)
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-18 19:44 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1476817578.6425.40.camel@sipsolutions.net>
Is there some way to disable the bluetooth functionality?
Am 18.10.2016 um 21:06 schrieb Johannes Berg:
> On Tue, 2016-10-18 at 18:22 +0200, Oliver Zemann wrote:
>> Because of the problems with the ath10 card, i bought an intel 7260
>> (mpcie) wifi card. Unfortunately it is also not working.
>> I get tons of those messages:
>>
>> [ 175.777030] usb 1-1: new full-speed USB device number 2 using
>> orion-ehci
>> [ 175.933953] usb 1-1: New USB device found, idVendor=8087,
>> idProduct=07dc
>> [ 175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
>> SerialNumber=0
>> [ 175.966954] Bluetooth: hci0: read Intel version:
>> 3707100180012d0d00
>> [ 175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
>> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
>> [ 176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch
>> completed
>> and activated
>> [ 176.749831] usb 1-1: USB disconnect, device number 2
> This is odd. However, it's entirely related to the NICs *Bluetooth*
> function, which lives on USB.
>
>> What's confusing me is that this device is connected through pcie,
>> not usb. When i use lspci i get:
>> [root@alarm log]# lspci
>> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev
>> 04)
>> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev
>> 04)
>> 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac
>> Wireless Network Adapter (rev ff)
>>
>> So the other card is seen as pci device, but the intel is not. I am
>> really lost now.
> The NICs *WiFi* function should be a PCIe device, but the USB
> connect/disconnect cycles suggest that there's something wrong with the
> electrical connection, which presumably causes the PCIe part of the
> device to never appear on the bus.
>
> johannes
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-18 19:31 UTC (permalink / raw)
Cc: linux-wireless
In-Reply-To: <CANUX_P1CaQZwc-=L4U9n+n5kfXW7H3-L05EDeXFYVvh2fddO8A@mail.gmail.com>
I tried 2 of those wifi cards. Both behaved the same. Also on another
clearfog pro. So i guess this is not a hardware fault. Also, the compex
WLE600 works (unfortunately the WLE900 does not).
Am 18.10.2016 um 21:30 schrieb Emmanuel Grumbach:
> On Tue, Oct 18, 2016 at 7:22 PM, Oliver Zemann <oliver.zemann@gmail.com> wrote:
>> Because of the problems with the ath10 card, i bought an intel 7260 (mpcie)
>> wifi card. Unfortunately it is also not working.
>> I get tons of those messages:
>>
>> [ 175.777030] usb 1-1: new full-speed USB device number 2 using orion-ehci
>> [ 175.933953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
>> [ 175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
>> SerialNumber=0
>> [ 175.966954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
>> [ 175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
>> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
>> [ 176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
>> activated
>> [ 176.749831] usb 1-1: USB disconnect, device number 2
>> [ 177.076993] usb 1-1: new full-speed USB device number 3 using orion-ehci
>> [ 177.233953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
>> [ 177.240682] usb 1-1: New USB device strings: Mfr=0, Product=0,
>> SerialNumber=0
>> [ 177.266957] Bluetooth: hci0: read Intel version: 3707100180012d0d00
>> [ 177.273316] Bluetooth: hci0: Intel Bluetooth firmware file:
>> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
>> [ 177.482955] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
>> activated
>> [ 178.046910] usb 1-1: USB disconnect, device number 3
>> [ 178.376958] usb 1-1: new full-speed USB device number 4 using orion-ehci
>> [ 178.533954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
>> [ 178.540682] usb 1-1: New USB device strings: Mfr=0, Product=0,
>> SerialNumber=0
> Hmm... bad connectors? USB seems to think that the device keeps disconnecting.
> But that's the BT part.
>
>> some information about the card:
>> Bus 001 Device 011: ID 8087:07dc Intel Corp.
>> Couldn't open device, some information will be missing
>> Device Descriptor:
>> bLength 18
>> bDescriptorType 1
>> bcdUSB 2.00
>> bDeviceClass 224 Wireless
>> bDeviceSubClass 1 Radio Frequency
>> bDeviceProtocol 1 Bluetooth
>> bMaxPacketSize0 64
>> idVendor 0x8087 Intel Corp.
>> idProduct 0x07dc
>> bcdDevice 0.01
>> iManufacturer 0
>> iProduct 0
>> iSerial 0
>> bNumConfigurations 1
>> Configuration Descriptor:
>> bLength 9
>> bDescriptorType 2
>> wTotalLength 177
>> bNumInterfaces 2
>> bConfigurationValue 1
>> iConfiguration 0
>> bmAttributes 0xe0
>> Self Powered
>> Remote Wakeup
>> MaxPower 100mA
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 0
>> bAlternateSetting 0
>> bNumEndpoints 3
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x81 EP 1 IN
>> bmAttributes 3
>> Transfer Type Interrupt
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0040 1x 64 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x02 EP 2 OUT
>> bmAttributes 2
>> Transfer Type Bulk
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0040 1x 64 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x82 EP 2 IN
>> bmAttributes 2
>> Transfer Type Bulk
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0040 1x 64 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 0
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0000 1x 0 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0000 1x 0 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 1
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0009 1x 9 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0009 1x 9 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 2
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0011 1x 17 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0011 1x 17 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 3
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0019 1x 25 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0019 1x 25 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 4
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0021 1x 33 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0021 1x 33 bytes
>> bInterval 1
>> Interface Descriptor:
>> bLength 9
>> bDescriptorType 4
>> bInterfaceNumber 1
>> bAlternateSetting 5
>> bNumEndpoints 2
>> bInterfaceClass 224 Wireless
>> bInterfaceSubClass 1 Radio Frequency
>> bInterfaceProtocol 1 Bluetooth
>> iInterface 0
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x03 EP 3 OUT
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0031 1x 49 bytes
>> bInterval 1
>> Endpoint Descriptor:
>> bLength 7
>> bDescriptorType 5
>> bEndpointAddress 0x83 EP 3 IN
>> bmAttributes 1
>> Transfer Type Isochronous
>> Synch Type None
>> Usage Type Data
>> wMaxPacketSize 0x0031 1x 49 bytes
>> bInterval 1
>>
>>
>> [root@alarm log]# uname -a
>> Linux alarm 4.4.24-2-ARCH #1 SMP Fri Oct 14 01:04:22 MDT 2016 armv7l
>> GNU/Linux
>>
>> What's confusing me is that this device is connected through pcie, not usb.
>> When i use lspci i get:
>> [root@alarm log]# lspci
>> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
>> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
>> 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless
>> Network Adapter (rev ff)
>>
>> So the other card is seen as pci device, but the intel is not. I am really
>> lost now.
> So is the NIC :) It is lost. If it doesn't appear in the enumeration,
> it seems you have a bad platform issue. the arm thing in your uname -a
> hints me that you can't really talk your OEM, right?
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Emmanuel Grumbach @ 2016-10-18 19:30 UTC (permalink / raw)
To: Oliver Zemann; +Cc: linux-wireless
In-Reply-To: <fa098763-cdf6-03f8-6d75-0fa9dfb270e4@gmail.com>
On Tue, Oct 18, 2016 at 7:22 PM, Oliver Zemann <oliver.zemann@gmail.com> wrote:
> Because of the problems with the ath10 card, i bought an intel 7260 (mpcie)
> wifi card. Unfortunately it is also not working.
> I get tons of those messages:
>
> [ 175.777030] usb 1-1: new full-speed USB device number 2 using orion-ehci
> [ 175.933953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
> [ 175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [ 175.966954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
> [ 175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
> [ 176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
> activated
> [ 176.749831] usb 1-1: USB disconnect, device number 2
> [ 177.076993] usb 1-1: new full-speed USB device number 3 using orion-ehci
> [ 177.233953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
> [ 177.240682] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [ 177.266957] Bluetooth: hci0: read Intel version: 3707100180012d0d00
> [ 177.273316] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
> [ 177.482955] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
> activated
> [ 178.046910] usb 1-1: USB disconnect, device number 3
> [ 178.376958] usb 1-1: new full-speed USB device number 4 using orion-ehci
> [ 178.533954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
> [ 178.540682] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
Hmm... bad connectors? USB seems to think that the device keeps disconnecting.
But that's the BT part.
> some information about the card:
> Bus 001 Device 011: ID 8087:07dc Intel Corp.
> Couldn't open device, some information will be missing
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 224 Wireless
> bDeviceSubClass 1 Radio Frequency
> bDeviceProtocol 1 Bluetooth
> bMaxPacketSize0 64
> idVendor 0x8087 Intel Corp.
> idProduct 0x07dc
> bcdDevice 0.01
> iManufacturer 0
> iProduct 0
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 177
> bNumInterfaces 2
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xe0
> Self Powered
> Remote Wakeup
> MaxPower 100mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 1
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0009 1x 9 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0009 1x 9 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 2
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0011 1x 17 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0011 1x 17 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 3
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0019 1x 25 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0019 1x 25 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 4
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0021 1x 33 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0021 1x 33 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 5
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0031 1x 49 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0031 1x 49 bytes
> bInterval 1
>
>
> [root@alarm log]# uname -a
> Linux alarm 4.4.24-2-ARCH #1 SMP Fri Oct 14 01:04:22 MDT 2016 armv7l
> GNU/Linux
>
> What's confusing me is that this device is connected through pcie, not usb.
> When i use lspci i get:
> [root@alarm log]# lspci
> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
> 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless
> Network Adapter (rev ff)
>
> So the other card is seen as pci device, but the intel is not. I am really
> lost now.
So is the NIC :) It is lost. If it doesn't appear in the enumeration,
it seems you have a bad platform issue. the arm thing in your uname -a
hints me that you can't really talk your OEM, right?
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Johannes Berg @ 2016-10-18 19:20 UTC (permalink / raw)
To: Jani Nikula, Markus Heiser; +Cc: Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <87eg3dvhdi.fsf@intel.com>
> This could probably be argued either way...
Yeah, I guess it could :)
> My view has been all along that we should prefer to use existing
> extensions written and maintained by others. Perhaps we (the kind of
> royal "we" of which I'm personally really not part of) could take on
> maintainership of some extensions in the interest of improving kernel
> documentation, but I think the goal should be that the extensions are
> maintained outside of the kernel tree, that the extensions are
> generally usable, and have a chance of attracting attention and
> contributions from outside of the kernel community. (Note that this
> doesn't preclude us from shipping the extensions in the kernel tree,
> as long as it's updated from the upstream, not forked.)
Right. I tend to agree, though in the particular case I'm looking at
we'd probably have to fork outside the kernel, forming a new upstream,
and then ship that version (or perhaps rewrite it, forming a new
upstream, and then ship that - doesn't matter all that much)
> (This is one part of me being unhappy about making it easy to run
> arbitrary scripts to produce documentation; those will never be
> generic, and we'll never be able to offload their maintenance outside
> of the kernel. We should not think that we have some really special
> needs in the kernel.)
I agree that we don't necessarily have any special needs (*), but in
cases like this (**) it does seem more practical to just ship the
plugin with the kernel. Whether or not a separate "upstream" is formed
for it could be a secondary question, although it does seem better to
do so.
(*) although not wanting to ship binary files *is* kinda special :)
(**) where the upstream is essentially dead (for all I can tell) and
severely limited to the point where a rewrite will be a better choice.
Anyway, I'll have to see if we (Intel Linux WiFi team) actually want to
do things this way. Using the existing blockdiag/seqdiag is practical
since it all exists already. OTOH, a simpler and better-looking
solution would also be nice, so if we do go this way I'll investigate
more what we can do around this.
johannes
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Johannes Berg @ 2016-10-18 19:09 UTC (permalink / raw)
To: Oliver Zemann, linux-wireless
In-Reply-To: <1476817578.6425.40.camel@sipsolutions.net>
On Tue, 2016-10-18 at 21:06 +0200, Johannes Berg wrote:
>
> The NICs *WiFi* function should be a PCIe device, but the USB
> connect/disconnect cycles suggest that there's something wrong with
> the
> electrical connection, which presumably causes the PCIe part of the
> device to never appear on the bus.
>
Also, FWIW, I had our later NIC (8260) running on an ARMv7 (a
Hummingboard Pro i2ex or so), in both little (default) and big endian
modes. I haven't tried the 7260 but conceivably could.
johannes
^ permalink raw reply
* Re: Intel 7260 not working on 4.4.24 / armv7
From: Johannes Berg @ 2016-10-18 19:06 UTC (permalink / raw)
To: Oliver Zemann, linux-wireless
In-Reply-To: <fa098763-cdf6-03f8-6d75-0fa9dfb270e4@gmail.com>
On Tue, 2016-10-18 at 18:22 +0200, Oliver Zemann wrote:
> Because of the problems with the ath10 card, i bought an intel 7260
> (mpcie) wifi card. Unfortunately it is also not working.
> I get tons of those messages:
>
> [ 175.777030] usb 1-1: new full-speed USB device number 2 using
> orion-ehci
> [ 175.933953] usb 1-1: New USB device found, idVendor=8087,
> idProduct=07dc
> [ 175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [ 175.966954] Bluetooth: hci0: read Intel version:
> 3707100180012d0d00
> [ 175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
> [ 176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch
> completed
> and activated
> [ 176.749831] usb 1-1: USB disconnect, device number 2
This is odd. However, it's entirely related to the NICs *Bluetooth*
function, which lives on USB.
> What's confusing me is that this device is connected through pcie,
> not usb. When i use lspci i get:
> [root@alarm log]# lspci
> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev
> 04)
> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev
> 04)
> 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac
> Wireless Network Adapter (rev ff)
>
> So the other card is seen as pci device, but the intel is not. I am
> really lost now.
The NICs *WiFi* function should be a PCIe device, but the USB
connect/disconnect cycles suggest that there's something wrong with the
electrical connection, which presumably causes the PCIe part of the
device to never appear on the bus.
johannes
^ permalink raw reply
* Intel 7260 not working on 4.4.24 / armv7
From: Oliver Zemann @ 2016-10-18 16:22 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <80788796-5768-1650-dcef-59ccfbe7be6f@gmail.com>
Because of the problems with the ath10 card, i bought an intel 7260
(mpcie) wifi card. Unfortunately it is also not working.
I get tons of those messages:
[ 175.777030] usb 1-1: new full-speed USB device number 2 using orion-ehci
[ 175.933953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 175.966954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 176.749831] usb 1-1: USB disconnect, device number 2
[ 177.076993] usb 1-1: new full-speed USB device number 3 using orion-ehci
[ 177.233953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 177.240682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 177.266957] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 177.273316] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 177.482955] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 178.046910] usb 1-1: USB disconnect, device number 3
[ 178.376958] usb 1-1: new full-speed USB device number 4 using orion-ehci
[ 178.533954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 178.540682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 178.566973] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 178.573315] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 178.782953] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 179.356044] usb 1-1: USB disconnect, device number 4
[ 179.686915] usb 1-1: new full-speed USB device number 5 using orion-ehci
[ 179.842952] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 179.849680] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 179.878956] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 179.885298] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 180.094953] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 180.650673] usb 1-1: USB disconnect, device number 5
[ 180.976877] usb 1-1: new full-speed USB device number 6 using orion-ehci
[ 181.132954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 181.139682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 181.165957] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 181.172311] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 181.381955] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 181.950509] usb 1-1: USB disconnect, device number 6
[ 182.276841] usb 1-1: new full-speed USB device number 7 using orion-ehci
[ 182.432953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 182.439681] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 182.465956] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 182.472309] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 182.681956] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 183.247916] usb 1-1: USB disconnect, device number 7
[ 183.576809] usb 1-1: new full-speed USB device number 8 using orion-ehci
[ 183.732954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 183.739682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 183.765954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 183.772307] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 183.982955] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 184.552876] usb 1-1: USB disconnect, device number 8
[ 184.886772] usb 1-1: new full-speed USB device number 9 using orion-ehci
[ 185.042953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 185.049681] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 185.073955] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 185.080318] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 185.291956] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 185.854882] usb 1-1: USB disconnect, device number 9
[ 186.186739] usb 1-1: new full-speed USB device number 10 using orion-ehci
[ 186.342953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 186.349680] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 186.373956] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 186.380311] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 186.589954] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 187.160396] usb 1-1: USB disconnect, device number 10
[ 187.486706] usb 1-1: new full-speed USB device number 11 using orion-ehci
[ 187.642954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 187.649682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 187.675955] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 187.682314] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 187.892955] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 188.464325] usb 1-1: USB disconnect, device number 11
[ 188.796675] usb 1-1: new full-speed USB device number 12 using orion-ehci
[ 188.952953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 188.959681] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 188.985954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 188.992344] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 189.202955] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 189.770861] usb 1-1: USB disconnect, device number 12
[ 190.106645] usb 1-1: new full-speed USB device number 13 using orion-ehci
[ 190.262953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[ 190.269682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 190.296958] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[ 190.303299] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[ 190.512954] Bluetooth: hci0: Intel Bluetooth firmware patch completed
and activated
[ 191.076700] usb 1-1: USB disconnect, device number 13
some information about the card:
Bus 001 Device 011: ID 8087:07dc Intel Corp.
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x8087 Intel Corp.
idProduct 0x07dc
bcdDevice 0.01
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 177
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
[root@alarm log]# uname -a
Linux alarm 4.4.24-2-ARCH #1 SMP Fri Oct 14 01:04:22 MDT 2016 armv7l
GNU/Linux
What's confusing me is that this device is connected through pcie, not
usb. When i use lspci i get:
[root@alarm log]# lspci
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04)
02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac
Wireless Network Adapter (rev ff)
So the other card is seen as pci device, but the intel is not. I am
really lost now.
^ permalink raw reply
* Re: [PATCH v8 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Rob Herring @ 2016-10-18 15:31 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, devicetree, linux-wireless, ath9k-devel, mcgrof,
mark.rutland, kvalo, chunkeey, arend.vanspriel, julian.calaby,
bjorn, linux, nbd
In-Reply-To: <20161016205907.19927-2-martin.blumenstingl@googlemail.com>
On Sun, Oct 16, 2016 at 10:59:05PM +0200, Martin Blumenstingl wrote:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> .../devicetree/bindings/net/wireless/qca,ath9k.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Jani Nikula @ 2016-10-18 14:52 UTC (permalink / raw)
To: Johannes Berg, Markus Heiser; +Cc: Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <1476799968.6425.33.camel@sipsolutions.net>
On Tue, 18 Oct 2016, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2016-10-18 at 15:51 +0200, Markus Heiser wrote:
>> Here are my thoughts ...
>>
>> Every extension which is not a part of the sphinx distro brings new
>> external dependencies
>
> I agree.
>
>> and the development of such extensions is IMO
>> far of kernel development's scope.
>
> Arguably, having good documentation *is* in the scope of kernel
> development.
>
> Also, it could be argued that shipping a module in the kernel sources
> would be more reliable than having to require it being externally
> installed, like the GCC plugins perhaps.
This could probably be argued either way...
My view has been all along that we should prefer to use existing
extensions written and maintained by others. Perhaps we (the kind of
royal "we" of which I'm personally really not part of) could take on
maintainership of some extensions in the interest of improving kernel
documentation, but I think the goal should be that the extensions are
maintained outside of the kernel tree, that the extensions are generally
usable, and have a chance of attracting attention and contributions from
outside of the kernel community. (Note that this doesn't preclude us
from shipping the extensions in the kernel tree, as long as it's updated
from the upstream, not forked.)
(This is one part of me being unhappy about making it easy to run
arbitrary scripts to produce documentation; those will never be generic,
and we'll never be able to offload their maintenance outside of the
kernel. We should not think that we have some really special needs in
the kernel.)
>> ATM, there are not many use cases for diagram generators, so why not
>> be KISS and creating diagrams with the favorite tool only adding the
>> resulting (e.g.) PNG to the Kernel's source?
>
> *Only* adding the PNG would be awful, I'd have to keep track of the
> corresponding source elsewhere, and perhaps couldn't even GPL it
> because then I couldn't distribute the PNG without corresponding
> source...
>
> Adding the source text would really be the only practical choice, but
> doing so makes it easy to mismatch things, and also very easy to use
> proprietary services for it that may go away at any time, etc.
Agreed. And there are other problems with attaching binaries (although
I'd say we should fix them too) [1].
BR,
Jani.
[1] http://lkml.kernel.org/r/02a78907-933d-3f61-572e-28154b16b9e5@redhat.com
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
From: Ard Biesheuvel @ 2016-10-18 14:30 UTC (permalink / raw)
To: Johannes Berg
Cc: <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, Herbert Xu, Jouni Malinen,
Andy Lutomirski
In-Reply-To: <1476800647.6425.38.camel@sipsolutions.net>
On 18 October 2016 at 15:24, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote:
>>
>> > Hmm. Is it really worth having a per-CPU variable for each possible
>> > key? You could have a large number of those (typically three when
>> > you're a client on an AP, and 1 + 1 for each client when you're the
>> > AP).
>
> 2 + 1 for each client, actually, since you have 2 GTKs present in the
> "steady state"; not a big difference though.
>
>> > Would it be so bad to have to set the TFM every time (if that's
>> > even possible), and just have a single per-CPU cache?
>
>> That would be preferred, yes. The only snag here is that
>> crypto_alloc_aead() is not guaranteed to return the same algo every
>> time, which means the request size is not guaranteed to be the same
>> either. This is a rare corner case, of course, but it needs to be
>> dealt with regardless
>
> Ah, good point. Well I guess you could allocate a bigger one it if it's
> too small, but then we'd have to recalculate the size all the time
> (which we already did anyway, but saving something else would be good).
> Then we'd be close to just having a per-CPU memory block cache though.
>
Well, ideally we'd allocate the ccm(aes) crypto_alg a single time and
'spawn' the transforms for each key. This is how the crypto API
implements templates internally, but I don't think this functionality
is publicly accessible. Herbert?
^ permalink raw reply
* Re: pull-request: mac80211 2016-10-18
From: David Miller @ 2016-10-18 14:26 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1476774058-9279-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 18 Oct 2016 09:00:57 +0200
> As I mention in the tag message, the most urgent fix here is for
> the VMAP_STACK vs. software crypto usage. I ended up applying Ard's
> fix that dynamically allocates everything in one go, perhaps we'll
> find a better solution in the future, but in the meantime this will
> get things working again (rather than crashing or getting BUG_ON),
> and normally it's a rarely used code path since hardware crypto is
> used for almost all devices.
>
> Please pull, or let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
From: Johannes Berg @ 2016-10-18 14:24 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, Herbert Xu, Jouni Malinen,
Andy Lutomirski
In-Reply-To: <CAKv+Gu8aE4AfewHeMDf2RQfJtSsrp6Fb1A_ygFsqEwpyP6hDjQ@mail.gmail.com>
On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote:
>
> > Hmm. Is it really worth having a per-CPU variable for each possible
> > key? You could have a large number of those (typically three when
> > you're a client on an AP, and 1 + 1 for each client when you're the
> > AP).
2 + 1 for each client, actually, since you have 2 GTKs present in the
"steady state"; not a big difference though.
> > Would it be so bad to have to set the TFM every time (if that's
> > even possible), and just have a single per-CPU cache?
> That would be preferred, yes. The only snag here is that
> crypto_alloc_aead() is not guaranteed to return the same algo every
> time, which means the request size is not guaranteed to be the same
> either. This is a rare corner case, of course, but it needs to be
> dealt with regardless
Ah, good point. Well I guess you could allocate a bigger one it if it's
too small, but then we'd have to recalculate the size all the time
(which we already did anyway, but saving something else would be good).
Then we'd be close to just having a per-CPU memory block cache though.
johannes
^ permalink raw reply
* Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
From: Ard Biesheuvel @ 2016-10-18 14:18 UTC (permalink / raw)
To: Johannes Berg
Cc: <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, Herbert Xu, Jouni Malinen,
Andy Lutomirski
In-Reply-To: <1476800194.6425.35.camel@sipsolutions.net>
On 18 October 2016 at 15:16, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote:
>>
>> + aead_req = *this_cpu_ptr(ccmp->reqs);
>> + if (!aead_req) {
>> + aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
>> + if (!aead_req)
>> + return -ENOMEM;
>> + *this_cpu_ptr(ccmp->reqs) = aead_req;
>> + aead_request_set_tfm(aead_req, ccmp->tfm);
>> + }
>
> Hmm. Is it really worth having a per-CPU variable for each possible
> key? You could have a large number of those (typically three when
> you're a client on an AP, and 1 + 1 for each client when you're the
> AP).
>
> Would it be so bad to have to set the TFM every time (if that's even
> possible), and just have a single per-CPU cache?
>
That would be preferred, yes. The only snag here is that
crypto_alloc_aead() is not guaranteed to return the same algo every
time, which means the request size is not guaranteed to be the same
either. This is a rare corner case, of course, but it needs to be
dealt with regardless
^ permalink raw reply
* Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
From: Johannes Berg @ 2016-10-18 14:16 UTC (permalink / raw)
To: Ard Biesheuvel, linux-wireless, netdev; +Cc: herbert, j, luto
In-Reply-To: <1476799713-16188-3-git-send-email-ard.biesheuvel@linaro.org>
On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote:
>
> + aead_req = *this_cpu_ptr(ccmp->reqs);
> + if (!aead_req) {
> + aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
> + if (!aead_req)
> + return -ENOMEM;
> + *this_cpu_ptr(ccmp->reqs) = aead_req;
> + aead_request_set_tfm(aead_req, ccmp->tfm);
> + }
Hmm. Is it really worth having a per-CPU variable for each possible
key? You could have a large number of those (typically three when
you're a client on an AP, and 1 + 1 for each client when you're the
AP).
Would it be so bad to have to set the TFM every time (if that's even
possible), and just have a single per-CPU cache?
johannes
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Johannes Berg @ 2016-10-18 14:12 UTC (permalink / raw)
To: Markus Heiser; +Cc: Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <B9AC83F3-AA14-414B-B538-81436620E432@darmarit.de>
On Tue, 2016-10-18 at 15:51 +0200, Markus Heiser wrote:
> Here are my thoughts ...
>
> Every extension which is not a part of the sphinx distro brings new
> external dependencies
I agree.
> and the development of such extensions is IMO
> far of kernel development's scope.
Arguably, having good documentation *is* in the scope of kernel
development.
Also, it could be argued that shipping a module in the kernel sources
would be more reliable than having to require it being externally
installed, like the GCC plugins perhaps.
> ATM, there are not many use cases for diagram generators, so why not
> be KISS and creating diagrams with the favorite tool only adding the
> resulting (e.g.) PNG to the Kernel's source?
*Only* adding the PNG would be awful, I'd have to keep track of the
corresponding source elsewhere, and perhaps couldn't even GPL it
because then I couldn't distribute the PNG without corresponding
source...
Adding the source text would really be the only practical choice, but
doing so makes it easy to mismatch things, and also very easy to use
proprietary services for it that may go away at any time, etc.
> Before we add new dependencies / complexity, we should get rid
> of the DocBook build.
That argument is ... completely bogus, politely said.
I'm not going to (be able to) do anything about all the docbooks that
exist, and have in fact converted the one docbook that I know anything
about. Holding back the development of documentation in one subsystem
because another subsystem hasn't converted is a garbage argument.
johannes
^ permalink raw reply
* [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU
From: Ard Biesheuvel @ 2016-10-18 14:08 UTC (permalink / raw)
To: linux-wireless, johannes, netdev; +Cc: herbert, j, luto, Ard Biesheuvel
In-Reply-To: <1476799713-16188-1-git-send-email-ard.biesheuvel@linaro.org>
Now that we can no longer invoke AEAD transforms with the aead_request
structure allocated on the stack, we perform a kmalloc/kfree for every
packet, which is expensive.
Since the CCMP routines execute in softirq context, we know there can
never be more than one request in flight on each CPU, and so we can
simply keep a cached aead_request structure per CPU, and deallocate all
of them when deallocating the AEAD transform.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/aes_ccm.c | 49 ++++++++++++++------
net/mac80211/key.h | 1 +
2 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 58e0338a2c34..2cb5ee4868ea 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -28,9 +28,14 @@ int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
- aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
- if (!aead_req)
- return -ENOMEM;
+ aead_req = *this_cpu_ptr(ccmp->reqs);
+ if (!aead_req) {
+ aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
+ *this_cpu_ptr(ccmp->reqs) = aead_req;
+ aead_request_set_tfm(aead_req, ccmp->tfm);
+ }
__aad = (u8 *)aead_req + reqsize;
memcpy(__aad, aad, CCM_AAD_LEN);
@@ -40,12 +45,10 @@ int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
sg_set_buf(&sg[1], data, data_len);
sg_set_buf(&sg[2], mic, mic_len);
- aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
crypto_aead_encrypt(aead_req);
- kzfree(aead_req);
return 0;
}
@@ -58,14 +61,18 @@ int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
struct aead_request *aead_req;
int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
- int err;
if (data_len == 0)
return -EINVAL;
- aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
- if (!aead_req)
- return -ENOMEM;
+ aead_req = *this_cpu_ptr(ccmp->reqs);
+ if (!aead_req) {
+ aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
+ if (!aead_req)
+ return -ENOMEM;
+ *this_cpu_ptr(ccmp->reqs) = aead_req;
+ aead_request_set_tfm(aead_req, ccmp->tfm);
+ }
__aad = (u8 *)aead_req + reqsize;
memcpy(__aad, aad, CCM_AAD_LEN);
@@ -75,14 +82,10 @@ int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
sg_set_buf(&sg[1], data, data_len);
sg_set_buf(&sg[2], mic, mic_len);
- aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
- err = crypto_aead_decrypt(aead_req);
- kzfree(aead_req);
-
- return err;
+ return crypto_aead_decrypt(aead_req);
}
int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
@@ -91,6 +94,7 @@ int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
size_t mic_len)
{
struct crypto_aead *tfm;
+ struct aead_request **r;
int err;
tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
@@ -104,6 +108,14 @@ int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
if (err)
goto free_aead;
+ /* allow a struct aead_request to be cached per cpu */
+ r = alloc_percpu(struct aead_request *);
+ if (!r) {
+ err = -ENOMEM;
+ goto free_aead;
+ }
+
+ ccmp->reqs = r;
ccmp->tfm = tfm;
return 0;
@@ -114,5 +126,14 @@ int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
void ieee80211_aes_key_free(struct ieee80211_ccmp_aead *ccmp)
{
+ struct aead_request *req;
+ int cpu;
+
+ for_each_possible_cpu(cpu) {
+ req = *per_cpu_ptr(ccmp->reqs, cpu);
+ if (req)
+ kzfree(req);
+ }
+ free_percpu(ccmp->reqs);
crypto_free_aead(ccmp->tfm);
}
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index 1ec7a737ab79..f99ec46dc08f 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -89,6 +89,7 @@ struct ieee80211_key {
*/
u8 rx_pn[IEEE80211_NUM_TIDS + 1][IEEE80211_CCMP_PN_LEN];
struct crypto_aead *tfm;
+ struct aead_request * __percpu *reqs;
u32 replays; /* dot11RSNAStatsCCMPReplays */
} ccmp;
struct {
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 1/2] mac80211: aes_ccm: prepare key struct for storing context data
From: Ard Biesheuvel @ 2016-10-18 14:08 UTC (permalink / raw)
To: linux-wireless, johannes, netdev; +Cc: herbert, j, luto, Ard Biesheuvel
In-Reply-To: <1476799713-16188-1-git-send-email-ard.biesheuvel@linaro.org>
As a prepatory change to allow per CPU caching of request structures,
refactor the key allocation routine so we can access per key data
beyond the core AEAD transform easily.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/aes_ccm.c | 35 +++++++++++---------
net/mac80211/aes_ccm.h | 16 ++++-----
net/mac80211/key.c | 16 ++++-----
net/mac80211/key.h | 2 +-
net/mac80211/wpa.c | 4 +--
5 files changed, 37 insertions(+), 36 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index a4e0d59a40dd..58e0338a2c34 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -10,6 +10,7 @@
*/
#include <linux/kernel.h>
+#include <linux/percpu.h>
#include <linux/types.h>
#include <linux/err.h>
#include <crypto/aead.h>
@@ -18,13 +19,13 @@
#include "key.h"
#include "aes_ccm.h"
-int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
+ u8 *aad, u8 *data, size_t data_len, u8 *mic,
size_t mic_len)
{
struct scatterlist sg[3];
struct aead_request *aead_req;
- int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
+ int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
@@ -39,7 +40,7 @@ int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
sg_set_buf(&sg[1], data, data_len);
sg_set_buf(&sg[2], mic, mic_len);
- aead_request_set_tfm(aead_req, tfm);
+ aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
@@ -49,13 +50,13 @@ int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
return 0;
}
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
+ u8 *aad, u8 *data, size_t data_len, u8 *mic,
size_t mic_len)
{
struct scatterlist sg[3];
struct aead_request *aead_req;
- int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
+ int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
int err;
@@ -74,7 +75,7 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
sg_set_buf(&sg[1], data, data_len);
sg_set_buf(&sg[2], mic, mic_len);
- aead_request_set_tfm(aead_req, tfm);
+ aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
@@ -84,16 +85,17 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
return err;
}
-struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
- size_t key_len,
- size_t mic_len)
+int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
+ const u8 key[],
+ size_t key_len,
+ size_t mic_len)
{
struct crypto_aead *tfm;
int err;
tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
- return tfm;
+ return PTR_ERR(tfm);
err = crypto_aead_setkey(tfm, key, key_len);
if (err)
@@ -102,14 +104,15 @@ struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
if (err)
goto free_aead;
- return tfm;
+ ccmp->tfm = tfm;
+ return 0;
free_aead:
crypto_free_aead(tfm);
- return ERR_PTR(err);
+ return err;
}
-void ieee80211_aes_key_free(struct crypto_aead *tfm)
+void ieee80211_aes_key_free(struct ieee80211_ccmp_aead *ccmp)
{
- crypto_free_aead(tfm);
+ crypto_free_aead(ccmp->tfm);
}
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index fcd3254c5cf0..82e91c6ec41f 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -14,15 +14,15 @@
#define CCM_AAD_LEN 32
-struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
- size_t key_len,
- size_t mic_len);
-int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
+ const u8 key[], size_t key_len,
+ size_t mic_len);
+int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
+ u8 *aad, u8 *data, size_t data_len, u8 *mic,
size_t mic_len);
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
+ u8 *aad, u8 *data, size_t data_len, u8 *mic,
size_t mic_len);
-void ieee80211_aes_key_free(struct crypto_aead *tfm);
+void ieee80211_aes_key_free(struct ieee80211_ccmp_aead *ccmp);
#endif /* AES_CCM_H */
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index edd6f2945f69..6d1a066e3c4e 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -431,10 +431,9 @@ ieee80211_key_alloc(u32 cipher, int idx, size_t key_len,
* Initialize AES key state here as an optimization so that
* it does not need to be initialized for every packet.
*/
- key->u.ccmp.tfm = ieee80211_aes_key_setup_encrypt(
- key_data, key_len, IEEE80211_CCMP_MIC_LEN);
- if (IS_ERR(key->u.ccmp.tfm)) {
- err = PTR_ERR(key->u.ccmp.tfm);
+ err = ieee80211_aes_key_setup_encrypt(&key->u.ccmp, key_data,
+ key_len, IEEE80211_CCMP_MIC_LEN);
+ if (err) {
kfree(key);
return ERR_PTR(err);
}
@@ -449,10 +448,9 @@ ieee80211_key_alloc(u32 cipher, int idx, size_t key_len,
/* Initialize AES key state here as an optimization so that
* it does not need to be initialized for every packet.
*/
- key->u.ccmp.tfm = ieee80211_aes_key_setup_encrypt(
- key_data, key_len, IEEE80211_CCMP_256_MIC_LEN);
- if (IS_ERR(key->u.ccmp.tfm)) {
- err = PTR_ERR(key->u.ccmp.tfm);
+ err = ieee80211_aes_key_setup_encrypt(&key->u.ccmp, key_data,
+ key_len, IEEE80211_CCMP_256_MIC_LEN);
+ if (err) {
kfree(key);
return ERR_PTR(err);
}
@@ -545,7 +543,7 @@ static void ieee80211_key_free_common(struct ieee80211_key *key)
switch (key->conf.cipher) {
case WLAN_CIPHER_SUITE_CCMP:
case WLAN_CIPHER_SUITE_CCMP_256:
- ieee80211_aes_key_free(key->u.ccmp.tfm);
+ ieee80211_aes_key_free(&key->u.ccmp);
break;
case WLAN_CIPHER_SUITE_AES_CMAC:
case WLAN_CIPHER_SUITE_BIP_CMAC_256:
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index 4aa20cef0859..1ec7a737ab79 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -80,7 +80,7 @@ struct ieee80211_key {
/* number of mic failures */
u32 mic_failures;
} tkip;
- struct {
+ struct ieee80211_ccmp_aead {
/*
* Last received packet number. The first
* IEEE80211_NUM_TIDS counters are used with Data
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index 14b28998c571..694af013494f 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -461,7 +461,7 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb,
pos += IEEE80211_CCMP_HDR_LEN;
ccmp_special_blocks(skb, pn, b_0, aad);
- return ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, b_0, aad, pos, len,
+ return ieee80211_aes_ccm_encrypt(&key->u.ccmp, b_0, aad, pos, len,
skb_put(skb, mic_len), mic_len);
}
@@ -538,7 +538,7 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx,
ccmp_special_blocks(skb, pn, b_0, aad);
if (ieee80211_aes_ccm_decrypt(
- key->u.ccmp.tfm, b_0, aad,
+ &key->u.ccmp, b_0, aad,
skb->data + hdrlen + IEEE80211_CCMP_HDR_LEN,
data_len,
skb->data + skb->len - mic_len, mic_len))
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 0/2] mac80211: aes_ccm: cache AEAD request allocations per CPU
From: Ard Biesheuvel @ 2016-10-18 14:08 UTC (permalink / raw)
To: linux-wireless, johannes, netdev; +Cc: herbert, j, luto, Ard Biesheuvel
This RFC implements per CPU caching of AEAD request structures, which allows
us to get rid of the per-packet kzalloc/kzfree calls we were forced to
introduce to deal with SG API violations, both in the mac80211 and in the
core crypto API code.
Since mac80211 only executes the AEAD transforms in softirq context, only one
AEAD request can be in flight at the same time on any given CPU, and so, instead
of free the request, we can stash its address in a per CPU variable, and reuse
it for the next packet.
This RFC only addressess CCMP, but GCM and GMAC could be fixed in the same way
(and CMAC did not suffer from the API violation issue in the first place)
Ard Biesheuvel (2):
mac80211: aes_ccm: prepare key struct for storing context data
mac80211: aes_ccm: cache AEAD request structures per CPU
net/mac80211/aes_ccm.c | 80 +++++++++++++-------
net/mac80211/aes_ccm.h | 16 ++--
net/mac80211/key.c | 16 ++--
net/mac80211/key.h | 3 +-
net/mac80211/wpa.c | 4 +-
5 files changed, 71 insertions(+), 48 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: sequence diagrams in rst documentation
From: Markus Heiser @ 2016-10-18 13:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jonathan Corbet, linux-wireless, linux-doc
In-Reply-To: <1476791021.6425.25.camel@sipsolutions.net>
Am 18.10.2016 um 13:43 schrieb Johannes Berg <johannes@sipsolutions.net>:
> On Tue, 2016-10-11 at 15:53 +0200, Johannes Berg wrote:
>>>
>>>
>>> Related question: I have some sequence diagrams, and just found the
>>> seqdiag sphinx plugin. How should we manage adding extensions? Or
>>> would you prefer not to add any at all?
>>
>> Example here:
>> https://johannes.sipsolutions.net/files/80211/mac80211.html#connection-flow
>
> Coming back to this - sadly, it appears that this software (blockdiag,
> seqdiag) is completely unmaintained, with open pull requests dating
> back to 2012 and the last commit dating back to 2015-08-22.
>
> I'd want/need feature improvements in it too, but if I can't feed those
> back to upstream (since it appears dead), there's little point.
>
> Perhaps we can ship plugins for this as part of the kernel sources?
> Shouldn't be too difficult to reimplement something like this, after
> all.
Here are my thoughts ...
Every extension which is not a part of the sphinx distro brings new
external dependencies and the development of such extensions is IMO
far of kernel development's scope.
ATM, there are not many use cases for diagram generators, so why not
be KISS and creating diagrams with the favorite tool only adding the
resulting (e.g.) PNG to the Kernel's source?
Before we add new dependencies / complexity, we should get rid
of the DocBook build.
-- Markus --
> johannes
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* sequence diagrams in rst documentation
From: Johannes Berg @ 2016-10-18 11:43 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-wireless, linux-doc
In-Reply-To: <1476194038.4118.11.camel@sipsolutions.net>
On Tue, 2016-10-11 at 15:53 +0200, Johannes Berg wrote:
> >
> >
> > Related question: I have some sequence diagrams, and just found the
> > seqdiag sphinx plugin. How should we manage adding extensions? Or
> > would you prefer not to add any at all?
>
> Example here:
> https://johannes.sipsolutions.net/files/80211/mac80211.html#connection-flow
Coming back to this - sadly, it appears that this software (blockdiag,
seqdiag) is completely unmaintained, with open pull requests dating
back to 2012 and the last commit dating back to 2015-08-22.
I'd want/need feature improvements in it too, but if I can't feed those
back to upstream (since it appears dead), there's little point.
Perhaps we can ship plugins for this as part of the kernel sources?
Shouldn't be too difficult to reimplement something like this, after
all.
johannes
^ permalink raw reply
* [PATCHv2 2/2] ath10k: add support for per sta tx bitrate
From: akolli @ 2016-10-18 9:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, akolli, Anilkumar Kolli
In-Reply-To: <1476783085-10724-1-git-send-email-akolli@qti.qualcomm.com>
From: Anilkumar Kolli <akolli@qti.qualcomm.com>
Per STA tx bitrate info is filled from peer stats.
Export per sta txrate info to cfg80211/nl80211
Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
---
v2:
* addressed kalle's comments
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 9955fea0802a..fce6f8137d33 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -77,6 +77,19 @@ void ath10k_sta_statistics(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
sinfo->rx_duration = arsta->rx_duration;
sinfo->filled |= 1ULL << NL80211_STA_INFO_RX_DURATION;
+
+ if (!arsta->txrate.legacy && !arsta->txrate.nss)
+ return;
+
+ if (arsta->txrate.legacy) {
+ sinfo->txrate.legacy = arsta->txrate.legacy;
+ } else {
+ sinfo->txrate.mcs = arsta->txrate.mcs;
+ sinfo->txrate.nss = arsta->txrate.nss;
+ sinfo->txrate.bw = arsta->txrate.bw;
+ }
+ sinfo->txrate.flags = arsta->txrate.flags;
+ sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_BITRATE;
}
static ssize_t ath10k_dbg_sta_read_aggr_mode(struct file *file,
--
1.7.9.5
^ 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