* Re: [PATCH][IPX] Use existing sock refcnt debugging infrastructure
From: Arnaldo Carvalho de Melo @ 2007-11-09 14:39 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: David Miller, Arnaldo Carvalho de Melo, Linux Netdev List, devel
In-Reply-To: <473463AD.9000807@openvz.org>
Em Fri, Nov 09, 2007 at 04:42:05PM +0300, Pavel Emelyanov escreveu:
> Just like in the af_packet.c, the ipx_sock_nr variable is used
> for debugging purposes.
>
> Switch to using existing infrastructure. Thanks to Arnaldo for
> pointing this out.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
^ permalink raw reply
* Re: [PATCH][PACKET] Use existing sock refcnt debugging infrastructure
From: Arnaldo Carvalho de Melo @ 2007-11-09 14:37 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: David Miller, Arnaldo Carvalho de Melo, Linux Netdev List, devel
In-Reply-To: <4734631D.6080807@openvz.org>
Em Fri, Nov 09, 2007 at 04:39:41PM +0300, Pavel Emelyanov escreveu:
> The packet_socks_nr variable is used purely for debugging
> the number of sockets.
>
> As Arnaldo pointed out, there's already an infrastructure
> for this purposes, so switch to using it.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> ---
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 4cb2dfb..36331a5 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -139,9 +139,6 @@ dev->hard_header == NULL (ll header is added by device, we cannot control it)
> static HLIST_HEAD(packet_sklist);
> static DEFINE_RWLOCK(packet_sklist_lock);
>
> -static atomic_t packet_socks_nr;
> -
> -
> /* Private packet socket structures. */
>
> struct packet_mclist
> @@ -236,10 +233,7 @@ static void packet_sock_destruct(struct sock *sk)
> return;
> }
>
> - atomic_dec(&packet_socks_nr);
> -#ifdef PACKET_REFCNT_DEBUG
> - printk(KERN_DEBUG "PACKET socket %p is free, %d are alive\n", sk, atomic_read(&packet_socks_nr));
> -#endif
> + sk_refcnt_debug_dec(sk);
> }
>
>
> @@ -849,6 +843,7 @@ static int packet_release(struct socket *sock)
> /* Purge queues */
>
> skb_queue_purge(&sk->sk_receive_queue);
> + sk_refcnt_debug_release(sk);
>
> sock_put(sk);
> return 0;
> @@ -1010,7 +1005,7 @@ static int packet_create(struct net *net, struct socket *sock, int protocol)
> po->num = proto;
>
> sk->sk_destruct = packet_sock_destruct;
> - atomic_inc(&packet_socks_nr);
> + sk_refcnt_debug_inc(sk);
>
> /*
> * Attach a protocol block
> --
> 1.5.3.4
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Grant Likely @ 2007-11-09 13:57 UTC (permalink / raw)
To: Domen Puncer, Jeff Garzik; +Cc: Jon Smirl, PowerPC dev list, netdev
In-Reply-To: <20071109091245.GA3148@nd47.coderock.org>
On 11/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > This is the reason I couldn't get user space started or connect to my
> > nfs server. Patch is against current linus git.
> >
> > mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> > where the wrong skb buffer was being referenced.
> >
> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> Acked-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Jeff, can you please pick this up for .24?
Thanks,
g.
>
> I can't test it at the moment, but the patch is obviously correct,
> mapped buffer should be the _same_ as submitted.
>
> >
> > ---
> >
> > drivers/net/fec_mpc52xx.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> >
> > diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> > index a8a0ee2..ddfcc0b 100644
> > --- a/drivers/net/fec_mpc52xx.c
> > +++ b/drivers/net/fec_mpc52xx.c
> > @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > irq, void *dev_id)
> >
> > rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> > (struct bcom_bd **)&bd);
> > - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
> > + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
> >
> > /* Test for errors in received frame */
> > if (status & BCOM_FEC_RX_BD_ERRORS) {
> > @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > irq, void *dev_id)
> > bcom_prepare_next_buffer(priv->rx_dmatsk);
> >
> > bd->status = FEC_RX_BUFFER_SIZE;
> > - bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> > + bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> > FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> >
> > bcom_submit_next_buffer(priv->rx_dmatsk, skb);
> >
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
>
> --
> Domen Puncer | Research & Development
> .............................................................................................
> Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
> .............................................................................................
> www.telargo.com
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH][IPX] Use existing sock refcnt debugging infrastructure
From: Pavel Emelyanov @ 2007-11-09 13:42 UTC (permalink / raw)
To: David Miller; +Cc: Arnaldo Carvalho de Melo, Linux Netdev List, devel
Just like in the af_packet.c, the ipx_sock_nr variable is used
for debugging purposes.
Switch to using existing infrastructure. Thanks to Arnaldo for
pointing this out.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
index a195a66..c76a952 100644
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -92,11 +92,6 @@ extern int ipxrtr_route_skb(struct sk_buff *skb);
extern struct ipx_route *ipxrtr_lookup(__be32 net);
extern int ipxrtr_ioctl(unsigned int cmd, void __user *arg);
-#undef IPX_REFCNT_DEBUG
-#ifdef IPX_REFCNT_DEBUG
-atomic_t ipx_sock_nr;
-#endif
-
struct ipx_interface *ipx_interfaces_head(void)
{
struct ipx_interface *rc = NULL;
@@ -151,14 +146,7 @@ static void ipx_destroy_socket(struct sock *sk)
{
ipx_remove_socket(sk);
skb_queue_purge(&sk->sk_receive_queue);
-#ifdef IPX_REFCNT_DEBUG
- atomic_dec(&ipx_sock_nr);
- printk(KERN_DEBUG "IPX socket %p released, %d are still alive\n", sk,
- atomic_read(&ipx_sock_nr));
- if (atomic_read(&sk->sk_refcnt) != 1)
- printk(KERN_DEBUG "Destruction sock ipx %p delayed, cnt=%d\n",
- sk, atomic_read(&sk->sk_refcnt));
-#endif
+ sk_refcnt_debug_dec(sk);
sock_put(sk);
}
@@ -1384,11 +1372,8 @@ static int ipx_create(struct net *net, struct socket *sock, int protocol)
sk = sk_alloc(net, PF_IPX, GFP_KERNEL, &ipx_proto);
if (!sk)
goto out;
-#ifdef IPX_REFCNT_DEBUG
- atomic_inc(&ipx_sock_nr);
- printk(KERN_DEBUG "IPX socket %p created, now we have %d alive\n", sk,
- atomic_read(&ipx_sock_nr));
-#endif
+
+ sk_refcnt_debug_inc(sk);
sock_init_data(sock, sk);
sk->sk_no_check = 1; /* Checksum off by default */
sock->ops = &ipx_dgram_ops;
@@ -1409,6 +1394,7 @@ static int ipx_release(struct socket *sock)
sock_set_flag(sk, SOCK_DEAD);
sock->sk = NULL;
+ sk_refcnt_debug_release(sk);
ipx_destroy_socket(sk);
out:
return 0;
--
1.5.3.4
^ permalink raw reply related
* [PATCH][PACKET] Use existing sock refcnt debugging infrastructure
From: Pavel Emelyanov @ 2007-11-09 13:39 UTC (permalink / raw)
To: David Miller; +Cc: Arnaldo Carvalho de Melo, Linux Netdev List, devel
The packet_socks_nr variable is used purely for debugging
the number of sockets.
As Arnaldo pointed out, there's already an infrastructure
for this purposes, so switch to using it.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 4cb2dfb..36331a5 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -139,9 +139,6 @@ dev->hard_header == NULL (ll header is added by device, we cannot control it)
static HLIST_HEAD(packet_sklist);
static DEFINE_RWLOCK(packet_sklist_lock);
-static atomic_t packet_socks_nr;
-
-
/* Private packet socket structures. */
struct packet_mclist
@@ -236,10 +233,7 @@ static void packet_sock_destruct(struct sock *sk)
return;
}
- atomic_dec(&packet_socks_nr);
-#ifdef PACKET_REFCNT_DEBUG
- printk(KERN_DEBUG "PACKET socket %p is free, %d are alive\n", sk, atomic_read(&packet_socks_nr));
-#endif
+ sk_refcnt_debug_dec(sk);
}
@@ -849,6 +843,7 @@ static int packet_release(struct socket *sock)
/* Purge queues */
skb_queue_purge(&sk->sk_receive_queue);
+ sk_refcnt_debug_release(sk);
sock_put(sk);
return 0;
@@ -1010,7 +1005,7 @@ static int packet_create(struct net *net, struct socket *sock, int protocol)
po->num = proto;
sk->sk_destruct = packet_sock_destruct;
- atomic_inc(&packet_socks_nr);
+ sk_refcnt_debug_inc(sk);
/*
* Attach a protocol block
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:33 UTC (permalink / raw)
To: Kim Phillips; +Cc: Li Yang, Kumar Gala, netdev, linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071105121530.5c38fbb7.kim.phillips@freescale.com>
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> Hello all,
>
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below). Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
>
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me). I'm hoping they're
> trivial enough to go in 2.6.24.
All five patches are
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Let's hope they'll hit 2.6.24.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] ehea: Add kdump support
From: Thomas Klein @ 2007-11-09 13:33 UTC (permalink / raw)
To: Jeff Garzik
Cc: Christoph Raisch, Jan-Bernd Themann, linux-kernel, linux-ppc,
Marcus Eder, netdev, Stefan Roscher, Michael Ellermann,
Michael Neuling, Paul Mackerras
To support ehea driver reloading in a kdump kernel the driver has to perform
firmware handle deregistrations when the original kernel crashes. As there's
currently no notifier chain for machine crashes this patch enables kdump support
in the ehea driver by bending the ppc_md.machine_crash_shutdown hook to its own
machine crash handler. The original machine_crash_shutdown() fn is called
afterwards. This works fine as long as the ehea driver is the only one which
does so. Problems may occur if other drivers do the same and unload regularly.
This patch enables 2.6.24-rc2 to use kdump with ehea and only puts a very
low risk on base kernel. In 2.6.24 we know ehea is the only user of this
mechanism. The next step for 2.6.25 would be to add a proper notifier chain.
The full solution might be that register_reboot_notifier() provides sth
like a SYS_CRASH action. Please apply.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0080"
+#define DRV_VERSION "EHEA_0081"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..40a732e 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -37,6 +37,7 @@
#include <linux/reboot.h>
#include <net/ip.h>
+#include <asm-powerpc/machdep.h>
#include "ehea.h"
#include "ehea_qmr.h"
@@ -98,6 +99,7 @@ static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags = 0;
struct work_struct ehea_rereg_mr_task;
+static void (*orig_machine_crash_shutdown)(struct pt_regs *regs);
struct semaphore dlpar_mem_lock;
@@ -3312,6 +3314,29 @@ static struct notifier_block ehea_reboot_nb = {
.notifier_call = ehea_reboot_notifier,
};
+void ehea_crash_notifier(struct pt_regs *regs)
+{
+ ehea_info("Machine crash: freeing all eHEA resources");
+ ibmebus_unregister_driver(&ehea_driver);
+ orig_machine_crash_shutdown(regs);
+}
+
+void ehea_register_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ orig_machine_crash_shutdown =
+ (void*)__xchg_u64((unsigned long*)&ppc_md.machine_crash_shutdown,
+ (unsigned long)ehea_crash_notifier);
+#endif
+}
+
+void ehea_unregister_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ ppc_md.machine_crash_shutdown = orig_machine_crash_shutdown;
+#endif
+}
+
static int check_module_parm(void)
{
int ret = 0;
@@ -3369,6 +3394,7 @@ int __init ehea_module_init(void)
goto out;
register_reboot_notifier(&ehea_reboot_nb);
+ ehea_register_crash_notifier();
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
@@ -3382,6 +3408,7 @@ int __init ehea_module_init(void)
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ibmebus_unregister_driver(&ehea_driver);
goto out;
}
@@ -3396,6 +3423,7 @@ static void __exit ehea_module_exit(void)
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ehea_destroy_busmap();
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:25 UTC (permalink / raw)
To: Kim Phillips; +Cc: Li Yang, Kumar Gala, netdev, linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071108131135.e16a2f9a.kim.phillips@freescale.com>
On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote:
[...]
> right, but whether it does or not doesn't affect your failure outcome
> either I'm assuming.
>
> > > If it's something like 0x03, the u-boot patch will probably look like:
> > >
> > > if ((bcsr[12] == 0x10) &&
> > > (immr->sysconf.spridr == SPR_8360_REV21 ||
> > > immr->sysconf.spridr == SPR_8360E_REV21))
> > > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > > ...
> > >
> > > but these linux patches would remain the same (the clk and data delay
> > > settings for the UCC's are still valid; it's just the PHY config
> > > that is triggering your problem from what I can tell).
> >
> > Yup, most likely this is not UCC specific, but PHY. For some reason
> > delays making harm here...
And today I was unable to reproduce yesterday's behaviour. Your
patches works fine, with sixth patch and without it. With -rxid
and with just -id.
Though, after few resets I hit on that:
- - - -
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
Reset Status: External/Internal Soft, External/Internal Hard
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM: 256 MB (DDR2, 64-bit, ECC on)
SDRAM: 64 MB (local bus)
FLASH: 32 MB
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
FSL UEC0: Full Duplex
switching to rgmii 100
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
read wrong value : mii_id 1,mii_reg 2, base e0103120
read wrong value : mii_id 1,mii_reg 3, base e0103120
UEC: PHY is Generic MII (ffffffff)
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 5, base e0103120
FSL UEC1: Full Duplex
switching to rgmii 100
FSL UEC1: Speed 100BT
FSL UEC1: Link is up
FSL UEC0, FSL UEC1
- - - -
And UCC1 does not work at all. After another reset that message
disappears and it does work again.
So, I think hardware is tricking me in various ways, not your
patches fault.
:-(
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 4/4] Consolidate equal handlers in tunnel4.c
From: Pavel Emelyanov @ 2007-11-09 13:18 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
Two sets - tunnel[6]4_rcv() and tunnel[6]4_err - do the same
thing, but scan for different lists of tunnels, so this code
is easily consolidated.
Signed-off-by: Pavel Emelyanov <xemul@openvz.ogr>
---
diff --git a/net/ipv4/tunnel4.c b/net/ipv4/tunnel4.c
index b662a9e..c85547d 100644
--- a/net/ipv4/tunnel4.c
+++ b/net/ipv4/tunnel4.c
@@ -101,14 +101,14 @@ void iptunnel_xmit(struct sk_buff *skb, struct rtable *rt,
EXPORT_SYMBOL(iptunnel_xmit);
-static int tunnel4_rcv(struct sk_buff *skb)
+static int tunnel_rcv(struct xfrm_tunnel *handlers, struct sk_buff *skb)
{
struct xfrm_tunnel *handler;
if (!pskb_may_pull(skb, sizeof(struct iphdr)))
goto drop;
- for (handler = tunnel4_handlers; handler; handler = handler->next)
+ for (handler = handlers; handler; handler = handler->next)
if (!handler->handler(skb))
return 0;
@@ -119,43 +119,36 @@ drop:
return 0;
}
+static int tunnel4_rcv(struct sk_buff *skb)
+{
+ return tunnel_rcv(tunnel4_handlers, skb);
+}
+
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
static int tunnel64_rcv(struct sk_buff *skb)
{
- struct xfrm_tunnel *handler;
-
- if (!pskb_may_pull(skb, sizeof(struct iphdr)))
- goto drop;
-
- for (handler = tunnel64_handlers; handler; handler = handler->next)
- if (!handler->handler(skb))
- return 0;
-
- icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
-
-drop:
- kfree_skb(skb);
- return 0;
+ return tunnel_rcv(tunnel64_handlers, skb);
}
#endif
-static void tunnel4_err(struct sk_buff *skb, u32 info)
+static void tunnel_err(struct xfrm_tunnel *handlers, struct sk_buff *skb, u32 i)
{
struct xfrm_tunnel *handler;
- for (handler = tunnel4_handlers; handler; handler = handler->next)
- if (!handler->err_handler(skb, info))
+ for (handler = handlers; handler; handler = handler->next)
+ if (!handler->err_handler(skb, i))
break;
}
+static void tunnel4_err(struct sk_buff *skb, u32 info)
+{
+ tunnel_err(tunnel4_handlers, skb, info);
+}
+
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
static void tunnel64_err(struct sk_buff *skb, u32 info)
{
- struct xfrm_tunnel *handler;
-
- for (handler = tunnel64_handlers; handler; handler = handler->next)
- if (!handler->err_handler(skb, info))
- break;
+ tunnel_err(tunnel64_handlers, skb, info);
}
#endif
--
1.5.3.4
^ permalink raw reply related
* [PATCH 3/4] Cleanup the xfrm4_tunnel_(un)register
From: Pavel Emelyanov @ 2007-11-09 13:16 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
Both check for the family to select an appropriate tunnel list.
Consolidate this check and make the for() loop more readable.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv4/tunnel4.c b/net/ipv4/tunnel4.c
index 7938430..b662a9e 100644
--- a/net/ipv4/tunnel4.c
+++ b/net/ipv4/tunnel4.c
@@ -18,6 +18,11 @@ static struct xfrm_tunnel *tunnel4_handlers;
static struct xfrm_tunnel *tunnel64_handlers;
static DEFINE_MUTEX(tunnel4_mutex);
+static inline struct xfrm_tunnel **fam_handlers(unsigned short family)
+{
+ return (family == AF_INET) ? &tunnel4_handlers : &tunnel64_handlers;
+}
+
int xfrm4_tunnel_register(struct xfrm_tunnel *handler, unsigned short family)
{
struct xfrm_tunnel **pprev;
@@ -26,8 +31,7 @@ int xfrm4_tunnel_register(struct xfrm_tunnel *handler, unsigned short family)
mutex_lock(&tunnel4_mutex);
- for (pprev = (family == AF_INET) ? &tunnel4_handlers : &tunnel64_handlers;
- *pprev; pprev = &(*pprev)->next) {
+ for (pprev = fam_handlers(family); *pprev; pprev = &(*pprev)->next) {
if ((*pprev)->priority > priority)
break;
if ((*pprev)->priority == priority)
@@ -54,8 +58,7 @@ int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler, unsigned short family)
mutex_lock(&tunnel4_mutex);
- for (pprev = (family == AF_INET) ? &tunnel4_handlers : &tunnel64_handlers;
- *pprev; pprev = &(*pprev)->next) {
+ for (pprev = fam_handlers(family); *pprev; pprev = &(*pprev)->next) {
if (*pprev == handler) {
*pprev = handler->next;
ret = 0;
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/4] Add missed tunnel64_err handler
From: Pavel Emelyanov @ 2007-11-09 13:14 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
The tunnel64_protocol uses the tunnel4_protocol's err_handler and
thus calls the tunnel4_protocol's handlers.
This is not very good, as in case of (icmp) error the wrong error
handlers will be called (e.g. ipip ones instead of sit) and this
won't be noticed at all, because the error is not reported.
Was that made deliberately and I miss something?
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv4/tunnel4.c b/net/ipv4/tunnel4.c
index c71617c..7938430 100644
--- a/net/ipv4/tunnel4.c
+++ b/net/ipv4/tunnel4.c
@@ -145,6 +145,17 @@ static void tunnel4_err(struct sk_buff *skb, u32 info)
break;
}
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+static void tunnel64_err(struct sk_buff *skb, u32 info)
+{
+ struct xfrm_tunnel *handler;
+
+ for (handler = tunnel64_handlers; handler; handler = handler->next)
+ if (!handler->err_handler(skb, info))
+ break;
+}
+#endif
+
static struct net_protocol tunnel4_protocol = {
.handler = tunnel4_rcv,
.err_handler = tunnel4_err,
@@ -154,7 +165,7 @@ static struct net_protocol tunnel4_protocol = {
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
static struct net_protocol tunnel64_protocol = {
.handler = tunnel64_rcv,
- .err_handler = tunnel4_err,
+ .err_handler = tunnel64_err,
.no_policy = 1,
};
#endif
--
1.5.3.4
^ permalink raw reply related
* [PATCH 1/4] Un-define the IPTUNNEL_XMIT() macro
From: Pavel Emelyanov @ 2007-11-09 13:09 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
This one is used in all the smth-to-ip tunnels we have and
looks ... not very good. Make this a regular function in the
tunnel4.ko module.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/include/net/ipip.h b/include/net/ipip.h
index 7cdc914..bc8f4a1 100644
--- a/include/net/ipip.h
+++ b/include/net/ipip.h
@@ -25,23 +25,7 @@ struct ip_tunnel
struct ip_tunnel_parm parms;
};
-#define IPTUNNEL_XMIT() do { \
- int err; \
- int pkt_len = skb->len; \
- \
- skb->ip_summed = CHECKSUM_NONE; \
- iph->tot_len = htons(skb->len); \
- ip_select_ident(iph, &rt->u.dst, NULL); \
- ip_send_check(iph); \
- \
- err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev, dst_output);\
- if (net_xmit_eval(err) == 0) { \
- stats->tx_bytes += pkt_len; \
- stats->tx_packets++; \
- } else { \
- stats->tx_errors++; \
- stats->tx_aborted_errors++; \
- } \
-} while (0)
+void iptunnel_xmit(struct sk_buff *skb, struct rtable *rt,
+ struct net_device_stats *stats);
#endif
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 02b02a8..4fc19b3 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -882,7 +882,7 @@ static int ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
nf_reset(skb);
- IPTUNNEL_XMIT();
+ iptunnel_xmit(skb, rt, stats);
tunnel->recursion--;
return 0;
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 8c2b2b0..01f6d34 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -638,7 +638,7 @@ static int ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
nf_reset(skb);
- IPTUNNEL_XMIT();
+ iptunnel_xmit(skb, rt, stats);
tunnel->recursion--;
return 0;
diff --git a/net/ipv4/tunnel4.c b/net/ipv4/tunnel4.c
index a794a8c..c71617c 100644
--- a/net/ipv4/tunnel4.c
+++ b/net/ipv4/tunnel4.c
@@ -8,6 +8,7 @@
#include <linux/mutex.h>
#include <linux/netdevice.h>
#include <linux/skbuff.h>
+#include <linux/netfilter_ipv4.h>
#include <net/icmp.h>
#include <net/ip.h>
#include <net/protocol.h>
@@ -71,6 +72,32 @@ int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler, unsigned short family)
EXPORT_SYMBOL(xfrm4_tunnel_deregister);
+void iptunnel_xmit(struct sk_buff *skb, struct rtable *rt,
+ struct net_device_stats *stats)
+{
+ int err;
+ struct iphdr *iph = ip_hdr(skb);
+ int pkt_len = skb->len;
+
+ skb->ip_summed = CHECKSUM_NONE;
+ iph->tot_len = htons(skb->len);
+ ip_select_ident(iph, &rt->u.dst, NULL);
+ ip_send_check(iph);
+
+ err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL,
+ rt->u.dst.dev, dst_output);
+
+ if (net_xmit_eval(err) == 0) {
+ stats->tx_bytes += pkt_len;
+ stats->tx_packets++;
+ } else {
+ stats->tx_errors++;
+ stats->tx_aborted_errors++;
+ }
+}
+
+EXPORT_SYMBOL(iptunnel_xmit);
+
static int tunnel4_rcv(struct sk_buff *skb)
{
struct xfrm_tunnel *handler;
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 71433d2..49b30ca 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -579,7 +579,7 @@ static int ipip6_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
nf_reset(skb);
- IPTUNNEL_XMIT();
+ iptunnel_xmit(skb, rt, stats);
tunnel->recursion--;
return 0;
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 3/5] memory accounting
From: Herbert Xu @ 2007-11-09 13:07 UTC (permalink / raw)
To: Hideo AOKI
Cc: David Miller, netdev, Satoshi Oshima, Andi Kleen,
Stephen Hemminger, Evgeniy Polyakov, yoshfuji, Yumiko Sugita
In-Reply-To: <47264F49.90308@redhat.com>
On Mon, Oct 29, 2007 at 05:23:21PM -0400, Hideo AOKI wrote:
> This patch adds UDP memory usage accounting in IPv4.
>
> --
> Hideo Aoki
> Hitachi Computer Products (America) Inc.
>
> Signed-off-by: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
> Signed-off-by: Hideo Aoki <haoki@redhat.com>
This looks fine for now. Although in future I'd prefer this
to use the forward alloc model used by stream sockets. In fact
we should be able to share most of that code too.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
From: Ben Dooks @ 2007-11-09 12:06 UTC (permalink / raw)
To: Al Viro; +Cc: Magnus Damm, netdev, lethal, ben-linux, akpm, jeff, linux-arch
In-Reply-To: <20071108081854.GN8181@ftp.linux.org.uk>
On Thu, Nov 08, 2007 at 08:18:54AM +0000, Al Viro wrote:
> On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> > config AX88796
> > tristate "ASIX AX88796 NE2000 clone support"
> > - depends on ARM || MIPS
> > + depends on ARM || MIPS || SUPERH
>
> You know, that really sucks more and more. How about doing the following:
> a) making it depend on PLAT_HAS_AX88796
> b) adding selects for all subarchitectures that have the corresponding
> platform device
> and setting that as a uniform policy for platform drivers? For things like
> SM501 we would do
> config MFD_SM501
> depends on PCI || PLAT_HAS_SM501
> etc.
The PLAT_HAS_xxx method is nice, and I would like it applied to other places
in the kernel (see libata arugment below), and would have acked
this patch if it hadn't already been applied by Jeff.
The only reservation is that this doesn't show up the posibilty
of having the driver in the menuconfig, but anyone adding new
board support (should) be bright enough to look through the
Kconfig scripts before deciding they need to write an entirely
new driver.
I would note you may want to do PLAT_HAS_NET_AX88796 as there is
entirely a posibility of confusing this with the simple parallel
port driver which a board may not have support for.
> Seriously, folks, we are getting shitloads of platform drivers with no
> dependencies whatsoever, needed on a handful of targets and occasionally
> failing to build on unrelated architectures. Moreover, having a list
> of architectures in dependencies for each of those suckers is a PITA
> from the conflict POV. Not to mention platform drivers that fall into
> the mainline kernel with not a single platform device for them, etc.
There is a general problem with chicken-vs-egg here, how do you submit
support for a machine's platform device without the platform device
being there (and vice-versa) with seperate maintainers for network
and machine support?
One of my colleagues has passed along comments you made about a pair
of the simtec drivers (simtec-i2c and simtec-ide) which have been
added, but have no current users as patches have been stalled either
in submission process, or awaiting for an resolution. In the case
of simtec-ide, I would like to replace it with platform-ata, but
the libata maintainers seem wholy un-interested in
PLAT_HAS_PLATFORM_ATA or similar.
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
From: Ben Dooks @ 2007-11-09 12:08 UTC (permalink / raw)
To: Paul Mundt, Ralf Baechle, Al Viro, Magnus Damm, netdev, ben-linux
In-Reply-To: <20071109094023.GA7022@linux-sh.org>
On Fri, Nov 09, 2007 at 06:40:23PM +0900, Paul Mundt wrote:
> On Fri, Nov 09, 2007 at 09:26:52AM +0000, Ralf Baechle wrote:
> > If writesb() is not an official API then maybe the answer should have been
> > to either add that API to other architectures or fix the driver.
> >
> > I guess this incident means I need to go through all Kconfig* files to
> > see what bogus architecture dependencies on MIPS or !MIPS exist ...
> >
> While writesb() isn't an official API, the iowriteX_rep() interfaces
> theoretically are. Tidying up the driver for iomap is probably a better
> option.
If anyone else isn't interested in doing this, and there are
no objections to having it done, then I would be willing to
look at moving to the iowrite interfaces.
The only other way would be to add an 8/16bit configuration
to drop the use of writesb, as I belive most people connect
these devices in 16bit mode.
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [PATCH 2/5] accounting unit and variable
From: Herbert Xu @ 2007-11-09 12:34 UTC (permalink / raw)
To: Hideo AOKI
Cc: David Miller, netdev, Satoshi Oshima, Andi Kleen,
Stephen Hemminger, Evgeniy Polyakov, yoshfuji, Yumiko Sugita
In-Reply-To: <47264F3E.3080306@redhat.com>
On Mon, Oct 29, 2007 at 05:23:10PM -0400, Hideo AOKI wrote:
>
> +#define SK_DATAGRAM_MEM_QUANTUM ((int)PAGE_SIZE)
> +
> +static inline int sk_datagram_pages(int amt)
> +{
> + return DIV_ROUND_UP(amt, SK_DATAGRAM_MEM_QUANTUM);
> +}
Does this really have to be int? Unsigned would let the compiler
optimise this to a simple shift.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/5] fix send buffer check
From: Herbert Xu @ 2007-11-09 12:24 UTC (permalink / raw)
To: Hideo AOKI
Cc: David Miller, netdev, Satoshi Oshima, Andi Kleen,
Stephen Hemminger, Evgeniy Polyakov, yoshfuji, Yumiko Sugita
In-Reply-To: <47264F2D.3010105@redhat.com>
On Mon, Oct 29, 2007 at 05:22:53PM -0400, Hideo AOKI wrote:
> This patch introduces sndbuf size check before memory allocation for
> send buffer.
Looks good, what about IPv6?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
From: Russell King @ 2007-11-09 12:02 UTC (permalink / raw)
To: Paul Mundt, Ralf Baechle, Al Viro, Magnus Damm, netdev, ben-linux
In-Reply-To: <20071109094023.GA7022@linux-sh.org>
On Fri, Nov 09, 2007 at 06:40:23PM +0900, Paul Mundt wrote:
> On Fri, Nov 09, 2007 at 09:26:52AM +0000, Ralf Baechle wrote:
> > If writesb() is not an official API then maybe the answer should have been
> > to either add that API to other architectures or fix the driver.
> >
> > I guess this incident means I need to go through all Kconfig* files to
> > see what bogus architecture dependencies on MIPS or !MIPS exist ...
> >
> While writesb() isn't an official API, the iowriteX_rep() interfaces
> theoretically are. Tidying up the driver for iomap is probably a better
> option.
writesb() predates iowriteX_rep() interfaces by quite a number of years,
though if you're using writesb(), converting over to iowriteX_rep() is
really a no-brainer.
writesb() is effectively what mmio_outsb() is, and exists to do what
outsb() does but for peripherals mapped using ioremap on ARM rather
than trying to emulate them via the legacy x86 IO interfaces.
Note that it would've been far better that whoever invented mmio_outsb()
looked around and noticed that some of us already have an implementation
called writesb()... but time has proven that folk seem to be blinkered
to anything not x86.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2007-11-09 11:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, netdev, jgarzik
In-Reply-To: <47336F9D.8060405@freescale.com>
Am Donnerstag, den 08.11.2007, 14:20 -0600 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > If both mdio and mdc controlling pins are on the same processor port,
> > one resource should be used.
> > Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.
>
> How about:
> The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg resource, it is used for
> both MDIO and MDC.
>
Ok.
> We also need to change the reference to port C in fsl,mdio-pin and
> fsl,mdc-pin.
Do you mean this:
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
-> fsl,cpm2-mdio-bitbang (reg is port C registers)
Properties for fsl,cpm2-mdio-bitbang:
-> fsl,mdio-pin : pin of port C controlling mdio data
-> fsl,mdc-pin : pin of port C controlling mdio clock
Right. But i thought it would be related to the example,
and than the reader gets the short comment about I/O ports.
Or the other variant would be:
--------------------
iv) MDIO
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
fsl,cpm2-mdio-bitbang (reg is the I/O port register block(s))
Properties for fsl,cpm2-mdio-bitbang:
The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC.
fsl,mdio-pin : pin of chosen port for controlling mdio data
fsl,mdc-pin : pin of chosen port for controlling mdio clock
Example:
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <12>;
fsl,mdc-pin = <13>;
};
-----------------
Regards
Sergej.
^ permalink raw reply
* Re: [PATCH 1/1]: Using ICMP type and code in xfrm selector
From: Herbert Xu @ 2007-11-09 11:29 UTC (permalink / raw)
To: Joy Latten; +Cc: netdev, davem, tgraf
In-Reply-To: <200711022317.lA2NHeX2018386@faith.austin.ibm.com>
On Fri, Nov 02, 2007 at 06:17:40PM -0500, Joy Latten wrote:
>
> While fixing this I wondered why we put icmp message
> type in sport and code in dport?
Where we put the info in the kernel is not specified by the
RFC. It has to document where you put it in IKE because IKE
is used by two systems which must agree on one format.
Your patch looks OK to me but in general we want to encourage
applications to use the xfrm_user interface as pf_key is not
portable anyway because of the lack of a standard specification
that covers the SPD.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
From: Paul Mundt @ 2007-11-09 9:40 UTC (permalink / raw)
To: Ralf Baechle
Cc: Al Viro, Magnus Damm, netdev, ben-linux, akpm, jeff, linux-arch
In-Reply-To: <20071109092652.GA13350@linux-mips.org>
On Fri, Nov 09, 2007 at 09:26:52AM +0000, Ralf Baechle wrote:
> If writesb() is not an official API then maybe the answer should have been
> to either add that API to other architectures or fix the driver.
>
> I guess this incident means I need to go through all Kconfig* files to
> see what bogus architecture dependencies on MIPS or !MIPS exist ...
>
While writesb() isn't an official API, the iowriteX_rep() interfaces
theoretically are. Tidying up the driver for iomap is probably a better
option.
^ permalink raw reply
* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
From: Ralf Baechle @ 2007-11-09 9:26 UTC (permalink / raw)
To: Al Viro; +Cc: Magnus Damm, netdev, lethal, ben-linux, akpm, jeff, linux-arch
In-Reply-To: <20071108081854.GN8181@ftp.linux.org.uk>
On Thu, Nov 08, 2007 at 08:18:54AM +0000, Al Viro wrote:
> On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> > config AX88796
> > tristate "ASIX AX88796 NE2000 clone support"
> > - depends on ARM || MIPS
> > + depends on ARM || MIPS || SUPERH
>
> You know, that really sucks more and more. How about doing the following:
> a) making it depend on PLAT_HAS_AX88796
> b) adding selects for all subarchitectures that have the corresponding
> platform device
> and setting that as a uniform policy for platform drivers? For things like
> SM501 we would do
> config MFD_SM501
> depends on PCI || PLAT_HAS_SM501
> etc.
>
> Seriously, folks, we are getting shitloads of platform drivers with no
> dependencies whatsoever, needed on a handful of targets and occasionally
> failing to build on unrelated architectures. Moreover, having a list
> of architectures in dependencies for each of those suckers is a PITA
> from the conflict POV. Not to mention platform drivers that fall into
> the mainline kernel with not a single platform device for them, etc.
>
> Comments?
commit def47c5095d53814512bb0c62ec02dfdec769db1
Author: Jeff Garzik <jeff@garzik.org>
Date: Tue Jul 10 14:06:48 2007 -0400
[netdrvr] Fix dependencies for ax88796 ne2k clone driver
It needs writesb(), not available on all platforms.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index a3bef22..a64c2fb 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -199,6 +199,7 @@ source "drivers/net/arm/Kconfig"
config AX88796
tristate "ASIX AX88796 NE2000 clone support"
+ depends on ARM || MIPS
select CRC32
select MII
help
If writesb() is not an official API then maybe the answer should have been
to either add that API to other architectures or fix the driver.
I guess this incident means I need to go through all Kconfig* files to
see what bogus architecture dependencies on MIPS or !MIPS exist ...
Ralf
^ permalink raw reply related
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Domen Puncer @ 2007-11-09 9:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Grant Likely, netdev
In-Reply-To: <9e4733910711082131v70c4b7bm2b00445b7e62c33f@mail.gmail.com>
On 09/11/07 00:31 -0500, Jon Smirl wrote:
> This is the reason I couldn't get user space started or connect to my
> nfs server. Patch is against current linus git.
>
> mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> where the wrong skb buffer was being referenced.
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Acked-by: Domen Puncer <domen.puncer@telargo.com>
I can't test it at the moment, but the patch is obviously correct,
mapped buffer should be the _same_ as submitted.
>
> ---
>
> drivers/net/fec_mpc52xx.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index a8a0ee2..ddfcc0b 100644
> --- a/drivers/net/fec_mpc52xx.c
> +++ b/drivers/net/fec_mpc52xx.c
> @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
>
> rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> (struct bcom_bd **)&bd);
> - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
> + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
>
> /* Test for errors in received frame */
> if (status & BCOM_FEC_RX_BD_ERRORS) {
> @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
> bcom_prepare_next_buffer(priv->rx_dmatsk);
>
> bd->status = FEC_RX_BUFFER_SIZE;
> - bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> + bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
>
> bcom_submit_next_buffer(priv->rx_dmatsk, skb);
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
--
Domen Puncer | Research & Development
.............................................................................................
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.............................................................................................
www.telargo.com
^ permalink raw reply
* [PATCH] [AF_PACKET] Fix minor code duplication
From: Urs Thuermann @ 2007-11-09 7:06 UTC (permalink / raw)
To: netdev
Simplify some code by eliminating duplicate if-else clauses in
packet_do_bind().
Signed-off-by: Urs Thuermann <urs@isnogud.escape.de>
--- net-2.6/net/packet/af_packet.c.orig 2007-11-05 13:07:28.000000000 +0100
+++ net-2.6/net/packet/af_packet.c 2007-11-08 12:14:25.000000000 +0100
@@ -886,20 +886,14 @@ static int packet_do_bind(struct sock *s
if (protocol == 0)
goto out_unlock;
- if (dev) {
- if (dev->flags&IFF_UP) {
- dev_add_pack(&po->prot_hook);
- sock_hold(sk);
- po->running = 1;
- } else {
- sk->sk_err = ENETDOWN;
- if (!sock_flag(sk, SOCK_DEAD))
- sk->sk_error_report(sk);
- }
- } else {
+ if (!dev || (dev->flags & IFF_UP)) {
dev_add_pack(&po->prot_hook);
sock_hold(sk);
po->running = 1;
+ } else {
+ sk->sk_err = ENETDOWN;
+ if (!sock_flag(sk, SOCK_DEAD))
+ sk->sk_error_report(sk);
}
out_unlock:
^ permalink raw reply
* [2.6 patch] remove references to net-modules.txt
From: Adrian Bunk @ 2007-11-09 6:01 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
When I removed net-modules.txt because it only contained ancient
information I missed that many Kconfig entries pointed to this ancient
information.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
Documentation/networking/3c505.txt | 3
drivers/net/Kconfig | 199 ++++++++++-------------------
drivers/net/arcnet/Kconfig | 15 --
drivers/net/tulip/Kconfig | 21 +--
4 files changed, 82 insertions(+), 156 deletions(-)
6451db6bafae46e17885b8c7b243095fc257e8ed
diff --git a/Documentation/networking/3c505.txt b/Documentation/networking/3c505.txt
index b9d5b72..72f38b1 100644
--- a/Documentation/networking/3c505.txt
+++ b/Documentation/networking/3c505.txt
@@ -14,8 +14,7 @@ If no base address is given at boot time, the driver will autoprobe
ports 0x300, 0x280 and 0x310 (in that order). If no IRQ is given, the driver
will try to probe for it.
-The driver can be used as a loadable module. See net-modules.txt for details
-of the parameters it can take.
+The driver can be used as a loadable module.
Theoretically, one instance of the driver can now run multiple cards,
in the standard way (when loading a module, say "modprobe 3c505
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 5f800a6..0fdcf72 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -365,8 +365,7 @@ config MAC89x0
read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. This module will
+ To compile this driver as a module, choose M here. This module will
be called mac89x0.
config MACSONIC
@@ -379,8 +378,7 @@ config MACSONIC
one of these say Y and read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. This module will
+ To compile this driver as a module, choose M here. This module will
be called macsonic.
config MACMACE
@@ -618,8 +616,7 @@ config EL1
have problems. Some people suggest to ping ("man ping") a nearby
machine every minute ("man cron") when using this card.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called 3c501.
config EL2
@@ -631,8 +628,7 @@ config EL2
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called 3c503.
config ELPLUS
@@ -644,8 +640,7 @@ config ELPLUS
this type, say Y and read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called 3c505.
config EL16
@@ -656,8 +651,7 @@ config EL16
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called 3c507.
config EL3
@@ -672,8 +666,7 @@ config EL3
setup disk to disable Plug & Play mode, and to select the default
media type.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called 3c509.
config 3C515
@@ -684,8 +677,7 @@ config 3C515
network card, say Y and read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called 3c515.
config ELMC
@@ -696,8 +688,7 @@ config ELMC
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called 3c523.
config ELMC_II
@@ -708,8 +699,7 @@ config ELMC_II
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called 3c527.
config VORTEX
@@ -732,8 +722,7 @@ config VORTEX
<file:Documentation/networking/vortex.txt> and in the comments at
the beginning of <file:drivers/net/3c59x.c>.
- To compile this support as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>.
+ To compile this support as a module, choose M here.
config TYPHOON
tristate "3cr990 series \"Typhoon\" support"
@@ -750,8 +739,7 @@ config TYPHOON
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called typhoon.
config LANCE
@@ -788,8 +776,7 @@ config WD80x3
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called wd.
config ULTRAMCA
@@ -801,8 +788,7 @@ config ULTRAMCA
an MCA based system (PS/2), say Y and read the Ethernet-HOWTO,
available from <http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called smc-mca.
config ULTRA
@@ -821,8 +807,7 @@ config ULTRA
this but keep it in mind if you have such a SCSI card and have
problems.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called smc-ultra.
config ULTRA32
@@ -834,8 +819,7 @@ config ULTRA32
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called smc-ultra32.
config BFIN_MAC
@@ -896,8 +880,7 @@ config SMC9194
<file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
available from <http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called smc9194.
config SMC91X
@@ -915,8 +898,7 @@ config SMC91X
This driver is also available as a module ( = code which can be
inserted in and removed from the running kernel whenever you want).
The module will be called smc91x. If you want to compile it as a
- module, say M here and read <file:Documentation/kbuild/modules.txt>
- as well as <file:Documentation/networking/net-modules.txt>.
+ module, say M here and read <file:Documentation/kbuild/modules.txt>.
config NET_NETX
tristate "NetX Ethernet support"
@@ -925,8 +907,7 @@ config NET_NETX
help
This is support for the Hilscher netX builtin Ethernet ports
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called netx-eth.
config DM9000
@@ -937,9 +918,8 @@ config DM9000
---help---
Support for DM9000 chipset.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will be
- called dm9000.
+ To compile this driver as a module, choose M here. The module
+ will be called dm9000.
config SMC911X
tristate "SMSC LAN911[5678] support"
@@ -979,8 +959,7 @@ config NI5010
<http://www.tldp.org/docs.html#howto>. Note that this is still
experimental code.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ni5010.
config NI52
@@ -991,8 +970,7 @@ config NI52
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ni52.
config NI65
@@ -1003,8 +981,7 @@ config NI65
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ni65.
source "drivers/net/tulip/Kconfig"
@@ -1018,8 +995,7 @@ config AT1700
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called at1700.
config DEPCA
@@ -1032,8 +1008,7 @@ config DEPCA
<http://www.tldp.org/docs.html#howto> as well as
<file:drivers/net/depca.c>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called depca.
config HP100
@@ -1044,8 +1019,7 @@ config HP100
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called hp100.
config NET_ISA
@@ -1074,8 +1048,7 @@ config E2100
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called e2100.
config EWRK3
@@ -1089,8 +1062,7 @@ config EWRK3
well as the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ewrk3.
config EEXPRESS
@@ -1104,8 +1076,7 @@ config EEXPRESS
because the driver was very unreliable. We now have a new driver
that should do better.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called eexpress.
config EEXPRESS_PRO
@@ -1118,8 +1089,7 @@ config EEXPRESS_PRO
driver. Please read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called eepro.
config HPLAN_PLUS
@@ -1131,8 +1101,7 @@ config HPLAN_PLUS
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called hp-plus.
config HPLAN
@@ -1144,8 +1113,7 @@ config HPLAN
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called hp.
config LP486E
@@ -1164,8 +1132,7 @@ config ETH16I
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called eth16i.
config NE2000
@@ -1185,8 +1152,7 @@ config NE2000
laptops), say N here and Y to "NE/2 (ne2000 MCA version) support",
below.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ne.
config ZNET
@@ -1207,8 +1173,7 @@ config SEEQ8005
is for you, read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called seeq8005.
config NE2_MCA
@@ -1220,8 +1185,7 @@ config NE2_MCA
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ne2.
config IBMLANA
@@ -1232,8 +1196,7 @@ config IBMLANA
CONFIG_MCA to use this driver. It is both available as an in-kernel
driver and as a module.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The only
+ To compile this driver as a module, choose M here. The only
currently supported card is the IBM LAN Adapter/A for Ethernet. It
will both support 16K and 32K memory windows, however a 32K window
gives a better security against packet losses. Usage of multiple
@@ -1247,8 +1210,7 @@ config IBMVETH
This driver supports virtual ethernet adapters on newer IBM iSeries
and pSeries systems.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called ibmveth.
source "drivers/net/ibm_emac/Kconfig"
@@ -1278,8 +1240,7 @@ config PCNET32
answer Y here and read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called pcnet32.
config PCNET32_NAPI
@@ -1306,8 +1267,7 @@ config AMD8111_ETH
answer Y here and read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called amd8111e.
config AMD8111E_NAPI
@@ -1361,8 +1321,7 @@ config AC3200
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ac3200.
config APRICOT
@@ -1373,9 +1332,8 @@ config APRICOT
read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will be
- called apricot.
+ To compile this driver as a module, choose M here. The module
+ will be called apricot.
config B44
tristate "Broadcom 440x/47xx ethernet support"
@@ -1387,9 +1345,8 @@ config B44
or M and read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will be
- called b44.
+ To compile this driver as a module, choose M here. The module
+ will be called b44.
# Auto-select SSB PCI-HOST support, if possible
config B44_PCI_AUTOSELECT
@@ -1418,9 +1375,8 @@ config FORCEDETH
read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will be
- called forcedeth.
+ To compile this driver as a module, choose M here. The module
+ will be called forcedeth.
config FORCEDETH_NAPI
bool "Use Rx Polling (NAPI) (EXPERIMENTAL)"
@@ -1446,9 +1402,8 @@ config CS89x0
<http://www.tldp.org/docs.html#howto> as well as
<file:Documentation/networking/cs89x0.txt>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will be
- called cs89x0.
+ To compile this driver as a module, choose M here. The module
+ will be called cs89x0.
config TC35815
tristate "TOSHIBA TC35815 Ethernet support"
@@ -1464,8 +1419,7 @@ config EEPRO100
card, say Y and read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called eepro100.
@@ -1492,8 +1446,7 @@ config E100
More specific information on configuring the driver is in
<file:Documentation/networking/e100.txt>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called e100.
config LNE390
@@ -1505,8 +1458,7 @@ config LNE390
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called lne390.
config FEALNX
@@ -1546,8 +1498,7 @@ config NE2K_PCI
NetVin NV5000SC Via 86C926 SureCom NE34 Winbond
Holtek HT80232 Holtek HT80229
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ne2k-pci.
config NE3210
@@ -1560,8 +1511,7 @@ config NE3210
<http://www.tldp.org/docs.html#howto>. Note that this driver
will NOT WORK for NE3200 cards as they are completely different.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ne3210.
config ES3210
@@ -1573,8 +1523,7 @@ config ES3210
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called es3210.
config 8139CP
@@ -1704,8 +1653,7 @@ config TLAN
Compaq NetFlex and Olicom cards. Please read the file
<file:Documentation/networking/tlan.txt> for more details.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called tlan.
Please email feedback to <torben.mathiasen@compaq.com>.
@@ -1995,8 +1943,7 @@ config E1000
More specific information on configuring the driver is in
<file:Documentation/networking/e1000.txt>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called e1000.
config E1000_NAPI
@@ -2041,8 +1988,7 @@ config E1000E
More specific information on configuring the driver is in
<file:Documentation/networking/e1000e.txt>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called e1000e.
source "drivers/net/ixp2000/Kconfig"
@@ -2075,8 +2021,7 @@ config HAMACHI
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will be
+ To compile this driver as a module, choose M here. The module will be
called hamachi.
config YELLOWFIN
@@ -2525,8 +2470,7 @@ config IXGBE
More specific information on configuring the driver is in
<file:Documentation/networking/ixgbe.txt>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ixgbe.
config IXGB
@@ -2548,8 +2492,7 @@ config IXGB
More specific information on configuring the driver is in
<file:Documentation/networking/ixgb.txt>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called ixgb.
config IXGB_NAPI
@@ -2602,8 +2545,7 @@ config MYRI10GE
<http://www.myri.com/scs/download-Myri10GE.html>
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called myri10ge.
config NETXEN_NIC
@@ -2827,10 +2769,9 @@ config PLIP
with the PLIP support in Linux versions 1.0.x. This option enlarges
your kernel by about 8 KB.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will be
- called plip. If unsure, say Y or M, in case you buy a laptop
- later.
+ To compile this driver as a module, choose M here. The module
+ will be called plip. If unsure, say Y or M, in case you buy
+ a laptop later.
config PPP
tristate "PPP (point-to-point protocol) support"
@@ -2860,8 +2801,7 @@ config PPP
If you said Y to "Version information on all symbols" above, then
you cannot compile the PPP driver into the kernel; you can then only
compile it as a module. To compile this driver as a module, choose M
- here and read <file:Documentation/networking/net-modules.txt>.
- The module will be called ppp_generic.
+ here. The module will be called ppp_generic.
config PPP_MULTILINK
bool "PPP multilink support (EXPERIMENTAL)"
@@ -3022,9 +2962,8 @@ config SLIP
<http://www.bart.nl/~patrickr/term-howto/Term-HOWTO.html>). SLIP
support will enlarge your kernel by about 4 KB. If unsure, say N.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will be
- called slip.
+ To compile this driver as a module, choose M here. The module
+ will be called slip.
config SLIP_COMPRESSED
bool "CSLIP compressed headers"
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index 4030274..3b2f7f1 100644
--- a/drivers/net/arcnet/Kconfig
+++ b/drivers/net/arcnet/Kconfig
@@ -19,8 +19,7 @@ menuconfig ARCNET
from <http://www.tldp.org/docs.html#howto>(even though ARCnet
is not really Ethernet).
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called arcnet.
if ARCNET
@@ -81,8 +80,7 @@ config ARCNET_COM90xx
have always used the old ARCnet driver without knowing what type of
card you had, this is probably the one for you.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called com90xx.
config ARCNET_COM90xxIO
@@ -93,8 +91,7 @@ config ARCNET_COM90xxIO
the normal driver. Only use it if your card doesn't support shared
memory.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called com90io.
config ARCNET_RIM_I
@@ -105,8 +102,7 @@ config ARCNET_RIM_I
driver is completely untested, so if you have one of these cards,
please mail <dwmw2@infradead.org>, especially if it works!
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called arc-rimi.
config ARCNET_COM20020
@@ -116,8 +112,7 @@ config ARCNET_COM20020
things as promiscuous mode, so packet sniffing is possible, and
extra diagnostic information.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called com20020.
config ARCNET_COM20020_ISA
diff --git a/drivers/net/tulip/Kconfig b/drivers/net/tulip/Kconfig
index 49d7a29..20ac150 100644
--- a/drivers/net/tulip/Kconfig
+++ b/drivers/net/tulip/Kconfig
@@ -24,8 +24,7 @@ config DE2104X
will say Y here.) Do read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called de2104x.
config TULIP
@@ -42,8 +41,7 @@ config TULIP
will say Y here.) Do read the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called tulip.
config TULIP_MWI
@@ -104,8 +102,7 @@ config DE4X5
information is contained in
<file:Documentation/networking/de4x5.txt>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called de4x5.
config WINBOND_840
@@ -129,8 +126,7 @@ config DM9102
(Ethernet) card, say Y. Some information is contained in the file
<file:Documentation/networking/dmfe.txt>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called dmfe.
config ULI526X
@@ -141,8 +137,7 @@ config ULI526X
This driver is for ULi M5261/M5263 10/100M Ethernet Controller
(<http://www.uli.com.tw/>).
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called uli526x.
config PCMCIA_XIRCOM
@@ -154,8 +149,7 @@ config PCMCIA_XIRCOM
as with work-alike chips from Lite-On (PNIC) and Macronix (MXIC) and
ASIX.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called xircom_cb. If unsure, say N.
config PCMCIA_XIRTULIP
@@ -168,8 +162,7 @@ config PCMCIA_XIRTULIP
as with work-alike chips from Lite-On (PNIC) and Macronix (MXIC) and
ASIX.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will
+ To compile this driver as a module, choose M here. The module will
be called xircom_tulip_cb. If unsure, say N.
endif # NET_TULIP
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox