* [PATCH 00/11] Removing dead code
From: Christoph Egger @ 2010-07-14 12:39 UTC (permalink / raw)
To: David S. Miller, Alexey Dobriyan, Jiri Pirko, Joe Perches,
Stephen Hemminger, Eric Dumazet, Jesper Nilsson, Tejun Heo,
Dongdong Deng, Jiri Kosina, Samuel Ortiz, Andrew Morton,
Roel Kluin, Nicolas Pitre, Tony Lindgren, Daniel Walker,
Alessandro Rubini, Ivo van Doorn, Gertjan van Wingerde,
John W. Linville, Bartlomiej Zolnierkiewicz, Felix Fietkau,
Helmut Schaa, netdev, linux-kernel, linux-wireless, users
Cc: vamos-dev
Hi all!
As part of the VAMOS[0] research project at the University of
Erlangen we are looking at multiple integrity errors in linux'
configuration system.
I've been running a check on the drivers/net sourcetree for
config Items not defined in Kconfig and found 11 such
cases. Sourcecode blocks depending on these Items are not reachable
from a vanilla kernel -- dead code. I've seen such dead blocks made on
purpose e.g. while integrating new features into the kernel but
generally they're just useless.
Each of the patches in this patchset removes on such dead
config Item, I'd be glad if you consider applying them. I've been
doing deeper analysis of such issues before and can do so again but
I'm not so sure they were fastly usefull.
I build the patches against a vanilla kernel in order to
try if the kernel compiles with this patches
Please keep me informed of this patch getting confirmed /
merged so we can keep track of it.
Regards
Christoph Egger
[0] http://vamos1.informatik.uni-erlangen.de/
Christoph Egger (11):
Removing dead RT2800PCI_SOC
Removing dead {AR,WAVE}LAN
Removing dead CASSINI_QGE_DEBUG
Removing dead CASSINI_MULTICAST_REG_WRITE
Removing dead CASSINI_NAPI
Removing dead CHELSIO_T1_COUGAR
Removing dead ARCH_PNX010X
Removing dead SH_HICOSH4
Removing dead ETRAX_NETWORK_RED_ON_NO_CONNECTION
Removing dead NETWINDER_{T,R}X_DMA_PROBLEMS
Removing dead REDWOOD_{5,6}
drivers/net/Space.c | 6 --
drivers/net/cassini.c | 25 +--------
drivers/net/cassini.h | 4 -
drivers/net/chelsio/subr.c | 48 +---------------
drivers/net/cris/eth_v10.c | 4 -
drivers/net/cs89x0.c | 96 +------------------------------
drivers/net/cs89x0.h | 4 -
drivers/net/irda/w83977af_ir.c | 33 +---------
drivers/net/smc91x.h | 37 ------------
drivers/net/wireless/rt2x00/Kconfig | 5 --
drivers/net/wireless/rt2x00/rt2800pci.c | 39 -------------
11 files changed, 9 insertions(+), 292 deletions(-)
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Florian Klink @ 2010-07-14 10:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Guy, Wey-Yi W
In-Reply-To: <1279101655.3719.12.camel@jlt3.sipsolutions.net>
Thanks ;-)
On Wed, 14 Jul 2010 12:00:55 +0200, Johannes Berg
<johannes@sipsolutions.net> wrote:
> [correct wey-yi's address, remove reinette]
>
> On Wed, 2010-07-14 at 11:33 +0200, Florian Klink wrote:
>> Hi,
>>
>> I hope I'm writing to the right addresses, this is my first kernel bug
>> report :-)
>>
>> I regulary build linus' tree from git. One day, my wireless card was
>> unable to connect to the access point. dmesg showed something like this:
>>
>> [ 122.290949] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 1)
>> [ 122.490158] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 2)
>> [ 122.690057] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 3)
>> [ 122.890031] wlan0: direct probe to 00:15:0c:xx:xx:xx timed out
>>
>> At first, I thought is was some link quality problem and tried it next
>> to the access point, but it still didn't work.
>> I booted another (older) kernel and with this one, the card was able to
>> connect without any problems.
>>
>> I bisected the problem and came to commit
>> 062bee448bd539580ef9f64efe50fdfe04eeb103
>> iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=062bee448bd539580ef9f64efe50fdfe04eeb103
>>
>> My wireless card is a Intel Corporation Wireless WiFi Link 5100.
>>
>> Will provide more info if needed.
>>
>> Florian
>>
>> PS: Please CC me, i'm not on linux-wireless.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Johannes Berg @ 2010-07-14 10:00 UTC (permalink / raw)
To: Florian Klink; +Cc: linux-wireless, Guy, Wey-Yi W
In-Reply-To: <1279100021.7275.24.camel@flokli-laptop>
[correct wey-yi's address, remove reinette]
On Wed, 2010-07-14 at 11:33 +0200, Florian Klink wrote:
> Hi,
>
> I hope I'm writing to the right addresses, this is my first kernel bug
> report :-)
>
> I regulary build linus' tree from git. One day, my wireless card was
> unable to connect to the access point. dmesg showed something like this:
>
> [ 122.290949] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 1)
> [ 122.490158] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 2)
> [ 122.690057] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 3)
> [ 122.890031] wlan0: direct probe to 00:15:0c:xx:xx:xx timed out
>
> At first, I thought is was some link quality problem and tried it next
> to the access point, but it still didn't work.
> I booted another (older) kernel and with this one, the card was able to
> connect without any problems.
>
> I bisected the problem and came to commit
> 062bee448bd539580ef9f64efe50fdfe04eeb103
> iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=062bee448bd539580ef9f64efe50fdfe04eeb103
>
> My wireless card is a Intel Corporation Wireless WiFi Link 5100.
>
> Will provide more info if needed.
>
> Florian
>
> PS: Please CC me, i'm not on linux-wireless.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Florian Klink @ 2010-07-14 9:33 UTC (permalink / raw)
To: linux-wireless; +Cc: ey-yi.w.guy, reinette.chatre, flokli
Hi,
I hope I'm writing to the right addresses, this is my first kernel bug
report :-)
I regulary build linus' tree from git. One day, my wireless card was
unable to connect to the access point. dmesg showed something like this:
[ 122.290949] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 1)
[ 122.490158] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 2)
[ 122.690057] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 3)
[ 122.890031] wlan0: direct probe to 00:15:0c:xx:xx:xx timed out
At first, I thought is was some link quality problem and tried it next
to the access point, but it still didn't work.
I booted another (older) kernel and with this one, the card was able to
connect without any problems.
I bisected the problem and came to commit
062bee448bd539580ef9f64efe50fdfe04eeb103
iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=062bee448bd539580ef9f64efe50fdfe04eeb103
My wireless card is a Intel Corporation Wireless WiFi Link 5100.
Will provide more info if needed.
Florian
PS: Please CC me, i'm not on linux-wireless.
^ permalink raw reply
* Re: Bug#588196: b43: does not join multicast groups
From: Simon Richter @ 2010-07-14 7:50 UTC (permalink / raw)
To: Michael Büsch
Cc: Larry Finger, Ben Hutchings, Stefano Brivio, linux-wireless,
588196
In-Reply-To: <4C3C7296.3070700@bu3sch.de>
Hi,
On Tue, Jul 13, 2010 at 04:05:10PM +0200, Michael Büsch wrote:
> So it is up to the upper layer to detect the failure. I don't think
> it's possible to automatically detect such incidents for multicast
> transmissions. So the mechanism fails here.
Well, it is about *receiving* a multicast transmission (IPv6 router
advertisement, sent to 33:33:00:00:00:01). I have no idea where the
packet is dropped; from my somewhat limited understanding of 802.11, I'd
expect the frames to be treated like broadcast frames by the AP, so it'd
be the receiver dropping them in the MAC filter.
Simon
^ permalink raw reply
* [PATCH 2/3] ath9k_htc: implement mac80211 flush op
From: Sujith @ 2010-07-14 3:31 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1279070845-29442-3-git-send-email-lrodriguez@atheros.com>
Luis R. Rodriguez wrote:
> This implements the mac80211 flush callback to let mac80211
> flush the hardware queues when it deems appropriate.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/htc_drv_main.c | 24 ++++++++++++++++++++++++
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> index e38ca66..fc234a7 100644
> --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
> @@ -1803,6 +1803,29 @@ static void ath9k_htc_set_coverage_class(struct ieee80211_hw *hw,
> mutex_unlock(&priv->mutex);
> }
>
> +static void ath9k_htc_flush(struct ieee80211_hw *hw, bool drop)
> +{
> + struct ath9k_htc_priv *priv = hw->priv;
> + u8 cmd_rsp;
> + int ret;
> +
> + mutex_lock(&priv->mutex);
> +
> + if (priv->op_flags & OP_INVALID)
> + goto err;
> +
> + ath9k_htc_ps_wakeup(priv);
> +
> + WMI_CMD(WMI_DRAIN_TXQ_ALL_CMDID);
> + if (drop)
> + skb_queue_purge(&priv->tx_queue);
> +
> + ath9k_htc_ps_restore(priv);
> +
> +err:
> + mutex_unlock(&priv->mutex);
> +}
> +
I don't think this would work.
Queuing of packets is done in the HIF (USB) layer.
Flushing would require dropping (or not) the buffered packets in the
USB layer. Also, we don't actually require this, since IDLE state
is handled in radio_disable(), where everything is flushed properly ...
Sujith
^ permalink raw reply
* Re: Rate control & USB
From: Julian Calaby @ 2010-07-14 1:53 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: Helmut Schaa, linux-wireless, Johannes Berg, Felix Fietkau
In-Reply-To: <AANLkTikP6mK-S5kLVrRDiQGX9MAgOt-uyUn0A1Z-593A@mail.gmail.com>
On Wed, Jul 14, 2010 at 05:51, Ivo Van Doorn <ivdoorn@gmail.com> wrote:
> On Tue, Jul 13, 2010 at 9:15 PM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
>> Am Dienstag 13 Juli 2010 schrieb Ivo Van Doorn:
>>> On Mon, Jul 12, 2010 at 9:14 PM, Helmut Schaa
>>> <helmut.schaa@googlemail.com> wrote:
>>> > Am Montag 12 Juli 2010 schrieb Ivo Van Doorn:
>>> >> I am currently looking into the old problem of the mac80211 rate
>>> >> control algorithms
>>> >> and USB devices. The Ralink USB devices (and as far as I know, the
>>> >> other USB devices
>>> >> as well), do not work well with the PID and Minstrel algorithms. This
>>> >> is caused by the
>>> >> fact that USB devices do not report the TX status to mac80211.
>>> >
>>> > Ivo, do you know by any chance if the USB devices also have a TX_STA_FIFO
>>> > register like the PCI variants? Does it contain useful data or just crap?
>>>
>>> Well I guess he has the registers (we don't have rt2870 specific specsheets,
>>> but the register definitions from the original Ralink driver to
>>> suggest the register
>>> is there). However, even if it contains valid data, how do you want to match
>>> the contents of that register with the sent frames in the queue?
>>
>> We could stuff a unique packet ID into the TXWI and the TX_STA_FIFO should
>> contain the same ID alongside the TX status after the frame was processed
>> by the hw.
>
> True, but we would have the same problem in rt2800pci, that the number
> of bits is too limited to completely identify a queue + queue index correctly.
We could have a table that matches queue and queue index to the
packet's ID. So if we're sending packet #47 from queue #1, and it gets
assigned id #9, then we drop that information into the table - so when
the hardware tells us the status of packet id #9 we can look up which
queue it is and send it to the right place.
Of course, this means storing a stack of extra data in system memory,
as well as having the complexity of looking up the queue data when we
get the status back, but if we've only got limited bits, then that'll
set a hard limit on the amount of data and time to retrieve, and we
may not even need all of it unless the hardware's running at full
capacity. We could reduce it further if we don't need a status of
*every* packet - we could potentially get away with only storing data
for, let's say, every fourth packet or something.
As we're likely to see similarly crippled devices elsewhere, maybe we
could incorporate this type of accounting into mac80211 somewhere.
Of course, this could just be a huge stack of overhead for a problem
that could be solved much more elegantly, but yeah.
*hands over $0.02*
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* [PATCH] ath5k: clean up rxlink handling
From: Bruno Randolf @ 2010-07-14 1:53 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
There were a few places where the sc->rxlink pointer was set to NULL "just in
case". This helps nothing - quite to the contrary it is problematic since it
can create self-linked rx descriptors in the middle of the list of receive
buffers.
Here is an example how this could happen (thanks Bob!):
cpu 0: cpu 1:
ath5k_rx_stop
ath5k_tasklet_rx
sc->rxlink = NULL; /* just in case */
// following doesn't link used
// buffer to prev.
ath5k_rxbuf_setup()
In the case of ath5k_rx_stop() and ath5k_stop_locked() buffers/descriptors are
not changed so rxlink should not be changed as well.
In ath5k_intr() we seem to try to work around a hardware bug, as the comment
(which is copied 1:1 from the HAL) suggests. I don't see how this could help.
Also the HAL does not set rxlink in this case (So where does this code come
from? It has been there since the first import of ath5k). Changed to just
increment a statistics counter.
After this patch rxlink is only set to NULL before we initialize rx descriptors
and updated when the descriptors are linked together.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/ath5k/base.c | 7 ++-----
drivers/net/wireless/ath/ath5k/base.h | 1 +
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index b0e1ca9..0d5de25 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1728,8 +1728,6 @@ ath5k_rx_stop(struct ath5k_softc *sc)
ath5k_hw_stop_rx_dma(ah); /* disable DMA engine */
ath5k_debug_printrxbuffs(sc, ah);
-
- sc->rxlink = NULL; /* just in case */
}
static unsigned int
@@ -2633,8 +2631,7 @@ ath5k_stop_locked(struct ath5k_softc *sc)
if (!test_bit(ATH_STAT_INVALID, sc->status)) {
ath5k_rx_stop(sc);
ath5k_hw_phy_disable(ah);
- } else
- sc->rxlink = NULL;
+ }
return 0;
}
@@ -2771,7 +2768,7 @@ ath5k_intr(int irq, void *dev_id)
* RXE bit is written, but it doesn't work at
* least on older hardware revs.
*/
- sc->rxlink = NULL;
+ sc->stats.rxeol_intr++;
}
if (status & AR5K_INT_TXURN) {
/* bump tx trigger level */
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index 86c90f4..dc1241f 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -137,6 +137,7 @@ struct ath5k_statistics {
unsigned int mib_intr;
unsigned int rxorn_intr;
+ unsigned int rxeol_intr;
};
#if CHAN_DEBUG
^ permalink raw reply related
* Re: [PATCH 2/2] ath5k: disable tasklets during reset
From: Bruno Randolf @ 2010-07-14 1:35 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, ath5k-devel, jirislaby, mickflemm,
lrodriguez
In-Reply-To: <1279035161-10802-2-git-send-email-me@bobcopeland.com>
On Wed July 14 2010 00:32:41 Bob Copeland wrote:
> Based on a patch from Bruno Randolf, attempting useful
> work while we are resetting the chip just leads to interface
> lockups and bad descriptor data, and possibly DMAing to
> freed buffers. Let's suspend all tasklets while
> reprogramming the registers in the card to avoid such
> problems.
>
> In the future we can convert the tasklets to threaded
> interrupt handlers to simplify things.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/base.c | 20 ++++++++++++++------
> 1 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/base.c
> b/drivers/net/wireless/ath/ath5k/base.c index b290cc6..b0e1ca9 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -2639,6 +2639,15 @@ ath5k_stop_locked(struct ath5k_softc *sc)
> return 0;
> }
>
> +static void stop_tasklets(struct ath5k_softc *sc)
> +{
> + tasklet_kill(&sc->rxtq);
> + tasklet_kill(&sc->txtq);
> + tasklet_kill(&sc->calib);
> + tasklet_kill(&sc->beacontq);
> + tasklet_kill(&sc->ani_tasklet);
> +}
> +
> /*
> * Stop the device, grabbing the top-level lock to protect
> * against concurrent entry through ath5k_init (which can happen
> @@ -2683,11 +2692,7 @@ ath5k_stop_hw(struct ath5k_softc *sc)
> mmiowb();
> mutex_unlock(&sc->lock);
>
> - tasklet_kill(&sc->rxtq);
> - tasklet_kill(&sc->txtq);
> - tasklet_kill(&sc->calib);
> - tasklet_kill(&sc->beacontq);
> - tasklet_kill(&sc->ani_tasklet);
> + stop_tasklets(sc);
>
> ath5k_rfkill_hw_stop(sc->ah);
>
> @@ -2937,8 +2942,11 @@ ath5k_reset(struct ath5k_softc *sc, struct
> ieee80211_channel *chan)
>
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "resetting\n");
>
> + ath5k_hw_set_imr(ah, 0);
> + synchronize_irq(sc->pdev->irq);
> + stop_tasklets(sc);
> +
> if (chan) {
> - ath5k_hw_set_imr(ah, 0);
> ath5k_txq_cleanup(sc);
> ath5k_rx_stop(sc);
please get this into 2.6.36...
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: move reset to mac80211 workqueue
From: Bruno Randolf @ 2010-07-14 1:35 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, ath5k-devel, jirislaby, mickflemm,
lrodriguez
In-Reply-To: <1279035161-10802-1-git-send-email-me@bobcopeland.com>
On Wed July 14 2010 00:32:40 Bob Copeland wrote:
> We currently trigger a reset via a tasklet when certain error
> conditions are detected so that the card will (eventually)
> restart. Unfortunately this makes locking complicated since
> reset can also be called in process context (e.g. for channel
> change). Currently nothing protects against concurrent resets,
> which can be the source of corruption bugs.
>
> Reset takes too long to spinlock the whole thing, so this
> patch moves deferred resets into the mac80211 workqueue to
> enable use of sc->lock mutex.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/base.c | 38
> +++++++++++++++++-------------- drivers/net/wireless/ath/ath5k/base.h |
> 3 +-
> drivers/net/wireless/ath/ath5k/debug.c | 2 +-
> 3 files changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/base.c
> b/drivers/net/wireless/ath/ath5k/base.c index 20328bd..b290cc6 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -388,7 +388,7 @@ static int ath5k_init(struct ath5k_softc *sc);
> static int ath5k_stop_locked(struct ath5k_softc *sc);
> static int ath5k_stop_hw(struct ath5k_softc *sc);
> static irqreturn_t ath5k_intr(int irq, void *dev_id);
> -static void ath5k_tasklet_reset(unsigned long data);
> +static void ath5k_reset_work(struct work_struct *work);
>
> static void ath5k_tasklet_calibrate(unsigned long data);
>
> @@ -831,11 +831,12 @@ ath5k_attach(struct pci_dev *pdev, struct
> ieee80211_hw *hw)
>
> tasklet_init(&sc->rxtq, ath5k_tasklet_rx, (unsigned long)sc);
> tasklet_init(&sc->txtq, ath5k_tasklet_tx, (unsigned long)sc);
> - tasklet_init(&sc->restq, ath5k_tasklet_reset, (unsigned long)sc);
> tasklet_init(&sc->calib, ath5k_tasklet_calibrate, (unsigned long)sc);
> tasklet_init(&sc->beacontq, ath5k_tasklet_beacon, (unsigned long)sc);
> tasklet_init(&sc->ani_tasklet, ath5k_tasklet_ani, (unsigned long)sc);
>
> + INIT_WORK(&sc->reset_work, ath5k_reset_work);
> +
> ret = ath5k_eeprom_read_mac(ah, mac);
> if (ret) {
> ATH5K_ERR(sc, "unable to read address from EEPROM: 0x%04x\n",
> @@ -2294,8 +2295,8 @@ err_unmap:
> * frame contents are done as needed and the slot time is
> * also adjusted based on current state.
> *
> - * This is called from software irq context (beacontq or restq
> - * tasklets) or user context from ath5k_beacon_config.
> + * This is called from software irq context (beacontq tasklets)
> + * or user context from ath5k_beacon_config.
> */
> static void
> ath5k_beacon_send(struct ath5k_softc *sc)
> @@ -2328,7 +2329,7 @@ ath5k_beacon_send(struct ath5k_softc *sc)
> sc->bmisscount);
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> "stuck beacon, resetting\n");
> - tasklet_schedule(&sc->restq);
> + ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> return;
> }
> @@ -2684,7 +2685,6 @@ ath5k_stop_hw(struct ath5k_softc *sc)
>
> tasklet_kill(&sc->rxtq);
> tasklet_kill(&sc->txtq);
> - tasklet_kill(&sc->restq);
> tasklet_kill(&sc->calib);
> tasklet_kill(&sc->beacontq);
> tasklet_kill(&sc->ani_tasklet);
> @@ -2737,7 +2737,7 @@ ath5k_intr(int irq, void *dev_id)
> */
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> "fatal int, resetting\n");
> - tasklet_schedule(&sc->restq);
> + ieee80211_queue_work(sc->hw, &sc->reset_work);
> } else if (unlikely(status & AR5K_INT_RXORN)) {
> /*
> * Receive buffers are full. Either the bus is busy or
> @@ -2752,7 +2752,7 @@ ath5k_intr(int irq, void *dev_id)
> if (ah->ah_mac_srev < AR5K_SREV_AR5212) {
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> "rx overrun, resetting\n");
> - tasklet_schedule(&sc->restq);
> + ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> else
> tasklet_schedule(&sc->rxtq);
> @@ -2799,14 +2799,6 @@ ath5k_intr(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> -static void
> -ath5k_tasklet_reset(unsigned long data)
> -{
> - struct ath5k_softc *sc = (void *)data;
> -
> - ath5k_reset(sc, sc->curchan);
> -}
> -
> /*
> * Periodically recalibrate the PHY to account
> * for temperature/environment changes.
> @@ -2830,7 +2822,7 @@ ath5k_tasklet_calibrate(unsigned long data)
> * to load new gain values.
> */
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "calibration, resetting\n");
> - ath5k_reset(sc, sc->curchan);
> + ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> if (ath5k_hw_phy_calibrate(ah, sc->curchan))
> ATH5K_ERR(sc, "calibration of channel %u failed\n",
> @@ -2934,6 +2926,8 @@ drop_packet:
> /*
> * Reset the hardware. If chan is not NULL, then also pause rx/tx
> * and change to the given channel.
> + *
> + * This should be called with sc->lock.
> */
> static int
> ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
> @@ -2990,6 +2984,16 @@ err:
> return ret;
> }
>
> +static void ath5k_reset_work(struct work_struct *work)
> +{
> + struct ath5k_softc *sc = container_of(work, struct ath5k_softc,
> + reset_work);
> +
> + mutex_lock(&sc->lock);
> + ath5k_reset(sc, sc->curchan);
> + mutex_unlock(&sc->lock);
> +}
> +
> static int ath5k_start(struct ieee80211_hw *hw)
> {
> return ath5k_init(hw->priv);
> diff --git a/drivers/net/wireless/ath/ath5k/base.h
> b/drivers/net/wireless/ath/ath5k/base.h index 56221bc..86c90f4 100644
> --- a/drivers/net/wireless/ath/ath5k/base.h
> +++ b/drivers/net/wireless/ath/ath5k/base.h
> @@ -47,6 +47,7 @@
> #include <linux/if_ether.h>
> #include <linux/leds.h>
> #include <linux/rfkill.h>
> +#include <linux/workqueue.h>
>
> #include "ath5k.h"
> #include "debug.h"
> @@ -189,7 +190,7 @@ struct ath5k_softc {
> unsigned int led_pin, /* GPIO pin for driving LED */
> led_on; /* pin setting for LED on */
>
> - struct tasklet_struct restq; /* reset tasklet */
> + struct work_struct reset_work; /* deferred chip reset */
>
> unsigned int rxbufsize; /* rx size based on mtu */
> struct list_head rxbuf; /* receive buffer */
> diff --git a/drivers/net/wireless/ath/ath5k/debug.c
> b/drivers/net/wireless/ath/ath5k/debug.c index 8c63886..ebb9c23 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.c
> +++ b/drivers/net/wireless/ath/ath5k/debug.c
> @@ -279,7 +279,7 @@ static ssize_t write_file_reset(struct file *file,
> {
> struct ath5k_softc *sc = file->private_data;
> ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "debug file triggered reset\n");
> - tasklet_schedule(&sc->restq);
> + ieee80211_queue_work(sc->hw, &sc->reset_work);
> return count;
> }
please get this into 2.6.36...
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* [PATCH 0/3] ath9k: flush patches
From: Luis R. Rodriguez @ 2010-07-14 1:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
These patchs add the mac8021 flush op to both ath9k and ath9k_htc.
Tested with AR9003 and AR9271.
Luis R. Rodriguez (3):
ath9k: implement mac80211 flush op
ath9k_htc: implement mac80211 flush op
ath9k_htc: make ath9k_htc_tx_aggr_oper() static
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 33 ++++++++++++++++++++++---
drivers/net/wireless/ath/ath9k/main.c | 19 ++++++++++++++
2 files changed, 48 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 2/3] ath9k_htc: implement mac80211 flush op
From: Luis R. Rodriguez @ 2010-07-14 1:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1279070845-29442-1-git-send-email-lrodriguez@atheros.com>
This implements the mac80211 flush callback to let mac80211
flush the hardware queues when it deems appropriate.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index e38ca66..fc234a7 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1803,6 +1803,29 @@ static void ath9k_htc_set_coverage_class(struct ieee80211_hw *hw,
mutex_unlock(&priv->mutex);
}
+static void ath9k_htc_flush(struct ieee80211_hw *hw, bool drop)
+{
+ struct ath9k_htc_priv *priv = hw->priv;
+ u8 cmd_rsp;
+ int ret;
+
+ mutex_lock(&priv->mutex);
+
+ if (priv->op_flags & OP_INVALID)
+ goto err;
+
+ ath9k_htc_ps_wakeup(priv);
+
+ WMI_CMD(WMI_DRAIN_TXQ_ALL_CMDID);
+ if (drop)
+ skb_queue_purge(&priv->tx_queue);
+
+ ath9k_htc_ps_restore(priv);
+
+err:
+ mutex_unlock(&priv->mutex);
+}
+
struct ieee80211_ops ath9k_htc_ops = {
.tx = ath9k_htc_tx,
.start = ath9k_htc_start,
@@ -1825,4 +1848,5 @@ struct ieee80211_ops ath9k_htc_ops = {
.set_rts_threshold = ath9k_htc_set_rts_threshold,
.rfkill_poll = ath9k_htc_rfkill_poll_state,
.set_coverage_class = ath9k_htc_set_coverage_class,
+ .flush = ath9k_htc_flush,
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] ath9k_htc: make ath9k_htc_tx_aggr_oper() static
From: Luis R. Rodriguez @ 2010-07-14 1:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1279070845-29442-1-git-send-email-lrodriguez@atheros.com>
This fixes this sparse complaint:
CHECK drivers/net/wireless/ath/ath9k/htc_drv_main.c
drivers/net/wireless/ath/ath9k/htc_drv_main.c:441:5:
warning: symbol 'ath9k_htc_tx_aggr_oper'
was not declared. Should it be static?
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index fc234a7..fe4c185 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -438,10 +438,11 @@ static void ath9k_htc_update_rate(struct ath9k_htc_priv *priv,
bss_conf->bssid, be32_to_cpu(trate.capflags));
}
-int ath9k_htc_tx_aggr_oper(struct ath9k_htc_priv *priv,
- struct ieee80211_vif *vif,
- struct ieee80211_sta *sta,
- enum ieee80211_ampdu_mlme_action action, u16 tid)
+static int ath9k_htc_tx_aggr_oper(struct ath9k_htc_priv *priv,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta,
+ enum ieee80211_ampdu_mlme_action action,
+ u16 tid)
{
struct ath_common *common = ath9k_hw_common(priv->ah);
struct ath9k_htc_target_aggr aggr;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] ath9k: implement mac80211 flush op
From: Luis R. Rodriguez @ 2010-07-14 1:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1279070845-29442-1-git-send-email-lrodriguez@atheros.com>
This implements the mac80211 flush callback to let mac80211
flush the hardware queues when it deems appropriate.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 4c0831f..46a6543 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2031,6 +2031,24 @@ static void ath9k_set_coverage_class(struct ieee80211_hw *hw, u8 coverage_class)
mutex_unlock(&sc->mutex);
}
+static void ath9k_flush(struct ieee80211_hw *hw, bool drop)
+{
+ struct ath_wiphy *aphy = hw->priv;
+ struct ath_softc *sc = aphy->sc;
+
+ mutex_lock(&sc->mutex);
+
+ if ((sc->sc_flags & SC_OP_INVALID))
+ goto out;
+
+ ath9k_ps_wakeup(sc);
+ ath_drain_all_txq(sc, !drop);
+ ath9k_ps_restore(sc);
+
+out:
+ mutex_unlock(&sc->mutex);
+}
+
struct ieee80211_ops ath9k_ops = {
.tx = ath9k_tx,
.start = ath9k_start,
@@ -2053,4 +2071,5 @@ struct ieee80211_ops ath9k_ops = {
.sw_scan_complete = ath9k_sw_scan_complete,
.rfkill_poll = ath9k_rfkill_poll_state,
.set_coverage_class = ath9k_set_coverage_class,
+ .flush = ath9k_flush,
};
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] compat-wireless: fix build of ath5k for CONFIG_PM_SLEEP=n
From: Luis R. Rodriguez @ 2010-07-13 22:44 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Hauke Mehrtens, linux-wireless, mcgrof
In-Reply-To: <AANLkTilfUKMido8N4vRF4Em7ewtoUAlkrsp1uaKTx6H9@mail.gmail.com>
On Tue, Jul 13, 2010 at 2:54 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Mon, Jul 12, 2010 at 12:19 PM, Philip A. Prindeville
> <philipp_subx@redfish-solutions.com> wrote:
>> On 07/12/2010 09:30 AM, Luis R. Rodriguez wrote:
>>> On Sun, Jul 11, 2010 at 1:23 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>>> suspend and resume are activated in ath5k if CONFIG_PM_SLEEP is set and
>>>> not if just CONFIG_PM is set.
>>>>
>>>> This should fix the problems reported by Philip Prindeville.
>>>>
>>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>>>
>>> Thanks! Applied and pushed out, at noon we'll have a new tarball with this.
>>>
>>> Luis
>>
>> And...
>>
>>
>> CC [M] /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o
>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c: In function 'l2cap_data_channel':
>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c:4352: error: void value not ignored as it ought to be
>> make[4]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o] Error 1
>> make[3]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth] Error 2
>> make[2]: *** [_module_/home/philipp/kernel/build_i586/compat-wireless-2010-07-12] Error 2
>> make[2]: Leaving directory `/home/philipp/kernel/build_i586/linux-2.6.27.48-astlinux'
>> make[1]: *** [modules] Error 2
>> make[1]: Leaving directory `/home/philipp/kernel/build_i586/compat-wireless-2010-07-12'
>> make: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/wireless/lib80211.ko] Error 2
>
> Thanks for reporting this, I am working on it now.
This is now fixed, I'll push out a new tarball shortly.
Luis
^ permalink raw reply
* Re: [PATCH] compat-wireless: fix build of ath5k for CONFIG_PM_SLEEP=n
From: Luis R. Rodriguez @ 2010-07-13 21:54 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Hauke Mehrtens, linux-wireless, mcgrof
In-Reply-To: <4C3B6AAE.4070204@redfish-solutions.com>
On Mon, Jul 12, 2010 at 12:19 PM, Philip A. Prindeville
<philipp_subx@redfish-solutions.com> wrote:
> On 07/12/2010 09:30 AM, Luis R. Rodriguez wrote:
>> On Sun, Jul 11, 2010 at 1:23 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>> suspend and resume are activated in ath5k if CONFIG_PM_SLEEP is set and
>>> not if just CONFIG_PM is set.
>>>
>>> This should fix the problems reported by Philip Prindeville.
>>>
>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>>
>> Thanks! Applied and pushed out, at noon we'll have a new tarball with this.
>>
>> Luis
>
> And...
>
>
> CC [M] /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o
> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c: In function 'l2cap_data_channel':
> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c:4352: error: void value not ignored as it ought to be
> make[4]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o] Error 1
> make[3]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth] Error 2
> make[2]: *** [_module_/home/philipp/kernel/build_i586/compat-wireless-2010-07-12] Error 2
> make[2]: Leaving directory `/home/philipp/kernel/build_i586/linux-2.6.27.48-astlinux'
> make[1]: *** [modules] Error 2
> make[1]: Leaving directory `/home/philipp/kernel/build_i586/compat-wireless-2010-07-12'
> make: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/wireless/lib80211.ko] Error 2
Thanks for reporting this, I am working on it now.
Luis
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-07-13
From: David Miller @ 2010-07-13 21:36 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20100713203639.GE3835@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 13 Jul 2010 16:36:40 -0400
> Here is the latest batch of wireless LAN goodies intended for 2.6.36.
> It is more-or-less the usual batch of driver updates, including ath9k,
> iwlwifi, rt2x00, and wl1271. The usual flurry of mac80211 updates is
> missing, due mostly to Johannes attending to a personal obligation of a
> happy nature. :-)
>
> Please let me know if there are problems!
Pulled, but please be on the lookout for things that add uses
of "attribute ((packed))" instead of "__packed".
Eric Dumazet converted all of drivers/net and I've been endlessly
seeing partial reverts and new additions of the explicit attribute in
wireless commits.
For example, see the things that got added to iwlwifi this time around.
Please fix them up, all of them, for the next pull request I see from
you.
Thanks!
^ permalink raw reply
* pull request: wireless-next-2.6 2010-07-13
From: John W. Linville @ 2010-07-13 20:36 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Here is the latest batch of wireless LAN goodies intended for 2.6.36.
It is more-or-less the usual batch of driver updates, including ath9k,
iwlwifi, rt2x00, and wl1271. The usual flurry of mac80211 updates is
missing, due mostly to Johannes attending to a personal obligation of a
happy nature. :-)
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 242647bcf8464860f173f3d4d4ab3490d3558518:
hso: remove driver version (2010-07-12 21:21:27 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Ameya Palande (1):
wl12xx: Use MODULE_ALIAS macro at correct postion for SPI bus
Amitkumar Karwar (1):
libertas: Added support for host sleep feature
Christian Lamparter (1):
p54: update MAINTAINERS
Dan Carpenter (2):
prism54: call BUG_ON() earlier
hostap: fixup strlen() math
Emmanuel Grumbach (1):
iwlagn: fix the bit mask of a FH register in stop Tx DMA flow
Felix Fietkau (16):
ath9k_hw: fix a few inconsistencies in initval array names
ath9k_hw: reformat the ar5008, ar9001 and ar9002 initvals to match ar9003
ath9k_hw: sync initvals for ar9001 and ar9002 with Atheros
ath9k_hw: sanitize noise floor values properly on all chips
ath9k_hw: clean up the noise floor calibration code to reduce code duplication
ath9k: fix false positives in the baseband hang check
ath9k: fix crash with WEP in ad-hoc mode
ath9k: fix a potential buffer leak in the STA teardown path
ath9k: fix a buffer leak in A-MPDU completion
ath9k_hw: fix antenna diversity on AR9285
ath9k_hw: fix a sign error in the IQ calibration code
ath9k_hw: fix an off-by-one error in the PDADC boundaries calculation
ath9k_hw: prevent a fast channel change after a rx DMA stuck issue
ath9k_hw: report the TID in the tx status on AR5008-AR9002
ath9k: validate the TID in the tx status information
ath9k: merge noisefloor load implementations
Helmut Schaa (9):
rt2x00: Limit txpower by eeprom values
rt2x00: Convert rt2x00 to use threaded interrupts
rt2x00: Allow beacon update without scheduling a work
rt2x00: Implement broad- and multicast buffering
rt2x00: Use pretbtt irq for fetching beacons on rt2800pci
rt2x00: Use separate mac80211_ops for rt2800pci and rt2800usb
rt2x00: Remove set_tim callback from PCI drivers
rt2x00: Don't initialize beacon interval to 0 on rt2800 devices
rt2x00: Add missing TSF sync mode for AP operation
Ivo van Doorn (8):
rt2x00: Convert AGC value from descriptor to RSSI (dBm)
rt2x00: Rename CONFIG_DISABLE_LINK_TUNING
rt2x00: Disable link tuning while scanning
rt2x00: Fix vgc_level_reg handling
rt2x00: Implement watchdog monitoring
rt2x00: Make rt2800_write_beacon only export to GPL
rt2x00: Move common firmware loading into rt2800lib
rt2x00: Move driver callback functions into the ops structure
Jay Sternberg (1):
iwlwifi: correct descriptions of advanced ucode errors
Jiri Slaby (1):
NET: nl80211, fix lock imbalance and netdev referencing
Johannes Berg (1):
cfg80211: ignore spurious deauth
John W. Linville (5):
Merge branch 'wireless-next-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
mac80211: remove wep dependency
MAINTAINERS: mark adm8211 as an orphan
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Juuso Oikarinen (9):
wl1271: Remove calibration from join command
wl1271: Add TSF handling
wl1271: Use the ARP configuration function from mac80211
wl1271: Use all basic rates for ps-poll, instead of just the slowest
wl1271: Work around AP's with broken ps-poll functionality
wl1271: Update hardware ARP filtering configuration handling
wl1271: Disable dynamic PS based on BT co-ext sense events
wl1271: Fix warning when disconnecting and ad-hoc network
wl1271: Update interface to temporarily disable dynamic PS
Kulikov Vasiliy (1):
adm8211: fix memory leak
Luciano Coelho (5):
wl1271: read fem manufacturer value from nvs
wl1271: moved scan operations to a separate file
wl1271: rewritten scanning code
wl1271: use per-channel max tx power passed by mac80211 when scanning
wl1271: use __packed annotation
Ming Lei (2):
minstrel_ht: fix updating rate with best probability
minstrel_ht: fix check for downgrading of top2 rate
Rajkumar Manoharan (1):
ath9k_htc: fix memory leak in ath9k_hif_usb_alloc_urbs
Reinette Chatre (1):
iwlwifi: remove key information during device restart
Shanyu Zhao (1):
iwlwifi: enable 6050 series Gen2 devices
Wey-Yi Guy (9):
iwlwifi: fix fw_restart module parameter
iwlwifi: add debug print for parsing firmware TLV
iwlwifi: tx fifo queue flush command
iwlwifi: add mac80211 flush callback support
iwlwifi: add support for device tx flush request
iwlwifi: debugfs file for txfifo command testing
iwlwifi: generic parameter define for _agn device
iwlwifi: adding enhance sensitivity table entries
iwlagn: more generic description for iwlagn devices
MAINTAINERS | 9 +-
drivers/net/wireless/adm8211.c | 5 +-
drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 1319 ++--
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 129 +-
drivers/net/wireless/ath/ath9k/ar9001_initvals.h | 2479 +++---
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 12 +-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h |10152 +++++++++++-----------
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 1 +
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 69 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.h | 26 +
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_mac.h | 3 -
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 213 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +
drivers/net/wireless/ath/ath9k/calib.c | 153 +-
drivers/net/wireless/ath/ath9k/calib.h | 7 +-
drivers/net/wireless/ath/ath9k/common.c | 4 +
drivers/net/wireless/ath/ath9k/eeprom.h | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 4 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 4 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 6 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 8 +-
drivers/net/wireless/ath/ath9k/hw-ops.h | 6 -
drivers/net/wireless/ath/ath9k/hw.c | 7 +-
drivers/net/wireless/ath/ath9k/hw.h | 23 +-
drivers/net/wireless/ath/ath9k/init.c | 1 +
drivers/net/wireless/ath/ath9k/mac.h | 3 +
drivers/net/wireless/ath/ath9k/main.c | 27 +-
drivers/net/wireless/ath/ath9k/xmit.c | 65 +-
drivers/net/wireless/hostap/hostap_main.c | 2 +-
drivers/net/wireless/iwlwifi/Kconfig | 9 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 12 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 44 +-
drivers/net/wireless/iwlwifi/iwl-agn-calib.c | 133 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 82 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 7 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 209 +-
drivers/net/wireless/iwlwifi/iwl-agn.h | 4 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 85 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 31 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 5 +-
drivers/net/wireless/iwlwifi/iwl-csr.h | 1 +
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 29 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 4 +
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 4 +
drivers/net/wireless/iwlwifi/iwl-fh.h | 7 +-
drivers/net/wireless/iwlwifi/iwl-hcmd.c | 1 +
drivers/net/wireless/iwlwifi/iwl-rx.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-sta.h | 11 +
drivers/net/wireless/libertas/README | 12 +
drivers/net/wireless/libertas/cmd.c | 61 +-
drivers/net/wireless/libertas/cmd.h | 2 +
drivers/net/wireless/libertas/debugfs.c | 66 +
drivers/net/wireless/libertas/main.c | 34 +-
drivers/net/wireless/prism54/isl_ioctl.c | 2 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 69 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 71 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 14 +-
drivers/net/wireless/rt2x00/rt2800.h | 30 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 434 +-
drivers/net/wireless/rt2x00/rt2800lib.h | 43 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 229 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 178 +-
drivers/net/wireless/rt2x00/rt2x00.h | 25 +-
drivers/net/wireless/rt2x00/rt2x00config.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 96 +-
drivers/net/wireless/rt2x00/rt2x00lib.h | 26 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 65 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 50 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 6 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 4 +
drivers/net/wireless/rt2x00/rt2x00queue.h | 11 +
drivers/net/wireless/rt2x00/rt2x00reg.h | 5 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 50 +
drivers/net/wireless/rt2x00/rt2x00usb.h | 10 +
drivers/net/wireless/rt2x00/rt61pci.c | 68 +-
drivers/net/wireless/rt2x00/rt73usb.c | 7 +
drivers/net/wireless/wl12xx/Makefile | 2 +-
drivers/net/wireless/wl12xx/wl1251_main.c | 1 -
drivers/net/wireless/wl12xx/wl1251_spi.c | 1 +
drivers/net/wireless/wl12xx/wl1271.h | 24 +-
drivers/net/wireless/wl12xx/wl1271_acx.c | 41 +-
drivers/net/wireless/wl12xx/wl1271_acx.h | 15 +-
drivers/net/wireless/wl12xx/wl1271_boot.c | 4 +-
drivers/net/wireless/wl12xx/wl1271_cmd.c | 248 +-
drivers/net/wireless/wl12xx/wl1271_cmd.h | 68 -
drivers/net/wireless/wl12xx/wl1271_conf.h | 16 +-
drivers/net/wireless/wl12xx/wl1271_event.c | 99 +-
drivers/net/wireless/wl12xx/wl1271_event.h | 1 +
drivers/net/wireless/wl12xx/wl1271_main.c | 174 +-
drivers/net/wireless/wl12xx/wl1271_rx.c | 6 -
drivers/net/wireless/wl12xx/wl1271_scan.c | 257 +
drivers/net/wireless/wl12xx/wl1271_scan.h | 109 +
drivers/net/wireless/wl12xx/wl1271_spi.c | 1 +
net/mac80211/cfg.c | 5 +
net/mac80211/main.c | 5 +-
net/mac80211/rc80211_minstrel_ht.c | 6 +-
net/mac80211/tkip.c | 8 +-
net/mac80211/tkip.h | 2 +-
net/mac80211/wep.c | 24 +-
net/mac80211/wep.h | 2 +-
net/mac80211/wpa.c | 5 +-
net/wireless/mlme.c | 8 +-
net/wireless/nl80211.c | 2 +-
106 files changed, 9722 insertions(+), 8517 deletions(-)
create mode 100644 drivers/net/wireless/wl12xx/wl1271_scan.c
create mode 100644 drivers/net/wireless/wl12xx/wl1271_scan.h
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-07-13.patch.bz2
--
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: Rate control & USB
From: Ivo Van Doorn @ 2010-07-13 19:51 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless, Johannes Berg, Felix Fietkau
In-Reply-To: <201007132115.16101.helmut.schaa@googlemail.com>
On Tue, Jul 13, 2010 at 9:15 PM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Am Dienstag 13 Juli 2010 schrieb Ivo Van Doorn:
>> On Mon, Jul 12, 2010 at 9:14 PM, Helmut Schaa
>> <helmut.schaa@googlemail.com> wrote:
>> > Am Montag 12 Juli 2010 schrieb Ivo Van Doorn:
>> >> I am currently looking into the old problem of the mac80211 rate
>> >> control algorithms
>> >> and USB devices. The Ralink USB devices (and as far as I know, the
>> >> other USB devices
>> >> as well), do not work well with the PID and Minstrel algorithms. This
>> >> is caused by the
>> >> fact that USB devices do not report the TX status to mac80211.
>> >
>> > Ivo, do you know by any chance if the USB devices also have a TX_STA_FIFO
>> > register like the PCI variants? Does it contain useful data or just crap?
>>
>> Well I guess he has the registers (we don't have rt2870 specific specsheets,
>> but the register definitions from the original Ralink driver to
>> suggest the register
>> is there). However, even if it contains valid data, how do you want to match
>> the contents of that register with the sent frames in the queue?
>
> We could stuff a unique packet ID into the TXWI and the TX_STA_FIFO should
> contain the same ID alongside the TX status after the frame was processed
> by the hw.
True, but we would have the same problem in rt2800pci, that the number
of bits is too limited to completely identify a queue + queue index correctly.
>> And another downside, is that the above only applies to rt2800usb, and not
>> for rt73usb and rt2500usb, which neither have the TX status register, and were
>> replaced with statistics registers (which I want to read for the batch
>> TX status).
>
> Ok, that's a valid argument ...
:)
Ivo
^ permalink raw reply
* Re: rt2x00: slow wifi with correct basic rate bitmap (was Re: stable? quality assurance?)
From: Stefan Richter @ 2010-07-13 19:18 UTC (permalink / raw)
To: Alejandro Riveira Fernández
Cc: Martin Steigerwald, linux-kernel, Johannes Berg, John W. Linville,
linux-wireless
In-Reply-To: <20100713200643.24ce019e@varda>
Alejandro Riveira Fernández wrote:
> El Tue, 13 Jul 2010 14:50:14 +0200
> Stefan Richter <stefanr@s5r6.in-berlin.de> escribió:
>> There were promises made in this thread? Then I must have read a
>> different mailinglist or so.
>
> Ok no promises.
> Maybe I read to much in to Mr Tso previous mail. My apologies
> [quote]
> > So I tend to use -rc3, -rc4, and -rc5 kernels on my laptops, and when
> > I find bugs, I report them and I help fix them. If more people did
> > that, then the 2.6.X.0 releases would be more stable. But kernel
> > development is a volunteer effort, so it's up to the volunteers to
> > test and fix bugs during the rc4, -rc5 and -rc6 time frame.
>
> [...]
> > [...] Linux may be a very good bargain (look
> > at how much Oracle has increased its support contracts for Solaris!),
> > but it's still not a free lunch. At the end of the day, you get what
> > you put into it.
>
> I tested the kernels i reported the bugs and helped (to the best of my
> knowledge; I'm not a programmer)
> I got no result.
"You get what you put into it" probably did not mean "report a bug, get
it fixed, every time". Often enough, kernel bugs or hardware quirks are
very hard to fix without direct access to affected hardware.
Here is how my involvement with Linux started: I reported a bug but
nobody reacted. I collected some more information, reported the bug
again, and it was immediately fixed by the driver authors. From then on
I kept following driver development as a tester and answered user
questions. A few years later, the driver authors all had left for other
projects but there were still bugs to tackle. So I started to write and
submit bug fixes myself. (I'm not a programmer either but by then I
already knew a lot about the subsystem.)
--
Stefan Richter
-=====-==-=- -=== -==-=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Rate control & USB
From: Helmut Schaa @ 2010-07-13 19:15 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: linux-wireless, Johannes Berg, Felix Fietkau
In-Reply-To: <AANLkTil9g4VT2tROcjSYu1hGNQ04M5psSzxLfpOGE9DS@mail.gmail.com>
Am Dienstag 13 Juli 2010 schrieb Ivo Van Doorn:
> On Mon, Jul 12, 2010 at 9:14 PM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
> > Am Montag 12 Juli 2010 schrieb Ivo Van Doorn:
> >> I am currently looking into the old problem of the mac80211 rate
> >> control algorithms
> >> and USB devices. The Ralink USB devices (and as far as I know, the
> >> other USB devices
> >> as well), do not work well with the PID and Minstrel algorithms. This
> >> is caused by the
> >> fact that USB devices do not report the TX status to mac80211.
> >
> > Ivo, do you know by any chance if the USB devices also have a TX_STA_FIFO
> > register like the PCI variants? Does it contain useful data or just crap?
>
> Well I guess he has the registers (we don't have rt2870 specific specsheets,
> but the register definitions from the original Ralink driver to
> suggest the register
> is there). However, even if it contains valid data, how do you want to match
> the contents of that register with the sent frames in the queue?
We could stuff a unique packet ID into the TXWI and the TX_STA_FIFO should
contain the same ID alongside the TX status after the frame was processed
by the hw.
> And another downside, is that the above only applies to rt2800usb, and not
> for rt73usb and rt2500usb, which neither have the TX status register, and were
> replaced with statistics registers (which I want to read for the batch
> TX status).
Ok, that's a valid argument ...
Helmut
^ permalink raw reply
* Re: rt2x00: slow wifi with correct basic rate bitmap (was Re: stable? quality assurance?)
From: Alejandro Riveira Fernández @ 2010-07-13 19:07 UTC (permalink / raw)
To: John W. Linville
Cc: Stefan Richter, Martin Steigerwald, linux-kernel, Johannes Berg,
linux-wireless
In-Reply-To: <20100713183851.GD3835@tuxdriver.com>
El Tue, 13 Jul 2010 14:38:52 -0400
"John W. Linville" <linville@tuxdriver.com> escribió:
>
> > > isn't using the basic_rates map properly. But after reviewing the
> > > code and the data I have, I can't see what would be causing that.
> > > It is at least possible that your AP is sending bad rate information.
> > > Have you tried this device with other APs?
I do no know; i captured some debug data for Ivo back in the day and from
what he said all the info passed to the card was correct...
See http://lkml.org/lkml/2009/5/25/163 ( link is in bugzilla) in case
you missed it
> >
> > No; this is a desktop pc that connects to my home router/AP. A new wifi
> > card is cheaper than a new AP ...
>
> Perhaps you could capture some beacons from that AP?
f you explain how; I can try.
>
^ permalink raw reply
* Compat-wireless release for 2010-07-13 is baked
From: Compat-wireless cronjob account @ 2010-07-13 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
5819544..122c2ee history -> origin/history
+ dfab7fb...7e28ebb master -> origin/master (forced update)
589643b..1c5474a stable -> origin/stable
* [new tag] next-20100713 -> next-20100713
* [new tag] v2.6.35-rc5 -> v2.6.35-rc5
compat-wireless code metrics
495975 - Total upstream lines of code being pulled
1419 - backport code changes
1186 - backport code additions
233 - backport code deletions
5766 - backport from compat module
7185 - total backport code
1.4487 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2456 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100713
compat-wireless release: compat-wireless-2010-07-12
^ permalink raw reply
* Re: rt2x00: slow wifi with correct basic rate bitmap (was Re: stable? quality assurance?)
From: John W. Linville @ 2010-07-13 18:38 UTC (permalink / raw)
To: Alejandro Riveira Fernández
Cc: Stefan Richter, Martin Steigerwald, linux-kernel, Johannes Berg,
linux-wireless
In-Reply-To: <20100713201927.78674c4a@varda>
On Tue, Jul 13, 2010 at 08:19:27PM +0200, Alejandro Riveira Fernández wrote:
> El Tue, 13 Jul 2010 11:35:31 -0400
> "John W. Linville" <linville@tuxdriver.com> escribió:
>
>
> >
> > The patch (7e0986c1) corrects an obvious error. Reverting it might
> > improve your (i.e. Alejandro) performance, but it seems likely to
> > cause connectivity problems for others.
> >
> > The fact that reverting 7e098c1 helps you suggests that rt2500usb
>
> my card is pci so it would be rt2500pci
Sorry, typo...
> > isn't using the basic_rates map properly. But after reviewing the
> > code and the data I have, I can't see what would be causing that.
> > It is at least possible that your AP is sending bad rate information.
> > Have you tried this device with other APs?
>
> No; this is a desktop pc that connects to my home router/AP. A new wifi
> card is cheaper than a new AP ...
Perhaps you could capture some beacons from that AP?
--
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: rt2x00: slow wifi with correct basic rate bitmap (was Re: stable? quality assurance?)
From: Alejandro Riveira Fernández @ 2010-07-13 18:19 UTC (permalink / raw)
To: John W. Linville
Cc: Stefan Richter, Martin Steigerwald, linux-kernel, Johannes Berg,
linux-wireless
In-Reply-To: <20100713153530.GC3835@tuxdriver.com>
El Tue, 13 Jul 2010 11:35:31 -0400
"John W. Linville" <linville@tuxdriver.com> escribió:
>
> The patch (7e0986c1) corrects an obvious error. Reverting it might
> improve your (i.e. Alejandro) performance, but it seems likely to
> cause connectivity problems for others.
>
> The fact that reverting 7e098c1 helps you suggests that rt2500usb
my card is pci so it would be rt2500pci
> isn't using the basic_rates map properly. But after reviewing the
> code and the data I have, I can't see what would be causing that.
> It is at least possible that your AP is sending bad rate information.
> Have you tried this device with other APs?
No; this is a desktop pc that connects to my home router/AP. A new wifi
card is cheaper than a new AP ...
>
> John
^ 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