Re: [Patch][IPv6] Fix wrong routing mechanism for Link Local IPv6 packets
In article [EMAIL PROTECTED] (at Tue, 30 Jan 2007 16:55:12 +0900), Wei Dong [EMAIL PROTECTED] says: Hello, Mr yoshfuji Take ping6 for example. Asumming there is a router which has 2 NICs. eth0 on router has ipv6 addr fe80::20c:29ff:fe24:fa0a, eth1 on router has ipv6 addr fe80::20c:29ff:fe24:fa14. Also there is a host connected to router's eth0, and the host's ipv6 addr is fe80::200:ff:fe00:100. We ping6 : I still need more precise figure. Please draw complete box for the 2-3 boxes (pinger, router (and the destination)), link(s) and interfaces. +-+ |Router | +---+-+---+ eth0| |eth1 | | eth0| +---+-+ |Host1| +-+ Host1 eth0: fe80: Router eth0: fe80: Router eth1: fe80:... Or, something like that I think you may use other tool such as tgif etc. --yoshfuji - 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
Re: sky2 problems on Intel Mac Mini
On Mon, Jan 29, 2007 at 04:01:17PM -0800, Stephen Hemminger wrote: On Mon, 29 Jan 2007 23:57:32 + Chris Lightfoot [EMAIL PROTECTED] wrote: [ please cc: me on any reply ] I'm seeing lots of problems with the sky2 driver on Mac Minis. Based on the suggestions in, http://www.mail-archive.com/netdev@vger.kernel.org/msg28221.html I am running stock 2.6.19 + the patches from the mactel-linux.org site to get the kernel booting on the Apple hardware; none of these touches the sky2 code. The module is installed with disable_msi=1 and idle_timeout=10; the chip version is, Yukon-EC (0xb6) rev 2 The crashes we're seeing at the moment show (with debug=16) lots and lots of transmits being queued up and never being completed, even with the timeout switched on. For instance, (this is on a machine running NFS root and vlans) Is this NFS over UDP? yes. but we see similar problems on machines which aren't doing lots of UDP traffic. -- Man: How was your flight, sir? Prince Philip: Have you ever been on an aeroplane? Man: Yes. Prince Philip: Well, it was like that. - 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
Re: TCP_DEFER_ACCEPT brokenness?
ping. i received no response on this one..
thanks
-dean
On Sat, 30 Dec 2006, dean gaudet wrote:
hi... i'm having troubles matching up the tcp(7) man page description of
TCP_DEFER_ACCEPT versus some comments in the kernel (2.6.20-rc2) versus
how the kernel actually acts.
the man page says this:
TCP_DEFER_ACCEPT
Allows a listener to be awakened only when data arrives on
the socket. Takes an integer value (seconds), this can bound
the maximum number of attempts TCP will make to complete the
connection. This option should not be used in code intended to
be portable.
which is a bit confusing because it talks both about seconds and
attempts. (and doesn't mention what happens when the timeout finishes
-- i could see dropping the socket or passing it to userland anyhow as
possibilities... but in fact the socket is dropped).
the setsockopt code in tcp.c does this:
case TCP_DEFER_ACCEPT:
icsk-icsk_accept_queue.rskq_defer_accept = 0;
if (val 0) {
/* Translate value in seconds to number of
* retransmits */
while (icsk-icsk_accept_queue.rskq_defer_accept 32
val ((TCP_TIMEOUT_INIT / HZ)
icsk-icsk_accept_queue.rskq_defer_accept))
icsk-icsk_accept_queue.rskq_defer_accept++;
icsk-icsk_accept_queue.rskq_defer_accept++;
}
break;
so at least the comment agrees with the man page -- however the code
doesn't... the code finds the least n such that val (3n)... but these
are timeouts and they're cumulative -- it would be more appropriate to
search for least n such that
val (30) + (31) + (32) + ... + (3n)
but that's not all that's wrong... i'm not sure why, for val == 1 it
computes n=0 correctly (verified with getsockopt) but then it defers
way more timeouts than 2. here's a tcpdump example where the timeout
was set to 1:
1167532741.446027 IP 127.0.0.1.56733 127.0.0.1.53846: S
1792609127:1792609127(0) win 32792 mss 16396,sackOK,timestamp 249615
0,nop,wscale 5
1167532741.446899 IP 127.0.0.1.53846 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768 mss 16396,sackOK,timestamp
249616 249615,nop,wscale 5
1167532741.446122 IP 127.0.0.1.56733 127.0.0.1.53846: . ack 1 win 1025
nop,nop,timestamp 249616 249616
1167532745.249902 IP 127.0.0.1.53846 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768 mss 16396,sackOK,timestamp
250566 249616,nop,wscale 5
1167532745.249912 IP 127.0.0.1.56733 127.0.0.1.53846: . ack 1 win 1025
nop,nop,timestamp 250566 250566,nop,nop,sack 1 {0:1}
1167532751.648046 IP 127.0.0.1.53846 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768 mss 16396,sackOK,timestamp
252166 250566,nop,wscale 5
1167532751.648058 IP 127.0.0.1.56733 127.0.0.1.53846: . ack 1 win 1025
nop,nop,timestamp 252166 252166,nop,nop,sack 1 {0:1}
1167532764.448456 IP 127.0.0.1.53846 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768 mss 16396,sackOK,timestamp
255366 252166,nop,wscale 5
1167532764.448473 IP 127.0.0.1.56733 127.0.0.1.53846: . ack 1 win 1025
nop,nop,timestamp 255366 255366,nop,nop,sack 1 {0:1}
1167532788.452409 IP 127.0.0.1.53846 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768 mss 16396,sackOK,timestamp
261366 255366,nop,wscale 5
1167532788.452430 IP 127.0.0.1.56733 127.0.0.1.53846: . ack 1 win 1025
nop,nop,timestamp 261366 261366,nop,nop,sack 1 {0:1}
1167532836.453520 IP 127.0.0.1.53846 127.0.0.1.56733: S
1785169552:1785169552(0) ack 1792609128 win 32768 mss 16396,sackOK,timestamp
273366 261366,nop,wscale 5
1167532836.453539 IP 127.0.0.1.56733 127.0.0.1.53846: . ack 1 win 1025
nop,nop,timestamp 273366 273366,nop,nop,sack 1 {0:1}
now honestly i don't mind if 1s works correctly (because
apache 2.2.x is broken and sets TCP_DEFER_ACCEPT to 1 ... see
http://issues.apache.org/bugzilla/show_bug.cgi?id=41270).
but even if i use more reasonable timeouts like 30s it doesn't
behave as expected based on the docs.
not sure which way this should be resolved -- or how long the code has
been like this... perhaps the current behaviour should just become the
documented behaviour (whatever the current behaviour is :).
-dean
-
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
-
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
Re: sky2 problems on Intel Mac Mini
On Tue, Jan 30, 2007 at 08:39:19 +, Chris Lightfoot wrote: On Mon, Jan 29, 2007 at 04:01:17PM -0800, Stephen Hemminger wrote: On Mon, 29 Jan 2007 23:57:32 + Chris Lightfoot [EMAIL PROTECTED] wrote: [ please cc: me on any reply ] I'm seeing lots of problems with the sky2 driver on Mac Minis. Based on the suggestions in, http://www.mail-archive.com/netdev@vger.kernel.org/msg28221.html I am running stock 2.6.19 + the patches from the mactel-linux.org site to get the kernel booting on the Apple hardware; none of these touches the sky2 code. The module is installed with disable_msi=1 and idle_timeout=10; the chip version is, Yukon-EC (0xb6) rev 2 The crashes we're seeing at the moment show (with debug=16) lots and lots of transmits being queued up and never being completed, even with the timeout switched on. For instance, (this is on a machine running NFS root and vlans) Is this NFS over UDP? yes. but we see similar problems on machines which aren't doing lots of UDP traffic. Hi, I found my machine with a freezed desktop tomorrow morning. I don't use anything UDP specific, just a lot of TCP traffic. I the machine is a Mac mini Core Duo running 2.6.20-rc6 without special mactel-linux.org patches except for the IR remote driver. The kernel log looks similar. I don't use MSI. However, I don't get this several times a day. IIRC this was the first time that I saw this. Regards, Tino sky2_freeze.txt.bz2 Description: Binary data
Re: [PATCH] PA Semi PWRficient Ethernet driver
On Mon, Jan 29, 2007 at 12:08:52AM -0600, Olof Johansson wrote: Driver for the PA Semi PWRficient on-chip Ethernet (1/10G) Basic enablement, will be complemented with performance enhancements over time. PHY support will be added as well. This patch still uses the numerical PCI vendor id, it will be replaced when the pci_ids.h change goes in (same as the other currently pending drivers). From a quick glance over the code you don't seem to handle memory allocation erros at all, that needs some fixing. - 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
Re: [PATCH] PA Semi PWRficient Ethernet driver
On Mon, Jan 29, 2007 at 07:41:16PM -0600, Olof Johansson wrote: Maybe a bit of introduction could be useful (also regarding the pci_map/alloc comments below). Our devices are on-chip, and while they're not on a PCI(e) bus internally, they do have config headers and will show up as devices on a pseudo-bus (the root one, in fact). Also, while the driver could go through the IOMMU layers, there's no real use in doing so at this time. sorry, but bypassing this is not what what we want in drivers at all. In case you have an iommu and don't want it on the root bus chose the noop dma implementation for this bus, which is easily possible on powerpc. - 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
Re: [RFC PATCH 1/6] invisible network devices
On Mon, Jan 29, 2007 at 10:28:14AM -0800, Stephen Hemminger wrote: Maybe code would be cleaner if you just could do: register_netdevice(mydev); cloak_netdevice(mydev); And cloak_netdevice() just removed the network device from the name table. I would rather keep it with a real ifindex and in the device list, so that if the interface is miss used or the device is referenced by other devices, we don't see unexpected surprises like oops. I don't think first publishing it and then hiding it is a good idea, but I agreed that it should at least have a valid ifindex. - 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
Re: [RFC] Alternative hidden netwirk device interface
On Mon, Jan 29, 2007 at 02:09:58PM -0800, Stephen Hemminger wrote: Change to allow register_netdevice() to be called with a blank name. If name is blank, it is not put in name hash list, and doesn't show up in /sys or /proc That sounds even better indeed! Of course register_netdevice should grow a detailed explanation of this behaviour in the kdoc comment. - 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
igmp: possible NULL dereference after GFP_ATOMIC allocation?
igmpv3_newpack() uses alloc_skb() with GFP_ATOMIC.
It fails, igmpv3_newpack() returns NULL.
add_grhead(), sees NULL, returns NULL.
At one place add_grhead() return value fed into skb_put() which
dereferences it.
net/ipv4/igmp.c:
454 if (first) {
455 skb = add_grhead(skb, pmc, type, pgr);
456 first = 0;
457 }
458 psrc = (u32 *)skb_put(skb, sizeof(u32));
-
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
Re: igmp: possible NULL dereference after GFP_ATOMIC allocation?
Alexey, I think you're correct-- looks like it needs: if (!skb) return NULL; just before the skb_put(), since an allocation (and failure) could occur in either the igmpv3_newpack() call or in add_grhead(). Also, similar code in net/ipv6/mcast..c. Will you be submitting the patch? +-DLS - 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
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
On Tue, Jan 30, 2007 at 07:25:36AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: In article [EMAIL PROTECTED] (at Mon, 29 Jan 2007 16:30:13 -0500), Neil Horman [EMAIL PROTECTED] says: Quick reality check here. In thinking about how best to go about this redirection of frames to the default router, based on Dave M.s input, I think that the best solution would be in ndisc_send_ns. What I was thinking was that in ndisc_send_ns, we already detect if a source address is optimistic and squash the transmission of the frame there. What if in addition to that supression, we : Well...I think it is okay if sending NS is deferred (or omit) in ndisc_send_ns() (or in ndisc_solicit(), probably) if the source is Agreed, the code already does this, per the RFC. optimistic address, but... I'm not sure so far if it is appropriate from design POV. The ndisc_send_ns() nor ndisc_solicit() is not about our current neigh state machine, at all. Thats true, but I'm not sure how we can avoid that. I do not think we should copy neighbor information from (one of) default routers, but use temporary neigh entry (or neigh in new state) for such datagrams in stead. We should aware that: Not sure how that is different from what I'm proposing. a neighbor entry that maps a given host on the current subnet to the MAC of the default router, that then gets flushed when DAD completes is temporary, as far as I can see. 1) default router's link-layer address may change. True, but if this changes, all our network connectivity is lost, until the normal neighbor solicitation process completes anyway. 2) we may have more than one default routers. True, but I would think we could select any of them and this would work. Granted, we wouldn't use all the default routers in the table as we would with routed frames, but I'm not sure how we avoid that. 3) the default router's link-layer may be invalidated. yes, but this would be bad for the same reason as (1) Anyway, I'm start thinking about CONFIG_IPV6_OPTIMISTIC_DAD to make sure the new code path will not break anything else... Agreed, I'll add in the config option with my next patch. --yoshfuji - 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
Re: [PATCH 4/6] d80211: don't display name of invisible network device
On Mon, 2007-01-29 at 18:48 +0100, Jiri Benc wrote: Invisible master interface does not have meaningful name. Display the wiphy identifier in kernel messages instead. Also, remove the allocation of master interface name as it is purposeless now. If the master netdev no longer has a name, how can you still use `tc' on it? johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 4/6] d80211: don't display name of invisible network device
2007/1/30, Johannes Berg [EMAIL PROTECTED]: On Mon, 2007-01-29 at 18:48 +0100, Jiri Benc wrote: Invisible master interface does not have meaningful name. Display the wiphy identifier in kernel messages instead. Also, remove the allocation of master interface name as it is purposeless now. If the master netdev no longer has a name, how can you still use `tc' on it? I hope you can't, because that was recently proven to be able to subtly break the stack: http://www.mail-archive.com/netdev@vger.kernel.org/msg29219.html Jan - 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
Re: [PATCH -FIX] e100: fix irq leak on suspend/resume
Auke Kok wrote: e100: fix irq leak on suspend/resume From: Frederik Deweerdt [EMAIL PROTECTED] The e100_resume() function should be calling netif_device_detach and free_irq. This fixes multiple irq's being allocated after resume. Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] applied - 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
Re: igmp: possible NULL dereference after GFP_ATOMIC allocation?
On Tue, Jan 30, 2007 at 03:34:18AM -0800, David Stevens wrote:
I think you're correct-- looks like it needs:
if (!skb)
return NULL;
just before the skb_put(), since an allocation (and failure)
could occur in either the igmpv3_newpack() call or in add_grhead().
Also, similar code in net/ipv6/mcast..c.
Will you be submitting the patch?
One box here can semi-reliably reproduce oops which is attributed to
these allocation failures. I'll tell if patch works or not soon.
BUG: unable to handle kernel NULL pointer dereference at virtual address
0064
EIP is at add_grec+0x22b/0x372
eax: ebx: ecx: f567cb20 edx: f567cb20
esi: e91ad540 edi: 0001 ebp: esp: c0787f54
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, veid: 0, ti=c0787000 task=c0670be0 task.ti=c073e000)
Stack: c0787f80 0001 0005 e08a8920 c930a800 e08a892c
e08a8920 e2000ea0 0005
c05f1510 0001 c0678580 c07fbb00 0100 c05f13ac
Call Trace:
[c05f1510] igmp_ifc_timer_expire+0x164/0x1db
[c042cd17] run_timer_softirq+0x116/0x18d
[c0427ea8] __do_softirq+0x84/0x109
[c0406234] do_softirq+0x55/0xad
===
Code: fa ff ff 89 c3 c7 44 24 1c 00 00 00 00 eb 04 85 ff 74 18 8b 4c 24 08 8d
44 24 2c 8b 54 24 0c 89 04 24 89 d8 e8 66 fc ff ff 89 c3 83 7b 64 00 8b bb a0
00 00 00 74 0b 0f 0b 66 b8 5a 03 b8 52 e9
EIP: [c05f1265] add_grec+0x22b/0x372 SS:ESP 0068:c0787f54
Kernel panic - not syncing: Fatal exception in interrupt
-
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
Re: [Fwd: Re: wan/pc300 bug found]
Hi, Jeff Garzik [EMAIL PROTECTED] writes: I have a driver for PC300/RSV (dual V.35 + V.24) for years. I'm told it works with X.21 version too. If someone has a spare T1/E1 card (non-returnable donation only) I can try to add support as well. T1/E1 is too complicated to maintain without the actual hardware. Perhaps we should add my driver to the tree, mark the old one as obsolete and look for angry reports from T1/E1 users? No objections... Great. I'm not marking the original pc300 driver as obsolete - should I? It supports (at least theoretically) multi line PPP and PC300 T1/E1, my drivers don't. -- Krzysztof Halasa - 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
PC300too alternative WAN driver
The attached patch adds an alternative driver pc300too for PCI WAN
cards PC300/RSV and PC300/X21 made by Cyclades Corp. (now Avocent Corp).
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
index 21f76f5..f07aec3 100644
--- a/drivers/net/wan/Kconfig
+++ b/drivers/net/wan/Kconfig
@@ -235,6 +235,19 @@ comment Cyclades-PC300 MLPPP support is disabled.
comment Refer to the file README.mlppp, provided by PC300 package.
depends on WAN HDLC PC300 (PPP=n || !PPP_MULTILINK ||
PPP_SYNC_TTY=n || !HDLC_PPP)
+config PC300TOO
+ tristate Cyclades PC300 RSV/X21 alternative support
+ depends on HDLC PCI
+ help
+ Alternative driver for PC300 RSV/X21 PCI cards made by
+ Cyclades, Inc. If you have such a card, say Y here and see
+ http://www.kernel.org/pub/linux/utils/net/hdlc/.
+
+ To compile this as a module, choose M here: the module
+ will be called pc300too.
+
+ If unsure, say N here.
+
config N2
tristate SDL RISCom/N2 support
depends on HDLC ISA
diff --git a/drivers/net/wan/Makefile b/drivers/net/wan/Makefile
index 83ec2c8..d61fef3 100644
--- a/drivers/net/wan/Makefile
+++ b/drivers/net/wan/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_N2) += n2.o
obj-$(CONFIG_C101) += c101.o
obj-$(CONFIG_WANXL)+= wanxl.o
obj-$(CONFIG_PCI200SYN)+= pci200syn.o
+obj-$(CONFIG_PC300TOO) += pc300too.o
clean-files := wanxlfw.inc
$(obj)/wanxl.o:$(obj)/wanxlfw.inc
diff --git a/drivers/net/wan/pc300too.c b/drivers/net/wan/pc300too.c
new file mode 100644
index 000..79b2d54
--- /dev/null
+++ b/drivers/net/wan/pc300too.c
@@ -0,0 +1,565 @@
+/*
+ * Cyclades PC300 synchronous serial card driver for Linux
+ *
+ * Copyright (C) 2000-2007 Krzysztof Halasa [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License
+ * as published by the Free Software Foundation.
+ *
+ * For information see http://www.kernel.org/pub/linux/utils/net/hdlc/.
+ *
+ * Sources of information:
+ *Hitachi HD64572 SCA-II User's Manual
+ *Cyclades PC300 Linux driver
+ *
+ * This driver currently supports only PC300/RSV (V.24/V.35) and
+ * PC300/X21 cards.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/sched.h
+#include linux/types.h
+#include linux/fcntl.h
+#include linux/in.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/ioport.h
+#include linux/moduleparam.h
+#include linux/netdevice.h
+#include linux/hdlc.h
+#include linux/pci.h
+#include linux/delay.h
+#include asm/io.h
+
+#include hd64572.h
+
+static const char* version = Cyclades PC300 driver version: 1.17;
+static const char* devname = PC300;
+
+#undef DEBUG_PKT
+#define DEBUG_RINGS
+
+#define PC300_PLX_SIZE 0x80/* PLX control window size (128 B) */
+#define PC300_SCA_SIZE 0x400 /* SCA window size (1 KB) */
+#define ALL_PAGES_ALWAYS_MAPPED
+#define NEED_DETECT_RAM
+#define NEED_SCA_MSCI_INTR
+#define MAX_TX_BUFFERS 10
+
+static int pci_clock_freq = 3300;
+static int use_crystal_clock = 0;
+static unsigned int CLOCK_BASE;
+
+/* Masks to access the init_ctrl PLX register */
+#define PC300_CLKSEL_MASK (0x0004UL)
+#define PC300_CHMEDIA_MASK(port) (0x0020UL ((port) * 3))
+#define PC300_CTYPE_MASK(0x0800UL)
+
+
+enum { PC300_RSV = 1, PC300_X21, PC300_TE }; /* card types */
+
+/*
+ * PLX PCI9050-1 local configuration and shared runtime registers.
+ * This structure can be used to access 9050 registers (memory mapped).
+ */
+typedef struct {
+ u32 loc_addr_range[4]; /* 00-0Ch : Local Address Ranges */
+ u32 loc_rom_range; /* 10h : Local ROM Range */
+ u32 loc_addr_base[4]; /* 14-20h : Local Address Base Addrs */
+ u32 loc_rom_base; /* 24h : Local ROM Base */
+ u32 loc_bus_descr[4]; /* 28-34h : Local Bus Descriptors */
+ u32 rom_bus_descr; /* 38h : ROM Bus Descriptor */
+ u32 cs_base[4]; /* 3C-48h : Chip Select Base Addrs */
+ u32 intr_ctrl_stat; /* 4Ch : Interrupt Control/Status */
+ u32 init_ctrl; /* 50h : EEPROM ctrl, Init Ctrl, etc */
+}plx9050;
+
+
+
+typedef struct port_s {
+ struct net_device *dev;
+ struct card_s *card;
+ spinlock_t lock;/* TX lock */
+ sync_serial_settings settings;
+ int rxpart; /* partial frame received, next frame invalid*/
+ unsigned short encoding;
+ unsigned short parity;
+ unsigned int iface;
+ u16 rxin; /* rx ring buffer 'in' pointer */
+ u16 txin; /* tx ring buffer 'in' and 'last' pointers */
+ u16 txlast;
+ u8 rxs, txs, tmc; /* SCA registers */
+ u8 phy_node;
[PATCH 0/2] NetXen: NetXen 1G/10G Ethernet Driver updates
Hi All, I will be sending NetXen: 1G/10G Ethernet Driver updates in subsequent emails. Thanks, --Amit - 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
[PATCH 1/2] NetXen: Added ethtool support for user level tools
Added ethtool support for user level firmware management utilities.
Signed-off-by: Amit S. Kale [EMAIL PROTECTED]
---
netxen_nic.h | 16 ++-
netxen_nic_ethtool.c | 87 +---
netxen_nic_init.c| 268 ++-
3 files changed, 351 insertions(+), 20 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 59324b1..f188b59 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -63,12 +63,16 @@ #include asm/pgtable.h
#include netxen_nic_hw.h
-#define NETXEN_NIC_BUILD_NO 2
+#define NETXEN_NIC_BUILD_NO 3
#define _NETXEN_NIC_LINUX_MAJOR 3
#define _NETXEN_NIC_LINUX_MINOR 3
#define _NETXEN_NIC_LINUX_SUBVERSION 3
#define NETXEN_NIC_LINUX_VERSIONID 3.3.3 - NETXEN_NIC_BUILD_NO
+#define NUM_FLASH_SECTORS (64)
+#define FLASH_SECTOR_SIZE (64*1024)
+#define FLASH_TOTAL_SIZE (NUM_FLASH_SECTORS*FLASH_SECTOR_SIZE)
+
#define RCV_DESC_RINGSIZE \
(sizeof(struct rcv_desc) * adapter-max_rx_desc_count)
#define STATUS_DESC_RINGSIZE \
@@ -85,6 +89,7 @@ #define NETXEN_NETDEV_STATUS 0x1
#define NETXEN_RCV_PRODUCER_OFFSET 0
#define NETXEN_RCV_PEG_DB_ID 2
#define NETXEN_HOST_DUMMY_DMA_SIZE 1024
+#define FLASH_SUCCESS 0
#define ADDR_IN_WINDOW1(off) \
((off NETXEN_CRB_PCIX_HOST2) (off NETXEN_CRB_MAX)) ? 1 : 0
@@ -1034,6 +1039,15 @@ void netxen_phantom_init(struct netxen_a
void netxen_load_firmware(struct netxen_adapter *adapter);
int netxen_pinit_from_rom(struct netxen_adapter *adapter, int verbose);
int netxen_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp);
+int netxen_rom_fast_read_words(struct netxen_adapter *adapter, int addr,
+ u8 *bytes, size_t size);
+int netxen_rom_fast_write_words(struct netxen_adapter *adapter, int addr,
+ u8 *bytes, size_t size);
+int netxen_flash_unlock(struct netxen_adapter *adapter);
+int netxen_backup_crbinit(struct netxen_adapter *adapter);
+int netxen_flash_erase_secondary(struct netxen_adapter *adapter);
+int netxen_flash_erase_primary(struct netxen_adapter *adapter);
+
int netxen_rom_fast_write(struct netxen_adapter *adapter, int addr, int data);
int netxen_rom_se(struct netxen_adapter *adapter, int addr);
int netxen_do_rom_se(struct netxen_adapter *adapter, int addr);
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c
b/drivers/net/netxen/netxen_nic_ethtool.c
index 3404461..49b3b4c 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -32,6 +32,7 @@
*/
#include linux/types.h
+#include linux/delay.h
#include asm/uaccess.h
#include linux/pci.h
#include asm/io.h
@@ -94,17 +95,7 @@ #define NETXEN_MAX_EEPROM_LEN 1024
static int netxen_nic_get_eeprom_len(struct net_device *dev)
{
- struct netxen_port *port = netdev_priv(dev);
- struct netxen_adapter *adapter = port-adapter;
- int n;
-
- if ((netxen_rom_fast_read(adapter, 0, n) == 0)
-(n NETXEN_ROM_ROUNDUP)) {
- n = ~NETXEN_ROM_ROUNDUP;
- if (n NETXEN_MAX_EEPROM_LEN)
- return n;
- }
- return 0;
+ return FLASH_TOTAL_SIZE;
}
static void
@@ -445,13 +436,78 @@ netxen_nic_get_eeprom(struct net_device
return -EINVAL;
eeprom-magic = (port-pdev)-vendor | ((port-pdev)-device 16);
- for (offset = 0; offset eeprom-len; offset++)
- if (netxen_rom_fast_read
- (adapter, (8 * offset) + 8, (int *)eeprom-data) == -1)
- return -EIO;
+ offset = eeprom-offset;
+
+ if (netxen_rom_fast_read_words
+ (adapter, offset, bytes, eeprom-len) == -1){
+ return -EIO;
+ }
+
return 0;
}
+static int
+netxen_nic_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom,
+ u8 * bytes)
+{
+ struct netxen_port *port = netdev_priv(dev);
+ struct netxen_adapter *adapter = port-adapter;
+ int offset = eeprom-offset;
+ static int first_write = 1;
+ int ret;
+ static int ready_to_flash = 0;
+
+ if(first_write == 1){
+ netxen_flash_unlock(adapter);
+ printk(%s: flash unlocked. \n, netxen_nic_driver_name);
+ if ((ret = netxen_flash_erase_secondary(adapter))
+ != FLASH_SUCCESS) {
+ printk(%s: Flash erase failed.\n,
+ netxen_nic_driver_name);
+ return(ret);
+ }
+ printk(%s: secondary flash erased successfully.\n,
+ netxen_nic_driver_name);
+ first_write = 0;
+ return 0;
+ }
+
+ if(offset == BOOTLD_START){
+ if ((ret = netxen_flash_erase_primary(adapter))
+
Re: [PATCH] PA Semi PWRficient Ethernet driver
On Tue, Jan 30, 2007 at 10:06:49AM +, Christoph Hellwig wrote: On Mon, Jan 29, 2007 at 07:41:16PM -0600, Olof Johansson wrote: Maybe a bit of introduction could be useful (also regarding the pci_map/alloc comments below). Our devices are on-chip, and while they're not on a PCI(e) bus internally, they do have config headers and will show up as devices on a pseudo-bus (the root one, in fact). Also, while the driver could go through the IOMMU layers, there's no real use in doing so at this time. sorry, but bypassing this is not what what we want in drivers at all. In case you have an iommu and don't want it on the root bus chose the noop dma implementation for this bus, which is easily possible on powerpc. Good point, I'll do that instead. -Olof - 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
[PATCH 2/2] NetXen: Firmware crb init changes
NetXen: firmware crb init changes.
Signed-off-by: Amit S. Kale [EMAIL PROTECTED]
---
netxen_nic.h |2 +-
netxen_nic_init.c | 12 +---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index f188b59..9964f56 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -63,7 +63,7 @@ #include asm/pgtable.h
#include netxen_nic_hw.h
-#define NETXEN_NIC_BUILD_NO 3
+#define NETXEN_NIC_BUILD_NO 4
#define _NETXEN_NIC_LINUX_MAJOR 3
#define _NETXEN_NIC_LINUX_MINOR 3
#define _NETXEN_NIC_LINUX_SUBVERSION 3
diff --git a/drivers/net/netxen/netxen_nic_init.c
b/drivers/net/netxen/netxen_nic_init.c
index 069436f..cdbaf1d 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -110,6 +110,7 @@ static void crb_addr_transform_setup(voi
crb_addr_transform(CAM);
crb_addr_transform(C2C1);
crb_addr_transform(C2C0);
+ crb_addr_transform(SMB);
}
int netxen_init_firmware(struct netxen_adapter *adapter)
@@ -803,9 +804,13 @@ int netxen_pinit_from_rom(struct netxen_
}
for (i = 0; i n; i++) {
- off =
- netxen_decode_crb_addr((unsigned long)buf[i].addr) +
- NETXEN_PCI_CRBSPACE;
+ off = netxen_decode_crb_addr((unsigned
long)buf[i].addr);
+ if (off == NETXEN_ADDR_ERROR) {
+ printk(KERN_ERRCRB init value out of range
%lx\n,
+ buf[i].addr);
+ continue;
+ }
+ off += NETXEN_PCI_CRBSPACE;
/* skipping cold reboot MAGIC */
if (off == NETXEN_CAM_RAM(0x1fc))
continue;
@@ -922,6 +927,7 @@ void netxen_phantom_init(struct netxen_a
int loops = 0;
if (!pegtune_val) {
+ val = readl(NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
while (val != PHAN_INITIALIZE_COMPLETE loops 20) {
udelay(100);
schedule();
-
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
[PATCH] IPv6: Fix up some CONFIG typos
Hey-
Noticed some typos in some configurable options while going through the
IPv6 code. Patch attached to clean them up.
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
addrconf.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 171e5b5..7b6cfa9 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3387,7 +3387,7 @@ static void inline ipv6_store_devconf(struct ipv6_devconf
*cnf,
#ifdef CONFIG_IPV6_ROUTER_PREF
array[DEVCONF_ACCEPT_RA_RTR_PREF] = cnf-accept_ra_rtr_pref;
array[DEVCONF_RTR_PROBE_INTERVAL] = cnf-rtr_probe_interval;
-#ifdef CONFIV_IPV6_ROUTE_INFO
+#ifdef CONFIG_IPV6_ROUTE_INFO
array[DEVCONF_ACCEPT_RA_RT_INFO_MAX_PLEN] =
cnf-accept_ra_rt_info_max_plen;
#endif
#endif
@@ -3892,7 +3892,7 @@ static struct addrconf_sysctl_table
.proc_handler = proc_dointvec_jiffies,
.strategy = sysctl_jiffies,
},
-#ifdef CONFIV_IPV6_ROUTE_INFO
+#ifdef CONFIG_IPV6_ROUTE_INFO
{
.ctl_name =
NET_IPV6_ACCEPT_RA_RT_INFO_MAX_PLEN,
.procname = accept_ra_rt_info_max_plen,
-
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
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
In article [EMAIL PROTECTED] (at Tue, 30 Jan 2007 08:02:08 -0500), Neil Horman [EMAIL PROTECTED] says: I do not think we should copy neighbor information from (one of) default routers, but use temporary neigh entry (or neigh in new state) for such datagrams in stead. We should aware that: Not sure how that is different from what I'm proposing. a neighbor entry that maps a given host on the current subnet to the MAC of the default router, that then gets flushed when DAD completes is temporary, as far as I can see. 1) default router's link-layer address may change. True, but if this changes, all our network connectivity is lost, until the normal neighbor solicitation process completes anyway. No, router may update its link-layer address by NA with Override flag set. In that case, we must use new link-layer for subsequent packets from our opportunistic address duing DAD. 2) we may have more than one default routers. True, but I would think we could select any of them and this would work. Granted, we wouldn't use all the default routers in the table as we would with routed frames, but I'm not sure how we avoid that. I mean, if the status of the selected default router has changed or has been deleted, we should try other router, at least. 3) the default router's link-layer may be invalidated. yes, but this would be bad for the same reason as (1) We MUST take this into account. --yoshfuji - 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
Re: sky2 problems on Intel Mac Mini
There are a couple problems here: 1) the transmitter is getting hung. 2) the recovery logic doesn't work. If I can reproduce hang, then maybe the recovery code could be fixable. Let's address the transmitter hang first. The transmitter has multiple stages so it could be either: a) hardware flow control problems look at ethtool -S eth0 statistics, are there flow control packets showing up? b) GMAC or ram buffer issues looking at 'ethtool -d eth0' output can help, but it is a needle in haystack finding these setup errors. The sky2 driver copies most of the stuff from vendor version of sk98lin, but if sk98lin works and sky2 doesn't then comparing register settings can give hints. c) DMA problems For some problems, I have had luck adding a /proc interface and dumping the transmit ring after a hang. Looking at the last control block that hung can help. This found the case where IPV6 TSO was leaking through. d) checksum problems Turning off tx scatter/gather forces non fragmented skb's. This hurts performance, but can tell if the problem is with fragment code. Turning off tx checksum turns off scatter/gather, checksumming and TSO. e) possible alignment and flow control interaction Because the receive DMA engine has hardware bugs and requires alignment or it doesn't work with flow control. I still wonder if there are alignment bugs on Tx with flow control. f) other driver bug To save time, I'll go get a new Mac Mini and try and clone this setup. Could you send me a full kernel config (and other setup information like filesystem type, distro etc). -- I assume this is just the same problem exhibiting on a kernel with soft lockups detection enabled? Hopefully I should be able to actually log into one of these machines over an alternate connection next time the problem recurs, at which point I should be able to get ethtool -d output. Anything else I should do at that point? Any suggestions for what to do next to chase this problem down? I haven't yet tried the sk98lin driver on this hardware; is that still worth doing? Are there any useful tests we should try? Unfortunately, though these crashes happen pretty frequently (several times per day typically), I don't have a test case to reproduce one; however, if it'd be useful, I can probably get a pcap trace of the period immediately before the interface falls over using port mirroring on the switch to which the machines are connected. Is that likely to be informative? The vendor driver does some slightly different setup, but it also does a hardware reset when inactive (every 10ms). -- Stephen Hemminger [EMAIL PROTECTED] - 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
Re: [PATCH] PA Semi PWRficient Ethernet driver
On Mon, Jan 29, 2007 at 09:34:06PM -0500, Jeff Garzik wrote:
Olof Johansson wrote:
Right now it's guaranteed that the interrupts will not be shared. They're
fixed for the on-chip devices, and no other driver should be binding to
the same channels (and thus irqs).
If it changes in the future, the driver would need other rework as well.
Nonetheless, it is far more sane to check for work, and return if no
work. Who knows if the hardware will signal an interrupt early or late.
Easy enough. Added in the next version.
+static struct pci_driver pasemi_mac_driver = {
+ .name = pasemi_mac,
+ .id_table = pasemi_mac_pci_tbl,
+ .probe = pasemi_mac_probe,
Don't you need a remove routine?
No hotplug support at this time, so I didn't see any use in providing one.
module remove.
Oh, good point. Added in the next version to be posted.
Thanks,
-Olof
-
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
buggy IFB driver change
Jeff, please revert: 0c0b3ae68ec93b1db5c637d294647d1cca0df763
It's wrong. We had a lengthy analysis of this piece of code
several months ago, and it is correct.
Consider, if we run the loop and we get an error
the following happens:
1) attempt of ifb_init_one(i) fails, therefore we should
not try to ifb_free_one() on i since it failed
2) the loop iteration first increments i, then it
check for error
Therefore we must decrement i twice before the first
free during the cleanup. One to undo the for() loop
increment, and one to skip the ifb_init_one() case which
failed.
commit 0c0b3ae68ec93b1db5c637d294647d1cca0df763
Author: Mariusz Kozlowski [EMAIL PROTECTED]
Date: Sat Jan 27 00:00:01 2007 -0800
net: ifb error path loop fix
On error we should start freeing resources at [i-1] not [i-2].
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index ca2b21f..c4ca7c9 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -271,8 +271,7 @@ static int __init ifb_init_module(void)
for (i = 0; i numifbs !err; i++)
err = ifb_init_one(i);
if (err) {
- i--;
- while (--i = 0)
+ while (i--)
ifb_free_one(i);
}
-
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
Re: [PATCH 1/2] NetXen: Added ethtool support for user level tools
Amit S. Kale [EMAIL PROTECTED] :
[...]
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c
b/drivers/net/netxen/netxen_nic_ethtool.c
index 3404461..49b3b4c 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
[...]
static void
@@ -445,13 +436,78 @@ netxen_nic_get_eeprom(struct net_device
return -EINVAL;
eeprom-magic = (port-pdev)-vendor | ((port-pdev)-device 16);
- for (offset = 0; offset eeprom-len; offset++)
- if (netxen_rom_fast_read
- (adapter, (8 * offset) + 8, (int *)eeprom-data) == -1)
- return -EIO;
+ offset = eeprom-offset;
+
+ if (netxen_rom_fast_read_words
+ (adapter, offset, bytes, eeprom-len) == -1){
+ return -EIO;
+ }
At your option, you can:
rc = netxen_rom_fast_read_words(adapter, offset, bytes, eeprom-len);
if (rc == -1)
return -EIO;
or directly return a sensible error status code from
netxen_rom_fast_read_words.
return 0;
}
+static int
+netxen_nic_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom,
+ u8 * bytes)
+{
+ struct netxen_port *port = netdev_priv(dev);
+ struct netxen_adapter *adapter = port-adapter;
+ int offset = eeprom-offset;
+ static int first_write = 1;
You could probably revert the operation and save an initialization.
+ int ret;
+ static int ready_to_flash = 0;
+
+ if(first_write == 1){
^^^^
+ netxen_flash_unlock(adapter);
+ printk(%s: flash unlocked. \n, netxen_nic_driver_name);
Missing KERN_XYZ
+ if ((ret = netxen_flash_erase_secondary(adapter))
+ != FLASH_SUCCESS) {
ret = netxen_flash_erase_secondary(adapter);
if (ret != FLASH_SUCCESS) {
...
+ printk(%s: Flash erase failed.\n,
Missing KERN_XYZ
+ netxen_nic_driver_name);
+ return(ret);
return is not a function
+ }
+ printk(%s: secondary flash erased successfully.\n,
+ netxen_nic_driver_name);
Missing KERN_XYZ
+ first_write = 0;
+ return 0;
+ }
+
+ if(offset == BOOTLD_START){
+ if ((ret = netxen_flash_erase_primary(adapter))
+ != FLASH_SUCCESS) {
+ printk(%s: Flash erase failed.\n,
Missing KERN_XYZ
+ netxen_nic_driver_name);
+ return ret;
+ }
+ if((ret = netxen_rom_se(adapter, USER_START)) != FLASH_SUCCESS)
^^
+ return ret;
+ if((ret = netxen_rom_se(adapter, FIXED_START)) != FLASH_SUCCESS)
^^
+ return ret;
+ printk(%s: primary flash erased successfully\n,
Missing KERN_XYZ
+ netxen_nic_driver_name);
+ udelay (500);
+
+ if((ret = netxen_backup_crbinit(adapter)) != FLASH_SUCCESS){
^^
+ printk(%s: CRBinit backup failed.\n,
Missing KERN_XYZ
+ netxen_nic_driver_name);
+ return ret;
+ }
+ printk(%s: CRBinit backup done.\n, netxen_nic_driver_name);
Missing KERN_XYZ
+ ready_to_flash = 1;
+ udelay (500);
+ }
+
+ if(!ready_to_flash){
^^
+ printk(%s: Invalid write sequence, returning...\n,
Missing KERN_XYZ
+ netxen_nic_driver_name);
+ return -EINVAL;
ready_to_flash could have returned it.
+ }
+
+ udelay (500);
+
+ return netxen_rom_fast_write_words(adapter, offset, bytes, eeprom-len);
+}
+
static void
netxen_nic_get_ringparam(struct net_device *dev, struct ethtool_ringparam
*ring)
{
@@ -721,6 +777,7 @@ struct ethtool_ops netxen_nic_ethtool_op
.get_link = netxen_nic_get_link,
.get_eeprom_len = netxen_nic_get_eeprom_len,
.get_eeprom = netxen_nic_get_eeprom,
+ .set_eeprom = netxen_nic_set_eeprom,
.get_ringparam = netxen_nic_get_ringparam,
.get_pauseparam = netxen_nic_get_pauseparam,
.set_pauseparam = netxen_nic_set_pauseparam,
diff --git a/drivers/net/netxen/netxen_nic_init.c
b/drivers/net/netxen/netxen_nic_init.c
index c3e41f3..069436f 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -391,6 +391,7 @@ static inline int do_rom_fast_write(stru
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ABYTE_CNT, 3);
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_INSTR_OPCODE,
M25P_INSTR_PP);
+ udelay(100);
if (netxen_wait_rom_done(adapter)) {
New list for wireless dev discussions
At the wireless summit in London, we collectively decided to move day-to-day wireless development discussions to our own list. I am hosting a list for this purpose: http://lists.tuxdriver.org/mailman/listinfo/wireless If you are interested in Linux wireless development, please subscribe to the list. Thanks, John -- John W. Linville [EMAIL PROTECTED] - 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
Re: [PATCH] PA Semi PWRficient Ethernet driver
Olof Johansson [EMAIL PROTECTED] : On Mon, Jan 29, 2007 at 11:35:06PM +0100, Francois Romieu wrote: [...] - The driver does not contain a single SMP locking instruction but http://www.pasemi.com claims the platform to be multicore. Is the driver really designed to be lockless ? Unless I misunderstood something, NAPI drivers that don't set NETIF_F_LLTX will have all locking taken care of by higher layers, no? It is not necessarily _that_ simple (it would be cool though :o) ). For instance, what does prevent pasemi_mac_clean_tx() to be issued from IRQ context (pasemi_mac_tx_intr) and from the xmit handler (pasemi_mac_start_tx) at the same time ? [...] unsigned int is supposed to save some cycles on ppc. Who told you that? That's not true. Jon D Mason [EMAIL PROTECTED] on 25/08/2004 about ppc64 (not ppc, sorry). [...] +#define DESCR(ring, i) ((ring)-desc[i % ((ring)-count)]) +#define BUFF(ring, i) ((ring)-buffers[i % ((ring)-count)]) +#define INFO(ring, i) ((ring)-desc_info[i % ((ring)-count)]) A bit ugly/obfuscating/name clash prone imvho. Use local variables ? I'm open for suggestions here, not sure how local variables will help though? struct pas_dma_xct_descr *desc = ring-desc[i % ring-count]; -- Ueimor - 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
Re: buggy IFB driver change
David Miller wrote: Jeff, please revert: 0c0b3ae68ec93b1db5c637d294647d1cca0df763 It's wrong. We had a lengthy analysis of this piece of code several months ago, and it is correct. Consider, if we run the loop and we get an error the following happens: 1) attempt of ifb_init_one(i) fails, therefore we should not try to ifb_free_one() on i since it failed 2) the loop iteration first increments i, then it check for error Therefore we must decrement i twice before the first free during the cleanup. One to undo the for() loop increment, and one to skip the ifb_init_one() case which failed. commit 0c0b3ae68ec93b1db5c637d294647d1cca0df763 Author: Mariusz Kozlowski [EMAIL PROTECTED] Andrew and I both missed that thread, sorry. I'm about to crash, can you or Linus handle the correction? Jeff - 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
Re: buggy IFB driver change
From: Jeff Garzik [EMAIL PROTECTED] Date: Tue, 30 Jan 2007 16:52:27 -0500 David Miller wrote: Jeff, please revert: 0c0b3ae68ec93b1db5c637d294647d1cca0df763 It's wrong. We had a lengthy analysis of this piece of code several months ago, and it is correct. Consider, if we run the loop and we get an error the following happens: 1) attempt of ifb_init_one(i) fails, therefore we should not try to ifb_free_one() on i since it failed 2) the loop iteration first increments i, then it check for error Therefore we must decrement i twice before the first free during the cleanup. One to undo the for() loop increment, and one to skip the ifb_init_one() case which failed. commit 0c0b3ae68ec93b1db5c637d294647d1cca0df763 Author: Mariusz Kozlowski [EMAIL PROTECTED] Andrew and I both missed that thread, sorry. I'm about to crash, can you or Linus handle the correction? Sure. - 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
Re: buggy IFB driver change
On Tue, 30 Jan 2007, Jeff Garzik wrote: I'm about to crash, can you or Linus handle the correction? Reverted, pushed out. Davem, if you have any other issues, just push me any fixes. I'm going to do a final -rc7 today (way too many changes for me to be happy releasing a 2.6.20 without a new -rc after all), and hope for the final 2.6.20 by the end of this week. Sounds like a plan? Linus - 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
Re: buggy IFB driver change
From: Linus Torvalds [EMAIL PROTECTED] Date: Tue, 30 Jan 2007 14:13:14 -0800 (PST) On Tue, 30 Jan 2007, Jeff Garzik wrote: I'm about to crash, can you or Linus handle the correction? Reverted, pushed out. Davem, if you have any other issues, just push me any fixes. I'm going to do a final -rc7 today (way too many changes for me to be happy releasing a 2.6.20 without a new -rc after all), and hope for the final 2.6.20 by the end of this week. Sounds like a plan? That works for me, I have 3 small netfilter fixes to review (one is a nasty divide by zero case) and one potential TCP fix. I'll take care of those right now and push. - 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
Re: TCP_DEFER_ACCEPT brokenness?
Hello, On Tue, 30 Jan 2007, dean gaudet wrote: which is a bit confusing because it talks both about seconds and attempts. (and doesn't mention what happens when the timeout finishes -- i could see dropping the socket or passing it to userland anyhow as possibilities... but in fact the socket is dropped). My understanding about SYN-ACKs is: - there is always one SYN+ACK and at least one retransmission (min 3+6 secs period to accept ACK) - TCP_SYNCNT (or tcp_synack_retries) define the number of retransmissions, this is a minimum that TCP_DEFER_ACCEPT can not reduce (due to the 'req-retrans thresh' check). It can only extend it after the ACK is received. - TCP_DEFER_ACCEPT defines seconds (total time) to wait for ACK plus first data Hint: one option is that you can treat TCP_DEFER_ACCEPT as flag, set it to 1 and then tune TCP_SYNCNT to cover the max desired period to wait for data. Regards -- Julian Anastasov [EMAIL PROTECTED] - 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
Re: [PATCH] IPv6: Fix up some CONFIG typos
From: Neil Horman [EMAIL PROTECTED] Date: Tue, 30 Jan 2007 11:04:11 -0500 Hey- Noticed some typos in some configurable options while going through the IPv6 code. Patch attached to clean them up. Thanks Regards Neil Signed-off-by: Neil Horman [EMAIL PROTECTED] Good spotting Neil, patch applied, thanks. - 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
Re: spidernet: add improved phy support in sungem_phy.c
On Sat, Jan 27, 2007 at 12:38:09AM +0100, Francois Romieu wrote:
Jens Osterkamp [EMAIL PROTECTED] :
Index: linux-2.6.20-rc5/drivers/net/sungem_phy.c
===
--- linux-2.6.20-rc5.orig/drivers/net/sungem_phy.c
+++ linux-2.6.20-rc5/drivers/net/sungem_phy.c
@@ -311,6 +311,107 @@ static int bcm5411_init(struct mii_phy*
[...]
+ if ( (phy_reg 0x0020) 5 ) {
Shifting to the right by 5 bits has no effect on the result
of this conditional. Either the bit is set, or its not.
There is no need to shift.
+ if ( (phy_reg 0x0020) 7 ) {
The result here will always be zero, since the bit,
if set, will be shifted off the end. Bits on the lef
are padded with zero. Ergo, this is a bug.
--linas
-
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
[PATCH 1/1] [SCTP]: Force update of the rto when processing HB-ACK
[SCTP]: Force update of the rto when processing HB-ACK When processing a HEARTBEAT-ACK it's possible that the transport rto timers will not be updated because a prior T3-RTX processing would have cleared the rto_pending flag on the transport. However, if we received a valid HEARTBEAT-ACK, we want to force update the rto variables, so re-set the rto_pending flag before calling sctp_transport_update_rto(). Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] --- net/sctp/sm_sideeffect.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c index 8bd3097..25c0277 100644 --- a/net/sctp/sm_sideeffect.c +++ b/net/sctp/sm_sideeffect.c @@ -621,7 +621,13 @@ static void sctp_cmd_transport_on(sctp_cmd_seq_t *cmds, /* The receiver of the HEARTBEAT ACK should also perform an * RTT measurement for that destination transport address * using the time value carried in the HEARTBEAT ACK chunk. +* If the transport's rto_pending variable has been cleared, +* it was most likely due to a retransmit. However, we want +* to re-enable it to properly update the rto. */ + if (t-rto_pending == 0) + t-rto_pending = 1; + hbinfo = (sctp_sender_hb_info_t *) chunk-skb-data; sctp_transport_update_rto(t, (jiffies - hbinfo-sent_at)); - 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
Re: [patch]IPv6:fix BUG of ndisc_send_redirect()
From: lyw [EMAIL PROTECTED] Date: Mon, 29 Jan 2007 18:16:36 +0800 Mr David: I have submitted a patch to fix the ndisc_send_resirect(), and this patch has been agreed by Mr yoshifuji. But you have not applied yet. The following is Mr yoshifuji's reply, and I submitted the patch again. I've applied your patch, thanks for reminding me. - 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
Re: [PATCH 1/1] [SCTP]: Force update of the rto when processing HB-ACK
From: Sridhar Samudrala [EMAIL PROTECTED] Date: Tue, 30 Jan 2007 14:32:51 -0800 [SCTP]: Force update of the rto when processing HB-ACK When processing a HEARTBEAT-ACK it's possible that the transport rto timers will not be updated because a prior T3-RTX processing would have cleared the rto_pending flag on the transport. However, if we received a valid HEARTBEAT-ACK, we want to force update the rto variables, so re-set the rto_pending flag before calling sctp_transport_update_rto(). Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] I'll apply this, thanks Sridhar. - 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
Re: New list for wireless dev discussions
John W. Linville wrote: At the wireless summit in London, we collectively decided to move day-to-day wireless development discussions to our own list. I am hosting a list for this purpose: http://lists.tuxdriver.org/mailman/listinfo/wireless If you are interested in Linux wireless development, please subscribe to the list. Why move from vger? It seems much more sane to get [EMAIL PROTECTED] to create [EMAIL PROTECTED] list. Jeff - 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
Re: New list for wireless dev discussions
From: Jeff Garzik [EMAIL PROTECTED] Date: Tue, 30 Jan 2007 17:36:04 -0500 John W. Linville wrote: At the wireless summit in London, we collectively decided to move day-to-day wireless development discussions to our own list. I am hosting a list for this purpose: http://lists.tuxdriver.org/mailman/listinfo/wireless If you are interested in Linux wireless development, please subscribe to the list. Why move from vger? It seems much more sane to get [EMAIL PROTECTED] to create [EMAIL PROTECTED] list. And we are happy to do so :-) Just let me know. - 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
Re: [PATCH 2.6.20-rc6 1/2] ehea: Fixed wrong jumbo frames status query
Thomas Klein wrote: This patch fixes the wrong query and logging of the per interface jumbo frames enabled/disabled status. Signed-off-by: Thomas Klein [EMAIL PROTECTED] applied 1-2 - 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
Re: [PATCH 2.6.20-rc5 1/4] atl1: unconditionally enable MSI
Jay Cliburn wrote:
From: Luca Tettamanti [EMAIL PROTECTED]
Unconditionally enable MSI in atl1 driver. Also remove some useless
#ifdef since pci_{en,dis}able_msi() are no-op when MSI support is not
configured in.
Signed-off-by: Luca Tettamanti [EMAIL PROTECTED]
Signed-off-by: Jay Cliburn [EMAIL PROTECTED]
applied patches 1-4 to #atl1
The only remaining problem with your patches is that they added trailing
whitespace:
[EMAIL PROTECTED] netdev-2.6]$ git-am --signoff --utf8 /g/tmp/mbox
Applying 'atl1: unconditionally enable MSI'
Adds trailing whitespace.
.dotest/patch:44:
warning: 1 line adds trailing whitespaces.
Wrote tree dc738e9c0b8becc628dc3bdbbcb02988b671065a
Committed: ab248491d6e576228710950e3d21ea0731aa2de4
Applying 'atl1: add missing include dma-mapping.h'
Wrote tree 5fb3cad9771ccb59d7e3610367bb69bb33b3b45d
Committed: 13b6ae2c23523e808530681e16998220150c881c
Applying 'atl1: properly use CONFIG_PM'
Wrote tree 9fb334ce776443d59039aaedcd6a5a09790a3d67
Committed: 01e8d5606f073baf9ec8664d1e833ac428ca
Applying 'atl1: incorporate reviewer comments'
Adds trailing whitespace.
.dotest/patch:197:static int atl1_get_settings(struct net_device *netdev,
Adds trailing whitespace.
.dotest/patch:230:static int atl1_set_settings(struct net_device *netdev,
Adds trailing whitespace.
.dotest/patch:240: printk(KERN_DEBUG %s: ethtool shutting
down adapter\n,
Adds trailing whitespace.
.dotest/patch:258: } else
Adds trailing whitespace.
.dotest/patch:292:
warning: squelched 10 whitespace errors
warning: 15 lines add trailing whitespaces.
Wrote tree 75ab9e0e86a96951c542b1f6e7557c917ca6799b
Committed: 37e12a2bd50cb62add05b97fc6661d21782f232b
-
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
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/82596.c |7 +++--
drivers/net/b44.c | 52 ++--
drivers/net/bonding/bonding.h |7 +++--
drivers/net/e100.c|2 +
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c | 31 +++-
drivers/net/fs_enet/mac-fec.c | 13 +++---
drivers/net/fs_enet/mac-scc.c |6 +++-
drivers/net/ifb.c |3 +-
drivers/net/phy/fixed.c |2 +-
10 files changed, 84 insertions(+), 41 deletions(-)
Al Viro (1):
b44: src_desc-addr is little-endian
Andrew Morton (1):
82596 warning fixes
Andy Gospodarek (1):
bonding: ARP monitoring broken on x86_64
Auke Kok (1):
e100: fix irq leak on suspend/resume
Dmitriy Monakhov (1):
Broadcom 4400 resume small fix
Mariusz Kozlowski (1):
net: ifb error path loop fix
Michael Chan (1):
b44: Fix frequent link changes
Thomas Klein (2):
ehea: Fixed wrong jumbo frames status query
ehea: Fixed missing tasklet_kill() call
Vitaly Bordug (1):
FS_ENET: OF-related fixup for FEC and SCC MAC's
diff --git a/drivers/net/82596.c b/drivers/net/82596.c
index 8236f26..640d7ca 100644
--- a/drivers/net/82596.c
+++ b/drivers/net/82596.c
@@ -1066,8 +1066,8 @@ static int i596_start_xmit(struct sk_buff *skb, struct
net_device *dev)
short length = skb-len;
dev-trans_start = jiffies;
- DEB(DEB_STARTTX,printk(KERN_DEBUG %s: i596_start_xmit(%x,%x)
called\n, dev-name,
- skb-len, (unsigned int)skb-data));
+ DEB(DEB_STARTTX,printk(KERN_DEBUG %s: i596_start_xmit(%x,%p) called\n,
+ dev-name, skb-len, skb-data));
if (skb-len ETH_ZLEN) {
if (skb_padto(skb, ETH_ZLEN))
@@ -1246,7 +1246,8 @@ struct net_device * __init i82596_probe(int unit)
dev-priv = (void *)(dev-mem_start);
lp = dev-priv;
- DEB(DEB_INIT,printk(KERN_DEBUG %s: lp at 0x%08lx (%d bytes), lp-scb
at 0x%08lx\n,
+ DEB(DEB_INIT,printk(KERN_DEBUG %s: lp at 0x%08lx (%zd bytes),
+ lp-scb at 0x%08lx\n,
dev-name, (unsigned long)lp,
sizeof(struct i596_private), (unsigned long)lp-scb));
memset((void *) lp, 0, sizeof(struct i596_private));
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 5eb2ec6..303a8d9 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -110,6 +110,11 @@ MODULE_DEVICE_TABLE(pci, b44_pci_tbl);
static void b44_halt(struct b44 *);
static void b44_init_rings(struct b44 *);
+
+#define B44_FULL_RESET 1
+#define B44_FULL_RESET_SKIP_PHY2
+#define B44_PARTIAL_RESET 3
+
static void b44_init_hw(struct b44 *, int);
static int dma_desc_align_mask;
@@ -752,7 +757,7 @@ static void b44_recycle_rx(struct b44 *bp, int src_idx, u32
dest_idx_unmasked)
dest_idx * sizeof(dest_desc),
DMA_BIDIRECTIONAL);
- pci_dma_sync_single_for_device(bp-pdev, src_desc-addr,
+ pci_dma_sync_single_for_device(bp-pdev, le32_to_cpu(src_desc-addr),
RX_PKT_BUF_SZ,
PCI_DMA_FROMDEVICE);
}
@@ -884,7 +889,7 @@ static int b44_poll(struct net_device *netdev, int *budget)
spin_lock_irqsave(bp-lock, flags);
b44_halt(bp);
b44_init_rings(bp);
- b44_init_hw(bp, 1);
+ b44_init_hw(bp, B44_FULL_RESET_SKIP_PHY);
netif_wake_queue(bp-dev);
spin_unlock_irqrestore(bp-lock, flags);
done = 1;
@@ -954,7 +959,7 @@ static void b44_tx_timeout(struct net_device *dev)
b44_halt(bp);
b44_init_rings(bp);
- b44_init_hw(bp, 1);
+ b44_init_hw(bp, B44_FULL_RESET);
spin_unlock_irq(bp-lock);
@@ -1071,7 +1076,7 @@ static int b44_change_mtu(struct net_device *dev, int
new_mtu)
b44_halt(bp);
dev-mtu = new_mtu;
b44_init_rings(bp);
- b44_init_hw(bp, 1);
+ b44_init_hw(bp, B44_FULL_RESET);
spin_unlock_irq(bp-lock);
b44_enable_ints(bp);
@@ -1368,12 +1373,12 @@ static int b44_set_mac_addr(struct net_device *dev,
void *p)
* packet processing. Invoked with bp-lock held.
*/
static void __b44_set_rx_mode(struct net_device *);
-static void b44_init_hw(struct b44 *bp, int full_reset)
+static void b44_init_hw(struct b44 *bp, int reset_kind)
{
u32 val;
b44_chip_reset(bp);
- if (full_reset) {
+ if (reset_kind == B44_FULL_RESET) {
b44_phy_reset(bp);
b44_setup_phy(bp);
}
@@ -1390,7 +1395,10 @@ static void b44_init_hw(struct b44 *bp, int
Re: [RFC] rfkill - Add support for input key to control wireless radio
Well it's been a while, but here is an updated version of rfkill.
The changes since the version that was originally send are:
Spelling fixes (Thanks to Randy Dunlap)
THIS_MODULE is now a field in the rkfill_master (Suggested by Christoph Hellwig)
Move to the new Workqueue API
The open_count has been completely removed, decision making on which action
should
be taken is now handled by the user_claim field, which can be set through sysfs.
The possible choice include
1 - let rfkill handle everything without bothering the user
2 - let rfkill handle everything but send a notification to the user
3 - let rfkill send a notification only
The toggling of the keys is now type based, this means that if 1 key is being
toggled
all keys of the same type will be toggled.
As optimization and clearly seperate the keys per type, the rfkill_type
structure
now holds the list of the keys that belong to him. This has greatly reduced
the size of the rfkill_master structure.
sysfs will hold the following entries:
- The main folder: rfkill
- The main folder contains the type folders wlan, bluetooth and irda.
- Each type folder contains the files
- claim where the user claim can be read/written
- status The radio status of this type
- The folders for each key belonging to this type
- Each key folder contains the files
- status The status of this key
- idev The symlink to the input device entry in sysfs
- dev The symlink to the drivers device entry in sysfs
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ba0e88c..6986d59 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,19 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RFKILL
+ tristate RF button support
+ help
+ If you say yes here, the rfkill driver will be build
+ which allowed network devices to register their hardware
+ RF button which controls the radio state. This driver
+ will then create an input device for it.
+
+ When the input device is not used, the rfkill driver
+ will make sure that when the RF button is pressed the radio
+ is enabled or disabled accordingly. When the input device
+ has been opened by the user this radio control will be left
+ to the user, and rfkill will only send the RF button status
+ change to userspace.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e788a1b 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RFKILL) += rfkill.o
diff --git a/drivers/input/misc/rfkill.c b/drivers/input/misc/rfkill.c
new file mode 100644
index 000..6719962
--- /dev/null
+++ b/drivers/input/misc/rfkill.c
@@ -0,0 +1,988 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program 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. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/workqueue.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/input.h
+#include linux/rfkill.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(RF key support);
+MODULE_LICENSE(GPL);
+
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+ /*
+* For sysfs representation.
+*/
+ struct class_device *cdev;
+
+ /*
+* Pointer to rfkill structure
+* that was filled in by key driver.
+*/
+ struct rfkill *rfkill;
+
+ /*
+* Pointer to type structure
+* that this key belongs to.
+*/
+ struct rfkill_type *type;
+
+ /*
+* Current status of the key which controls the radio,
+* this value will change after the key state has changed
+* after polling, or the key driver has send the
Re: [2.6 patch] NF_CONNTRACK_H323 must depend on (IPV6 || IPV6=n)
Adrian Bunk wrote: On Sun, Jan 28, 2007 at 04:04:42PM -0800, David Miller wrote: From: Adrian Bunk [EMAIL PROTECTED] Date: Mon, 29 Jan 2007 01:00:11 +0100 depends on IPV6 would fix the bug - but it would also make NF_CONNTRACK_H323 unavailable for all people without IPV6 support in their kernel. Yes, that is an issue. I guess with some slightly ugly ifdefs we could support the whole matrix of possibilities. But perhaps that's undesirable for another reason. ... This depends on what NF_CONNTRACK_H323=y, IPV6=m is supposed to be: - not allowed (NF_CONNTRACK_H323 must be modular) or - NF_CONNTRACK_H323 can only be used for IPV4 My patch implements the first case. Unfortunately a few ifdefs aren't enough to support IPV6=m, NF_CONNTRACK_H323=y. For now I think Adrian's patch is the best solution (IPV6=m isn't that useful anyway since it will normally get loaded automatically when the first program attempts to open an AF_INET6 socket and can't be unloaded), but I'll look into moving the route lookup to the netfilter AF ops in 2.6.21 so we can also support that configuration. Acked-by: Patrick McHardy [EMAIL PROTECTED] - 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
Re: Hidden SSID's
On Tue, Jan 30, 2007 at 01:08:29AM -0600, Larry Finger wrote: Any AP with a hidden SSID will only respond to probe requests that specify its SSID, and will ignore any other probes. In addition, the response will have an empty SSID field. These responses are the only ones in which a substitution would occur. These are the same responses where the current code sends back the hidden pseudo-SSID. My change would put the correct one there. Is the SSID from the probe response really used here? Your patch did not look like that.. The SSID from the last scan request command may not be the one that triggered the last scan (e.g., one could request a new scan without specifying an SSID). We aren't guessing. The response frame with the empty SSID field must have come from the AP with the SSID we want. Filling in the expected value is just making it easier for the user-space tools. I don't see how the proposed patch would be using the correct SSID value in all cases. Especially cases where there are multiple APs using hidden SSIDs, but with different real SSID values and cases where multiple scan requests are being processed would be likely to leave windows open for reporting incorrect SSID. -- Jouni MalinenPGP id EFC895FA - 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
Re: Hidden SSID's
On Sun, Jan 28, 2007 at 04:18:01PM -0600, Larry Finger wrote: Is there something funny about Cisco APs with hidden SSID? Yes, there is.. Or well, hidden SSID is funny concept in itself, but anyway.. Some APs set the SSID IE to an array of 0x00 octets with the length of the original SSID when hiding the SSID while others just use 0-length SSID. -- Jouni MalinenPGP id EFC895FA - 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
Re: sky2 problems on Intel Mac Mini
On Tue, 30 Jan 2007 10:40:33 +0100 Tino Keitel [EMAIL PROTECTED] wrote: On Tue, Jan 30, 2007 at 08:39:19 +, Chris Lightfoot wrote: On Mon, Jan 29, 2007 at 04:01:17PM -0800, Stephen Hemminger wrote: On Mon, 29 Jan 2007 23:57:32 + Chris Lightfoot [EMAIL PROTECTED] wrote: [ please cc: me on any reply ] I'm seeing lots of problems with the sky2 driver on Mac Minis. Based on the suggestions in, http://www.mail-archive.com/netdev@vger.kernel.org/msg28221.html I am running stock 2.6.19 + the patches from the mactel-linux.org site to get the kernel booting on the Apple hardware; none of these touches the sky2 code. The module is installed with disable_msi=1 and idle_timeout=10; the chip version is, Yukon-EC (0xb6) rev 2 The crashes we're seeing at the moment show (with debug=16) lots and lots of transmits being queued up and never being completed, even with the timeout switched on. For instance, (this is on a machine running NFS root and vlans) Is this NFS over UDP? yes. but we see similar problems on machines which aren't doing lots of UDP traffic. Hi, I found my machine with a freezed desktop tomorrow morning. I don't use anything UDP specific, just a lot of TCP traffic. I the machine is a Mac mini Core Duo running 2.6.20-rc6 without special mactel-linux.org patches except for the IR remote driver. The kernel log looks similar. I don't use MSI. However, I don't get this several times a day. IIRC this was the first time that I saw this. Regards, Tino Are you running 64 bit (x86-64) or 32 bit (i386)? -- Stephen Hemminger [EMAIL PROTECTED] - 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
Re: sky2 problems on Intel Mac Mini
On Tue, Jan 30, 2007 at 15:21:50 -0800, Stephen Hemminger wrote: On Tue, 30 Jan 2007 10:40:33 +0100 Tino Keitel [EMAIL PROTECTED] wrote: [...] Hi, I found my machine with a freezed desktop tomorrow morning. I don't use anything UDP specific, just a lot of TCP traffic. I the machine is a Mac mini Core Duo running 2.6.20-rc6 without special mactel-linux.org patches except for the IR remote driver. The kernel log looks similar. I don't use MSI. However, I don't get this several times a day. IIRC this was the first time that I saw this. Regards, Tino Are you running 64 bit (x86-64) or 32 bit (i386)? It's a Core Duo, so it is 32 bit. Regards, Tino - 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
Re: [Patch][IPv6] Fix wrong routing mechanism for Link Local IPv6 packets
Hello, Mr yoshfuji: Thanks for your reply. The following is the figure. || || | Router | |||---| | |--| |--| || other | | | eth0 |---| eth1 |--||network| | |--| ||--| ||---| |--|--||-| | v| | fe80::20c:29ff:fe24:fa0a | | | | | | | | | | | | v | fe80::20c:29ff:fe24:fa14 | | |--|--| | |--| | | | eth0 |---|---fe80::200:ff:fe00:100 | |--| | | | |Host | |-| Host eth0: fe80::200:ff:fe00:100 Router eth0: fe80::20c:29ff:fe24:fa0a Router eth1: fe80::20c:29ff:fe24:fa14 We ping6 from host's eth0 to Router's eth1. Echo Request's src addr = fe80::200:ff:fe00:100, dst addr = fe80::20c:29ff:fe24:fa14. And Kernel just send ICMPv6 redirect packet and then forward the Echo Request to router's eth0. If we run tcpdump on Host eth0, we can receive the ICMPv6 Redirect packet. And if we send NA which advertises fe80::20c:29ff:fe24:fa14 MAC address(this is very easy for v6eval tool), we also can receive the forwarded Echo Request(src:fe80::200:ff:fe00:100 dst is fe80::20c:29ff:fe24:fa14). I dived into the kernel, and found that maybe function rt6_score_route() has problems. In rt6_score_route(), if rt6_check_dev() return 0, and the dst ipv6 addr is link local addr, rt6_socre_route() return -1 directly. I think this is not correct, we should return -1 only if the entry is in the route cache, and the dst addr is link local addr. Only entries in cache may select wrong IPv6 Link Local NIC for a link local dst addr. because they are copied from static IPv6 fib table entries. Hello, Mr yoshfuji Take ping6 for example. Asumming there is a router which has 2 NICs. eth0 on router has ipv6 addr fe80::20c:29ff:fe24:fa0a, eth1 on router has ipv6 addr fe80::20c:29ff:fe24:fa14. Also there is a host connected to router's eth0, and the host's ipv6 addr is fe80::200:ff:fe00:100. We ping6 : I still need more precise figure. Please draw complete box for the 2-3 boxes (pinger, router (and the destination)), link(s) and interfaces. +-+ |Router | +---+-+---+ eth0| |eth1 | | eth0| +---+-+ |Host1| +-+ Host1 eth0: fe80: Router eth0: fe80: Router eth1: fe80:... Or, something like that I think you may use other tool such as tgif etc. --yoshfuji - 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
Re: sky2 problems on Intel Mac Mini
On Tue, Jan 30, 2007 at 11:15:20AM -0800, Stephen Hemminger wrote: a) hardware flow control problems look at ethtool -S eth0 statistics, are there flow control packets showing up? on yeti (machine from which i quoted the first log output), [EMAIL PROTECTED] /root]# /root/ethtool -S eth0 | grep mac_pause tx_mac_pause: 0 rx_mac_pause: 8649 and on t1 both 0. But presumably you want to know this at the point of the failure -- I'll add it to the things the watchdog records before rebooting. b) GMAC or ram buffer issues looking at 'ethtool -d eth0' output can help, but it is a needle in haystack finding these setup errors. The sky2 driver copies most of the stuff from vendor version of sk98lin, but if sk98lin works and sky2 doesn't then comparing register settings can give hints. ok. I'll try to get one of these machines running the vendor driver to see whether the problems still occur. c) DMA problems For some problems, I have had luck adding a /proc interface and dumping the transmit ring after a hang. Looking at the last control block that hung can help. This found the case where IPV6 TSO was leaking through. d) checksum problems Turning off tx scatter/gather forces non fragmented skb's. This hurts performance, but can tell if the problem is with fragment code. Turning off tx checksum turns off scatter/gather, checksumming and TSO. also seems worth trying, though without a test case it'll take a while to be sure what was causing the problem. e) possible alignment and flow control interaction Because the receive DMA engine has hardware bugs and requires alignment or it doesn't work with flow control. I still wonder if there are alignment bugs on Tx with flow control. f) other driver bug To save time, I'll go get a new Mac Mini and try and clone this setup. Could you send me a full kernel config (and other setup information like filesystem type, distro etc). we've seen this on lots of different machines; yeti is NFS-root, originally ancient Redhat plus lots of locally-built packages with some bits of the filesystem on ext3. t1 is Ubuntu (`edgy' I think) on ext3. The same problems occur on Debian `sarge' and CentOS, though. What I haven't yet managed to do is to reproduce the problem -- the test machine on my desk (also NFS-root) has never exhibited it. But it's mostly idle. [...] The vendor driver does some slightly different setup, but it also does a hardware reset when inactive (every 10ms). !!! -- ``I have a sneaking sympathy for Belgium, as a land where, by accident of geography, too often other people have chosen to hold their wars.'' (Alan Follett) - 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
Re: [Patch][IPv6] Fix wrong routing mechanism for Link Local IPv6 packets
In article [EMAIL PROTECTED] (at Wed, 21 Feb 2007 09:57:12 -0500), weidong
[EMAIL PROTECTED] says:
The following is the figure.
:
Host eth0: fe80::200:ff:fe00:100
Router eth0: fe80::20c:29ff:fe24:fa0a
Router eth1: fe80::20c:29ff:fe24:fa14
Other network
|
| eth1
+++
| Router |
+++
| eth0
|
| eth0
+++
| Host |
+-+
We ping6 from host's eth0 to Router's eth1. Echo Request's src addr =
fe80::200:ff:fe00:100, dst addr = fe80::20c:29ff:fe24:fa14. And Kernel
just send ICMPv6 redirect packet and then forward the Echo Request to
router's eth0. If we run tcpdump on Host eth0, we can receive the ICMPv6
Redirect packet. And if we send NA which advertises
This is correct, and intended behavior.
fe80::20c:29ff:fe24:fa14 MAC address(this is very easy for v6eval tool),
we also can receive the forwarded Echo Request(src:fe80::200:ff:fe00:100
dst is fe80::20c:29ff:fe24:fa14).
Well, this is known issue, actually.
While this cannot happen in normal operation, we should NOT accept
such traffic. :-)
Here is the (untested) fix.
-
[IPV6] ROUTE: Do not accept traffic for link-local address on different
interface.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 5f0043c..a7468e0 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -311,12 +311,19 @@ static inline void rt6_probe(struct rt6_info *rt)
static int inline rt6_check_dev(struct rt6_info *rt, int oif)
{
struct net_device *dev = rt-rt6i_dev;
+ int ret = 0;
+
+ if (dev-flags IFF_LOOPBACK) {
+ if (!WARN_ON(rt-rt6i_idev == NULL)
+ rt-rt6i_idev-dev-ifindex == oif)
+ ret = 1;
+ else
+ return 0;
+ }
if (!oif || dev-ifindex == oif)
return 2;
- if ((dev-flags IFF_LOOPBACK)
- rt-rt6i_idev rt-rt6i_idev-dev-ifindex == oif)
- return 1;
- return 0;
+
+ return ret;
}
static int inline rt6_check_neigh(struct rt6_info *rt)
--
YOSHIFUJI Hideaki @ USAGI Project [EMAIL PROTECTED]
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
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
Re: buggy IFB driver change
On Tue, 2007-01-30 at 14:12 -0800, David Miller wrote:
Therefore we must decrement i twice before the first
free during the cleanup. One to undo the for() loop
increment, and one to skip the ifb_init_one() case which
failed.
Perhaps putting the error unwind inside the for loop
is simpler and more intelligible.
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index ca2b21f..0b24c31 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -264,19 +264,20 @@ static void ifb_free_one(int index)
static int __init ifb_init_module(void)
{
- int i, err = 0;
+ int i, err;
ifbs = kmalloc(numifbs * sizeof(void *), GFP_KERNEL);
if (!ifbs)
return -ENOMEM;
- for (i = 0; i numifbs !err; i++)
+ for (i = 0; i numifbs; i++) {
err = ifb_init_one(i);
- if (err) {
- i--;
- while (--i = 0)
- ifb_free_one(i);
+ if (err) {
+ while (i 0)
+ ifb_free_one(--i);
+ return err;
+ }
}
- return err;
+ return 0;
}
static void __exit ifb_cleanup_module(void)
-
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
Re: Hidden SSID's
Jouni Malinen wrote: On Tue, Jan 30, 2007 at 01:08:29AM -0600, Larry Finger wrote: Any AP with a hidden SSID will only respond to probe requests that specify its SSID, and will ignore any other probes. In addition, the response will have an empty SSID field. These responses are the only ones in which a substitution would occur. These are the same responses where the current code sends back the hidden pseudo-SSID. My change would put the correct one there. Is the SSID from the probe response really used here? Your patch did not look like that.. The SSID from the last scan request command may not be the one that triggered the last scan (e.g., one could request a new scan without specifying an SSID). If one does the equivalent of 'iwlist eth1 scan essid myssid', then a probe response with NETWORK_EMPTY_ESSID set in the network flags will have 'myssid' returned in the SSID field of the returned buffer. If the input command were 'iwlist eth1 scan', then an empty SSID would be returned under the same circumstances. My code saves the SSID that is in the extra argument of the SIOCSIWSCAN call, and uses that in the SIOCGIWSCAN call. We aren't guessing. The response frame with the empty SSID field must have come from the AP with the SSID we want. Filling in the expected value is just making it easier for the user-space tools. I don't see how the proposed patch would be using the correct SSID value in all cases. Especially cases where there are multiple APs using hidden SSIDs, but with different real SSID values and cases where multiple scan requests are being processed would be likely to leave windows open for reporting incorrect SSID. I can think of one instance where the wrong value could be reported. That is if some other STA probes a different hidden AP just when we have sent a probe request. For WPA this should not cause a problem as wpa_supplicant will sort that out while authenticating. What is the method that should be used to associated with a given hidden AP? Larry - 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
RE: [PATCH 2.6.20 1/5] s2io: Making LRO and UFO as module loadable parameter.
Hi Jeff, Where you able to apply the patches. Please let me the known if you have any issues. Thanks, ~Siva -Original Message- From: Sivakumar Subramani Sent: Monday, January 29, 2007 11:36 AM To: netdev@vger.kernel.org; 'Jeff Garzik' Cc: Leonid Grossman; Ananda Raju; Sreenivasa Honnur; Ramkrishna Vepa; Rastapur Santosh; Sriram Rapuru Subject: RE: [PATCH 2.6.20 1/5] s2io: Making LRO and UFO as module loadable parameter. Hi Jeff, As per your comment I have synced up the patch with the latest netdev-2.6.git#upstream branch. Also I have corrected the white space issue. I have resubmitted the patches again. Thanks, ~Siva -Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 24, 2007 2:56 AM To: Ananda Raju Cc: [EMAIL PROTECTED]; Leonid Grossman; Alicia Pena; Ramkrishna Vepa; Sreenivasa Honnur; Sriram Rapuru Subject: Re: [PATCH 2.6.20 1/5] s2io: Making LRO and UFO as module loadable parameter. Ananda Raju wrote: This patch adds two load parameters napi and ufo. Previously NAPI was compilation option with these changes wan enable disable NAPI using load parameter. Also we are introducing ufo load parameter to enable/disable ufo feature Signed-off-by: Sivakumar Subramani [EMAIL PROTECTED] ACK patches 1-5, but patch does not apply to netdev-2.6.git#upstream. Also, git-am complains about whitespace. [EMAIL PROTECTED] netdev-2.6]$ git-am --signoff --utf8 /g/tmp/mbox Applying 's2io: Making LRO and UFO as module loadable parameter.' Space in indent is followed by a tab. .dotest/patch:41: (block_no * (rxd_count[nic-rxd_mode] + 1)) + off; Adds trailing whitespace. .dotest/patch:46: } Space in indent is followed by a tab. .dotest/patch:137: * Rx handler is called by default, without checking for the Space in indent is followed by a tab. .dotest/patch:138: * cause of interrupt. Space in indent is followed by a tab. .dotest/patch:139: * rx_traffic_int reg is an R1 register, writing all 1's error: patch failed: drivers/net/s2io.c:6985 error: drivers/net/s2io.c: patch does not apply Patch failed at 0001. When you have resolved this problem run git-am --resolved. If you would prefer to skip this patch, instead run git-am --skip. - 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
Re: [Patch][IPv6] Fix wrong routing mechanism for Link Local IPv6 packets
Hello, Mr yoshfuji
Thanks for your patch. I think maybe we checking oif first is better,
and WARN_ON in function rt6_score_route().
The following is my patch
Signed-off-by: Wei Dong [EMAIL PROTECTED]
diff -ruN old/net/ipv6/route.c new/net/ipv6/route.c
--- old/net/ipv6/route.c2007-02-16 13:46:33.0 -0500
+++ new/net/ipv6/route.c2007-02-16 13:44:27.0 -0500
@@ -309,12 +309,21 @@
static int inline rt6_check_dev(struct rt6_info *rt, int oif)
{
struct net_device *dev = rt-rt6i_dev;
- if (!oif || dev-ifindex == oif)
+ int ret = 0;
+
+ if (!oif)
return 2;
+
if ((dev-flags IFF_LOOPBACK)
rt-rt6i_idev rt-rt6i_idev-dev-ifindex == oif)
- return 1;
- return 0;
+ ret = 1;
+ else
+ return 0;
+
+ if (dev-ifindex == oif)
+ return 2;
+
+ return ret;
}
static int inline rt6_check_neigh(struct rt6_info *rt)
@@ -339,8 +348,11 @@
int m, n;
m = rt6_check_dev(rt, oif);
- if (!m (strict RT6_LOOKUP_F_IFACE))
+ if (!m (strict RT6_LOOKUP_F_IFACE)) {
+ WARN_ON(rt-rt6i_dev-flags IFF_LOOPBACK);
return -1;
+ }
+
#ifdef CONFIG_IPV6_ROUTER_PREF
m |= IPV6_DECODE_PREF(IPV6_EXTRACT_PREF(rt-rt6i_flags)) 2;
#endif
On Wed, 2007-01-31 at 13:00 +0900, Wei Dong wrote:
In article [EMAIL PROTECTED] (at Wed, 21 Feb 2007
09:57:12 -0500), weidong [EMAIL PROTECTED] says:
The following is the figure.
:
Host eth0: fe80::200:ff:fe00:100
Router eth0: fe80::20c:29ff:fe24:fa0a
Router eth1: fe80::20c:29ff:fe24:fa14
Other network
|
| eth1
+++
| Router |
+++
| eth0
|
| eth0
+++
| Host |
+-+
We ping6 from host's eth0 to Router's eth1. Echo Request's src addr =
fe80::200:ff:fe00:100, dst addr = fe80::20c:29ff:fe24:fa14. And Kernel
just send ICMPv6 redirect packet and then forward the Echo Request to
router's eth0. If we run tcpdump on Host eth0, we can receive the ICMPv6
Redirect packet. And if we send NA which advertises
This is correct, and intended behavior.
fe80::20c:29ff:fe24:fa14 MAC address(this is very easy for v6eval tool),
we also can receive the forwarded Echo Request(src:fe80::200:ff:fe00:100
dst is fe80::20c:29ff:fe24:fa14).
Well, this is known issue, actually.
While this cannot happen in normal operation, we should NOT accept
such traffic. :-)
Here is the (untested) fix.
-
[IPV6] ROUTE: Do not accept traffic for link-local address on different
interface.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 5f0043c..a7468e0 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -311,12 +311,19 @@ static inline void rt6_probe(struct rt6_info *rt)
static int inline rt6_check_dev(struct rt6_info *rt, int oif)
{
struct net_device *dev = rt-rt6i_dev;
+ int ret = 0;
+
+ if (dev-flags IFF_LOOPBACK) {
+ if (!WARN_ON(rt-rt6i_idev == NULL)
+ rt-rt6i_idev-dev-ifindex == oif)
+ ret = 1;
+ else
+ return 0;
+ }
if (!oif || dev-ifindex == oif)
return 2;
- if ((dev-flags IFF_LOOPBACK)
- rt-rt6i_idev rt-rt6i_idev-dev-ifindex == oif)
- return 1;
- return 0;
+
+ return ret;
}
static int inline rt6_check_neigh(struct rt6_info *rt)
-
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
Re: [PATCH] PA Semi PWRficient Ethernet driver
On Tue, Jan 30, 2007 at 10:45:18PM +0100, Francois Romieu wrote: Olof Johansson [EMAIL PROTECTED] : On Mon, Jan 29, 2007 at 11:35:06PM +0100, Francois Romieu wrote: [...] - The driver does not contain a single SMP locking instruction but http://www.pasemi.com claims the platform to be multicore. Is the driver really designed to be lockless ? Unless I misunderstood something, NAPI drivers that don't set NETIF_F_LLTX will have all locking taken care of by higher layers, no? It is not necessarily _that_ simple (it would be cool though :o) ). For instance, what does prevent pasemi_mac_clean_tx() to be issued from IRQ context (pasemi_mac_tx_intr) and from the xmit handler (pasemi_mac_start_tx) at the same time ? You're right. Bummer. I'll add locking on the rings. [...] unsigned int is supposed to save some cycles on ppc. Who told you that? That's not true. Jon D Mason [EMAIL PROTECTED] on 25/08/2004 about ppc64 (not ppc, sorry). Interesting, I hadn't thought about that before. There's nothing architectural in PPC that makes signed math slower than unsigned, but in the case of modulo operations (which we do alot on the rings), unsigned is per definition more complex to do the operations on. It's pretty much within the noise on the current implementation, but still an interesting tidbit. Thanks. [...] +#define DESCR(ring, i) ((ring)-desc[i % ((ring)-count)]) +#define BUFF(ring, i) ((ring)-buffers[i % ((ring)-count)]) +#define INFO(ring, i) ((ring)-desc_info[i % ((ring)-count)]) A bit ugly/obfuscating/name clash prone imvho. Use local variables ? I'm open for suggestions here, not sure how local variables will help though? struct pas_dma_xct_descr *desc = ring-desc[i % ring-count]; That makes sense. Done. -Olof - 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
Re: [Patch][IPv6] Fix wrong routing mechanism for Link Local IPv6 packets
In article [EMAIL PROTECTED] (at Wed, 21 Feb 2007 23:51:45 -0500), weidong [EMAIL PROTECTED] says: Thanks for your patch. I think maybe we checking oif first is better, and WARN_ON in function rt6_score_route(). Please remove WARN_ON. Otherwise, I'm fine with it. --yoshfuji - 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
[PATCH] [v3] PA Semi PWRficient Ethernet driver
Driver for the PA Semi PWRficient on-chip Ethernet (1/10G)
Basic enablement, will be complemented with performance enhancements
over time. PHY support will be added as well.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
Further improvements based on comments:
* Added remove function
* Checking interrupt status in handler
* Misc cleanups w.r.t. ring handing (INFO/DESCR/BUFF are gone)
* Added locking of the rings
* Using PCI DMA for all buffers
Misc other changes while I was touching the code:
* Setting the interrupt descriptor field to include interface number
* Added PCI vendor ID, it's been submitted to sf.net as well.
* Moved Kconfig entry to the 10GbE section
Index: merge/drivers/net/Kconfig
===
--- merge.orig/drivers/net/Kconfig
+++ merge/drivers/net/Kconfig
@@ -2488,6 +2488,13 @@ config NETXEN_NIC
help
This enables the support for NetXen's Gigabit Ethernet card.
+config PASEMI_MAC
+ tristate PA Semi 1/10Gbit MAC
+ depends on PPC64 PCI
+ help
+ This driver supports the on-chip 1/10Gbit Ethernet controller on
+ PA Semi's PWRficient line of chips.
+
endmenu
source drivers/net/tokenring/Kconfig
Index: merge/drivers/net/Makefile
===
--- merge.orig/drivers/net/Makefile
+++ merge/drivers/net/Makefile
@@ -196,6 +196,7 @@ obj-$(CONFIG_SMC91X) += smc91x.o
obj-$(CONFIG_SMC911X) += smc911x.o
obj-$(CONFIG_DM9000) += dm9000.o
obj-$(CONFIG_FEC_8XX) += fec_8xx/
+obj-$(CONFIG_PASEMI_MAC) += pasemi_mac.o
obj-$(CONFIG_MACB) += macb.o
Index: merge/drivers/net/pasemi_mac.c
===
--- /dev/null
+++ merge/drivers/net/pasemi_mac.c
@@ -0,0 +1,963 @@
+/*
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Driver for the PA Semi PWRficient onchip 1G/10G Ethernet MACs
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program 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. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/interrupt.h
+#include linux/dmaengine.h
+#include linux/delay.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include asm/dma-mapping.h
+#include linux/in.h
+#include linux/skbuff.h
+
+#include linux/ip.h
+#include linux/tcp.h
+#include net/checksum.h
+
+#include pasemi_mac.h
+
+#define INITIAL_RX_RING_SIZE 512
+#define INITIAL_TX_RING_SIZE 512
+
+#define BUF_SIZE 1646 /* 1500 MTU + ETH_HLEN + VLAN_HLEN + 2 64B cachelines */
+
+#define PAS_DMA_MAX_IF 40
+#define PAS_DMA_MAX_RXCH 8
+#define PAS_DMA_MAX_TXCH 8
+
+/* XXXOJN these should come out of the device tree some day */
+#define PAS_DMA_CAP_BASE 0xe00d0040
+#define PAS_DMA_CAP_SIZE 0x100
+#define PAS_DMA_COM_BASE 0xe00d0100
+#define PAS_DMA_COM_SIZE 0x100
+
+static struct pasdma_status *dma_status;
+
+static int pasemi_set_mac_addr(struct pasemi_mac *mac)
+{
+ struct pci_dev *pdev = mac-pdev;
+ struct device_node *dn = pci_device_to_OF_node(pdev);
+ const u8 *maddr;
+ u8 addr[6];
+
+ if (!dn) {
+ dev_dbg(pdev-dev,
+ No device node for mac, not configuring\n);
+ return -ENOENT;
+ }
+
+ maddr = get_property(dn, mac-address, NULL);
+ if (maddr == NULL) {
+ dev_warn(pdev-dev,
+no mac address in device tree, not configuring\n);
+ return -ENOENT;
+ }
+
+ if (sscanf(maddr, %hhx:%hhx:%hhx:%hhx:%hhx:%hhx, addr[0],
+ addr[1], addr[2], addr[3], addr[4], addr[5]) != 6) {
+ dev_warn(pdev-dev,
+can't parse mac address, not configuring\n);
+ return -EINVAL;
+ }
+
+ memcpy(mac-mac_addr, addr, sizeof(addr));
+ return 0;
+}
+
+static int pasemi_mac_setup_rx_resources(struct net_device *dev)
+{
+ struct pasemi_mac_rxring *ring;
+ struct pasemi_mac *mac = netdev_priv(dev);
+ int chan_id = mac-dma_rxch;
+
+ ring = kzalloc(sizeof(*ring), GFP_KERNEL);
+
+ if (!ring)
+ goto out_ring;
+
+ spin_lock_init(ring-lock);
+ ring-count = INITIAL_RX_RING_SIZE;
+
+ ring-desc_info = kzalloc(sizeof(struct pasemi_mac_buffer)*ring-count,
+ GFP_KERNEL);
+
+ if
[PATCH][NET_SCHED] sch_prio: class statistics printing enabled
Hello,
This patch adds a dump_stats callback to enable
printing of basic statistics of prio classes.
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp linux-2.6.20-rc6-/net/sched/sch_prio.c
linux-2.6.20-rc6/net/sched/sch_prio.c
--- linux-2.6.20-rc6-/net/sched/sch_prio.c 2007-01-08 20:23:58.0
+0100
+++ linux-2.6.20-rc6/net/sched/sch_prio.c 2007-01-30 20:26:31.0
+0100
@@ -372,6 +372,23 @@ static int prio_dump_class(struct Qdisc
return 0;
}
+static int prio_dump_class_stats(struct Qdisc *sch, unsigned long cl,
+ struct gnet_dump *d)
+{
+ struct prio_sched_data *q = qdisc_priv(sch);
+ struct Qdisc *cl_q;
+
+ if (cl - 1 q-bands)
+ return -ENOENT;
+
+ cl_q = q-queues[cl - 1];
+ if (gnet_stats_copy_basic(d, cl_q-bstats) 0 ||
+ gnet_stats_copy_queue(d, cl_q-qstats) 0)
+ return -1;
+
+ return 0;
+}
+
static void prio_walk(struct Qdisc *sch, struct qdisc_walker *arg)
{
struct prio_sched_data *q = qdisc_priv(sch);
@@ -414,6 +431,7 @@ static struct Qdisc_class_ops prio_class
.bind_tcf = prio_bind,
.unbind_tcf = prio_put,
.dump = prio_dump_class,
+ .dump_stats = prio_dump_class_stats,
};
static struct Qdisc_ops prio_qdisc_ops = {
-
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
Re: [RFC] rfkill - Add support for input key to control wireless radio
Hope you will be resubmitting this.
+/*
+ * rfkill key structure.
+ */
+struct rfkill_key {
+ /*
+ * For sysfs representation.
+ */
+ struct class_device *cdev;
+
+ /*
+ * Pointer to rfkill structure
+ * that was filled in by key driver.
+ */
+ struct rfkill *rfkill;
Since rfkill is basically a function pointer table,
can it be made const?
+ /*
+ * Pointer to type structure that this key belongs to.
+ */
+ struct rfkill_type *type;
+
+ /*
+ * Once key status change has been detected, the toggled
+ * field should be set to indicate a notification to
+ * user or driver should be performed.
+ */
+ int toggled;
+
+ /*
+ * Current state of the device radio, this state will
+ * change after the radio has actually been toggled since
+ * receiving the radio key event.
+ */
+ int radio_status;
+
+ /*
+ * Current status of the key which controls the radio,
+ * this value will change after the key state has changed
+ * after polling, or the key driver has send the new state
+ * manually.
+ */
+ int key_status;
Maybe turn these bits into a bit values (set_bit/clear_bit) in an unsigned long.
+ /*
+ * Input device for this key,
+ * we also keep track of the number of
+ * times this input device is open. This
+ * is important for determining to whom we
+ * should report key events.
+ */
+ struct input_dev *input;
+ unsigned int open_count;
atomic on open_count?
+ /*
+ * Key index number.
+ */
+ unsigned int key_index;
+
+ /*
+ * List head structure to be used
+ * to add this structure to the list.
+ */
+ struct list_head entry;
+};
+
+/*
+ * rfkill key type structure.
+ */
+struct rfkill_type {
+ /*
+ * For sysfs representation.
+ */
+ struct class_device *cdev;
+
+ /*
+ * Name of this radio type.
+ */
+ char *name;
const?
+ /*
+ * Key type identification. Value must be any
+ * in the key_type enum.
+ */
+ unsigned int key_type;
+
+ /*
+ * Number of registered keys of this type.
+ */
+ unsigned int key_count;
+};
+
+/*
+ * rfkill master structure.
+ */
+struct rfkill_master {
+ /*
+ * For sysfs representation.
+ */
+ struct class *class;
+
+ /*
+ * All access to the master structure
+ * and its children (the keys) are protected
+ * by this key lock.
+ */
+ struct semaphore key_sem;
mutex instead of semaphort
+ /*
+ * List of available key types.
+ */
+ struct rfkill_type type[KEY_TYPE_MAX];
+
+ /*
+ * Total number of registered keys.
+ */
+ unsigned int key_count;
+
+ /*
+ * Number of keys that require polling
+ */
+ unsigned int poll_required;
+
+ /*
+ * List of rfkill_key structures.
+ */
+ struct list_head key_list;
+
+ /*
+ * Work structures for periodic polling,
+ * as well as the scheduled radio toggling.
+ */
+ struct work_struct toggle_work;
+ struct work_struct poll_work;
delayed_rearming_work instead?
+};
-
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
[PATCH 0/10] cxgb3 - Chelsio T3 1G/10G driver updates
Jeff, I'm sending a series of incremental patches updating the cxgb3 driver. These patches are built against netdev#upstream. Cheers, Divy - 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
[PATCH 5/10] cxgb3 - Clean up HW init routine
From: Divy Le Ray [EMAIL PROTECTED]
Clean up the tp_config() routine.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/t3_hw.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 2215400..7112bac 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -2328,8 +2328,6 @@ static inline void tp_wr_indirect(struct
static void tp_config(struct adapter *adap, const struct tp_params *p)
{
- unsigned int v;
-
t3_write_reg(adap, A_TP_GLOBAL_CONFIG, F_TXPACINGENABLE | F_PATHMTU |
F_IPCHECKSUMOFFLOAD | F_UDPCHECKSUMOFFLOAD |
F_TCPCHECKSUMOFFLOAD | V_IPTTL(64));
@@ -2348,15 +2346,11 @@ static void tp_config(struct adapter *ad
adap-params.rev 0 ? F_ENABLEESND : F_T3A_ENABLEESND,
0);
- v = t3_read_reg(adap, A_TP_PC_CONFIG);
- v = ~(F_ENABLEEPCMDAFULL | F_ENABLEOCSPIFULL);
- t3_write_reg(adap, A_TP_PC_CONFIG, v | F_TXDEFERENABLE |
-F_MODULATEUNIONMODE | F_HEARBEATDACK |
-F_TXCONGESTIONMODE | F_RXCONGESTIONMODE);
-
- v = t3_read_reg(adap, A_TP_PC_CONFIG2);
- v = ~F_CHDRAFULL;
- t3_write_reg(adap, A_TP_PC_CONFIG2, v);
+ t3_set_reg_field(adap, A_TP_PC_CONFIG,
+F_ENABLEEPCMDAFULL | F_ENABLEOCSPIFULL,
+F_TXDEFERENABLE | F_HEARBEATDACK | F_TXCONGESTIONMODE |
+F_RXCONGESTIONMODE);
+ t3_set_reg_field(adap, A_TP_PC_CONFIG2, F_CHDRAFULL, 0);
if (adap-params.rev 0) {
tp_wr_indirect(adap, A_TP_EGRESS_CONFIG, F_REWRITEFORCETOSIZE);
-
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
[PATCH 2/10] cxgb3 - bind qsets on multiport adapter
From: Divy Le Ray [EMAIL PROTECTED]
Inform FW about the queue set-interface mapping.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/adapter.h|2 +
drivers/net/cxgb3/cxgb3_main.c | 68 ++--
drivers/net/cxgb3/sge.c|8 +
3 files changed, 54 insertions(+), 24 deletions(-)
diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h
index 16643f6..8902007 100644
--- a/drivers/net/cxgb3/adapter.h
+++ b/drivers/net/cxgb3/adapter.h
@@ -46,6 +46,7 @@ enum {/* adapter flags */
FULL_INIT_DONE = (1 0),
USING_MSI = (1 1),
USING_MSIX = (1 2),
+ QUEUES_BOUND = (1 3),
};
struct rx_desc;
@@ -244,6 +245,7 @@ void t3_free_sge_resources(struct adapte
void t3_sge_err_intr_handler(struct adapter *adapter);
intr_handler_t t3_intr_handler(struct adapter *adap, int polling);
int t3_eth_xmit(struct sk_buff *skb, struct net_device *dev);
+int t3_mgmt_tx(struct adapter *adap, struct sk_buff *skb);
void t3_update_qset_coalesce(struct sge_qset *qs, const struct qset_params *p);
int t3_sge_alloc_qset(struct adapter *adapter, unsigned int id, int nports,
int irq_vec_idx, const struct qset_params *p,
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 8044146..7e7ee7a 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -649,6 +649,37 @@ static void init_port_mtus(struct adapte
t3_write_reg(adapter, A_TP_MTU_PORT_TABLE, mtus);
}
+static void send_pktsched_cmd(struct adapter *adap, int sched, int qidx, int
lo,
+ int hi, int port)
+{
+ struct sk_buff *skb;
+ struct mngt_pktsched_wr *req;
+
+ skb = alloc_skb(sizeof(*req), GFP_KERNEL | __GFP_NOFAIL);
+ req = (struct mngt_pktsched_wr *)skb_put(skb, sizeof(*req));
+ req-wr_hi = htonl(V_WR_OP(FW_WROPCODE_MNGT));
+ req-mngt_opcode = FW_MNGTOPCODE_PKTSCHED_SET;
+ req-sched = sched;
+ req-idx = qidx;
+ req-min = lo;
+ req-max = hi;
+ req-binding = port;
+ t3_mgmt_tx(adap, skb);
+}
+
+static void bind_qsets(struct adapter *adap)
+{
+ int i, j;
+
+ for_each_port(adap, i) {
+ const struct port_info *pi = adap2pinfo(adap, i);
+
+ for (j = 0; j pi-nqsets; ++j)
+ send_pktsched_cmd(adap, 1, pi-first_qset + j, -1,
+ -1, i);
+ }
+}
+
/**
* cxgb_up - enable the adapter
* @adapter: adapter being enabled
@@ -708,6 +739,11 @@ static int cxgb_up(struct adapter *adap)
t3_sge_start(adap);
t3_intr_enable(adap);
+
+ if ((adap-flags (USING_MSIX | QUEUES_BOUND)) == USING_MSIX)
+ bind_qsets(adap);
+ adap-flags |= QUEUES_BOUND;
+
out:
return err;
irq_err:
@@ -1830,34 +1866,18 @@ static int cxgb_extension_ioctl(struct n
break;
}
case CHELSIO_SET_PKTSCHED:{
- struct sk_buff *skb;
struct ch_pktsched_params p;
- struct mngt_pktsched_wr *req;
- if (!(adapter-flags FULL_INIT_DONE))
- return -EIO;/* uP must be up and running */
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+ if (!adapter-open_device_map)
+ return -EAGAIN; /* uP and SGE must be running */
if (copy_from_user(p, useraddr, sizeof(p)))
- return -EFAULT;
- skb = alloc_skb(sizeof(*req), GFP_KERNEL);
- if (!skb)
- return -ENOMEM;
- req =
- (struct mngt_pktsched_wr *)skb_put(skb,
- sizeof(*req));
- req-wr_hi = htonl(V_WR_OP(FW_WROPCODE_MNGT));
- req-mngt_opcode = FW_MNGTOPCODE_PKTSCHED_SET;
- req-sched = p.sched;
- req-idx = p.idx;
- req-min = p.min;
- req-max = p.max;
- req-binding = p.binding;
- printk(KERN_INFO
- pktsched: sched %u idx %u min %u max %u binding %u\n,
- req-sched, req-idx, req-min, req-max,
- req-binding);
- skb-priority = 1;
- offload_tx(adapter-tdev, skb);
+ return -EFAULT;
+ send_pktsched_cmd(adapter, p.sched, p.idx, p.min, p.max,
+ p.binding);
break;
+
}
default:
return -EOPNOTSUPP;
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index 6c77f4b..ccea06a 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -1198,6 +1198,14 @@ static void
[PATCH 7/10] cxgb3 - Remove BUG_ON from t3b_intr_napi
From: Divy Le Ray [EMAIL PROTECTED]
In some cases, SG_DATA_INTR won't clear on read and the following
interrupt may cause us to assert because NAPI is already scheduled.
Remove the assertion, NAPI can handle attempts to rearm it while
it's already scheduled.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/sge.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index 8b3c824..daef7fd 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -2199,14 +2199,12 @@ static irqreturn_t t3b_intr_napi(int irq
if (likely(map 1)) {
dev = adap-sge.qs[0].netdev;
- BUG_ON(napi_is_scheduled(dev));
if (likely(__netif_rx_schedule_prep(dev)))
__netif_rx_schedule(dev);
}
if (map 2) {
dev = adap-sge.qs[1].netdev;
- BUG_ON(napi_is_scheduled(dev));
if (likely(__netif_rx_schedule_prep(dev)))
__netif_rx_schedule(dev);
}
-
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
[PATCH 10/10] cxgb3 - Add dual licensing
From: Divy Le Ray [EMAIL PROTECTED] Dual licensing, needed for OFED 1.2 Signed-off-by: Divy Le Ray [EMAIL PROTECTED] --- drivers/net/cxgb3/adapter.h | 33 +++ drivers/net/cxgb3/ael1002.c | 34 +++- drivers/net/cxgb3/common.h | 34 +++- drivers/net/cxgb3/cxgb3_ctl_defs.h | 34 drivers/net/cxgb3/cxgb3_defs.h |4 +-- drivers/net/cxgb3/cxgb3_ioctl.h | 34 +++- drivers/net/cxgb3/cxgb3_main.c | 36 -- drivers/net/cxgb3/cxgb3_offload.c|4 +-- drivers/net/cxgb3/cxgb3_offload.h|4 +-- drivers/net/cxgb3/firmware_exports.h | 48 +++--- drivers/net/cxgb3/l2t.c |4 +-- drivers/net/cxgb3/l2t.h |4 +-- drivers/net/cxgb3/mc5.c | 34 +++- drivers/net/cxgb3/sge.c | 38 +-- drivers/net/cxgb3/t3_cpl.h | 34 ++-- drivers/net/cxgb3/t3_hw.c| 38 +-- drivers/net/cxgb3/t3cdev.h |3 +- drivers/net/cxgb3/version.h | 47 ++--- drivers/net/cxgb3/vsc8211.c | 34 +++- drivers/net/cxgb3/xgmac.c| 34 +++- 20 files changed, 399 insertions(+), 136 deletions(-) diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h index 97e35c8..5c97a64 100644 --- a/drivers/net/cxgb3/adapter.h +++ b/drivers/net/cxgb3/adapter.h @@ -1,12 +1,33 @@ /* - * This file is part of the Chelsio T3 Ethernet driver for Linux. + * Copyright (c) 2003-2007 Chelsio, Inc. All rights reserved. * - * Copyright (C) 2003-2006 Chelsio Communications. All rights reserved. + * This software is available to you under a choice of one of two + * licenses. You may choose to be licensed under the terms of the GNU + * General Public License (GPL) Version 2, available from the file + * COPYING in the main directory of this source tree, or the + * OpenIB.org BSD license below: * - * This program 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. See the LICENSE file included in this - * release for licensing terms and conditions. + * Redistribution and use in source and binary forms, with or + * without modification, are permitted provided that the following + * conditions are met: + * + * - Redistributions of source code must retain the above + *copyright notice, this list of conditions and the following + *disclaimer. + * + * - Redistributions in binary form must reproduce the above + *copyright notice, this list of conditions and the following + *disclaimer in the documentation and/or other materials + *provided with the distribution. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. */ /* This file should not be included directly. Include common.h instead. */ diff --git a/drivers/net/cxgb3/ael1002.c b/drivers/net/cxgb3/ael1002.c index 93a90d8..73a41e6 100644 --- a/drivers/net/cxgb3/ael1002.c +++ b/drivers/net/cxgb3/ael1002.c @@ -1,14 +1,34 @@ /* - * This file is part of the Chelsio T3 Ethernet driver. + * Copyright (c) 2005-2007 Chelsio, Inc. All rights reserved. * - * Copyright (C) 2005-2006 Chelsio Communications. All rights reserved. + * This software is available to you under a choice of one of two + * licenses. You may choose to be licensed under the terms of the GNU + * General Public License (GPL) Version 2, available from the file + * COPYING in the main directory of this source tree, or the + * OpenIB.org BSD license below: * - * This program 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. See the LICENSE file included in this - * release for licensing terms and conditions. + * Redistribution and use in source and binary forms, with or + * without modification, are permitted provided that the following + * conditions are met: + * + * - Redistributions of source code must retain the above + *copyright notice, this list of conditions and the following + *disclaimer. + * + * - Redistributions in binary form must reproduce the above
[PATCH 8/10] cxgb3 - Unmap offload packets when they are freed.
From: Divy Le Ray [EMAIL PROTECTED]
Offload packets may be DMAed long after their SGE Tx descriptors are done
so they must remain mapped until they are freed rather than until their
descriptors are freed. Unmap such packets through an skb destructor.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/sge.c | 63 ++-
1 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index daef7fd..d563f7a 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -85,6 +85,15 @@ struct unmap_info { /* packet unmapping
};
/*
+ * Holds unmapping information for Tx packets that need deferred unmapping.
+ * This structure lives at skb-head and must be allocated by callers.
+ */
+struct deferred_unmap_info {
+ struct pci_dev *pdev;
+ dma_addr_t addr[MAX_SKB_FRAGS + 1];
+};
+
+/*
* Maps a number of flits to the number of Tx descriptors that can hold them.
* The formula is
*
@@ -232,10 +241,13 @@ static void free_tx_desc(struct adapter
struct pci_dev *pdev = adapter-pdev;
unsigned int cidx = q-cidx;
+ const int need_unmap = need_skb_unmap()
+ q-cntxt_id = FW_TUNNEL_SGEEC_START;
+
d = q-sdesc[cidx];
while (n--) {
if (d-skb) { /* an SGL is present */
- if (need_skb_unmap())
+ if (need_unmap)
unmap_skb(d-skb, q, cidx, pdev);
if (d-skb-priority == cidx)
kfree_skb(d-skb);
@@ -1207,6 +1219,50 @@ int t3_mgmt_tx(struct adapter *adap, str
}
/**
+ * deferred_unmap_destructor - unmap a packet when it is freed
+ * @skb: the packet
+ *
+ * This is the packet destructor used for Tx packets that need to remain
+ * mapped until they are freed rather than until their Tx descriptors are
+ * freed.
+ */
+static void deferred_unmap_destructor(struct sk_buff *skb)
+{
+ int i;
+ const dma_addr_t *p;
+ const struct skb_shared_info *si;
+ const struct deferred_unmap_info *dui;
+ const struct unmap_info *ui = (struct unmap_info *)skb-cb;
+
+ dui = (struct deferred_unmap_info *)skb-head;
+ p = dui-addr;
+
+ if (ui-len)
+ pci_unmap_single(dui-pdev, *p++, ui-len, PCI_DMA_TODEVICE);
+
+ si = skb_shinfo(skb);
+ for (i = 0; i si-nr_frags; i++)
+ pci_unmap_page(dui-pdev, *p++, si-frags[i].size,
+ PCI_DMA_TODEVICE);
+}
+
+static void setup_deferred_unmapping(struct sk_buff *skb, struct pci_dev *pdev,
+const struct sg_ent *sgl, int sgl_flits)
+{
+ dma_addr_t *p;
+ struct deferred_unmap_info *dui;
+
+ dui = (struct deferred_unmap_info *)skb-head;
+ dui-pdev = pdev;
+ for (p = dui-addr; sgl_flits = 3; sgl++, sgl_flits -= 3) {
+ *p++ = be64_to_cpu(sgl-addr[0]);
+ *p++ = be64_to_cpu(sgl-addr[1]);
+ }
+ if (sgl_flits)
+ *p = be64_to_cpu(sgl-addr[0]);
+}
+
+/**
* write_ofld_wr - write an offload work request
* @adap: the adapter
* @skb: the packet to send
@@ -1242,8 +1298,11 @@ static void write_ofld_wr(struct adapter
sgp = ndesc == 1 ? (struct sg_ent *)d-flit[flits] : sgl;
sgl_flits = make_sgl(skb, sgp, skb-h.raw, skb-tail - skb-h.raw,
adap-pdev);
- if (need_skb_unmap())
+ if (need_skb_unmap()) {
+ setup_deferred_unmapping(skb, adap-pdev, sgp, sgl_flits);
+ skb-destructor = deferred_unmap_destructor;
((struct unmap_info *)skb-cb)-len = skb-tail - skb-h.raw;
+ }
write_wr_hdr_sgl(ndesc, skb, d, pidx, q, sgl, flits, sgl_flits,
gen, from-wr_hi, from-wr_lo);
-
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
[PATCH 9/10] cxgb3 - Add linux/mutex.h
From: Divy Le Ray [EMAIL PROTECTED] Include linux/mutex.h in adapter.h Signed-off-by: Divy Le Ray [EMAIL PROTECTED] --- drivers/net/cxgb3/adapter.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/cxgb3/adapter.h b/drivers/net/cxgb3/adapter.h index 8902007..97e35c8 100644 --- a/drivers/net/cxgb3/adapter.h +++ b/drivers/net/cxgb3/adapter.h @@ -19,6 +19,7 @@ #include linux/interrupt.h #include linux/timer.h #include linux/cache.h +#include linux/mutex.h #include t3cdev.h #include asm/semaphore.h #include asm/bitops.h - 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
[PATCH 1/10] cxgb3 - FW versioning
From: Divy Le Ray [EMAIL PROTECTED]
Clean up FW version checking.
The supported FW version is now 3.1.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/cxgb3_main.c | 15 ---
drivers/net/cxgb3/firmware_exports.h | 27 +++
drivers/net/cxgb3/t3_hw.c| 17 -
3 files changed, 47 insertions(+), 12 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 54c49ac..8044146 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -665,11 +665,8 @@ static int cxgb_up(struct adapter *adap)
if (!(adap-flags FULL_INIT_DONE)) {
err = t3_check_fw_version(adap);
- if (err) {
- dev_err(adap-pdev-dev,
- adapter FW is not compatible with driver\n);
+ if (err)
goto out;
- }
err = init_dummy_netdevs(adap);
if (err)
@@ -1002,10 +999,14 @@ static void get_drvinfo(struct net_devic
strcpy(info-bus_info, pci_name(adapter-pdev));
if (!fw_vers)
strcpy(info-fw_version, N/A);
- else
+ else {
snprintf(info-fw_version, sizeof(info-fw_version),
-%s %u.%u, (fw_vers 24) ? T : N,
-(fw_vers 12) 0xfff, fw_vers 0xfff);
+%s %u.%u.%u,
+G_FW_VERSION_TYPE(fw_vers) ? T : N,
+G_FW_VERSION_MAJOR(fw_vers),
+G_FW_VERSION_MINOR(fw_vers),
+G_FW_VERSION_MICRO(fw_vers));
+ }
}
static void get_strings(struct net_device *dev, u32 stringset, u8 * data)
diff --git a/drivers/net/cxgb3/firmware_exports.h
b/drivers/net/cxgb3/firmware_exports.h
index 3565f48..eea7d89 100644
--- a/drivers/net/cxgb3/firmware_exports.h
+++ b/drivers/net/cxgb3/firmware_exports.h
@@ -141,4 +141,31 @@
#define FW_WRC_NUM \
(65536 + FW_TUNNEL_NUM + FW_CTRL_NUM + FW_RI_NUM + FW_RX_PKT_NUM)
+/*
+ * FW type and version.
+ */
+#define S_FW_VERSION_TYPE 28
+#define M_FW_VERSION_TYPE 0xF
+#define V_FW_VERSION_TYPE(x) ((x) S_FW_VERSION_TYPE)
+#define G_FW_VERSION_TYPE(x) \
+(((x) S_FW_VERSION_TYPE) M_FW_VERSION_TYPE)
+
+#define S_FW_VERSION_MAJOR 16
+#define M_FW_VERSION_MAJOR 0xFFF
+#define V_FW_VERSION_MAJOR(x) ((x) S_FW_VERSION_MAJOR)
+#define G_FW_VERSION_MAJOR(x) \
+(((x) S_FW_VERSION_MAJOR) M_FW_VERSION_MAJOR)
+
+#define S_FW_VERSION_MINOR 8
+#define M_FW_VERSION_MINOR 0xFF
+#define V_FW_VERSION_MINOR(x) ((x) S_FW_VERSION_MINOR)
+#define G_FW_VERSION_MINOR(x) \
+(((x) S_FW_VERSION_MINOR) M_FW_VERSION_MINOR)
+
+#define S_FW_VERSION_MICRO 0
+#define M_FW_VERSION_MICRO 0xFF
+#define V_FW_VERSION_MICRO(x) ((x) S_FW_VERSION_MICRO)
+#define G_FW_VERSION_MICRO(x) \
+(((x) S_FW_VERSION_MICRO) M_FW_VERSION_MICRO)
+
#endif /* _FIRMWARE_EXPORTS_H_ */
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index a4e2e57..4545acb 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -826,6 +826,11 @@ static int t3_write_flash(struct adapter
return 0;
}
+enum fw_version_type {
+ FW_VERSION_N3,
+ FW_VERSION_T3
+};
+
/**
* t3_get_fw_version - read the firmware version
* @adapter: the adapter
@@ -849,19 +854,21 @@ int t3_check_fw_version(struct adapter *
{
int ret;
u32 vers;
+ unsigned int type, major, minor;
ret = t3_get_fw_version(adapter, vers);
if (ret)
return ret;
- /* Minor 0xfff means the FW is an internal development-only version. */
- if ((vers 0xfff) == 0xfff)
- return 0;
+ type = G_FW_VERSION_TYPE(vers);
+ major = G_FW_VERSION_MAJOR(vers);
+ minor = G_FW_VERSION_MINOR(vers);
- if (vers == 0x1002009)
+ if (type == FW_VERSION_T3 major == 3 minor == 1)
return 0;
- CH_ERR(adapter, found wrong FW version, driver needs version 2.9\n);
+ CH_ERR(adapter, found wrong FW version(%u.%u),
+ driver needs version 3.1\n, major, minor);
return -EINVAL;
}
-
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
[PATCH 6/10] cxgb3 - white space to tabs
From: Divy Le Ray [EMAIL PROTECTED] Use tabs in comments. Signed-off-by: Divy Le Ray [EMAIL PROTECTED] --- drivers/net/cxgb3/t3_hw.c | 30 +++--- 1 files changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c index 7112bac..35a7fab 100644 --- a/drivers/net/cxgb3/t3_hw.c +++ b/drivers/net/cxgb3/t3_hw.c @@ -14,21 +14,21 @@ #include sge_defs.h #include firmware_exports.h - /** - *t3_wait_op_done_val - wait until an operation is completed - *@adapter: the adapter performing the operation - *@reg: the register to check for completion - *@mask: a single-bit field within @reg that indicates completion - *@polarity: the value of the field when the operation is completed - *@attempts: number of check iterations - *@delay: delay in usecs between iterations - *@valp: where to store the value of the register at completion time - * - *Wait until an operation is completed by checking a bit in a register - *up to @attempts times. If @valp is not NULL the value of the register - *at the time it indicated completion is stored there. Returns 0 if the - *operation completes and -EAGAIN otherwise. - */ +/** + * t3_wait_op_done_val - wait until an operation is completed + * @adapter: the adapter performing the operation + * @reg: the register to check for completion + * @mask: a single-bit field within @reg that indicates completion + * @polarity: the value of the field when the operation is completed + * @attempts: number of check iterations + * @delay: delay in usecs between iterations + * @valp: where to store the value of the register at completion time + * + * Wait until an operation is completed by checking a bit in a register + * up to @attempts times. If @valp is not NULL the value of the register + * at the time it indicated completion is stored there. Returns 0 if the + * operation completes and -EAGAIN otherwise. + */ int t3_wait_op_done_val(struct adapter *adapter, int reg, u32 mask, int polarity, int attempts, int delay, u32 *valp) - 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
[PATCH 3/10] cxgb3 - remove SW Tx credits coalescing
From: Divy Le Ray [EMAIL PROTECTED]
Remove tx credit coalescing done in SW.
The HW is caring care of it already.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/sge.c | 75 +--
1 files changed, 14 insertions(+), 61 deletions(-)
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index ccea06a..8b3c824 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -1550,33 +1550,6 @@ static inline int rx_offload(struct t3cd
}
/**
- * update_tx_completed - update the number of processed Tx descriptors
- * @qs: the queue set to update
- * @idx: which Tx queue within the set to update
- * @credits: number of new processed descriptors
- * @tx_completed: accumulates credits for the queues
- *
- * Updates the number of completed Tx descriptors for a queue set's Tx
- * queue. On UP systems we updated the information immediately but on
- * MP we accumulate the credits locally and update the Tx queue when we
- * reach a threshold to avoid cache-line bouncing.
- */
-static inline void update_tx_completed(struct sge_qset *qs, int idx,
- unsigned int credits,
- unsigned int tx_completed[])
-{
-#ifdef CONFIG_SMP
- tx_completed[idx] += credits;
- if (tx_completed[idx] 32) {
- qs-txq[idx].processed += tx_completed[idx];
- tx_completed[idx] = 0;
- }
-#else
- qs-txq[idx].processed += credits;
-#endif
-}
-
-/**
* restart_tx - check whether to restart suspended Tx queues
* @qs: the queue set to resume
*
@@ -1656,13 +1629,12 @@ static void rx_eth(struct adapter *adap,
* handle_rsp_cntrl_info - handles control information in a response
* @qs: the queue set corresponding to the response
* @flags: the response control flags
- * @tx_completed: accumulates completion credits for the Tx queues
*
* Handles the control information of an SGE response, such as GTS
* indications and completion credits for the queue set's Tx queues.
+ * HW coalesces credits, we don't do any extra SW coalescing.
*/
-static inline void handle_rsp_cntrl_info(struct sge_qset *qs, u32 flags,
-unsigned int tx_completed[])
+static inline void handle_rsp_cntrl_info(struct sge_qset *qs, u32 flags)
{
unsigned int credits;
@@ -1671,37 +1643,21 @@ static inline void handle_rsp_cntrl_info
clear_bit(TXQ_RUNNING, qs-txq[TXQ_ETH].flags);
#endif
- /* ETH credits are already coalesced, return them immediately. */
credits = G_RSPD_TXQ0_CR(flags);
if (credits)
qs-txq[TXQ_ETH].processed += credits;
+ credits = G_RSPD_TXQ2_CR(flags);
+ if (credits)
+ qs-txq[TXQ_CTRL].processed += credits;
+
# if USE_GTS
if (flags F_RSPD_TXQ1_GTS)
clear_bit(TXQ_RUNNING, qs-txq[TXQ_OFLD].flags);
# endif
- update_tx_completed(qs, TXQ_OFLD, G_RSPD_TXQ1_CR(flags), tx_completed);
- update_tx_completed(qs, TXQ_CTRL, G_RSPD_TXQ2_CR(flags), tx_completed);
-}
-
-/**
- * flush_tx_completed - returns accumulated Tx completions to Tx queues
- * @qs: the queue set to update
- * @tx_completed: pending completion credits to return to Tx queues
- *
- * Updates the number of completed Tx descriptors for a queue set's Tx
- * queues with the credits pending in @tx_completed. This does something
- * only on MP systems as on UP systems we return the credits immediately.
- */
-static inline void flush_tx_completed(struct sge_qset *qs,
- unsigned int tx_completed[])
-{
-#if defined(CONFIG_SMP)
- if (tx_completed[TXQ_OFLD])
- qs-txq[TXQ_OFLD].processed += tx_completed[TXQ_OFLD];
- if (tx_completed[TXQ_CTRL])
- qs-txq[TXQ_CTRL].processed += tx_completed[TXQ_CTRL];
-#endif
+ credits = G_RSPD_TXQ1_CR(flags);
+ if (credits)
+ qs-txq[TXQ_OFLD].processed += credits;
}
/**
@@ -1784,7 +1740,7 @@ static int process_responses(struct adap
struct sge_rspq *q = qs-rspq;
struct rsp_desc *r = q-desc[q-cidx];
int budget_left = budget;
- unsigned int sleeping = 0, tx_completed[3] = { 0, 0, 0 };
+ unsigned int sleeping = 0;
struct sk_buff *offload_skbs[RX_BUNDLE_SIZE];
int ngathered = 0;
@@ -1837,7 +1793,7 @@ static int process_responses(struct adap
if (flags RSPD_CTRL_MASK) {
sleeping |= flags RSPD_GTS_MASK;
- handle_rsp_cntrl_info(qs, flags, tx_completed);
+ handle_rsp_cntrl_info(qs, flags);
}
r++;
@@ -1868,7 +1824,6 @@ static int process_responses(struct adap
--budget_left;
}
- flush_tx_completed(qs, tx_completed);
[PATCH 4/10] cxgb3 - bogus status error string
From: Divy Le Ray [EMAIL PROTECTED]
Remove a status error string from the pci-x context
and add it where it belongs - the pci-e context.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/t3_hw.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 4545acb..2215400 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -1181,7 +1181,6 @@ static int t3_handle_intr_status(struct
static void pci_intr_handler(struct adapter *adapter)
{
static const struct intr_info pcix1_intr_info[] = {
- { F_PEXERR, PCI PEX error, -1, 1 },
{F_MSTDETPARERR, PCI master detected parity error, -1, 1},
{F_SIGTARABT, PCI signaled target abort, -1, 1},
{F_RCVTARABT, PCI received target abort, -1, 1},
@@ -1218,6 +1217,7 @@ static void pci_intr_handler(struct adap
static void pcie_intr_handler(struct adapter *adapter)
{
static const struct intr_info pcie_intr_info[] = {
+ {F_PEXERR, PCI PEX error, -1, 1},
{F_UNXSPLCPLERRR,
PCI unexpected split completion DMA read error, -1, 1},
{F_UNXSPLCPLERRC,
-
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
