[PATCH] No need to inc/dec packet_socks_nr if PACKET_REFCNT_DEBUG is not set
No need to inc/dec packet_socks_nr if PACKET_REFCNT_DEBUG is not set. Signed-off-by: Denis V. Lunev [EMAIL PROTECTED] --- ./net/packet/af_packet.c.packetrefcnt 2007-11-08 13:48:22.0 +0300 +++ ./net/packet/af_packet.c2007-11-08 13:54:29.0 +0300 @@ -135,7 +135,9 @@ dev-hard_header == NULL (ll header is a packet classifier depends on it. */ +#ifdef PACKET_REFCNT_DEBUG static atomic_t packet_socks_nr; +#endif /* Private packet socket structures. */ @@ -232,8 +234,8 @@ static void packet_sock_destruct(struct return; } - atomic_dec(packet_socks_nr); #ifdef PACKET_REFCNT_DEBUG + atomic_dec(packet_socks_nr); printk(KERN_DEBUG PACKET socket %p is free, %d are alive\n, sk, atomic_read(packet_socks_nr)); #endif } @@ -1005,7 +1007,9 @@ static int packet_create(struct net *net po-num = proto; sk-sk_destruct = packet_sock_destruct; +#ifdef PACKET_REFCNT_DEBUG atomic_inc(packet_socks_nr); +#endif /* * Attach a protocol block - 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] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
On Thu, 8 Nov 2007 08:18:54 + Al Viro [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote: config AX88796 tristate ASIX AX88796 NE2000 clone support - depends on ARM || MIPS + depends on ARM || MIPS || SUPERH You know, that really sucks more and more. How about doing the following: a) making it depend on PLAT_HAS_AX88796 b) adding selects for all subarchitectures that have the corresponding platform device and setting that as a uniform policy for platform drivers? Yup, but we should be religious about the naming conventions. ARCH_HAS_ and PLAT_HAS_ followed by the exact name of the thus-enabled config option. For things like SM501 we would do config MFD_SM501 depends on PCI || PLAT_HAS_SM501 etc. See, bug. That should be PLAT_HAS_MFD_SM501 Seriously, folks, we are getting shitloads of platform drivers with no dependencies whatsoever, needed on a handful of targets and occasionally failing to build on unrelated architectures. Moreover, having a list of architectures in dependencies for each of those suckers is a PITA from the conflict POV. Not to mention platform drivers that fall into the mainline kernel with not a single platform device for them, etc. Comments? grep PPC drivers/*/Kconfig and weep. - 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: [PATCH] iSCSI fix endieness of digest to be network byte order
On Thu, Nov 08, 2007 at 05:04:09PM +0900, FUJITA Tomonori wrote:
I wonder why crc32c isn't used directly while crc32 is used directly
since they vary by only the polynomial.
It's because iSCSI uses it with scatterlists. The crypto layer
provides a nice interface for that while using it directly would
require the user to do the scatterlist walk.
Using crc32c directly might enable us to kill net/sctp/crc32c.c and
merge lib/crc32.c and lib/libcrc32c?
I'm pretty sure we can kill net/sctp/crc32c.c today by converting
it over to use the crypto interface.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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 19/24] [IPSEC]: Merge most of the output path
On Thu, Nov 08, 2007 at 12:23:29PM +0100, Patrick McHardy wrote:
We have a few places that go though the trouble of selecting the
correct hook value for the address family, even though the numerical
values are identical. How about we just get rid of the different
naming and use NF_INET_... for both IPv4 and IPv6?
Nice work! Thanks Patrick.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] No need to inc/dec packet_socks_nr if PACKET_REFCNT_DEBUG is not set
pls disregard this, Pavel have sent one similar already Denis V. Lunev wrote: No need to inc/dec packet_socks_nr if PACKET_REFCNT_DEBUG is not set. Signed-off-by: Denis V. Lunev [EMAIL PROTECTED] --- ./net/packet/af_packet.c.packetrefcnt 2007-11-08 13:48:22.0 +0300 +++ ./net/packet/af_packet.c 2007-11-08 13:54:29.0 +0300 @@ -135,7 +135,9 @@ dev-hard_header == NULL (ll header is a packet classifier depends on it. */ +#ifdef PACKET_REFCNT_DEBUG static atomic_t packet_socks_nr; +#endif /* Private packet socket structures. */ @@ -232,8 +234,8 @@ static void packet_sock_destruct(struct return; } - atomic_dec(packet_socks_nr); #ifdef PACKET_REFCNT_DEBUG + atomic_dec(packet_socks_nr); printk(KERN_DEBUG PACKET socket %p is free, %d are alive\n, sk, atomic_read(packet_socks_nr)); #endif } @@ -1005,7 +1007,9 @@ static int packet_create(struct net *net po-num = proto; sk-sk_destruct = packet_sock_destruct; +#ifdef PACKET_REFCNT_DEBUG atomic_inc(packet_socks_nr); +#endif /* * Attach a protocol block - 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
[PATCH] [PKT_SCHED] CLS_U32: Use ffs() instead of C code on hash mask to get first set bit.
Computing the rank of the first set bit in the hash mask (for using later
in u32_hash_fold()) was done with plain C code. Using ffs() instead makes
the code more readable and improves performance (since ffs() is better
optimized in assembler).
Using the conditional operator on hash mask before applying ntohl() also
saves one ntohl() call if mask is 0.
Signed-off-by: Radu Rendec [EMAIL PROTECTED]
---
net/sched/cls_u32.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index 5317102..c390082 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -613,17 +613,7 @@ static int u32_change(struct tcf_proto *tp, unsigned long
base, u32 handle,
memcpy(n-sel, s, sizeof(*s) + s-nkeys*sizeof(struct tc_u32_key));
n-ht_up = ht;
n-handle = handle;
-{
- u8 i = 0;
- u32 mask = ntohl(s-hmask);
- if (mask) {
- while (!(mask 1)) {
- i++;
- mask=1;
- }
- }
- n-fshift = i;
-}
+ n-fshift = s-hmask ? ffs(ntohl(s-hmask)) - 1 : 0;
#ifdef CONFIG_CLS_U32_MARK
if (tb[TCA_U32_MARK-1]) {
--
1.5.3.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] [PKT_SCHED] CLS_U32: Use ffs() instead of C code on hash mask to get first set bit.
On Thu, Nov 08, 2007 at 01:07:47PM +0200, Radu Rendec wrote:
Computing the rank of the first set bit in the hash mask (for using later
in u32_hash_fold()) was done with plain C code. Using ffs() instead makes
the code more readable and improves performance (since ffs() is better
optimized in assembler).
Using the conditional operator on hash mask before applying ntohl() also
saves one ntohl() call if mask is 0.
Signed-off-by: Radu Rendec [EMAIL PROTECTED]
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
net/sched/cls_u32.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index 5317102..c390082 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -613,17 +613,7 @@ static int u32_change(struct tcf_proto *tp, unsigned
long base, u32 handle,
memcpy(n-sel, s, sizeof(*s) + s-nkeys*sizeof(struct tc_u32_key));
n-ht_up = ht;
n-handle = handle;
-{
- u8 i = 0;
- u32 mask = ntohl(s-hmask);
- if (mask) {
- while (!(mask 1)) {
- i++;
- mask=1;
- }
- }
- n-fshift = i;
-}
+ n-fshift = s-hmask ? ffs(ntohl(s-hmask)) - 1 : 0;
#ifdef CONFIG_CLS_U32_MARK
if (tb[TCA_U32_MARK-1]) {
--
1.5.3.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
[RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote: config AX88796 tristate ASIX AX88796 NE2000 clone support - depends on ARM || MIPS + depends on ARM || MIPS || SUPERH You know, that really sucks more and more. How about doing the following: a) making it depend on PLAT_HAS_AX88796 b) adding selects for all subarchitectures that have the corresponding platform device and setting that as a uniform policy for platform drivers? For things like SM501 we would do config MFD_SM501 depends on PCI || PLAT_HAS_SM501 etc. Seriously, folks, we are getting shitloads of platform drivers with no dependencies whatsoever, needed on a handful of targets and occasionally failing to build on unrelated architectures. Moreover, having a list of architectures in dependencies for each of those suckers is a PITA from the conflict POV. Not to mention platform drivers that fall into the mainline kernel with not a single platform device for them, etc. Comments? - 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: ax88796: add superh to kconfig dependencies
On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote: ax88796: add superh to kconfig dependencies This patch adds sh architecture support to the ax88796 kconfig. Signed-off-by: Magnus Damm [EMAIL PROTECTED] --- This patch was posted about a month ago but never picked up: http://www.mail-archive.com/netdev@vger.kernel.org/msg50018.html The rest of the sh support is already included in rc1. Please apply. And as per: http://www.mail-archive.com/netdev@vger.kernel.org/msg50027.html Still-acked-by: Paul Mundt [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
[PATCH] ipconfig.c : implement DHCP Class-identifier
This patch implements the DHCP Class identifier (see rfc1533) which is
used by DHCP clients to optionally identify the type and configuration of
a DHCP client which is send as a string to the server. For example, the
identifier may encode the client's hardware configuration. If the newly
introduced kernel-parameter 'dhcpclass' is set, then the kernel sends
the given string in its DHCP-request to the server.
If the option is omitted, the behaviour is as before without this patch.
Patch applies to:
Version:2.6.23.1
File: net/ipv4/ipconfig.c
Signed-off-by: Rainer Jochem [EMAIL PROTECTED]
---
--- net/ipv4/ipconfig.c.orig2007-11-08 14:54:11.001662860 +0100
+++ net/ipv4/ipconfig.c 2007-11-08 14:54:15.961480524 +0100
@@ -139,6 +139,8 @@ __be32 ic_servaddr = NONE; /* Boot serve
__be32 root_server_addr = NONE;/* Address of NFS server */
u8 root_server_path[256] = { 0, }; /* Path to mount as root */
+char vendor_class_identifier[256] = { 0, }; /* vendor class identifier */
+
/* Persistent data: */
static int ic_proto_used; /* Protocol used, if any */
@@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
*e++ = sizeof(ic_req_params);
memcpy(e, ic_req_params, sizeof(ic_req_params));
e += sizeof(ic_req_params);
+
+ // Send it only if the according kernel parameter was set
+ if (*vendor_class_identifier) {
+ printk(KERN_INFO Sending class identifier \%s\\n,
+ vendor_class_identifier);
+ *e++ = 60; /* Class-identifier */
+ *e++ = strlen(vendor_class_identifier);
+ memcpy(e, vendor_class_identifier,
+ strlen(vendor_class_identifier));
+ e += strlen(vendor_class_identifier);
+ }
}
*e++ = 255; /* End of the list */
@@ -1507,5 +1520,14 @@ static int __init nfsaddrs_config_setup(
return ip_auto_config_setup(addrs);
}
+static int __init vendor_class_identifier_setup(char *addrs)
+{
+ if (strlcpy(vendor_class_identifier, addrs, 250) 250)
+ printk(KERN_WARNING vendorclass too long, truncated to \%s\,
+ vendor_class_identifier);
+ return 1;
+}
+
__setup(ip=, ip_auto_config_setup);
__setup(nfsaddrs=, nfsaddrs_config_setup);
+__setup(dhcpclass=, vendor_class_identifier_setup);
--- ../linux-2.6.23.1/Documentation/kernel-parameters.txt 2007-10-12
18:43:44.0 +0200
+++ Documentation/kernel-parameters.txt 2007-10-24 17:02:22.441454955 +0200
@@ -533,6 +533,10 @@ and is between 256 and 4096 characters.
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
+ dhcpclass= [KNL]
+ Set DHCP Vendor Class Identifier to be sent
+ by the client.
+
digi= [HW,SERIAL]
IO parameters + enable/disable command.
-
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
Please pull 'fixes-jgarzik' branch of wireless-2.6 (3rd time is the charm?)
Jeff, OK, I think things are settled now. I apologize for the confusion. These are fixes intended for 2.6.24. Please note that three of the patches from Michael Buesch in the list below were already sent to you directed for 2.6.25. Upon further review, I think they belong in 2.6.24 instead. I cherry-picked them, so I'm fairly certain git will be smart enough to drop them from your 2.6.25 branch when you rebase. Please let me know if there are any problems. Thanks! John --- Individual patches are available here: http://www.kernel.org/pub//linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/ --- The following changes since commit 2655e2cee2d77459fcb7e10228259e4ee0328697: Alan Cox (1): ata_piix: Add additional PCI identifier for 40 wire short cable are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik Holger Schurig (1): libertas: fixes for slow hardware Ivo van Doorn (1): rt2x00: Block adhoc master mode John W. Linville (1): hermes: clarify Intel reference in Kconfig help Marcelo Tosatti (1): libertas: properly account for queue commands Michael Buesch (7): b43: pcmcia-host initialization bugfixes b43: Fix rfkill callback deadlock b43: debugfs SHM read buffer overrun fix b43: Rewrite and fix rfkill init b43: properly request pcmcia IRQ b43legacy: Fix sparse warning b43: Fix kconfig dependencies for rfkill and leds Pierre Ossman (1): libertas: make if_sdio align packets Randy Dunlap (1): hostap: fix section mismatch warning Roel Kluin (1): ipw2100: fix postfix decrement errors Stefano Brivio (4): b43legacy: fix possible buffer overrun in debugfs b43legacy: add me as maintainer and fix URLs b43: fix shared IRQ race condition b43legacy: fix shared IRQ race condition MAINTAINERS | 10 ++- drivers/net/wireless/Kconfig |2 +- drivers/net/wireless/b43/Kconfig | 10 ++- drivers/net/wireless/b43/debugfs.c |2 +- drivers/net/wireless/b43/main.c | 19 +++--- drivers/net/wireless/b43/pcmcia.c| 52 +- drivers/net/wireless/b43/rfkill.c| 115 + drivers/net/wireless/b43/rfkill.h| 14 +--- drivers/net/wireless/b43legacy/debugfs.c |2 +- drivers/net/wireless/b43legacy/main.c| 21 +++--- drivers/net/wireless/hostap/hostap_pci.c |6 +- drivers/net/wireless/ipw2100.c |4 +- drivers/net/wireless/libertas/cmd.c | 10 ++- drivers/net/wireless/libertas/if_cs.c|7 ++- drivers/net/wireless/libertas/if_sdio.c |4 +- drivers/net/wireless/rt2x00/rt2x00mac.c |8 ++ 16 files changed, 154 insertions(+), 132 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1c7c229..6a97027 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -787,23 +787,25 @@ B43 WIRELESS DRIVER P: Michael Buesch M: [EMAIL PROTECTED] P: Stefano Brivio -M: [EMAIL PROTECTED] +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -W: http://bcm43xx.berlios.de/ +W: http://linuxwireless.org/en/users/Drivers/b43 S: Maintained B43LEGACY WIRELESS DRIVER P: Larry Finger M: [EMAIL PROTECTED] +P: Stefano Brivio +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -W: http://bcm43xx.berlios.de/ +W: http://linuxwireless.org/en/users/Drivers/b43 S: Maintained BCM43XX WIRELESS DRIVER (SOFTMAC BASED VERSION) P: Larry Finger M: [EMAIL PROTECTED] P: Stefano Brivio -M: [EMAIL PROTECTED] +M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://bcm43xx.berlios.de/ S: Maintained diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig index dae5c8d..2b733c5 100644 --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -325,7 +325,7 @@ config HERMES Cabletron/EnteraSys Roamabout, ELSA AirLancer, MELCO Buffalo, Avaya, IBM High Rate Wireless, Farralon Syyline, Samsung MagicLAN, Netgear MA401, LinkSys WPC-11, D-Link DWL-650, 3Com AirConnect, Intel - PRO/Wireless, and Symbol Spectrum24 High Rate amongst others. + IPW2011, and Symbol Spectrum24 High Rate amongst others. This option includes the guts of the driver, but in order to actually use a card you will also need to enable support for PCMCIA diff --git a/drivers/net/wireless/b43/Kconfig b/drivers/net/wireless/b43/Kconfig index e3c573e..fdbc351 100644 --- a/drivers/net/wireless/b43/Kconfig +++ b/drivers/net/wireless/b43/Kconfig @@ -61,16 +61,18 @@ config B43_PCMCIA If unsure, say N. -# LED support +# This config option automatically enables b43 LEDS support, +# if it's possible. config B43_LEDS bool - depends on B43 MAC80211_LEDS + depends on B43 MAC80211_LEDS (LEDS_CLASS = y ||
Re: Please pull 'fixes-jgarzik' branch of wireless-2.6 (this time for real!)
Clearly having a bad week...just ignore this thread and I'll post a
totally new request shortly.
Thanks,
John
On Wed, Nov 07, 2007 at 08:34:29PM -0500, John W. Linville wrote:
On Wed, Nov 07, 2007 at 02:24:19PM -0500, Jeff Garzik wrote:
On Wed, Nov 07, 2007 at 02:13:29PM -0500, John W. Linville wrote:
Jeff,
If you haven't already pulled this then please hold-off. I'll post
a new request soon.
Haven't pulled yet...
Jeff,
These fixes are additive on top of the previous request in this thread.
That request is archived here:
http://marc.info/?l=linux-wirelessm=119438263704232w=2
Also, note that the first three from Michael Buesch in the list below
were already sent to you directed for 2.6.25, but I think they belong in
2.6.24 instead. I cherry-picked them, so I'm fairly certain git will be
smart enough to drop them from your 2.6.25 branch when you rebase.
Let me know if there are any problems!
Thanks,
John
---
The entire series (i.e. both from yesterday and today) is available
here:
http://www.kernel.org/pub//linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
The following changes since commit 33a463d0c82cad08a64526c217f6d835a51dfc1c:
Michael Buesch (1):
b43: pcmcia-host initialization bugfixes
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
fixes-jgarzik
Michael Buesch (6):
b43: Fix rfkill callback deadlock
b43: debugfs SHM read buffer overrun fix
b43: Rewrite and fix rfkill init
b43: properly request pcmcia IRQ
b43legacy: Fix sparse warning
b43: Fix kconfig dependencies for rfkill and leds
Stefano Brivio (4):
b43legacy: fix possible buffer overrun in debugfs
b43legacy: add me as maintainer and fix URLs
b43: fix shared IRQ race condition
b43legacy: fix shared IRQ race condition
MAINTAINERS | 10 ++-
drivers/net/wireless/b43/Kconfig | 10 ++-
drivers/net/wireless/b43/debugfs.c |2 +-
drivers/net/wireless/b43/main.c | 19 +++---
drivers/net/wireless/b43/pcmcia.c|8 ++
drivers/net/wireless/b43/rfkill.c| 115 +
drivers/net/wireless/b43/rfkill.h| 14 +---
drivers/net/wireless/b43legacy/debugfs.c |2 +-
drivers/net/wireless/b43legacy/main.c| 21 +++---
9 files changed, 100 insertions(+), 101 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c7c229..6a97027 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -787,23 +787,25 @@ B43 WIRELESS DRIVER
P: Michael Buesch
M: [EMAIL PROTECTED]
P: Stefano Brivio
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
-W: http://bcm43xx.berlios.de/
+W: http://linuxwireless.org/en/users/Drivers/b43
S: Maintained
B43LEGACY WIRELESS DRIVER
P: Larry Finger
M: [EMAIL PROTECTED]
+P: Stefano Brivio
+M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
-W: http://bcm43xx.berlios.de/
+W: http://linuxwireless.org/en/users/Drivers/b43
S: Maintained
BCM43XX WIRELESS DRIVER (SOFTMAC BASED VERSION)
P: Larry Finger
M: [EMAIL PROTECTED]
P: Stefano Brivio
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
W: http://bcm43xx.berlios.de/
S: Maintained
diff --git a/drivers/net/wireless/b43/Kconfig
b/drivers/net/wireless/b43/Kconfig
index e3c573e..fdbc351 100644
--- a/drivers/net/wireless/b43/Kconfig
+++ b/drivers/net/wireless/b43/Kconfig
@@ -61,16 +61,18 @@ config B43_PCMCIA
If unsure, say N.
-# LED support
+# This config option automatically enables b43 LEDS support,
+# if it's possible.
config B43_LEDS
bool
- depends on B43 MAC80211_LEDS
+ depends on B43 MAC80211_LEDS (LEDS_CLASS = y || LEDS_CLASS = B43)
default y
-# RFKILL support
+# This config option automatically enables b43 RFKILL support,
+# if it's possible.
config B43_RFKILL
bool
- depends on B43 RFKILL RFKILL_INPUT INPUT_POLLDEV
+ depends on B43 (RFKILL = y || RFKILL = B43) RFKILL_INPUT
(INPUT_POLLDEV = y || INPUT_POLLDEV = B43)
default y
config B43_DEBUG
diff --git a/drivers/net/wireless/b43/debugfs.c
b/drivers/net/wireless/b43/debugfs.c
index 734e70e..ef0075d 100644
--- a/drivers/net/wireless/b43/debugfs.c
+++ b/drivers/net/wireless/b43/debugfs.c
@@ -128,7 +128,7 @@ static ssize_t shm_read_file(struct b43_wldev *dev,
__le16 *le16buf = (__le16 *)buf;
for (i = 0; i 0x1000; i++) {
- if (bufsize = 0)
+ if (bufsize sizeof(tmp))
break;
tmp = b43_shm_read16(dev, B43_SHM_SHARED, 2 * i);
le16buf[i] = cpu_to_le16(tmp);
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 5058e60..2b17c1d 100644
---
[PATCH] drivers/net: remove duplicated defines
Remove duplicated defines. Signed-off-by: Nicolas Kaiser [EMAIL PROTECTED] --- drivers/net/cxgb3/regs.h | 37 -- drivers/net/e1000e/defines.h | 23 +- drivers/net/ehea/ehea_phyp.c |7 - drivers/net/hp100.c |6 drivers/net/niu.h |1 drivers/net/tokenring/smctr.h |6 drivers/net/tulip/de4x5.c |6 drivers/net/usb/rtl8150.c | 26 - drivers/net/wan/dscc4.c |1 drivers/net/wireless/atmel.c |1 drivers/net/wireless/iwlwifi/iwl-eeprom.h |3 -- drivers/net/wireless/libertas/host.h |1 12 files changed, 3 insertions(+), 115 deletions(-) diff -ur a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h --- a/drivers/net/cxgb3/regs.h 2007-11-07 11:26:12.0 +0100 +++ b/drivers/net/cxgb3/regs.h 2007-11-07 21:55:15.0 +0100 @@ -555,10 +555,6 @@ #define V_BUSY(x) ((x) S_BUSY) #define F_BUSYV_BUSY(1U) -#define S_BUSY31 -#define V_BUSY(x) ((x) S_BUSY) -#define F_BUSYV_BUSY(1U) - #define A_MC7_EXT_MODE1 0x108 #define A_MC7_EXT_MODE2 0x10c @@ -619,14 +615,6 @@ #define A_MC7_CAL 0x128 -#define S_BUSY31 -#define V_BUSY(x) ((x) S_BUSY) -#define F_BUSYV_BUSY(1U) - -#define S_BUSY31 -#define V_BUSY(x) ((x) S_BUSY) -#define F_BUSYV_BUSY(1U) - #define S_CAL_FAULT30 #define V_CAL_FAULT(x) ((x) S_CAL_FAULT) #define F_CAL_FAULTV_CAL_FAULT(1U) @@ -685,7 +673,6 @@ #define V_OP(x) ((x) S_OP) #define F_OPV_OP(1U) -#define F_OPV_OP(1U) #define A_SF_OP 0x6dc #define A_MC7_BIST_ADDR_BEG 0x168 @@ -700,8 +687,6 @@ #define V_CONT(x) ((x) S_CONT) #define F_CONTV_CONT(1U) -#define F_CONTV_CONT(1U) - #define A_MC7_INT_ENABLE 0x178 #define S_AE17 @@ -805,8 +790,6 @@ #define V_NICMODE(x) ((x) S_NICMODE) #define F_NICMODEV_NICMODE(1U) -#define F_NICMODEV_NICMODE(1U) - #define S_IPV6ENABLE15 #define V_IPV6ENABLE(x) ((x) S_IPV6ENABLE) #define F_IPV6ENABLEV_IPV6ENABLE(1U) @@ -1268,27 +1251,15 @@ #define A_ULPRX_STAG_ULIMIT 0x530 #define A_ULPRX_RQ_LLIMIT 0x534 -#define A_ULPRX_RQ_LLIMIT 0x534 #define A_ULPRX_RQ_ULIMIT 0x538 -#define A_ULPRX_RQ_ULIMIT 0x538 #define A_ULPRX_PBL_LLIMIT 0x53c #define A_ULPRX_PBL_ULIMIT 0x540 -#define A_ULPRX_PBL_ULIMIT 0x540 #define A_ULPRX_TDDP_TAGMASK 0x524 -#define A_ULPRX_RQ_LLIMIT 0x534 -#define A_ULPRX_RQ_LLIMIT 0x534 - -#define A_ULPRX_RQ_ULIMIT 0x538 -#define A_ULPRX_RQ_ULIMIT 0x538 - -#define A_ULPRX_PBL_ULIMIT 0x540 -#define A_ULPRX_PBL_ULIMIT 0x540 - #define A_ULPTX_CONFIG 0x580 #define S_CFG_RR_ARB0 @@ -1615,8 +1586,6 @@ #define A_SF_DATA 0x6d8 -#define A_SF_OP 0x6dc - #define S_BYTECNT1 #define M_BYTECNT0x3 #define V_BYTECNT(x) ((x) S_BYTECNT) @@ -1747,8 +1716,6 @@ #define V_TMMODE(x) ((x) S_TMMODE) #define F_TMMODEV_TMMODE(1U) -#define F_TMMODEV_TMMODE(1U) - #define A_MC5_DB_ROUTING_TABLE_INDEX 0x70c #define A_MC5_DB_FILTER_TABLE 0x710 @@ -2110,8 +2077,6 @@ #define V_TXACTENABLE(x) ((x) S_TXACTENABLE) #define F_TXACTENABLEV_TXACTENABLE(1U) -#define A_XGM_SERDES_CTRL0 0x8e0 - #define S_RESET323 #define V_RESET3(x) ((x) S_RESET3) #define F_RESET3V_RESET3(1U) @@ -2240,8 +2205,6 @@ #define V_CMULOCK(x) ((x) S_CMULOCK) #define F_CMULOCKV_CMULOCK(1U) -#define A_XGM_RX_MAX_PKT_SIZE_ERR_CNT 0x9a4 - #define A_XGM_TX_SPI4_SOP_EOP_CNT 0x9a8 #define S_TXSPI4SOPCNT16 diff -ur a/drivers/net/e1000e/defines.h b/drivers/net/e1000e/defines.h --- a/drivers/net/e1000e/defines.h 2007-11-07 11:26:13.0 +0100 +++ b/drivers/net/e1000e/defines.h 2007-11-07 22:16:15.0 +0100 @@ -29,6 +29,8 @@ #ifndef _E1000_DEFINES_H_ #define _E1000_DEFINES_H_ +/* Transmit Descriptor bit definitions */ +#define E1000_TXD_DTYP_D 0x0010 /* Data Descriptor */ #define E1000_TXD_POPTS_IXSM 0x01 /* Insert IP checksum */ #define E1000_TXD_POPTS_TXSM 0x02 /* Insert TCP/UDP checksum */ #define E1000_TXD_CMD_EOP0x0100 /* End of Packet */ @@ -256,27 +258,6 @@ #define E1000_LEDCTL_MODE_LED_ON0xE #define E1000_LEDCTL_MODE_LED_OFF 0xF -/* Transmit Descriptor bit definitions */ -#define E1000_TXD_DTYP_D 0x0010 /* Data Descriptor */ -#define E1000_TXD_POPTS_IXSM 0x01 /* Insert IP checksum */ -#define E1000_TXD_POPTS_TXSM 0x02 /* Insert TCP/UDP checksum */ -#define E1000_TXD_CMD_EOP0x0100 /* End of Packet */ -#define E1000_TXD_CMD_IFCS 0x0200 /* Insert FCS (Ethernet CRC) */ -#define E1000_TXD_CMD_IC 0x0400 /* Insert Checksum */ -#define E1000_TXD_CMD_RS 0x0800 /* Report Status */ -#define E1000_TXD_CMD_RPS0x1000 /* Report Packet Sent */ -#define E1000_TXD_CMD_DEXT 0x2000 /* Descriptor extension (0 = legacy)
Re: [PATCH] [PKT_SCHED] CLS_U32: Use ffs() instead of C code on hash mask to get first set bit.
On Thu, 2007-08-11 at 13:07 +0200, Radu Rendec wrote: Computing the rank of the first set bit in the hash mask (for using later in u32_hash_fold()) was done with plain C code. Using ffs() instead makes the code more readable and improves performance (since ffs() is better optimized in assembler). Using the conditional operator on hash mask before applying ntohl() also saves one ntohl() call if mask is 0. Signed-off-by: Radu Rendec [EMAIL PROTECTED] Acked-by: Jamal Hadi Salim [EMAIL PROTECTED] cheers, jamal - 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 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote: Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. Depending on how the review goes, a follow-on patch to u-boot will be sent out that fixes up the phy-connection-type in the device tree (from rgmii-id to rgmii-rxid iff on mpc8360rev2.1). I've upgraded CPU to rev2.1, board rev0.3. Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is the results: If I use -rxid, then geth not able to transmit anything. With -txid geth not able to receive anything. With just -id everything works fine though... Maybe there should be another condition, in addition to cpu rev2.1? Thanks, Kim mpc8360 rev 2.1 erratum #2: --- Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII when working with Rev Pilot MDS for proper RGMII operation: IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2) IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1) IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's) The Phy (Marvell 88e) should be configured NOT to work with RGMII delay for TxD. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 - 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 04/05] ipv6: RFC4214 Support
In article [EMAIL PROTECTED] (at Wed, 7 Nov 2007 11:12:47 -0800), Templin, Fred L [EMAIL PROTECTED] says: The goal was to avoid requiring changes to applications such as 'iproute2', i.e., the intention was for a standalone code insertion point within the kernel itself. What do you suggest? Agreed, magic names are evil. Change iproute2 utilities, if it is more logical for administration. This being an experimental release, I would prefer to go forward with a standalone kernel solution for the first iteration then come back with the iproute2 changes at a later time. IMHO, we should only touch iproute2 once, and it should be an architected solution - not just a quick hack. For the short term, timeliness of interoperability testing with the other major OS's should be the highest priority, IMHO. Hmm, what is missing from API POV? Since even if you do not change iproute2 now, users may need to change their configuration script twice anyway, we should be careful. --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: Fwd: Re: [PATCH] iSCSI fix endieness of digest to be network byte order
Herbert Xu wrote: On Thu, Nov 08, 2007 at 05:04:09PM +0900, FUJITA Tomonori wrote: I wonder why crc32c isn't used directly while crc32 is used directly since they vary by only the polynomial. It's because iSCSI uses it with scatterlists. The crypto layer provides a nice interface for that while using it directly would require the user to do the scatterlist walk. Using crc32c directly might enable us to kill net/sctp/crc32c.c and merge lib/crc32.c and lib/libcrc32c? I'm pretty sure we can kill net/sctp/crc32c.c today by converting it over to use the crypto interface. Funny, I looked for crc32c in the lib just the other week and didn't spot it. Need to look harder :) -vlad - 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: 2.6.24-rc1-gb4f5550 oops
On Thursday, 8 of November 2007, Grant Wilson wrote: On Thu, 8 Nov 2007 01:06:21 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 5 of November 2007, Grant Wilson wrote: Hi, I got this oops on 2.6.24-rc1-641-gb4f5550: (1) Is this reproducible? (2) Did it happen previously on your system? [18073.371126] Unable to handle kernel NULL pointer dereference at 0120 RIP: [18073.371134] [8023572e] check_preempt_wakeup+0x6e/0x110 This has now happened twice - the second time was last night when running 2.6.24-rc2. Here's that second occurrence: [ 7224.233621] Unable to handle kernel NULL pointer dereference at 0120 RIP: [ 7224.233631] [8023572e] check_preempt_wakeup+0x6e/0x110 [ 7224.233644] PGD 0 [ 7224.233650] Oops: [1] PREEMPT SMP [ 7224.233660] CPU 0 [ 7224.233716] Modules linked in: [ 7224.233722] Pid: 7622, comm: ssh Not tainted 2.6.24-rc2 #1 [ 7224.233726] RIP: 0010:[8023572e] [8023572e] check_preempt_wakeup+0x6e/0x110 [ 7224.233735] RSP: 0018:81000aafba78 EFLAGS: 00010006 [ 7224.233738] RAX: RBX: RCX: 5745 [ 7224.233743] RDX: 81000442fbf0 RSI: 810006c96860 RDI: 810004438b80 [ 7224.233748] RBP: 81000aafbaa8 R08: 007e8e25cf71 R09: [ 7224.233752] R10: 81000442fbf0 R11: 0001 R12: 810007479d80 [ 7224.233756] R13: 810006c96860 R14: 810009924860 R15: 81000442b8e0 [ 7224.233760] FS: 2b8bf089d350() GS:808d7000() knlGS: [ 7224.233764] CS: 0010 DS: ES: CR0: 8005003b [ 7224.233768] CR2: 0120 CR3: 0ab3f000 CR4: 06e0 [ 7224.233771] DR0: DR1: DR2: [ 7224.233775] DR3: DR6: 0ff0 DR7: 0400 [ 7224.233779] Process ssh (pid: 7622, threadinfo 81000aafa000, task 81000abc2000) [ 7224.233782] Stack: 810004438b80 0001 810006c96860 810004438b80 [ 7224.233796] 81000442b8e0 81000aafbb38 8023061e [ 7224.233807] 0400 81000442fb80 0001 [ 7224.233816] Call Trace: [ 7224.233823] [8023061e] try_to_wake_up+0x2fe/0x3a0 [ 7224.233828] [802306cd] default_wake_function+0xd/0x10 [ 7224.233833] [8022daca] __wake_up_common+0x5a/0x90 [ 7224.233839] [8023095a] __wake_up_sync+0x4a/0x70 [ 7224.233845] [80602fbf] unix_write_space+0x8f/0xa0 [ 7224.233850] [805936f9] sock_wfree+0x49/0x50 [ 7224.233854] [80595579] __kfree_skb+0x69/0xe0 [ 7224.233859] [80595607] kfree_skb+0x17/0x30 [ 7224.233863] [806016c7] unix_stream_recvmsg+0x267/0x610 [ 7224.233869] [8058e457] sock_aio_read+0x107/0x110 [ 7224.233875] [802928f1] do_sync_read+0xf1/0x130 [ 7224.233882] [802a4f20] __d_free+0x30/0x40 [ 7224.233887] [80251830] autoremove_wake_function+0x0/0x40 [ 7224.233892] [80293246] vfs_read+0x156/0x160 [ 7224.233897] [80293650] sys_read+0x50/0x90 [ 7224.233901] [8020bd7e] system_call+0x7e/0x83 [ 7224.233904] [ 7224.233907] [ 7224.233907] Code: 48 8b 90 20 01 00 00 48 39 93 20 01 00 00 75 e2 48 81 3b 00 [ 7224.233951] RIP [8023572e] check_preempt_wakeup+0x6e/0x110 [ 7224.233957] RSP 81000aafba78 [ 7224.233961] CR2: 0120 [ 7224.233967] note: ssh[7622] exited with preempt_count 3 Hmm. Please run gdb vmlinux and see what code corresponds to check_preempt_wakeup+0x6e in your kernel. - 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
No implementation of NETLINK_USERSOCK ?
Some 6 months ago I asked about a way to make network protocol servers(s) that live in userspace, but whose application interface still uses kernel socket calls. I recall getting an answer that there is NETLINK_USERSOCK for that use. I have tried to have a look into what NETLINK_USERSOCK supplies to its users, but alas there appears to be no implementation at all in existence. Is it some sort of placeholder of things to implement some day ? /Matti Aarnio - 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: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':
On Thu, 8 Nov 2007 04:30:10 +0100 Adrian Bunk wrote: On Wed, Nov 07, 2007 at 11:52:32PM +0100, Adrian Bunk wrote: On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote: But on the other hand, it seems that only the ASIX code will work right; the DM9601 and MCS7830 Kconfig is different/wrong. I'm not seeing the problem. Which configuration will be handled wrongly? Notice how only the ASIX kconfig depended on NET_ETHERNET... since MII depends on NET_ETHERNET, and (last I knew) the reverse dependencies didn't capture the complete dependency tree, selecting only MII would leave out some stuff. Except for one s390 net driver (I'll check why it's doing this) the NET_ETHERNET option does not influence what code is being generated - it's just a Kconfig-internal option allowing to disable a huge bunch of drivers at once. Damn, I shouldn't have only grep'ed under drivers/. @davem: Please look at net/ipv4/arp.c:arp_process() Am I right that CONFIG_NET_ETHERNET=n and CONFIG_NETDEV_1000=y or CONFIG_NETDEV_1=y will not be handled correctly there? I'd say yes, you are correct. And the best solution is to nuke all #ifdef's in this function and make the code unconditionally available? --- ~Randy - 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: [Bug 9080] Weird network problems with 2.6.23-rc2
On Thursday, 8 of November 2007, [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9080 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #1 from [EMAIL PROTECTED] 2007-11-07 17:56 --- Rafael, we should probably email this to netdev. OK, let's try. :-) - 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] ipconfig.c : implement DHCP Class-identifier
Rainer Jochem wrote:
--- net/ipv4/ipconfig.c.orig2007-11-08 14:54:11.001662860 +0100
+++ net/ipv4/ipconfig.c 2007-11-08 14:54:15.961480524 +0100
@@ -139,6 +139,8 @@ __be32 ic_servaddr = NONE; /* Boot serve
__be32 root_server_addr = NONE;/* Address of NFS server */
u8 root_server_path[256] = { 0, }; /* Path to mount as root */
+char vendor_class_identifier[256] = { 0, }; /* vendor class identifier */
static please, no need to initialize.
+
/* Persistent data: */
static int ic_proto_used; /* Protocol used, if any */
@@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
*e++ = sizeof(ic_req_params);
memcpy(e, ic_req_params, sizeof(ic_req_params));
e += sizeof(ic_req_params);
+
+ // Send it only if the according kernel parameter was set
+ if (*vendor_class_identifier) {
+ printk(KERN_INFO Sending class identifier \%s\\n,
+ vendor_class_identifier);
Seems like useless noise.
+ *e++ = 60; /* Class-identifier */
+ *e++ = strlen(vendor_class_identifier);
+ memcpy(e, vendor_class_identifier,
+ strlen(vendor_class_identifier));
+ e += strlen(vendor_class_identifier);
You could avoid these three strlen calls by using a temporary
variable to hold the length.
+ }
}
*e++ = 255; /* End of the list */
@@ -1507,5 +1520,14 @@ static int __init nfsaddrs_config_setup(
return ip_auto_config_setup(addrs);
}
+static int __init vendor_class_identifier_setup(char *addrs)
+{
+ if (strlcpy(vendor_class_identifier, addrs, 250) 250)
sizeof(vendor_class_identifier). Why are you using 250 but the
array is 256 bytes large?
+ printk(KERN_WARNING vendorclass too long, truncated to \%s\,
+ vendor_class_identifier);
+ return 1;
+}
+
__setup(ip=, ip_auto_config_setup);
__setup(nfsaddrs=, nfsaddrs_config_setup);
+__setup(dhcpclass=, vendor_class_identifier_setup);
--- ../linux-2.6.23.1/Documentation/kernel-parameters.txt 2007-10-12
18:43:44.0 +0200
+++ Documentation/kernel-parameters.txt 2007-10-24 17:02:22.441454955 +0200
@@ -533,6 +533,10 @@ and is between 256 and 4096 characters.
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
+ dhcpclass= [KNL]
[IP_PNP]
+ Set DHCP Vendor Class Identifier to be sent
+ by the client.
+
digi= [HW,SERIAL]
IO parameters + enable/disable command.
-
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
[VLAN]: Don't synchronize addresses while the vlan device is down
[VLAN]: Don't synchronize addresses while the vlan device is down While the VLAN device is down, the unicast addresses are not configured on the underlying device, so we shouldn't attempt to sync them. Noticed by Dmitry Butskoy [EMAIL PROTECTED] Signed-off-by: Patrick McHardy [EMAIL PROTECTED] --- commit f6d0e3b654d36bd87016b0626464990f3fc57ca7 tree 16ce232acdd1919e7ca42dc12b24f09f8d92f966 parent dbeeb816e805091e7cfc03baf36dc40b4adb2bbd author Patrick McHardy [EMAIL PROTECTED] Thu, 08 Nov 2007 17:34:43 +0100 committer Patrick McHardy [EMAIL PROTECTED] Thu, 08 Nov 2007 17:34:43 +0100 net/8021q/vlan.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c index 3fe4fc8..d80afec 100644 --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -636,6 +636,10 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event, if (!vlandev) continue; + flgs = vlandev-flags; + if (!(flgs IFF_UP)) +continue; + vlan_sync_address(dev, vlandev); } break;
[VLAN]: Allow setting mac address while device is up
This patch allows to change a VLAN device's MAC address while
the device is up. Doesn't seem worth to hold back until
2.6.25-rc since it can't break anything without actually
getting used (and it does work :))
[VLAN]: Allow setting mac address while device is up
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 5efb3597bba3b223fcf3690a88394064dded87ba
tree a15ae1c12bcdc1277c5a5096f420437c1ded7414
parent f6d0e3b654d36bd87016b0626464990f3fc57ca7
author Patrick McHardy [EMAIL PROTECTED] Thu, 08 Nov 2007 18:12:20 +0100
committer Patrick McHardy [EMAIL PROTECTED] Thu, 08 Nov 2007 18:12:20 +0100
net/8021q/vlan.c |1 +
net/8021q/vlan.h |1 +
net/8021q/vlan_dev.c | 26 ++
3 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index d80afec..dd4086b 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -376,6 +376,7 @@ void vlan_setup(struct net_device *new_dev)
new_dev-init = vlan_dev_init;
new_dev-open = vlan_dev_open;
new_dev-stop = vlan_dev_stop;
+ new_dev-set_mac_address = vlan_set_mac_address;
new_dev-set_multicast_list = vlan_dev_set_multicast_list;
new_dev-change_rx_flags = vlan_change_rx_flags;
new_dev-destructor = free_netdev;
diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
index cf4a80d..2cd1393 100644
--- a/net/8021q/vlan.h
+++ b/net/8021q/vlan.h
@@ -60,6 +60,7 @@ int vlan_dev_hwaccel_hard_start_xmit(struct sk_buff *skb, struct net_device *dev
int vlan_dev_change_mtu(struct net_device *dev, int new_mtu);
int vlan_dev_open(struct net_device* dev);
int vlan_dev_stop(struct net_device* dev);
+int vlan_set_mac_address(struct net_device *dev, void *p);
int vlan_dev_ioctl(struct net_device* dev, struct ifreq *ifr, int cmd);
void vlan_dev_set_ingress_priority(const struct net_device *dev,
u32 skb_prio, short vlan_prio);
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 1a1740a..7a36878 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -665,6 +665,32 @@ int vlan_dev_stop(struct net_device *dev)
return 0;
}
+int vlan_set_mac_address(struct net_device *dev, void *p)
+{
+ struct net_device *real_dev = VLAN_DEV_INFO(dev)-real_dev;
+ struct sockaddr *addr = p;
+ int err;
+
+ if (!is_valid_ether_addr(addr-sa_data))
+ return -EADDRNOTAVAIL;
+
+ if (!(dev-flags IFF_UP))
+ goto out;
+
+ if (compare_ether_addr(addr-sa_data, real_dev-dev_addr)) {
+ err = dev_unicast_add(real_dev, addr-sa_data, ETH_ALEN);
+ if (err 0)
+ return err;
+ }
+
+ if (compare_ether_addr(dev-dev_addr, real_dev-dev_addr))
+ dev_unicast_delete(real_dev, dev-dev_addr, ETH_ALEN);
+
+out:
+ memcpy(dev-dev_addr, addr-sa_data, ETH_ALEN);
+ return 0;
+}
+
int vlan_dev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
struct net_device *real_dev = VLAN_DEV_INFO(dev)-real_dev;
Re: 2.6.24-rc1-gb4f5550 oops
On Thu, 8 Nov 2007 16:53:10 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Thursday, 8 of November 2007, Grant Wilson wrote: On Thu, 8 Nov 2007 01:06:21 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 5 of November 2007, Grant Wilson wrote: Hi, I got this oops on 2.6.24-rc1-641-gb4f5550: (1) Is this reproducible? (2) Did it happen previously on your system? [18073.371126] Unable to handle kernel NULL pointer dereference at 0120 RIP: [18073.371134] [8023572e] check_preempt_wakeup+0x6e/0x110 This has now happened twice - the second time was last night when running 2.6.24-rc2. Here's that second occurrence: [snip] Hmm. Please run gdb vmlinux and see what code corresponds to check_preempt_wakeup+0x6e in your kernel. Dump of assembler code for function check_preempt_wakeup: 0x80232940 check_preempt_wakeup+0:push %rbp 0x80232941 check_preempt_wakeup+1:mov%rsp,%rbp 0x80232944 check_preempt_wakeup+4:sub$0x30,%rsp 0x80232948 check_preempt_wakeup+8:mov%r13,-0x18(%rbp) 0x8023294c check_preempt_wakeup+12: mov%rbx,-0x28(%rbp) 0x80232950 check_preempt_wakeup+16: mov%rsi,%r13 0x80232953 check_preempt_wakeup+19: mov%r12,-0x20(%rbp) 0x80232957 check_preempt_wakeup+23: mov%r14,-0x10(%rbp) 0x8023295b check_preempt_wakeup+27: mov%r15,-0x8(%rbp) 0x8023295f check_preempt_wakeup+31: cmpl $0x63,0x20(%rsi) 0x80232963 check_preempt_wakeup+35: mov0x750(%rdi),%r14 0x8023296a check_preempt_wakeup+42: mov0x168(%r14),%r12 0x80232971 check_preempt_wakeup+49: jle0x80232a1c check_preempt_wakeup+220 0x80232977 check_preempt_wakeup+55: cmpl $0x3,0x17c(%rsi) 0x8023297e check_preempt_wakeup+62: je 0x802329f8 check_preempt_wakeup+184 0x80232980 check_preempt_wakeup+64: testb $0x10,0x593cb9(%rip) # 0x807c6640 sysctl_sched_features 0x80232987 check_preempt_wakeup+71: je 0x802329f8 check_preempt_wakeup+184 0x80232989 check_preempt_wakeup+73: cmp0x168(%rsi),%r12 0x80232990 check_preempt_wakeup+80: lea0x48(%r14),%rbx 0x80232994 check_preempt_wakeup+84: lea0x48(%rsi),%rax 0x80232998 check_preempt_wakeup+88: je 0x802329be check_preempt_wakeup+126 0x8023299a check_preempt_wakeup+90: nopw 0x0(%rax,%rax,1) 0x802329a0 check_preempt_wakeup+96: mov0x118(%rbx),%rbx 0x802329a7 check_preempt_wakeup+103: mov0x118(%rax),%rax 0x802329ae check_preempt_wakeup+110: mov0x120(%rax),%rdx 0x802329b5 check_preempt_wakeup+117: cmp%rdx,0x120(%rbx) 0x802329bc check_preempt_wakeup+124: jne0x802329a0 check_preempt_wakeup+96 0x802329be check_preempt_wakeup+126: cmpq $0x400,(%rbx) 0x802329c5 check_preempt_wakeup+133: mov0x40(%rbx),%r12 0x802329c9 check_preempt_wakeup+137: mov0x40(%rax),%r15 0x802329cd check_preempt_wakeup+141: mov0x593c81(%rip),%edi # 0x807c6654 sysctl_sched_wakeup_granularity 0x802329d3 check_preempt_wakeup+147: jne0x80232a37 check_preempt_wakeup+247 0x802329d5 check_preempt_wakeup+149: sub%r15,%r12 0x802329d8 check_preempt_wakeup+152: cmp%r12,%rdi 0x802329db check_preempt_wakeup+155: jge0x802329f8 check_preempt_wakeup+184 0x802329dd check_preempt_wakeup+157: testb $0x20,0x593c5c(%rip) # 0x807c6640 sysctl_sched_features Cheers, Grant -- Running Linux 2.6.24-rc2 on x86_64 - 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: Why does a connect to IPv6 LLA address fail ?
On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote: The reason is that 2 different hosts may have the same link-local address as long as they are on different links. If the sender is connected to both links then it may send the packet to the wrong destination. Good point. What's confusing is that connect(2) fails even if the host itself has the specified address. This isn't necessary. What's even more confusing is that the kernel doesn't seem to honor the interface in all cases: with fe80::20f:20ff:fe3b:e9c3 on eth0 and ::1 on lo, I get the following: ping6 fe80::20f:20ff:fe3b:e9c3fails with EINVAL ping6 fe80::20f:20ff:fe3b:e9c3%eth0 succeeds ping6 fe80::20f:20ff:fe3b:e9c3%lo succeeds At least the last ping should fail, shouldn't it? A different and some might say 'better' alternative is to define a default link. Thus when the zone id is not specified the default is used. This will work fine for link-scoped addresses. A default zone would also need to be defined for other scopes as well. That's just one idea. I think at least for host with only one link (in addition to loopback), selecting that link for non-local addresses would make sense. Thanks, Andreas - 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: Please pull 'fixes-jgarzik' branch of wireless-2.6 (3rd time is the charm?)
On Thu, Nov 08, 2007 at 09:26:26AM -0500, John W. Linville wrote: Jeff, OK, I think things are settled now. I apologize for the confusion. These are fixes intended for 2.6.24. Please note that three of the patches from Michael Buesch in the list below were already sent to you directed for 2.6.25. Upon further review, I think they belong in 2.6.24 instead. I cherry-picked them, so I'm fairly certain git will be smart enough to drop them from your 2.6.25 branch when you rebase. Please let me know if there are any problems. Thanks! John --- Individual patches are available here: http://www.kernel.org/pub//linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/ pulled into #upstream-fixes; please check the merge in #upstream - 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] qla3xxx: bugfix: Move link state machine into a worker thread
On Wed, Nov 07, 2007 at 01:59:06PM -0800, Ron Mercer wrote: The link state machine requires access to some resources that are shared with the iSCSI function on the chip. (See iSCSI driver at drivers/scsi/qla4xxx) If the interface is being up/downed at a rapid pace this driver may need to sleep waiting to get access to the common resources. For this we are moving the state machine to run as a work thread. Signed-off-by: Ron Mercer [EMAIL PROTECTED] --- drivers/net/qla3xxx.c | 27 +-- drivers/net/qla3xxx.h |1 + 2 files changed, 14 insertions(+), 14 deletions(-) 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] [NETFILTER] Consolidate nf_sockopt and compat_nf_sockopt v2
Pavel Emelyanov wrote: Both lookup the nf_sockopt_ops object to call the get/set callbacks from, but they perform it in a completely similar way. Introduce the helper for finding the ops. Ported at the top of today's net-2.6 tree to resolve conflict with the patch from Alexey Dobriyan. Applied, thanks Pavel. - 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: Why does a connect to IPv6 LLA address fail ?
Andreas Gruenbacher wrote: On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote: The reason is that 2 different hosts may have the same link-local address as long as they are on different links. If the sender is connected to both links then it may send the packet to the wrong destination. Good point. What's confusing is that connect(2) fails even if the host itself has the specified address. This isn't necessary. Yes and no. Since linux doesn't have the concept of default zone, we have to fail, because from the perspective of the kernel, the address was not fully specified. OTOH, since this is our address, we 'could' have all the info. The problem is that this verification happens before we hit the routing logic. It's an explicit check the if the sin6_scope_id is not set and we are not bound to an interface, it's an error. What's even more confusing is that the kernel doesn't seem to honor the interface in all cases: with fe80::20f:20ff:fe3b:e9c3 on eth0 and ::1 on lo, I get the following: ping6 fe80::20f:20ff:fe3b:e9c3 fails with EINVAL ping6 fe80::20f:20ff:fe3b:e9c3%eth0 succeeds Yes, but if you run a capture, you'll see the packet on loopback. That's because you have a route to this address. ping6 fe80::20f:20ff:fe3b:e9c3%lo succeeds Yes, same thing. Routing code takes care of it. At least the last ping should fail, shouldn't it? No, because both pings really go over loopback. You are on the same system and have 'local' routes for those addresses: ip -6 r l t local A different and some might say 'better' alternative is to define a default link. Thus when the zone id is not specified the default is used. This will work fine for link-scoped addresses. A default zone would also need to be defined for other scopes as well. That's just one idea. I think at least for host with only one link (in addition to loopback), selecting that link for non-local addresses would make sense. Yes, you could do that. Or you can push the interface check to the routing code and do some logic to see if you can select an interface. -vlad - 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 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Thu, 8 Nov 2007 17:16:11 +0300 Anton Vorontsov [EMAIL PROTECTED] wrote: On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote: Hello all, the following patches fix RGMII timing for rev. 2.1 of the mpc8360, according to erratum #2 (erratum text included below). Basically the most intrusive part is the addition of two new RGMII Internal Delay modes; one for TX delay only, and the other for RX delay only (i.e, not both at the same time). Please review, and since this affects both netdev and powerpc trees, one maintainer should ack them for the other to push upstream (i.e, Kumar acks them, and Leo picks them up to go through netdev or the other way around; either way is fine with me). I'm hoping they're trivial enough to go in 2.6.24. Depending on how the review goes, a follow-on patch to u-boot will be sent out that fixes up the phy-connection-type in the device tree (from rgmii-id to rgmii-rxid iff on mpc8360rev2.1). I've upgraded CPU to rev2.1, board rev0.3. thanks for testing this. I tested these patches on a pilot assy 0.3. Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is the results: If I use -rxid, then geth not able to transmit anything. With -txid geth not able to receive anything. With just -id everything works fine though... Maybe there should be another condition, in addition to cpu rev2.1? the errata simply states 'pilot boards', but we can probably modify u-boot to look at the cpu rev and the board rev (BCSR 12). My bcsr12 looks like: = md.b f80c 1 f80c: 10. what is yours? If it's something like 0x03, the u-boot patch will probably look like: if ((bcsr[12] == 0x10) (immr-sysconf.spridr == SPR_8360_REV21 || immr-sysconf.spridr == SPR_8360E_REV21)) /* if phy-connection-type is rgmii-id, set it to rgmii-rxid */ ... but these linux patches would remain the same (the clk and data delay settings for the UCC's are still valid; it's just the PHY config that is triggering your problem from what I can tell). Thanks, Kim mpc8360 rev 2.1 erratum #2: --- Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII when working with Rev Pilot MDS for proper RGMII operation: IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2) IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1) IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's) The Phy (Marvell 88e) should be configured NOT to work with RGMII delay for TxD. - 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] sky2: new pci id's
Found a couple of more chips in the latest version of the vendor driver.
They are minor variations on existing chips, so please incorporate into
2.6.24.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/drivers/net/sky2.c2007-11-07 22:45:02.0 -0800
+++ b/drivers/net/sky2.c2007-11-07 22:46:29.0 -0800
@@ -121,6 +121,7 @@ static const struct pci_device_id sky2_i
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4353) }, /* 88E8039 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4354) }, /* 88E8040 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4356) }, /* 88EC033 */
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4357) }, /* 88E8042 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x435A) }, /* 88E8048 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4360) }, /* 88E8052 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4361) }, /* 88E8050 */
@@ -134,6 +135,7 @@ static const struct pci_device_id sky2_i
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4369) }, /* 88EC042 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436A) }, /* 88E8058 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436C) }, /* 88E8072 */
{ 0 }
};
-
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] Fix e100 on systems that have cache incoherent DMA
From: David Acker [EMAIL PROTECTED]
On the systems that have cache incoherent DMA, including ARM, there
is a race condition between software allocating a new receive buffer
and hardware writing into a buffer. The two race on touching the last
Receive Frame Descriptor (RFD). It has its el-bit set and its next
link equal to 0. When hardware encounters this buffer it attempts to
write data to it and then update Status Word bits and Actual Count in
the RFD. At the same time software may try to clear the el-bit and
set the link address to a new buffer.
Since the entire RFD is once cache-line, the two write operations can
collide. This can lead to the receive unit stalling or interpreting
random memory as its receive area.
The fix is to set the el-bit on and the size to 0 on the next to last
buffer in the chain. When the hardware encounters this buffer it stops
and does not write to it at all. The hardware issues an RNR interrupt
with the receive unit in the No Resources state. Software can write
to the tail of the list because it knows hardware will stop on the
previous descriptor that was marked as the end of list.
Once it has a new next to last buffer prepared, it can clear the el-bit
and set the size on the previous one. The race on this buffer is safe
since the link already points to a valid next buffer and the software
can handle the race setting the size (assuming aligned 16 bit writes
are atomic with respect to the DMA read). If the hardware sees the
el-bit cleared without the size set, it will move on to the next buffer
and skip this one. If it sees the size set but the el-bit still set,
it will complete that buffer and then RNR interrupt and wait.
Signed-off-by: David Acker [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e100.c | 128
1 files changed, 99 insertions(+), 29 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 3dbaec6..2153058 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -106,6 +106,13 @@
* the RFD, the RFD must be dma_sync'ed to maintain a consistent
* view from software and hardware.
*
+ * In order to keep updates to the RFD link field from colliding with
+ * hardware writes to mark packets complete, we use the feature that
+ * hardware will not write to a size 0 descriptor and mark the previous
+ * packet as end-of-list (EL). After updating the link, we remove EL
+ * and only then restore the size such that hardware may use the
+ * previous-to-end RFD.
+ *
* Under typical operation, the receive unit (RU) is start once,
* and the controller happily fills RFDs as frames arrive. If
* replacement RFDs cannot be allocated, or the RU goes non-active,
@@ -281,6 +288,7 @@ struct csr {
};
enum scb_status {
+ rus_no_res = 0x08,
rus_ready= 0x10,
rus_mask = 0x3C,
};
@@ -952,7 +960,7 @@ static void e100_get_defaults(struct nic *nic)
((nic-mac = mac_82558_D101_A4) ? cb_cid : cb_i));
/* Template for a freshly allocated RFD */
- nic-blank_rfd.command = cpu_to_le16(cb_el);
+ nic-blank_rfd.command = 0;
nic-blank_rfd.rbd = 0x;
nic-blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
@@ -1791,15 +1799,12 @@ static int e100_rx_alloc_skb(struct nic *nic, struct rx
*rx)
}
/* Link the RFD to end of RFA by linking previous RFD to
-* this one, and clearing EL bit of previous. */
+* this one. We are safe to touch the previous RFD because
+* it is protected by the before last buffer's el bit being set */
if(rx-prev-skb) {
struct rfd *prev_rfd = (struct rfd *)rx-prev-skb-data;
put_unaligned(cpu_to_le32(rx-dma_addr),
(u32 *)prev_rfd-link);
- wmb();
- prev_rfd-command = ~cpu_to_le16(cb_el);
- pci_dma_sync_single_for_device(nic-pdev, rx-prev-dma_addr,
- sizeof(struct rfd), PCI_DMA_TODEVICE);
}
return 0;
@@ -1824,8 +1829,19 @@ static int e100_rx_indicate(struct nic *nic, struct rx
*rx,
DPRINTK(RX_STATUS, DEBUG, status=0x%04X\n, rfd_status);
/* If data isn't ready, nothing to indicate */
- if(unlikely(!(rfd_status cb_complete)))
+ if (unlikely(!(rfd_status cb_complete))) {
+ /* If the next buffer has the el bit, but we think the receiver
+* is still running, check to see if it really stopped while
+* we had interrupts off.
+* This allows for a fast restart without re-enabling
+* interrupts */
+ if ((le16_to_cpu(rfd-command) cb_el)
+ (RU_RUNNING == nic-ru_running))
+
+ if (readb(nic-csr-scb.status) rus_no_res)
+ nic-ru_running =
[PATCH] NET: Fix skb_truesize_check() assertion
The intent of the assertion in skb_truesize_check() is to check
for skb-truesize being decremented too much by other code,
resulting in a wraparound below zero.
The type of the right side of the comparison causes the compiler to
promote the left side to an unsigned type, despite the presence of an
explicit type cast. This defeats the check for negativity.
Ensure both sides of the comparison are a signed type to prevent the
implicit type conversion.
Signed-off-by: Chuck Lever [EMAIL PROTECTED]
---
include/linux/skbuff.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 94e4991..91140fe 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -387,7 +387,9 @@ extern void skb_truesize_bug(struct sk_buff *skb);
static inline void skb_truesize_check(struct sk_buff *skb)
{
- if (unlikely((int)skb-truesize sizeof(struct sk_buff) + skb-len))
+ int len = sizeof(struct sk_buff) + skb-len;
+
+ if (unlikely((int)skb-truesize len))
skb_truesize_bug(skb);
}
-
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] sky2: netpoll on port 0 only
On Tue, Nov 06, 2007 at 11:45:40AM -0800, Stephen Hemminger wrote: Netpoll will only work on port 0 because of the restrictive relationship between NAPI and netpoll. Signed-off-by: Stephen Hemminger [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: [PATCH 1/2] bonding: fix rtnl locking merge error
On Tue, Nov 06, 2007 at 01:33:28PM -0800, Jay Vosburgh wrote: Looks like I incorrectly merged one of the rtnl lock changes, so that one function, bonding_show_active_slave, held rtnl but didn't release it, and another, bonding_store_active_slave, never held rtnl but did release it. Fixed so the first function doesn't mess with rtnl, and the second correctly acquires and releases rtnl. Bug reported by Moni Shoua [EMAIL PROTECTED] Signed-off-by: Jay Vosburgh [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 1/2] pasemi_mac: Don't set replace-source-address descriptor bits
On Tue, Nov 06, 2007 at 10:20:39PM -0600, Olof Johansson wrote: Don't use the replace source address with local MAC address bits, since it causes problems on some variations of the hardware due to an erratum. Signed-off-by: Olof Johansson [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: ax88796: add superh to kconfig dependencies
On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote: ax88796: add superh to kconfig dependencies This patch adds sh architecture support to the ax88796 kconfig. Signed-off-by: Magnus Damm [EMAIL PROTECTED] --- This patch was posted about a month ago but never picked up: http://www.mail-archive.com/netdev@vger.kernel.org/msg50018.html The rest of the sh support is already included in rc1. Please apply. drivers/net/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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: Why does a connect to IPv6 LLA address fail ?
On Thu, Nov 08, 2007 at 01:15:52PM -0500, Vlad Yasevich wrote: Andreas Gruenbacher wrote: On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote: The reason is that 2 different hosts may have the same link-local address as long as they are on different links. If the sender is connected to both links then it may send the packet to the wrong destination. Good point. What's confusing is that connect(2) fails even if the host itself has the specified address. This isn't necessary. Yes and no. Since linux doesn't have the concept of default zone, we have to fail, because from the perspective of the kernel, the address was not fully specified. OTOH, since this is our address, we 'could' have all the info. The problem is that this verification happens before we hit the routing logic. It's an explicit check the if the sin6_scope_id is not set and we are not bound to an interface, it's an error. OK I run into this issue while running the TAHI testsuite. The test is as follows: Check 03: DNS Address: fec0::9 Candidate Source Addresses: fec0::1(SS) or LLA(LS) Destination Address List: 3fff::2(GS) or fe80::2(LS) Result: fe80::2 (src LLA) then 3fff::2 (src fec0::1) Scope(fe80::2) = Scope(LLA) and Scope(3fff::2) Scope(fec0::1), then prefer fe80::2 the nameserver send following answer for the query: | | | | DNS_Question(length:21) | | | | | DNS_QuestionEntry (length:21) | | | | | | Name = server.tahi.org. | | | | | | Type = 28 () | | | | | | Class= 1 | | | | DNS_Answer (length:86) | | | | | DNS_RR_ (length:43) | | | | | | Name = server.tahi.org. | | | | | | Type = 28 | | | | | | Class= 1 | | | | | | TTL = 0 | | | | | | Length = 16 | | | | | | Address = 3fff::2 | | | | | DNS_RR_ (length:43) | | | | | | Name = server.tahi.org. | | | | | | Type = 28 | | | | | | Class= 1 | | | | | | TTL = 0 | | | | | | Length = 16 | | | | | | Address = fe80::2 So how we should handle this issue, claim that the test is wrong, the test should not use LLA for this ? -- Karsten Keil SuSE Labs ISDN and VOIP development SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) - 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 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
On Thu, 8 Nov 2007 17:16:11 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
Hello all,
the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
according to erratum #2 (erratum text included below). Basically the
most intrusive part is the addition of two new RGMII Internal Delay
modes; one for TX delay only, and the other for RX delay only (i.e, not
both at the same time).
Please review, and since this affects both netdev and powerpc trees,
one maintainer should ack them for the other to push upstream (i.e,
Kumar acks them, and Leo picks them up to go through netdev or the
other way around; either way is fine with me). I'm hoping they're
trivial enough to go in 2.6.24.
Depending on how the review goes, a follow-on patch to u-boot will be
sent out that fixes up the phy-connection-type in the device tree (from
rgmii-id to rgmii-rxid iff on mpc8360rev2.1).
I've upgraded CPU to rev2.1, board rev0.3.
thanks for testing this. I tested these patches on a pilot assy 0.3.
Same here.
Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
the results:
If I use -rxid, then geth not able to transmit anything.
With -txid geth not able to receive anything.
With just -id everything works fine though...
Maybe there should be another condition, in addition to cpu rev2.1?
the errata simply states 'pilot boards', but we can probably modify
u-boot to look at the cpu rev and the board rev (BCSR 12).
My bcsr12 looks like:
= md.b f80c 1
f80c: 10.
what is yours?
= md.b f80c 1
f80c: 10.
:-/
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
[EMAIL PROTECTED]:~# cat /proc/cpuinfo
processor : 0
cpu : e300c1
clock : 528.00MHz
revision: 3.1 (pvr 8083 0031)
bogomips: 131.58
timebase: 6600
platform: MPC836x MDS
+ /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+ svid = mfspr(SPRN_SVR);
+ if (svid == 0x80480021) {
^^ that branch executes on the board I'm testing.
If it's something like 0x03, the u-boot patch will probably look like:
if ((bcsr[12] == 0x10)
(immr-sysconf.spridr == SPR_8360_REV21 ||
immr-sysconf.spridr == SPR_8360E_REV21))
/* if phy-connection-type is rgmii-id, set it to rgmii-rxid */
...
but these linux patches would remain the same (the clk and data delay
settings for the UCC's are still valid; it's just the PHY config
that is triggering your problem from what I can tell).
Yup, most likely this is not UCC specific, but PHY. For some reason
delays making harm here...
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
-
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: [2.6 patch] drivers/net/netxen/: cleanups
This looks good to me, I might chop off these #if 0 'ed functions in
my next round of patches.
Acked-by: Dhananjay Phadke [EMAIL PROTECTED]
On 11/5/07, Adrian Bunk [EMAIL PROTECTED] wrote:
This patch contains the following cleanups:
- static functions in .c files shouldn't be marked inline
- make needlessly global code static
- #if 0 unused code
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic.h | 14
drivers/net/netxen/netxen_nic_hw.c | 19 +++---
drivers/net/netxen/netxen_nic_hw.h |8 --
drivers/net/netxen/netxen_nic_init.c | 70 ---
drivers/net/netxen/netxen_nic_isr.c |7 +-
drivers/net/netxen/netxen_nic_main.c |9 +-
drivers/net/netxen/netxen_nic_niu.c | 26 +---
drivers/net/netxen/netxen_nic_phan_reg.h |7 --
8 files changed, 76 insertions(+), 84 deletions(-)
dbc7aeed37e41cd37a01cce259e5c0ab01f8dd88
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index fbc2553..ef9f986 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -1015,14 +1015,8 @@ int netxen_niu_xgbe_enable_phy_interrupts(struct
netxen_adapter *adapter);
int netxen_niu_gbe_enable_phy_interrupts(struct netxen_adapter *adapter);
int netxen_niu_xgbe_disable_phy_interrupts(struct netxen_adapter *adapter);
int netxen_niu_gbe_disable_phy_interrupts(struct netxen_adapter *adapter);
-int netxen_niu_xgbe_clear_phy_interrupts(struct netxen_adapter *adapter);
-int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter);
void netxen_nic_xgbe_handle_phy_intr(struct netxen_adapter *adapter);
void netxen_nic_gbe_handle_phy_intr(struct netxen_adapter *adapter);
-void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter, int port,
-long enable);
-void netxen_niu_gbe_set_gmii_mode(struct netxen_adapter *adapter, int port,
- long enable);
int netxen_niu_gbe_phy_read(struct netxen_adapter *adapter, long reg,
__u32 * readval);
int netxen_niu_gbe_phy_write(struct netxen_adapter *adapter,
@@ -1045,7 +1039,6 @@ int netxen_nic_hw_write_wx(struct netxen_adapter
*adapter, u64 off, void *data,
int len);
void netxen_crb_writelit_adapter(struct netxen_adapter *adapter,
unsigned long off, int data);
-int netxen_nic_erase_pxe(struct netxen_adapter *adapter);
/* Functions from netxen_nic_init.c */
void netxen_free_adapter_offload(struct netxen_adapter *adapter);
@@ -1064,15 +1057,10 @@ int netxen_flash_erase_secondary(struct
netxen_adapter *adapter);
int netxen_flash_erase_primary(struct netxen_adapter *adapter);
void netxen_halt_pegs(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);
/* Functions from netxen_nic_isr.c */
int netxen_nic_link_ok(struct netxen_adapter *adapter);
-void netxen_nic_isr_other(struct netxen_adapter *adapter);
-void netxen_indicate_link_status(struct netxen_adapter *adapter, u32 link);
-void netxen_handle_port_int(struct netxen_adapter *adapter, u32 enable);
void netxen_initialize_adapter_sw(struct netxen_adapter *adapter);
void netxen_initialize_adapter_hw(struct netxen_adapter *adapter);
void *netxen_alloc(struct pci_dev *pdev, size_t sz, dma_addr_t * ptr,
@@ -1089,8 +1077,6 @@ int netxen_nic_tx_has_work(struct netxen_adapter
*adapter);
void netxen_watchdog_task(struct work_struct *work);
void netxen_post_rx_buffers(struct netxen_adapter *adapter, u32 ctx,
u32 ringid);
-void netxen_post_rx_buffers_nodb(struct netxen_adapter *adapter, u32 ctx,
-u32 ringid);
int netxen_process_cmd_ring(unsigned long data);
u32 netxen_process_rcv_ring(struct netxen_adapter *adapter, int ctx, int
max);
void netxen_nic_set_multi(struct net_device *netdev);
diff --git a/drivers/net/netxen/netxen_nic_hw.c
b/drivers/net/netxen/netxen_nic_hw.c
index 2c19b8d..b2c7861 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -33,7 +33,6 @@
#include netxen_nic.h
#include netxen_nic_hw.h
-#define DEFINE_GLOBAL_RECV_CRB
#include netxen_nic_phan_reg.h
@@ -244,12 +243,15 @@ struct netxen_recv_crb recv_crb_registers[] = {
},
};
-u64 ctx_addr_sig_regs[][3] = {
+static u64 ctx_addr_sig_regs[][3] = {
{NETXEN_NIC_REG(0x188), NETXEN_NIC_REG(0x18c), NETXEN_NIC_REG(0x1c0)},
{NETXEN_NIC_REG(0x190), NETXEN_NIC_REG(0x194), NETXEN_NIC_REG(0x1c4)},
{NETXEN_NIC_REG(0x198), NETXEN_NIC_REG(0x19c), NETXEN_NIC_REG(0x1c8)},
{NETXEN_NIC_REG(0x1a0), NETXEN_NIC_REG(0x1a4), NETXEN_NIC_REG(0x1cc)}
[PATCH 03/05] r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)
Various symptoms depending on the .config options: - the card stops working after some (short) time - the card does not work at all - the card disappears (nothing in lspci/dmesg) A real power-off is needed to recover the card. Signed-off-by: Mark Lord [EMAIL PROTECTED] Signed-off-by: Francois Romieu [EMAIL PROTECTED] --- drivers/net/r8169.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index 9dbab3f..a37cf82 100644 --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -1328,6 +1328,7 @@ static void rtl_hw_phy_config(struct net_device *dev) break; case RTL_GIGA_MAC_VER_11: case RTL_GIGA_MAC_VER_12: + break; case RTL_GIGA_MAC_VER_17: rtl8168b_hw_phy_config(ioaddr); break; -- 1.5.3.3 - 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 04/05] r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (bis repetita)
RTL_GIGA_MAC_VER_17 breaks as well.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index a37cf82..f9ba2e4 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1247,16 +1247,6 @@ static void rtl8169sb_hw_phy_config(void __iomem *ioaddr)
rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
-static void rtl8168b_hw_phy_config(void __iomem *ioaddr)
-{
- struct phy_reg phy_reg_init[] = {
- { 0x1f, 0x },
- { 0x10, 0xf41b },
- { 0x1f, 0x }
- };
-
- rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
-}
static void rtl8168cp_hw_phy_config(void __iomem *ioaddr)
{
@@ -1326,12 +1316,6 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_04:
rtl8169sb_hw_phy_config(ioaddr);
break;
- case RTL_GIGA_MAC_VER_11:
- case RTL_GIGA_MAC_VER_12:
- break;
- case RTL_GIGA_MAC_VER_17:
- rtl8168b_hw_phy_config(ioaddr);
- break;
case RTL_GIGA_MAC_VER_18:
rtl8168cp_hw_phy_config(ioaddr);
break;
--
1.5.3.3
-
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 02/05] ipv6: RFC4214 Support (2)
In article [EMAIL PROTECTED] (at Thu, 08 Nov 2007 12:41:39 -0800), osprey67
[EMAIL PROTECTED] says:
From: Fred L. Templin [EMAIL PROTECTED]
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
ip utility with device names beginning with: isatap.
The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.
Signed-off-by: Fred L. Templin [EMAIL PROTECTED]
Hmm...tabs are still mangled, and it's better to have your
official address. Anyway...
--- linux-2.6.24-rc2/include/net/addrconf.h.orig2007-11-08
12:06:17.0 -0800
+++ linux-2.6.24-rc2/include/net/addrconf.h 2007-11-08 08:27:24.0
-0800
@@ -241,6 +241,37 @@ static inline int ipv6_addr_is_ll_all_ro
addr-s6_addr32[3] == htonl(0x0002));
}
+#if defined(CONFIG_IPV6_ISATAP)
+static inline int ipv6_isatap_eui64(u8 *eui, __be32 addr)
+{
+
+ /* RFC3330 Special-Use IPv4 Addresses */
+ eui[0] = (((addr htonl(0xFF00)) == htonl(0x)) ||
+ ((addr htonl(0xFF00)) == htonl(0x0A00)) ||
+ ((addr htonl(0xFF00)) == htonl(0x0D00)) ||
+ ((addr htonl(0xFF00)) == htonl(0x1800)) ||
+ ((addr htonl(0xFF00)) == htonl(0x7F00)) ||
+ ((addr htonl(0x)) == htonl(0xA9FE)) ||
+ ((addr htonl(0xFFF0)) == htonl(0xAC10)) ||
+ ((addr htonl(0xFF00)) == htonl(0xC200)) ||
+ ((addr htonl(0xFF00)) == htonl(0xC0586300)) ||
+ ((addr htonl(0x)) == htonl(0xC0A8)) ||
+ ((addr htonl(0xFFFE)) == htonl(0xC612)) ||
+ ((addr htonl(0xF000)) == htonl(0xE000)) ||
+ ((addr htonl(0xF000)) == htonl(0xF000))) ?
+ 0x00 : 0x02;
+
+ eui[1] = 0; eui[2] = 0x5E; eui[3] = 0xFE;
+ memcpy (eui+4, addr, 4);
+ return 0;
+}
+
Please put this function in net/ipv6/addrconf.c as addrconf_ifid_isatap().
Please use MULTICAST, LOCALNET etc. (and probaly introduce new macro
for others). IMHO, it's better to add a comment for each entry, e.g.,
MULTICAST(addr) || /* 224.0.0.0/4 */
instead of
((addr htonl(0xF000)) == htonl(0xE000)) ||
+static inline int ipv6_addr_is_isatap(const struct in6_addr *addr)
+{
+ return ((addr-s6_addr32[2] | htonl(0x0200)) ==
htonl(0x02005EFE));
+}
+#endif
+
ipv6_addr_isatap(), maybe (to align with ipv6_addr_any() 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
[PATCH 05/05] r8169: prevent bit sign expansion error in mdio_write
Oops.
The current code does not like being given an u16 with the highest
bit set as an argument to mdio_write. Let's enforce a correct range of
values for both the register address and value (resp. 5 and 16 bits).
The callers are currently left as-is.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index f9ba2e4..1f647b9 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -470,7 +470,7 @@ static void mdio_write(void __iomem *ioaddr, int reg_addr,
int value)
{
int i;
- RTL_W32(PHYAR, 0x8000 | (reg_addr 0xFF) 16 | value);
+ RTL_W32(PHYAR, 0x8000 | (reg_addr 0x1f) 16 | (value 0x));
for (i = 20; i 0; i--) {
/*
@@ -487,7 +487,7 @@ static int mdio_read(void __iomem *ioaddr, int reg_addr)
{
int i, value = -1;
- RTL_W32(PHYAR, 0x0 | (reg_addr 0xFF) 16);
+ RTL_W32(PHYAR, 0x0 | (reg_addr 0x1f) 16);
for (i = 20; i 0; i--) {
/*
@@ -495,7 +495,7 @@ static int mdio_read(void __iomem *ioaddr, int reg_addr)
* the specified MII register.
*/
if (RTL_R32(PHYAR) 0x8000) {
- value = (int) (RTL_R32(PHYAR) 0x);
+ value = RTL_R32(PHYAR) 0x;
break;
}
udelay(25);
--
1.5.3.3
-
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 00/05] pull request for 'upstream-jeff' branch
Please pull from branch 'upstream-jeff' in repository
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git
upstream-jeff
to get the changes below.
They should make things better for people who have experienced the 8168b
regression since 2.6.24-rc1.
Distance from 'master' (f2511f13daaf00fdd206bee7b108f75923a613c6)
-
407b35429151dd1d7a64cbef9f4bc59dac2efe5d
d981c1de3b81edf50fe59f0e1298668919117b14
9d891d0bb0a14bc8184eee45323cb010db4d0db4
69b4d070ea49bd7f589776ea471a69883455
db1470271c581050dcacc6ed681b9166d30bdba0
Diffstat
drivers/net/r8169.c | 26 +++---
1 files changed, 7 insertions(+), 19 deletions(-)
Shortlog
Ciaran McCreesh (1):
r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard
Francois Romieu (2):
r8169: do not enable the TBI for the 8168 and the 81x0
r8169: prevent bit sign expansion error in mdio_write
Mark Lord (2):
r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)
r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (bis repetita)
Patch
-
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b94fa7e..1f647b9 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -171,6 +171,8 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(0x16ec,0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS,0x1032,
PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
+ { 0x0001, 0x8168,
+ PCI_ANY_ID, 0x2410, 0, 0, RTL_CFG_2 },
{0,},
};
@@ -468,7 +470,7 @@ static void mdio_write(void __iomem *ioaddr, int reg_addr,
int value)
{
int i;
- RTL_W32(PHYAR, 0x8000 | (reg_addr 0xFF) 16 | value);
+ RTL_W32(PHYAR, 0x8000 | (reg_addr 0x1f) 16 | (value 0x));
for (i = 20; i 0; i--) {
/*
@@ -485,7 +487,7 @@ static int mdio_read(void __iomem *ioaddr, int reg_addr)
{
int i, value = -1;
- RTL_W32(PHYAR, 0x0 | (reg_addr 0xFF) 16);
+ RTL_W32(PHYAR, 0x0 | (reg_addr 0x1f) 16);
for (i = 20; i 0; i--) {
/*
@@ -493,7 +495,7 @@ static int mdio_read(void __iomem *ioaddr, int reg_addr)
* the specified MII register.
*/
if (RTL_R32(PHYAR) 0x8000) {
- value = (int) (RTL_R32(PHYAR) 0x);
+ value = RTL_R32(PHYAR) 0x;
break;
}
udelay(25);
@@ -1245,16 +1247,6 @@ static void rtl8169sb_hw_phy_config(void __iomem *ioaddr)
rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
-static void rtl8168b_hw_phy_config(void __iomem *ioaddr)
-{
- struct phy_reg phy_reg_init[] = {
- { 0x1f, 0x },
- { 0x10, 0xf41b },
- { 0x1f, 0x }
- };
-
- rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
-}
static void rtl8168cp_hw_phy_config(void __iomem *ioaddr)
{
@@ -1324,11 +1316,6 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_04:
rtl8169sb_hw_phy_config(ioaddr);
break;
- case RTL_GIGA_MAC_VER_11:
- case RTL_GIGA_MAC_VER_12:
- case RTL_GIGA_MAC_VER_17:
- rtl8168b_hw_phy_config(ioaddr);
- break;
case RTL_GIGA_MAC_VER_18:
rtl8168cp_hw_phy_config(ioaddr);
break;
@@ -1739,7 +1726,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
tp-features |= rtl_try_msi(pdev, ioaddr, cfg);
RTL_W8(Cfg9346, Cfg9346_Lock);
- if (RTL_R8(PHYstatus) TBI_Enable) {
+ if ((tp-mac_version = RTL_GIGA_MAC_VER_06)
+ (RTL_R8(PHYstatus) TBI_Enable)) {
tp-set_speed = rtl8169_set_speed_tbi;
tp-get_settings = rtl8169_gset_tbi;
tp-phy_reset_enable = rtl8169_tbi_reset_enable;
--
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
[PATCH 02/05] r8169: do not enable the TBI for the 8168 and the 81x0
The 8168c and the 8100e choke on it. I have not seen an indication
nor received a report that the TBI is being actively used on the
remaining 8168b and 8110. Let's disable it for now until someone
complains.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Matthias Winkler [EMAIL PROTECTED]
Cc: Maarten Vanraes [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 702334e..9dbab3f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1741,7 +1741,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
tp-features |= rtl_try_msi(pdev, ioaddr, cfg);
RTL_W8(Cfg9346, Cfg9346_Lock);
- if (RTL_R8(PHYstatus) TBI_Enable) {
+ if ((tp-mac_version = RTL_GIGA_MAC_VER_06)
+ (RTL_R8(PHYstatus) TBI_Enable)) {
tp-set_speed = rtl8169_set_speed_tbi;
tp-get_settings = rtl8169_gset_tbi;
tp-phy_reset_enable = rtl8169_tbi_reset_enable;
--
1.5.3.3
-
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] NET: Add the helper kernel_sock_shutdown()
From: Trond Myklebust [EMAIL PROTECTED]
...and fix a couple of bugs in the NBD, CIFS and OCFS2 socket handlers.
Looking at the sock-op-shutdown() handlers, it looks as if all of them
take a SHUT_RD/SHUT_WR/SHUT_RDWR argument instead of the
RCV_SHUTDOWN/SEND_SHUTDOWN arguments.
Add a helper, and then define the SHUT_* enum to ensure that kernel users
of shutdown() don't get confused.
Signed-off-by: Trond Myklebust [EMAIL PROTECTED]
Cc: Paul Clements [EMAIL PROTECTED]
Cc: Mark Fasheh [EMAIL PROTECTED]
Cc: Steve French [EMAIL PROTECTED]
Cc: David Howells [EMAIL PROTECTED]
Cc: David S Miller [EMAIL PROTECTED]
---
drivers/block/nbd.c|3 ++-
fs/cifs/connect.c |2 +-
fs/ocfs2/cluster/tcp.c |4 ++--
include/linux/net.h|7 +++
net/rxrpc/ar-local.c |4 ++--
net/socket.c |6 ++
6 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 6332aca..b4c0888 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -28,6 +28,7 @@
#include linux/err.h
#include linux/kernel.h
#include net/sock.h
+#include linux/net.h
#include asm/uaccess.h
#include asm/system.h
@@ -126,7 +127,7 @@ static void sock_shutdown(struct nbd_device *lo, int lock)
if (lo-sock) {
printk(KERN_WARNING %s: shutting down socket\n,
lo-disk-disk_name);
- lo-sock-ops-shutdown(lo-sock, SEND_SHUTDOWN|RCV_SHUTDOWN);
+ kernel_sock_shutdown(lo-sock, SHUT_RDWR);
lo-sock = NULL;
}
if (lock)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 19ee11f..bea0d2e 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -160,7 +160,7 @@ cifs_reconnect(struct TCP_Server_Info *server)
if (server-ssocket) {
cFYI(1, (State: 0x%x Flags: 0x%lx, server-ssocket-state,
server-ssocket-flags));
- server-ssocket-ops-shutdown(server-ssocket, SEND_SHUTDOWN);
+ kernel_sock_shutdown(server-ssocket, SHUT_WR);
cFYI(1, (Post shutdown state: 0x%x Flags: 0x%lx,
server-ssocket-state,
server-ssocket-flags));
diff --git a/fs/ocfs2/cluster/tcp.c b/fs/ocfs2/cluster/tcp.c
index 685c180..d84bd15 100644
--- a/fs/ocfs2/cluster/tcp.c
+++ b/fs/ocfs2/cluster/tcp.c
@@ -58,6 +58,7 @@
#include linux/slab.h
#include linux/idr.h
#include linux/kref.h
+#include linux/net.h
#include net/tcp.h
#include asm/uaccess.h
@@ -616,8 +617,7 @@ static void o2net_shutdown_sc(struct work_struct *work)
del_timer_sync(sc-sc_idle_timeout);
o2net_sc_cancel_delayed_work(sc, sc-sc_keepalive_work);
sc_put(sc);
- sc-sc_sock-ops-shutdown(sc-sc_sock,
- RCV_SHUTDOWN|SEND_SHUTDOWN);
+ kernel_sock_shutdown(sc-sc_sock, SHUT_RDWR);
}
/* not fatal so failed connects before the other guy has our
diff --git a/include/linux/net.h b/include/linux/net.h
index dd79cdb..c804d81 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -95,6 +95,12 @@ enum sock_type {
#endif /* ARCH_HAS_SOCKET_TYPES */
+enum {
+ SHUT_RD = 0,
+ SHUT_WR = 1,
+ SHUT_RDWR = 2,
+};
+
/**
* struct socket - general BSD socket
* @state: socket state (%SS_CONNECTED, etc)
@@ -223,6 +229,7 @@ extern int kernel_setsockopt(struct socket *sock, int
level, int optname,
extern int kernel_sendpage(struct socket *sock, struct page *page, int offset,
size_t size, int flags);
extern int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg);
+extern int kernel_sock_shutdown(struct socket *sock, int how);
#ifndef CONFIG_SMP
#define SOCKOPS_WRAPPED(name) name
diff --git a/net/rxrpc/ar-local.c b/net/rxrpc/ar-local.c
index fe03f71..f3a2bd7 100644
--- a/net/rxrpc/ar-local.c
+++ b/net/rxrpc/ar-local.c
@@ -114,7 +114,7 @@ static int rxrpc_create_local(struct rxrpc_local *local)
return 0;
error:
- local-socket-ops-shutdown(local-socket, 2);
+ kernel_sock_shutdown(local-socket, SHUT_RDWR);
local-socket-sk-sk_user_data = NULL;
sock_release(local-socket);
local-socket = NULL;
@@ -267,7 +267,7 @@ static void rxrpc_destroy_local(struct work_struct *work)
/* finish cleaning up the local descriptor */
rxrpc_purge_queue(local-accept_queue);
rxrpc_purge_queue(local-reject_queue);
- local-socket-ops-shutdown(local-socket, 2);
+ kernel_sock_shutdown(local-socket, SHUT_RDWR);
sock_release(local-socket);
up_read(rxrpc_local_sem);
diff --git a/net/socket.c b/net/socket.c
index 5d879fd..1e41b15 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2319,6 +2319,11 @@ int kernel_sock_ioctl(struct socket *sock, int cmd,
unsigned long arg)
return err;
}
+int kernel_sock_shutdown(struct
Re: 2.6.24-rc1-gb4f5550 oops
On Thursday, 8 of November 2007, Grant Wilson wrote: On Thu, 8 Nov 2007 16:53:10 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Thursday, 8 of November 2007, Grant Wilson wrote: On Thu, 8 Nov 2007 01:06:21 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Monday, 5 of November 2007, Grant Wilson wrote: Hi, I got this oops on 2.6.24-rc1-641-gb4f5550: (1) Is this reproducible? (2) Did it happen previously on your system? [18073.371126] Unable to handle kernel NULL pointer dereference at 0120 RIP: [18073.371134] [8023572e] check_preempt_wakeup+0x6e/0x110 This has now happened twice - the second time was last night when running 2.6.24-rc2. Here's that second occurrence: [snip] Hmm. Please run gdb vmlinux and see what code corresponds to check_preempt_wakeup+0x6e in your kernel. Dump of assembler code for function check_preempt_wakeup: Well, thanks, but I meant the source code. Please do gdb vmlinux and then l *check_preempt_wakeup+0x6e in gdb. Thanks, Rafael - 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 05/05] ipv6: RFC4214 Support (2)
From: Fred L. Templin [EMAIL PROTECTED] This is experimental support for the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses the SIT module, and is configured using the unmodified ip utility with device names beginning with: isatap. The following diffs are specific to the Linux 2.6.24-rc2 kernel distribution. Signed-off-by: Fred L. Templin [EMAIL PROTECTED] --- --- linux-2.6.24-rc2/net/ipv6/Kconfig.orig 2007-11-08 12:07:17.0 -0800 +++ linux-2.6.24-rc2/net/ipv6/Kconfig 2007-11-08 08:27:48.0 -0800 @@ -57,6 +57,17 @@ config IPV6_ROUTE_INFO If unsure, say N. +config IPV6_ISATAP + bool IPv6: ISATAP (RFC 4214) support (EXPERIMENTAL) + depends on IPV6 EXPERIMENTAL + ---help--- + This is experimental support for the Intra-Site Automatic + Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses + the SIT module, and is configured using the ip utility + with device names beginning with: isatap. + + If unsure, say N. + config IPV6_OPTIMISTIC_DAD bool IPv6: Enable RFC 4429 Optimistic DAD (EXPERIMENTAL) depends on IPV6 EXPERIMENTAL - 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] ipconfig.c : implement DHCP Class-identifier
On Thu, 8 Nov 2007, Rainer Jochem wrote:
@@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
*e++ = sizeof(ic_req_params);
memcpy(e, ic_req_params, sizeof(ic_req_params));
e += sizeof(ic_req_params);
+
+ // Send it only if the according kernel parameter was set
No C99 comments please. Though I'm not sure if this comment is that
necessary anyway...
+ if (*vendor_class_identifier) {
+ printk(KERN_INFO Sending class identifier \%s\\n,
+vendor_class_identifier);
+ *e++ = 60; /* Class-identifier */
+ *e++ = strlen(vendor_class_identifier);
+ memcpy(e, vendor_class_identifier,
+strlen(vendor_class_identifier));
+ e += strlen(vendor_class_identifier);
+ }
}
*e++ = 255; /* End of the list */
--
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] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
Sergej Stepanov wrote: If both mdio and mdc controlling pins are on the same processor port, one resource should be used. Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc. How about: The first reg resource is the I/O port register block on which MDIO resides. The second reg resource is the I/O port register block on which MDC resides. If there is only one reg resource, it is used for both MDIO and MDC. We also need to change the reference to port C in fsl,mdio-pin and fsl,mdc-pin. -Scott - 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 01/05] r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard
Signed-off-by: Ciaran McCreesh [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b94fa7e..702334e 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -171,6 +171,8 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(0x16ec,0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS,0x1032,
PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
+ { 0x0001, 0x8168,
+ PCI_ANY_ID, 0x2410, 0, 0, RTL_CFG_2 },
{0,},
};
--
1.5.3.3
-
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: 2.6.24-rc1-gb4f5550 oops
On Thursday, 8 of November 2007, Grant Wilson wrote:
On Thu, 8 Nov 2007 22:42:21 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Thursday, 8 of November 2007, Grant Wilson wrote:
On Thu, 8 Nov 2007 16:53:10 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Thursday, 8 of November 2007, Grant Wilson wrote:
On Thu, 8 Nov 2007 01:06:21 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Monday, 5 of November 2007, Grant Wilson wrote:
Hi,
I got this oops on 2.6.24-rc1-641-gb4f5550:
(1) Is this reproducible?
(2) Did it happen previously on your system?
[18073.371126] Unable to handle kernel NULL pointer dereference at
0120 RIP:
[18073.371134] [8023572e] check_preempt_wakeup+0x6e/0x110
This has now happened twice - the second time was last night when
running 2.6.24-rc2.
Here's that second occurrence:
[snip]
Hmm.
Please run gdb vmlinux and see what code corresponds to
check_preempt_wakeup+0x6e in your kernel.
Dump of assembler code for function check_preempt_wakeup:
Well, thanks, but I meant the source code. Please do gdb vmlinux and then
l *check_preempt_wakeup+0x6e in gdb.
Here's the requested output:
(gdb) l *check_preempt_wakeup+0x6e
0x802329ae is in check_preempt_wakeup (kernel/sched_fair.c:668).
663
664 /* Do the two (enqueued) entities belong to the same group ? */
665 static inline int
666 is_same_group(struct sched_entity *se, struct sched_entity *pse)
667 {
668 if (se-cfs_rq == pse-cfs_rq)
669 return 1;
670
671 return 0;
672 }
Well, it looks like either se or pse is NULL.
Ingo, can you please have a look?
Thanks,
Rafael
-
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: Why does a connect to IPv6 LLA address fail ?
Karsten Keil wrote: OK I run into this issue while running the TAHI testsuite. The test is as follows: Check 03: DNS Address: fec0::9 Candidate Source Addresses: fec0::1(SS) or LLA(LS) Destination Address List: 3fff::2(GS) or fe80::2(LS) Result: fe80::2 (src LLA) then 3fff::2 (src fec0::1) Scope(fe80::2) = Scope(LLA) and Scope(3fff::2) Scope(fec0::1), then prefer fe80::2 the nameserver send following answer for the query: | | | | DNS_Question(length:21) | | | | | DNS_QuestionEntry (length:21) | | | | | | Name = server.tahi.org. | | | | | | Type = 28 () | | | | | | Class= 1 | | | | DNS_Answer (length:86) | | | | | DNS_RR_ (length:43) | | | | | | Name = server.tahi.org. | | | | | | Type = 28 | | | | | | Class= 1 | | | | | | TTL = 0 | | | | | | Length = 16 | | | | | | Address = 3fff::2 | | | | | DNS_RR_ (length:43) | | | | | | Name = server.tahi.org. | | | | | | Type = 28 | | | | | | Class= 1 | | | | | | TTL = 0 | | | | | | Length = 16 | | | | | | Address = fe80::2 So how we should handle this issue, claim that the test is wrong, the test should not use LLA for this ? You could argue that a DNS server should not return link-local addresses because there is no way for the DNS server to specify a correct zone. I believe this is actually documented somewhere... -vlad - 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 04/05] ipv6: RFC4214 Support (2)
From: Fred L. Templin [EMAIL PROTECTED]
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
ip utility with device names beginning with: isatap.
The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.
Signed-off-by: Fred L. Templin [EMAIL PROTECTED]
---
--- linux-2.6.24-rc2/net/ipv6/sit.c.orig2007-11-08 12:03:41.0
-0800
+++ linux-2.6.24-rc2/net/ipv6/sit.c 2007-11-08 08:31:08.0 -0800
@@ -16,6 +16,7 @@
* Changes:
* Roger Venning [EMAIL PROTECTED]: 6to4 support
* Nate Thompson [EMAIL PROTECTED]:6to4 support
+ * Fred L. Templin [EMAIL PROTECTED]:isatap support
*/
#include linux/module.h
@@ -154,6 +155,14 @@ static struct ip_tunnel * ipip6_tunnel_l
struct net_device *dev;
char name[IFNAMSIZ];
+#if defined(CONFIG_IPV6_ISATAP)
+ /* ISATAP (RFC4214) - router address in daddr */
+ if (!strncmp(parms-name, isatap, 6)) {
+ parms-i_key = parms-iph.daddr;
+ parms-iph.daddr = remote = 0;
+ }
+#endif
+
for (tp = __ipip6_bucket(parms); (t = *tp) != NULL; tp = t-next) {
if (local == t-parms.iph.saddr remote == t-parms.iph.daddr)
return t;
@@ -182,6 +191,11 @@ static struct ip_tunnel * ipip6_tunnel_l
dev-init = ipip6_tunnel_init;
nt-parms = *parms;
+#if defined(CONFIG_IPV6_ISATAP)
+ if (!strncmp(dev-name, isatap, 6))
+ dev-priv_flags |= IFF_ISATAP;
+#endif
+
if (register_netdevice(dev) 0) {
free_netdev(dev);
goto failed;
@@ -382,6 +396,47 @@ static int ipip6_rcv(struct sk_buff *skb
IPCB(skb)-flags = 0;
skb-protocol = htons(ETH_P_IPV6);
skb-pkt_type = PACKET_HOST;
+#if defined(CONFIG_IPV6_ISATAP)
+ /* ISATAP (RFC4214) - check source address */
+ if (tunnel-dev-priv_flags IFF_ISATAP) {
+ struct neighbour *neigh;
+ struct dst_entry *dst;
+ struct flowi fl;
+ struct in6_addr *addr6;
+ struct ipv6hdr *iph6;
+
+ /* from ISATAP router */
+ if (iph-saddr == tunnel-parms.i_key) goto accept;
+
+ iph6 = ipv6_hdr(skb);
+ addr6 = iph6-saddr;
+
+ /* from legitimate previous hop */
+ memset(fl, 0, sizeof(fl));
+ fl.proto = iph6-nexthdr;
+ ipv6_addr_copy(fl.fl6_dst, addr6);
+ fl.oif = tunnel-dev-ifindex;
+ security_skb_classify_flow(skb, fl);
+
+ if (!(dst = ip6_route_output(NULL, fl)) ||
+(dst-dev != tunnel-dev) ||
+((neigh = dst-neighbour) == NULL)) goto drop;
+
+ addr6 = (struct in6_addr*)neigh-primary_key;
+
+ if (!(ipv6_addr_is_isatap(addr6)) ||
+(addr6-s6_addr32[3] != iph-saddr)) {
+drop:
+ tunnel-stat.rx_errors++;
+ read_unlock(ipip6_lock);
+ dst_release(dst);
+ kfree_skb(skb);
+ return 0;
+ }
+ dst_release(dst);
+ }
+accept:
+#endif
tunnel-stat.rx_packets++;
tunnel-stat.rx_bytes += skb-len;
skb-dev = tunnel-dev;
@@ -444,6 +499,31 @@ static int ipip6_tunnel_xmit(struct sk_b
if (skb-protocol != htons(ETH_P_IPV6))
goto tx_error;
+#if defined(CONFIG_IPV6_ISATAP)
+ /* ISATAP (RFC4214) - must come before 6to4 */
+ if (dev-priv_flags IFF_ISATAP) {
+ struct neighbour *neigh = NULL;
+
+ if (skb-dst)
+ neigh = skb-dst-neighbour;
+
+ if (neigh == NULL) {
+ if (net_ratelimit())
+ printk(KERN_DEBUG sit: nexthop == NULL\n);
+ goto tx_error;
+ }
+
+ addr6 = (struct in6_addr*)neigh-primary_key;
+ addr_type = ipv6_addr_type(addr6);
+
+ if ((addr_type IPV6_ADDR_UNICAST)
+ipv6_addr_is_isatap(addr6))
+ dst = addr6-s6_addr32[3];
+ else
+ goto tx_error;
+ }
+#endif /* CONFIG_IPV6_ISATAP */
+
if (!dst)
dst = try_6to4(iph6-daddr);
-
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 03/05] ipv6: RFC4214 Support (2)
From: Fred L. Templin [EMAIL PROTECTED]
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
ip utility with device names beginning with: isatap.
The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.
Signed-off-by: Fred L. Templin [EMAIL PROTECTED]
---
--- linux-2.6.24-rc2/net/ipv6/addrconf.c.orig 2007-11-08 11:59:35.0
-0800
+++ linux-2.6.24-rc2/net/ipv6/addrconf.c2007-11-08 11:28:43.0
-0800
@@ -75,7 +75,7 @@
#include net/ip.h
#include net/netlink.h
#include net/pkt_sched.h
-#include linux/if_tunnel.h
+#include net/ipip.h
#include linux/rtnetlink.h
#ifdef CONFIG_IPV6_PRIVACY
@@ -1435,6 +1435,11 @@ static int ipv6_generate_eui64(u8 *eui,
return addrconf_ifid_arcnet(eui, dev);
case ARPHRD_INFINIBAND:
return addrconf_ifid_infiniband(eui, dev);
+#if defined(CONFIG_IPV6_ISATAP)
+ case ARPHRD_SIT:
+ if (dev-priv_flagsIFF_ISATAP)
+ return ipv6_isatap_eui64(eui, *(__be32 *)dev-dev_addr);
+#endif
}
return -1;
}
@@ -2201,6 +2206,31 @@ static void addrconf_sit_config(struct n
return;
}
+#if defined(CONFIG_IPV6_ISATAP)
+ /* ISATAP (RFC4214) - configure as NBMA link */
+ if (dev-priv_flags IFF_ISATAP) {
+ struct in6_addr addr;
+
+ addrconf_add_lroute(dev);
+
+ ipv6_addr_set(addr, htonl(0xFE80), 0, 0, 0);
+
+ if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) {
+ struct inet6_ifaddr *ifp;
+
+ ifp = ipv6_add_addr(idev, addr, 64,
+ IFA_LINK, IFA_F_PERMANENT);
+ if (!IS_ERR(ifp)) {
+ addrconf_prefix_route(ifp-addr,
+ ifp-prefix_len, idev-dev, 0, 0);
+ addrconf_dad_start(ifp, 0);
+ in6_ifa_put(ifp);
+ }
+ }
+ return;
+ }
+#endif
+
sit_add_v4_addrs(idev);
if (dev-flagsIFF_POINTOPOINT) {
@@ -2531,6 +2561,16 @@ static void addrconf_rs_timer(unsigned l
* Announcement received after solicitation
* was sent
*/
+#if defined(CONFIG_IPV6_ISATAP)
+ /* ISATAP (RFC4214) - Re-DAD to trigger new RS/RA */
+ if (ifp-idev-dev-priv_flags IFF_ISATAP) {
+ spin_lock(ifp-lock);
+ ifp-probes = 0;
+ ifp-idev-if_flags = ~(IF_RS_SENT|IF_RA_RCVD);
+ addrconf_mod_timer(ifp, AC_DAD, HZ*120);
+ spin_unlock(ifp-lock);
+ }
+#endif
goto out;
}
@@ -2545,10 +2585,30 @@ static void addrconf_rs_timer(unsigned l
ifp-idev-cnf.rtr_solicit_interval);
spin_unlock(ifp-lock);
+#if defined(CONFIG_IPV6_ISATAP)
+ /* ISATAP (RFC4214) - unicast RS */
+ if (ifp-idev-dev-priv_flags IFF_ISATAP) {
+ struct ip_tunnel *t = netdev_priv(ifp-idev-dev);
+ __be32 rtr = t-parms.i_key;
+
+ if (!rtr) goto out;
+
+ ipv6_addr_set(all_routers, htonl(0xFE80), 0, 0, 0);
+ ipv6_isatap_eui64(all_routers.s6_addr + 8, rtr);
+ } else
+#endif
ipv6_addr_all_routers(all_routers);
ndisc_send_rs(ifp-idev-dev, ifp-addr, all_routers);
} else {
+#if defined(CONFIG_IPV6_ISATAP)
+ /* ISATAP (RFC4214) - Re-DAD to trigger new RS/RA */
+ if (ifp-idev-dev-priv_flags IFF_ISATAP) {
+ ifp-probes = 0;
+ ifp-idev-if_flags = ~(IF_RS_SENT|IF_RA_RCVD);
+ addrconf_mod_timer(ifp, AC_DAD, HZ*120);
+ }
+#endif
spin_unlock(ifp-lock);
/*
* Note: we do not support deprecated all on-link
@@ -2594,6 +2654,9 @@ static void addrconf_dad_start(struct in
spin_lock_bh(ifp-lock);
if (dev-flags(IFF_NOARP|IFF_LOOPBACK) ||
+#if defined(CONFIG_IPV6_ISATAP)
+ dev-priv_flagsIFF_ISATAP ||
+#endif
!(ifp-flagsIFA_F_TENTATIVE) ||
ifp-flags IFA_F_NODAD) {
ifp-flags = ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
@@ -2690,6 +2753,18 @@ static void addrconf_dad_completed(struc
(ipv6_addr_type(ifp-addr) IPV6_ADDR_LINKLOCAL)) {
struct in6_addr all_routers;
+#if defined(CONFIG_IPV6_ISATAP)
+ /* ISATAP (RFC4214) - unicast RS */
+ if (ifp-idev-dev-priv_flags IFF_ISATAP) {
+ struct ip_tunnel *t =
Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
On Thu, 8 Nov 2007 21:39:52 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
On Thu, 8 Nov 2007 17:16:11 +0300
Anton Vorontsov [EMAIL PROTECTED] wrote:
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
Hello all,
the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
according to erratum #2 (erratum text included below). Basically the
most intrusive part is the addition of two new RGMII Internal Delay
modes; one for TX delay only, and the other for RX delay only (i.e, not
both at the same time).
Please review, and since this affects both netdev and powerpc trees,
one maintainer should ack them for the other to push upstream (i.e,
Kumar acks them, and Leo picks them up to go through netdev or the
other way around; either way is fine with me). I'm hoping they're
trivial enough to go in 2.6.24.
Depending on how the review goes, a follow-on patch to u-boot will be
sent out that fixes up the phy-connection-type in the device tree (from
rgmii-id to rgmii-rxid iff on mpc8360rev2.1).
I've upgraded CPU to rev2.1, board rev0.3.
thanks for testing this. I tested these patches on a pilot assy 0.3.
Same here.
Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
the results:
If I use -rxid, then geth not able to transmit anything.
With -txid geth not able to receive anything.
With just -id everything works fine though...
Maybe there should be another condition, in addition to cpu rev2.1?
the errata simply states 'pilot boards', but we can probably modify
u-boot to look at the cpu rev and the board rev (BCSR 12).
My bcsr12 looks like:
= md.b f80c 1
f80c: 10.
what is yours?
= md.b f80c 1
f80c: 10.
:-/
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
[EMAIL PROTECTED]:~# cat /proc/cpuinfo
processor : 0
cpu : e300c1
clock : 528.00MHz
revision: 3.1 (pvr 8083 0031)
bogomips: 131.58
timebase: 6600
platform: MPC836x MDS
check. :/
+ /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+ svid = mfspr(SPRN_SVR);
+ if (svid == 0x80480021) {
^^ that branch executes on the board I'm testing.
right, but whether it does or not doesn't affect your failure outcome
either I'm assuming.
If it's something like 0x03, the u-boot patch will probably look like:
if ((bcsr[12] == 0x10)
(immr-sysconf.spridr == SPR_8360_REV21 ||
immr-sysconf.spridr == SPR_8360E_REV21))
/* if phy-connection-type is rgmii-id, set it to rgmii-rxid */
...
but these linux patches would remain the same (the clk and data delay
settings for the UCC's are still valid; it's just the PHY config
that is triggering your problem from what I can tell).
Yup, most likely this is not UCC specific, but PHY. For some reason
delays making harm here...
hmm..
Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
I have jumper JP1 set to 3.3V.
can you send me your:
= md.b f800 15
f800: 04 04 00 c6 94 60 00 00 ac 2f 00 b8 10 3f 30 02.`.../...?0.
f810: 05 07 05 15 11.
and maybe try the following on top of these 5 patches (to specify rgmii
mode in the bcsr's):
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0a72260..753071e 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -98,6 +98,11 @@ static void __init mpc836x_mds_setup_arch(void)
!= NULL){
uint svid;
+ /* configure RGMII mode for both GETH ports */
+#define BCSR8_TSECXM_RGMII 0xf0
+ clrbits8(bcsr_regs[8], BCSR8_TSECXM_RGMII);
+
+
/* Reset the Ethernet PHY */
#define BCSR9_GETHRST 0x20
clrbits8(bcsr_regs[9], BCSR9_GETHRST);
Thanks,
Kim
-
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] NET: Add the helper kernel_sock_shutdown()
Trond Myklebust [EMAIL PROTECTED] wrote: Looking at the sock-op-shutdown() handlers, it looks as if all of them take a SHUT_RD/SHUT_WR/SHUT_RDWR argument instead of the RCV_SHUTDOWN/SEND_SHUTDOWN arguments. Add a helper, and then define the SHUT_* enum to ensure that kernel users of shutdown() don't get confused. Acked-by: David Howells [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
[PATCH 01/05] ipv6: RFC4214 Support (2)
From: Fred L. Templin [EMAIL PROTECTED] This is experimental support for the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses the SIT module, and is configured using the unmodified ip utility with device names beginning with: isatap. The following diffs are specific to the Linux 2.6.24-rc2 kernel distribution. Signed-off-by: Fred L. Templin [EMAIL PROTECTED] --- --- linux-2.6.24-rc2/include/linux/if.h.orig2007-11-08 12:05:47.0 -0800 +++ linux-2.6.24-rc2/include/linux/if.h 2007-11-08 08:26:44.0 -0800 @@ -61,6 +61,7 @@ #define IFF_MASTER_ALB 0x10/* bonding master, balance-alb. */ #define IFF_BONDING0x20/* bonding master or slave */ #define IFF_SLAVE_NEEDARP 0x40 /* need ARPs for validation */ +#define IFF_ISATAP 0x80/* ISATAP interface (RFC4214) */ #define IF_GET_IFACE 0x0001 /* for querying only */ #define IF_GET_PROTO 0x0002 - 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 02/05] ipv6: RFC4214 Support (2)
From: Fred L. Templin [EMAIL PROTECTED]
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
ip utility with device names beginning with: isatap.
The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.
Signed-off-by: Fred L. Templin [EMAIL PROTECTED]
---
--- linux-2.6.24-rc2/include/net/addrconf.h.orig2007-11-08
12:06:17.0 -0800
+++ linux-2.6.24-rc2/include/net/addrconf.h 2007-11-08 08:27:24.0
-0800
@@ -241,6 +241,37 @@ static inline int ipv6_addr_is_ll_all_ro
addr-s6_addr32[3] == htonl(0x0002));
}
+#if defined(CONFIG_IPV6_ISATAP)
+static inline int ipv6_isatap_eui64(u8 *eui, __be32 addr)
+{
+
+ /* RFC3330 Special-Use IPv4 Addresses */
+ eui[0] = (((addr htonl(0xFF00)) == htonl(0x)) ||
+ ((addr htonl(0xFF00)) == htonl(0x0A00)) ||
+ ((addr htonl(0xFF00)) == htonl(0x0D00)) ||
+ ((addr htonl(0xFF00)) == htonl(0x1800)) ||
+ ((addr htonl(0xFF00)) == htonl(0x7F00)) ||
+ ((addr htonl(0x)) == htonl(0xA9FE)) ||
+ ((addr htonl(0xFFF0)) == htonl(0xAC10)) ||
+ ((addr htonl(0xFF00)) == htonl(0xC200)) ||
+ ((addr htonl(0xFF00)) == htonl(0xC0586300)) ||
+ ((addr htonl(0x)) == htonl(0xC0A8)) ||
+ ((addr htonl(0xFFFE)) == htonl(0xC612)) ||
+ ((addr htonl(0xF000)) == htonl(0xE000)) ||
+ ((addr htonl(0xF000)) == htonl(0xF000))) ?
+ 0x00 : 0x02;
+
+ eui[1] = 0; eui[2] = 0x5E; eui[3] = 0xFE;
+ memcpy (eui+4, addr, 4);
+ return 0;
+}
+
+static inline int ipv6_addr_is_isatap(const struct in6_addr *addr)
+{
+ return ((addr-s6_addr32[2] | htonl(0x0200)) == htonl(0x02005EFE));
+}
+#endif
+
#ifdef CONFIG_PROC_FS
extern int if6_proc_init(void);
extern void if6_proc_exit(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: No implementation of NETLINK_USERSOCK ?
Following up on myself... On Thu, Nov 08, 2007 at 05:15:12PM +0200, Matti Aarnio wrote: Some 6 months ago I asked about a way to make network protocol servers(s) that live in userspace, but whose application interface still uses kernel socket calls. I recall getting an answer that there is NETLINK_USERSOCK for that use. I have tried to have a look into what NETLINK_USERSOCK supplies to its users, but alas there appears to be no implementation at all in existence. Is it some sort of placeholder of things to implement some day ? The more I am reading around places, the more it looks like there really is no implementation, but somebody thought that such would be a nice thing to have. It did appear around Linux 2.2, and probable reservation maker was Alexey N. Kuznetsov. So, in order to implement the thing, something must be defined at first. Requirements are at least: - Applications see SOCKET API, and addresses are presentable via struct sockaddr* -- meaning that 16 bit sa_family leads the record, or possibly leading byte is record size and second one is family. - sa_family number space must be somehow managed, for example with file: /etc/socketfamilies #PF_## value: 128-254 #nn 'struct sockaddr' size in bytes # # PF_### keyword name # Explanatory name # 128 36 PF_USERSOCK1 Experimental usersock 1 129 80 PF_USERSOCK2 Experimental usersock 2 130 22 PF_USERSOCK3 Experimental usersock 3 And why not all the built in hard-coded ones, too. The sa_family numbers _must_ be static for at least machine runtime, even if they are otherwise quite dynamic in nature. (Registering and reading them from /proc/sys/... -file is a possibility.) - There is only one NETLINK_USERSOCK, but it should somehow manage N different protocols. N being at least 32. - Netlink itself is unrealiable protocol, but applications should still be able to read() and write() from it reliably. There is some reliability-thing in documentation. - For all intents and purposes the only difference from well established socket API based protocols, applications using NETLINK_USERSOCK implemented ones shall not be aware of anything being different except with the the how PF_ literal is resolved. What else is needed ? Any pointers on how to construct this framework ? Or does it exist although I didn't spot it yet ? /Matti Aarnio - 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 04/05] ipv6: RFC4214 Support
Hmm, what is missing from API POV? This would have to be determined under a follow-on project (hopefully with input from others) after we have gained operational experience. Since even if you do not change iproute2 now, users may need to change their configuration script twice anyway, we should be careful. The unmodified iproute2 gives a basic API that is sufficient for now. A more feature-rich API can be developed later, but the basic API will remain in place such that no existing scripts would have to change and new scripts could benefit from the new API. Thanks - Fred [EMAIL PROTECTED] --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: 2.6.24-rc1-gb4f5550 oops
On Thu, 8 Nov 2007 22:42:21 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Thursday, 8 of November 2007, Grant Wilson wrote:
On Thu, 8 Nov 2007 16:53:10 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Thursday, 8 of November 2007, Grant Wilson wrote:
On Thu, 8 Nov 2007 01:06:21 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Monday, 5 of November 2007, Grant Wilson wrote:
Hi,
I got this oops on 2.6.24-rc1-641-gb4f5550:
(1) Is this reproducible?
(2) Did it happen previously on your system?
[18073.371126] Unable to handle kernel NULL pointer dereference at
0120 RIP:
[18073.371134] [8023572e] check_preempt_wakeup+0x6e/0x110
This has now happened twice - the second time was last night when
running 2.6.24-rc2.
Here's that second occurrence:
[snip]
Hmm.
Please run gdb vmlinux and see what code corresponds to
check_preempt_wakeup+0x6e in your kernel.
Dump of assembler code for function check_preempt_wakeup:
Well, thanks, but I meant the source code. Please do gdb vmlinux and then
l *check_preempt_wakeup+0x6e in gdb.
Here's the requested output:
(gdb) l *check_preempt_wakeup+0x6e
0x802329ae is in check_preempt_wakeup (kernel/sched_fair.c:668).
663
664 /* Do the two (enqueued) entities belong to the same group ? */
665 static inline int
666 is_same_group(struct sched_entity *se, struct sched_entity *pse)
667 {
668 if (se-cfs_rq == pse-cfs_rq)
669 return 1;
670
671 return 0;
672 }
Grant
-
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 04/05] ipv6: RFC4214 Support
From: Templin, Fred L [EMAIL PROTECTED] Date: Thu, 8 Nov 2007 13:01:34 -0800 Hmm, what is missing from API POV? This would have to be determined under a follow-on project (hopefully with input from others) after we have gained operational experience. I personally don't buy any of this desire to avoid iproute2 changes at this time. This is never how we handle this kind of situation. We add in the new feature, and add support to iproute2 in parallel. If we screw it up we figure that out quickly and fix things before it's been deployed for too long. I suspect you simply want users to just be able to use the new feature with only a kernel patch, but that's not an appropriate reason to not do things correctly when submitting a feature upstream. Please use the new name in the kernel side changes and implement iproute2 support for these ISATAP devices. Thank you. - 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] forcedeth new mcp79 device ids
This patch adds new device ids for mcp79 devices. Signed-off-by: Ayaz Abdulla [EMAIL PROTECTED] --- old/include/linux/pci_ids.h 2007-11-07 14:14:01.0 -0500 +++ new/include/linux/pci_ids.h 2007-11-07 14:13:53.0 -0500 @@ -1237,6 +1237,10 @@ #define PCI_DEVICE_ID_NVIDIA_NVENET_33 0x0761 #define PCI_DEVICE_ID_NVIDIA_NVENET_34 0x0762 #define PCI_DEVICE_ID_NVIDIA_NVENET_35 0x0763 +#define PCI_DEVICE_ID_NVIDIA_NVENET_36 0x0AB0 +#define PCI_DEVICE_ID_NVIDIA_NVENET_37 0x0AB1 +#define PCI_DEVICE_ID_NVIDIA_NVENET_38 0x0AB2 +#define PCI_DEVICE_ID_NVIDIA_NVENET_39 0x0AB3 #define PCI_VENDOR_ID_IMS 0x10e0 #define PCI_DEVICE_ID_IMS_TT1280x9128
[PATCH 2/2] forcedeth new mcp79 device ids
This patch adds new device ids and features for mcp79 devices into the
forcedeth driver.
Signed-off-by: Ayaz Abdulla [EMAIL PROTECTED]
--- old/drivers/net/forcedeth.c 2007-11-07 14:13:47.0 -0500
+++ new/drivers/net/forcedeth.c 2007-11-07 14:13:39.0 -0500
@@ -5613,6 +5613,22 @@
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_35),
.driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
},
+ { /* MCP79 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_36),
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
+ { /* MCP79 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_37),
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
+ { /* MCP79 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_38),
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
+ { /* MCP79 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_39),
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
{0,},
};
Re: [PATCH] [POWERPC] Fix typo #ifdef - #ifndef
On Sat, 03 Nov 2007 20:16:36 +0100 Jochen Friedrich [EMAIL PROTECTED] wrote: Subject: [PATCH] [POWERPC] Fix typo #ifdef - #ifndef Please put the powerpc outside the []. Because things inside [] get removed when the receiver applies the patch, but the subsystem identification (powerpc) is useful information which we want to carry into the permanent git record. (Although Paul might add it anyway - some git tree maintainers do). User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) This seems to be setting a record for MUA vandalism. Leading spaces were removed and various esoteric whitespace transformations were made. The diffs were small so I fixed them by hand. Please strangle your email client. - 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] Fix buglets in mpc5200 FEC code that are corrupting memory.
This is the reason I couldn't get user space started or connect to my
nfs server. Patch is against current linus git.
mpc5200 fec driver is corrupting memory. This patch fixes two bugs
where the wrong skb buffer was being referenced.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
drivers/net/fec_mpc52xx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index a8a0ee2..ddfcc0b 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
rskb = bcom_retrieve_buffer(priv-rx_dmatsk, status,
(struct bcom_bd **)bd);
- dma_unmap_single(dev-dev, bd-skb_pa, skb-len,
DMA_FROM_DEVICE);
+ dma_unmap_single(dev-dev, bd-skb_pa, rskb-len,
DMA_FROM_DEVICE);
/* Test for errors in received frame */
if (status BCOM_FEC_RX_BD_ERRORS) {
@@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
bcom_prepare_next_buffer(priv-rx_dmatsk);
bd-status = FEC_RX_BUFFER_SIZE;
- bd-skb_pa = dma_map_single(dev-dev, rskb-data,
+ bd-skb_pa = dma_map_single(dev-dev, skb-data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv-rx_dmatsk, skb);
--
Jon Smirl
[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
[2.6 patch] remove references to net-modules.txt
When I removed net-modules.txt because it only contained ancient information I missed that many Kconfig entries pointed to this ancient information. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- Documentation/networking/3c505.txt |3 drivers/net/Kconfig| 199 ++--- drivers/net/arcnet/Kconfig | 15 -- drivers/net/tulip/Kconfig | 21 +-- 4 files changed, 82 insertions(+), 156 deletions(-) 6451db6bafae46e17885b8c7b243095fc257e8ed diff --git a/Documentation/networking/3c505.txt b/Documentation/networking/3c505.txt index b9d5b72..72f38b1 100644 --- a/Documentation/networking/3c505.txt +++ b/Documentation/networking/3c505.txt @@ -14,8 +14,7 @@ If no base address is given at boot time, the driver will autoprobe ports 0x300, 0x280 and 0x310 (in that order). If no IRQ is given, the driver will try to probe for it. -The driver can be used as a loadable module. See net-modules.txt for details -of the parameters it can take. +The driver can be used as a loadable module. Theoretically, one instance of the driver can now run multiple cards, in the standard way (when loading a module, say modprobe 3c505 diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 5f800a6..0fdcf72 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -365,8 +365,7 @@ config MAC89x0 read the Ethernet-HOWTO, available from http://www.tldp.org/docs.html#howto. - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. This module will + To compile this driver as a module, choose M here. This module will be called mac89x0. config MACSONIC @@ -379,8 +378,7 @@ config MACSONIC one of these say Y and read the Ethernet-HOWTO, available from http://www.tldp.org/docs.html#howto. - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. This module will + To compile this driver as a module, choose M here. This module will be called macsonic. config MACMACE @@ -618,8 +616,7 @@ config EL1 have problems. Some people suggest to ping (man ping) a nearby machine every minute (man cron) when using this card. - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. The module + To compile this driver as a module, choose M here. The module will be called 3c501. config EL2 @@ -631,8 +628,7 @@ config EL2 the Ethernet-HOWTO, available from http://www.tldp.org/docs.html#howto. - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. The module + To compile this driver as a module, choose M here. The module will be called 3c503. config ELPLUS @@ -644,8 +640,7 @@ config ELPLUS this type, say Y and read the Ethernet-HOWTO, available from http://www.tldp.org/docs.html#howto. - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. The module + To compile this driver as a module, choose M here. The module will be called 3c505. config EL16 @@ -656,8 +651,7 @@ config EL16 the Ethernet-HOWTO, available from http://www.tldp.org/docs.html#howto. - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. The module + To compile this driver as a module, choose M here. The module will be called 3c507. config EL3 @@ -672,8 +666,7 @@ config EL3 setup disk to disable Plug Play mode, and to select the default media type. - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. The module + To compile this driver as a module, choose M here. The module will be called 3c509. config 3C515 @@ -684,8 +677,7 @@ config 3C515 network card, say Y and read the Ethernet-HOWTO, available from http://www.tldp.org/docs.html#howto. - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. The module + To compile this driver as a module, choose M here. The module will be called 3c515. config ELMC @@ -696,8 +688,7 @@ config ELMC the Ethernet-HOWTO, available from http://www.tldp.org/docs.html#howto. - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. The module + To compile this driver as a module, choose M here. The module will be called 3c523. config ELMC_II @@ -708,8 +699,7 @@ config ELMC_II
[PATCH] [AF_PACKET] Fix minor code duplication
Simplify some code by eliminating duplicate if-else clauses in
packet_do_bind().
Signed-off-by: Urs Thuermann [EMAIL PROTECTED]
--- net-2.6/net/packet/af_packet.c.orig 2007-11-05 13:07:28.0 +0100
+++ net-2.6/net/packet/af_packet.c 2007-11-08 12:14:25.0 +0100
@@ -886,20 +886,14 @@ static int packet_do_bind(struct sock *s
if (protocol == 0)
goto out_unlock;
- if (dev) {
- if (dev-flagsIFF_UP) {
- dev_add_pack(po-prot_hook);
- sock_hold(sk);
- po-running = 1;
- } else {
- sk-sk_err = ENETDOWN;
- if (!sock_flag(sk, SOCK_DEAD))
- sk-sk_error_report(sk);
- }
- } else {
+ if (!dev || (dev-flags IFF_UP)) {
dev_add_pack(po-prot_hook);
sock_hold(sk);
po-running = 1;
+ } else {
+ sk-sk_err = ENETDOWN;
+ if (!sock_flag(sk, SOCK_DEAD))
+ sk-sk_error_report(sk);
}
out_unlock:
-
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
