* Re: [PATCH][RESEND] ath9k: Fix ath_print in xmit for hardware reset.
From: Justin P. Mattock @ 2010-05-26 18:07 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, arnd, linux-wireless
In-Reply-To: <AANLkTilII7C41BTshkXyCmAU81LQ3fJF0ogq_BLVv6w-@mail.gmail.com>
On 05/26/2010 11:02 AM, Luis R. Rodriguez wrote:
> On Wed, May 26, 2010 at 11:00 AM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>
>> ath_print in xmit.c should say "Reseting hardware"
>> instead of Resetting HAL!(since HAL is being fazed out).
>> dmesg shows:
>> [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
>>
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>
>>
> For next time, no need for extra spaces between the SOB and the ---.
> And instead of RESEND do [PATCH v2]. Please read:
>
> http://wireless.kernel.org/en/developers/Documentation/git-guide
>
>
o.k.!!
>> ---
>> drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
>> index 3db1917..09cb13c 100644
>> --- a/drivers/net/wireless/ath/ath9k/xmit.c
>> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
>> @@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
>> int r;
>>
>> ath_print(common, ATH_DBG_FATAL,
>> - "Unable to stop TxDMA. Reset HAL!\n");
>> + "Failed to stop TX DMA. Resetting hardware!\n");
>>
>> spin_lock_bh(&sc->sc_resetlock);
>> r = ath9k_hw_reset(ah, sc->sc_ah->curchan, false);
>>
> Thanks, this is good.
>
> Luis
>
>
what about all the signed-off's? should I
resend with all of those, or no?
Justin P. Mattock
^ permalink raw reply
* [PATCH][RESEND] ath9k: Fix ath_print in xmit for hardware reset.
From: Justin P. Mattock @ 2010-05-26 18:00 UTC (permalink / raw)
To: linville; +Cc: arnd, linux-wireless, mcgrof, Justin P. Mattock
ath_print in xmit.c should say "Reseting hardware"
instead of Resetting HAL!(since HAL is being fazed out).
dmesg shows:
[ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 3db1917..09cb13c 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
int r;
ath_print(common, ATH_DBG_FATAL,
- "Unable to stop TxDMA. Reset HAL!\n");
+ "Failed to stop TX DMA. Resetting hardware!\n");
spin_lock_bh(&sc->sc_resetlock);
r = ath9k_hw_reset(ah, sc->sc_ah->curchan, false);
--
1.6.5.GIT
^ permalink raw reply related
* Re: [PATCH] ath9k: Fix ath_print in xmit for harware reset.
From: Luis R. Rodriguez @ 2010-05-26 18:03 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linville, arnd, linux-wireless
In-Reply-To: <4BFD620B.8010301@gmail.com>
On Wed, May 26, 2010 at 11:01 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> On 05/26/2010 10:50 AM, Luis R. Rodriguez wrote:
>>
>> On Wed, May 26, 2010 at 10:46 AM, Justin P. Mattock
>> <justinmattock@gmail.com> wrote:
>>
>>>
>>> ath_print in xmit.c should say "Reseting hardware"
>>> instead of Resetting HAL!(since HAL is being fazed out).
>>> dmesg shows:
>>> [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last
>>> frame
>>> [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
>>>
>>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>>
>>> ---
>>> drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
>>> b/drivers/net/wireless/ath/ath9k/xmit.c
>>> index 3db1917..617db8e 100644
>>> --- a/drivers/net/wireless/ath/ath9k/xmit.c
>>> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
>>> @@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool
>>> retry_tx)
>>> int r;
>>>
>>> ath_print(common, ATH_DBG_FATAL,
>>> - "Unable to stop TxDMA. Reset HAL!\n");
>>> + "ath9k: Failed to stop TX DMA. Resetting
>>> hardware!\n");
>>>
>>
>> Nack, No need to put "ath9k:" since ath_print already prepends "ath: "
>>
>> Luis
>>
>>
>
> ah.. so the ATH_DBG_FATAL takes care of that?
> resent..
No FATAL just makes sure it prints all the time, even if you do not
have debugging enabled. Go read ath_print() though.
Luis
^ permalink raw reply
* Re: [PATCH][RESEND] ath9k: Fix ath_print in xmit for hardware reset.
From: Luis R. Rodriguez @ 2010-05-26 18:02 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linville, arnd, linux-wireless
In-Reply-To: <1274896804-19441-1-git-send-email-justinmattock@gmail.com>
On Wed, May 26, 2010 at 11:00 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> ath_print in xmit.c should say "Reseting hardware"
> instead of Resetting HAL!(since HAL is being fazed out).
> dmesg shows:
> [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
> [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
For next time, no need for extra spaces between the SOB and the ---.
And instead of RESEND do [PATCH v2]. Please read:
http://wireless.kernel.org/en/developers/Documentation/git-guide
> ---
> drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
> index 3db1917..09cb13c 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
> int r;
>
> ath_print(common, ATH_DBG_FATAL,
> - "Unable to stop TxDMA. Reset HAL!\n");
> + "Failed to stop TX DMA. Resetting hardware!\n");
>
> spin_lock_bh(&sc->sc_resetlock);
> r = ath9k_hw_reset(ah, sc->sc_ah->curchan, false);
Thanks, this is good.
Luis
^ permalink raw reply
* Re: [PATCH] ath9k: Fix ath_print in xmit for harware reset.
From: Justin P. Mattock @ 2010-05-26 18:01 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, arnd, linux-wireless
In-Reply-To: <AANLkTimrFUYIkTQ7ev-AL0V8y0Lot064h8JK_fU81Lyr@mail.gmail.com>
On 05/26/2010 10:50 AM, Luis R. Rodriguez wrote:
> On Wed, May 26, 2010 at 10:46 AM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>
>> ath_print in xmit.c should say "Reseting hardware"
>> instead of Resetting HAL!(since HAL is being fazed out).
>> dmesg shows:
>> [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
>>
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>
>> ---
>> drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
>> index 3db1917..617db8e 100644
>> --- a/drivers/net/wireless/ath/ath9k/xmit.c
>> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
>> @@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
>> int r;
>>
>> ath_print(common, ATH_DBG_FATAL,
>> - "Unable to stop TxDMA. Reset HAL!\n");
>> + "ath9k: Failed to stop TX DMA. Resetting hardware!\n");
>>
> Nack, No need to put "ath9k:" since ath_print already prepends "ath: "
>
> Luis
>
>
ah.. so the ATH_DBG_FATAL takes care of that?
resent..
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH] rt2x00: do not shortcut rt2x00lib_config_antenna
From: Ivo Van Doorn @ 2010-05-26 17:53 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, gwingerde
In-Reply-To: <1274895211-11438-1-git-send-email-linville@tuxdriver.com>
On Wed, May 26, 2010 at 7:33 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> This function was exiting early if the existing diversity settings
> were unchanged. Unfortunately, in some cases the antenna configuration
> is not initialized at all.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=14751
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> Cc: Ivo van Doorn <IvDoorn@gmail.com>
> Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2x00config.c | 8 --------
> 1 files changed, 0 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c b/drivers/net/wireless/rt2x00/rt2x00config.c
> index 098315a..14a817d 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00config.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00config.c
> @@ -124,11 +124,6 @@ void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
> * ANTENNA_SW_DIVERSITY state to the driver.
> * If that happens, fallback to hardware defaults,
> * or our own default.
> - * If diversity handling is active for a particular antenna,
> - * we shouldn't overwrite that antenna.
> - * The calls to rt2x00lib_config_antenna_check()
> - * might have caused that we restore back to the already
> - * active setting. If that has happened we can quit.
> */
> if (!(ant->flags & ANTENNA_RX_DIVERSITY))
> config.rx = rt2x00lib_config_antenna_check(config.rx, def->rx);
> @@ -140,9 +135,6 @@ void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
> else
> config.tx = active->tx;
>
> - if (config.rx == active->rx && config.tx == active->tx)
> - return;
> -
> /*
> * Antenna setup changes require the RX to be disabled,
> * else the changes will be ignored by the device.
> --
> 1.6.6.1
>
>
^ permalink raw reply
* RE: [RFC] wireless-regdb: Add A band in IL
From: Grumbach, Emmanuel @ 2010-05-26 17:51 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
Michael Green, David Quan
In-Reply-To: <AANLkTinG2zWHE8l-ZPBnyrFq5gs4nZX59zhF3AVh7h_4@mail.gmail.com>
Pk9uIFdlZCwgTWF5IDI2LCAyMDEwIGF0IDEwOjMyIEFNLCBHcnVtYmFjaCwgRW1tYW51ZWwNCj48
ZW1tYW51ZWwuZ3J1bWJhY2hAaW50ZWwuY29tPiB3cm90ZToNCj4+Pj4gwqBjb3VudHJ5IElMOg0K
Pj4+PiDCoCDCoCDCoCDCoCgyNDAyIC0gMjQ4MiBAIDQwKSwgKE4vQSwgMjApDQo+Pj4+ICsgwqAg
wqAgwqAgKDUxNTAgLSA1MjUwIEAgNDApLiAoTi9BLCAyMDAgbVcpLCBOTy1PVVRET09SDQo+Pj4+
ICsgwqAgwqAgwqAgKDUyNTAgLSA1MzUwIEAgNDApLiAoTi9BLCAyMDAgbVcpLCBOTy1PVVRET09S
LCBERlMNCj4+Pg0KPj4+SSBiZWxpZXZlIHRoZSBvbmUgc3RhbmRpbmcgaXNzdWUgaGVyZSBpcyB5
b3UgYXJlIGVuYWJsaW5nIEhUNDAgb24gNQ0KPj4+R0h6LCBob3cgYWJvdXQgZW5hYmxpbmcgMi40
IEdIeiBmaXJzdCwgYW5kIHRoZW4gdGhyb3VnaCBhIHNlcGFyYXRlDQo+Pj5wYXRjaCBhbmQgdGlt
ZS9yZXZpZXcgd2UgcmV2aWV3IHRoZSBIVDQwIHN0dWZmLCB1bmxlc3MgeW91IGFyZSBpbiBubw0K
Pj4+cnVzaCB0byBnZXQgMi40IEdIeiBlbmFibGVkLg0KPj4+DQo+Pg0KPj4gSSBhbSBub3QgZm9s
bG93aW5nLi4uIEhUNDAgb24gMi40IEdIeiBpcyBhbHJlYWR5IGVuYWJsZWQuLi4NCj4+IFdoYXQg
c2hvdWxkIEkgZW5hYmxlIGluIDIuNCBHSHogPw0KPg0KPlNvcnJ5IEkgbWVhbnQgNSBHSHouDQoN
CkFjdHVhbGx5IDQwR0h6IGlzIGxlc3MgYSBwcm9ibGVtIGluIDVHSHogdGhhbiBpbiAyLjRHSHog
c2luY2UgaW4gMi40R0h6DQpJIG5lZWQgdG8gaGF2ZSBhICJDb2V4aXN0ZW5jZSBtZWNoYW5pc20i
LCB3aGljaCBpcyBub3QgcmVxdWlyZWQgaW4gNUdIei4NClRoaXMgQ29leGlzdGVuY2UgbWVjaGFu
aXNtIGlzIGFwcGFyZW50bHkgaW1wbGVtZW50ZWQgYnkgb25lIE9FTSB1bmRlciB0aGUNCm5hbWUg
IkNsZWFyIENoYW5uZWwgQXNzZXNzbWVudCAoQ0NBKSIuDQoNCkluIHNob3J0LCBJIGRvbid0IHRo
aW5rIHRoZXJlIGlzIGFueSBzcGVjaWFsIGlzc3VlIHdpdGggNDBNSHogaW4gNUdIeiwgYnV0DQpJ
IG1heSBtaXNzIHNvbWV0aGluZyBoZXJlLi4uIEluIGFueSBjYXNlLCBJIGhhdmUgbm8gcHJvYmxl
bSB3aXRoIHNlbmRpbmcNCmEgcGF0Y2ggdGhhdCBhbGxvd3MgNUdIeiBpbiAyME1IeiBmb3IgdGhl
IG1vbWVudC4NCkkgY2FuIGFsc28gaGF2ZSBhIGxvb2sgYXQgdGhlIEVFUFJPTSBpbiBvdXIgTklD
cyB3aGljaCBpcyBzdXBwb3NlZCB0byBoYXZlDQphbGwgdGhlIG5lZWRlZCBsaW1pdGF0aW9ucy4g
RGV0YWlscyB0byBmb2xsb3cgdG9tb3Jyb3cuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KSW50ZWwgSXNyYWVsICg3
NCkgTGltaXRlZAoKVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj
b25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVj
aXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbgpieSBvdGhlcnMgaXMgc3RyaWN0
bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCwgcGxl
YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuCg==
^ permalink raw reply
* Re: [PATCH] ath9k: Fix ath_print in xmit for harware reset.
From: Luis R. Rodriguez @ 2010-05-26 17:50 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linville, arnd, linux-wireless
In-Reply-To: <1274896002-10866-1-git-send-email-justinmattock@gmail.com>
On Wed, May 26, 2010 at 10:46 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> ath_print in xmit.c should say "Reseting hardware"
> instead of Resetting HAL!(since HAL is being fazed out).
> dmesg shows:
> [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
> [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
> index 3db1917..617db8e 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
> int r;
>
> ath_print(common, ATH_DBG_FATAL,
> - "Unable to stop TxDMA. Reset HAL!\n");
> + "ath9k: Failed to stop TX DMA. Resetting hardware!\n");
Nack, No need to put "ath9k:" since ath_print already prepends "ath: "
Luis
^ permalink raw reply
* Re: [PATCH]wireless:ath9k Fix ath_print in xmit.c
From: Justin P. Mattock @ 2010-05-26 17:49 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: linux-wireless, linville, mcgrof
In-Reply-To: <4BFD5A49.4050601@arndnet.de>
On 05/26/2010 10:28 AM, Arnd Hannemann wrote:
> Am 26.05.2010 19:14, schrieb Justin P. Mattock:
>
>> ath_print in xmit.c should say "Reseting hardware"
>> instead of Reaseting HAL!(since HAL is being fazed out).
>> dmesg shows:
>> [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
>> [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
>>
>>
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>
>> ---
>> drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
>> index 3db1917..2a0558e 100644
>> --- a/drivers/net/wireless/ath/ath9k/xmit.c
>> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
>> @@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
>> int r;
>>
>> ath_print(common, ATH_DBG_FATAL,
>> - "Unable to stop TxDMA. Reset HAL!\n");
>> + "Unable to stop TxDMA. Reseting hardware!\n");
>>
>>
> 1.) Should'nt it read "Resetting"
> 2.) Why "common" ? Seems it is ath9k specific so message should read
> "ath9k: Failed to stop TX DMA"
> 3.) While we are at it write "TX DMA" instead of "TxDMA" just to be
> consistent...
>
pretty bad!! I cant spell.
>>
>> spin_lock_bh(&sc->sc_resetlock);
>> r = ath9k_hw_reset(ah, sc->sc_ah->curchan, false);
>>
>>
> Best regards,
> Arnd
>
>
>
o.k. re-submitted, with the above fixes, if good
let me know..(a bit confused with the signed off
stuff(if I need to re-du to add the correct signed-off's
let me know))
Justin P. mattock
^ permalink raw reply
* Re: [PATCH]wireless:ath9k Fix ath_print in xmit.c
From: Arnd Hannemann @ 2010-05-26 17:28 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-wireless, linville, mcgrof
In-Reply-To: <1274894056-2866-1-git-send-email-justinmattock@gmail.com>
Am 26.05.2010 19:14, schrieb Justin P. Mattock:
> ath_print in xmit.c should say "Reseting hardware"
> instead of Reaseting HAL!(since HAL is being fazed out).
> dmesg shows:
> [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
> [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
>
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
> index 3db1917..2a0558e 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
> int r;
>
> ath_print(common, ATH_DBG_FATAL,
> - "Unable to stop TxDMA. Reset HAL!\n");
> + "Unable to stop TxDMA. Reseting hardware!\n");
>
1.) Should'nt it read "Resetting"
2.) Why "common" ? Seems it is ath9k specific so message should read
"ath9k: Failed to stop TX DMA"
3.) While we are at it write "TX DMA" instead of "TxDMA" just to be
consistent...
>
> spin_lock_bh(&sc->sc_resetlock);
> r = ath9k_hw_reset(ah, sc->sc_ah->curchan, false);
>
Best regards,
Arnd
^ permalink raw reply
* [PATCH] ath9k: Fix ath_print in xmit for harware reset.
From: Justin P. Mattock @ 2010-05-26 17:46 UTC (permalink / raw)
To: linville; +Cc: arnd, linux-wireless, mcgrof, Justin P. Mattock
ath_print in xmit.c should say "Reseting hardware"
instead of Resetting HAL!(since HAL is being fazed out).
dmesg shows:
[ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 3db1917..617db8e 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
int r;
ath_print(common, ATH_DBG_FATAL,
- "Unable to stop TxDMA. Reset HAL!\n");
+ "ath9k: Failed to stop TX DMA. Resetting hardware!\n");
spin_lock_bh(&sc->sc_resetlock);
r = ath9k_hw_reset(ah, sc->sc_ah->curchan, false);
--
1.6.5.GIT
^ permalink raw reply related
* Re: [RFC] wireless-regdb: Add A band in IL
From: Luis R. Rodriguez @ 2010-05-26 17:46 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
Michael Green, David Quan
In-Reply-To: <4825B8A2C4E264489E57869F0DCFB22343E33E611F@hasmsx502.ger.corp.intel.com>
On Wed, May 26, 2010 at 10:32 AM, Grumbach, Emmanuel
<emmanuel.grumbach@intel.com> wrote:
>>> country IL:
>>> (2402 - 2482 @ 40), (N/A, 20)
>>> + (5150 - 5250 @ 40). (N/A, 200 mW), NO-OUTDOOR
>>> + (5250 - 5350 @ 40). (N/A, 200 mW), NO-OUTDOOR, DFS
>>
>>I believe the one standing issue here is you are enabling HT40 on 5
>>GHz, how about enabling 2.4 GHz first, and then through a separate
>>patch and time/review we review the HT40 stuff, unless you are in no
>>rush to get 2.4 GHz enabled.
>>
>
> I am not following... HT40 on 2.4 GHz is already enabled...
> What should I enable in 2.4 GHz ?
Sorry I meant 5 GHz.
Luis
^ permalink raw reply
* Re: regulatory problems with ath5k
From: Luis R. Rodriguez @ 2010-05-26 17:45 UTC (permalink / raw)
To: Arnd Hannemann
Cc: linux-wireless@vger.kernel.org, ath5k-devel@lists.ath5k.org
In-Reply-To: <4BFD555C.4060205@nets.rwth-aachen.de>
On Wed, May 26, 2010 at 10:07 AM, Arnd Hannemann
<hannemann@nets.rwth-aachen.de> wrote:
> Hi,
>
> FWI: I believe this whole regulatory framework is pretty broken in 2.6.34
> If I associate with a 802.11g accesspoint with one NIC , I'm not allowed
> to use 802.11a on my other NIC at all.
>
> [ 23.352168] wlan0: associated
> [ 23.355993] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 23.375106] cfg80211: Calling CRDA for country: DE
> [ 23.412542] cfg80211: Current regulatory domain updated by AP to: DE
> [ 23.431728] (start_freq - end_freq @ bandwidth),
> (max_antenna_gain, max_eirp)
> [ 23.454319] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 1800 mBm)
>
> # iw reg get
> country 98:
> (2402 - 2482 @ 40), (N/A, 18)
>
> ???
No, although that may be your regulatory domain cfg80211 will not
disable 5 GHz if you already had it enabled and your AP provided a
country IE with only 2 GHz rules. Check 'iw list' both before and
after you associate.
Luis
^ permalink raw reply
* [PATCH] rt2x00: do not shortcut rt2x00lib_config_antenna
From: John W. Linville @ 2010-05-26 17:33 UTC (permalink / raw)
To: linux-wireless; +Cc: ivdoorn, gwingerde, John W. Linville, Ivo van Doorn
This function was exiting early if the existing diversity settings
were unchanged. Unfortunately, in some cases the antenna configuration
is not initialized at all.
https://bugzilla.kernel.org/show_bug.cgi?id=14751
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
---
drivers/net/wireless/rt2x00/rt2x00config.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c b/drivers/net/wireless/rt2x00/rt2x00config.c
index 098315a..14a817d 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/rt2x00/rt2x00config.c
@@ -124,11 +124,6 @@ void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
* ANTENNA_SW_DIVERSITY state to the driver.
* If that happens, fallback to hardware defaults,
* or our own default.
- * If diversity handling is active for a particular antenna,
- * we shouldn't overwrite that antenna.
- * The calls to rt2x00lib_config_antenna_check()
- * might have caused that we restore back to the already
- * active setting. If that has happened we can quit.
*/
if (!(ant->flags & ANTENNA_RX_DIVERSITY))
config.rx = rt2x00lib_config_antenna_check(config.rx, def->rx);
@@ -140,9 +135,6 @@ void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
else
config.tx = active->tx;
- if (config.rx == active->rx && config.tx == active->tx)
- return;
-
/*
* Antenna setup changes require the RX to be disabled,
* else the changes will be ignored by the device.
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH]wireless:ath9k Disable leds for Apple products.
From: Justin P. Mattock @ 2010-05-26 17:38 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, mcgrof
In-Reply-To: <20100526171844.GB5823@tuxdriver.com>
On 05/26/2010 10:18 AM, John W. Linville wrote:
> On Wed, May 26, 2010 at 10:14:16AM -0700, Justin P. Mattock wrote:
>
>> Disable the leds on ath9k for Apple products, since
>> there is no leds on any of there machines(or non that I can find!!).
>>
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>
>>
>
>> void ath_init_leds(struct ath_softc *sc)
>> {
>> char *trigger;
>> int ret;
>>
>> + /* Apple has no leds lights for their wireless. */
>> + if (dmi_check_system(dmi_system_table)> 0)
>> + return -ENODEV;
>> + else
>> +
>> if (AR_SREV_9287(sc->sc_ah))
>> sc->sc_ah->led_pin = ATH_LED_PIN_9287;
>> else
>>
> Surely we don't need the 'else'.
>
> Does enabling the LEDs on these systems cause any problems?
>
> John
>
I picked up the idea, from this patch:
http://kerneltrap.org/mailarchive/linux-kernel/2010/1/20/4530535
while looking into a bug for ath9k(thinking maybe leds
are causing something, which want the case)
so Id have to say I don't think the leds cause issue's,
if anything just a wasted symlink, call, or whatever
in /sys/class/leds/*
Justin P. mattock
^ permalink raw reply
* RE: [RFC] wireless-regdb: Add A band in IL
From: Grumbach, Emmanuel @ 2010-05-26 17:32 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
Michael Green, David Quan
In-Reply-To: <AANLkTikzEywcDi9zyJknMWkKymCVYnWQa2YXbbSDVx5o@mail.gmail.com>
Pj4gwqBjb3VudHJ5IElMOg0KPj4gwqAgwqAgwqAgwqAoMjQwMiAtIDI0ODIgQCA0MCksIChOL0Es
IDIwKQ0KPj4gKyDCoCDCoCDCoCAoNTE1MCAtIDUyNTAgQCA0MCkuIChOL0EsIDIwMCBtVyksIE5P
LU9VVERPT1INCj4+ICsgwqAgwqAgwqAgKDUyNTAgLSA1MzUwIEAgNDApLiAoTi9BLCAyMDAgbVcp
LCBOTy1PVVRET09SLCBERlMNCj4NCj5JIGJlbGlldmUgdGhlIG9uZSBzdGFuZGluZyBpc3N1ZSBo
ZXJlIGlzIHlvdSBhcmUgZW5hYmxpbmcgSFQ0MCBvbiA1DQo+R0h6LCBob3cgYWJvdXQgZW5hYmxp
bmcgMi40IEdIeiBmaXJzdCwgYW5kIHRoZW4gdGhyb3VnaCBhIHNlcGFyYXRlDQo+cGF0Y2ggYW5k
IHRpbWUvcmV2aWV3IHdlIHJldmlldyB0aGUgSFQ0MCBzdHVmZiwgdW5sZXNzIHlvdSBhcmUgaW4g
bm8NCj5ydXNoIHRvIGdldCAyLjQgR0h6IGVuYWJsZWQuDQo+DQoNCkkgYW0gbm90IGZvbGxvd2lu
Zy4uLiBIVDQwIG9uIDIuNCBHSHogaXMgYWxyZWFkeSBlbmFibGVkLi4uDQpXaGF0IHNob3VsZCBJ
IGVuYWJsZSBpbiAyLjQgR0h6ID8NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpJbnRlbCBJc3JhZWwgKDc0KSBMaW1p
dGVkCgpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu
dGlhbCBtYXRlcmlhbCBmb3IKdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQo
cykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uCmJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o
aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50LCBwbGVhc2UgY29u
dGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4K
^ permalink raw reply
* Re: regulatory problems with ath5k
From: Arnd Hannemann @ 2010-05-26 17:07 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: ath5k-devel@lists.ath5k.org
In-Reply-To: <4BFD04A4.4000403@nets.rwth-aachen.de>
Hi,
FWI: I believe this whole regulatory framework is pretty broken in 2.6.34
If I associate with a 802.11g accesspoint with one NIC , I'm not allowed
to use 802.11a on my other NIC at all.
[ 23.352168] wlan0: associated
[ 23.355993] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 23.375106] cfg80211: Calling CRDA for country: DE
[ 23.412542] cfg80211: Current regulatory domain updated by AP to: DE
[ 23.431728] (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 23.454319] (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 1800 mBm)
# iw reg get
country 98:
(2402 - 2482 @ 40), (N/A, 18)
???
Best regards,
Arnd
^ permalink raw reply
* Re: [PATCH]wireless:ath9k Disable leds for Apple products.
From: John W. Linville @ 2010-05-26 17:18 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-wireless, mcgrof
In-Reply-To: <1274894056-2866-2-git-send-email-justinmattock@gmail.com>
On Wed, May 26, 2010 at 10:14:16AM -0700, Justin P. Mattock wrote:
> Disable the leds on ath9k for Apple products, since
> there is no leds on any of there machines(or non that I can find!!).
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> void ath_init_leds(struct ath_softc *sc)
> {
> char *trigger;
> int ret;
>
> + /* Apple has no leds lights for their wireless. */
> + if (dmi_check_system(dmi_system_table) > 0)
> + return -ENODEV;
> + else
> +
> if (AR_SREV_9287(sc->sc_ah))
> sc->sc_ah->led_pin = ATH_LED_PIN_9287;
> else
Surely we don't need the 'else'.
Does enabling the LEDs on these systems cause any problems?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH]wireless:ath9k Disable leds for Apple products.
From: Luis R. Rodriguez @ 2010-05-26 17:19 UTC (permalink / raw)
To: Justin P. Mattock, David Quan, Vinod Nagarajan; +Cc: linux-wireless, linville
In-Reply-To: <1274894056-2866-2-git-send-email-justinmattock@gmail.com>
Note: This e-mail is on a public mailing list.
David, Vinod, is it true, no Apple devices have LEDs?
On Wed, May 26, 2010 at 10:14 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> Disable the leds on ath9k for Apple products, since
> there is no leds on any of there machines(or non that I can find!!).
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> drivers/net/wireless/ath/ath9k/gpio.c | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/gpio.c b/drivers/net/wireless/ath/ath9k/gpio.c
> index 0ee75e7..c21e74f 100644
> --- a/drivers/net/wireless/ath/ath9k/gpio.c
> +++ b/drivers/net/wireless/ath/ath9k/gpio.c
> @@ -15,6 +15,7 @@
> */
>
> #include "ath9k.h"
> +#include <linux/dmi.h>
>
> /********************************/
> /* LED functions */
> @@ -127,11 +128,30 @@ void ath_deinit_leds(struct ath_softc *sc)
> ath9k_hw_set_gpio(sc->sc_ah, sc->sc_ah->led_pin, 1);
> }
>
> +static struct dmi_system_id __initdata dmi_system_table[] = {
> + {
> + .matches = {
> + DMI_MATCH(DMI_BIOS_VENDOR, "Apple Computer, Inc.")
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_BIOS_VENDOR, "Apple Inc.")
> + },
> + },
> + {}
> +};
> +
> void ath_init_leds(struct ath_softc *sc)
> {
> char *trigger;
> int ret;
>
> + /* Apple has no leds lights for their wireless. */
> + if (dmi_check_system(dmi_system_table) > 0)
> + return -ENODEV;
> + else
> +
> if (AR_SREV_9287(sc->sc_ah))
> sc->sc_ah->led_pin = ATH_LED_PIN_9287;
> else
> --
> 1.6.5.GIT
>
>
^ permalink raw reply
* Re: [PATCH]wireless:ath9k Fix ath_print in xmit.c
From: Luis R. Rodriguez @ 2010-05-26 17:16 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-wireless, linville
In-Reply-To: <1274894056-2866-1-git-send-email-justinmattock@gmail.com>
Subject should just be
ath9k: Fix ath_print in xmit for hardware reset
On Wed, May 26, 2010 at 10:14 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> ath_print in xmit.c should say "Reseting hardware"
> instead of Reaseting HAL!(since HAL is being fazed out).
> dmesg shows:
> [ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
> [ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
>
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Looks good. You want to address patches To john, and cc the rest.
> ---
> drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
> index 3db1917..2a0558e 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
> int r;
>
> ath_print(common, ATH_DBG_FATAL,
> - "Unable to stop TxDMA. Reset HAL!\n");
> + "Unable to stop TxDMA. Reseting hardware!\n");
>
> spin_lock_bh(&sc->sc_resetlock);
> r = ath9k_hw_reset(ah, sc->sc_ah->curchan, false);
> --
> 1.6.5.GIT
>
>
^ permalink raw reply
* [PATCH]wireless:ath9k Disable leds for Apple products.
From: Justin P. Mattock @ 2010-05-26 17:14 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, mcgrof, Justin P. Mattock
In-Reply-To: <1274894056-2866-1-git-send-email-justinmattock@gmail.com>
Disable the leds on ath9k for Apple products, since
there is no leds on any of there machines(or non that I can find!!).
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/net/wireless/ath/ath9k/gpio.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/gpio.c b/drivers/net/wireless/ath/ath9k/gpio.c
index 0ee75e7..c21e74f 100644
--- a/drivers/net/wireless/ath/ath9k/gpio.c
+++ b/drivers/net/wireless/ath/ath9k/gpio.c
@@ -15,6 +15,7 @@
*/
#include "ath9k.h"
+#include <linux/dmi.h>
/********************************/
/* LED functions */
@@ -127,11 +128,30 @@ void ath_deinit_leds(struct ath_softc *sc)
ath9k_hw_set_gpio(sc->sc_ah, sc->sc_ah->led_pin, 1);
}
+static struct dmi_system_id __initdata dmi_system_table[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_BIOS_VENDOR, "Apple Computer, Inc.")
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BIOS_VENDOR, "Apple Inc.")
+ },
+ },
+ {}
+};
+
void ath_init_leds(struct ath_softc *sc)
{
char *trigger;
int ret;
+ /* Apple has no leds lights for their wireless. */
+ if (dmi_check_system(dmi_system_table) > 0)
+ return -ENODEV;
+ else
+
if (AR_SREV_9287(sc->sc_ah))
sc->sc_ah->led_pin = ATH_LED_PIN_9287;
else
--
1.6.5.GIT
^ permalink raw reply related
* [PATCH]wireless:ath9k Fix ath_print in xmit.c
From: Justin P. Mattock @ 2010-05-26 17:14 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, mcgrof, Justin P. Mattock
ath_print in xmit.c should say "Reseting hardware"
instead of Reaseting HAL!(since HAL is being fazed out).
dmesg shows:
[ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 3db1917..2a0558e 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1198,7 +1198,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
int r;
ath_print(common, ATH_DBG_FATAL,
- "Unable to stop TxDMA. Reset HAL!\n");
+ "Unable to stop TxDMA. Reseting hardware!\n");
spin_lock_bh(&sc->sc_resetlock);
r = ath9k_hw_reset(ah, sc->sc_ah->curchan, false);
--
1.6.5.GIT
^ permalink raw reply related
* Re: regulatory problems with ath5k
From: Luis R. Rodriguez @ 2010-05-26 17:11 UTC (permalink / raw)
To: Arnd Hannemann, David Quan
Cc: linux-wireless@vger.kernel.org, ath5k-devel@lists.ath5k.org
In-Reply-To: <4BFD04A4.4000403@nets.rwth-aachen.de>
On Wed, May 26, 2010 at 4:23 AM, Arnd Hannemann
<hannemann@nets.rwth-aachen.de> wrote:
> Hi,
>
> I'm trying to use 802.11a channels in AP mode with my ath5k nics with kernel 2.6.34.
> And after setting up crda, udev and wireless regdb,
Which release of wireless-regdb?
> "iw list" still shows flags
> "passive scanning, no IBSS" for most of the 802.11a channels (see below.)
>
> I wonder what I'm doing wrong here?
Lets take a look.
>
> Band 2:
> Frequencies:
> * 5180 MHz [36] (20.0 dBm) (radar detection)
> * 5200 MHz [40] (20.0 dBm) (radar detection)
> * 5220 MHz [44] (20.0 dBm) (radar detection)
> * 5240 MHz [48] (20.0 dBm) (radar detection)
> * 5260 MHz [52] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5280 MHz [56] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5300 MHz [60] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5320 MHz [64] (20.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5500 MHz [100] (26.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5520 MHz [104] (26.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5540 MHz [108] (26.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5560 MHz [112] (26.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5580 MHz [116] (26.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5600 MHz [120] (26.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5620 MHz [124] (26.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5640 MHz [128] (26.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5660 MHz [132] (26.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5680 MHz [136] (26.0 dBm) (passive scanning, no IBSS, radar detection)
> * 5700 MHz [140] (26.0 dBm) (passive scanning, no IBSS, radar detection)
Please do: 'iw reg get' and paste the output here, the above channels
should not be passive scan/no-ibss for 'DE'.
> * 5745 MHz [149] (disabled)
> * 5765 MHz [153] (disabled)
> * 5785 MHz [157] (disabled)
> * 5805 MHz [161] (disabled)
> * 5825 MHz [165] (disabled)
>
> hannemann@mrouter46:~ $ sudo iw reg get
> country DE:
> (2400 - 2483 @ 40), (N/A, 20)
> (5150 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
> (5470 - 5725 @ 40), (N/A, 26), NO-OUTDOOR, DFS
>
> dmesg snippet:
>
> May 26 12:10:36 mrouter46 kernel: [ 30.023089] console [netcon0] enabled
> May 26 12:10:36 mrouter46 kernel: [ 30.023103] netconsole: network logging started
> May 26 12:10:36 mrouter46 kernel: [ 30.314702] cfg80211: Calling CRDA to update world regulatory domain
> May 26 12:10:37 mrouter46 kernel: [ 30.555745] ath5k 0000:00:0c.0: registered as \'phy0\'
> May 26 12:10:37 mrouter46 kernel: [ 31.039151] ath: EEPROM regdomain: 0x8114
WTF your EEPROM has 0x8114 set on the regulatory domain. David, have
you ever seen such a thing? This kernel (2.6.34) should already have
an ath5k EEPROM checksum check so the EEPROM should be valid. Lets
figure this out first before digging more into this.
Some more notes below though.
> May 26 12:10:37 mrouter46 kernel: [ 31.039168] ath: EEPROM indicates we should expect a country code
> May 26 12:10:37 mrouter46 kernel: [ 31.039188] ath: doing EEPROM country->regdmn map search
> May 26 12:10:37 mrouter46 kernel: [ 31.039205] ath: country maps to regdmn code: 0x37
> May 26 12:10:37 mrouter46 kernel: [ 31.039222] ath: Country alpha2 being used: DE
> May 26 12:10:37 mrouter46 kernel: [ 31.039237] ath: Regpair used: 0x37
> May 26 12:10:37 mrouter46 kernel: [ 31.054155] cfg80211: World regulatory domain updated:
So cfg80211 *first* starts out with the world regulatory domain by
default, and then it will call CRDA for DE since your regpair mapped
to 'DE'.
> May 26 12:10:37 mrouter46 kernel: [ 31.054178] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> May 26 12:10:37 mrouter46 kernel: [ 31.054207] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> May 26 12:10:37 mrouter46 kernel: [ 31.054232] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> May 26 12:10:37 mrouter46 kernel: [ 31.054258] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> May 26 12:10:37 mrouter46 kernel: [ 31.054284] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> May 26 12:10:37 mrouter46 kernel: [ 31.054310] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> May 26 12:10:38 mrouter46 kernel: [ 31.212057] phy0: Selected rate control algorithm \'minstrel\'
> May 26 12:10:38 mrouter46 kernel: [ 31.212732] ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
> May 26 12:10:38 mrouter46 kernel: [ 31.212732] ath5k phy0: RF5112B multiband radio found (0x36)
> May 26 12:10:38 mrouter46 kernel: [ 31.212732] ath5k 0000:00:0e.0: registered as \'phy1\'
> May 26 12:10:38 mrouter46 kernel: [ 31.622592] cfg80211: Calling CRDA for country: DE
Here is the call for 'DE'
> May 26 12:10:38 mrouter46 kernel: [ 31.688006] cfg80211: Regulatory domain changed to country: DE
> May 26 12:10:38 mrouter46 kernel: [ 31.688030] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> May 26 12:10:38 mrouter46 kernel: [ 31.688057] (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm)
> May 26 12:10:38 mrouter46 kernel: [ 31.688080] (5150000 KHz - 5350000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> May 26 12:10:38 mrouter46 kernel: [ 31.688103] (5470000 KHz - 5725000 KHz @ 40000 KHz), (N/A, 2698 mBm)
> May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: EEPROM regdomain: 0x8114
> May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: EEPROM indicates we should expect a country code
> May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: doing EEPROM country->regdmn map search
> May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: country maps to regdmn code: 0x37
> May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: Country alpha2 being used: DE
> May 26 12:10:38 mrouter46 kernel: [ 31.745694] ath: Regpair used: 0x37
> May 26 12:10:38 mrouter46 kernel: [ 31.758662] phy1: Selected rate control algorithm \'minstrel\'
> May 26 12:10:38 mrouter46 kernel: [ 31.759383] ath5k phy1: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
> May 26 12:10:38 mrouter46 kernel: [ 31.759383] ath5k phy1: RF5112B multiband radio found (0x36)
Do you have two cards?
Luis
^ permalink raw reply
* Re: [ath9k-devel] ath9k: 802.11n ad-hoc mode and mesh mode
From: Luis R. Rodriguez @ 2010-05-26 16:53 UTC (permalink / raw)
To: Jónatan Muñoz; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <-4856622450948873340@unknownmsgid>
On Wed, May 26, 2010 at 2:33 AM, Jónatan Muñoz <jonatan.munoz@alu.umh.es> wrote:
>
>
>
>
> Hi All,
>
>
>
> I’m interested in ad-hoc and mesh networks and I have some questions.
>
>
>
> Does anyone know if mesh mode is successfully enabled for AR9280?
Yes, does no one read the documentation or think of looking for it?
http://wireless.kernel.org/en/users/Drivers
http://wireless.kernel.org/en/users/Drivers/ath9k#supported_chipsets
Luis
^ permalink raw reply
* Re: [RFC] wireless-regdb: Add A band in IL
From: Luis R. Rodriguez @ 2010-05-26 16:51 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linville, linux-wireless, Michael Green, David Quan
In-Reply-To: <1274856569-13436-1-git-send-email-emmanuel.grumbach@intel.com>
On Tue, May 25, 2010 at 11:49 PM, Emmanuel Grumbach
<emmanuel.grumbach@intel.com> wrote:
> A band in allowed in IL, according to official document issued by the Ministry
> of Communications: http://www.moc.gov.il/sip_storage/FILES/1/1061.pdf.
>
> 5150 - 5250 200mW e.i.r.p. OUTDOOR forbidden
> 5250 - 5350 200mW e.i.r.p. OUTDOOR forbidden DFS mandatory
>
> 40Mhz is allowed in A band for every WiFi-Alliance certified equipment.
>
> ***************************************************************
> Not to be merged for the moment
> ***************************************************************
>
> CC: Michael Green <Michael.Green@atheros.com>
> CC: David Quan <David.Quan@atheros.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> ---
> db.txt | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/db.txt b/db.txt
> index e63a43e..d49c397 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -319,6 +319,8 @@ country IE:
>
> country IL:
> (2402 - 2482 @ 40), (N/A, 20)
> + (5150 - 5250 @ 40). (N/A, 200 mW), NO-OUTDOOR
> + (5250 - 5350 @ 40). (N/A, 200 mW), NO-OUTDOOR, DFS
I believe the one standing issue here is you are enabling HT40 on 5
GHz, how about enabling 2.4 GHz first, and then through a separate
patch and time/review we review the HT40 stuff, unless you are in no
rush to get 2.4 GHz enabled.
Luis
^ 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