* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
From: Arend van Spriel @ 2013-10-31 17:42 UTC (permalink / raw)
To: Undekari, Sunil Dutt
Cc: Johannes Berg, linux-wireless@vger.kernel.org, j@w1.fi
In-Reply-To: <26F3B0343EE4744AA14EEEF9E1E534511F7A6606@aphydexd01a>
On 10/31/13 16:54, Undekari, Sunil Dutt wrote:
>> Just do it in the supplicant - that has full control over what's going on with a given device.
>> Trying to have the kernel manage multiple things that may or may not be exclusive and are all done in userspace is going to be a futile exercise.
> Please note that the scans that are mentioned by me in this context are not triggered by the supplicant, rather the host driver would initiate them.
So how would the scenario look like. The host driver will get involved
in setting up the P2P connection so that knowledge is already available
to defer the scans or am I missing something.
Regards,
Arend
> The driver / firmware would do such scans for a better roam performance.
> I would say, some handshake between the supplicant and the driver would be needed for a better understanding on the operations.
> Please have your say.
> Regards,
> Sunil
>
> -----Original Message-----
> From: Johannes Berg [mailto:johannes@sipsolutions.net]
> Sent: Thursday, October 31, 2013 8:55 PM
> To: Undekari, Sunil Dutt
> Cc: linux-wireless@vger.kernel.org; j@w1.fi
> Subject: Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
>
> On Thu, 2013-10-31 at 15:22 +0000, Undekari, Sunil Dutt wrote:
>>> That's not what the critical protocol stuff was designed for, so no.
>> I would consider the P2P connection phase (P2P+WPS+WPA) to be critical
>> and any off channel operations (scan) triggered by the host driver
>> would result in the delayed / failed P2P connection attempt.
>> I suppose there should be an indication to the host driver w.r.t p2p
>> connection attempt so that any off load operations on any other
>> interface sharing the same radio would be avoided by the driver.
>> Since there is already an existing interface through the critical
>> protocol indication, I thought of extending it to also include a P2P
>> protocol/connection. This new proto id would be an indication to the
>> drivers to allow the scan on the current interface and avoid any scans
>> on another considering the fact that a p2p connection requires a scan.
>> Do you propose an alternative (a new interface?) to achieve the same?
>
> Just do it in the supplicant - that has full control over what's going on with a given device.
>
> Trying to have the kernel manage multiple things that may or may not be exclusive and are all done in userspace is going to be a futile exercise.
>
> johannes
>
> N�����r��y���b�X��ǧv�^�){.n�+����{��*ޕ�,�{ay�\x1dʇڙ�,j\a��f���h���z�\x1e�w���\f���j:+v���w�j�m����\a����zZ+�����ݢj"��!�i
^ permalink raw reply
* Re: [PATCH 1/5] cfg80211/mac80211: DFS setup chandef for cac event
From: Johannes Berg @ 2013-10-31 16:47 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: linux-wireless
In-Reply-To: <1382984824-3729-1-git-send-email-janusz.dziedzic@tieto.com>
I'd apply patches 1-3 but those don't seem very useful in themselves,
please resend the entire series when/if you address my comments.
johannes
^ permalink raw reply
* Re: [PATCH 5/5] cfg80211: fix dfs channel state after stopping AP
From: Johannes Berg @ 2013-10-31 16:46 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: linux-wireless, Marek Puzyniak
In-Reply-To: <1382984824-3729-5-git-send-email-janusz.dziedzic@tieto.com>
On Mon, 2013-10-28 at 19:27 +0100, Janusz Dziedzic wrote:
> + } else if (sdata->radar_required) {
> + /*
> + * AP stopped on DFS channel so change that channel state
> + * to NL80211_DFS_USABLE again.
> + */
> + cfg80211_leave_dfs_channel(wiphy, &sdata->vif.bss_conf.chandef);
Would it make sense to just do this in cfg80211?
johannes
^ permalink raw reply
* Re: [PATCH 4/5] cfg80211: DFS check chandef usable before CAC
From: Johannes Berg @ 2013-10-31 16:46 UTC (permalink / raw)
To: Janusz Dziedzic; +Cc: linux-wireless
In-Reply-To: <1382984824-3729-4-git-send-email-janusz.dziedzic@tieto.com>
On Mon, 2013-10-28 at 19:27 +0100, Janusz Dziedzic wrote:
> +/**
> + * cfg80211_chandef_dfs_usable - checks if chandef is usable and we can
> + * start CAC on such chandef.
The short kernel-doc description can't span multiple lines
johannes
^ permalink raw reply
* Crash related to wmi_event_mgt_rx (or ieee80211_rx).
From: Ben Greear @ 2013-10-31 16:45 UTC (permalink / raw)
To: ath10k, linux-wireless@vger.kernel.org
This is yesterday's ath tree, with Michal's ath10k RFT patch series applied,
and a few ath10k patches of my own. Using modified ath10k firmware that supports
two stations to same AP. This happened on module reload.
(gdb) l *(ath10k_wmi_event_mgmt_rx+0x246)
0xb501 is in ath10k_wmi_event_mgmt_rx (/mnt/sda/home/greearb/git/linux.ath/drivers/net/wireless/ath/ath10k/wmi.c:959).
954 * because they can originally come in along with a trailer
955 */
956 skb_trim(skb, buf_len);
957
958 ieee80211_rx(ar->hw, skb);
959 return 0;
960 }
961
962 static int freq_to_idx(struct ath10k *ar, int freq)
963 {
(gdb) l *(ieee80211_rx+0x54f)
0x1ac7a is in ieee80211_rx (/mnt/sda/home/greearb/git/linux.ath/arch/x86/include/asm/bitops.h:329).
324 }
325
326 static __always_inline int constant_test_bit(long nr, const volatile unsigned long *addr)
327 {
328 return ((1UL << (nr & (BITS_PER_LONG-1))) &
329 (addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
330 }
331
332 static inline int variable_test_bit(long nr, volatile const unsigned long *addr)
333 {
general protection fault: 0000 [#1] PREEMPT SMP
Modules linked in: ath10k_pci(-) ath10k_core nfsv3 nfs_acl nfs fscache nf_nat_ipv4 nf_nat veth 8021q garp s]
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G WC 3.12.0-rc5-wl+ #2
Hardware name: To be filled by O.E.M. To be filled by O.E.M./HURONRIVER, BIOS 4.6.5 05/02/2012
task: ffffffff81a14490 ti: ffffffff81a00000 task.ti: ffffffff81a00000
RIP: 0010:[<ffffffffa032ac7a>] [<ffffffffa032ac7a>] ieee80211_rx+0x54f/0x649 [mac80211]
RSP: 0018:ffff88021fa03b30 EFLAGS: 00010287
RAX: ffff880032c31ad0 RBX: ffff880032c308a0 RCX: 01526201bc0b4003
RDX: 0000000000000003 RSI: ffffffff81a14ba8 RDI: ffffffff81a14ba8
RBP: ffff88021fa03bc0 R08: ffff88020d766401 R09: ffff88020d766418
R10: ffffffff810c1f95 R11: ffff880032c30bd0 R12: ffff880032e11b00
R13: ffff880034324ca0 R14: ffff880032e36464 R15: dead000000100100
FS: 0000000000000000(0000) GS:ffff88021fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000001a90ae0 CR3: 0000000001a0d000 CR4: 00000000000407f0
Stack:
ffff88021fa03b68 0000000000000001 00000000ffffffe6 dead000000100100
ffff8800cc013600 ffff880032c308a0 ffff8800cd658a00 ffff8802120bd668
0000000000000000 0000001000000000 0000000000000010 0000000000000000
Call Trace:
<IRQ>
[<ffffffffa0a01501>] ath10k_wmi_event_mgmt_rx+0x246/0x27e [ath10k_core]
[<ffffffffa0a0435a>] ath10k_wmi_process_rx+0x6cc/0xa5a [ath10k_core]
[<ffffffffa09fb07a>] ? ath10k_dbg+0x5c/0x5e [ath10k_core]
[<ffffffffa09fda39>] ath10k_htc_rx_completion_handler+0x3b4/0x3e8 [ath10k_core]
[<ffffffffa09fb07a>] ? ath10k_dbg+0x5c/0x5e [ath10k_core]
[<ffffffffa0a18fe5>] ath10k_pci_process_ce+0x1a2/0x21e [ath10k_pci]
[<ffffffffa0a190ae>] ath10k_pci_ce_recv_data+0x4d/0x123 [ath10k_pci]
[<ffffffffa0a1b650>] ath10k_ce_per_engine_service+0x6b/0xab [ath10k_pci]
[<ffffffffa0a1b6df>] ath10k_ce_per_engine_service_any+0x4f/0x6c [ath10k_pci]
[<ffffffffa0a1a250>] ath10k_pci_tasklet+0x1e/0x4e [ath10k_pci]
[<ffffffff810a2bed>] tasklet_action+0x88/0xe8
[<ffffffff810de341>] ? handle_irq_event+0x47/0x5e
[<ffffffff810a2eb8>] __do_softirq+0xc9/0x18e
[<ffffffff81597dbc>] call_softirq+0x1c/0x30
[<ffffffff8100c0d2>] do_softirq+0x45/0x9b
[<ffffffff810a30a0>] irq_exit+0x56/0x9b
[<ffffffff8100bd58>] do_IRQ+0x89/0xa0
[<ffffffff81591eb2>] common_interrupt+0x72/0x72
<EOI>
[<ffffffff81495b80>] ? arch_local_irq_enable+0x8/0xd
[<ffffffff810efe16>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff81495ead>] cpuidle_enter_state+0x51/0xbc
[<ffffffff81495fe4>] cpuidle_idle_call+0xcc/0x118
[<ffffffff81011b57>] arch_cpu_idle+0x9/0x21
[<ffffffff810dda69>] cpu_startup_entry+0xae/0x119
[<ffffffff8157fedd>] rest_init+0xc1/0xc8
[<ffffffff8157fe1c>] ? csum_partial_copy_generic+0x16c/0x16c
[<ffffffff81ae4d5c>] start_kernel+0x3b2/0x3bf
[<ffffffff81ae47b2>] ? repair_env_string+0x5a/0x5a
[<ffffffff81ae44b8>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81ae45a4>] x86_64_start_kernel+0xea/0xf7
Code: a8 48 89 45 a0 e9 99 00 00 00 4c 89 e7 e8 13 77 1a e1 e9 fa fd ff ff 48 8b 83 30 12 00 00 45 31 ed 48
RIP [<ffffffffa032ac7a>] ieee80211_rx+0x54f/0x649 [mac80211]
RSP <ffff88021fa03b30>
---[ end trace 1385eeb9a1ac09ee ]---
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 00/14] wlan: consolidate passive-scan and no-ibss flags
From: Luis R. Rodriguez @ 2013-10-31 16:42 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, linux-wireless, Janusz Dziedzic, Shete, Mihir,
Bhattacharyya, Tushnim, Peter Senna Tschudin, Julia Lawall
In-Reply-To: <1383237294.14302.5.camel@jlt4.sipsolutions.net>
On Thu, Oct 31, 2013 at 5:34 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2013-10-21 at 19:22 +0200, Luis R. Rodriguez wrote:
>> John, Johannes,
>>
>> This series addresses consolidating passive-scan and no-ibss flags.
>> Since its crosses over drivers I'll let you guys decide what tree
>> this goes into.
>
> Alright, I've applied this, but in one single big patch, and I've redone
> (most of) the driver updates using spatch.
>
> There were conflicts applying the patch, so most likely John will get
> conflicts when merging my tree. I've added the spatches to the commit
> log so that should be easy to resolve.
Oh I love to hear merge conflict issues are being addressed with
Coccinelle, thanks for the update. I should have just provided the
SmPL for it in the first place ;) -- my bad.
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: do not compute offset from ssn in Rx AMPDU reordering buffer
From: Johannes Berg @ 2013-10-31 16:42 UTC (permalink / raw)
To: Karl Beldan; +Cc: linux-wireless, Karl Beldan
In-Reply-To: <1382622812-18253-1-git-send-email-karl.beldan@gmail.com>
On Thu, 2013-10-24 at 15:53 +0200, Karl Beldan wrote:
> From: Karl Beldan <karl.beldan@rivierawaves.com>
>
> ATM, frames with SN sn are mapped into the sta reordering buffer
> sta->ampdu_mlme->tid_rx->reorder_buf at index
> ieee80211_sn_sub(sn, tid_rx->ssn) % tid_rx->buf_size.
> This offset calculation is useless, and this change replaces the index
> with sn % tid_rx->buf_size.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 00/14] wlan: consolidate passive-scan and no-ibss flags
From: Johannes Berg @ 2013-10-31 16:34 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville, linux-wireless, janusz.dziedzic, smihir, tushnimb
In-Reply-To: <1382376158-25586-1-git-send-email-mcgrof@do-not-panic.com>
On Mon, 2013-10-21 at 19:22 +0200, Luis R. Rodriguez wrote:
> John, Johannes,
>
> This series addresses consolidating passive-scan and no-ibss flags.
> Since its crosses over drivers I'll let you guys decide what tree
> this goes into.
Alright, I've applied this, but in one single big patch, and I've redone
(most of) the driver updates using spatch.
There were conflicts applying the patch, so most likely John will get
conflicts when merging my tree. I've added the spatches to the commit
log so that should be easy to resolve.
johannes
^ permalink raw reply
* Re: [PATCH] Revert "mac80211: allow disable power save in mesh"
From: Johannes Berg @ 2013-10-31 16:15 UTC (permalink / raw)
To: Bob Copeland; +Cc: Chun-Yeow Yeoh, linux-wireless
In-Reply-To: <1383084719-26610-1-git-send-email-me@bobcopeland.com>
On Tue, 2013-10-29 at 18:11 -0400, Bob Copeland wrote:
> This reverts commit ee1f668136b2fb6640ee2d54c2a525ea41f98211.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH v2] nl80211: better document NL80211_CMD_TDLS_MGMT
From: Johannes Berg @ 2013-10-31 16:14 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless
In-Reply-To: <1383224075-15157-1-git-send-email-arik@wizery.com>
On Thu, 2013-10-31 at 14:54 +0200, Arik Nemtsov wrote:
> This command has different semantics depending on the action code sent.
> Document this fact and detail the supported action codes.
Applied, thanks.
johannes
^ permalink raw reply
* RE: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
From: Undekari, Sunil Dutt @ 2013-10-31 15:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, j@w1.fi
In-Reply-To: <1383233115.14302.2.camel@jlt4.sipsolutions.net>
Pkp1c3QgZG8gaXQgaW4gdGhlIHN1cHBsaWNhbnQgLSB0aGF0IGhhcyBmdWxsIGNvbnRyb2wgb3Zl
ciB3aGF0J3MgZ29pbmcgb24gd2l0aCBhIGdpdmVuIGRldmljZS4NCj5UcnlpbmcgdG8gaGF2ZSB0
aGUga2VybmVsIG1hbmFnZSBtdWx0aXBsZSB0aGluZ3MgdGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBl
eGNsdXNpdmUgYW5kIGFyZSBhbGwgZG9uZSBpbiB1c2Vyc3BhY2UgaXMgZ29pbmcgdG8gYmUgYSBm
dXRpbGUgZXhlcmNpc2UuDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBzY2FucyB0aGF0IGFyZSBtZW50
aW9uZWQgYnkgbWUgaW4gdGhpcyBjb250ZXh0IGFyZSBub3QgdHJpZ2dlcmVkIGJ5IHRoZSBzdXBw
bGljYW50LCByYXRoZXIgdGhlIGhvc3QgZHJpdmVyIHdvdWxkIGluaXRpYXRlIHRoZW0uDQpUaGUg
ZHJpdmVyIC8gZmlybXdhcmUgd291bGQgZG8gc3VjaCBzY2FucyBmb3IgYSBiZXR0ZXIgcm9hbSBw
ZXJmb3JtYW5jZS4NCkkgd291bGQgc2F5LCBzb21lIGhhbmRzaGFrZSBiZXR3ZWVuIHRoZSBzdXBw
bGljYW50IGFuZCB0aGUgZHJpdmVyIHdvdWxkIGJlIG5lZWRlZCBmb3IgYSBiZXR0ZXIgdW5kZXJz
dGFuZGluZyBvbiB0aGUgb3BlcmF0aW9ucy4NClBsZWFzZSBoYXZlIHlvdXIgc2F5Lg0KUmVnYXJk
cywNClN1bmlsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2hhbm5lcyBC
ZXJnIFttYWlsdG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0gDQpTZW50OiBUaHVyc2RheSwg
T2N0b2JlciAzMSwgMjAxMyA4OjU1IFBNDQpUbzogVW5kZWthcmksIFN1bmlsIER1dHQNCkNjOiBs
aW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IGpAdzEuZmkNClN1YmplY3Q6IFJlOiBbUEFU
Q0hdIGNmZzgwMjExOiBJbnRyb2R1Y2UgY3JpdGljYWwgcHJvdG9jb2wgaW5kaWNhdGlvbiBmb3Ig
cDJwIGNvbm5lY3Rpb24uDQoNCk9uIFRodSwgMjAxMy0xMC0zMSBhdCAxNToyMiArMDAwMCwgVW5k
ZWthcmksIFN1bmlsIER1dHQgd3JvdGU6DQo+ID4gVGhhdCdzIG5vdCB3aGF0IHRoZSBjcml0aWNh
bCBwcm90b2NvbCBzdHVmZiB3YXMgZGVzaWduZWQgZm9yLCBzbyBuby4NCj4gSSB3b3VsZCBjb25z
aWRlciB0aGUgUDJQIGNvbm5lY3Rpb24gcGhhc2UgKFAyUCtXUFMrV1BBKSB0byBiZSBjcml0aWNh
bCANCj4gYW5kIGFueSBvZmYgY2hhbm5lbCBvcGVyYXRpb25zIChzY2FuKSB0cmlnZ2VyZWQgYnkg
dGhlIGhvc3QgZHJpdmVyIA0KPiB3b3VsZCByZXN1bHQgaW4gdGhlIGRlbGF5ZWQgLyBmYWlsZWQg
UDJQIGNvbm5lY3Rpb24gYXR0ZW1wdC4NCj4gSSBzdXBwb3NlIHRoZXJlIHNob3VsZCBiZSBhbiBp
bmRpY2F0aW9uIHRvIHRoZSBob3N0IGRyaXZlciB3LnIudCBwMnAgDQo+IGNvbm5lY3Rpb24gYXR0
ZW1wdCBzbyB0aGF0IGFueSBvZmYgbG9hZCBvcGVyYXRpb25zIG9uIGFueSBvdGhlciANCj4gaW50
ZXJmYWNlIHNoYXJpbmcgdGhlIHNhbWUgcmFkaW8gd291bGQgYmUgYXZvaWRlZCBieSB0aGUgZHJp
dmVyLg0KPiBTaW5jZSB0aGVyZSBpcyBhbHJlYWR5IGFuIGV4aXN0aW5nIGludGVyZmFjZSB0aHJv
dWdoIHRoZSBjcml0aWNhbCANCj4gcHJvdG9jb2wgaW5kaWNhdGlvbiwgSSB0aG91Z2h0IG9mIGV4
dGVuZGluZyBpdCB0byBhbHNvIGluY2x1ZGUgYSBQMlAgDQo+IHByb3RvY29sL2Nvbm5lY3Rpb24u
IFRoaXMgbmV3IHByb3RvIGlkIHdvdWxkIGJlIGFuIGluZGljYXRpb24gdG8gdGhlIA0KPiBkcml2
ZXJzIHRvIGFsbG93IHRoZSBzY2FuIG9uIHRoZSBjdXJyZW50IGludGVyZmFjZSBhbmQgYXZvaWQg
YW55IHNjYW5zIA0KPiBvbiBhbm90aGVyIGNvbnNpZGVyaW5nIHRoZSBmYWN0IHRoYXQgYSBwMnAg
Y29ubmVjdGlvbiByZXF1aXJlcyBhIHNjYW4uDQo+IERvIHlvdSBwcm9wb3NlIGFuIGFsdGVybmF0
aXZlIChhIG5ldyBpbnRlcmZhY2U/KSB0byBhY2hpZXZlIHRoZSBzYW1lPw0KDQpKdXN0IGRvIGl0
IGluIHRoZSBzdXBwbGljYW50IC0gdGhhdCBoYXMgZnVsbCBjb250cm9sIG92ZXIgd2hhdCdzIGdv
aW5nIG9uIHdpdGggYSBnaXZlbiBkZXZpY2UuDQoNClRyeWluZyB0byBoYXZlIHRoZSBrZXJuZWwg
bWFuYWdlIG11bHRpcGxlIHRoaW5ncyB0aGF0IG1heSBvciBtYXkgbm90IGJlIGV4Y2x1c2l2ZSBh
bmQgYXJlIGFsbCBkb25lIGluIHVzZXJzcGFjZSBpcyBnb2luZyB0byBiZSBhIGZ1dGlsZSBleGVy
Y2lzZS4NCg0Kam9oYW5uZXMNCg0K
^ permalink raw reply
* Re: Edimax EW-7733UnD
From: Gertjan van Wingerde @ 2013-10-31 15:49 UTC (permalink / raw)
To: Gianfranco Costamagna
Cc: Hauke Mehrtens, Stanislaw Gruszka, linux-wireless@vger.kernel.org
In-Reply-To: <1383233873.6949.YahooMailNeo@web171806.mail.ir2.yahoo.com>
On Thu, Oct 31, 2013 at 4:37 PM, Gianfranco Costamagna
<costamagnagianfranco@yahoo.it> wrote:
>
>>Aren't you trying to get a RT3573 card to work? You should activate
>>CONFIG_RT2800USB_RT3573.
>
>
> I'm rebuilding the kernel with this module, but I don't think this is my chip
> http://www.edimax.com/au/produce_detail.php?pd_id=399&pl1_id=1&pl2_id=44
>
> is it?
>
It should be, as it is the only Ralink chipset that supports 3x3
operation (i.e. 450 Mbps).
Also, the USB id of the device is listed in the driver under that
configuration option, so I'm pretty sure you
have to enable that configuration option ;-)
--
---
Gertjan
^ permalink raw reply
* Re: Edimax EW-7733UnD
From: Gianfranco Costamagna @ 2013-10-31 15:37 UTC (permalink / raw)
To: Hauke Mehrtens, Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <527264F6.2030001@hauke-m.de>
>Aren't you trying to get a RT3573 card to work? You should activate
>CONFIG_RT2800USB_RT3573.
I'm rebuilding the kernel with this module, but I don't think this is my chip
http://www.edimax.com/au/produce_detail.php?pd_id=399&pl1_id=1&pl2_id=44
is it?
Thanks
Gianfranco
> Il Giovedì 31 Ottobre 2013 15:11, Hauke Mehrtens <hauke@hauke-m.de> ha scritto:
> > On 10/31/2013 02:56 PM, Gianfranco Costamagna wrote:
>>
>>
>>> Il Giovedì 24 Ottobre 2013 13:41, Stanislaw Gruszka
> <sgruszka@redhat.com> ha scritto:
>>>> On Thu, Oct 24, 2013 at 12:32:16PM +0100, Gianfranco Costamagna
> wrote:
>>>>
>>>>
>>>> Il Giovedì 24 Ottobre 2013 13:25, Stanislaw Gruszka
>>> <sgruszka@redhat.com> ha scritto:
>>>>
>>>> On Wed, Oct 23, 2013 at 03:27:49PM +0100, Gianfranco Costamagna
> wrote:
>>>> >
>>>> >> Hi Kernel Wireless developers, I write here since I have
> an issue
>>> with this module.
>>>> >>
>>>> >>
>>>> >> We bought 2 of them since they are both 2.4 and 5Ghz
> capable, and
>>> they seem to be powerful enough for our pourposes
>>>> >>
>>>
> http://www.edimax.com/au/produce_detail.php?pd_id=399&pl1_id=1&pl2_id=44
>>>> >>
>>>> >>
>>>> >> Anyway there is a problem, that the linux kernel seems to
> be not
>>> supporting them
>>>> >>
>>>> >> I tried following this guide
>>>> >> http://wikidevi.com/wiki/Edimax_EW-7733UnD
>>>> >> rt3573sta, possibly rt5572sta, and future support in
> rt2800usb
>>> "uhosg's patchset adding support, may be in by k3.12"
>>>> >> but at this moment it is showing an interface with one of
> them (I
>>> cannot connect to anything, the interface shown seems to be incorrect),
> with
>>> another I get a kernel anic and with the third one doesn't work at
> all.
>>>> >>
>>>> >> lsusb |grep Edimax
>>>> >>
>>>> >> Bus 002 Device 002: ID 7392:7733 Edimax Technology Co.,
> Ltd
>>>> >
>>>> >I have that exect device and it works ok here, but I'm
> using
>>>> >wireless-testing tree. So perhaps you should try install that
>>>> >tree or use backports .
>>>>
>>>>
>>>> Wonderful! I don't really understand what do you mean with
> backports,
>>> are you referring to "linux kernel backports" right?
>>>
>>> Yes.
>>>
>>>> So I can choose the backport source or to checkout and build the
>>> wireless-testing tree.
>>>>
>>>> Just as information, how long will it take to have it into the
> stable
>>> mainline?
>>>
>>> Current wireless-testing content will be available on 3.13 ,
>>> though I think that device should also work on 3.12 .
>>>
>>
>> Ok I built a custom kernel but I still have some issues
>> Ubuntu 13.10 x64
>> git clone
> http://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
>> cd wireless-testing
>> copied my config from this kernel
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc7-saucy/
>>
>> make oldconfig
>> (a tail of my .config file after the make)
>> CONFIG_RT2800PCI=m
>> CONFIG_RT2800PCI_RT33XX=y
>> CONFIG_RT2800PCI_RT35XX=y
>> CONFIG_RT2800PCI_RT53XX=y
>> CONFIG_RT2800PCI_RT3290=y
>> CONFIG_RT2500USB=m
>> CONFIG_RT73USB=m
>> CONFIG_RT2800USB=m
>> CONFIG_RT2800USB_RT33XX=y
>> CONFIG_RT2800USB_RT35XX=y
>> # CONFIG_RT2800USB_RT3573 is not set
>
> Aren't you trying to get a RT3573 card to work? You should activate
>
> CONFIG_RT2800USB_RT3573.
>
>> CONFIG_RT2800USB_RT53XX=y
>> CONFIG_RT2800USB_RT55XX=y
>> CONFIG_RT2800USB_UNKNOWN=y
>> CONFIG_RT2800_LIB=m
>> CONFIG_RT2800_LIB_MMIO=m
>> CONFIG_RT2X00_LIB_MMIO=m
>> CONFIG_RT2X00_LIB_PCI=m
>> CONFIG_RT2X00_LIB_USB=m
>> CONFIG_RT2X00_LIB=m
>> CONFIG_RT2X00_LIB_FIRMWARE=y
>> CONFIG_RT2X00_LIB_CRYPTO=y
>> CONFIG_RT2X00_LIB_LEDS=y
>> # CONFIG_RT2X00_LIB_DEBUGFS is not set
>> # CONFIG_RT2X00_DEBUG is not set
>>
>> (apt-get build-dep linux)
>> make
>> make all
>> sudo make modules_install
>> sudo make install
>>
>> I was surprised that everything was automatically copied in /boot and grub
> automatically found the new kernel without manual mkinitrd anymore (so long time
> from my last kernel build)
>>
>> Reboot
>>
>> locutus@gianfranco-Latitude-E5520:~/wireless-testing$ uname -a
>> Linux gianfranco-Latitude-E5520 3.12.0-rc5-wl #2 SMP Thu Oct 31 14:04:43
> CET 2013 x86_64 x86_64 x86_64 GNU/Linux
>>
>>
>> put key in my pc
>> [ 471.585065] usb 2-1.2: new high-speed USB device number 11 using
> ehci-pci
>> [ 471.693762] usb 2-1.2: New USB device found, idVendor=7392,
> idProduct=7733
>> [ 471.693766] usb 2-1.2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
>> [ 471.693768] usb 2-1.2: Product: 802.11 n WLAN
>> [ 471.693770] usb 2-1.2: Manufacturer: Ralink
>> [ 471.693771] usb 2-1.2: SerialNumber: 1.0
>>
>> sudo modprobe rt2800usb
>>
>> [ 540.170899] usbcore: registered new interface driver rt2800usb
>>
>> nothing works...
>>
>> Can you please help me again?
>>
>
^ permalink raw reply
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
From: Johannes Berg @ 2013-10-31 15:25 UTC (permalink / raw)
To: Undekari, Sunil Dutt; +Cc: linux-wireless@vger.kernel.org, j@w1.fi
In-Reply-To: <26F3B0343EE4744AA14EEEF9E1E534511F7A65CC@aphydexd01a>
On Thu, 2013-10-31 at 15:22 +0000, Undekari, Sunil Dutt wrote:
> > That's not what the critical protocol stuff was designed for, so no.
> I would consider the P2P connection phase (P2P+WPS+WPA) to be critical
> and any off channel operations (scan) triggered by the host driver would result in
> the delayed / failed P2P connection attempt.
> I suppose there should be an indication to the host driver w.r.t p2p connection
> attempt so that any off load operations on any other interface sharing the same radio
> would be avoided by the driver.
> Since there is already an existing interface through the critical protocol indication, I
> thought of extending it to also include a P2P protocol/connection. This new proto id
> would be an indication to the drivers to allow the scan on the current interface
> and avoid any scans on another considering the fact that a p2p connection requires a
> scan.
> Do you propose an alternative (a new interface?) to achieve the same?
Just do it in the supplicant - that has full control over what's going
on with a given device.
Trying to have the kernel manage multiple things that may or may not be
exclusive and are all done in userspace is going to be a futile
exercise.
johannes
^ permalink raw reply
* RE: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
From: Undekari, Sunil Dutt @ 2013-10-31 15:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, j@w1.fi
In-Reply-To: <1383230593.14302.1.camel@jlt4.sipsolutions.net>
PiBUaGF0J3Mgbm90IHdoYXQgdGhlIGNyaXRpY2FsIHByb3RvY29sIHN0dWZmIHdhcyBkZXNpZ25l
ZCBmb3IsIHNvIG5vLg0KSSB3b3VsZCBjb25zaWRlciB0aGUgUDJQIGNvbm5lY3Rpb24gcGhhc2Ug
KFAyUCtXUFMrV1BBKSB0byBiZSBjcml0aWNhbCANCmFuZCBhbnkgb2ZmIGNoYW5uZWwgb3BlcmF0
aW9ucyAoc2NhbikgdHJpZ2dlcmVkIGJ5IHRoZSBob3N0IGRyaXZlciB3b3VsZCByZXN1bHQgaW4g
DQp0aGUgZGVsYXllZCAvIGZhaWxlZCBQMlAgY29ubmVjdGlvbiBhdHRlbXB0Lg0KSSBzdXBwb3Nl
IHRoZXJlIHNob3VsZCBiZSBhbiBpbmRpY2F0aW9uIHRvIHRoZSBob3N0IGRyaXZlciB3LnIudCBw
MnAgY29ubmVjdGlvbiANCmF0dGVtcHQgc28gdGhhdCBhbnkgb2ZmIGxvYWQgb3BlcmF0aW9ucyBv
biBhbnkgb3RoZXIgaW50ZXJmYWNlIHNoYXJpbmcgdGhlIHNhbWUgcmFkaW8gDQp3b3VsZCBiZSBh
dm9pZGVkIGJ5IHRoZSBkcml2ZXIuDQpTaW5jZSB0aGVyZSBpcyBhbHJlYWR5IGFuIGV4aXN0aW5n
IGludGVyZmFjZSB0aHJvdWdoIHRoZSBjcml0aWNhbCBwcm90b2NvbCBpbmRpY2F0aW9uLCBJIA0K
dGhvdWdodCBvZiBleHRlbmRpbmcgaXQgdG8gYWxzbyBpbmNsdWRlIGEgUDJQIHByb3RvY29sL2Nv
bm5lY3Rpb24uIFRoaXMgbmV3IHByb3RvIGlkIA0Kd291bGQgYmUgYW4gaW5kaWNhdGlvbiB0byB0
aGUgZHJpdmVycyB0byBhbGxvdyB0aGUgc2NhbiBvbiB0aGUgY3VycmVudCBpbnRlcmZhY2UgDQph
bmQgYXZvaWQgYW55IHNjYW5zIG9uIGFub3RoZXIgY29uc2lkZXJpbmcgdGhlIGZhY3QgdGhhdCBh
IHAycCBjb25uZWN0aW9uIHJlcXVpcmVzIGEgIA0Kc2Nhbi4NCkRvIHlvdSBwcm9wb3NlIGFuIGFs
dGVybmF0aXZlIChhIG5ldyBpbnRlcmZhY2U/KSB0byBhY2hpZXZlIHRoZSBzYW1lPw0KDQpSZWdh
cmRzLA0KU3VuaWwNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
Sm9oYW5uZXMgQmVyZyBbbWFpbHRvOmpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXRdIA0KU2VudDog
VGh1cnNkYXksIE9jdG9iZXIgMzEsIDIwMTMgODoxMyBQTQ0KVG86IFVuZGVrYXJpLCBTdW5pbCBE
dXR0DQpDYzogbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnOyBqQHcxLmZpDQpTdWJqZWN0
OiBSZTogW1BBVENIXSBjZmc4MDIxMTogSW50cm9kdWNlIGNyaXRpY2FsIHByb3RvY29sIGluZGlj
YXRpb24gZm9yIHAycCBjb25uZWN0aW9uLg0KDQpPbiBUaHUsIDIwMTMtMTAtMzEgYXQgMjA6MTAg
KzA1MzAsIFN1bmlsIER1dHQgVW5kZWthcmkgd3JvdGU6DQo+IEEgcmVsaWFibGUgUDJQIGNvbm5l
Y3Rpb24gbmVlZHMgdG8gYXZvaWQgYW55IG9mZmxvYWQgb2ZmIGNoYW5uZWwgDQo+IG9wZXJhdGlv
bnMgdHJpZ2dlcmVkIGJ5IHRoZSBob3N0IGRyaXZlci4NCg0KVGhhdCdzIG5vdCB3aGF0IHRoZSBj
cml0aWNhbCBwcm90b2NvbCBzdHVmZiB3YXMgZGVzaWduZWQgZm9yLCBzbyBuby4NCg0Kam9oYW5u
ZXMNCg0K
^ permalink raw reply
* Re: [PATCH 5/7] wireless-regdb: optimize two of ES's rules
From: Xose Vazquez Perez @ 2013-10-31 15:07 UTC (permalink / raw)
To: wireless-regdb; +Cc: linux-wireless, Luis R. Rodriguez, John W. Linville
hi Luis,
This patch is incompatible with my ("pending")patch:
http://lists.infradead.org/pipermail/wireless-regdb/2013-February/000136.html
thanks,
---cortamorena---
Subject: [PATCH] wireless-regdb: change Max_EIRP in 5150-5250 for ES (Spain)
I did cut&paste from DE rules, but DE lowers the limit
in 5150-5250 to 100mW for "neighborhood reasons" [1].
Even when 200mW is completely legal in DE.
put 200mW, as Spanish law says:
Banda 5150 – 5350 MHz: En esta banda el uso por el servicio móvil en sistemas de
acceso inalámbrico incluyendo comunicaciones electrónicas y redes de área local, se
restringe para su utilización únicamente en el interior de recintos. La potencia isotrópica
radiada equivalente máxima será de 200 mW (p.i.r.e.), siendo la densidad máxima de
p.i.r.e. media de 10 mW/MHz en cualquier banda de 1 MHz. Este valor se refiere a la
potencia promediada sobre una ráfaga de transmisión ajustada a la máxima potencia
Orden ITC/332/2010, de 12 de febrero, por la que se aprueba el cuadro
nacional de atribución de frecuencias (CNAF):
https://www.boe.es/diario_boe/txt.php?id=BOE-A-2010-2719
https://www.boe.es/boe/dias/2010/02/19/pdfs/BOE-A-2010-2719.pdf
search for:
UN - 85 RLANs y datos en 2400 a 2483,5 MHz (pag. 213)
UN - 128 RLANs en 5 GHz (pag. 232)
more info at "Cuadro nacional de atribución de frecuencias (CNAF)":
http://www.minetur.gob.es/telecomunicaciones/espectro/paginas/cnaf.aspx
[1] http://marc.info/?l=linux-wireless&m=127429049514439
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Luis R. Rodriguez <mcgrof@frijolero.org>
Cc: wireless-regdb@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
db.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/db.txt b/db.txt
index c5861b8..6f618c0 100644
--- a/db.txt
+++ b/db.txt
@@ -269,7 +269,7 @@ country EG:
country ES: DFS-ETSI
(2400 - 2483.5 @ 40), (N/A, 100 mW)
- (5150 - 5250 @ 40), (N/A, 100 mW), NO-OUTDOOR
+ (5150 - 5250 @ 40), (N/A, 200 mW), NO-OUTDOOR
(5250 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS
(5470 - 5725 @ 40), (N/A, 500 mW), DFS
# 60 gHz band channels 1-4, ref: Etsi En 302 567
--
1.7.11.7
---end---
^ permalink raw reply related
* Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
From: Russell King - ARM Linux @ 2013-10-31 14:49 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Hans Verkuil, alsa-devel, linux-doc, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, linux-scsi,
e1000-devel, b43-dev, linux-media, devicetree, dri-devel,
linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
linux-crypto, Greg Kroah-Hartman, uclinux-dist-devel,
linuxppc-dev
In-Reply-To: <20131031094640.205840a2@samsung.com>
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
> Hi Russell,
>
> Em Mon, 30 Sep 2013 13:57:47 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
> > On 09/19/2013 11:44 PM, Russell King wrote:
> > > Replace the following sequence:
> > >
> > > dma_set_mask(dev, mask);
> > > dma_set_coherent_mask(dev, mask);
> > >
> > > with a call to the new helper dma_set_mask_and_coherent().
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >
> > Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
>
> Somehow, I lost your original post (I got unsubscribed on a few days
> from all vger mailing lists at the end of september).
>
> I suspect that you want to sent this via your tree, right?
Yes please.
> If so:
>
> Acked-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Added, thanks.
> > > - err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> > > - if (err)
> > > - return -ENODEV;
> > > - err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> > > + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> > > if (err)
> > > return -ENODEV;
One thing I've just noticed is that return should be "return err" not
"return -ENODEV" - are you okay for me to change that in this patch?
Thanks.
^ permalink raw reply
* Re: [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
From: Johannes Berg @ 2013-10-31 14:43 UTC (permalink / raw)
To: Sunil Dutt Undekari; +Cc: linux-wireless, j
In-Reply-To: <1383230452-12608-1-git-send-email-usdutt@qti.qualcomm.com>
On Thu, 2013-10-31 at 20:10 +0530, Sunil Dutt Undekari wrote:
> A reliable P2P connection needs to avoid any offload off channel
> operations triggered by the host driver.
That's not what the critical protocol stuff was designed for, so no.
johannes
^ permalink raw reply
* [PATCH] cfg80211: Introduce critical protocol indication for p2p connection.
From: Sunil Dutt Undekari @ 2013-10-31 14:40 UTC (permalink / raw)
To: linux-wireless; +Cc: j, usdutt
A reliable P2P connection needs to avoid any offload off channel
operations triggered by the host driver.Thus, indicate such
attempts to the host driver by including a new protocol id,
signifying the p2p connection.
Signed-off-by: Sunil Dutt <usdutt@qti.qualcomm.com>
---
include/uapi/linux/nl80211.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 8f01961..cae07aa 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3894,6 +3894,7 @@ enum nl80211_protocol_features {
* @NL80211_CRIT_PROTO_DHCP: BOOTP or DHCPv6 protocol.
* @NL80211_CRIT_PROTO_EAPOL: EAPOL protocol.
* @NL80211_CRIT_PROTO_APIPA: APIPA protocol.
+ * @NL80211_CRIT_PROTO_P2P: P2P protocol.
* @NUM_NL80211_CRIT_PROTO: must be kept last.
*/
enum nl80211_crit_proto_id {
@@ -3901,6 +3902,7 @@ enum nl80211_crit_proto_id {
NL80211_CRIT_PROTO_DHCP,
NL80211_CRIT_PROTO_EAPOL,
NL80211_CRIT_PROTO_APIPA,
+ NL80211_CRIT_PROTO_P2P,
/* add other protocols before this one */
NUM_NL80211_CRIT_PROTO
};
--
1.8.2.1
^ permalink raw reply related
* Re: Edimax EW-7733UnD
From: Gertjan van Wingerde @ 2013-10-31 14:22 UTC (permalink / raw)
To: Gianfranco Costamagna; +Cc: Stanislaw Gruszka, linux-wireless@vger.kernel.org
In-Reply-To: <1383227814.41997.YahooMailNeo@web171801.mail.ir2.yahoo.com>
On Thu, Oct 31, 2013 at 2:56 PM, Gianfranco Costamagna
<costamagnagianfranco@yahoo.it> wrote:
>
>
>> Il Giovedì 24 Ottobre 2013 13:41, Stanislaw Gruszka <sgruszka@redhat.com> ha scritto:
>> > On Thu, Oct 24, 2013 at 12:32:16PM +0100, Gianfranco Costamagna wrote:
>>>
>>>
>>> Il Giovedì 24 Ottobre 2013 13:25, Stanislaw Gruszka
>> <sgruszka@redhat.com> ha scritto:
>>>
>>> On Wed, Oct 23, 2013 at 03:27:49PM +0100, Gianfranco Costamagna wrote:
>>> >
>>> >> Hi Kernel Wireless developers, I write here since I have an issue
>> with this module.
>>> >>
>>> >>
>>> >> We bought 2 of them since they are both 2.4 and 5Ghz capable, and
>> they seem to be powerful enough for our pourposes
>>> >>
>> http://www.edimax.com/au/produce_detail.php?pd_id=399&pl1_id=1&pl2_id=44
>>> >>
>>> >>
>>> >> Anyway there is a problem, that the linux kernel seems to be not
>> supporting them
>>> >>
>>> >> I tried following this guide
>>> >> http://wikidevi.com/wiki/Edimax_EW-7733UnD
>>> >> rt3573sta, possibly rt5572sta, and future support in rt2800usb
>> "uhosg's patchset adding support, may be in by k3.12"
>>> >> but at this moment it is showing an interface with one of them (I
>> cannot connect to anything, the interface shown seems to be incorrect), with
>> another I get a kernel anic and with the third one doesn't work at all.
>>> >>
>>> >> lsusb |grep Edimax
>>> >>
>>> >> Bus 002 Device 002: ID 7392:7733 Edimax Technology Co., Ltd
>>> >
>>> >I have that exect device and it works ok here, but I'm using
>>> >wireless-testing tree. So perhaps you should try install that
>>> >tree or use backports .
>>>
>>>
>>> Wonderful! I don't really understand what do you mean with backports,
>> are you referring to "linux kernel backports" right?
>>
>> Yes.
>>
>>> So I can choose the backport source or to checkout and build the
>> wireless-testing tree.
>>>
>>> Just as information, how long will it take to have it into the stable
>> mainline?
>>
>> Current wireless-testing content will be available on 3.13 ,
>> though I think that device should also work on 3.12 .
>>
>
> Ok I built a custom kernel but I still have some issues
> Ubuntu 13.10 x64
> git clone http://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> cd wireless-testing
> copied my config from this kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc7-saucy/
>
> make oldconfig
> (a tail of my .config file after the make)
> CONFIG_RT2800PCI=m
> CONFIG_RT2800PCI_RT33XX=y
> CONFIG_RT2800PCI_RT35XX=y
> CONFIG_RT2800PCI_RT53XX=y
> CONFIG_RT2800PCI_RT3290=y
> CONFIG_RT2500USB=m
> CONFIG_RT73USB=m
> CONFIG_RT2800USB=m
> CONFIG_RT2800USB_RT33XX=y
> CONFIG_RT2800USB_RT35XX=y
> # CONFIG_RT2800USB_RT3573 is not set
You will have to enable this configuration item to make this device work.
> CONFIG_RT2800USB_RT53XX=y
> CONFIG_RT2800USB_RT55XX=y
> CONFIG_RT2800USB_UNKNOWN=y
> CONFIG_RT2800_LIB=m
> CONFIG_RT2800_LIB_MMIO=m
> CONFIG_RT2X00_LIB_MMIO=m
> CONFIG_RT2X00_LIB_PCI=m
> CONFIG_RT2X00_LIB_USB=m
> CONFIG_RT2X00_LIB=m
> CONFIG_RT2X00_LIB_FIRMWARE=y
> CONFIG_RT2X00_LIB_CRYPTO=y
> CONFIG_RT2X00_LIB_LEDS=y
> # CONFIG_RT2X00_LIB_DEBUGFS is not set
> # CONFIG_RT2X00_DEBUG is not set
>
> (apt-get build-dep linux)
> make
> make all
> sudo make modules_install
> sudo make install
>
> I was surprised that everything was automatically copied in /boot and grub automatically found the new kernel without manual mkinitrd anymore (so long time from my last kernel build)
>
> Reboot
>
> locutus@gianfranco-Latitude-E5520:~/wireless-testing$ uname -a
> Linux gianfranco-Latitude-E5520 3.12.0-rc5-wl #2 SMP Thu Oct 31 14:04:43 CET 2013 x86_64 x86_64 x86_64 GNU/Linux
>
>
> put key in my pc
> [ 471.585065] usb 2-1.2: new high-speed USB device number 11 using ehci-pci
> [ 471.693762] usb 2-1.2: New USB device found, idVendor=7392, idProduct=7733
> [ 471.693766] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 471.693768] usb 2-1.2: Product: 802.11 n WLAN
> [ 471.693770] usb 2-1.2: Manufacturer: Ralink
> [ 471.693771] usb 2-1.2: SerialNumber: 1.0
>
> sudo modprobe rt2800usb
>
> [ 540.170899] usbcore: registered new interface driver rt2800usb
>
> nothing works...
>
> Can you please help me again?
>
--
---
Gertjan
^ permalink raw reply
* Re: Edimax EW-7733UnD
From: Hauke Mehrtens @ 2013-10-31 14:11 UTC (permalink / raw)
To: Gianfranco Costamagna, Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1383227814.41997.YahooMailNeo@web171801.mail.ir2.yahoo.com>
On 10/31/2013 02:56 PM, Gianfranco Costamagna wrote:
>
>
>> Il Giovedì 24 Ottobre 2013 13:41, Stanislaw Gruszka <sgruszka@redhat.com> ha scritto:
>>> On Thu, Oct 24, 2013 at 12:32:16PM +0100, Gianfranco Costamagna wrote:
>>>
>>>
>>> Il Giovedì 24 Ottobre 2013 13:25, Stanislaw Gruszka
>> <sgruszka@redhat.com> ha scritto:
>>>
>>> On Wed, Oct 23, 2013 at 03:27:49PM +0100, Gianfranco Costamagna wrote:
>>> >
>>> >> Hi Kernel Wireless developers, I write here since I have an issue
>> with this module.
>>> >>
>>> >>
>>> >> We bought 2 of them since they are both 2.4 and 5Ghz capable, and
>> they seem to be powerful enough for our pourposes
>>> >>
>> http://www.edimax.com/au/produce_detail.php?pd_id=399&pl1_id=1&pl2_id=44
>>> >>
>>> >>
>>> >> Anyway there is a problem, that the linux kernel seems to be not
>> supporting them
>>> >>
>>> >> I tried following this guide
>>> >> http://wikidevi.com/wiki/Edimax_EW-7733UnD
>>> >> rt3573sta, possibly rt5572sta, and future support in rt2800usb
>> "uhosg's patchset adding support, may be in by k3.12"
>>> >> but at this moment it is showing an interface with one of them (I
>> cannot connect to anything, the interface shown seems to be incorrect), with
>> another I get a kernel anic and with the third one doesn't work at all.
>>> >>
>>> >> lsusb |grep Edimax
>>> >>
>>> >> Bus 002 Device 002: ID 7392:7733 Edimax Technology Co., Ltd
>>> >
>>> >I have that exect device and it works ok here, but I'm using
>>> >wireless-testing tree. So perhaps you should try install that
>>> >tree or use backports .
>>>
>>>
>>> Wonderful! I don't really understand what do you mean with backports,
>> are you referring to "linux kernel backports" right?
>>
>> Yes.
>>
>>> So I can choose the backport source or to checkout and build the
>> wireless-testing tree.
>>>
>>> Just as information, how long will it take to have it into the stable
>> mainline?
>>
>> Current wireless-testing content will be available on 3.13 ,
>> though I think that device should also work on 3.12 .
>>
>
> Ok I built a custom kernel but I still have some issues
> Ubuntu 13.10 x64
> git clone http://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> cd wireless-testing
> copied my config from this kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc7-saucy/
>
> make oldconfig
> (a tail of my .config file after the make)
> CONFIG_RT2800PCI=m
> CONFIG_RT2800PCI_RT33XX=y
> CONFIG_RT2800PCI_RT35XX=y
> CONFIG_RT2800PCI_RT53XX=y
> CONFIG_RT2800PCI_RT3290=y
> CONFIG_RT2500USB=m
> CONFIG_RT73USB=m
> CONFIG_RT2800USB=m
> CONFIG_RT2800USB_RT33XX=y
> CONFIG_RT2800USB_RT35XX=y
> # CONFIG_RT2800USB_RT3573 is not set
Aren't you trying to get a RT3573 card to work? You should activate
CONFIG_RT2800USB_RT3573.
> CONFIG_RT2800USB_RT53XX=y
> CONFIG_RT2800USB_RT55XX=y
> CONFIG_RT2800USB_UNKNOWN=y
> CONFIG_RT2800_LIB=m
> CONFIG_RT2800_LIB_MMIO=m
> CONFIG_RT2X00_LIB_MMIO=m
> CONFIG_RT2X00_LIB_PCI=m
> CONFIG_RT2X00_LIB_USB=m
> CONFIG_RT2X00_LIB=m
> CONFIG_RT2X00_LIB_FIRMWARE=y
> CONFIG_RT2X00_LIB_CRYPTO=y
> CONFIG_RT2X00_LIB_LEDS=y
> # CONFIG_RT2X00_LIB_DEBUGFS is not set
> # CONFIG_RT2X00_DEBUG is not set
>
> (apt-get build-dep linux)
> make
> make all
> sudo make modules_install
> sudo make install
>
> I was surprised that everything was automatically copied in /boot and grub automatically found the new kernel without manual mkinitrd anymore (so long time from my last kernel build)
>
> Reboot
>
> locutus@gianfranco-Latitude-E5520:~/wireless-testing$ uname -a
> Linux gianfranco-Latitude-E5520 3.12.0-rc5-wl #2 SMP Thu Oct 31 14:04:43 CET 2013 x86_64 x86_64 x86_64 GNU/Linux
>
>
> put key in my pc
> [ 471.585065] usb 2-1.2: new high-speed USB device number 11 using ehci-pci
> [ 471.693762] usb 2-1.2: New USB device found, idVendor=7392, idProduct=7733
> [ 471.693766] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 471.693768] usb 2-1.2: Product: 802.11 n WLAN
> [ 471.693770] usb 2-1.2: Manufacturer: Ralink
> [ 471.693771] usb 2-1.2: SerialNumber: 1.0
>
> sudo modprobe rt2800usb
>
> [ 540.170899] usbcore: registered new interface driver rt2800usb
>
> nothing works...
>
> Can you please help me again?
>
^ permalink raw reply
* Re: Edimax EW-7733UnD
From: Stanislaw Gruszka @ 2013-10-31 14:08 UTC (permalink / raw)
To: Gianfranco Costamagna; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1383227814.41997.YahooMailNeo@web171801.mail.ir2.yahoo.com>
On Thu, Oct 31, 2013 at 01:56:54PM +0000, Gianfranco Costamagna wrote:
> put key in my pc
> [ 471.585065] usb 2-1.2: new high-speed USB device number 11 using ehci-pci
> [ 471.693762] usb 2-1.2: New USB device found, idVendor=7392, idProduct=7733
> [ 471.693766] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 471.693768] usb 2-1.2: Product: 802.11 n WLAN
> [ 471.693770] usb 2-1.2: Manufacturer: Ralink
> [ 471.693771] usb 2-1.2: SerialNumber: 1.0
>
> sudo modprobe rt2800usb
>
> [ 540.170899] usbcore: registered new interface driver rt2800usb
>
> nothing works...
>
> Can you please help me again?
Lack of firmware ? Also check if device support is really compiled in
the module - "modinfo rt2800usb | grep 7733" should show device id.
Stanislaw
^ permalink raw reply
* Re: Edimax EW-7733UnD
From: Gianfranco Costamagna @ 2013-10-31 13:56 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20131024113748.GD1677@redhat.com>
> Il Giovedì 24 Ottobre 2013 13:41, Stanislaw Gruszka <sgruszka@redhat.com> ha scritto:
> > On Thu, Oct 24, 2013 at 12:32:16PM +0100, Gianfranco Costamagna wrote:
>>
>>
>> Il Giovedì 24 Ottobre 2013 13:25, Stanislaw Gruszka
> <sgruszka@redhat.com> ha scritto:
>>
>> On Wed, Oct 23, 2013 at 03:27:49PM +0100, Gianfranco Costamagna wrote:
>> >
>> >> Hi Kernel Wireless developers, I write here since I have an issue
> with this module.
>> >>
>> >>
>> >> We bought 2 of them since they are both 2.4 and 5Ghz capable, and
> they seem to be powerful enough for our pourposes
>> >>
> http://www.edimax.com/au/produce_detail.php?pd_id=399&pl1_id=1&pl2_id=44
>> >>
>> >>
>> >> Anyway there is a problem, that the linux kernel seems to be not
> supporting them
>> >>
>> >> I tried following this guide
>> >> http://wikidevi.com/wiki/Edimax_EW-7733UnD
>> >> rt3573sta, possibly rt5572sta, and future support in rt2800usb
> "uhosg's patchset adding support, may be in by k3.12"
>> >> but at this moment it is showing an interface with one of them (I
> cannot connect to anything, the interface shown seems to be incorrect), with
> another I get a kernel anic and with the third one doesn't work at all.
>> >>
>> >> lsusb |grep Edimax
>> >>
>> >> Bus 002 Device 002: ID 7392:7733 Edimax Technology Co., Ltd
>> >
>> >I have that exect device and it works ok here, but I'm using
>> >wireless-testing tree. So perhaps you should try install that
>> >tree or use backports .
>>
>>
>> Wonderful! I don't really understand what do you mean with backports,
> are you referring to "linux kernel backports" right?
>
> Yes.
>
>> So I can choose the backport source or to checkout and build the
> wireless-testing tree.
>>
>> Just as information, how long will it take to have it into the stable
> mainline?
>
> Current wireless-testing content will be available on 3.13 ,
> though I think that device should also work on 3.12 .
>
Ok I built a custom kernel but I still have some issues
Ubuntu 13.10 x64
git clone http://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
cd wireless-testing
copied my config from this kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-rc7-saucy/
make oldconfig
(a tail of my .config file after the make)
CONFIG_RT2800PCI=m
CONFIG_RT2800PCI_RT33XX=y
CONFIG_RT2800PCI_RT35XX=y
CONFIG_RT2800PCI_RT53XX=y
CONFIG_RT2800PCI_RT3290=y
CONFIG_RT2500USB=m
CONFIG_RT73USB=m
CONFIG_RT2800USB=m
CONFIG_RT2800USB_RT33XX=y
CONFIG_RT2800USB_RT35XX=y
# CONFIG_RT2800USB_RT3573 is not set
CONFIG_RT2800USB_RT53XX=y
CONFIG_RT2800USB_RT55XX=y
CONFIG_RT2800USB_UNKNOWN=y
CONFIG_RT2800_LIB=m
CONFIG_RT2800_LIB_MMIO=m
CONFIG_RT2X00_LIB_MMIO=m
CONFIG_RT2X00_LIB_PCI=m
CONFIG_RT2X00_LIB_USB=m
CONFIG_RT2X00_LIB=m
CONFIG_RT2X00_LIB_FIRMWARE=y
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_RT2X00_LIB_LEDS=y
# CONFIG_RT2X00_LIB_DEBUGFS is not set
# CONFIG_RT2X00_DEBUG is not set
(apt-get build-dep linux)
make
make all
sudo make modules_install
sudo make install
I was surprised that everything was automatically copied in /boot and grub automatically found the new kernel without manual mkinitrd anymore (so long time from my last kernel build)
Reboot
locutus@gianfranco-Latitude-E5520:~/wireless-testing$ uname -a
Linux gianfranco-Latitude-E5520 3.12.0-rc5-wl #2 SMP Thu Oct 31 14:04:43 CET 2013 x86_64 x86_64 x86_64 GNU/Linux
put key in my pc
[ 471.585065] usb 2-1.2: new high-speed USB device number 11 using ehci-pci
[ 471.693762] usb 2-1.2: New USB device found, idVendor=7392, idProduct=7733
[ 471.693766] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 471.693768] usb 2-1.2: Product: 802.11 n WLAN
[ 471.693770] usb 2-1.2: Manufacturer: Ralink
[ 471.693771] usb 2-1.2: SerialNumber: 1.0
sudo modprobe rt2800usb
[ 540.170899] usbcore: registered new interface driver rt2800usb
nothing works...
Can you please help me again?
Many thanks
have a nice day,
Gianfranco
>
> Stanislaw
>
^ permalink raw reply
* [PATCH v2] nl80211: better document NL80211_CMD_TDLS_MGMT
From: Arik Nemtsov @ 2013-10-31 12:54 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Arik Nemtsov
This command has different semantics depending on the action code sent.
Document this fact and detail the supported action codes.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
include/uapi/linux/nl80211.h | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index f752e98..3d8325b 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -581,7 +581,14 @@
* operation, %NL80211_ATTR_MAC contains the peer MAC address, and
* %NL80211_ATTR_REASON_CODE the reason code to be used (only with
* %NL80211_TDLS_TEARDOWN).
- * @NL80211_CMD_TDLS_MGMT: Send a TDLS management frame.
+ * @NL80211_CMD_TDLS_MGMT: Send a TDLS management frame. The
+ * %NL80211_ATTR_TDLS_ACTION attribute determines the type of frame to be
+ * sent. Public Action codes (802.11-2012 8.1.5.1) will be sent as
+ * 802.11 management frames, while TDLS action codes (802.11-2012
+ * 8.5.13.1) will be encapsulated and sent as data frames. The currently
+ * supported Public Action code is %WLAN_PUB_ACTION_TDLS_DISCOVER_RES
+ * and the currently supported TDLS actions codes are given in
+ * &enum ieee80211_tdls_actioncode.
*
* @NL80211_CMD_UNEXPECTED_FRAME: Used by an application controlling an AP
* (or GO) interface (i.e. hostapd) to ask for unexpected frames to
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] nl80211: better document NL80211_CMD_TDLS_MGMT
From: Arik Nemtsov @ 2013-10-31 12:53 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <20131030184302.GA1026@localhost>
On Wed, Oct 30, 2013 at 8:43 PM, Bob Copeland <me@bobcopeland.com> wrote:
>
> On Wed, Oct 30, 2013 at 07:09:34PM +0200, Arik Nemtsov wrote:
> > + * @NL80211_CMD_TDLS_MGMT: Send a TDLS management frame. The
> > + * %NL80211_ATTR_TDLS_ACTION attribute determines the typ of frame to be
>
> type typo there.
Thanks.
^ 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