Re: [PATCH][IPSEC][4/7] inter address family ipsec tunnel
On Fri, 01 Dec 2006 13:41:39 +0900
Kazunori MIYAZAWA [EMAIL PROTECTED] wrote:
David Miller wrote:
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Fri, 24 Nov 2006 14:38:39 +0900
What is going on here?
+ /* Without this, the atomic inc below segfaults */
+ if (encap_family == AF_INET6) {
+ rt-peer = NULL;
+ rt_bind_peer(rt,1);
+ }
...
- dst_prev-output= xfrm4_output;
+ if (dst_prev-xfrm-props.family == AF_INET)
+ dst_prev-output = xfrm4_output;
+#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
+ else
+ dst_prev-output = xfrm6_output;
+#endif
if (rt-peer)
atomic_inc(rt-peer-refcnt);
If it's non-NULL and you get a segfault for atomic_inc() that
means there is garbage here, and it seems that if you're
setting it to NULL explicitly then it's just a workaround
for whatever problem is causing it to be non-NULL to begin
with.
What is putting a non-valid pointer value there? Is this an IPV6 or
IPSEC dst route by chance? If so, that makes this change really
wrong, and we are corrupting the route by running rt_bind_peer() on
it. rt_bind_peer() is only valid on ipv4 route entries.
Thank you for your good catch.
I think atomic_inc must be done in case of props.family == AF_INET.
And we probably should manage reference count of the device in case of
AF_INET6.
Anyway I'll check and fix it.
Thank you.
Hello David,
Sorry, I mixed up changes in the patches. I described that [4/7] will add
IPv6 over IPv4 IPsec tunnel. However I send a patch for IPv4 over IPv6
as a reply because it includes the discussing item.
So this patch adds IPv4 over IPv6 IPsec tunnel. It's complicated.
I deleted subustituting NULL for rt-peer and moved atomic_inc stuff
under the if section.
BTW, I have a question about descrementing the reference count of rt-peer.
The reference cound in normal dst structure is decremented by calling
inet_putpeer from ipv4_dst_destroy. But xfrm4_dst_destroy does not call
inet_putpeer.
Where do we decrement the count? Should xfrm4_dst_destroy do that?
Signed-off-by: Miika Komu [EMAIL PROTECTED]
Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
Signed-off-by: Kazunori Miyazawa [EMAIL PROTECTED]
---
net/ipv4/xfrm4_policy.c | 68 --
net/ipv6/xfrm6_mode_tunnel.c | 42 --
2 files changed, 83 insertions(+), 27 deletions(-)
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index d4107bb..37b14e8 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -72,17 +72,20 @@ __xfrm4_bundle_create(struct xfrm_policy
struct dst_entry *dst, *dst_prev;
struct rtable *rt0 = (struct rtable*)(*dst_p);
struct rtable *rt = rt0;
- __be32 remote = fl-fl4_dst;
- __be32 local = fl-fl4_src;
struct flowi fl_tunnel = {
.nl_u = {
.ip4_u = {
- .saddr = local,
- .daddr = remote,
+ .saddr = fl-fl4_src,
+ .daddr = fl-fl4_dst,
.tos = fl-fl4_tos
}
}
};
+ union {
+ struct in6_addr *in6;
+ struct in_addr *in;
+ } remote, local;
+ unsigned short encap_family = 0;
int i;
int err;
int header_len = 0;
@@ -94,7 +97,6 @@ __xfrm4_bundle_create(struct xfrm_policy
for (i = 0; i nx; i++) {
struct dst_entry *dst1 = dst_alloc(xfrm4_dst_ops);
struct xfrm_dst *xdst;
- int tunnel = 0;
if (unlikely(dst1 == NULL)) {
err = -ENOBUFS;
@@ -116,19 +118,45 @@ __xfrm4_bundle_create(struct xfrm_policy
dst1-next = dst_prev;
dst_prev = dst1;
- if (xfrm[i]-props.mode != XFRM_MODE_TRANSPORT) {
- remote = xfrm[i]-id.daddr.a4;
- local = xfrm[i]-props.saddr.a4;
- tunnel = 1;
+
+ if (xfrm[i]-props.mode == XFRM_MODE_TUNNEL) {
+ encap_family = xfrm[i]-props.family;
+
+ switch(encap_family) {
+ case AF_INET:
+ remote.in = (struct in_addr*)xfrm[i]-id.daddr;
+ local.in = (struct
in_addr*)xfrm[i]-props.saddr;
+ break;
+#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
+ case AF_INET6:
+ remote.in6 = (struct
in6_addr*)xfrm[i]-id.daddr;
+ local.in6 = (struct
in6_addr*)xfrm[i]-props.saddr;
+
Re: [PATCH][IPSEC][5/7] inter address family ipsec tunnel
On Thu, 30 Nov 2006 16:49:03 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Fri, 24 Nov 2006 14:38:52 +0900
+static inline void ip6ip_ecn_decapsulate(struct sk_buff *skb)
+{
+ if (INET_ECN_is_ce(ipv6_get_dsfield(skb-nh.ipv6h)))
+ IP_ECN_set_ce(skb-h.ipiph);
+}
+
Please fix this extra tab indentation :-)
Thank you.
I fixed. As mentioned in another mail, I mixed up the changes
in my previous patch. This adds IPv6 over IPv4 IPsec tunnel.
The fix of extra tab is included in another mail.
Signed-off-by: Miika Komu [EMAIL PROTECTED]
Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
Signed-off-by: Kazunori Miyazawa [EMAIL PROTECTED]
---
net/ipv4/xfrm4_mode_tunnel.c | 57 ++
net/ipv6/xfrm6_policy.c | 48 +--
2 files changed, 80 insertions(+), 25 deletions(-)
diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c
index e23c21d..e54c549 100644
--- a/net/ipv4/xfrm4_mode_tunnel.c
+++ b/net/ipv4/xfrm4_mode_tunnel.c
@@ -23,6 +23,12 @@ static inline void ipip_ecn_decapsulate(
IP_ECN_set_ce(inner_iph);
}
+static inline void ipip6_ecn_decapsulate(struct iphdr *iph, struct sk_buff
*skb)
+{
+ if (INET_ECN_is_ce(iph-tos))
+ IP6_ECN_set_ce(skb-nh.ipv6h);
+}
+
/* Add encapsulation header.
*
* The top IP header will be constructed per RFC 2401. The following fields
@@ -36,6 +42,7 @@ static inline void ipip_ecn_decapsulate(
static int xfrm4_tunnel_output(struct xfrm_state *x, struct sk_buff *skb)
{
struct dst_entry *dst = skb-dst;
+ struct xfrm_dst *xdst = (struct xfrm_dst*)dst;
struct iphdr *iph, *top_iph;
int flags;
@@ -48,15 +55,27 @@ static int xfrm4_tunnel_output(struct xf
top_iph-ihl = 5;
top_iph-version = 4;
+ flags = x-props.flags;
+
/* DS disclosed */
- top_iph-tos = INET_ECN_encapsulate(iph-tos, iph-tos);
+ if (xdst-route-ops-family == AF_INET) {
+ top_iph-protocol = IPPROTO_IPIP;
+ top_iph-tos = INET_ECN_encapsulate(iph-tos, iph-tos);
+ top_iph-frag_off = (flags XFRM_STATE_NOPMTUDISC) ?
+ 0 : (iph-frag_off htons(IP_DF));
+ }
+#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
+ else {
+ struct ipv6hdr *ipv6h = (struct ipv6hdr*)iph;
+ top_iph-protocol = IPPROTO_IPV6;
+ top_iph-tos = INET_ECN_encapsulate(iph-tos,
ipv6_get_dsfield(ipv6h));
+ top_iph-frag_off = 0;
+ }
+#endif
- flags = x-props.flags;
if (flags XFRM_STATE_NOECN)
IP_ECN_clear(top_iph);
- top_iph-frag_off = (flags XFRM_STATE_NOPMTUDISC) ?
- 0 : (iph-frag_off htons(IP_DF));
if (!top_iph-frag_off)
__ip_select_ident(top_iph, dst-child, 0);
@@ -64,7 +83,6 @@ static int xfrm4_tunnel_output(struct xf
top_iph-saddr = x-props.saddr.a4;
top_iph-daddr = x-id.daddr.a4;
- top_iph-protocol = IPPROTO_IPIP;
memset((IPCB(skb)-opt), 0, sizeof(struct ip_options));
return 0;
@@ -75,8 +93,16 @@ static int xfrm4_tunnel_input(struct xfr
struct iphdr *iph = skb-nh.iph;
int err = -EINVAL;
- if (iph-protocol != IPPROTO_IPIP)
- goto out;
+ switch(iph-protocol){
+ case IPPROTO_IPIP:
+#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
+ case IPPROTO_IPV6:
+ break;
+#endif
+ default:
+ goto out;
+ }
+
if (!pskb_may_pull(skb, sizeof(struct iphdr)))
goto out;
@@ -84,10 +110,19 @@ static int xfrm4_tunnel_input(struct xfr
(err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC)))
goto out;
- if (x-props.flags XFRM_STATE_DECAP_DSCP)
- ipv4_copy_dscp(iph, skb-h.ipiph);
- if (!(x-props.flags XFRM_STATE_NOECN))
- ipip_ecn_decapsulate(skb);
+ if (iph-protocol == IPPROTO_IPIP) {
+ if (x-props.flags XFRM_STATE_DECAP_DSCP)
+ ipv4_copy_dscp(iph, skb-h.ipiph);
+ if (!(x-props.flags XFRM_STATE_NOECN))
+ ipip_ecn_decapsulate(skb);
+ }
+#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
+ else {
+ if (!(x-props.flags XFRM_STATE_NOECN))
+ ipip6_ecn_decapsulate(iph, skb);
+ skb-protocol = htons(ETH_P_IPV6);
+ }
+#endif
skb-mac.raw = memmove(skb-data - skb-mac_len,
skb-mac.raw, skb-mac_len);
skb-nh.raw = skb-data;
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 8dffd4d..a7f28bf 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -131,16 +131,19 @@
Re: [Devel] Re: Network virtualization/isolation
If there is a better and less intrusive while still being obvious method I am all for it. I do not like the OpenVZ thing of doing the lookup once and then stashing the value in current and the special casing the exceptions. Why? I like it when things are obvious and not implied. The implementations seems to favor fewer lines of code touched over maintainability of the code. Which if you are maintaining out of tree code is fine. At leas that was my impression last time I looked at the code. FYI, when we started doing networking virtualization many years ago we tried both approaches. Over time, context notion looked much more natural and easier for us. Even Alexey Kuznetsov tells that he prefers exec_env as the logic becomes very clear and little mess is introduced. I know there are a lot of silly things in the existing implementations because they were initially written without the expectation of being able to merge the code into the main kernel. This resulted in some non-general interfaces, and a preference for patches that touch as few lines of code as possible. Sure, but OpenVZ code is being constantly cleaned from such code and we are open for discussion. No one pretends that code is perferct from the beginning. Anyway this has bit has been discussed before and we can discuss it seriously in the context of patch review. Let me explain when explicit context like exec_env IMHO is cleaner: - context is a natural notion of linux kernel. e.g. current. why not pass 'current' to all the functions as an argument starting from entry.S? in_atomic(), in_interrupt() etc. all these functions deal with current context. IMHO when one needs to pass an argument too many times like 'current' it is better to use a notion of the context. - e.g. NFS should set networking context of the mount point or socket. But, ok, it is not the real point to argue so much imho and waste our time instead of doing things. Thanks, Kirill - 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 wireless-2.6-git] prism54: WPA/RSN support for fullmac cards
On Wednesday, 6. December 2006 02:44, you wrote: FYI...after latest round of merges, that patch that I've been carrying in the pending branch of wireless-2.6 no longer applies. John Ok, I'm waiting for Dmitry' feedback... (hello, where're you ;) ?) Christian - To unsubscribe from this list: 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: Kernel header changes break glibc build
On Mon, 2006-12-04 at 10:13 +0100, Thomas Graf wrote:
Userspace is not supposd to directly include kernel headers, instead
it has to make local copies and compile against them.
No. It was _never_ sensible to simply declare that userspace shall not
use kernel headers in the absence of any serious alternative. It was
always just a cop-out.
Historically, there were a number of efforts to provide 'sanitised'
kernel headers which are needed for userspace to build against. Various
people forked headers from the kernel at different times, got burned out
at different times, took different approaches w.r.t. how much abuse of
kernel-private stuff should be permitted. We ended up with a bunch of
inconsistent sets of 'kernel headers' each done differently and updated
sporadically.
Thankfully, this is no longer the case. The kernel now has a
'headers_install' make target which spits out those headers which are
suitable for userspace, sanitised by removing anything within
__KERNEL__. We have a _consistent_, up to date set of headers which
distributions can use for building glibc and other system libraries and
tools. Some distributions are already shipping like that; others are
still working on doing so.
Binary compatibility is always guaranteed but in times of development
within a stable tree it's wrong to assume that headers never change.
I do not agree with the change to include if_addr.h in rtnetlink.h.
The point is to move bits apart and have multiple small pieces
of header files defining a specific rtnetlink family which are a
lot easier to maintain for both kernel and userspace than one giant
rtnetlink.h for everything.
That makes some sense, but we need to be more careful about making
incompatible changes in the headers which we export -- it's no longer
acceptable to just toss a pile of crap over the wall and declare it to
be someone else's problem.
That isn't to say that we should _never_ make such changes, but we
should at least make sure we think about it and make sure that glibc
adapts to cope, _before_ people start to see build failures.
I suspect that if the IF{L,}A_{PAYLOAD,RTA} macros aren't used in the
kernel then the best answer is for glibc to define those for itself.
Right, if they did it right they would only have noticed when they
updated the kernel headers to some newer versions and only had to
move the bits to some compat header.
No. They _are_ doing it right -- they're running 'make headers_install'
against the 2.6.19 kernel and only _now_ are they finding that we broke
it without even the courtesy of a warning, let alone any consultation.
If _we_ had done it right, then they would have been warned when we
decided to change this, and we wouldn't have just released 2.6.19 with
changes which break the glibc build.
--
dwmw2
-
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: [NET_SCHED]: cls_fw: fix NULL pointer dereference
On 04-12-2006 16:34, Patrick McHardy wrote: Fix a regression from my nfmark mask patch for cls_fw. Thomas, Jamal, do you have an idea what this old method stuff is used for? It seems it is only used during the below mentioned race. Sorry for eavesdropping, but have a look at htb_classify starting comment. It is also used by unofficial but quite popular IPMARK target. Jarek P. - 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: Kernel header changes break glibc build
On Wed, Dec 06, 2006 at 01:01:54PM +, David Woodhouse wrote:
No. They _are_ doing it right -- they're running 'make headers_install'
against the 2.6.19 kernel and only _now_ are they finding that we broke
it without even the courtesy of a warning, let alone any consultation.
If _we_ had done it right, then they would have been warned when we
decided to change this, and we wouldn't have just released 2.6.19 with
changes which break the glibc build.
Yeah, I don't think glibc was doing anything wrong and the 2.6.19
changes to the make headers_install created headers mean we'd
either need to add configure checks for the headers (we can't
simply #include linux/if_addr.h because that header didn't
exist pre 2.6.19 and IF*_{RTA,PAYLOAD} macros were dropped anyway),
or we need to start defining this ourselves.
Here is the second variant.
I just hope further kernel header cleanups don't cause similar
breakage though.
2006-12-06 Jakub Jelinek [EMAIL PROTECTED]
* sysdeps/unix/sysv/linux/netlinkaccess.h (struct ifaddrmsg): New type.
(IFA_UNSPEC, IFA_ADDRESS, IFA_LOCAL, IFA_LABEL, IFA_BROADCAST,
IFA_ANYCAST, IFA_CACHEINFO, IFA_MULTICAST): New enum.
(IFA_F_SECONDARY, IFA_F_TEMPORARY, IFA_F_HOMEADDRESS,
IFA_F_DEPRECATED): Define if not defined.
(IFA_RTA, IFA_PAYLOAD, IFLA_RTA, IFLA_PAYLOAD): Likewise.
* sysdeps/unix/sysv/linux/check_pf.c: Include netlinkaccess.h
instead of asm/types.h, linux/netlink.h and linux/rtnetlink.h.
--- libc/sysdeps/unix/sysv/linux/netlinkaccess.h.jj 2006-01-08
09:21:15.0 +0100
+++ libc/sysdeps/unix/sysv/linux/netlinkaccess.h2006-12-06
13:48:50.0 +0100
@@ -25,6 +25,51 @@
#include kernel-features.h
+/* 2.6.19 kernel headers helpfully removed some macros and
+ moved lots of stuff into new headers, some of which aren't
+ included by linux/rtnetlink.h. */
+
+#ifndef IFA_MAX
+struct ifaddrmsg
+{
+ uint8_t ifa_family;
+ uint8_t ifa_prefixlen;
+ uint8_t ifa_flags;
+ uint8_t ifa_scope;
+ uint32_t ifa_index;
+};
+
+enum
+{
+ IFA_UNSPEC,
+ IFA_ADDRESS,
+ IFA_LOCAL,
+ IFA_LABEL,
+ IFA_BROADCAST,
+ IFA_ANYCAST,
+ IFA_CACHEINFO,
+ IFA_MULTICAST
+};
+#endif
+
+#ifndef IFA_F_SECONDARY
+# define IFA_F_SECONDARY 0x01
+# define IFA_F_TEMPORARY IFA_F_SECONDARY
+# define IFA_F_HOMEADDRESS 0x10
+# define IFA_F_DEPRECATED 0x20
+#endif
+
+#ifndef IFA_RTA
+# define IFA_RTA(r) \
+ ((struct rtattr *) ((char *)(r) + NLMSG_ALIGN (sizeof (struct ifaddrmsg
+# define IFA_PAYLOAD(n) NLMSG_PAYLOAD (n, sizeof (struct ifaddrmsg))
+#endif
+
+#ifndef IFLA_RTA
+# define IFLA_RTA(r) \
+ ((struct rtattr *) ((char *)(r) + NLMSG_ALIGN (sizeof (struct ifinfomsg
+# define IFLA_PAYLOAD(n) NLMSG_PAYLOAD (n, sizeof (struct ifinfomsg))
+#endif
struct netlink_res
{
--- libc/sysdeps/unix/sysv/linux/check_pf.c.jj 2006-09-24 18:50:22.0
+0200
+++ libc/sysdeps/unix/sysv/linux/check_pf.c 2006-12-06 13:54:37.0
+0100
@@ -27,13 +27,10 @@
#include unistd.h
#include sys/socket.h
-#include asm/types.h
-#include linux/netlink.h
-#include linux/rtnetlink.h
-
#include not-cancel.h
#include kernel-features.h
+#include netlinkaccess.h
#ifndef IFA_F_TEMPORARY
# define IFA_F_TEMPORARY IFA_F_SECONDARY
Jakub
-
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 some wireless ext stuff
This fixes compilation with d80211/cfg80211/wireless ext. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- linux-2.6-git.orig/net/core/net-sysfs.c 2006-12-06 12:31:04.247283692 +0100 +++ linux-2.6-git/net/core/net-sysfs.c 2006-12-06 12:31:11.865215130 +0100 @@ -329,7 +329,7 @@ .attrs = netstat_attrs, }; -#ifdef WIRELESS_EXT +#ifdef CONFIG_WIRELESS_EXT /* helper function that does all the locking etc for wireless stats */ static ssize_t wireless_show(struct class_device *cd, char *buf, ssize_t (*format)(const struct iw_statistics *, @@ -462,7 +462,7 @@ if (net-get_stats) *groups++ = netstat_group; -#ifdef WIRELESS_EXT +#ifdef CONFIG_WIRELESS_EXT if (net-wireless_handlers net-wireless_handlers-get_wireless_stats) *groups++ = wireless_group; #endif --- linux-2.6-git.orig/net/d80211/Kconfig 2006-12-06 12:31:58.903791779 +0100 +++ linux-2.6-git/net/d80211/Kconfig2006-12-06 12:32:07.355715711 +0100 @@ -3,6 +3,7 @@ select CRYPTO select CRYPTO_ARC4 select CRYPTO_AES + select WIRELESS_EXT ---help--- This option enables the hardware independent IEEE 802.11 networking stack. --- linux-2.6-git.orig/net/wireless/Makefile2006-12-06 12:35:58.838632346 +0100 +++ linux-2.6-git/net/wireless/Makefile 2006-12-06 12:36:03.541590019 +0100 @@ -12,5 +12,5 @@ # this needs to be compiled in... obj-$(CONFIG_CFG80211_WEXT_COMPAT) += wext-compat.o -obj-$(CONFIG_CFG80211_WEXTNL_COMPAT)$(CONFIG_NET_WIRELESS) += wext-common.o +obj-$(CONFIG_CFG80211_WEXT_COMPAT)$(CONFIG_NET_WIRELESS) += wext-common.o obj-y += $(obj-yy) $(obj-yn) $(obj-ny) - 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: Kernel header changes break glibc build
On Wed, 2006-12-06 at 14:43 +0100, Jakub Jelinek wrote:
+/* 2.6.19 kernel headers helpfully removed some macros and
+ moved lots of stuff into new headers, some of which aren't
+ included by linux/rtnetlink.h. */
+
+#ifndef IFA_MAX
+struct ifaddrmsg
+{
+ uint8_t ifa_family;
+ uint8_t ifa_prefixlen;
+ uint8_t ifa_flags;
+ uint8_t ifa_scope;
+ uint32_t ifa_index;
+};
+
+enum
+{
+ IFA_UNSPEC,
+ IFA_ADDRESS,
+ IFA_LOCAL,
+ IFA_LABEL,
+ IFA_BROADCAST,
+ IFA_ANYCAST,
+ IFA_CACHEINFO,
+ IFA_MULTICAST
+};
+#endif
+
+#ifndef IFA_F_SECONDARY
+# define IFA_F_SECONDARY 0x01
+# define IFA_F_TEMPORARY IFA_F_SECONDARY
+# define IFA_F_HOMEADDRESS 0x10
+# define IFA_F_DEPRECATED 0x20
+#endif
This much is still available from the new linux/if_addr.h -- you could
include that directly instead of copying it.
--
dwmw2
-
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: Kernel header changes break glibc build
* Jakub Jelinek [EMAIL PROTECTED] 2006-12-06 14:43
On Wed, Dec 06, 2006 at 01:01:54PM +, David Woodhouse wrote:
No. They _are_ doing it right -- they're running 'make headers_install'
against the 2.6.19 kernel and only _now_ are they finding that we broke
it without even the courtesy of a warning, let alone any consultation.
If _we_ had done it right, then they would have been warned when we
decided to change this, and we wouldn't have just released 2.6.19 with
changes which break the glibc build.
Yeah, I don't think glibc was doing anything wrong and the 2.6.19
changes to the make headers_install created headers mean we'd
either need to add configure checks for the headers (we can't
simply #include linux/if_addr.h because that header didn't
exist pre 2.6.19 and IF*_{RTA,PAYLOAD} macros were dropped anyway),
or we need to start defining this ourselves.
Are you suggesting that the kernel has to keep macros around which
are of no use to the kernel itself just because glibc uses them?
What's wrong with copying the headers and ship them? Every glibc
release is based on some kernel version anyway and its no problem
to run glibc compiled with a 2.6.19 header set on a 2.6.18 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
Re: Kernel header changes break glibc build
On Wed, Dec 06, 2006 at 01:51:07PM +, David Woodhouse wrote:
On Wed, 2006-12-06 at 14:43 +0100, Jakub Jelinek wrote:
+/* 2.6.19 kernel headers helpfully removed some macros and
+ moved lots of stuff into new headers, some of which aren't
+ included by linux/rtnetlink.h. */
+
+#ifndef IFA_MAX
+struct ifaddrmsg
+{
+ uint8_t ifa_family;
+ uint8_t ifa_prefixlen;
+ uint8_t ifa_flags;
+ uint8_t ifa_scope;
+ uint32_t ifa_index;
+};
+
+enum
+{
+ IFA_UNSPEC,
+ IFA_ADDRESS,
+ IFA_LOCAL,
+ IFA_LABEL,
+ IFA_BROADCAST,
+ IFA_ANYCAST,
+ IFA_CACHEINFO,
+ IFA_MULTICAST
+};
+#endif
+
+#ifndef IFA_F_SECONDARY
+# define IFA_F_SECONDARY 0x01
+# define IFA_F_TEMPORARY IFA_F_SECONDARY
+# define IFA_F_HOMEADDRESS 0x10
+# define IFA_F_DEPRECATED 0x20
+#endif
This much is still available from the new linux/if_addr.h -- you could
include that directly instead of copying it.
Yes, but as I said, I'd need to add configure checks for that, using
#include linux/if_addr.h
alone breaks build with older headers.
glibc so far managed to build without a single configure check for header
existence, this would be the first place where something like that is
needed.
Jakub
-
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: Kernel header changes break glibc build
On Wed, 2006-12-06 at 14:57 +0100, Jakub Jelinek wrote: Yes, but as I said, I'd need to add configure checks for that, using #include linux/if_addr.h alone breaks build with older headers. I was thinking that the #ifndef IFA_MAX you already have ought to be sufficient for that. Or even checking KERNEL_VERSION. -- dwmw2 - 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: Kernel header changes break glibc build
On Wed, 2006-12-06 at 14:59 +0100, Thomas Graf wrote: Are you suggesting that the kernel has to keep macros around which are of no use to the kernel itself just because glibc uses them? No, although in fact that _is_ the only reason we use these horrid __uXX types rather than proper C datatypes, isn't it? I'm suggesting that if you want to change things around as you did, you should make sure the users of those headers adapt to cope. You did fix the in-kernel users; you neglected to fix glibc -- and as far as I can tell you didn't even bother to _warn_ glibc folks. We need to do better than that. The dark ages where we used to toss a pile of crap over the wall and declare it was someone else's problem are now behind us, thankfully. -- dwmw2 - 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 wireless-2.6-git] prism54: WPA/RSN support for fullmac cards
On 12/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wednesday, 6. December 2006 02:44, you wrote: FYI...after latest round of merges, that patch that I've been carrying in the pending branch of wireless-2.6 no longer applies. John Ok, I'm waiting for Dmitry' feedback... (hello, where're you ;) ?) Sorry, busy time... I still have to do ifup eth1 manually after inserting the card to get it going. -- Dmitry - 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: Kernel header changes break glibc build
On Wed, Dec 06, 2006 at 02:07:19PM +, David Woodhouse wrote: On Wed, 2006-12-06 at 14:59 +0100, Thomas Graf wrote: Are you suggesting that the kernel has to keep macros around which are of no use to the kernel itself just because glibc uses them? No, although in fact that _is_ the only reason we use these horrid __uXX types rather than proper C datatypes, isn't it? There are the kernel's own headers and kernel ABI headers for userland use. Until recently the latter has been maintained by various distributions and manually occassionally updated to sync a little bit with kernel ABI additions (new syscalls, etc.)., but now, thanks to David, these are generated from kernel's own headers. If the macros were part of such ABI (I don't think these macros were meant to be #ifdef __KERNEL__ and just by omission exported to userland), then if you change the kernel headers (which of course you can do, that's kernel private headers), then you IMNSHO should also add magic to make headers_install to keep the kernel ABI headers for userland headers stable. Which in this case would mean if you decide rtnetlink.h shouldn't include the newly added if_addr.h that you add rules for generating the userland rtnetlink.h such that it will include linux/if_addr.h and define the macros you intentionally omitted. Jakub - 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: Kernel header changes break glibc build
* David Woodhouse [EMAIL PROTECTED] 2006-12-06 14:07 On Wed, 2006-12-06 at 14:59 +0100, Thomas Graf wrote: Are you suggesting that the kernel has to keep macros around which are of no use to the kernel itself just because glibc uses them? No, although in fact that _is_ the only reason we use these horrid __uXX types rather than proper C datatypes, isn't it? Alright, so we agree that there must be a possibility of getting rid of deprecated crap which leads to interface abusage. Fixing things is as simple as #ifndef IFA_MAX respectively IFLA_RTA in some compat header. I'm suggesting that if you want to change things around as you did, you should make sure the users of those headers adapt to cope. You did fix the in-kernel users; you neglected to fix glibc -- and as far as I can tell you didn't even bother to _warn_ glibc folks. I didn't warn them because I didn't know better. I was under the impression that glibc still maintains their own set of headers and will fix this automatically when they look at the diff. That's what I do for my userspace applications that use kernel headers. Ideally install_headers would do the trick but it often fails f.e. when some application which uses bsd features thus including net/if.h also wants to use new linux features and includes linux/if.h which then conflicts. - 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: Kernel header changes break glibc build
* Jakub Jelinek [EMAIL PROTECTED] 2006-12-06 15:18 There are the kernel's own headers and kernel ABI headers for userland use. Until recently the latter has been maintained by various distributions and manually occassionally updated to sync a little bit with kernel ABI additions (new syscalls, etc.)., but now, thanks to David, these are generated from kernel's own headers. If the macros were part of such ABI Macros can't possibly be part of an ABI :-) You probably mean API. (I don't think these macros were meant to be #ifdef __KERNEL__ and just by omission exported to userland), then if you change the kernel headers (which of course you can do, that's kernel private headers), then you IMNSHO should also add magic to make headers_install to keep the kernel ABI headers for userland headers stable. At the time they were added they were meant to be exported but netlink has evolved and we now have a type safe API. Guess what, I'm going to remove more bits of the old interface because they are no longer needed. Which in this case would mean if you decide rtnetlink.h shouldn't include the newly added if_addr.h that you add rules for generating the userland rtnetlink.h such that it will include linux/if_addr.h and define the macros you intentionally omitted. Sure, moving these bits to some compat header which gets automatically included by make install_headers instead of removing them sounds like a good compromise, it just has to be clear that they are deprecated and not supposed to be used by new code. - 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] netxen: sparse warning and ioctl bug fixes
Hi Stephen,
This patch looks good.
ioctls: NetXen chip is far more generic and will eventually show a significant
amount of functionality in different products. We need ioctl analysis for
user level tools that can tell states of registers etc. Removing ioctls all
together will make any analysis from userland extremely difficult.
Does anyone have ideas on improving this ioctl interface?
Thanks.
-Amit
On Wednesday 06 December 2006 01:37, Stephen Hemminger wrote:
Fix sparse warnings and get rid of casts that hide misuse
of __user pointers. There were two real bugs here:
* ioctl was copying uninitialized stack om NETXEN_NIC_NAME
* ioctl was dereferencing a user pointer
in nettxen_nic_cmd_clear_stats.
IMHO the ioctl usage in this driver is going to be more maintenance
burden than useful. and should be removed.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic.h |5 +
drivers/net/netxen/netxen_nic_hdr.h | 128
+ drivers/net/netxen/netxen_nic_init.c |
38 +-
drivers/net/netxen/netxen_nic_ioctl.h |2 -
drivers/net/netxen/netxen_nic_main.c | 34 +++--
5 files changed, 99 insertions(+), 108 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h
b/drivers/net/netxen/netxen_nic.h index d925053..f66ebe3 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -916,9 +916,8 @@ void netxen_tso_check(struct netxen_adap
struct cmd_desc_type0 *desc, struct sk_buff *skb);
int netxen_nic_hw_resources(struct netxen_adapter *adapter);
void netxen_nic_clear_stats(struct netxen_adapter *adapter);
-int
-netxen_nic_do_ioctl(struct netxen_adapter *adapter, void *u_data,
- struct netxen_port *port);
+int netxen_nic_do_ioctl(struct netxen_adapter *adapter, void __user
*u_data, +struct netxen_port *port);
int netxen_nic_rx_has_work(struct netxen_adapter *adapter);
int netxen_nic_tx_has_work(struct netxen_adapter *adapter);
void netxen_watchdog_task(unsigned long v);
diff --git a/drivers/net/netxen/netxen_nic_hdr.h
b/drivers/net/netxen/netxen_nic_hdr.h index 72c6ec4..2461afc 100644
--- a/drivers/net/netxen/netxen_nic_hdr.h
+++ b/drivers/net/netxen/netxen_nic_hdr.h
@@ -228,139 +228,139 @@ enum {
/* This field defines CRB adr [31:20] of the agents */
#define NETXEN_HW_CRB_HUB_AGT_ADR_MN \
- ((NETXEN_HW_H0_CH_HUB_ADR 7) | NETXEN_HW_MN_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H0_CH_HUB_ADR 7) | NETXEN_HW_MN_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_PH \
- ((NETXEN_HW_H0_CH_HUB_ADR 7) | NETXEN_HW_PH_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H0_CH_HUB_ADR 7) | NETXEN_HW_PH_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_MS \
- ((NETXEN_HW_H0_CH_HUB_ADR 7) | NETXEN_HW_MS_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H0_CH_HUB_ADR 7) | NETXEN_HW_MS_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_PS \
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_PS_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_PS_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_SS \
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_SS_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_SS_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_RPMX3 \
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_RPMX3_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_RPMX3_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_QMS\
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_QMS_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_QMS_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_SQS0 \
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_SQGS0_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_SQGS0_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_SQS1 \
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_SQGS1_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_SQGS1_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_SQS2 \
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_SQGS2_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_SQGS2_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_SQS3 \
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_SQGS3_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_SQGS3_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_C2C0 \
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_C2C0_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_C2C0_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_C2C1 \
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_C2C1_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_C2C1_CRB_AGT_ADR)
#define NETXEN_HW_CRB_HUB_AGT_ADR_RPMX2 \
- ((NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_RPMX2_CRB_AGT_ADR)
+ (((u32)NETXEN_HW_H1_CH_HUB_ADR 7) | NETXEN_HW_RPMX2_CRB_AGT_ADR)
[PATCH]: Fix netpoll arp_reply for multiple routers
All,
Attached is a patch to fix arp_reply when you have multiple possible
routers doing ARP requests to you. Currently arp_reply always replies to the
MAC address that it was given when it starts. However, if you have multiple
routers that can ARP request you, you might respond to the wrong router; in
which case the other router will eventually drop you from it's ARP cache and
stop delivering packets to you. The fix is to always reply to the router that
asked you, not the one you have hard-coded.
I do not have the setup to test this; the customer that does have the
setup has tested the patch and reports that it fixes the problems they were
having.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 3c58846..5833b21 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -331,6 +331,7 @@ static void arp_reply(struct sk_buff *sk
unsigned char *arp_ptr;
int size, type = ARPOP_REPLY, ptype = ETH_P_ARP;
__be32 sip, tip;
+ unsigned char *sha;
struct sk_buff *send_skb;
struct netpoll *np = NULL;
@@ -357,9 +358,14 @@ static void arp_reply(struct sk_buff *sk
arp-ar_op != htons(ARPOP_REQUEST))
return;
- arp_ptr = (unsigned char *)(arp+1) + skb-dev-addr_len;
+ arp_ptr = (unsigned char *)(arp+1);
+ /* save the location of the src hw addr */
+ sha = arp_ptr;
+ arp_ptr += skb-dev-addr_len;
memcpy(sip, arp_ptr, 4);
- arp_ptr += 4 + skb-dev-addr_len;
+ arp_ptr += 4;
+ /* if we actually cared about dst hw addr, it would get copied here */
+ arp_ptr += skb-dev-addr_len;
memcpy(tip, arp_ptr, 4);
/* Should we ignore arp? */
@@ -382,7 +388,7 @@ static void arp_reply(struct sk_buff *sk
if (np-dev-hard_header
np-dev-hard_header(send_skb, skb-dev, ptype,
- np-remote_mac, np-local_mac,
+ sha, np-local_mac,
send_skb-len) 0) {
kfree_skb(send_skb);
return;
@@ -406,7 +412,7 @@ static void arp_reply(struct sk_buff *sk
arp_ptr += np-dev-addr_len;
memcpy(arp_ptr, tip, 4);
arp_ptr += 4;
- memcpy(arp_ptr, np-remote_mac, np-dev-addr_len);
+ memcpy(arp_ptr, sha, np-dev-addr_len);
arp_ptr += np-dev-addr_len;
memcpy(arp_ptr, sip, 4);
Re: [PATCH] netxen: sparse warning and ioctl bug fixes
On Wed, 6 Dec 2006 21:40:34 +0530 Amit S. Kale [EMAIL PROTECTED] wrote: Hi Stephen, This patch looks good. ioctls: NetXen chip is far more generic and will eventually show a significant amount of functionality in different products. We need ioctl analysis for user level tools that can tell states of registers etc. Removing ioctls all together will make any analysis from userland extremely difficult. Use (and extend) existing ethtool interface to get registers and statistics. Does anyone have ideas on improving this ioctl interface? Thanks. -Amit - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][GENETLINK] fix misplaced command flags
fixes something i broke in previous patch. Against net-2.6.20. BTW, is it just me having problems syncing net-2.6.20? cheers, jamal [GENETLINK] fix misplaced command flags The command flags for dump and do were swapped.. Signed-off-by: Jamal Hadi Salim[EMAIL PROTECTED] --- commit 03b09fc1e8f71a14c661af496941b6de963fddf1 tree 3b3c62e1b5f1db0e75ab383a2ec43173cb0f0efa parent 49ba7537cec41f0db2500054b5fde3c193c37a97 author Jamal Hadi Salim [EMAIL PROTECTED] Wed, 06 Dec 2006 11:58:34 -0500 committer Jamal Hadi Salim [EMAIL PROTECTED] Wed, 06 Dec 2006 11:58:34 -0500 net/netlink/genetlink.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c index 3e37ea5..a59b7bb 100644 --- a/net/netlink/genetlink.c +++ b/net/netlink/genetlink.c @@ -144,9 +144,9 @@ int genl_register_ops(struct genl_family *family, struct genl_ops *ops) } if (ops-dumpit) - ops-flags |= GENL_CMD_CAP_DO; - if (ops-doit) ops-flags |= GENL_CMD_CAP_DUMP; + if (ops-doit) + ops-flags |= GENL_CMD_CAP_DO; if (ops-policy) ops-flags |= GENL_CMD_CAP_HASPOL;
Re: [NET_SCHED]: cls_fw: fix NULL pointer dereference
Jarek Poplawski wrote: On 04-12-2006 16:34, Patrick McHardy wrote: Thomas, Jamal, do you have an idea what this old method stuff is used for? It seems it is only used during the below mentioned race. Sorry for eavesdropping, but have a look at htb_classify starting comment. It is also used by unofficial but quite popular IPMARK target. Yes I know, I just didn't see how it could be configured to really use that code. But while trying to explain the flow that would always lead to tp-root != NULL in this mail, I noticed I missed something :) At the top of fw_change: if (!opt) return handle ? -EINVAL : 0; which happens when adding a fw classifier without specifying any arguments. My previous fix is still enough, but we can't remove this of course. - 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
[IPROUTE2 PATCH][GENETLINK] Multicast computation off by one
A small typo fixup
BTW, how do you like the subject to look like?
cheers,
jamal
[GENL] Multicast computation off by one
When using the first 32 groups, the multicast group to bit mapping
was off by one.
Signed-off-by: Jamal Hadi Salim
---
commit b883bf2396abc0434b3a63d228593cec80808dbb
tree dba2b9664d88d7a4641d11c6284b984a33d2b47a
parent 288384f22ffafd2d7d888ee45d8dfcf26d3f2b1c
author Jamal Hadi Salim [EMAIL PROTECTED] Tue, 05 Dec 2006 14:13:46 -0500
committer Jamal Hadi Salim [EMAIL PROTECTED] Tue, 05 Dec 2006 14:13:46 -0500
genl/genl_utils.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/genl/genl_utils.h b/genl/genl_utils.h
index 2f2314b..22e9210 100644
--- a/genl/genl_utils.h
+++ b/genl/genl_utils.h
@@ -16,7 +16,7 @@ extern int genl_ctrl_resolve_family(const char *family);
/* seems to have dissapeared from netlink.h */
static inline __u32 nl_mgrp(__u32 group)
{
- return group ? 1 group : 0;
+ return group ? (1 (group -1)) : 0;
}
#endif
Re: Kernel header changes break glibc build
On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote: At the time they were added they were meant to be exported but netlink has evolved and we now have a type safe API. Where? AFAICS, netlink might be considered type-safe only within an address family... - To unsubscribe from this 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][GENETLINK] fix misplaced command flags
From: jamal [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 12:02:23 -0500 fixes something i broke in previous patch. Against net-2.6.20. BTW, is it just me having problems syncing net-2.6.20? You should be using the net-2.6.git tree now, I blow away the net-2.6.X.git tree when 2.6.X integration starts happening and just do everything from net-2.6.git - 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
[IPROUTE2 PATCH][GENETLINK] Add controller support for new features exposed
Ok, heres hopefully the last one in this series for generic netlink ..
cheers,
jamal
[GENL]: Add controller support for new features exposed
Update the controller to spit out the new features being exposed
from the kernel
Signed-off-by: J Hadi Salim [EMAIL PROTECTED]
---
commit 241e28d5d5d326d33b2d71752d574e2ae118f671
tree ccda0d9dd9b85180fdd803f79ad11d305f2ffc53
parent 515370c958be14b417e20611258eecbe9fda2382
author Jamal Hadi Salim [EMAIL PROTECTED] Wed, 06 Dec 2006 12:30:36 -0500
committer Jamal Hadi Salim [EMAIL PROTECTED] Wed, 06 Dec 2006 12:30:36 -0500
genl/ctrl.c | 84 ++-
1 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/genl/ctrl.c b/genl/ctrl.c
index 0d4750d..fe010f3 100644
--- a/genl/ctrl.c
+++ b/genl/ctrl.c
@@ -22,6 +22,7 @@
#include utils.h
#include genl_utils.h
+#define GENL_MAX_FAM_OPS 256
static int usage(void)
{
fprintf(stderr,Usage: ctrl CMD\n \
@@ -108,6 +109,51 @@ errout:
return ret;
}
+void print_ctrl_cmd_flags(FILE *fp, __u32 fl)
+{
+ fprintf(fp, \n\t\tCapabilities (0x%x):\n , fl);
+ if (!fl) {
+ fprintf(fp, \n);
+ return;
+ }
+ fprintf(fp, \t\t );
+
+ if (fl GENL_ADMIN_PERM)
+ fprintf(fp, requires admin permission;);
+ if (fl GENL_CMD_CAP_DO)
+ fprintf(fp, can doit;);
+ if (fl GENL_CMD_CAP_DUMP)
+ fprintf(fp, can dumpit;);
+ if (fl GENL_CMD_CAP_HASPOL)
+ fprintf(fp, has policy);
+
+ fprintf(fp, \n);
+}
+
+static int print_ctrl_cmds(FILE *fp, struct rtattr *arg, __u32 ctrl_ver)
+{
+ struct rtattr *tb[CTRL_ATTR_OP_MAX + 1];
+
+ if (arg == NULL)
+ return -1;
+
+ parse_rtattr_nested(tb, CTRL_ATTR_OP_MAX, arg);
+ if (tb[CTRL_ATTR_OP_ID]) {
+ __u32 *id = RTA_DATA(tb[CTRL_ATTR_OP_ID]);
+ fprintf(fp, ID-0x%x ,*id);
+ }
+ /* we are only gonna do this for newer version of the controller */
+ if (tb[CTRL_ATTR_OP_FLAGS] ctrl_ver = 0x2) {
+ __u32 *fl = RTA_DATA(tb[CTRL_ATTR_OP_FLAGS]);
+ print_ctrl_cmd_flags(fp, *fl);
+ }
+ return 0;
+
+}
+
+/*
+ * The controller sends one nlmsg per family
+*/
static int print_ctrl(const struct sockaddr_nl *who, struct nlmsghdr *n,
void *arg)
{
@@ -116,6 +162,7 @@ static int print_ctrl(const struct sockaddr_nl *who, struct
nlmsghdr *n,
int len = n-nlmsg_len;
struct rtattr *attrs;
FILE *fp = (FILE *) arg;
+ __u32 ctrl_v = 0x1;
if (n-nlmsg_type != GENL_ID_CTRL) {
fprintf(stderr, Not a controller message, nlmsg_len=%d
@@ -142,13 +189,46 @@ static int print_ctrl(const struct sockaddr_nl *who,
struct nlmsghdr *n,
if (tb[CTRL_ATTR_FAMILY_NAME]) {
char *name = RTA_DATA(tb[CTRL_ATTR_FAMILY_NAME]);
- fprintf(fp, Name: %s\n,name);
+ fprintf(fp, \nName: %s\n,name);
}
if (tb[CTRL_ATTR_FAMILY_ID]) {
__u16 *id = RTA_DATA(tb[CTRL_ATTR_FAMILY_ID]);
- fprintf(fp, ID: 0x%x\n,*id);
+ fprintf(fp, \tID: 0x%x ,*id);
+ }
+ if (tb[CTRL_ATTR_VERSION]) {
+ __u32 *v = RTA_DATA(tb[CTRL_ATTR_VERSION]);
+ fprintf(fp, Version: 0x%x ,*v);
+ ctrl_v = *v;
}
+ if (tb[CTRL_ATTR_HDRSIZE]) {
+ __u32 *h = RTA_DATA(tb[CTRL_ATTR_HDRSIZE]);
+ fprintf(fp, header size: %d ,*h);
+ }
+ if (tb[CTRL_ATTR_MAXATTR]) {
+ __u32 *ma = RTA_DATA(tb[CTRL_ATTR_MAXATTR]);
+ fprintf(fp, max attribs: %d ,*ma);
+ }
+ /* end of family definitions .. */
+ fprintf(fp,\n);
+ if (tb[CTRL_ATTR_OPS]) {
+ struct rtattr *tb2[GENL_MAX_FAM_OPS];
+ int i=0;
+ parse_rtattr_nested(tb2, GENL_MAX_FAM_OPS, tb[CTRL_ATTR_OPS]);
+ fprintf(fp, \tcommands supported: \n);
+ for (i = 0; i GENL_MAX_FAM_OPS; i++) {
+ if (tb2[i]) {
+ fprintf(fp, \t\t#%d: , i);
+ if (0 print_ctrl_cmds(fp, tb2[i], ctrl_v)) {
+ fprintf(fp, Error printing command\n);
+ }
+ /* for next command */
+ fprintf(fp,\n);
+ }
+ }
+ /* end of family::cmds definitions .. */
+ fprintf(fp,\n);
+ }
fflush(fp);
return 0;
}
[IPROUTE2 PATCH][DOC] clarify ok and pass
a small one.
I have a few more but just run out of cycles for now;
if you dont mind holding before releasing for a short while so i can
get them out I will appreciate it.
cheers,
jamal
[DOC]: clarify ok and pass
A small fixup to elucidate the mysteries of accepting ..
---
commit d3f9d336f524d2aa36442212d72f39de15b1e585
tree cba1f16ca21fd70ad2d2b59b460166929157ba59
parent 241e28d5d5d326d33b2d71752d574e2ae118f671
author Marco Berizzi [EMAIL PROTECTED] Wed, 06 Dec 2006 12:39:19 -0500
committer Jamal Hadi Salim [EMAIL PROTECTED] Wed, 06 Dec 2006 12:39:19 -0500
doc/actions/actions-general |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/actions/actions-general b/doc/actions/actions-general
index bb2295d..6561eda 100644
--- a/doc/actions/actions-general
+++ b/doc/actions/actions-general
@@ -65,7 +65,7 @@ action police mtu 4000 rate 1500kbit burst 90k
{ drop, pass, reclassify, continue}
(If you have others, no listed here give me a reason and we will add them)
+drop says to drop the packet
-+pass says to accept it
++pass and ok (are equivalent) says to accept it
+reclassify requests for reclassification of the packet
+continue requests for next lookup to match
Strange problem with tcpdump.
Hi, guys. I've got a problem. I can see all the incoming packets on an ethernet interface, but no outgoing packets, although they are sent to the network, and successfully recieved by the other side. The platform is ixp420, with severely nodifyed ethernet driver, the kernel is 2.6.16.20. May I ask, how is this possible at all? As I understand, the outgoing packets get captured before they reach the driver, so it can't be the cause. On the other hand, I get all the packets sent over an other, non-ethernet interface, so I can't blame tcpdump. Any suggestions, where to start the investigation? - 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: [Devel] Re: Network virtualization/isolation
On Wed, Dec 06, 2006 at 02:54:16PM +0300, Kirill Korotaev wrote: If there is a better and less intrusive while still being obvious method I am all for it. I do not like the OpenVZ thing of doing the lookup once and then stashing the value in current and the special casing the exceptions. Why? I like it when things are obvious and not implied. The implementations seems to favor fewer lines of code touched over maintainability of the code. Which if you are maintaining out of tree code is fine. At leas that was my impression last time I looked at the code. FYI, when we started doing networking virtualization many years ago we tried both approaches. Over time, context notion looked much more natural and easier for us. Even Alexey Kuznetsov tells that he prefers exec_env as the logic becomes very clear and little mess is introduced. I know there are a lot of silly things in the existing implementations because they were initially written without the expectation of being able to merge the code into the main kernel. This resulted in some non-general interfaces, and a preference for patches that touch as few lines of code as possible. Sure, but OpenVZ code is being constantly cleaned from such code and we are open for discussion. No one pretends that code is perferct from the beginning. Anyway this has bit has been discussed before and we can discuss it seriously in the context of patch review. Let me explain when explicit context like exec_env IMHO is cleaner: - context is a natural notion of linux kernel. e.g. current. why not pass 'current' to all the functions as an argument starting from entry.S? in_atomic(), in_interrupt() etc. all these functions deal with current context. IMHO when one needs to pass an argument too many times like 'current' it is better to use a notion of the context. - e.g. NFS should set networking context of the mount point or socket. how would that work for a 'shared' NFS partition? (shared between different context) But, ok, it is not the real point to argue so much imho and waste our time instead of doing things. well, IMHO better talk (and think) first, then implement something ... not the other way round, and then start fixing up the mess ... best, Herbert Thanks, Kirill ___ Containers mailing list [EMAIL PROTECTED] https://lists.osdl.org/mailman/listinfo/containers - 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: network devices don't handle pci_dma_mapping_error()'s
On Tue, 5 Dec 2006 09:00:45 +0200 Muli Ben-Yehuda [EMAIL PROTECTED] wrote: On Mon, Dec 04, 2006 at 10:39:49AM -0800, Stephen Hemminger wrote: I notice that no current network driver handles dma mapping errors. Might that be part of the problem. On i386, this never happens, and it would be rare on most others. IOMMUs are already available on x86-64 and are going to get widespread with the the introduction of IOMMUs from Intel and AMD. Might as well fix it now... How about CONFIG_DEBUG_DMA_API that does book-keeping and yells if a driver is mis-using the DMA API? Cheers, Muli I think it is really only an issue for drivers that turn on HIGH_DMA and have limited mask values. The majority of drivers either only handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the details of how we manage IOMMU, but doesn't mapping always work for those drivers. That just leaves devices with odd size mask values that need to be handle mapping errors. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
On Wed, Dec 06, 2006 at 10:16:44AM -0800, Stephen Hemminger wrote: I think it is really only an issue for drivers that turn on HIGH_DMA and have limited mask values. The majority of drivers either only handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the details of how we manage IOMMU, but doesn't mapping always work for those drivers. It's up to an IOMMU (DMA-API) implementation to define what constitutes a mapping error, e.g., Calgary and GART on x86-64 will return bad_dma_address from the mapping functions when they run out of entries in the IO space, which can happen regardless of the mask. Cheers, Muli - 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: Kernel header changes break glibc build
Am Montag, 4. Dezember 2006 10:13 schrieb Thomas Graf: I do not agree with the change to include if_addr.h in rtnetlink.h. The point is to move bits apart and have multiple small pieces of header files defining a specific rtnetlink family which are a lot easier to maintain for both kernel and userspace than one giant rtnetlink.h for everything. According to a user's report, your change also broke compilation of my dhcpclient because it neeeds if_addr.h since 2.6.19. Any suggestion how to make one source code build on 2.6.19 and older headers? I hope you don't want me to check on UTS_RELEASE in a userspace program? Stefan - 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] irlan: fix header build warning
From: Randy Dunlap [EMAIL PROTECTED] Fix compile warning when CONFIG_PROC_FS=n: include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared inside parameter list include/net/irda/irlan_filter.h:31: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- include/net/irda/irlan_filter.h |1 + 1 file changed, 1 insertion(+) --- linux-2.6.19-git7.orig/include/net/irda/irlan_filter.h +++ linux-2.6.19-git7/include/net/irda/irlan_filter.h @@ -28,6 +28,7 @@ void irlan_check_command_param(struct irlan_cb *self, char *param, char *value); void irlan_filter_request(struct irlan_cb *self, struct sk_buff *skb); +struct seq_file; void irlan_print_filter(struct seq_file *seq, int filter_type); #endif /* IRLAN_FILTER_H */ --- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel header changes break glibc build
* Al Viro [EMAIL PROTECTED] 2006-12-06 17:13 On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote: At the time they were added they were meant to be exported but netlink has evolved and we now have a type safe API. Where? AFAICS, netlink might be considered type-safe only within an address family... The new interface can be found in net/netlink.h, it obsoletes the old interface which is spread over linux/netlink.h and linux/rtnetlink.h I'm removing the old bits as soon as I've finished converting all its users. An almost identical interface is provided to userspace by libnl. - 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: Kernel header changes break glibc build
* Stefan Rompf [EMAIL PROTECTED] 2006-12-06 20:32 According to a user's report, your change also broke compilation of my dhcpclient because it neeeds if_addr.h since 2.6.19. Any suggestion how to make one source code build on 2.6.19 and older headers? I hope you don't want me to check on UTS_RELEASE in a userspace program? #ifndef IFA_MAX #include linux/if_addr.h #endif - 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: Kernel header changes break glibc build
On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote: * Al Viro [EMAIL PROTECTED] 2006-12-06 17:13 On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote: At the time they were added they were meant to be exported but netlink has evolved and we now have a type safe API. Where? AFAICS, netlink might be considered type-safe only within an address family... The new interface can be found in net/netlink.h, it obsoletes the old interface which is spread over linux/netlink.h and linux/rtnetlink.h ... and for different address families you have conflicting policies. You can't tell if ATTR_... means __le16, __be32, 16byte-array or something else - the answer depends on the code interpreting the damn thing. Moreover, you get zero warnings if you use wrong accessor to decode. - 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] softmac: Fixed handling of deassociation from AP
From: Ulrich Kunitz [EMAIL PROTECTED]
A deauthentication from the AP doesn't start a reassociation by
SoftMAC. To fix this mac-associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled.
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
net/ieee80211/softmac/ieee80211softmac_assoc.c | 14 --
net/ieee80211/softmac/ieee80211softmac_auth.c |2 ++
net/ieee80211/softmac/ieee80211softmac_priv.h |2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
===
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -427,6 +427,17 @@ ieee80211softmac_handle_assoc_response(s
return 0;
}
+void
+ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(mac-lock, flags);
+ mac-associnfo.associating = 1;
+ schedule_work(mac-associnfo.work);
+ spin_unlock_irqrestore(mac-lock, flags);
+}
+
int
ieee80211softmac_handle_disassoc(struct net_device * dev,
struct ieee80211_disassoc *disassoc)
@@ -445,8 +456,7 @@ ieee80211softmac_handle_disassoc(struct
dprintk(KERN_INFO PFX got disassoc frame\n);
ieee80211softmac_disassoc(mac);
- /* try to reassociate */
- schedule_work(mac-associnfo.work);
+ ieee80211softmac_try_reassoc(mac);
return 0;
}
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_auth.c
===
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -334,6 +334,8 @@ ieee80211softmac_deauth_from_net(struct
/* can't transmit data right now... */
netif_carrier_off(mac-dev);
spin_unlock_irqrestore(mac-lock, flags);
+
+ ieee80211softmac_try_reassoc(mac);
}
/*
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_priv.h
===
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_priv.h
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_priv.h
@@ -238,4 +238,6 @@ void ieee80211softmac_call_events_locked
int ieee80211softmac_notify_internal(struct ieee80211softmac_device *mac,
int event, void *event_context, notify_function_ptr fun, void *context,
gfp_t gfp_mask);
+void ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac);
+
#endif /* IEEE80211SOFTMAC_PRIV_H_ */
---
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel header changes break glibc build
* Al Viro [EMAIL PROTECTED] 2006-12-06 20:34 On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote: * Al Viro [EMAIL PROTECTED] 2006-12-06 17:13 On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote: At the time they were added they were meant to be exported but netlink has evolved and we now have a type safe API. Where? AFAICS, netlink might be considered type-safe only within an address family... The new interface can be found in net/netlink.h, it obsoletes the old interface which is spread over linux/netlink.h and linux/rtnetlink.h ... and for different address families you have conflicting policies. You can't tell if ATTR_... means __le16, __be32, 16byte-array or something else - the answer depends on the code interpreting the damn thing. Moreover, you get zero warnings if you use wrong accessor to decode. That's right, some attribute cary address specific content such as addresses. By type safe I meant the API which no longer consists of macros prone to errors. I didn't mean to say netlink attributes are now type safe. - 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] memory barrier cleanups
I believe all the below memory barriers only matter on SMP so therefore
the smp_* variant of the barrier should be used.
I'm wondering if the barrier in net/ipv4/inet_timewait_sock.c should be
dropped entirely. schedule_work's implementation currently implies a
memory barrier and I think sane semantics of schedule_work() should imply
a memory barrier, as needed so the caller shouldn't have to worry.
It's not quite obvious why the barrier in net/packet/af_packet.c is
needed; maybe it should be implied through flush_dcache_page?
Ralf
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
diff --git a/net/core/wireless.c b/net/core/wireless.c
index cb1b872..f69ab7b 100644
--- a/net/core/wireless.c
+++ b/net/core/wireless.c
@@ -2130,7 +2130,7 @@ int iw_handler_set_spy(struct net_device
* The rtnl_lock() make sure we don't race with the other iw_handlers.
* This make sure wireless_spy_update() see that the spy list
* is temporarily disabled. */
- wmb();
+ smp_wmb();
/* Are there are addresses to copy? */
if(wrqu-data.length 0) {
@@ -2159,7 +2159,7 @@ #endif/* WE_SPY_DEBUG */
}
/* Make sure above is updated before re-enabling */
- wmb();
+ smp_wmb();
/* Enable addresses */
spydata-spy_number = wrqu-data.length;
diff --git a/net/ipv4/inet_timewait_sock.c b/net/ipv4/inet_timewait_sock.c
index cdd8053..1a852c2 100644
--- a/net/ipv4/inet_timewait_sock.c
+++ b/net/ipv4/inet_timewait_sock.c
@@ -178,7 +178,7 @@ void inet_twdr_hangman(unsigned long dat
need_timer = 0;
if (inet_twdr_do_twkill_work(twdr, twdr-slot)) {
twdr-thread_slots |= (1 twdr-slot);
- mb();
+ smp_mb();
schedule_work(twdr-twkill_work);
need_timer = 1;
} else {
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9304034..c701f6a 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4235,7 +4235,7 @@ static int tcp_rcv_synsent_state_process
* Change state from SYN-SENT only after copied_seq
* is initialized. */
tp-copied_seq = tp-rcv_nxt;
- mb();
+ smp_mb();
tcp_set_state(sk, TCP_ESTABLISHED);
security_inet_conn_established(sk, skb);
@@ -4483,7 +4483,7 @@ int tcp_rcv_state_process(struct sock *s
case TCP_SYN_RECV:
if (acceptable) {
tp-copied_seq = tp-rcv_nxt;
- mb();
+ smp_mb();
tcp_set_state(sk, TCP_ESTABLISHED);
sk-sk_state_change(sk);
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 08e68b6..da73e8a 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -660,7 +660,7 @@ static int tpacket_rcv(struct sk_buff *s
sll-sll_ifindex = dev-ifindex;
h-tp_status = status;
- mb();
+ smp_mb();
{
struct page *p_start, *p_end;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/16] Spidernet RX Misc cleanups and fixes
Andrew, Please apply and forward upstream. This series of 16 small patches consist of mostly of various cleanups, a few fixes, and a clarification of the flow of the RX side of the spidernet ethernet driver. The first patch, though, is a resubmit of an old patch. --linas - To unsubscribe 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] irlan: fix header build warning
Hi Randy, Thanks for the patch. Looks fine to me. On Wed, Dec 06, 2006 at 11:44:07AM -0800, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Fix compile warning when CONFIG_PROC_FS=n: include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared inside parameter list include/net/irda/irlan_filter.h:31: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Cheers, Samuel. - 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/16] Spidernet DMA coalescing
The current driver code performs 512 DMA mappings of a bunch of
32-byte structures. This is silly, as they are all in contiguous
memory. Ths patch changes the code to DMA map the entie area
with just one call.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Acked-by: Joel Schopp [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 107 +++
drivers/net/spider_net.h | 16 ++-
2 files changed, 59 insertions(+), 64 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
15:53:23.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 15:56:20.0
-0600
@@ -269,25 +269,6 @@ spider_net_get_descr_status(struct spide
}
/**
- * spider_net_free_chain - free descriptor chain
- * @card: card structure
- * @chain: address of chain
- *
- */
-static void
-spider_net_free_chain(struct spider_net_card *card,
- struct spider_net_descr_chain *chain)
-{
- struct spider_net_descr *descr;
-
- for (descr = chain-tail; !descr-bus_addr; descr = descr-next) {
- pci_unmap_single(card-pdev, descr-bus_addr,
-SPIDER_NET_DESCR_SIZE, PCI_DMA_BIDIRECTIONAL);
- descr-bus_addr = 0;
- }
-}
-
-/**
* spider_net_init_chain - links descriptor chain
* @card: card structure
* @chain: address of chain
@@ -299,15 +280,15 @@ spider_net_free_chain(struct spider_net_
*
* returns 0 on success, 0 on failure
*/
-static int
+static void
spider_net_init_chain(struct spider_net_card *card,
struct spider_net_descr_chain *chain,
struct spider_net_descr *start_descr,
+ dma_addr_t buf,
int no)
{
int i;
struct spider_net_descr *descr;
- dma_addr_t buf;
descr = start_descr;
memset(descr, 0, sizeof(*descr) * no);
@@ -316,17 +297,12 @@ spider_net_init_chain(struct spider_net_
for (i=0; ino; i++, descr++) {
descr-dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
- buf = pci_map_single(card-pdev, descr,
-SPIDER_NET_DESCR_SIZE,
-PCI_DMA_BIDIRECTIONAL);
-
- if (pci_dma_mapping_error(buf))
- goto iommu_error;
-
descr-bus_addr = buf;
+ descr-next_descr_addr = 0;
descr-next = descr + 1;
descr-prev = descr - 1;
+ buf += sizeof(struct spider_net_descr);
}
/* do actual circular list */
(descr-1)-next = start_descr;
@@ -335,17 +311,6 @@ spider_net_init_chain(struct spider_net_
spin_lock_init(chain-lock);
chain-head = start_descr;
chain-tail = start_descr;
-
- return 0;
-
-iommu_error:
- descr = start_descr;
- for (i=0; i no; i++, descr++)
- if (descr-bus_addr)
- pci_unmap_single(card-pdev, descr-bus_addr,
-SPIDER_NET_DESCR_SIZE,
-PCI_DMA_BIDIRECTIONAL);
- return -ENOMEM;
}
/**
@@ -1652,24 +1617,32 @@ spider_net_open(struct net_device *netde
{
struct spider_net_card *card = netdev_priv(netdev);
struct spider_net_descr *descr;
- int i, result;
+ int result = -ENOMEM;
- result = -ENOMEM;
- if (spider_net_init_chain(card, card-tx_chain, card-descr,
- card-num_tx_desc))
- goto alloc_tx_failed;
+ card-descr_dma_addr = pci_map_single(card-pdev, card-descr,
+ (card-num_tx_desc+card-num_rx_desc)*sizeof(struct
spider_net_descr),
+PCI_DMA_BIDIRECTIONAL);
+ if (pci_dma_mapping_error(card-descr_dma_addr))
+ return -ENOMEM;
+
+ spider_net_init_chain(card, card-tx_chain, card-descr,
+ card-descr_dma_addr,
+ card-num_tx_desc);
card-low_watermark = NULL;
/* rx_chain is after tx_chain, so offset is descr + tx_count */
- if (spider_net_init_chain(card, card-rx_chain,
+ spider_net_init_chain(card, card-rx_chain,
card-descr + card-num_tx_desc,
- card-num_rx_desc))
- goto alloc_rx_failed;
+ card-descr_dma_addr
+ + card-num_tx_desc * sizeof(struct
spider_net_descr),
+ card-num_rx_desc);
descr = card-rx_chain.head;
- for (i=0; i card-num_rx_desc; i++, descr++)
+ do {
[PATCH 2/16] Spidernet add net_ratelimit to suppress long output
This patch adds net_ratelimit to many of the printks
in order to limit extraneous warning messages
This patch supercedes all previous ratelimit patches.
This has been tested, please apply.
From: James K Lewis [EMAIL PROTECTED]
Signed-off-by: James K Lewis [EMAIL PROTECTED]
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 11 +--
drivers/net/spider_net.h |2 +-
2 files changed, 6 insertions(+), 7 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
15:56:20.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 15:58:27.0
-0600
@@ -1008,11 +1008,10 @@ spider_net_decode_one_descr(struct spide
if ( (status != SPIDER_NET_DESCR_COMPLETE)
(status != SPIDER_NET_DESCR_FRAME_END) ) {
- if (netif_msg_rx_err(card)) {
+ if (netif_msg_rx_err(card))
pr_err(%s: RX descriptor with state %d\n,
card-netdev-name, status);
- card-spider_stats.rx_desc_unk_state++;
- }
+ card-spider_stats.rx_desc_unk_state++;
goto refill;
}
@@ -1331,7 +1330,7 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_GRFAFLLINT: /* fallthrough */
case SPIDER_NET_GRMFLLINT:
if (netif_msg_intr(card) net_ratelimit())
- pr_debug(Spider RX RAM full, incoming packets
+ pr_err(Spider RX RAM full, incoming packets
might be discarded!\n);
spider_net_rx_irq_off(card);
tasklet_schedule(card-rxram_full_tl);
@@ -1349,7 +1348,7 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_GDCDCEINT: /* fallthrough */
case SPIDER_NET_GDBDCEINT: /* fallthrough */
case SPIDER_NET_GDADCEINT:
- if (netif_msg_intr(card))
+ if (netif_msg_intr(card) net_ratelimit())
pr_err(got descriptor chain end interrupt,
restarting DMAC %c.\n,
'D'-(i-SPIDER_NET_GDDDCEINT)/3);
@@ -1420,7 +1419,7 @@ spider_net_handle_error_irq(struct spide
break;
}
- if ((show_error) (netif_msg_intr(card)))
+ if ((show_error) (netif_msg_intr(card)) net_ratelimit())
pr_err(Got error interrupt on %s, GHIINT0STS = 0x%08x,
GHIINT1STS = 0x%08x, GHIINT2STS = 0x%08x\n,
card-netdev-name,
Index: linux-2.6.19-git7/drivers/net/spider_net.h
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.h 2006-12-06
15:56:20.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.h 2006-12-06 15:57:28.0
-0600
@@ -24,7 +24,7 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
-#define VERSION 1.6 A
+#define VERSION 1.6 B
#include sungem_phy.h
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/16] Spidernet RX Locking
The RX packet handling can be called from several
places, yet does not protect the rx ring structure.
This patch places the ring buffer pointers under a lock.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
15:58:27.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:01:49.0
-0600
@@ -969,28 +969,33 @@ static int
spider_net_decode_one_descr(struct spider_net_card *card, int napi)
{
struct spider_net_descr_chain *chain = card-rx_chain;
- struct spider_net_descr *descr = chain-tail;
+ struct spider_net_descr *descr;
int status;
int result;
+ unsigned long flags;
+
+ spin_lock_irqsave(chain-lock, flags);
+ descr = chain-tail;
status = spider_net_get_descr_status(descr);
if (status == SPIDER_NET_DESCR_CARDOWNED) {
/* nothing in the descriptor yet */
- result=0;
- goto out;
+ spin_unlock_irqrestore(chain-lock, flags);
+ return 0;
}
if (status == SPIDER_NET_DESCR_NOT_IN_USE) {
/* not initialized yet, the ring must be empty */
+ spin_unlock_irqrestore(chain-lock, flags);
spider_net_refill_rx_chain(card);
spider_net_enable_rxdmac(card);
- result=0;
- goto out;
+ return 0;
}
/* descriptor definitively used -- move on tail */
chain-tail = descr-next;
+ spin_unlock_irqrestore(chain-lock, flags);
result = 0;
if ( (status == SPIDER_NET_DESCR_RESPONSE_ERROR) ||
@@ -1022,7 +1027,6 @@ refill:
/* change the descriptor state: */
if (!napi)
spider_net_refill_rx_chain(card);
-out:
return result;
}
-
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 4/16] Spidernet Refactor RX refill
Refactor how spider_net_refill_rx_chain() is called.
No functional change; this just simplifies the code
by moving the subroutine call to a more appropriate spot.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:01:49.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:02:58.0
-0600
@@ -1023,10 +1023,8 @@ spider_net_decode_one_descr(struct spide
/* ok, we've got a packet in descr */
result = spider_net_pass_skb_up(descr, card, napi);
refill:
- descr-dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
/* change the descriptor state: */
- if (!napi)
- spider_net_refill_rx_chain(card);
+ descr-dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
return result;
}
@@ -1205,8 +1203,11 @@ spider_net_set_mac(struct net_device *ne
static void
spider_net_handle_rxram_full(struct spider_net_card *card)
{
- while (spider_net_decode_one_descr(card, 0))
- ;
+ int rc = 1;
+ while (rc) {
+ rc = spider_net_decode_one_descr(card, 0);
+ spider_net_refill_rx_chain(card);
+ }
spider_net_enable_rxchtails(card);
spider_net_enable_rxdmac(card);
netif_rx_schedule(card-netdev);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/16] Spidernet RX skb mem leak
One of the unlikely error branches has an skb memory leak.
Fix this by handling the error conditions consistently.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:02:58.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:00.0
-0600
@@ -884,8 +884,8 @@ spider_net_do_ioctl(struct net_device *n
*
* returns 1 on success, 0 if no packet was passed to the stack
*
- * iommu-unmaps the skb, fills out skb structure and passes the data to the
- * stack. The descriptor state is not changed.
+ * Fills out skb structure and passes the data to the stack.
+ * The descriptor state is not changed.
*/
static int
spider_net_pass_skb_up(struct spider_net_descr *descr,
@@ -900,10 +900,6 @@ spider_net_pass_skb_up(struct spider_net
netdev = card-netdev;
- /* unmap descriptor */
- pci_unmap_single(card-pdev, descr-buf_addr, SPIDER_NET_MAX_FRAME,
- PCI_DMA_FROMDEVICE);
-
/* the cases we'll throw away the packet immediately */
if (data_error SPIDER_NET_DESTROY_RX_FLAGS) {
if (netif_msg_rx_err(card))
@@ -998,6 +994,11 @@ spider_net_decode_one_descr(struct spide
spin_unlock_irqrestore(chain-lock, flags);
result = 0;
+
+ /* unmap descriptor */
+ pci_unmap_single(card-pdev, descr-buf_addr,
+ SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
+
if ( (status == SPIDER_NET_DESCR_RESPONSE_ERROR) ||
(status == SPIDER_NET_DESCR_PROTECTION_ERROR) ||
(status == SPIDER_NET_DESCR_FORCE_END) ) {
@@ -1005,8 +1006,6 @@ spider_net_decode_one_descr(struct spide
pr_err(%s: dropping RX descriptor with state %d\n,
card-netdev-name, status);
card-netdev_stats.rx_dropped++;
- pci_unmap_single(card-pdev, descr-buf_addr,
- SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
dev_kfree_skb_irq(descr-skb);
goto refill;
}
@@ -1014,9 +1013,10 @@ spider_net_decode_one_descr(struct spide
if ( (status != SPIDER_NET_DESCR_COMPLETE)
(status != SPIDER_NET_DESCR_FRAME_END) ) {
if (netif_msg_rx_err(card))
- pr_err(%s: RX descriptor with state %d\n,
+ pr_err(%s: RX descriptor with unkown state %d\n,
card-netdev-name, status);
card-spider_stats.rx_desc_unk_state++;
+ dev_kfree_skb_irq(descr-skb);
goto refill;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/16] Spidernet another skb mem leak
Another skb leak in an error branch. Fix this by adding
call to dev_kfree_skb_irq() after moving to a more
appropriate spot.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:00.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:04.0
-0600
@@ -897,19 +897,8 @@ spider_net_pass_skb_up(struct spider_net
data_status = descr-data_status;
data_error = descr-data_error;
-
netdev = card-netdev;
- /* the cases we'll throw away the packet immediately */
- if (data_error SPIDER_NET_DESTROY_RX_FLAGS) {
- if (netif_msg_rx_err(card))
- pr_err(error in received descriptor found,
- data_status=x%08x, data_error=x%08x\n,
- data_status, data_error);
- card-spider_stats.rx_desc_error++;
- return 0;
- }
-
skb = descr-skb;
skb-dev = netdev;
skb_put(skb, descr-valid_size);
@@ -1020,6 +1009,18 @@ spider_net_decode_one_descr(struct spide
goto refill;
}
+ /* The cases we'll throw away the packet immediately */
+ if (descr-data_error SPIDER_NET_DESTROY_RX_FLAGS) {
+ if (netif_msg_rx_err(card))
+ pr_err(%s: error in received descriptor found,
+ data_status=x%08x, data_error=x%08x\n,
+ card-netdev-name,
+ descr-data_status, descr-data_error);
+ card-spider_stats.rx_desc_error++;
+ dev_kfree_skb_irq(descr-skb);
+ goto refill;
+ }
+
/* ok, we've got a packet in descr */
result = spider_net_pass_skb_up(descr, card, napi);
refill:
-
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 7/16] Spidernet Cleanup return codes
Simplify the somewhat convoluted use of return codes
in the rx buffre handling.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:04.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:06.0
-0600
@@ -882,12 +882,10 @@ spider_net_do_ioctl(struct net_device *n
* @card: card structure
* @napi: whether caller is in NAPI context
*
- * returns 1 on success, 0 if no packet was passed to the stack
- *
* Fills out skb structure and passes the data to the stack.
* The descriptor state is not changed.
*/
-static int
+static void
spider_net_pass_skb_up(struct spider_net_descr *descr,
struct spider_net_card *card, int napi)
{
@@ -935,8 +933,6 @@ spider_net_pass_skb_up(struct spider_net
/* update netdevice statistics */
card-netdev_stats.rx_packets++;
card-netdev_stats.rx_bytes += skb-len;
-
- return 1;
}
/**
@@ -956,7 +952,6 @@ spider_net_decode_one_descr(struct spide
struct spider_net_descr_chain *chain = card-rx_chain;
struct spider_net_descr *descr;
int status;
- int result;
unsigned long flags;
spin_lock_irqsave(chain-lock, flags);
@@ -982,8 +977,6 @@ spider_net_decode_one_descr(struct spide
chain-tail = descr-next;
spin_unlock_irqrestore(chain-lock, flags);
- result = 0;
-
/* unmap descriptor */
pci_unmap_single(card-pdev, descr-buf_addr,
SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
@@ -995,8 +988,7 @@ spider_net_decode_one_descr(struct spide
pr_err(%s: dropping RX descriptor with state %d\n,
card-netdev-name, status);
card-netdev_stats.rx_dropped++;
- dev_kfree_skb_irq(descr-skb);
- goto refill;
+ goto bad_desc;
}
if ( (status != SPIDER_NET_DESCR_COMPLETE)
@@ -1005,8 +997,7 @@ spider_net_decode_one_descr(struct spide
pr_err(%s: RX descriptor with unkown state %d\n,
card-netdev-name, status);
card-spider_stats.rx_desc_unk_state++;
- dev_kfree_skb_irq(descr-skb);
- goto refill;
+ goto bad_desc;
}
/* The cases we'll throw away the packet immediately */
@@ -1017,16 +1008,18 @@ spider_net_decode_one_descr(struct spide
card-netdev-name,
descr-data_status, descr-data_error);
card-spider_stats.rx_desc_error++;
- dev_kfree_skb_irq(descr-skb);
- goto refill;
+ goto bad_desc;
}
- /* ok, we've got a packet in descr */
- result = spider_net_pass_skb_up(descr, card, napi);
-refill:
- /* change the descriptor state: */
+ /* Ok, we've got a packet in descr */
+ spider_net_pass_skb_up(descr, card, napi);
descr-dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
- return result;
+ return 1;
+
+bad_desc:
+ dev_kfree_skb_irq(descr-skb);
+ descr-dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
+ return 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 9/16] Spidernet Merge error branches
Two distinct if() statements have the ame body. Merge the clauses.
Also clean up punctuation, capitalization, etc.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:08.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:09.0
-0600
@@ -936,15 +936,16 @@ spider_net_pass_skb_up(struct spider_net
}
/**
- * spider_net_decode_one_descr - processes an rx descriptor
+ * spider_net_decode_one_descr - Processes an RX descriptor
* @card: card structure
* @napi: whether caller is in NAPI context
*
- * returns 1 if a packet has been sent to the stack, otherwise 0
+ * Returns 1 if a packet has been sent to the stack, otherwise 0.
*
- * processes an rx descriptor by iommu-unmapping the data buffer and passing
- * the packet up to the stack. This function is called in softirq
- * context, e.g. either bottom half from interrupt or NAPI polling context
+ * Processes an RX descriptor by iommu-unmapping the data buffer
+ * and passing the packet up to the stack. This function is called
+ * in a softirq context, e.g. either bottom half from interrupt or
+ * NAPI polling context.
*/
static int
spider_net_decode_one_descr(struct spider_net_card *card, int napi)
@@ -959,23 +960,18 @@ spider_net_decode_one_descr(struct spide
status = spider_net_get_descr_status(descr);
- if (status == SPIDER_NET_DESCR_CARDOWNED) {
- /* nothing in the descriptor yet */
+ /* Nothing in the descriptor yet, or ring is empty */
+ if ( (status == SPIDER_NET_DESCR_CARDOWNED) ||
+(status == SPIDER_NET_DESCR_NOT_IN_USE) ) {
spin_unlock_irqrestore(chain-lock, flags);
return 0;
}
- if (status == SPIDER_NET_DESCR_NOT_IN_USE) {
- /* not initialized yet, the ring must be empty */
- spin_unlock_irqrestore(chain-lock, flags);
- return 0;
- }
-
- /* descriptor definitively used -- move on tail */
+ /* Descriptor definitively used -- move on tail. */
chain-tail = descr-next;
spin_unlock_irqrestore(chain-lock, flags);
- /* unmap descriptor */
+ /* Unmap descriptor. */
pci_unmap_single(card-pdev, descr-buf_addr,
SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
@@ -998,7 +994,7 @@ spider_net_decode_one_descr(struct spide
goto bad_desc;
}
- /* The cases we'll throw away the packet immediately */
+ /* The cases we'll throw away the packet immediately. */
if (descr-data_error SPIDER_NET_DESTROY_RX_FLAGS) {
if (netif_msg_rx_err(card))
pr_err(%s: error in received descriptor found,
-
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 8/16] Spidernet RX Refill
The invocation of the rx ring refill routine is haphazard;
centralize and make its usage consistent.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:06.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:08.0
-0600
@@ -968,8 +968,6 @@ spider_net_decode_one_descr(struct spide
if (status == SPIDER_NET_DESCR_NOT_IN_USE) {
/* not initialized yet, the ring must be empty */
spin_unlock_irqrestore(chain-lock, flags);
- spider_net_refill_rx_chain(card);
- spider_net_enable_rxdmac(card);
return 0;
}
@@ -1058,6 +1056,7 @@ spider_net_poll(struct net_device *netde
netdev-quota -= packets_done;
*budget -= packets_done;
spider_net_refill_rx_chain(card);
+ spider_net_enable_rxdmac(card);
/* if all packets are in the stack, enable interrupts and return 0 */
/* if not, return 1 */
@@ -1197,11 +1196,9 @@ spider_net_set_mac(struct net_device *ne
static void
spider_net_handle_rxram_full(struct spider_net_card *card)
{
- int rc = 1;
- while (rc) {
- rc = spider_net_decode_one_descr(card, 0);
- spider_net_refill_rx_chain(card);
- }
+ while (spider_net_decode_one_descr(card, 0));
+
+ spider_net_refill_rx_chain(card);
spider_net_enable_rxchtails(card);
spider_net_enable_rxdmac(card);
netif_rx_schedule(card-netdev);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/16] Spidernet Remove unused variable
Remove unused variable; this makes code easier to read.
Tweak commentary.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:09.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:11.0
-0600
@@ -341,17 +341,16 @@ spider_net_free_rx_chain_contents(struct
* @card: card structure
* @descr: descriptor to re-init
*
- * return 0 on succes, 0 on failure
+ * Return 0 on succes, 0 on failure.
*
- * allocates a new rx skb, iommu-maps it and attaches it to the descriptor.
- * Activate the descriptor state-wise
+ * Allocates a new rx skb, iommu-maps it and attaches it to the
+ * descriptor. Mark the descriptor as activated, ready-to-use.
*/
static int
spider_net_prepare_rx_descr(struct spider_net_card *card,
struct spider_net_descr *descr)
{
dma_addr_t buf;
- int error = 0;
int offset;
int bufsize;
@@ -379,7 +378,7 @@ spider_net_prepare_rx_descr(struct spide
(SPIDER_NET_RXBUF_ALIGN - 1);
if (offset)
skb_reserve(descr-skb, SPIDER_NET_RXBUF_ALIGN - offset);
- /* io-mmu-map the skb */
+ /* iommu-map the skb */
buf = pci_map_single(card-pdev, descr-skb-data,
SPIDER_NET_MAX_FRAME, PCI_DMA_FROMDEVICE);
descr-buf_addr = buf;
@@ -394,7 +393,7 @@ spider_net_prepare_rx_descr(struct spide
SPIDER_NET_DMAC_NOINTR_COMPLETE;
}
- return error;
+ return 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 11/16] Spidernet RX Chain tail
Tell the hardware the location of the rx ring tail. More punctuation cleanup. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc: James K Lewis [EMAIL PROTECTED] Cc: Arnd Bergmann [EMAIL PROTECTED] drivers/net/spider_net.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) Index: linux-2.6.19-git7/drivers/net/spider_net.c === --- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06 16:03:11.0 -0600 +++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:13.0 -0600 @@ -457,10 +457,10 @@ spider_net_refill_rx_chain(struct spider } /** - * spider_net_alloc_rx_skbs - allocates rx skbs in rx descriptor chains + * spider_net_alloc_rx_skbs - Allocates rx skbs in rx descriptor chains * @card: card structure * - * returns 0 on success, 0 on failure + * Returns 0 on success, 0 on failure. */ static int spider_net_alloc_rx_skbs(struct spider_net_card *card) @@ -471,17 +471,18 @@ spider_net_alloc_rx_skbs(struct spider_n result = -ENOMEM; chain = card-rx_chain; - /* put at least one buffer into the chain. if this fails, -* we've got a problem. if not, spider_net_refill_rx_chain -* will do the rest at the end of this function */ + /* Put at least one buffer into the chain. if this fails, +* we've got a problem. If not, spider_net_refill_rx_chain +* will do the rest at the end of this function. */ if (spider_net_prepare_rx_descr(card, chain-head)) goto error; else chain-head = chain-head-next; - /* this will allocate the rest of the rx buffers; if not, it's -* business as usual later on */ + /* This will allocate the rest of the rx buffers; +* if not, it's business as usual later on. */ spider_net_refill_rx_chain(card); + spider_net_enable_rxchtails(card); spider_net_enable_rxdmac(card); return 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 13/16] Spidernet Memory barrier
Add memory barrier to make sure that the rest of the
RX descriptor state is flushed to memory before we tell
the hardware that its ready to go.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:15.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:16.0
-0600
@@ -389,6 +389,7 @@ spider_net_prepare_rx_descr(struct spide
card-spider_stats.rx_iommu_map_error++;
descr-dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
} else {
+ wmb();
descr-dmac_cmd_status = SPIDER_NET_DESCR_CARDOWNED |
SPIDER_NET_DMAC_NOINTR_COMPLETE;
}
-
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 12/16] Spidernet Turn RX irq back on
Re-enable irq's after emptying the RX ring; these had been previously turned off on reception of the rxram_full interrupt. More punctuation cleanup. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc: James K Lewis [EMAIL PROTECTED] Cc: Arnd Bergmann [EMAIL PROTECTED] drivers/net/spider_net.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux-2.6.19-git7/drivers/net/spider_net.c === --- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06 16:03:13.0 -0600 +++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:15.0 -0600 @@ -1182,12 +1182,11 @@ spider_net_set_mac(struct net_device *ne } /** - * spider_net_handle_rxram_full - cleans up RX ring upon RX RAM full interrupt + * spider_net_handle_rxram_full - Clean RX ring on RX RAM full interrupt * @card: card structure * - * spider_net_handle_rxram_full empties the RX ring so that spider can put - * more packets in it and empty its RX RAM. This is called in bottom half - * context + * Empty the RX ring so that the hardware can put more packets + * in it and empty its RX RAM. This is called in bottom half context. */ static void spider_net_handle_rxram_full(struct spider_net_card *card) @@ -1198,6 +1197,7 @@ spider_net_handle_rxram_full(struct spid spider_net_enable_rxchtails(card); spider_net_enable_rxdmac(card); netif_rx_schedule(card-netdev); + spider_net_rx_irq_on(card); } /** - 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 14/16] Spidernet Avoid possible RX chain corruption
Delete possible source of chain corruption; the hardware already knows the location of the tail, and writing it again is likely to mess it up. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Cc: James K Lewis [EMAIL PROTECTED] Cc: Arnd Bergmann [EMAIL PROTECTED] drivers/net/spider_net.c |1 - 1 file changed, 1 deletion(-) Index: linux-2.6.19-git7/drivers/net/spider_net.c === --- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06 16:03:16.0 -0600 +++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:03:18.0 -0600 @@ -1195,7 +1195,6 @@ spider_net_handle_rxram_full(struct spid while (spider_net_decode_one_descr(card, 0)); spider_net_refill_rx_chain(card); - spider_net_enable_rxchtails(card); spider_net_enable_rxdmac(card); netif_rx_schedule(card-netdev); spider_net_rx_irq_on(card); - 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 16/16] Spidernet Rework RX linked list
Make the hardware perceive the RX descriptor ring as a
null-terminated linked list, instead of a circular ring.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: James K Lewis [EMAIL PROTECTED]
Cc: Arnd Bergmann [EMAIL PROTECTED]
drivers/net/spider_net.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
Index: linux-2.6.19-git7/drivers/net/spider_net.c
===
--- linux-2.6.19-git7.orig/drivers/net/spider_net.c 2006-12-06
16:03:20.0 -0600
+++ linux-2.6.19-git7/drivers/net/spider_net.c 2006-12-06 16:05:48.0
-0600
@@ -389,9 +389,13 @@ spider_net_prepare_rx_descr(struct spide
card-spider_stats.rx_iommu_map_error++;
descr-dmac_cmd_status = SPIDER_NET_DESCR_NOT_IN_USE;
} else {
+ descr-next_descr_addr = 0;
wmb();
descr-dmac_cmd_status = SPIDER_NET_DESCR_CARDOWNED |
SPIDER_NET_DMAC_NOINTR_COMPLETE;
+
+ wmb();
+ descr-prev-next_descr_addr = descr-bus_addr;
}
return 0;
@@ -1676,12 +1680,6 @@ spider_net_open(struct net_device *netde
+ card-num_tx_desc * sizeof(struct
spider_net_descr),
card-num_rx_desc);
- descr = card-rx_chain.head;
- do {
- descr-next_descr_addr = descr-next-bus_addr;
- descr = descr-next;
- } while (descr != card-rx_chain.head);
-
/* allocate rx skbs */
if (spider_net_alloc_rx_skbs(card))
goto alloc_skbs_failed;
-
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/7] d80211: allow for hardware crypto of default keys
Remove incorrect prohibition of hardware crypto support. This was
originally present to prevent hardware crypto when more than one
station interface was created for a single hardware device, the code
in question is no longer correct and should be removed.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -537,9 +537,7 @@ static int ieee80211_set_encryption(stru
}
key = sdata-keys[idx];
- /* Disable hwaccel for default keys when the interface is not
-* the default one.
-* TODO: consider adding hwaccel support for these; at least
+ /* TODO: consider adding hwaccel support for these; at least
* Atheros key cache should be able to handle this since AP is
* only transmitting frames with default keys. */
/* FIX: hw key cache can be used when only one virtual
@@ -548,11 +546,6 @@ static int ieee80211_set_encryption(stru
* must be used. This should be done automatically
* based on configured station devices. For the time
* being, this can be only set at compile time. */
- /* FIXME: There is no more anything like default
-* interface. We should try hwaccel if there is just one
-* interface - for now, hwaccel is unconditionaly
-* disabled. */
- try_hwaccel = 0;
} else {
set_tx_key = 0;
if (idx != 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 5/7] d80211: remove unused references to sub interface data
In these three cases the pointer returned by IEEE80211_DEV_TO_SUB_IF()
is never used.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -1362,11 +1362,9 @@ static int ieee80211_master_start_xmit(s
struct ieee80211_tx_control control;
struct ieee80211_tx_packet_data *pkt_data;
struct net_device *odev = NULL;
- struct ieee80211_sub_if_data *sdata, *osdata;
+ struct ieee80211_sub_if_data *osdata;
int ret;
- sdata = IEEE80211_DEV_TO_SUB_IF(dev);
-
/*
* copy control out of the skb so other people can use skb-cb
*/
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -407,10 +407,8 @@ static int ieee80211_ioctl_get_info_sta(
if (param-sta_addr[0] == 0xff param-sta_addr[1] == 0xff
param-sta_addr[2] == 0xff param-sta_addr[3] == 0xff
param-sta_addr[4] == 0xff param-sta_addr[5] == 0xff) {
- struct ieee80211_sub_if_data *sdata;
struct net_device_stats *stats;
- sdata = IEEE80211_DEV_TO_SUB_IF(dev);
stats = ieee80211_dev_stats(local-mdev);
param-u.get_info_sta.rx_bytes = stats-rx_bytes;
param-u.get_info_sta.tx_bytes = stats-tx_bytes;
Index: wireless-dev/net/d80211/ieee80211_iface.c
===
--- wireless-dev.orig/net/d80211/ieee80211_iface.c
+++ wireless-dev/net/d80211/ieee80211_iface.c
@@ -42,7 +42,7 @@ int ieee80211_if_add(struct net_device *
{
struct net_device *ndev, *tmp_dev;
struct ieee80211_local *local = dev-ieee80211_ptr;
- struct ieee80211_sub_if_data *sdata = NULL, *sdata_parent;
+ struct ieee80211_sub_if_data *sdata = NULL;
int ret;
int i;
@@ -83,7 +83,6 @@ int ieee80211_if_add(struct net_device *
sdata-type = IEEE80211_IF_TYPE_AP;
sdata-dev = ndev;
sdata-local = local;
- sdata_parent = IEEE80211_DEV_TO_SUB_IF(dev);
ieee80211_if_sdata_init(sdata);
ret = register_netdevice(ndev);
--
-
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 7/7] d80211: do not pass an invalid key index to set_key()
If a hardware key has not been configured then there is no point
to calling DISABLE_KEY.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -612,7 +612,7 @@ static int ieee80211_set_encryption(stru
if (alg == ALG_NONE) {
keyconf = NULL;
- if (try_hwaccel key local-ops-set_key
+ if (try_hwaccel key key-hw_key_idx != -1
local-ops-set_key
(keyconf = ieee80211_key_data2conf(local, key)) != NULL
local-ops-set_key(local_to_hw(local), DISABLE_KEY,
sta_addr, keyconf, sta ? sta-aid : 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 4/7] d80211: fix potential invalid array index returning key information
sdata-keys[] has NUM_DEFAULT_KEYS elements, don't access past that.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -803,7 +803,7 @@ static int ieee80211_ioctl_get_encryptio
param-sta_addr[2] == 0xff param-sta_addr[3] == 0xff
param-sta_addr[4] == 0xff param-sta_addr[5] == 0xff) {
sta = NULL;
- if (param-u.crypt.idx NUM_DEFAULT_KEYS) {
+ if (param-u.crypt.idx = NUM_DEFAULT_KEYS) {
param-u.crypt.idx = sdata-default_key ?
sdata-default_key-keyidx : 0;
return 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 3/7] d80211: fix potential interface name overflow
dev-name and ndev-name are both IFNAMSIZ in length, the .%d is
not guarenteed to fit in ndev-name.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_iface.c
===
--- wireless-dev.orig/net/d80211/ieee80211_iface.c
+++ wireless-dev/net/d80211/ieee80211_iface.c
@@ -56,7 +56,8 @@ int ieee80211_if_add(struct net_device *
if (strlen(name) == 0) {
i = 0;
do {
- sprintf(ndev-name, %s.%d, dev-name, i++);
+ snprintf(ndev-name, sizeof(ndev-name), %s.%d,
+dev-name, i++);
tmp_dev = dev_get_by_name(ndev-name);
if (!tmp_dev)
break;
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/7] d80211: set default_wep_only dynamically
Without this change d80211 relies on userspace to let it know when it can
configure default wep keys. It is always safe to set default_wep_only if there
is a single station interface. This allows for hardware accelleration for
the case of a single station interface.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_i.h
===
--- wireless-dev.orig/net/d80211/ieee80211_i.h
+++ wireless-dev/net/d80211/ieee80211_i.h
@@ -607,6 +607,7 @@ extern const struct iw_handler_def ieee8
int ieee80211_set_hw_encryption(struct net_device *dev,
struct sta_info *sta, u8 addr[ETH_ALEN],
struct ieee80211_key *key);
+void ieee80211_update_default_wep_only(struct ieee80211_local *local);
/* ieee80211_scan.c */
void ieee80211_init_scan(struct ieee80211_local *local);
Index: wireless-dev/net/d80211/ieee80211_iface.c
===
--- wireless-dev.orig/net/d80211/ieee80211_iface.c
+++ wireless-dev/net/d80211/ieee80211_iface.c
@@ -97,6 +97,7 @@ int ieee80211_if_add(struct net_device *
}
list_add(sdata-list, local-sub_if_list);
+ ieee80211_update_default_wep_only(local);
return 0;
@@ -164,6 +165,7 @@ void ieee80211_if_del_mgmt(struct ieee80
void ieee80211_if_set_type(struct net_device *dev, int type)
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ struct ieee80211_local *local = dev-ieee80211_ptr;
sdata-type = type;
switch (type) {
@@ -205,6 +207,7 @@ void ieee80211_if_set_type(struct net_de
dev-name, __FUNCTION__, type);
}
ieee80211_sysfs_change_if_type(dev);
+ ieee80211_update_default_wep_only(local);
}
/* Must be called with rtnl lock held. */
@@ -329,6 +332,7 @@ int ieee80211_if_remove(struct net_devic
strcmp(name, sdata-dev-name) == 0
sdata-dev != local-mdev) {
__ieee80211_if_del(local, sdata);
+ ieee80211_update_default_wep_only(local);
return 0;
}
}
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -2357,6 +2357,36 @@ static int ieee80211_ioctl_default_wep_o
}
+void ieee80211_update_default_wep_only(struct ieee80211_local *local)
+{
+ int i = 0;
+ struct ieee80211_sub_if_data *sdata;
+
+ spin_lock_bh(local-sub_if_lock);
+ list_for_each_entry(sdata, local-sub_if_list, list) {
+
+ if (sdata-dev == local-mdev)
+ continue;
+
+ /* If there is an AP interface then depend on userspace to
+ set default_wep_only correctly. */
+ if (sdata-type == IEEE80211_IF_TYPE_AP) {
+ spin_unlock_bh(local-sub_if_lock);
+ return;
+ }
+
+ i++;
+ }
+
+ if (i = 1)
+ ieee80211_ioctl_default_wep_only(local, 1);
+ else
+ ieee80211_ioctl_default_wep_only(local, 0);
+
+ spin_unlock_bh(local-sub_if_lock);
+}
+
+
static int ieee80211_ioctl_prism2_param(struct net_device *dev,
struct iw_request_info *info,
void *wrqu, char *extra)
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 6/7] d80211: fix invalid check for sub interface type AP
We should be checking the type member, not the raw pointer.
Signed-off-by: David Kimdon [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/d80211/ieee80211_ioctl.c
@@ -1996,7 +1996,7 @@ static int ieee80211_ioctl_siwscan(struc
sdata-type == IEEE80211_IF_TYPE_IBSS) {
ssid = sdata-u.sta.ssid;
ssid_len = sdata-u.sta.ssid_len;
- } else if (sdata == IEEE80211_IF_TYPE_AP) {
+ } else if (sdata-type == IEEE80211_IF_TYPE_AP) {
ssid = sdata-u.ap.ssid;
ssid_len = sdata-u.ap.ssid_len;
} else
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [IrDA] Incorrect TTP header reservation
We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in.
Patch from Jeet Chaudhuri [EMAIL PROTECTED]
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]
---
net/irda/irttp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/irda/irttp.c b/net/irda/irttp.c
index 252f110..03504f3 100644
--- a/net/irda/irttp.c
+++ b/net/irda/irttp.c
@@ -1100,7 +1100,7 @@ int irttp_connect_request(struct tsap_cb
return -ENOMEM;
/* Reserve space for MUX_CONTROL and LAP header */
- skb_reserve(tx_skb, TTP_MAX_HEADER);
+ skb_reserve(tx_skb, TTP_MAX_HEADER + TTP_SAR_HEADER);
} else {
tx_skb = userdata;
/*
@@ -1349,7 +1349,7 @@ int irttp_connect_response(struct tsap_c
return -ENOMEM;
/* Reserve space for MUX_CONTROL and LAP header */
- skb_reserve(tx_skb, TTP_MAX_HEADER);
+ skb_reserve(tx_skb, TTP_MAX_HEADER + TTP_SAR_HEADER);
} else {
tx_skb = userdata;
/*
--
1.4.2.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 1/2] [IrDA] PXA FIR code device model conversion
Hi Dave,
pxaficp_ir.c was not converted to the device model framework.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]
---
drivers/net/irda/pxaficp_ir.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/irda/pxaficp_ir.c b/drivers/net/irda/pxaficp_ir.c
index f9a1c88..9137e23 100644
--- a/drivers/net/irda/pxaficp_ir.c
+++ b/drivers/net/irda/pxaficp_ir.c
@@ -704,9 +704,9 @@ static int pxa_irda_stop(struct net_devi
return 0;
}
-static int pxa_irda_suspend(struct device *_dev, pm_message_t state)
+static int pxa_irda_suspend(struct platform_device *_dev, pm_message_t state)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
struct pxa_irda *si;
if (dev netif_running(dev)) {
@@ -718,9 +718,9 @@ static int pxa_irda_suspend(struct devic
return 0;
}
-static int pxa_irda_resume(struct device *_dev)
+static int pxa_irda_resume(struct platform_device *_dev)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
struct pxa_irda *si;
if (dev netif_running(dev)) {
@@ -746,9 +746,8 @@ static int pxa_irda_init_iobuf(iobuff_t
return io-head ? 0 : -ENOMEM;
}
-static int pxa_irda_probe(struct device *_dev)
+static int pxa_irda_probe(struct platform_device *pdev)
{
- struct platform_device *pdev = to_platform_device(_dev);
struct net_device *dev;
struct pxa_irda *si;
unsigned int baudrate_mask;
@@ -822,9 +821,9 @@ err_mem_1:
return err;
}
-static int pxa_irda_remove(struct device *_dev)
+static int pxa_irda_remove(struct platform_device *_dev)
{
- struct net_device *dev = dev_get_drvdata(_dev);
+ struct net_device *dev = platform_get_drvdata(_dev);
if (dev) {
struct pxa_irda *si = netdev_priv(dev);
@@ -840,9 +839,10 @@ static int pxa_irda_remove(struct device
return 0;
}
-static struct device_driver pxa_ir_driver = {
- .name = pxa2xx-ir,
- .bus= platform_bus_type,
+static struct platform_driver pxa_ir_driver = {
+ .driver = {
+ .name = pxa2xx-ir,
+ },
.probe = pxa_irda_probe,
.remove = pxa_irda_remove,
.suspend= pxa_irda_suspend,
@@ -851,12 +851,12 @@ static struct device_driver pxa_ir_drive
static int __init pxa_irda_init(void)
{
- return driver_register(pxa_ir_driver);
+ return platform_driver_register(pxa_ir_driver);
}
static void __exit pxa_irda_exit(void)
{
- driver_unregister(pxa_ir_driver);
+ platform_driver_unregister(pxa_ir_driver);
}
module_init(pxa_irda_init);
--
1.4.2.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: network devices don't handle pci_dma_mapping_error()'s
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 6 Dec 2006 10:16:44 -0800 I think it is really only an issue for drivers that turn on HIGH_DMA and have limited mask values. The majority of drivers either only handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the details of how we manage IOMMU, but doesn't mapping always work for those drivers. That just leaves devices with odd size mask values that need to be handle mapping errors. Not true. On platforms such as sparc64 the IOMMU is used for all DMA mappings, no matter what, because only IOMMU based mappings can do prefetching and write-combining in the PCI controller. The problem with just silently dropping packets that can't get DMA mapped is that you're going to drop a very large sequence of these while the IOMMU is out of space, and that to me looks like a bad quality of implementation decision. The IOMMU layer really needs a way to callback the driver to tell it when space is available, or something similar. FWIW, Solaris handles this by blocking when the IOMMU is out of space since under Solaris even interrupt contexts can block (via interrupt threads). - 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] irlan: fix header build warning
From: Randy Dunlap [EMAIL PROTECTED] Date: Wed, 6 Dec 2006 11:44:07 -0800 From: Randy Dunlap [EMAIL PROTECTED] Fix compile warning when CONFIG_PROC_FS=n: include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared inside parameter list include/net/irda/irlan_filter.h:31: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Randy Dunlap [EMAIL PROTECTED] How about we protect these function externs with CONFIG_PROC_FS ifdefs instead? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
On Wed, 06 Dec 2006 16:54:18 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 6 Dec 2006 10:16:44 -0800 I think it is really only an issue for drivers that turn on HIGH_DMA and have limited mask values. The majority of drivers either only handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the details of how we manage IOMMU, but doesn't mapping always work for those drivers. That just leaves devices with odd size mask values that need to be handle mapping errors. Not true. On platforms such as sparc64 the IOMMU is used for all DMA mappings, no matter what, because only IOMMU based mappings can do prefetching and write-combining in the PCI controller. The problem with just silently dropping packets that can't get DMA mapped is that you're going to drop a very large sequence of these while the IOMMU is out of space, and that to me looks like a bad quality of implementation decision. The IOMMU layer really needs a way to callback the driver to tell it when space is available, or something similar. FWIW, Solaris handles this by blocking when the IOMMU is out of space since under Solaris even interrupt contexts can block (via interrupt threads). - 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 The more robust way would be to stop the queue (like flow control) and return busy. You would need a timer though to handle the case where some disk i/o stole all the mappings and then network device flow blocked. - 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] irlan: fix header build warning
On Wed, 06 Dec 2006 16:57:17 -0800 (PST) David Miller wrote: How about we protect these function externs with CONFIG_PROC_FS ifdefs instead? Sure. --- From: Randy Dunlap [EMAIL PROTECTED] Fix compile warning when CONFIG_PROC_FS=n: include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared inside parameter list include/net/irda/irlan_filter.h:31: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- include/net/irda/irlan_filter.h |2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.19-git7.orig/include/net/irda/irlan_filter.h +++ linux-2.6.19-git7/include/net/irda/irlan_filter.h @@ -28,6 +28,8 @@ void irlan_check_command_param(struct irlan_cb *self, char *param, char *value); void irlan_filter_request(struct irlan_cb *self, struct sk_buff *skb); +#ifdef CONFIG_PROC_FS void irlan_print_filter(struct seq_file *seq, int filter_type); +#endif #endif /* IRLAN_FILTER_H */ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 6 Dec 2006 16:58:35 -0800 The more robust way would be to stop the queue (like flow control) and return busy. You would need a timer though to handle the case where some disk i/o stole all the mappings and then network device flow blocked. You need some kind of fairness, yes, that's why I suggested a callback. When your DMA allocation fails, you get into the rear of the FIFO, when a free occurs, we callback starting from the head of the FIFO. You don't get removed from the FIFO unless at least one of your DMA allocation retries succeed. - 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] bonding: change spinlocks and remove timers in favor of workqueues
On 12/4/06, Jay Vosburgh [EMAIL PROTECTED] wrote: Andy Gospodarek [EMAIL PROTECTED] wrote: [...] Let me see if I can dust off the extensive patch that does change the locking model; I'll see if I can bring it up to the current git and post it. It would seem ideal if we could combine the two into one big patch. Appended is my working development patch for rearranging a bunch of stuff in bonding. This is a work in progress, and is not likely to be very stable. This largely reimplements the entire link monitor scheme, along with associated locking changes. It's not split into functional pieces, and is just a big kitchen sink blob at the moment. It's still very experimental. Jay, Thanks for sending it. I've finally got some time to digest it. I didn't get a chance to test it, but I did have a chance to take a look at it in detail. I certainly agree with the design points you laid out in your description. I like the fact that you've restructured a lot of the code and moved the monitoring to a common place. It is also nice to have it in one spot so you can report link status and bond membership. I don't think the bh-locking is necessary since the workqueues eliminate the possibility that you will be preempted by the bonding driver -- I dropped them all from my patch. Overall this seems like a good way to go, but it [obviously] seems like it would be good to work towards this functionality rather than simply dumping this huge blob all at once. I would like to use a smaller patch to switch to workqueues (my patch or a partial of yours -- it makes no difference to me) as a start with the intent to let that soak-in for a while and follow it with chunks that will eventually get the entire driver closer to the functionality that your big patch has. Thoughts? -andy - 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] softmac: Fixed handling of deassociation from AP
On Wednesday 06 December 2006 15:45, Larry Finger wrote:
From: Ulrich Kunitz [EMAIL PROTECTED]
A deauthentication from the AP doesn't start a reassociation by
SoftMAC. To fix this mac-associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled.
Signed-off-by: Ulrich Kunitz [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
net/ieee80211/softmac/ieee80211softmac_assoc.c | 14 --
net/ieee80211/softmac/ieee80211softmac_auth.c |2 ++
net/ieee80211/softmac/ieee80211softmac_priv.h |2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
Index: wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
===
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ wireless-2.6/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -427,6 +427,17 @@ ieee80211softmac_handle_assoc_response(s
return 0;
}
+void
+ieee80211softmac_try_reassoc(struct ieee80211softmac_device *mac)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(mac-lock, flags);
+ mac-associnfo.associating = 1;
+ schedule_work(mac-associnfo.work);
+ spin_unlock_irqrestore(mac-lock, flags);
+}
All data in mac-associnfo is protected by mac-associnfo-mutex
and _not_ mac-lock.
--
Greetings Michael.
-
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] softmac: Fixed handling of deassociation from AP
On 06-12-06 18:52 Michael Buesch wrote:
All data in mac-associnfo is protected by mac-associnfo-mutex
and _not_ mac-lock.
Are you sure? One can find for instance the following function in
ieee80211softmac_assoc.c:
void
ieee80211softmac_disassoc(struct ieee80211softmac_device *mac)
{
unsigned long flags;
spin_lock_irqsave(mac-lock, flags);
if (mac-associnfo.associating)
cancel_delayed_work(mac-associnfo.timeout);
netif_carrier_off(mac-dev);
mac-associnfo.associated = 0;
mac-associnfo.bssvalid = 0;
mac-associnfo.associating = 0;
ieee80211softmac_init_bss(mac);
ieee80211softmac_call_events_locked(mac,
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
spin_unlock_irqrestore(mac-lock, flags);
}
Cheers,
Uli
--
Uli Kunitz
-
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] softmac: Fixed handling of deassociation from AP
On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
On 06-12-06 18:52 Michael Buesch wrote:
All data in mac-associnfo is protected by mac-associnfo-mutex
and _not_ mac-lock.
Are you sure?
Yes I am.
One can find for instance the following function in
ieee80211softmac_assoc.c:
This is not the first time we notice that locking
is completely broken in softmac. ;)
void
ieee80211softmac_disassoc(struct ieee80211softmac_device *mac)
{
unsigned long flags;
spin_lock_irqsave(mac-lock, flags);
if (mac-associnfo.associating)
cancel_delayed_work(mac-associnfo.timeout);
netif_carrier_off(mac-dev);
mac-associnfo.associated = 0;
mac-associnfo.bssvalid = 0;
mac-associnfo.associating = 0;
ieee80211softmac_init_bss(mac);
ieee80211softmac_call_events_locked(mac,
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
spin_unlock_irqrestore(mac-lock, flags);
}
Cheers,
Uli
--
Greetings Michael.
-
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] softmac: Fixed handling of deassociation from AP
On 06-12-06 21:52 Michael Buesch wrote: On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote: On 06-12-06 18:52 Michael Buesch wrote: All data in mac-associnfo is protected by mac-associnfo-mutex and _not_ mac-lock. Are you sure? Yes I am. One can find for instance the following function in ieee80211softmac_assoc.c: This is not the first time we notice that locking is completely broken in softmac. ;) So the right thing would be to add another work function (*_start_reassoc_work) which sets the associating variable and calls then *_assoc_work? Uli -- Uli Kunitz - 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] softmac: Fixed handling of deassociation from AP
On Wednesday 06 December 2006 22:51, Ulrich Kunitz wrote: On 06-12-06 21:52 Michael Buesch wrote: On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote: On 06-12-06 18:52 Michael Buesch wrote: All data in mac-associnfo is protected by mac-associnfo-mutex and _not_ mac-lock. Are you sure? Yes I am. One can find for instance the following function in ieee80211softmac_assoc.c: This is not the first time we notice that locking is completely broken in softmac. ;) So the right thing would be to add another work function (*_start_reassoc_work) which sets the associating variable and calls then *_assoc_work? Ah, well. I think the right thing doesn't exist. Even if you replace the lock by the mutex, it's still racy. The whole lock design of softmac is broken and racy and we can't simply fix that with a oneliner. I'd say, John, apply the original patch as-is, as it does more good than harm. Basically, I just wanted to point out that this is not race-free. But I think we can live with it. -- Greetings Michael. - 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] softmac: Fixed handling of deassociation from AP
Michael Buesch wrote: On Wednesday 06 December 2006 22:51, Ulrich Kunitz wrote: On 06-12-06 21:52 Michael Buesch wrote: On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote: On 06-12-06 18:52 Michael Buesch wrote: All data in mac-associnfo is protected by mac-associnfo-mutex and _not_ mac-lock. Are you sure? Yes I am. One can find for instance the following function in ieee80211softmac_assoc.c: This is not the first time we notice that locking is completely broken in softmac. ;) So the right thing would be to add another work function (*_start_reassoc_work) which sets the associating variable and calls then *_assoc_work? Ah, well. I think the right thing doesn't exist. Even if you replace the lock by the mutex, it's still racy. The whole lock design of softmac is broken and racy and we can't simply fix that with a oneliner. I'd say, John, apply the original patch as-is, as it does more good than harm. Basically, I just wanted to point out that this is not race-free. But I think we can live with it. In struct ieee80211softmac_device, there are the following entries: ... spinlock_t lock; u8 running; /* SoftMAC started? */ u8 scanning; struct ieee80211softmac_scaninfo *scaninfo; struct ieee80211softmac_assoc_info associnfo; struct ieee80211softmac_bss_info bssinfo; ... In struct ieee80211softmac_assoc_info, we have the following entries: struct mutex mutex; struct ieee80211softmac_essid associate_essid; char bssid[ETH_ALEN]; u8 static_essid; u8 short_preamble_available; u8 associating; u8 associated; u8 assoc_wait; u8 bssvalid; u8 bssfixed; Although it has been amply demonstrated in this forum that I know nothing about locking, it seems to me that the mutex protects only the association data; whereas the spinlock protects more data, but does include the association data. If this is correct, then the original posted code is not wrong, only protecting data unnecessarily. Please point out the error in my logic. I'm trying to learn. Larry - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
David Miller wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 6 Dec 2006 16:58:35 -0800 The more robust way would be to stop the queue (like flow control) and return busy. You would need a timer though to handle the case where some disk i/o stole all the mappings and then network device flow blocked. You need some kind of fairness, yes, that's why I suggested a callback. When your DMA allocation fails, you get into the rear of the FIFO, when a free occurs, we callback starting from the head of the FIFO. You don't get removed from the FIFO unless at least one of your DMA allocation retries succeed. While tossing a TCP|UDP|SCTP|etc packet could be plusungood, especially if the IOMMU fills frequently (for some suitable definiton of frequently), is it really worth the effort to save say an ACK? rick jones - 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: network devices don't handle pci_dma_mapping_error()'s
From: Rick Jones [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 18:18:52 -0800 While tossing a TCP|UDP|SCTP|etc packet could be plusungood, especially if the IOMMU fills frequently (for some suitable definiton of frequently), is it really worth the effort to save say an ACK? ACKs are less important than data packets sure. But the drivers shouldn't be parsing packets at transmit time to decide what to do. And when this kind of thing fails, it's going to fail for all the packets currently queued up to the device for transmit. So it's likely not just an ACK, but rather a set of several packets composed of ACKs and data packets. - 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] [IrDA] PXA FIR code device model conversion
From: Samuel Ortiz [EMAIL PROTECTED] Date: Thu, 7 Dec 2006 02:50:53 +0200 pxaficp_ir.c was not converted to the device model framework. Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IrDA] Incorrect TTP header reservation
From: Samuel Ortiz [EMAIL PROTECTED] Date: Thu, 7 Dec 2006 02:51:17 +0200 We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in. Patch from Jeet Chaudhuri [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Also applied. Are you sending this patch to -stable? Please do. - 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] irlan: fix header build warning
From: Randy Dunlap [EMAIL PROTECTED] Date: Wed, 6 Dec 2006 17:08:18 -0800 On Wed, 06 Dec 2006 16:57:17 -0800 (PST) David Miller wrote: How about we protect these function externs with CONFIG_PROC_FS ifdefs instead? Sure. --- From: Randy Dunlap [EMAIL PROTECTED] Fix compile warning when CONFIG_PROC_FS=n: include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared inside parameter list include/net/irda/irlan_filter.h:31: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Looks great, 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
NAPI and shared interrupt control
Hi Dave ! I'd like your advice on something we need to deal with in the EMAC ethernet driver (an IBM part). The driver is maintainedby Eugene (CC'd), I'm mostly adding support for some new hardware at this point, which involves making it SMP safe among other things ;-) So the problem this driver has is with NAPI polling and its shared DMA engine. Basically, the DMA engine can be shared between several EMAC ethernet cells. It has separate channels (and thus separate rings) so in that area, all is fine... except the interrupt control. The is only one global interrupt enable/disable bit for packet interrupts, shared by all the EMACs using that DMA engine cell. That means complications for NAPI polling as we can't just disable/enable Rx interrupts as NAPI would normally expect on a per-device basis. What Eugene does currently, which seems to me like it's actually the only proper solution, is to create a separate net_device structure for the DMA engine and thus have a single NAPI poll weighting for all the EMACs sharing a given MAL (MAL is the name of that DMA engine). This means that Rx from any of the channels schedules the poll, and interrupts can be properly masked/unmasked globally based on the presence/absence of work on all the channels. I'd still like to run it through you, make sure you are ok or see if you have a better idea as you are way more familiar with the network stack than I am :-) My main concern with the approach is purely due to how the additional net_device is initialized. It's currently allocated as part of some private data structure in the driver which then manually initializes some fields that are used by NAPI polling. While it certainly works, I find the approach a bit fragile (what if the NAPI code internals change and some initialisations have to be done differently ?) Thus I was wondering, if you think the approach is sane, wether it would make sense to provide a low level netif_init_device() thingy that makes sure a net_device data structure is fully initialized and suitable for use ? (make sure spinlocks are initialized etc...). Something similar to the code used to initialize the backlog fake device ? The driver currently does: set_bit(__LINK_STATE_START, mal-poll_dev.state); mal-poll_dev.weight = CONFIG_IBM_EMAC_POLL_WEIGHT; mal-poll_dev.poll = mal_poll; mal-poll_dev.priv = mal; atomic_set(mal-poll_dev.refcnt, 1); (None of the spinlocks are initialized, but then, the driver was only ever used on UP only embedded CPUs so far and it's possible that none of the NAPI code path for which this net_device structure is used are hitting any spinlock). Or do you think that net_device should be fully registered with register_netdev ? (that would involve a lot more than what is currently needed/used though). Cheers, Ben. - 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: NAPI and shared interrupt control
What Eugene does currently, which seems to me like it's actually the only proper solution, is to create a separate net_device structure for the DMA engine and thus have a single NAPI poll weighting for all the EMACs sharing a given MAL (MAL is the name of that DMA engine). This means that Rx from any of the channels schedules the poll, and interrupts can be properly masked/unmasked globally based on the presence/absence of work on all the channels. Actually, another solution would be to have one of the instances do the NAPI poll for all of them instead of creating a separate net_device for the DMA engine... Ben. - 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: network devices don't handle pci_dma_mapping_error()'s
On Thursday 07 December 2006 01:03, Muli Ben-Yehuda wrote: On Wed, Dec 06, 2006 at 10:16:44AM -0800, Stephen Hemminger wrote: I think it is really only an issue for drivers that turn on HIGH_DMA and have limited mask values. The majority of drivers either only handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the details of how we manage IOMMU, but doesn't mapping always work for those drivers. It's up to an IOMMU (DMA-API) implementation to define what constitutes a mapping error, e.g., Calgary and GART on x86-64 will return bad_dma_address from the mapping functions when they run out of entries in the IO space, which can happen regardless of the mask. We've seen IOMMU space running out on ia64 systems. Would this be the case with other 10G driver requiring IOMMU remapping? We need frequent map-unmap at near 10G throughput. On the x86_64 boxes that don't feature iommu functionality (because the motherboard disables it or because Linux can't handle it) Linux bounce buffer framework automatically comes into picture. Could we have the same framework take over when IOMMU space is over? I don't think this is possible with present code, though. We probably can have fallback_dma_ops in addition to dma_ops. -Amit - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
We can let a driver handle dma mapping errors using these- 1.Reduce the size of a receive ring. This will free some possibly remapped memory, reducing pressure on iommu. We also need to printk a message so that a user knows the reason why receive ring was shrunk. Growing it when iommu pressure goes down will result in a ping-pong. 2. Force processing of receive and transmit ring. This will ensure that the buffers processed by hardware are freed, reducing iommu pressure. 3. If we need to do (1) and (2) a predefined number of times (say 20), stop the queue. Stopping the queue in general will cause a ping-pong, so it should be avoided as far as possible. -Amit On Thursday 07 December 2006 06:28, Stephen Hemminger wrote: The more robust way would be to stop the queue (like flow control) and return busy. You would need a timer though to handle the case where some disk i/o stole all the mappings and then network device flow blocked. - 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] bonding: change spinlocks and remove timers in favor of workqueues
Andy Gospodarek [EMAIL PROTECTED] wrote: On 12/4/06, Jay Vosburgh [EMAIL PROTECTED] wrote: [...] Appended is my working development patch for rearranging a bunch of stuff in bonding. This is a work in progress, and is not likely to be very stable. This largely reimplements the entire link monitor scheme, along with associated locking changes. It's not split into functional pieces, and is just a big kitchen sink blob at the moment. It's still very experimental. [...] Thanks for sending it. I've finally got some time to digest it. I didn't get a chance to test it, but I did have a chance to take a look at it in detail. I think the patch might have been over the size limit for netdev, as I never saw it appear on the list. For interested readers, the description Andy mentions in his next paragraph is: By way of description, in the patch, all monitors (link state and mode specific bits for ALB and 802.3ad) are all dispatched from a single workqueue (rather than each on a separate timer), and the updelay / downdelay parameters are done as special monitors. The monitors can be paused for purposes of conflict avoidance, although some mutexing with TX activity is still necessary. It also allows for the ARP and MII link monitors to run simultaneously (which isn't allowed in the current mainline driver). This also splits up the slave lists into an all and an active list, rearranges the release processing for bonding (consolidates duplicated code from bond_release and bond_release_all into a common function). I'm still dithering as to whether or not this is a good idea; it adds a little complexity to link state changes and add/remove of slaves, but simplifies most of the transmit processing. The locking still needs some adjustment; there's some tracking of whether or not RTNL is held, and right now most locking is of the _bh variety, which may be too strict. I certainly agree with the design points you laid out in your description. I like the fact that you've restructured a lot of the code and moved the monitoring to a common place. It is also nice to have it in one spot so you can report link status and bond membership. I don't think the bh-locking is necessary since the workqueues eliminate the possibility that you will be preempted by the bonding driver -- I dropped them all from my patch. The only concern I had in that regard is whether it's possible to get into a bonding transmit function from someplace that requires _bh level locking to mutex against. I'm thinking in particular of packet receive processing somewhere turning around to do a transmit right away. Overall this seems like a good way to go, but it [obviously] seems like it would be good to work towards this functionality rather than simply dumping this huge blob all at once. I absolutely agree that moving in steps to a final resolution is much better than dropping a big blob; the patch ended up this way since it's just a big diff from my experimental tree. [...] I would like to use a smaller patch to switch to workqueues (my patch or a partial of yours -- it makes no difference to me) as a start with the intent to let that soak-in for a while and follow it with chunks that will eventually get the entire driver closer to the functionality that your big patch has. I don't see a problem in starting with your patch; the end state will be sufficiently different (e.g., the four workqueues would ultimately be consolidated into one) that it's still a good testbed to start with. The only other minor issue is that after this week, I will be off for the holidays (and far, far away from email) for the next month. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
Amit S. Kale wrote: We can let a driver handle dma mapping errors using these- 1.Reduce the size of a receive ring. This will free some possibly remapped memory, reducing pressure on iommu. We also need to printk a message so that a user knows the reason why receive ring was shrunk. Growing it when iommu pressure goes down will result in a ping-pong. 2. Force processing of receive and transmit ring. This will ensure that the buffers processed by hardware are freed, reducing iommu pressure. 3. If we need to do (1) and (2) a predefined number of times (say 20), stop the queue. Stopping the queue in general will cause a ping-pong, so it should be avoided as far as possible. But what if it isn't the network device that is using all the IOMMU resources. Linux is already crap at handling out of memory, lets not add another starvation path. In this case, the device does have some idea about worst case i/o's in flight, couldn't we have some sort of reservation/management system to avoid overcommitting? Worst case map usage for a network device can be fairly high because of the possiblity of on transmit with a high number of pages when using TSO. Perhaps the transmit ring needs to be accounted for in maps used rather than packets pending. - 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: network devices don't handle pci_dma_mapping_error()'s
On Thursday 07 December 2006 12:16, Stephen Hemminger wrote: Amit S. Kale wrote: We can let a driver handle dma mapping errors using these- 1.Reduce the size of a receive ring. This will free some possibly remapped memory, reducing pressure on iommu. We also need to printk a message so that a user knows the reason why receive ring was shrunk. Growing it when iommu pressure goes down will result in a ping-pong. 2. Force processing of receive and transmit ring. This will ensure that the buffers processed by hardware are freed, reducing iommu pressure. 3. If we need to do (1) and (2) a predefined number of times (say 20), stop the queue. Stopping the queue in general will cause a ping-pong, so it should be avoided as far as possible. But what if it isn't the network device that is using all the IOMMU resources. Linux is already crap at handling out of memory, lets not add another starvation path. In this case, the device does have some idea about worst case i/o's in flight, couldn't we have some sort of reservation/management system to avoid overcommitting? Worst case map usage for a network device can be fairly high because of the possiblity of on transmit with a high number of pages when using TSO. Perhaps the transmit ring needs to be accounted for in maps used rather than packets pending. I am afraid I don't have a good answer for that. Any kind of reservation may result in underutilization and transparently shared resources may result in starvation. Designing heuristics for handling these cases may be the only possible wayout, though these heuristics need to be validated frequently to ensure that they aren't out of date. -Amit - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7][TG3]: Add 5787F device ID.
[TG3]: Add 5787F device ID.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 819758e..bfa7e3e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -192,6 +192,7 @@ static struct pci_device_id tg3_pci_tbl[
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5786)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5787)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5787M)},
+ {PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5787F)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5714)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5714S)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5715)},
@@ -10859,7 +10860,8 @@ static int __devinit tg3_get_invariants(
tp-pdev-device == PCI_DEVICE_ID_TIGON3_5705F)) ||
(tp-pdev-vendor == PCI_VENDOR_ID_BROADCOM
(tp-pdev-device == PCI_DEVICE_ID_TIGON3_5751F ||
- tp-pdev-device == PCI_DEVICE_ID_TIGON3_5753F)) ||
+ tp-pdev-device == PCI_DEVICE_ID_TIGON3_5753F ||
+ tp-pdev-device == PCI_DEVICE_ID_TIGON3_5787F)) ||
GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5906)
tp-tg3_flags |= TG3_FLAG_10_100_ONLY;
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6294559..55710b7 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1927,6 +1927,7 @@
#define PCI_DEVICE_ID_TIGON3_5750M 0x167c
#define PCI_DEVICE_ID_TIGON3_5751M 0x167d
#define PCI_DEVICE_ID_TIGON3_5751F 0x167e
+#define PCI_DEVICE_ID_TIGON3_5787F 0x167f
#define PCI_DEVICE_ID_TIGON3_5787M 0x1693
#define PCI_DEVICE_ID_TIGON3_5782 0x1696
#define PCI_DEVICE_ID_TIGON3_5786 0x169a
-
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/7][TG3]: Fix Phy loopback.
[TG3]: Fix Phy loopback.
Phy loopback on most 10/100 devices need to be run in 1Gbps mode in
GMII mode.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c20bb99..819758e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8781,17 +8781,20 @@ static int tg3_run_loopback(struct tg3 *
tg3_writephy(tp, 0x10, phy ~0x4000);
tg3_writephy(tp, MII_TG3_EPHY_TEST, phytest);
}
- }
- val = BMCR_LOOPBACK | BMCR_FULLDPLX;
- if (tp-tg3_flags TG3_FLAG_10_100_ONLY)
- val |= BMCR_SPEED100;
- else
- val |= BMCR_SPEED1000;
+ val = BMCR_LOOPBACK | BMCR_FULLDPLX | BMCR_SPEED100;
+ } else
+ val = BMCR_LOOPBACK | BMCR_FULLDPLX | BMCR_SPEED1000;
tg3_writephy(tp, MII_BMCR, val);
udelay(40);
- if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5906)
+
+ mac_mode = (tp-mac_mode ~MAC_MODE_PORT_MODE_MASK) |
+ MAC_MODE_LINK_POLARITY;
+ if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5906) {
tg3_writephy(tp, MII_TG3_EPHY_PTEST, 0x1800);
+ mac_mode |= MAC_MODE_PORT_MODE_MII;
+ } else
+ mac_mode |= MAC_MODE_PORT_MODE_GMII;
/* reset to prevent losing 1st rx packet intermittently */
if (tp-tg3_flags2 TG3_FLG2_MII_SERDES) {
@@ -8799,12 +8802,6 @@ static int tg3_run_loopback(struct tg3 *
udelay(10);
tw32_f(MAC_RX_MODE, tp-rx_mode);
}
- mac_mode = (tp-mac_mode ~MAC_MODE_PORT_MODE_MASK) |
- MAC_MODE_LINK_POLARITY;
- if (tp-tg3_flags TG3_FLAG_10_100_ONLY)
- mac_mode |= MAC_MODE_PORT_MODE_MII;
- else
- mac_mode |= MAC_MODE_PORT_MODE_GMII;
if ((tp-phy_id PHY_ID_MASK) == PHY_ID_BCM5401) {
mac_mode = ~MAC_MODE_LINK_POLARITY;
tg3_writephy(tp, MII_TG3_EXT_CTRL,
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7][TG3]: Add TG3_FLG2_IS_NIC flag.
[TG3]: Add TG3_FLG2_IS_NIC flag.
Add Tg3_FLG2_IS_NIC flag to unambiguously determine whether the
device is NIC or onboard. Previously, the EEPROM_WRITE_PROT flag was
overloaded to also mean onboard. With the separation, we can
support some devices that are onboard but do not use eeprom write
protect.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index bfa7e3e..6a2f019 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1062,7 +1062,7 @@ static void tg3_frob_aux_power(struct tg
{
struct tg3 *tp_peer = tp;
- if ((tp-tg3_flags TG3_FLAG_EEPROM_WRITE_PROT) != 0)
+ if ((tp-tg3_flags2 TG3_FLG2_IS_NIC) == 0)
return;
if ((GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5704) ||
@@ -1213,8 +1213,8 @@ static int tg3_set_power_state(struct tg
power_control);
udelay(100);/* Delay after power state change */
- /* Switch out of Vaux if it is not a LOM */
- if (!(tp-tg3_flags TG3_FLAG_EEPROM_WRITE_PROT))
+ /* Switch out of Vaux if it is a NIC */
+ if (tp-tg3_flags2 TG3_FLG2_IS_NIC)
tw32_wait_f(GRC_LOCAL_CTRL, tp-grc_local_ctrl, 100);
return 0;
@@ -6397,16 +6397,17 @@ static int tg3_reset_hw(struct tg3 *tp,
udelay(40);
/* tp-grc_local_ctrl is partially set up during tg3_get_invariants().
-* If TG3_FLAG_EEPROM_WRITE_PROT is set, we should read the
+* If TG3_FLG2_IS_NIC is zero, we should read the
* register to preserve the GPIO settings for LOMs. The GPIOs,
* whether used as inputs or outputs, are set by boot code after
* reset.
*/
- if (tp-tg3_flags TG3_FLAG_EEPROM_WRITE_PROT) {
+ if (!(tp-tg3_flags2 TG3_FLG2_IS_NIC)) {
u32 gpio_mask;
- gpio_mask = GRC_LCLCTRL_GPIO_OE0 | GRC_LCLCTRL_GPIO_OE2 |
- GRC_LCLCTRL_GPIO_OUTPUT0 | GRC_LCLCTRL_GPIO_OUTPUT2;
+ gpio_mask = GRC_LCLCTRL_GPIO_OE0 | GRC_LCLCTRL_GPIO_OE1 |
+ GRC_LCLCTRL_GPIO_OE2 | GRC_LCLCTRL_GPIO_OUTPUT0 |
+ GRC_LCLCTRL_GPIO_OUTPUT1 | GRC_LCLCTRL_GPIO_OUTPUT2;
if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5752)
gpio_mask |= GRC_LCLCTRL_GPIO_OE3 |
@@ -6418,8 +6419,9 @@ static int tg3_reset_hw(struct tg3 *tp,
tp-grc_local_ctrl |= tr32(GRC_LOCAL_CTRL) gpio_mask;
/* GPIO1 must be driven high for eeprom write protect */
- tp-grc_local_ctrl |= (GRC_LCLCTRL_GPIO_OE1 |
- GRC_LCLCTRL_GPIO_OUTPUT1);
+ if (tp-tg3_flags TG3_FLAG_EEPROM_WRITE_PROT)
+ tp-grc_local_ctrl |= (GRC_LCLCTRL_GPIO_OE1 |
+ GRC_LCLCTRL_GPIO_OUTPUT1);
}
tw32_f(GRC_LOCAL_CTRL, tp-grc_local_ctrl);
udelay(100);
@@ -9963,8 +9965,10 @@ static void __devinit tg3_get_eeprom_hw_
tp-tg3_flags |= TG3_FLAG_EEPROM_WRITE_PROT;
if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5906) {
- if (!(tr32(PCIE_TRANSACTION_CFG) PCIE_TRANS_CFG_LOM))
+ if (!(tr32(PCIE_TRANSACTION_CFG) PCIE_TRANS_CFG_LOM)) {
tp-tg3_flags = ~TG3_FLAG_EEPROM_WRITE_PROT;
+ tp-tg3_flags2 |= TG3_FLG2_IS_NIC;
+ }
return;
}
@@ -10064,10 +10068,17 @@ static void __devinit tg3_get_eeprom_hw_
tp-pdev-subsystem_vendor == PCI_VENDOR_ID_DELL)
tp-led_ctrl = LED_CTRL_MODE_PHY_2;
- if (nic_cfg NIC_SRAM_DATA_CFG_EEPROM_WP)
+ if (nic_cfg NIC_SRAM_DATA_CFG_EEPROM_WP) {
tp-tg3_flags |= TG3_FLAG_EEPROM_WRITE_PROT;
- else
+ if ((tp-pdev-subsystem_vendor ==
+PCI_VENDOR_ID_ARIMA)
+ (tp-pdev-subsystem_device == 0x205a ||
+tp-pdev-subsystem_device == 0x2063))
+ tp-tg3_flags = ~TG3_FLAG_EEPROM_WRITE_PROT;
+ } else {
tp-tg3_flags = ~TG3_FLAG_EEPROM_WRITE_PROT;
+ tp-tg3_flags2 |= TG3_FLG2_IS_NIC;
+ }
if (nic_cfg NIC_SRAM_DATA_CFG_ASF_ENABLE) {
tp-tg3_flags |= TG3_FLAG_ENABLE_ASF;
@@ -10693,7 +10704,7 @@ static int __devinit tg3_get_invariants(
tp-tg3_flags |= TG3_FLAG_SRAM_USE_CONFIG;
/* Get eeprom hw config before calling tg3_set_power_state().
-* In particular, the TG3_FLAG_EEPROM_WRITE_PROT flag must be
+* In particular, the TG3_FLG2_IS_NIC flag must be
* determined before calling tg3_set_power_state() so that
* we know whether
[PATCH 4/7][TG3]: Allow partial speed advertisement.
[TG3]: Allow partial speed advertisement.
Honor the advertisement bitmask from ethtool. We used to always
advertise the full capability when autoneg was set to on.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 6a2f019..5dfeb64 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1558,12 +1558,6 @@ static void tg3_phy_copper_begin(struct
tg3_writephy(tp, MII_ADVERTISE, new_adv);
} else if (tp-link_config.speed == SPEED_INVALID) {
- tp-link_config.advertising =
- (ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
-ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
-ADVERTISED_1000baseT_Half | ADVERTISED_1000baseT_Full |
-ADVERTISED_Autoneg | ADVERTISED_MII);
-
if (tp-tg3_flags TG3_FLAG_10_100_ONLY)
tp-link_config.advertising =
~(ADVERTISED_1000baseT_Half |
@@ -1707,25 +1701,36 @@ static int tg3_init_5401phy_dsp(struct t
return err;
}
-static int tg3_copper_is_advertising_all(struct tg3 *tp)
+static int tg3_copper_is_advertising_all(struct tg3 *tp, u32 mask)
{
- u32 adv_reg, all_mask;
+ u32 adv_reg, all_mask = 0;
+
+ if (mask ADVERTISED_10baseT_Half)
+ all_mask |= ADVERTISE_10HALF;
+ if (mask ADVERTISED_10baseT_Full)
+ all_mask |= ADVERTISE_10FULL;
+ if (mask ADVERTISED_100baseT_Half)
+ all_mask |= ADVERTISE_100HALF;
+ if (mask ADVERTISED_100baseT_Full)
+ all_mask |= ADVERTISE_100FULL;
if (tg3_readphy(tp, MII_ADVERTISE, adv_reg))
return 0;
- all_mask = (ADVERTISE_10HALF | ADVERTISE_10FULL |
- ADVERTISE_100HALF | ADVERTISE_100FULL);
if ((adv_reg all_mask) != all_mask)
return 0;
if (!(tp-tg3_flags TG3_FLAG_10_100_ONLY)) {
u32 tg3_ctrl;
+ all_mask = 0;
+ if (mask ADVERTISED_1000baseT_Half)
+ all_mask |= ADVERTISE_1000HALF;
+ if (mask ADVERTISED_1000baseT_Full)
+ all_mask |= ADVERTISE_1000FULL;
+
if (tg3_readphy(tp, MII_TG3_CTRL, tg3_ctrl))
return 0;
- all_mask = (MII_TG3_CTRL_ADV_1000_HALF |
- MII_TG3_CTRL_ADV_1000_FULL);
if ((tg3_ctrl all_mask) != all_mask)
return 0;
}
@@ -1885,7 +1890,8 @@ static int tg3_setup_copper_phy(struct t
/* Force autoneg restart if we are exiting
* low power mode.
*/
- if (!tg3_copper_is_advertising_all(tp))
+ if (!tg3_copper_is_advertising_all(tp,
+ tp-link_config.advertising))
current_link_up = 0;
} else {
current_link_up = 0;
@@ -10156,7 +10162,7 @@ static int __devinit tg3_phy_probe(struc
if (!(tp-tg3_flags2 TG3_FLG2_ANY_SERDES)
!(tp-tg3_flags TG3_FLAG_ENABLE_ASF)) {
- u32 bmsr, adv_reg, tg3_ctrl;
+ u32 bmsr, adv_reg, tg3_ctrl, mask;
tg3_readphy(tp, MII_BMSR, bmsr);
if (!tg3_readphy(tp, MII_BMSR, bmsr)
@@ -10180,7 +10186,10 @@ static int __devinit tg3_phy_probe(struc
MII_TG3_CTRL_ENABLE_AS_MASTER);
}
- if (!tg3_copper_is_advertising_all(tp)) {
+ mask = (ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
+ ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
+ ADVERTISED_1000baseT_Half | ADVERTISED_1000baseT_Full);
+ if (!tg3_copper_is_advertising_all(tp, mask)) {
tg3_writephy(tp, MII_ADVERTISE, adv_reg);
if (!(tp-tg3_flags TG3_FLAG_10_100_ONLY))
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7][TG3]: Use netif_msg_*.
[TG3]: Use netif_msg_*.
Use netif_msg_* to turn on or off some messages.
Based on Stephen Hemminger's initial patch.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 5dfeb64..99fb4e4 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1402,8 +1402,10 @@ static int tg3_set_power_state(struct tg
static void tg3_link_report(struct tg3 *tp)
{
if (!netif_carrier_ok(tp-dev)) {
- printk(KERN_INFO PFX %s: Link is down.\n, tp-dev-name);
- } else {
+ if (netif_msg_link(tp))
+ printk(KERN_INFO PFX %s: Link is down.\n,
+ tp-dev-name);
+ } else if (netif_msg_link(tp)) {
printk(KERN_INFO PFX %s: Link is up at %d Mbps, %s duplex.\n,
tp-dev-name,
(tp-link_config.active_speed == SPEED_1000 ?
@@ -3710,8 +3712,9 @@ static void tg3_tx_timeout(struct net_de
{
struct tg3 *tp = netdev_priv(dev);
- printk(KERN_ERR PFX %s: transmit timed out, resetting\n,
- dev-name);
+ if (netif_msg_tx_err(tp))
+ printk(KERN_ERR PFX %s: transmit timed out, resetting\n,
+ dev-name);
schedule_work(tp-reset_task);
}
@@ -8665,7 +8668,9 @@ static int tg3_test_registers(struct tg3
return 0;
out:
- printk(KERN_ERR PFX Register test failed at offset %x\n, offset);
+ if (netif_msg_hw(tp))
+ printk(KERN_ERR PFX Register test failed at offset %x\n,
+ offset);
tw32(offset, save_val);
return -EIO;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7][TG3]: Use msleep.
[TG3]: Use msleep.
Change some udelay() in some eeprom functions to msleep(). Eeprom
related functions are always called from sleepable context.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 99fb4e4..61e9533 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -9467,16 +9467,12 @@ static void __devinit tg3_get_5906_nvram
/* Chips other than 5700/5701 use the NVRAM for fetching info. */
static void __devinit tg3_nvram_init(struct tg3 *tp)
{
- int j;
-
tw32_f(GRC_EEPROM_ADDR,
(EEPROM_ADDR_FSM_RESET |
(EEPROM_DEFAULT_CLOCK_PERIOD
EEPROM_ADDR_CLKPERD_SHIFT)));
- /* XXX schedule_timeout() ... */
- for (j = 0; j 100; j++)
- udelay(10);
+ msleep(1);
/* Enable seeprom accesses. */
tw32_f(GRC_LOCAL_CTRL,
@@ -9537,12 +9533,12 @@ static int tg3_nvram_read_using_eeprom(s
EEPROM_ADDR_ADDR_MASK) |
EEPROM_ADDR_READ | EEPROM_ADDR_START);
- for (i = 0; i 1; i++) {
+ for (i = 0; i 1000; i++) {
tmp = tr32(GRC_EEPROM_ADDR);
if (tmp EEPROM_ADDR_COMPLETE)
break;
- udelay(100);
+ msleep(1);
}
if (!(tmp EEPROM_ADDR_COMPLETE))
return -EBUSY;
@@ -9667,12 +9663,12 @@ static int tg3_nvram_write_block_using_e
EEPROM_ADDR_START |
EEPROM_ADDR_WRITE);
- for (j = 0; j 1; j++) {
+ for (j = 0; j 1000; j++) {
val = tr32(GRC_EEPROM_ADDR);
if (val EEPROM_ADDR_COMPLETE)
break;
- udelay(100);
+ msleep(1);
}
if (!(val EEPROM_ADDR_COMPLETE)) {
rc = -EBUSY;
-
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 7/7][TG3]: Identify Serdes devices more clearly.
[TG3]: Identify Serdes devices more clearly. Change the message to more clearly identify Serdes devices. Update version to 3.70. Signed-off-by: Michael Chan [EMAIL PROTECTED] diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c index 61e9533..a71707e 100644 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -68,8 +68,8 @@ #define DRV_MODULE_NAMEtg3 #define PFX DRV_MODULE_NAME: -#define DRV_MODULE_VERSION 3.69 -#define DRV_MODULE_RELDATE November 15, 2006 +#define DRV_MODULE_VERSION 3.70 +#define DRV_MODULE_RELDATE December 1, 2006 #define TG3_DEF_MAC_MODE 0 #define TG3_DEF_RX_MODE0 @@ -11932,13 +11932,15 @@ static int __devinit tg3_init_one(struct pci_set_drvdata(pdev, dev); - printk(KERN_INFO %s: Tigon3 [partno(%s) rev %04x PHY(%s)] (%s) %sBaseT Ethernet , + printk(KERN_INFO %s: Tigon3 [partno(%s) rev %04x PHY(%s)] (%s) %s Ethernet , dev-name, tp-board_part_number, tp-pci_chip_rev_id, tg3_phy_string(tp), tg3_bus_string(tp, str), - (tp-tg3_flags TG3_FLAG_10_100_ONLY) ? 10/100 : 10/100/1000); + ((tp-tg3_flags TG3_FLAG_10_100_ONLY) ? 10/100Base-TX : + ((tp-tg3_flags2 TG3_FLG2_ANY_SERDES) ? 1000Base-SX : +10/100/1000Base-T))); for (i = 0; i 6; i++) printk(%2.2x%c, dev-dev_addr[i], - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/16] Spidernet DMA coalescing
It worries me when a patch series gets resent a few hours later. Did anything change? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network devices don't handle pci_dma_mapping_error()'s
From: Amit S. Kale [EMAIL PROTECTED] Date: Thu, 7 Dec 2006 11:55:22 +0530 We can let a driver handle dma mapping errors using these- 1.Reduce the size of a receive ring. This will free some possibly remapped memory, reducing pressure on iommu. We also need to printk a message so that a user knows the reason why receive ring was shrunk. Growing it when iommu pressure goes down will result in a ping-pong. 2. Force processing of receive and transmit ring. This will ensure that the buffers processed by hardware are freed, reducing iommu pressure. 3. If we need to do (1) and (2) a predefined number of times (say 20), stop the queue. Stopping the queue in general will cause a ping-pong, so it should be avoided as far as possible. This scheme assumes the networking card is the culprit. In many workloads it will not be and these efforts will be in vain and perhaps even make the situation worse. There's not reason to run the RX and TX queues, and even shrink them, when the FC controller has most of the IOMMU entires tied up. That's why users needs to queue up and get feedback when IOMMU space is made available. - 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][IPSEC][4/7] inter address family ipsec tunnel
From: Kazunori MIYAZAWA [EMAIL PROTECTED] Date: Wed, 6 Dec 2006 20:35:37 +0900 Sorry, I mixed up changes in the patches. I described that [4/7] will add IPv6 over IPv4 IPsec tunnel. However I send a patch for IPv4 over IPv6 as a reply because it includes the discussing item. So this patch adds IPv4 over IPv6 IPsec tunnel. It's complicated. I deleted subustituting NULL for rt-peer and moved atomic_inc stuff under the if section. I have applied this patch, thanks for fixing it up. BTW, I have a question about descrementing the reference count of rt-peer. The reference cound in normal dst structure is decremented by calling inet_putpeer from ipv4_dst_destroy. But xfrm4_dst_destroy does not call inet_putpeer. Where do we decrement the count? Should xfrm4_dst_destroy do that? Indeed, it is a real leak. And yes, I believe that xfrm4_dst_destroy() should release it. I will make this fix, 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
Re: [PATCH][IPSEC][4/7] inter address family ipsec tunnel
From: David Miller [EMAIL PROTECTED] Date: Wed, 06 Dec 2006 23:37:49 -0800 (PST) From: Kazunori MIYAZAWA [EMAIL PROTECTED] Date: Wed, 6 Dec 2006 20:35:37 +0900 Sorry, I mixed up changes in the patches. I described that [4/7] will add IPv6 over IPv4 IPsec tunnel. However I send a patch for IPv4 over IPv6 as a reply because it includes the discussing item. So this patch adds IPv4 over IPv6 IPsec tunnel. It's complicated. I deleted subustituting NULL for rt-peer and moved atomic_inc stuff under the if section. I have applied this patch, thanks for fixing it up. Actually, I have to revert this change again, it still has a problem. Sorry :-/ I very much feared the following kind of obstacle with these changes. Specifically, references to modular IPV6 code from statically compiled IPV4 code. Which produces the following build error: net/built-in.o: In function `__xfrm4_bundle_create':xfrm4_policy.c:(.text+0x59a88): undefined reference to `xfrm6_output' :xfrm4_policy.c:(.text+0x59ac0): undefined reference to `xfrm6_output' Please test with IPV6 built modular in the future, 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
