Re: [NETFILTER]: Introduce nf_inet_address

2008-02-22 Thread David Woodhouse

On Fri, 2008-02-22 at 16:52 +0900, David Woodhouse wrote:
 
 It looks like iptables is fairly broken anyway:
 
 make[1]: Entering directory
 `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
 Unable to resolve dependency on linux/compiler.h. Try 'make clean'.

And if I move away the contents of the local include/linux/ directory
and replace it with proper headers generated by 'make
headers_install' (which won't be trying to include compiler.h), then I
get more failures:

Unable to resolve dependency on ../include/linux/netfilter/xt_u32.h. Try 'make 
clean'.
Unable to resolve dependency on linux/netfilter/xt_time.h. Try 'make clean'.
Unable to resolve dependency on linux/netfilter/xt_quota.h. Try 'make clean'.
Unable to resolve dependency on ../include/linux/netfilter/xt_connlimit.h. Try 
'make clean'.
Unable to resolve dependency on linux/netfilter_ipv6/ip6t_mh.h. Try 'make 
clean'.
Unable to resolve dependency on linux/netfilter/nf_nat.h. Try 'make clean'.

In file included from include/linux/netfilter/xt_conntrack.h:10,
 from 
extensions/../include/linux/netfilter_ipv4/ipt_conntrack.h:9,
 from extensions/libipt_conntrack.c:15:
/usr/include/linux/in.h:26: error: redeclaration of enumerator ‘IPPROTO_IP’
/usr/include/netinet/in.h:34: error: previous definition of ‘IPPROTO_IP’ was 
here

-- 
dwmw2

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?

2008-02-22 Thread Kay Sievers
On Tue, Feb 19, 2008 at 9:47 AM, Kay Sievers [EMAIL PROTECTED] wrote:
 On Feb 18, 2008 9:06 PM, Stephen Hemminger [EMAIL PROTECTED] wrote:
   On Mon, 18 Feb 2008 19:42:25 + (GMT)
   Chris Rankin [EMAIL PROTECTED] wrote:
  
--- Stephen Hemminger [EMAIL PROTECTED] wrote:
   sysfs: duplicate filename 'bridge' can not be created
   WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
   Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
[c0105020] show_trace_log_lvl+0x1a/0x2f
[c0105990] show_trace+0x12/0x14
[c010613d] dump_stack+0x6c/0x72
[c01991bf] sysfs_add_one+0x57/0xbc
[c0199e41] sysfs_create_link+0xc2/0x10d
[c01bae9a] pci_bus_add_devices+0xbd/0x103
[c034016c] pci_legacy_init+0x56/0xe3
[c03274e1] kernel_init+0x157/0x2c3
[c0104c83] kernel_thread_helper+0x7/0x10
===
   pci :00:01.0: Error creating sysfs bridge symlink, 
 continuing...
   sysfs: duplicate filename 'bridge' can not be created
   WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()

Greg,
it seems that:
  arch/x86/pci/legacy.c :: pci_legacy_init()

tries to create already created bridge symlinks in 2.6.24. So we
discover the same devices twice? Can this be a reason for the hang?

I guess in 2.6.25, the warning is gone with:
  commit fd7d1ced29e5beb88c9068801da7a362606d8273
  Author: Greg Kroah-Hartman [EMAIL PROTECTED]
  Date:   Tue May 22 22:47:54 2007 -0400

  PCI: make pci_bus a struct device

  This moves the pci_bus class device to be a real struct device and at
  the same time, place it in the device tree in the correct location.
  Note, the old bridge symlink is now gone.

Thanks,
Kay
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH][NEIGH]: Fix race between neighbor lookup and table's hash_rnd update.

2008-02-22 Thread Pavel Emelyanov
The neigh_hash_grow() may update the tbl-hash_rnd value, which 
is used in all tbl-hash callbacks to calculate the hashval.

Two lookup routines may race with this, since they call the 
-hash callback without the tbl-lock held. Since the hash_rnd
is changed with this lock write-locked moving the calls to -hash
under this lock read-locked closes this gap.

Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]

---

diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 4062b88..2328acb 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -358,11 +358,12 @@ struct neighbour *neigh_lookup(struct neigh_table *tbl, 
const void *pkey,
 {
struct neighbour *n;
int key_len = tbl-key_len;
-   u32 hash_val = tbl-hash(pkey, dev);
+   u32 hash_val;
 
NEIGH_CACHE_STAT_INC(tbl, lookups);
 
read_lock_bh(tbl-lock);
+   hash_val = tbl-hash(pkey, dev);
for (n = tbl-hash_buckets[hash_val  tbl-hash_mask]; n; n = n-next) {
if (dev == n-dev  !memcmp(n-primary_key, pkey, key_len)) {
neigh_hold(n);
@@ -379,11 +380,12 @@ struct neighbour *neigh_lookup_nodev(struct neigh_table 
*tbl, struct net *net,
 {
struct neighbour *n;
int key_len = tbl-key_len;
-   u32 hash_val = tbl-hash(pkey, NULL);
+   u32 hash_val;
 
NEIGH_CACHE_STAT_INC(tbl, lookups);
 
read_lock_bh(tbl-lock);
+   hash_val = tbl-hash(pkey, NULL);
for (n = tbl-hash_buckets[hash_val  tbl-hash_mask]; n; n = n-next) {
if (!memcmp(n-primary_key, pkey, key_len) 
(net == n-dev-nd_net)) {
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?

2008-02-22 Thread Chris Rankin
--- Kay Sievers [EMAIL PROTECTED] wrote:
 Greg,
 it seems that:
   arch/x86/pci/legacy.c :: pci_legacy_init()
 
 tries to create already created bridge symlinks in 2.6.24. So we
 discover the same devices twice? Can this be a reason for the hang?

No, it can't be because it's *not* hanging in this configuration :-). It hangs 
when I *don't* add
the acpi=noirq option, whereas here it's just adding noise to the dmesg log. 
(I'm guessing Linux
doesn't call pci_legacy_init() when ACPI takes charge of the IRQs.)

Cheers,
Chris



  __
Sent from Yahoo! Mail.
A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()

2008-02-22 Thread Daniel Lezcano

Eric Dumazet wrote:

Daniel Lezcano a écrit :

Eric Dumazet wrote:

Hi David

This is an RFC, based on net-2.6 for convenience only.

Thank you

[RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()

Loopback transmit function loopback_xmit() actually calls netif_rx() 
to queue
a skb to the softnet queue, and arms a softirq so that this skb can 
be handled later.


This has a cost on SMP, because we need to hold a reference on the 
device, and free this

reference when softirq dequeues packet.

Following patch directly calls netif_receive_skb() and avoids lot of 
atomic operations.
(atomic_inc(dev-refcnt), set_and_set_bit(NAPI_STATE_SCHED, 
n-state), ...
 atomic_dec(dev-refcnt)...), cache line ping-pongs on device 
refcnt, but also softirq overhead.


This gives a nice boost on tbench for example (5 % on my machine)


I understand this is interesting for the loopback when there is no 
multiple instances of it and it can't be unregistered. But now with 
the network namespaces, we can have multiple instances of the loopback 
and it can to be unregistered. Shouldn't we still use netif_rx ?

Perhaps we can do something like:

if (dev-nd_net == init_net)
netif_receive_skb(skb);
else
netif_rx(skb);


or

#ifdef CONFIG_NET_NS
if (dev-nd_net != init_net)
netif_rx(skb);
else
#endif
netif_receive_skb(skb);



Or we create:
init_loopback_xmit() calling netif_receive_skb(skb);
and setup this function when creating the loopback for init_net,
otherwise we setup the usual loopback_xmit.

We are still safe for multiple network namespaces and we have the 
improvement for init_net loopback.




I dont understand how my patch could degrade loopbackdev unregister 
logic. It should only help it, by avoiding a queue of 'pending packets' 
per cpu.


When we want to unregister a network device, stack makes sure that no 
more calls to dev-hard_start_xmit() can occur.


If no more loopback_xmit() calls are done on this device, it doesnt 
matter if it internally uses netif_rx() or netif_receive_skb(skb)


loopback device has no queue, its really unfortunate to use the 
'softirq' internal queue.


Fair enough :)

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 00/04] smc91x: request bus width using platform data V2

2008-02-22 Thread Magnus Damm
These patches make it possible to request bus width in the platform data.

Instead of keep on updating smc91x.h with board specific configuration,
use platform data to pass along bus width and irq flags to the driver.
This change is designed to be backwards-compatible, so all boards configured
in the header file should just work as usual.

[PATCH 01/04] smc91x: pass along private data V2
[PATCH 02/04] smc91x: introduce platform data flags V2
[PATCH 03/04] smc91x: add insw/outsw to default config V2
[PATCH 04/04] smc91x: make superh use default config V2

Tested with and without platform data on a SuperH sh7722 MigoR board.

V2 changes the macro argument name to lp and adds SMC_DYNAMIC_BUS_CONFIG.

Signed-off-by: Magnus Damm [EMAIL PROTECTED]
---

 drivers/net/smc91x.c   |  335 +-
 drivers/net/smc91x.h   |  343 +++-
 include/linux/smc91x.h |   13 +
 3 files changed, 359 insertions(+), 332 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: lockdep warning

2008-02-22 Thread Jiri Kosina
On Fri, 22 Feb 2008, Anders Eriksson wrote:

 I found this is a newly booted 2.6.25-rc2's syslog.
 Feb 21 20:46:33 tippex BUG: rwlock wrong owner on CPU#0, runscript.sh/2633, 
 d2c04084
 Feb 21 20:46:33 tippex Pid: 2633, comm: runscript.sh Not tainted 2.6.25-rc2 #3
 Feb 21 20:46:33 tippex [c02342d0] rwlock_bug+0x50/0x60
 Feb 21 20:46:33 tippex [c0234356] _raw_write_unlock+0x56/0x60
 Feb 21 20:46:33 tippex [c040365d] _write_unlock+0x1d/0x50
 Feb 21 20:46:33 tippex [c03289be] neigh_timer_handler+0x18e/0x2d0
 Feb 21 20:46:33 tippex [c0125449] run_timer_softirq+0x119/0x180
 Feb 21 20:46:33 tippex [c013856d] ? lock_release_holdtime+0x5d/0x80
 Feb 21 20:46:33 tippex [c0328830] ? neigh_timer_handler+0x0/0x2d0
 Feb 21 20:46:33 tippex [c0121a64] __do_softirq+0x54/0xb0
 Feb 21 20:46:33 tippex [c0121af5] do_softirq+0x35/0x40
 Feb 21 20:46:33 tippex [c0121cb4] irq_exit+0x44/0x50
 Feb 21 20:46:33 tippex [c0105757] do_IRQ+0x47/0x80
 Feb 21 20:46:33 tippex [c01039c3] common_interrupt+0x23/0x28
 Feb 21 20:46:33 tippex ===

This needs to be CCed to netdev.

Any chance that

git revert 69cc64d8d92

makes this report go away?

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 01/04] smc91x: pass along private data V2

2008-02-22 Thread Magnus Damm
Pass a private data pointer to macros and functions. This makes it easy
to later on make run time decisions. This patch does not change any logic.
These changes should be optimized away during compilation.

V2 changes the macro argument name from priv to lp.

Signed-off-by: Magnus Damm [EMAIL PROTECTED]
---

 drivers/net/smc91x.c |  301 +-
 drivers/net/smc91x.h |  254 +-
 2 files changed, 280 insertions(+), 275 deletions(-)

--- 0001/drivers/net/smc91x.c
+++ work/drivers/net/smc91x.c   2008-02-22 14:07:43.0 +0900
@@ -220,22 +220,22 @@ static void PRINT_PKT(u_char *buf, int l
 
 
 /* this enables an interrupt in the interrupt mask register */
-#define SMC_ENABLE_INT(x) do { \
+#define SMC_ENABLE_INT(lp, x) do { \
unsigned char mask; \
spin_lock_irq(lp-lock);   \
-   mask = SMC_GET_INT_MASK();  \
+   mask = SMC_GET_INT_MASK(lp);\
mask |= (x);\
-   SMC_SET_INT_MASK(mask); \
+   SMC_SET_INT_MASK(lp, mask); \
spin_unlock_irq(lp-lock); \
 } while (0)
 
 /* this disables an interrupt from the interrupt mask register */
-#define SMC_DISABLE_INT(x) do {
\
+#define SMC_DISABLE_INT(lp, x) do {\
unsigned char mask; \
spin_lock_irq(lp-lock);   \
-   mask = SMC_GET_INT_MASK();  \
+   mask = SMC_GET_INT_MASK(lp);\
mask = ~(x);   \
-   SMC_SET_INT_MASK(mask); \
+   SMC_SET_INT_MASK(lp, mask); \
spin_unlock_irq(lp-lock); \
 } while (0)
 
@@ -244,10 +244,10 @@ static void PRINT_PKT(u_char *buf, int l
  * if at all, but let's avoid deadlocking the system if the hardware
  * decides to go south.
  */
-#define SMC_WAIT_MMU_BUSY() do {   \
-   if (unlikely(SMC_GET_MMU_CMD()  MC_BUSY)) {\
+#define SMC_WAIT_MMU_BUSY(lp) do { \
+   if (unlikely(SMC_GET_MMU_CMD(lp)  MC_BUSY)) {  \
unsigned long timeout = jiffies + 2;\
-   while (SMC_GET_MMU_CMD()  MC_BUSY) {   \
+   while (SMC_GET_MMU_CMD(lp)  MC_BUSY) { \
if (time_after(jiffies, timeout)) { \
printk(%s: timeout %s line %d\n,  \
dev-name, __FILE__, __LINE__); \
@@ -273,8 +273,8 @@ static void smc_reset(struct net_device 
 
/* Disable all interrupts, block TX tasklet */
spin_lock_irq(lp-lock);
-   SMC_SELECT_BANK(2);
-   SMC_SET_INT_MASK(0);
+   SMC_SELECT_BANK(lp, 2);
+   SMC_SET_INT_MASK(lp, 0);
pending_skb = lp-pending_tx_skb;
lp-pending_tx_skb = NULL;
spin_unlock_irq(lp-lock);
@@ -290,15 +290,15 @@ static void smc_reset(struct net_device 
 * This resets the registers mostly to defaults, but doesn't
 * affect EEPROM.  That seems unnecessary
 */
-   SMC_SELECT_BANK(0);
-   SMC_SET_RCR(RCR_SOFTRST);
+   SMC_SELECT_BANK(lp, 0);
+   SMC_SET_RCR(lp, RCR_SOFTRST);
 
/*
 * Setup the Configuration Register
 * This is necessary because the CONFIG_REG is not affected
 * by a soft reset
 */
-   SMC_SELECT_BANK(1);
+   SMC_SELECT_BANK(lp, 1);
 
cfg = CONFIG_DEFAULT;
 
@@ -316,7 +316,7 @@ static void smc_reset(struct net_device 
 */
cfg |= CONFIG_EPH_POWER_EN;
 
-   SMC_SET_CONFIG(cfg);
+   SMC_SET_CONFIG(lp, cfg);
 
/* this should pause enough for the chip to be happy */
/*
@@ -329,12 +329,12 @@ static void smc_reset(struct net_device 
udelay(1);
 
/* Disable transmit and receive functionality */
-   SMC_SELECT_BANK(0);
-   SMC_SET_RCR(RCR_CLEAR);
-   SMC_SET_TCR(TCR_CLEAR);
+   SMC_SELECT_BANK(lp, 0);
+   SMC_SET_RCR(lp, RCR_CLEAR);
+   SMC_SET_TCR(lp, TCR_CLEAR);
 
-   SMC_SELECT_BANK(1);
-   ctl = SMC_GET_CTL() | CTL_LE_ENABLE;
+   SMC_SELECT_BANK(lp, 1);
+   ctl = SMC_GET_CTL(lp) | CTL_LE_ENABLE;
 
/*
 * Set the control register to automatically release successfully
@@ 

[PATCH 03/04] smc91x: add insw/outsw to default config V2

2008-02-22 Thread Magnus Damm
This patch makes sure SMC_insw()/SMC_outsw() are defined for the
default configuration. Without this change BUG()s will be triggered
when using 16-bit only platform data and the default configuration.

Signed-off-by: Magnus Damm [EMAIL PROTECTED]
---

 drivers/net/smc91x.h |2 ++
 1 file changed, 2 insertions(+)

--- 0003/drivers/net/smc91x.h
+++ work/drivers/net/smc91x.h   2008-02-22 15:25:39.0 +0900
@@ -476,6 +476,8 @@ static inline void LPD7_SMC_outsw (unsig
 #define SMC_outb(v, a, r)  writeb(v, (a) + (r))
 #define SMC_outw(v, a, r)  writew(v, (a) + (r))
 #define SMC_outl(v, a, r)  writel(v, (a) + (r))
+#define SMC_insw(a, r, p, l)   readsw((a) + (r), p, l)
+#define SMC_outsw(a, r, p, l)  writesw((a) + (r), p, l)
 #define SMC_insl(a, r, p, l)   readsl((a) + (r), p, l)
 #define SMC_outsl(a, r, p, l)  writesl((a) + (r), p, l)
 
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 04/04] smc91x: make superh use default config V2

2008-02-22 Thread Magnus Damm
Removes superh board specific configuration from the header file. These boards
will instead be configured using platform data.

Signed-off-by: Magnus Damm [EMAIL PROTECTED]
---

 drivers/net/smc91x.h |   30 --
 1 file changed, 30 deletions(-)

--- 0004/drivers/net/smc91x.h
+++ work/drivers/net/smc91x.h   2008-02-22 15:26:42.0 +0900
@@ -292,36 +292,6 @@ SMC_outw(u16 val, void __iomem *ioaddr, 
 #define SMC_insw(a, r, p, l)   insw((a) + (r), p, l)
 #define SMC_outsw(a, r, p, l)  outsw((a) + (r), p, l)
 
-#elif   defined(CONFIG_SUPERH)
-
-#ifdef CONFIG_SOLUTION_ENGINE
-#define SMC_IRQ_FLAGS  (0)
-#define SMC_CAN_USE_8BIT   0
-#define SMC_CAN_USE_16BIT  1
-#define SMC_CAN_USE_32BIT  0
-#define SMC_IO_SHIFT   0
-#define SMC_NOWAIT 1
-
-#define SMC_inw(a, r)  inw((a) + (r))
-#define SMC_outw(v, a, r)  outw(v, (a) + (r))
-#define SMC_insw(a, r, p, l)   insw((a) + (r), p, l)
-#define SMC_outsw(a, r, p, l)  outsw((a) + (r), p, l)
-
-#else /* BOARDS */
-
-#define SMC_CAN_USE_8BIT   1
-#define SMC_CAN_USE_16BIT  1
-#define SMC_CAN_USE_32BIT  0
-
-#define SMC_inb(a, r)  inb((a) + (r))
-#define SMC_inw(a, r)  inw((a) + (r))
-#define SMC_outb(v, a, r)  outb(v, (a) + (r))
-#define SMC_outw(v, a, r)  outw(v, (a) + (r))
-#define SMC_insw(a, r, p, l)   insw((a) + (r), p, l)
-#define SMC_outsw(a, r, p, l)  outsw((a) + (r), p, l)
-
-#endif  /* BOARDS */
-
 #elif   defined(CONFIG_M32R)
 
 #define SMC_CAN_USE_8BIT   0
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 02/04] smc91x: introduce platform data flags V2

2008-02-22 Thread Magnus Damm
This patch introduces struct smc91x_platdata and modifies the driver so
bus width is checked during run time using SMC_nBIT() instead of
SMC_CAN_USE_nBIT.

V2 keeps static configuration lean using SMC_DYNAMIC_BUS_CONFIG.

Signed-off-by: Magnus Damm [EMAIL PROTECTED]
---

 drivers/net/smc91x.c   |   34 
 drivers/net/smc91x.h   |   57 +---
 include/linux/smc91x.h |   13 ++
 3 files changed, 77 insertions(+), 27 deletions(-)

--- 0002/drivers/net/smc91x.c
+++ work/drivers/net/smc91x.c   2008-02-22 15:11:44.0 +0900
@@ -1997,6 +1997,8 @@ err_out:
 
 static int smc_enable_device(struct platform_device *pdev)
 {
+   struct net_device *ndev = platform_get_drvdata(pdev);
+   struct smc_local *lp = netdev_priv(ndev);
unsigned long flags;
unsigned char ecor, ecsr;
void __iomem *addr;
@@ -2039,7 +2041,7 @@ static int smc_enable_device(struct plat
 * Set the appropriate byte/word mode.
 */
ecsr = readb(addr + (ECSR  SMC_IO_SHIFT))  ~ECSR_IOIS8;
-   if (!SMC_CAN_USE_16BIT)
+   if (!SMC_16BIT(lp))
ecsr |= ECSR_IOIS8;
writeb(ecsr, addr + (ECSR  SMC_IO_SHIFT));
local_irq_restore(flags);
@@ -2124,10 +2126,11 @@ static void smc_release_datacs(struct pl
  */
 static int smc_drv_probe(struct platform_device *pdev)
 {
+   struct smc91x_platdata *pd = pdev-dev.platform_data;
+   struct smc_local *lp;
struct net_device *ndev;
struct resource *res, *ires;
unsigned int __iomem *addr;
-   unsigned long irq_flags = SMC_IRQ_FLAGS;
int ret;
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, smc91x-regs);
@@ -2152,6 +2155,27 @@ static int smc_drv_probe(struct platform
}
SET_NETDEV_DEV(ndev, pdev-dev);
 
+   /* get configuration from platform data, only allow use of
+* bus width if both SMC_CAN_USE_xxx and SMC91X_USE_xxx are set.
+*/
+
+   lp = netdev_priv(ndev);
+   lp-cfg.irq_flags = SMC_IRQ_FLAGS;
+
+#ifdef SMC_DYNAMIC_BUS_CONFIG
+   if (pd)
+   memcpy(lp-cfg, pd, sizeof(lp-cfg));
+   else {
+   lp-cfg.flags = SMC91X_USE_8BIT;
+   lp-cfg.flags |= SMC91X_USE_16BIT;
+   lp-cfg.flags |= SMC91X_USE_32BIT;
+   }
+
+   lp-cfg.flags = ~(SMC_CAN_USE_8BIT ? 0 : SMC91X_USE_8BIT);
+   lp-cfg.flags = ~(SMC_CAN_USE_16BIT ? 0 : SMC91X_USE_16BIT);
+   lp-cfg.flags = ~(SMC_CAN_USE_32BIT ? 0 : SMC91X_USE_32BIT);
+#endif
+
ndev-dma = (unsigned char)-1;
 
ires = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -2162,7 +2186,7 @@ static int smc_drv_probe(struct platform
 
ndev-irq = ires-start;
if (SMC_IRQ_FLAGS == -1)
-   irq_flags = ires-flags  IRQF_TRIGGER_MASK;
+   lp-cfg.irq_flags = ires-flags  IRQF_TRIGGER_MASK;
 
ret = smc_request_attrib(pdev);
if (ret)
@@ -2170,6 +2194,7 @@ static int smc_drv_probe(struct platform
 #if defined(CONFIG_SA1100_ASSABET)
NCR_0 |= NCR_ENET_OSC_EN;
 #endif
+   platform_set_drvdata(pdev, ndev);
ret = smc_enable_device(pdev);
if (ret)
goto out_release_attrib;
@@ -2188,8 +2213,7 @@ static int smc_drv_probe(struct platform
}
 #endif
 
-   platform_set_drvdata(pdev, ndev);
-   ret = smc_probe(ndev, addr, irq_flags);
+   ret = smc_probe(ndev, addr, lp-cfg.irq_flags);
if (ret != 0)
goto out_iounmap;
 
--- 0002/drivers/net/smc91x.h
+++ work/drivers/net/smc91x.h   2008-02-22 15:01:30.0 +0900
@@ -34,6 +34,7 @@
 #ifndef _SMC91X_H_
 #define _SMC91X_H_
 
+#include linux/smc91x.h
 
 /*
  * Define your architecture specific bus configuration parameters here.
@@ -481,6 +482,7 @@ static inline void LPD7_SMC_outsw (unsig
 #define RPC_LSA_DEFAULTRPC_LED_100_10
 #define RPC_LSB_DEFAULTRPC_LED_TX_RX
 
+#define SMC_DYNAMIC_BUS_CONFIG
 #endif
 
 
@@ -526,8 +528,19 @@ struct smc_local {
 #endif
void __iomem *base;
void __iomem *datacs;
+
+   struct smc91x_platdata cfg;
 };
 
+#ifdef SMC_DYNAMIC_BUS_CONFIG
+#define SMC_8BIT(p) (((p)-cfg.flags  SMC91X_USE_8BIT)  SMC_CAN_USE_8BIT)
+#define SMC_16BIT(p) (((p)-cfg.flags  SMC91X_USE_16BIT)  SMC_CAN_USE_16BIT)
+#define SMC_32BIT(p) (((p)-cfg.flags  SMC91X_USE_32BIT)  SMC_CAN_USE_32BIT)
+#else
+#define SMC_8BIT(p) SMC_CAN_USE_8BIT
+#define SMC_16BIT(p) SMC_CAN_USE_16BIT
+#define SMC_32BIT(p) SMC_CAN_USE_32BIT
+#endif
 
 #ifdef SMC_USE_PXA_DMA
 /*
@@ -1108,41 +1121,41 @@ static const char * chip_ids[ 16 ] =  {
  *
  * Enforce it on any 32-bit capable setup for now.
  */
-#define SMC_MUST_ALIGN_WRITE   SMC_CAN_USE_32BIT
+#define SMC_MUST_ALIGN_WRITE(lp)   SMC_32BIT(lp)
 
 #define SMC_GET_PN(lp) \
-   (SMC_CAN_USE_8BIT   ? (SMC_inb(ioaddr, PN_REG(lp))) \
+   (SMC_8BIT(lp)   ? 

Re: [PATCH] Fix multicast on VLAN interfaces

2008-02-22 Thread Patrick McHardy

Phil Oester wrote:

In commit 56addd6eeeb4e11f5a0af7093ca078e0f29140e0 the VLAN multicast list
handling was reworked.  Unfortunately, a variable initialization was missed,
and multicast over vlan devices has been broken since 2.6.23-rc1 (apparently
not too many people use this).  Trivial fix below, which might be a candidate
for -stable.


Thanks Phil, a similar patch is already sitting in net-2.6.git.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RTNL]: Validate hardware and broadcast address attribute for RTM_NEWLINK

2008-02-22 Thread Patrick McHardy

Thomas Graf wrote:

RTM_NEWLINK allows for already existing links to be modified. For this
purpose do_setlink() is called which expects address attributes with a
payload length of at least dev-addr_len. This patch adds the necessary
validation for the RTM_NEWLINK case.

The address length for links to be created is not checked for now as the
actual attribute length is used when copying the address to the netdevice
structure. It might make sense to report an error if less than addr_len
bytes are provided but enforcing this might break drivers trying to be
smart with not transmitting all zero addresses.

Signed-off-by: Thomas Graf [EMAIL PROTECTED]

Index: net-2.6.26/net/core/rtnetlink.c
===
--- net-2.6.26.orig/net/core/rtnetlink.c2008-02-22 01:50:53.0 
+0100
+++ net-2.6.26/net/core/rtnetlink.c 2008-02-22 11:28:59.0 +0100
@@ -726,6 +726,21 @@
return net;
 }
 
+static int validate_linkmsg(struct net_device *dev, struct nlattr *tb[])

+{
+   if (dev) {
+   if (tb[IFLA_ADDRESS] 
+   nla_len(tb[IFLA_ADDRESS])  dev-addr_len)
+   return -EINVAL;
+
+   if (tb[IFLA_BROADCAST] 
+   nla_len(tb[IFLA_BROADCAST])  dev-addr_len)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
  struct nlattr **tb, char *ifname, int modified)
 {
@@ -910,12 +925,7 @@
goto errout;
}
 
-	if (tb[IFLA_ADDRESS] 

-   nla_len(tb[IFLA_ADDRESS])  dev-addr_len)
-   goto errout_dev;
-
-   if (tb[IFLA_BROADCAST] 
-   nla_len(tb[IFLA_BROADCAST])  dev-addr_len)
+   if ((err = validate_linkmsg(dev, tb))  0)
goto errout_dev;
 
 	err = do_setlink(dev, ifm, tb, ifname, 0);

@@ -1036,6 +1046,9 @@
else
dev = NULL;
 
+	if ((err = validate_linkmsg(dev, tb))  0)

+   return err;
+


Minor nitpick: it would be more logical to put this in the

if (dev) {
 ...

branch a bit below since thats the only path that leads to
do_setlink(). That would also allow to remove the
if (dev) check from validate_linkmsg().
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Taiwan's glory--computer industry

2008-02-22 Thread 『Taiwan News Express』


 http://www.taiwannews.com.tw/static/express/080222-01.pdf
http://www.taiwannews.com.tw/static/express/080222-02.pdf
http://www.taiwannews.com.tw/static/express/080222-03.pdf
http://www.taiwannews.com.tw/static/express/080222-04.pdf



 


--
Powered by PHPlist, www.phplist.com --



--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[RTNL]: Validate hardware and broadcast address attribute for RTM_NEWLINK

2008-02-22 Thread Thomas Graf
RTM_NEWLINK allows for already existing links to be modified. For this
purpose do_setlink() is called which expects address attributes with a
payload length of at least dev-addr_len. This patch adds the necessary
validation for the RTM_NEWLINK case.

The address length for links to be created is not checked for now as the
actual attribute length is used when copying the address to the netdevice
structure. It might make sense to report an error if less than addr_len
bytes are provided but enforcing this might break drivers trying to be
smart with not transmitting all zero addresses.

Signed-off-by: Thomas Graf [EMAIL PROTECTED]

Index: net-2.6.26/net/core/rtnetlink.c
===
--- net-2.6.26.orig/net/core/rtnetlink.c2008-02-22 01:50:53.0 
+0100
+++ net-2.6.26/net/core/rtnetlink.c 2008-02-22 11:28:59.0 +0100
@@ -726,6 +726,21 @@
return net;
 }
 
+static int validate_linkmsg(struct net_device *dev, struct nlattr *tb[])
+{
+   if (dev) {
+   if (tb[IFLA_ADDRESS] 
+   nla_len(tb[IFLA_ADDRESS])  dev-addr_len)
+   return -EINVAL;
+
+   if (tb[IFLA_BROADCAST] 
+   nla_len(tb[IFLA_BROADCAST])  dev-addr_len)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
  struct nlattr **tb, char *ifname, int modified)
 {
@@ -910,12 +925,7 @@
goto errout;
}
 
-   if (tb[IFLA_ADDRESS] 
-   nla_len(tb[IFLA_ADDRESS])  dev-addr_len)
-   goto errout_dev;
-
-   if (tb[IFLA_BROADCAST] 
-   nla_len(tb[IFLA_BROADCAST])  dev-addr_len)
+   if ((err = validate_linkmsg(dev, tb))  0)
goto errout_dev;
 
err = do_setlink(dev, ifm, tb, ifname, 0);
@@ -1036,6 +1046,9 @@
else
dev = NULL;
 
+   if ((err = validate_linkmsg(dev, tb))  0)
+   return err;
+
if (tb[IFLA_LINKINFO]) {
err = nla_parse_nested(linkinfo, IFLA_INFO_MAX,
   tb[IFLA_LINKINFO], ifla_info_policy);
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: lockdep warning

2008-02-22 Thread Jiri Kosina
On Fri, 22 Feb 2008, Anders Eriksson wrote:

  This needs to be CCed to netdev.
  Any chance that
  git revert 69cc64d8d92
  makes this report go away? 
 I'll have to install a git repo to check, or maybe you can send me the diff 
 to 
 reverse vs. 2.6.25-rc2?

diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 7bb6a9a..a16cf1e 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -834,12 +834,18 @@ static void neigh_timer_handler(unsigned long arg)
}
if (neigh-nud_state  (NUD_INCOMPLETE | NUD_PROBE)) {
struct sk_buff *skb = skb_peek(neigh-arp_queue);
-
+   /* keep skb alive even if arp_queue overflows */
+   if (skb)
+   skb_get(skb);
+   write_unlock(neigh-lock);
neigh-ops-solicit(neigh, skb);
atomic_inc(neigh-probes);
-   }
+   if (skb)
+   kfree_skb(skb);
+   } else {
 out:
-   write_unlock(neigh-lock);
+   write_unlock(neigh-lock);
+   }
 
if (notify)
neigh_update_notify(neigh);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index c663fa5..8e17f65 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -368,6 +368,7 @@ static void arp_solicit(struct neighbour *neigh, struct 
sk_buff *skb)
if (!(neigh-nud_stateNUD_VALID))
printk(KERN_DEBUG trying to ucast probe in 
NUD_INVALID\n);
dst_ha = neigh-ha;
+   read_lock_bh(neigh-lock);
} else if ((probes -= neigh-parms-app_probes)  0) {
 #ifdef CONFIG_ARPD
neigh_app_ns(neigh);
@@ -377,6 +378,8 @@ static void arp_solicit(struct neighbour *neigh, struct 
sk_buff *skb)
 
arp_send(ARPOP_REQUEST, ETH_P_ARP, target, dev, saddr,
 dst_ha, dev-dev_addr, NULL);
+   if (dst_ha)
+   read_unlock_bh(neigh-lock);
 }
 
 static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH][NET] sock.c: sk_dst_lock lockdep keys and names per af_family

2008-02-22 Thread Jarek Poplawski
On Thu, Feb 21, 2008 at 09:53:56AM +, James Chapman wrote:
...
 The lockups still happen, but I think they are now due to a different  
 problem, as you say.
...

I hope, this patch should help to remove some possibly false lockdep
warnings during this current testing.

Regards,
Jarek P.

---

Subject: [NET] sock.c: sk_dst_lock lockdep keys and names per af_family

Initialize sk_dst_lock lockdep keys and names per af_family.

Additionally some reorder is done in lockdep related code to keep
it in one place and to use static key tables only when needed.


Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]

[not tested]
---

 net/core/sock.c |   79 +++
 1 files changed, 56 insertions(+), 23 deletions(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index 433715f..18c33d2 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -131,14 +131,17 @@
 #include net/tcp.h
 #endif
 
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+
 /*
- * Each address family might have different locking rules, so we have
- * one slock key per address family:
+ * Each address family might have different locking rules, so we have one:
+ * sk_lock, slock, sk_callback_lock and sk_dst_lock key per address family:
  */
 static struct lock_class_key af_family_keys[AF_MAX];
 static struct lock_class_key af_family_slock_keys[AF_MAX];
+static struct lock_class_key af_family_callback_keys[AF_MAX];
+static struct lock_class_key af_family_dst_keys[AF_MAX];
 
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
 /*
  * Make lock validator output more readable. (we pre-construct these
  * strings build-time, so that runtime initialization of socket
@@ -186,13 +189,52 @@ static const char *af_family_clock_key_strings[AF_MAX+1] 
= {
   clock-AF_TIPC  , clock-AF_BLUETOOTH, clock-AF_IUCV ,
   clock-AF_RXRPC , clock-AF_MAX
 };
-#endif
+static const char *af_family_dst_key_strings[AF_MAX+1] = {
+  sk_dst-AF_UNSPEC, sk_dst-AF_UNIX , sk_dst-AF_INET ,
+  sk_dst-AF_AX25  , sk_dst-AF_IPX  , sk_dst-AF_APPLETALK,
+  sk_dst-AF_NETROM, sk_dst-AF_BRIDGE   , sk_dst-AF_ATMPVC   ,
+  sk_dst-AF_X25   , sk_dst-AF_INET6, sk_dst-AF_ROSE ,
+  sk_dst-AF_DECnet, sk_dst-AF_NETBEUI  , sk_dst-AF_SECURITY ,
+  sk_dst-AF_KEY   , sk_dst-AF_NETLINK  , sk_dst-AF_PACKET   ,
+  sk_dst-AF_ASH   , sk_dst-AF_ECONET   , sk_dst-AF_ATMSVC   ,
+  sk_dst-21   , sk_dst-AF_SNA  , sk_dst-AF_IRDA ,
+  sk_dst-AF_PPPOX , sk_dst-AF_WANPIPE  , sk_dst-AF_LLC  ,
+  sk_dst-27   , sk_dst-28  , sk_dst-29  ,
+  sk_dst-AF_TIPC  , sk_dst-AF_BLUETOOTH, sk_dst-AF_IUCV ,
+  sk_dst-AF_RXRPC , sk_dst-AF_MAX
+};
 
-/*
- * sk_callback_lock locking rules are per-address-family,
- * so split the lock classes by using a per-AF key:
- */
-static struct lock_class_key af_callback_keys[AF_MAX];
+
+static inline void sock_lock_init(struct sock *sk)
+{
+   sock_lock_init_class_and_name(sk,
+   af_family_slock_key_strings[sk-sk_family],
+   af_family_slock_keys + sk-sk_family,
+   af_family_key_strings[sk-sk_family],
+   af_family_keys + sk-sk_family);
+}
+
+#define lockdep_set_sk_callback_lock(lock, family) \
+   lockdep_set_class_and_name(lock, \
+   af_family_callback_keys + (family), \
+   af_family_clock_key_strings[(family)])
+
+#define lockdep_set_sk_dst_lock(lock, family) \
+   lockdep_set_class_and_name(lock, \
+   af_family_dst_keys + (family), \
+   af_family_dst_key_strings[(family)])
+
+#else
+
+static inline void sock_lock_init(struct sock *sk)
+{
+   sock_lock_init_class_and_name(sk, 0, 0, 0, 0);
+}
+
+#define lockdep_set_sk_callback_lock(lock, family) do {} while (0)
+#define lockdep_set_sk_dst_lock(lock, family)  do {} while (0)
+
+#endif /* CONFIG_DEBUG_LOCK_ALLOC */
 
 /* Take into consideration the size of the struct sk_buff overhead in the
  * determination of these values, since that is non-constant across
@@ -866,14 +908,6 @@ lenout:
  *
  * (We also register the sk_lock with the lock validator.)
  */
-static inline void sock_lock_init(struct sock *sk)
-{
-   sock_lock_init_class_and_name(sk,
-   af_family_slock_key_strings[sk-sk_family],
-   af_family_slock_keys + sk-sk_family,
-   af_family_key_strings[sk-sk_family],
-   af_family_keys + sk-sk_family);
-}
 
 static void sock_copy(struct sock *nsk, const struct sock *osk)
 {
@@ -1014,10 +1048,10 @@ struct sock *sk_clone(const struct sock *sk, const 
gfp_t priority)
 #endif
 
rwlock_init(newsk-sk_dst_lock);
+   lockdep_set_sk_dst_lock(newsk-sk_dst_lock, newsk-sk_family);
rwlock_init(newsk-sk_callback_lock);
-   

[PATCH] iproute2: fix ip manpage typo (syntax error)

2008-02-22 Thread Andreas Henriksson
Hello Stephen!

The patches branch of the debian packaging repo, at
git://git.debian.org/git/collab-maint/pkg-iproute, now has four patches still
pending. (Not resending, since they've all been posted multiple times before.
Pick them up from the repo if you're interested.)

Here's the latest addition:


commit 3c904bb5933257533f4afecf805ca5a548a8e885
Author: Andreas Henriksson [EMAIL PROTECTED]
Date:   Fri Feb 22 13:57:10 2008 +0100

Fix typo (syntax error) in ip(8) manpage.

Caught by lintian (debian package checker).

diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 1a57a42..c46a9f6 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -940,7 +940,7 @@ Linux-2.x can pack routes into several routing
 tables identified by a number in the range from 1 to 255 or by
 name from the file
 .B /etc/iproute2/rt_tables
-. By default all normal routes are inserted into the
+By default all normal routes are inserted into the
 .B main
 table (ID 254) and the kernel only uses this table when calculating routes.
 


-- 
Regards,
Andreas Henriksson
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 01/04] smc91x: pass along private data V2

2008-02-22 Thread Nicolas Pitre
On Fri, 22 Feb 2008, Magnus Damm wrote:

 Pass a private data pointer to macros and functions. This makes it easy
 to later on make run time decisions. This patch does not change any logic.
 These changes should be optimized away during compilation.
 
 V2 changes the macro argument name from priv to lp.
 
 Signed-off-by: Magnus Damm [EMAIL PROTECTED]

Acked-by: Nicolas Pitre [EMAIL PROTECTED]


 ---
 
  drivers/net/smc91x.c |  301 
 +-
  drivers/net/smc91x.h |  254 +-
  2 files changed, 280 insertions(+), 275 deletions(-)
 
 --- 0001/drivers/net/smc91x.c
 +++ work/drivers/net/smc91x.c 2008-02-22 14:07:43.0 +0900
 @@ -220,22 +220,22 @@ static void PRINT_PKT(u_char *buf, int l
  
  
  /* this enables an interrupt in the interrupt mask register */
 -#define SMC_ENABLE_INT(x) do {   
 \
 +#define SMC_ENABLE_INT(lp, x) do {   \
   unsigned char mask; \
   spin_lock_irq(lp-lock);   \
 - mask = SMC_GET_INT_MASK();  \
 + mask = SMC_GET_INT_MASK(lp);\
   mask |= (x);\
 - SMC_SET_INT_MASK(mask); \
 + SMC_SET_INT_MASK(lp, mask); \
   spin_unlock_irq(lp-lock); \
  } while (0)
  
  /* this disables an interrupt from the interrupt mask register */
 -#define SMC_DISABLE_INT(x) do {  
 \
 +#define SMC_DISABLE_INT(lp, x) do {  \
   unsigned char mask; \
   spin_lock_irq(lp-lock);   \
 - mask = SMC_GET_INT_MASK();  \
 + mask = SMC_GET_INT_MASK(lp);\
   mask = ~(x);   \
 - SMC_SET_INT_MASK(mask); \
 + SMC_SET_INT_MASK(lp, mask); \
   spin_unlock_irq(lp-lock); \
  } while (0)
  
 @@ -244,10 +244,10 @@ static void PRINT_PKT(u_char *buf, int l
   * if at all, but let's avoid deadlocking the system if the hardware
   * decides to go south.
   */
 -#define SMC_WAIT_MMU_BUSY() do { \
 - if (unlikely(SMC_GET_MMU_CMD()  MC_BUSY)) {\
 +#define SMC_WAIT_MMU_BUSY(lp) do {   \
 + if (unlikely(SMC_GET_MMU_CMD(lp)  MC_BUSY)) {  \
   unsigned long timeout = jiffies + 2;\
 - while (SMC_GET_MMU_CMD()  MC_BUSY) {   \
 + while (SMC_GET_MMU_CMD(lp)  MC_BUSY) { \
   if (time_after(jiffies, timeout)) { \
   printk(%s: timeout %s line %d\n,  \
   dev-name, __FILE__, __LINE__); \
 @@ -273,8 +273,8 @@ static void smc_reset(struct net_device 
  
   /* Disable all interrupts, block TX tasklet */
   spin_lock_irq(lp-lock);
 - SMC_SELECT_BANK(2);
 - SMC_SET_INT_MASK(0);
 + SMC_SELECT_BANK(lp, 2);
 + SMC_SET_INT_MASK(lp, 0);
   pending_skb = lp-pending_tx_skb;
   lp-pending_tx_skb = NULL;
   spin_unlock_irq(lp-lock);
 @@ -290,15 +290,15 @@ static void smc_reset(struct net_device 
* This resets the registers mostly to defaults, but doesn't
* affect EEPROM.  That seems unnecessary
*/
 - SMC_SELECT_BANK(0);
 - SMC_SET_RCR(RCR_SOFTRST);
 + SMC_SELECT_BANK(lp, 0);
 + SMC_SET_RCR(lp, RCR_SOFTRST);
  
   /*
* Setup the Configuration Register
* This is necessary because the CONFIG_REG is not affected
* by a soft reset
*/
 - SMC_SELECT_BANK(1);
 + SMC_SELECT_BANK(lp, 1);
  
   cfg = CONFIG_DEFAULT;
  
 @@ -316,7 +316,7 @@ static void smc_reset(struct net_device 
*/
   cfg |= CONFIG_EPH_POWER_EN;
  
 - SMC_SET_CONFIG(cfg);
 + SMC_SET_CONFIG(lp, cfg);
  
   /* this should pause enough for the chip to be happy */
   /*
 @@ -329,12 +329,12 @@ static void smc_reset(struct net_device 
   udelay(1);
  
   /* Disable transmit and receive functionality */
 - SMC_SELECT_BANK(0);
 - SMC_SET_RCR(RCR_CLEAR);
 - SMC_SET_TCR(TCR_CLEAR);
 + SMC_SELECT_BANK(lp, 0);
 + SMC_SET_RCR(lp, RCR_CLEAR);
 + SMC_SET_TCR(lp, TCR_CLEAR);
  
 - SMC_SELECT_BANK(1);
 - ctl = SMC_GET_CTL() | CTL_LE_ENABLE;
 + SMC_SELECT_BANK(lp, 1);
 + ctl = SMC_GET_CTL(lp) | CTL_LE_ENABLE;
  
   /*
* 

Re: [PATCH 02/04] smc91x: introduce platform data flags V2

2008-02-22 Thread Nicolas Pitre
On Fri, 22 Feb 2008, Magnus Damm wrote:

 This patch introduces struct smc91x_platdata and modifies the driver so
 bus width is checked during run time using SMC_nBIT() instead of
 SMC_CAN_USE_nBIT.
 
 V2 keeps static configuration lean using SMC_DYNAMIC_BUS_CONFIG.
 
 Signed-off-by: Magnus Damm [EMAIL PROTECTED]

Acked-by: Nicolas Pitre [EMAIL PROTECTED]

 ---
 
  drivers/net/smc91x.c   |   34 
  drivers/net/smc91x.h   |   57 
 +---
  include/linux/smc91x.h |   13 ++
  3 files changed, 77 insertions(+), 27 deletions(-)
 
 --- 0002/drivers/net/smc91x.c
 +++ work/drivers/net/smc91x.c 2008-02-22 15:11:44.0 +0900
 @@ -1997,6 +1997,8 @@ err_out:
  
  static int smc_enable_device(struct platform_device *pdev)
  {
 + struct net_device *ndev = platform_get_drvdata(pdev);
 + struct smc_local *lp = netdev_priv(ndev);
   unsigned long flags;
   unsigned char ecor, ecsr;
   void __iomem *addr;
 @@ -2039,7 +2041,7 @@ static int smc_enable_device(struct plat
* Set the appropriate byte/word mode.
*/
   ecsr = readb(addr + (ECSR  SMC_IO_SHIFT))  ~ECSR_IOIS8;
 - if (!SMC_CAN_USE_16BIT)
 + if (!SMC_16BIT(lp))
   ecsr |= ECSR_IOIS8;
   writeb(ecsr, addr + (ECSR  SMC_IO_SHIFT));
   local_irq_restore(flags);
 @@ -2124,10 +2126,11 @@ static void smc_release_datacs(struct pl
   */
  static int smc_drv_probe(struct platform_device *pdev)
  {
 + struct smc91x_platdata *pd = pdev-dev.platform_data;
 + struct smc_local *lp;
   struct net_device *ndev;
   struct resource *res, *ires;
   unsigned int __iomem *addr;
 - unsigned long irq_flags = SMC_IRQ_FLAGS;
   int ret;
  
   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, smc91x-regs);
 @@ -2152,6 +2155,27 @@ static int smc_drv_probe(struct platform
   }
   SET_NETDEV_DEV(ndev, pdev-dev);
  
 + /* get configuration from platform data, only allow use of
 +  * bus width if both SMC_CAN_USE_xxx and SMC91X_USE_xxx are set.
 +  */
 +
 + lp = netdev_priv(ndev);
 + lp-cfg.irq_flags = SMC_IRQ_FLAGS;
 +
 +#ifdef SMC_DYNAMIC_BUS_CONFIG
 + if (pd)
 + memcpy(lp-cfg, pd, sizeof(lp-cfg));
 + else {
 + lp-cfg.flags = SMC91X_USE_8BIT;
 + lp-cfg.flags |= SMC91X_USE_16BIT;
 + lp-cfg.flags |= SMC91X_USE_32BIT;
 + }
 +
 + lp-cfg.flags = ~(SMC_CAN_USE_8BIT ? 0 : SMC91X_USE_8BIT);
 + lp-cfg.flags = ~(SMC_CAN_USE_16BIT ? 0 : SMC91X_USE_16BIT);
 + lp-cfg.flags = ~(SMC_CAN_USE_32BIT ? 0 : SMC91X_USE_32BIT);
 +#endif
 +
   ndev-dma = (unsigned char)-1;
  
   ires = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 @@ -2162,7 +2186,7 @@ static int smc_drv_probe(struct platform
  
   ndev-irq = ires-start;
   if (SMC_IRQ_FLAGS == -1)
 - irq_flags = ires-flags  IRQF_TRIGGER_MASK;
 + lp-cfg.irq_flags = ires-flags  IRQF_TRIGGER_MASK;
  
   ret = smc_request_attrib(pdev);
   if (ret)
 @@ -2170,6 +2194,7 @@ static int smc_drv_probe(struct platform
  #if defined(CONFIG_SA1100_ASSABET)
   NCR_0 |= NCR_ENET_OSC_EN;
  #endif
 + platform_set_drvdata(pdev, ndev);
   ret = smc_enable_device(pdev);
   if (ret)
   goto out_release_attrib;
 @@ -2188,8 +2213,7 @@ static int smc_drv_probe(struct platform
   }
  #endif
  
 - platform_set_drvdata(pdev, ndev);
 - ret = smc_probe(ndev, addr, irq_flags);
 + ret = smc_probe(ndev, addr, lp-cfg.irq_flags);
   if (ret != 0)
   goto out_iounmap;
  
 --- 0002/drivers/net/smc91x.h
 +++ work/drivers/net/smc91x.h 2008-02-22 15:01:30.0 +0900
 @@ -34,6 +34,7 @@
  #ifndef _SMC91X_H_
  #define _SMC91X_H_
  
 +#include linux/smc91x.h
  
  /*
   * Define your architecture specific bus configuration parameters here.
 @@ -481,6 +482,7 @@ static inline void LPD7_SMC_outsw (unsig
  #define RPC_LSA_DEFAULT  RPC_LED_100_10
  #define RPC_LSB_DEFAULT  RPC_LED_TX_RX
  
 +#define SMC_DYNAMIC_BUS_CONFIG
  #endif
  
  
 @@ -526,8 +528,19 @@ struct smc_local {
  #endif
   void __iomem *base;
   void __iomem *datacs;
 +
 + struct smc91x_platdata cfg;
  };
  
 +#ifdef SMC_DYNAMIC_BUS_CONFIG
 +#define SMC_8BIT(p) (((p)-cfg.flags  SMC91X_USE_8BIT)  SMC_CAN_USE_8BIT)
 +#define SMC_16BIT(p) (((p)-cfg.flags  SMC91X_USE_16BIT)  
 SMC_CAN_USE_16BIT)
 +#define SMC_32BIT(p) (((p)-cfg.flags  SMC91X_USE_32BIT)  
 SMC_CAN_USE_32BIT)
 +#else
 +#define SMC_8BIT(p) SMC_CAN_USE_8BIT
 +#define SMC_16BIT(p) SMC_CAN_USE_16BIT
 +#define SMC_32BIT(p) SMC_CAN_USE_32BIT
 +#endif
  
  #ifdef SMC_USE_PXA_DMA
  /*
 @@ -1108,41 +1121,41 @@ static const char * chip_ids[ 16 ] =  {
   *
   * Enforce it on any 32-bit capable setup for now.
   */
 -#define SMC_MUST_ALIGN_WRITE SMC_CAN_USE_32BIT
 +#define SMC_MUST_ALIGN_WRITE(lp) SMC_32BIT(lp)
  
  #define SMC_GET_PN(lp)  

Re: [PATCH 03/04] smc91x: add insw/outsw to default config V2

2008-02-22 Thread Nicolas Pitre
On Fri, 22 Feb 2008, Magnus Damm wrote:

 This patch makes sure SMC_insw()/SMC_outsw() are defined for the
 default configuration. Without this change BUG()s will be triggered
 when using 16-bit only platform data and the default configuration.
 
 Signed-off-by: Magnus Damm [EMAIL PROTECTED]

Acked-by: Nicolas Pitre [EMAIL PROTECTED]

 ---
 
  drivers/net/smc91x.h |2 ++
  1 file changed, 2 insertions(+)
 
 --- 0003/drivers/net/smc91x.h
 +++ work/drivers/net/smc91x.h 2008-02-22 15:25:39.0 +0900
 @@ -476,6 +476,8 @@ static inline void LPD7_SMC_outsw (unsig
  #define SMC_outb(v, a, r)writeb(v, (a) + (r))
  #define SMC_outw(v, a, r)writew(v, (a) + (r))
  #define SMC_outl(v, a, r)writel(v, (a) + (r))
 +#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l)
 +#define SMC_outsw(a, r, p, l)writesw((a) + (r), p, l)
  #define SMC_insl(a, r, p, l) readsl((a) + (r), p, l)
  #define SMC_outsl(a, r, p, l)writesl((a) + (r), p, l)
  
 


Nicolas
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 04/04] smc91x: make superh use default config V2

2008-02-22 Thread Nicolas Pitre
On Fri, 22 Feb 2008, Magnus Damm wrote:

 Removes superh board specific configuration from the header file. These boards
 will instead be configured using platform data.
 
 Signed-off-by: Magnus Damm [EMAIL PROTECTED]

Acked-by: Nicolas Pitre [EMAIL PROTECTED]

 ---
 
  drivers/net/smc91x.h |   30 --
  1 file changed, 30 deletions(-)
 
 --- 0004/drivers/net/smc91x.h
 +++ work/drivers/net/smc91x.h 2008-02-22 15:26:42.0 +0900
 @@ -292,36 +292,6 @@ SMC_outw(u16 val, void __iomem *ioaddr, 
  #define SMC_insw(a, r, p, l) insw((a) + (r), p, l)
  #define SMC_outsw(a, r, p, l)outsw((a) + (r), p, l)
  
 -#elif   defined(CONFIG_SUPERH)
 -
 -#ifdef CONFIG_SOLUTION_ENGINE
 -#define SMC_IRQ_FLAGS(0)
 -#define SMC_CAN_USE_8BIT   0
 -#define SMC_CAN_USE_16BIT  1
 -#define SMC_CAN_USE_32BIT  0
 -#define SMC_IO_SHIFT   0
 -#define SMC_NOWAIT 1
 -
 -#define SMC_inw(a, r)  inw((a) + (r))
 -#define SMC_outw(v, a, r)  outw(v, (a) + (r))
 -#define SMC_insw(a, r, p, l)   insw((a) + (r), p, l)
 -#define SMC_outsw(a, r, p, l)  outsw((a) + (r), p, l)
 -
 -#else /* BOARDS */
 -
 -#define SMC_CAN_USE_8BIT   1
 -#define SMC_CAN_USE_16BIT  1
 -#define SMC_CAN_USE_32BIT  0
 -
 -#define SMC_inb(a, r)  inb((a) + (r))
 -#define SMC_inw(a, r)  inw((a) + (r))
 -#define SMC_outb(v, a, r)  outb(v, (a) + (r))
 -#define SMC_outw(v, a, r)  outw(v, (a) + (r))
 -#define SMC_insw(a, r, p, l)   insw((a) + (r), p, l)
 -#define SMC_outsw(a, r, p, l)  outsw((a) + (r), p, l)
 -
 -#endif  /* BOARDS */
 -
  #elif   defined(CONFIG_M32R)
  
  #define SMC_CAN_USE_8BIT 0
 


Nicolas
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NETFILTER]: Introduce nf_inet_address

2008-02-22 Thread Patrick McHardy

David Woodhouse wrote:

On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:

That would break iptables compilation, which already includes
linux/in.h in some files. I guess the best fix for now is to
include netinet/in.h in busybox and long-term clean this up
properly.


It looks like iptables is fairly broken anyway:

make[1]: Entering directory 
`/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
Unable to resolve dependency on linux/compiler.h. Try 'make clean'.
Extensions found:
make[1]: Leaving directory 
`/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
error: Bad exit status from /var/tmp/rpm-tmp.32057 (%build)



Yes, that was a bug in the lastest release. We need to
release a 1.4.1 version or something like that, but I'm
not too familiar with the release process, so I haven't
done this so far.

Anyway, I just committed this patch to iptables to remove
the compiler.h inclusions.

Index: include/linux/netfilter_ipv6/ip6_tables.h
===
--- include/linux/netfilter_ipv6/ip6_tables.h   (Revision 7376)
+++ include/linux/netfilter_ipv6/ip6_tables.h   (Arbeitskopie)
@@ -15,7 +15,6 @@
 #ifndef _IP6_TABLES_H
 #define _IP6_TABLES_H
 
-#include linux/compiler.h
 #include linux/netfilter_ipv6.h
 
 #include linux/netfilter/x_tables.h
Index: include/linux/netfilter.h
===
--- include/linux/netfilter.h   (Revision 7376)
+++ include/linux/netfilter.h   (Arbeitskopie)
@@ -1,8 +1,6 @@
 #ifndef __LINUX_NETFILTER_H
 #define __LINUX_NETFILTER_H
 
-#include linux/compiler.h
-
 /* Responses from hook functions. */
 #define NF_DROP 0
 #define NF_ACCEPT 1
Index: include/linux/netfilter_ipv4/ip_tables.h
===
--- include/linux/netfilter_ipv4/ip_tables.h(Revision 7376)
+++ include/linux/netfilter_ipv4/ip_tables.h(Arbeitskopie)
@@ -15,7 +15,6 @@
 #ifndef _IPTABLES_H
 #define _IPTABLES_H
 
-#include linux/compiler.h
 #include linux/netfilter_ipv4.h
 
 #include linux/netfilter/x_tables.h


Re: [NETFILTER]: Introduce nf_inet_address

2008-02-22 Thread Patrick McHardy

David Woodhouse wrote:

On Fri, 2008-02-22 at 16:52 +0900, David Woodhouse wrote:

It looks like iptables is fairly broken anyway:

make[1]: Entering directory
`/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
Unable to resolve dependency on linux/compiler.h. Try 'make clean'.


And if I move away the contents of the local include/linux/ directory
and replace it with proper headers generated by 'make
headers_install' (which won't be trying to include compiler.h), then I
get more failures:

Unable to resolve dependency on ../include/linux/netfilter/xt_u32.h. Try 'make 
clean'.
Unable to resolve dependency on linux/netfilter/xt_time.h. Try 'make clean'.
Unable to resolve dependency on linux/netfilter/xt_quota.h. Try 'make clean'.
Unable to resolve dependency on ../include/linux/netfilter/xt_connlimit.h. Try 
'make clean'.
Unable to resolve dependency on linux/netfilter_ipv6/ip6t_mh.h. Try 'make 
clean'.
Unable to resolve dependency on linux/netfilter/nf_nat.h. Try 'make clean'.



Yes, the dependency tracking has always been a bit strange/broken.
The next release will use autoconf, which will hopefully behave
better.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ssb: Add CHIPCO IRQ access functions

2008-02-22 Thread Michael Buesch
From: Aurelien Jarno [EMAIL PROTECTED]

This patch adds functions to setup and read the CHIPCO IRQ.

Signed-off-by: Aurelien Jarno [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]

---

For 2.6.26.

 drivers/ssb/driver_chipcommon.c   |   10 ++
 include/linux/ssb/ssb_driver_chipcommon.h |4 
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/ssb/driver_chipcommon.c b/drivers/ssb/driver_chipcommon.c
index e586321..45b672a 100644
--- a/drivers/ssb/driver_chipcommon.c
+++ b/drivers/ssb/driver_chipcommon.c
@@ -353,6 +353,16 @@ void ssb_chipco_watchdog_timer_set(struct ssb_chipcommon 
*cc, u32 ticks)
chipco_write32(cc, SSB_CHIPCO_WATCHDOG, ticks);
 }
 
+void ssb_chipco_irq_mask(struct ssb_chipcommon *cc, u32 mask, u32 value)
+{
+   chipco_write32_masked(cc, SSB_CHIPCO_IRQMASK, mask, value);
+}
+
+u32 ssb_chipco_irq_status(struct ssb_chipcommon *cc, u32 mask)
+{
+   return chipco_read32(cc, SSB_CHIPCO_IRQSTAT)  mask;
+}
+
 u32 ssb_chipco_gpio_in(struct ssb_chipcommon *cc, u32 mask)
 {
return chipco_read32(cc, SSB_CHIPCO_GPIOIN)  mask;
diff --git a/include/linux/ssb/ssb_driver_chipcommon.h 
b/include/linux/ssb/ssb_driver_chipcommon.h
index 536851b..b548a54 100644
--- a/include/linux/ssb/ssb_driver_chipcommon.h
+++ b/include/linux/ssb/ssb_driver_chipcommon.h
@@ -390,6 +390,10 @@ extern void ssb_chipco_set_clockmode(struct ssb_chipcommon 
*cc,
 extern void ssb_chipco_watchdog_timer_set(struct ssb_chipcommon *cc,
  u32 ticks);
 
+void ssb_chipco_irq_mask(struct ssb_chipcommon *cc, u32 mask, u32 value);
+
+u32 ssb_chipco_irq_status(struct ssb_chipcommon *cc, u32 mask);
+
 /* Chipcommon GPIO pin access. */
 u32 ssb_chipco_gpio_in(struct ssb_chipcommon *cc, u32 mask);
 u32 ssb_chipco_gpio_out(struct ssb_chipcommon *cc, u32 mask, u32 value);
-- 
1.5.4.1



-- 
Greetings Michael.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Marvell PHY driver fix

2008-02-22 Thread Alexandr Smirnov
Marvell PHY m88e (not sure about other models, but think they too) works in
two modes: fiber and copper. In Marvell PHY driver (that we have in current
community kernels) code supported only copper mode, and this is not 
configurable,
bits for copper mode are simply written in registers during PHY
initialization. This patch adds support for both modes.

Signed-off-by: Alexandr Smirnov [EMAIL PROTECTED]

diff -pruN powerpc.orig/drivers/net/phy/marvell.c 
powerpc/drivers/net/phy/marvell.c
--- powerpc.orig/drivers/net/phy/marvell.c  2008-02-07 14:59:32.0 
+0300
+++ powerpc/drivers/net/phy/marvell.c   2008-02-19 21:47:34.0 +0300
@@ -58,9 +58,28 @@
 #define MII_M_RX_DELAY 0x80
 #define MII_M_TX_DELAY 0x2
 #define MII_M_PHY_EXT_SR   0x1b
-#define MII_M_HWCFG_MODE_MASK  0xf
-#define MII_M_HWCFG_MODE_RGMII 0xb
+
+#define MII_M_HWCFG_MODE_MASK  0xf
+#define MII_M_HWCFG_MODE_COPPER_RGMII  0xb
+#define MII_M_HWCFG_MODE_FIBER_RGMII   0x3
 #define MII_M_HWCFG_MODE_SGMII_NO_CLK  0x4
+#define MII_M_HWCFG_FIBER_COPPER_AUTO  0x8000
+#define MII_M_HWCFG_FIBER_COPPER_RES   0x2000
+
+#define MII_M_PHY_CR   0
+#define MII_M_SOFTWARE_RESET   0x8000
+
+#define MII_M_COPPER   0
+#define MII_M_FIBER1
+
+#define MII_M1011_PHY_STATUS   0x11
+#define MII_M1011_PHY_STATUS_1000  0x8000
+#define MII_M1011_PHY_STATUS_100   0x4000
+#define MII_M1011_PHY_STATUS_SPD_MASK  0xc000
+#define MII_M1011_PHY_STATUS_FULLDUPLEX0x2000
+#define MII_M1011_PHY_STATUS_RESOLVED  0x0800
+#define MII_M1011_PHY_STATUS_LINK  0x0400
+
 
 MODULE_DESCRIPTION(Marvell PHY driver);
 MODULE_AUTHOR(Andy Fleming);
@@ -141,12 +160,22 @@ static int marvell_config_aneg(struct ph
 static int m88e_config_init(struct phy_device *phydev)
 {
int err;
+   int temp;
+   int mode;
+
+   /* Enable Fiber/Copper auto selection */
+   temp = phy_read(phydev, MII_M_PHY_EXT_SR);
+   temp |= MII_M_HWCFG_FIBER_COPPER_AUTO;
+   phy_write(phydev, MII_M_PHY_EXT_SR, temp);
+
+   temp = phy_read(phydev, MII_M_PHY_CR);
+   temp |= MII_M_SOFTWARE_RESET;
+   phy_write(phydev, MII_M_PHY_CR, temp);
 
if ((phydev-interface == PHY_INTERFACE_MODE_RGMII) ||
(phydev-interface == PHY_INTERFACE_MODE_RGMII_ID) ||
(phydev-interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(phydev-interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
-   int temp;
 
temp = phy_read(phydev, MII_M_PHY_EXT_CR);
if (temp  0)
@@ -171,7 +200,17 @@ static int m88e_config_init(struct p
return temp;
 
temp = ~(MII_M_HWCFG_MODE_MASK);
-   temp |= MII_M_HWCFG_MODE_RGMII;
+
+   mode = phy_read(phydev, MII_M_PHY_EXT_CR);
+   mode = (mode  MII_M_HWCFG_FIBER_COPPER_RES)  13;
+
+   switch (mode) {
+   case MII_M_COPPER:
+   temp |= MII_M_HWCFG_MODE_COPPER_RGMII;
+   break;
+   case MII_M_FIBER:
+   temp |= MII_M_HWCFG_MODE_FIBER_RGMII;
+   }
 
err = phy_write(phydev, MII_M_PHY_EXT_SR, temp);
if (err  0)
@@ -262,6 +301,93 @@ static int m88e1145_config_init(struct p
return 0;
 }
 
+/* marvell_read_status
+ *
+ * Generic status code does not detect Fiber correctly!
+ * Description: 
+ *   Check the link, then figure out the current state
+ *   by comparing what we advertise with what the link partner
+ *   advertises.  Start by checking the gigabit possibilities,
+ *   then move on to 10/100.
+ */
+static int marvell_read_status(struct phy_device *phydev)
+{
+   int adv;
+   int err;
+   int lpa;
+   int status = 0;
+
+   /* Update the link, but return if there
+* was an error */
+   err = genphy_update_link(phydev);
+   if (err)
+   return err;
+
+   if (AUTONEG_ENABLE == phydev-autoneg) {
+   status = phy_read(phydev, MII_M1011_PHY_STATUS);
+   if (status  0)
+   return status;
+
+   lpa = phy_read(phydev, MII_LPA);
+   if (lpa  0)
+   return lpa;
+
+   adv = phy_read(phydev, MII_ADVERTISE);
+   if (adv  0)
+   return adv;
+
+   lpa = adv;
+
+   if (status  MII_M1011_PHY_STATUS_FULLDUPLEX)
+   phydev-duplex = DUPLEX_FULL;
+   else
+   phydev-duplex = DUPLEX_HALF;
+
+   status = status  MII_M1011_PHY_STATUS_SPD_MASK;
+   phydev-pause = phydev-asym_pause = 0;
+
+   switch (status) {
+   case 

Re: [NETFILTER]: Introduce nf_inet_address

2008-02-22 Thread Patrick McHardy

Pablo Neira Ayuso wrote:

Patrick McHardy wrote:

Yes, that was a bug in the lastest release. We need to
release a 1.4.1 version or something like that, but I'm
not too familiar with the release process, so I haven't
done this so far.


I can schedule one for this weekend, just send me an ACK.



That would be great. I think we had another issue in 1.4.0 with
some header files, but I can't remeber the details.

Jan, I recall we talked about this some time ago, do you remember?

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NETFILTER]: Introduce nf_inet_address

2008-02-22 Thread Pablo Neira Ayuso
Patrick McHardy wrote:
 Yes, that was a bug in the lastest release. We need to
 release a 1.4.1 version or something like that, but I'm
 not too familiar with the release process, so I haven't
 done this so far.

I can schedule one for this weekend, just send me an ACK.

-- 
Los honestos son inadaptados sociales -- Les Luthiers
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH RFC] phylib: fix forced mode misbehaviour for aneg off case

2008-02-22 Thread Anton Vorontsov
When user disabled autonegotiation via ethtool, and no link is detected,
phylib will place phy into forcing mode, and then will start calling
phy_force_reduction(). This will break user expectations. For example,
user asks for fixed speed 1000:

ethtool -s eth0 autoneg off speed 1000

Without link attached what will actually happen is:

Trying 100/FULL
Trying 100/HALF
Trying 10/FULL
Trying 10/HALF
...

This patch implements software autonegotiation that is equivalent to
current behaviour, but enabled only when hardware autonegotiation was
enabled and failed afterwards. With aneg disabled, phylib will not try
other link setups.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---

This is of course post-2.6.25 material and highly RFC, as it changes
current behaviour. Please review carefully.

Thanks.

 drivers/net/phy/phy.c   |   19 ---
 include/linux/ethtool.h |4 
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 12fccb1..35ad91f 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -264,7 +264,8 @@ void phy_sanitize_settings(struct phy_device *phydev)
int idx;
 
/* Sanitize settings based on PHY capabilities */
-   if ((features  SUPPORTED_Autoneg) == 0)
+   if ((features  SUPPORTED_Autoneg) == 0 
+   AUTONEG_SOFT != phydev-autoneg)
phydev-autoneg = AUTONEG_DISABLE;
 
idx = phy_find_valid(phy_find_setting(phydev-speed, phydev-duplex),
@@ -297,13 +298,15 @@ int phy_ethtool_sset(struct phy_device *phydev, struct 
ethtool_cmd *cmd)
cmd-advertising = phydev-supported;
 
/* Verify the settings we care about. */
-   if (cmd-autoneg != AUTONEG_ENABLE  cmd-autoneg != AUTONEG_DISABLE)
+   if (cmd-autoneg != AUTONEG_ENABLE 
+   cmd-autoneg != AUTONEG_DISABLE 
+   cmd-autoneg != AUTONEG_SOFT)
return -EINVAL;
 
if (cmd-autoneg == AUTONEG_ENABLE  cmd-advertising == 0)
return -EINVAL;
 
-   if (cmd-autoneg == AUTONEG_DISABLE
+   if ((cmd-autoneg == AUTONEG_DISABLE || cmd-autoneg == AUTONEG_SOFT)
 ((cmd-speed != SPEED_1000
 cmd-speed != SPEED_100
 cmd-speed != SPEED_10)
@@ -433,7 +436,8 @@ int phy_start_aneg(struct phy_device *phydev)
 
mutex_lock(phydev-lock);
 
-   if (AUTONEG_DISABLE == phydev-autoneg)
+   if (AUTONEG_DISABLE == phydev-autoneg ||
+   AUTONEG_SOFT == phydev-autoneg)
phy_sanitize_settings(phydev);
 
err = phydev-drv-config_aneg(phydev);
@@ -447,7 +451,8 @@ int phy_start_aneg(struct phy_device *phydev)
phydev-link_timeout = PHY_AN_TIMEOUT;
} else {
phydev-state = PHY_FORCING;
-   phydev-link_timeout = PHY_FORCE_TIMEOUT;
+   if (AUTONEG_SOFT == phydev-autoneg)
+   phydev-link_timeout = PHY_FORCE_TIMEOUT;
}
}
 
@@ -875,7 +880,7 @@ static void phy_state_machine(struct work_struct *work)
phydev-speed = settings[idx].speed;
phydev-duplex = settings[idx].duplex;
 
-   phydev-autoneg = AUTONEG_DISABLE;
+   phydev-autoneg = AUTONEG_SOFT;
 
pr_info(Trying %d/%s\n, phydev-speed,
DUPLEX_FULL ==
@@ -904,7 +909,7 @@ static void phy_state_machine(struct work_struct *work)
if (phydev-link) {
phydev-state = PHY_RUNNING;
netif_carrier_on(phydev-attached_dev);
-   } else {
+   } else if (AUTONEG_SOFT == phydev-autoneg) {
if (0 == phydev-link_timeout--) {
phy_force_reduction(phydev);
needs_aneg = 1;
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index fcbe8b6..446f78b 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -517,6 +517,10 @@ struct ethtool_ops {
  */
 #define AUTONEG_DISABLE0x00
 #define AUTONEG_ENABLE 0x01
+/* Software autonegotiation: will try several link variants in this
+ * order -- 1000/FULL, 1000/HALF, 100/FULL, 100/HALF, 10/FULL, 10/HALF.
+ */
+#define AUTONEG_SOFT   0x02
 
 /* Wake-On-Lan options. */
 #define WAKE_PHY   (1  0)
-- 
1.5.2.2
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NETFILTER]: Introduce nf_inet_address

2008-02-22 Thread Jan Engelhardt

On Feb 22 2008 16:44, Patrick McHardy wrote:
 Pablo Neira Ayuso wrote:
 Patrick McHardy wrote:
  Yes, that was a bug in the lastest release. We need to
  release a 1.4.1 version or something like that, but I'm
  not too familiar with the release process, so I haven't
  done this so far.
 
 I can schedule one for this weekend, just send me an ACK.


 That would be great. I think we had another issue in 1.4.0 with
 some header files, but I can't remeber the details.

 Jan, I recall we talked about this some time ago, do you remember?

I dunno, in Xtables 1.5.1 all header problems (minus
the uint32_t all in nf_inet_addr) are resolved I believe.
The thing even compiles without a kernel source now.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NETFILTER]: Introduce nf_inet_address

2008-02-22 Thread Patrick McHardy

Pablo Neira Ayuso wrote:

Patrick McHardy wrote:

Pablo Neira Ayuso wrote:

Patrick McHardy wrote:

Yes, that was a bug in the lastest release. We need to
release a 1.4.1 version or something like that, but I'm
not too familiar with the release process, so I haven't
done this so far.

I can schedule one for this weekend, just send me an ACK.


That would be great. I think we had another issue in 1.4.0 with
some header files, but I can't remeber the details.

Jan, I recall we talked about this some time ago, do you remember?


Was it related with kernel 2.4.x compilation?



Yes, I just found the old mail, the error was:

In file included from include/linux/netfilter/nf_nat.h:4,
 from extensions/libipt_DNAT.c:9:
include/linux/netfilter/nf_conntrack_tuple.h:29: error: syntax error 
before __be32



--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NETFILTER]: Introduce nf_inet_address

2008-02-22 Thread Pablo Neira Ayuso
Patrick McHardy wrote:
 Pablo Neira Ayuso wrote:
 Patrick McHardy wrote:
 Yes, that was a bug in the lastest release. We need to
 release a 1.4.1 version or something like that, but I'm
 not too familiar with the release process, so I haven't
 done this so far.

 I can schedule one for this weekend, just send me an ACK.
 
 
 That would be great. I think we had another issue in 1.4.0 with
 some header files, but I can't remeber the details.
 
 Jan, I recall we talked about this some time ago, do you remember?

Was it related with kernel 2.4.x compilation?

-- 
Los honestos son inadaptados sociales -- Les Luthiers
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: lockdep warning

2008-02-22 Thread Anders Eriksson

[EMAIL PROTECTED] said:
  Any chance that
  git revert 69cc64d8d92
  makes this report go away?  

I've tested the patch and I no longer get that lock thing in my syslog.

/A

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: lockdep warning

2008-02-22 Thread Jiri Kosina
On Fri, 22 Feb 2008, Anders Eriksson wrote:

   Any chance that
 git revert 69cc64d8d92
   makes this report go away?  
 I've tested the patch and I no longer get that lock thing in my syslog.

Thanks for verification.

Hmm, I don't immediately see how this patch could make neigh-lock owner 
to change between lock and unlock ... I have skimmed through the solicit 
methods, and they don't seem to be doing anything nasty to neigh ...

The scenario I was thinking about is that before 69cc64d8d92, if any of 
the _solicit methods could do anything bad to neigh struct, this warning 
wouldn't trigger, because the lock has been dropped before calling 
_solicit() and reacquired later, so no mismatch on -current could happen, 
but now as long as the lock is held during _solicit() call, this would 
trigger on the next unlock.

But I am not able to see anything like that in the code. Dave, do you have 
any idea? (the thread started at http://lkml.org/lkml/2008/2/22/105).

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 2.6.25-rc2-mm1 - several bugs and a crash

2008-02-22 Thread Paul E. McKenney
On Fri, Feb 22, 2008 at 01:52:53AM +0100, Tilman Schmidt wrote:
 Am 22.02.2008 01:40 schrieb Tilman Schmidt:
 
  [NETFILTER]: nf_conntrack: fix smp_processor_id() in preemptible code 
  warning
  
  Yes, it does; and the system also survives substantially longer.
  (IOW, it hasn't crashed on me so far.)
 
 Which of course it did the second after I sent off that mail. :-(
 No message at all this time at the time of the crash, even though
 I had tail -f /var/log/messages running in an ssh session.
 
 So the nf_conntrack BUG is fixed, but the crash (and of course the
 swapper spinlock bad magic BUG) persists.

Do you have CONFIG_DEBUG_PREEMPT set?  That would help find any other
bugs similar to nf_conntrack.

Thanx, Paul
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Marvell PHY driver fix

2008-02-22 Thread Andy Fleming


On Feb 22, 2008, at 08:34, Alexandr Smirnov wrote:

Marvell PHY m88e (not sure about other models, but think they  
too) works in
two modes: fiber and copper. In Marvell PHY driver (that we have in  
current
community kernels) code supported only copper mode, and this is not  
configurable,

bits for copper mode are simply written in registers during PHY
initialization. This patch adds support for both modes.


Excellent.  I've known about this problem for a while, but haven't  
been able to look into it.


However, some comments below



Signed-off-by: Alexandr Smirnov [EMAIL PROTECTED]

diff -pruN powerpc.orig/drivers/net/phy/marvell.c powerpc/drivers/ 
net/phy/marvell.c
--- powerpc.orig/drivers/net/phy/marvell.c	2008-02-07  
14:59:32.0 +0300
+++ powerpc/drivers/net/phy/marvell.c	2008-02-19 21:47:34.0  
+0300

@@ -58,9 +58,28 @@




+#define MII_M_PHY_CR   0
+#define MII_M_SOFTWARE_RESET   0x8000


You don't need to do this.  There are already constants for both of  
those values.  That's a standard register.





 MODULE_DESCRIPTION(Marvell PHY driver);
 MODULE_AUTHOR(Andy Fleming);
@@ -141,12 +160,22 @@ static int marvell_config_aneg(struct ph
 static int m88e_config_init(struct phy_device *phydev)
 {
int err;
+   int temp;
+   int mode;
+
+   /* Enable Fiber/Copper auto selection */
+   temp = phy_read(phydev, MII_M_PHY_EXT_SR);
+   temp |= MII_M_HWCFG_FIBER_COPPER_AUTO;
+   phy_write(phydev, MII_M_PHY_EXT_SR, temp);
+
+   temp = phy_read(phydev, MII_M_PHY_CR);
+   temp |= MII_M_SOFTWARE_RESET;
+   phy_write(phydev, MII_M_PHY_CR, temp);



Use the standard constants from mii.h (MII_BMCR, and BMCR_RESET)






temp = ~(MII_M_HWCFG_MODE_MASK);
-   temp |= MII_M_HWCFG_MODE_RGMII;
+
+   mode = phy_read(phydev, MII_M_PHY_EXT_CR);
+   mode = (mode  MII_M_HWCFG_FIBER_COPPER_RES)  13;
+
+   switch (mode) {
+   case MII_M_COPPER:
+   temp |= MII_M_HWCFG_MODE_COPPER_RGMII;
+   break;
+   case MII_M_FIBER:
+   temp |= MII_M_HWCFG_MODE_FIBER_RGMII;
+   }



I think using a switch statement on a single bit is probably  
overkill.  Much clearer, I think, if you do:


mode = phy_read(phydev, MII_M_PHY_EXT_CR);

if (mode  MII_M_HWCFG_FIBER_COPPER_RES)
temp |= MII_M_HWCFG_MODE_FIBER_RGMII;
else
temp |= MII_M_HWCFG_MODE_COPPER_RGMII;




+/* marvell_read_status
+ *
+ * Generic status code does not detect Fiber correctly!



After looking at the manual for the 88e, I think there may be a  
way to continue using the generic code, rather than replicating the  
generic code with slightly different values.  It looks like the  
problem isn't that Fiber disobeys the MIIM standard, but that it uses  
a paging mechanism to determine whether it's the Fiber Status/Control  
or the Copper Status/Control.  Many of the registers exist in both  
pages, but those two don't.  However, based on this, it seems  
reasonable to use the detected mode (fiber/copper) to determine  
whether we should be operating out of page 0 or 1.


Could you try making sure that register 22[7:0] = 0x1 for fiber, and  
see if you can then just use the standard genphy_read_status()?


Andy
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] phylib: fix forced mode misbehaviour for aneg off case

2008-02-22 Thread Andy Fleming


On Feb 22, 2008, at 09:55, Anton Vorontsov wrote:

When user disabled autonegotiation via ethtool, and no link is  
detected,

phylib will place phy into forcing mode, and then will start calling
phy_force_reduction(). This will break user expectations. For example,
user asks for fixed speed 1000:

ethtool -s eth0 autoneg off speed 1000

Without link attached what will actually happen is:

Trying 100/FULL
Trying 100/HALF
Trying 10/FULL
Trying 10/HALF
...



The intent of phy_force_reduction() was to provide a fallback in case  
the user unknowingly selects a speed that is not possible with the  
current link partner.  For instance, if you try to select gigabit on  
a 100MB link, it wouldn't work, but because of the way the code was  
designed, the phylib will find a link configuration that works.


However, I agree that it's not ideal to have the phylib spending a  
lot of time looking for a link if there's not one there.  On the  
other hand, why is the user trying to force the link to a certain  
speed if there's no link?


I'm not really opposed to it, though.




This patch implements software autonegotiation that is equivalent to
current behaviour, but enabled only when hardware autonegotiation was
enabled and failed afterwards. With aneg disabled, phylib will not try
other link setups.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---





@@ -447,7 +451,8 @@ int phy_start_aneg(struct phy_device *phydev)
phydev-link_timeout = PHY_AN_TIMEOUT;
} else {
phydev-state = PHY_FORCING;
-   phydev-link_timeout = PHY_FORCE_TIMEOUT;
+   if (AUTONEG_SOFT == phydev-autoneg)
+   phydev-link_timeout = PHY_FORCE_TIMEOUT;
}
}



I'm worried that phydev-link_timeout may end up being left in an  
unknown state here.  Are you expecting it to be 0?  If so, I think it  
would be best to set it to 0 in an if clause.





@@ -904,7 +909,7 @@ static void phy_state_machine(struct  
work_struct *work)

if (phydev-link) {
phydev-state = PHY_RUNNING;
netif_carrier_on(phydev-attached_dev);
-   } else {
+   } else if (AUTONEG_SOFT == phydev-autoneg) {
if (0 == phydev-link_timeout--) {
phy_force_reduction(phydev);
needs_aneg = 1;



Especially since this will, I believe, leave link_timeout at -1

Andy
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[no subject]

2008-02-22 Thread 内藤 賢司
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC] phylib: fix forced mode misbehaviour for aneg off case

2008-02-22 Thread Anton Vorontsov
On Fri, Feb 22, 2008 at 11:40:04AM -0600, Andy Fleming wrote:
 
 On Feb 22, 2008, at 09:55, Anton Vorontsov wrote:
 
 When user disabled autonegotiation via ethtool, and no link is  
 detected,
 phylib will place phy into forcing mode, and then will start calling
 phy_force_reduction(). This will break user expectations. For example,
 user asks for fixed speed 1000:
 
 ethtool -s eth0 autoneg off speed 1000
 
 Without link attached what will actually happen is:
 
 Trying 100/FULL
 Trying 100/HALF
 Trying 10/FULL
 Trying 10/HALF
 ...
 
 
 The intent of phy_force_reduction() was to provide a fallback in case  
 the user unknowingly selects a speed that is not possible with the  
 current link partner.  For instance, if you try to select gigabit on  
 a 100MB link, it wouldn't work, but because of the way the code was  
 designed, the phylib will find a link configuration that works.

Yup, with this patch phylib will not able to find suitable speed for
PHYs without hw angeg capability. The question is: do we have such
hardware or this feature was actually unused and we'll not break
anything.

We can think out something for this case, but it will be still
incompatible with old behaviour. For example, for such setups
we might introduce kernel command line option, specifying
softaneg=eth0, that will force softaneg for PHYs without hw aneg
capability.

 However, I agree that it's not ideal to have the phylib spending a  
 lot of time looking for a link if there's not one there.  On the  
 other hand, why is the user trying to force the link to a certain  
 speed if there's no link?

To set up fixed speed for the link, thus to not re-setup it when link
is gone down... This is how all drivers [not using phylib] are
behaving.

 I'm not really opposed to it, though.
 
 
 
 This patch implements software autonegotiation that is equivalent to
 current behaviour, but enabled only when hardware autonegotiation was
 enabled and failed afterwards. With aneg disabled, phylib will not try
 other link setups.
 
 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
 ---
 
 
 
 @@ -447,7 +451,8 @@ int phy_start_aneg(struct phy_device *phydev)
  phydev-link_timeout = PHY_AN_TIMEOUT;
  } else {
  phydev-state = PHY_FORCING;
 -phydev-link_timeout = PHY_FORCE_TIMEOUT;
 +if (AUTONEG_SOFT == phydev-autoneg)
 +phydev-link_timeout = PHY_FORCE_TIMEOUT;
  }
  }
 
 
 I'm worried that phydev-link_timeout may end up being left in an  
 unknown state here.  Are you expecting it to be 0?  If so, I think it  
 would be best to set it to 0 in an if clause.

Um.. I though about it when I wrote this, and to me it seems we
really don't use link_timeout with AUTONEG_DISABLED...
We use it for PHY_AN, PHY_FORCING  AUTONEG_SOFT, and
PHY_RESUMING  AUTONEG_ENABLED.

But as a matter of safety, I probably indeed add link_timeout
zeroing...


Thanks,

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] tg3: ethtool phys_id default (rev2)

2008-02-22 Thread Michael Chan
On Fri, 2008-02-22 at 10:24 -0800, Stephen Hemminger wrote:
 When asked to blink LEDs the tg3 driver behaves when using:
   ethtool -p ethX
 The default value for data is zero, and other drivers interpret this
 as blink forever (or at least a really long time).  The tg3 driver
 interprets this as blink once.  All drivers should have the same
 behaviour.
 
 Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]

Acked-by: Michael Chan [EMAIL PROTECTED]

We should do this across the board for bnx2, bnx2x, and niu as well.


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/3][BNX2]: More 5706S link down workaround.

2008-02-22 Thread Michael Chan
[BNX2]: More 5706S link down workaround.

The previous patches to workaround the 5706S on an HP blade were not
sufficient.  The link state still does not change properly in some
cases.  This patch adds polling to make it completely reliable.

Signed-off-by: Michael Chan [EMAIL PROTECTED]

diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 471c7f3..2fa2580 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -1273,14 +1273,20 @@ bnx2_set_link(struct bnx2 *bp)
 
if ((bp-phy_flags  BNX2_PHY_FLAG_SERDES) 
(CHIP_NUM(bp) == CHIP_NUM_5706)) {
-   u32 val;
+   u32 val, an_dbg;
 
if (bp-phy_flags  BNX2_PHY_FLAG_FORCED_DOWN) {
bnx2_5706s_force_link_dn(bp, 0);
bp-phy_flags = ~BNX2_PHY_FLAG_FORCED_DOWN;
}
val = REG_RD(bp, BNX2_EMAC_STATUS);
-   if (val  BNX2_EMAC_STATUS_LINK)
+
+   bnx2_write_phy(bp, MII_BNX2_MISC_SHADOW, MISC_SHDW_AN_DBG);
+   bnx2_read_phy(bp, MII_BNX2_MISC_SHADOW, an_dbg);
+   bnx2_read_phy(bp, MII_BNX2_MISC_SHADOW, an_dbg);
+
+   if ((val  BNX2_EMAC_STATUS_LINK) 
+   !(an_dbg  MISC_SHDW_AN_DBG_NOSYNC))
bmsr |= BMSR_LSTATUS;
else
bmsr = ~BMSR_LSTATUS;
@@ -5390,13 +5396,6 @@ bnx2_5706_serdes_timer(struct bnx2 *bp)
int check_link = 1;
 
spin_lock(bp-phy_lock);
-   if (bp-phy_flags  BNX2_PHY_FLAG_FORCED_DOWN) {
-   bnx2_5706s_force_link_dn(bp, 0);
-   bp-phy_flags = ~BNX2_PHY_FLAG_FORCED_DOWN;
-   spin_unlock(bp-phy_lock);
-   return;
-   }
-
if (bp-serdes_an_pending) {
bp-serdes_an_pending--;
check_link = 0;
@@ -5420,7 +5419,6 @@ bnx2_5706_serdes_timer(struct bnx2 *bp)
 (bp-phy_flags  BNX2_PHY_FLAG_PARALLEL_DETECT)) {
u32 phy2;
 
-   check_link = 0;
bnx2_write_phy(bp, 0x17, 0x0f01);
bnx2_read_phy(bp, 0x15, phy2);
if (phy2  0x20) {
@@ -5435,17 +5433,21 @@ bnx2_5706_serdes_timer(struct bnx2 *bp)
} else
bp-current_interval = bp-timer_interval;
 
-   if (bp-link_up  (bp-autoneg  AUTONEG_SPEED)  check_link) {
+   if (check_link) {
u32 val;
 
bnx2_write_phy(bp, MII_BNX2_MISC_SHADOW, MISC_SHDW_AN_DBG);
bnx2_read_phy(bp, MII_BNX2_MISC_SHADOW, val);
bnx2_read_phy(bp, MII_BNX2_MISC_SHADOW, val);
 
-   if (val  MISC_SHDW_AN_DBG_NOSYNC) {
-   bnx2_5706s_force_link_dn(bp, 1);
-   bp-phy_flags |= BNX2_PHY_FLAG_FORCED_DOWN;
-   }
+   if (bp-link_up  (val  MISC_SHDW_AN_DBG_NOSYNC)) {
+   if (!(bp-phy_flags  BNX2_PHY_FLAG_FORCED_DOWN)) {
+   bnx2_5706s_force_link_dn(bp, 1);
+   bp-phy_flags |= BNX2_PHY_FLAG_FORCED_DOWN;
+   } else
+   bnx2_set_link(bp);
+   } else if (!bp-link_up  !(val  MISC_SHDW_AN_DBG_NOSYNC))
+   bnx2_set_link(bp);
}
spin_unlock(bp-phy_lock);
 }


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/3][BNX2]: Disable parallel detect on an HP blade.

2008-02-22 Thread Michael Chan
[BNX2]: Disable parallel detect on an HP blade.

Because of some board issues, we need to disable parallel detect on
an HP blade.  Without this patch, the link state can become stuck
when it goes into parallel detect mode.

Signed-off-by: Michael Chan [EMAIL PROTECTED]

diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 2fa2580..35356fb 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -5362,11 +5362,15 @@ bnx2_test_intr(struct bnx2 *bp)
return -ENODEV;
 }
 
+/* Determining link for parallel detection. */
 static int
 bnx2_5706_serdes_has_link(struct bnx2 *bp)
 {
u32 mode_ctl, an_dbg, exp;
 
+   if (bp-phy_flags  BNX2_PHY_FLAG_NO_PARALLEL)
+   return 0;
+
bnx2_write_phy(bp, MII_BNX2_MISC_SHADOW, MISC_SHDW_MODE_CTL);
bnx2_read_phy(bp, MII_BNX2_MISC_SHADOW, mode_ctl);
 
@@ -7328,7 +7332,15 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device 
*dev)
bp-flags |= BNX2_FLAG_NO_WOL;
bp-wol = 0;
}
-   if (CHIP_NUM(bp) != CHIP_NUM_5706) {
+   if (CHIP_NUM(bp) == CHIP_NUM_5706) {
+   /* Don't do parallel detect on this board because of
+* some board problems.  The link will not go down
+* if we do parallel detect.
+*/
+   if (pdev-subsystem_vendor == PCI_VENDOR_ID_HP 
+   pdev-subsystem_device == 0x310c)
+   bp-phy_flags |= BNX2_PHY_FLAG_NO_PARALLEL;
+   } else {
bp-phy_addr = 2;
if (reg  BNX2_SHARED_HW_CFG_PHY_2_5G)
bp-phy_flags |= BNX2_PHY_FLAG_2_5G_CAPABLE;
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index 3aa0364..1eaf5bb 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6673,6 +6673,7 @@ struct bnx2 {
 #define BNX2_PHY_FLAG_DIS_EARLY_DAC0x0400
 #define BNX2_PHY_FLAG_REMOTE_PHY_CAP   0x0800
 #define BNX2_PHY_FLAG_FORCED_DOWN  0x1000
+#define BNX2_PHY_FLAG_NO_PARALLEL  0x2000
 
u32 mii_bmcr;
u32 mii_bmsr;


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/3][BNX2]: Update version to 1.7.4.

2008-02-22 Thread Michael Chan
[BNX2]: Update version to 1.7.4.

Signed-off-by: Michael Chan [EMAIL PROTECTED]

diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 35356fb..15853be 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -56,8 +56,8 @@
 
 #define DRV_MODULE_NAMEbnx2
 #define PFX DRV_MODULE_NAME: 
-#define DRV_MODULE_VERSION 1.7.3
-#define DRV_MODULE_RELDATE January 29, 2008
+#define DRV_MODULE_VERSION 1.7.4
+#define DRV_MODULE_RELDATE February 18, 2008
 
 #define RUN_AT(x) (jiffies + (x))
 


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[2.6 patch] unexport ip6_find_1stfragopt

2008-02-22 Thread Adrian Bunk
This patch removes the no longer used 
EXPORT_SYMBOL_GPL(ip6_find_1stfragopt).

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---

This patch has been sent on:
- 30 Jan 2008

961bcbf7370019e35920a75d2d34c91b71708dfe 
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 15c4f6c..ca707c0 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -595,7 +595,6 @@ int ip6_find_1stfragopt(struct sk_buff *skb, u8 **nexthdr)
 
return offset;
 }
-EXPORT_SYMBOL_GPL(ip6_find_1stfragopt);
 
 static int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
 {


--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 01/08] [TIPC]: Update version to 1.6.3

2008-02-22 Thread Stephens, Allan
This patch updates TIPC's version number to 1.6.3.

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
---
 net/tipc/core.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/tipc/core.c b/net/tipc/core.c
index d2d7d32..9b9429e 100644
--- a/net/tipc/core.c
+++ b/net/tipc/core.c
@@ -57,7 +57,7 @@ void tipc_socket_stop(void);
 int  tipc_netlink_start(void);
 void tipc_netlink_stop(void);
 
-#define TIPC_MOD_VER 1.6.2
+#define TIPC_MOD_VER 1.6.3
 
 #ifndef CONFIG_TIPC_ZONES
 #define CONFIG_TIPC_ZONES 3
-- 
1.5.3.2
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 04/08] [TIPC]: Minor cleanup of message header code

2008-02-22 Thread Stephens, Allan
This patch eliminates some unused or duplicate message header
symbols, and fixes up the comments and/or location of a few
other symbols.

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
---
 net/tipc/link.c |   16 
 net/tipc/msg.c  |   16 
 net/tipc/msg.h  |   19 ---
 net/tipc/port.c |4 ++--
 4 files changed, 26 insertions(+), 29 deletions(-)

diff --git a/net/tipc/link.c b/net/tipc/link.c
index 1b17fec..9d6b315 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -2832,15 +2832,15 @@ static void link_set_supervision_props(struct
link *l_ptr, u32 tolerance)
 void tipc_link_set_queue_limits(struct link *l_ptr, u32 window)
 {
/* Data messages from this node, inclusive FIRST_FRAGM */
-   l_ptr-queue_limit[DATA_LOW] = window;
-   l_ptr-queue_limit[DATA_MEDIUM] = (window / 3) * 4;
-   l_ptr-queue_limit[DATA_HIGH] = (window / 3) * 5;
-   l_ptr-queue_limit[DATA_CRITICAL] = (window / 3) * 6;
+   l_ptr-queue_limit[TIPC_LOW_IMPORTANCE] = window;
+   l_ptr-queue_limit[TIPC_MEDIUM_IMPORTANCE] = (window / 3) * 4;
+   l_ptr-queue_limit[TIPC_HIGH_IMPORTANCE] = (window / 3) * 5;
+   l_ptr-queue_limit[TIPC_CRITICAL_IMPORTANCE] = (window / 3) * 6;
/* Transiting data messages,inclusive FIRST_FRAGM */
-   l_ptr-queue_limit[DATA_LOW + 4] = 300;
-   l_ptr-queue_limit[DATA_MEDIUM + 4] = 600;
-   l_ptr-queue_limit[DATA_HIGH + 4] = 900;
-   l_ptr-queue_limit[DATA_CRITICAL + 4] = 1200;
+   l_ptr-queue_limit[TIPC_LOW_IMPORTANCE + 4] = 300;
+   l_ptr-queue_limit[TIPC_MEDIUM_IMPORTANCE + 4] = 600;
+   l_ptr-queue_limit[TIPC_HIGH_IMPORTANCE + 4] = 900;
+   l_ptr-queue_limit[TIPC_CRITICAL_IMPORTANCE + 4] = 1200;
l_ptr-queue_limit[CONN_MANAGER] = 1200;
l_ptr-queue_limit[ROUTE_DISTRIBUTOR] = 1200;
l_ptr-queue_limit[CHANGEOVER_PROTOCOL] = 2500;
diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index 7824854..696a863 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
@@ -73,10 +73,10 @@ void tipc_msg_print(struct print_buf *buf, struct
tipc_msg *msg, const char *str
tipc_printf(buf, NO(%u/%u):,msg_long_msgno(msg),
msg_fragm_no(msg));
break;
-   case DATA_LOW:
-   case DATA_MEDIUM:
-   case DATA_HIGH:
-   case DATA_CRITICAL:
+   case TIPC_LOW_IMPORTANCE:
+   case TIPC_MEDIUM_IMPORTANCE:
+   case TIPC_HIGH_IMPORTANCE:
+   case TIPC_CRITICAL_IMPORTANCE:
tipc_printf(buf, DAT%u:, msg_user(msg));
if (msg_short(msg)) {
tipc_printf(buf, CON:);
@@ -229,10 +229,10 @@ void tipc_msg_print(struct print_buf *buf, struct
tipc_msg *msg, const char *str
switch (usr) {
case CONN_MANAGER:
case NAME_DISTRIBUTOR:
-   case DATA_LOW:
-   case DATA_MEDIUM:
-   case DATA_HIGH:
-   case DATA_CRITICAL:
+   case TIPC_LOW_IMPORTANCE:
+   case TIPC_MEDIUM_IMPORTANCE:
+   case TIPC_HIGH_IMPORTANCE:
+   case TIPC_CRITICAL_IMPORTANCE:
if (msg_short(msg))
break;  /* No error */
switch (msg_errcode(msg)) {
diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index e9ef6df..282e916 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -40,18 +40,16 @@
 #include core.h
 
 #define TIPC_VERSION  2
-#define DATA_LOW  TIPC_LOW_IMPORTANCE
-#define DATA_MEDIUM   TIPC_MEDIUM_IMPORTANCE
-#define DATA_HIGH TIPC_HIGH_IMPORTANCE
-#define DATA_CRITICAL TIPC_CRITICAL_IMPORTANCE
-#define SHORT_H_SIZE  24   /* Connected,in cluster */
+
+#define SHORT_H_SIZE  24   /* Connected, in-cluster
messages */
 #define DIR_MSG_H_SIZE32   /* Directly addressed messages
*/
-#define CONN_MSG_H_SIZE   36   /* Routed connected msgs*/
-#define LONG_H_SIZE   40   /* Named Messages */
+#define LONG_H_SIZE   40   /* Named messages */
 #define MCAST_H_SIZE  44   /* Multicast messages */
-#define MAX_H_SIZE60   /* Inclusive full options */
+#define INT_H_SIZE40   /* Internal messages */
+#define MIN_H_SIZE24   /* Smallest legal TIPC header
size */
+#define MAX_H_SIZE60   /* Largest possible TIPC header
size */
+
 #define MAX_MSG_SIZE (MAX_H_SIZE + TIPC_MAX_USER_MSG_SIZE)
-#define LINK_CONFIG   13
 
 
 /*
@@ -97,7 +95,7 @@ static inline u32 msg_user(struct tipc_msg *m)
 
 static inline u32 msg_isdata(struct tipc_msg *m)
 {
-   return (msg_user(m) = DATA_CRITICAL);
+   return (msg_user(m) = TIPC_CRITICAL_IMPORTANCE);
 }
 
 static inline void msg_set_user(struct tipc_msg *m, u32 n)
@@ -388,7 +386,6 @@ static inline void msg_expand(struct tipc_msg *m,
u32 destnode)
 #define  NAME_DISTRIBUTOR 11
 #define  MSG_FRAGMENTER   12
 #define  LINK_CONFIG  13
-#define  INT_H_SIZE   

[PATCH 00/08] [TIPC]: Initial patch set for TIPC 1.6.3

2008-02-22 Thread Stephens, Allan
This is a patch set containing TIPC code developed as part of the TIPC
1.7
development project.  This first set contains small enhancements and bug
fixes
only, and is thus being integrated under the current TIPC 1.6
designation.

Patch set summary:
01 Update version to 1.6.3
02 Add argument validation for shutdown
03 Eliminate sparse warning in socket code
04 Minor cleanup of message header code
05 Use correct bitmask when setting version in
06 Enhancements to message header field writing
07 Removal of obsolete message header option co
08 TIPC network address handling cleanup

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 02/08] [TIPC]: Add argument validation for shutdown()

2008-02-22 Thread Stephens, Allan
This patch validates that the how argument to shutdown()
is SHUT_RDWR, since this is the only form that TIPC supports.

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
---
 net/tipc/socket.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 2290903..e5a6983 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1419,20 +1419,25 @@ exit:
 /**
  * shutdown - shutdown socket connection
  * @sock: socket structure
- * @how: direction to close (unused; always treated as read + write)
+ * @how: direction to close (must be SHUT_RDWR)
  *
  * Terminates connection (if necessary), then purges socket's receive
queue.
  *
  * Returns 0 on success, errno otherwise
  */
 
+#ifndef SHUT_RDWR
+#define SHUT_RDWR 2
+#endif
+
 static int shutdown(struct socket *sock, int how)
 {
struct tipc_sock* tsock = tipc_sk(sock-sk);
struct sk_buff *buf;
int res;
 
-   /* Could return -EINVAL for an invalid how, but why bother? */
+   if (how != SHUT_RDWR)
+   return -EINVAL;
 
if (down_interruptible(tsock-sem))
return -ERESTARTSYS;
-- 
1.5.3.2
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 03/08] [TIPC]: Eliminate sparse warning in socket code

2008-02-22 Thread Stephens, Allan
This patch eliminates warnings about a pair of undeclared symbols.

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
---
 net/tipc/socket.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index e5a6983..356a18c 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -81,6 +81,12 @@ static int sockets_enabled = 0;
 
 static atomic_t tipc_queue_size = ATOMIC_INIT(0);
 
+/*
+ * Declare public routines so sparse doesn't complain ...
+ */
+
+extern int  tipc_socket_init(void);
+extern void tipc_socket_stop(void);
 
 /*
  * sock_lock(): Lock a port/socket pair. lock_sock() can
-- 
1.5.3.2
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 06/08] [TIPC]: Enhancements to message header field writing

2008-02-22 Thread Stephens, Allan
From d588668422a802166b8368104490c7f644e95271 Mon Sep 17 00:00:00 2001
From: Allan Stephens [EMAIL PROTECTED]
Date: Fri, 22 Feb 2008 10:21:42 -0500
Subject: 

This patch makes two enhancements to the routine used to
set bit fields within a TIPC message header:

 1) It now ignores any bits of the new field value that are not
covered by the mask being used.  (Previously, if the new value
exceeded the size of the mask the extra bits could corrupt
other fields in the message header word being updated.)

 2) The code has been optimized to minimize the number of run-time
endianness conversion operations by leveraging the fact that the
mask (and, in some cases, the value as well) is constant and the
necessary conversion can be performed by the compiler.

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
---
 net/tipc/msg.h |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index 45c85a2..3f03739 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -70,8 +70,10 @@ static inline void msg_set_bits(struct tipc_msg *m,
u32 w,
u32 pos, u32 mask, u32 val)
 {
val = (val  mask)  pos;
-   m-hdr[w] = ~htonl(mask  pos);
-   m-hdr[w] |= htonl(val);
+   val = htonl(val);
+   mask = htonl(mask  pos);
+   m-hdr[w] = ~mask;
+   m-hdr[w] |= val;
 }
 
 /*
-- 
1.5.3.2
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 07/08] [TIPC]: Removal of obsolete message header option code

2008-02-22 Thread Stephens, Allan
This patch removes code associated with optional, user-specified
fields of the TIPC message header.  Such fields were never
utilized by TIPC, and have now been removed from the protocol
specification.

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
---
 include/net/tipc/tipc_port.h |7 ---
 net/tipc/core.c  |1 -
 net/tipc/msg.h   |   23 ---
 net/tipc/port.c  |7 ---
 4 files changed, 0 insertions(+), 38 deletions(-)

diff --git a/include/net/tipc/tipc_port.h b/include/net/tipc/tipc_port.h
index cfc4ba4..c9b36b7 100644
--- a/include/net/tipc/tipc_port.h
+++ b/include/net/tipc/tipc_port.h
@@ -86,13 +86,6 @@ u32 tipc_createport_raw(void *usr_handle,
void (*wakeup)(struct tipc_port *),
const u32 importance);
 
-/*
- * tipc_set_msg_option(): port must be locked.
- */
-int tipc_set_msg_option(struct tipc_port *tp_ptr,
-   const char *opt,
-   const u32 len);
-
 int tipc_reject_msg(struct sk_buff *buf, u32 err);
 
 int tipc_send_buf_fast(struct sk_buff *buf, u32 destnode);
diff --git a/net/tipc/core.c b/net/tipc/core.c
index 9b9429e..99ddb8e 100644
--- a/net/tipc/core.c
+++ b/net/tipc/core.c
@@ -277,7 +277,6 @@ EXPORT_SYMBOL(tipc_register_media);
 /* TIPC API for external APIs (see tipc_port.h) */
 
 EXPORT_SYMBOL(tipc_createport_raw);
-EXPORT_SYMBOL(tipc_set_msg_option);
 EXPORT_SYMBOL(tipc_reject_msg);
 EXPORT_SYMBOL(tipc_send_buf_fast);
 EXPORT_SYMBOL(tipc_acknowledge);
diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index 3f03739..4bcf4c9 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -190,18 +190,6 @@ static inline void msg_set_lookup_scope(struct
tipc_msg *m, u32 n)
msg_set_bits(m, 1, 19, 0x3, n);
 }
 
-static inline void msg_set_options(struct tipc_msg *m, const char *opt,
u32 sz)
-{
-   u32 hsz = msg_hdr_sz(m);
-   char *to = (char *)m-hdr[hsz/4];
-
-   if ((hsz  DIR_MSG_H_SIZE) || ((hsz + sz)  MAX_H_SIZE))
-   return;
-   msg_set_bits(m, 1, 16, 0x7, (hsz - 28)/4);
-   msg_set_hdr_sz(m, hsz + sz);
-   memcpy(to, opt, sz);
-}
-
 static inline u32 msg_bcast_ack(struct tipc_msg *m)
 {
return msg_bits(m, 1, 0, 0x);
@@ -330,17 +318,6 @@ static inline struct tipc_msg
*msg_get_wrapped(struct tipc_msg *m)
return (struct tipc_msg *)msg_data(m);
 }
 
-static inline void msg_expand(struct tipc_msg *m, u32 destnode)
-{
-   if (!msg_short(m))
-   return;
-   msg_set_hdr_sz(m, LONG_H_SIZE);
-   msg_set_orignode(m, msg_prevnode(m));
-   msg_set_destnode(m, destnode);
-   memset(m-hdr[8], 0, 12);
-}
-
-
 
 /*
TIPC internal message header format, version 2
diff --git a/net/tipc/port.c b/net/tipc/port.c
index 25b6967..c4ea00f 100644
--- a/net/tipc/port.c
+++ b/net/tipc/port.c
@@ -413,13 +413,6 @@ static struct sk_buff *port_build_proto_msg(u32
destport, u32 destnode,
return buf;
 }
 
-int tipc_set_msg_option(struct tipc_port *tp_ptr, const char *opt,
const u32 sz)
-{
-   msg_expand(tp_ptr-phdr, msg_destnode(tp_ptr-phdr));
-   msg_set_options(tp_ptr-phdr, opt, sz);
-   return TIPC_OK;
-}
-
 int tipc_reject_msg(struct sk_buff *buf, u32 err)
 {
struct tipc_msg *msg = buf_msg(buf);
-- 
1.5.3.2
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 08/08] [TIPC]: TIPC network address handling cleanup

2008-02-22 Thread Stephens, Allan
This patch improves the code which manipulates TIPC network
address (aka Z.C.N values).

1) Address format validation routines are generalized to
   accept any valid Z.C.N value.

2) Eliminated inlining of scope checking code to prevent
   needless code duplication in non-critical path areas.

3) Introduced new primitives for manipulating network
   addresses to improve code readability.

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
---
 net/tipc/addr.c   |   35 ---
 net/tipc/addr.h   |   30 ++
 net/tipc/bearer.c |2 +-
 net/tipc/discover.c   |2 +-
 net/tipc/name_table.c |2 +-
 net/tipc/net.c|2 +-
 net/tipc/node.c   |6 +++---
 7 files changed, 45 insertions(+), 34 deletions(-)

diff --git a/net/tipc/addr.c b/net/tipc/addr.c
index e5207a1..84570ae 100644
--- a/net/tipc/addr.c
+++ b/net/tipc/addr.c
@@ -2,7 +2,7 @@
  * net/tipc/addr.c: TIPC address utility routines
  *
  * Copyright (c) 2000-2006, Ericsson AB
- * Copyright (c) 2004-2005, Wind River Systems
+ * Copyright (c) 2004-2007, Wind River Systems
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -49,8 +49,7 @@ u32 tipc_get_addr(void)
 /**
  * tipc_addr_domain_valid - validates a network domain address
  *
- * Accepts Z.C.N, Z.C.0, Z.0.0, and 0.0.0,
- * where Z, C, and N are non-zero and do not exceed the configured
limits.
+ * Accepts Z.C.N, Z.C.0, Z.0.0, and 0.0.0, where Z, C,  N are
non-zero.
  *
  * Returns 1 if domain address is valid, otherwise 0
  */
@@ -60,16 +59,6 @@ int tipc_addr_domain_valid(u32 addr)
u32 n = tipc_node(addr);
u32 c = tipc_cluster(addr);
u32 z = tipc_zone(addr);
-   u32 max_nodes = tipc_max_nodes;
-
-   if (is_slave(addr))
-   max_nodes = LOWEST_SLAVE + tipc_max_slaves;
-   if (n  max_nodes)
-   return 0;
-   if (c  tipc_max_clusters)
-   return 0;
-   if (z  tipc_max_zones)
-   return 0;
 
if (n  (!z || !c))
return 0;
@@ -81,8 +70,7 @@ int tipc_addr_domain_valid(u32 addr)
 /**
  * tipc_addr_node_valid - validates a proposed network address for this
node
  *
- * Accepts Z.C.N, where Z, C, and N are non-zero and do not exceed
- * the configured limits.
+ * Accepts Z.C.N, where Z, C, and N are non-zero.
  *
  * Returns 1 if address can be used, otherwise 0
  */
@@ -92,3 +80,20 @@ int tipc_addr_node_valid(u32 addr)
return (tipc_addr_domain_valid(addr)  tipc_node(addr));
 }
 
+/**
+ * tipc_in_scope - determines if network address lies within specified
domain
+ */
+
+int tipc_in_scope(u32 domain, u32 addr)
+{
+if (likely(domain == addr))
+return 1;
+   if (domain == 0)
+   return 1;
+   if (domain == addr_cluster(addr)) /* domain Z.C.0 */
+   return 1;
+   if (domain == addr_zone(addr)) /* domain Z.0.0 */
+   return 1;
+   return 0;
+}
+
diff --git a/net/tipc/addr.h b/net/tipc/addr.h
index 3ba67e6..097eb20 100644
--- a/net/tipc/addr.h
+++ b/net/tipc/addr.h
@@ -2,7 +2,7 @@
  * net/tipc/addr.h: Include file for TIPC address utility routines
  *
  * Copyright (c) 2000-2006, Ericsson AB
- * Copyright (c) 2004-2005, Wind River Systems
+ * Copyright (c) 2004-2006, Wind River Systems
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -37,6 +37,17 @@
 #ifndef _TIPC_ADDR_H
 #define _TIPC_ADDR_H
 
+
+static inline u32 addr_zone(u32 addr)
+{
+return addr  0xff00u;
+}
+
+static inline u32 addr_cluster(u32 addr)
+{
+return addr  0xf000u;
+}
+
 static inline u32 own_node(void)
 {
return tipc_node(tipc_own_addr);
@@ -57,6 +68,11 @@ static inline int in_own_cluster(u32 addr)
return !((addr ^ tipc_own_addr)  12);
 }
 
+static inline int in_own_zone(u32 addr)
+{
+   return !((addr ^ tipc_own_addr)  24);
+}
+
 static inline int is_slave(u32 addr)
 {
return addr  0x800;
@@ -67,17 +83,6 @@ static inline int may_route(u32 addr)
return(addr ^ tipc_own_addr)  11;
 }
 
-static inline int in_scope(u32 domain, u32 addr)
-{
-   if (!domain || (domain == addr))
-   return 1;
-   if (domain == (addr  0xf000u)) /* domain Z.C.0 */
-   return 1;
-   if (domain == (addr  0xff00u)) /* domain Z.0.0 */
-   return 1;
-   return 0;
-}
-
 /**
  * addr_scope - convert message lookup domain to equivalent 2-bit scope
value
  */
@@ -119,5 +124,6 @@ static inline char *addr_string_fill(char *string,
u32 addr)
 
 int tipc_addr_domain_valid(u32);
 int tipc_addr_node_valid(u32 addr);
+int tipc_in_scope(u32 domain, u32 addr);
 
 #endif
diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index 271a375..ec2fd2e 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -491,7 +491,7 @@ int tipc_enable_bearer(const char *name, u32
bcast_scope, u32 priority)
  

[PATCH 05/08] [TIPC]: Use correct bitmask when setting version in message

2008-02-22 Thread Stephens, Allan
This patch ensures that the 3-bit version field of the TIPC
message header is masked correctly when written into a message.

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
---
 net/tipc/msg.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index 282e916..45c85a2 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -85,7 +85,7 @@ static inline u32 msg_version(struct tipc_msg *m)
 
 static inline void msg_set_version(struct tipc_msg *m)
 {
-   msg_set_bits(m, 0, 29, 0xf, TIPC_VERSION);
+   msg_set_bits(m, 0, 29, 0x7, TIPC_VERSION);
 }
 
 static inline u32 msg_user(struct tipc_msg *m)
-- 
1.5.3.2
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 03/08] [TIPC]: Eliminate sparse warning in socket code

2008-02-22 Thread Sam Ravnborg
On Fri, Feb 22, 2008 at 11:59:12AM -0800, Stephens, Allan wrote:
 This patch eliminates warnings about a pair of undeclared symbols.

Hi Allan.

Last I looked there where ~90 sparse warnings for tipc.
I assume you are aware and that they are getting fixed.

Sam - who would like to see an almost sparse clean kernel
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 03/08] [TIPC]: Eliminate sparse warning in socket code

2008-02-22 Thread Stephens, Allan
Hi Sam:

Yes and yes.  Some fixes will occur naturally as the problematic code
has already been rewritten in TIPC 1.7, but other fixes will need to be
developed.  I'll see what I can do to accelerate the process ...

-- Al 

-Original Message-
From: Sam Ravnborg [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 22, 2008 3:04 PM
To: Stephens, Allan
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 03/08] [TIPC]: Eliminate sparse warning in socket
code

On Fri, Feb 22, 2008 at 11:59:12AM -0800, Stephens, Allan wrote:
 This patch eliminates warnings about a pair of undeclared symbols.

Hi Allan.

Last I looked there where ~90 sparse warnings for tipc.
I assume you are aware and that they are getting fixed.

Sam - who would like to see an almost sparse clean kernel
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/08] [TIPC]: Initial patch set for TIPC 1.6.3

2008-02-22 Thread David Miller

Please only submit bug fixes for 2.6.25 at this time.

Thank you.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Error on ip route replace command

2008-02-22 Thread Francesco Saverio Giudice

Hi All,

I have a problem with kernel 2.6.24.

Having a running configuration using Shorewall and restarting it I got 
follow error:

RTNETLINK answers: File exists

Tom Eastep, Shorewall creator, told me to inform you about the problem.

Here is the mail:

Francesco Saverio Giudice wrote:

Hi Tom,

I get the error:

-
# ip route add 1.2.4.5 dev eth3
# ip route replace 1.2.4.5 dev eth3
RTNETLINK answers: File exists
-

I have to patch kernel or something else ?



You should report it at netdev@vger.kernel.org (that's where the Linux
networking developers hang out). This failure does not occur with kernel
2.6.22 and iproute2 ss070710:

gateway:~ # ip route add 1.2.4.5 dev eth0
gateway:~ # ip route replace 1.2.4.5 dev eth0
gateway:~ # ip route del 1.2.4.5

-Tom
--
Tom Eastep\ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA  \ [EMAIL PROTECTED]
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



Best Regards

Francesco Saverio Giudice



--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NETFILTER]: Introduce nf_inet_address

2008-02-22 Thread David Woodhouse

On Fri, 2008-02-22 at 16:44 +0100, Patrick McHardy wrote:
 Pablo Neira Ayuso wrote:
  Patrick McHardy wrote:
  Yes, that was a bug in the lastest release. We need to
  release a 1.4.1 version or something like that, but I'm
  not too familiar with the release process, so I haven't
  done this so far.
  
  I can schedule one for this weekend, just send me an ACK.
 
 
 That would be great. I think we had another issue in 1.4.0 with
 some header files, but I can't remeber the details.

If you are going to include header files in the release (which makes a
certain amount of sense), it would be best if those are simply the
result of the kernel's 'make headers_install', without any manual
changes.

-- 
dwmw2

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Patch] Crash (BUG()) when handling fragmented ESP packets

2008-02-22 Thread Dirk Nehring
Most likely all 2.6 series kernels crash with BUG() when receives a
fragmented ESP packet where ESP header and IV are not in the first
fragment. This patches fixes this behaviour by reassembling the
fragmented packet into the sk_buff.

Signed-off-by: Dirk Nehring [EMAIL PROTECTED]
Signed-off-by: Andreas Ferber [EMAIL PROTECTED]



Please apply this patch to 2.6.25. We tested the patch successfully on
production systems which ran into this problem.

Long description:
=

We have come across (and fixed) a bug in the linux kernel (specifically
in the IPsec code) that has some security concerns attached. On Dec.,
12., 2007, we have contacted [EMAIL PROTECTED] where Herbert was also
informed.

RedHat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=404291

Future CVE: CVE-2007-6282


BUG DESCRIPTION:


As you may know, an ESP packet starts with an ESP header (8 Octets),
depending on the encryption algorithm followed by an Initialization
Vector (eg. 16 Octets for AES-CBC, 8 Octets for 3DES-CBC). If the ESP
packet is divided into IP fragments so that the first fragment does not
contain the whole of ESP-Header plus the IV (for example only the first
8 Octets), the kernel runs into a BUG() when decoding the packet and
thus crashes instantly.

HOW TO REPRODUCE:
-

To reproduce the problem you can use the following setup with three
machines:

   ++ ++ ++
   | E1 |-| IR |-| E2 |
   ++ ++ ++

 E1, E2: IPsec tunnel endpoints
 IR: intermediate router

Setup an IPsec tunnel using 3DES-CBC or AES-CBC between E1 and E2 (I
tested it with ISAKMP keying, but it should work with manual keying
also). Now setup IR so that it fragments packets going from E1 to E2
into very small fragments (8 Octets each), for example using fragrouter.

Now, when you try to send some traffic through the tunnel from E1 to E2
(thus generating ESP packets), as soon as the last fragment of it has
arrived on E2, it crashes with a BUG().

Note that E1 does not have to be a linux machine, any IPsec capable
device will do.

ANALYSIS:
-

All line numbers refer to kernel version 2.6.24-rc4.

Have a look at net/ipv4/esp4.c, function esp_input(). Starting at line
195, it tries to get the IV from the ESP packet, however it does not
take into account that the sk_buff it is handling may be paged or
fragmented. This may result in an out of bounds memory read access if
the head of the sk_buff does not contain the full ESP header plus the
IV.

Then at the end of the function, at line 268, it tries to __skb_pull()
the ESP header and IV of the packet. This is where the BUG() is
triggered, since __skb_pull() checks that there is enough data in the
sk_buff head to fulfill the pull.

When reassembling fragmented IP packets, the kernel does so using a
fragmented sk_buff (using skb-frag_list). If the first fragment is
shorter than the ESP header plus the IV, the condition to trigger the
BUG() in esp_input() is satisfied by the resulting sk_buff, thus
crashing the kernel.

The relevant code for IPv6 ESP (in net/ipv6/esp6.c) is mostly the same
as the IPv4 code, so this is affected, too.

The bug most likely exists in all 2.6 kernel versions up till today. I
explicitly checked 2.6.18 (my vendors version of that I first
encountered the bug on a few days ago) and 2.6.0. Although the code of
esp_input() changed in between, the relevant code lines exist in almost
identical form since 2.6.0 up to the latest development versions, so it
is unlikely that some version in between is unaffected by the bug.

BUGFIX:
---

Attached you can find a patch against stable 2.6.24.1 and 2.6.25-rc2
(there are some bigger changes between 2.6.24 and 2.6.25 is the
responsible code segment). This patch modify the code in question to
correctly deal with a fragmented or paged sk_buff.

We did not test the IPv6 part of the patch, but since it is almost the
same as the IPv4 part, we are pretty confident that it will work as
advertised.

SECURITY CONCERNS:
--

In order to reach the code path that crashes the machine, the fragmented
ESP packet has to contain a valid SPI and must be correctly
authenticated (if authentication is used on the Policy).

Thus, you can remotely crash a vulnerable machine, if you

  (a) have control of an IPsec peer connected to it (with a valid SA
  existing)

or

  (b) have the ability to manipulate (fragment) packets going from a
  peer to the machine (note that you do not have to crack the
  encryption to do this)

An example of (b) is that if you are connecting to your company network
using an IPsec VPN from an internet cafe or WiFi hotspot, the owner of
the cafe or access point can crash your central company VPN gateway if
it is running a vulnerable version of the linux kernel.


Dirk
diff -ur linux-2.6.24.2.orig/net/ipv4/esp4.c linux-2.6.24.2/net/ipv4/esp4.c
--- linux-2.6.24.2.orig/net/ipv4/esp4.c 2008-01-24 

[PATCH] sky2: fix LED management

2008-02-22 Thread Stephen Hemminger
Fix problems in LED management, so ethtool -p works correctly on Yukon-EC
and other chips. The driver was incorrectly setting the PHY LED overide bits.
Moral: read the spec sheet, not the vendor driver.

Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
 drivers/net/sky2.c |   99 +
 drivers/net/sky2.h |   21 +--
 2 files changed, 44 insertions(+), 76 deletions(-)

--- a/drivers/net/sky2.h2008-02-22 14:02:58.0 -0800
+++ b/drivers/net/sky2.h2008-02-22 14:06:17.0 -0800
@@ -1318,18 +1318,21 @@ enum {
BLINK_670MS = 4,/* 670 ms */
 };
 
-/ PHY_MARV_LED_OVER16 bit r/w LED control */
-enum {
-   PHY_M_LED_MO_DUP  = 310,/* Bit 11..10:  Duplex */
-   PHY_M_LED_MO_10   = 38, /* Bit  9.. 8:  Link 10 */
-   PHY_M_LED_MO_100  = 36, /* Bit  7.. 6:  Link 100 */
-   PHY_M_LED_MO_1000 = 34, /* Bit  5.. 4:  Link 1000 */
-   PHY_M_LED_MO_RX   = 32, /* Bit  3.. 2:  Rx */
-   PHY_M_LED_MO_TX   = 30, /* Bit  1.. 0:  Tx */
-
-   PHY_M_LED_ALL = PHY_M_LED_MO_DUP | PHY_M_LED_MO_10 
-   | PHY_M_LED_MO_100 | PHY_M_LED_MO_1000
-   | PHY_M_LED_MO_RX,
+/*  PHY_MARV_LED_OVER  16 bit r/w  Manual LED Override Reg */
+#define PHY_M_LED_MO_SGMII(x)  ((x)14)   /* Bit 15..14:  SGMII AN Timer 
*/
+
+#define PHY_M_LED_MO_DUP(x)((x)10)   /* Bit 11..10:  Duplex */
+#define PHY_M_LED_MO_10(x) ((x)8)/* Bit  9.. 8:  Link 10 */
+#define PHY_M_LED_MO_100(x)((x)6)/* Bit  7.. 6:  Link 100 */
+#define PHY_M_LED_MO_1000(x)   ((x)4)/* Bit  5.. 4:  Link 1000 */
+#define PHY_M_LED_MO_RX(x) ((x)2)/* Bit  3.. 2:  Rx */
+#define PHY_M_LED_MO_TX(x) ((x)0)/* Bit  1.. 0:  Tx */
+
+enum led_mode {
+   MO_LED_NORM  = 0,
+   MO_LED_BLINK = 1,
+   MO_LED_OFF   = 2,
+   MO_LED_ON= 3,
 };
 
 /*  PHY_MARV_EXT_CTRL_216 bit r/w  Ext. PHY Specific Ctrl 2 */
--- a/drivers/net/sky2.c2008-02-22 10:51:13.0 -0800
+++ b/drivers/net/sky2.c2008-02-22 15:46:18.0 -0800
@@ -572,8 +572,9 @@ static void sky2_phy_init(struct sky2_hw
default:
/* set Tx LED (LED_TX) to blink mode on Rx OR Tx activity */
ledctrl |= PHY_M_LED_BLINK_RT(BLINK_84MS) | PHY_M_LEDC_TX_CTRL;
+
/* turn off the Rx LED (LED_RX) */
-   ledover = ~PHY_M_LED_MO_RX;
+   ledover |= PHY_M_LED_MO_RX(MO_LED_OFF);
}
 
if (hw-chip_id == CHIP_ID_YUKON_EC_U 
@@ -602,7 +603,7 @@ static void sky2_phy_init(struct sky2_hw
 
if (sky2-autoneg == AUTONEG_DISABLE || sky2-speed == 
SPEED_100) {
/* turn on 100 Mbps LED (LED_LINK100) */
-   ledover |= PHY_M_LED_MO_100;
+   ledover |= PHY_M_LED_MO_100(MO_LED_ON);
}
 
if (ledover)
@@ -3322,82 +3323,80 @@ static void sky2_set_multicast(struct ne
 /* Can have one global because blinking is controlled by
  * ethtool and that is always under RTNL mutex
  */
-static void sky2_led(struct sky2_hw *hw, unsigned port, int on)
+static void sky2_led(struct sky2_port *sky2, enum led_mode mode)
 {
-   u16 pg;
+   struct sky2_hw *hw = sky2-hw;
+   unsigned port = sky2-port;
 
-   switch (hw-chip_id) {
-   case CHIP_ID_YUKON_XL:
+   spin_lock_bh(sky2-phy_lock);
+   if (hw-chip_id == CHIP_ID_YUKON_EC_U ||
+   hw-chip_id == CHIP_ID_YUKON_EX ||
+   hw-chip_id == CHIP_ID_YUKON_SUPR) {
+   u16 pg;
pg = gm_phy_read(hw, port, PHY_MARV_EXT_ADR);
gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 3);
-   gm_phy_write(hw, port, PHY_MARV_PHY_CTRL,
-on ? (PHY_M_LEDC_LOS_CTRL(1) |
-  PHY_M_LEDC_INIT_CTRL(7) |
-  PHY_M_LEDC_STA1_CTRL(7) |
-  PHY_M_LEDC_STA0_CTRL(7))
-: 0);
 
-   gm_phy_write(hw, port, PHY_MARV_EXT_ADR, pg);
-   break;
+   switch (mode) {
+   case MO_LED_OFF:
+   gm_phy_write(hw, port, PHY_MARV_PHY_CTRL,
+PHY_M_LEDC_LOS_CTRL(8) |
+PHY_M_LEDC_INIT_CTRL(8) |
+PHY_M_LEDC_STA1_CTRL(8) |
+PHY_M_LEDC_STA0_CTRL(8));
+   break;
+   case MO_LED_ON:
+   gm_phy_write(hw, port, PHY_MARV_PHY_CTRL,
+PHY_M_LEDC_LOS_CTRL(9) |
+PHY_M_LEDC_INIT_CTRL(9) |
+PHY_M_LEDC_STA1_CTRL(9) |
+PHY_M_LEDC_STA0_CTRL(9));
+   break;
+ 

[patch 2.6.25-rc2-git] rndis_host: fix transfer size negotiation

2008-02-22 Thread David Brownell
From: Jean-Christophe Dubois [EMAIL PROTECTED]

This patch should resolve a problem that's troubled support for
some RNDIS peripherals.  It seems to have boiled down to using a
variable to establish transfer size limits before it was assigned,
which caused those devices to fallback to a default jumbogram
mode we don't support.  Fix by assigning it earlier for RNDIS.

Signed-off-by: Jean-Christophe Dubois [EMAIL PROTECTED]
[ cleanups ]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
This bugfix should be merged before 2.6.25-final.

 drivers/net/usb/rndis_host.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

--- g26.orig/drivers/net/usb/rndis_host.c   2008-02-01 22:24:38.0 
-0800
+++ g26/drivers/net/usb/rndis_host.c2008-02-16 12:55:35.0 -0800
@@ -16,10 +16,6 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
-
-// #define DEBUG   // error path messages, extra info
-// #define VERBOSE // more; success messages
-
 #include linux/module.h
 #include linux/init.h
 #include linux/netdevice.h
@@ -318,6 +314,14 @@ generic_rndis_bind(struct usbnet *dev, s
net-hard_header_len += sizeof (struct rndis_data_hdr);
dev-hard_mtu = net-mtu + net-hard_header_len;
 
+   dev-maxpacket = usb_maxpacket(dev-udev, dev-out, 1);
+   if (dev-maxpacket == 0) {
+   if (netif_msg_probe(dev))
+   dev_dbg(intf-dev, dev-maxpacket can't be 0\n);
+   retval = -EINVAL;
+   goto fail_and_release;
+   }
+
dev-rx_urb_size = dev-hard_mtu + (dev-maxpacket + 1);
dev-rx_urb_size = ~(dev-maxpacket - 1);
u.init-max_transfer_size = cpu_to_le32(dev-rx_urb_size);
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Error on ip route replace command

2008-02-22 Thread Joonwoo Park
2008/2/23, Francesco Saverio Giudice [EMAIL PROTECTED]:
 Hi All,

 I have a problem with kernel 2.6.24.

 Having a running configuration using Shorewall and restarting it I got
 follow error:
 RTNETLINK answers: File exists

 Tom Eastep, Shorewall creator, told me to inform you about the problem.

 Here is the mail:
 
 Francesco Saverio Giudice wrote:
  Hi Tom,
 
  I get the error:
 
  -
  # ip route add 1.2.4.5 dev eth3
  # ip route replace 1.2.4.5 dev eth3
  RTNETLINK answers: File exists
  -
 
  I have to patch kernel or something else ?
 

 You should report it at netdev@vger.kernel.org (that's where the Linux
 networking developers hang out). This failure does not occur with kernel
 2.6.22 and iproute2 ss070710:

 gateway:~ # ip route add 1.2.4.5 dev eth0
 gateway:~ # ip route replace 1.2.4.5 dev eth0
 gateway:~ # ip route del 1.2.4.5

 -Tom
 --
 Tom Eastep\ Nothing is foolproof to a sufficiently talented fool
 Shoreline, \ http://shorewall.net
 Washington USA  \ [EMAIL PROTECTED]
 PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

 

 Best Regards

 Francesco Saverio Giudice



 --
 To unsubscribe from this list: send the line unsubscribe netdev in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


Francesco,
It was fixed by 936f6f8e1bc46834bbb3e3fa3ac13ab44f1e7ba6 and
c18865f39276435abb9286f9a816cb5b66c99a00.
Please try with lastest git source

Joonwoo.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html