* Re: [PATCH] Documentation, clarify tuntap IPX example.
From: andrew hendry @ 2009-11-18 9:03 UTC (permalink / raw)
To: Max Krasnyansky; +Cc: netdev@vger.kernel.org, linux-kernel
In-Reply-To: <4B038BB7.2050902@qualcomm.com>
Hi Max,
Thanks. TUNSETLINK looks like exactly what I need.
I'll have to have a closer look at kernel x.25 next, i don't think it
likes the tunx25 going away with routes still too it.
deb32:~# cat /proc/net/x25/route
Address Digits Device
000000000000000 0 @�\x18��
\x18�@�\x1d
[ 662.425648] BUG: unable to handle kernel NULL pointer dereference at 00000017
[ 662.426291] IP: [<c10b5908>] dup_fd+0x21f/0x2fa
[ 662.427849] *pde = 00000000
[ 662.428028] Oops: 0002 [#1] SMP
[ 662.428028] last sysfs file: /sys/class/net/lo/operstate
[ 662.428028] Modules linked in: x25 tun ipv6 loop ac button
parport_pc parport snd_pcm snd_timer serio_raw psmouse snd soundcore
snd_page_alloc pcspkr i2c_piix4 i2c_core evdev ext3 jbd mbcache
ide_cd_mod cdrom ide_gd_mod ata_generic ata_piix libata scsi_mod
ide_pci_generic piix floppy pcnet32 mii ide_core thermal fan
thermal_sys [last unloaded: tun]
[ 662.428028]
[ 662.428028] Pid: 12252, comm: net.agent Not tainted (2.6.31.6 #1) VirtualBox
[ 662.428028] EIP: 0060:[<c10b5908>] EFLAGS: 00010286 CPU: 0
[ 662.428028] EIP is at dup_fd+0x21f/0x2fa
[ 662.428028] EAX: 00000017 EBX: ce5262a0 ECX: 00000220 EDX: ffffffff
[ 662.428028] ESI: 00000088 EDI: ce41e400 EBP: 00000100 ESP: c2849eec
[ 662.428028] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
[ 662.428028] Process net.agent (pid: 12252, ti=c2848000
task=ce9d51c0 task.ti=c2848000)
[ 662.428028] Stack:
[ 662.428028] 00000202 00000020 00000008 cf466cc0 cf466cc4 cf4667c0
ce41e400 00000078
[ 662.428028] <0> ce5262c0 cf466d00 cf4667c8 ce02bc00 ce18db60
00000000 00000000 ce9d51c0
[ 662.428028] <0> c102d03b 080a8120 cf649668 c2849fb4 bfe05a6c
01200011 ce18dca4 fffffff4
[ 662.428028] Call Trace:
[ 662.428028] [<c102d03b>] ? copy_process+0x469/0xf96
[ 662.428028] [<c102dc7d>] ? do_fork+0x115/0x282
[ 662.428028] [<c10a4965>] ? vfs_llseek+0x30/0x34
[ 662.428028] [<c1001d8e>] ? sys_clone+0x21/0x27
[ 662.428028] [<c10030c9>] ? syscall_call+0x7/0xb
[ 662.428028] Code: 4c 24 08 8b 70 08 f3 a5 8b 4c 24 04 83 e1 03 74
02 f3 a4 31 c9 31 f6 89 6c 24 1c eb 29 8b 7c 24 18 8b 14 0f 85 d2 74
09 8d 42 18 <3e> ff 42 18 eb 06 8b 43 0c 0f b3 30 8b 44 24 2c 46 89 14
08 83
[ 662.428028] EIP: [<c10b5908>] dup_fd+0x21f/0x2fa SS:ESP 0069:c2849eec
[ 662.428028] CR2: 0000000000000017
[ 662.452941] ---[ end trace aab1610cb3ca8b89 ]---
Message from syslogd@deb32 at Nov 19 06:58:56 ...
kernel:[ 904.324109] unregister_netdevice: waiting for xotdtun to
become free. Usage count = -3
Andrew
On Wed, Nov 18, 2009 at 4:52 PM, Max Krasnyansky <maxk@qualcomm.com> wrote:
> andrew hendry wrote:
>> Hi Max,
>>
>> I started looking through the documentation because im looking to use
>> tun for X.25 over TCP. The IPX example sounded similar but i couldn't
>> get it to work as I was expecting. Looking for a hint in the right
>> direction.
> Ah, X25 is different.
>
>> There is an old non-mainline patch called x25tap (clone of obsolete
>> ethertap). I'm hoping to replace x25tap with tun.
>>
>> The old x25tap creates a device like:
>> x25tap0 Link encap:generic X.25 HWaddr
>> UP BROADCAST RUNNING NOARP MULTICAST MTU:1024 Metric:1
>> RX packets:3040785 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:2895530 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:10
>> RX bytes:138787339 (132.3 Mb) TX bytes:91395983 (87.1 Mb)
>> When the x25tap is loaded it has dev->type = ARPHRD_X25, after which
>> x.25 routing and AF_X25 sockets can be created. Along with an XoT
>> userspace program which handles some basic headers and TCP port 1998
>> it works well.
>>
>> If using tun, how does something get registered to handle protocol AF_X25?
>>
>
> I've never tried this personally so ... :). But I just glanced over net/ax25
> and drivers/wan/ax25 and it looks TUNSETLINK might work for you.
> In other words you want to allocate TUN device (not TAP) and then call
> TUNSETLINK with ARPHRD_X25. Seems like you'll get exactly what you need.
>
> Max
>
>
>> Regards,
>> Andrew.
>>
>> On Wed, Nov 18, 2009 at 12:40 PM, Max Krasnyansky <maxk@qualcomm.com> wrote:
>>> On 11/17/2009 05:30 PM, andrew hendry wrote:
>>>> Can the TUNSETIFF ioctl change a tap's protocol to IPX as the
>>>> documentation suggests?
>>>> I think tun.c would need IFF_IPX_TAP added for it to work as described?
>>>> Otherwise tap can only be ptp or ethernet, and there is no way to
>>>> route or use AF_IPX.
>>> TAP is an Ethernet device. No special handling is required for IPX or for
>>> that matter any other protocol. Example seems fine too.
>>>
>>> Max
>>>
>>>> Signed-off-by: Andrew Hendry<andrew.hendry@gmail.com>
>>>>
>>>> --- a/Documentation/networking/tuntap.txt 2009-11-11
>>>> 14:03:22.676167648 +1100
>>>> +++ b/Documentation/networking/tuntap.txt 2009-11-18
>>>> 11:34:18.106647029 +1100
>>>> @@ -127,12 +127,14 @@ Ethernet device, which instead of receiv
>>>> media, receives them from user space program and instead of sending
>>>> packets via physical media sends them to the user space program.
>>>>
>>>> -Let's say that you configured IPX on the tap0, then whenever
>>>> -the kernel sends an IPX packet to tap0, it is passed to the application
>>>> -(VTun for example). The application encrypts, compresses and sends it to
>>>> -the other side over TCP or UDP. The application on the other side
>>>> decompresses
>>>> -and decrypts the data received and writes the packet to the TAP device,
>>>> -the kernel handles the packet like it came from real physical device.
>>>> +Let's say for the purpose of example, IPX support was added to tuntap.
>>>> +Then whenever the kernel routes an IPX packet to tap0, it is passed to
>>>> the
>>>> +application reading the file descriptor from /dev/net/tun (VTun for
>>>> example).
>>>> +The application encrypts, compresses and sends it to the other side over
>>>> TCP
>>>> +or UDP. The application on the other side decompresses and decrypts the
>>>> data
>>>> +received and writes the packet to the TAP device, the remote kernel
>>>> handles
>>>> +the packet like it came from real physical device. The IPX applications
>>>> are
>>>> +able to communicate as if there was a real IPX network.
>>>>
>>>> 4. What is the difference between TUN driver and TAP driver?
>>>> TUN works with IP frames. TAP works with Ethernet frames.
>>>
>
>
^ permalink raw reply
* [PATCH 2/3] TI Davinci EMAC : add platform specific interrupt enable/disable logic.
From: Sriramakrishnan @ 2009-11-18 9:42 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, Sriramakrishnan
In-Reply-To: <1258537328-31527-2-git-send-email-srk@ti.com>
On certain SOCs, the EMAC controller is interfaced with a wrapper logic
for handling interrupts. This patch implements a platform
specific hook to cater to platforms that require custom interrupt
handling logic
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
---
drivers/net/davinci_emac.c | 11 +++++++++++
include/linux/davinci_emac.h | 2 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 6aec8f5..81931f8 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -487,6 +487,9 @@ struct emac_priv {
struct mii_bus *mii_bus;
struct phy_device *phydev;
spinlock_t lock;
+ /*platform specific members*/
+ void (*wrapper_int_enable) (void);
+ void (*wrapper_int_disable) (void);
};
/* clock frequency for EMAC */
@@ -1001,6 +1004,8 @@ static void emac_int_disable(struct emac_priv *priv)
emac_ctrl_write(EMAC_DM646X_CMRXINTEN, 0x0);
emac_ctrl_write(EMAC_DM646X_CMTXINTEN, 0x0);
/* NOTE: Rx Threshold and Misc interrupts are not disabled */
+ if (priv->wrapper_int_disable)
+ priv->wrapper_int_disable();
local_irq_restore(flags);
@@ -1020,6 +1025,9 @@ static void emac_int_disable(struct emac_priv *priv)
static void emac_int_enable(struct emac_priv *priv)
{
if (priv->version == EMAC_VERSION_2) {
+ if (priv->wrapper_int_enable)
+ priv->wrapper_int_enable();
+
emac_ctrl_write(EMAC_DM646X_CMRXINTEN, 0xff);
emac_ctrl_write(EMAC_DM646X_CMTXINTEN, 0xff);
@@ -2662,6 +2670,9 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
priv->phy_mask = pdata->phy_mask;
priv->rmii_en = pdata->rmii_en;
priv->version = pdata->version;
+ priv->wrapper_int_enable = pdata->wrapper_interrupt_enable;
+ priv->wrapper_int_disable = pdata->wrapper_interrupt_disable;
+
emac_dev = &ndev->dev;
/* Get EMAC platform data */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index ff55487..eb24dc0 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -25,6 +25,8 @@ struct emac_platform_data {
u32 mdio_max_freq;
u8 rmii_en;
u8 version;
+ void (*wrapper_interrupt_enable) (void);
+ void (*wrapper_interrupt_disable) (void);
};
enum {
--
1.6.2.4
^ permalink raw reply related
* [PATCH 0/3] TI EMAC driver : Make driver re-usable on non-davinci platforms.
From: Sriramakrishnan @ 2009-11-18 9:42 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, Sriramakrishnan
The Davinci EMAC peripheral is also available on other TI platforms -
notably TI AM3517 SoC. The following series of patches modify the driver
suitably to make it platform agnostic.
Sriramakrishnan (3):
TI Davinci EMAC : Re-use driver for other platforms.
TI Davinci EMAC : add platform specific interrupt enable/disable
logic.
TI Davinci EMAC : Abstract Buffer address translation logic.
arch/arm/mach-davinci/board-dm644x-evm.c | 2 +-
arch/arm/mach-davinci/board-dm646x-evm.c | 2 +-
arch/arm/mach-davinci/common.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/mach-davinci/include/mach/dm365.h | 2 +-
arch/arm/mach-davinci/include/mach/dm644x.h | 2 +-
arch/arm/mach-davinci/include/mach/dm646x.h | 2 +-
arch/arm/mach-davinci/include/mach/emac.h | 36 -----------------
drivers/net/Kconfig | 2 +-
drivers/net/davinci_emac.c | 55 +++++++++++++++++---------
include/linux/davinci_emac.h | 39 +++++++++++++++++++
11 files changed, 83 insertions(+), 63 deletions(-)
delete mode 100644 arch/arm/mach-davinci/include/mach/emac.h
create mode 100644 include/linux/davinci_emac.h
^ permalink raw reply
* [PATCH 1/3] TI Davinci EMAC : Re-use driver for other platforms.
From: Sriramakrishnan @ 2009-11-18 9:42 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, Sriramakrishnan
In-Reply-To: <1258537328-31527-1-git-send-email-srk@ti.com>
The davinci EMAC peripheral is also available on other TI
platforms -notably TI AM3517 SoC. This patch modifies the
config option and the platform structure header files so that
the driver can be reused on non-davinci platforms as well.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
---
arch/arm/mach-davinci/board-dm644x-evm.c | 2 +-
arch/arm/mach-davinci/board-dm646x-evm.c | 2 +-
arch/arm/mach-davinci/common.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/mach-davinci/include/mach/dm365.h | 2 +-
arch/arm/mach-davinci/include/mach/dm644x.h | 2 +-
arch/arm/mach-davinci/include/mach/dm646x.h | 2 +-
arch/arm/mach-davinci/include/mach/emac.h | 36 ---------------------------
drivers/net/Kconfig | 2 +-
drivers/net/davinci_emac.c | 3 +-
include/linux/davinci_emac.h | 36 +++++++++++++++++++++++++++
11 files changed, 45 insertions(+), 46 deletions(-)
delete mode 100644 arch/arm/mach-davinci/include/mach/emac.h
create mode 100644 include/linux/davinci_emac.h
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 1213a00..e930281 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -29,6 +29,7 @@
#include <linux/phy.h>
#include <linux/clk.h>
#include <linux/videodev2.h>
+#include <linux/davinci_emac.h>
#include <media/tvp514x.h>
@@ -47,7 +48,6 @@
#include <mach/psc.h>
#include <mach/nand.h>
#include <mach/mmc.h>
-#include <mach/emac.h>
#define DM644X_EVM_PHY_MASK (0x2)
#define DM644X_EVM_MDIO_FREQUENCY (2200000) /* PHY bus frequency */
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 24e0e13..6f9fe36 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -33,6 +33,7 @@
#include <linux/i2c/at24.h>
#include <linux/i2c/pcf857x.h>
#include <linux/etherdevice.h>
+#include <linux/davinci_emac.h>
#include <media/tvp514x.h>
@@ -48,7 +49,6 @@
#include <mach/serial.h>
#include <mach/i2c.h>
#include <mach/mmc.h>
-#include <mach/emac.h>
#if defined(CONFIG_BLK_DEV_PALMCHIP_BK3710) || \
defined(CONFIG_BLK_DEV_PALMCHIP_BK3710_MODULE)
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index 61ede19..d62398b 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -11,13 +11,13 @@
#include <linux/module.h>
#include <linux/io.h>
#include <linux/etherdevice.h>
+#include <linux/davinci_emac.h>
#include <asm/tlb.h>
#include <asm/mach/map.h>
#include <mach/common.h>
#include <mach/cputype.h>
-#include <mach/emac.h>
#include "clock.h"
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index d4095d0..f056178 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -11,10 +11,10 @@
#ifndef __ASM_ARCH_DAVINCI_DA8XX_H
#define __ASM_ARCH_DAVINCI_DA8XX_H
+#include <linux/davinci_emac.h>
#include <mach/serial.h>
#include <mach/edma.h>
#include <mach/i2c.h>
-#include <mach/emac.h>
#include <mach/asp.h>
#include <mach/mmc.h>
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index 09db434..f2e34d8 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -14,8 +14,8 @@
#define __ASM_ARCH_DM665_H
#include <linux/platform_device.h>
+#include <linux/davinci_emac.h>
#include <mach/hardware.h>
-#include <mach/emac.h>
#define DM365_EMAC_BASE (0x01D07000)
#define DM365_EMAC_CNTRL_OFFSET (0x0000)
diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h
index 0efb738..dad3622 100644
--- a/arch/arm/mach-davinci/include/mach/dm644x.h
+++ b/arch/arm/mach-davinci/include/mach/dm644x.h
@@ -23,8 +23,8 @@
#define __ASM_ARCH_DM644X_H
#include <linux/platform_device.h>
+#include <linux/davinci_emac.h>
#include <mach/hardware.h>
-#include <mach/emac.h>
#include <mach/asp.h>
#include <media/davinci/vpfe_capture.h>
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h
index 8cec746..5c92dfb 100644
--- a/arch/arm/mach-davinci/include/mach/dm646x.h
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -12,10 +12,10 @@
#define __ASM_ARCH_DM646X_H
#include <mach/hardware.h>
-#include <mach/emac.h>
#include <mach/asp.h>
#include <linux/i2c.h>
#include <linux/videodev2.h>
+#include <linux/davinci_emac.h>
#define DM646X_EMAC_BASE (0x01C80000)
#define DM646X_EMAC_CNTRL_OFFSET (0x0000)
diff --git a/arch/arm/mach-davinci/include/mach/emac.h b/arch/arm/mach-davinci/include/mach/emac.h
deleted file mode 100644
index beff4fb..0000000
--- a/arch/arm/mach-davinci/include/mach/emac.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * TI DaVinci EMAC platform support
- *
- * Author: Kevin Hilman, Deep Root Systems, LLC
- *
- * 2007 (c) Deep Root Systems, LLC. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- */
-#ifndef _MACH_DAVINCI_EMAC_H
-#define _MACH_DAVINCI_EMAC_H
-
-#include <linux/if_ether.h>
-#include <linux/memory.h>
-
-struct emac_platform_data {
- char mac_addr[ETH_ALEN];
- u32 ctrl_reg_offset;
- u32 ctrl_mod_reg_offset;
- u32 ctrl_ram_offset;
- u32 mdio_reg_offset;
- u32 ctrl_ram_size;
- u32 phy_mask;
- u32 mdio_max_freq;
- u8 rmii_en;
- u8 version;
-};
-
-enum {
- EMAC_VERSION_1, /* DM644x */
- EMAC_VERSION_2, /* DM646x */
-};
-
-void davinci_get_mac_addr(struct memory_accessor *mem_acc, void *context);
-#endif
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index e19ca4b..2d3443c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -920,7 +920,7 @@ config NET_NETX
config TI_DAVINCI_EMAC
tristate "TI DaVinci EMAC Support"
- depends on ARM && ARCH_DAVINCI
+ depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
select PHYLIB
help
This driver supports TI's DaVinci Ethernet .
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 4cf80ec..6aec8f5 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -62,12 +62,11 @@
#include <linux/bitops.h>
#include <linux/io.h>
#include <linux/uaccess.h>
+#include <linux/davinci_emac.h>
#include <asm/irq.h>
#include <asm/page.h>
-#include <mach/emac.h>
-
static int debug_level;
module_param(debug_level, int, 0);
MODULE_PARM_DESC(debug_level, "DaVinci EMAC debug level (NETIF_MSG bits)");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
new file mode 100644
index 0000000..ff55487
--- /dev/null
+++ b/include/linux/davinci_emac.h
@@ -0,0 +1,36 @@
+/*
+ * TI DaVinci EMAC platform support
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * 2007 (c) Deep Root Systems, LLC. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#ifndef _LINUX_DAVINCI_EMAC_H
+#define _LINUX_DAVINCI_EMAC_H
+
+#include <linux/if_ether.h>
+#include <linux/memory.h>
+
+struct emac_platform_data {
+ char mac_addr[ETH_ALEN];
+ u32 ctrl_reg_offset;
+ u32 ctrl_mod_reg_offset;
+ u32 ctrl_ram_offset;
+ u32 mdio_reg_offset;
+ u32 ctrl_ram_size;
+ u32 phy_mask;
+ u32 mdio_max_freq;
+ u8 rmii_en;
+ u8 version;
+};
+
+enum {
+ EMAC_VERSION_1, /* DM644x */
+ EMAC_VERSION_2, /* DM646x */
+};
+
+void davinci_get_mac_addr(struct memory_accessor *mem_acc, void *context);
+#endif
--
1.6.2.4
^ permalink raw reply related
* [PATCH 3/3] TI Davinci EMAC : Abstract Buffer address translation logic.
From: Sriramakrishnan @ 2009-11-18 9:42 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, Sriramakrishnan
In-Reply-To: <1258537328-31527-3-git-send-email-srk@ti.com>
When programming the DMA engine, the next pointers must be
programmed with physical address as seen from the DMA master
address space. This address may be different from physical
address of the buffer RAM area. This patch abstracts the
buffer address translation logic.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
---
drivers/net/davinci_emac.c | 41 ++++++++++++++++++++++++-----------------
include/linux/davinci_emac.h | 1 +
2 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 81931f8..d4e173b 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -464,6 +464,7 @@ struct emac_priv {
void __iomem *ctrl_base;
void __iomem *emac_ctrl_ram;
u32 ctrl_ram_size;
+ u32 hw_ram_addr;
struct emac_txch *txch[EMAC_DEF_MAX_TX_CH];
struct emac_rxch *rxch[EMAC_DEF_MAX_RX_CH];
u32 link; /* 1=link on, 0=link off */
@@ -497,11 +498,9 @@ static struct clk *emac_clk;
static unsigned long emac_bus_frequency;
static unsigned long mdio_max_freq;
-/* EMAC internal utility function */
-static inline u32 emac_virt_to_phys(void __iomem *addr)
-{
- return (u32 __force) io_v2p(addr);
-}
+#define emac_virt_to_phys(addr, priv) \
+ (((u32 __force)(addr) - (u32 __force)(priv->emac_ctrl_ram)) \
+ + priv->hw_ram_addr)
/* Cache macros - Packet buffers would be from skb pool which is cached */
#define EMAC_VIRT_NOCACHE(addr) (addr)
@@ -1309,7 +1308,7 @@ static int emac_tx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
curr_bd = txch->active_queue_head;
if (NULL == curr_bd) {
emac_write(EMAC_TXCP(ch),
- emac_virt_to_phys(txch->last_hw_bdprocessed));
+ emac_virt_to_phys(txch->last_hw_bdprocessed, priv));
txch->no_active_pkts++;
spin_unlock_irqrestore(&priv->tx_lock, flags);
return 0;
@@ -1319,7 +1318,7 @@ static int emac_tx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
while ((curr_bd) &&
((frame_status & EMAC_CPPI_OWNERSHIP_BIT) == 0) &&
(pkts_processed < budget)) {
- emac_write(EMAC_TXCP(ch), emac_virt_to_phys(curr_bd));
+ emac_write(EMAC_TXCP(ch), emac_virt_to_phys(curr_bd, priv));
txch->active_queue_head = curr_bd->next;
if (frame_status & EMAC_CPPI_EOQ_BIT) {
if (curr_bd->next) { /* misqueued packet */
@@ -1406,7 +1405,7 @@ static int emac_send(struct emac_priv *priv, struct emac_netpktobj *pkt, u32 ch)
txch->active_queue_tail = curr_bd;
if (1 != txch->queue_active) {
emac_write(EMAC_TXHDP(ch),
- emac_virt_to_phys(curr_bd));
+ emac_virt_to_phys(curr_bd, priv));
txch->queue_active = 1;
}
++txch->queue_reinit;
@@ -1418,10 +1417,11 @@ static int emac_send(struct emac_priv *priv, struct emac_netpktobj *pkt, u32 ch)
tail_bd->next = curr_bd;
txch->active_queue_tail = curr_bd;
tail_bd = EMAC_VIRT_NOCACHE(tail_bd);
- tail_bd->h_next = (int)emac_virt_to_phys(curr_bd);
+ tail_bd->h_next = (int)emac_virt_to_phys(curr_bd, priv);
frame_status = tail_bd->mode;
if (frame_status & EMAC_CPPI_EOQ_BIT) {
- emac_write(EMAC_TXHDP(ch), emac_virt_to_phys(curr_bd));
+ emac_write(EMAC_TXHDP(ch),
+ emac_virt_to_phys(curr_bd, priv));
frame_status &= ~(EMAC_CPPI_EOQ_BIT);
tail_bd->mode = frame_status;
++txch->end_of_queue_add;
@@ -1611,7 +1611,8 @@ static int emac_init_rxch(struct emac_priv *priv, u32 ch, char *param)
}
/* populate the hardware descriptor */
- curr_bd->h_next = emac_virt_to_phys(rxch->active_queue_head);
+ curr_bd->h_next = emac_virt_to_phys(rxch->active_queue_head,
+ priv);
/* FIXME buff_ptr = dma_map_single(... data_ptr ...) */
curr_bd->buff_ptr = virt_to_phys(curr_bd->data_ptr);
curr_bd->off_b_len = rxch->buf_size;
@@ -1886,7 +1887,7 @@ static void emac_addbd_to_rx_queue(struct emac_priv *priv, u32 ch,
rxch->active_queue_tail = curr_bd;
if (0 != rxch->queue_active) {
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(rxch->active_queue_head));
+ emac_virt_to_phys(rxch->active_queue_head, priv));
rxch->queue_active = 1;
}
} else {
@@ -1897,11 +1898,11 @@ static void emac_addbd_to_rx_queue(struct emac_priv *priv, u32 ch,
rxch->active_queue_tail = curr_bd;
tail_bd->next = curr_bd;
tail_bd = EMAC_VIRT_NOCACHE(tail_bd);
- tail_bd->h_next = emac_virt_to_phys(curr_bd);
+ tail_bd->h_next = emac_virt_to_phys(curr_bd, priv);
frame_status = tail_bd->mode;
if (frame_status & EMAC_CPPI_EOQ_BIT) {
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(curr_bd));
+ emac_virt_to_phys(curr_bd, priv));
frame_status &= ~(EMAC_CPPI_EOQ_BIT);
tail_bd->mode = frame_status;
++rxch->end_of_queue_add;
@@ -1994,7 +1995,7 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
curr_pkt->num_bufs = 1;
curr_pkt->pkt_length =
(frame_status & EMAC_RX_BD_PKT_LENGTH_MASK);
- emac_write(EMAC_RXCP(ch), emac_virt_to_phys(curr_bd));
+ emac_write(EMAC_RXCP(ch), emac_virt_to_phys(curr_bd, priv));
++rxch->processed_bd;
last_bd = curr_bd;
curr_bd = last_bd->next;
@@ -2005,7 +2006,7 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
if (curr_bd) {
++rxch->mis_queued_packets;
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(curr_bd));
+ emac_virt_to_phys(curr_bd, priv));
} else {
++rxch->end_of_queue;
rxch->queue_active = 0;
@@ -2106,7 +2107,7 @@ static int emac_hw_enable(struct emac_priv *priv)
emac_write(EMAC_RXINTMASKSET, BIT(ch));
rxch->queue_active = 1;
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(rxch->active_queue_head));
+ emac_virt_to_phys(rxch->active_queue_head, priv));
}
/* Enable MII */
@@ -2705,6 +2706,12 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
priv->ctrl_ram_size = pdata->ctrl_ram_size;
priv->emac_ctrl_ram = priv->remap_addr + pdata->ctrl_ram_offset;
+ if (pdata->hw_ram_addr)
+ priv->hw_ram_addr = pdata->hw_ram_addr;
+ else
+ priv->hw_ram_addr = (u32 __force)res->start +
+ pdata->ctrl_ram_offset;
+
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(emac_dev, "DaVinci EMAC: Error getting irq res\n");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index eb24dc0..b318dfd 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -19,6 +19,7 @@ struct emac_platform_data {
u32 ctrl_reg_offset;
u32 ctrl_mod_reg_offset;
u32 ctrl_ram_offset;
+ u32 hw_ram_addr;
u32 mdio_reg_offset;
u32 ctrl_ram_size;
u32 phy_mask;
--
1.6.2.4
^ permalink raw reply related
* Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
From: Arnd Bergmann @ 2009-11-18 9:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <4B03949D.4000908@gmail.com>
On Wednesday 18 November 2009, Eric Dumazet wrote:
> > - skb->dev = dev;
> > - skb->pkt_type = PACKET_HOST;
> > + skb->protocol = eth_type_trans(skb, dev);
> > + eth = eth_hdr(skb);
> >
> > - netif_rx(skb);
> > - return NULL;
> > + skb_dst_drop(skb);
>
> Why do you drop dst here ?
>
> It seems strange, since this driver specifically masks out IFF_XMIT_DST_RELEASE
> in its macvlan_setup() :
>
> dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
>
> If we really want to drop dst, it could be done by caller, if IFF_XMIT_DST_RELEASE
> was not masked in macvlan_setup().
>
That must be my fault, it is the only change I did to Eric B's patch when
forward-porting to 2.6.32. The original patch did
skb->protocol = eth_type_trans(skb, dev);
eth = eth_hdr(skb);
dst_release(skb->dst);
skb->dst = NULL;
skb->mark = 0;
and I tried to convert that in the same way that other drivers did, but I
have to admit that I did not understand the mechanics of IFF_XMIT_DST_RELEASE.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/3] macvlan: implement VEPA and private mode
From: Arnd Bergmann @ 2009-11-18 9:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <4B03974D.3010708@gmail.com>
On Wednesday 18 November 2009, Eric Dumazet wrote:
> > + macvlan_broadcast(skb, port, NULL, MACVLAN_MODE_VEPA
> > + | MACVLAN_MODE_VEPA | MACVLAN_MODE_BRIDGE);
>
> typo here, you probably meant MACVLAN_PRIVATE | MACVLAN_VEPA | MACVLAN_BRIDGE
Well spotted. One last minute-change gone wrong.
Thanks,
Arnd <><
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-18 9:59 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Frans Pop, Andi Kleen, linux-kernel, netdev
In-Reply-To: <20091113211640.GA2540@ami.dom.local>
> Might be the same bugzilla report, I guess. We need to establish if
> these pings reach 192.168.1.1, so a short test and tcpdump without any
> special options just to get a few lost cases as seen on both sides.
> (And ifconfigs before and after the test.)
>
> Btw, could you check with lsmod if usbserial module is loaded before
> this test? I'd like to verify this git bisection result. (If the
> module is loaded or you have CONFIG_USB_SERIAL=y instead of m, try to
> recompile the kernel with this option turned off, for this test.)
sorry for taking so long to get back. busy problematic times.
the dumps and ifconfigs are a bit less 'clean' because the router
serves several other computers (none of which have this issue
(windows)) here's the ifconfig -a from the router.
usbserial is not loaded. actually from reading the patch submission I
suspected the official cause might be off... but I'm not kernel
programmer all I know is where I could see the loss during tests.and I
haven't been able to reproduce over dozens of reboots from this
2.6.31.1-test-00091-gfa31221 kernel.
I totally forgot to do it during the dump's so I hope these are still useful
I haven't rebooted this in a few weeks (the router)
br-lan Link encap:Ethernet HWaddr 00:1D:7E:F8:21:66
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:60613991 errors:0 dropped:0 overruns:0 frame:0
TX packets:67849334 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2172912561 (2.0 GiB) TX bytes:3999263405 (3.7 GiB)
eth0 Link encap:Ethernet HWaddr 00:1D:7E:F8:21:66
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:144116625 errors:0 dropped:0 overruns:0 frame:0
TX packets:122639966 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1986512923 (1.8 GiB) TX bytes:1548485891 (1.4 GiB)
Interrupt:4
eth0.0 Link encap:Ethernet HWaddr 00:1D:7E:F8:21:66
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:57318567 errors:0 dropped:0 overruns:0 frame:0
TX packets:62317675 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3466538358 (3.2 GiB) TX bytes:2132301174 (1.9 GiB)
eth0.1 Link encap:Ethernet HWaddr 00:1D:7E:F8:21:66
inet addr:68.42.198.183 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:86777655 errors:0 dropped:0 overruns:0 frame:0
TX packets:60312064 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:205005516 (195.5 MiB) TX bytes:3162930981 (2.9 GiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:168 errors:0 dropped:0 overruns:0 frame:0
TX packets:168 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:19706 (19.2 KiB) TX bytes:19706 (19.2 KiB)
wl0 Link encap:Ethernet HWaddr 00:1D:7E:F8:21:68
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5114480 errors:0 dropped:0 overruns:0 frame:720205
TX packets:7576790 errors:1902 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:762579947 (727.2 MiB) TX bytes:3981402458 (3.7 GiB)
Interrupt:2 Base address:0x5000
this is the ifconfig -a from my desktop while experiencing the issue
eth0 Link encap:Ethernet HWaddr 00:21:9B:06:4C:C9
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::221:9bff:fe06:4cc9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3465 errors:0 dropped:0 overruns:0 frame:0
TX packets:4951 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1467320 (1.3 Mb) TX bytes:631808 (617.0 Kb)
Memory:fdfc0000-fdfe0000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:624 errors:0 dropped:0 overruns:0 frame:0
TX packets:624 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:64397 (62.8 Kb) TX bytes:64397 (62.8 Kb)
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: [PATCH 3/3] macvlan: export macvlan mode through netlink
From: Arnd Bergmann @ 2009-11-18 9:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <4B0398D4.8030904@gmail.com>
On Wednesday 18 November 2009, Eric Dumazet wrote:
> > --- a/drivers/net/macvlan.c
> > +++ b/drivers/net/macvlan.c
> > @@ -33,12 +33,6 @@
> >
> > #define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
> >
> > -enum macvlan_type {
> > - MACVLAN_PRIVATE = 1,
> > - MACVLAN_VEPA = 2,
> > - MACVLAN_BRIDGE = 4,
> > -};
>
> I realize you defined MACVLAN_PRIVATE in patch 2, but used MACVLAN_MODE_PRIVATE,
> so patch 2 is not compilable and breaks bisection ?
>
Hmm, right. I'll fix that up as well.
Thanks,
Arnd <><
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-18 10:00 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Frans Pop, Andi Kleen, linux-kernel, netdev
In-Reply-To: <81bfc67a0911180159g45a45675k44ce3f251c6bddea@mail.gmail.com>
p.s. dumps are on the old bug here...
http://bugzilla.kernel.org/show_bug.cgi?id=13835
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
From: roel kluin @ 2009-11-18 10:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <1258497551-25959-2-git-send-email-arnd@arndb.de>
On Tue, Nov 17, 2009 at 11:39 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> From: Eric Biederman <ebiederm@xmission.com>
>
> Switch ports do not send packets back out the same port they came
> in on. This causes problems when using a macvlan device inside
> of a network namespace as it becomes impossible to talk to
> other macvlan devices.
>
> Signed-off-by: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I found a problem:
> @@ -140,20 +145,45 @@ static void macvlan_broadcast(struct sk_buff *skb,
> }
> }
>
> +static int macvlan_unicast(struct sk_buff *skb, const struct macvlan_dev *dest)
> +{
> + struct net_device *dev = dest->dev;
> +
> + if (unlikely(!dev->flags & IFF_UP)) {
parentheses are missing:
if (unlikely(!(dev->flags & IFF_UP))) {
> + kfree_skb(skb);
> + return NET_XMIT_DROP;
> + }
> +
> + skb = skb_share_check(skb, GFP_ATOMIC);
> + if (!skb) {
> + dev->stats.rx_errors++;
> + dev->stats.rx_dropped++;
> + return NET_XMIT_DROP;
> + }
> +
> + dev->stats.rx_bytes += skb->len + ETH_HLEN;
> + dev->stats.rx_packets++;
> +
> + skb->dev = dev;
> + skb->pkt_type = PACKET_HOST;
> + netif_rx(skb);
> + return NET_XMIT_SUCCESS;
> +}
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Fix EMACx_TRTR[TRT] bit shifts
From: Stefan Roese @ 2009-11-18 10:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, Dave Mitchell, linuxppc-dev
In-Reply-To: <1258505815-31261-1-git-send-email-dmitchell@appliedmicro.com>
On Wednesday 18 November 2009 01:56:55 Dave Mitchell wrote:
> The TRT bit shifts were reversed for EMAC4 and non-EMAC4 during the
> port from ibm_emac to ibm_newemac. This patch corrects that error.
>
> Signed-off-by: Dave Mitchell <dmitchell@appliedmicro.com>
> Acked-by: Feng Kan <fkan@appliedmicro.com>
> Acked-by: Prodyut Hazarika <phazarika@appliedmicro.com>
Acked-by: Stefan Roese <sr@denx.de>
Would be great if this could go into 2.6.32. Thanks.
Cheers,
Stefan
^ permalink raw reply
* Re: [RFC v2] mac80211: disallow bridging managed/adhoc interfaces
From: Johannes Berg @ 2009-11-18 10:52 UTC (permalink / raw)
To: John W. Linville
Cc: Stefan Monnier, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091118025920.GA4588-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
On Tue, 2009-11-17 at 21:59 -0500, John W. Linville wrote:
> > As someone who's been bitten by this, I fully support this change.
> > Still, it makes me wonder: my broadcom-based home-router using the wl.o
> > driver can be set in "client bridge" mode. How does it work?
>
> If I'm not mistaken, that has a bunch of code embedded in it that
> among other things can do a layer-2 version of NAT to rewrite the
> MAC adresses for frames on the air.
Yeah, that's how it works. You can probably achieve the same effect with
the ebtable_nat module in ebtables but I've never even attempted to try
that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] bnx2x: Refactor MAC address setup code.
From: Stanislaw Gruszka @ 2009-11-18 11:06 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev, michaelc, shmulikr, eilong
In-Reply-To: <1255218419-17320-2-git-send-email-mchan@broadcom.com>
Hi Michael
On Sat, Oct 10, 2009 at 04:46:54PM -0700, Michael Chan wrote:
> For iSCSI MAC address setup in later patches.
>
> Signed-off-by: Shmulik Ravid - Rabinovitz <shmulikr@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Acked-by: Eilon Greenstein <eilong@broadcom.com>
In this patch you become to use ->set_mac_pending as a counter. It looks
like you are trying to do smb_wmb() to make incrementing/decrementing
operations correct on many processors. But this seems to be wrong,
since there is no data dependency and smp_wmb()/smp_rmb() does noting.
In particular these barriers not prevent to race when two processors
decrement/increment counter. IMHO atomic_t should be used.
Stanislaw
> ---
> drivers/net/bnx2x.h | 4 +-
> drivers/net/bnx2x_main.c | 162 ++++++++++++++++++++++++++++++++--------------
> 2 files changed, 114 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/net/bnx2x.h b/drivers/net/bnx2x.h
> index bbf8422..1f07063 100644
> --- a/drivers/net/bnx2x.h
> +++ b/drivers/net/bnx2x.h
> @@ -863,8 +863,8 @@ struct bnx2x {
>
> /* Flags for marking that there is a STAT_QUERY or
> SET_MAC ramrod pending */
> - u8 stats_pending;
> - u8 set_mac_pending;
> + int stats_pending;
> + int set_mac_pending;
>
> /* End of fields used in the performance code paths */
>
> diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
> index 713d669..02ce3b3 100644
> --- a/drivers/net/bnx2x_main.c
> +++ b/drivers/net/bnx2x_main.c
> @@ -1026,12 +1026,15 @@ static void bnx2x_sp_event(struct bnx2x_fastpath *fp,
> case (RAMROD_CMD_ID_ETH_SET_MAC | BNX2X_STATE_OPEN):
> case (RAMROD_CMD_ID_ETH_SET_MAC | BNX2X_STATE_DIAG):
> DP(NETIF_MSG_IFUP, "got set mac ramrod\n");
> - bp->set_mac_pending = 0;
> + bp->set_mac_pending--;
> + smp_wmb();
> break;
>
> case (RAMROD_CMD_ID_ETH_SET_MAC | BNX2X_STATE_CLOSING_WAIT4_HALT):
> case (RAMROD_CMD_ID_ETH_SET_MAC | BNX2X_STATE_DISABLED):
> DP(NETIF_MSG_IFDOWN, "got (un)set mac ramrod\n");
> + bp->set_mac_pending--;
> + smp_wmb();
> break;
>
> default:
> @@ -2530,7 +2533,7 @@ u32 bnx2x_fw_command(struct bnx2x *bp, u32 command)
> }
>
> static void bnx2x_set_storm_rx_mode(struct bnx2x *bp);
> -static void bnx2x_set_mac_addr_e1h(struct bnx2x *bp, int set);
> +static void bnx2x_set_eth_mac_addr_e1h(struct bnx2x *bp, int set);
> static void bnx2x_set_rx_mode(struct net_device *dev);
>
> static void bnx2x_e1h_disable(struct bnx2x *bp)
> @@ -2546,7 +2549,7 @@ static void bnx2x_e1h_disable(struct bnx2x *bp)
>
> REG_WR(bp, NIG_REG_LLH0_FUNC_EN + port*8, 0);
>
> - bnx2x_set_mac_addr_e1h(bp, 0);
> + bnx2x_set_eth_mac_addr_e1h(bp, 0);
>
> for (i = 0; i < MC_HASH_SIZE; i++)
> REG_WR(bp, MC_HASH_OFFSET(bp, i), 0);
> @@ -2560,7 +2563,7 @@ static void bnx2x_e1h_enable(struct bnx2x *bp)
>
> REG_WR(bp, NIG_REG_LLH0_FUNC_EN + port*8, 1);
>
> - bnx2x_set_mac_addr_e1h(bp, 1);
> + bnx2x_set_eth_mac_addr_e1h(bp, 1);
>
> /* Tx queue should be only reenabled */
> netif_tx_wake_all_queues(bp->dev);
> @@ -7036,7 +7039,19 @@ static void bnx2x_netif_stop(struct bnx2x *bp, int disable_hw)
> * Init service functions
> */
>
> -static void bnx2x_set_mac_addr_e1(struct bnx2x *bp, int set)
> +/**
> + * Sets a MAC in a CAM for a few L2 Clients for E1 chip
> + *
> + * @param bp driver descriptor
> + * @param set set or clear an entry (1 or 0)
> + * @param mac pointer to a buffer containing a MAC
> + * @param cl_bit_vec bit vector of clients to register a MAC for
> + * @param cam_offset offset in a CAM to use
> + * @param with_bcast set broadcast MAC as well
> + */
> +static void bnx2x_set_mac_addr_e1_gen(struct bnx2x *bp, int set, u8 *mac,
> + u32 cl_bit_vec, u8 cam_offset,
> + u8 with_bcast)
> {
> struct mac_configuration_cmd *config = bnx2x_sp(bp, mac_config);
> int port = BP_PORT(bp);
> @@ -7045,25 +7060,25 @@ static void bnx2x_set_mac_addr_e1(struct bnx2x *bp, int set)
> * unicasts 0-31:port0 32-63:port1
> * multicast 64-127:port0 128-191:port1
> */
> - config->hdr.length = 2;
> - config->hdr.offset = port ? 32 : 0;
> - config->hdr.client_id = bp->fp->cl_id;
> + config->hdr.length = 1 + (with_bcast ? 1 : 0);
> + config->hdr.offset = cam_offset;
> + config->hdr.client_id = 0xff;
> config->hdr.reserved1 = 0;
>
> /* primary MAC */
> config->config_table[0].cam_entry.msb_mac_addr =
> - swab16(*(u16 *)&bp->dev->dev_addr[0]);
> + swab16(*(u16 *)&mac[0]);
> config->config_table[0].cam_entry.middle_mac_addr =
> - swab16(*(u16 *)&bp->dev->dev_addr[2]);
> + swab16(*(u16 *)&mac[2]);
> config->config_table[0].cam_entry.lsb_mac_addr =
> - swab16(*(u16 *)&bp->dev->dev_addr[4]);
> + swab16(*(u16 *)&mac[4]);
> config->config_table[0].cam_entry.flags = cpu_to_le16(port);
> if (set)
> config->config_table[0].target_table_entry.flags = 0;
> else
> CAM_INVALIDATE(config->config_table[0]);
> config->config_table[0].target_table_entry.clients_bit_vector =
> - cpu_to_le32(1 << BP_L_ID(bp));
> + cpu_to_le32(cl_bit_vec);
> config->config_table[0].target_table_entry.vlan_id = 0;
>
> DP(NETIF_MSG_IFUP, "%s MAC (%04x:%04x:%04x)\n",
> @@ -7073,47 +7088,58 @@ static void bnx2x_set_mac_addr_e1(struct bnx2x *bp, int set)
> config->config_table[0].cam_entry.lsb_mac_addr);
>
> /* broadcast */
> - config->config_table[1].cam_entry.msb_mac_addr = cpu_to_le16(0xffff);
> - config->config_table[1].cam_entry.middle_mac_addr = cpu_to_le16(0xffff);
> - config->config_table[1].cam_entry.lsb_mac_addr = cpu_to_le16(0xffff);
> - config->config_table[1].cam_entry.flags = cpu_to_le16(port);
> - if (set)
> - config->config_table[1].target_table_entry.flags =
> - TSTORM_CAM_TARGET_TABLE_ENTRY_BROADCAST;
> - else
> - CAM_INVALIDATE(config->config_table[1]);
> - config->config_table[1].target_table_entry.clients_bit_vector =
> - cpu_to_le32(1 << BP_L_ID(bp));
> - config->config_table[1].target_table_entry.vlan_id = 0;
> + if (with_bcast) {
> + config->config_table[1].cam_entry.msb_mac_addr =
> + cpu_to_le16(0xffff);
> + config->config_table[1].cam_entry.middle_mac_addr =
> + cpu_to_le16(0xffff);
> + config->config_table[1].cam_entry.lsb_mac_addr =
> + cpu_to_le16(0xffff);
> + config->config_table[1].cam_entry.flags = cpu_to_le16(port);
> + if (set)
> + config->config_table[1].target_table_entry.flags =
> + TSTORM_CAM_TARGET_TABLE_ENTRY_BROADCAST;
> + else
> + CAM_INVALIDATE(config->config_table[1]);
> + config->config_table[1].target_table_entry.clients_bit_vector =
> + cpu_to_le32(cl_bit_vec);
> + config->config_table[1].target_table_entry.vlan_id = 0;
> + }
>
> bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_SET_MAC, 0,
> U64_HI(bnx2x_sp_mapping(bp, mac_config)),
> U64_LO(bnx2x_sp_mapping(bp, mac_config)), 0);
> }
>
> -static void bnx2x_set_mac_addr_e1h(struct bnx2x *bp, int set)
> +/**
> + * Sets a MAC in a CAM for a few L2 Clients for E1H chip
> + *
> + * @param bp driver descriptor
> + * @param set set or clear an entry (1 or 0)
> + * @param mac pointer to a buffer containing a MAC
> + * @param cl_bit_vec bit vector of clients to register a MAC for
> + * @param cam_offset offset in a CAM to use
> + */
> +static void bnx2x_set_mac_addr_e1h_gen(struct bnx2x *bp, int set, u8 *mac,
> + u32 cl_bit_vec, u8 cam_offset)
> {
> struct mac_configuration_cmd_e1h *config =
> (struct mac_configuration_cmd_e1h *)bnx2x_sp(bp, mac_config);
>
> - /* CAM allocation for E1H
> - * unicasts: by func number
> - * multicast: 20+FUNC*20, 20 each
> - */
> config->hdr.length = 1;
> - config->hdr.offset = BP_FUNC(bp);
> - config->hdr.client_id = bp->fp->cl_id;
> + config->hdr.offset = cam_offset;
> + config->hdr.client_id = 0xff;
> config->hdr.reserved1 = 0;
>
> /* primary MAC */
> config->config_table[0].msb_mac_addr =
> - swab16(*(u16 *)&bp->dev->dev_addr[0]);
> + swab16(*(u16 *)&mac[0]);
> config->config_table[0].middle_mac_addr =
> - swab16(*(u16 *)&bp->dev->dev_addr[2]);
> + swab16(*(u16 *)&mac[2]);
> config->config_table[0].lsb_mac_addr =
> - swab16(*(u16 *)&bp->dev->dev_addr[4]);
> + swab16(*(u16 *)&mac[4]);
> config->config_table[0].clients_bit_vector =
> - cpu_to_le32(1 << BP_L_ID(bp));
> + cpu_to_le32(cl_bit_vec);
> config->config_table[0].vlan_id = 0;
> config->config_table[0].e1hov_id = cpu_to_le16(bp->e1hov);
> if (set)
> @@ -7122,11 +7148,11 @@ static void bnx2x_set_mac_addr_e1h(struct bnx2x *bp, int set)
> config->config_table[0].flags =
> MAC_CONFIGURATION_ENTRY_E1H_ACTION_TYPE;
>
> - DP(NETIF_MSG_IFUP, "%s MAC (%04x:%04x:%04x) E1HOV %d CLID %d\n",
> + DP(NETIF_MSG_IFUP, "%s MAC (%04x:%04x:%04x) E1HOV %d CLID mask %d\n",
> (set ? "setting" : "clearing"),
> config->config_table[0].msb_mac_addr,
> config->config_table[0].middle_mac_addr,
> - config->config_table[0].lsb_mac_addr, bp->e1hov, BP_L_ID(bp));
> + config->config_table[0].lsb_mac_addr, bp->e1hov, cl_bit_vec);
>
> bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_SET_MAC, 0,
> U64_HI(bnx2x_sp_mapping(bp, mac_config)),
> @@ -7178,6 +7204,31 @@ static int bnx2x_wait_ramrod(struct bnx2x *bp, int state, int idx,
> return -EBUSY;
> }
>
> +static void bnx2x_set_eth_mac_addr_e1h(struct bnx2x *bp, int set)
> +{
> + bp->set_mac_pending++;
> + smp_wmb();
> +
> + bnx2x_set_mac_addr_e1h_gen(bp, set, bp->dev->dev_addr,
> + (1 << bp->fp->cl_id), BP_FUNC(bp));
> +
> + /* Wait for a completion */
> + bnx2x_wait_ramrod(bp, 0, 0, &bp->set_mac_pending, set ? 0 : 1);
> +}
> +
> +static void bnx2x_set_eth_mac_addr_e1(struct bnx2x *bp, int set)
> +{
> + bp->set_mac_pending++;
> + smp_wmb();
> +
> + bnx2x_set_mac_addr_e1_gen(bp, set, bp->dev->dev_addr,
> + (1 << bp->fp->cl_id), (BP_PORT(bp) ? 32 : 0),
> + 1);
> +
> + /* Wait for a completion */
> + bnx2x_wait_ramrod(bp, 0, 0, &bp->set_mac_pending, set ? 0 : 1);
> +}
> +
> static int bnx2x_setup_leading(struct bnx2x *bp)
> {
> int rc;
> @@ -7452,9 +7503,9 @@ static int bnx2x_nic_load(struct bnx2x *bp, int load_mode)
> }
>
> if (CHIP_IS_E1(bp))
> - bnx2x_set_mac_addr_e1(bp, 1);
> + bnx2x_set_eth_mac_addr_e1(bp, 1);
> else
> - bnx2x_set_mac_addr_e1h(bp, 1);
> + bnx2x_set_eth_mac_addr_e1h(bp, 1);
> }
>
> if (bp->port.pmf)
> @@ -7717,7 +7768,7 @@ static int bnx2x_nic_unload(struct bnx2x *bp, int unload_mode)
> struct mac_configuration_cmd *config =
> bnx2x_sp(bp, mcast_config);
>
> - bnx2x_set_mac_addr_e1(bp, 0);
> + bnx2x_set_eth_mac_addr_e1(bp, 0);
>
> for (i = 0; i < config->hdr.length; i++)
> CAM_INVALIDATE(config->config_table[i]);
> @@ -7730,6 +7781,9 @@ static int bnx2x_nic_unload(struct bnx2x *bp, int unload_mode)
> config->hdr.client_id = bp->fp->cl_id;
> config->hdr.reserved1 = 0;
>
> + bp->set_mac_pending++;
> + smp_wmb();
> +
> bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_SET_MAC, 0,
> U64_HI(bnx2x_sp_mapping(bp, mcast_config)),
> U64_LO(bnx2x_sp_mapping(bp, mcast_config)), 0);
> @@ -7737,7 +7791,7 @@ static int bnx2x_nic_unload(struct bnx2x *bp, int unload_mode)
> } else { /* E1H */
> REG_WR(bp, NIG_REG_LLH0_FUNC_EN + port*8, 0);
>
> - bnx2x_set_mac_addr_e1h(bp, 0);
> + bnx2x_set_eth_mac_addr_e1h(bp, 0);
>
> for (i = 0; i < MC_HASH_SIZE; i++)
> REG_WR(bp, MC_HASH_OFFSET(bp, i), 0);
> @@ -8520,6 +8574,14 @@ static void __devinit bnx2x_link_settings_requested(struct bnx2x *bp)
> bp->link_params.req_flow_ctrl, bp->port.advertising);
> }
>
> +static void __devinit bnx2x_set_mac_buf(u8 *mac_buf, u32 mac_lo, u16 mac_hi)
> +{
> + mac_hi = cpu_to_be16(mac_hi);
> + mac_lo = cpu_to_be32(mac_lo);
> + memcpy(mac_buf, &mac_hi, sizeof(mac_hi));
> + memcpy(mac_buf + sizeof(mac_hi), &mac_lo, sizeof(mac_lo));
> +}
> +
> static void __devinit bnx2x_get_port_hwinfo(struct bnx2x *bp)
> {
> int port = BP_PORT(bp);
> @@ -8601,12 +8663,7 @@ static void __devinit bnx2x_get_port_hwinfo(struct bnx2x *bp)
>
> val2 = SHMEM_RD(bp, dev_info.port_hw_config[port].mac_upper);
> val = SHMEM_RD(bp, dev_info.port_hw_config[port].mac_lower);
> - bp->dev->dev_addr[0] = (u8)(val2 >> 8 & 0xff);
> - bp->dev->dev_addr[1] = (u8)(val2 & 0xff);
> - bp->dev->dev_addr[2] = (u8)(val >> 24 & 0xff);
> - bp->dev->dev_addr[3] = (u8)(val >> 16 & 0xff);
> - bp->dev->dev_addr[4] = (u8)(val >> 8 & 0xff);
> - bp->dev->dev_addr[5] = (u8)(val & 0xff);
> + bnx2x_set_mac_buf(bp->dev->dev_addr, val, val2);
> memcpy(bp->link_params.mac_addr, bp->dev->dev_addr, ETH_ALEN);
> memcpy(bp->dev->perm_addr, bp->dev->dev_addr, ETH_ALEN);
> }
> @@ -10232,14 +10289,16 @@ static int bnx2x_test_intr(struct bnx2x *bp)
> config->hdr.client_id = bp->fp->cl_id;
> config->hdr.reserved1 = 0;
>
> + bp->set_mac_pending++;
> + smp_wmb();
> rc = bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_SET_MAC, 0,
> U64_HI(bnx2x_sp_mapping(bp, mac_config)),
> U64_LO(bnx2x_sp_mapping(bp, mac_config)), 0);
> if (rc == 0) {
> - bp->set_mac_pending++;
> for (i = 0; i < 10; i++) {
> if (!bp->set_mac_pending)
> break;
> + smp_rmb();
> msleep_interruptible(10);
> }
> if (i == 10)
> @@ -11337,6 +11396,9 @@ static void bnx2x_set_rx_mode(struct net_device *dev)
> config->hdr.client_id = bp->fp->cl_id;
> config->hdr.reserved1 = 0;
>
> + bp->set_mac_pending++;
> + smp_wmb();
> +
> bnx2x_sp_post(bp, RAMROD_CMD_ID_ETH_SET_MAC, 0,
> U64_HI(bnx2x_sp_mapping(bp, mcast_config)),
> U64_LO(bnx2x_sp_mapping(bp, mcast_config)),
> @@ -11386,9 +11448,9 @@ static int bnx2x_change_mac_addr(struct net_device *dev, void *p)
> memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
> if (netif_running(dev)) {
> if (CHIP_IS_E1(bp))
> - bnx2x_set_mac_addr_e1(bp, 1);
> + bnx2x_set_eth_mac_addr_e1(bp, 1);
> else
> - bnx2x_set_mac_addr_e1h(bp, 1);
> + bnx2x_set_eth_mac_addr_e1h(bp, 1);
> }
>
> return 0;
> --
> 1.6.4.GIT
>
>
> --
> 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: [net-next-2.6 PATCH] net: device name allocation cleanups
From: Octavian Purdila @ 2009-11-18 12:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20091117164633.49e5fa44@nehalam>
On Wednesday 18 November 2009 02:46:33 you wrote:
>
> Flatten this logic out.
>
> if (fmt && strchr(name, '%'))
> return __dev_alloc_name(net, name, buf);
> else if (__dev_get_by_name(net, name))
> return -EEXIST;
> else if (buf != name)
> strlcpy(buf, name, IFNAMSIZ);
>
> return 0;
>
Thanks for your help ! Here is a new version which addresses the spotted issues:
[net-next-2.6 PATCH] net: device name allocation cleanups
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
---
net/core/dev.c | 69 +++++++++++++++++++------------------------------------
1 files changed, 24 insertions(+), 45 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 4b24d79..f684ff8 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -893,7 +893,8 @@ static int __dev_alloc_name(struct net *net, const char *name, char *buf)
free_page((unsigned long) inuse);
}
- snprintf(buf, IFNAMSIZ, name, i);
+ if (buf != name)
+ snprintf(buf, IFNAMSIZ, name, i);
if (!__dev_get_by_name(net, buf))
return i;
@@ -933,6 +934,21 @@ int dev_alloc_name(struct net_device *dev, const char *name)
}
EXPORT_SYMBOL(dev_alloc_name);
+static int dev_get_valid_name(struct net *net, const char *name, char *buf,
+ bool fmt)
+{
+ if (!dev_valid_name(name))
+ return -EINVAL;
+
+ if (fmt && strchr(name, '%'))
+ return __dev_alloc_name(net, name, buf);
+ else if (__dev_get_by_name(net, name))
+ return -EEXIST;
+ else if (buf != name)
+ strlcpy(buf, name, IFNAMSIZ);
+
+ return 0;
+}
/**
* dev_change_name - change name of a device
@@ -956,22 +972,14 @@ int dev_change_name(struct net_device *dev, const char *newname)
if (dev->flags & IFF_UP)
return -EBUSY;
- if (!dev_valid_name(newname))
- return -EINVAL;
-
if (strncmp(newname, dev->name, IFNAMSIZ) == 0)
return 0;
memcpy(oldname, dev->name, IFNAMSIZ);
- if (strchr(newname, '%')) {
- err = dev_alloc_name(dev, newname);
- if (err < 0)
- return err;
- } else if (__dev_get_by_name(net, newname))
- return -EEXIST;
- else
- strlcpy(dev->name, newname, IFNAMSIZ);
+ err = dev_get_valid_name(net, newname, dev->name, 1);
+ if (err < 0)
+ return err;
rollback:
/* For now only devices in the initial network namespace
@@ -4864,8 +4872,6 @@ EXPORT_SYMBOL(netdev_fix_features);
int register_netdevice(struct net_device *dev)
{
- struct hlist_head *head;
- struct hlist_node *p;
int ret;
struct net *net = dev_net(dev);
@@ -4894,26 +4900,14 @@ int register_netdevice(struct net_device *dev)
}
}
- if (!dev_valid_name(dev->name)) {
- ret = -EINVAL;
+ ret = dev_get_valid_name(net, dev->name, dev->name, 0);
+ if (ret)
goto err_uninit;
- }
dev->ifindex = dev_new_index(net);
if (dev->iflink == -1)
dev->iflink = dev->ifindex;
- /* Check for existence of name */
- head = dev_name_hash(net, dev->name);
- hlist_for_each(p, head) {
- struct net_device *d
- = hlist_entry(p, struct net_device, name_hlist);
- if (!strncmp(d->name, dev->name, IFNAMSIZ)) {
- ret = -EEXIST;
- goto err_uninit;
- }
- }
-
/* Fix illegal checksum combinations */
if ((dev->features & NETIF_F_HW_CSUM) &&
(dev->features & (NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))) {
@@ -5422,8 +5416,6 @@ EXPORT_SYMBOL(unregister_netdev);
int dev_change_net_namespace(struct net_device *dev, struct net *net, const char *pat)
{
- char buf[IFNAMSIZ];
- const char *destname;
int err;
ASSERT_RTNL();
@@ -5456,20 +5448,11 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char
* we can use it in the destination network namespace.
*/
err = -EEXIST;
- destname = dev->name;
- if (__dev_get_by_name(net, destname)) {
+ if (__dev_get_by_name(net, dev->name)) {
/* We get here if we can't use the current device name */
if (!pat)
goto out;
- if (!dev_valid_name(pat))
- goto out;
- if (strchr(pat, '%')) {
- if (__dev_alloc_name(net, pat, buf) < 0)
- goto out;
- destname = buf;
- } else
- destname = pat;
- if (__dev_get_by_name(net, destname))
+ if (dev_get_valid_name(net, pat, dev->name, 1))
goto out;
}
@@ -5505,10 +5488,6 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char
/* Actually switch the network namespace */
dev_net_set(dev, net);
- /* Assign the new device name */
- if (destname != dev->name)
- strcpy(dev->name, destname);
-
/* If there is an ifindex conflict assign a new one */
if (__dev_get_by_index(net, dev->ifindex)) {
int iflink = (dev->iflink == dev->ifindex);
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 1/2] net: introduce NETDEV_UNREGISTER_PERNET
From: David Miller @ 2009-11-18 13:04 UTC (permalink / raw)
To: opurdila; +Cc: netdev, eric.dumazet
In-Reply-To: <200911170149.35240.opurdila@ixiacom.com>
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Tue, 17 Nov 2009 01:49:35 +0200
> This new event is called once for each unique net namespace in batched
> unregister operations (with the argument set to a random device from
> that namespace) and once per device in non-batched unregister
> operations.
>
> It allows us to factorize some device unregister work such as clearing the
> routing cache.
>
> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/2] ipv4: factorize cache clearing for batched unregister operations
From: David Miller @ 2009-11-18 13:04 UTC (permalink / raw)
To: opurdila; +Cc: netdev, eric.dumazet
In-Reply-To: <200911170149.50011.opurdila@ixiacom.com>
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Tue, 17 Nov 2009 01:49:49 +0200
> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: PATCH net-next-2.6] linkwatch: linkwatch_forget_dev() to speedup device dismantle
From: David Miller @ 2009-11-18 13:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: herbert, shemminger, netdev
In-Reply-To: <4B02C859.6020100@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 17 Nov 2009 16:59:21 +0100
> Herbert Xu a écrit :
>> On Tue, Nov 17, 2009 at 04:26:04AM -0800, David Miller wrote:
>>> Really, the link watch stuff is just due for a redesign. I don't
>>> think a simple hack is going to cut it this time, sorry Eric :-)
>>
>> I have no objections against any redesigns, but since the only
>> caller of linkwatch_forget_dev runs in process context with the
>> RTNL, it could also legally emit those events.
>
> Thanks guys, here an updated version then, before linkwatch surgery ?
Sure, applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [net-next] bnx2x: Don't set netdev->trans_start
From: David Miller @ 2009-11-18 13:06 UTC (permalink / raw)
To: vladz; +Cc: netdev
In-Reply-To: <1258474595.32030.1.camel@lb-tlvb-vladz.il.broadcom.com>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Tue, 17 Nov 2009 18:16:35 +0200
> Setting dev->trans_start caused spurious watchdog warnings.
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] can: fix setting mcp251x bit timing on open
From: David Miller @ 2009-11-18 13:06 UTC (permalink / raw)
To: wg; +Cc: chripell, socketcan-core, netdev, pthomas8589
In-Reply-To: <4B02CDFA.6040700@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Tue, 17 Nov 2009 17:23:22 +0100
> Christian Pellegrin wrote:
>> Signed-off-by: Christian Pellegrin <chripell@fsfe.org>
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] netns: net_identifiers should be read_mostly
From: David Miller @ 2009-11-18 13:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4B030AC9.3050709@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 17 Nov 2009 21:42:49 +0100
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 1/1] qlge: Bonding fix for mode 6.
From: David Miller @ 2009-11-18 13:07 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1258492240-24554-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Tue, 17 Nov 2009 13:10:40 -0800
> Allow MAC address to be changed even if device is not up.
>
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Applied.
^ permalink raw reply
* Re: [patch 1/1] drivers/atm/solos-pci.c: fix warning/bug, clean up code
From: David Miller @ 2009-11-18 13:07 UTC (permalink / raw)
To: david.woodhouse; +Cc: akpm, netdev, chas, nathan
In-Reply-To: <1258498555.6132.71.camel@macbook.infradead.org>
From: David Woodhouse <david.woodhouse@intel.com>
Date: Tue, 17 Nov 2009 22:55:55 +0000
> On Tue, 2009-11-17 at 14:46 -0800, akpm@linux-foundation.org wrote:
>> From: Andrew Morton <akpm@linux-foundation.org>
>>
>> drivers/atm/solos-pci.c: In function 'flash_upgrade':
>> drivers/atm/solos-pci.c:528: warning: 'fw_name' may be used uninitialized in this function
>>
>> Cc: Chas Williams <chas@cmf.nrl.navy.mil>
>> Cc: Nathan Williams <nathan@traverse.com.au>
>> Cc: David S. Miller <davem@davemloft.net>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: device name allocation cleanups
From: David Miller @ 2009-11-18 13:07 UTC (permalink / raw)
To: opurdila; +Cc: shemminger, netdev
In-Reply-To: <200911181436.59261.opurdila@ixiacom.com>
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Wed, 18 Nov 2009 14:36:59 +0200
> Thanks for your help ! Here is a new version which addresses the spotted issues:
>
> [net-next-2.6 PATCH] net: device name allocation cleanups
>
> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Fix EMACx_TRTR[TRT] bit shifts
From: David Miller @ 2009-11-18 13:11 UTC (permalink / raw)
To: sr; +Cc: linuxppc-dev, dmitchell, netdev, linuxppc-dev, benh
In-Reply-To: <200911181107.51661.sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Wed, 18 Nov 2009 11:07:51 +0100
> On Wednesday 18 November 2009 01:56:55 Dave Mitchell wrote:
>> The TRT bit shifts were reversed for EMAC4 and non-EMAC4 during the
>> port from ibm_emac to ibm_newemac. This patch corrects that error.
>>
>> Signed-off-by: Dave Mitchell <dmitchell@appliedmicro.com>
>> Acked-by: Feng Kan <fkan@appliedmicro.com>
>> Acked-by: Prodyut Hazarika <phazarika@appliedmicro.com>
>
> Acked-by: Stefan Roese <sr@denx.de>
>
> Would be great if this could go into 2.6.32. Thanks.
Applied to net-2.6, thanks.
^ permalink raw reply
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