* Re: [PATCH 2/2] ath9k_htc: reboot firmware if it was loaded
From: Adrian Chadd @ 2013-07-10 19:27 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1373438404-5871-2-git-send-email-linux@rempel-privat.de>
Great catch!
-adrian
On 9 July 2013 23:40, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Currently ath9k_htc will reboot firmware only if interface was
> ever started. Which lead to the problem in case where interface
> was never started but module need to be reloaded.
>
> This patch will partially fix bug "ath9k_htc: Target is unresponsive"
> https://github.com/qca/open-ath9k-htc-firmware/issues/1
>
> Reproduction case:
> - plug adapter
> - make sure nothing will touch it. Stop Networkmanager or blacklist mac address of this adapter.
> - rmmod ath9k_htc; sleep 1; modprobe ath9k_htc
>
> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index 2469db5..5205a36 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -1295,7 +1295,9 @@ static void ath9k_hif_usb_disconnect(struct usb_interface *interface)
>
> usb_set_intfdata(interface, NULL);
>
> - if (!unplugged && (hif_dev->flags & HIF_USB_START))
> + /* If firmware was loaded we should drop it
> + * go back to first stage bootloader. */
> + if (!unplugged && (hif_dev->flags & HIF_USB_READY))
> ath9k_hif_usb_reboot(udev);
>
> kfree(hif_dev);
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Larry Finger @ 2013-07-10 18:16 UTC (permalink / raw)
To: José Miguel Gonçalves
Cc: Luciano Coelho, Arik Nemtsov, linux-wireless
In-Reply-To: <51DD9E6C.5060008@inov.pt>
On 07/10/2013 12:48 PM, José Miguel Gonçalves wrote:
> On 10-07-2013 18:17, Luciano Coelho wrote:
>> On Wed, 2013-07-10 at 17:30 +0100, José Miguel Gonçalves wrote:
>>> On 10-07-2013 13:34, José Miguel Gonçalves wrote:
>>>> I will try a new AP to see how it behaves...
>>>>
>>> I've tested with my Android smartphone acting as an AP, without authentication,
>>> and I'm also unable to associate!
>>>
>>> I get from iw the following error message:
>>>
>>> wlan0 (phy #0): failed to connect to b4:07:f9:49:cc:65, status: 1:
>>> Unspecified failure
>>>
>>> Complete log is here:
>>>
>>> http://pastebin.com/DzPmMw8i
>>>
>>> So, something is definitely wrong with my setup... but what?
>>> Hope that log has some useful info for you...
>> This definitely looks like RF problems. Especially this:
>>
>> [ 177.575000] wlan0: send auth to b4:07:f9:49:cc:65 (try 1/3)
>> [ 177.595000] wlan0: send auth to b4:07:f9:49:cc:65 (try 2/3)
>> [ 177.605000] wlcore: EVENT on mbox 1
>> [ 177.605000] wlcore: MBOX vector: 0x100000
>> [ 177.610000] wlcore: MAX_TX_FAILURE_EVENT_ID
>> [ 177.615000] wlan0: send auth to b4:07:f9:49:cc:65 (try 3/3)
>> [ 177.640000] wlan0: authentication with b4:07:f9:49:cc:65 timed out
>>
>> You are send auth requests out, but not getting anything back.
>> Apparently you're not even getting ACKs (as pointed out by the
>> MAX_TX_FAILURE_EVENT_ID).
>
> Hum. I never considered RF problems because I'm testing this module with a
> Jorjin's development kit, so I was considering that Jorjin knows how to make
> PCBs for RF. Also seeing that when I remove the antenna the AP signal strength
> changes from -51 dBm to -73 dBm was a signal to me that the RF was OK.
>
>>
>> Do you have a sniffer? You could try to use your TP-Link dongle with
>> wireshark to see if it works fine as a sniffer.
>
> I have a text console only system. I could put tcpdump on my system, but I think
> I can not monitor wireless traffic with it, or can I?
I use Kismet to monitor the air on a text-only system.
Larry
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-10 17:48 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <1373476663.8385.28.camel@cumari.coelho.fi>
On 10-07-2013 18:17, Luciano Coelho wrote:
> On Wed, 2013-07-10 at 17:30 +0100, José Miguel Gonçalves wrote:
>> On 10-07-2013 13:34, José Miguel Gonçalves wrote:
>>> I will try a new AP to see how it behaves...
>>>
>> I've tested with my Android smartphone acting as an AP, without authentication,
>> and I'm also unable to associate!
>>
>> I get from iw the following error message:
>>
>> wlan0 (phy #0): failed to connect to b4:07:f9:49:cc:65, status: 1: Unspecified failure
>>
>> Complete log is here:
>>
>> http://pastebin.com/DzPmMw8i
>>
>> So, something is definitely wrong with my setup... but what?
>> Hope that log has some useful info for you...
> This definitely looks like RF problems. Especially this:
>
> [ 177.575000] wlan0: send auth to b4:07:f9:49:cc:65 (try 1/3)
> [ 177.595000] wlan0: send auth to b4:07:f9:49:cc:65 (try 2/3)
> [ 177.605000] wlcore: EVENT on mbox 1
> [ 177.605000] wlcore: MBOX vector: 0x100000
> [ 177.610000] wlcore: MAX_TX_FAILURE_EVENT_ID
> [ 177.615000] wlan0: send auth to b4:07:f9:49:cc:65 (try 3/3)
> [ 177.640000] wlan0: authentication with b4:07:f9:49:cc:65 timed out
>
> You are send auth requests out, but not getting anything back.
> Apparently you're not even getting ACKs (as pointed out by the
> MAX_TX_FAILURE_EVENT_ID).
Hum. I never considered RF problems because I'm testing this module with a
Jorjin's development kit, so I was considering that Jorjin knows how to make PCBs
for RF. Also seeing that when I remove the antenna the AP signal strength changes
from -51 dBm to -73 dBm was a signal to me that the RF was OK.
>
> Do you have a sniffer? You could try to use your TP-Link dongle with
> wireshark to see if it works fine as a sniffer.
I have a text console only system. I could put tcpdump on my system, but I think I
can not monitor wireless traffic with it, or can I?
José Gonçalves
^ permalink raw reply
* Re: Baseband watchdog timer tripping on AR9342
From: Harshal Chhaya @ 2013-07-10 17:30 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAJ8GFOg9c78f3ivnSiX1o2TCTPa2B3D_01Tiki-cK1=tgghuhQ@mail.gmail.com>
On Wed, Jul 10, 2013 at 11:43 AM, Harshal Chhaya <harshal@gmail.com> wrote:
> On an AR9342-based AP, we see non-zero counts for
> RESET_TYPE_BB_WATCHDOG and RESET_TYPE_BEACON_STUCK when trying to do
> large uplink transfers from ~60 clients with some of them 30-40 ft
> away.
>
> All the other reset types have a count of zero.
>
> These resets cause all the clients to disconnect.
>
> Any ideas on how to avoid these resets and the subsequent disconnections?
I forgot to mention that there were three "Failed to stop TX DMA"
messages on the debug port which seem to map to the
RESET_TYPE_BB_WATCHDOG events.
Regards,
- Harshal
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Luciano Coelho @ 2013-07-10 17:17 UTC (permalink / raw)
To: José Miguel Gonçalves; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <51DD8C20.7010900@inov.pt>
On Wed, 2013-07-10 at 17:30 +0100, José Miguel Gonçalves wrote:
> On 10-07-2013 13:34, José Miguel Gonçalves wrote:
> >
> > I will try a new AP to see how it behaves...
> >
>
> I've tested with my Android smartphone acting as an AP, without authentication,
> and I'm also unable to associate!
>
> I get from iw the following error message:
>
> wlan0 (phy #0): failed to connect to b4:07:f9:49:cc:65, status: 1: Unspecified failure
>
> Complete log is here:
>
> http://pastebin.com/DzPmMw8i
>
> So, something is definitely wrong with my setup... but what?
> Hope that log has some useful info for you...
This definitely looks like RF problems. Especially this:
[ 177.575000] wlan0: send auth to b4:07:f9:49:cc:65 (try 1/3)
[ 177.595000] wlan0: send auth to b4:07:f9:49:cc:65 (try 2/3)
[ 177.605000] wlcore: EVENT on mbox 1
[ 177.605000] wlcore: MBOX vector: 0x100000
[ 177.610000] wlcore: MAX_TX_FAILURE_EVENT_ID
[ 177.615000] wlan0: send auth to b4:07:f9:49:cc:65 (try 3/3)
[ 177.640000] wlan0: authentication with b4:07:f9:49:cc:65 timed out
You are send auth requests out, but not getting anything back.
Apparently you're not even getting ACKs (as pointed out by the
MAX_TX_FAILURE_EVENT_ID).
Do you have a sniffer? You could try to use your TP-Link dongle with
wireshark to see if it works fine as a sniffer.
My bet is that you'll see lots of retransmissions there. :\
--
Luca.
^ permalink raw reply
* Re: ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices
From: Geert Uytterhoeven @ 2013-07-10 17:12 UTC (permalink / raw)
To: Kalle Valo, John W. Linville
Cc: linux-wireless, netdev, Linux Kernel Development
In-Reply-To: <20130710022602.1F6F16609DE@gitolite.kernel.org>
On Wed, 10 Jul 2013, Linux Kernel Mailing List wrote:
> --- /dev/null
> +++ b/drivers/net/wireless/ath/ath10k/hw.h
> +#define SUPPORTED_FW_MAJOR 1
> +#define SUPPORTED_FW_MINOR 0
> +#define SUPPORTED_FW_RELEASE 0
> +#define SUPPORTED_FW_BUILD 629
> +static int ath10k_check_fw_version(struct ath10k *ar)
> +{
> + char version[32];
> +
> + if (ar->fw_version_major >= SUPPORTED_FW_MAJOR &&
> + ar->fw_version_minor >= SUPPORTED_FW_MINOR &&
> + ar->fw_version_release >= SUPPORTED_FW_RELEASE &&
> + ar->fw_version_build >= SUPPORTED_FW_BUILD)
> + return 0;
My attention got triggered by:
drivers/net/wireless/ath/ath10k/core.c: In function ‘ath10k_check_fw_version’:
drivers/net/wireless/ath/ath10k/core.c:79: warning: comparison is always true due to limited range of data type
as an u16 is always larger or equal than zero. Not much you can do to
silence that warning, though.
However, I don't think the version check is correct.
Shouldn't it stop checking later fields if an exact match is found in an
earlier field?
I.e.
if (ar->fw_version_major > SUPPORTED_FW_MAJOR ||
(ar->fw_version_major == SUPPORTED_FW_MAJOR &&
ar->fw_version_minor > SUPPORTED_FW_MINOR) ||
...) { ... }
Currently e.g. (major, minor) = (3, 0) is considered older than (2, 1).
Or perhaps minor is never reset to zero when major is increased? In that
case, the check is correct, but IMHO it's a bit silly to split the version
number in seperate fields.
> + snprintf(version, sizeof(version), "%u.%u.%u.%u",
> + SUPPORTED_FW_MAJOR, SUPPORTED_FW_MINOR,
> + SUPPORTED_FW_RELEASE, SUPPORTED_FW_BUILD);
> +
> + ath10k_warn("WARNING: Firmware version %s is not officially supported.\n",
> + ar->hw->wiphy->fw_version);
> + ath10k_warn("Please upgrade to version %s (or newer)\n", version);
> +
> + return 0;
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Baseband watchdog timer tripping on AR9342
From: Harshal Chhaya @ 2013-07-10 16:43 UTC (permalink / raw)
To: linux-wireless
On an AR9342-based AP, we see non-zero counts for
RESET_TYPE_BB_WATCHDOG and RESET_TYPE_BEACON_STUCK when trying to do
large uplink transfers from ~60 clients with some of them 30-40 ft
away.
All the other reset types have a count of zero.
These resets cause all the clients to disconnect.
Any ideas on how to avoid these resets and the subsequent disconnections?
Thanks,
- Harshal
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-10 16:30 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <51DD54D4.6090502@inov.pt>
On 10-07-2013 13:34, José Miguel Gonçalves wrote:
>
> I will try a new AP to see how it behaves...
>
I've tested with my Android smartphone acting as an AP, without authentication,
and I'm also unable to associate!
I get from iw the following error message:
wlan0 (phy #0): failed to connect to b4:07:f9:49:cc:65, status: 1: Unspecified failure
Complete log is here:
http://pastebin.com/DzPmMw8i
So, something is definitely wrong with my setup... but what?
Hope that log has some useful info for you...
Best regards,
José Gonçalves
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-10 14:12 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <1373446089.8385.7.camel@cumari.coelho.fi>
On 10-07-2013 09:48, Luciano Coelho wrote:
> On Tue, 2013-07-09 at 14:22 +0100, José Miguel Gonçalves wrote:
>> On 09-07-2013 13:42, Arik Nemtsov wrote:
>>> On Tue, Jul 9, 2013 at 2:27 PM, José Miguel Gonçalves
>>> <jose.goncalves@inov.pt> wrote:
>>>
>>>> Any more ideas on how to debug this? Is there any specific debug_level mask
>>>> that can apply to the driver to help it?
>>> You can try the mask 0x63c20 (it's pretty verbose, so I would put it
>>> in pastebin).
>>>
>>> Perhaps this is a genuine problem with the antenna of the card?
>> Nope. The AP is 1 meter away form my board (even without antenna in the
>> card it should associate).
> Too strong a signal can also cause problems, because of distortion.
>
>
>>> Can
>>> you verify the RSSI of the AP is ok using iw?
>> The iw output:
>>
>> http://pastebin.com/XmEzqjHs
> This looks okay, but the RSSI value cannot be trusted blindly. There
> are other factors that can influence the signal quality, such as the
> SNR.
>
>
>> The dmesg output with debug mask set to 0x63c20:
>>
>> http://pastebin.com/zGE0Gfp8
>>
>> Note that with debug activated I did not see the driver's "Beacon loss
>> detected" messages.
> There could be some timing issue here. Is it always like that? Do you
> *always* see the "Beacon loss" messages without debugging and *never*
> with debugging?
>
Yep, is always like that!
José Gonçalves
^ permalink raw reply
* Re: [PATCHv4 4/5] mac80211: add channel switch command and beacon callbacks
From: Simon Wunderlich @ 2013-07-10 13:33 UTC (permalink / raw)
To: Michal Kazior
Cc: Simon Wunderlich, Johannes Berg, linux-wireless,
Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <CA+BoTQniF+b0JAjiKyRApttz8Or+urYB+XCxsNFA4y87Cbry-w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
On Wed, Jul 10, 2013 at 12:52:00PM +0200, Michal Kazior wrote:
> On 9 July 2013 20:27, Simon Wunderlich
> <simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> > (...)
> > + /* don't handle if chanctx is used */
> > + if (local->use_chanctx)
> > + return -EINVAL;
> > (...)
>
> This check doesn't seem to be necessary anymore (since you verify if
> the number of channel contexts is 1), or is it?
Yeah, I forgot to remove this check (same for the patch 3).
I'll wait a few days for any further comments, and resend it without this
check.
Thanks,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-10 12:34 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <1373448177.8385.22.camel@cumari.coelho.fi>
On 10-07-2013 10:22, Luciano Coelho wrote:
>> Can my problems be related with an inadequate NVS file? I've generated
>> it with the calibrate tool from ti-utils and the INI file TQS_D_1.7.ini
>> with the command "calibrator plt calibrate". Is this the correct INI for
>> my module (Jorjin's WG7350 - wl1273 based)?
> Yes, the problem can be because of a bad NVS file. Try with the
> "default" NVS file that is provided in linux-firmware.git. That one
> won't be optimal, but should work okay.
I have the same problems with the default NVS file.
>
> I'm not sure which FEM Jorjin's module use. Can you ask them?
I will ask my contact.
>
> I found this on github (Dick Chiang appears to work for Jorjin):
> https://github.com/dickychiang/compat-wireless-r5/blob/master/jorjin/ini_files/TQS_D_1.7_WG7350_NLCP.ini
>
> DISCLAIMER: I have no clue whether this is the correct INI file or not
> and I'm not claiming it's associated with TI in any way, so use it at
> your own risk.
>
Same problem after generating a new NVS file from this INI.
I will try a new AP to see how it behaves...
José Gonçalves
^ permalink raw reply
* Re: ralink 3290: still lots of misc errors reported by Iwconfig with 3.10 + HD streaming on WiFi fails
From: Stanislaw Gruszka @ 2013-07-10 11:31 UTC (permalink / raw)
To: Eric Valette; +Cc: linux-wireless
In-Reply-To: <51DC259D.9010505@Free.fr>
On Tue, Jul 09, 2013 at 05:00:45PM +0200, Eric Valette wrote:
> On 07/09/2013 04:35 PM, Eric Valette wrote:
>
> >>Do you mean that 3.10 perform better than 3.9.9 ? I do not see any
> >>rt2x00 fixes between 3.9 and 3.10 that are not yet applied on 3.9.9.
> >>I can see only some cleanups and new hardware support patches.
> >
> > From memory I think I had a lot of reported TX error with 3.9.9 and
> >they are now gone with 3.10 but the number of misc error reported by
> >iwconfig is still high with 3.10. But you are right the fix for TX is
> >still in wireless git and does not seem to be in 3.10. As I checked
> >several git trees I mist have been confused...
>
> Unless I'm really tired, this patch is in 3.10 and not in 3.9.9 :
>
> http://git.kernel.org/cgit/linux/kernel/git/linville/wireless-testing.git/patch/drivers/net/wireless/rt2x00?id=8857d6dc77e4e3afeee2f33c49597010130ed858
You have right, I missed that one. It's on 3.10 but not on 3.9. We could
post it to 3.9 -stable, but since 3.10 is now realised, 3.9 will become
end of life probably.
Stanislaw
^ permalink raw reply
* Re: [PATCHv4 4/5] mac80211: add channel switch command and beacon callbacks
From: Michal Kazior @ 2013-07-10 10:52 UTC (permalink / raw)
To: Simon Wunderlich
Cc: Johannes Berg, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1373394424-23298-5-git-send-email-siwu@hrz.tu-chemnitz.de>
On 9 July 2013 20:27, Simon Wunderlich
<simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> (...)
> + /* don't handle if chanctx is used */
> + if (local->use_chanctx)
> + return -EINVAL;
> (...)
This check doesn't seem to be necessary anymore (since you verify if
the number of channel contexts is 1), or is it?
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* RE: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels
From: Peer, Ilan @ 2013-07-10 10:47 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Spinadel, David, linux-wireless,
wireless-regdb@lists.infradead.org, Jouni Malinen, Ginsburg, Noam,
Perelmooter, Liraz, Shalev, Oz
In-Reply-To: <CAB=NE6VQXQPRK9_Q-Nh+ripRa+PdCd=4_EZvPxeghBjc32ejyQ@mail.gmail.com>
SGkgTHVpcywgDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldyA6KQ0KDQpJbGFuLg0KDQo+ID4gTm90
ZSB0aGF0IHRoaXMgaXMgYSBwZXJtaXNzaXZlIGFwcHJvYWNoIHRvIHRoZSBGQ0MgZGVmaW5pdGlv
bnMsIHRoYXQNCj4gPiByZXF1aXJlIGEgY2xlYXIgYXNzZXNzbWVudCB0aGF0IGVpdGhlciB0aGUg
cGxhdGZvcm0gZGV2aWNlIGlzIGFuDQo+ID4gaW5kb29yIGRldmljZSwgb3IgdGhlIGRldmljZSBv
cGVyYXRpbmcgdGhlIEFQIGlzIGFuIGluZG9vciBkZXZpY2UsDQo+ID4gaS5lLiwgQUMgcG93ZXJl
ZC4NCj4gPiBJdCBpcyBhc3N1bWVkIHRoYXQgdGhlc2UgcmVzdHJpY3Rpb25zIGFyZSBlbmZvcmNl
ZCBieSB1c2VyIHNwYWNlLg0KPiA+IEZ1cnRoZXJtb3JlLCBpdCBpcyBhc3N1bWVkLCB0aGF0IGlm
IHRoZSBjb25kaXRpb25zIHRoYXQgYWxsb3dlZCBmb3INCj4gPiB0aGUgb3BlcmF0aW9uIG9mIHRo
ZSBHTyBvbiBzdWNoIGEgY2hhbm5lbCBjaGFuZ2UsIGl0IGlzIHRoZQ0KPiA+IHJlc3BvbnNpYmls
aXR5IG9mIHVzZXIgc3BhY2UgdG8gZXZhY3VhdGUgdGhlIEdPIGZyb20gdGhlIGNoYW5uZWwuDQo+
IA0KPiBJbiB0aGUgY29udGV4dCBvZiBzdHJpY3QgcmVndWxhdG9yeSBkYXRhIHdlIGN1cnJlbnRs
eSBkbyBub3QgZGlmZmVyZW50aWF0ZQ0KPiBzcGVjaWZpY2FsbHkgYmV0d2VlbiBhIGRldmljZSB0
aGF0IGNhbiBpbml0aWF0ZSByYWRpYXRpb24gYmV0d2VlbiBBUCBhbmQgR3JvdXANCj4gT3duZXIg
KEdPKSBidXQgaW4geW91ciBlYXJsaWVyIHBhdGNoZXMgeW91IHByb3Bvc2VkIGEgd2F5IHRvIGRv
IHRoYXQuIEkNCj4gcmV2aWV3ZWQgZmVlZGJhY2sgb24gdGhhdCBwYXRjaCB0aGVyZS4gSXQgbWF5
IG1ha2Ugc2Vuc2UgaG93ZXZlciB0byBkZWZpbmUNCj4gY2xlYXJseSB3aGF0IHlvdSBtZWFuIGJ5
IHdoeSB0aGUgZmxhZyBpcyBiZWluZyBpbnRyb2R1Y2VkIGJ5IGRvY3VtZW50aW5nIHRoZQ0KPiB1
c2UgY2FzZSwgaWUgd2hhdCB5b3UgZGVzY3JpYmUgaGVyZS4gT3RoZXIgcmVndWxhdG9yeSBib2Rp
ZXMgbWF5IGZvbGxvdyBhbmQgaXQNCj4gaGVscHMgdG8gcHJvdmlkZSBjb250ZXh0IGhlcmUuDQoN
ClN1cmUsIEknbGwgYWRkIHN1Y2ggYSB1c2UgY2FzZSB0byB0aGUgcHJldmlvdXMgcGF0Y2gNCg0K
PiA+IGRpZmYgLS1naXQgYS9uZXQvd2lyZWxlc3MvS2NvbmZpZyBiL25ldC93aXJlbGVzcy9LY29u
ZmlnIGluZGV4DQo+ID4gZGU3NjA3OC4uZDllMmJlNyAxMDA2NDQNCj4gPiAtLS0gYS9uZXQvd2ly
ZWxlc3MvS2NvbmZpZw0KPiA+ICsrKyBiL25ldC93aXJlbGVzcy9LY29uZmlnDQo+ID4gQEAgLTEw
Miw2ICsxMDIsMTYgQEAgY29uZmlnIENGRzgwMjExX1JFR19DRUxMVUxBUl9ISU5UUw0KPiA+ICAg
ICAgICAgICBUaGlzIG9wdGlvbiBhZGRzIHN1cHBvcnQgZm9yIGRyaXZlcnMgdGhhdCBjYW4gcmVj
ZWl2ZSByZWd1bGF0b3J5DQo+ID4gICAgICAgICAgIGhpbnRzIGZyb20gY2VsbHVsYXIgYmFzZSBz
dGF0aW9ucw0KPiA+DQo+ID4gK2NvbmZpZyBDRkc4MDIxMV9SRUdfU09GVF9DT05GSUdVUkFUSU9O
Uw0KPiA+ICsgICAgICAgYm9vbCAiY2ZnODAyMTEgc3VwcG9ydCBmb3IgR08gb3BlcmF0aW9uIG9u
IGFkZGl0aW9uYWwgY2hhbm5lbHMiDQo+ID4gKyAgICAgICBkZXBlbmRzIG9uIENGRzgwMjExICYm
IENGRzgwMjExX0NFUlRJRklDQVRJT05fT05VUw0KPiA+ICsgICAgICAgLS0taGVscC0tLQ0KPiA+
ICsgICAgICAgICBUaGlzIG9wdGlvbiBlbmFibGVzIHRoZSBvcGVyYXRpb24gb2YgYSBQMlAgR3Jv
dXAgT3duZXIgb24NCj4gPiArICAgICAgICAgYWRkaXRpb25hbCBjaGFubmVscywgaWYgdGhlcmUg
aXMgYSBjbGVhciBhc3Nlc3NtZW50IHRoYXQNCj4gPiArICAgICAgICAgdGhlIHBsYXRmb3JtIGRl
dmljZSBvcGVyYXRlcyBpbiBhbiBpbmRvb3IgZW52aXJvbm1lbnQgb3INCj4gPiArICAgICAgICAg
aW4gY2FzZSB0aGF0IHRoZXJlIGlzIGFuIGFkZGl0aW9uYWwgQlNTIGludGVyZmFjZSB3aGljaCBp
cw0KPiA+ICsgICAgICAgICBjb25uZWN0ZWQgdG8gYW4gQVAgd2hpY2ggaXMgYW4gaW5kb29yIGRl
dmljZS4NCj4gPiArDQo+IA0KPiBJIGxpa2UgdGhpcyBhcHByb2FjaCwgaW5kZWVkIHRoaXMgaXMg
Z3JlYXQgd29yayBhbmQgcmVmbGVjdHMgdXNhZ2Ugb2YgdGhlIG9udXMNCj4ga2NvbmZpZyBvcHRp
b24gYXBwcm9wcmlhdGVseSBpbiB0aGlzIGNhc2UgZHVlIGRpbGxpZ2VuY2UgcmVxdWlyZWQgbW9y
ZSBpbiBwYXJ0DQo+IG9uIHVzZXJzcGFjZSAvIG90aGVyIGNvbXBvbmVudHMgZm9yIGZ1bGwgcmVn
dWxhdG9yeSBjb21wbGlhbmNlLg0KPiANCg0KVGhlIGNyZWRpdCBoZXJlIHNob3VsZCBnbyB0byBK
b2hhbm5lcyA6KQ0KDQo+ID4gKyNpZmRlZiBDUFRDRkdfQ0ZHODAyMTFfUkVHX1NPRlRfQ09ORklH
VVJBVElPTlMNCj4gPiArc3RhdGljIGludCBjZmc4MDIxMV9nZXRfdW5paV9iYW5kKGludCBmcmVx
KSB7DQo+ID4gKyAgICAgICAvKiBVTklJLTEgKi8NCj4gPiArICAgICAgIGlmIChmcmVxID49IDUx
NTAgJiYgZnJlcSA8PSA1MjUwKQ0KPiA+ICsgICAgICAgICAgICAgICByZXR1cm4gMDsNCj4gPiAr
DQo+ID4gKyAgICAgICAvKiBVTklJLTIgKi8NCj4gPiArICAgICAgIGlmIChmcmVxID4gNTI1MCAm
JiBmcmVxIDw9IDUzNTApDQo+ID4gKyAgICAgICAgICAgICAgIHJldHVybiAxOw0KPiA+ICsNCj4g
PiArICAgICAgIC8qIFVOSUktMkUgKi8NCj4gPiArICAgICAgIGlmIChmcmVxID49IDU0NzAgJiYg
ZnJlcSA8PSA1NzI1KQ0KPiA+ICsgICAgICAgICAgICAgICByZXR1cm4gMjsNCj4gPiArDQo+ID4g
KyAgICAgICAvKiBVTklJLTMgKi8NCj4gPiArICAgICAgIGlmIChmcmVxID4gNTcyNSAmJiBmcmVx
IDw9IDU4MjUpDQo+ID4gKyAgICAgICAgICAgICAgIHJldHVybiAzOw0KPiA+ICsNCj4gPiArICAg
ICAgIFdBUk5fT04oMSk7DQo+ID4gKyAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4gPiArfQ0KPiA+
ICsjZW5kaWYNCj4gDQo+ICNlbHNlPw0KDQpXZSBjb25zaWRlcmVkIHRoaXMgYXBwcm9hY2gsIGJ1
dCBwcmVmZXJyZWQgdG8gbW92ZSB0aGUgaWZkZWYgaW5zaWRlIHRoZSBmdW5jdGlvbi4NCg0KPiAN
Cj4gQXJlIHlvdSBhd2FyZSBvZiBVTklJLTEsIFVOSUktMiwgVU5JSS0yRSwgVU5JSS0zIGFyZSBz
cGVjaWZpYyB3b3JsZCByZWd1bGF0b3J5DQo+IGxhbmd1YWdlIGJhbmRzPyBXaGVuIEkgbGFzdCB0
cmllZCB0byBsb29rIGZvciBhIGNsZWFyIGRlZmluaXRpb24gSSBjb3VsZCBub3QgZmluZA0KPiBh
IGNsZWFyIGRlZmluaXRpb24gb2YgdGhlbSBhbmQgaXRzIHdoeSBvbiB0aGUgYXRoIG1vZHVsZSBv
biBmb3IgUUNBIG1vZHVsZXMgSQ0KPiBzdGF0ZSAid2UgY2FsbCB0aGVzZSIgaW4gcmVmZXJlbmNl
IHRvIHRoZSBVTklJIG5vbWVuY2xhdHVyZS4gSWYgd2UgY2FuIGdldCBhDQo+IGNsZWFyIHJlc291
cmNlIGZvciBpdHMgZGVmaW5pdGlvbiB0aGF0IHdvdWxkIGhlbHAgaGVyZS4NCj4gDQoNCk1heWJl
IHRoZXNlIGxpbmsgd2lsbCBoZWxwLg0KaHR0cDovL3d3dy5ncG8uZ292L2Zkc3lzL3BrZy9DRlIt
MjAxMC10aXRsZTQ3LXZvbDEveG1sL0NGUi0yMDEwLXRpdGxlNDctdm9sMS1wYXJ0MTUueG1sI3Nl
cW51bTE1LjQwMw0KaHR0cDovL2hyYXVuZm9zcy5mY2MuZ292L2Vkb2NzX3B1YmxpYy9hdHRhY2ht
YXRjaC9GQ0MtMTMtMjJBMS5wZGYNCg0KQW55d2F5LCBJIHdpbGwgdXNlIHlvdXIgJyd3ZSBjYWxs
IHRoZXNlIiBub3RhdGlvbiBhcyB3ZWxsIDopDQoNCj4gPiArDQo+ID4gKy8qIEZvciBHTyBvbmx5
LCBjaGVjayBpZiB0aGUgY2hhbm5lbCBjYW4gYmUgdXNlZCB1bmRlciBwZXJtaXNzaXZlDQo+ID4g
K2NvbmRpdGlvbnMNCj4gPiArICogbWFuZGF0ZWQgYnkgdGhlIEZDQywgaS5lLiwgdGhlIGNoYW5u
ZWwgaXMgbWFya2VkIGFzOg0KPiANCj4gQWggLS0gbm90ZSAtIEZDQywgeW91IGFyZSBtYWtpbmcg
YW4gRkNDIHNwZWNpZmljIHJ1bGUgZ2xvYmFsLCB0aGF0IGRvZXNuJ3Qgc2VlbXMNCj4gcmlnaHQu
IFRoZSBpbXBsZW1lbnRhdGlvbiBzaG91bGQgcmVmbGVjdCB0aGF0ICpzb21lKiByZWd1bGF0b3J5
IGJvZGllcyBhcmUNCj4gaW1wbGljYXRpbmcgc29mdHdhcmUgcmVxdWlyZW1lbnRzIGZvciBHTyBv
cGVyYXRpb24gYW5kIGluIHRoYXQgY2FzZSB0aGlzIHRyaWVzDQo+IHRvIGltcGxlbWVudCBzdWNo
IGtub3duIGN1cnJlbnQgaW50ZXJwcmV0YXRpb25zLg0KPiANCj4gSG9wZSBpcyB0aGF0IHJlZ3Vs
YXRvcnkgYm9kaWVzIHdpbGwgc3RpY2sgdG8gdGhpcyBzaW5ndWxhciBpbnRlcnByZXRhdGlvbiAv
DQo+IHByZWZlcmVuY2Ugd2hlbiByZXF1aXJlZC4NCj4gDQo+IFNvIG15IHBvaW50OiB5b3VyIGNv
ZGUgdHJlYXRzIHRoaXMgYXBwcm9wcmlhdGVseSBhcyBhZ25vc3RpYyB0byB0aGUgcmVndWxhdG9y
eQ0KPiBib2R5IGJ1dCB5b3VyIGNvbW1lbnRzIGRvIG5vdCwganVzdCBtb2RpZnkgdGhlIGNvbW1l
bnRzIG1vcmUgdG8gbWFrZSBpdA0KPiBtb3JlIGFnbm9zdGljLg0KPg0KDQpXaWxsIGZpeC4NCiAN
Cj4gPiArICogMS4gSW5kb29yIG9ubHk6IGEgR08gY2FuIGJlIG9wZXJhdGlvbmFsIG9uIHN1Y2gg
YSBjaGFubmVsLCBpZmYgdGhlcmUgaXMNCj4gPiArICogICAgY2xlYXIgYXNzZXNzbWVudCB0aGF0
IHRoZSBwbGF0Zm9ybSBkZXZpY2UgaXMgaW5kb29yLg0KPiA+ICsgKiAyLiBDb25jdXJyZW50IEdP
OiBhIEdPIGNhbiBiZSBvcGVyYXRpb25hbCBvbiBzdWNoIGEgY2hhbm5lbCwgaWZmIHRoZXJlIGlz
DQo+IGFuDQo+ID4gKyAqICAgIGFkZGl0aW9uYWwgc3RhdGlvbiBpbnRlcmZhY2UgY29ubmVjdGVk
IHRvIGFuIEFQIG9uIHRoaXMgY2hhbm5lbC4NCj4gPiArICoNCj4gPiArICogVE9ETzogVGhlIGZ1
bmN0aW9uIGlzIHRvbyBwZXJtaXNzaXZlLCBhcyBpdCBkb2VzIG5vdCB2ZXJpZnkgdGhlDQo+ID4g
KyBwbGF0Zm9ybQ0KPiA+ICsgKiBkZXZpY2UgdHlwZSBpcyBpbmRlZWQgaW5kb29yLCBvciB0aGF0
IHRoZSBBUCBpcyBpbmRvb3IvQUMgcG93ZXJlZC4NCj4gDQo+IFNvIHRvIGRvIHRoaXMgcHJvcGVy
bHkgd2UgbmVlZCBhbiBldmVudHVhbCB1c2Vyc3BhY2UgQVBJIHRvIHRocm93IHRvDQo+IGtlcm5l
bHNwYWNlIGlmIHdlIGFyZSBBQyBwb3dlcmVkPyBXZSdsbCBuZWVkIHRoaXMgdG8gZW5oYW5jZSB0
aGlzIHJvdXRpbmUNCj4gaGVyZT8NCj4gDQoNCk5vdCBzdXJlIGFib3V0IHRoaXMgcG9pbnQuIEkg
cHJlZmVyIGxlYXZpbmcgdGhlIGV4YWN0IGtub3dsZWRnZSBvZiB0aGUgZGV2aWNlIHR5cGUsIGJl
aW5nIEFDIFBvd2VyZWQgb3Igbm90IChhbmQgd2hpY2ggdHlwZSBvZiBBQyBwb3dlcikgZXRjLiBv
dXQgc2lkZSBvZiB0aGUga2VybmVsLiBUaGUgYXBwcm9hY2ggSSBjaG9zZSB3aXRoIHRoaXMgcGF0
Y2ggd2FzIHRvIG9ubHkgYWxsb3cgdG8gc3RhcnQgYSBHTyBvbiBzdWNoIGEgY2hhbm5lbCwgbWFr
aW5nIHRoZSBiYXNpYyB2ZXJpZmljYXRpb24gZG9uZSBhYm92ZSwgYXNzdW1pbmcgdGhhdCB0aGUg
dXNlciBzcGFjZSBjb21wb25lbnQgZ3VhcmFudGVlcyB0aGF0IGFsbCB0aGUgZnVsbCByZXN0cmlj
dGlvbnMgYXJlIHNhdGlzZmllZC4NCg0KPiA+ICsgKi8NCj4gPiArc3RhdGljIGJvb2wgY2ZnODAy
MTFfY2FuX2dvX3VzZV9jaGFuKHN0cnVjdCBjZmc4MDIxMV9yZWdpc3RlcmVkX2RldmljZQ0KPiAq
cmRldiwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGll
ZWU4MDIxMV9jaGFubmVsICpjaGFuKSB7DQo+ID4gKyNpZmRlZiBDUFRDRkdfQ0ZHODAyMTFfUkVH
X1NPRlRfQ09ORklHVVJBVElPTlMNCj4gPiArICAgICAgIHN0cnVjdCB3aXJlbGVzc19kZXYgKndk
ZXZfaXRlcjsNCj4gPiArDQo+ID4gKyAgICAgICBBU1NFUlRfUlROTCgpOw0KPiA+ICsNCj4gPiAr
ICAgICAgIGlmICghKGNoYW4tPmZsYWdzICYgKElFRUU4MDIxMV9DSEFOX0lORE9PUl9PTkxZIHwN
Cj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIElFRUU4MDIxMV9DSEFOX0dPX0NPTkNV
UlJFTlQpKSkNCj4gPiArICAgICAgICAgICAgICAgcmV0dXJuIGZhbHNlOw0KPiA+ICsNCj4gPiAr
ICAgICAgIGlmIChjaGFuLT5iYW5kID09IElFRUU4MDIxMV9CQU5EXzYwR0haKQ0KPiA+ICsgICAg
ICAgICAgICAgICByZXR1cm4gZmFsc2U7DQo+ID4gKw0KPiA+ICsgICAgICAgbGlzdF9mb3JfZWFj
aF9lbnRyeSh3ZGV2X2l0ZXIsICZyZGV2LT53ZGV2X2xpc3QsIGxpc3QpIHsNCj4gPiArICAgICAg
ICAgICAgICAgc3RydWN0IGllZWU4MDIxMV9jaGFubmVsICpvdGhlcl9jaGFuID0gTlVMTDsNCj4g
PiArDQo+ID4gKyAgICAgICAgICAgICAgIGlmICh3ZGV2X2l0ZXItPmlmdHlwZSAhPSBOTDgwMjEx
X0lGVFlQRV9TVEFUSU9OIHx8DQo+ID4gKyAgICAgICAgICAgICAgICAgICAoIW5ldGlmX3J1bm5p
bmcod2Rldl9pdGVyLT5uZXRkZXYpKSkNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNvbnRpbnVlOw0KPiA+ICsNCj4gPiArDQo+ID4gKyAgICAgICAgICAgICAgIHdkZXZfbG9j
ayh3ZGV2X2l0ZXIpOw0KPiA+ICsgICAgICAgICAgICAgICBpZiAod2Rldl9pdGVyLT5jdXJyZW50
X2JzcykNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICBvdGhlcl9jaGFuID0gd2Rldl9pdGVy
LT5jdXJyZW50X2Jzcy0+cHViLmNoYW5uZWw7DQo+ID4gKyAgICAgICAgICAgICAgIHdkZXZfdW5s
b2NrKHdkZXZfaXRlcik7DQo+ID4gKw0KPiA+ICsgICAgICAgICAgICAgICBpZiAoIW90aGVyX2No
YW4pDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgY29udGludWU7DQo+ID4gKw0KPiA+ICsg
ICAgICAgICAgICAgICBpZiAoY2hhbiA9PSBvdGhlcl9jaGFuKQ0KPiA+ICsgICAgICAgICAgICAg
ICAgICAgICAgIHJldHVybiB0cnVlOw0KPiA+ICsgICAgICAgICAgICAgICBlbHNlIGlmICgoY2hh
bi0+YmFuZCA9PSBJRUVFODAyMTFfQkFORF81R0haKSAmJg0KPiA+ICsgICAgICAgICAgICAgICAg
ICAgICAgICAoY2ZnODAyMTFfZ2V0X3VuaWlfYmFuZChjaGFuLT5jZW50ZXJfZnJlcSkgPT0NCj4g
PiArICAgICAgICAgICAgICAgICAgICAgICAgIGNmZzgwMjExX2dldF91bmlpX2JhbmQob3RoZXJf
Y2hhbi0+Y2VudGVyX2ZyZXEpKSkNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4g
dHJ1ZTsNCj4gPiArICAgICAgIH0NCj4gPiArI2VuZGlmDQo+ID4gKyAgICAgICByZXR1cm4gZmFs
c2U7DQo+ID4gK30NCj4gDQo+IFBsZWFzZSB3cmFwIGNvZGUgYXMgZm9sbG93czoNCj4gDQo+ICNp
ZmRlZiBGT08NCj4gc3RhdGljIGludCBmb28odm9pZCkNCj4gew0KPiAgIHJldHVybiB0cnVlOw0K
PiB9DQo+ICNlbHNlDQo+IHN0YXRpYyBpbnQgZm9vKHZvaWQpDQo+ICAgcmV0dXJuIGZhbHNlOw0K
PiB9DQo+ICNlbmRpZg0KDQpPay4gSSBjYW4gZG8gdGhhdC4NCg0KPiBJbiB0aGUgbWVhbnRpbWUs
IHdoaWxlIHlvdSBnZXQgYWxsIHlvdXIgcGF0Y2ggc2V0cyBwcm9wZXJseSBkZXZlbG9wZWQgSSdk
DQo+IHJlY29tbWVuZCB0byBkZWZpbmUgdGhlIGNvZGUgcmV0dXJuaW5nIGZhbHNlIHRoZXJlIHN0
cmljdGx5IG9yIHBlcmhhcHMgZm9yIGFueQ0KPiBmbGFnIG9uIHRoZSBjaGFubmVsIHJlcXVpcmlu
ZyBERlMgLyBuby1pYnNzLCBvciBwYXNzaXZlIHNjYW4uIFRoZSBzdHJpY3RlciBjYXNlLA0KPiBk
ZWZpbmluZyBmYWxzZSBhbHdheXMsIHNlZW1zIHRvIGJlIHdoYXQgeW91IGFyZSBzdWdnZXN0aW5n
IGhlcmUuDQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBuZWVkZWQgaGVyZS4gUmV0dXJu
aW5nIGZhbHNlLCBtZWFucyB0aGF0IHRoZSBjb2RlIHNob3VsZCB0ZXN0IGlmIHRoZSBQQVNTSVZF
X1NDQU4gYW5kIE5PX0lCU1MgYXJlIG5vdCBzZXQgb24gdGhlIGNoYW5uZWwgd2Ugd2FudCB0byBz
dGFydCBiZWFjb25pbmcgb24uDQoNCj4gRG8geW91IGhhdmUgYSB3aGl0ZSBsaXN0IHRoYXQgY2Fu
IGV4Y2x1ZGUgc29tZSBjaGFubmVscyBmb3Igbm93IGdsb2JhbGx5IG9yDQo+IHNvbWVob3cgYXMg
YWxsIHRoaXMgbGluZXMgdXA/DQo+IA0KDQpOb3RlIHN1cmUgSSB1bmRlcnN0b29kIHdoYXQgeW91
IGFyZSBsb29raW5nIGZvci4gQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB0aGlzIHBvaW50Pw0K
^ permalink raw reply
* RE: [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes
From: Peer, Ilan @ 2013-07-10 10:43 UTC (permalink / raw)
To: Luis R. Rodriguez, wireless-regdb@lists.infradead.org
Cc: linux-wireless, Spinadel, David, Ginsburg, Noam,
Perelmooter, Liraz, Shalev, Oz
In-Reply-To: <CAB=NE6Wr_Y+uoGwOT_nE-VE49vd0eobv_F7=hF=mtVfGgCOehg@mail.gmail.com>
SGkgTHVpcywNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBXaWxsIG5lZWQgc29tZSBtb3JlIHRp
bWUgdG8gbG9vayBhdCB5b3VyIHN1Z2dlc3Rpb25zIGJlbG93IDopDQoNClJlZ2FyZHMsDQoNCkls
YW4uDQoNCj4gDQo+IE9uIFR1ZSwgSnVsIDIsIDIwMTMgYXQgNToyOCBBTSwgSWxhbiBQZWVyIDxp
bGFuLnBlZXJAaW50ZWwuY29tPiB3cm90ZToNCj4gPiBGcm9tOiBEYXZpZCBTcGluYWRlbCA8ZGF2
aWQuc3BpbmFkZWxAaW50ZWwuY29tPg0KPiA+DQo+ID4gVGhlIEZDQyBhcmUgY2xhcmlmeWluZyBz
b21lIHNvZnQgY29uZmlndXJhdGlvbiByZXF1aXJlbWVudHMsIHdoaWNoDQo+ID4gYW1vbmcgb3Ro
ZXIgaW5jbHVkZXMgdGhlIGZvbGxvd2luZzoNCj4gPg0KPiA+IDEuIENvbmN1cnJlbnQgR08gb3Bl
cmF0aW9uLCB3aGVyZSBkZXZpY2VzIG1heSBzdXBwb3J0IFdGRCBpbg0KPiA+ICAgIGJhbmRzIHdo
ZXJlIGFuIGF1dGhvcml6ZWQgbWFzdGVyIChmb3IgZXhhbXBsZSB3aXRoIERGUyBhbmQNCj4gPiAg
ICBERlMgYW5kIHJhZGFyIGRldGVjdGlvbiBjYXBhYmlsaXR5IGluIHRoZSBVTklJIGJhbmQpIGlz
IG9wZXJhdGluZy4NCj4gDQo+IElzIFdGRCBXaUZpIERpc3BsYXk/IElzIHRoZXJlIGFueSBzdHJp
Y3QgcmVsYXRpb25zaGlwIGhlcmUgdG8gV0ZEIGFuZCBHTyBhbmQNCj4gcmVndWxhdG9yeSBvciBp
cyBXRkQganVzdCBhIHVzZSBjYXNlIGV4YW1wbGU/IEFyZSB5b3UgaW5kaWNhdGluZyB0aGF0IHRo
ZSBGQ0MNCj4gaXMgbWFraW5nIHNwZWNpYWwgcnVsZXMgZm9yIGNhc2VzIGluIHNwZWNpZmljIGJh
bmRzIHdoZXJlIEdPICpjYW4qIGNvLWV4aXN0IHdpdGgNCj4gb3RoZXIgR08gZGV2aWNlcyA/DQoN
CldGRCBpcyBXaUZpIGRpcmVjdCBpbiB0aGlzIGNvbnRleHQuIEkgZG8gbm90IHRoaW5rIHRoYXQg
dGhlIEZDQyBhcmUgbWFraW5nIHNwZWNpYWwgcnVsZXMgb25seSBmb3IgR08gc3BlY2lmaWMgc2Nl
bmFyaW9zIGJ1dCBhIG1vcmUgZ2VuZXJhbCBhcHByb2FjaCB3aGVyZSAiY29tcGxpYW5jZSBtYXkg
YmUgYWNoaWV2ZWQgdW5kZXIgdGhlIGd1aWRhbmNlIG9mIGFuIGF1dGhvcml6ZWQgbWFzdGVyIi4g
VGhlIFdGRC9QMlAgR08gY2FzZSBpcyBvbmx5IGFuIGV4YW1wbGUuDQoNCj4gWW91IGFubm90YXRl
IHRoYXQgdGhpcyBpcyBzb21laG93IHJlbGF0ZWQgdG8gREZTLCBhcmUgdGhlIEdPIGNvbmN1cnJl
bnQgcnVsZXMNCj4gdGhhdCB0aGUgRkNDIGlzIGRlZmluaW5nIG9ubHkgYXBwbGljYWJsZSB0byBE
RlMgZnJlcXVlbmN5IHJhbmdlcz8gSWYgc28gd291bGQgaXQNCj4gc3VmZmljZSB0byBvbmx5IHVz
ZSBERlMgZmxhZyA/IE9yIGFyZSB0aGVyZSBvdGhlciBzcGVjaWFsIGNhc2VzIGJleW9uZCBERlMN
Cj4gZnJlcXVlbmN5IHJhbmdlcyB0aGF0IHRoZSBGQ0MgaXMgY3JlYXRpbmcgc3BlY2lhbCBoYW5k
bGluZz8NCj4NCg0KREZTIHdhcyBnaXZlbiBoZXJlIGFzIGFuIGV4YW1wbGUuIEdlbmVyYWxseSwg
SSB0aGluayB0aGF0IHRoZSBjaGFuZ2VzIHRoYXQgdGhlIEZDQyBhcmUgbWFraW5nIGFyZSB0YXJn
ZXRpbmcgdmFyaW91cyBzY2VuYXJpb3MgYW5kIHZhcmlvdXMgUkYgZGV2aWNlcyAoZm9yIGV4YW1w
bGUgdGhvc2UgZGVmaW5lZCBpbiBwYXJ0IDE1IG9mIENGUiB0aXRsZSA0NykuDQogDQo+IEFwYXJ0
IGZyb20gdGhlIEZDQyBhcmUgeW91IGF3YXJlIG9mIHNwZWNpYWwgY2FzZXMgaGFuZGxpbmcgZm9y
IG90aGVyDQo+IHJlZ3VsYXRvcnkgYm9kaWVzIGF0IHRoaXMgcG9pbnQ/DQoNCk5vdCB0aGF0IEkn
bSBhd2FyZSBvZi4gQWRkaW5nIHNvbWUgbW9yZSBwZW9wbGUgdGhhdCBtaWdodCBrbm93IG1vcmUu
DQoNCj4gDQo+IE5vdGUgdGhhdCB3ZSBoYXZlIGFscmVhZHkgdGhlc2Ugb24gcmVnZGIuaCBmcm9t
IENSREE6DQo+IA0KPiANCj4gLyoNCj4gICogVGhlIExpbnV4IG1hcCBkZWZpbmVkIGluIDxsaW51
eC91YXBpL25sODAyMTEuaD4gZW51bQ0KPiBubDgwMjExX3JlZ19ydWxlX2ZsYWdzICAqLyBlbnVt
IHJlZ19ydWxlX2ZsYWdzIHsNCj4gICAgICAgICBSUkZfTk9fT0ZETSAgICAgICAgICAgICA9IDE8
PDAsIC8qIE9GRE0gbW9kdWxhdGlvbiBub3QgYWxsb3dlZCAqLw0KPiAgICAgICAgIFJSRl9OT19D
Q0sgICAgICAgICAgICAgID0gMTw8MSwgLyogQ0NLIG1vZHVsYXRpb24gbm90IGFsbG93ZWQgKi8N
Cj4gICAgICAgICBSUkZfTk9fSU5ET09SICAgICAgICAgICA9IDE8PDIsIC8qIGluZG9vciBvcGVy
YXRpb24gbm90IGFsbG93ZWQgKi8NCj4gICAgICAgICBSUkZfTk9fT1VURE9PUiAgICAgICAgICA9
IDE8PDMsIC8qIG91dGRvb3Igb3BlcmF0aW9uIG5vdCBhbGxvd2VkICovDQo+ICAgICAgICAgUlJG
X0RGUyAgICAgICAgICAgICAgICAgPSAxPDw0LCAvKiBERlMgc3VwcG9ydCBpcyByZXF1aXJlZCB0
byBiZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogdXNlZCAq
Lw0KPiAgICAgICAgIFJSRl9QVFBfT05MWSAgICAgICAgICAgID0gMTw8NSwgLyogdGhpcyBpcyBv
bmx5IGZvciBQb2ludCBUbyBQb2ludA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICogbGlua3MgKi8NCj4gICAgICAgICBSUkZfUFRNUF9PTkxZICAgICAgICAgICA9
IDE8PDYsIC8qIHRoaXMgaXMgb25seSBmb3IgUG9pbnQgVG8gTXVsdGkNCj4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIFBvaW50IGxpbmtzICovDQo+ICAgICAgICAg
UlJGX1BBU1NJVkVfU0NBTiAgICAgICAgPSAxPDw3LCAvKiBwYXNzaXZlIHNjYW4gaXMgcmVxdWly
ZWQgKi8NCj4gICAgICAgICBSUkZfTk9fSUJTUyAgICAgICAgICAgICA9IDE8PDgsIC8qIElCU1Mg
aXMgbm90IGFsbG93ZWQgKi8NCj4gfTsNCj4gDQo+IEhpc3RvcmljYWxseSB3ZSBkb24ndCBkaXN0
aW5ndWlzaCB0aGVuIGEgdHlwZSBvZiA4MDIuMTEgZGV2aWNlIHRoYXQgaW5pdGlhdGVzDQo+IHJh
ZGlhdGlvbiBleGNlcHQgZm9yIHRoZSBOT19JQlNTIHJ1bGUsIGJ1dCB0aGF0IHJ1bGUgY2FuIGJl
IHRyZWF0ZWQgbW9yZSBhcw0KPiBsZWdhY3kgZ2l2ZW4gdGhhdCB0aGUgaW50ZW50IGFuZCBtb3Rp
dmF0aW9uIGJlaGluZCB0aGF0IHdhcyB0aGF0IHNvbWUgT0RNcw0KPiBzaW1wbHkgcHJlZmVycmVk
IGFuIGludGVycHJldGF0aW9uIG9mIHJlZ3VsYXRvcnkgcnVsZXMgYW5kIHdlICpjdXJyZW50bHkq
IGRvbid0DQo+IHVzZSB0aGF0IGluIG11Y2ggcGxhY2VzIG90aGVyIHRoYW4gY3VzdG9tIHJlZ3Vs
YXRvcnkgZG9tYWlucyBkZWZpbmVkIGluIHRoZQ0KPiBrZXJuZWwuIFRoZSBQVFBfT05MWSBhbmQg
UFRNUF9PTkxZIGFyZSBleGFtcGxlIG90aGVyIHJ1bGVzIHRoYXQgY291bGQNCj4gcG90ZW50aWFs
bHkgaGF2ZSBiZWVuIHVzZWQgYnV0IHRvIHRoaXMgZGF5IHdlIGhhdmVuJ3QgZm91bmQgYSB1c2Ug
Y2FzZSBmb3IgaXQNCj4gZ2l2ZW4gdGhhdCB0eXBpY2FsIDgwMi4xMSBkZXZpY2VzIGFyZSBQVE1Q
Lg0KPiANCj4gSSBtZW50aW9uIHRoZSBOT19JQlNTIGNhc2UgYXMgSSdkIGxpa2UgdG8gdHJ5IHRv
IGF2b2lkIGFkZGluZyBHTyBzcGVjaWZpYyBmbGFnIGlmDQo+IHdlIGNhbiBmaWd1cmUgb3V0IGEg
d2F5IHRvIG1ha2UgdGhpcyBtb3JlIGdlbmVyaWMuIEF0IHRoaXMgcG9pbnQgZm9yIGV4YW1wbGUg
SQ0KPiB0aGluayBhIG1vcmUgYXBwcm9wcmlhdGUgZmxhZyBpcyBpbiBwbGFjZToNCj4gDQoNCkFj
dHVhbGx5LCB0aGlzIHNob3VsZCBiZSBhIEdPIG9ubHkgZmxhZywgbWVhbmluZyB0aGF0IHN1Y2gg
cmVsYXhhdGlvbiBzaG91bGQgbm90IGJlIHZhbGlkIGZvciBzb2Z0IEFQLCBJQlNTIG9yIG1lc2gu
IFRoZSBpbnRlbnRpb24gaGVyZSBpcyBsaW1pdCB0aGUgZXh0ZW5kIG9mIHRoZSBjZWxsLCBhbmQg
cHJldmVudCBkYWlzeSBjaGFpbiBzY2VuYXJpb3MgKGFzc3VtZSB0aGF0IHlvdSBhbGxvdyBhIHNv
ZnQgQVAgb24gc3VjaCBhIGNoYW5uZWwgYW5kIHRoYXQgYSBjbGllbnQgYXNzb2NpYXRlZCB0byBp
dCwgYW5kIHRoZW4gdGhhdCBkZXZpY2UgY2FuIGFsc28gc3RhcnQgYSBzb2Z0IEFQIG9uIHRoZSBj
aGFubmVsIC4uLi4pLiBBbnl3YXksIEknbGwgbmVlZCB0byBoYXZlIGFub3RoZXIgbG9vayBhdCB0
aGlzIChtaWdodCBiZSBwZXJtaXNzaWJsZSBmb3IgSUJTUyAuLi4pDQoNCj4gICAqIE5PX0lSIC0g
Y2Fubm90IGluaXRpYXRlIHJhZGlhdGlvbg0KPiANCj4gQW5kIHRoaXMgY291bGQgaW4gdHVybiBl
bmQgdXAgcmVwbGFjaW5nIG1vc3QgdXNlIGNhc2VzIG9mIE5PX0lCU1MgYW5kDQo+IFBBU1NJVkVf
U0NBTiBnaXZuZSB0aGF0IGJvdGggb2YgdGhlc2UgaW1wbHkgd2UgY2Fubm90IGluaXRpYXRlIHJh
ZGlhdGlvbg0KPiB1bmxlc3Mgc3BlY2lmaWMgdGhpbmdzIGFyZSBkb25lLiBJIHdvbmRlciBpZiB3
ZSBjYW4gZm9sZCB0aGUgR08gZmxhZyBpbnRvIHRoaXMgYW5kDQo+IHBlcmhhcHMgcmVuYW1lIHRo
ZSBOT19JQlNTIGZsYWcgdG8gdGhlIEdPIG9uZS4NCj4gDQo+IEFsc28gbm90ZSB0aGF0IHdlIHNo
b3VsZCBrZWVwIHRoZSBmbGFncyBpbiBzeW5jIHdpdGggdGhlIHVhcGkgbmw4MDIxMSBjaGFuZ2Uu
DQo+IFBsZWFzZSByZXZpZXcgdGhlc2Ugc3VnZ2VzdGlvbnMgYW5kIGxldCBtZSBrbm93IHdoYXQg
eW91IHRoaW5rLg0KPiANCg0KU3VyZS4gV2lsbCBuZWVkIHRvIHRha2UgYSBkZWVwZXIgbG9vayBh
dCB0aGlzLg0KDQo+ID4gMi4gSW5kb29yIG9wZXJhdGlvbiwgd2hlcmUgaW4gYmFuZHMgcmVxdWly
aW5nIGluZG9vciBvcGVyYXRpb24sIHRoZQ0KPiA+ICAgIGRldmljZSBtdXN0IGJlIHByb2dyYW1t
ZWQgdG8gZGV0ZWN0IGluZG9vciBvcGVyYXRpb24sIG9yDQo+ID4gICAgLSBEZXZpY2UgbXVzdCBi
ZSBjb25uZWN0ZWQgdG8gQUMgUG93ZXINCj4gDQo+IERvZXMgYW55b25lICBrbm93IGlmIHRoZSBG
Q0MgY29uc2lkZXJzICJpbmRvb3IiIGlmIHdlIHBvd2VyIGEgZGV2aWNlIHRocm91Z2gNCj4gdGhl
IGNhciBvbiBBQyBwb3dlciB0aHJvdWdoIGEgY29udmVydGVyID8gQXJlIHdlIHdpbGxpbmcgdG8g
aWdub3JlIHRoYXQgY29ybmVyDQo+IGNhc2U/DQoNCk5vLiBBQyBwb3dlciBtZWFucyAibWFpbnMi
IGFuZCBub3QgdGhyb3VnaCBwb3J0YWJsZSBEQyBjb252ZXJ0ZXJzIChzZWUgc2xpZGUgMTIgaW4g
aHR0cHM6Ly9hcHBzLmZjYy5nb3YvZWFzL2NvbW1lbnRzL0dldFB1Ymxpc2hlZERvY3VtZW50Lmh0
bWw/aWQ9MzI3JnRuPSA1MjgxMjIpLiBJdCB3b3VsZCBiZSB1cCB0byB0aGUgdXNlciBzcGFjZSB0
byBpZGVudGlmeSB0aGUgZGV2aWNlIHR5cGUgZXRjLiBhbmQgaWRlbnRpZnkgaWYgdGhpcyBhIHRy
dWx5IEFDIHBvd2VyZWQgQVAuDQoNCj4gDQo+ID4gICAgLSBEZXZpY2UgbXVzdCBiZSB1bmRlciB0
aGUgY29udHJvbCBvZiBhIGxvY2FsIG1hc3RlciB0aGF0IGlzIGFjdGluZw0KPiANCj4gSW50ZXJl
c3RpbmcsIHNvIHNvbWUgQVBJcyB3b3VsZCBiZSBkZWZpbmVkLCBJIHRha2UgaXQgb24gaG9zdGFw
ZCB0byBkbyB0aGUNCj4gcHJvcGVyIGNhbGxiYWNrcyB0byAnc2xhdmUnIHR5cGUgb2YgZGV2aWNl
cyB0aGF0IGRlcGVuZCBvbiB0aGUgbG9jYWwgbWFzdGVyKHMpLiBJDQo+IGNvdWxkIGVudmlzaW9u
IHRoaXMgYmVpbmcgaW1wbGVtZW50ZWQgb24gaG9zdGFwZCBieSBleHBhbmRpbmcgdGhlIEFQDQo+
IGludGVyZmFjZSB0eXBlIGFuZCBhc3NvY2lhdGluZyAnc2xhdmUnIGRldmljZXMgYW5kIGNhbGxi
YWNrcyBmb3IgdXBkYXRlcyBvbiBBUA0KPiBkZXZpY2UgdXBkYXRlcyAoY2hhbm5lbCBjaGFuZ2Vz
LCBhbmQgc28gb24pLiBJcyB0aGlzIHdvcmsgYmVpbmcgcGxhbm5lZD8NCg0KWWVzLiBXZSBoYXZl
IHBsYW5zIHRvIGluY29ycG9yYXRlIG1vcmUgbG9naWMgdG8gaG9zdGFwIChjdXJyZW50bHkgaW50
byB3cGFfc3VwcGxpY2FudCBmb3IgUDJQIHVzZSBjYXNlcykuDQoNCg0K
^ permalink raw reply
* [RFC]: vlan priority handling in WMM
From: voncken @ 2013-07-10 9:29 UTC (permalink / raw)
To: 'Johannes Berg'; +Cc: linux-wireless, netdev-owner
I would like to manage the VLAN priority in Wireless QOS (WMM).
I get the VLAN tag from skb->vlan_tci and I extract the VLAN priority.
How I should handle the priority value 0.
- Handle this value as no priority request, In this case the frame will sent with the DSCP priority or default (Best effort)
- Handle this value as a lowest priority, in this case I Map it to the WMM.
For your information, you can found below a discussion on this point with Johannes Berg.
Regards.
Cedric Voncken.
-----Message d'origine-----
De : Johannes Berg [mailto:johannes@sipsolutions.net]
Envoyé : lundi 8 juillet 2013 14:16
À : voncken
Cc : linux-wireless@vger.kernel.org
Objet : Re: [PATCH V2] vlan priority handling in WMM
On Mon, 2013-07-08 at 12:39 +0200, voncken wrote:
> > > The vlan Tag contain three bit for priority. The value 0 indicate
> no
> > > priority (on this case the VLAN tag contain only VID). The
> vlan_tci
> > > field is set to zero if the frame do not contain the vlan tag. So
> if
> > > we have not a vlan tag or no priority in VLAN tag the priority
> value
> > > is always 0.
>
> > Yes but don't we know that the vlan_tci field is valid?
>
> > I don't think you're correct in that 0 means "no priority present",
> it actually means "best effort" as far as I can tell. Ignoring the
> VLAN tag when the field is 0 would mean we could use a higher priority
> from the contents of the frame, which would not be desired?
>
> I can add a test with the macro vlan_tx_tag_present() to verify if the
> vlan_tci field is valid.
> I test the value 0 to skip the VLAN priority and use the dscp priority
> in this case. The priority 0 in VLAN tag is often use to turn off the
> QOS, because not bit is allowed for it.
What do you mean by "is often used"? I don't see how that would be the case? Are you saying routers commonly ignore the VLAN priority value if it's 0? That would seem odd?
> For me is it correct. Nevertheless, if you prefer, I can test only the
> vlan_tci validity and in this case always use the VLAN priority.
I don't know! Since you don't seem to really know either, we should ask somebody who knows, I think. Maybe you should Cc netdev with this question on the patch or so?
> Sorry I made a mistake 0xE000 >>13 = 0x0007 and not 0x0003, and 7 is
> a 3 bits value.
Ah yes, I made the same mistake, sorry.
johannes
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Luciano Coelho @ 2013-07-10 9:22 UTC (permalink / raw)
To: José Miguel Gonçalves; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <51DCA3EF.8090900@inov.pt>
On Wed, 2013-07-10 at 00:59 +0100, José Miguel Gonçalves wrote:
> Hi Arik,
>
> On 09-07-2013 20:10, Arik Nemtsov wrote:
> > On Tue, Jul 9, 2013 at 4:22 PM, José Miguel Gonçalves
> > <jose.goncalves@inov.pt> wrote:
> >> http://pastebin.com/XmEzqjHs
> >>
> >> The dmesg output with debug mask set to 0x63c20:
> >>
> >> http://pastebin.com/zGE0Gfp8
> >>
> >> Note that with debug activated I did not see the driver's "Beacon loss
> >> detected" messages.
> > You have this line in the log:
> > [ 72.435000] wlan0: deauthenticated from 88:43:e1:57:79:c0 (Reason: 23)
> >
> > This means:
> > Association request rejected because the information in the Power
> > Capability element is
> > unacceptable
Actually, I think this is "IEEE 802.1X authentication failed". This is
the reason_code in the deauth frame. If it were the status_code in the
association response, mac80211 would print "denied association instead".
> > In other words the AP is disconnecting you since your Tx power is
> > inadequate (probably too high?). I'd try to limit it using iw, or just
> > set a different regdomain where its limited.
> > Also I'd try with a different AP.
>
> I think that return code is a bogus caused by the driver debug code,
> because when I remove all the debug I see a different behaviour, i.e.,
> after brief associating with the AP, I see 3 driver messages;
I think this is happening here because of timing. I suspect that the
signal is bad so there are probably lots of retransmissions and with
debugging, things can become so slow that the authentication times out.
IIRC EAP has very strict timing requirements.
> wlcore: Beacon loss detected. roles:0xff
>
> and then receive from wpa_supplicant;
>
> wlan0: CTRL-EVENT-DISCONNECTED bssid=88:43:e1:57:79:c0 reason=4
> locally_generated=1
> wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
> wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="A. Guidance"
> auth_failures=1 duration=10
>
> and I've not make any mistake on the pre-shared key.
>
> Also I've used this AP for tests of different wireless adapters with
> success. Inclusive have use it with the same hardware platform and same
> kernel and sysapps (ifconfig, iw, wpa_supplicant, etc...) and a TP-Link
> TL-WN722N Wi-Fi adapter (ath9k_htc driver) and had no problems in
> associating that adapter.
Still, there may be some interoperability issue with this AP and the
wl127x chip. ;)
I would try with another AP, just to see how things go. Also, I'd try
with an open connection to rule out problems with authentication.
> Can my problems be related with an inadequate NVS file? I've generated
> it with the calibrate tool from ti-utils and the INI file TQS_D_1.7.ini
> with the command "calibrator plt calibrate". Is this the correct INI for
> my module (Jorjin's WG7350 - wl1273 based)?
Yes, the problem can be because of a bad NVS file. Try with the
"default" NVS file that is provided in linux-firmware.git. That one
won't be optimal, but should work okay.
I'm not sure which FEM Jorjin's module use. Can you ask them?
I found this on github (Dick Chiang appears to work for Jorjin):
https://github.com/dickychiang/compat-wireless-r5/blob/master/jorjin/ini_files/TQS_D_1.7_WG7350_NLCP.ini
DISCLAIMER: I have no clue whether this is the correct INI file or not
and I'm not claiming it's associated with TI in any way, so use it at
your own risk.
> Any ideas also why I can not get a complete APs list with the command
> "iw wlan0 scan"? No one as seen this behaviour before?
Many people have seen this kind of behavior and it usually indicates bad
RF performance. ;)
--
Cheers,
Luca.
^ permalink raw reply
* Re:
From: Samuel Ortiz @ 2013-07-10 9:12 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Jeffrey (Sheng-Hui) Chu, linux-wireless@vger.kernel.org
In-Reply-To: <51DC0E91.2020604@broadcom.com>
Hi Arend, Jeffrey,
On Tue, Jul 09, 2013 at 03:22:25PM +0200, Arend van Spriel wrote:
> + Samuel
>
> On 07/08/2013 11:52 PM, Jeffrey (Sheng-Hui) Chu wrote:
> > From b4555081b1d27a31c22abede8e0397f1d61fbb04 Mon Sep 17 00:00:00 2001
> >From: Jeffrey Chu <jeffchu@broadcom.com>
> >Date: Mon, 8 Jul 2013 17:50:21 -0400
> >Subject: [PATCH] Add bcm2079x-i2c driver for Bcm2079x NFC Controller.
>
> The subject did not show in my mailbox. Not sure if necessary, but I
> tend to send patches to a maintainer and CC the appropriate list(s).
> So the nfc list as well (linux-nfc@lists.01.org).
Thanks for cc'ing me. Yes, the NFC maintainers emails and the mailing
list are in the MAINTAINERS file, so I expect people to use them to post
their NFC related patches.
> >---
> > drivers/nfc/Kconfig | 1 +
> > drivers/nfc/Makefile | 1 +
> > drivers/nfc/bcm2079x/Kconfig | 10 +
> > drivers/nfc/bcm2079x/Makefile | 4 +
> > drivers/nfc/bcm2079x/bcm2079x-i2c.c | 416 +++++++++++++++++++++++++++++++++++
> > drivers/nfc/bcm2079x/bcm2079x.h | 34 +++
> > 6 files changed, 466 insertions(+)
> > create mode 100644 drivers/nfc/bcm2079x/Kconfig
> > create mode 100644 drivers/nfc/bcm2079x/Makefile
> > create mode 100644 drivers/nfc/bcm2079x/bcm2079x-i2c.c
> > create mode 100644 drivers/nfc/bcm2079x/bcm2079x.h
Jeffrey, I appreciate the upstreaming effort, but I'm not going to take
this patch. It's designed for Android exclusively and not using any of
the NFC kernel APIs.
In particular, we have a full NCI stack that you could use. There
currently is an SPI transport layer, adding an i2c one would be really
easy.
If you're interested and can spend some cycles on this, I can surely
help you with the kernel APIs and how your driver should look like.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Luciano Coelho @ 2013-07-10 8:48 UTC (permalink / raw)
To: José Miguel Gonçalves; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <51DC0E7C.9080306@inov.pt>
On Tue, 2013-07-09 at 14:22 +0100, José Miguel Gonçalves wrote:
> On 09-07-2013 13:42, Arik Nemtsov wrote:
> > On Tue, Jul 9, 2013 at 2:27 PM, José Miguel Gonçalves
> > <jose.goncalves@inov.pt> wrote:
> >
> >> Any more ideas on how to debug this? Is there any specific debug_level mask
> >> that can apply to the driver to help it?
> > You can try the mask 0x63c20 (it's pretty verbose, so I would put it
> > in pastebin).
> >
> > Perhaps this is a genuine problem with the antenna of the card?
>
> Nope. The AP is 1 meter away form my board (even without antenna in the
> card it should associate).
Too strong a signal can also cause problems, because of distortion.
> > Can
> > you verify the RSSI of the AP is ok using iw?
>
> The iw output:
>
> http://pastebin.com/XmEzqjHs
This looks okay, but the RSSI value cannot be trusted blindly. There
are other factors that can influence the signal quality, such as the
SNR.
> The dmesg output with debug mask set to 0x63c20:
>
> http://pastebin.com/zGE0Gfp8
>
> Note that with debug activated I did not see the driver's "Beacon loss
> detected" messages.
There could be some timing issue here. Is it always like that? Do you
*always* see the "Beacon loss" messages without debugging and *never*
with debugging?
--
Luca.
^ permalink raw reply
* Re: [Ilw] Re: Performance regression in firmware-iwlwifi 0.38~bpo70+1
From: Henrik Ahlgren @ 2013-07-10 7:49 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: Ben Hutchings, Intel Linux Wireless,
debian-backports@lists.debian.org, linux-wireless, Sergey Frolov
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB3019FFDBF@HASMSX103.ger.corp.intel.com>
On Wed, Jul 10, 2013 at 05:32:21AM +0000, Grumbach, Emmanuel wrote:
> Just to make sure I properly understand what you are saying here: only the firmware is changed? Not the driver?
BTW, in my Thinkpad x21e (Intel Wireless-N 1000) I've noticed a very
high (~80%+) CPU utilization by the "irq/42-iwlwifi" kernel process
with the 3.9.x series kernel (self-built from upstream GIT sources)
and 3.10. Not sure in what exact 3.9 version this behaviour
started. I'm using the standard 0.36+wheezy.1 (non-free) version of
firmware-iwlwifi.
^ permalink raw reply
* Re: intel 4965 fails to set channel 12 or 13
From: Stanislaw Gruszka @ 2013-07-10 7:58 UTC (permalink / raw)
To: Hendrik-Jan Heins; +Cc: linux-wireless
In-Reply-To: <CAAU0D9d5XKkRgAexQomR+EqCjpP5ZSf-jYgCgd617vpDum9b+g@mail.gmail.com>
On Tue, Jul 09, 2013 at 08:00:19PM +0200, Hendrik-Jan Heins wrote:
> Frequencies:
> * 2412 MHz [1] (14.0 dBm)
> * 2417 MHz [2] (14.0 dBm)
> * 2422 MHz [3] (14.0 dBm)
> * 2427 MHz [4] (14.0 dBm)
> * 2432 MHz [5] (14.0 dBm)
> * 2437 MHz [6] (14.0 dBm)
> * 2442 MHz [7] (14.0 dBm)
> * 2447 MHz [8] (14.0 dBm)
> * 2452 MHz [9] (14.0 dBm)
> * 2457 MHz [10] (14.0 dBm)
> * 2462 MHz [11] (14.0 dBm)
> Bitrates (non-HT):
Your device does not support channels 12 & 13. This limit is coded
in device EEPROM. Is not possible to workaround that in driver or
user space, as (closed source) firmware will force EEPROM regulatory
limits.
Stanislaw
^ permalink raw reply
* RE: [Ilw] Re: Performance regression in firmware-iwlwifi 0.38~bpo70+1
From: Grumbach, Emmanuel @ 2013-07-10 7:53 UTC (permalink / raw)
To: Henrik Ahlgren
Cc: Ben Hutchings, Intel Linux Wireless,
debian-backports@lists.debian.org, linux-wireless, Sergey Frolov
In-Reply-To: <20130710074930.GE11186@seestieto.com>
> > Just to make sure I properly understand what you are saying here: only the
> firmware is changed? Not the driver?
>
> BTW, in my Thinkpad x21e (Intel Wireless-N 1000) I've noticed a very
> high (~80%+) CPU utilization by the "irq/42-iwlwifi" kernel process
> with the 3.9.x series kernel (self-built from upstream GIT sources)
> and 3.10. Not sure in what exact 3.9 version this behaviour
> started. I'm using the standard 0.36+wheezy.1 (non-free) version of
> firmware-iwlwifi.
For CPU utilization:
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi.git/commit/?id=01911dab97cb3e21e640aaca82689acec00ed848
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/iwlwifi.git/commit/?id=68972c46f2975d3d61f9dc9f311f77bfc8a8b12b
^ permalink raw reply
* [PATCH 2/2] ath9k_htc: reboot firmware if it was loaded
From: Oleksij Rempel @ 2013-07-10 6:40 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Oleksij Rempel
In-Reply-To: <1373438404-5871-1-git-send-email-linux@rempel-privat.de>
Currently ath9k_htc will reboot firmware only if interface was
ever started. Which lead to the problem in case where interface
was never started but module need to be reloaded.
This patch will partially fix bug "ath9k_htc: Target is unresponsive"
https://github.com/qca/open-ath9k-htc-firmware/issues/1
Reproduction case:
- plug adapter
- make sure nothing will touch it. Stop Networkmanager or blacklist mac address of this adapter.
- rmmod ath9k_htc; sleep 1; modprobe ath9k_htc
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 2469db5..5205a36 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1295,7 +1295,9 @@ static void ath9k_hif_usb_disconnect(struct usb_interface *interface)
usb_set_intfdata(interface, NULL);
- if (!unplugged && (hif_dev->flags & HIF_USB_START))
+ /* If firmware was loaded we should drop it
+ * go back to first stage bootloader. */
+ if (!unplugged && (hif_dev->flags & HIF_USB_READY))
ath9k_hif_usb_reboot(udev);
kfree(hif_dev);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/2] ath9k_htc: do some initial hardware configuration
From: Oleksij Rempel @ 2013-07-10 6:40 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Oleksij Rempel
Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.
This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.
Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 71a183f..c3676bf 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -861,6 +861,7 @@ static int ath9k_init_device(struct ath9k_htc_priv *priv,
if (error != 0)
goto err_rx;
+ ath9k_hw_disable(priv->ah);
#ifdef CONFIG_MAC80211_LEDS
/* must be initialized before ieee80211_register_hw */
priv->led_cdev.default_trigger = ieee80211_create_tpt_led_trigger(priv->hw,
--
1.8.1.2
^ permalink raw reply related
* Re: [Ilw] Re: Slow throughput on Ultimate-N 6300
From: Steve Freitas @ 2013-07-10 5:56 UTC (permalink / raw)
To: Grumbach, Emmanuel; +Cc: ilw@linux.intel.com, linux-wireless@vger.kernel.org
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB3019FFE28@HASMSX103.ger.corp.intel.com>
Wonderful, thank you for the tips. I'll wade back into it tomorrow or
the next day and let you know what I find.
Thank you,
Steve
On 07/09/13 22:55, Grumbach, Emmanuel wrote:
>> Emmanuel,
>>
>> Thank you for your quick response!
>>
>> It is a regression. I regularly had 300 Mbps speeds on this very access point,
>> but it was years ago, in the 2.6 kernel series. However, I believe, from
>> extensive online searches, that Intel has disabled the N functionality in the
>> firmware on Linux, ostensibly until they (you? :-)
>> ) can fix whatever problem they were seeing. With the demise of the Intel
>> Linux Wireless bug tracker, though, public tracking of the bug has been
>> impossible. There are now-dead links to the defunct bug tracker over this
>> very issue.
>>
> 11n hasn't been disabled in firmware, but rather in driver.
> There is a bug we know about the "fail to flush tx fifo" thing that people reports (through mailing list or bugzilla of RedHat).
> Can you please send the output of the kerne log (dmesg)?
>
>> Sadly I only get 2 MByte/s on N, and under 1 MByte/s G.
>>
>> I have not tried another access point in ages. Tired of replacing fried Netgears
>> and Dlinks and Belkins, I've converted all my friends and families to Apple's
>> access points. I'll try to locate something else and see how it goes.
> No need to. If you say that it worked, then it should still work. The issue I was thinking is the way they use some fancy feature of WiFi that no one implements (besides the wifi module of their devices of course).
> Also, can you please try different firmwares from http://wireless.kernel.org/en/users/Drivers/iwlwifi#Download ?
> I wonder if newer firmware has made things worse. You may want to try older firmware.
> To do so, open the tarball from that you'll download and copy iwlwifi-*.ucode to /lib/firmware.
^ 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