* Re: Problems connectring to an AP with Acer Aspire Revo
From: reinette chatre @ 2010-06-04 16:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: Christian P. Schmidt, linux-wireless@vger.kernel.org
In-Reply-To: <1275634104.3694.0.camel@jlt3.sipsolutions.net>
On Thu, 2010-06-03 at 23:48 -0700, Johannes Berg wrote:
> On Thu, 2010-06-03 at 17:56 +0200, Christian P. Schmidt wrote:
>
> > > Maybe try the rfkill tool:
> > > http://wireless.kernel.org/en/users/Documentation/rfkill
> >
> > Yes, it was the rfkill tool that caused my attempts to fail. However,
> > this didn't change my association attempt problems.
> > I also took my time to look at the PCIe port - steady 3.3V on the RFKILL
> > pin, which means "no RFKILL".
> >
> > Any further ideas?
>
> Unfortunately not. It would seem that something is causing your frames
> not to be transmitted correctly, but I see no reason for that right now.
The logs provided contains a lot of useful information. Among this is
that the device is unable to transmit data with the firmware returning a
"TX_LOCKED" status. From what I understand this is a regulatory check
failure based on the channel type, which does not make sense in this
regard since from what I can tell channel 8, which is an active channel,
is used. I passed this question to our firmware folks and now waiting
for an answer.
Reinette
^ permalink raw reply
* Re: [PATCH] iwlwifi: recalculate average tpt if not current
From: Nils Radtke @ 2010-06-04 16:32 UTC (permalink / raw)
To: linville; +Cc: reinette.chatre, linux-kernel, linux-wireless
Hi John,
http://marc.info/?l=linux-wireless&m=127317062320707&w=2 :
> > > The BUG_ON was introduced by:
> > > commit 3110bef78cb4282c58245bc8fd6d95d9ccb19749
> > > Author: Guy Cohen <guy.cohen@intel.com>
> > > Date: Tue Sep 9 10:54:54 2008 +0800
> > >
> > > iwlwifi: Added support for 3 antennas
> > >
> > > ... the portion adding the BUG_ON is reverted since we are encountering the error
> > > and BUG_ON was created with assumption that error is not encountered.
> > >
> > > Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> > > ---
> >
> > I noticed this patch in your wireless-next-2.6 pull request. Since it is
> > addressing a system hang issue, could it perhaps be included in
> > wireless-2.6 also? I should have included the bug report reference for
> > this purpose, sorry ... it is
> > https://bugzilla.redhat.com/show_bug.cgi?id=588021
>
> I didn't send it that way because a) that code has been there for a
> really long time; and b) the reporter couldn't reliably reproduce
> the bug and therefore can't reliably test the fix. While I agree
> that the fix looks harmless, no update is zero-risk.
>
> Can you reliably hit that code? Has it been tested enough that we
> should risk holding-up 2.6.34's release for it?
I'm one of those _very reliably_ hitting this BUG. I can tell how
annoying it is. I have to backport the patch w/ every kernel release
to be able to use the wireless link _at all_. So please consider
it as somewhat urgent to get the patch included.
I'm still in contact w/ Reinette regularly to get those problems fixed.
It involves physically moving around the city for testing any modification
so this working is slowly processing as it takes every time an enormous
amount of time to do so. Work in (slow) progress, but it's alive..
C.f. http://permalink.gmane.org/gmane.linux.kernel/992941
BTW, https://bugzilla.redhat.com/show_bug.cgi?id=588021 this isn't fixed.
Maybe RH did fix it. kernel.org sources haven't. This is a blocker ever
since.
Cheers,
Nils
^ permalink raw reply
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Pavel Roskin @ 2010-06-04 16:22 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: ath5k-devel, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
Bob Copeland, John W. Linville, GeunSik Lim, Greg Kroah-Hartman,
Lukas Turek, Mark Hindley, Johannes Berg, Jiri Kosina, Kalle Valo,
Keng-Yu Lin, Luca Verdesca, Shahar Or, linux-wireless, netdev,
linux-kernel
In-Reply-To: <4c0902ef.0a41df0a.6c86.2df0@mx.google.com>
On Fri, 2010-06-04 at 16:43 +0300, Dmytro Milinevskyy wrote:
> Hi!
>
> Here is the patch to disable ath5k leds support on build stage.
> However if the leds support was enabled do not force selection of 802.11 leds layer.
> Depency on LEDS_CLASS is kept.
>
> Suggestion given by Pavel Roskin and Bob Copeland applied.
It's great that you did it. The patch is much clearer now. That makes
smaller issues visible. Please don't be discouraged by the criticism,
you are on the right track.
First of all, your patch doesn't apply cleanly to the current
wireless-testing because of formatting changes in Makefile. Please
update.
> +config ATH5K_LEDS
> + tristate "Atheros 5xxx wireless cards LEDs support"
> + depends on ATH5K
> + select NEW_LEDS
> + select LEDS_CLASS
> + ---help---
> + Atheros 5xxx LED support.
"tristate" is wrong here. "tristate" would allow users select "m",
which is wrong, since LED support is not a separate module. I think you
want "bool" here.
> +#ifdef CONFIG_ATH5K_LEDS
> /*
> * State for LED triggers
> */
> @@ -95,6 +96,7 @@ struct ath5k_led
> struct ath5k_softc *sc; /* driver state */
> struct led_classdev led_dev; /* led classdev */
> };
> +#endif
This shouldn't be needed. I'll rather see a structure that is not used
in some cases than an extra pair of preprocessor conditionals.
> diff --git a/drivers/net/wireless/ath/ath5k/gpio.c b/drivers/net/wireless/ath/ath5k/gpio.c
> index 64a27e7..9e757b3 100644
> --- a/drivers/net/wireless/ath/ath5k/gpio.c
> +++ b/drivers/net/wireless/ath/ath5k/gpio.c
> @@ -25,6 +25,7 @@
> #include "debug.h"
> #include "base.h"
>
> +#ifdef CONFIG_ATH5K_LEDS
> /*
> * Set led state
> */
> @@ -76,6 +77,7 @@ void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
> else
> AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG, led_5210);
> }
> +#endif
I would just move that function to led.c (and don't forget to include
reg.h). The Makefile should take care of the rest.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Strange ACK Behaviour with ath9k
From: Felix Fietkau @ 2010-06-04 15:52 UTC (permalink / raw)
To: Roberto Riggio; +Cc: linux-wireless
In-Reply-To: <AANLkTik03jIq7xEzdY0FF3LQHI_Zqeu_unbI3CJbUqu-@mail.gmail.com>
On 2010-06-04 5:02 PM, Roberto Riggio wrote:
> On Fri, Jun 4, 2010 at 5:00 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>> Are you using 2.4 or 5 GHz?
>
> 5 GHz
Did you test a recent version of wireless-testing/compat-wireless?
IIRC versions before the AR9300 merge had some bugs/inconsistencies in
the fast clock handling for 5 GHz.
- Felix
^ permalink raw reply
* Re: Strange ACK Behaviour with ath9k
From: Roberto Riggio @ 2010-06-04 15:02 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <4C09151C.7040509@openwrt.org>
On Fri, Jun 4, 2010 at 5:00 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> Are you using 2.4 or 5 GHz?
5 GHz
> - Felix
R.
^ permalink raw reply
* Re: Strange ACK Behaviour with ath9k
From: Felix Fietkau @ 2010-06-04 15:00 UTC (permalink / raw)
To: Roberto Riggio; +Cc: linux-wireless
In-Reply-To: <loom.20100604T153747-904@post.gmane.org>
On 2010-06-04 3:59 PM, Roberto Riggio wrote:
>
>> On 05/14/2010 01:15 AM, Björn Smedman wrote:
>> > Hi Roberto,
>> >
>> > When I've seen this it has been caused by a mismatch between the
>> > addresses in the injected frame and that configured in the hardware.
>> > The transmitting radio doesn't understand it is the intended recipient
>> > of the ack and continues retrying.
>
> It seems that the problem is related to the ack timeout. The strange thing is
> that if is use (on the transmitter)
>
> iw phy phy0 set distance 600
>
> everything works fine
>
> however if I use:
>
> iw phy phy0 set distance 300
>
> ack are ignored.
Are you using 2.4 or 5 GHz?
- Felix
^ permalink raw reply
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: John W. Linville @ 2010-06-04 14:09 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Bob Copeland,
GeunSik Lim, Greg Kroah-Hartman, Lukas Turek, Mark Hindley,
Johannes Berg, Jiri Kosina, Kalle Valo, Keng-Yu Lin,
Luca Verdesca, Shahar Or, linux-wireless, netdev, linux-kernel
In-Reply-To: <4c0804e2.0c3ddf0a.2771.10f7@mx.google.com>
On Thu, Jun 03, 2010 at 10:39:30PM +0300, Dmytro Milinevskyy wrote:
> Hi!
>
> Here is the patch to disable ath5k leds support on build stage.
> However if the leds support was enabled do not force selection of 802.11 leds layer.
> Depency on LEDS_CLASS is kept.
>
> Suggestion given by Pavel Roskin and Bob Copeland applied.
>
> Regards,
>
> --Dima
Needs at least a Signed-off-by line, and preferrably a changelog that
explains what the patch is doing and (especially) why it is necessary.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Strange ACK Behaviour with ath9k
From: Roberto Riggio @ 2010-06-04 13:59 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4BEE684F.2070707@create-net.org>
> On 05/14/2010 01:15 AM, Björn Smedman wrote:
> > Hi Roberto,
> >
> > When I've seen this it has been caused by a mismatch between the
> > addresses in the injected frame and that configured in the hardware.
> > The transmitting radio doesn't understand it is the intended recipient
> > of the ack and continues retrying.
It seems that the problem is related to the ack timeout. The strange thing is
that if is use (on the transmitter)
iw phy phy0 set distance 600
everything works fine
however if I use:
iw phy phy0 set distance 300
ack are ignored.
R.
^ permalink raw reply
* [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-04 13:43 UTC (permalink / raw)
To: ath5k-devel
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Bob Copeland,
John W. Linville, GeunSik Lim, Greg Kroah-Hartman, Lukas Turek,
Mark Hindley, Johannes Berg, Jiri Kosina, Kalle Valo, Keng-Yu Lin,
Luca Verdesca, Shahar Or, linux-wireless, netdev, linux-kernel
Hi!
Here is the patch to disable ath5k leds support on build stage.
However if the leds support was enabled do not force selection of 802.11 leds layer.
Depency on LEDS_CLASS is kept.
Suggestion given by Pavel Roskin and Bob Copeland applied.
Regards,
--Dima
---
drivers/net/wireless/ath/ath5k/Kconfig | 12 +++++++++---
drivers/net/wireless/ath/ath5k/Makefile | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 22 ++++++++++++++++++++++
drivers/net/wireless/ath/ath5k/base.h | 13 +++++++++----
drivers/net/wireless/ath/ath5k/gpio.c | 2 ++
5 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/Kconfig b/drivers/net/wireless/ath/ath5k/Kconfig
index eb83b7b..29f4572 100644
--- a/drivers/net/wireless/ath/ath5k/Kconfig
+++ b/drivers/net/wireless/ath/ath5k/Kconfig
@@ -1,9 +1,6 @@
config ATH5K
tristate "Atheros 5xxx wireless cards support"
depends on PCI && MAC80211
- select MAC80211_LEDS
- select LEDS_CLASS
- select NEW_LEDS
---help---
This module adds support for wireless adapters based on
Atheros 5xxx chipset.
@@ -18,6 +15,15 @@ config ATH5K
If you choose to build a module, it'll be called ath5k. Say M if
unsure.
+
+config ATH5K_LEDS
+ tristate "Atheros 5xxx wireless cards LEDs support"
+ depends on ATH5K
+ select NEW_LEDS
+ select LEDS_CLASS
+ ---help---
+ Atheros 5xxx LED support.
+
config ATH5K_DEBUG
bool "Atheros 5xxx debugging"
depends on ATH5K
diff --git a/drivers/net/wireless/ath/ath5k/Makefile b/drivers/net/wireless/ath/ath5k/Makefile
index cc09595..6d552dd 100644
--- a/drivers/net/wireless/ath/ath5k/Makefile
+++ b/drivers/net/wireless/ath/ath5k/Makefile
@@ -10,8 +10,8 @@ ath5k-y += phy.o
ath5k-y += reset.o
ath5k-y += attach.o
ath5k-y += base.o
-ath5k-y += led.o
ath5k-y += rfkill.o
ath5k-y += ani.o
ath5k-$(CONFIG_ATH5K_DEBUG) += debug.o
+ath5k-$(CONFIG_ATH5K_LEDS) += led.o
obj-$(CONFIG_ATH5K) += ath5k.o
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 2785946..bb7e09a 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1148,11 +1148,27 @@ struct ath5k_hw {
int ath5k_hw_attach(struct ath5k_softc *sc);
void ath5k_hw_detach(struct ath5k_hw *ah);
+#ifdef CONFIG_ATH5K_LEDS
/* LED functions */
int ath5k_init_leds(struct ath5k_softc *sc);
void ath5k_led_enable(struct ath5k_softc *sc);
void ath5k_led_off(struct ath5k_softc *sc);
void ath5k_unregister_leds(struct ath5k_softc *sc);
+#else
+static inline int ath5k_init_leds(struct ath5k_softc *sc)
+{
+ return 0;
+}
+static inline void ath5k_led_enable(struct ath5k_softc *sc)
+{
+}
+static inline void ath5k_led_off(struct ath5k_softc *sc)
+{
+}
+static inline void ath5k_unregister_leds(struct ath5k_softc *sc)
+{
+}
+#endif
/* Reset Functions */
int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial);
@@ -1233,7 +1249,13 @@ int ath5k_hw_set_slot_time(struct ath5k_hw *ah, unsigned int slot_time);
int ath5k_hw_init_desc_functions(struct ath5k_hw *ah);
/* GPIO Functions */
+#ifdef CONFIG_ATH5K_LEDS
void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state);
+#else
+static inline void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
+{
+}
+#endif
int ath5k_hw_set_gpio_input(struct ath5k_hw *ah, u32 gpio);
int ath5k_hw_set_gpio_output(struct ath5k_hw *ah, u32 gpio);
u32 ath5k_hw_get_gpio(struct ath5k_hw *ah, u32 gpio);
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index 56221bc..97b26c1 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -86,6 +86,7 @@ struct ath5k_txq {
#define ATH5K_LED_MAX_NAME_LEN 31
+#ifdef CONFIG_ATH5K_LEDS
/*
* State for LED triggers
*/
@@ -95,6 +96,7 @@ struct ath5k_led
struct ath5k_softc *sc; /* driver state */
struct led_classdev led_dev; /* led classdev */
};
+#endif
/* Rfkill */
struct ath5k_rfkill {
@@ -186,9 +188,6 @@ struct ath5k_softc {
u8 bssidmask[ETH_ALEN];
- unsigned int led_pin, /* GPIO pin for driving LED */
- led_on; /* pin setting for LED on */
-
struct tasklet_struct restq; /* reset tasklet */
unsigned int rxbufsize; /* rx size based on mtu */
@@ -196,7 +195,6 @@ struct ath5k_softc {
spinlock_t rxbuflock;
u32 *rxlink; /* link ptr in last RX desc */
struct tasklet_struct rxtq; /* rx intr tasklet */
- struct ath5k_led rx_led; /* rx led */
struct list_head txbuf; /* transmit buffer */
spinlock_t txbuflock;
@@ -204,7 +202,14 @@ struct ath5k_softc {
struct ath5k_txq txqs[AR5K_NUM_TX_QUEUES]; /* tx queues */
struct ath5k_txq *txq; /* main tx queue */
struct tasklet_struct txtq; /* tx intr tasklet */
+
+
+#ifdef CONFIG_ATH5K_LEDS
+ unsigned int led_pin, /* GPIO pin for driving LED */
+ led_on; /* pin setting for LED on */
+ struct ath5k_led rx_led; /* rx led */
struct ath5k_led tx_led; /* tx led */
+#endif
struct ath5k_rfkill rf_kill;
diff --git a/drivers/net/wireless/ath/ath5k/gpio.c b/drivers/net/wireless/ath/ath5k/gpio.c
index 64a27e7..9e757b3 100644
--- a/drivers/net/wireless/ath/ath5k/gpio.c
+++ b/drivers/net/wireless/ath/ath5k/gpio.c
@@ -25,6 +25,7 @@
#include "debug.h"
#include "base.h"
+#ifdef CONFIG_ATH5K_LEDS
/*
* Set led state
*/
@@ -76,6 +77,7 @@ void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
else
AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG, led_5210);
}
+#endif
/*
* Set GPIO inputs
--
1.7.1
^ permalink raw reply related
* [PATCH] ath5k: retain promiscuous setting
From: Bob Copeland @ 2010-06-04 12:14 UTC (permalink / raw)
To: linville
Cc: linux-wireless, ath5k-devel, weedy2887, sidhayn, Bob Copeland,
stable
Commit 56d1de0a21db28e41741cfa0a66e18bc8d920554, "ath5k: clean up
filter flags setting" introduced a regression in monitor mode such
that the promisc filter flag would get lost.
Although we set the promisc flag when it changed, we did not
preserve it across subsequent calls to configure_filter. This patch
restores the original functionality.
Cc: stable@kernel.org
Bisected-by: weedy2887@gmail.com
Tested-by: weedy2887@gmail.com
Tested-by: Rick Farina <sidhayn@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/base.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9c27623..9e023b8 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -3153,13 +3153,15 @@ static void ath5k_configure_filter(struct ieee80211_hw *hw,
if (changed_flags & (FIF_PROMISC_IN_BSS | FIF_OTHER_BSS)) {
if (*new_flags & FIF_PROMISC_IN_BSS) {
- rfilt |= AR5K_RX_FILTER_PROM;
__set_bit(ATH_STAT_PROMISC, sc->status);
} else {
__clear_bit(ATH_STAT_PROMISC, sc->status);
}
}
+ if (test_bit(ATH_STAT_PROMISC, sc->status))
+ rfilt |= AR5K_RX_FILTER_PROM;
+
/* Note, AR5K_RX_FILTER_MCAST is already enabled */
if (*new_flags & FIF_ALLMULTI) {
mfilt[0] = ~0;
--
1.6.3.3
^ permalink raw reply related
* Re: rt2800, minstrel_ht & mac80211
From: Helmut Schaa @ 2010-06-04 10:32 UTC (permalink / raw)
To: Johannes Berg
Cc: Felix Fietkau, Ivo van Doorn, Gertjan van Wingerde,
linux-wireless
In-Reply-To: <1275647301.9953.20.camel@jlt3.sipsolutions.net>
Am Freitag 04 Juni 2010 schrieb Johannes Berg:
> On Fri, 2010-06-04 at 12:22 +0200, Helmut Schaa wrote:
>
> > This meant that minstrel most of the time selected MCS15 as tx rate which
> > resulted in a huge number of retries and thus a very slow throughput.
> >
> > status.c:
> >
> > 178 /* the HW cannot have attempted that rate */
> > 179 if (i >= hw->max_rates) {
> > 180 info->status.rates[i].idx = -1;
> > 181 info->status.rates[i].count = 0;
> >
> > Johannes, is there a valid reason for this check in status.c. Can we remove
> > it without breaking anything else?
>
> IIRC there were/are some drivers that were not terminating the rates[]
> array correctly with a -1, thus this code.
Understood, so it's a driver workaround ;)
Maybe we should check which driver doesn't set it and fix these?
> > What other options would we have to fix this issue? Just use max_rates = 4
> > in rt2800 even if we will only use the first rate provided by minstrel and
> > then fall back to the global fallback setup (I tried that already and it
> > works just fine but seems not correct to me)?
>
> p54 kinda does some trickery in this area too, not really sure what to
> do though.
Thanks for the pointer, p54 just sets max_rates=4 even if it cannot support
it.
So, if you would like to keep the check I'll just use max_rates=4 in rt2800.
Helmut
^ permalink raw reply
* Re: rt2800, minstrel_ht & mac80211
From: Johannes Berg @ 2010-06-04 10:28 UTC (permalink / raw)
To: Helmut Schaa
Cc: Felix Fietkau, Ivo van Doorn, Gertjan van Wingerde,
linux-wireless
In-Reply-To: <201006041222.49820.helmut.schaa@googlemail.com>
On Fri, 2010-06-04 at 12:22 +0200, Helmut Schaa wrote:
> This meant that minstrel most of the time selected MCS15 as tx rate which
> resulted in a huge number of retries and thus a very slow throughput.
>
> status.c:
>
> 178 /* the HW cannot have attempted that rate */
> 179 if (i >= hw->max_rates) {
> 180 info->status.rates[i].idx = -1;
> 181 info->status.rates[i].count = 0;
>
> Johannes, is there a valid reason for this check in status.c. Can we remove
> it without breaking anything else?
IIRC there were/are some drivers that were not terminating the rates[]
array correctly with a -1, thus this code.
> What other options would we have to fix this issue? Just use max_rates = 4
> in rt2800 even if we will only use the first rate provided by minstrel and
> then fall back to the global fallback setup (I tried that already and it
> works just fine but seems not correct to me)?
p54 kinda does some trickery in this area too, not really sure what to
do though.
johannes
^ permalink raw reply
* rt2800, minstrel_ht & mac80211
From: Helmut Schaa @ 2010-06-04 10:22 UTC (permalink / raw)
To: Johannes Berg
Cc: Felix Fietkau, Ivo van Doorn, Gertjan van Wingerde,
linux-wireless
Hi,
While working on throughput problems with some mcs rates on rt2800 cards I've
noticed a strange issue between rt2800, minstrel_ht and mac80211.
Despite the fact that rt2800 always reported MCS15 as _not_ successful (and
it was really never successful), minstrel_ht's rc_stats always claimed that
the attempt was successful.
rt2800 has a global rate fallback table (something like MCS15 -> MCS14 ->
MCS13 ...), so it is capable of trying a frame at different rates but we
cannot specify the rates to be used for every single frame. Hence, rt2800
does not set hw->max_rates and thus ends up with max_rates = 1 but since
rt2800 will try different rates it will fill the tx status with all the rates
it really tried.
Unfortunately, mac80211 (status.c) decides to drop all reported rates >=
max_rates and thus we end up with minstrel_ht thinking that MCS15 was
successful while rt2800 reported that it tried MCS15,14,13 and 12 was
finally successful.
This meant that minstrel most of the time selected MCS15 as tx rate which
resulted in a huge number of retries and thus a very slow throughput.
status.c:
178 /* the HW cannot have attempted that rate */
179 if (i >= hw->max_rates) {
180 info->status.rates[i].idx = -1;
181 info->status.rates[i].count = 0;
Johannes, is there a valid reason for this check in status.c. Can we remove
it without breaking anything else?
What other options would we have to fix this issue? Just use max_rates = 4
in rt2800 even if we will only use the first rate provided by minstrel and
then fall back to the global fallback setup (I tried that already and it
works just fine but seems not correct to me)?
Thanks,
Helmut
^ permalink raw reply
* RE: Power save mode in 2.6.32-22
From: Gordon, Charles @ 2010-06-04 9:42 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <201006040255.46964.chunkeey@googlemail.com>
Hi Christian,
Thanks for the information.
What I have observed is that the wireless stack will continuously send null-data frames, toggling the power-mgmt bit, and use the config call back routine to turn power save on and off. Can I assume from this that in 2.6.32 the stack will take care of sending all the null-data frames and just tell the driver when to power up or power down the hardware? When did this change in the implementation of power save occur? In previous versions of the wireless stack the driver received one config call to turn power save on or off and then it was up to the driver to manage it, including sending null-data frames and duty cycling.
How can I disable power save mode for performance testing? It seems to come on automatically and the "iwconfig wlan0 power off" command says that function is not supported. Is there a way to control what percentage of the time the H/W will be powered up?
I will check to see if the wireless stack is doing periodic scans. I think I did see some probe frames. Is there a way to turn this feature off for performance testing?
Thanks for any help.
________________________________________
From: Christian Lamparter [chunkeey@googlemail.com]
Sent: Thursday, June 03, 2010 8:55 PM
To: Gordon, Charles
Cc: linux-wireless@vger.kernel.org
Subject: Re: Power save mode in 2.6.32-22
On Friday 04 June 2010 01:27:38 Gordon, Charles wrote:
> Hi,
>
> I'm trying to get power save mode to work in a wireless driver on Linux
> 2.6.32. What I'm seeing is that the wireless stack is sending null-data
> frames with the power management bit on or off from time to time. It does
> this regardless of whether flags IEEE80211_HW_SUPPORTS_PS and
> IEEE80211_HW_SUPPORTS_DYNAMIC_PS are set. This is not how I would expect
> it to work. If IEEE80211_HW_SUPPORTS_PS is set, I would expect it to let
> the driver handle the sending of these frames. If IEEE80211_HW_SUPPORTS_PS
> is not set, then this would indicate that the driver cannot power down, in
> which case I still would not expect the stack to be sending these frames.
> The documentation for power save is very thin and it seems the
> implementation has changed recently.
>
> Why is the stack sending these frames when the driver says the H/W does not
> support powering down?
well, could this be a periodic scan / site survey? (perhaps
NM/wicd/wpa_supplicant is running in the background?).
The device signalize the AP that it goes "off-channel" to scan on other
frequencies. Therefore the AP should be prepared to buffer any traffic,
until the STA resumes normal operation.
This can be easily tested with the help of a sniffer,
because you should then get probe requests from the interface.
> Why is the stack sending these frames when it would seem that the driver
> could better handle them?
>
> The reason why I think the driver can better handle them is that if the
> stack sends a frame with the power-mgmt bit set, and then tells the driver
> to power down, there will be a race condition where the interface could
> receive a frame before the hardware is powered down. The AP may send such
> a frame after it receives the null-data frame because some could be in a
> H/W queue. I have seen this happen. In this case, the interface H/W on
> the station will send an ACK and since the H/W does not know that it is
> about to be powered down, that ACK will be sent with the power-mgmt bit
> clear, which may confuse the access point.
> In short, sending these frames
> is something the driver should do since it will know that it should adjust
> the H/W so that any ACKs or other control frames will be sent with the
> power mgmt bit correctly set until such time as the H/W is actually powered
> down.
quote from: 802.11-2007 "11.2.1 Power management in an infrastructure network"
"A STA shall remain in its current Power Management mode until it informs the AP of
a Power Management mode change via a frame exchange that includes an acknowledgment
from the AP. Power Management mode shall not change during any single frame exchange
sequence as described in 9.12"
The way I read it, it means two things:
Firstly, the STA has to initiate a "frame exchange" in order to
notify the AP about its new power state. (And importantly, that
frame exchange has to succeed, before the STA can actually
go off-channel/sleep! - This is important, because not all
drivers/HW do support an accurate *frame success* report.)
Secondly: The AP should only consider the PSM bit setting,
if the "exchange" was actually initiated by the STA and not
by the AP. (Furthermore, for most control frames timing is
critical. Therefore they have to be implemented in the
hardware/firmware and this makes it nearly impossible to
do what you are describing in your last _quoted_ sentence)
BTW: have you tried to reproduce your "timing" problem with
a recent compat-wireless?
Regards,
Chr
^ permalink raw reply
* [stable][PATCH] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Vivek Natarajan @ 2010-06-04 9:06 UTC (permalink / raw)
To: greg; +Cc: stable, linux-wireless, Ranga Rao Ravuri
If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
with WEP or TKIP, eventhough the received frame may be a CRC failed
corrupted frame. If this bit is set, H/W obeys key type in keycache.
If it is not set and if the key type in keycache is neither open nor
AES, H/W forces key type to be open. But bit 29 should be set to 1
for AsyncFIFO feature to encrypt/decrypt the aggregate with WEP or TKIP.
Reported-by: Johan Hovold <johan.hovold@lundinova.se>
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
---
Applies on top of 2.6.33 and 2.6.34
drivers/net/wireless/ath/ath9k/initvals.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/initvals.h b/drivers/net/wireless/ath/ath9k/initvals.h
index 8a3bf3a..7203f00 100644
--- a/drivers/net/wireless/ath/ath9k/initvals.h
+++ b/drivers/net/wireless/ath/ath9k/initvals.h
@@ -246,7 +246,7 @@ static const u32 ar5416Common[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8000010 },
+ { 0x00008264, 0x88000010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -2766,7 +2766,7 @@ static const u32 ar9280Common_9280_2[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -3936,7 +3936,7 @@ static const u_int32_t ar9285Common_9285[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -5073,7 +5073,7 @@ static const u_int32_t ar9287Common_9287_1_0[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] p54spi: replace internal "cx3110x" name with "p54spi"
From: Johannes Berg @ 2010-06-04 8:36 UTC (permalink / raw)
To: Luke-Jr; +Cc: linux-wireless, linux-kernel, torvalds
In-Reply-To: <201006021406.15393.luke@dashjr.org>
On Wed, 2010-06-02 at 14:06 -0500, Luke-Jr wrote:
> > > .driver = {
> > > - /* use cx3110x name because board-n800.c uses that for the
> > > - * SPI port */
> > > - .name = "cx3110x",
> > > + .name = "p54spi",
> > > .bus = &spi_bus_type,
> >
> > maybe that comment wasn't clear enough ... it needs to be that way to be
> > properly linked up against SPI.
>
> I don't understand what you mean here. Does the hardware-side of SPI use
> string identifiers? These are the only two instances of "cx3110x" in the
> kernel source; N8x0 board files expect "p54spi"
Hm, ok, I thought that the board stuff needed cx3110x. Hopefully it
doesn't differ in n810s?
johannes
^ permalink raw reply
* Re: WARNING: at drivers/base/core.c:130 device_release+0x82/0x90()
From: Fabio Rossi @ 2010-06-04 8:25 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez
In-Reply-To: <AANLkTik0A8qhlIi1pjvo0DKXhxjBEYEwOCn6iIsLXFJi@mail.gmail.com>
On Wednesday 02 June 2010 23:42:14 Luis R. Rodriguez wrote:
> On Wed, Jun 2, 2010 at 2:29 AM, Fabio Rossi <rossi.f@inwind.it> wrote:
> > Compiling the kernel without ACPI (CONFIG_ACPI=n) gives the following
> > warning:
> >
> > cfg80211: Calling CRDA to update world regulatory domain
> > cfg80211: World regulatory domain updated:
> > (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> > (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> > ath5k 0000:08:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> > ath5k 0000:08:01.0: registered as 'phy0'
> > ath5k phy0: request_irq failed
> > ------------[ cut here ]------------
>
> Since traces are printed reversed you will have to read my logic from
> bottom to top:
>
> Seems we need to implement the dev_release() op for the class of our
> devices.
Shall I open a bug in kernel bugzilla to keep trace of this?
Fabio
^ permalink raw reply
* Re: rt73usb & Mesh network
From: Johannes Berg @ 2010-06-04 8:13 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: linux-wireless
In-Reply-To: <AANLkTinChab0MINV64h1UFb7YUxVRNvDztRbcKxZuDJO@mail.gmail.com>
On Thu, 2010-06-03 at 12:49 +0200, Ivo Van Doorn wrote:
> The stacktrace indicates the problem is a scheduling while atomic bug,
> however this seems to be triggerd by mac80211 making the bss_info_changed()
> callback function in atomic context. But the current documentation of mac80211
> implies that this callback function is allowed to sleep.
>
> Could you check the stacktrace to see if this is indeed a mac80211 bug rather
> then rt73usb?
It clearly is, at least a documentation issue in that it must not sleep
in mesh mode ... fixing it would seem to require major locking changes
in the mesh implementation, and unfortunately we don't have anybody who
has enough time to care about it.
FWIW, if anybody is interested to fix this, it seems like it should be
safe to use sta_mtx instead of rcu_read_lock() for station protection
and change a lot of mesh stuff to not use the per-sta spinlock. Must be
very careful with this though since some stuff is in the RX path.
Short of doing that, I can only suggest disabling mesh for drivers that
require being able to sleep.
johannes
^ permalink raw reply
* Re: Problems connectring to an AP with Acer Aspire Revo
From: Johannes Berg @ 2010-06-04 6:48 UTC (permalink / raw)
To: Christian P. Schmidt; +Cc: reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <4C07D0C7.8010907@digadd.de>
On Thu, 2010-06-03 at 17:56 +0200, Christian P. Schmidt wrote:
> > Maybe try the rfkill tool:
> > http://wireless.kernel.org/en/users/Documentation/rfkill
>
> Yes, it was the rfkill tool that caused my attempts to fail. However,
> this didn't change my association attempt problems.
> I also took my time to look at the PCIe port - steady 3.3V on the RFKILL
> pin, which means "no RFKILL".
>
> Any further ideas?
Unfortunately not. It would seem that something is causing your frames
not to be transmitted correctly, but I see no reason for that right now.
johannes
^ permalink raw reply
* Re: iwl3945 dies (oops) in post 2.6.34 kernels
From: Abhijeet Kolekar @ 2010-06-04 5:08 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: John W. Linville, Johannes Berg, linux-wireless@vger.kernel.org,
LKML
In-Reply-To: <20100604050836.GA21239@core.coreip.homeip.net>
On Thu, 2010-06-03 at 22:08 -0700, Dmitry Torokhov wrote:
> On Tue, May 25, 2010 at 10:27:31AM -0700, Dmitry Torokhov wrote:
> > On Tuesday 25 May 2010 10:08:22 am Abhijeet Kolekar wrote:
> > > On Tue, 2010-05-25 at 10:01 -0700, Johannes Berg wrote:
> > > > On Tue, 2010-05-25 at 09:39 -0700, Dmitry Torokhov wrote:
> > > > > Hi,
> > > > >
> > > > > I am getting the following crashers in iwl3945 after updating to
> > > > > post-2.6.34 kernels. This is with the pull from Linus's tree as of last
> > > > > night (the taint is from nvidia module):
> > > > >
> > > > > [ 3330.630734] general protection fault: 0000 [#1] PREEMPT SMP
> > > > > [ 3330.630752] last sysfs file: /sys/devices/platform/dock.0/docked
> > > > > [ 3330.630761] CPU 0
> > > > > [ 3330.630766] Modules linked in: cryptd aes_x86_64 aes_generic fuse
> > > > > rfcomm sco bnep l2cap autofs4 coretemp hwmon sunrpc ppdev parport_pc
> > > > > parport acpi_cpufreq mperf uinput nvidia(P) snd_hda_codec_idt arc4
> > > > > snd_hda_intel ecb snd_hda_codec snd_hwdep iwl3945 joydev snd_seq
> > > > > snd_seq_device snd_pcm iwlcore mac80211 snd_timer cfg80211 snd psmouse
> > > > > iTCO_wdt dell_wmi iTCO_vendor_support serio_raw tg3 battery
> > > > > dell_laptop dcdbas soundcore snd_page_alloc btusb bluetooth video
> > > > > pcspkr mac_hid ac wmi libphy firewire_ohci i2c_i801 firewire_core
> > > > > yenta_socket crc_itu_t ohci_hcd [last unloaded: microcode] [
> > > > > 3330.630950]
> > > > > [ 3330.630958] Pid: 455, comm: iwl3945 Tainted: P 2.6.35-rc0
> > > > > #293 0WM416/Latitude D630 [ 3330.630967] RIP:
> > > > > 0010:[<ffffffffa01e70d3>] [<ffffffffa01e70d3>]
> > > > > iwl3945_get_channels_for_scan+0xe3/0x460 [iwl3945]
> > > >
> > > > http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208
> > >
> > > Can you please try this patch and report your findings?
> > >
> > > http://bugzilla.intellinuxwireless.org/attachment.cgi?id=2447
> > >
> >
> > Thanks, will try both this patch and the one John mention. Later tonight
> > though.
> >
>
> John,
>
> Any chnace that 2nd patch be merged upstream? Without it my iwl3945
> craps out regularly.
>
It is merged in iwlwifi-2.6. It will be sent for upstream submission.
Abhijeet
> Thanks!
>
^ permalink raw reply
* Re: iwl3945 dies (oops) in post 2.6.34 kernels
From: Dmitry Torokhov @ 2010-06-04 5:08 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, linux-wireless@vger.kernel.org, LKML,
Abhijeet Kolekar
In-Reply-To: <201005251027.32778.dmitry.torokhov@gmail.com>
On Tue, May 25, 2010 at 10:27:31AM -0700, Dmitry Torokhov wrote:
> On Tuesday 25 May 2010 10:08:22 am Abhijeet Kolekar wrote:
> > On Tue, 2010-05-25 at 10:01 -0700, Johannes Berg wrote:
> > > On Tue, 2010-05-25 at 09:39 -0700, Dmitry Torokhov wrote:
> > > > Hi,
> > > >
> > > > I am getting the following crashers in iwl3945 after updating to
> > > > post-2.6.34 kernels. This is with the pull from Linus's tree as of last
> > > > night (the taint is from nvidia module):
> > > >
> > > > [ 3330.630734] general protection fault: 0000 [#1] PREEMPT SMP
> > > > [ 3330.630752] last sysfs file: /sys/devices/platform/dock.0/docked
> > > > [ 3330.630761] CPU 0
> > > > [ 3330.630766] Modules linked in: cryptd aes_x86_64 aes_generic fuse
> > > > rfcomm sco bnep l2cap autofs4 coretemp hwmon sunrpc ppdev parport_pc
> > > > parport acpi_cpufreq mperf uinput nvidia(P) snd_hda_codec_idt arc4
> > > > snd_hda_intel ecb snd_hda_codec snd_hwdep iwl3945 joydev snd_seq
> > > > snd_seq_device snd_pcm iwlcore mac80211 snd_timer cfg80211 snd psmouse
> > > > iTCO_wdt dell_wmi iTCO_vendor_support serio_raw tg3 battery
> > > > dell_laptop dcdbas soundcore snd_page_alloc btusb bluetooth video
> > > > pcspkr mac_hid ac wmi libphy firewire_ohci i2c_i801 firewire_core
> > > > yenta_socket crc_itu_t ohci_hcd [last unloaded: microcode] [
> > > > 3330.630950]
> > > > [ 3330.630958] Pid: 455, comm: iwl3945 Tainted: P 2.6.35-rc0
> > > > #293 0WM416/Latitude D630 [ 3330.630967] RIP:
> > > > 0010:[<ffffffffa01e70d3>] [<ffffffffa01e70d3>]
> > > > iwl3945_get_channels_for_scan+0xe3/0x460 [iwl3945]
> > >
> > > http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208
> >
> > Can you please try this patch and report your findings?
> >
> > http://bugzilla.intellinuxwireless.org/attachment.cgi?id=2447
> >
>
> Thanks, will try both this patch and the one John mention. Later tonight
> though.
>
John,
Any chnace that 2nd patch be merged upstream? Without it my iwl3945
craps out regularly.
Thanks!
--
Dmitry
^ permalink raw reply
* [patch 2/5] b43legacy: replace the ssb_dma API with the generic DMA API
From: akpm @ 2010-06-04 2:37 UTC (permalink / raw)
To: linville
Cc: linux-wireless, akpm, fujita.tomonori, Larry.Finger, davem, mb,
stefano.brivio
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stefano Brivio <stefano.brivio@polimi.it>
Cc: John W. Linville <linville@tuxdriver.com>
Acked-by: Michael Buesch <mb@bu3sch.de>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/wireless/b43legacy/dma.c | 49 +++++++++++++------------
1 file changed, 26 insertions(+), 23 deletions(-)
diff -puN drivers/net/wireless/b43legacy/dma.c~b43legacy-replace-the-ssb_dma-api-with-the-generic-dma-api drivers/net/wireless/b43legacy/dma.c
--- a/drivers/net/wireless/b43legacy/dma.c~b43legacy-replace-the-ssb_dma-api-with-the-generic-dma-api
+++ a/drivers/net/wireless/b43legacy/dma.c
@@ -394,11 +394,11 @@ dma_addr_t map_descbuffer(struct b43lega
dma_addr_t dmaaddr;
if (tx)
- dmaaddr = ssb_dma_map_single(ring->dev->dev,
+ dmaaddr = dma_map_single(ring->dev->dev->dma_dev,
buf, len,
DMA_TO_DEVICE);
else
- dmaaddr = ssb_dma_map_single(ring->dev->dev,
+ dmaaddr = dma_map_single(ring->dev->dev->dma_dev,
buf, len,
DMA_FROM_DEVICE);
@@ -412,11 +412,11 @@ void unmap_descbuffer(struct b43legacy_d
int tx)
{
if (tx)
- ssb_dma_unmap_single(ring->dev->dev,
+ dma_unmap_single(ring->dev->dev->dma_dev,
addr, len,
DMA_TO_DEVICE);
else
- ssb_dma_unmap_single(ring->dev->dev,
+ dma_unmap_single(ring->dev->dev->dma_dev,
addr, len,
DMA_FROM_DEVICE);
}
@@ -428,8 +428,8 @@ void sync_descbuffer_for_cpu(struct b43l
{
B43legacy_WARN_ON(ring->tx);
- ssb_dma_sync_single_for_cpu(ring->dev->dev,
- addr, len, DMA_FROM_DEVICE);
+ dma_sync_single_for_cpu(ring->dev->dev->dma_dev,
+ addr, len, DMA_FROM_DEVICE);
}
static inline
@@ -439,8 +439,8 @@ void sync_descbuffer_for_device(struct b
{
B43legacy_WARN_ON(ring->tx);
- ssb_dma_sync_single_for_device(ring->dev->dev,
- addr, len, DMA_FROM_DEVICE);
+ dma_sync_single_for_device(ring->dev->dev->dma_dev,
+ addr, len, DMA_FROM_DEVICE);
}
static inline
@@ -460,10 +460,10 @@ void free_descriptor_buffer(struct b43le
static int alloc_ringmemory(struct b43legacy_dmaring *ring)
{
/* GFP flags must match the flags in free_ringmemory()! */
- ring->descbase = ssb_dma_alloc_consistent(ring->dev->dev,
- B43legacy_DMA_RINGMEMSIZE,
- &(ring->dmabase),
- GFP_KERNEL);
+ ring->descbase = dma_alloc_coherent(ring->dev->dev->dma_dev,
+ B43legacy_DMA_RINGMEMSIZE,
+ &(ring->dmabase),
+ GFP_KERNEL);
if (!ring->descbase) {
b43legacyerr(ring->dev->wl, "DMA ringmemory allocation"
" failed\n");
@@ -476,8 +476,8 @@ static int alloc_ringmemory(struct b43le
static void free_ringmemory(struct b43legacy_dmaring *ring)
{
- ssb_dma_free_consistent(ring->dev->dev, B43legacy_DMA_RINGMEMSIZE,
- ring->descbase, ring->dmabase, GFP_KERNEL);
+ dma_free_coherent(ring->dev->dev->dma_dev, B43legacy_DMA_RINGMEMSIZE,
+ ring->descbase, ring->dmabase);
}
/* Reset the RX DMA channel */
@@ -589,7 +589,7 @@ static bool b43legacy_dma_mapping_error(
size_t buffersize,
bool dma_to_device)
{
- if (unlikely(ssb_dma_mapping_error(ring->dev->dev, addr)))
+ if (unlikely(dma_mapping_error(ring->dev->dev->dma_dev, addr)))
return 1;
switch (ring->type) {
@@ -906,7 +906,7 @@ struct b43legacy_dmaring *b43legacy_setu
goto err_kfree_meta;
/* test for ability to dma to txhdr_cache */
- dma_test = ssb_dma_map_single(dev->dev, ring->txhdr_cache,
+ dma_test = dma_map_single(dev->dev->dma_dev, ring->txhdr_cache,
sizeof(struct b43legacy_txhdr_fw3),
DMA_TO_DEVICE);
@@ -920,7 +920,7 @@ struct b43legacy_dmaring *b43legacy_setu
if (!ring->txhdr_cache)
goto err_kfree_meta;
- dma_test = ssb_dma_map_single(dev->dev,
+ dma_test = dma_map_single(dev->dev->dma_dev,
ring->txhdr_cache,
sizeof(struct b43legacy_txhdr_fw3),
DMA_TO_DEVICE);
@@ -930,9 +930,9 @@ struct b43legacy_dmaring *b43legacy_setu
goto err_kfree_txhdr_cache;
}
- ssb_dma_unmap_single(dev->dev, dma_test,
- sizeof(struct b43legacy_txhdr_fw3),
- DMA_TO_DEVICE);
+ dma_unmap_single(dev->dev->dma_dev, dma_test,
+ sizeof(struct b43legacy_txhdr_fw3),
+ DMA_TO_DEVICE);
}
ring->nr_slots = nr_slots;
@@ -1040,9 +1040,12 @@ static int b43legacy_dma_set_mask(struct
/* Try to set the DMA mask. If it fails, try falling back to a
* lower mask, as we can always also support a lower one. */
while (1) {
- err = ssb_dma_set_mask(dev->dev, mask);
- if (!err)
- break;
+ err = dma_set_mask(dev->dev->dma_dev, mask);
+ if (!err) {
+ err = dma_set_coherent_mask(dev->dev->dma_dev, mask);
+ if (!err)
+ break;
+ }
if (mask == DMA_BIT_MASK(64)) {
mask = DMA_BIT_MASK(32);
fallback = 1;
_
^ permalink raw reply
* [patch 1/5] ssb: add dma_dev to ssb_device structure
From: akpm @ 2010-06-04 2:37 UTC (permalink / raw)
To: linville
Cc: linux-wireless, akpm, fujita.tomonori, Larry.Finger, davem, mb,
stefano.brivio, zambrano
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Add dma_dev, a pointer to struct device, to struct ssb_device. We pass it
to the generic DMA API with SSB_BUSTYPE_PCI and SSB_BUSTYPE_SSB.
ssb_devices_register() sets up it properly.
This is preparation for replacing the ssb bus specific DMA API (ssb_dma_*)
with the generic DMA API.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Michael Buesch <mb@bu3sch.de>
Cc: Gary Zambrano <zambrano@broadcom.com>
Cc: Stefano Brivio <stefano.brivio@polimi.it>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W. Linville <linville@tuxdriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/ssb/main.c | 2 ++
include/linux/ssb/ssb.h | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff -puN drivers/ssb/main.c~ssb-add-dma_dev-to-ssb_device-structure drivers/ssb/main.c
--- a/drivers/ssb/main.c~ssb-add-dma_dev-to-ssb_device-structure
+++ a/drivers/ssb/main.c
@@ -486,6 +486,7 @@ static int ssb_devices_register(struct s
#ifdef CONFIG_SSB_PCIHOST
sdev->irq = bus->host_pci->irq;
dev->parent = &bus->host_pci->dev;
+ sdev->dma_dev = dev->parent;
#endif
break;
case SSB_BUSTYPE_PCMCIA:
@@ -501,6 +502,7 @@ static int ssb_devices_register(struct s
break;
case SSB_BUSTYPE_SSB:
dev->dma_mask = &dev->coherent_dma_mask;
+ sdev->dma_dev = dev;
break;
}
diff -puN include/linux/ssb/ssb.h~ssb-add-dma_dev-to-ssb_device-structure include/linux/ssb/ssb.h
--- a/include/linux/ssb/ssb.h~ssb-add-dma_dev-to-ssb_device-structure
+++ a/include/linux/ssb/ssb.h
@@ -167,7 +167,7 @@ struct ssb_device {
* is an optimization. */
const struct ssb_bus_ops *ops;
- struct device *dev;
+ struct device *dev, *dma_dev;
struct ssb_bus *bus;
struct ssb_device_id id;
_
^ permalink raw reply
* [patch 3/5] b43: replace the ssb_dma API with the generic DMA API
From: akpm @ 2010-06-04 2:37 UTC (permalink / raw)
To: linville
Cc: linux-wireless, akpm, fujita.tomonori, Larry.Finger, davem, mb,
stefano.brivio
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Stefano Brivio <stefano.brivio@polimi.it>
Cc: John W. Linville <linville@tuxdriver.com>
Acked-by: Michael Buesch <mb@bu3sch.de>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/wireless/b43/dma.c | 65 ++++++++++++++++---------------
1 file changed, 34 insertions(+), 31 deletions(-)
diff -puN drivers/net/wireless/b43/dma.c~b43-replace-the-ssb_dma-api-with-the-generic-dma-api drivers/net/wireless/b43/dma.c
--- a/drivers/net/wireless/b43/dma.c~b43-replace-the-ssb_dma-api-with-the-generic-dma-api
+++ a/drivers/net/wireless/b43/dma.c
@@ -333,11 +333,11 @@ static inline
dma_addr_t dmaaddr;
if (tx) {
- dmaaddr = ssb_dma_map_single(ring->dev->dev,
- buf, len, DMA_TO_DEVICE);
+ dmaaddr = dma_map_single(ring->dev->dev->dma_dev,
+ buf, len, DMA_TO_DEVICE);
} else {
- dmaaddr = ssb_dma_map_single(ring->dev->dev,
- buf, len, DMA_FROM_DEVICE);
+ dmaaddr = dma_map_single(ring->dev->dev->dma_dev,
+ buf, len, DMA_FROM_DEVICE);
}
return dmaaddr;
@@ -348,11 +348,11 @@ static inline
dma_addr_t addr, size_t len, int tx)
{
if (tx) {
- ssb_dma_unmap_single(ring->dev->dev,
- addr, len, DMA_TO_DEVICE);
+ dma_unmap_single(ring->dev->dev->dma_dev,
+ addr, len, DMA_TO_DEVICE);
} else {
- ssb_dma_unmap_single(ring->dev->dev,
- addr, len, DMA_FROM_DEVICE);
+ dma_unmap_single(ring->dev->dev->dma_dev,
+ addr, len, DMA_FROM_DEVICE);
}
}
@@ -361,7 +361,7 @@ static inline
dma_addr_t addr, size_t len)
{
B43_WARN_ON(ring->tx);
- ssb_dma_sync_single_for_cpu(ring->dev->dev,
+ dma_sync_single_for_cpu(ring->dev->dev->dma_dev,
addr, len, DMA_FROM_DEVICE);
}
@@ -370,8 +370,8 @@ static inline
dma_addr_t addr, size_t len)
{
B43_WARN_ON(ring->tx);
- ssb_dma_sync_single_for_device(ring->dev->dev,
- addr, len, DMA_FROM_DEVICE);
+ dma_sync_single_for_device(ring->dev->dev->dma_dev,
+ addr, len, DMA_FROM_DEVICE);
}
static inline
@@ -401,9 +401,9 @@ static int alloc_ringmemory(struct b43_d
*/
if (ring->type == B43_DMA_64BIT)
flags |= GFP_DMA;
- ring->descbase = ssb_dma_alloc_consistent(ring->dev->dev,
- B43_DMA_RINGMEMSIZE,
- &(ring->dmabase), flags);
+ ring->descbase = dma_alloc_coherent(ring->dev->dev->dma_dev,
+ B43_DMA_RINGMEMSIZE,
+ &(ring->dmabase), flags);
if (!ring->descbase) {
b43err(ring->dev->wl, "DMA ringmemory allocation failed\n");
return -ENOMEM;
@@ -420,8 +420,8 @@ static void free_ringmemory(struct b43_d
if (ring->type == B43_DMA_64BIT)
flags |= GFP_DMA;
- ssb_dma_free_consistent(ring->dev->dev, B43_DMA_RINGMEMSIZE,
- ring->descbase, ring->dmabase, flags);
+ dma_free_coherent(ring->dev->dev->dma_dev, B43_DMA_RINGMEMSIZE,
+ ring->descbase, ring->dmabase);
}
/* Reset the RX DMA channel */
@@ -528,7 +528,7 @@ static bool b43_dma_mapping_error(struct
dma_addr_t addr,
size_t buffersize, bool dma_to_device)
{
- if (unlikely(ssb_dma_mapping_error(ring->dev->dev, addr)))
+ if (unlikely(dma_mapping_error(ring->dev->dev->dma_dev, addr)))
return 1;
switch (ring->type) {
@@ -874,10 +874,10 @@ struct b43_dmaring *b43_setup_dmaring(st
goto err_kfree_meta;
/* test for ability to dma to txhdr_cache */
- dma_test = ssb_dma_map_single(dev->dev,
- ring->txhdr_cache,
- b43_txhdr_size(dev),
- DMA_TO_DEVICE);
+ dma_test = dma_map_single(dev->dev->dma_dev,
+ ring->txhdr_cache,
+ b43_txhdr_size(dev),
+ DMA_TO_DEVICE);
if (b43_dma_mapping_error(ring, dma_test,
b43_txhdr_size(dev), 1)) {
@@ -889,10 +889,10 @@ struct b43_dmaring *b43_setup_dmaring(st
if (!ring->txhdr_cache)
goto err_kfree_meta;
- dma_test = ssb_dma_map_single(dev->dev,
- ring->txhdr_cache,
- b43_txhdr_size(dev),
- DMA_TO_DEVICE);
+ dma_test = dma_map_single(dev->dev->dma_dev,
+ ring->txhdr_cache,
+ b43_txhdr_size(dev),
+ DMA_TO_DEVICE);
if (b43_dma_mapping_error(ring, dma_test,
b43_txhdr_size(dev), 1)) {
@@ -903,9 +903,9 @@ struct b43_dmaring *b43_setup_dmaring(st
}
}
- ssb_dma_unmap_single(dev->dev,
- dma_test, b43_txhdr_size(dev),
- DMA_TO_DEVICE);
+ dma_unmap_single(dev->dev->dma_dev,
+ dma_test, b43_txhdr_size(dev),
+ DMA_TO_DEVICE);
}
err = alloc_ringmemory(ring);
@@ -1018,9 +1018,12 @@ static int b43_dma_set_mask(struct b43_w
/* Try to set the DMA mask. If it fails, try falling back to a
* lower mask, as we can always also support a lower one. */
while (1) {
- err = ssb_dma_set_mask(dev->dev, mask);
- if (!err)
- break;
+ err = dma_set_mask(dev->dev->dma_dev, mask);
+ if (!err) {
+ err = dma_set_coherent_mask(dev->dev->dma_dev, mask);
+ if (!err)
+ break;
+ }
if (mask == DMA_BIT_MASK(64)) {
mask = DMA_BIT_MASK(32);
fallback = 1;
_
^ permalink raw reply
* [patch 5/5] ssb: remove the ssb DMA API
From: akpm @ 2010-06-04 2:37 UTC (permalink / raw)
To: linville
Cc: linux-wireless, akpm, fujita.tomonori, Larry.Finger, davem, mb,
stefano.brivio, zambrano
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Now they are unnecessary. We can use the generic DMA API with any bus.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Michael Buesch <mb@bu3sch.de>
Cc: Gary Zambrano <zambrano@broadcom.com>
Cc: Stefano Brivio <stefano.brivio@polimi.it>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/ssb/main.c | 74 -----------------
include/linux/ssb/ssb.h | 157 --------------------------------------
2 files changed, 231 deletions(-)
diff -puN drivers/ssb/main.c~ssb-remove-the-ssb-dma-api drivers/ssb/main.c
--- a/drivers/ssb/main.c~ssb-remove-the-ssb-dma-api
+++ a/drivers/ssb/main.c
@@ -1228,80 +1228,6 @@ u32 ssb_dma_translation(struct ssb_devic
}
EXPORT_SYMBOL(ssb_dma_translation);
-int ssb_dma_set_mask(struct ssb_device *dev, u64 mask)
-{
-#ifdef CONFIG_SSB_PCIHOST
- int err;
-#endif
-
- switch (dev->bus->bustype) {
- case SSB_BUSTYPE_PCI:
-#ifdef CONFIG_SSB_PCIHOST
- err = pci_set_dma_mask(dev->bus->host_pci, mask);
- if (err)
- return err;
- err = pci_set_consistent_dma_mask(dev->bus->host_pci, mask);
- return err;
-#endif
- case SSB_BUSTYPE_SSB:
- return dma_set_mask(dev->dev, mask);
- default:
- __ssb_dma_not_implemented(dev);
- }
- return -ENOSYS;
-}
-EXPORT_SYMBOL(ssb_dma_set_mask);
-
-void * ssb_dma_alloc_consistent(struct ssb_device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t gfp_flags)
-{
- switch (dev->bus->bustype) {
- case SSB_BUSTYPE_PCI:
-#ifdef CONFIG_SSB_PCIHOST
- if (gfp_flags & GFP_DMA) {
- /* Workaround: The PCI API does not support passing
- * a GFP flag. */
- return dma_alloc_coherent(&dev->bus->host_pci->dev,
- size, dma_handle, gfp_flags);
- }
- return pci_alloc_consistent(dev->bus->host_pci, size, dma_handle);
-#endif
- case SSB_BUSTYPE_SSB:
- return dma_alloc_coherent(dev->dev, size, dma_handle, gfp_flags);
- default:
- __ssb_dma_not_implemented(dev);
- }
- return NULL;
-}
-EXPORT_SYMBOL(ssb_dma_alloc_consistent);
-
-void ssb_dma_free_consistent(struct ssb_device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle,
- gfp_t gfp_flags)
-{
- switch (dev->bus->bustype) {
- case SSB_BUSTYPE_PCI:
-#ifdef CONFIG_SSB_PCIHOST
- if (gfp_flags & GFP_DMA) {
- /* Workaround: The PCI API does not support passing
- * a GFP flag. */
- dma_free_coherent(&dev->bus->host_pci->dev,
- size, vaddr, dma_handle);
- return;
- }
- pci_free_consistent(dev->bus->host_pci, size,
- vaddr, dma_handle);
- return;
-#endif
- case SSB_BUSTYPE_SSB:
- dma_free_coherent(dev->dev, size, vaddr, dma_handle);
- return;
- default:
- __ssb_dma_not_implemented(dev);
- }
-}
-EXPORT_SYMBOL(ssb_dma_free_consistent);
-
int ssb_bus_may_powerdown(struct ssb_bus *bus)
{
struct ssb_chipcommon *cc;
diff -puN include/linux/ssb/ssb.h~ssb-remove-the-ssb-dma-api include/linux/ssb/ssb.h
--- a/include/linux/ssb/ssb.h~ssb-remove-the-ssb-dma-api
+++ a/include/linux/ssb/ssb.h
@@ -470,14 +470,6 @@ extern u32 ssb_dma_translation(struct ss
#define SSB_DMA_TRANSLATION_MASK 0xC0000000
#define SSB_DMA_TRANSLATION_SHIFT 30
-extern int ssb_dma_set_mask(struct ssb_device *dev, u64 mask);
-
-extern void * ssb_dma_alloc_consistent(struct ssb_device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t gfp_flags);
-extern void ssb_dma_free_consistent(struct ssb_device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle,
- gfp_t gfp_flags);
-
static inline void __cold __ssb_dma_not_implemented(struct ssb_device *dev)
{
#ifdef CONFIG_SSB_DEBUG
@@ -486,155 +478,6 @@ static inline void __cold __ssb_dma_not_
#endif /* DEBUG */
}
-static inline int ssb_dma_mapping_error(struct ssb_device *dev, dma_addr_t addr)
-{
- switch (dev->bus->bustype) {
- case SSB_BUSTYPE_PCI:
-#ifdef CONFIG_SSB_PCIHOST
- return pci_dma_mapping_error(dev->bus->host_pci, addr);
-#endif
- break;
- case SSB_BUSTYPE_SSB:
- return dma_mapping_error(dev->dev, addr);
- default:
- break;
- }
- __ssb_dma_not_implemented(dev);
- return -ENOSYS;
-}
-
-static inline dma_addr_t ssb_dma_map_single(struct ssb_device *dev, void *p,
- size_t size, enum dma_data_direction dir)
-{
- switch (dev->bus->bustype) {
- case SSB_BUSTYPE_PCI:
-#ifdef CONFIG_SSB_PCIHOST
- return pci_map_single(dev->bus->host_pci, p, size, dir);
-#endif
- break;
- case SSB_BUSTYPE_SSB:
- return dma_map_single(dev->dev, p, size, dir);
- default:
- break;
- }
- __ssb_dma_not_implemented(dev);
- return 0;
-}
-
-static inline void ssb_dma_unmap_single(struct ssb_device *dev, dma_addr_t dma_addr,
- size_t size, enum dma_data_direction dir)
-{
- switch (dev->bus->bustype) {
- case SSB_BUSTYPE_PCI:
-#ifdef CONFIG_SSB_PCIHOST
- pci_unmap_single(dev->bus->host_pci, dma_addr, size, dir);
- return;
-#endif
- break;
- case SSB_BUSTYPE_SSB:
- dma_unmap_single(dev->dev, dma_addr, size, dir);
- return;
- default:
- break;
- }
- __ssb_dma_not_implemented(dev);
-}
-
-static inline void ssb_dma_sync_single_for_cpu(struct ssb_device *dev,
- dma_addr_t dma_addr,
- size_t size,
- enum dma_data_direction dir)
-{
- switch (dev->bus->bustype) {
- case SSB_BUSTYPE_PCI:
-#ifdef CONFIG_SSB_PCIHOST
- pci_dma_sync_single_for_cpu(dev->bus->host_pci, dma_addr,
- size, dir);
- return;
-#endif
- break;
- case SSB_BUSTYPE_SSB:
- dma_sync_single_for_cpu(dev->dev, dma_addr, size, dir);
- return;
- default:
- break;
- }
- __ssb_dma_not_implemented(dev);
-}
-
-static inline void ssb_dma_sync_single_for_device(struct ssb_device *dev,
- dma_addr_t dma_addr,
- size_t size,
- enum dma_data_direction dir)
-{
- switch (dev->bus->bustype) {
- case SSB_BUSTYPE_PCI:
-#ifdef CONFIG_SSB_PCIHOST
- pci_dma_sync_single_for_device(dev->bus->host_pci, dma_addr,
- size, dir);
- return;
-#endif
- break;
- case SSB_BUSTYPE_SSB:
- dma_sync_single_for_device(dev->dev, dma_addr, size, dir);
- return;
- default:
- break;
- }
- __ssb_dma_not_implemented(dev);
-}
-
-static inline void ssb_dma_sync_single_range_for_cpu(struct ssb_device *dev,
- dma_addr_t dma_addr,
- unsigned long offset,
- size_t size,
- enum dma_data_direction dir)
-{
- switch (dev->bus->bustype) {
- case SSB_BUSTYPE_PCI:
-#ifdef CONFIG_SSB_PCIHOST
- /* Just sync everything. That's all the PCI API can do. */
- pci_dma_sync_single_for_cpu(dev->bus->host_pci, dma_addr,
- offset + size, dir);
- return;
-#endif
- break;
- case SSB_BUSTYPE_SSB:
- dma_sync_single_range_for_cpu(dev->dev, dma_addr, offset,
- size, dir);
- return;
- default:
- break;
- }
- __ssb_dma_not_implemented(dev);
-}
-
-static inline void ssb_dma_sync_single_range_for_device(struct ssb_device *dev,
- dma_addr_t dma_addr,
- unsigned long offset,
- size_t size,
- enum dma_data_direction dir)
-{
- switch (dev->bus->bustype) {
- case SSB_BUSTYPE_PCI:
-#ifdef CONFIG_SSB_PCIHOST
- /* Just sync everything. That's all the PCI API can do. */
- pci_dma_sync_single_for_device(dev->bus->host_pci, dma_addr,
- offset + size, dir);
- return;
-#endif
- break;
- case SSB_BUSTYPE_SSB:
- dma_sync_single_range_for_device(dev->dev, dma_addr, offset,
- size, dir);
- return;
- default:
- break;
- }
- __ssb_dma_not_implemented(dev);
-}
-
-
#ifdef CONFIG_SSB_PCIHOST
/* PCI-host wrapper driver */
extern int ssb_pcihost_register(struct pci_driver *driver);
_
^ 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