* 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: 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: 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: 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: [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
* 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: 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
* 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: 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: 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: 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: 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: 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
* [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
* [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 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 3/7] mac80211: improve RX aggregation data in debugfs
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>
When the driver sets the SUPPORTS_REORDERING_BUFFER hardware flag,
the debugfs data for RX aggregation sessions won't even indicate
that a session is open. Since the previous fix to store the dialog
token separately, we can indicate that it's open and add the token
so that there's at least some data (ssn is not available.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/debugfs_sta.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index 14ec63a..f6003b8 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -199,13 +199,18 @@ static ssize_t sta_agg_status_read(struct file *file, char __user *userbuf,
"TID\t\tRX\tDTKN\tSSN\t\tTX\tDTKN\tpending\n");
for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
+ bool tid_rx_valid;
+
tid_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[i]);
tid_tx = rcu_dereference(sta->ampdu_mlme.tid_tx[i]);
+ tid_rx_valid = test_bit(i, sta->ampdu_mlme.agg_session_valid);
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\t%x",
+ tid_rx_valid);
p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.2x",
- tid_rx ? sta->ampdu_mlme.tid_rx_token[i] : 0);
+ tid_rx_valid ?
+ sta->ampdu_mlme.tid_rx_token[i] : 0);
p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.3x",
tid_rx ? tid_rx->ssn : 0);
--
2.9.3
^ permalink raw reply related
* [PATCH 4/7] mac80211: allow the driver not to pass the tid to ieee80211_sta_uapsd_trigger
From: Luca Coelho @ 2016-10-18 20:12 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20161018201213.18873-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
iwlwifi will check internally that the tid maps to an AC
that is trigger enabled, but can't know what tid exactly.
Allow the driver to pass a generic tid and make mac80211
assume that a trigger frame was received.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
include/net/mac80211.h | 4 ++++
net/mac80211/rx.c | 5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index e50c9e0..f3dbada 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -4087,6 +4087,10 @@ void ieee80211_sta_pspoll(struct ieee80211_sta *sta);
* This must be used in conjunction with ieee80211_sta_ps_transition()
* and possibly ieee80211_sta_pspoll(); calls to all three must be
* serialized.
+ * %IEEE80211_NUM_TIDS can be passed as the tid if the tid is unknown.
+ * In this case, mac80211 will not check that this tid maps to an AC
+ * that is trigger enabled and assume that the caller did the proper
+ * checks.
*/
void ieee80211_sta_uapsd_trigger(struct ieee80211_sta *sta, u8 tid);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index fc08a50..837d562 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1394,13 +1394,14 @@ void ieee80211_sta_uapsd_trigger(struct ieee80211_sta *pubsta, u8 tid)
u8 ac = ieee802_1d_to_ac[tid & 7];
/*
- * If this AC is not trigger-enabled do nothing.
+ * If this AC is not trigger-enabled do nothing unless the
+ * driver is calling us after it already checked.
*
* NB: This could/should check a separate bitmap of trigger-
* enabled queues, but for now we only implement uAPSD w/o
* TSPEC changes to the ACs, so they're always the same.
*/
- if (!(sta->sta.uapsd_queues & BIT(ac)))
+ if (!(sta->sta.uapsd_queues & BIT(ac)) && tid != IEEE80211_NUM_TIDS)
return;
/* if we are in a service period, do nothing */
--
2.9.3
^ permalink raw reply related
* [PATCH 5/7] mac80211: add a HW flag for supporting HW TX fragmentation
From: Luca Coelho @ 2016-10-18 20:12 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Sara Sharon, Luca Coelho
In-Reply-To: <20161018201213.18873-1-luca@coelho.fi>
From: Sara Sharon <sara.sharon@intel.com>
Currently mac80211 determines whether HW does fragmentation
by checking whether the set_frag_threshold callback is set
or not.
However, some drivers may want to set the HW fragmentation
capability depending on HW generation.
Allow this by checking a HW flag instead of checking the
callback.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
[added the flag to ath10k and wlcore]
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 1 +
drivers/net/wireless/ti/wlcore/main.c | 1 +
include/net/mac80211.h | 10 ++++++++--
net/mac80211/debugfs.c | 1 +
net/mac80211/main.c | 4 ++++
net/mac80211/tx.c | 4 ++--
net/mac80211/wpa.c | 2 +-
7 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 76297d6..e322b6d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7881,6 +7881,7 @@ int ath10k_mac_register(struct ath10k *ar)
ieee80211_hw_set(ar->hw, WANT_MONITOR_VIF);
ieee80211_hw_set(ar->hw, CHANCTX_STA_CSA);
ieee80211_hw_set(ar->hw, QUEUE_CONTROL);
+ ieee80211_hw_set(ar->hw, SUPPORTS_TX_FRAG);
if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags))
ieee80211_hw_set(ar->hw, SW_CRYPTO_CONTROL);
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 471521a..9f39c6c 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -6086,6 +6086,7 @@ static int wl1271_init_ieee80211(struct wl1271 *wl)
ieee80211_hw_set(wl->hw, SUPPORTS_DYNAMIC_PS);
ieee80211_hw_set(wl->hw, SIGNAL_DBM);
ieee80211_hw_set(wl->hw, SUPPORTS_PS);
+ ieee80211_hw_set(wl->hw, SUPPORTS_TX_FRAG);
wl->hw->wiphy->cipher_suites = cipher_suites;
wl->hw->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index f3dbada..a1a2702 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2025,6 +2025,10 @@ struct ieee80211_txq {
* drivers, mac80211 packet loss mechanism will not be triggered and driver
* is completely depending on firmware event for station kickout.
*
+ * @IEEE80211_HW_SUPPORTS_TX_FRAG: Hardware does fragmentation by itself.
+ * The stack will not do fragmentation.
+ * The callback for @set_frag_threshold should be set as well.
+ *
* @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
*/
enum ieee80211_hw_flags {
@@ -2066,6 +2070,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_TX_AMSDU,
IEEE80211_HW_TX_FRAG_LIST,
IEEE80211_HW_REPORTS_LOW_ACK,
+ IEEE80211_HW_SUPPORTS_TX_FRAG,
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
@@ -3093,8 +3098,9 @@ enum ieee80211_reconfig_type {
* The callback must be atomic.
*
* @set_frag_threshold: Configuration of fragmentation threshold. Assign this
- * if the device does fragmentation by itself; if this callback is
- * implemented then the stack will not do fragmentation.
+ * if the device does fragmentation by itself. Note that to prevent the
+ * stack from doing fragmentation IEEE80211_HW_SUPPORTS_TX_FRAG
+ * should be set as well.
* The callback can sleep.
*
* @set_rts_threshold: Configuration of RTS threshold (if device needs it)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index f56e2f4..e02ba42 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -210,6 +210,7 @@ static const char *hw_flag_names[] = {
FLAG(TX_AMSDU),
FLAG(TX_FRAG_LIST),
FLAG(REPORTS_LOW_ACK),
+ FLAG(SUPPORTS_TX_FRAG),
#undef FLAG
};
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 1075ac2..0d9163c 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -821,6 +821,10 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
!local->ops->tdls_recv_channel_switch))
return -EOPNOTSUPP;
+ if (WARN_ON(ieee80211_hw_check(hw, SUPPORTS_TX_FRAG) &&
+ !local->ops->set_frag_threshold))
+ return -EINVAL;
+
if (WARN_ON(local->hw.wiphy->interface_modes &
BIT(NL80211_IFTYPE_NAN) &&
(!local->ops->start_nan || !local->ops->stop_nan)))
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 772e369..62ccaf6 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -934,7 +934,7 @@ ieee80211_tx_h_fragment(struct ieee80211_tx_data *tx)
if (info->flags & IEEE80211_TX_CTL_DONTFRAG)
return TX_CONTINUE;
- if (tx->local->ops->set_frag_threshold)
+ if (ieee80211_hw_check(&tx->local->hw, SUPPORTS_TX_FRAG))
return TX_CONTINUE;
/*
@@ -2800,7 +2800,7 @@ void ieee80211_check_fast_xmit(struct sta_info *sta)
/* fast-xmit doesn't handle fragmentation at all */
if (local->hw.wiphy->frag_threshold != (u32)-1 &&
- !local->ops->set_frag_threshold)
+ !ieee80211_hw_check(&local->hw, SUPPORTS_TX_FRAG))
goto out;
rcu_read_lock();
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index b48c1e1..c249345 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -57,7 +57,7 @@ ieee80211_tx_h_michael_mic_add(struct ieee80211_tx_data *tx)
if (info->control.hw_key &&
(info->flags & IEEE80211_TX_CTL_DONTFRAG ||
- tx->local->ops->set_frag_threshold) &&
+ ieee80211_hw_check(&tx->local->hw, SUPPORTS_TX_FRAG)) &&
!(tx->key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MMIC)) {
/* hwaccel - with no need for SW-generated MMIC */
return TX_CONTINUE;
--
2.9.3
^ permalink raw reply related
* [PATCH 6/7] mac80211: uapsd_queues is in QoS IE order
From: Luca Coelho @ 2016-10-18 20:12 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20161018201213.18873-1-luca@coelho.fi>
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The uapsd_queue field is in QoS IE order and not in
IEEE80211_AC_*'s order.
This means that mac80211 would get confused between
BK and BE which is certainly not such a big deal but
needs to be fixed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
include/net/cfg80211.h | 3 ++-
include/net/mac80211.h | 3 ++-
net/mac80211/ieee80211_i.h | 2 ++
net/mac80211/mlme.c | 2 +-
net/mac80211/rx.c | 3 ++-
net/mac80211/sta_info.c | 13 ++++++++-----
net/mac80211/util.c | 7 +++++++
7 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5000ec7..10a26f0 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4574,7 +4574,8 @@ void cfg80211_auth_timeout(struct net_device *dev, const u8 *addr);
* moves to cfg80211 in this call
* @buf: authentication frame (header + body)
* @len: length of the frame data
- * @uapsd_queues: bitmap of ACs configured to uapsd. -1 if n/a.
+ * @uapsd_queues: bitmap of queues configured for uapsd. Same format
+ * as the AC bitmap in the QoS info field
*
* After being asked to associate via cfg80211_ops::assoc() the driver must
* call either this function or cfg80211_auth_timeout().
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index a1a2702..b9b24ab 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1745,7 +1745,8 @@ struct ieee80211_sta_rates {
* @drv_priv: data area for driver use, will always be aligned to
* sizeof(void *), size is determined in hw information.
* @uapsd_queues: bitmap of queues configured for uapsd. Only valid
- * if wme is supported.
+ * if wme is supported. The bits order is like in
+ * IEEE80211_WMM_IE_STA_QOSINFO_AC_*.
* @max_sp: max Service Period. Only valid if wme is supported.
* @bandwidth: current bandwidth the station can receive with
* @rx_nss: in HT/VHT, the maximum number of spatial streams the
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 42d194a..b4e2b6c 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -84,6 +84,8 @@ struct ieee80211_local;
#define IEEE80211_DEFAULT_MAX_SP_LEN \
IEEE80211_WMM_IE_STA_QOSINFO_SP_ALL
+extern const u8 ieee80211_ac_to_qos_mask[IEEE80211_NUM_ACS];
+
#define IEEE80211_DEAUTH_FRAME_LEN (24 /* hdr */ + 2 /* reason */)
#define IEEE80211_MAX_NAN_INSTANCE_ID 255
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 7486f2d..c8d3a9b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3193,7 +3193,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
uapsd_queues = 0;
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
if (sdata->tx_conf[ac].uapsd)
- uapsd_queues |= BIT(ac);
+ uapsd_queues |= ieee80211_ac_to_qos_mask[ac];
}
cfg80211_rx_assoc_resp(sdata->dev, bss, (u8 *)mgmt, len, uapsd_queues);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 837d562..21a8947 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1401,7 +1401,8 @@ void ieee80211_sta_uapsd_trigger(struct ieee80211_sta *pubsta, u8 tid)
* enabled queues, but for now we only implement uAPSD w/o
* TSPEC changes to the ACs, so they're always the same.
*/
- if (!(sta->sta.uapsd_queues & BIT(ac)) && tid != IEEE80211_NUM_TIDS)
+ if (!(sta->sta.uapsd_queues & ieee80211_ac_to_qos_mask[ac]) &&
+ tid != IEEE80211_NUM_TIDS)
return;
/* if we are in a service period, do nothing */
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index ab91e1e..236d47e 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -709,7 +709,7 @@ static void __sta_info_recalc_tim(struct sta_info *sta, bool ignore_pending)
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
unsigned long tids;
- if (ignore_for_tim & BIT(ac))
+ if (ignore_for_tim & ieee80211_ac_to_qos_mask[ac])
continue;
indicate_tim |= !skb_queue_empty(&sta->tx_filtered[ac]) ||
@@ -1389,7 +1389,7 @@ ieee80211_sta_ps_more_data(struct sta_info *sta, u8 ignored_acs,
return true;
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
- if (ignored_acs & BIT(ac))
+ if (ignored_acs & ieee80211_ac_to_qos_mask[ac])
continue;
if (!skb_queue_empty(&sta->tx_filtered[ac]) ||
@@ -1414,7 +1414,7 @@ ieee80211_sta_ps_get_frames(struct sta_info *sta, int n_frames, u8 ignored_acs,
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
unsigned long tids;
- if (ignored_acs & BIT(ac))
+ if (ignored_acs & ieee80211_ac_to_qos_mask[ac])
continue;
tids = ieee80211_tids_for_ac(ac);
@@ -1482,7 +1482,7 @@ ieee80211_sta_ps_deliver_response(struct sta_info *sta,
BIT(find_highest_prio_tid(driver_release_tids));
if (skb_queue_empty(&frames) && !driver_release_tids) {
- int tid;
+ int tid, ac;
/*
* For PS-Poll, this can only happen due to a race condition
@@ -1500,7 +1500,10 @@ ieee80211_sta_ps_deliver_response(struct sta_info *sta,
*/
/* This will evaluate to 1, 3, 5 or 7. */
- tid = 7 - ((ffs(~ignored_acs) - 1) << 1);
+ for (ac = IEEE80211_AC_VO; ac < IEEE80211_NUM_ACS; ac++)
+ if (ignored_acs & BIT(ac))
+ continue;
+ tid = 7 - 2 * ac;
ieee80211_send_null_response(sta, tid, reason, true, false);
} else if (!driver_release_tids) {
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 031273a..7f24bdc 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -3452,3 +3452,10 @@ void ieee80211_txq_get_depth(struct ieee80211_txq *txq,
*byte_cnt = txqi->tin.backlog_bytes + frag_bytes;
}
EXPORT_SYMBOL(ieee80211_txq_get_depth);
+
+const u8 ieee80211_ac_to_qos_mask[IEEE80211_NUM_ACS] = {
+ IEEE80211_WMM_IE_STA_QOSINFO_AC_VO,
+ IEEE80211_WMM_IE_STA_QOSINFO_AC_VI,
+ IEEE80211_WMM_IE_STA_QOSINFO_AC_BE,
+ IEEE80211_WMM_IE_STA_QOSINFO_AC_BK
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 7/7] cfg80211: Call rdev_disconnect() when connection is in progress
From: Luca Coelho @ 2016-10-18 20:12 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Ilan Peer, Luca Coelho
In-Reply-To: <20161018201213.18873-1-luca@coelho.fi>
From: Ilan Peer <ilan.peer@intel.com>
On a disconnect request from user space, cfg80211 would have
called rdev_disconnect() only in case that 'current_bss' was set, i.e.,
connection has been established.
Change this, so rdev_disconnect() would be called also in case that
connection is in progress, so the connection attempt would be stopped.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
include/net/cfg80211.h | 7 ++++---
net/wireless/sme.c | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 10a26f0..2bbbcc3 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2564,9 +2564,10 @@ struct cfg80211_nan_func {
* cases, the result of roaming is indicated with a call to
* cfg80211_roamed() or cfg80211_roamed_bss().
* (invoked with the wireless_dev mutex held)
- * @disconnect: Disconnect from the BSS/ESS. Once done, call
- * cfg80211_disconnected().
- * (invoked with the wireless_dev mutex held)
+ * @disconnect: Disconnect from the BSS/ESS or stop connection attempts if
+ * connection is in progress. Once done, call cfg80211_disconnected() in
+ * case connection was already established (invoked with the
+ * wireless_dev mutex held), otherwise call cfg80211_connect_timeout().
*
* @join_ibss: Join the specified IBSS (or create if necessary). Once done, call
* cfg80211_ibss_joined(), also call that function when changing BSSID due
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index a77db33..2b5bb38 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1088,7 +1088,7 @@ int cfg80211_disconnect(struct cfg80211_registered_device *rdev,
err = cfg80211_sme_disconnect(wdev, reason);
else if (!rdev->ops->disconnect)
cfg80211_mlme_down(rdev, dev);
- else if (wdev->current_bss)
+ else if (wdev->ssid_len)
err = rdev_disconnect(rdev, dev, reason);
return err;
--
2.9.3
^ permalink raw reply related
* Re: sequence diagrams in rst documentation
From: Jonathan Corbet @ 2016-10-18 23:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-doc
In-Reply-To: <1476791021.6425.25.camel@sipsolutions.net>
On Tue, 18 Oct 2016 13:43:41 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> > 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.
OK, I've read through all of this. My thoughts, for whatever it's worth.
We already carry a few sphinx plugins in the kernel; there is room for
more if we *really* need them. But...
- Part of the idea behind switching over to sphinx was to be able to get
away from maintaining our own formatting system. Adding plugins to the
kernel is a step away from that goal. So I'd like to be sure that
there's nothing that's part of standard sphinx that will do the job
first.
That said, I think that requiring people to install plugins from contrib
sites or third-party repos may be even worse. We don't want to put people
through misery just to format the docs.
In summary, I think we can consider taking on a module if it's what we
need to do the docs right. And if somebody agrees to maintain it! :)
I've heard others say they would like better diagramming support. Do you
think that, maybe, something like aafigure would do the trick?
https://pythonhosted.org/sphinxcontrib-aafig/
I've not actually played with it at all, but I like the idea that we'd
have readable diagrams in the source docs as well...
jon
^ permalink raw reply
* [PATCH net-next 2/6] net: use core MTU range checking in wireless drivers
From: Jarod Wilson @ 2016-10-19 2:33 UTC (permalink / raw)
To: linux-kernel
Cc: Jarod Wilson, netdev, linux-wireless, Maya Erez, Simon Kelley,
Stanislav Yakovlev
In-Reply-To: <20161019023333.15760-1-jarod@redhat.com>
- set max_mtu in wil6210 driver
- set max_mtu in atmel driver
- set min/max_mtu in cisco airo driver, remove airo_change_mtu
- set min/max_mtu in ipw2100/ipw2200 drivers, remove libipw_change_mtu
- set min/max_mtu in p80211netdev, remove wlan_change_mtu
CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: Maya Erez <qca_merez@qca.qualcomm.com>
CC: Simon Kelley <simon@thekelleys.org.uk>
CC: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
---
drivers/net/wireless/ath/wil6210/netdev.c | 17 +----------------
drivers/net/wireless/atmel/atmel.c | 13 ++++---------
drivers/net/wireless/cisco/airo.c | 14 +++-----------
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 3 ++-
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 8 ++++++--
drivers/net/wireless/intel/ipw2x00/libipw.h | 1 -
drivers/net/wireless/intel/ipw2x00/libipw_module.c | 9 ---------
drivers/staging/wlan-ng/p80211netdev.c | 18 +++++-------------
8 files changed, 21 insertions(+), 62 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/netdev.c b/drivers/net/wireless/ath/wil6210/netdev.c
index 61de5e9..d18372c 100644
--- a/drivers/net/wireless/ath/wil6210/netdev.c
+++ b/drivers/net/wireless/ath/wil6210/netdev.c
@@ -41,21 +41,6 @@ static int wil_stop(struct net_device *ndev)
return wil_down(wil);
}
-static int wil_change_mtu(struct net_device *ndev, int new_mtu)
-{
- struct wil6210_priv *wil = ndev_to_wil(ndev);
-
- if (new_mtu < 68 || new_mtu > mtu_max) {
- wil_err(wil, "invalid MTU %d\n", new_mtu);
- return -EINVAL;
- }
-
- wil_dbg_misc(wil, "change MTU %d -> %d\n", ndev->mtu, new_mtu);
- ndev->mtu = new_mtu;
-
- return 0;
-}
-
static int wil_do_ioctl(struct net_device *ndev, struct ifreq *ifr, int cmd)
{
struct wil6210_priv *wil = ndev_to_wil(ndev);
@@ -69,7 +54,6 @@ static const struct net_device_ops wil_netdev_ops = {
.ndo_start_xmit = wil_start_xmit,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
- .ndo_change_mtu = wil_change_mtu,
.ndo_do_ioctl = wil_do_ioctl,
};
@@ -126,6 +110,7 @@ static int wil6210_netdev_poll_tx(struct napi_struct *napi, int budget)
static void wil_dev_setup(struct net_device *dev)
{
ether_setup(dev);
+ dev->max_mtu = mtu_max;
dev->tx_queue_len = WIL_TX_Q_LEN_DEFAULT;
}
diff --git a/drivers/net/wireless/atmel/atmel.c b/drivers/net/wireless/atmel/atmel.c
index bf2e9a0..eb92d5a 100644
--- a/drivers/net/wireless/atmel/atmel.c
+++ b/drivers/net/wireless/atmel/atmel.c
@@ -1295,14 +1295,6 @@ static struct iw_statistics *atmel_get_wireless_stats(struct net_device *dev)
return &priv->wstats;
}
-static int atmel_change_mtu(struct net_device *dev, int new_mtu)
-{
- if ((new_mtu < 68) || (new_mtu > 2312))
- return -EINVAL;
- dev->mtu = new_mtu;
- return 0;
-}
-
static int atmel_set_mac_address(struct net_device *dev, void *p)
{
struct sockaddr *addr = p;
@@ -1506,7 +1498,6 @@ static const struct file_operations atmel_proc_fops = {
static const struct net_device_ops atmel_netdev_ops = {
.ndo_open = atmel_open,
.ndo_stop = atmel_close,
- .ndo_change_mtu = atmel_change_mtu,
.ndo_set_mac_address = atmel_set_mac_address,
.ndo_start_xmit = start_tx,
.ndo_do_ioctl = atmel_ioctl,
@@ -1600,6 +1591,10 @@ struct net_device *init_atmel_card(unsigned short irq, unsigned long port,
dev->irq = irq;
dev->base_addr = port;
+ /* MTU range: 68 - 2312 */
+ dev->min_mtu = 68;
+ dev->max_mtu = MAX_WIRELESS_BODY - ETH_FCS_LEN;
+
SET_NETDEV_DEV(dev, sys_dev);
if ((rc = request_irq(dev->irq, service_interrupt, IRQF_SHARED, dev->name, dev))) {
diff --git a/drivers/net/wireless/cisco/airo.c b/drivers/net/wireless/cisco/airo.c
index 69b826d..4b04045 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -2329,14 +2329,6 @@ static int airo_set_mac_address(struct net_device *dev, void *p)
return 0;
}
-static int airo_change_mtu(struct net_device *dev, int new_mtu)
-{
- if ((new_mtu < 68) || (new_mtu > 2400))
- return -EINVAL;
- dev->mtu = new_mtu;
- return 0;
-}
-
static LIST_HEAD(airo_devices);
static void add_airo_dev(struct airo_info *ai)
@@ -2656,7 +2648,6 @@ static const struct net_device_ops airo11_netdev_ops = {
.ndo_get_stats = airo_get_stats,
.ndo_set_mac_address = airo_set_mac_address,
.ndo_do_ioctl = airo_ioctl,
- .ndo_change_mtu = airo_change_mtu,
};
static void wifi_setup(struct net_device *dev)
@@ -2668,6 +2659,8 @@ static void wifi_setup(struct net_device *dev)
dev->type = ARPHRD_IEEE80211;
dev->hard_header_len = ETH_HLEN;
dev->mtu = AIRO_DEF_MTU;
+ dev->min_mtu = 68;
+ dev->max_mtu = MIC_MSGLEN_MAX;
dev->addr_len = ETH_ALEN;
dev->tx_queue_len = 100;
@@ -2754,7 +2747,6 @@ static const struct net_device_ops airo_netdev_ops = {
.ndo_set_rx_mode = airo_set_multicast_list,
.ndo_set_mac_address = airo_set_mac_address,
.ndo_do_ioctl = airo_ioctl,
- .ndo_change_mtu = airo_change_mtu,
.ndo_validate_addr = eth_validate_addr,
};
@@ -2766,7 +2758,6 @@ static const struct net_device_ops mpi_netdev_ops = {
.ndo_set_rx_mode = airo_set_multicast_list,
.ndo_set_mac_address = airo_set_mac_address,
.ndo_do_ioctl = airo_ioctl,
- .ndo_change_mtu = airo_change_mtu,
.ndo_validate_addr = eth_validate_addr,
};
@@ -2822,6 +2813,7 @@ static struct net_device *_init_airo_card( unsigned short irq, int port,
dev->irq = irq;
dev->base_addr = port;
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
+ dev->max_mtu = MIC_MSGLEN_MAX;
SET_NETDEV_DEV(dev, dmdev);
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index bfa542c..6417609 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -6035,7 +6035,6 @@ static const struct net_device_ops ipw2100_netdev_ops = {
.ndo_open = ipw2100_open,
.ndo_stop = ipw2100_close,
.ndo_start_xmit = libipw_xmit,
- .ndo_change_mtu = libipw_change_mtu,
.ndo_tx_timeout = ipw2100_tx_timeout,
.ndo_set_mac_address = ipw2100_set_address,
.ndo_validate_addr = eth_validate_addr,
@@ -6071,6 +6070,8 @@ static struct net_device *ipw2100_alloc_device(struct pci_dev *pci_dev,
dev->wireless_data = &priv->wireless_data;
dev->watchdog_timeo = 3 * HZ;
dev->irq = 0;
+ dev->min_mtu = 68;
+ dev->max_mtu = LIBIPW_DATA_LEN;
/* NOTE: We don't use the wireless_handlers hook
* in dev as the system will start throwing WX requests
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index bfd6861..ef9af8a 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -11561,7 +11561,6 @@ static const struct net_device_ops ipw_prom_netdev_ops = {
.ndo_open = ipw_prom_open,
.ndo_stop = ipw_prom_stop,
.ndo_start_xmit = ipw_prom_hard_start_xmit,
- .ndo_change_mtu = libipw_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
};
@@ -11587,6 +11586,9 @@ static int ipw_prom_alloc(struct ipw_priv *priv)
priv->prom_net_dev->type = ARPHRD_IEEE80211_RADIOTAP;
priv->prom_net_dev->netdev_ops = &ipw_prom_netdev_ops;
+ priv->prom_net_dev->min_mtu = 68;
+ priv->prom_net_dev->max_mtu = LIBIPW_DATA_LEN;
+
priv->prom_priv->ieee->iw_mode = IW_MODE_MONITOR;
SET_NETDEV_DEV(priv->prom_net_dev, &priv->pci_dev->dev);
@@ -11619,7 +11621,6 @@ static const struct net_device_ops ipw_netdev_ops = {
.ndo_set_rx_mode = ipw_net_set_multicast_list,
.ndo_set_mac_address = ipw_net_set_mac_address,
.ndo_start_xmit = libipw_xmit,
- .ndo_change_mtu = libipw_change_mtu,
.ndo_validate_addr = eth_validate_addr,
};
@@ -11729,6 +11730,9 @@ static int ipw_pci_probe(struct pci_dev *pdev,
net_dev->wireless_handlers = &ipw_wx_handler_def;
net_dev->ethtool_ops = &ipw_ethtool_ops;
+ net_dev->min_mtu = 68;
+ net_dev->max_mtu = LIBIPW_DATA_LEN;
+
err = sysfs_create_group(&pdev->dev.kobj, &ipw_attribute_group);
if (err) {
IPW_ERROR("failed to create sysfs device attributes\n");
diff --git a/drivers/net/wireless/intel/ipw2x00/libipw.h b/drivers/net/wireless/intel/ipw2x00/libipw.h
index b057161..b513551 100644
--- a/drivers/net/wireless/intel/ipw2x00/libipw.h
+++ b/drivers/net/wireless/intel/ipw2x00/libipw.h
@@ -948,7 +948,6 @@ static inline int libipw_is_cck_rate(u8 rate)
/* libipw.c */
void free_libipw(struct net_device *dev, int monitor);
struct net_device *alloc_libipw(int sizeof_priv, int monitor);
-int libipw_change_mtu(struct net_device *dev, int new_mtu);
void libipw_networks_age(struct libipw_device *ieee, unsigned long age_secs);
diff --git a/drivers/net/wireless/intel/ipw2x00/libipw_module.c b/drivers/net/wireless/intel/ipw2x00/libipw_module.c
index 60f2874..2332075 100644
--- a/drivers/net/wireless/intel/ipw2x00/libipw_module.c
+++ b/drivers/net/wireless/intel/ipw2x00/libipw_module.c
@@ -118,15 +118,6 @@ static void libipw_networks_initialize(struct libipw_device *ieee)
&ieee->network_free_list);
}
-int libipw_change_mtu(struct net_device *dev, int new_mtu)
-{
- if ((new_mtu < 68) || (new_mtu > LIBIPW_DATA_LEN))
- return -EINVAL;
- dev->mtu = new_mtu;
- return 0;
-}
-EXPORT_SYMBOL(libipw_change_mtu);
-
struct net_device *alloc_libipw(int sizeof_priv, int monitor)
{
struct libipw_device *ieee;
diff --git a/drivers/staging/wlan-ng/p80211netdev.c b/drivers/staging/wlan-ng/p80211netdev.c
index 825a63a..4762d38 100644
--- a/drivers/staging/wlan-ng/p80211netdev.c
+++ b/drivers/staging/wlan-ng/p80211netdev.c
@@ -669,18 +669,6 @@ static int p80211knetdev_set_mac_address(struct net_device *dev, void *addr)
return result;
}
-static int wlan_change_mtu(struct net_device *dev, int new_mtu)
-{
- /* 2312 is max 802.11 payload, 20 is overhead, (ether + llc +snap)
- and another 8 for wep. */
- if ((new_mtu < 68) || (new_mtu > (2312 - 20 - 8)))
- return -EINVAL;
-
- dev->mtu = new_mtu;
-
- return 0;
-}
-
static const struct net_device_ops p80211_netdev_ops = {
.ndo_init = p80211knetdev_init,
.ndo_open = p80211knetdev_open,
@@ -690,7 +678,6 @@ static const struct net_device_ops p80211_netdev_ops = {
.ndo_do_ioctl = p80211knetdev_do_ioctl,
.ndo_set_mac_address = p80211knetdev_set_mac_address,
.ndo_tx_timeout = p80211knetdev_tx_timeout,
- .ndo_change_mtu = wlan_change_mtu,
.ndo_validate_addr = eth_validate_addr,
};
@@ -756,6 +743,11 @@ int wlan_setup(struct wlandevice *wlandev, struct device *physdev)
wdev->wiphy = wiphy;
wdev->iftype = NL80211_IFTYPE_STATION;
netdev->ieee80211_ptr = wdev;
+ netdev->min_mtu = 68;
+ /* 2312 is max 802.11 payload, 20 is overhead,
+ * (ether + llc + snap) and another 8 for wep.
+ */
+ netdev->max_mtu = (2312 - 20 - 8);
netif_stop_queue(netdev);
netif_carrier_off(netdev);
--
2.10.0
^ permalink raw reply related
* Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption
From: Herbert Xu @ 2016-10-19 3:31 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Andy Lutomirski, Johannes Berg, Sergey Senozhatsky,
<netdev@vger.kernel.org>, David S. Miller,
<linux-wireless@vger.kernel.org>,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <CAKv+Gu-25OvTSbyE06Ln8N+HsqNyV1T6oOudK2tyAAOmmXXqgA@mail.gmail.com>
On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote:
>
> Annoyingly, all this complication with scatterlists etc is for doing
> asynchronous crypto via DMA capable crypto accelerators, and the
> networking code (ipsec as well as mac80211, afaik) only allow
> synchronous in the first place, given that they execute in softirq
> context.
I'm still thinking about the issue (in particular, whether we
should continue to rely on the request context being SG-capable
or allow it to be on the stack for AEAD).
But IPsec definitely supports async crypto. In fact it was the
very first user of async crypto.
mac80211 on the other hand is currently sync-only.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] cfg80211: allow vendor commands to be sent to nan interface
From: Luca Coelho @ 2016-10-19 4:47 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Andrei Otcheretianski, Luca Coelho
From: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Allow vendor commands that require WIPHY_VENDOR_CMD_NEED_RUNNING flag, to
be sent to NAN interface.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
net/wireless/nl80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e48b9c3..fcf5b4f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -11258,7 +11258,8 @@ static int nl80211_vendor_cmd(struct sk_buff *skb, struct genl_info *info)
if (wdev->netdev &&
!netif_running(wdev->netdev))
return -ENETDOWN;
- if (!wdev->netdev && !wdev->p2p_started)
+ if (!wdev->netdev && !wdev->p2p_started &&
+ !wdev->nan_started)
return -ENETDOWN;
}
--
2.9.3
^ 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