* Re: ath5k past 2.6.30 breaks monitor mode (and thus the aircrack suite)
From: Richard Farina @ 2010-05-27 3:49 UTC (permalink / raw)
To: Bob Copeland; +Cc: Gábor Stefanik, Weedy, linux-wireless, Johannes Berg
In-Reply-To: <AANLkTilXJHs8emXX4YNHbPq0SkuC4Z22NEh-T6mwUSHS@mail.gmail.com>
Bob Copeland wrote:
> 2010/5/25 Gábor Stefanik <netrolller.3d@gmail.com>:
>
>> On Tue, May 25, 2010 at 4:53 PM, Bob Copeland <me@bobcopeland.com> wrote:
>>
>>> 2010/5/25 Weedy <weedy2887@gmail.com>:
>>>
>>>> 2010/5/24 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>>
>>>>> 2010/5/25 Weedy <weedy2887@gmail.com>:
>>>>>
>>>>>> 2010/5/23 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>>>>
>>>>>>> In the meantime, one thing to test: Add a printk of sc->opmode.
>>>>>>>
>>>>>> May 24 22:04:20 tiny-h4x kernel: [41147.243149] sc->opmode: 02 (over9000 times)
>>>>>>
>>>>>> So i'm guessing I did it wrong (I don't know C).
>>>>>> printk(KERN_NOTICE "sc->opmode: %02x\n", sc->opmode);
>>>>>>
>>>>>>
>>>>> No, that is correct, and proves my theory (2 is NL80211_IFTYPE_STATION
>>>>> - it should be 6 for monitor mode).
>>>>>
>>>>> BTW, please use "Reply to all".
>>>>>
>>>>>
>>>> gmail got rid of the "Reply to all by default" option :<
>>>>
>>>> When you have a patch I will be waiting.
>>>>
>>> Sorry, I missed this thread somehow. Thanks for the detective
>>> work and apologies for my stupid goof. Gábor, are you prepping
>>> a patch? I can fix it if you like.
>>>
>>>
>> If you can, please fix it - I know what the bug is, but have no solid
>> idea about a fix.
>>
>
> Ok, it should be enough to look at the filter flags instead of
> the opmode -- I knew in the back of my mind that the monitor
> stuff was bogus (part of the reason I did the patch in the first
> place) but just got confused by what was already there I guess.
>
>
I've got a lot of people very interested in this fix. Let me know what
kind of support you need to make this happen. You know where to find me
on irc ;-)
Thanks,
Rick
^ permalink raw reply
* Re: [PATCH] ath9k: Fix bug in the way "bf_tx_aborted" of struct ath_buf is used
From: Luis R. Rodriguez @ 2010-05-27 3:10 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan, Senthil Balasubramanian, Felix Fietkau
Cc: linville, linux-wireless
In-Reply-To: <1274926013-31968-1-git-send-email-vasanth@atheros.com>
On Wed, May 26, 2010 at 7:06 PM, Vasanthakumar Thiagarajan
<vasanth@atheros.com> wrote:
> This bug was introduced by the following commit
>
> Author: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> Date: Thu Apr 15 17:38:46 2010 -0400
>
> ath9k: Remove ATH9K_TX_SW_ABORTED and introduce a bool for this purpose
>
> Wrong buffer is checked for bf_tx_aborted field in ath_tx_num_badfrms(),
> this may result in a rate scaling with wrong feedback (number
> of unacked frames in this case). It is the last one in the chain
> of buffers for an aggregate frame that should be checked.
>
> Also it misses the initialization of this field in the buffer,
> this may lead to a situation where we stop the sw retransmission
> of failed subframes associated to this buffer.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> ---
FWIW, for those who want to test this, I've applied this patch into
the compat-wireless linux-next-pending/ directory. I've also kicked
out a new linux-next based compat-wireless tarball with the
pending+crap patches applied and fixed today's new compile issue
introduced by:
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date: Mon May 24 14:33:03 2010 -0700
kernel-wide: replace USHORT_MAX, SHORT_MAX and SHORT_MIN with
USHRT_MAX, SHRT_MAX and SHRT_MIN
- C99 knows about USHRT_MAX/SHRT_MAX/SHRT_MIN, not
USHORT_MAX/SHORT_MAX/SHORT_MIN.
- Make SHRT_MIN of type s16, not int, for consistency.
[akpm@linux-foundation.org: fix drivers/dma/timb_dma.c]
[akpm@linux-foundation.org: fix security/keys/keyring.c]
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This fix required a simple patch on compat.git.
The "pc" compat-wireless tarball for today then is:
http://www.orbit-lab.org/kernel/compat-wireless-2.6/compat-wireless-2010-05-26-pc.tar.bz2
sha1sum: 62937a3bec62cc564731b30295b44994504355cf
I've compile and load tested ath9k against 2.6.31-20-generic
Luis
^ permalink raw reply
* [PATCH] ath9k: Fix bug in the way "bf_tx_aborted" of struct ath_buf is used
From: Vasanthakumar Thiagarajan @ 2010-05-27 2:06 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
This bug was introduced by the following commit
Author: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Date: Thu Apr 15 17:38:46 2010 -0400
ath9k: Remove ATH9K_TX_SW_ABORTED and introduce a bool for this purpose
Wrong buffer is checked for bf_tx_aborted field in ath_tx_num_badfrms(),
this may result in a rate scaling with wrong feedback (number
of unacked frames in this case). It is the last one in the chain
of buffers for an aggregate frame that should be checked.
Also it misses the initialization of this field in the buffer,
this may lead to a situation where we stop the sw retransmission
of failed subframes associated to this buffer.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/xmit.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 3db1917..c575552 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1728,6 +1728,8 @@ static int ath_tx_setup_buffer(struct ieee80211_hw *hw, struct ath_buf *bf,
} else
bf->bf_isnullfunc = false;
+ bf->bf_tx_aborted = false;
+
return 0;
}
@@ -1989,7 +1991,7 @@ static int ath_tx_num_badfrms(struct ath_softc *sc, struct ath_buf *bf,
int nbad = 0;
int isaggr = 0;
- if (bf->bf_tx_aborted)
+ if (bf->bf_lastbf->bf_tx_aborted)
return 0;
isaggr = bf_isaggr(bf);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] mac80211: mark 1, 2, 5.5 and 11Mbps as mandatory rates for 802.11b
From: Bruno Randolf @ 2010-05-27 0:45 UTC (permalink / raw)
To: linville; +Cc: juuso.oikarinen, johannes, ath5k-devel, linux-wireless
In-Reply-To: <1274883276.3658.15.camel@jlt3.sipsolutions.net>
IEEE802.11-2007 clause 18.2.3.3 (p640) states that 1, 2, 5.5 & 11 Mbits are
mandatory rates for what they call High Rate direct sequence spread spectrum
(HR/DSSS) PHY (with long PLCP).
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
net/wireless/util.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 3416373..f6f4101 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -100,17 +100,17 @@ static void set_mandatory_flags_band(struct ieee80211_supported_band *sband,
case IEEE80211_BAND_2GHZ:
want = 7;
for (i = 0; i < sband->n_bitrates; i++) {
- if (sband->bitrates[i].bitrate == 10) {
+ if (sband->bitrates[i].bitrate == 10 ||
+ sband->bitrates[i].bitrate == 20 ||
+ sband->bitrates[i].bitrate == 55 ||
+ sband->bitrates[i].bitrate == 110) {
sband->bitrates[i].flags |=
IEEE80211_RATE_MANDATORY_B |
IEEE80211_RATE_MANDATORY_G;
want--;
}
- if (sband->bitrates[i].bitrate == 20 ||
- sband->bitrates[i].bitrate == 55 ||
- sband->bitrates[i].bitrate == 110 ||
- sband->bitrates[i].bitrate == 60 ||
+ if (sband->bitrates[i].bitrate == 60 ||
sband->bitrates[i].bitrate == 120 ||
sband->bitrates[i].bitrate == 240) {
sband->bitrates[i].flags |=
@@ -125,7 +125,7 @@ static void set_mandatory_flags_band(struct ieee80211_supported_band *sband,
sband->bitrates[i].flags |=
IEEE80211_RATE_ERP_G;
}
- WARN_ON(want != 0 && want != 3 && want != 6);
+ WARN_ON(want != 0 && want != 3);
break;
case IEEE80211_NUM_BANDS:
WARN_ON(1);
^ permalink raw reply related
* Re: [PATCHv2] mac80211: Fix basic rates for created IBSS networks
From: Bruno Randolf @ 2010-05-27 0:41 UTC (permalink / raw)
To: Johannes Berg
Cc: Juuso Oikarinen, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1274883276.3658.15.camel@jlt3.sipsolutions.net>
On Wednesday 26 May 2010 23:14:36 you wrote:
> Needs to be split up (setting bss_conf and the bss_change flag is a
> separate bugfix) and tested but this is what I think it should be like.
thanks for this!
> + } else {
> + /*
> + * If no rates were explicitly configured,
> + * use the mandatory rate set for 11b or
> + * 11a for maximum compatibility.
> + */
> + struct ieee80211_supported_band *sband =
> + wiphy->bands[ibss.channel->band];
> + int j;
> + u32 flag = ibss.channel->band == IEEE80211_BAND_5GHZ ?
> + IEEE80211_RATE_MANDATORY_A :
> + IEEE80211_RATE_MANDATORY_B;
> +
> + for (j = 0; j < sband->n_bitrates; j++) {
> + if (sband->bitrates[j].flags & flag)
> + ibss.basic_rates |= j;
> + }
> + }
couldn't we use ieee80211_mandatory_rates() here?
bruno
^ permalink raw reply
* Re: [PATCH]wireless:ath9k Disable leds for Apple products.
From: Justin P. Mattock @ 2010-05-26 22:28 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John W. Linville, linux-wireless
In-Reply-To: <AANLkTik_di7oAPf6PeebZJCC3RyGGB5FNTkJNNj0XVzU@mail.gmail.com>
On 05/26/2010 02:42 PM, Luis R. Rodriguez wrote:
> On Wed, May 26, 2010 at 2:34 PM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>
>> On 05/26/2010 02:05 PM, Luis R. Rodriguez wrote:
>>
>>> On Wed, May 26, 2010 at 10:38 AM, Justin P. Mattock
>>> <justinmattock@gmail.com> wrote:
>>>
>>>
>>>> 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>
>>>>>>
>>>>>>
>>> Our team has confirmed Apple devices do not have LEDs so a change like
>>> this is OK but this patch is wrong anyway. More details below.
>>>
>>>
>>>
>>>>>> 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/*
>>>>
>>>>
>>> The patch is wrong anyway, ath_init_leds() is void and yet you return
>>> a value. If this is really needed I'd also prefer if you define a bool
>>> or something and use a ah->ignore_leds and set this to true if the DMI
>>> stuff checks out for Apple up hw init. Then check for ignore_leds
>>> prior to calling ath_init_leds() and also avoid it if set. Also check
>>> for ingore_leds upon device cleanup and ignore the
>>> acancel_delayed_work_sync(&sc->ath_led_blink_work) and
>>> ath_deinit_leds() and skip that.
>>>
>>> But given that it is not needed it seems a lot of work for something
>>> that is a non-issue.
>>>
>>> Luis
>>>
>>>
>>>
>> tough to say!! I was looking into a bug a few months back, and
>> thought hmm.. maybe something is being called with the leds
>> but the leds are not there causing some thing to crap out..
>>
>> so out of curiosity I remembered the dmi disable patch, and
>> semi somewhat pieced it together(just to see the results of disabling the
>> leds).
>> unfortunately still hit the strange thing with wpa_supplicant and ath9k(the
>> disconnect thing).
>>
>> as for the above procedure(I can give that a try.. but it might
>> take a while...)
>>
> OK thanks for the details, best just ignore it unless you can prove it
> fixes an issue.
>
> Luis
>
>
at this point the only thing I can think of(if anything),
would maybe a wakeup with powertop or something in
the area of power management(but haven't looked into it).
In any case Thanks for having a look at the ath_print
earlier..
cheers,
Justin P. Mattock
^ permalink raw reply
* Re: Realtek rtl8188 support?
From: Gábor Stefanik @ 2010-05-26 22:21 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Paul Thomas, linux-wireless, Andrea Merello
In-Reply-To: <1274911569.2593.8.camel@mj>
On Thu, May 27, 2010 at 12:06 AM, Pavel Roskin <proski@gnu.org> wrote:
> On Mon, 2010-03-29 at 15:19 -0700, Paul Thomas wrote:
>> OK, I'd love to get to where Pavel & Gabor are, but I think I'm having
>> trouble with the PCI dependency. I'm on an arm platform without PCI
>> (atmel at91sam9g20). If I remove the PCI dependency from the Kconfig
>> it does compile with warnings, and then when the module loads I get
>> "r8192s_usb: Unknown symbol wireless_send_event".
>>
>> I'm happy to hang out and try again when the driver leaves staging,
>> but I thought I might mention the PCI dependency now.
>
> wireless_send_event should be available if WIRELESS_EXT is selected in Kconfig.
>
> But I cannot find the "r8192s_usb" symbol in any staging drivers, so I
> have no idea which driver you are talking about.
r8192s_usb is not a symbol, it is the name of the module being loaded.
>
> I suggest that you don't hijack existing threads to report new issues.
> When reporting a problem, please give the kernel version, the driver
> name and whatever details are needed for others to reproduce the
> problem.
>
>> > CCMP is working, and I could browse the web over it!
>
> Please don't quote parts of the message that are irrelevant to what you
> are saying.
>
> --
> Regards,
> Pavel Roskin
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: Realtek rtl8188 support?
From: Pavel Roskin @ 2010-05-26 22:06 UTC (permalink / raw)
To: Paul Thomas; +Cc: Gábor Stefanik, linux-wireless, Andrea Merello
In-Reply-To: <c785bba31003291519tfd7d26fy466a4ee4310ac590@mail.gmail.com>
On Mon, 2010-03-29 at 15:19 -0700, Paul Thomas wrote:
> OK, I'd love to get to where Pavel & Gabor are, but I think I'm having
> trouble with the PCI dependency. I'm on an arm platform without PCI
> (atmel at91sam9g20). If I remove the PCI dependency from the Kconfig
> it does compile with warnings, and then when the module loads I get
> "r8192s_usb: Unknown symbol wireless_send_event".
>
> I'm happy to hang out and try again when the driver leaves staging,
> but I thought I might mention the PCI dependency now.
wireless_send_event should be available if WIRELESS_EXT is selected in Kconfig.
But I cannot find the "r8192s_usb" symbol in any staging drivers, so I
have no idea which driver you are talking about.
I suggest that you don't hijack existing threads to report new issues.
When reporting a problem, please give the kernel version, the driver
name and whatever details are needed for others to reproduce the
problem.
> > CCMP is working, and I could browse the web over it!
Please don't quote parts of the message that are irrelevant to what you
are saying.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: ath5k past 2.6.30 breaks monitor mode (and thus the aircrack suite)
From: Weedy @ 2010-05-26 21:47 UTC (permalink / raw)
To: Bob Copeland; +Cc: Gábor Stefanik, linux-wireless, Johannes Berg
In-Reply-To: <AANLkTilXJHs8emXX4YNHbPq0SkuC4Z22NEh-T6mwUSHS@mail.gmail.com>
2010/5/26 Bob Copeland <me@bobcopeland.com>:
> 2010/5/25 Gábor Stefanik <netrolller.3d@gmail.com>:
>> On Tue, May 25, 2010 at 4:53 PM, Bob Copeland <me@bobcopeland.com> wrote:
>>> 2010/5/25 Weedy <weedy2887@gmail.com>:
>>>> 2010/5/24 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>>> 2010/5/25 Weedy <weedy2887@gmail.com>:
>>>>>> 2010/5/23 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>>>>> In the meantime, one thing to test: Add a printk of sc->opmode.
>>>>>>
>>>>>> May 24 22:04:20 tiny-h4x kernel: [41147.243149] sc->opmode: 02 (over9000 times)
>>>>>>
>>>>>> So i'm guessing I did it wrong (I don't know C).
>>>>>> printk(KERN_NOTICE "sc->opmode: %02x\n", sc->opmode);
>>>>>>
>>>>>
>>>>> No, that is correct, and proves my theory (2 is NL80211_IFTYPE_STATION
>>>>> - it should be 6 for monitor mode).
>>>>>
>>>>> BTW, please use "Reply to all".
>>>>>
>>>> gmail got rid of the "Reply to all by default" option :<
>>>>
>>>> When you have a patch I will be waiting.
>>>
>>> Sorry, I missed this thread somehow. Thanks for the detective
>>> work and apologies for my stupid goof. Gábor, are you prepping
>>> a patch? I can fix it if you like.
>>>
>>
>> If you can, please fix it - I know what the bug is, but have no solid
>> idea about a fix.
>
> Ok, it should be enough to look at the filter flags instead of
> the opmode -- I knew in the back of my mind that the monitor
> stuff was bogus (part of the reason I did the patch in the first
> place) but just got confused by what was already there I guess.
>
>
I await your patch with open arms.
^ permalink raw reply
* Re: [ath5k-devel] Race condition in CRDA calls?
From: Luis R. Rodriguez @ 2010-05-26 21:46 UTC (permalink / raw)
To: Lukáš Turek; +Cc: ath5k-devel@lists.ath5k.org, linux-wireless
In-Reply-To: <201003251801.57951.8an@praha12.net>
Just FYI, you want to use linux-wireless for reporting such things,
not ath5k-devel. Also I have been real busy in March (and stil am but
just trying to reply) so if I do not reply maybe others can. In
linux-wireless you'll likely get much more review/help than ath5k-devel
for this.
More below.
On Thu, Mar 25, 2010 at 10:01:54AM -0700, Lukáš Turek wrote:
> Hi,
>
> I've been testing current vanilla 2.6.34 from git today on a computer with
> three Atheros PCI cards and noticed a strange behavior: although all the
> cards have the same regulatory domain (0x36), only the last one (phy2) had
> the correct channels enabled, the other two (phy0 and phy1) stayed in US
> regulatory domain with channels 52-140 disabled.
>
> It seems the reply from CRDA for the first request gets into the kernel after
> the last card is detected and all the replies get mixed up some way:
>
> ath5k 0000:02:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> ath5k 0000:02:01.0: registered as 'phy0'
> ath: EEPROM regdomain: 0x36
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: CZ
> ath: Regpair used: 0x36
> udev: renamed network interface eth0 to eth2
> udev: renamed network interface eth1_rename to eth0
> phy0: Selected rate control algorithm 'minstrel'
> ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
> ath5k 0000:02:02.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> ath5k 0000:02:02.0: registered as 'phy1'
> ath: EEPROM regdomain: 0x36
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: CZ
> ath: Regpair used: 0x36
> cfg80211: Calling CRDA for country: CZ
> phy1: Selected rate control algorithm 'minstrel'
> ath5k phy1: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
> ath5k 0000:02:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
> ath5k 0000:02:03.0: registered as 'phy2'
> ath: EEPROM regdomain: 0x36
> ath: EEPROM indicates we should expect a direct regpair map
> ath: Country alpha2 being used: CZ
> ath: Regpair used: 0x36
> cfg80211: Calling CRDA for country: CZ
> udev: renamed network interface wlan1 to wlan3
> phy2: Selected rate control algorithm 'minstrel'
> ath5k phy2: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
> cfg80211: Calling CRDA for country: CZ
> udev: renamed network interface wlan1 to wlan2
> cfg80211: Current regulatory domain intersected:
> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> (2474000 KHz - 2483500 KHz @ 9500 KHz), (N/A, 2000 mBm)
> (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> cfg80211: Current regulatory domain intersected:
> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> (2474000 KHz - 2483500 KHz @ 9500 KHz), (N/A, 2000 mBm)
> (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> cfg80211: Current regulatory domain intersected:
> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> (2474000 KHz - 2483500 KHz @ 9500 KHz), (N/A, 2000 mBm)
> (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>
> Another reason might be udev messing up with device names. I will try to debug
> this, but any hints would be greatly appreciated, because there's not much
> info about the CRDA <-> kernel interaction.
You forgot to supply the kernel log of when cfg80211 loads, that
would have been helpful. After cfg80211 loads then leave a window
open with 'iw event -t' running. Then load ath5k, and if you want to
debug udev you can use udevadm, for example to debug only
kernel messages:
udevadm monitor --environment kernel
In short cfg80211 will do an intersection if the core had a regulatory
domain set for some reason and then a driver suggested to use another
country. If cfg80211 was world roaming and a driver then just used
a request for CZ then it shuld stick to CZ. If a second device comes
up with CZ then -EALREADY should be expected IIRC, if this is not happening
it smells like a bug.
Luis
^ permalink raw reply
* Re: [PATCH]wireless:ath9k Disable leds for Apple products.
From: Luis R. Rodriguez @ 2010-05-26 21:42 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: John W. Linville, linux-wireless
In-Reply-To: <4BFD93E0.5080506@gmail.com>
On Wed, May 26, 2010 at 2:34 PM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> On 05/26/2010 02:05 PM, Luis R. Rodriguez wrote:
>>
>> On Wed, May 26, 2010 at 10:38 AM, Justin P. Mattock
>> <justinmattock@gmail.com> wrote:
>>
>>>
>>> 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>
>>>>>
>>
>> Our team has confirmed Apple devices do not have LEDs so a change like
>> this is OK but this patch is wrong anyway. More details below.
>>
>>
>>>>>
>>>>> 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/*
>>>
>>
>> The patch is wrong anyway, ath_init_leds() is void and yet you return
>> a value. If this is really needed I'd also prefer if you define a bool
>> or something and use a ah->ignore_leds and set this to true if the DMI
>> stuff checks out for Apple up hw init. Then check for ignore_leds
>> prior to calling ath_init_leds() and also avoid it if set. Also check
>> for ingore_leds upon device cleanup and ignore the
>> acancel_delayed_work_sync(&sc->ath_led_blink_work) and
>> ath_deinit_leds() and skip that.
>>
>> But given that it is not needed it seems a lot of work for something
>> that is a non-issue.
>>
>> Luis
>>
>>
>
> tough to say!! I was looking into a bug a few months back, and
> thought hmm.. maybe something is being called with the leds
> but the leds are not there causing some thing to crap out..
>
> so out of curiosity I remembered the dmi disable patch, and
> semi somewhat pieced it together(just to see the results of disabling the
> leds).
> unfortunately still hit the strange thing with wpa_supplicant and ath9k(the
> disconnect thing).
>
> as for the above procedure(I can give that a try.. but it might
> take a while...)
OK thanks for the details, best just ignore it unless you can prove it
fixes an issue.
Luis
^ permalink raw reply
* Re: [PATCH]wireless:ath9k Disable leds for Apple products.
From: Justin P. Mattock @ 2010-05-26 21:34 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John W. Linville, linux-wireless
In-Reply-To: <AANLkTim6ef__fNdXUyP1T4HB7jxbyt-Jlqi3Xa5Y_whm@mail.gmail.com>
On 05/26/2010 02:05 PM, Luis R. Rodriguez wrote:
> On Wed, May 26, 2010 at 10:38 AM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>
>> 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>
>>>>
> Our team has confirmed Apple devices do not have LEDs so a change like
> this is OK but this patch is wrong anyway. More details below.
>
>
>>>> 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/*
>>
> The patch is wrong anyway, ath_init_leds() is void and yet you return
> a value. If this is really needed I'd also prefer if you define a bool
> or something and use a ah->ignore_leds and set this to true if the DMI
> stuff checks out for Apple up hw init. Then check for ignore_leds
> prior to calling ath_init_leds() and also avoid it if set. Also check
> for ingore_leds upon device cleanup and ignore the
> acancel_delayed_work_sync(&sc->ath_led_blink_work) and
> ath_deinit_leds() and skip that.
>
> But given that it is not needed it seems a lot of work for something
> that is a non-issue.
>
> Luis
>
>
tough to say!! I was looking into a bug a few months back, and
thought hmm.. maybe something is being called with the leds
but the leds are not there causing some thing to crap out..
so out of curiosity I remembered the dmi disable patch, and
semi somewhat pieced it together(just to see the results of disabling
the leds).
unfortunately still hit the strange thing with wpa_supplicant and
ath9k(the disconnect thing).
as for the above procedure(I can give that a try.. but it might
take a while...)
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH]wireless:ath9k Disable leds for Apple products.
From: Luis R. Rodriguez @ 2010-05-26 21:05 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: John W. Linville, linux-wireless
In-Reply-To: <4BFD5C89.8000308@gmail.com>
On Wed, May 26, 2010 at 10:38 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> 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>
Our team has confirmed Apple devices do not have LEDs so a change like
this is OK but this patch is wrong anyway. More details below.
>>>
>>> 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/*
The patch is wrong anyway, ath_init_leds() is void and yet you return
a value. If this is really needed I'd also prefer if you define a bool
or something and use a ah->ignore_leds and set this to true if the DMI
stuff checks out for Apple up hw init. Then check for ignore_leds
prior to calling ath_init_leds() and also avoid it if set. Also check
for ingore_leds upon device cleanup and ignore the
acancel_delayed_work_sync(&sc->ath_led_blink_work) and
ath_deinit_leds() and skip that.
But given that it is not needed it seems a lot of work for something
that is a non-issue.
Luis
^ permalink raw reply
* Re: [RFC] mac80211: sample survey implementation for mac80211 & hwsim
From: Johannes Berg @ 2010-05-26 20:43 UTC (permalink / raw)
To: Joerg Pommnitz; +Cc: linux-wireless, Holger Schurig
In-Reply-To: <loom.20100422T100127-458@post.gmane.org>
Holger,
> > +static int ieee80211_dump_survey(struct wiphy *wiphy, struct net_device *dev,
> > + int idx, struct survey_info *survey)
> > +{
> > + struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
> > +
> > + if (!local->ops->get_survey)
> > + return -EOPNOTSUPP;
>
> The check for the function is duplicated in drv_get_survey. I think the
> wrapper should be called unconditionally.
Please address this comment and add tracing. Your patch was merged, so
that needs to be an add-on patch.
johannes
^ permalink raw reply
* Re: [PATCH][RESEND] ath9k: Fix ath_print in xmit for hardware reset.
From: Justin P. Mattock @ 2010-05-26 18:34 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, arnd, linux-wireless
In-Reply-To: <AANLkTinjgtKhQJ1UoQPY8aUFxhb3qrKrYjBgAZz1asZ_@mail.gmail.com>
On 05/26/2010 11:14 AM, Luis R. Rodriguez wrote:
> On Wed, May 26, 2010 at 11:12 AM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>
>> On 05/26/2010 11:09 AM, Luis R. Rodriguez wrote:
>>
>>> On Wed, May 26, 2010 at 11:07 AM, Justin P. Mattock
>>> <justinmattock@gmail.com> wrote:
>>>
>
>>>> what about all the signed-off's? should I
>>>> resend with all of those, or no?
>>>>
>>
>>> I do not get what you are asking.
>>>
>> all the people that gave there 00.02$ on this to
>> make it all-good
>>
> Heh... no. SOBs are just for the authors of the code. The real purpose
> of SOB is explained on Documentation/SubmittingPatches, read
> "Developer's Certificate of Origin 1.1".
>
> Luis
>
>
I thought you were talking about
Son of a bit*h(was like what's this guy
talkin about man!!
I'll read up today!!
Justin P. Mattock
^ permalink raw reply
* Re: wireless-regdb: FI/CZ updates
From: Luis R. Rodriguez @ 2010-05-26 18:30 UTC (permalink / raw)
To: Pekka Pietikainen, Michael Green, David Quan; +Cc: linville, linux-wireless
In-Reply-To: <20100525132035.GA863@ee.oulu.fi>
On Tue, May 25, 2010 at 6:20 AM, Pekka Pietikainen <pp@ee.oulu.fi> wrote:
> Was looking at the relevant local regulations and noticed the regdb allowed
> less power at 5GHz than is actually allowed. Until I found the "If you don't do TPC you have
> to reduce your power by 3dB sometimes" bit on the next page.
>
> And looks like someone that did the entry for CZ fell into the same trap, they have
>
> "stations in the c and d bands must employ automatic transmitter power
> control, which provides, on average, an interference mitigation factor at
> least 3 dB on the maximum permitted output power of the systems. If
> automatic power control is not employed, the maximum permitted mean e.i.r.p.
> and the corresponding limit of the mean e.i.r.p. density for bands c and d
> must be reduced by 3 dB;"
>
> Please sanity check, I became very confused while looking into this.
> (like some places starting their freq ranges at 2400, others at 2402. Didn't
> touch those, regs say 2400-2485,5, 5150-5250, 5250-5350 and 5470-5725)
>
> Signed-off-by: Pekka Pietikäinen <pp@ee.oulu.fi>
> diff -up ./db.txt.orig ./db.txt
> --- ./db.txt.orig 2010-05-25 15:03:48.812116854 +0300
> +++ ./db.txt 2010-05-25 15:58:43.947117884 +0300
> @@ -170,11 +170,13 @@ country CY:
>
> # Data from http://www.ctu.eu/164/download/VOR/VOR-12-08-2005-34.pdf
> # and http://www.ctu.eu/164/download/VOR/VOR-12-05-2007-6-AN.pdf
> +# Power at 5250 - 5350 MHz and 5470 - 5725 MHz can be doubled if TPC is
> +# implemented.
> country CZ:
> (2400 - 2483.5 @ 40), (N/A, 100 mW)
> (5150 - 5250 @ 40), (N/A, 200 mW), NO-OUTDOOR
> - (5250 - 5350 @ 40), (N/A, 200 mW), NO-OUTDOOR, DFS
> - (5470 - 5725 @ 40), (N/A, 1000 mW), DFS
> + (5250 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS
> + (5470 - 5725 @ 40), (N/A, 500 mW), DFS
Michael -- as per David's review this seems fine, please let us know
if you agree.
> # Data from "Frequenznutzungsplan" (as published in April 2008),
> # downloaded from http://www.bundesnetzagentur.de/media/archive/13358.pdf
> @@ -226,11 +228,15 @@ country ES:
> (5250 - 5330 @ 40), (N/A, 20), DFS
> (5490 - 5710 @ 40), (N/A, 27), DFS
>
> +# Data from FICORA Regulation 15Z / 2009 M
> +# http://www.ficora.fi/attachments/suomiry/5l1x1FIIk/Viestintavirasto15Z2009M.pdf
> +# Power at 5250 - 5350 MHz and 5470 - 5725 MHz can be doubled if TPC is
> +# implemented.
> country FI:
> - (2402 - 2482 @ 40), (N/A, 20)
> - (5170 - 5250 @ 40), (N/A, 20)
> - (5250 - 5330 @ 40), (N/A, 20), DFS
> - (5490 - 5710 @ 40), (N/A, 27), DFS
> + (2402 - 2482 @ 40), (N/A, 100mW)
> + (5170 - 5250 @ 40), (N/A, 200mW), NO-OUTDOOR
> + (5250 - 5330 @ 40), (N/A, 100mW), NO-OUTDOOR, DFS
> + (5490 - 5710 @ 40), (N/A, 500mW), DFS
Pekka, please remove these changes from this patch, you want to make
your patches atomic, with only one purpose to help the review process
easier. You stashed changes to CZ & FI on one... You also switched
from dBm to mW and note how you actually did change the EIRP here for
only one for FI. Please provide a separate set of patches for that for
FI. If you want to switch to mW for all of the entries for FI first do
that, and then on a separate patch make the actual regulatory changes
so this is crystal clear for the review process.
So in summary: please post another separate patch for CZ and please
lets wait on Michael's final ACK. The other FI changes should be split
up. Also please CC Michael And David on your e-mails for regulatory
changes, they are not subscribed to linux-wireless but can certainly
help with reviewing these changes. I'll post some suggested updates on
guidelines for patches to wireless-regdb later.
Thanks,
Luis
^ permalink raw reply
* Re: [RFC] wireless-regdb: Add A band in IL
From: Luis R. Rodriguez @ 2010-05-26 18:22 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
Michael Green, David Quan
In-Reply-To: <4825B8A2C4E264489E57869F0DCFB22343E33E6133@hasmsx502.ger.corp.intel.com>
On Wed, May 26, 2010 at 10:51 AM, Grumbach, Emmanuel
<emmanuel.grumbach@intel.com> wrote:
>>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.
>
> Actually 40GHz is less a problem in 5GHz than in 2.4GHz since in 2.4GHz
> I need to have a "Coexistence mechanism", which is not required in 5GHz.
> This Coexistence mechanism is apparently implemented by one OEM under the
> name "Clear Channel Assessment (CCA)".
>
> In short, I don't think there is any special issue with 40MHz in 5GHz, but
> I may miss something here... In any case, I have no problem with sending
> a patch that allows 5GHz in 20MHz for the moment.
> I can also have a look at the EEPROM in our NICs which is supposed to have
> all the needed limitations. Details to follow tomorrow.
OK thanks for the clarification Emmanuel, please give Michael some
time to review.
Luis
^ permalink raw reply
* Re: [PATCH][RESEND] ath9k: Fix ath_print in xmit for hardware reset.
From: Luis R. Rodriguez @ 2010-05-26 18:14 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linville, arnd, linux-wireless
In-Reply-To: <4BFD6478.8090700@gmail.com>
On Wed, May 26, 2010 at 11:12 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> On 05/26/2010 11:09 AM, Luis R. Rodriguez wrote:
>> On Wed, May 26, 2010 at 11:07 AM, Justin P. Mattock
>> <justinmattock@gmail.com> wrote:
>>> what about all the signed-off's? should I
>>> resend with all of those, or no?
>
>> I do not get what you are asking.
>
> all the people that gave there 00.02$ on this to
> make it all-good
Heh... no. SOBs are just for the authors of the code. The real purpose
of SOB is explained on Documentation/SubmittingPatches, read
"Developer's Certificate of Origin 1.1".
Luis
^ permalink raw reply
* Re: regulatory problems with ath5k
From: Luis R. Rodriguez @ 2010-05-26 18:12 UTC (permalink / raw)
To: Arnd Hannemann
Cc: David Quan, linux-wireless@vger.kernel.org,
ath5k-devel@lists.ath5k.org
In-Reply-To: <4BFD63F0.9020905@nets.rwth-aachen.de>
On Wed, May 26, 2010 at 11:09 AM, Arnd Hannemann
<hannemann@nets.rwth-aachen.de> wrote:
> Am 26.05.2010 19:11, schrieb Luis R. Rodriguez:
>> 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?
>>
>>
> This morning's git tree. I just copied the regulatory.bin from there.
> Last commit was:
>
> commit f3ba942f073358d1bca82a389da9f7da6e8fe81f
> Author: John W. Linville <linville@tuxdriver.com>
> Date: Fri Feb 5 13:47:41 2010 -0500
>
> wireless-regdb: update sha1sum.txt in Makefile and fix REGDB_CHANGED
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
>
>
>
>>> "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'.
>>
>
> 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
>
>
>>> 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.
>>
>
> You got me, I hacked this up:
>
> --- linux-2.6.34/drivers/net/wireless/ath/regd.c 2010-05-16
> 23:17:36.000000000 +0200
> +++ linux-2.6.34.x-um/drivers/net/wireless/ath/regd.c 2010-05-26
> 19:57:44.000000000 +0200
> @@ -501,7 +501,7 @@ ath_regd_init(struct ath_regulatory *reg
> return -EINVAL;
>
> ath_regd_sanitize(reg);
> -
> + reg->current_rd = CTRY_GERMANY | COUNTRY_ERD_FLAG;
> printk(KERN_DEBUG "ath: EEPROM regdomain: 0x%0x\n", reg->current_rd);
>
> if (!ath_regd_is_eeprom_valid(reg)) {
>
>
> Do you think this is the cause?
You won't get support if you hack that stuff, you should be using only
what your EEPROM is configured for, otherwise good luck, you're on
your own.
Provide the logs with that change removed to receive more review,
otherwise I consider this thread dead.
Luis
^ permalink raw reply
* Re: [PATCH][RESEND] ath9k: Fix ath_print in xmit for hardware reset.
From: Justin P. Mattock @ 2010-05-26 18:12 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, arnd, linux-wireless
In-Reply-To: <AANLkTikIfbrD7t122jJG-ODU5qb9sbGVIGrHlNJ7w2ia@mail.gmail.com>
On 05/26/2010 11:09 AM, Luis R. Rodriguez wrote:
> On Wed, May 26, 2010 at 11:07 AM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>
>> 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?
>>
> I do not get what you are asking.
>
> Luis
>
>
all the people that gave there 00.02$ on this to
make it all-good
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH][RESEND] ath9k: Fix ath_print in xmit for hardware reset.
From: Luis R. Rodriguez @ 2010-05-26 18:09 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linville, arnd, linux-wireless
In-Reply-To: <4BFD636B.3070607@gmail.com>
On Wed, May 26, 2010 at 11:07 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> 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?
I do not get what you are asking.
Luis
^ permalink raw reply
* Re: regulatory problems with ath5k
From: Arnd Hannemann @ 2010-05-26 18:09 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: David Quan, linux-wireless@vger.kernel.org,
ath5k-devel@lists.ath5k.org
In-Reply-To: <AANLkTik5BnKa7eP4U2Qq6uDYiRk_uc47IpslpFeC0l9r@mail.gmail.com>
Am 26.05.2010 19:11, schrieb Luis R. Rodriguez:
> 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?
>
>
This morning's git tree. I just copied the regulatory.bin from there.
Last commit was:
commit f3ba942f073358d1bca82a389da9f7da6e8fe81f
Author: John W. Linville <linville@tuxdriver.com>
Date: Fri Feb 5 13:47:41 2010 -0500
wireless-regdb: update sha1sum.txt in Makefile and fix REGDB_CHANGED
Signed-off-by: John W. Linville <linville@tuxdriver.com>
>> "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'.
>
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
>> 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.
>
You got me, I hacked this up:
--- linux-2.6.34/drivers/net/wireless/ath/regd.c 2010-05-16
23:17:36.000000000 +0200
+++ linux-2.6.34.x-um/drivers/net/wireless/ath/regd.c 2010-05-26
19:57:44.000000000 +0200
@@ -501,7 +501,7 @@ ath_regd_init(struct ath_regulatory *reg
return -EINVAL;
ath_regd_sanitize(reg);
-
+ reg->current_rd = CTRY_GERMANY | COUNTRY_ERD_FLAG;
printk(KERN_DEBUG "ath: EEPROM regdomain: 0x%0x\n", reg->current_rd);
if (!ath_regd_is_eeprom_valid(reg)) {
Do you think this is the cause?
>
>> 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?
>
Yes.
Best regards,
Arnd
^ permalink raw reply
* Re: [PATCH] ath9k: Fix ath_print in xmit for harware reset.
From: Justin P. Mattock @ 2010-05-26 18:08 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, arnd, linux-wireless
In-Reply-To: <AANLkTilrXZCtJpTrynPlC0FbNfpXcfgYg1Pd6_2oOZml@mail.gmail.com>
On 05/26/2010 11:03 AM, Luis R. Rodriguez wrote:
> 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
>
>
alright!!
Justin P. Mattock
^ permalink raw reply
* Re: [ath9k-devel] ath9k: 802.11n ad-hoc mode and mesh mode
From: Xianghua Xiao @ 2010-05-26 18:07 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Jónatan Muñoz, linux-wireless, ath9k-devel
In-Reply-To: <AANLkTinAgV0Vd4mjuVB_wOARcWlAC_VKAoEmCS0rr1qa@mail.gmail.com>
the non-HT 80211n mesh should work, however for 80211N I think HT is
not fully supported(yet) for mesh.
Xianghua
On Wed, May 26, 2010 at 11:53 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> 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
> --
> 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: [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
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