On Fri, 01 Dec 2006 13:41:39 +0900
Kazunori MIYAZAWA [EMAIL PROTECTED] wrote:
David Miller wrote:
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Fri, 24 Nov 2006 14:38:39 +0900
What is going on here?
+ /* Without this, the atomic inc below segfaults */
+
On Thu, 30 Nov 2006 16:49:03 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Fri, 24 Nov 2006 14:38:52 +0900
+static inline void ip6ip_ecn_decapsulate(struct sk_buff *skb)
+{
+ if (INET_ECN_is_ce(ipv6_get_dsfield(skb-nh.ipv6h)))
+
If there is a better and less intrusive while still being obvious
method I am all for it. I do not like the OpenVZ thing of doing the
lookup once and then stashing the value in current and the special
casing the exceptions.
Why?
I like it when things are obvious and not implied.
The
On Wednesday, 6. December 2006 02:44, you wrote:
FYI...after latest round of merges, that patch that I've been carrying
in the pending branch of wireless-2.6 no longer applies.
John
Ok, I'm waiting for Dmitry' feedback... (hello, where're you ;) ?)
Christian
-
To unsubscribe from this list:
On Mon, 2006-12-04 at 10:13 +0100, Thomas Graf wrote:
Userspace is not supposd to directly include kernel headers, instead
it has to make local copies and compile against them.
No. It was _never_ sensible to simply declare that userspace shall not
use kernel headers in the absence of any
On 04-12-2006 16:34, Patrick McHardy wrote:
Fix a regression from my nfmark mask patch for cls_fw.
Thomas, Jamal, do you have an idea what this old method stuff
is used for? It seems it is only used during the below mentioned
race.
Sorry for eavesdropping, but have a look at htb_classify
On Wed, Dec 06, 2006 at 01:01:54PM +, David Woodhouse wrote:
No. They _are_ doing it right -- they're running 'make headers_install'
against the 2.6.19 kernel and only _now_ are they finding that we broke
it without even the courtesy of a warning, let alone any consultation.
If _we_ had
This fixes compilation with d80211/cfg80211/wireless ext.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
--- linux-2.6-git.orig/net/core/net-sysfs.c 2006-12-06 12:31:04.247283692
+0100
+++ linux-2.6-git/net/core/net-sysfs.c 2006-12-06 12:31:11.865215130 +0100
@@ -329,7 +329,7 @@
On Wed, 2006-12-06 at 14:43 +0100, Jakub Jelinek wrote:
+/* 2.6.19 kernel headers helpfully removed some macros and
+ moved lots of stuff into new headers, some of which aren't
+ included by linux/rtnetlink.h. */
+
+#ifndef IFA_MAX
+struct ifaddrmsg
+{
+ uint8_t ifa_family;
+
* Jakub Jelinek [EMAIL PROTECTED] 2006-12-06 14:43
On Wed, Dec 06, 2006 at 01:01:54PM +, David Woodhouse wrote:
No. They _are_ doing it right -- they're running 'make headers_install'
against the 2.6.19 kernel and only _now_ are they finding that we broke
it without even the courtesy of
On Wed, Dec 06, 2006 at 01:51:07PM +, David Woodhouse wrote:
On Wed, 2006-12-06 at 14:43 +0100, Jakub Jelinek wrote:
+/* 2.6.19 kernel headers helpfully removed some macros and
+ moved lots of stuff into new headers, some of which aren't
+ included by linux/rtnetlink.h. */
+
On Wed, 2006-12-06 at 14:57 +0100, Jakub Jelinek wrote:
Yes, but as I said, I'd need to add configure checks for that, using
#include linux/if_addr.h
alone breaks build with older headers.
I was thinking that the #ifndef IFA_MAX you already have ought to be
sufficient for that. Or even
On Wed, 2006-12-06 at 14:59 +0100, Thomas Graf wrote:
Are you suggesting that the kernel has to keep macros around which
are of no use to the kernel itself just because glibc uses them?
No, although in fact that _is_ the only reason we use these horrid __uXX
types rather than proper C
On 12/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Wednesday, 6. December 2006 02:44, you wrote:
FYI...after latest round of merges, that patch that I've been carrying
in the pending branch of wireless-2.6 no longer applies.
John
Ok, I'm waiting for Dmitry' feedback... (hello,
On Wed, Dec 06, 2006 at 02:07:19PM +, David Woodhouse wrote:
On Wed, 2006-12-06 at 14:59 +0100, Thomas Graf wrote:
Are you suggesting that the kernel has to keep macros around which
are of no use to the kernel itself just because glibc uses them?
No, although in fact that _is_ the only
* David Woodhouse [EMAIL PROTECTED] 2006-12-06 14:07
On Wed, 2006-12-06 at 14:59 +0100, Thomas Graf wrote:
Are you suggesting that the kernel has to keep macros around which
are of no use to the kernel itself just because glibc uses them?
No, although in fact that _is_ the only reason we
* Jakub Jelinek [EMAIL PROTECTED] 2006-12-06 15:18
There are the kernel's own headers and kernel ABI headers for userland use.
Until recently the latter has been maintained by various distributions
and manually occassionally updated to sync a little bit with kernel ABI
additions (new syscalls,
Hi Stephen,
This patch looks good.
ioctls: NetXen chip is far more generic and will eventually show a significant
amount of functionality in different products. We need ioctl analysis for
user level tools that can tell states of registers etc. Removing ioctls all
together will make any
All,
Attached is a patch to fix arp_reply when you have multiple possible
routers doing ARP requests to you. Currently arp_reply always replies to the
MAC address that it was given when it starts. However, if you have multiple
routers that can ARP request you, you might respond to the
On Wed, 6 Dec 2006 21:40:34 +0530
Amit S. Kale [EMAIL PROTECTED] wrote:
Hi Stephen,
This patch looks good.
ioctls: NetXen chip is far more generic and will eventually show a
significant
amount of functionality in different products. We need ioctl analysis for
user level tools that
fixes something i broke in previous patch. Against net-2.6.20.
BTW, is it just me having problems syncing net-2.6.20?
cheers,
jamal
[GENETLINK] fix misplaced command flags
The command flags for dump and do were swapped..
Signed-off-by: Jamal Hadi Salim[EMAIL PROTECTED]
---
commit
Jarek Poplawski wrote:
On 04-12-2006 16:34, Patrick McHardy wrote:
Thomas, Jamal, do you have an idea what this old method stuff
is used for? It seems it is only used during the below mentioned
race.
Sorry for eavesdropping, but have a look at htb_classify
starting comment. It is also
A small typo fixup
BTW, how do you like the subject to look like?
cheers,
jamal
[GENL] Multicast computation off by one
When using the first 32 groups, the multicast group to bit mapping
was off by one.
Signed-off-by: Jamal Hadi Salim
---
commit b883bf2396abc0434b3a63d228593cec80808dbb
tree
On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote:
At the time they were added they were meant to be exported but netlink
has evolved and we now have a type safe API.
Where? AFAICS, netlink might be considered type-safe only within an
address family...
-
To unsubscribe from this
From: jamal [EMAIL PROTECTED]
Date: Wed, 06 Dec 2006 12:02:23 -0500
fixes something i broke in previous patch. Against net-2.6.20.
BTW, is it just me having problems syncing net-2.6.20?
You should be using the net-2.6.git tree now, I blow away the
net-2.6.X.git tree when 2.6.X integration
Ok, heres hopefully the last one in this series for generic netlink ..
cheers,
jamal
[GENL]: Add controller support for new features exposed
Update the controller to spit out the new features being exposed
from the kernel
Signed-off-by: J Hadi Salim [EMAIL PROTECTED]
---
commit
a small one.
I have a few more but just run out of cycles for now;
if you dont mind holding before releasing for a short while so i can
get them out I will appreciate it.
cheers,
jamal
[DOC]: clarify ok and pass
A small fixup to elucidate the mysteries of accepting ..
---
commit
Hi, guys.
I've got a problem. I can see all the incoming packets on an ethernet
interface, but no outgoing packets, although they are sent to the
network, and successfully recieved by the other side. The platform is
ixp420, with severely nodifyed ethernet driver, the kernel is
2.6.16.20. May I
On Wed, Dec 06, 2006 at 02:54:16PM +0300, Kirill Korotaev wrote:
If there is a better and less intrusive while still being obvious
method I am all for it. I do not like the OpenVZ thing of doing the
lookup once and then stashing the value in current and the special
casing the exceptions.
On Tue, 5 Dec 2006 09:00:45 +0200
Muli Ben-Yehuda [EMAIL PROTECTED] wrote:
On Mon, Dec 04, 2006 at 10:39:49AM -0800, Stephen Hemminger wrote:
I notice that no current network driver handles dma mapping errors.
Might that be part of the problem. On i386, this never happens, and
it would
On Wed, Dec 06, 2006 at 10:16:44AM -0800, Stephen Hemminger wrote:
I think it is really only an issue for drivers that turn on HIGH_DMA
and have limited mask values. The majority of drivers either only
handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know
the details of how we
Am Montag, 4. Dezember 2006 10:13 schrieb Thomas Graf:
I do not agree with the change to include if_addr.h in rtnetlink.h.
The point is to move bits apart and have multiple small pieces
of header files defining a specific rtnetlink family which are a
lot easier to maintain for both kernel and
From: Randy Dunlap [EMAIL PROTECTED]
Fix compile warning when CONFIG_PROC_FS=n:
include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared inside
parameter list
include/net/irda/irlan_filter.h:31: warning: its scope is only this definition
or declaration, which is probably not
* Al Viro [EMAIL PROTECTED] 2006-12-06 17:13
On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote:
At the time they were added they were meant to be exported but netlink
has evolved and we now have a type safe API.
Where? AFAICS, netlink might be considered type-safe only within
* Stefan Rompf [EMAIL PROTECTED] 2006-12-06 20:32
According to a user's report, your change also broke compilation of my
dhcpclient because it neeeds if_addr.h since 2.6.19. Any suggestion how to
make one source code build on 2.6.19 and older headers? I hope you don't want
me to check on
On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote:
* Al Viro [EMAIL PROTECTED] 2006-12-06 17:13
On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote:
At the time they were added they were meant to be exported but netlink
has evolved and we now have a type safe API.
From: Ulrich Kunitz [EMAIL PROTECTED]
A deauthentication from the AP doesn't start a reassociation by
SoftMAC. To fix this mac-associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled.
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
Signed-off-by: Larry
* Al Viro [EMAIL PROTECTED] 2006-12-06 20:34
On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote:
* Al Viro [EMAIL PROTECTED] 2006-12-06 17:13
On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote:
At the time they were added they were meant to be exported but netlink
I believe all the below memory barriers only matter on SMP so therefore
the smp_* variant of the barrier should be used.
I'm wondering if the barrier in net/ipv4/inet_timewait_sock.c should be
dropped entirely. schedule_work's implementation currently implies a
memory barrier and I think sane
Andrew,
Please apply and forward upstream. This series of 16 small patches
consist of mostly of various cleanups, a few fixes, and a clarification
of the flow of the RX side of the spidernet ethernet driver. The
first patch, though, is a resubmit of an old patch.
--linas
-
To unsubscribe
Hi Randy,
Thanks for the patch. Looks fine to me.
On Wed, Dec 06, 2006 at 11:44:07AM -0800, Randy Dunlap wrote:
From: Randy Dunlap [EMAIL PROTECTED]
Fix compile warning when CONFIG_PROC_FS=n:
include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared
inside parameter list
The current driver code performs 512 DMA mappings of a bunch of
32-byte structures. This is silly, as they are all in contiguous
memory. Ths patch changes the code to DMA map the entie area
with just one call.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Acked-by: Joel Schopp [EMAIL
This patch adds net_ratelimit to many of the printks
in order to limit extraneous warning messages
This patch supercedes all previous ratelimit patches.
This has been tested, please apply.
From: James K Lewis [EMAIL PROTECTED]
Signed-off-by: James K Lewis [EMAIL PROTECTED]
Signed-off-by: Linas
The RX packet handling can be called from several
places, yet does not protect the rx ring structure.
This patch places the ring buffer pointers under a lock.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
Refactor how spider_net_refill_rx_chain() is called.
No functional change; this just simplifies the code
by moving the subroutine call to a more appropriate spot.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
One of the unlikely error branches has an skb memory leak.
Fix this by handling the error conditions consistently.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 18 +-
1
Another skb leak in an error branch. Fix this by adding
call to dev_kfree_skb_irq() after moving to a more
appropriate spot.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 23
Simplify the somewhat convoluted use of return codes
in the rx buffre handling.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 31 ---
1 file changed, 12
Two distinct if() statements have the ame body. Merge the clauses.
Also clean up punctuation, capitalization, etc.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 28
The invocation of the rx ring refill routine is haphazard;
centralize and make its usage consistent.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 11 ---
1 file changed, 4
Remove unused variable; this makes code easier to read.
Tweak commentary.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
Tell the hardware the location of the rx ring tail.
More punctuation cleanup.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 15 ---
1 file changed, 8 insertions(+), 7
Add memory barrier to make sure that the rest of the
RX descriptor state is flushed to memory before we tell
the hardware that its ready to go.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c
Re-enable irq's after emptying the RX ring; these had
been previously turned off on reception of the rxram_full
interrupt. More punctuation cleanup.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
Delete possible source of chain corruption; the hardware
already knows the location of the tail, and writing it
again is likely to mess it up.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c |
Make the hardware perceive the RX descriptor ring as a
null-terminated linked list, instead of a circular ring.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 10 --
1 file
Remove incorrect prohibition of hardware crypto support. This was
originally present to prevent hardware crypto when more than one
station interface was created for a single hardware device, the code
in question is no longer correct and should be removed.
Signed-off-by: David Kimdon [EMAIL
In these three cases the pointer returned by IEEE80211_DEV_TO_SUB_IF()
is never used.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++
If a hardware key has not been configured then there is no point
to calling DISABLE_KEY.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
---
sdata-keys[] has NUM_DEFAULT_KEYS elements, don't access past that.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++
dev-name and ndev-name are both IFNAMSIZ in length, the .%d is
not guarenteed to fit in ndev-name.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_iface.c
===
---
Without this change d80211 relies on userspace to let it know when it can
configure default wep keys. It is always safe to set default_wep_only if there
is a single station interface. This allows for hardware accelleration for
the case of a single station interface.
Signed-off-by: David Kimdon
We should be checking the type member, not the raw pointer.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++
We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in.
Patch from Jeet Chaudhuri [EMAIL PROTECTED]
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]
---
net/irda/irttp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/irda/irttp.c b/net/irda/irttp.c
index
Hi Dave,
pxaficp_ir.c was not converted to the device model framework.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]
---
drivers/net/irda/pxaficp_ir.c | 26
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 6 Dec 2006 10:16:44 -0800
I think it is really only an issue for drivers that turn on HIGH_DMA
and have limited mask values. The majority of drivers either only handle
32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the details
From: Randy Dunlap [EMAIL PROTECTED]
Date: Wed, 6 Dec 2006 11:44:07 -0800
From: Randy Dunlap [EMAIL PROTECTED]
Fix compile warning when CONFIG_PROC_FS=n:
include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared
inside parameter list
include/net/irda/irlan_filter.h:31:
On Wed, 06 Dec 2006 16:54:18 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 6 Dec 2006 10:16:44 -0800
I think it is really only an issue for drivers that turn on HIGH_DMA
and have limited mask values. The majority of drivers either
On Wed, 06 Dec 2006 16:57:17 -0800 (PST) David Miller wrote:
How about we protect these function externs with CONFIG_PROC_FS ifdefs
instead?
Sure.
---
From: Randy Dunlap [EMAIL PROTECTED]
Fix compile warning when CONFIG_PROC_FS=n:
include/net/irda/irlan_filter.h:31: warning: 'struct
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 6 Dec 2006 16:58:35 -0800
The more robust way would be to stop the queue (like flow control)
and return busy. You would need a timer though to handle the case
where some disk i/o stole all the mappings and then network device flow
blocked.
On 12/4/06, Jay Vosburgh [EMAIL PROTECTED] wrote:
Andy Gospodarek [EMAIL PROTECTED] wrote:
[...]
Let me see if I can dust off the extensive patch that does
change the locking model; I'll see if I can bring it up to the current
git and post it.
It would seem ideal if we could combine
On Wednesday 06 December 2006 15:45, Larry Finger wrote:
From: Ulrich Kunitz [EMAIL PROTECTED]
A deauthentication from the AP doesn't start a reassociation by
SoftMAC. To fix this mac-associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled.
On 06-12-06 18:52 Michael Buesch wrote:
All data in mac-associnfo is protected by mac-associnfo-mutex
and _not_ mac-lock.
Are you sure? One can find for instance the following function in
ieee80211softmac_assoc.c:
void
ieee80211softmac_disassoc(struct ieee80211softmac_device *mac)
{
On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
On 06-12-06 18:52 Michael Buesch wrote:
All data in mac-associnfo is protected by mac-associnfo-mutex
and _not_ mac-lock.
Are you sure?
Yes I am.
One can find for instance the following function in
ieee80211softmac_assoc.c:
On 06-12-06 21:52 Michael Buesch wrote:
On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
On 06-12-06 18:52 Michael Buesch wrote:
All data in mac-associnfo is protected by mac-associnfo-mutex
and _not_ mac-lock.
Are you sure?
Yes I am.
One can find for instance the
On Wednesday 06 December 2006 22:51, Ulrich Kunitz wrote:
On 06-12-06 21:52 Michael Buesch wrote:
On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
On 06-12-06 18:52 Michael Buesch wrote:
All data in mac-associnfo is protected by mac-associnfo-mutex
and _not_ mac-lock.
Michael Buesch wrote:
On Wednesday 06 December 2006 22:51, Ulrich Kunitz wrote:
On 06-12-06 21:52 Michael Buesch wrote:
On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
On 06-12-06 18:52 Michael Buesch wrote:
All data in mac-associnfo is protected by mac-associnfo-mutex
and _not_
David Miller wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 6 Dec 2006 16:58:35 -0800
The more robust way would be to stop the queue (like flow control)
and return busy. You would need a timer though to handle the case
where some disk i/o stole all the mappings and then network
From: Rick Jones [EMAIL PROTECTED]
Date: Wed, 06 Dec 2006 18:18:52 -0800
While tossing a TCP|UDP|SCTP|etc packet could be plusungood, especially
if the IOMMU fills frequently (for some suitable definiton of
frequently), is it really worth the effort to save say an ACK?
ACKs are less
From: Samuel Ortiz [EMAIL PROTECTED]
Date: Thu, 7 Dec 2006 02:50:53 +0200
pxaficp_ir.c was not converted to the device model framework.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]
Applied.
-
From: Samuel Ortiz [EMAIL PROTECTED]
Date: Thu, 7 Dec 2006 02:51:17 +0200
We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in.
Patch from Jeet Chaudhuri [EMAIL PROTECTED]
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]
Also applied.
Are you sending this patch to -stable? Please do.
-
From: Randy Dunlap [EMAIL PROTECTED]
Date: Wed, 6 Dec 2006 17:08:18 -0800
On Wed, 06 Dec 2006 16:57:17 -0800 (PST) David Miller wrote:
How about we protect these function externs with CONFIG_PROC_FS ifdefs
instead?
Sure.
---
From: Randy Dunlap [EMAIL PROTECTED]
Fix compile
Hi Dave !
I'd like your advice on something we need to deal with in the EMAC
ethernet driver (an IBM part). The driver is maintainedby Eugene (CC'd),
I'm mostly adding support for some new hardware at this point, which
involves making it SMP safe among other things ;-)
So the problem this driver
What Eugene does currently, which seems to me like it's actually the
only proper solution, is to create a separate net_device structure for
the DMA engine and thus have a single NAPI poll weighting for all the
EMACs sharing a given MAL (MAL is the name of that DMA engine). This
means that
On Thursday 07 December 2006 01:03, Muli Ben-Yehuda wrote:
On Wed, Dec 06, 2006 at 10:16:44AM -0800, Stephen Hemminger wrote:
I think it is really only an issue for drivers that turn on HIGH_DMA
and have limited mask values. The majority of drivers either only
handle 32 bit (!HIGH_DMA) or
We can let a driver handle dma mapping errors using these-
1.Reduce the size of a receive ring. This will free some possibly remapped
memory, reducing pressure on iommu. We also need to printk a message so that
a user knows the reason why receive ring was shrunk. Growing it when iommu
pressure
Andy Gospodarek [EMAIL PROTECTED] wrote:
On 12/4/06, Jay Vosburgh [EMAIL PROTECTED] wrote:
[...]
Appended is my working development patch for rearranging a bunch
of stuff in bonding. This is a work in progress, and is not likely to
be very stable. This largely reimplements the entire
Amit S. Kale wrote:
We can let a driver handle dma mapping errors using these-
1.Reduce the size of a receive ring. This will free some possibly remapped
memory, reducing pressure on iommu. We also need to printk a message so that
a user knows the reason why receive ring was shrunk. Growing
On Thursday 07 December 2006 12:16, Stephen Hemminger wrote:
Amit S. Kale wrote:
We can let a driver handle dma mapping errors using these-
1.Reduce the size of a receive ring. This will free some possibly
remapped memory, reducing pressure on iommu. We also need to printk a
message so
[TG3]: Add 5787F device ID.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 819758e..bfa7e3e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -192,6 +192,7 @@ static struct pci_device_id tg3_pci_tbl[
[TG3]: Fix Phy loopback.
Phy loopback on most 10/100 devices need to be run in 1Gbps mode in
GMII mode.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c20bb99..819758e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8781,17
[TG3]: Add TG3_FLG2_IS_NIC flag.
Add Tg3_FLG2_IS_NIC flag to unambiguously determine whether the
device is NIC or onboard. Previously, the EEPROM_WRITE_PROT flag was
overloaded to also mean onboard. With the separation, we can
support some devices that are onboard but do not use eeprom write
[TG3]: Allow partial speed advertisement.
Honor the advertisement bitmask from ethtool. We used to always
advertise the full capability when autoneg was set to on.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 6a2f019..5dfeb64 100644
---
[TG3]: Use netif_msg_*.
Use netif_msg_* to turn on or off some messages.
Based on Stephen Hemminger's initial patch.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 5dfeb64..99fb4e4 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@
[TG3]: Use msleep.
Change some udelay() in some eeprom functions to msleep(). Eeprom
related functions are always called from sleepable context.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 99fb4e4..61e9533 100644
---
[TG3]: Identify Serdes devices more clearly.
Change the message to more clearly identify Serdes devices.
Update version to 3.70.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 61e9533..a71707e 100644
--- a/drivers/net/tg3.c
+++
It worries me when a patch series gets resent a few hours later.
Did anything change?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Amit S. Kale [EMAIL PROTECTED]
Date: Thu, 7 Dec 2006 11:55:22 +0530
We can let a driver handle dma mapping errors using these-
1.Reduce the size of a receive ring. This will free some possibly remapped
memory, reducing pressure on iommu. We also need to printk a message so that
a
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Wed, 6 Dec 2006 20:35:37 +0900
Sorry, I mixed up changes in the patches. I described that [4/7] will add
IPv6 over IPv4 IPsec tunnel. However I send a patch for IPv4 over IPv6
as a reply because it includes the discussing item.
So this patch
From: David Miller [EMAIL PROTECTED]
Date: Wed, 06 Dec 2006 23:37:49 -0800 (PST)
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Wed, 6 Dec 2006 20:35:37 +0900
Sorry, I mixed up changes in the patches. I described that [4/7] will add
IPv6 over IPv4 IPsec tunnel. However I send a patch for
1 - 100 of 111 matches
Mail list logo
