* Re: [2.6 patch] schedule SHAPER for removal
From: Jan Engelhardt @ 2006-01-19 20:18 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Alan Cox, jgarzik, netdev, linux-kernel
In-Reply-To: <20060119021150.GC19398@stusta.de>
>Subject: [2.6 patch] schedule SHAPER for removal
Replaced by what; the QoS subsystem?
> config SHAPER
>- tristate "Traffic Shaper (EXPERIMENTAL)"
>+ tristate "Traffic Shaper (OBSOLETE)"
> depends on EXPERIMENTAL
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
^ permalink raw reply
* Re: [2.6 patch] schedule SHAPER for removal
From: Benjamin LaHaise @ 2006-01-19 21:57 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Alan Cox, jgarzik, netdev, linux-kernel
In-Reply-To: <20060119021150.GC19398@stusta.de>
On Thu, Jan 19, 2006 at 03:11:50AM +0100, Adrian Bunk wrote:
> +What: Traffic Shaper (CONFIG_SHAPER)
> +When: July 2006
> +Why: obsoleted by the code in net/sched/
> +Who: Adrian Bunk <bunk@stusta.de
This length of obsolete cycles is way too short -- it's not even enough
time for a single release of a distro to ship with the feature marked as
obsolete.
-ben
^ permalink raw reply
* Re: WCONF, netlink based WE replacement.
From: Harald Welte @ 2006-01-20 8:48 UTC (permalink / raw)
To: Thomas Graf; +Cc: Michael Buesch, linux-kernel, netdev
In-Reply-To: <20060113131503.GA379@postel.suug.ch>
[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]
On Fri, Jan 13, 2006 at 02:15:03PM +0100, Thomas Graf wrote:
> * Michael Buesch <mbuesch@freenet.de> 2006-01-12 18:24
> > This is an attempt to rewrite the Wireless Extensions
> > userspace API, using netlink sockets.
> > There should also be a notification API, to inform
> > userspace for changes (config changes, state changes, etc).
> > It is not implemented, yet.
>
> I'll only comment on the netlink bits and leave the rest to
> others. I'd highly recommend the use of attributes instead
> of fixed message structures to allow the interface to be
> flexible to extensions while staying binary compatible.
I can only second Thomas' suggestion. The power and flexibility of the
use of netlink is only really unveiled if you use attributes. This way
you can easily extend your data structures later on without breaking
compatibility, etc.
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: My vote against eepro* removal
From: kus Kusche Klaus @ 2006-01-20 9:37 UTC (permalink / raw)
To: John Ronciak, Adrian Bunk
Cc: kus Kusche Klaus, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
> From: John Ronciak
> During the watchdog the e100 driver reads all of the status registers
> from the actual hardware. There are 26 (worst case) register reads.
> There is also a spin lock for another check in the watchdog. It would
> still surprise me that all of this would take 500 usec. If you are
> seeing this delay, you can comment out the scheduling of the watchdog
> to see if this goes away. We'll need to narrow down exactly what in
> the watchdog is causing the delay
Retested it.
Software:
2.6.15.1-rt6, no additional patches, configured for full preemption.
Hardware:
500 MHz Pentium 3
According to lspci: 82443+82371 Chipset (440 BX + PIIX4)
According to lspci: 82559ER (09) e100
100 Mbit full duplex
Measurement software:
* I start the rtc at 8192 Hz.
* I read from /dev/rtc in a usermode realtime process.
* After each read, I read the tsc and calculate the interval.
* It should be 122 us most of the time, and indeed it is.
At rtprio 2-99, practically all measurements are < 160-175 us
on an otherwise idle machine (160 for 99, 175 for 2).
At rtprio 1, there are some intervals of up to 300 us on an
idle machine.
* The program records the intervals in internal arrays and prints
them at the end, it doesn't perform any I/O while it is running.
Basically, my software measures how long it takes for a realtime
process at prio n to get executed after it became ready:
The actual interval minus 122 is the time the process was waiting
for the CPU (didn't get scheduled).
This means that there was continuous CPU activity for at least
that long, either at a higher or the same rt prio, on in
non-thread kernel code.
(the rtc threaded interrupt handler is running above all others)
Effect of the e100 driver:
* There is no measurable effect when my test program is running
at prio 2 - 99.
* For prio 1, I get an interval of 500-650 us every 2 seconds,
which indicates a scheduling latency of 380-530 us.
Hence, some piece of code is running for ~500 us at rt prio 1.
Analysis of e100:
* If I comment out the whole body of e100_watchdog except for the
timer re-registration, the delays are gone (so it is really the
body of e100_watchdog). However, this makes eth0 non-functional.
* Commenting out parts of it, I found out that most of the time
goes into its first half: The code from mii_ethtool_gset to
mii_check_link (including) makes the big difference, as far as
I can tell especially mii_ethtool_gset.
Effect of desktop preemption:
With desktop preemption insted of full preemption, the 400-500 us
scheduling delay hits at any rt priority, even at 99, i.e. the
CPU is occupied by non-thread kernel code.
Again, commenting out e100_watchdog brings the delays back to
well below 400 us.
Latency traces:
None.
The latency tracer does not record this scheduling latency.
My max. traces are around 35 us with full preemption and
around 70 us with desktop preemption, and are not related to e100.
--
Klaus Kusche (Software Development - Control Systems)
KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
E-Mail: kus@keba.com WWW: www.keba.com
^ permalink raw reply
* Re: My vote against eepro* removal
From: Evgeniy Polyakov @ 2006-01-20 9:55 UTC (permalink / raw)
To: kus Kusche Klaus
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323324@MAILIT.keba.co.at>
On Fri, Jan 20, 2006 at 10:37:43AM +0100, kus Kusche Klaus (kus@keba.com) wrote:
> > From: John Ronciak
> > During the watchdog the e100 driver reads all of the status registers
> > from the actual hardware. There are 26 (worst case) register reads.
> > There is also a spin lock for another check in the watchdog. It would
> > still surprise me that all of this would take 500 usec. If you are
> > seeing this delay, you can comment out the scheduling of the watchdog
> > to see if this goes away. We'll need to narrow down exactly what in
> > the watchdog is causing the delay
>
> Retested it.
...
> Effect of the e100 driver:
> * There is no measurable effect when my test program is running
> at prio 2 - 99.
> * For prio 1, I get an interval of 500-650 us every 2 seconds,
> which indicates a scheduling latency of 380-530 us.
> Hence, some piece of code is running for ~500 us at rt prio 1.
>
> Analysis of e100:
> * If I comment out the whole body of e100_watchdog except for the
> timer re-registration, the delays are gone (so it is really the
> body of e100_watchdog). However, this makes eth0 non-functional.
> * Commenting out parts of it, I found out that most of the time
> goes into its first half: The code from mii_ethtool_gset to
> mii_check_link (including) makes the big difference, as far as
> I can tell especially mii_ethtool_gset.
Each MDIO read can take upto 2 msecs (!) and at least 20 usecs in e100,
and this runs in timer handler.
Concider attaching (only compile tested) patch which moves e100 watchdog
into workqueue.
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 22cd045..e884578 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -549,7 +549,7 @@ struct nic {
enum phy phy;
struct params params;
struct net_device_stats net_stats;
- struct timer_list watchdog;
+ struct work_struct watchdog;
struct timer_list blink_timer;
struct mii_if_info mii;
struct work_struct tx_timeout_task;
@@ -1495,7 +1495,7 @@ static void e100_adjust_adaptive_ifs(str
}
}
-static void e100_watchdog(unsigned long data)
+static void e100_watchdog(void *data)
{
struct nic *nic = (struct nic *)data;
struct ethtool_cmd cmd;
@@ -1539,7 +1539,7 @@ static void e100_watchdog(unsigned long
else
nic->flags &= ~ich_10h_workaround;
- mod_timer(&nic->watchdog, jiffies + E100_WATCHDOG_PERIOD);
+ schedule_delayed_work(&nic->watchdog, E100_WATCHDOG_PERIOD);
}
static inline void e100_xmit_prepare(struct nic *nic, struct cb *cb,
@@ -2004,7 +2004,7 @@ static int e100_up(struct nic *nic)
goto err_clean_cbs;
e100_set_multicast_list(nic->netdev);
e100_start_receiver(nic, NULL);
- mod_timer(&nic->watchdog, jiffies);
+ schedule_work(&nic->watchdog);
if((err = request_irq(nic->pdev->irq, e100_intr, SA_SHIRQ,
nic->netdev->name, nic->netdev)))
goto err_no_irq;
@@ -2016,7 +2016,7 @@ static int e100_up(struct nic *nic)
return 0;
err_no_irq:
- del_timer_sync(&nic->watchdog);
+ cancel_rearming_delayed_work(&nic->watchdog);
err_clean_cbs:
e100_clean_cbs(nic);
err_rx_clean_list:
@@ -2031,7 +2031,7 @@ static void e100_down(struct nic *nic)
netif_stop_queue(nic->netdev);
e100_hw_reset(nic);
free_irq(nic->pdev->irq, nic->netdev);
- del_timer_sync(&nic->watchdog);
+ flush_scheduled_work();
netif_carrier_off(nic->netdev);
e100_clean_cbs(nic);
e100_rx_clean_list(nic);
@@ -2570,9 +2570,7 @@ static int __devinit e100_probe(struct p
pci_set_master(pdev);
- init_timer(&nic->watchdog);
- nic->watchdog.function = e100_watchdog;
- nic->watchdog.data = (unsigned long)nic;
+ INIT_WORK(&nic->watchdog, e100_watchdog, nic);
init_timer(&nic->blink_timer);
nic->blink_timer.function = e100_blink_led;
nic->blink_timer.data = (unsigned long)nic;
> --
> Klaus Kusche (Software Development - Control Systems)
> KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
> Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
> E-Mail: kus@keba.com WWW: www.keba.com
--
Evgeniy Polyakov
^ permalink raw reply related
* RE: My vote against eepro* removal
From: kus Kusche Klaus @ 2006-01-20 10:19 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
From: Evgeniy Polyakov
> Each MDIO read can take upto 2 msecs (!) and at least 20
> usecs in e100,
> and this runs in timer handler.
> Concider attaching (only compile tested) patch which moves
> e100 watchdog
> into workqueue.
Hmmm, I don't think moving it around is worth the trouble
(nevertheless, I will test later if I find time).
For a full preemption kernel, both timer code and workqueue code
are executed in a thread of their own. If I know that there is a
500 us piece of code in either of them, I have to adjust the prio
of the corresponding thread (and all others) accordingly anyway.
For a non-full preemption kernel, your patch moves the 500 us
piece of code from kernel to thread context, so it really
improves things. But is 500 us something to worry about in a
non-full preemption kernel?
--
Klaus Kusche (Software Development - Control Systems)
KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
E-Mail: kus@keba.com WWW: www.keba.com
^ permalink raw reply
* RE: My vote against eepro* removal
From: kus Kusche Klaus @ 2006-01-20 10:51 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
From: Evgeniy Polyakov [mailto:johnpol@2ka.mipt.ru]
> Each MDIO read can take upto 2 msecs (!) and at least 20
> usecs in e100,
> and this runs in timer handler.
> Concider attaching (only compile tested) patch which moves
> e100 watchdog
> into workqueue.
Tested the patch. Works and has the expected effects:
Fully preemptible kernel:
No change: 500 us delay at rtprio 1, no delay at higher rtprio.
(you just moved the 500 us piece of code from one rtprio 1 kernel
thread to another rtprio 1 kernel thread).
Kernel with desktop preemption:
Originally: Threads at any rtprio suffered from 500 us delay.
With your patch: Only rtprio 1 threads suffer from 500 us delay,
no delay at higher rtprio.
--
Klaus Kusche (Software Development - Control Systems)
KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
E-Mail: kus@keba.com WWW: www.keba.com
^ permalink raw reply
* Re: My vote against eepro* removal
From: Evgeniy Polyakov @ 2006-01-20 11:02 UTC (permalink / raw)
To: kus Kusche Klaus
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323325@MAILIT.keba.co.at>
On Fri, Jan 20, 2006 at 11:19:20AM +0100, kus Kusche Klaus (kus@keba.com) wrote:
> From: Evgeniy Polyakov
> > Each MDIO read can take upto 2 msecs (!) and at least 20
> > usecs in e100,
> > and this runs in timer handler.
> > Concider attaching (only compile tested) patch which moves
> > e100 watchdog
> > into workqueue.
>
> Hmmm, I don't think moving it around is worth the trouble
> (nevertheless, I will test later if I find time).
>
> For a full preemption kernel, both timer code and workqueue code
> are executed in a thread of their own. If I know that there is a
> 500 us piece of code in either of them, I have to adjust the prio
> of the corresponding thread (and all others) accordingly anyway.
>
> For a non-full preemption kernel, your patch moves the 500 us
> piece of code from kernel to thread context, so it really
> improves things. But is 500 us something to worry about in a
> non-full preemption kernel?
In the worst case it will be milliseconds, which is not very nice
timeout for timer handler...
P.S. above patch works without problems with my e100 card.
> --
> Klaus Kusche (Software Development - Control Systems)
> KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
> Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
> E-Mail: kus@keba.com WWW: www.keba.com
--
Evgeniy Polyakov
^ permalink raw reply
* Re: My vote against eepro* removal
From: Evgeniy Polyakov @ 2006-01-20 11:05 UTC (permalink / raw)
To: kus Kusche Klaus
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323326@MAILIT.keba.co.at>
On Fri, Jan 20, 2006 at 11:51:23AM +0100, kus Kusche Klaus (kus@keba.com) wrote:
> From: Evgeniy Polyakov [mailto:johnpol@2ka.mipt.ru]
> > Each MDIO read can take upto 2 msecs (!) and at least 20
> > usecs in e100,
> > and this runs in timer handler.
> > Concider attaching (only compile tested) patch which moves
> > e100 watchdog
> > into workqueue.
>
> Tested the patch. Works and has the expected effects:
>
> Fully preemptible kernel:
> No change: 500 us delay at rtprio 1, no delay at higher rtprio.
> (you just moved the 500 us piece of code from one rtprio 1 kernel
> thread to another rtprio 1 kernel thread).
>
> Kernel with desktop preemption:
> Originally: Threads at any rtprio suffered from 500 us delay.
> With your patch: Only rtprio 1 threads suffer from 500 us delay,
> no delay at higher rtprio.
Just a hack:
--- drivers/net/e100.c.1 2006-01-20 13:39:19.000000000 +0300
+++ drivers/net/e100.c 2006-01-20 14:15:40.000000000 +0300
@@ -879,8 +879,8 @@
writel((reg << 16) | (addr << 21) | dir | data, &nic->csr->mdi_ctrl);
- for(i = 0; i < 100; i++) {
- udelay(20);
+ for(i = 0; i < 1000; i++) {
+ udelay(2);
if((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready)
break;
}
> --
> Klaus Kusche (Software Development - Control Systems)
> KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
> Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
> E-Mail: kus@keba.com WWW: www.keba.com
>
--
Evgeniy Polyakov
^ permalink raw reply
* RE: My vote against eepro* removal
From: kus Kusche Klaus @ 2006-01-20 11:27 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: John Ronciak, Adrian Bunk, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev, Steven Rostedt
From: Evgeniy Polyakov
> Just a hack:
>
> --- drivers/net/e100.c.1 2006-01-20 13:39:19.000000000 +0300
> +++ drivers/net/e100.c 2006-01-20 14:15:40.000000000 +0300
> @@ -879,8 +879,8 @@
>
> writel((reg << 16) | (addr << 21) | dir | data,
> &nic->csr->mdi_ctrl);
>
> - for(i = 0; i < 100; i++) {
> - udelay(20);
> + for(i = 0; i < 1000; i++) {
> + udelay(2);
> if((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready)
> break;
> }
My test environment and software is not precise enough for small
improvements, but I'd say this results in a 10-15 % improvement
(i.e. something like 50 us shorter delay) on the average.
To be sure, one would have to take and print tsc timestamps directly
in the watchdog code, but printk's mess up my timings.
--
Klaus Kusche (Software Development - Control Systems)
KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
E-Mail: kus@keba.com WWW: www.keba.com
^ permalink raw reply
* [2.6 patch] AIRO{,_CS} <-> CRYPTO fixes
From: Adrian Bunk @ 2006-01-21 0:35 UTC (permalink / raw)
To: linville; +Cc: netdev, linux-kernel
CRYPTO is a helper variable, and to make it easier for users, it should
therefore select'ed and not be listed in the dependencies.
drivers/net/wireless/airo.c requires CONFIG_CRYPTO for compilations.
Therefore, AIRO_CS also has to CRYPTO.
Additionally, this patch removes the #ifdef's for the non-compiling
CRYPTO=n case from drivers/net/wireless/airo.c.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/wireless/Kconfig | 4 +-
drivers/net/wireless/airo.c | 56 +----------------------------------
2 files changed, 5 insertions(+), 55 deletions(-)
--- linux-2.6.15-mm2-full/drivers/net/wireless/Kconfig.old 2006-01-10 20:40:12.000000000 +0100
+++ linux-2.6.15-mm2-full/drivers/net/wireless/Kconfig 2006-01-10 21:06:08.000000000 +0100
@@ -244,6 +244,7 @@
config AIRO
tristate "Cisco/Aironet 34X/35X/4500/4800 ISA and PCI cards"
- depends on NET_RADIO && ISA_DMA_API && CRYPTO && (PCI || BROKEN)
+ depends on NET_RADIO && ISA_DMA_API && (PCI || BROKEN)
+ select CRYPTO
---help---
This is the standard Linux driver to support Cisco/Aironet ISA and
PCI 802.11 wireless cards.
@@ -391,6 +392,7 @@
config AIRO_CS
tristate "Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards"
depends on NET_RADIO && PCMCIA && (BROKEN || !M32R)
+ select CRYPTO
---help---
This is the standard Linux driver to support Cisco/Aironet PCMCIA
802.11 wireless cards. This driver is the same as the Aironet
--- linux-2.6.15-mm2-full/drivers/net/wireless/airo.c.old 2006-01-10 20:40:31.000000000 +0100
+++ linux-2.6.15-mm2-full/drivers/net/wireless/airo.c 2006-01-10 20:42:44.000000000 +0100
@@ -36,6 +36,7 @@
#include <linux/in.h>
#include <linux/bitops.h>
#include <linux/scatterlist.h>
+#include <linux/crypto.h>
#include <asm/io.h>
#include <asm/system.h>
@@ -87,14 +88,6 @@
#include <linux/delay.h>
#endif
-/* Support Cisco MIC feature */
-#define MICSUPPORT
-
-#if defined(MICSUPPORT) && !defined(CONFIG_CRYPTO)
-#warning MIC support requires Crypto API
-#undef MICSUPPORT
-#endif
-
/* Hack to do some power saving */
#define POWER_ON_DOWN
@@ -1118,7 +1111,6 @@
static int writerids(struct net_device *dev, aironet_ioctl *comp);
static int flashcard(struct net_device *dev, aironet_ioctl *comp);
#endif /* CISCO_EXT */
-#ifdef MICSUPPORT
static void micinit(struct airo_info *ai);
static int micsetup(struct airo_info *ai);
static int encapsulate(struct airo_info *ai, etherHead *pPacket, MICBuffer *buffer, int len);
@@ -1127,9 +1119,6 @@
static u8 airo_rssi_to_dbm (tdsRssiEntry *rssi_rid, u8 rssi);
static u8 airo_dbm_to_pct (tdsRssiEntry *rssi_rid, u8 dbm);
-#include <linux/crypto.h>
-#endif
-
struct airo_info {
struct net_device_stats stats;
struct net_device *dev;
@@ -1190,12 +1179,10 @@
unsigned long scan_timestamp; /* Time started to scan */
struct iw_spy_data spy_data;
struct iw_public_data wireless_data;
-#ifdef MICSUPPORT
/* MIC stuff */
struct crypto_tfm *tfm;
mic_module mod[2];
mic_statistics micstats;
-#endif
HostRxDesc rxfids[MPI_MAX_FIDS]; // rx/tx/config MPI350 descriptors
HostTxDesc txfids[MPI_MAX_FIDS];
HostRidDesc config_desc;
@@ -1229,7 +1216,6 @@
static int flashputbuf(struct airo_info *ai);
static int flashrestart(struct airo_info *ai,struct net_device *dev);
-#ifdef MICSUPPORT
/***********************************************************************
* MIC ROUTINES *
***********************************************************************
@@ -1686,7 +1672,6 @@
digest[2] = (val>>8) & 0xFF;
digest[3] = val & 0xFF;
}
-#endif
static int readBSSListRid(struct airo_info *ai, int first,
BSSListRid *list) {
@@ -2005,7 +1990,6 @@
* Firmware automaticly puts 802 header on so
* we don't need to account for it in the length
*/
-#ifdef MICSUPPORT
if (test_bit(FLAG_MIC_CAPABLE, &ai->flags) && ai->micstats.enabled &&
(ntohs(((u16 *)buffer)[6]) != 0x888E)) {
MICBuffer pMic;
@@ -2022,9 +2006,7 @@
memcpy (sendbuf, &pMic, sizeof(pMic));
sendbuf += sizeof(pMic);
memcpy (sendbuf, buffer, len - sizeof(etherHead));
- } else
-#endif
- {
+ } else {
*payloadLen = cpu_to_le16(len - sizeof(etherHead));
dev->trans_start = jiffies;
@@ -2400,9 +2382,7 @@
ai->shared, ai->shared_dma);
}
}
-#ifdef MICSUPPORT
crypto_free_tfm(ai->tfm);
-#endif
del_airo_dev( dev );
free_netdev( dev );
}
@@ -2726,9 +2706,7 @@
ai->thr_pid = kernel_thread(airo_thread, dev, CLONE_FS | CLONE_FILES);
if (ai->thr_pid < 0)
goto err_out_free;
-#ifdef MICSUPPORT
ai->tfm = NULL;
-#endif
rc = add_airo_dev( dev );
if (rc)
goto err_out_thr;
@@ -2969,10 +2947,8 @@
airo_read_wireless_stats(ai);
else if (test_bit(JOB_PROMISC, &ai->flags))
airo_set_promisc(ai);
-#ifdef MICSUPPORT
else if (test_bit(JOB_MIC, &ai->flags))
micinit(ai);
-#endif
else if (test_bit(JOB_EVENT, &ai->flags))
airo_send_event(dev);
else if (test_bit(JOB_AUTOWEP, &ai->flags))
@@ -3010,12 +2986,10 @@
if ( status & EV_MIC ) {
OUT4500( apriv, EVACK, EV_MIC );
-#ifdef MICSUPPORT
if (test_bit(FLAG_MIC_CAPABLE, &apriv->flags)) {
set_bit(JOB_MIC, &apriv->flags);
wake_up_interruptible(&apriv->thr_wait);
}
-#endif
}
if ( status & EV_LINK ) {
union iwreq_data wrqu;
@@ -3194,11 +3168,8 @@
}
bap_read (apriv, buffer + hdrlen/2, len, BAP0);
} else {
-#ifdef MICSUPPORT
MICBuffer micbuf;
-#endif
bap_read (apriv, buffer, ETH_ALEN*2, BAP0);
-#ifdef MICSUPPORT
if (apriv->micstats.enabled) {
bap_read (apriv,(u16*)&micbuf,sizeof(micbuf),BAP0);
if (ntohs(micbuf.typelen) > 0x05DC)
@@ -3211,15 +3182,10 @@
skb_trim (skb, len + hdrlen);
}
}
-#endif
bap_read(apriv,buffer+ETH_ALEN,len,BAP0);
-#ifdef MICSUPPORT
if (decapsulate(apriv,&micbuf,(etherHead*)buffer,len)) {
badmic:
dev_kfree_skb_irq (skb);
-#else
- if (0) {
-#endif
badrx:
OUT4500( apriv, EVACK, EV_RX);
goto exitrx;
@@ -3430,10 +3396,8 @@
int len = 0;
struct sk_buff *skb;
char *buffer;
-#ifdef MICSUPPORT
int off = 0;
MICBuffer micbuf;
-#endif
memcpy_fromio(&rxd, ai->rxfids[0].card_ram_off, sizeof(rxd));
/* Make sure we got something */
@@ -3448,7 +3412,6 @@
goto badrx;
}
buffer = skb_put(skb,len);
-#ifdef MICSUPPORT
memcpy(buffer, ai->rxfids[0].virtual_host_addr, ETH_ALEN * 2);
if (ai->micstats.enabled) {
memcpy(&micbuf,
@@ -3470,9 +3433,6 @@
dev_kfree_skb_irq (skb);
goto badrx;
}
-#else
- memcpy(buffer, ai->rxfids[0].virtual_host_addr, len);
-#endif
#ifdef WIRELESS_SPY
if (ai->spy_data.spy_number > 0) {
char *sa;
@@ -3689,13 +3649,11 @@
ai->config.authType = AUTH_OPEN;
ai->config.modulation = MOD_CCK;
-#ifdef MICSUPPORT
if ((cap_rid.len>=sizeof(cap_rid)) && (cap_rid.extSoftCap&1) &&
(micsetup(ai) == SUCCESS)) {
ai->config.opmode |= MODE_MIC;
set_bit(FLAG_MIC_CAPABLE, &ai->flags);
}
-#endif
/* Save off the MAC */
for( i = 0; i < ETH_ALEN; i++ ) {
@@ -4170,15 +4128,12 @@
}
len -= ETH_ALEN * 2;
-#ifdef MICSUPPORT
if (test_bit(FLAG_MIC_CAPABLE, &ai->flags) && ai->micstats.enabled &&
(ntohs(((u16 *)pPacket)[6]) != 0x888E)) {
if (encapsulate(ai,(etherHead *)pPacket,&pMic,len) != SUCCESS)
return ERROR;
miclen = sizeof(pMic);
}
-#endif
-
// packet is destination[6], source[6], payload[len-12]
// write the payload length and dst/src/payload
if (bap_setup(ai, txFid, 0x0036, BAP1) != SUCCESS) return ERROR;
@@ -7271,13 +7226,11 @@
case AIROGSTAT: ridcode = RID_STATUS; break;
case AIROGSTATSD32: ridcode = RID_STATSDELTA; break;
case AIROGSTATSC32: ridcode = RID_STATS; break;
-#ifdef MICSUPPORT
case AIROGMICSTATS:
if (copy_to_user(comp->data, &ai->micstats,
min((int)comp->len,(int)sizeof(ai->micstats))))
return -EFAULT;
return 0;
-#endif
case AIRORRID: ridcode = comp->ridnum; break;
default:
return -EINVAL;
@@ -7309,9 +7262,7 @@
static int writerids(struct net_device *dev, aironet_ioctl *comp) {
struct airo_info *ai = dev->priv;
int ridcode;
-#ifdef MICSUPPORT
int enabled;
-#endif
Resp rsp;
static int (* writer)(struct airo_info *, u16 rid, const void *, int, int);
unsigned char *iobuf;
@@ -7368,11 +7319,9 @@
PC4500_readrid(ai,RID_STATSDELTACLEAR,iobuf,RIDSIZE, 1);
-#ifdef MICSUPPORT
enabled = ai->micstats.enabled;
memset(&ai->micstats,0,sizeof(ai->micstats));
ai->micstats.enabled = enabled;
-#endif
if (copy_to_user(comp->data, iobuf,
min((int)comp->len, (int)RIDSIZE))) {
^ permalink raw reply
* [2.6 patch] drivers/net/wireless/ipw2100.c: make ipw2100_wpa_assoc_frame() static
From: Adrian Bunk @ 2006-01-21 0:36 UTC (permalink / raw)
To: yi.zhu, jketreno; +Cc: linville, netdev, linux-kernel
This patch makes the needlessly global ipw2100_wpa_assoc_frame() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2100.c.old 2006-01-21 00:53:47.000000000 +0100
+++ linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2100.c 2006-01-21 00:53:59.000000000 +0100
@@ -5771,8 +5771,8 @@
return ret;
}
-void ipw2100_wpa_assoc_frame(struct ipw2100_priv *priv,
- char *wpa_ie, int wpa_ie_len)
+static void ipw2100_wpa_assoc_frame(struct ipw2100_priv *priv,
+ char *wpa_ie, int wpa_ie_len)
{
struct ipw2100_wpa_assoc_frame frame;
^ permalink raw reply
* [2.6 patch] drivers/net/wireless/ipw2200: possible cleanups
From: Adrian Bunk @ 2006-01-21 0:39 UTC (permalink / raw)
To: yi.zhu, jketreno; +Cc: linville, netdev, linux-kernel
This patch contains the following possible cleanups:
- make needlessly global functions static
- "extern inline" -> "static inline"
- #if 0 the unused global function ipw_led_activity_on()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/wireless/ipw2200.c | 33 ++++++++++++++++++---------------
drivers/net/wireless/ipw2200.h | 4 ++--
2 files changed, 20 insertions(+), 17 deletions(-)
--- linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2200.h.old 2006-01-21 01:15:58.000000000 +0100
+++ linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2200.h 2006-01-21 01:16:30.000000000 +0100
@@ -853,7 +853,7 @@
u16 dwell_time[IPW_SCAN_TYPES];
} __attribute__ ((packed));
-extern inline u8 ipw_get_scan_type(struct ipw_scan_request_ext *scan, u8 index)
+static inline u8 ipw_get_scan_type(struct ipw_scan_request_ext *scan, u8 index)
{
if (index % 2)
return scan->scan_type[index / 2] & 0x0F;
@@ -861,7 +861,7 @@
return (scan->scan_type[index / 2] & 0xF0) >> 4;
}
-extern inline void ipw_set_scan_type(struct ipw_scan_request_ext *scan,
+static inline void ipw_set_scan_type(struct ipw_scan_request_ext *scan,
u8 index, u8 scan_type)
{
if (index % 2)
--- linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2200.c.old 2006-01-21 00:54:24.000000000 +0100
+++ linux-2.6.16-rc1-mm2-full/drivers/net/wireless/ipw2200.c 2006-01-21 01:17:04.000000000 +0100
@@ -701,7 +701,7 @@
}
-u32 ipw_register_toggle(u32 reg)
+static u32 ipw_register_toggle(u32 reg)
{
reg &= ~IPW_START_STANDBY;
if (reg & IPW_GATE_ODMA)
@@ -726,7 +726,7 @@
#define LD_TIME_LINK_OFF 2700
#define LD_TIME_ACT_ON 250
-void ipw_led_link_on(struct ipw_priv *priv)
+static void ipw_led_link_on(struct ipw_priv *priv)
{
unsigned long flags;
u32 led;
@@ -769,7 +769,7 @@
mutex_unlock(&priv->mutex);
}
-void ipw_led_link_off(struct ipw_priv *priv)
+static void ipw_led_link_off(struct ipw_priv *priv)
{
unsigned long flags;
u32 led;
@@ -847,6 +847,7 @@
}
}
+#if 0
void ipw_led_activity_on(struct ipw_priv *priv)
{
unsigned long flags;
@@ -854,8 +855,9 @@
__ipw_led_activity_on(priv);
spin_unlock_irqrestore(&priv->lock, flags);
}
+#endif /* 0 */
-void ipw_led_activity_off(struct ipw_priv *priv)
+static void ipw_led_activity_off(struct ipw_priv *priv)
{
unsigned long flags;
u32 led;
@@ -890,7 +892,7 @@
mutex_unlock(&priv->mutex);
}
-void ipw_led_band_on(struct ipw_priv *priv)
+static void ipw_led_band_on(struct ipw_priv *priv)
{
unsigned long flags;
u32 led;
@@ -925,7 +927,7 @@
spin_unlock_irqrestore(&priv->lock, flags);
}
-void ipw_led_band_off(struct ipw_priv *priv)
+static void ipw_led_band_off(struct ipw_priv *priv)
{
unsigned long flags;
u32 led;
@@ -948,24 +950,24 @@
spin_unlock_irqrestore(&priv->lock, flags);
}
-void ipw_led_radio_on(struct ipw_priv *priv)
+static void ipw_led_radio_on(struct ipw_priv *priv)
{
ipw_led_link_on(priv);
}
-void ipw_led_radio_off(struct ipw_priv *priv)
+static void ipw_led_radio_off(struct ipw_priv *priv)
{
ipw_led_activity_off(priv);
ipw_led_link_off(priv);
}
-void ipw_led_link_up(struct ipw_priv *priv)
+static void ipw_led_link_up(struct ipw_priv *priv)
{
/* Set the Link Led on for all nic types */
ipw_led_link_on(priv);
}
-void ipw_led_link_down(struct ipw_priv *priv)
+static void ipw_led_link_down(struct ipw_priv *priv)
{
ipw_led_activity_off(priv);
ipw_led_link_off(priv);
@@ -974,7 +976,7 @@
ipw_led_radio_off(priv);
}
-void ipw_led_init(struct ipw_priv *priv)
+static void ipw_led_init(struct ipw_priv *priv)
{
priv->nic_type = priv->eeprom[EEPROM_NIC_TYPE];
@@ -1025,7 +1027,7 @@
}
}
-void ipw_led_shutdown(struct ipw_priv *priv)
+static void ipw_led_shutdown(struct ipw_priv *priv)
{
ipw_led_activity_off(priv);
ipw_led_link_off(priv);
@@ -6146,7 +6148,8 @@
return ret;
}
-void ipw_wpa_assoc_frame(struct ipw_priv *priv, char *wpa_ie, int wpa_ie_len)
+static void ipw_wpa_assoc_frame(struct ipw_priv *priv, char *wpa_ie,
+ int wpa_ie_len)
{
/* make sure WPA is enabled */
ipw_wpa_enable(priv, 1);
@@ -9977,7 +9980,7 @@
mutex_unlock(&priv->mutex);
}
-void ipw_link_up(struct ipw_priv *priv)
+static void ipw_link_up(struct ipw_priv *priv)
{
priv->last_seq_num = -1;
priv->last_frag_num = -1;
@@ -10012,7 +10015,7 @@
mutex_unlock(&priv->mutex);
}
-void ipw_link_down(struct ipw_priv *priv)
+static void ipw_link_down(struct ipw_priv *priv)
{
ipw_led_link_down(priv);
netif_carrier_off(priv->net_dev);
^ permalink raw reply
* Re: My vote against eepro* removal
From: Lee Revell @ 2006-01-21 0:40 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: kus Kusche Klaus, John Ronciak, Adrian Bunk, linux-kernel,
john.ronciak, ganesh.venkatesan, jesse.brandeburg, netdev,
Steven Rostedt
In-Reply-To: <20060120095548.GA16000@2ka.mipt.ru>
On Fri, 2006-01-20 at 12:55 +0300, Evgeniy Polyakov wrote:
> > Analysis of e100:
> > * If I comment out the whole body of e100_watchdog except for the
> > timer re-registration, the delays are gone (so it is really the
> > body of e100_watchdog). However, this makes eth0 non-functional.
> > * Commenting out parts of it, I found out that most of the time
> > goes into its first half: The code from mii_ethtool_gset to
> > mii_check_link (including) makes the big difference, as far as
> > I can tell especially mii_ethtool_gset.
>
> Each MDIO read can take upto 2 msecs (!) and at least 20 usecs in
> e100,
> and this runs in timer handler.
> Concider attaching (only compile tested) patch which moves e100
> watchdog
> into workqueue.
Seems like the important question is, why does e100 need a watchdog if
eepro100 works fine without one? Isn't the point of a watchdog in this
context to work around other bugs in the driver (or the hardware)?
Lee
^ permalink raw reply
* RE: My vote against eepro* removal
From: Lee Revell @ 2006-01-21 0:45 UTC (permalink / raw)
To: kus Kusche Klaus
Cc: Evgeniy Polyakov, John Ronciak, Adrian Bunk, linux-kernel,
john.ronciak, ganesh.venkatesan, jesse.brandeburg, netdev,
Steven Rostedt
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323325@MAILIT.keba.co.at>
On Fri, 2006-01-20 at 11:19 +0100, kus Kusche Klaus wrote:
> For a non-full preemption kernel, your patch moves the 500 us
> piece of code from kernel to thread context, so it really
> improves things. But is 500 us something to worry about in a
> non-full preemption kernel?
Yes, absolutely. Once exit_mmap (a latency regression which was
introduced in 2.6.14) and rt_run_flush/rt_garbage_collect (which have
always been problematic) are fixed, 500usecs will stick out like a sore
thumb even on a regular PREEMPT kernel.
Also, you should be able to capture this latency in /proc/latency trace
by configuring an -rt kernel with PREEMPT_DESKTOP and hard/softirq
preemption disabled.
Lee
^ permalink raw reply
* Re: [2.6 patch] schedule SHAPER for removal
From: Adrian Bunk @ 2006-01-21 0:48 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Andrew Morton, Alan Cox, jgarzik, netdev, linux-kernel
In-Reply-To: <20060119215722.GO16285@kvack.org>
On Thu, Jan 19, 2006 at 04:57:22PM -0500, Benjamin LaHaise wrote:
> On Thu, Jan 19, 2006 at 03:11:50AM +0100, Adrian Bunk wrote:
> > +What: Traffic Shaper (CONFIG_SHAPER)
> > +When: July 2006
> > +Why: obsoleted by the code in net/sched/
> > +Who: Adrian Bunk <bunk@stusta.de
>
> This length of obsolete cycles is way too short -- it's not even enough
> time for a single release of a distro to ship with the feature marked as
> obsolete.
Do we really have to wait the three years between stable Debian releases
for removing an obsolete driver that has always been marked as
EXPERIMENTAL?
Please be serious.
> -ben
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: My vote against eepro* removal
From: John Ronciak @ 2006-01-21 1:19 UTC (permalink / raw)
To: Lee Revell
Cc: Evgeniy Polyakov, kus Kusche Klaus, Adrian Bunk, linux-kernel,
john.ronciak, ganesh.venkatesan, jesse.brandeburg, netdev,
Steven Rostedt
In-Reply-To: <1137804050.3241.32.camel@mindpipe>
On 1/20/06, Lee Revell <rlrevell@joe-job.com> wrote:
> Seems like the important question is, why does e100 need a watchdog if
> eepro100 works fine without one? Isn't the point of a watchdog in this
> context to work around other bugs in the driver (or the hardware)?
There are a number of things that the watchdog in e100 does. It
checks link (up, down), reads the hardware stats, adjusts the adaptive
IFS and checks to 3 known hang conditions based on certain types of
the hardware. You might be able to get around without doing the
work-arounds (as long as you don't' see hangs happening with the
hardware being used) but the checking of the link and the stats are
probably needed.
--
Cheers,
John
^ permalink raw reply
* Re: My vote against eepro* removal
From: Lee Revell @ 2006-01-21 1:30 UTC (permalink / raw)
To: John Ronciak
Cc: Evgeniy Polyakov, kus Kusche Klaus, Adrian Bunk, linux-kernel,
john.ronciak, ganesh.venkatesan, jesse.brandeburg, netdev,
Steven Rostedt
In-Reply-To: <56a8daef0601201719t448a6177lfebabe3ca38a00c7@mail.gmail.com>
On Fri, 2006-01-20 at 17:19 -0800, John Ronciak wrote:
> On 1/20/06, Lee Revell <rlrevell@joe-job.com> wrote:
> > Seems like the important question is, why does e100 need a watchdog if
> > eepro100 works fine without one? Isn't the point of a watchdog in this
> > context to work around other bugs in the driver (or the hardware)?
> There are a number of things that the watchdog in e100 does. It
> checks link (up, down), reads the hardware stats, adjusts the adaptive
> IFS and checks to 3 known hang conditions based on certain types of
> the hardware. You might be able to get around without doing the
> work-arounds (as long as you don't' see hangs happening with the
> hardware being used) but the checking of the link and the stats are
> probably needed.
Why don't these cause excessive scheduling delays in eepro100 then?
Can't we just copy the eepro100 behavior?
Lee
^ permalink raw reply
* Re: My vote against eepro* removal
From: John Ronciak @ 2006-01-21 2:01 UTC (permalink / raw)
To: Lee Revell
Cc: Evgeniy Polyakov, kus Kusche Klaus, Adrian Bunk, linux-kernel,
john.ronciak, ganesh.venkatesan, jesse.brandeburg, netdev,
Steven Rostedt
In-Reply-To: <1137807048.3241.58.camel@mindpipe>
On 1/20/06, Lee Revell <rlrevell@joe-job.com> wrote:
>
> Why don't these cause excessive scheduling delays in eepro100 then?
> Can't we just copy the eepro100 behavior?
Reports still float around from time to time about hangs with the
eepro100 which go away when the e100 driver is used. We don't
maintain the eepro100 driver so I can't tell you much about it other
than the reports we get sometimes.
There is a timer routine in the eepro100 driver which does the check
for link as well as a check for on of the hang conditions (with
work-around). It does the check for link in a different way than
e100. e100 uses mii call where eepro100 does it manually. Another
difference is that eepro100 doesn't get stats unless called by the
system. It's not in the timer routine at all.
Can we try a couple of things? 1) just comment out all the check for
link code in the e100 driver and give that a try and 2) just comment
out the update stats call and see if that works. These seem to be the
differences and we need to know which one is causing the problem.
--
Cheers,
John
^ permalink raw reply
* Re: My vote against eepro* removal
From: Lee Revell @ 2006-01-21 3:56 UTC (permalink / raw)
To: John Ronciak
Cc: Evgeniy Polyakov, kus Kusche Klaus, Adrian Bunk, linux-kernel,
john.ronciak, ganesh.venkatesan, jesse.brandeburg, netdev,
Steven Rostedt
In-Reply-To: <56a8daef0601201801s6f8c3b79xcc06aaacc430309d@mail.gmail.com>
On Fri, 2006-01-20 at 18:01 -0800, John Ronciak wrote:
> There is a timer routine in the eepro100 driver which does the check
> for link as well as a check for on of the hang conditions (with
> work-around). It does the check for link in a different way than
> e100. e100 uses mii call where eepro100 does it manually. Another
> difference is that eepro100 doesn't get stats unless called by the
> system. It's not in the timer routine at all.
>
> Can we try a couple of things? 1) just comment out all the check for
> link code in the e100 driver and give that a try and 2) just comment
> out the update stats call and see if that works. These seem to be the
> differences and we need to know which one is causing the problem.
Heh, FWIW, Microsoft found this exact same bug with 2 different chipsets
in their latency testing (see section 4.4):
http://research.microsoft.com/~mbj/papers/tr-98-29.html
Lee
^ permalink raw reply
* Re: [PATCH 3/5] [RFC] Infiniband: connection abstraction
From: Roland Dreier @ 2006-01-21 23:37 UTC (permalink / raw)
To: Sean Hefty; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <ORSMSX4011XvpFVjCRG00000041@orsmsx401.amr.corp.intel.com>
BTW, it's probably worth highlighting these parts of this patch:
First off, ip_dev_find() is exported again:
> --- linux-2.6.git/net/ipv4/fib_frontend.c 2006-01-16 10:28:29.000000000 -0800
> +++ linux-2.6.ib/net/ipv4/fib_frontend.c 2006-01-16 16:14:24.000000000 -0800
> @@ -666,4 +666,5 @@ void __init ip_fib_init(void)
> }
>
> EXPORT_SYMBOL(inet_addr_type);
> +EXPORT_SYMBOL(ip_dev_find);
> EXPORT_SYMBOL(ip_rt_ioctl);
And then it's used here:
> +int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr)
> +{
> + struct net_device *dev;
> + u32 ip = ((struct sockaddr_in *) addr)->sin_addr.s_addr;
> + int ret;
> +
> + dev = ip_dev_find(ip);
> + if (!dev)
> + return -EADDRNOTAVAIL;
> +
> + ret = copy_addr(dev_addr, dev, NULL);
> + dev_put(dev);
> + return ret;
> +}
And also here to find the local device to use when connecting to a
loopback address:
> +static int addr_resolve_local(struct sockaddr_in *src_in,
> + struct sockaddr_in *dst_in,
> + struct rdma_dev_addr *addr)
> +{
> + struct net_device *dev;
> + u32 src_ip = src_in->sin_addr.s_addr;
> + u32 dst_ip = dst_in->sin_addr.s_addr;
> + int ret;
> +
> + dev = ip_dev_find(dst_ip);
> + if (!dev)
> + return -EADDRNOTAVAIL;
> +
> + if (!src_ip) {
> + src_in->sin_family = dst_in->sin_family;
> + src_in->sin_addr.s_addr = dst_ip;
> + ret = copy_addr(addr, dev, dev->dev_addr);
> + } else {
> + ret = rdma_translate_ip((struct sockaddr *)src_in, addr);
> + if (!ret)
> + memcpy(addr->dst_dev_addr, dev->dev_addr, MAX_ADDR_LEN);
> + }
> +
> + dev_put(dev);
> + return ret;
> +}
I don't really have an opinion one way or another about this usage,
but I think it's a good idea to make sure that this stuff doesn't get
lost in all the other code, since it is (re)exporting a function that
is currently private to networking.
- R.
^ permalink raw reply
* [PATCH] trivial fix
From: Denis Vlasenko @ 2006-01-22 11:57 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev
In-Reply-To: <20060118200616.GC6583@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 116 bytes --]
Patch fixes misplaced (). Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
--
vda
[-- Attachment #2: trivial.patch --]
[-- Type: text/x-diff, Size: 761 bytes --]
diff -urpN softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c Sun Jan 22 13:12:30 2006
@@ -562,7 +562,7 @@ int ieee80211_rx(struct ieee80211_device
/* skb: hdr + (possibly fragmented) plaintext payload */
// PR: FIXME: hostap has additional conditions in the "if" below:
// ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTED) &&
- if ((frag != 0 || (fc & IEEE80211_FCTL_MOREFRAGS))) {
+ if ((frag != 0) || (fc & IEEE80211_FCTL_MOREFRAGS)) {
int flen;
struct sk_buff *frag_skb = ieee80211_frag_cache_get(ieee, hdr);
IEEE80211_DEBUG_FRAG("Rx Fragment received (%u)\n", frag);
^ permalink raw reply
* [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
From: Denis Vlasenko @ 2006-01-22 11:59 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <20060118200616.GC6583@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to softmac
as ieee80211_rx_any() function.
Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
--
vda
[-- Attachment #2: rx.patch --]
[-- Type: text/x-diff, Size: 2655 bytes --]
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to softmac.
diff -urpN softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c Sun Jan 22 13:12:30 2006
@@ -758,6 +758,79 @@ int ieee80211_rx(struct ieee80211_device
/* Returning 0 indicates to caller that we have not handled the SKB--
* so it is still allocated and can be used again by underlying
* hardware as a DMA target */
+ return 0;
+}
+
+/* Kernel doesn't have it, why? */
+static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
+{
+ return (0x01 & addr[0]);
+}
+
+/* Filter out unrelated packets, call ieee80211_rx[_mgt] */
+int ieee80211_rx_any(struct ieee80211_device *ieee,
+ struct sk_buff *skb, struct ieee80211_rx_stats *stats)
+{
+ struct ieee80211_hdr_4addr *hdr;
+ int is_packet_for_us;
+ u16 fc;
+
+ if (ieee->iw_mode == IW_MODE_MONITOR)
+ return ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL;
+
+ hdr = (struct ieee80211_hdr_4addr *)skb->data;
+ fc = le16_to_cpu(hdr->frame_ctl);
+
+ switch (fc & IEEE80211_FCTL_FTYPE) {
+ case IEEE80211_FTYPE_MGMT:
+ return ieee80211_rx_mgt(ieee, hdr, stats);
+ case IEEE80211_FTYPE_DATA:
+ break;
+ case IEEE80211_FTYPE_CTL:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+
+ is_packet_for_us = 0;
+ switch (ieee->iw_mode) {
+ case IW_MODE_ADHOC:
+ /* promisc: get all */
+ if (ieee->dev->flags & IFF_PROMISC)
+ is_packet_for_us = 1;
+ /* our BSS */
+ else if (memcmp(hdr->addr3, ieee->bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+ is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+ is_packet_for_us = 1;
+ }
+ break;
+ case IW_MODE_INFRA:
+ /* promisc: get all */
+ if (ieee->dev->flags & IFF_PROMISC)
+ is_packet_for_us = 1;
+ /* our BSS (== from our AP) */
+ else if (memcmp(hdr->addr2, ieee->bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+ is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+ /* not our own packet bcasted from AP */
+ if (memcmp(hdr->addr3, ieee->dev->dev_addr, ETH_ALEN))
+ is_packet_for_us = 1;
+ }
+ break;
+ default:
+ /* ? */
+ break;
+ }
+
+ if (is_packet_for_us)
+ return (ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL);
return 0;
}
^ permalink raw reply
* [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
From: Denis Vlasenko @ 2006-01-22 12:04 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <20060118200616.GC6583@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to 80211
as ieee80211_rx_any() function.
Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
--
vda
[-- Attachment #2: rx.patch --]
[-- Type: text/x-diff, Size: 2456 bytes --]
diff -urp softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c Sun Jan 22 14:01:43 2006
@@ -758,6 +758,80 @@ int ieee80211_rx(struct ieee80211_device
/* Returning 0 indicates to caller that we have not handled the SKB--
* so it is still allocated and can be used again by underlying
* hardware as a DMA target */
+ return 0;
+}
+
+/* Kernel doesn't have it, why? */
+static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
+{
+ return (0x01 & addr[0]);
+}
+
+/* Filter out unrelated packets, call ieee80211_rx[_mgt] */
+int ieee80211_rx_any(struct ieee80211_device *ieee,
+ struct sk_buff *skb, struct ieee80211_rx_stats *stats)
+{
+ struct ieee80211_hdr_4addr *hdr;
+ int is_packet_for_us;
+ u16 fc;
+
+ if (ieee->iw_mode == IW_MODE_MONITOR)
+ return ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL;
+
+ hdr = (struct ieee80211_hdr_4addr *)skb->data;
+ fc = le16_to_cpu(hdr->frame_ctl);
+
+ switch (fc & IEEE80211_FCTL_FTYPE) {
+ case IEEE80211_FTYPE_MGMT:
+ ieee80211_rx_mgt(ieee, hdr, stats);
+ return 0;
+ case IEEE80211_FTYPE_DATA:
+ break;
+ case IEEE80211_FTYPE_CTL:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+
+ is_packet_for_us = 0;
+ switch (ieee->iw_mode) {
+ case IW_MODE_ADHOC:
+ /* promisc: get all */
+ if (ieee->dev->flags & IFF_PROMISC)
+ is_packet_for_us = 1;
+ /* our BSS */
+ else if (memcmp(hdr->addr3, ieee->bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+ is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+ is_packet_for_us = 1;
+ }
+ break;
+ case IW_MODE_INFRA:
+ /* promisc: get all */
+ if (ieee->dev->flags & IFF_PROMISC)
+ is_packet_for_us = 1;
+ /* our BSS (== from our AP) */
+ else if (memcmp(hdr->addr2, ieee->bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+ is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+ /* not our own packet bcasted from AP */
+ if (memcmp(hdr->addr3, ieee->dev->dev_addr, ETH_ALEN))
+ is_packet_for_us = 1;
+ }
+ break;
+ default:
+ /* ? */
+ break;
+ }
+
+ if (is_packet_for_us)
+ return (ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL);
return 0;
}
^ permalink raw reply
* Re: [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
From: Denis Vlasenko @ 2006-01-22 12:08 UTC (permalink / raw)
To: John W. Linville
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jbenc-AlSwsSmVLrQ,
softmac-dev-cdvu00un1VgdHxzADdlk8Q,
bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <200601221359.31482.vda-BN/BzeNzsW2SlH3FCl+8hg@public.gmane.org>
On Sunday 22 January 2006 13:59, Denis Vlasenko wrote:
> bcm43xx_rx() contains code to filter out packets from
> foreign BSSes and decide whether to call ieee80211_rx
> or ieee80211_rx_mgt. This is not bcm specific.
>
> Patch adapts that code and adds it to softmac
> as ieee80211_rx_any() function.
>
> Diffed against wireless-2.6.git
>
> Signed-off-by: Denis Vlasenko <vda-BN/BzeNzsW2SlH3FCl+8hg@public.gmane.org>
> --
> vda
Please ignore this one. This is not good:
+ return ieee80211_rx_mgt(ieee, hdr, stats);
Use corrected patch in my another email with
"Date: Sun, 22 Jan 2006 14:04:52 +0200"
--
vda
^ 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