* Re: ATH5k - Signal measurement reports wrong values - thanks for a fix
From: Bruno Randolf @ 2010-06-30 7:26 UTC (permalink / raw)
To: Jaroslav Fojtik; +Cc: linux-wireless, Nick Kossifidis
In-Reply-To: <4C2AEF25.1702.2DF7E2@jafojtik.seznam.cz>
On Wed June 30 2010 16:15:49 Jaroslav Fojtik wrote:
> > > Before this patch there were short peeks from -78dB to -71dB.
> > > After patch there are short measurement drops from -62dB to -70dB.
> > >
> > > The week charting simply averages it:
> > > http://78.108.103.11:11080/cgi-bin/rodga_1week_big.cgi
> >
> > i guess this must be the same situation as before, no?
>
> Just repeat:
> ## Before this patch there were short peeks from -78dB to -71dB.
>
> ## After patch there are short measurement drops from -62dB to -70dB.
i meant: did you see the same kind of drops with the older compat-wireless
versions, before you reported the problem?
> > how many antennas do you have attached to your device?
>
> One miniPCI device has only one antenna attached. Second U.FL. connector
> is empty.
>
> > it might be interesting to check if you get more consistent
> > signal measurements by disabling antenna
> > diversity, setting it to a fixed antenna. you can do this by using a
> > debugfs file "echo fixed-a > /sys/kernel/debug/ath5k/phy0/antenna" (or
> > "fixed-b")...
>
> I have found that "fixed-b" is a right connector. There is a stupid
> question why? When I am using "out" and not "aux". I just guess that "out"
> should be 'a' and 'aux' should be 'b'.
yes, i have noticed the same thing on some cards. maybe a wrong setting in
eeprom, or some bug in ath5k.
> Please again have a look at:
> http://78.108.103.11:11080/cgi-bin/rodga_1day_big.cgi
>
> It looks like signal power jumped to -46dB.
> It seems that ATH5k never switched to "fixed-b" and I has been receiving
> garbage from empty U.FL. It is a miracle that it has been worked.
i have also had problems with diversity in ath5k when there is only one
antenna attached and in this case i always need to set a fixed antenna for
optimal performance.
> MadWiFi is much more intelligent. It tests both inputs and selects better
> one.
glad to hear it works for you; i had many inconsistencies with antenna
diversity on madwifi as well..
bruno
PS: CC'ing nick, maybe he has some idea?
^ permalink raw reply
* Re: ATH5k - Signal measurement reports wrong values - thanks for a fix
From: Jaroslav Fojtik @ 2010-06-30 7:15 UTC (permalink / raw)
To: Bruno Randolf, linux-wireless
In-Reply-To: <201006281021.47132.br1@einfach.org>
Dear Bruno,
> > Anyway, when you look at the magenta line here:
> > http://78.108.103.11:11080/cgi-bin/rodga_1day_big.cgi
> >
> > There are big drops in measured signal. Did you fix all places?
> >
> > Before this patch there were short peeks from -78dB to -71dB.
> > After patch there are short measurement drops from -62dB to -70dB.
> >
> > The week charting simply averages it:
> > http://78.108.103.11:11080/cgi-bin/rodga_1week_big.cgi
>
> i guess this must be the same situation as before, no?
Just repeat:
## Before this patch there were short peeks from -78dB to -71dB.
## After patch there are short measurement drops from -62dB to -70dB.
MadWiFi does not produce such drops.
> how many antennas do you have attached to your device?
One miniPCI device has only one antenna attached. Second U.FL. connector
is empty.
> it might be interesting to check if you get more consistent
> signal measurements by disabling antenna
> diversity, setting it to a fixed antenna. you can do this by using a debugfs
> file "echo fixed-a > /sys/kernel/debug/ath5k/phy0/antenna" (or "fixed-b")...
I have found that "fixed-b" is a right connector. There is a stupid question why?
When I am using "out" and not "aux". I just guess that "out" should be 'a'
and 'aux' should be 'b'.
Please again have a look at:
http://78.108.103.11:11080/cgi-bin/rodga_1day_big.cgi
It looks like signal power jumped to -46dB.
It seems that ATH5k never switched to "fixed-b" and I has been receiving
garbage from empty U.FL. It is a miracle that it has been worked.
MadWiFi is much more intelligent. It tests both inputs and selects better one.
> btw: when the signal measurement was low, did you see any negative impact on
> the thruput as well?
Nope.
http://78.108.103.11:11080/cgi-bin/pktloss_1day_big.cgi
But the line is so overpowered that I would not notify 8dB drop.
regards
Jara
> bruno
^ permalink raw reply
* [PATCHv2] mac82011: Allow selection of minstrel_ht as default rc algorithm
From: Helmut Schaa @ 2010-06-30 6:48 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Felix Fietkau, Luis R. Rodriguez
Allow selection of minstrel_ht as default rate control algorithm. At
the moment minstrel_ht can only be requested by the driver code but
not selected as default in make menuconfig. Fix this by using
minstrel_ht when minstrel was selected as default and minstrel_ht
is available.
This change won't affect legacy devices as minstrel_ht falls back to
minstrel in that case.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
net/mac80211/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 83eec7a..4d6f865 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -69,6 +69,7 @@ endchoice
config MAC80211_RC_DEFAULT
string
+ default "minstrel_ht" if MAC80211_RC_DEFAULT_MINSTREL && MAC80211_RC_MINSTREL_HT
default "minstrel" if MAC80211_RC_DEFAULT_MINSTREL
default "pid" if MAC80211_RC_DEFAULT_PID
default ""
--
1.6.4.2
^ permalink raw reply related
* Re: [ath5k-devel] ath5k Register Question
From: Benoit Papillault @ 2010-06-30 6:05 UTC (permalink / raw)
To: Jono; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTinTDPyeV2QWWmXskp4504nxPIm1neJdxdLat51p@mail.gmail.com>
Le 30/06/2010 05:44, Jono a écrit :
> Hi,
>
> I'm not sure if this is the right place to ask, but I'm looking for
> information on a specific register on Atheros cards.
>
> I've been told that there is a register that Atheros chips update with
> information about how much of a set period has been detected as 'CCA'
> time. Unfortunately, I cannot find this information in the source
> code. The only register I found that matches this even closely appears
> to only be used during noise calibration, and not updated
> continuously.
>
> Any help would be greatly appreciated!
>
> Thank you,
>
> --
> Jonathan Guerin
Look for Profile Count Registers in ath5k/reg.h. Busy count is probably
what you need.
Regards,
Benoit
^ permalink raw reply
* Re: Problem with firmware load on ipw2200
From: Pavel Roskin @ 2010-06-30 5:46 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4C29F711.1090306@lwfinger.net>
On Tue, 2010-06-29 at 08:37 -0500, Larry Finger wrote:
> I'm trying to help an ipw2200 user on the openSUSE Wireless Forum and I'm
> stuck. The system is failing to load the firmware with error -2 (File or
> directory not found). The difficulty is that the required files are
> present with the correct permissions.
>
> What system component might be missing and/or borked to get this symptom?
Older versions of compat-wireless had a race condition in the firmware
code that could cause that. From the log of the compat repository:
commit 524449c0184d44773d4947db8cd3bfd98a0a215f
Author: Grazvydas Ignotas <notasas@gmail.com>
Date: Thu Apr 22 16:54:02 2010 +0300
compat: fix uevent_suppress on 2.6.29 or older kernels
Missing uevent_suppress is causing two uevents instead of one, which is
confusing udev and sometimes causing firmware load to fail due to race
condition, so let's add it.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
--
Regards,
Pavel Roskin
^ permalink raw reply
* ath5k Register Question
From: Jono @ 2010-06-30 3:44 UTC (permalink / raw)
To: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTikC3saJNwAFhHvSyJNqVF1fGPcVfn-hwGpR5V30@mail.gmail.com>
Hi,
I'm not sure if this is the right place to ask, but I'm looking for
information on a specific register on Atheros cards.
I've been told that there is a register that Atheros chips update with
information about how much of a set period has been detected as 'CCA'
time. Unfortunately, I cannot find this information in the source
code. The only register I found that matches this even closely appears
to only be used during noise calibration, and not updated
continuously.
Any help would be greatly appreciated!
Thank you,
--
Jonathan Guerin
^ permalink raw reply
* [PATCH] ath9k: fix TSF after reset on AR913x
From: Felix Fietkau @ 2010-06-30 0:07 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez, John W. Linville, Björn Smedman
When issuing a reset, the TSF value is lost in the hardware because of
the 913x specific cold reset. As with some AR9280 cards, the TSF needs
to be preserved in software here.
Additionally, there's an issue that frequently prevents a successful
TSF write directly after the chip reset. In this case, repeating the
TSF write after the initval-writes usually works.
This patch detects failed TSF writes and recovers from them, taking
into account the delay caused by the initval writes.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Björn Smedman <bjorn.smedman@venatech.se>
Cc: stable@kernel.org
---
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1280,7 +1280,8 @@ int ath9k_hw_reset(struct ath_hw *ah, st
macStaId1 = REG_READ(ah, AR_STA_ID1) & AR_STA_ID1_BASE_RATE_11B;
/* For chips on which RTC reset is done, save TSF before it gets cleared */
- if (AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL))
+ if (AR_SREV_9100(ah) ||
+ (AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL)))
tsf = ath9k_hw_gettsf64(ah);
saveLedState = REG_READ(ah, AR_CFG_LED) &
@@ -1312,7 +1313,7 @@ int ath9k_hw_reset(struct ath_hw *ah, st
}
/* Restore TSF */
- if (tsf && AR_SREV_9280(ah) && ah->eep_ops->get_eeprom(ah, EEP_OL_PWRCTRL))
+ if (tsf)
ath9k_hw_settsf64(ah, tsf);
if (AR_SREV_9280_10_OR_LATER(ah))
@@ -1325,6 +1326,17 @@ int ath9k_hw_reset(struct ath_hw *ah, st
if (r)
return r;
+ /*
+ * Some AR91xx SoC devices frequently fail to accept TSF writes
+ * right after the chip reset. When that happens, write a new
+ * value after the initvals have been applied, with an offset
+ * based on measured time difference
+ */
+ if (AR_SREV_9100(ah) && (ath9k_hw_gettsf64(ah) < tsf)) {
+ tsf += 1500;
+ ath9k_hw_settsf64(ah, tsf);
+ }
+
/* Setup MFP options for CCMP */
if (AR_SREV_9280_20_OR_LATER(ah)) {
/* Mask Retry(b11), PwrMgt(b12), MoreData(b13) to 0 in mgmt
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Felix Fietkau @ 2010-06-29 23:56 UTC (permalink / raw)
To: Björn Smedman; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTimhHK461U_qguBGuJjppy5RP2tx5ApasJWVLgr4@mail.gmail.com>
On 2010-06-30 12:50 AM, Björn Smedman wrote:
> 2010/6/29 Felix Fietkau <nbd@openwrt.org>:
>> I had a similar thought about the multiple invocations thing. I think
>> that's a good approach in general, but we need to ensure that we make it
>> safe.
>> The main point of this function is to detect baseband hangs. If we
>> experience such a hang, I'm not sure we will always get enough
>> interrupts to do multiple consecutive tests.
>> One way to make it safe would be to reschedule the tasklet each time we
>> ignore the result of the ath9k_hw_check_alive(), that way we keep the
>> detection time low as well. Maybe we could also use a timer for leaving
>> 10 ms time between attempts.
>
> The xmit logic has sc->tx_complete_work that periodically checks if
> the tx is hung and resets the chip if so. Maybe we could refactor that
> into a common periodic health checkup task in main.c that could call
> into both xmit.c and recv.c? Or does ath9k_hw_check_alive() have to
> run in the interrupt context in some way?
I'd like to keep them separate. I think a tx queue hang is very rare,
and the check only runs every second or so, whereas the baseband hang
check needs to run very frequently, as in some situations, the hangs can
probably occur frequently as well.
- Felix
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Björn Smedman @ 2010-06-29 22:50 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <4C2A6BA4.8080000@openwrt.org>
2010/6/29 Felix Fietkau <nbd@openwrt.org>:
> I had a similar thought about the multiple invocations thing. I think
> that's a good approach in general, but we need to ensure that we make it
> safe.
> The main point of this function is to detect baseband hangs. If we
> experience such a hang, I'm not sure we will always get enough
> interrupts to do multiple consecutive tests.
> One way to make it safe would be to reschedule the tasklet each time we
> ignore the result of the ath9k_hw_check_alive(), that way we keep the
> detection time low as well. Maybe we could also use a timer for leaving
> 10 ms time between attempts.
The xmit logic has sc->tx_complete_work that periodically checks if
the tx is hung and resets the chip if so. Maybe we could refactor that
into a common periodic health checkup task in main.c that could call
into both xmit.c and recv.c? Or does ath9k_hw_check_alive() have to
run in the interrupt context in some way?
> - Felix
/Björn
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Felix Fietkau @ 2010-06-29 21:54 UTC (permalink / raw)
To: Björn Smedman; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTikQz34vgfweDrzH_9_a-BU4dPXbX2UGR61jtJ9n@mail.gmail.com>
On 2010-06-29 11:40 PM, Björn Smedman wrote:
> 2010/6/29 Björn Smedman <bjorn.smedman@venatech.se>:
>> Yes, hw reset is due to reg = 0x01702400 every 4 - 40 seconds or so:
>> ...
>
> When the chip is really stuck, does 'reg' (at 'return false') change
> over time? If I add a second requirement that ath9k_hw_check_alive()
> must fail three times in a row (in different invocations of
> ath9k_tasklet()) before we reset the chip the ap seems fine. I
> sometimes get several of these reg = 0x01702400 every second but only
> one or at the max two in a row.
>
> Under load I sometimes see some reg = 0x00f02400 as well. I also see
> an occasional reset now and then (about once a minute) that must be
> caused by something else.
>
> Any insight into what these reg values mean? Do you think they can
> safely be ignored as per above?
I had a similar thought about the multiple invocations thing. I think
that's a good approach in general, but we need to ensure that we make it
safe.
The main point of this function is to detect baseband hangs. If we
experience such a hang, I'm not sure we will always get enough
interrupts to do multiple consecutive tests.
One way to make it safe would be to reschedule the tasklet each time we
ignore the result of the ath9k_hw_check_alive(), that way we keep the
detection time low as well. Maybe we could also use a timer for leaving
10 ms time between attempts.
Another thing that I'm working on right now is to ensure that the TSF
gets preserved across resets. For some AR9280 based cards the code
already preserves TSF in software over the chip reset, I could simply
extend that to cover SoC as well.
But before I post such a patch, I'll do a test on AR9160 - to see if it
would be better to make the TSF preserve unconditional.
- Felix
^ permalink raw reply
* Re: ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Björn Smedman @ 2010-06-29 21:40 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <AANLkTikw3l6FIxLtIwxofGaqGQD_b7LO25uu-JV45UL6@mail.gmail.com>
2010/6/29 Björn Smedman <bjorn.smedman@venatech.se>:
> Yes, hw reset is due to reg = 0x01702400 every 4 - 40 seconds or so:
> ...
When the chip is really stuck, does 'reg' (at 'return false') change
over time? If I add a second requirement that ath9k_hw_check_alive()
must fail three times in a row (in different invocations of
ath9k_tasklet()) before we reset the chip the ap seems fine. I
sometimes get several of these reg = 0x01702400 every second but only
one or at the max two in a row.
Under load I sometimes see some reg = 0x00f02400 as well. I also see
an occasional reset now and then (about once a minute) that must be
caused by something else.
Any insight into what these reg values mean? Do you think they can
safely be ignored as per above?
/Björn
^ permalink raw reply
* Re: [ath9k-devel] ath9k: ap tsf seems random and only uses lower 24 bits or so
From: Benoit Papillault @ 2010-06-29 21:23 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Björn Smedman, ath9k-devel, linux-wireless
In-Reply-To: <4C29DCC1.2060707@openwrt.org>
Le 29/06/2010 13:45, Felix Fietkau a écrit :
> On 2010-06-29 8:08 AM, Benoit Papillault wrote:
>> Le 29/06/2010 00:55, Felix Fietkau a écrit :
>>> On 2010-06-29 12:31 AM, Björn Smedman wrote:
>>>> Hi all,
>>>>
>>>> I'm getting weird values from the debugfs file ieee80211/phy0/tsf: the
>>>> value goes up and down rather randomly and only the lower 24 bits or
>>>> so seem to ever be used (see below for details).
>>>>
>>>> The only thing running on phy0 is a single ap interface (and the
>>>> monitor companion that hostapd sets up). I was expecting tsf to
>>>> increase monotonically until all 64 bits had been used.
>>>>
>>>> For a moment I thought it might be the kernel snprintf (on mips)
>>>> playing a trick on me so I tried the following patch. But the result
>>>> is the same.
>>> IMHO the most likely problem source is stuck beacons. Please compile the
>>> driver with the debug option enabled and load it with
>>> insmod ath9k debug=0x00000100
>>>
>>> - Felix
>>
>> Humm... I observed a similar behavior a while ago because only the 15
>> lower bits of rstamp were used when being extended (but rstamp is 32
>> bits in fact). If so, it has been fixed by Felix in the following commit :
> Nope, different issue. The TSF extending applies only to rx timestamps,
> however Björn has been observing weird TSF values from the hw register.
> The Rx TSF timestamp is pretty much irrelevant in AP mode.
>
> - Felix
>
Ah, right and.. right! :-)
Sorry for the noise.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH] iwlwifi: do not export iwl_leds_background
From: John W. Linville @ 2010-06-29 20:32 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1277842739.4197.54.camel@rchatre-DESK>
On Tue, Jun 29, 2010 at 01:18:59PM -0700, reinette chatre wrote:
> On Tue, 2010-06-29 at 12:39 -0700, John W. Linville wrote:
> > It is only used from within the iwlcore module.
> >
> > Reported-by: Johannes Berg <johannes@sipsolutions.net>
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > drivers/net/wireless/iwlwifi/iwl-led.c | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/iwlwifi/iwl-led.c b/drivers/net/wireless/iwlwifi/iwl-led.c
> > index db5bfcb..486244b 100644
> > --- a/drivers/net/wireless/iwlwifi/iwl-led.c
> > +++ b/drivers/net/wireless/iwlwifi/iwl-led.c
> > @@ -214,7 +214,6 @@ void iwl_leds_background(struct iwl_priv *priv)
> > priv->last_blink_time = jiffies;
> > priv->last_blink_rate = blink_idx;
> > }
> > -EXPORT_SYMBOL(iwl_leds_background);
> >
> > void iwl_leds_init(struct iwl_priv *priv)
> > {
>
> Nack.
>
> Please take a closer look at how it is used ... it is used in iwl-core.h
> in an inline (iwl_update_stats) function that is used by both iwlagn and
> iwl3945.
OK
--
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
* [PATCH] compat-wireless: refresh patch
From: Hauke Mehrtens @ 2010-06-29 20:36 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/25-multicast-list_head.patch | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/patches/25-multicast-list_head.patch b/patches/25-multicast-list_head.patch
index f7304cb..f3746ca 100644
--- a/patches/25-multicast-list_head.patch
+++ b/patches/25-multicast-list_head.patch
@@ -419,7 +419,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
size_t fw_name_len, u32 *hw_ver);
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
-@@ -1587,7 +1587,11 @@ static void set_multicast_list(struct us
+@@ -1588,7 +1588,11 @@ static void set_multicast_list(struct us
netdev_for_each_mc_addr(ha, usbdev->net)
memcpy(mc_addrs + i++ * ETH_ALEN,
@@ -601,9 +601,9 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
+ memcpy(__skb_put(skb, ETH_ALEN), ha->dmi_addr, ETH_ALEN);
+ memcpy(__skb_put(skb, ETH_ALEN), ha->dmi_addr, ETH_ALEN);
+#endif
+
+ i++;
}
- r->len = htons(skb->len - len);
- }
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -90,14 +90,28 @@ static inline void drv_bss_info_changed(
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] iwlwifi: do not export iwl_leds_background
From: reinette chatre @ 2010-06-29 20:18 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1277840378-18305-1-git-send-email-linville@tuxdriver.com>
On Tue, 2010-06-29 at 12:39 -0700, John W. Linville wrote:
> It is only used from within the iwlcore module.
>
> Reported-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-led.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-led.c b/drivers/net/wireless/iwlwifi/iwl-led.c
> index db5bfcb..486244b 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-led.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-led.c
> @@ -214,7 +214,6 @@ void iwl_leds_background(struct iwl_priv *priv)
> priv->last_blink_time = jiffies;
> priv->last_blink_rate = blink_idx;
> }
> -EXPORT_SYMBOL(iwl_leds_background);
>
> void iwl_leds_init(struct iwl_priv *priv)
> {
Nack.
Please take a closer look at how it is used ... it is used in iwl-core.h
in an inline (iwl_update_stats) function that is used by both iwlagn and
iwl3945.
Reinette
^ permalink raw reply
* [PATCH 21/21] rt2x00: Fix compile warning when debug disabled
From: Ivo van Doorn @ 2010-06-29 19:49 UTC (permalink / raw)
To: John W. Linville
Cc: users, linux-wireless, Helmut Schaa, Gertjan van Wingerde
In-Reply-To: <201006292149.27751.IvDoorn@gmail.com>
From: Ivo van Doorn <IvDoorn@gmail.com>
CC [M] drivers/net/wireless/rt2x00/rt2800lib.o
drivers/net/wireless/rt2x00/rt2800lib.c: In function 'rt2800_ampdu_action':
drivers/net/wireless/rt2x00/rt2800lib.c:2821: warning: unused variable 'rt2x00dev'
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index f813b43..d3cf0cc 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2769,7 +2769,6 @@ static int rt2800_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_sta *sta,
u16 tid, u16 *ssn)
{
- struct rt2x00_dev *rt2x00dev = hw->priv;
int ret = 0;
switch (action) {
@@ -2787,7 +2786,7 @@ static int rt2800_ampdu_action(struct ieee80211_hw *hw,
case IEEE80211_AMPDU_TX_OPERATIONAL:
break;
default:
- WARNING(rt2x00dev, "Unknown AMPDU action\n");
+ WARNING((struct rt2x00_dev *)hw->priv, "Unknown AMPDU action\n");
}
return ret;
--
1.6.6.1
^ permalink raw reply related
* [PATCH 20/21] rt2x00: Always set BBP_CSR_CFG_BBP_RW_MODE to 1
From: Ivo van Doorn @ 2010-06-29 19:49 UTC (permalink / raw)
To: John W. Linville
Cc: users, linux-wireless, Helmut Schaa, Gertjan van Wingerde
In-Reply-To: <201006292149.06304.IvDoorn@gmail.com>
From: Ivo van Doorn <IvDoorn@gmail.com>
Latest rt2870 legacy driver also sets BBP_CSR_CFG_BBP_RW_MODE to 1
when reading or writing the EEPROM. This means we can make the
BBP reading and writing completely equal on all platforms.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 0cf7796..f813b43 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -99,8 +99,7 @@ static void rt2800_bbp_write(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(®, BBP_CSR_CFG_REGNUM, word);
rt2x00_set_field32(®, BBP_CSR_CFG_BUSY, 1);
rt2x00_set_field32(®, BBP_CSR_CFG_READ_CONTROL, 0);
- if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev))
- rt2x00_set_field32(®, BBP_CSR_CFG_BBP_RW_MODE, 1);
+ rt2x00_set_field32(®, BBP_CSR_CFG_BBP_RW_MODE, 1);
rt2800_register_write_lock(rt2x00dev, BBP_CSR_CFG, reg);
}
@@ -128,8 +127,7 @@ static void rt2800_bbp_read(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(®, BBP_CSR_CFG_REGNUM, word);
rt2x00_set_field32(®, BBP_CSR_CFG_BUSY, 1);
rt2x00_set_field32(®, BBP_CSR_CFG_READ_CONTROL, 1);
- if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev))
- rt2x00_set_field32(®, BBP_CSR_CFG_BBP_RW_MODE, 1);
+ rt2x00_set_field32(®, BBP_CSR_CFG_BBP_RW_MODE, 1);
rt2800_register_write_lock(rt2x00dev, BBP_CSR_CFG, reg);
--
1.6.6.1
^ permalink raw reply related
* [PATCH 19/21] rt2x00: Fix antenna initialization
From: Ivo van Doorn @ 2010-06-29 19:49 UTC (permalink / raw)
To: John W. Linville
Cc: users, linux-wireless, Helmut Schaa, Gertjan van Wingerde
In-Reply-To: <201006292148.38803.IvDoorn@gmail.com>
From: Ivo van Doorn <IvDoorn@gmail.com>
Legacy driver indicates that BBP1_TX_ANTENNA must be set
to 0 for TXPATH values of 1 and 3. So the previous statement
that nothing should be done for TXPATH = 3, is false.
Furthermore, remove the false BBP3_RX_ANTENNA initialization
when TXPATH is 1 for PCI and SOC devices. This field will always
be overridden in the next switch statement, making this initialization
bogus. History of this line indicates it was there from the beginning,
and was once caught as typo. Instead of replacing the line with the
correct line, the correct line was added...
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 2d0a216..0cf7796 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -836,14 +836,12 @@ void rt2800_config_ant(struct rt2x00_dev *rt2x00dev, struct antenna_setup *ant)
switch ((int)ant->tx) {
case 1:
rt2x00_set_field8(&r1, BBP1_TX_ANTENNA, 0);
- if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev))
- rt2x00_set_field8(&r3, BBP3_RX_ANTENNA, 0);
break;
case 2:
rt2x00_set_field8(&r1, BBP1_TX_ANTENNA, 2);
break;
case 3:
- /* Do nothing */
+ rt2x00_set_field8(&r1, BBP1_TX_ANTENNA, 0);
break;
}
--
1.6.6.1
^ permalink raw reply related
* [PATCH 18/21] rt2x00: Fix IEEE80211_HT_CAP_RX_STBC assignment
From: Ivo van Doorn @ 2010-06-29 19:48 UTC (permalink / raw)
To: John W. Linville
Cc: users, linux-wireless, Helmut Schaa, Gertjan van Wingerde
In-Reply-To: <201006292148.07594.IvDoorn@gmail.com>
From: Ivo van Doorn <IvDoorn@gmail.com>
IEEE80211_HT_CAP_RX_STBC is a 2 bit flag, and should thus
never be set as normal flag. Instead we must read the number
of RX paths from the EEPROM and set the IEEE80211_HT_CAP_RX_STBC
with the correct value (using the same logic as the number of TX
streams).
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 5125315..2d0a216 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2572,12 +2572,15 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
IEEE80211_HT_CAP_GRN_FLD |
IEEE80211_HT_CAP_SGI_20 |
- IEEE80211_HT_CAP_SGI_40 |
- IEEE80211_HT_CAP_RX_STBC;
+ IEEE80211_HT_CAP_SGI_40;
if (rt2x00_get_field16(eeprom, EEPROM_ANTENNA_TXPATH) >= 2)
spec->ht.cap |= IEEE80211_HT_CAP_TX_STBC;
+ spec->ht.cap |=
+ rt2x00_get_field16(eeprom, EEPROM_ANTENNA_RXPATH) <<
+ IEEE80211_HT_CAP_RX_STBC_SHIFT;
+
spec->ht.ampdu_factor = 3;
spec->ht.ampdu_density = 4;
spec->ht.mcs.tx_params =
--
1.6.6.1
^ permalink raw reply related
* [PATCH 17/21] rt2x00: fix beacon reset on rt2800
From: Ivo van Doorn @ 2010-06-29 19:48 UTC (permalink / raw)
To: John W. Linville
Cc: users, linux-wireless, Helmut Schaa, Gertjan van Wingerde
In-Reply-To: <201006292147.38367.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
When an interface is removed the according beacon entry should be reset.
The current approach to only clear the first word is not enough to stop
the device from sending out the beacon, hence resulting in beacons being
sent out for already removed interfaces.
Fix this by invalidating the entire TXWI in front of the beacon instead
of only the first word.
Also clear all beacons during startup in the same way.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 42 +++++++++++++++++-------------
1 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index f7e9e76..5125315 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -432,6 +432,20 @@ void rt2800_write_beacon(struct queue_entry *entry, struct txentry_desc *txdesc)
}
EXPORT_SYMBOL(rt2800_write_beacon);
+static void inline rt2800_clear_beacon(struct rt2x00_dev *rt2x00dev,
+ unsigned int beacon_base)
+{
+ int i;
+
+ /*
+ * For the Beacon base registers we only need to clear
+ * the whole TXWI which (when set to 0) will invalidate
+ * the entire beacon.
+ */
+ for (i = 0; i < TXWI_DESC_SIZE; i += sizeof(__le32))
+ rt2800_register_write(rt2x00dev, beacon_base + i, 0);
+}
+
#ifdef CONFIG_RT2X00_LIB_DEBUGFS
const struct rt2x00debug rt2800_rt2x00debug = {
.owner = THIS_MODULE,
@@ -733,19 +747,14 @@ EXPORT_SYMBOL_GPL(rt2800_config_filter);
void rt2800_config_intf(struct rt2x00_dev *rt2x00dev, struct rt2x00_intf *intf,
struct rt2x00intf_conf *conf, const unsigned int flags)
{
- unsigned int beacon_base;
u32 reg;
if (flags & CONFIG_UPDATE_TYPE) {
/*
* Clear current synchronisation setup.
- * For the Beacon base registers we only need to clear
- * the first byte since that byte contains the VALID and OWNER
- * bits which (when set to 0) will invalidate the entire beacon.
*/
- beacon_base = HW_BEACON_OFFSET(intf->beacon->entry_idx);
- rt2800_register_write(rt2x00dev, beacon_base, 0);
-
+ rt2800_clear_beacon(rt2x00dev,
+ HW_BEACON_OFFSET(intf->beacon->entry_idx));
/*
* Enable synchronisation.
*/
@@ -1565,18 +1574,15 @@ int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
/*
* Clear all beacons
- * For the Beacon base registers we only need to clear
- * the first byte since that byte contains the VALID and OWNER
- * bits which (when set to 0) will invalidate the entire beacon.
*/
- rt2800_register_write(rt2x00dev, HW_BEACON_BASE0, 0);
- rt2800_register_write(rt2x00dev, HW_BEACON_BASE1, 0);
- rt2800_register_write(rt2x00dev, HW_BEACON_BASE2, 0);
- rt2800_register_write(rt2x00dev, HW_BEACON_BASE3, 0);
- rt2800_register_write(rt2x00dev, HW_BEACON_BASE4, 0);
- rt2800_register_write(rt2x00dev, HW_BEACON_BASE5, 0);
- rt2800_register_write(rt2x00dev, HW_BEACON_BASE6, 0);
- rt2800_register_write(rt2x00dev, HW_BEACON_BASE7, 0);
+ rt2800_clear_beacon(rt2x00dev, HW_BEACON_BASE0);
+ rt2800_clear_beacon(rt2x00dev, HW_BEACON_BASE1);
+ rt2800_clear_beacon(rt2x00dev, HW_BEACON_BASE2);
+ rt2800_clear_beacon(rt2x00dev, HW_BEACON_BASE3);
+ rt2800_clear_beacon(rt2x00dev, HW_BEACON_BASE4);
+ rt2800_clear_beacon(rt2x00dev, HW_BEACON_BASE5);
+ rt2800_clear_beacon(rt2x00dev, HW_BEACON_BASE6);
+ rt2800_clear_beacon(rt2x00dev, HW_BEACON_BASE7);
if (rt2x00_is_usb(rt2x00dev)) {
rt2800_register_read(rt2x00dev, US_CYC_CNT, ®);
--
1.6.6.1
^ permalink raw reply related
* [PATCH 16/21] rt2x00: Disable link tuning in AP mode
From: Ivo van Doorn @ 2010-06-29 19:47 UTC (permalink / raw)
To: John W. Linville
Cc: users, linux-wireless, Helmut Schaa, Gertjan van Wingerde
In-Reply-To: <201006292147.11774.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
Since the link tuning is based on average RSSI values taken from all received
frames it doesn't make sense to enable it in AP mode where every associated
station provides independent RSSI values. Furthermore the legacy drivers
don't enable link tuning in AP mode as well.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2x00link.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00link.c b/drivers/net/wireless/rt2x00/rt2x00link.c
index 0efbf5a..2f8136c 100644
--- a/drivers/net/wireless/rt2x00/rt2x00link.c
+++ b/drivers/net/wireless/rt2x00/rt2x00link.c
@@ -271,11 +271,11 @@ void rt2x00link_start_tuner(struct rt2x00_dev *rt2x00dev)
/*
* Link tuning should only be performed when
- * an active sta or master interface exists.
- * Single monitor mode interfaces should never have
- * work with link tuners.
+ * an active sta interface exists. AP interfaces
+ * don't need link tuning and monitor mode interfaces
+ * should never have to work with link tuners.
*/
- if (!rt2x00dev->intf_ap_count && !rt2x00dev->intf_sta_count)
+ if (!rt2x00dev->intf_sta_count)
return;
rt2x00link_reset_tuner(rt2x00dev, false);
--
1.6.6.1
^ permalink raw reply related
* [PATCH 15/21] rt2x00: Fix beacon updates in rt61pci
From: Ivo van Doorn @ 2010-06-29 19:47 UTC (permalink / raw)
To: John W. Linville
Cc: users, linux-wireless, Helmut Schaa, Gertjan van Wingerde
In-Reply-To: <201006292146.44952.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
Fix rt61pci beacon updates in the same way as rt2800pci. rt61pci didn't
update the beacon template after each beacon interval, resulting in the
DTIM count being incorrect (if DTIM period > 1). Fix this by calling
rt2x00lib_beacondone after the current beacon was sent out.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt61pci.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 1e74f8c..0123fbc 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2200,6 +2200,12 @@ static irqreturn_t rt61pci_interrupt(int irq, void *dev_instance)
if (rt2x00_get_field32(reg_mcu, MCU_INT_SOURCE_CSR_TWAKEUP))
rt61pci_wakeup(rt2x00dev);
+ /*
+ * 5 - Beacon done interrupt.
+ */
+ if (rt2x00_get_field32(reg, INT_SOURCE_CSR_BEACON_DONE))
+ rt2x00lib_beacondone(rt2x00dev);
+
return IRQ_HANDLED;
}
--
1.6.6.1
^ permalink raw reply related
* [PATCH 07/21] rt2x00: Move common txdone handling to rt2x00lib_txdone.
From: Ivo van Doorn @ 2010-06-29 19:41 UTC (permalink / raw)
To: John W. Linville
Cc: users, linux-wireless, Helmut Schaa, Gertjan van Wingerde
In-Reply-To: <201006292141.07070.IvDoorn@gmail.com>
From: Gertjan van Wingerde <gwingerde@gmail.com>
Now that the write_tx_data functions are merged, also merge the relevant
parts of the txdone handling into common code, rather than {usb,pci}
specific code.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2400pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 15 +++++++++++++++
drivers/net/wireless/rt2x00/rt2x00pci.c | 31 -------------------------------
drivers/net/wireless/rt2x00/rt2x00pci.h | 8 --------
drivers/net/wireless/rt2x00/rt2x00usb.c | 11 -----------
drivers/net/wireless/rt2x00/rt61pci.c | 4 ++--
8 files changed, 20 insertions(+), 55 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index 1ad3596..3bedf56 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1229,7 +1229,7 @@ static void rt2400pci_txdone(struct rt2x00_dev *rt2x00dev,
}
txdesc.retry = rt2x00_get_field32(word, TXD_W0_RETRY_COUNT);
- rt2x00pci_txdone(entry, &txdesc);
+ rt2x00lib_txdone(entry, &txdesc);
}
}
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 2771ae7..69d231d 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1365,7 +1365,7 @@ static void rt2500pci_txdone(struct rt2x00_dev *rt2x00dev,
}
txdesc.retry = rt2x00_get_field32(word, TXD_W0_RETRY_COUNT);
- rt2x00pci_txdone(entry, &txdesc);
+ rt2x00lib_txdone(entry, &txdesc);
}
}
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index 615a865..894a43a 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -905,7 +905,7 @@ static void rt2800pci_txdone(struct rt2x00_dev *rt2x00dev)
if (txdesc.retry)
__set_bit(TXDONE_FALLBACK, &txdesc.flags);
- rt2x00pci_txdone(entry, &txdesc);
+ rt2x00lib_txdone(entry, &txdesc);
}
}
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index a914855..12ee7bd 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -211,6 +211,21 @@ void rt2x00lib_txdone(struct queue_entry *entry,
bool success;
/*
+ * Unmap the skb.
+ */
+ rt2x00queue_unmap_skb(rt2x00dev, entry->skb);
+
+ /*
+ * Remove the extra tx headroom from the skb.
+ */
+ skb_pull(entry->skb, rt2x00dev->ops->extra_tx_headroom);
+
+ /*
+ * Signal that the TX descriptor is no longer in the skb.
+ */
+ skbdesc->flags &= ~SKBDESC_DESC_IN_SKB;
+
+ /*
* Remove L2 padding which was added during
*/
if (test_bit(DRIVER_REQUIRE_L2PAD, &rt2x00dev->flags))
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index 1c9ccc3..fc9da83 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
@@ -60,37 +60,6 @@ int rt2x00pci_regbusy_read(struct rt2x00_dev *rt2x00dev,
}
EXPORT_SYMBOL_GPL(rt2x00pci_regbusy_read);
-/*
- * TX/RX data handlers.
- */
-void rt2x00pci_txdone(struct queue_entry *entry,
- struct txdone_entry_desc *txdesc)
-{
- struct rt2x00_dev *rt2x00dev = entry->queue->rt2x00dev;
- struct skb_frame_desc *skbdesc = get_skb_frame_desc(entry->skb);
-
- /*
- * Unmap the skb.
- */
- rt2x00queue_unmap_skb(rt2x00dev, entry->skb);
-
- /*
- * Remove the extra tx headroom from the skb.
- */
- skb_pull(entry->skb, rt2x00dev->ops->extra_tx_headroom);
-
- /*
- * Signal that the TX descriptor is no longer in the skb.
- */
- skbdesc->flags &= ~SKBDESC_DESC_IN_SKB;
-
- /*
- * Pass on to rt2x00lib.
- */
- rt2x00lib_txdone(entry, txdesc);
-}
-EXPORT_SYMBOL_GPL(rt2x00pci_txdone);
-
void rt2x00pci_rxdone(struct rt2x00_dev *rt2x00dev)
{
struct data_queue *queue = rt2x00dev->rx;
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.h b/drivers/net/wireless/rt2x00/rt2x00pci.h
index 2dca185..b854d62 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.h
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.h
@@ -99,14 +99,6 @@ struct queue_entry_priv_pci {
};
/**
- * rt2x00pci_txdone - Handle TX done events.
- * @entry: The queue entry for which a TX done event was received.
- * @txdesc: The TX done descriptor for the entry.
- */
-void rt2x00pci_txdone(struct queue_entry *entry,
- struct txdone_entry_desc *txdesc);
-
-/**
* rt2x00pci_rxdone - Handle RX done events
* @rt2x00dev: Device pointer, see &struct rt2x00_dev.
*/
diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c
index f78ebb4..a22837c 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -171,7 +171,6 @@ static void rt2x00usb_interrupt_txdone(struct urb *urb)
{
struct queue_entry *entry = (struct queue_entry *)urb->context;
struct rt2x00_dev *rt2x00dev = entry->queue->rt2x00dev;
- struct skb_frame_desc *skbdesc = get_skb_frame_desc(entry->skb);
struct txdone_entry_desc txdesc;
if (!test_bit(DEVICE_STATE_ENABLED_RADIO, &rt2x00dev->flags) ||
@@ -179,16 +178,6 @@ static void rt2x00usb_interrupt_txdone(struct urb *urb)
return;
/*
- * Remove the descriptor from the front of the skb.
- */
- skb_pull(entry->skb, entry->queue->desc_size);
-
- /*
- * Signal that the TX descriptor is no longer in the skb.
- */
- skbdesc->flags &= ~SKBDESC_DESC_IN_SKB;
-
- /*
* Obtain the status about this packet.
* Note that when the status is 0 it does not mean the
* frame was send out correctly. It only means the frame
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index cb6e20a..1e74f8c 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2108,7 +2108,7 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
__set_bit(TXDONE_UNKNOWN, &txdesc.flags);
txdesc.retry = 0;
- rt2x00pci_txdone(entry_done, &txdesc);
+ rt2x00lib_txdone(entry_done, &txdesc);
entry_done = rt2x00queue_get_entry(queue, Q_INDEX_DONE);
}
@@ -2135,7 +2135,7 @@ static void rt61pci_txdone(struct rt2x00_dev *rt2x00dev)
if (txdesc.retry)
__set_bit(TXDONE_FALLBACK, &txdesc.flags);
- rt2x00pci_txdone(entry, &txdesc);
+ rt2x00lib_txdone(entry, &txdesc);
}
}
--
1.6.6.1
^ permalink raw reply related
* [PATCH 14/21] rt2x00: Fix beacon updates in rt2800pci
From: Ivo van Doorn @ 2010-06-29 19:46 UTC (permalink / raw)
To: John W. Linville
Cc: users, linux-wireless, Helmut Schaa, Gertjan van Wingerde
In-Reply-To: <201006292145.32554.IvDoorn@gmail.com>
From: Helmut Schaa <helmut.schaa@googlemail.com>
rt2800pci didn't update the beacon template after each beacon interval,
resulting in the DTIM count being incorrect (if DTIM period > 1). Fix this
by calling rt2x00lib_beacondone after the current beacon was sent out.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800pci.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index b48b949..6f11760 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -953,6 +953,12 @@ static irqreturn_t rt2800pci_interrupt(int irq, void *dev_instance)
if (rt2x00_get_field32(reg, INT_SOURCE_CSR_TX_FIFO_STATUS))
rt2800pci_txdone(rt2x00dev);
+ /*
+ * Current beacon was sent out, fetch the next one
+ */
+ if (rt2x00_get_field32(reg, INT_SOURCE_CSR_TBTT))
+ rt2x00lib_beacondone(rt2x00dev);
+
if (rt2x00_get_field32(reg, INT_SOURCE_CSR_AUTO_WAKEUP))
rt2800pci_wakeup(rt2x00dev);
--
1.6.6.1
^ permalink raw reply related
* [PATCH 13/21] rt2x00: Enable multiBSS in rt2800
From: Ivo van Doorn @ 2010-06-29 19:45 UTC (permalink / raw)
To: John W. Linville
Cc: users, linux-wireless, Helmut Schaa, Gertjan van Wingerde
In-Reply-To: <201006292144.51636.IvDoorn@gmail.com>
From: Ivo van Doorn <IvDoorn@gmail.com>
MAC_BSSID_DW1_BSS_ID_MASK must be set to the mask 3, to
enable 8 BSSID's. The MAC_BSSID_DW1_BSS_BCN_NUM is initialized
to 7 to enable the 8 beacons.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Tested-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index f25997e..f7e9e76 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -768,8 +768,8 @@ void rt2800_config_intf(struct rt2x00_dev *rt2x00dev, struct rt2x00_intf *intf,
if (flags & CONFIG_UPDATE_BSSID) {
reg = le32_to_cpu(conf->bssid[1]);
- rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_ID_MASK, 0);
- rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_BCN_NUM, 0);
+ rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_ID_MASK, 3);
+ rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_BCN_NUM, 7);
conf->bssid[1] = cpu_to_le32(reg);
rt2800_register_multiwrite(rt2x00dev, MAC_BSSID_DW0,
--
1.6.6.1
^ permalink raw reply related
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