* Re: ar5523 Gigaset USB Adapter 108 issue
From: Oleksij Rempel @ 2013-10-19 15:30 UTC (permalink / raw)
To: Yannik Völker; +Cc: Pontus Fuchs, linux-wireless
In-Reply-To: <5262789D.8030704@yahoo.de>
Am 19.10.2013 14:18, schrieb Yannik Völker:
> Am 18.10.2013 19:16, schrieb Oleksij Rempel:
>> Am 18.10.2013 18:33, schrieb Yannik Völker:
>>> Am 18.10.2013 18:16, schrieb Oleksij Rempel:
>>>> Am 18.10.2013 17:38, schrieb Yannik Völker:
>>>>> Am 18.10.2013 17:07, schrieb Oleksij Rempel:
>>>>>> Am 18.10.2013 16:49, schrieb Alan Stern:
>>>>>>> Yannik, you should always use Reply-To-All so that your
>>>>>>> messages get sent to the mailing list and not just to
>>>>>>> me.
>>>>>>>
>>>>>>> On Thu, 17 Oct 2013, Yannik Völker wrote:
>>>>>>>
>>>>>>>> Am 07.08.2013 19:34, schrieb Alan Stern:
>>>>>>>>> Please post two usbmon traces, one showing the
>>>>>>>>> failure on your current system and the other showing
>>>>>>>>> the adapter running correctly under a 32-bit kernel.
>>>>>>>>> Instructions for usbmon are in the kernel source
>>>>>>>>> file Documentation/usb/usbmon.txt.
>>>>>>>> I never got it to work under a 32-bit kernel, i was
>>>>>>>> just able to utilize a windows32 driver using
>>>>>>>> ndiswrapper.
>>>>>>>>
>>>>>>>> Now i got it to "work". I randomly found out that the
>>>>>>>> ar5523 driver actually works when you load it after
>>>>>>>> you unload ndiswrapper so the following steps make it
>>>>>>>> work: 1. modprobe ndiswrapper 2. plug in device 3.
>>>>>>>> connect to wlan using ndiswrapper and disconnect again
>>>>>>>> (might be optional) 4. modprobe -r ndiswrapper 5.
>>>>>>>> modprobe ar5523 6. connect to wlan log for that is
>>>>>>>> attatched as wlanthennative2.log
>>>>>
>>>>>
>>>>>> It sounds like linux driver didn't recognised usb id and
>>>>>> didn't uploaded firmware, or there was no firmware to
>>>>>> upload.
>>>>> there is firmware (/lib/firmware/ar5523.bin exists) but it
>>>>> does not even get touched (i renamed the file and the error
>>>>> did not change at all)
>>>
>>>> find first usbid of your adapter (it will be changed after
>>>> firmware upload). And try to force driver to use this id:
>>>> modprobe -v ar5523 echo 07d1 3a0d >
>>>> /sys/bus/usb/drivers/ar5523/new_id
>>>
>>>> instead of "07d1 3a0d" use your id.
>>>
>>>
>>> # lsusb … Bus 003 Device 011: ID 129b:160c CyberTAN Technology
>>> Siemens S30853-S1038-R351 802.11g Wireless Adapter [Atheros
>>> AR5523] …
>>>
>>> # modprobe ar5523 # echo 129b 160c >
>>> /sys/bus/usb/drivers/ar5523/new_id <plugging device in> syslog:
>>> Oct 18 18:27:47 yannik-desktop kernel: [ 8751.447784] usbcore:
>>> registered new interface driver ar5523 Oct 18 18:28:25
>>> yannik-desktop kernel: [ 8789.036912] usb 3-14: new high-speed
>>> USB device number 12 using xhci_hcd Oct 18 18:28:25
>>> yannik-desktop kernel: [ 8789.053995] usb 3-14: New USB device
>>> found, idVendor=129b, idProduct=160c Oct 18 18:28:25
>>> yannik-desktop kernel: [ 8789.054005] usb 3-14: New USB device
>>> strings: Mfr=1, Product=2, SerialNumber=3 Oct 18 18:28:25
>>> yannik-desktop kernel: [ 8789.054010] usb 3-14: Product: AR5523
>>> Oct 18 18:28:25 yannik-desktop kernel: [ 8789.054015] usb 3-14:
>>> Manufacturer: Atheros Communications Inc Oct 18 18:28:25
>>> yannik-desktop kernel: [ 8789.054019] usb 3-14: SerialNumber:
>>> 1.0 Oct 18 18:28:27 yannik-desktop kernel: [ 8791.052313] usb
>>> 3-14: timeout waiting for command 01 reply Oct 18 18:28:27
>>> yannik-desktop kernel: [ 8791.052323] usb 3-14: could not
>>> initialize adapter Oct 18 18:28:27 yannik-desktop kernel: [
>>> 8791.052359] usb 3-14: RX USB error -2. Oct 18 18:28:27
>>> yannik-desktop kernel: [ 8791.052378] usb 3-14: error -1 when
>>> submitting rx urb Oct 18 18:28:27 yannik-desktop kernel: [
>>> 8791.052504] ar5523: probe of 3-14:1.0 failed with error -110
>>>
>>>> Besidy, what kernel version are you using? May be it is too
>>>> old..
>>>
>>> 3.11.0-12-generic it is my understanding that the ar5523 driver
>>> was included from 3.8 on.
>
>> please test attached patch.
> Stopped the error from appearing but it looks like it would not even try
> to upload the firmware to me:
>
> [ 708.193488] cfg80211: Calling CRDA to update world regulatory domain
>
>
> [ 708.492120] usbcore: registered new interface driver ar5523
>
>
> [ 708.509819] cfg80211: World regulatory domain updated:
>
>
> [ 708.509822] cfg80211: (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
>
> [ 708.509823] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300
> mBi, 2000 mBm)
> [ 708.509824] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300
> mBi, 2000 mBm)
> [ 708.509825] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300
> mBi, 2000 mBm)
> [ 708.509826] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300
> mBi, 2000 mBm)
> [ 708.509827] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300
> mBi, 2000 mBm)
> [ 720.232697] usb 3-14: USB disconnect, device number 8
> [ 721.721980] usb 3-14: new high-speed USB device number 9 using xhci_hcd
> [ 721.739153] usb 3-14: New USB device found, idVendor=129b,
> idProduct=160c
> [ 721.739163] usb 3-14: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 721.739168] usb 3-14: Product: AR5523
> [ 721.739174] usb 3-14: Manufacturer: Atheros Communications Inc
> [ 721.739178] usb 3-14: SerialNumber: 1.0
> mtp-probe: checking bus 3, device 9:
> "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-14"
> mtp-probe: bus: 3, device: 9 was not an MTP device
>
> also it did not load the module on plugging in.
does not looks like it is complete log. Please attach your dmesg.
--
Regards,
Oleksij
^ permalink raw reply
* [PATCH] using kfree_skb() instead of kfree() to free sk_buff
From: Salil Kapur @ 2013-10-19 22:19 UTC (permalink / raw)
To: lauro.venancio, aloisio.almeida, sameo, linux-wireless, linux-nfc,
linux-kernel
Cc: Salil Kapur
---
drivers/nfc/mei_phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c
index 606bf55..bc30081 100644
--- a/drivers/nfc/mei_phy.c
+++ b/drivers/nfc/mei_phy.c
@@ -127,7 +127,7 @@ void nfc_mei_event_cb(struct mei_cl_device *device, u32 events, void *context)
reply_size = mei_cl_recv(device, skb->data, MEI_NFC_MAX_READ);
if (reply_size < MEI_NFC_HEADER_SIZE) {
- kfree(skb);
+ kfree_skb(skb);
return;
}
--
1.8.1.2
^ permalink raw reply related
* Re: ar5523 Gigaset USB Adapter 108 issue
From: Stefan Lippers-Hollmann @ 2013-10-19 23:53 UTC (permalink / raw)
To: Yannik Völker; +Cc: Oleksij Rempel, Pontus Fuchs, linux-wireless
In-Reply-To: <5262789D.8030704@yahoo.de>
Hi
On Saturday 19 October 2013, Yannik Völker wrote:
[…]
> [ 708.193488] cfg80211: Calling CRDA to update world regulatory domain
> [ 708.492120] usbcore: registered new interface driver ar5523
> [ 708.509819] cfg80211: World regulatory domain updated:
> [ 708.509822] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> [ 708.509823] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 708.509824] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 708.509825] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ 708.509826] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 708.509827] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 720.232697] usb 3-14: USB disconnect, device number 8
> [ 721.721980] usb 3-14: new high-speed USB device number 9 using xhci_hcd
> [ 721.739153] usb 3-14: New USB device found, idVendor=129b, idProduct=160c
> [ 721.739163] usb 3-14: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 721.739168] usb 3-14: Product: AR5523
> [ 721.739174] usb 3-14: Manufacturer: Atheros Communications Inc
> [ 721.739178] usb 3-14: SerialNumber: 1.0
> mtp-probe: checking bus 3, device 9:
> "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-14"
> mtp-probe: bus: 3, device: 9 was not an MTP device
Like Oleksij Rempel mentioned, working with arbitrarily cut kernel
messages is pretty futile, but I would first recommend to confirm that
your firmware is really correct:
$ md5sum -b /lib/firmware/ar5523.bin
78fe4478dca9134c028e7507421b3f6a */lib/firmware/ar5523.bin
ar5523 behaves in a slightly uncommon way, when you first connect your
USB wlan card, it flags 0x129b, 0x160c (let's at least use this
example) as its USB IDs. ar5523.ko binds to this USB and starts the
firmware upload, once the firmware is uploaded to the device, a USB bus
reset is triggered and the firmware makes the device now flag a
different USB, decremented by 1 - so ending up with 0x129b, 0x160b this
time, only now after this modeswitch the module can actually load.
In the past - before ar5523 was ever merged into linux, there was (at
least) one faulty firmware version which incremented the USB ID, rather
than decrementing it, which would be one explanation for your problem.
Another quite likely problem would be a side effect of your previous
ndiswrapper installation, which -in order to function- takes over the
USB IDs for itself, so also make sure to get rid of all traces of it,
in particular its overrides in /etc/modprobe.d/*.conf.
But in order to do anything, we really need full logs - at least from
the moment on you plug in your USB card. What your log should look like
is something like this:
[ 4826.812663] usb 3-1.6: new high-speed USB device number 6 using ehci-pci
[ 4826.899085] usb 3-1.6: New USB device found, idVendor=1385, idProduct=4251
[ 4826.899090] usb 3-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4826.899092] usb 3-1.6: Product: WG111T
[ 4826.899103] usb 3-1.6: Manufacturer: Atheros Communications Inc
[ 4826.899105] usb 3-1.6: SerialNumber: 1.0
[ 4827.004173] usbcore: registered new interface driver ar5523
[ 4827.325368] usb 3-1.6: USB disconnect, device number 6
[ 4827.502257] usb 3-1.6: new high-speed USB device number 7 using ehci-pci
[ 4827.588323] usb 3-1.6: New USB device found, idVendor=1385, idProduct=4250
[ 4827.588328] usb 3-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4827.588331] usb 3-1.6: Product: WG111T
[ 4827.588333] usb 3-1.6: Manufacturer: Atheros Communications Inc
[ 4827.588335] usb 3-1.6: SerialNumber: 1.0
[ 4827.637048] usb 3-1.6: Cap: CAP_TARGET_VERSION=0x00000006
[ 4827.637432] usb 3-1.6: Cap: CAP_TARGET_REVISION=0x00000001
[ 4827.637800] usb 3-1.6: Cap: CAP_MAC_VERSION=0x00000008
[ 4827.638176] usb 3-1.6: Cap: CAP_MAC_REVISION=0x00000001
[ 4827.638520] usb 3-1.6: Cap: CAP_PHY_REVISION=0x00000046
[ 4827.638889] usb 3-1.6: Cap: CAP_ANALOG_5GHz_REVISION=0x00000046
[ 4827.639138] usb 3-1.6: Cap: CAP_ANALOG_2GHz_REVISION=0x00000000
[ 4827.639525] usb 3-1.6: Cap: CAP_REG_DOMAIN=0x00000000
[ 4827.639885] usb 3-1.6: Cap: CAP_REG_CAP_BITS=0x00000000
[ 4827.640147] usb 3-1.6: Cap: CAP_WIRELESS_MODES=0x00000000
[ 4827.640534] usb 3-1.6: Cap: CAP_CHAN_SPREAD_SUPPORT=0x0000001c
[ 4827.640885] usb 3-1.6: Cap: CAP_COMPRESS_SUPPORT=0x00000001
[ 4827.641151] usb 3-1.6: Cap: CAP_BURST_SUPPORT=0x00000001
[ 4827.641527] usb 3-1.6: Cap: CAP_FAST_FRAMES_SUPPORT=0x00000001
[ 4827.641884] usb 3-1.6: Cap: CAP_CHAP_TUNING_SUPPORT=0x00000001
[ 4827.642133] usb 3-1.6: Cap: CAP_TURBOG_SUPPORT=0x00000001
[ 4827.642508] usb 3-1.6: Cap: CAP_TURBO_PRIME_SUPPORT=0x00000001
[ 4827.642761] usb 3-1.6: Cap: CAP_DEVICE_TYPE=0x00000001
[ 4827.643132] usb 3-1.6: Cap: CAP_WME_SUPPORT=0x00000001
[ 4827.643383] usb 3-1.6: Cap: CAP_TOTAL_QUEUES=0x00000001
[ 4827.643757] usb 3-1.6: Cap: CAP_CONNECTION_ID_MAX=0x0000000a
[ 4827.644013] usb 3-1.6: Cap: CAP_LOW_5GHZ_CHAN=0x00000004
[ 4827.644382] usb 3-1.6: Cap: CAP_HIGH_5GHZ_CHAN=0x00001338
[ 4827.644756] usb 3-1.6: Cap: CAP_LOW_2GHZ_CHAN=0x000017d4
[ 4827.645008] usb 3-1.6: Cap: CAP_HIGH_2GHZ_CHAN=0x00000908
[ 4827.645390] usb 3-1.6: Cap: CAP_TWICE_ANTENNAGAIN_5G=0x00000001
[ 4827.645659] usb 3-1.6: Cap: CAP_TWICE_ANTENNAGAIN_2G=0x00000004
[ 4827.646014] usb 3-1.6: Cap: CAP_CIPHER_AES_CCM=0x00000001
[ 4827.646276] usb 3-1.6: Cap: CAP_CIPHER_TKIP=0x00000000
[ 4827.646649] usb 3-1.6: Cap: CAP_MIC_TKIP=0x00000000
[ 4827.647409] usb 3-1.6: MAC/BBP AR5523, RF AR2112
[ 4827.647676] usb 3-1.6: Found and initialized AR5523 device
only then, afterwards when you actually up your interface, the calls to
wpa_supplicant and crda will happen, like:
[29068.766731] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[29092.453104] NET: Registered protocol family 17
[29093.421812] wlan1: authenticate with 01:23:45:67:89:ab
[29093.431498] wlan1: send auth to 01:23:45:67:89:ab (try 1/3)
[29093.434232] wlan1: authenticated
[29093.435348] wlan1: associate with 01:23:45:67:89:ab (try 1/3)
[29093.438360] wlan1: RX AssocResp from 01:23:45:67:89:ab (capab=0x431 status=0 aid=1)
[29093.439215] wlan1: associated
[29093.439243] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[29093.439332] cfg80211: Calling CRDA for country: DE
[29093.443332] cfg80211: Regulatory domain changed to country: DE
[29093.443335] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[29093.443337] cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
[29093.443339] cfg80211: (5150000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[29093.443341] cfg80211: (5250000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[29093.443342] cfg80211: (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
[29093.443344] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
We'd need the debugging information for all of these messages,
especially the early ones about the mode switch.
Personally I'm rather confident that the existing USB IDs are correct,
namely 0x129b, 0x160c without firmware loaded and 0x129b, 0x160b after
the firmware upload has executed its modeswitch, which would be
reminiscence of your earlier games with ndiswrapper (which -surprise-
also uploads a(n eventually broken, see above) firmware). In order to
make sure to remove different firmwares from your device's RAM, you
need to physically disconnect your USB device for a moment (or power
down your whole system), unloading ndiswrapper and loading ar5523.ko
or just warmrebooting is not enough (as this won't make the device
forget its firmware).
Regards
Stefan Lippers-Hollmann
^ permalink raw reply
* [PATCH] iwlwifi: remove duplicate includes
From: Michael Opdenacker @ 2013-10-20 5:01 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, ilw, linville
Cc: linux-wireless, netdev, linux-kernel, Michael Opdenacker
Reported by "make includecheck"
Tested that the corresponding sources still compile well on x86
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/wireless/iwlwifi/iwl-io.c | 1 -
drivers/net/wireless/iwlwifi/mvm/mvm.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-io.c b/drivers/net/wireless/iwlwifi/iwl-io.c
index dfa4d2e..ad8e19a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-io.c
+++ b/drivers/net/wireless/iwlwifi/iwl-io.c
@@ -34,7 +34,6 @@
#include "iwl-csr.h"
#include "iwl-debug.h"
#include "iwl-fh.h"
-#include "iwl-csr.h"
#define IWL_POLL_INTERVAL 10 /* microseconds */
diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index b038927..bd80865 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -73,7 +73,6 @@
#include "iwl-trans.h"
#include "iwl-notif-wait.h"
#include "iwl-eeprom-parse.h"
-#include "iwl-trans.h"
#include "sta.h"
#include "fw-api.h"
#include "constants.h"
--
1.8.1.2
^ permalink raw reply related
* RE: [PATCH] iwlwifi: remove duplicate includes
From: Grumbach, Emmanuel @ 2013-10-20 6:01 UTC (permalink / raw)
To: Michael Opdenacker, Berg, Johannes, ilw@linux.intel.com,
linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1382245260-19065-1-git-send-email-michael.opdenacker@free-electrons.com>
> Subject: [PATCH] iwlwifi: remove duplicate includes
>
> Reported by "make includecheck"
>
> Tested that the corresponding sources still compile well on x86
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-
> electrons.com>
> ---
Picked up. Thanks.
^ permalink raw reply
* [PATCH] mac80211: document IEEE80211_HW_SUPPORTS_HT_CCK_RATES
From: Michael Opdenacker @ 2013-10-20 6:45 UTC (permalink / raw)
To: johannes, davem; +Cc: linux-wireless, netdev, linux-kernel, Michael Opdenacker
This patch documents the IEEE80211_HW_SUPPORTS_HT_CCK_RATES flag
in ieee80211_hw_flags.
Without this, you get countless warnings in "make htmldocs".
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
include/net/mac80211.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index cc6035f..0a26a6e 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1492,6 +1492,9 @@ struct ieee80211_tx_control {
*
* @IEEE80211_HW_TIMING_BEACON_ONLY: Use sync timing from beacon frames
* only, to allow getting TBTT of a DTIM beacon.
+ *
+ * @IEEE80211_HW_SUPPORTS_HT_CCK_RATES:
+ * Hardware has CCK support for HT clients.
*/
enum ieee80211_hw_flags {
IEEE80211_HW_HAS_RATE_CONTROL = 1<<0,
--
1.8.1.2
^ permalink raw reply related
* Re: Active scanning on DFS channels
From: Luis R. Rodriguez @ 2013-10-20 9:53 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, Johannes Berg, Simon Wunderlich
In-Reply-To: <CAA2SeNJRSPB=Hus8y1bYJ-O1Hgkd=gvNhUKnF9atqwuhd2m0aA@mail.gmail.com>
On Fri, Oct 18, 2013 at 5:53 PM, Lorenzo Bianconi
<lorenzo.bianconi83@gmail.com> wrote:
> Hi all,
>
> According to regdb.txt, DFS channels are not marked with passive scan flag:
>
> country US: DFS-FCC
> (2402 - 2472 @ 40), (3, 27)
> (5170 - 5250 @ 80), (3, 17)
> (5250 - 5330 @ 80), (3, 20), DFS
> (5490 - 5600 @ 80), (3, 20), DFS
> (5650 - 5710 @ 40), (3, 20), DFS
> (5735 - 5835 @ 80), (3, 30)
>
> Therefore STA device will perform active scanning on DFS channels even
> if the channel is not CAC checked and available yet.
This is certainly an issue, at least for the atheros drivers the ath
module ensures to alway set the passive-scan and no-ibss flags for DFS
frequencies, but we should at this point just standardize on this.
> Should we perform
> passive scan on radar channel setting new state to SCAN_DECISION and
> not to SCAN_SEND_PROBE in ieee80211_scan_state_set_channel()?
There's a few thing we need to do and I'm working on it.
1) no-ibss and passive-scan flags should be merged to a no-ir flag
2) beaconing should not be allowed if you have no-ir flag or radar
flag set but your device doesn't support DFS. If your wiphy supports
DFS and if CAC was cleared you can use that channel. If you had an AP
and a STA on the same wiphy and if the AP had DFS support and cleared
a CAC on a channel, the STA can resuse that information to do an
active scan, but it doesn't make sense to share CAC information across
different radios on the same system as we technically have no
guarantee they are on the same location, you never know.
I'm working on 1) right now.
Luis
^ permalink raw reply
* Re: [PATCH 1/6] cfg80211: export reg_initiator_name()
From: Luis R. Rodriguez @ 2013-10-20 9:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, linux-wireless
In-Reply-To: <1382120516.14393.21.camel@jlt4.sipsolutions.net>
On Fri, Oct 18, 2013 at 8:21 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2013-10-18 at 14:01 -0400, John W. Linville wrote:
>> I'm going to merge this series, including the cfg80211.h change...FYI!
>
> I already have this patch though, hmm.
I have another series similar to this coming up soon but much more
intrusive, it'll deal with cfg80211 / nl80211 flags and tons of
drivers use them. I'll just post it to both and you guys can decide
what tree this goes in. Just giving an early heads up now.
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Luis R. Rodriguez @ 2013-10-20 10:39 UTC (permalink / raw)
To: Chauhan, Rajesh
Cc: Dan Williams, Johannes Berg, linux-wireless@vger.kernel.org,
Malinen, Jouni, Bahini, Henri, Chang, Leo, Luo, Xun
In-Reply-To: <D19FD2B13A40CD4B8DA64DB9B8F112E9218DAF6F@nasanexd01a.na.qualcomm.com>
On Thu, Oct 17, 2013 at 9:51 PM, Chauhan, Rajesh
<rajeshc@qca.qualcomm.com> wrote:
> Hi Dan,
>
> Thanks for your comments.
>
> Current patch is to report event asynchronously and that would be needed even if we have your suggested interface of client collecting that information upfront, which seems like you also kind of agree, because RF environment may change later and generating an event at that time with frequency details would help. So your suggested approach of "mechanism for the client to get this information" in itself seems like a candidate for a separate patch.
The infrastructure for this sort of thing that me, Inaky and Marcel
had proposed in 2007 is the Frequency Broker:
http://wireless.kernel.org/en/developers/FrequencyBroker
> On the race condition which you described - thanks!, but it is something which implementation of driver would need to take care. Similarly, user space can have implementation to cache information on receipt of the event to use it later.
This patch is vague. Once we set something as API we have to live with
it, I am not comfortable with this patch having enough information for
proper usage by different drivers for the same purpose or intent. The
only real positive argument that could be used here is where something
like Android might have already embraced some similar API but are we
going to always just enable API on Linux just because Android did it
without thinking about proper long term architecture? I don't think
so.
Luis
^ permalink raw reply
* Re: regarding Linux Wifi driver
From: Stanislaw Gruszka @ 2013-10-21 5:43 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: Daniel Wrede, linux-wireless@vger.kernel.org
In-Reply-To: <CACna6rzC_jOeE1=r85EJg=jdrr-gbmKCJ1fFwUwySczRsZskSQ@mail.gmail.com>
On Fri, Oct 18, 2013 at 02:49:15PM +0200, Rafał Miłecki wrote:
> 2013/10/18 Daniel Wrede <dawre12@student.sdu.dk>:
> > I do have a question regarding the drivers on http://wireless.kernel.org/en/users/Drivers/iwlegacy
>
> You're writing to generic Linux wireless ML, so please include main
> info in the thread (driver name / wireless chipset).
>
>
> > My kernel version is 3.8.0-19-generic. Which driver should I use for the WiFi Link 4965AGN? I am a little confused by the numbering.
>
> You linked to the "iwlegacy" driver wiki page and this page lists
> 4965AGN chipset as supported. That's pretty obvious you need an
> iwlegacy driver, isn't it?
Perhaps confusion came from fact that iwlegacy is a common/library module.
Driver module for the 4965 chip is iwl4965. I've updated the wiki page with
information about individual modules.
Stanislaw
^ permalink raw reply
* Re: Active scanning on DFS channels
From: Kalle Valo @ 2013-10-21 6:19 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Lorenzo Bianconi, linux-wireless, Johannes Berg, Simon Wunderlich
In-Reply-To: <CAB=NE6WSNZ10pNfKN5-o0cnVYkZbt4gGAzPOcO=Dtw5aUj+wGA@mail.gmail.com>
"Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:
>> Should we perform
>> passive scan on radar channel setting new state to SCAN_DECISION and
>> not to SCAN_SEND_PROBE in ieee80211_scan_state_set_channel()?
>
> There's a few thing we need to do and I'm working on it.
>
> 1) no-ibss and passive-scan flags should be merged to a no-ir flag
For me IR always reminds of infrared, so the name no-ir is a bit vague
to me :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: remove P2P from supported interface modes for 10.X FW
From: Kalle Valo @ 2013-10-21 6:30 UTC (permalink / raw)
To: Bartosz Markowski; +Cc: ath10k, linux-wireless
In-Reply-To: <1382090878-22216-1-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> writes:
> FW 10.X does not support P2P, stop advertising it to mac80211.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
[...]
> @@ -3478,7 +3504,11 @@ int ath10k_mac_register(struct ath10k *ar)
> */
> ar->hw->queues = 4;
>
> - ar->hw->wiphy->iface_combinations = &ath10k_if_comb;
> + if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features))
> + ar->hw->wiphy->iface_combinations = &ath10k_10x_if_comb;
> + else
> + ar->hw->wiphy->iface_combinations = &ath10k_if_comb;
I think it would be better to have a separate feature flag for this,
like NO_P2P or something like that. Just in case we want to disable P2P
in other firmware branches.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/2] ath10k: extend number of AP interfaces for 10.X firmware
From: Kalle Valo @ 2013-10-21 6:31 UTC (permalink / raw)
To: Bartosz Markowski; +Cc: ath10k, linux-wireless
In-Reply-To: <1382090878-22216-2-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> writes:
> This firmware can support up to 8 AP interfaces.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index af046c4..dc65dcd 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -3255,7 +3255,7 @@ static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = {
> .types = BIT(NL80211_IFTYPE_STATION)
> },
> {
> - .max = 7,
> + .max = 8,
> .types = BIT(NL80211_IFTYPE_AP)
> },
> };
Why only with 10.x firmware branch? Doesn't the main branch support 8
interfaces?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/2] ath10k: extend number of AP interfaces for 10.X firmware
From: Bartosz Markowski @ 2013-10-21 6:51 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless@vger.kernel.org
In-Reply-To: <87iowruocz.fsf@kamboji.qca.qualcomm.com>
On 21 October 2013 08:31, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Bartosz Markowski <bartosz.markowski@tieto.com> writes:
>
>> This firmware can support up to 8 AP interfaces.
>>
>> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
>> ---
>> drivers/net/wireless/ath/ath10k/mac.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index af046c4..dc65dcd 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -3255,7 +3255,7 @@ static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = {
>> .types = BIT(NL80211_IFTYPE_STATION)
>> },
>> {
>> - .max = 7,
>> + .max = 8,
>> .types = BIT(NL80211_IFTYPE_AP)
>> },
>> };
>
> Why only with 10.x firmware branch? Doesn't the main branch support 8
> interfaces?
With .636 there's a firmware crash when we try to create interface 8 (ap mode).
--
Bartosz
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: remove P2P from supported interface modes for 10.X FW
From: Bartosz Markowski @ 2013-10-21 6:52 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless@vger.kernel.org
In-Reply-To: <87mwm3uoep.fsf@kamboji.qca.qualcomm.com>
On 21 October 2013 08:30, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Bartosz Markowski <bartosz.markowski@tieto.com> writes:
>
>> FW 10.X does not support P2P, stop advertising it to mac80211.
>>
>> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
>
> [...]
>
>> @@ -3478,7 +3504,11 @@ int ath10k_mac_register(struct ath10k *ar)
>> */
>> ar->hw->queues = 4;
>>
>> - ar->hw->wiphy->iface_combinations = &ath10k_if_comb;
>> + if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features))
>> + ar->hw->wiphy->iface_combinations = &ath10k_10x_if_comb;
>> + else
>> + ar->hw->wiphy->iface_combinations = &ath10k_if_comb;
>
> I think it would be better to have a separate feature flag for this,
> like NO_P2P or something like that. Just in case we want to disable P2P
> in other firmware branches.
Make sense. I will change this.
--
Bartosz
^ permalink raw reply
* [PATCH] rt2x00: rt2800lib: Update BBP register initialization for RT53xx
From: Kevin Lo @ 2013-10-21 7:38 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users
Update bbp register initialization for RT53xx chips to match with the
latest MediaTek/Ralink driver.
Based on: NICInitRT5390BbpRegisters()
From: DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5390.c
Signed-off-by: Kevin Lo <kevlo.org>
---
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index c5738f1..eae635a 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -5462,15 +5462,14 @@ static void rt2800_init_bbp_53xx(struct rt2x00_dev *rt2x00dev)
rt2800_bbp_write(rt2x00dev, 68, 0x0b);
- rt2800_bbp_write(rt2x00dev, 69, 0x12);
+ rt2800_bbp_write(rt2x00dev, 69, 0x0d);
+ rt2800_bbp_write(rt2x00dev, 70, 0x06);
rt2800_bbp_write(rt2x00dev, 73, 0x13);
rt2800_bbp_write(rt2x00dev, 75, 0x46);
rt2800_bbp_write(rt2x00dev, 76, 0x28);
rt2800_bbp_write(rt2x00dev, 77, 0x59);
- rt2800_bbp_write(rt2x00dev, 70, 0x0a);
-
rt2800_bbp_write(rt2x00dev, 79, 0x13);
rt2800_bbp_write(rt2x00dev, 80, 0x05);
rt2800_bbp_write(rt2x00dev, 81, 0x33);
@@ -5513,6 +5512,7 @@ static void rt2800_init_bbp_53xx(struct rt2x00_dev *rt2x00dev)
if (rt2x00_rt(rt2x00dev, RT5392)) {
rt2800_bbp_write(rt2x00dev, 134, 0xd0);
rt2800_bbp_write(rt2x00dev, 135, 0xf6);
+ rt2800_bbp_write(rt2x00dev, 148, 0x84);
}
rt2800_disable_unused_dac_adc(rt2x00dev);
^ permalink raw reply related
* Re: WIFI USB-Stick for P2P
From: David Herrmann @ 2013-10-21 8:29 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: Alexander Müller, linux-wireless@vger.kernel.org
In-Reply-To: <525316EF.6070102@rempel-privat.de>
Hi
On Mon, Oct 7, 2013 at 10:17 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 07.10.2013 11:08, schrieb Alexander Müller:
>> Hello linux-wireless,
>>
>> I'm wondering if there is a list of usb wifi devices having a good and stable p2p support for wifi direct. We are currently using an AVM Fritz wifi stick that is supported by the carl9170 driver, but it is experiencing random failures and stalls which require a hardware reset. The p2p howto page at http://wireless.kernel.org/en/developers/p2p/howto suggests that there may be other devices and drivers supporting p2p, but I haven't figured out exactly which devices work best.
>>
>> Can you give me a hint?
>
> You can try ath9k_htc based device. It should be able to support P2P,
> but right now i was not able to transfer any data. p2p_find and
> p2p_connect seems to work.
>
> If you wont to do some more testing with ath9k_htc, please contact me.
If anyone else is trying this, I was able to transfer data between my
Android device and a linux host:
Android device is a Nexus 4. To wait for connections, go to
Settings->Wifi->Wifi-Direct
On the linux host, I used "Sony UWABR100", a ath9k_htc dual-band
(2.4/5Ghz) USB pluggable device. As kernel I used 3.12-rc3.
At least wpa_supplicant-2.0 is needed. As config-file I used:
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
device_name=my-device-name
device_type=1-0050F204-1
Then run wpa_supplicant via:
wpa_supplicant -Dnl80211 -c /path/to/p2p.conf -i wlan0 -dt
This information is also available here:
http://wireless.kernel.org/en/developers/p2p/howto
To connect your device, run "wpa_cli" on the host. Use "p2p_find" and
wait for your android device to be detected. Then run "p2p_connect
<android-mac> pbc" to connect via WPS-PBC. After a few seconds the
android device shows a pop-up where you need to press "Accept".
This will give you a new interface p2p-wlan0-0 (or similar). If you're
the GO, you need to assign an IP address and start a dhcp-daemon (I
used udhcpd). Otherwise, Android disconnects after a short timeout
(about 5s). Once the dhcpd is running, the android device acquires an
IP address and you can start communication. The IP network is fully
set up.
I hope this helps!
David
Some links I found useful:
http://processors.wiki.ti.com/index.php/OMAP_Wireless_Connectivity_NLCP_WiFi_Direct_Configuration_Scripts
http://svn.dd-wrt.com/browser/src/router/hostapd-wps/wpa_supplicant/README-P2P?rev=16495
http://developer.android.com/guide/topics/connectivity/wifip2p.html
^ permalink raw reply
* [PATCH 3.12] cfg80211: fix scheduled scan pointer access
From: Johannes Berg @ 2013-10-21 9:59 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Since rdev->sched_scan_req is dereferenced outside the
lock protecting it, this might be done at the wrong
time, causing crashes. Move the dereference to where
it should be - inside the RTNL locked section.
Cc: stable@vger.kernel.org [3.8+]
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index eeb7148..d4397eb 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -254,10 +254,10 @@ void __cfg80211_sched_scan_results(struct work_struct *wk)
rdev = container_of(wk, struct cfg80211_registered_device,
sched_scan_results_wk);
- request = rdev->sched_scan_req;
-
rtnl_lock();
+ request = rdev->sched_scan_req;
+
/* we don't have sched_scan_req anymore if the scan is stopping */
if (request) {
if (request->flags & NL80211_SCAN_FLAG_FLUSH) {
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH] mac80211: document IEEE80211_HW_SUPPORTS_HT_CCK_RATES
From: Johannes Berg @ 2013-10-21 10:22 UTC (permalink / raw)
To: Michael Opdenacker; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <1382251529-22540-1-git-send-email-michael.opdenacker@free-electrons.com>
On Sun, 2013-10-20 at 08:45 +0200, Michael Opdenacker wrote:
> This patch documents the IEEE80211_HW_SUPPORTS_HT_CCK_RATES flag
> in ieee80211_hw_flags.
>
> Without this, you get countless warnings in "make htmldocs".
I already have an equivalent patch with correct documentation :)
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix uninitialized variable
From: Johannes Berg @ 2013-10-21 10:26 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless
In-Reply-To: <1382133420-1545-1-git-send-email-michal.kazior@tieto.com>
On Fri, 2013-10-18 at 14:57 -0700, Michal Kazior wrote:
> CSA completion could call in a driver
> bss_info_changed() with a garbled `changed` flag
> leading to all sorts of problems.
Applied.
johannes
^ permalink raw reply
* rtl8187 AP/Master mode
From: Mark Moes @ 2013-10-21 11:21 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <DUB119-W4654D1E1A8377FA92B6E049E010@phx.gbl>
Hi,
I was wondering if there's any work being done on the AP/Master mode implementation of the rtl8187 chip as listed here: http://wireless.kernel.org/en/users/Drivers/rtl8187
If not, could anyone give a guesstimate of how much work is needed to write the code for this functionality?
Mark
^ permalink raw reply
* Re: [PATCH 00/23 v2] cleanup: introduce br/netdev/netif/wiphy_<foo>_ratelimited() and use them to simplify code
From: Kefeng Wang @ 2013-10-21 11:26 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-kernel, netfilter, netdev, linux-wireless
In-Reply-To: <1382069482.22110.164.camel@joe-AO722>
On 10/18 12:11, Joe Perches wrote:
> (resending to lists only because of multiple X's in the subject line)
>
> On Fri, 2013-10-18 at 11:52 +0800, Kefeng Wang wrote:
>> v1-v2:
>>
>> Introduce macro br/netdev/netif/wiphy_XXX_ratelimited() according
>> to Joe Perches's advice. The macros are similar to net_XXX_ratelimited()
>> which is more clarifying than net_ratelimited_function(), then use them
>> to simplify code.
>
> There are some conceptual differences between these
> implementations and other <foo>_ratelimited uses.
>
> For every other subsystem but net, there is a per-location
> struct ratelimit_state.
yes, but I think I just changed net subsystem. Macro DEFINE_RATELIMIT_STATE used
DEFAULT_RATELIMIT_INTERVAL and DEFAULT_RATELIMIT_BURST, so what do you think?
Could anyone give me some advises ?
> Here you've made the global net_ratelimit_state replace all
> of these individual structs so there is some new interaction.
>
> Dunno if that's good or bad.
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH] mac80211: document IEEE80211_HW_SUPPORTS_HT_CCK_RATES
From: Michael Opdenacker @ 2013-10-21 11:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <1382350961.14310.42.camel@jlt4.sipsolutions.net>
Hi Johannes,
On 10/21/2013 12:22 PM, Johannes Berg wrote:
> On Sun, 2013-10-20 at 08:45 +0200, Michael Opdenacker wrote:
>> This patch documents the IEEE80211_HW_SUPPORTS_HT_CCK_RATES flag
>> in ieee80211_hw_flags.
>>
>> Without this, you get countless warnings in "make htmldocs".
> I already have an equivalent patch with correct documentation :)
Great! Then let's use your patch :)
Thanks,
Michael.
--
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
^ permalink raw reply
* Re: Active scanning on DFS channels
From: Luis R. Rodriguez @ 2013-10-21 12:51 UTC (permalink / raw)
To: Kalle Valo
Cc: Lorenzo Bianconi, linux-wireless, Johannes Berg, Simon Wunderlich
In-Reply-To: <87wql7tac9.fsf@purkki.adurom.net>
On Mon, Oct 21, 2013 at 8:19 AM, Kalle Valo <kvalo@adurom.com> wrote:
> "Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:
>
>>> Should we perform
>>> passive scan on radar channel setting new state to SCAN_DECISION and
>>> not to SCAN_SEND_PROBE in ieee80211_scan_state_set_channel()?
>>
>> There's a few thing we need to do and I'm working on it.
>>
>> 1) no-ibss and passive-scan flags should be merged to a no-ir flag
>
> For me IR always reminds of infrared, so the name no-ir is a bit vague
> to me :)
Any recommendations? I'm just lazy.
Luis
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: fix DFS channel recovery timeout
From: Johannes Berg @ 2013-10-21 13:04 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless
In-Reply-To: <1382034072-13541-1-git-send-email-michal.kazior@tieto.com>
On Thu, 2013-10-17 at 11:21 -0700, Michal Kazior wrote:
> The timeout was not properly converted from msecs
> to jiffies. As a result channel transition to
> NL80211_DFS_USABLE was delayed depending on
> CONFIG_HZ configuration, e.g. HZ=100 would delay
> the NOP from 30 minutes to 300 minutes.
Applied both, but I think getting into 3.12 might be hard.
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox