* Re: [PATCH] kill massive wireless-related log spam
From: J.A. Magallon @ 2005-10-26 21:23 UTC (permalink / raw)
To: Linux-Kernel; +Cc: netdev
In-Reply-To: <9a8748490510260823s681a4d82k5efa5734486eda85@mail.gmail.com>
On 2005.10.26, at 17:23, Jesper Juhl wrote:
> On 10/26/05, Andi Kleen <ak@suse.de> wrote:
>
>> On Wednesday 26 October 2005 06:28, Jeff Garzik wrote:
>>
>>
>>> Change this to printing out the message once, per kernel boot.
>>>
>>
>> It doesn't do that. It prints it once every 2^32 calls. Also
>>
>
> I noted that as well. How about just using something along the
> lines of
>
> static unsigned char printed_message = 0;
> if (!printed_message) {
> printk(...);
> printed_message++;
> }
Sorry, but why not the old good
printed_message = 1
??
What kind of microoptimization is that ?
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
wolverine \ It's better when it's free
MacOS X 10.4.2, Darwin Kernel Version 8.2.0
^ permalink raw reply
* Re: [PATCH] kill massive wireless-related log spam
From: Jesper Juhl @ 2005-10-26 21:43 UTC (permalink / raw)
To: J.A. Magallon; +Cc: Linux-Kernel, netdev
In-Reply-To: <AB480DAC-57B0-4125-8BA5-D6C715B693B6@able.es>
On 10/26/05, J.A. Magallon <jamagallon@able.es> wrote:
>
> On 2005.10.26, at 17:23, Jesper Juhl wrote:
>
> > On 10/26/05, Andi Kleen <ak@suse.de> wrote:
> >
> >> On Wednesday 26 October 2005 06:28, Jeff Garzik wrote:
> >>
> >>
> >>> Change this to printing out the message once, per kernel boot.
> >>>
> >>
> >> It doesn't do that. It prints it once every 2^32 calls. Also
> >>
> >
> > I noted that as well. How about just using something along the
> > lines of
> >
> > static unsigned char printed_message = 0;
> > if (!printed_message) {
> > printk(...);
> > printed_message++;
> > }
>
> Sorry, but why not the old good
>
> printed_message = 1
>
> ??
> What kind of microoptimization is that ?
>
Does it really matter? I needed to pick one of
printed_message=1; or printed_message++;
the end result is the same, so I just picked one at random.
But now that you mention it, I guess ++ would turn into "inc" which
should be faster than an assignment... but it *doesn't matter*... I
was not trying to optimize anything, just make the code work properly
- as in, only ever print the message once...
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Herbert Xu @ 2005-10-27 12:15 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <20051017.094919.56989341.yoshfuji@linux-ipv6.org>
On Mon, Oct 17, 2005 at 09:49:19AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> Stack should process the packet just once if it is of transport mode.
> (It is okay to process one twice if it is of tunnel mode.)
Thinking about this again, I'm not sure that I agree.
OK, I don't actually care whether we process it once or twice for
pure transport mode, but I think that it is absolutely essential
that LOCAL_IN/LOCAL_OUT see the decapsulated packet instead of
the encrypted version.
Whether it's IPv4 or IPv6, transport mode shouldn't make you lose the
ability to use netfilter to filter out packets.
Now if we can achieve this by sending the packet through netfilter
only once then I'm all for it.
But if for whatever reason we can't do that, then I'd rather have it
go through twice than not see the decapsulated packet at all which is
the case at the moment.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Patrick McHardy @ 2005-10-27 14:42 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel
In-Reply-To: <20051026003954.GA14068@gondor.apana.org.au>
Herbert Xu wrote:
> On Wed, Oct 26, 2005 at 01:14:31AM +0200, Patrick McHardy wrote:
>
>>No. I thought of this as a special case of inner transport mode SAs
>>(without any further SAs) which would be unhandled. I've never used
>>pure transport mode SAs except for testing, and I've never seen any
>>other users of this. Do you think it is important to handle?
>
>
> Well the scenario is IPv4 transport mode ESP applied outside normal
> IPIP tunnel devices.
>
> Actually, this could work if we make sure that the user-space KMs
> set the SA selectors properly in this case.
>
> I presume that you will be changing the output path so that LOCAL_OUT
> does not see the plain-text packet. Otherwise it'll be asymmetric with
> repsect to the inbound side which does not see plain-text packets for
> transport mode SAs.
Yes, that was the idea. But since people seem to consider this an
important case to handle I'm going to try the per-SA flag you
proposed. I'll send new patches in the next days.
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-10-27 14:57 UTC (permalink / raw)
To: herbert; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <20051027121545.GA5530@gondor.apana.org.au>
In article <20051027121545.GA5530@gondor.apana.org.au> (at Thu, 27 Oct 2005 22:15:45 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:
> On Mon, Oct 17, 2005 at 09:49:19AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> >
> > Stack should process the packet just once if it is of transport mode.
> > (It is okay to process one twice if it is of tunnel mode.)
>
> Thinking about this again, I'm not sure that I agree.
>
> OK, I don't actually care whether we process it once or twice for
> pure transport mode, but I think that it is absolutely essential
> that LOCAL_IN/LOCAL_OUT see the decapsulated packet instead of
> the encrypted version.
Well, I really care.
I strongly believe that we SHOULD NOT mix encrypted
packets and plain text packets at the same hook.
e.g. LOCAL_IN is NOT for decrypted plain text packets,
but for the original encrypted ones.
I believe that we should have another set of hooks
after decryption (other than LOCAL_IN) if we want to
look inside the encrypted packets.
--yoshfuji
^ permalink raw reply
* iBurst (TM) compatible driver
From: Nicholas Jefferson @ 2005-10-27 15:47 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
The latest release of the iBurst (TM) compatible driver [1] for the
2.6 kernel is now available. Thanks to ArrayComm (R) for the original
code under the GPL, and Personal Broadband Australia (PBA) and
Independent Service Providers Australia (ISP) for support. Special
thanks to developers David Barr and Nik Trevallyn-Jones.
[1] http://sourceforge.net/projects/ibdriver
Disclaimer: This driver was not written by ArrayComm (R) and it is not
supported by them. This driver is distributed in the hope that it will
be useful, but without any warranty; without even the implied warranty
of merchantability or fitness for a particular purpose.
Signed-off-by: Nicholas Jefferson <xanthophile@gmail.com>
Kind regards,
Nicholas
^ permalink raw reply
* <REAL> iBurst (TM) compatible driver
From: Nicholas Jefferson @ 2005-10-27 16:24 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
The latest release of the iBurst (TM) compatible driver [1] for the
2.6 kernel is now available. Thanks to ArrayComm (R) for the original
code under the GPL, and Personal Broadband Australia (PBA) and
Independent Service Providers Australia (ISP) for support. Special
thanks to developers David Barr and Nik Trevallyn-Jones.
[1] http://sourceforge.net/projects/ibdriver
Disclaimer: This driver was not written by ArrayComm (R) and it is not
supported by them. This driver is distributed in the hope that it will
be useful, but without any warranty; without even the implied warranty
of merchantability or fitness for a particular purpose.
Signed-off-by: Nicholas Jefferson <xanthophile@gmail.com>
Kind regards,
Nicholas
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Patrick McHardy @ 2005-10-27 16:58 UTC (permalink / raw)
To: yoshifuji; +Cc: netdev, netfilter-devel, herbert
In-Reply-To: <20051027.235732.01166239.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[ wrote:
> In article <20051027121545.GA5530@gondor.apana.org.au> (at Thu, 27 Oct 2005 22:15:45 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:
>
>
>>On Mon, Oct 17, 2005 at 09:49:19AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>>
>>>Stack should process the packet just once if it is of transport mode.
>>>(It is okay to process one twice if it is of tunnel mode.)
>>
>>Thinking about this again, I'm not sure that I agree.
>>
>>OK, I don't actually care whether we process it once or twice for
>>pure transport mode, but I think that it is absolutely essential
>>that LOCAL_IN/LOCAL_OUT see the decapsulated packet instead of
>>the encrypted version.
>
>
> Well, I really care.
> I strongly believe that we SHOULD NOT mix encrypted
> packets and plain text packets at the same hook.
> e.g. LOCAL_IN is NOT for decrypted plain text packets,
> but for the original encrypted ones.
It is in tunnel mode. LOCAL_IN is for all packets that are
locally delivered, independant of encryption. Using new
hooks for decrypted transport mode packets is inconsistent
IMO.
> I believe that we should have another set of hooks
> after decryption (other than LOCAL_IN) if we want to
> look inside the encrypted packets.
This isn't possible without adding completely new tables since
we can't add new chains to existing tables without breaking
userspace compatiblity. If we want existing functionality to
continue working we would need an "xfrm" version of the raw,
mangle, nat and filter table and need to change conntrack (and
possibly NAT) to use the new hooks. Rerouting after NAT (with IPv4)
won't work if we don't pass the packet through the stack again.
I think adding new hooks has too many drawbacks compared to simply
sending the decrypted packet through the stack again.
^ permalink raw reply
* Re: <REAL> iBurst (TM) compatible driver
From: John W. Linville @ 2005-10-27 17:07 UTC (permalink / raw)
To: Nicholas Jefferson; +Cc: netdev, linux-kernel
In-Reply-To: <4cd031a50510270924r38ad4d5oa88ae92a514df3cf@mail.gmail.com>
On Fri, Oct 28, 2005 at 02:24:20AM +1000, Nicholas Jefferson wrote:
> The latest release of the iBurst (TM) compatible driver [1] for the
> 2.6 kernel is now available. Thanks to ArrayComm (R) for the original
<snip>
> Signed-off-by: Nicholas Jefferson <xanthophile@gmail.com>
-ENOPATCH?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH] kill massive wireless-related log spam
From: Horst von Brand @ 2005-10-27 17:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andi Kleen, Linus Torvalds, netdev, linux-kernel, jketreno,
Andrew Morton
In-Reply-To: <435FA3FB.9030107@pobox.com>
Jeff Garzik <jgarzik@pobox.com> wrote:
> Andi Kleen wrote:
> > On Wednesday 26 October 2005 06:28, Jeff Garzik wrote:
> >
> >>Change this to printing out the message once, per kernel boot.
> > It doesn't do that. It prints it once every 2^32 calls. Also
>
> ...which is effectively one per kernel boot
>
>
> > the ++ causes unnecessary dirty cache lines in normal operation.
> Not a hot path operation by any stretch of the imagination, so that's
fine.
Right. As the "++" is inside "if(!printed) { ... }" it clearly isn't ;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: <REAL> iBurst (TM) compatible driver
From: Andi Kleen @ 2005-10-27 17:44 UTC (permalink / raw)
To: John W. Linville; +Cc: Nicholas Jefferson, netdev, linux-kernel
In-Reply-To: <20051027170727.GA26569@tuxdriver.com>
On Thursday 27 October 2005 19:07, John W. Linville wrote:
> On Fri, Oct 28, 2005 at 02:24:20AM +1000, Nicholas Jefferson wrote:
> > The latest release of the iBurst (TM) compatible driver [1] for the
> > 2.6 kernel is now available. Thanks to ArrayComm (R) for the original
>
> <snip>
>
> > Signed-off-by: Nicholas Jefferson <xanthophile@gmail.com>
>
> -ENOPATCH?
And no description what an "iBurst (tm)" actually is. It sounds like
something to clear blocked drains with.
-Andi
^ permalink raw reply
* Re: <REAL> iBurst (TM) compatible driver
From: Lennert Buytenhek @ 2005-10-27 17:45 UTC (permalink / raw)
To: Andi Kleen; +Cc: John W. Linville, Nicholas Jefferson, netdev, linux-kernel
In-Reply-To: <200510271944.12452.ak@suse.de>
On Thu, Oct 27, 2005 at 07:44:12PM +0200, Andi Kleen wrote:
> And no description what an "iBurst (tm)" actually is. It sounds like
> something to clear blocked drains with.
>From reading http://sourceforge.net/projects/ibdriver, it appears
to be some kind of wireless adapter:
Linux driver for the ArrayComm* "iBurst*" wireless broadband devices.
--L
^ permalink raw reply
* Re: <REAL> iBurst (TM) compatible driver
From: Bongani Hlope @ 2005-10-27 21:25 UTC (permalink / raw)
To: Andi Kleen; +Cc: John W. Linville, Nicholas Jefferson, netdev, linux-kernel
In-Reply-To: <200510271944.12452.ak@suse.de>
On Thursday 27 October 2005 19:44, Andi Kleen wrote:
> On Thursday 27 October 2005 19:07, John W. Linville wrote:
> > On Fri, Oct 28, 2005 at 02:24:20AM +1000, Nicholas Jefferson wrote:
> > > The latest release of the iBurst (TM) compatible driver [1] for the
> > > 2.6 kernel is now available. Thanks to ArrayComm (R) for the original
> >
> > <snip>
> >
> > > Signed-off-by: Nicholas Jefferson <xanthophile@gmail.com>
> >
> > -ENOPATCH?
>
> And no description what an "iBurst (tm)" actually is. It sounds like
> something to clear blocked drains with.
>
> -Andi
iBurst is a wireless broadband internet service, so far I only know that it is
available in Austrailer and South Africa. Here in South Africa, there are two
devices you can use for connectivity an internal and external "modem". With
the external modem, you can use either USB or ethernet to connect (pppoe).
The PCMCIA currently is not documented and there is no driver for Linux.
I ordered the external modem (still waiting for it), I'll try to get some guys
from our LUG to test it (only the PCMCIA version is causing pain), hopefuly
someone is stuck with that version ;)
^ permalink raw reply
* Re: <REAL> iBurst (TM) compatible driver
From: Stephen Hemminger @ 2005-10-27 22:31 UTC (permalink / raw)
To: Nicholas Jefferson; +Cc: netdev, linux-kernel
In-Reply-To: <4cd031a50510270924r38ad4d5oa88ae92a514df3cf@mail.gmail.com>
It is good to see more hardware supported, but like many drivers
you are adding a lot of racy ugliness just for debug crap.
Did you actually read any of the other network device drivers first
or try to write code from scratch off some book?
In order of severity.
1. Your network device registration code is wrong.
Read Documentation/netdevices.txt
You need to use alloc_netdev() and make the device specific data
be allocated there, not bury netdevice in a kmalloc'd structure.
2. Transmit routine is wrong. Drop packets if out of memory.
You can only return NETDEV_TX_OKAY or NETDEV_TX_BUSY
You probably don't need to allocate memory anyway if you use
hard header space properly.
3. You need to flow control the transmit queue. When it gets full
use netdev_stop_queue() and call netdev_wake_queue when you
have more space.
4. WTF is the whole ib_net_tap file stuff, and why do you need it?
You can eliminate a lot of module races etc, by just pulling it.
5. Why bother with a /proc interface?
6. If you must then use seq_file.
7. If you must then do one device per file.
8. Then you can get rid of having a global array of device structures
which is hard to maintain properly.
9. If you don't support ioctl's just leave dev->ioctl as NULL
10. Error code's from call's like register_netdev() should propogate back
out.
11. ib_net_open, ib_net_close only called from user context don't need irqsave
use spin_lock_irq()
12. Coding style: don't use u_long it's a BSDism
13. Please have source code laid out as patch to kernel, not out of tree driver
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
^ permalink raw reply
* [git patches] 2.6.x net driver updates
From: Jeff Garzik @ 2005-10-28 0:42 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, linux-kernel
Please pull from 'upstream' branch of
master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following misc. updates, many of them minor fixes, and a
ton of accumulated wireless updates.
drivers/net/gianfar_phy.c | 661 ------------
drivers/net/gianfar_phy.h | 213 ----
drivers/net/hamradio/mkiss.h | 62 -
Documentation/networking/bonding.txt | 5
drivers/net/8139cp.c | 5
drivers/net/8139too.c | 5
drivers/net/Kconfig | 23
drivers/net/Makefile | 4
drivers/net/au1000_eth.c | 13
drivers/net/b44.c | 136 ++
drivers/net/b44.h | 2
drivers/net/bonding/bond_main.c | 57 +
drivers/net/declance.c | 37
drivers/net/e100.c | 4
drivers/net/e1000/e1000.h | 74 +
drivers/net/e1000/e1000_ethtool.c | 95 +
drivers/net/e1000/e1000_hw.c | 220 +++-
drivers/net/e1000/e1000_hw.h | 96 +
drivers/net/e1000/e1000_main.c | 1082 +++++++++++++++-----
drivers/net/e1000/e1000_param.c | 10
drivers/net/epic100.c | 4
drivers/net/forcedeth.c | 310 +++--
drivers/net/gianfar.c | 412 +------
drivers/net/gianfar.h | 30
drivers/net/gianfar_ethtool.c | 100 +
drivers/net/gianfar_mii.c | 219 ++++
drivers/net/gianfar_mii.h | 45
drivers/net/hamradio/Kconfig | 1
drivers/net/hamradio/bpqether.c | 9
drivers/net/hamradio/mkiss.c | 182 ++-
drivers/net/hp100.c | 48
drivers/net/irda/stir4200.c | 7
drivers/net/ixgb/ixgb_ethtool.c | 8
drivers/net/ixgb/ixgb_main.c | 3
drivers/net/lne390.c | 2
drivers/net/mii.c | 15
drivers/net/mipsnet.c | 371 ++++++
drivers/net/mipsnet.h | 127 ++
drivers/net/ne.c | 15
drivers/net/ne2k-pci.c | 2
drivers/net/ns83820.c | 3
drivers/net/pcnet32.c | 278 ++++-
drivers/net/phy/Kconfig | 8
drivers/net/phy/phy.c | 8
drivers/net/phy/phy_device.c | 3
drivers/net/r8169.c | 2
drivers/net/rionet.c | 574 ++++++++++
drivers/net/s2io-regs.h | 11
drivers/net/s2io.c | 801 ++++++++++++---
drivers/net/s2io.h | 50
drivers/net/sb1250-mac.c | 1380 +++++++++++++-------------
drivers/net/sgiseeq.c | 37
drivers/net/skge.c | 2
drivers/net/sundance.c | 53
drivers/net/tokenring/ibmtr.c | 9
drivers/net/tokenring/olympic.c | 2
drivers/net/tokenring/tms380tr.c | 3
drivers/net/tulip/de2104x.c | 5
drivers/net/typhoon.c | 7
drivers/net/via-rhine.c | 38
drivers/net/wan/cosa.c | 6
drivers/net/wan/cycx_drv.c | 7
drivers/net/wan/cycx_main.c | 2
drivers/net/wan/cycx_x25.c | 5
drivers/net/wan/dscc4.c | 23
drivers/net/wan/farsync.c | 27
drivers/net/wan/hdlc_fr.c | 2
drivers/net/wan/lmc/lmc_debug.c | 10
drivers/net/wan/lmc/lmc_media.c | 8
drivers/net/wan/pc300.h | 16
drivers/net/wan/pc300_drv.c | 87 -
drivers/net/wan/pc300_tty.c | 18
drivers/net/wan/sdla.c | 20
drivers/net/wan/sdla_fr.c | 4
drivers/net/wan/sdla_x25.c | 8
drivers/net/wan/sdladrv.c | 16
drivers/net/wan/syncppp.c | 10
drivers/net/wireless/airo.c | 37
drivers/net/wireless/airport.c | 19
drivers/net/wireless/atmel.c | 24
drivers/net/wireless/hermes.c | 11
drivers/net/wireless/hermes.h | 111 +-
drivers/net/wireless/hostap/hostap.c | 6
drivers/net/wireless/hostap/hostap_80211_rx.c | 43
drivers/net/wireless/hostap/hostap_80211_tx.c | 28
drivers/net/wireless/hostap/hostap_ap.c | 80 -
drivers/net/wireless/hostap/hostap_ap.h | 6
drivers/net/wireless/hostap/hostap_cs.c | 50
drivers/net/wireless/hostap/hostap_hw.c | 22
drivers/net/wireless/hostap/hostap_ioctl.c | 23
drivers/net/wireless/hostap/hostap_pci.c | 21
drivers/net/wireless/hostap/hostap_plx.c | 11
drivers/net/wireless/hostap/hostap_wlan.h | 2
drivers/net/wireless/ipw2100.c | 24
drivers/net/wireless/ipw2100.h | 2
drivers/net/wireless/ipw2200.c | 27
drivers/net/wireless/ipw2200.h | 4
drivers/net/wireless/netwave_cs.c | 185 ---
drivers/net/wireless/orinoco.c | 235 +---
drivers/net/wireless/orinoco.h | 16
drivers/net/wireless/orinoco_cs.c | 110 +-
drivers/net/wireless/orinoco_nortel.c | 20
drivers/net/wireless/orinoco_pci.c | 18
drivers/net/wireless/orinoco_plx.c | 18
drivers/net/wireless/orinoco_tmd.c | 18
drivers/net/wireless/prism54/isl_ioctl.c | 10
drivers/net/wireless/prism54/islpci_dev.c | 10
drivers/net/wireless/prism54/islpci_dev.h | 2
drivers/net/wireless/prism54/islpci_mgt.c | 5
drivers/net/wireless/ray_cs.c | 46
drivers/net/wireless/spectrum_cs.c | 79 -
drivers/net/wireless/wavelan.c | 8
drivers/net/wireless/wavelan.p.h | 4
drivers/net/wireless/wavelan_cs.c | 8
drivers/net/wireless/wavelan_cs.p.h | 4
drivers/net/wireless/wl3501.h | 2
drivers/s390/net/qeth.h | 45
drivers/s390/net/qeth_fs.h | 12
drivers/s390/net/qeth_main.c | 419 +++++--
drivers/s390/net/qeth_mpc.c | 6
drivers/s390/net/qeth_mpc.h | 15
drivers/s390/net/qeth_sys.c | 28
include/asm-mips/sgi/hpc3.h | 40
include/linux/cyclomx.h | 2
include/linux/cycx_drv.h | 1
include/linux/ibmtr.h | 4
include/linux/if_arp.h | 1
include/linux/mii.h | 1
include/linux/netdevice.h | 6
include/linux/sdladrv.h | 4
include/linux/wanpipe.h | 9
include/net/ieee80211.h | 523 +++++++--
include/net/ieee80211_crypt.h | 38
include/net/ieee80211_radiotap.h | 231 ++++
include/net/syncppp.h | 1
net/ieee80211/Makefile | 3
net/ieee80211/ieee80211_crypt.c | 59 -
net/ieee80211/ieee80211_crypt_ccmp.c | 75 -
net/ieee80211/ieee80211_crypt_tkip.c | 150 +-
net/ieee80211/ieee80211_crypt_wep.c | 26
net/ieee80211/ieee80211_geo.c | 141 ++
net/ieee80211/ieee80211_module.c | 65 -
net/ieee80211/ieee80211_rx.c | 610 ++++++++---
net/ieee80211/ieee80211_tx.c | 321 ++++--
net/ieee80211/ieee80211_wx.c | 372 +++++--
145 files changed, 8163 insertions(+), 4651 deletions(-)
Adrian Bunk:
drivers/net/wan/: possible cleanups
Andrew Morton:
e1000_intr build fix
s2io build fix
e1000 build fix
Andy Fleming:
[netdrvr gianfar] use new phy layer
Ayaz Abdulla:
[netdrvr forcedeth] scatter gather and segmentation offload support
Dale Farnsworth:
mii: Add test for GigE support
Hong Liu:
Fixed problem with not being able to decrypt/encrypt broadcast packets.
Fixed oops if an uninitialized key is used for encryption.
Hubert WS Lin:
pcnet32: set_ringparam implementation
pcnet32: set min ring size to 4
Ivo van Doorn:
This will move the ieee80211_is_ofdm_rate function to the ieee80211.h
Currently the info_element is parsed by 2 seperate functions, this
When an assoc_resp is received the network structure is not completely
James Ketrenos:
Fixed some endian issues with 802.11 header usage in ieee80211_rx.c
ieee80211 quality scaling algorithm extension handler
ieee80211 Added wireless spy support
Changed 802.11 headers to use ieee80211_info_element[0]
ieee80211 Removed ieee80211_info_element_hdr
ieee80211 Cleanup memcpy parameters.
ieee80211 Switched to sscanf in store_debug_level
ieee80211 Fixed type-o of abg_ture -> abg_true
Updated ipw2200 to compile with ieee80211 abg_ture to abg_true change
ieee80211: Updated ipw2100 to be compatible with ieee80211_hdr changes
ieee80211: Updated ipw2100 to be compatible with ieee80211's hard_start_xmit change
ieee80211: Updated ipw2200 to be compatible with ieee80211_hdr changes
ieee80211: Updated ipw2200 to be compatible with ieee80211's hard_start_xmit change.
ieee80211: Updated atmel to be compatible with ieee80211_hdr changes
ieee80211: Fixed a kernel oops on module unload
ieee80211: Hardware crypto and fragmentation offload support
ieee80211: Fix time calculation, switching to use jiffies_to_msecs
ieee80211: Fix kernel Oops when module unload
ieee80211: Allow drivers to fix an issue when using wpa_supplicant with WEP
ieee82011: Added WE-18 support to default wireless extension handler
ieee80211: Renamed ieee80211_hdr to ieee80211_hdr_3addr
ieee80211: adds support for the creation of RTS packets
ieee82011: Added ieee80211_tx_frame to convert generic 802.11 data frames, and callbacks
ieee80211: Fix TKIP, repeated fragmentation problem, and payload_size reporting
ieee80211: Return NETDEV_TX_BUSY when QoS buffer full
ieee80211: Add QoS (WME) support to the ieee80211 subsystem
ieee80211: Added ieee80211_geo to provide helper functions
ieee80211: Added ieee80211_radiotap.h
ieee80211: Additional fixes for endian-aware types
ieee80211: "extern inline" to "static inline"
ieee80211: Type-o, capbility definition for QoS, and ERP parsing
ieee80211: Mixed PTK/GTK CCMP/TKIP support
ieee80211: Keep auth mode unchanged after iwconfig key off/on cycle
ieee80211: Updated copyright dates
ieee80211: Updated hostap to be compatible with ieee80211_hdr changes
ieee80211: Updated hostap to be compatible with extra_prefix_len changes
ieee82011: Remove WIRELESS_EXT ifdefs
ieee80211: Added subsystem version string and reporting via MODULE_VERSION
ieee80211: Added handle_deauth() callback, enhanced tkip/ccmp support of varying hw/sw offload
ieee80211: added IE comments, reason_code to reason, removed info_element from ieee80211_disassoc
ieee80211: in-tree driver updates to sync with latest ieee80211 series
ieee80211: update orinoco, wl3501 drivers for latest struct naming
Lindent and trailing whitespace script executed ieee80211 subsystem
Update version ieee80211 stamp to 1.1.6
ieee80211 build fix
Jean Tourrilhes:
hostap: Add support for WE-19
hostap: Use GFP_ATOMIC to get rid of weird might_sleep issue
hostap: Remove iwe_stream_add_event kludge
Jeff Garzik:
[netdrvr] delete CONFIG_PHYCONTROL
Remove WIRELESS_EXT ifdefs from several wireless drivers.
[wireless airo] remove needed dma_addr_t obfuscation
e1000: fix warnings
Jiri Benc:
ieee80211: division by zero fix
John Linville:
[netdrvr s2io] Add a MODULE_VERSION entry
John W. Linville:
8139cp: support ETHTOOL_GPERMADDR
8139too: support ETHTOOL_GPERMADDR
b44: support ETHTOOL_GPERMADDR
e1000: support ETHTOOL_GPERMADDR
e100: support ETHTOOL_GPERMADDR
forcedeth: support ETHTOOL_GPERMADDR
ixgb: support ETHTOOL_GPERMADDR
ne2k-pci: support ETHTOOL_GPERMADDR
pcnet32: support ETHTOOL_GPERMADDR
r8169: support ETHTOOL_GPERMADDR
skge: support ETHTOOL_GPERMADDR
sundance: support ETHTOOL_GPERMADDR
via-rhine: support ETHTOOL_GPERMADDR
s2io: change strncpy length arg to use size of target
bonding: replicate IGMP traffic in activebackup mode
via-rhine: change mdelay to msleep and remove from ISR path
epic100: fix counting of work_done in epic_poll
bonding: fix typos in bonding documentation
8139too: fix resume for Realtek 8100B/8139D
bonding: cleanup comment for mode 1 IGMP xmit hack
b44: alternate allocation option for DMA descriptors
orinoco: remove redundance skb length check before padding
sundance: remove if (1) { ... } block in sundance_probe1
sundance: expand reset mask
sundance: include MII address 0 in PHY probe
Jouni Malinen:
hostap: Remove hw specific dev_open/close handlers
hostap: Fix hostap_pci build with PRISM2_IO_DEBUG
hostap: Do not free local->hw_priv before unregistering netdev
hostap: Unregister netdevs before freeing local data
Mallikarjuna R Chilakala:
e1000: Support for 82571 and 82572 controllers
e1000: multi-queue defines/modification to data structures
e1000: implementation of the multi-queue feature
e1000: Enable custom configuration bits for 82571/2 controllers
e1000: Fixes for packet split related issues
e1000: Added msleep_interruptible delay
e1000: Flush shadow RAM
e1000: Driver version, white space, comments, device id & other
Manfred Spraul:
forcedeth: add hardware tx checksumming
Mateusz Berezecki:
[wireless ipw2200] remove redundant return statement
Matt Porter:
Add rapidio net driver
Michael Buesch:
ieee80211 subsystem:
Michael Wu:
This patch fixes a typo in ieee80211.h: ieee82011_deauth -> ieee80211_deauth
Michal Schmidt:
airo: fix resume
Nishanth Aravamudan:
drivers/net: fix-up schedule_timeout() usage
Pavel Roskin:
orinoco: WE-18 support
orinoco: Remove conditionals that are useless in the kernel drivers.
orinoco: Don't include <net/ieee80211.h> twice.
orinoco: Update PCMCIA ID's.
orinoco: Remove inneeded system includes.
orinoco: Make nortel_pci_hw_init() static.
orinoco: Fix memory leak and unneeded unlock in orinoco_join_ap()
orinoco: orinoco_send_wevents() could return without unlocking.
orinoco: Remove unneeded forward declarations.
orinoco: Annotate endianess of variables and structure members.
orinoco: Read only needed data in __orinoco_ev_txexc().
orinoco: Bump version to 0.15rc3.
hostap: Fix pci_driver name for hostap_plx and hostap_pci
Ralf Baechle:
AX.25: Delete debug printk from mkiss driver
AX.25: Convert mkiss.c to DEFINE_RWLOCK
rcu in bpqether driver.
SMACK support for mkiss
Initialize the .owner field the tty_ldisc structure.
sb1250-mac: Check the actual setting for reporting hw checksumming.
sb1250-mac: Ensure 16-byte alignment of the descriptor ring.
au1000_eth: Misc Au1000 net driver fixes.
de2104x: Resurrect Cobalt support for 2.6.
sgiseeq: Fix resource handling.
sgiseeq: Configure PIO and DMA timing requests.
declance: Convert to irqreturn_t.
declance: Fix mapping of device.
declance: Deal with the bloody KSEG vs CKSEG horror...
declance: Use physical addresses at the interface level.
ne: Support for RBHMA4500 eval board.
mipsnet: Virtual ethernet driver for MIPSsim.
Remove unused header.
sb1250-mac: Get rid of all the funny SBMAC_WRITECSR and SBMAC_READCSR macros.
sb1250-mac: Whitespace cleanup.
sb1250-mac: PHY probing fixes.
Randy Dunlap:
Fix implicit nocast warnings in ieee80211 code:
Ravinandan Arakali:
S2io: MSI/MSI-X support (runtime configurable)
ravinandan.arakali@neterion.com:
S2io: Offline diagnostics fixes
Tobias Klauser:
Replace drivers/net/wan custom ctype macros with standard ones
Ursula Braun:
s390: introducing support in qeth for new OSA CHPID type OSN
viro@ZenIV.linux.org.uk:
lne390 bogus casts
C99 initializers in ray_cs.c
^ permalink raw reply
* [PATCH] 2.6.14-rc5-mm1 net/ipv4/route.c: spin_unlock call fails to compile
From: John Bowler @ 2005-10-28 7:08 UTC (permalink / raw)
To: netdev; +Cc: mingo, linux-kernel
The spin_unlock call which gets an rt_hash_lock_addr(i)
argument fails to compile on rc5-mm1 uniprocessor with
no CONFIG_DEBUG_SPINLOCK because, in mm1, the spin_unlock
macro expands to a statement of the form:
do { (void)&ptr->raw; } while (0)
and 'ptr' is 'NULL'. Since the expression is address-of
(therefore not evaluated as an r-value - i.e. no attempt
is made to load the non-existent raw, just take its address)
this expression is harmless.
The patch makes 'ptr' ((spinlock_t*)NULL), which the compiler
can compile (sizeof *ptr is 0 in the case - the spinlock_t
struct is empty - so the patch is particularly safe.)
The patch applies to both 2.6.14 and 2.6.14-rc5-mm1 (although
only the latter requires it.)
Signed-off-by: John Bowler <jbowler@acm.org>
--- linux-2.6.14-rc5/net/ipv4/route.c 2005-10-26 08:37:20.752285410 -0700
+++ patched/net/ipv4/route.c 2005-10-26 12:17:00.761651111 -0700
@@ -231,7 +231,7 @@ static spinlock_t *rt_hash_locks;
spin_lock_init(&rt_hash_locks[i]); \
}
#else
-# define rt_hash_lock_addr(slot) NULL
+# define rt_hash_lock_addr(slot) ((spinlock_t*)NULL)
# define rt_hash_lock_init()
#endif
^ permalink raw reply
* Re: [PATCH] 2.6.14-rc5-mm1 net/ipv4/route.c: spin_unlock call fails to compile
From: Ingo Molnar @ 2005-10-28 9:00 UTC (permalink / raw)
To: John Bowler; +Cc: netdev, linux-kernel
In-Reply-To: <001401c5db8e$650bd380$1001a8c0@kalmiopsis>
* John Bowler <jbowler@acm.org> wrote:
> #else
> -# define rt_hash_lock_addr(slot) NULL
> +# define rt_hash_lock_addr(slot) ((spinlock_t*)NULL)
> # define rt_hash_lock_init()
looks good to me - it gives (slightly) more type safety too.
Ingo
^ permalink raw reply
* [PATH] [MCAST] IPv6: Fix algorithm to compute Querier's Query Interval and Maximum Response Delay
From: Yan Zheng @ 2005-10-28 16:02 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
5.1.3. Maximum Response Code
The Maximum Response Code field specifies the maximum time allowed
before sending a responding Report. The actual time allowed, called
the Maximum Response Delay, is represented in units of milliseconds,
and is derived from the Maximum Response Code as follows:
If Maximum Response Code < 32768,
Maximum Response Delay = Maximum Response Code
If Maximum Response Code >=32768, Maximum Response Code represents a
floating-point value as follows:
0 1 2 3 4 5 6 7 8 9 A B C D E F
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Response Delay = (mant | 0x1000) << (exp+3)
5.1.9. QQIC (Querier's Query Interval Code)
The Querier's Query Interval Code field specifies the [Query
Interval] used by the Querier. The actual interval, called the
Querier's Query Interval (QQI), is represented in units of seconds,
and is derived from the Querier's Query Interval Code as follows:
If QQIC < 128, QQI = QQIC
If QQIC >= 128, QQIC represents a floating-point value as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+
QQI = (mant | 0x10) << (exp + 3)
-- rfc3810
#define MLDV2_QQIC(value) MLDV2_EXP(0x80, 4, 3, value)
#define MLDV2_MRC(value) MLDV2_EXP(0x8000, 12, 3, value)
Above macro are defined in mcast.c. but 1 << 4 == 0x10 and 1 << 12 == 0x1000.
So the result computed by original Macro is larger.
Signed-off-by: Yan Zheng <yanzheng@21cn.com>
Index: net/ipv6/mcast.c
===================================================================
--- linux-2.6.14/net/ipv6/mcast.c 2005-10-28 08:02:08.000000000 +0800
+++ linux/net/ipv6/mcast.c 2005-10-28 23:41:18.000000000 +0800
@@ -164,7 +164,7 @@
#define MLDV2_MASK(value, nb) ((nb)>=32 ? (value) : ((1<<(nb))-1) & (value))
#define MLDV2_EXP(thresh, nbmant, nbexp, value) \
((value) < (thresh) ? (value) : \
- ((MLDV2_MASK(value, nbmant) | (1<<(nbmant+nbexp))) << \
+ ((MLDV2_MASK(value, nbmant) | (1<<(nbmant))) << \
(MLDV2_MASK((value) >> (nbmant), nbexp) + (nbexp))))
#define MLDV2_QQIC(value) MLDV2_EXP(0x80, 4, 3, value)
^ permalink raw reply
* Re: [PATCH] 2.6.14-rc4: wider use of for_each_*cpu() in net
From: Arnaldo Carvalho de Melo @ 2005-10-28 16:02 UTC (permalink / raw)
To: hawkes@sgi.com; +Cc: netdev, linux-kernel
In-Reply-To: <20051013190133.13192.46039.sendpatchset@tomahawk.engr.sgi.com>
On 10/13/05, hawkes@sgi.com <hawkes@sgi.com> wrote:
> In 'net' change the explicit use of for-loops and NR_CPUS into the
> general for_each_cpu() or for_each_online_cpu() constructs, as
> appropriate. This widens the scope of potential future optimizations
> of the general constructs, as well as takes advantage of the existing
> optimizations of first_cpu() and next_cpu(), which is advantageous
> when the true CPU count is much smaller than NR_CPUS.
>
> Signed-off-by: John Hawkes <hawkes@sgi.com>
Thanks, applied and pushed to Linus,
- Arnaldo
^ permalink raw reply
* Re: [PATH] [MCAST] IPv6: Fix algorithm to compute Querier's Query Interval and Maximum Response Delay
From: David Stevens @ 2005-10-28 17:18 UTC (permalink / raw)
To: Yan Zheng; +Cc: linux-kernel, netdev, netdev-owner
In-Reply-To: <43624B98.6010405@21cn.com>
Yes, I think you're correct.
Acked-by: David L Stevens <dlstevens@us.ibm.com>
>
> Signed-off-by: Yan Zheng <yanzheng@21cn.com>
>
> Index: net/ipv6/mcast.c
> ===================================================================
> --- linux-2.6.14/net/ipv6/mcast.c 2005-10-28 08:02:08.000000000 +0800
> +++ linux/net/ipv6/mcast.c 2005-10-28 23:41:18.000000000 +0800
> @@ -164,7 +164,7 @@
> #define MLDV2_MASK(value, nb) ((nb)>=32 ? (value) : ((1<<(nb))-1) &
(value))
> #define MLDV2_EXP(thresh, nbmant, nbexp, value) \
> ((value) < (thresh) ? (value) : \
> - ((MLDV2_MASK(value, nbmant) | (1<<(nbmant+nbexp))) << \
> + ((MLDV2_MASK(value, nbmant) | (1<<(nbmant))) << \
> (MLDV2_MASK((value) >> (nbmant), nbexp) + (nbexp))))
>
> #define MLDV2_QQIC(value) MLDV2_EXP(0x80, 4, 3, value)
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: [PATH] [MCAST] IPv6: Fix algorithm to compute Querier's Query Interval and Maximum Response Delay
From: Arnaldo Carvalho de Melo @ 2005-10-28 18:19 UTC (permalink / raw)
To: David Stevens; +Cc: Yan Zheng, linux-kernel, netdev, netdev-owner
In-Reply-To: <OF7FABC1EE.FDB8A0D4-ON882570A8.005EDBB4-882570A8.005F14D9@us.ibm.com>
On 10/28/05, David Stevens <dlstevens@us.ibm.com> wrote:
> Yes, I think you're correct.
>
> Acked-by: David L Stevens <dlstevens@us.ibm.com>
Thanks, applying to my tree.
- Arnaldo
^ permalink raw reply
* Re: [PATCH 1/5] ibmveth fix bonding
From: Jeff Garzik @ 2005-10-28 20:07 UTC (permalink / raw)
To: Santiago Leon; +Cc: Andrew Morton, netdev, lkml
In-Reply-To: <20051026164539.21820.57374.sendpatchset@localhost.localdomain>
Santiago Leon wrote:
> This patch updates dev->trans_start and dev->last_rx so that the ibmveth
> driver can be used with the ARP monitor in the bonding driver.
>
> Signed-off-by: Santiago Leon <santil@us.ibm.com>
applied 1-5
^ permalink raw reply
* Re: [PATCH] sis900: come alive after temporary memory shortage
From: Jeff Garzik @ 2005-10-28 20:46 UTC (permalink / raw)
To: Vasily Averin; +Cc: Daniele Venzano, Andrew Morton, NetDev, Stanislav Protassov
In-Reply-To: <4347C50A.9010501@sw.ru>
applied
^ permalink raw reply
* Re: [PATCH] Add Wake on LAN support to sis900 (2)
From: Jeff Garzik @ 2005-10-28 20:49 UTC (permalink / raw)
To: Daniele Venzano; +Cc: NetDev, akpm
In-Reply-To: <20051011074430.GA29824@renditai.milesteg.arr>
applied to sis900-wol branch of netdev-2.6.git. This will
auto-propagate to -mm. Let me know when sufficient testing has been
had, and I will push it upstream.
^ permalink raw reply
* Re: [PATCH 02/14] Big kfree NULL check cleanup - drivers/net
From: Jeff Garzik @ 2005-10-28 20:53 UTC (permalink / raw)
To: Jesper Juhl
Cc: linux-kernel, Andrew Morton, David S. Miller, Jes Sorensen,
Matt Porter, Michael Chan, linux.nics, hans, Santiago Leon,
Jean Tourrilhes, Paul Mackerras, Michael Hipp, Jes Sorensen,
Carsten Langgaard, Benjamin Reed, Jouni Malinen, prism54-private,
netdev, Stuart Cheshire, g4klx, Alan Cox
In-Reply-To: <200510132122.48035.jesper.juhl@gmail.com>
Jesper Juhl wrote:
> This is the drivers/net/ part of the big kfree cleanup patch.
>
> Remove pointless checks for NULL prior to calling kfree() in drivers/net/.
>
>
> Sorry about the long Cc: list, but I wanted to make sure I included everyone
> who's code I've changed with this patch.
>
>
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
applied 98% of this
^ 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