On Saturday 10 March 2007 16:52, Jeff Garzik wrote:
> Amit Kale wrote:
> > On Friday 09 March 2007 22:26, Jeff Garzik wrote:
> >> Linsys Contractor Mithlesh Thukral wrote:
> >>> Hi All,
> >>>
> >>> I will be sending updates to NetXen: 1G/10G Ethernet driver in
> >>> subsequent mails. The patches wi
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/ipv4/ipmr.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
From 98ed69cabc5d06b65d34d8fa779aacec791d4ef3 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Sun, 11 Mar 2007 22:38:29 -
For the cases where the network header is being set to a offset from skb->data.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
From 03b510407695a4ad4edb3cb54dd489ca486e0165 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Sun, 11 Mar 2007 22:39:41 -03
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_3ad.c |4 ++--
drivers/net/bonding/bond_alb.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
From c71af7068c66bcbc377b1e4593eb58bec961699c Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo
For the quite common 'skb->nh.raw - skb->data' sequence.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
From 578a14f390cd7731eefaa81905ed8383a7c567f6 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Sat, 10 Mar 2007 22:16:10 -0300
Subject: [PATCH 15/1
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/ipv4/ip_output.c |3 ++-
net/ipv4/ip_sockglue.c |5 +++--
2 files changed, 5 insertions(+), 3 deletions(-)
From 8eb8a114c4b1ece5b71d1d56a400531627c63129 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <[EMAIL PROTE
boot_pkt->iph is the first member, that is at skb->data, so just use
skb_reset_network_header().
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/ipv4/ipconfig.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
From 71ecb4941b897c724bb7b9762cf49d1979403362 Mon Sep 17
Some more cases where skb->nh.iph was being set that were converted
to using skb_reset_network_header.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/ipv4/ip_output.c | 14 ++
net/ipv4/ipmr.c |9 ++---
2 files changed, 12 insertions(+), 11 deletions(-
Now related to this form:
skb->nh.ipv6h = (struct ipv6hdr *)skb_put(skb, length);
That, as the others, is done when skb->tail is still equal to skb->data, making
the conversion to skb_reset_network_header possible.
Also one more case equivalent to skb->nh.raw = skb->data, of this form:
iph = (
Setting it to skb->h.raw, which is valid, in the (to become) old pointer based
world order and in the new world of offset based layer headers.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/ipv4/xfrm4_mode_transport.c |6 --
1 files changed, 4 insertions(+), 2 deletion
For the common, open coded 'skb->nh.raw = skb->data' operation, so that we can
later turn skb->nh.raw into a offset, reducing the size of struct sk_buff in
64bit land while possibly keeping it as a pointer on 32bit.
This one touches just the most simple case, next will handle the slightly more
"c
skb_push updates and returns skb->data, so we can just call
skb_reset_network_header after the call to skb_push.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/core/netpoll.c |4 +++-
net/ipv4/ip_gre.c |3 ++-
net/ipv4/ip_output.c|
But only in the cases where its a newly allocated skb, i.e. one where skb->tail
is equal to skb->data, or just after skb_reserve, where this requirement is
maintained.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/appletalk/aarp.c | 12 +---
net/ipv4/igmp.c |
It returns skb->data, so we can just use skb_reset_network_header after it.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/ipv4/ip_gre.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
From 5993129f2113315b46f5045d2a7c333a24f3ae1b Mon Sep 17 00:00:00 2001
From: Ar
This time of the type:
skb->nh.iph = (struct iphdr *)skb->data;
That is completely equivalent to:
skb->nh.raw = skb->data;
Wonder why people love casts... :-)
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/ieee80211/ieee80211_rx.c |2 +-
net/ipv4/ipmr.c |
Hi David,
Paving the way for turning the layer headers offsets, to
shrink struct sk_buff on 64bits (and perhaps on 32 bits too), this
time for skb->nh, more on this layer still to come (ip_hdr(), etc).
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/a
For consistency with all the other skb->nh.raw accessors.
Also do some really obvious simplifications in pppoe_recvmsg, well the
kfree_skb one is not so obvious, but free() and kfree() have the same behaviour
(hint :-) ).
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/ne
For consistency with all the other skb->nh.raw accessors.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_alb.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
From 017d8a3262d70f04de22c653e80ef1137bacb88b Mon Sep 17 00:00:00 2001
From: A
nh.ipv6h is there exactly for this reason! Use it while it exists ;-)
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/ipv6/exthdrs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From 45e1146ca9763f450277260d9c41f2b2e83b6d4e Mon Sep 17 00:00:00 2001
From: Arnaldo
On Fri, Mar 09, 2007 at 09:14:29AM -0800, Randy Dunlap wrote:
> Good to use FIELD_SIZEOF(),
Thanks.
> but in general, we prefer to use it
> directly, not in yet another wrapper.
I left the item_{size,addr} in place as it seemed to make the item[]
more compact.
I'm
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]>
Date: Sat, 10 Mar 2007 13:45:44 -0300
> Hi David,
>
> Paving the way for turning the layer headers offsets, to
> shrink struct sk_buff on 64bits (and perhaps on 32 bits too).
>
> Please consider pulling from:
>
> master.kern
Attached below is my take on how to address this problem.
This addresses any concerns you may have had about checking po->pppoe_dev==NULL,
because accesses to this field are now synchronized with pppoe_hash_lock.
Once we can settle on a fix for this, I'll deal with the SID==0 issue
(trying to d
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
net/ax25/af_ax25.c | 77 +++-
net/netrom/af_netrom.c | 93 -
net/rose/af_rose.c | 54 +---
3 files changed, 109 insertions(+),
Especially if you actually try to do it ;-)
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
net/rose/af_rose.c | 78 +
1 file changed, 50 insertions(+), 28 deletions(-)
Index: linux-net/net/rose/af_rose.c
Patches 1/3 and 2/3 are fixes for 2.6.21 and -stable. 3/3 is a cleanup
even though it seems to partly paper over a connection establishment issue
on extremly fast networks such as loopback I'm still chasing.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body o
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
net/rose/af_rose.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-net/net/rose/af_rose.c
===
--- linux-net.orig/net/rose/af_rose.c
+++ linux-net/net/rose/af_rose.c
@@ -877,6 +
On Sunday 11 March 2007 15:19, Daniel Drake wrote:
> Changed the reference to Devicescape stack to mac80211.
>
I referred to Devicescape originally because the only other driver that had
both softmac and devicescape versions was bcm43xx, so I copied "(DeviceScape
stack)" in order to be consistent
On Sunday 11 March 2007 21:11, Ulrich Kunitz wrote:
> > I'm still not convinced that papering over the problem in userspace is a
> > real solution.
> >
> > johannes
>
> Just my 2 cents. I support this. What are the options? I see only
> two:
>
> 1. Use different magic numbers for 32 bit and 64 b
> I'm still not convinced that papering over the problem in userspace is a
> real solution.
>
> johannes
Just my 2 cents. I support this. What are the options? I see only
two:
1. Use different magic numbers for 32 bit and 64 bit structures. A
flag is an alternative, but will be more difficult
ZD1211 appears to be back in production: a number of new devices have
been appearing! Some of them are using new radios.
This patch adds support for the next generation AL2230 RF chip which has
been spotted in a few new devices.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
zd_chip.c
ASUS A9Rp
Tested by Serge
zd1211b chip 0b05:171b v4802 high 00-17-31 AL2230_RF pa0 g--
ZyXEL G-202
Tested by Marcus D. Hanwell
zd1211b chip 0586:3410 v4810 high 00-13-49 AL2230_RF pa0 g---
US Robotics USR805423
Tested by Pascal S. de Kloe
FCC ID: RAXWN4501H
zd1211b chip 0baf:0121 v4810 high 00-14
zd1211rw currently detects AL2230S-based devices as AL2230, and hence
programs the RF incorrectly. Transmit silently fails on this
misconfiguration.
After this patch, AL2230S devices are rejected with an error message, to
avoid any confusion with an apparent driver bug.
Signed-off-by: Daniel Drak
Suggested by Maxime Austruy, based on mac80211 changes from Stephen
Hemminger
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
zd_mac.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
Index: linux/drivers/net/wireless/zd1211rw/zd_mac.c
=
ASUS A9Rp
Tested by Serge
zd1211b chip 0b05:171b v4802 high 00-17-31 AL2230_RF pa0 g--
ZyXEL G-202
Tested by Marcus D. Hanwell
zd1211b chip 0586:3410 v4810 high 00-13-49 AL2230_RF pa0 g---
US Robotics USR805423
Tested by Pascal S. de Kloe
FCC ID: RAXWN4501H
zd1211b chip 0baf:0121 v4810 high 00-14
ZD1211 appears to be back in production: a number of new devices have
been appearing! Some of them are using new radios.
This patch adds support for the next generation AL2230 RF chip which has
been spotted in a few new devices.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
drivers/net/wir
Suggested by Maxime Austruy, based on mac80211 changes from Stephen
Hemminger
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
drivers/net/wireless/mac80211/zd1211rw/zd_mac.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/mac80211/zd1211rw/zd_mac
From: Ulrich Kunitz <[EMAIL PROTECTED]>
Changed the reference to Devicescape stack to mac80211.
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
drivers/net/wireless/mac80211/zd1211rw/Kconfig |6 +++---
1 files changed, 3 insertions(+), 3 d
From: Pavel Roskin <[EMAIL PROTECTED]>
All fields in radiotap header must be little endian. The driver does it
correctly, but the structure definition must be annotated.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Signed-off-by: Daniel Drake <
I need some more time to think about this one; there are some problem
I'm seeing here but I can't look at it right now. I'll send out my
version of a patch for this tomorrow and we can discuss more.
Regarding the previous three patches, they seem fine after a first pass.
However, I'd like to ask
Daniel Drake wrote:
Suggested by Maxime Austruy, based on mac80211 changes from Stephen
Hemminger
Sorry, paths were broken on these patches. Resends coming a little later.
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Hi,
I recently was able to get hold of a 3C597 card for my Jensen Alpha.
Compiling the driver for it however gives error messages about undefined
symbols:
pci_alloc_consistent
pci_free_consistent
pci_map_single
pci_map_unsingle
These functions do not exist on a pure EISA system (like the Jensen
ZD1211 appears to be back in production: a number of new devices have
been appearing! Some of them are using new radios.
This patch adds support for the next generation AL2230 RF chip which has
been spotted in a few new devices.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
drivers/net/wir
From: Pavel Roskin <[EMAIL PROTECTED]>
All fields in radiotap header must be little endian. The driver does it
correctly, but the structure definition must be annotated.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Signed-off-by: Daniel Drake <
From: Ulrich Kunitz <[EMAIL PROTECTED]>
Changed the reference to Devicescape stack to mac80211.
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
drivers/net/wireless/mac80211/zd1211rw/Kconfig |6 +++---
1 files changed, 3 insertions(+), 3 d
Suggested by Maxime Austruy, based on mac80211 changes from Stephen
Hemminger
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
drivers/net/wireless/zd1211rw/zd_mac.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c
b/dri
On Fri, 2007-03-09 at 13:35 -0800, Jean Tourrilhes wrote:
> It's not as bad as it look like. All userspace programs
> nowadays use either the iwlib or wpa_supplicant. For example,
> NetworkManager gets its stuff through wpa_supplicant, and kdenetwork
> uses iwlib. So, in essence, there is on
On Sat, Mar 10, 2007 at 11:22:40AM -0500, John W. Linville wrote:
> On Sat, Mar 10, 2007 at 04:38:16PM +0100, Adrian Bunk wrote:
> > On Sat, Mar 10, 2007 at 10:03:46AM -0500, John W. Linville wrote:
>
> > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > > index 6a4325b..b2e1deb 100644
Hi,
The uli526x network driver doesn't implement .suspend and .resume methods
and the interface handled by it is unuseable after the resume. Since I have
one of these boards in a box which is used to test the suspend/resume
functionality, I've prepared the appended patch that adds the .suspend an
On Sat, Mar 10, 2007 at 11:25:05PM +0300, Sergei Shtylyov wrote:
>Oops, I was going to recast the patch but my attention switched
>elsewhere for couple of days, and it "slipped" into mainline. I'm now
> preparing a better patch to also protect...
Ah, I was also looking at it. I enclose
49 matches
Mail list logo
