* Re: [PATCH] Make EN2 pin optional in the TRF7970A driver
From: Rob Herring @ 2017-02-21 16:43 UTC (permalink / raw)
To: Heiko Schocher
Cc: netdev, Guan Ben, Mark Jonas, devicetree@vger.kernel.org,
linux-wireless, linux-kernel@vger.kernel.org, Samuel Ortiz,
Lauro Ramos Venancio, Aloisio Almeida Jr, Mark Rutland
In-Reply-To: <58AA7C5D.60801@denx.de>
On Sun, Feb 19, 2017 at 11:19 PM, Heiko Schocher <hs@denx.de> wrote:
> Hello all,
>
> Am 13.02.2017 um 22:31 schrieb Rob Herring:
>>
>> On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher <hs@denx.de> wrote:
>>>
>>> Hello Rob,
>>>
>>>
>>> Am 10.02.2017 um 16:51 schrieb Rob Herring:
>>>>
>>>>
>>>> On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:
>>>>>
>>>>>
>>>>> From: Guan Ben <ben.guan@cn.bosch.com>
>>>>>
>>>>> Make the EN2 pin optional. This is useful for boards,
>>>>> which have this pin fix wired, for example to ground.
>>>>>
>>>>> Signed-off-by: Guan Ben <ben.guan@cn.bosch.com>
>>>>> Signed-off-by: Mark Jonas <mark.jonas@de.bosch.com>
>>>>> Signed-off-by: Heiko Schocher <hs@denx.de>
>>>>>
>>>>> ---
>>>>>
>>>>> .../devicetree/bindings/net/nfc/trf7970a.txt | 4 ++--
>>>>> drivers/nfc/trf7970a.c | 26
>>>>> ++++++++++++----------
>>>>> 2 files changed, 16 insertions(+), 14 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>>>>> b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>>>>> index 32b35a0..5889a3d 100644
>>>>> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>>>>> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>>>>> @@ -5,8 +5,8 @@ Required properties:
>>>>> - spi-max-frequency: Maximum SPI frequency (<= 2000000).
>>>>> - interrupt-parent: phandle of parent interrupt handler.
>>>>> - interrupts: A single interrupt specifier.
>>>>> -- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on
>>>>> the
>>>>> - TRF7970A.
>>>>> +- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2'
>>>>> pins
>>>>> on the
>>>>> + TRF7970A. EN2 is optional.
>>>>
>>>>
>>>>
>>>> Could EN ever be optional/fixed? If so, perhaps deprecate this property
>>>> and do 2 properties, one for each pin.
>>>
>>>
>>>
>>> The hardware I have has the EN2 pin fix connected to ground. Looking
>>> into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
>>> and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
>>> selects between Power Down and Sleep Mode ... I see no reason why
>>> this is not possible/allowed ...
>>>
>>> Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
>>> property into 2 seperate properties ... but if this would be a reason
>>> for not accepting this patch, I can do this ... How should I name
>>> the 2 new properties?
>>
>>
>> I guess if this ever happens, then we just add "ti,enable2-gpios" and
>> ti,enable-gpios continues to point to EN. We don't need to deprecate
>> anything (or maybe just deprecate having both GPIOs on single
>> property).
>>
>> In that case,
>>
>> Acked-by: Rob Herring <robh@kernel.org>
>
>
> gentle ping.
>
> Are there any more comments to this patch? Is it acceptable as it
> is?
I acked it, so yes, it is fine.
Rob
^ permalink raw reply
* Re: [OpenWrt-Devel] ATH10K VLAN firmware issue
From: Bruno Antunes @ 2017-02-21 16:47 UTC (permalink / raw)
To: Tom Psyborg
Cc: Valo, Kalle, OpenWrt Development List, linux-wireless,
ath10k@lists.infradead.org, voncken
In-Reply-To: <CAKR_QVLpSWab-kF-f8=xqw+oWAfA966GDm7CtXrWfzmJz8gP-w@mail.gmail.com>
On 21 February 2017 at 13:42, Tom Psyborg <pozega.tomislav@gmail.com> wrote:
> have you tried this one
> https://forum.lede-project.org/t/new-qca988x-firmware-with-mesh-support/1587
>From my testing it does not work.
>
> On 21 February 2017 at 14:19, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
>>
>> voncken <cedric.voncken@acksys.fr> writes:
>>
>> > Do you know if the firmware team planned to fix the VLAN issue on ath10k
>> > firmware?
>>
>> I reported it forward only this week.
>>
>> --
>> Kalle Valo
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
^ permalink raw reply
* ANNOUNCE: Netdev 2.1 CFP extended
From: Jamal Hadi Salim @ 2017-02-21 17:57 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: netfilter-devel, netfilter, info, linux-wireless, tech-committee,
David Miller, Stephen Jaworski, lwn, people, Brenda Butler
The tech committee has graciously extended the CFP to February 27th.
Hurry o thee procastinators and submit early to avoid the hazards of
last minute traffic. Refer to:
https://netdevconf.org/2.1/submit-proposal.html
Some reminders, again:
-Registration is open. Register early so we can plan better.
https://onlineregistrations.ca/netdev21/
- hotel (If you can get the hotel cheaper online than conference
rates please send us email, dont book ):
https://www.netdevconf.org/2.1/hotel.html
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 1/2] firmware: add more flexible request_firmware_async function
From: Luis R. Rodriguez @ 2017-02-21 17:59 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Ming Lei, Luis R . Rodriguez, Greg KH, Linux Kernel Mailing List,
Kalle Valo, Arend van Spriel, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170215222948.21030-1-zajec5@gmail.com>
On Wed, Feb 15, 2017 at 11:29:47PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreover this
> bool also controls user helper in an unclear way.
>
> Resolve this problem by adding a one flexible function
You've just taken under-the-hood flags and exposed them without considering and
enabling easy testing of any possible conflicts here. Take for instance the
FW_OPT_NOCACHE feature -- not using caching functionality has implications for
driver developers -- they *must* resolve their own suspend/resume mishaps.
Another example, when we get firmware signing having just flags won't cut it
for optional parameters, we want a struct with the ability to specify custom
signing requirements. Exposing just flags will not cut it for us long term and
we'd have to then either add new export symbol or modify this one.
This is not as flexible nor as well documented as I want for future
functionality. Nor is there any series of battery of tests of all possible
options to ensure we do not regress. I've addressed this in the driver data
series.
> and making old
> request_firmware_nowait a simple inline using new solution.
This I had not addressed in the driver data series but I will fold similar
strategy onto it.
> This
> implementation:
> 1) Modifies only single bits on existing code
> 2) Doesn't require adjusting / rewriting current drivers
> 3) Adds new function for drivers that need more control over loading a
> firmware. Thanks to using flags more features can be added later.
As I noted in the driver data series -- we're passed using the firmware API for
non-firmware specific stuff, and as recent history shows regressions are are
easy, specially with the fallback mechanism. A new API which just gives us
2 calls: sync/async calls and shares a common set of optional parameters is
what we need, we need proper testing to ensure we also don't regress should
new features be introduced.
What I'll do is I'll integrate the feature you are asking for here and fold
this into the driver data series as what we need now is actual users of new
functionality, not just a test driver.
Luis
^ permalink raw reply
* Re: [PATCH V2 1/2] firmware: add more flexible request_firmware_async function
From: Luis R. Rodriguez @ 2017-02-21 18:02 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Ming Lei, Luis R . Rodriguez, Greg KH, Linux Kernel Mailing List,
Kalle Valo, Arend van Spriel, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170216072636.7128-1-zajec5@gmail.com>
On Thu, Feb 16, 2017 at 08:26:35AM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreover this
> bool also controls user helper in an unclear way.
>
> Resolve this problem by adding a one flexible function and making old
> request_firmware_nowait a simple inline using new solution. This
> implementation:
> 1) Modifies only single bits on existing code
> 2) Doesn't require adjusting / rewriting current drivers
> 3) Adds new function for drivers that need more control over loading a
> firmware. Thanks to using flags more features can be added later.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> This patch is based on top of
> [PATCH V2 RESEND] firmware: simplify defining and handling FW_OPT_FALLBACK
> applied on top of Linux 4.10-rc8.
>
> Ming/Luis/Greg: assuming this gets a positive review, could someone of you pick
> this patchset? Second patch modifies brcmfmac, I'll try to get a proper Ack for
> that one.
> Unless you want this to go through wireless tree, then let me know please.
As I noted in the v1 post, just exposing all the flags under the hood is not
enough to ensure sanity here. Additionally just flags won't cut it to make this
as flexible as we need. I've addressed this in the driver data series, so I'll
take this feature request and fold it in there.
Luis
^ permalink raw reply
* Re: [PATCH V3 1/2] firmware: add more flexible request_firmware_async function
From: Luis R. Rodriguez @ 2017-02-21 18:04 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Ming Lei, Luis R . Rodriguez, Greg KH, Linux Kernel Mailing List,
Kalle Valo, Arend van Spriel, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170221094754.15406-1-zajec5@gmail.com>
On Tue, Feb 21, 2017 at 10:47:53AM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreover this
> bool also controls user helper in an unclear way.
>
> Resolve this problem by adding a one flexible function and making old
> request_firmware_nowait a simple inline using new solution. This
> implementation:
> 1) Modifies only single bits on existing code
> 2) Doesn't require adjusting / rewriting current drivers
> 3) Adds new function for drivers that need more control over loading a
> firmware. Thanks to using flags more features can be added later.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> This patch is based on top of
> [PATCH V2 RESEND] firmware: simplify defining and handling FW_OPT_FALLBACK
> applied on top of Linux 4.10-rc8.
>
> Ming/Luis/Greg: assuming this gets a positive review, could someone of you pick
> this patchset? Second patch modifies brcmfmac, I'll try to get a proper Ack for
> that one.
> Unless you want this to go through wireless tree, then let me know please.
As noted in the v1 and v2 series:
This is not as flexible as we need. I'll fold this functionality in to the
driver data series as it provides more flexibility and enables more testing to
be done in userspace.
Luis
^ permalink raw reply
* Re: [RFC 2/5] iwlwifi: fix request_module() use
From: Luis R. Rodriguez @ 2017-02-21 18:15 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: Luis R. Rodriguez, Berg, Johannes, Coelho, Luciano, tj@kernel.org,
arjan@linux.intel.com, ming.lei@canonical.com, zajec5@gmail.com,
jeyu@redhat.com, rusty@rustcorp.com.au, pmladek@suse.com,
gregkh@linuxfoundation.org, linuxwifi,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB3A8F4DEAB@hasmsx107.ger.corp.intel.com>
On Tue, Feb 21, 2017 at 07:16:16AM +0000, Grumbach, Emmanuel wrote:
> >
> > a) just remove the print and use instead request_module_nowait() (this is
> > more in alignment of what your code actually does today; or
> >
> > b) fix the request_module() use so that the error print matches the
> > expected and proper recommended use of request_module() (what this patch
> > does)
> >
> > I prefer a) actually but I had to show what b) looked like first :)
>
> Me too. Let's do the simple thing. After all, it's been working for 5 years
> now (maybe more?) and I don't see a huge need to verify that the opmode
> module has been loaded. It is very unlikely to fail anyway, and in the case
> it did fail, it's not that we can do much from iwlwifi point of view.
I tend to agree with you on this, retries would be the only sensible thing to
do, but why do that -- the error should be logged right and addressed by any
upper layers. Its one reason to consider in the future adding verifiers
as built-in optional part of module loading.
> iwlwifi will stay loaded and sit idle since no opmode will be there to start
> using the hardware. We will keep having the device claimed, and will keep the
> interrupt registered and all that. No WiFi for you, but no harm caused
> either.
Fine by me. Will send follow up simple patches.
Luis
^ permalink raw reply
* Re: ath10k regression on XPS13
From: David Miller @ 2017-02-21 18:18 UTC (permalink / raw)
To: kvalo; +Cc: torvalds, jikos, linux-kernel, ath10k, linux-wireless
In-Reply-To: <87d1eb99dq.fsf_-_@purkki.adurom.net>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 21 Feb 2017 11:32:49 +0200
> We are working on a fix so that ath10k continues to work with older
> board-2.bin, but that might take a day or two still.
Kalle I really wanted to send my net-next pull request to Linus later
today. But I guess I have to wait for this ath10k first.
Please get this to me as soon as possible, thanks.
^ permalink raw reply
* Re: ath10k regression on XPS13
From: Kalle Valo @ 2017-02-21 18:38 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, jikos, linux-kernel, ath10k, linux-wireless
In-Reply-To: <20170221.131858.949421414784612398.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Tue, 21 Feb 2017 11:32:49 +0200
>
>> We are working on a fix so that ath10k continues to work with older
>> board-2.bin, but that might take a day or two still.
>
> Kalle I really wanted to send my net-next pull request to Linus later
> today. But I guess I have to wait for this ath10k first.
>
> Please get this to me as soon as possible, thanks.
We have a fix now but it's not really tested that well so I'm reluctant
to submit it yet. As I don't want to make you wait I think I'll submit
you a patch reverting f2593cb1b291 in an hour or two. And later in the
week I send you a properly fixed (and tested) version of f2593cb1b291.
Does that sound ok to you?
--
Kalle Valo
^ permalink raw reply
* Re: TL-WN823N
From: Jes Sorensen @ 2017-02-21 18:44 UTC (permalink / raw)
To: madmaxxx, linux-wireless
In-Reply-To: <58A5C340.3060201@email.it>
On 02/16/2017 10:20 AM, madmaxxx wrote:
> Hi,
>
> I have a problem with rtl8xxxu driver, which seems to not work with a
> dongle tp-link TL-WN823N model. I just filled out a 4.9.10 kernel and the
> device is not fully recognized .. I can only scan network and not link.
>
> Thank you
There is nothing in this output that looks unusual, you need to provide
more data.
Jes
> lsusb:
> Bus 002 Device 002: ID 2357:0109
>
> dmesg:
> [gio feb 16 16:08:33 2017] usb 2-1: Vendor: Realtek
> [gio feb 16 16:08:33 2017] usb 2-1: Product: \x03802.11n NI
> [gio feb 16 16:08:33 2017] usb 2-1: Serial:
> [gio feb 16 16:08:33 2017] usb 2-1: rtl8192eu_parse_efuse: dumping efuse
> (0x200 bytes):
> [gio feb 16 16:08:33 2017] usb 2-1: 00: 29 81 00 7c 01 40 03 00
> [gio feb 16 16:08:33 2017] usb 2-1: 08: 40 74 04 50 14 00 00 00
> [gio feb 16 16:08:33 2017] usb 2-1: 10: 28 28 28 29 29 29 2a 2a
> [gio feb 16 16:08:33 2017] usb 2-1: 18: 2b 2b 2b f2 ef ef ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 20: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 28: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 30: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 38: ff ff 28 28 28 28 28 28
> [gio feb 16 16:08:33 2017] usb 2-1: 40: 2a 2a 29 2a 2a f2 ef ef
> [gio feb 16 16:08:33 2017] usb 2-1: 48: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 50: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 58: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 60: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 68: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 70: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 78: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 80: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 88: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 90: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 98: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: a0: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: a8: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: b0: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: b8: a1 22 21 00 00 00 ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: c0: ff 01 00 10 00 00 00 ff
> [gio feb 16 16:08:33 2017] usb 2-1: c8: 00 00 ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: d0: 57 23 09 01 e7 47 02 98
> [gio feb 16 16:08:33 2017] usb 2-1: d8: de d0 1e a4 d7 0a 03 52
> [gio feb 16 16:08:33 2017] usb 2-1: e0: 65 61 6c 74 65 6b 20 0e
> [gio feb 16 16:08:33 2017] usb 2-1: e8: 03 38 30 32 2e 31 31 6e
> [gio feb 16 16:08:33 2017] usb 2-1: f0: 20 4e 49 43 20 00 00 ff
> [gio feb 16 16:08:33 2017] usb 2-1: f8: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 100: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 108: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 110: ff ff ff ff ff ff ff 0d
> [gio feb 16 16:08:33 2017] usb 2-1: 118: 03 00 05 00 30 00 00 00
> [gio feb 16 16:08:33 2017] usb 2-1: 120: 00 93 ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 128: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 130: f6 a8 98 2d 03 92 98 00
> [gio feb 16 16:08:33 2017] usb 2-1: 138: fc 8c 00 11 9b 44 02 0a
> [gio feb 16 16:08:33 2017] usb 2-1: 140: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 148: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 150: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 158: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 160: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 168: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 170: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 178: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 180: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 188: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 190: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 198: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1a0: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1a8: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1b0: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1b8: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1c0: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1c8: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1d0: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1d8: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1e0: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1e8: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1f0: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: 1f8: ff ff ff ff ff ff ff ff
> [gio feb 16 16:08:33 2017] usb 2-1: RTL8192EU rev B (SMIC) 2T2R, TX
> queues 3, WiFi=1, BT=0, GPS=0, HI PA=0
> [gio feb 16 16:08:33 2017] usb 2-1: RTL8192EU MAC: 98:de:d0:1e:a4:d7
> [gio feb 16 16:08:33 2017] usb 2-1: rtl8xxxu: Loading firmware
> rtlwifi/rtl8192eu_nic.bin
>
^ permalink raw reply
* Re: ath10k regression on XPS13
From: Linus Torvalds @ 2017-02-21 18:52 UTC (permalink / raw)
To: David Miller
Cc: Kalle Valo, Jiri Kosina, Linux Kernel Mailing List,
open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER,
Linux Wireless List
In-Reply-To: <20170221.131858.949421414784612398.davem@davemloft.net>
On Tue, Feb 21, 2017 at 10:18 AM, David Miller <davem@davemloft.net> wrote:
>
> Kalle I really wanted to send my net-next pull request to Linus later
> today. But I guess I have to wait for this ath10k first.
Feel free to send it to me - it sounds like the regression is
(a) easy to work around
and
(b) has a fix coming up.
And it won't even be something that I personally notice, since I have
the prev-gen XPS13 that has intel wireless.
Linus
^ permalink raw reply
* Re: ath10k regression on XPS13
From: David Miller @ 2017-02-21 18:53 UTC (permalink / raw)
To: kvalo; +Cc: torvalds, jikos, linux-kernel, ath10k, linux-wireless
In-Reply-To: <87y3wzbd8n.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 21 Feb 2017 20:38:48 +0200
> David Miller <davem@davemloft.net> writes:
>
>> From: Kalle Valo <kvalo@codeaurora.org>
>> Date: Tue, 21 Feb 2017 11:32:49 +0200
>>
>>> We are working on a fix so that ath10k continues to work with older
>>> board-2.bin, but that might take a day or two still.
>>
>> Kalle I really wanted to send my net-next pull request to Linus later
>> today. But I guess I have to wait for this ath10k first.
>>
>> Please get this to me as soon as possible, thanks.
>
> We have a fix now but it's not really tested that well so I'm reluctant
> to submit it yet. As I don't want to make you wait I think I'll submit
> you a patch reverting f2593cb1b291 in an hour or two. And later in the
> week I send you a properly fixed (and tested) version of f2593cb1b291.
>
> Does that sound ok to you?
Sure.
^ permalink raw reply
* Problem with RTL8191SU driver
From: Marius Melzer @ 2017-02-21 19:23 UTC (permalink / raw)
To: linux-wireless
Hi,
I have a usb wifi stick with a RTL8191SU chipset and the driver doesn't
work for me (at least I think that's the problem). I'm using the
following driver: [1] which refers on its page to this email address for
reports.
I listed all relevant information in a post [2] in the archlinux forum,
espescially interesting is probably the dmesg output [3] and the
systemctl status NetworkManager output [4]. Also with NetworkManager
stopped it doesn't work (which was one of the proposed solutions): [5]
Is this a driver problem? If yes, how can I solve this? Espescially the
"does not support SSID scanning" is a bit weird for a usb wifi stick
which should at least support this, right?
Thanks in advance,
Marius
PS: Please keep me in CC or send me a quick message if I need to
subscribe to the mailinglist to follow the thread.
[1] https://github.com/chunkeey/rtl8192su
[2] https://bbs.archlinux.org/viewtopic.php?id=223264
[3] https://bbs.archlinux.org/viewtopic.php?pid=1691938#p1691938
[4] https://bbs.archlinux.org/viewtopic.php?pid=1692639#p1692639
[5] https://bbs.archlinux.org/viewtopic.php?pid=1692790#p1692790
^ permalink raw reply
* [PATCH] Revert "ath10k: Search SMBIOS for OEM board file extension"
From: Kalle Valo @ 2017-02-21 19:47 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, ath10k
This reverts commit f2593cb1b29185d38db706cbcbe22ed538720ae1.
Paul reported that this patch with older board-2.bin ath10k initialisation
fails on Dell XPS 13:
ath10k_pci 0000:3a:00.0: failed to fetch board data for bus=pci,vendor=168c,
device=003e,subsystem-vendor=1a56,subsystem-device=1535,variant=RV_0520 from
ath10k/QCA6174/hw3.0/board-2.bin
The reason is that the older board-2.bin does not have the variant version of
the image name and ath10k does not fallback to the older naming scheme.
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=185621#c9
Fixes: f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension")
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
Dave, please take this directly if you can.
drivers/net/wireless/ath/ath10k/core.c | 84 ++--------------------------------
drivers/net/wireless/ath/ath10k/core.h | 19 --------
2 files changed, 3 insertions(+), 100 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 59729aa8cd82..dd902b43f8f7 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -18,8 +18,6 @@
#include <linux/module.h>
#include <linux/firmware.h>
#include <linux/of.h>
-#include <linux/dmi.h>
-#include <linux/ctype.h>
#include <asm/byteorder.h>
#include "core.h"
@@ -713,72 +711,6 @@ static int ath10k_core_get_board_id_from_otp(struct ath10k *ar)
return 0;
}
-static void ath10k_core_check_bdfext(const struct dmi_header *hdr, void *data)
-{
- struct ath10k *ar = data;
- const char *bdf_ext;
- const char *magic = ATH10K_SMBIOS_BDF_EXT_MAGIC;
- u8 bdf_enabled;
- int i;
-
- if (hdr->type != ATH10K_SMBIOS_BDF_EXT_TYPE)
- return;
-
- if (hdr->length != ATH10K_SMBIOS_BDF_EXT_LENGTH) {
- ath10k_dbg(ar, ATH10K_DBG_BOOT,
- "wrong smbios bdf ext type length (%d).\n",
- hdr->length);
- return;
- }
-
- bdf_enabled = *((u8 *)hdr + ATH10K_SMBIOS_BDF_EXT_OFFSET);
- if (!bdf_enabled) {
- ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not found.\n");
- return;
- }
-
- /* Only one string exists (per spec) */
- bdf_ext = (char *)hdr + hdr->length;
-
- if (memcmp(bdf_ext, magic, strlen(magic)) != 0) {
- ath10k_dbg(ar, ATH10K_DBG_BOOT,
- "bdf variant magic does not match.\n");
- return;
- }
-
- for (i = 0; i < strlen(bdf_ext); i++) {
- if (!isascii(bdf_ext[i]) || !isprint(bdf_ext[i])) {
- ath10k_dbg(ar, ATH10K_DBG_BOOT,
- "bdf variant name contains non ascii chars.\n");
- return;
- }
- }
-
- /* Copy extension name without magic suffix */
- if (strscpy(ar->id.bdf_ext, bdf_ext + strlen(magic),
- sizeof(ar->id.bdf_ext)) < 0) {
- ath10k_dbg(ar, ATH10K_DBG_BOOT,
- "bdf variant string is longer than the buffer can accommodate (variant: %s)\n",
- bdf_ext);
- return;
- }
-
- ath10k_dbg(ar, ATH10K_DBG_BOOT,
- "found and validated bdf variant smbios_type 0x%x bdf %s\n",
- ATH10K_SMBIOS_BDF_EXT_TYPE, bdf_ext);
-}
-
-static int ath10k_core_check_smbios(struct ath10k *ar)
-{
- ar->id.bdf_ext[0] = '\0';
- dmi_walk(ath10k_core_check_bdfext, ar);
-
- if (ar->id.bdf_ext[0] == '\0')
- return -ENODATA;
-
- return 0;
-}
-
static int ath10k_download_and_run_otp(struct ath10k *ar)
{
u32 result, address = ar->hw_params.patch_load_addr;
@@ -1125,9 +1057,6 @@ static int ath10k_core_fetch_board_data_api_n(struct ath10k *ar,
static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
size_t name_len)
{
- /* strlen(',variant=') + strlen(ar->id.bdf_ext) */
- char variant[9 + ATH10K_SMBIOS_BDF_EXT_STR_LENGTH] = { 0 };
-
if (ar->id.bmi_ids_valid) {
scnprintf(name, name_len,
"bus=%s,bmi-chip-id=%d,bmi-board-id=%d",
@@ -1137,15 +1066,12 @@ static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
goto out;
}
- if (ar->id.bdf_ext[0] != '\0')
- scnprintf(variant, sizeof(variant), ",variant=%s",
- ar->id.bdf_ext);
-
scnprintf(name, name_len,
- "bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x%s",
+ "bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x",
ath10k_bus_str(ar->hif.bus),
ar->id.vendor, ar->id.device,
- ar->id.subsystem_vendor, ar->id.subsystem_device, variant);
+ ar->id.subsystem_vendor, ar->id.subsystem_device);
+
out:
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot using board name '%s'\n", name);
@@ -2202,10 +2128,6 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
goto err_free_firmware_files;
}
- ret = ath10k_core_check_smbios(ar);
- if (ret)
- ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not set.\n");
-
ret = ath10k_core_fetch_board_file(ar);
if (ret) {
ath10k_err(ar, "failed to fetch board file: %d\n", ret);
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 88d14be7fcce..757242ef52ac 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -69,23 +69,6 @@
#define ATH10K_NAPI_BUDGET 64
#define ATH10K_NAPI_QUOTA_LIMIT 60
-/* SMBIOS type containing Board Data File Name Extension */
-#define ATH10K_SMBIOS_BDF_EXT_TYPE 0xF8
-
-/* SMBIOS type structure length (excluding strings-set) */
-#define ATH10K_SMBIOS_BDF_EXT_LENGTH 0x9
-
-/* Offset pointing to Board Data File Name Extension */
-#define ATH10K_SMBIOS_BDF_EXT_OFFSET 0x8
-
-/* Board Data File Name Extension string length.
- * String format: BDF_<Customer ID>_<Extension>\0
- */
-#define ATH10K_SMBIOS_BDF_EXT_STR_LENGTH 0x20
-
-/* The magic used by QCA spec */
-#define ATH10K_SMBIOS_BDF_EXT_MAGIC "BDF_"
-
struct ath10k;
enum ath10k_bus {
@@ -815,8 +798,6 @@ struct ath10k {
bool bmi_ids_valid;
u8 bmi_board_id;
u8 bmi_chip_id;
-
- char bdf_ext[ATH10K_SMBIOS_BDF_EXT_STR_LENGTH];
} id;
int fw_api;
--
2.7.4
^ permalink raw reply related
* Re: ath10k regression on XPS13
From: Kalle Valo @ 2017-02-21 19:49 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, jikos, linux-kernel, ath10k, linux-wireless
In-Reply-To: <20170221.135337.291678413491553794.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Tue, 21 Feb 2017 20:38:48 +0200
>
>> David Miller <davem@davemloft.net> writes:
>>
>>> From: Kalle Valo <kvalo@codeaurora.org>
>>> Date: Tue, 21 Feb 2017 11:32:49 +0200
>>>
>>>> We are working on a fix so that ath10k continues to work with older
>>>> board-2.bin, but that might take a day or two still.
>>>
>>> Kalle I really wanted to send my net-next pull request to Linus later
>>> today. But I guess I have to wait for this ath10k first.
>>>
>>> Please get this to me as soon as possible, thanks.
>>
>> We have a fix now but it's not really tested that well so I'm reluctant
>> to submit it yet. As I don't want to make you wait I think I'll submit
>> you a patch reverting f2593cb1b291 in an hour or two. And later in the
>> week I send you a properly fixed (and tested) version of f2593cb1b291.
>>
>> Does that sound ok to you?
>
> Sure.
Here's the revert:
https://patchwork.ozlabs.org/patch/730735/
I didn't send a pull request because that felt overkill to do just for
one patch.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] cfg80211: support 4-way handshake offloading for WPA/WPA2-PSK
From: Arend Van Spriel @ 2017-02-21 19:57 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Eliad Peller, Jouni Malinen, Jithu Jance
In-Reply-To: <1487680651.2215.5.camel@sipsolutions.net>
On 21-2-2017 13:37, Johannes Berg wrote:
>
>> What I am also missing is how to deal with NL80211_CMD_CONNECTED
>> event signalling. Should that be given after (un)successful
>> completion of the 4-way handshake or should we have a separate event
>> for that?
>
> That's a good point. I don't think a new event really works well, but
> perhaps we should extend the NL80211_TIMEOUT_* values with this? It's
> not strictly a timeout, I guess, but it's not a direct rejection of the
> association either.
>
> Any thoughts?
I discussed about the event mechanism with Jithu which is who asked me
to look at their patches for this feature. His suggestion was to have a
"port authorized" event after successful handshake as it will help in
key mgmt offload cases. He gave the following example: Suppose you are
doing a fresh 8021x followed by 4way handshake offload. Right now there
is no event to indicate to the upper layer that the 4way handshake have
been completed successfully. So the only thing to do in wpa_supplicant
is to consider it completed and if not be hit with deauth.
Regards,
Arend
^ permalink raw reply
* Re: [RFC 2/5] iwlwifi: fix request_module() use
From: Luis R. Rodriguez @ 2017-02-21 20:17 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Grumbach, Emmanuel, Berg, Johannes, Coelho, Luciano,
tj@kernel.org, arjan@linux.intel.com, ming.lei@canonical.com,
zajec5@gmail.com, jeyu@redhat.com, rusty@rustcorp.com.au,
pmladek@suse.com, gregkh@linuxfoundation.org, linuxwifi,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20170221181541.GN31264@wotan.suse.de>
On Tue, Feb 21, 2017 at 07:15:41PM +0100, Luis R. Rodriguez wrote:
> On Tue, Feb 21, 2017 at 07:16:16AM +0000, Grumbach, Emmanuel wrote:
> > >
> > > a) just remove the print and use instead request_module_nowait() (this is
> > > more in alignment of what your code actually does today; or
> > >
> > > b) fix the request_module() use so that the error print matches the
> > > expected and proper recommended use of request_module() (what this patch
> > > does)
> > >
> > > I prefer a) actually but I had to show what b) looked like first :)
> >
> > Me too. Let's do the simple thing. After all, it's been working for 5 years
> > now (maybe more?) and I don't see a huge need to verify that the opmode
> > module has been loaded. It is very unlikely to fail anyway, and in the case
> > it did fail, it's not that we can do much from iwlwifi point of view.
>
> I tend to agree with you on this, retries would be the only sensible thing to
> do, but why do that -- the error should be logged right and addressed by any
> upper layers. Its one reason to consider in the future adding verifiers
> as built-in optional part of module loading.
It would seem we still need to offload the opmode start as it is the one that
really should be issuing the completion, otherwise we would end up sending a
completion while the opmode module is being loaded asynchronously. The changes
are for that are still very likely desirable as it should help with speeding
boot up.
So the sharing of the opcode start will go first.
Will send v2.
Luis
^ permalink raw reply
* Re: [PATCH] Revert "ath10k: Search SMBIOS for OEM board file extension"
From: David Miller @ 2017-02-21 21:00 UTC (permalink / raw)
To: kvalo; +Cc: netdev, linux-wireless, ath10k
In-Reply-To: <1487706426-31172-1-git-send-email-kvalo@qca.qualcomm.com>
From: Kalle Valo <kvalo@qca.qualcomm.com>
Date: Tue, 21 Feb 2017 21:47:06 +0200
> This reverts commit f2593cb1b29185d38db706cbcbe22ed538720ae1.
>
> Paul reported that this patch with older board-2.bin ath10k initialisation
> fails on Dell XPS 13:
>
> ath10k_pci 0000:3a:00.0: failed to fetch board data for bus=pci,vendor=168c,
> device=003e,subsystem-vendor=1a56,subsystem-device=1535,variant=RV_0520 from
> ath10k/QCA6174/hw3.0/board-2.bin
>
> The reason is that the older board-2.bin does not have the variant version of
> the image name and ath10k does not fallback to the older naming scheme.
>
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=185621#c9
> Fixes: f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file extension")
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
> ---
>
> Dave, please take this directly if you can.
Applied, thanks Kalle.
^ permalink raw reply
* Re: ath10k regression on XPS13
From: David Miller @ 2017-02-21 21:00 UTC (permalink / raw)
To: kvalo; +Cc: torvalds, jikos, linux-kernel, ath10k, linux-wireless
In-Reply-To: <87poibb9ze.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 21 Feb 2017 21:49:09 +0200
> David Miller <davem@davemloft.net> writes:
>
>> From: Kalle Valo <kvalo@codeaurora.org>
>> Date: Tue, 21 Feb 2017 20:38:48 +0200
>>
>>> David Miller <davem@davemloft.net> writes:
>>>
>>>> From: Kalle Valo <kvalo@codeaurora.org>
>>>> Date: Tue, 21 Feb 2017 11:32:49 +0200
>>>>
>>>>> We are working on a fix so that ath10k continues to work with older
>>>>> board-2.bin, but that might take a day or two still.
>>>>
>>>> Kalle I really wanted to send my net-next pull request to Linus later
>>>> today. But I guess I have to wait for this ath10k first.
>>>>
>>>> Please get this to me as soon as possible, thanks.
>>>
>>> We have a fix now but it's not really tested that well so I'm reluctant
>>> to submit it yet. As I don't want to make you wait I think I'll submit
>>> you a patch reverting f2593cb1b291 in an hour or two. And later in the
>>> week I send you a properly fixed (and tested) version of f2593cb1b291.
>>>
>>> Does that sound ok to you?
>>
>> Sure.
>
> Here's the revert:
>
> https://patchwork.ozlabs.org/patch/730735/
>
> I didn't send a pull request because that felt overkill to do just for
> one patch.
Yep, that's fine.
^ permalink raw reply
* Re: ath10k regression on XPS13
From: David Miller @ 2017-02-21 21:01 UTC (permalink / raw)
To: torvalds; +Cc: kvalo, jikos, linux-kernel, ath10k, linux-wireless
In-Reply-To: <CA+55aFyqH3WAKsD_AaCe905zJbPzTXGygu2eiD1L0d6c2sAkGA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 21 Feb 2017 10:52:33 -0800
> On Tue, Feb 21, 2017 at 10:18 AM, David Miller <davem@davemloft.net> wrote:
>>
>> Kalle I really wanted to send my net-next pull request to Linus later
>> today. But I guess I have to wait for this ath10k first.
>
> Feel free to send it to me - it sounds like the regression is
> (a) easy to work around
> and
> (b) has a fix coming up.
>
> And it won't even be something that I personally notice, since I have
> the prev-gen XPS13 that has intel wireless.
I have the revert in my tree, it's all good.
I'll let my tree sit quietly for a few hours then send a pull
request out later tonight.
^ permalink raw reply
* Regression with Intel 3160 AP: client not reconnecting
From: Jarek Kamiński @ 2017-02-21 21:33 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless; +Cc: linux-wireless
Hello,
I have an accesspoint running on Intel 3160 (ZBOX RI-323). It was
running just fine on 3.16 from Debian, but I recently tried upgrading it
to 4.9 and noticed strange issues with wireless clients.
With the recent versions of iwlwifi, when a client disconnects, it is
not noticed by the accesspoint. The following log comes from
backport-iwlwifi master (7ae529a404a30fdb78d7dcc1a7e5883a014c6552) on
3.16 (similar results on 4.9 as well):
#v+
lut 21 22:12:04 Wintermute hostapd[2419]: wlan0: STA xx:xx:xx:xx:xx:xx RADIUS: VLAN ID 2
lut 21 22:12:04 Wintermute hostapd[2419]: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
lut 21 22:12:04 Wintermute hostapd[2419]: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 3)
lut 21 22:12:04 Wintermute hostapd[2419]: wlan0: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session 58ACAD18-00000002
lut 21 22:12:04 Wintermute hostapd[2419]: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
[disconnect: nothing happens]
[try to reconnect: nothing happens, client doesn't connect]
#v-
Only running iw wlan0.2 station del xx:xx:xx:xx:xx:xx helps and allows
the client to connect.
To compare, on iwlwifi from Debian 3.16.39-1-amd64 everything works fine:
#v+
lut 21 22:03:46 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx RADIUS: VLAN ID 2
lut 21 22:03:46 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
lut 21 22:03:46 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 2)
lut 21 22:03:49 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session 58A9650D-00000084
lut 21 22:03:49 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
lut 21 22:04:16 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated
lut 21 22:04:16 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated
lut 21 22:04:17 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
lut 21 22:04:24 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx RADIUS: VLAN ID 2
lut 21 22:04:24 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
lut 21 22:04:24 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 2)
lut 21 22:04:26 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session 58A9650D-00000085
lut 21 22:04:26 Wintermute hostapd[12719]: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
#v-
I bisected it using the backport-iwlwifi tree on 4.5 down to
4061dda503118ef5c70e0afe77798c94a48a79b9 (iwlwifi: mvm: pass station to
mac80211 RX where known, [1]). I was using the following test procedure:
1) Build, load, start hostapd.
2) Connect with an Android mobile phone (which I had at hand).
3) Disable Wi-Fi on Android.
4) Reenable Wi-Fi. Connected -> git bisect good, didn't connect -> git
bisect bad.
I was using 4.5 because that was the lowest version against which all
intermediate commits were compiling without errors.
To verify, I patched the backports-iwlwifi master with the following
patch (on 3.16) and the Android phone started reconnecting.
#v+
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
index b02ad68..70edf42 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rx.c
@@ -144,7 +144,7 @@ static void iwl_mvm_pass_packet_to_mac80211(struct iwl_mvm *mvm,
fraglen, rxb->truesize);
}
- ieee80211_rx_napi(mvm->hw, sta, skb, napi);
+ ieee80211_rx_napi(mvm->hw, NULL, skb, napi);
}
/*
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index 66d237c..93c2542 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -209,7 +209,7 @@ static void iwl_mvm_pass_packet_to_mac80211(struct iwl_mvm *mvm,
if (iwl_mvm_check_pn(mvm, skb, queue, sta))
kfree_skb(skb);
else
- ieee80211_rx_napi(mvm->hw, sta, skb, napi);
+ ieee80211_rx_napi(mvm->hw, NULL, skb, napi);
}
static void iwl_mvm_get_signal_strength(struct iwl_mvm *mvm,
#v-
I assume that's not a correct fix, but maybe it can help to pinpoint the
root cause.
I'm running hostapd in a fairly normal configuration. One notable thing
is dynamic_vlan=1 with accept_mac_file and individual PSKs set in
wpa_psk_file.
What might be the cause? Is there anything I can do to help debug or fix
this?
Thanks in advance!
[1] http://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/commit/?id=4061dda503118ef5c70e0afe77798c94a48a79b9
--
pozdr(); // Jarek
^ permalink raw reply related
* Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
From: Oliver Freyermuth @ 2017-02-21 21:46 UTC (permalink / raw)
To: linux-wireless
Dear wireless experts,
I have been trying to get basic WoWLAN to work with the following configuration:
- Intel Corporation Wireless 7260 (rev 73) with in-tree iwlwifi driver
- Kernel 4.10.0 (on Gentoo Linux)
- Very recent firmware version for the card and revision:
iwlwifi 0000:0a:00.0: loaded firmware version 17.459231.0 op_mode iwlmvm
iwlwifi 0000:0a:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144
I try to do:
$ iw phy phy0 wowlan enable magic-packet
$ iw phy phy0 wowlan show
WoWLAN is enabled:
* wake up on magic packet
However, when trying to suspend to RAM ( echo mem > /sys/power/state ), I get:
[46656.403767] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211] returns -16
[46656.403769] PM: Device phy0 failed to suspend async: error -16
[46656.967002] PM: Some devices failed to suspend, or early wake event detected
It also happens with more complex configurations (e.g. TCP connection WoWLAN mode).
Only after:
$ iw phy phy0 wowlan disable
I can suspend normally again.
I found an earlier report here:
https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
from somebody using kernel 4.6.
Is this a known issue? Is WoWLAN supposed to work with this hardware (I guess it's quite wide-spread)?
If possible, please ping me directly in replies, I am not subscribed to the list (but will try to check gmane regularly).
Cheers and thanks for any support,
Oliver
^ permalink raw reply
* [PATCH] mac80211: Jitter HWMP MPATH reply frames to reduce collision, on dense networks.
From: Alexis Green @ 2017-02-21 23:24 UTC (permalink / raw)
To: linux-wireless; +Cc: Jesse Jones
From: Jesse Jones <jjones@uniumwifi.com>
When more than one station hears a broadcast request, it is possible that
multiple devices will reply at the same time, potentially causing
collision. This patch helps reduce this issue.
Signed-off-by: Alexis Green <agreen@uniumwifi.com>
Signed-off-by: Benjamin Morgan <bmorgan@uniumwifi.com>
---
net/mac80211/ieee80211_i.h | 11 ++++
net/mac80211/iface.c | 58 +++++++++++++++++++++
net/mac80211/mesh.c | 2 +
net/mac80211/mesh_hwmp.c | 124 +++++++++++++++++++++++++++++++++++----------
4 files changed, 168 insertions(+), 27 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 159a1a7..f422897 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -330,6 +330,11 @@ struct mesh_preq_queue {
u8 flags;
};
+struct mesh_tx_queue {
+ struct list_head list;
+ struct sk_buff *skb;
+};
+
struct ieee80211_roc_work {
struct list_head list;
@@ -670,6 +675,11 @@ struct ieee80211_if_mesh {
spinlock_t mesh_preq_queue_lock;
struct mesh_preq_queue preq_queue;
int preq_queue_len;
+ /* Spinlock for MPATH frame tx queue */
+ spinlock_t mesh_tx_queue_lock;
+ struct mesh_tx_queue tx_queue;
+ int tx_queue_len;
+
struct mesh_stats mshstats;
struct mesh_config mshcfg;
atomic_t estab_plinks;
@@ -919,6 +929,7 @@ struct ieee80211_sub_if_data {
struct work_struct work;
struct sk_buff_head skb_queue;
+ struct delayed_work tx_work;
u8 needed_rx_chains;
enum ieee80211_smps_mode smps_mode;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 40813dd..51d5cfa 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -778,6 +778,59 @@ static int ieee80211_open(struct net_device *dev)
return ieee80211_do_open(&sdata->wdev, true);
}
+static void flush_tx_skbs(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct mesh_tx_queue *tx_node;
+
+ spin_lock_bh(&ifmsh->mesh_tx_queue_lock);
+
+ /* Note that this check is important because of the two-stage
+ * way that ieee80211_if_mesh is initialized.
+ */
+ if (ifmsh->tx_queue_len > 0) {
+ mhwmp_dbg(sdata, "flushing %d skbs", ifmsh->tx_queue_len);
+
+ while (!list_empty(&ifmsh->tx_queue.list)) {
+ tx_node = list_last_entry(&ifmsh->tx_queue.list,
+ struct mesh_tx_queue, list);
+ kfree_skb(tx_node->skb);
+ list_del(&tx_node->list);
+ kfree(tx_node);
+ }
+ ifmsh->tx_queue_len = 0;
+ }
+
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+}
+
+static void mesh_jittered_tx(struct work_struct *wk)
+{
+ struct ieee80211_sub_if_data *sdata =
+ container_of(
+ wk, struct ieee80211_sub_if_data,
+ tx_work.work);
+
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct mesh_tx_queue *tx_node;
+
+ spin_lock_bh(&ifmsh->mesh_tx_queue_lock);
+
+ list_for_each_entry(tx_node, &ifmsh->tx_queue.list, list) {
+ ieee80211_tx_skb(sdata, tx_node->skb);
+ }
+
+ while (!list_empty(&ifmsh->tx_queue.list)) {
+ tx_node = list_last_entry(&ifmsh->tx_queue.list,
+ struct mesh_tx_queue, list);
+ list_del(&tx_node->list);
+ kfree(tx_node);
+ }
+ ifmsh->tx_queue_len = 0;
+
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+}
+
static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
bool going_down)
{
@@ -881,6 +934,9 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);
+ flush_tx_skbs(sdata);
+ cancel_delayed_work_sync(&sdata->tx_work);
+
if (sdata->wdev.cac_started) {
chandef = sdata->vif.bss_conf.chandef;
WARN_ON(local->suspended);
@@ -1846,6 +1902,8 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
ieee80211_dfs_cac_timer_work);
INIT_DELAYED_WORK(&sdata->dec_tailroom_needed_wk,
ieee80211_delayed_tailroom_dec);
+ INIT_DELAYED_WORK(&sdata->tx_work,
+ mesh_jittered_tx);
for (i = 0; i < NUM_NL80211_BANDS; i++) {
struct ieee80211_supported_band *sband;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index c28b0af..f0d3cd9 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1381,6 +1381,8 @@ void ieee80211_mesh_init_sdata(struct ieee80211_sub_if_data *sdata)
ieee80211_mesh_path_root_timer,
(unsigned long) sdata);
INIT_LIST_HEAD(&ifmsh->preq_queue.list);
+ INIT_LIST_HEAD(&ifmsh->tx_queue.list);
+ spin_lock_init(&ifmsh->mesh_tx_queue_lock);
skb_queue_head_init(&ifmsh->ps.bc_buf);
spin_lock_init(&ifmsh->mesh_preq_queue_lock);
spin_lock_init(&ifmsh->sync_offset_lock);
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index b747c96..2f8ca4a 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -18,6 +18,7 @@
#define ARITH_SHIFT 8
#define MAX_PREQ_QUEUE_LEN 64
+#define MAX_TX_QUEUE_LEN 8
static void mesh_queue_preq(struct mesh_path *, u8);
@@ -98,13 +99,15 @@ enum mpath_frame_type {
static const u8 broadcast_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
-static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
- const u8 *orig_addr, u32 orig_sn,
- u8 target_flags, const u8 *target,
- u32 target_sn, const u8 *da,
- u8 hop_count, u8 ttl,
- u32 lifetime, u32 metric, u32 preq_id,
- struct ieee80211_sub_if_data *sdata)
+static struct sk_buff *alloc_mesh_path_sel_frame(enum mpath_frame_type action,
+ u8 flags, const u8 *orig_addr,
+ u32 orig_sn, u8 target_flags,
+ const u8 *target,
+ u32 target_sn, const u8 *da,
+ u8 hop_count, u8 ttl,
+ u32 lifetime, u32 metric,
+ u32 preq_id,
+ struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_local *local = sdata->local;
struct sk_buff *skb;
@@ -117,7 +120,7 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
hdr_len +
2 + 37); /* max HWMP IE */
if (!skb)
- return -1;
+ return NULL;
skb_reserve(skb, local->tx_headroom);
mgmt = (struct ieee80211_mgmt *) skb_put(skb, hdr_len);
memset(mgmt, 0, hdr_len);
@@ -153,7 +156,7 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
break;
default:
kfree_skb(skb);
- return -ENOTSUPP;
+ return NULL;
}
*pos++ = ie_len;
*pos++ = flags;
@@ -192,10 +195,72 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
pos += 4;
}
- ieee80211_tx_skb(sdata, skb);
- return 0;
+ return skb;
+}
+
+static void mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
+ const u8 *orig_addr, u32 orig_sn,
+ u8 target_flags, const u8 *target,
+ u32 target_sn, const u8 *da,
+ u8 hop_count, u8 ttl,
+ u32 lifetime, u32 metric, u32 preq_id,
+ struct ieee80211_sub_if_data *sdata)
+{
+ struct sk_buff *skb = alloc_mesh_path_sel_frame(action, flags,
+ orig_addr, orig_sn, target_flags, target, target_sn,
+ da, hop_count, ttl, lifetime, metric, preq_id, sdata);
+ if (skb)
+ ieee80211_tx_skb(sdata, skb);
}
+static void mesh_path_sel_frame_tx_jittered(enum mpath_frame_type action,
+ u8 flags, const u8 *orig_addr,
+ u32 orig_sn, u8 target_flags,
+ const u8 *target, u32 target_sn,
+ const u8 *da, u8 hop_count, u8 ttl,
+ u32 lifetime, u32 metric,
+ u32 preq_id,
+ struct ieee80211_sub_if_data *sdata)
+{
+ u32 jitter;
+ struct sk_buff *skb = alloc_mesh_path_sel_frame(action, flags,
+ orig_addr, orig_sn,
+ target_flags, target,
+ target_sn, da,
+ hop_count, ttl,
+ lifetime, metric,
+ preq_id, sdata);
+ if (skb) {
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct mesh_tx_queue *tx_node = kmalloc(
+ sizeof(struct mesh_tx_queue), GFP_ATOMIC);
+ if (!tx_node) {
+ mhwmp_dbg(sdata, "could not allocate mesh_hwmp tx node");
+ return;
+ }
+
+ spin_lock_bh(&ifmsh->mesh_tx_queue_lock);
+ if (ifmsh->tx_queue_len == MAX_TX_QUEUE_LEN) {
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+ kfree(tx_node);
+ kfree_skb(skb);
+ if (printk_ratelimit())
+ mhwmp_dbg(sdata, "mesh_hwmp tx node queue full");
+ return;
+ }
+
+ tx_node->skb = skb;
+ list_add_tail(&tx_node->list, &ifmsh->tx_queue.list);
+ ++ifmsh->tx_queue_len;
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+
+ jitter = prandom_u32() % 25;
+
+ ieee80211_queue_delayed_work(
+ &sdata->local->hw,
+ &sdata->tx_work, msecs_to_jiffies(jitter));
+ }
+}
/* Headroom is not adjusted. Caller should ensure that skb has sufficient
* headroom in case the frame is encrypted. */
@@ -611,11 +676,13 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
ttl = ifmsh->mshcfg.element_ttl;
if (ttl != 0) {
mhwmp_dbg(sdata, "replying to the PREQ\n");
- mesh_path_sel_frame_tx(MPATH_PREP, 0, orig_addr,
- orig_sn, 0, target_addr,
- target_sn, mgmt->sa, 0, ttl,
- lifetime, target_metric, 0,
- sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_PREP, 0,
+ orig_addr, orig_sn,
+ 0, target_addr,
+ target_sn, mgmt->sa,
+ 0, ttl, lifetime,
+ target_metric, 0,
+ sdata);
} else {
ifmsh->mshstats.dropped_frames_ttl++;
}
@@ -643,10 +710,11 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
target_sn = PREQ_IE_TARGET_SN(preq_elem);
}
- mesh_path_sel_frame_tx(MPATH_PREQ, flags, orig_addr,
- orig_sn, target_flags, target_addr,
- target_sn, da, hopcount, ttl, lifetime,
- orig_metric, preq_id, sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_PREQ, flags, orig_addr,
+ orig_sn, target_flags,
+ target_addr, target_sn, da,
+ hopcount, ttl, lifetime,
+ orig_metric, preq_id, sdata);
if (!is_multicast_ether_addr(da))
ifmsh->mshstats.fwded_unicast++;
else
@@ -712,9 +780,10 @@ static void hwmp_prep_frame_process(struct ieee80211_sub_if_data *sdata,
target_sn = PREP_IE_TARGET_SN(prep_elem);
orig_sn = PREP_IE_ORIG_SN(prep_elem);
- mesh_path_sel_frame_tx(MPATH_PREP, flags, orig_addr, orig_sn, 0,
- target_addr, target_sn, next_hop, hopcount,
- ttl, lifetime, metric, 0, sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_PREP, flags, orig_addr, orig_sn,
+ 0, target_addr, target_sn, next_hop,
+ hopcount, ttl, lifetime, metric, 0,
+ sdata);
rcu_read_unlock();
sdata->u.mesh.mshstats.fwded_unicast++;
@@ -864,10 +933,11 @@ static void hwmp_rann_frame_process(struct ieee80211_sub_if_data *sdata,
ttl--;
if (ifmsh->mshcfg.dot11MeshForwarding) {
- mesh_path_sel_frame_tx(MPATH_RANN, flags, orig_addr,
- orig_sn, 0, NULL, 0, broadcast_addr,
- hopcount, ttl, interval,
- metric + metric_txsta, 0, sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_RANN, flags, orig_addr,
+ orig_sn, 0, NULL, 0,
+ broadcast_addr, hopcount, ttl,
+ interval, metric + metric_txsta,
+ 0, sdata);
}
rcu_read_unlock();
^ permalink raw reply related
* Re: [RFC 2/5] iwlwifi: fix request_module() use
From: Luis R. Rodriguez @ 2017-02-22 0:18 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Grumbach, Emmanuel, Berg, Johannes, Coelho, Luciano,
tj@kernel.org, arjan@linux.intel.com, ming.lei@canonical.com,
zajec5@gmail.com, jeyu@redhat.com, rusty@rustcorp.com.au,
pmladek@suse.com, gregkh@linuxfoundation.org, linuxwifi,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20170221201715.GZ31264@wotan.suse.de>
On Tue, Feb 21, 2017 at 09:17:15PM +0100, Luis R. Rodriguez wrote:
> On Tue, Feb 21, 2017 at 07:15:41PM +0100, Luis R. Rodriguez wrote:
> > On Tue, Feb 21, 2017 at 07:16:16AM +0000, Grumbach, Emmanuel wrote:
> > > >
> > > > a) just remove the print and use instead request_module_nowait() (this is
> > > > more in alignment of what your code actually does today; or
> > > >
> > > > b) fix the request_module() use so that the error print matches the
> > > > expected and proper recommended use of request_module() (what this patch
> > > > does)
> > > >
> > > > I prefer a) actually but I had to show what b) looked like first :)
> > >
> > > Me too. Let's do the simple thing. After all, it's been working for 5 years
> > > now (maybe more?) and I don't see a huge need to verify that the opmode
> > > module has been loaded. It is very unlikely to fail anyway, and in the case
> > > it did fail, it's not that we can do much from iwlwifi point of view.
> >
> > I tend to agree with you on this, retries would be the only sensible thing to
> > do, but why do that -- the error should be logged right and addressed by any
> > upper layers. Its one reason to consider in the future adding verifiers
> > as built-in optional part of module loading.
>
> It would seem we still need to offload the opmode start as it is the one that
> really should be issuing the completion, otherwise we would end up sending a
> completion while the opmode module is being loaded asynchronously. The changes
> are for that are still very likely desirable as it should help with speeding
> boot up.
>
> So the sharing of the opcode start will go first.
>
> Will send v2.
Actually the completion was always being sent prior to request_module(), so this
would not change anything really. The sharing of the opcode then is optional,
and I can send separately in another series.
Luis
^ permalink raw reply
* [PATCH v2 0/2] iwlwifi: corner case fix and request module changes
From: Luis R. Rodriguez @ 2017-02-22 2:09 UTC (permalink / raw)
To: johannes.berg, luciano.coelho, emmanuel.grumbach
Cc: ming.lei, zajec5, linuxwifi, linux-wireless, linux-kernel,
Luis R. Rodriguez
In-Reply-To: <20170222001822.GE31264@wotan.suse.de>
This v2 addresses the preference to keep things simple on iwlwifi when
requesting modules and not implementing a verifier for loaing the opmode
module. We now know what a verifier looks like for both sync and async
approaches. The already established long standing practice of just doing
best effort to load suffices and keeps the driver cleaner.
There no change to the first patch. The second patch just embraces
request_module_nowait() instead of implementing a verifier for a sync
call. The remaining patches from the last series will be sent separately.
Luis R. Rodriguez (2):
iwlwifi: fix drv cleanup on opmode registration failure
iwlwifi: simplify requesting ops module
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 28 ++++++++++------------------
1 file changed, 10 insertions(+), 18 deletions(-)
--
2.11.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox