[PATCH] [AF_PACKET] Fix minor code duplication

[Urs Thuermann]

Simplify some code by eliminating duplicate if-else clauses in
packet_do_bind().


Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]>


--- net-2.6/net/packet/af_packet.c.orig 2007-11-05 13:07:28.0 +0100
+++ net-2.6/net/packet/af_packet.c  2007-11-08 12:14:25.0 +0100
@@ -886,20 +886,14 @@ static int packet_do_bind(struct sock *s
if (protocol == 0)
goto out_unlock;
 
-   if (dev) {
-   if (dev->flags&IFF_UP) {
-   dev_add_pack(&po->prot_hook);
-   sock_hold(sk);
-   po->running = 1;
-   } else {
-   sk->sk_err = ENETDOWN;
-   if (!sock_flag(sk, SOCK_DEAD))
-   sk->sk_error_report(sk);
-   }
-   } else {
+   if (!dev || (dev->flags & IFF_UP)) {
dev_add_pack(&po->prot_hook);
sock_hold(sk);
po->running = 1;
+   } else {
+   sk->sk_err = ENETDOWN;
+   if (!sock_flag(sk, SOCK_DEAD))
+   sk->sk_error_report(sk);
}
 
 out_unlock:
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[2.6 patch] remove references to net-modules.txt

[Adrian Bunk]

When I removed net-modules.txt because it only contained ancient 
information I missed that many Kconfig entries pointed to this ancient 
information.

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

---

 Documentation/networking/3c505.txt |3 
 drivers/net/Kconfig|  199 ++---
 drivers/net/arcnet/Kconfig |   15 --
 drivers/net/tulip/Kconfig  |   21 +--
 4 files changed, 82 insertions(+), 156 deletions(-)

6451db6bafae46e17885b8c7b243095fc257e8ed 
diff --git a/Documentation/networking/3c505.txt 
b/Documentation/networking/3c505.txt
index b9d5b72..72f38b1 100644
--- a/Documentation/networking/3c505.txt
+++ b/Documentation/networking/3c505.txt
@@ -14,8 +14,7 @@ If no base address is given at boot time, the driver will 
autoprobe
 ports 0x300, 0x280 and 0x310 (in that order).  If no IRQ is given, the driver
 will try to probe for it.
 
-The driver can be used as a loadable module.  See net-modules.txt for details
-of the parameters it can take.  
+The driver can be used as a loadable module.
 
 Theoretically, one instance of the driver can now run multiple cards,
 in the standard way (when loading a module, say "modprobe 3c505
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 5f800a6..0fdcf72 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -365,8 +365,7 @@ config MAC89x0
  read the Ethernet-HOWTO, available from
  .
 
- To compile this driver as a module, choose M here and read
- .  This module will
+ To compile this driver as a module, choose M here. This module will
  be called mac89x0.
 
 config MACSONIC
@@ -379,8 +378,7 @@ config MACSONIC
  one of these say Y and read the Ethernet-HOWTO, available from
  .
 
- To compile this driver as a module, choose M here and read
- .  This module will
+ To compile this driver as a module, choose M here. This module will
  be called macsonic.
 
 config MACMACE
@@ -618,8 +616,7 @@ config EL1
  have problems.  Some people suggest to ping ("man ping") a nearby
  machine every minute ("man cron") when using this card.
 
- To compile this driver as a module, choose M here and read
- . The module
+ To compile this driver as a module, choose M here. The module
  will be called 3c501.
 
 config EL2
@@ -631,8 +628,7 @@ config EL2
  the Ethernet-HOWTO, available from
  .
 
- To compile this driver as a module, choose M here and read
- . The module
+ To compile this driver as a module, choose M here. The module
  will be called 3c503.
 
 config ELPLUS
@@ -644,8 +640,7 @@ config ELPLUS
  this type, say Y and read the Ethernet-HOWTO, available from
  .
 
- To compile this driver as a module, choose M here and read
- . The module
+ To compile this driver as a module, choose M here. The module
  will be called 3c505.
 
 config EL16
@@ -656,8 +651,7 @@ config EL16
  the Ethernet-HOWTO, available from
  .
 
- To compile this driver as a module, choose M here and read
- . The module
+ To compile this driver as a module, choose M here. The module
  will be called 3c507.
 
 config EL3
@@ -672,8 +666,7 @@ config EL3
  setup disk to disable Plug & Play mode, and to select the default
  media type.
 
- To compile this driver as a module, choose M here and read
- . The module
+ To compile this driver as a module, choose M here. The module
  will be called 3c509.
 
 config 3C515
@@ -684,8 +677,7 @@ config 3C515
  network card, say Y and read the Ethernet-HOWTO, available from
  .
 
- To compile this driver as a module, choose M here and read
- . The module
+ To compile this driver as a module, choose M here. The module
  will be called 3c515.
 
 config ELMC
@@ -696,8 +688,7 @@ config ELMC
  the Ethernet-HOWTO, available from
  .
 
- To compile this driver as a module, choose M here and read
- . The module
+ To compile this driver as a module, choose M here. The module
  will be called 3c523.
 
 config ELMC_II
@@ -708,8 +699,7 @@ config ELMC_II
  the Ethernet-HOWTO, available from
  .
 
- To compile this driver as a module, choose M here and read
- . The module
+ To compile this driver as a module, choose M here. The module
  will be called 3c527.
 
 config VORTEX
@@ -732,8 +722,7 @@ config VORTEX
   and in the comments at
  the begin

[PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.

[Jon Smirl]

This is the reason I couldn't get user space started or connect to my
nfs server. Patch is against current linus git.

mpc5200 fec driver is corrupting memory. This patch fixes two bugs
where the wrong skb buffer was being referenced.

Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>

---

 drivers/net/fec_mpc52xx.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index a8a0ee2..ddfcc0b 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)

rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
(struct bcom_bd **)&bd);
-   dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, 
DMA_FROM_DEVICE);
+   dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, 
DMA_FROM_DEVICE);

/* Test for errors in received frame */
if (status & BCOM_FEC_RX_BD_ERRORS) {
@@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
bcom_prepare_next_buffer(priv->rx_dmatsk);

bd->status = FEC_RX_BUFFER_SIZE;
-   bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
+   bd->skb_pa = dma_map_single(&dev->dev, skb->data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);

bcom_submit_next_buffer(priv->rx_dmatsk, skb);


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

Re: [PATCH] [POWERPC] Fix typo #ifdef -> #ifndef

[Andrew Morton]

> On Sat, 03 Nov 2007 20:16:36 +0100 Jochen Friedrich <[EMAIL PROTECTED]> wrote:
> Subject: [PATCH] [POWERPC] Fix typo #ifdef -> #ifndef

Please put the "powerpc" outside the [].  Because things inside [] get
removed when the receiver applies the patch, but the subsystem
identification ("powerpc") is useful information which we want to carry
into the permanent git record. (Although Paul might add it anyway - some
git tree maintainers do).

> User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009)

This seems to be setting a record for MUA vandalism.  Leading spaces were
removed and various esoteric whitespace transformations were made.  The
diffs were small so I fixed them by hand.

Please strangle your email client.

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

Re: [PATCH 04/05] ipv6: RFC4214 Support

[David Miller]

From: "Templin, Fred L" <[EMAIL PROTECTED]>
Date: Thu, 8 Nov 2007 13:01:34 -0800

> > Hmm, what is missing from API POV?
> 
> This would have to be determined under a follow-on project (hopefully
> with input from others) after we have gained operational experience.

I personally don't buy any of this desire to avoid iproute2
changes at this time.

This is never how we handle this kind of situation.

We add in the new feature, and add support to iproute2 in
parallel.  If we screw it up we figure that out quickly
and fix things before it's been deployed for too long.

I suspect you simply want users to just be able to use the
new feature with only a kernel patch, but that's not an
appropriate reason to not do things correctly when submitting
a feature upstream.

Please use the new name in the kernel side changes and implement
iproute2 support for these ISATAP devices.

Thank you.

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

Re: [PATCH] NET: Add the helper kernel_sock_shutdown()

[David Howells]

Trond Myklebust <[EMAIL PROTECTED]> wrote:

> Looking at the sock->op->shutdown() handlers, it looks as if all of them
> take a SHUT_RD/SHUT_WR/SHUT_RDWR argument instead of the
> RCV_SHUTDOWN/SEND_SHUTDOWN arguments.
> Add a helper, and then define the SHUT_* enum to ensure that kernel users
> of shutdown() don't get confused.

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

[PATCH] NET: Add the helper kernel_sock_shutdown()

[Trond Myklebust]

From: Trond Myklebust <[EMAIL PROTECTED]>

...and fix a couple of bugs in the NBD, CIFS and OCFS2 socket handlers.

Looking at the sock->op->shutdown() handlers, it looks as if all of them
take a SHUT_RD/SHUT_WR/SHUT_RDWR argument instead of the
RCV_SHUTDOWN/SEND_SHUTDOWN arguments.
Add a helper, and then define the SHUT_* enum to ensure that kernel users
of shutdown() don't get confused.

Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
Cc: Paul Clements <[EMAIL PROTECTED]>
Cc: Mark Fasheh <[EMAIL PROTECTED]>
Cc: Steve French <[EMAIL PROTECTED]>
Cc: David Howells <[EMAIL PROTECTED]>
Cc: David S Miller <[EMAIL PROTECTED]>
---

 drivers/block/nbd.c|3 ++-
 fs/cifs/connect.c  |2 +-
 fs/ocfs2/cluster/tcp.c |4 ++--
 include/linux/net.h|7 +++
 net/rxrpc/ar-local.c   |4 ++--
 net/socket.c   |6 ++
 6 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 6332aca..b4c0888 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -126,7 +127,7 @@ static void sock_shutdown(struct nbd_device *lo, int lock)
if (lo->sock) {
printk(KERN_WARNING "%s: shutting down socket\n",
lo->disk->disk_name);
-   lo->sock->ops->shutdown(lo->sock, SEND_SHUTDOWN|RCV_SHUTDOWN);
+   kernel_sock_shutdown(lo->sock, SHUT_RDWR);
lo->sock = NULL;
}
if (lock)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 19ee11f..bea0d2e 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -160,7 +160,7 @@ cifs_reconnect(struct TCP_Server_Info *server)
if (server->ssocket) {
cFYI(1, ("State: 0x%x Flags: 0x%lx", server->ssocket->state,
server->ssocket->flags));
-   server->ssocket->ops->shutdown(server->ssocket, SEND_SHUTDOWN);
+   kernel_sock_shutdown(server->ssocket, SHUT_WR);
cFYI(1, ("Post shutdown state: 0x%x Flags: 0x%lx",
server->ssocket->state,
server->ssocket->flags));
diff --git a/fs/ocfs2/cluster/tcp.c b/fs/ocfs2/cluster/tcp.c
index 685c180..d84bd15 100644
--- a/fs/ocfs2/cluster/tcp.c
+++ b/fs/ocfs2/cluster/tcp.c
@@ -58,6 +58,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -616,8 +617,7 @@ static void o2net_shutdown_sc(struct work_struct *work)
del_timer_sync(&sc->sc_idle_timeout);
o2net_sc_cancel_delayed_work(sc, &sc->sc_keepalive_work);
sc_put(sc);
-   sc->sc_sock->ops->shutdown(sc->sc_sock,
-  RCV_SHUTDOWN|SEND_SHUTDOWN);
+   kernel_sock_shutdown(sc->sc_sock, SHUT_RDWR);
}
 
/* not fatal so failed connects before the other guy has our
diff --git a/include/linux/net.h b/include/linux/net.h
index dd79cdb..c804d81 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -95,6 +95,12 @@ enum sock_type {
 
 #endif /* ARCH_HAS_SOCKET_TYPES */
 
+enum {
+   SHUT_RD = 0,
+   SHUT_WR = 1,
+   SHUT_RDWR   = 2,
+};
+
 /**
  *  struct socket - general BSD socket
  *  @state: socket state (%SS_CONNECTED, etc)
@@ -223,6 +229,7 @@ extern int kernel_setsockopt(struct socket *sock, int 
level, int optname,
 extern int kernel_sendpage(struct socket *sock, struct page *page, int offset,
   size_t size, int flags);
 extern int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg);
+extern int kernel_sock_shutdown(struct socket *sock, int how);
 
 #ifndef CONFIG_SMP
 #define SOCKOPS_WRAPPED(name) name
diff --git a/net/rxrpc/ar-local.c b/net/rxrpc/ar-local.c
index fe03f71..f3a2bd7 100644
--- a/net/rxrpc/ar-local.c
+++ b/net/rxrpc/ar-local.c
@@ -114,7 +114,7 @@ static int rxrpc_create_local(struct rxrpc_local *local)
return 0;
 
 error:
-   local->socket->ops->shutdown(local->socket, 2);
+   kernel_sock_shutdown(local->socket, SHUT_RDWR);
local->socket->sk->sk_user_data = NULL;
sock_release(local->socket);
local->socket = NULL;
@@ -267,7 +267,7 @@ static void rxrpc_destroy_local(struct work_struct *work)
/* finish cleaning up the local descriptor */
rxrpc_purge_queue(&local->accept_queue);
rxrpc_purge_queue(&local->reject_queue);
-   local->socket->ops->shutdown(local->socket, 2);
+   kernel_sock_shutdown(local->socket, SHUT_RDWR);
sock_release(local->socket);
 
up_read(&rxrpc_local_sem);
diff --git a/net/socket.c b/net/socket.c
index 5d879fd..1e41b15 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2319,6 +2319,11 @@ int kernel_sock_ioctl(struct socket *sock, int cmd, 
unsigned long arg)
return err;
 }
 
+int kernel_sock_shutdown(struct socket *sock, int how)
+{
+   return sock->ops->shutdown(sock, h

[PATCH 02/05] r8169: do not enable the TBI for the 8168 and the 81x0

[Francois Romieu]

The 8168c and the 8100e choke on it. I have not seen an indication
nor received a report that the TBI is being actively used on the
remaining 8168b and 8110. Let's disable it for now until someone
complains.

Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Matthias Winkler <[EMAIL PROTECTED]>
Cc: Maarten Vanraes <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
 drivers/net/r8169.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 702334e..9dbab3f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1741,7 +1741,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
tp->features |= rtl_try_msi(pdev, ioaddr, cfg);
RTL_W8(Cfg9346, Cfg9346_Lock);
 
-   if (RTL_R8(PHYstatus) & TBI_Enable) {
+   if ((tp->mac_version <= RTL_GIGA_MAC_VER_06) &&
+   (RTL_R8(PHYstatus) & TBI_Enable)) {
tp->set_speed = rtl8169_set_speed_tbi;
tp->get_settings = rtl8169_gset_tbi;
tp->phy_reset_enable = rtl8169_tbi_reset_enable;
-- 
1.5.3.3

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

[PATCH 04/05] r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (bis repetita)

[Francois Romieu]

RTL_GIGA_MAC_VER_17 breaks as well.

Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
 drivers/net/r8169.c |   16 
 1 files changed, 0 insertions(+), 16 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index a37cf82..f9ba2e4 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1247,16 +1247,6 @@ static void rtl8169sb_hw_phy_config(void __iomem *ioaddr)
 
rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
 }
-static void rtl8168b_hw_phy_config(void __iomem *ioaddr)
-{
-   struct phy_reg phy_reg_init[] = {
-   { 0x1f, 0x },
-   { 0x10, 0xf41b },
-   { 0x1f, 0x }
-   };
-
-   rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
-}
 
 static void rtl8168cp_hw_phy_config(void __iomem *ioaddr)
 {
@@ -1326,12 +1316,6 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_04:
rtl8169sb_hw_phy_config(ioaddr);
break;
-   case RTL_GIGA_MAC_VER_11:
-   case RTL_GIGA_MAC_VER_12:
-   break;
-   case RTL_GIGA_MAC_VER_17:
-   rtl8168b_hw_phy_config(ioaddr);
-   break;
case RTL_GIGA_MAC_VER_18:
rtl8168cp_hw_phy_config(ioaddr);
break;
-- 
1.5.3.3

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

Re: [PATCH 02/05] ipv6: RFC4214 Support (2)

[YOSHIFUJI Hideaki / 吉藤英明]

In article <[EMAIL PROTECTED]> (at Thu, 08 Nov 2007 12:41:39 -0800), osprey67 
<[EMAIL PROTECTED]> says:

> From: Fred L. Templin <[EMAIL PROTECTED]>
> 
> This is experimental support for the Intra-Site Automatic
> Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
> the SIT module, and is configured using the unmodified
> "ip" utility with device names beginning with: "isatap".
> 
> The following diffs are specific to the Linux 2.6.24-rc2
> kernel distribution.
> 
> Signed-off-by: Fred L. Templin <[EMAIL PROTECTED]>

Hmm...tabs are still mangled, and it's better to have your
official address.  Anyway...

> --- linux-2.6.24-rc2/include/net/addrconf.h.orig2007-11-08 
> 12:06:17.0 -0800
> +++ linux-2.6.24-rc2/include/net/addrconf.h 2007-11-08 08:27:24.0 
> -0800
> @@ -241,6 +241,37 @@ static inline int ipv6_addr_is_ll_all_ro
>  addr->s6_addr32[3] == htonl(0x0002));
>   }
> 
> +#if defined(CONFIG_IPV6_ISATAP)
> +static inline int ipv6_isatap_eui64(u8 *eui, __be32 addr)
> +{
> +
> +   /* RFC3330 Special-Use IPv4 Addresses */
> +   eui[0] = (((addr & htonl(0xFF00)) == htonl(0x)) ||
> + ((addr & htonl(0xFF00)) == htonl(0x0A00)) ||
> + ((addr & htonl(0xFF00)) == htonl(0x0D00)) ||
> + ((addr & htonl(0xFF00)) == htonl(0x1800)) ||
> + ((addr & htonl(0xFF00)) == htonl(0x7F00)) ||
> + ((addr & htonl(0x)) == htonl(0xA9FE)) ||
> + ((addr & htonl(0xFFF0)) == htonl(0xAC10)) ||
> + ((addr & htonl(0xFF00)) == htonl(0xC200)) ||
> + ((addr & htonl(0xFF00)) == htonl(0xC0586300)) ||
> + ((addr & htonl(0x)) == htonl(0xC0A8)) ||
> + ((addr & htonl(0xFFFE)) == htonl(0xC612)) ||
> + ((addr & htonl(0xF000)) == htonl(0xE000)) ||
> + ((addr & htonl(0xF000)) == htonl(0xF000))) ?
> +   0x00 : 0x02;
> +
> +   eui[1] = 0; eui[2] = 0x5E; eui[3] = 0xFE;
> +   memcpy (eui+4, &addr, 4);
> +   return 0;
> +}
> +

Please put this function in net/ipv6/addrconf.c as addrconf_ifid_isatap().

Please use MULTICAST, LOCALNET etc. (and probaly introduce new macro
for others).  IMHO, it's better to add a comment for each entry, e.g.,
MULTICAST(addr) ||  /* 224.0.0.0/4 */
instead of
((addr & htonl(0xF000)) == htonl(0xE000)) ||

> +static inline int ipv6_addr_is_isatap(const struct in6_addr *addr)
> +{
> +   return ((addr->s6_addr32[2] | htonl(0x0200)) == 
> htonl(0x02005EFE));
> +}
> +#endif
> +

ipv6_addr_isatap(), maybe (to align with ipv6_addr_any() etc.).

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

[PATCH 03/05] r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)

[Francois Romieu]

Various symptoms depending on the .config options:
- the card stops working after some (short) time
- the card does not work at all
- the card disappears (nothing in lspci/dmesg)

A real power-off is needed to recover the card.

Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
 drivers/net/r8169.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9dbab3f..a37cf82 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1328,6 +1328,7 @@ static void rtl_hw_phy_config(struct net_device *dev)
break;
case RTL_GIGA_MAC_VER_11:
case RTL_GIGA_MAC_VER_12:
+   break;
case RTL_GIGA_MAC_VER_17:
rtl8168b_hw_phy_config(ioaddr);
break;
-- 
1.5.3.3

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

[PATCH 05/05] r8169: prevent bit sign expansion error in mdio_write

[Francois Romieu]

Oops.

The current code does not like being given an u16 with the highest
bit set as an argument to mdio_write. Let's enforce a correct range of
values for both the register address and value (resp. 5 and 16 bits).

The callers are currently left as-is.

Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
 drivers/net/r8169.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index f9ba2e4..1f647b9 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -470,7 +470,7 @@ static void mdio_write(void __iomem *ioaddr, int reg_addr, 
int value)
 {
int i;
 
-   RTL_W32(PHYAR, 0x8000 | (reg_addr & 0xFF) << 16 | value);
+   RTL_W32(PHYAR, 0x8000 | (reg_addr & 0x1f) << 16 | (value & 0x));
 
for (i = 20; i > 0; i--) {
/*
@@ -487,7 +487,7 @@ static int mdio_read(void __iomem *ioaddr, int reg_addr)
 {
int i, value = -1;
 
-   RTL_W32(PHYAR, 0x0 | (reg_addr & 0xFF) << 16);
+   RTL_W32(PHYAR, 0x0 | (reg_addr & 0x1f) << 16);
 
for (i = 20; i > 0; i--) {
/*
@@ -495,7 +495,7 @@ static int mdio_read(void __iomem *ioaddr, int reg_addr)
 * the specified MII register.
 */
if (RTL_R32(PHYAR) & 0x8000) {
-   value = (int) (RTL_R32(PHYAR) & 0x);
+   value = RTL_R32(PHYAR) & 0x;
break;
}
udelay(25);
-- 
1.5.3.3

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

[PATCH 00/05] pull request for 'upstream-jeff' branch

[Francois Romieu]

Please pull from branch 'upstream-jeff' in repository

git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git 
upstream-jeff

to get the changes below.

They should make things better for people who have experienced the 8168b
regression since 2.6.24-rc1.

Distance from 'master' (f2511f13daaf00fdd206bee7b108f75923a613c6)
-

407b35429151dd1d7a64cbef9f4bc59dac2efe5d
d981c1de3b81edf50fe59f0e1298668919117b14
9d891d0bb0a14bc8184eee45323cb010db4d0db4
69b4d070ea49bd7f589776ea471a69883455
db1470271c581050dcacc6ed681b9166d30bdba0

Diffstat


 drivers/net/r8169.c |   26 +++---
 1 files changed, 7 insertions(+), 19 deletions(-)

Shortlog


Ciaran McCreesh (1):
  r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard

Francois Romieu (2):
  r8169: do not enable the TBI for the 8168 and the 81x0
  r8169: prevent bit sign expansion error in mdio_write

Mark Lord (2):
  r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)
  r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (bis repetita)

Patch
-

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b94fa7e..1f647b9 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -171,6 +171,8 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(0x16ec,0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS,0x1032,
PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
+   { 0x0001,   0x8168,
+   PCI_ANY_ID, 0x2410, 0, 0, RTL_CFG_2 },
{0,},
 };
 
@@ -468,7 +470,7 @@ static void mdio_write(void __iomem *ioaddr, int reg_addr, 
int value)
 {
int i;
 
-   RTL_W32(PHYAR, 0x8000 | (reg_addr & 0xFF) << 16 | value);
+   RTL_W32(PHYAR, 0x8000 | (reg_addr & 0x1f) << 16 | (value & 0x));
 
for (i = 20; i > 0; i--) {
/*
@@ -485,7 +487,7 @@ static int mdio_read(void __iomem *ioaddr, int reg_addr)
 {
int i, value = -1;
 
-   RTL_W32(PHYAR, 0x0 | (reg_addr & 0xFF) << 16);
+   RTL_W32(PHYAR, 0x0 | (reg_addr & 0x1f) << 16);
 
for (i = 20; i > 0; i--) {
/*
@@ -493,7 +495,7 @@ static int mdio_read(void __iomem *ioaddr, int reg_addr)
 * the specified MII register.
 */
if (RTL_R32(PHYAR) & 0x8000) {
-   value = (int) (RTL_R32(PHYAR) & 0x);
+   value = RTL_R32(PHYAR) & 0x;
break;
}
udelay(25);
@@ -1245,16 +1247,6 @@ static void rtl8169sb_hw_phy_config(void __iomem *ioaddr)
 
rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
 }
-static void rtl8168b_hw_phy_config(void __iomem *ioaddr)
-{
-   struct phy_reg phy_reg_init[] = {
-   { 0x1f, 0x },
-   { 0x10, 0xf41b },
-   { 0x1f, 0x }
-   };
-
-   rtl_phy_write(ioaddr, phy_reg_init, ARRAY_SIZE(phy_reg_init));
-}
 
 static void rtl8168cp_hw_phy_config(void __iomem *ioaddr)
 {
@@ -1324,11 +1316,6 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_04:
rtl8169sb_hw_phy_config(ioaddr);
break;
-   case RTL_GIGA_MAC_VER_11:
-   case RTL_GIGA_MAC_VER_12:
-   case RTL_GIGA_MAC_VER_17:
-   rtl8168b_hw_phy_config(ioaddr);
-   break;
case RTL_GIGA_MAC_VER_18:
rtl8168cp_hw_phy_config(ioaddr);
break;
@@ -1739,7 +1726,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
tp->features |= rtl_try_msi(pdev, ioaddr, cfg);
RTL_W8(Cfg9346, Cfg9346_Lock);
 
-   if (RTL_R8(PHYstatus) & TBI_Enable) {
+   if ((tp->mac_version <= RTL_GIGA_MAC_VER_06) &&
+   (RTL_R8(PHYstatus) & TBI_Enable)) {
tp->set_speed = rtl8169_set_speed_tbi;
tp->get_settings = rtl8169_gset_tbi;
tp->phy_reset_enable = rtl8169_tbi_reset_enable;
-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/05] r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard

[Francois Romieu]

Signed-off-by: Ciaran McCreesh <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
 drivers/net/r8169.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b94fa7e..702334e 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -171,6 +171,8 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(0x16ec,0x0116), 0, 0, RTL_CFG_0 },
{ PCI_VENDOR_ID_LINKSYS,0x1032,
PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
+   { 0x0001,   0x8168,
+   PCI_ANY_ID, 0x2410, 0, 0, RTL_CFG_2 },
{0,},
 };
 
-- 
1.5.3.3

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

[PATCH 1/2] forcedeth new mcp79 device ids

[Ayaz Abdulla]

This patch adds new device ids for mcp79 devices.

Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]>

--- old/include/linux/pci_ids.h 2007-11-07 14:14:01.0 -0500
+++ new/include/linux/pci_ids.h 2007-11-07 14:13:53.0 -0500
@@ -1237,6 +1237,10 @@
 #define PCI_DEVICE_ID_NVIDIA_NVENET_33  0x0761
 #define PCI_DEVICE_ID_NVIDIA_NVENET_34  0x0762
 #define PCI_DEVICE_ID_NVIDIA_NVENET_35  0x0763
+#define PCI_DEVICE_ID_NVIDIA_NVENET_36  0x0AB0
+#define PCI_DEVICE_ID_NVIDIA_NVENET_37  0x0AB1
+#define PCI_DEVICE_ID_NVIDIA_NVENET_38  0x0AB2
+#define PCI_DEVICE_ID_NVIDIA_NVENET_39  0x0AB3
 
 #define PCI_VENDOR_ID_IMS  0x10e0
 #define PCI_DEVICE_ID_IMS_TT1280x9128

[PATCH 2/2] forcedeth new mcp79 device ids

[Ayaz Abdulla]

This patch adds new device ids and features for mcp79 devices into the 
forcedeth driver.


Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]>

--- old/drivers/net/forcedeth.c 2007-11-07 14:13:47.0 -0500
+++ new/drivers/net/forcedeth.c 2007-11-07 14:13:39.0 -0500
@@ -5613,6 +5613,22 @@
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 
PCI_DEVICE_ID_NVIDIA_NVENET_35),
.driver_data = 
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
},
+   {   /* MCP79 Ethernet Controller */
+   PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 
PCI_DEVICE_ID_NVIDIA_NVENET_36),
+   .driver_data = 
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+   },
+   {   /* MCP79 Ethernet Controller */
+   PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 
PCI_DEVICE_ID_NVIDIA_NVENET_37),
+   .driver_data = 
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+   },
+   {   /* MCP79 Ethernet Controller */
+   PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 
PCI_DEVICE_ID_NVIDIA_NVENET_38),
+   .driver_data = 
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+   },
+   {   /* MCP79 Ethernet Controller */
+   PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, 
PCI_DEVICE_ID_NVIDIA_NVENET_39),
+   .driver_data = 
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+   },
{0,},
 };
 

Re: 2.6.24-rc1-gb4f5550 oops

[Rafael J. Wysocki]

On Thursday, 8 of November 2007, Grant Wilson wrote:
> On Thu, 8 Nov 2007 22:42:21 +0100
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> 
> > On Thursday, 8 of November 2007, Grant Wilson wrote:
> > > On Thu, 8 Nov 2007 16:53:10 +0100
> > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > 
> > > > On Thursday, 8 of November 2007, Grant Wilson wrote:
> > > > > On Thu, 8 Nov 2007 01:06:21 +0100
> > > > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > > > 
> > > > > > On Monday, 5 of November 2007, Grant Wilson wrote:
> > > > > > > Hi,
> > > > > > > I got this oops on 2.6.24-rc1-641-gb4f5550:
> > > > > > 
> > > > > > (1) Is this reproducible?
> > > > > > (2) Did it happen previously on your system?
> > > > > >
> > > > > > [18073.371126] Unable to handle kernel NULL pointer dereference at 
> > > > > > 0120 RIP: 
> > > > > > [18073.371134]  [] check_preempt_wakeup+0x6e/0x110
> > > > > 
> > > > > This has now happened twice - the second time was last night when
> > > > > running 2.6.24-rc2.
> > > > > 
> > > > > Here's that second occurrence:
> > > > > 
> > > [snip]
> > > > 
> > > > Hmm.
> > > > 
> > > > Please run "gdb vmlinux" and see what code corresponds to
> > > > check_preempt_wakeup+0x6e in your kernel.
> > >
> > > 
> > > Dump of assembler code for function check_preempt_wakeup:
> > 
> > Well, thanks, but I meant the source code.  Please do "gdb vmlinux" and then
> > "l *check_preempt_wakeup+0x6e" in gdb.
> 
> Here's the requested output:
> 
> (gdb) l *check_preempt_wakeup+0x6e
> 0x802329ae is in check_preempt_wakeup (kernel/sched_fair.c:668).
> 663
> 664 /* Do the two (enqueued) entities belong to the same group ? */
> 665 static inline int
> 666 is_same_group(struct sched_entity *se, struct sched_entity *pse)
> 667 {
> 668 if (se->cfs_rq == pse->cfs_rq)
> 669 return 1;
> 670
> 671 return 0;
> 672 }

Well, it looks like either se or pse is NULL.

Ingo, can you please have a look?

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

Re: 2.6.24-rc1-gb4f5550 oops

[Grant Wilson]

On Thu, 8 Nov 2007 22:42:21 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Thursday, 8 of November 2007, Grant Wilson wrote:
> > On Thu, 8 Nov 2007 16:53:10 +0100
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > 
> > > On Thursday, 8 of November 2007, Grant Wilson wrote:
> > > > On Thu, 8 Nov 2007 01:06:21 +0100
> > > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > > 
> > > > > On Monday, 5 of November 2007, Grant Wilson wrote:
> > > > > > Hi,
> > > > > > I got this oops on 2.6.24-rc1-641-gb4f5550:
> > > > > 
> > > > > (1) Is this reproducible?
> > > > > (2) Did it happen previously on your system?
> > > > >
> > > > > [18073.371126] Unable to handle kernel NULL pointer dereference at 
> > > > > 0120 RIP: 
> > > > > [18073.371134]  [] check_preempt_wakeup+0x6e/0x110
> > > > 
> > > > This has now happened twice - the second time was last night when
> > > > running 2.6.24-rc2.
> > > > 
> > > > Here's that second occurrence:
> > > > 
> > [snip]
> > > 
> > > Hmm.
> > > 
> > > Please run "gdb vmlinux" and see what code corresponds to
> > > check_preempt_wakeup+0x6e in your kernel.
> >
> > 
> > Dump of assembler code for function check_preempt_wakeup:
> 
> Well, thanks, but I meant the source code.  Please do "gdb vmlinux" and then
> "l *check_preempt_wakeup+0x6e" in gdb.

Here's the requested output:

(gdb) l *check_preempt_wakeup+0x6e
0x802329ae is in check_preempt_wakeup (kernel/sched_fair.c:668).
663
664 /* Do the two (enqueued) entities belong to the same group ? */
665 static inline int
666 is_same_group(struct sched_entity *se, struct sched_entity *pse)
667 {
668 if (se->cfs_rq == pse->cfs_rq)
669 return 1;
670
671 return 0;
672 }

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

Re: 2.6.24-rc1-gb4f5550 oops

[Rafael J. Wysocki]

On Thursday, 8 of November 2007, Grant Wilson wrote:
> On Thu, 8 Nov 2007 16:53:10 +0100
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> 
> > On Thursday, 8 of November 2007, Grant Wilson wrote:
> > > On Thu, 8 Nov 2007 01:06:21 +0100
> > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > > 
> > > > On Monday, 5 of November 2007, Grant Wilson wrote:
> > > > > Hi,
> > > > > I got this oops on 2.6.24-rc1-641-gb4f5550:
> > > > 
> > > > (1) Is this reproducible?
> > > > (2) Did it happen previously on your system?
> > > >
> > > > [18073.371126] Unable to handle kernel NULL pointer dereference at 
> > > > 0120 RIP: 
> > > > [18073.371134]  [] check_preempt_wakeup+0x6e/0x110
> > > 
> > > This has now happened twice - the second time was last night when
> > > running 2.6.24-rc2.
> > > 
> > > Here's that second occurrence:
> > > 
> [snip]
> > 
> > Hmm.
> > 
> > Please run "gdb vmlinux" and see what code corresponds to
> > check_preempt_wakeup+0x6e in your kernel.
>
> 
> Dump of assembler code for function check_preempt_wakeup:

Well, thanks, but I meant the source code.  Please do "gdb vmlinux" and then
"l *check_preempt_wakeup+0x6e" in gdb.

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

RE: [PATCH 04/05] ipv6: RFC4214 Support

[Templin, Fred L]

> Hmm, what is missing from API POV?

This would have to be determined under a follow-on project (hopefully
with input from others) after we have gained operational experience.

> Since even if you do not change iproute2 now, users may need
> to change their configuration script twice anyway, we should
> be careful.

The unmodified iproute2 gives a basic API that is sufficient for now.
A more feature-rich API can be developed later, but the basic API
will remain in place such that no existing scripts would have to
change and new scripts could benefit from the new API. 

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

Re: Why does a connect to IPv6 LLA address fail ?

[Vlad Yasevich]

Karsten Keil wrote:
> 
> OK I run into this issue while running the TAHI testsuite. The test is as
> follows:
> 
>   Check 03:
> DNS Address: fec0::9
> Candidate Source Addresses: fec0::1(SS) or LLA(LS)
> Destination Address List: 3fff::2(GS) or fe80::2(LS)
> Result: fe80::2 (src LLA) then 3fff::2 (src fec0::1)
> 
> Scope(fe80::2) = Scope(LLA) and Scope(3fff::2) <> Scope(fec0::1), then 
> prefer fe80::2
> 
> the nameserver send following answer for the query:
> 
> | | | | DNS_Question(length:21)
> | | | | | DNS_QuestionEntry   (length:21)
> | | | | | | Name = server.tahi.org.
> | | | | | | Type = 28 ()
> | | | | | | Class= 1
> | | | | DNS_Answer  (length:86)
> | | | | | DNS_RR_ (length:43)
> | | | | | | Name = server.tahi.org.
> | | | | | | Type = 28
> | | | | | | Class= 1
> | | | | | | TTL  = 0
> | | | | | | Length   = 16
> | | | | | | Address  = 3fff::2
> | | | | | DNS_RR_ (length:43)
> | | | | | | Name = server.tahi.org.
> | | | | | | Type = 28
> | | | | | | Class= 1
> | | | | | | TTL  = 0
> | | | | | | Length   = 16
> | | | | | | Address  = fe80::2
> 
> 
> 
> So how we should handle this issue, claim that the test is wrong, the test
> should not use LLA for this ?
> 

You could argue that a DNS server should not return link-local addresses 
because there
is no way for the DNS server to specify a correct zone.

I believe this is actually documented somewhere...

-vlad

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

Re: No implementation of NETLINK_USERSOCK ?

[Matti Aarnio]

Following up on myself...

On Thu, Nov 08, 2007 at 05:15:12PM +0200, Matti Aarnio wrote:
> Some 6 months ago I asked about a way to make network protocol
> servers(s) that live in userspace, but whose application interface
> still uses kernel socket calls.
> 
> I recall getting an answer that there is  NETLINK_USERSOCK for that
> use.  I have tried to have a look into what NETLINK_USERSOCK
> supplies to its users, but alas there appears to be no implementation
> at all in existence.   Is it some sort of placeholder of things
> to implement some day ?

The more I am reading around places, the more it looks like there
really is no implementation, but somebody thought that such would
be a nice thing to have.

It did appear around  Linux 2.2, and probable reservation maker was
Alexey N. Kuznetsov. 

So, in order to implement the thing, something must be defined at
first.  Requirements are at least:

   - Applications see SOCKET API, and addresses are presentable
 via  struct sockaddr*   -- meaning that 16 bit sa_family leads
 the record, or possibly leading byte is record size and
 second one is family.

   - sa_family number space must be somehow managed, for example
 with file:  /etc/socketfamilies

   #PF_## value: 128-254
   #nn  'struct sockaddr' size in bytes
   # # PF_### keyword name
   # Explanatory name
   #
   128  36  PF_USERSOCK1 Experimental usersock 1
   129  80  PF_USERSOCK2 Experimental usersock 2
   130  22  PF_USERSOCK3 Experimental usersock 3

 And why not all the built in "hard-coded" ones, too.
 
 The sa_family numbers _must_ be static for at least machine
 runtime, even if they are otherwise quite dynamic in nature.
 (Registering and reading them from /proc/sys/...  -file is
  a possibility.)

   - There is only one  NETLINK_USERSOCK, but it should somehow
 manage N different protocols.  N being at least 32.

   - Netlink itself is unrealiable protocol, but applications
 should still be able to read() and write() from it reliably.
 There is some reliability-thing in documentation.

   - For all intents and purposes the only difference from well
 established socket API based protocols, applications using
 NETLINK_USERSOCK implemented ones shall not be aware of
 anything being different except with the the how PF_
 literal is resolved.


What else is needed ?
Any pointers on how to construct this framework ?
Or does it exist although I didn't spot it yet ?

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

[PATCH 05/05] ipv6: RFC4214 Support (2)

[osprey67]

From: Fred L. Templin <[EMAIL PROTECTED]>

This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".

The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.

Signed-off-by: Fred L. Templin <[EMAIL PROTECTED]>

---

--- linux-2.6.24-rc2/net/ipv6/Kconfig.orig  2007-11-08 12:07:17.0 
-0800
+++ linux-2.6.24-rc2/net/ipv6/Kconfig   2007-11-08 08:27:48.0 -0800
@@ -57,6 +57,17 @@ config IPV6_ROUTE_INFO

  If unsure, say N.

+config IPV6_ISATAP
+   bool "IPv6: ISATAP (RFC 4214) support (EXPERIMENTAL)"
+   depends on IPV6 && EXPERIMENTAL
+   ---help---
+ This is experimental support for the Intra-Site Automatic
+ Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
+ the SIT module, and is configured using the "ip" utility
+ with device names beginning with: "isatap".
+
+ If unsure, say N.
+
 config IPV6_OPTIMISTIC_DAD
bool "IPv6: Enable RFC 4429 Optimistic DAD (EXPERIMENTAL)"
depends on IPV6 && EXPERIMENTAL
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/05] ipv6: RFC4214 Support (2)

[osprey67]

From: Fred L. Templin <[EMAIL PROTECTED]>

This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".

The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.

Signed-off-by: Fred L. Templin <[EMAIL PROTECTED]>

---

--- linux-2.6.24-rc2/net/ipv6/sit.c.orig2007-11-08 12:03:41.0 
-0800
+++ linux-2.6.24-rc2/net/ipv6/sit.c 2007-11-08 08:31:08.0 -0800
@@ -16,6 +16,7 @@
  * Changes:
  * Roger Venning <[EMAIL PROTECTED]>:  6to4 support
  * Nate Thompson <[EMAIL PROTECTED]>:6to4 support
+ * Fred L. Templin <[EMAIL PROTECTED]>:isatap support
  */

 #include 
@@ -154,6 +155,14 @@ static struct ip_tunnel * ipip6_tunnel_l
struct net_device *dev;
char name[IFNAMSIZ];

+#if defined(CONFIG_IPV6_ISATAP)
+   /* ISATAP (RFC4214) - router address in daddr */
+   if (!strncmp(parms->name, "isatap", 6)) {
+   parms->i_key = parms->iph.daddr;
+   parms->iph.daddr = remote = 0;
+   }
+#endif
+
for (tp = __ipip6_bucket(parms); (t = *tp) != NULL; tp = &t->next) {
if (local == t->parms.iph.saddr && remote == t->parms.iph.daddr)
return t;
@@ -182,6 +191,11 @@ static struct ip_tunnel * ipip6_tunnel_l
dev->init = ipip6_tunnel_init;
nt->parms = *parms;

+#if defined(CONFIG_IPV6_ISATAP)
+   if (!strncmp(dev->name, "isatap", 6))
+   dev->priv_flags |= IFF_ISATAP;
+#endif
+
if (register_netdevice(dev) < 0) {
free_netdev(dev);
goto failed;
@@ -382,6 +396,47 @@ static int ipip6_rcv(struct sk_buff *skb
IPCB(skb)->flags = 0;
skb->protocol = htons(ETH_P_IPV6);
skb->pkt_type = PACKET_HOST;
+#if defined(CONFIG_IPV6_ISATAP)
+   /* ISATAP (RFC4214) - check source address */
+   if (tunnel->dev->priv_flags & IFF_ISATAP) {
+   struct neighbour *neigh;
+   struct dst_entry *dst;
+   struct flowi fl;
+   struct in6_addr *addr6;
+   struct ipv6hdr *iph6;
+
+   /* from ISATAP router */
+   if (iph->saddr == tunnel->parms.i_key) goto accept;
+
+   iph6 = ipv6_hdr(skb);
+   addr6 = &iph6->saddr;
+
+   /* from legitimate previous hop */
+   memset(&fl, 0, sizeof(fl));
+   fl.proto = iph6->nexthdr;
+   ipv6_addr_copy(&fl.fl6_dst, addr6);
+   fl.oif = tunnel->dev->ifindex;
+   security_skb_classify_flow(skb, &fl);
+
+   if (!(dst = ip6_route_output(NULL, &fl)) ||
+(dst->dev != tunnel->dev) ||
+((neigh = dst->neighbour) == NULL)) goto drop;
+
+   addr6 = (struct in6_addr*)&neigh->primary_key;
+
+   if (!(ipv6_addr_is_isatap(addr6)) ||
+(addr6->s6_addr32[3] != iph->saddr)) {
+drop:
+   tunnel->stat.rx_errors++;
+   read_unlock(&ipip6_lock);
+   dst_release(dst);
+   kfree_skb(skb);
+   return 0;
+   }
+   dst_release(dst);
+   }
+accept:
+#endif
tunnel->stat.rx_packets++;
tunnel->stat.rx_bytes += skb->len;
skb->dev = tunnel->dev;
@@ -444,6 +499,31 @@ static int ipip6_tunnel_xmit(struct sk_b
if (skb->protocol != htons(ETH_P_IPV6))
goto tx_error;

+#if defined(CONFIG_IPV6_ISATAP)
+   /* ISATAP (RFC4214) - must come before 6to4 */
+   if (dev->priv_flags & IFF_ISATAP) {
+   struct neighbour *neigh = NULL;
+
+   if (skb->dst)
+   neigh = skb->dst->neighbour;
+
+   if (neigh == NULL) {
+   if (net_ratelimit())
+   printk(KERN_DEBUG "sit: nexthop == NULL\n");
+   goto tx_error;
+   }
+
+   addr6 = (struct in6_addr*)&neigh->primary_key;
+   addr_type = ipv6_addr_type(addr6);
+
+   if ((addr_type & IPV6_ADDR_UNICAST) &&
+ipv6_addr_is_isatap(addr6))
+   dst = addr6->s6_addr32[3];
+   else
+   goto tx_error;
+   }
+#endif /* CONFIG_IPV6_ISATAP */
+
if (!dst)
dst = try_6to4(&iph6->daddr);

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More major

[PATCH 03/05] ipv6: RFC4214 Support (2)

[osprey67]

From: Fred L. Templin <[EMAIL PROTECTED]>

This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".

The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.

Signed-off-by: Fred L. Templin <[EMAIL PROTECTED]>

---

--- linux-2.6.24-rc2/net/ipv6/addrconf.c.orig   2007-11-08 11:59:35.0 
-0800
+++ linux-2.6.24-rc2/net/ipv6/addrconf.c2007-11-08 11:28:43.0 
-0800
@@ -75,7 +75,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 

 #ifdef CONFIG_IPV6_PRIVACY
@@ -1435,6 +1435,11 @@ static int ipv6_generate_eui64(u8 *eui,
return addrconf_ifid_arcnet(eui, dev);
case ARPHRD_INFINIBAND:
return addrconf_ifid_infiniband(eui, dev);
+#if defined(CONFIG_IPV6_ISATAP)
+   case ARPHRD_SIT:
+   if (dev->priv_flags&IFF_ISATAP)
+   return ipv6_isatap_eui64(eui, *(__be32 *)dev->dev_addr);
+#endif
}
return -1;
 }
@@ -2201,6 +2206,31 @@ static void addrconf_sit_config(struct n
return;
}

+#if defined(CONFIG_IPV6_ISATAP)
+   /* ISATAP (RFC4214) - configure as NBMA link */
+   if (dev->priv_flags & IFF_ISATAP) {
+   struct in6_addr addr;
+
+   addrconf_add_lroute(dev);
+
+   ipv6_addr_set(&addr,  htonl(0xFE80), 0, 0, 0);
+
+   if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) {
+   struct inet6_ifaddr *ifp;
+
+   ifp = ipv6_add_addr(idev, &addr, 64,
+   IFA_LINK, IFA_F_PERMANENT);
+   if (!IS_ERR(ifp)) {
+   addrconf_prefix_route(&ifp->addr,
+   ifp->prefix_len, idev->dev, 0, 0);
+   addrconf_dad_start(ifp, 0);
+   in6_ifa_put(ifp);
+   }
+   }
+   return;
+   }
+#endif
+
sit_add_v4_addrs(idev);

if (dev->flags&IFF_POINTOPOINT) {
@@ -2531,6 +2561,16 @@ static void addrconf_rs_timer(unsigned l
 *  Announcement received after solicitation
 *  was sent
 */
+#if defined(CONFIG_IPV6_ISATAP)
+   /* ISATAP (RFC4214) - Re-DAD to trigger new RS/RA */
+   if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
+   spin_lock(&ifp->lock);
+   ifp->probes = 0;
+   ifp->idev->if_flags &= ~(IF_RS_SENT|IF_RA_RCVD);
+   addrconf_mod_timer(ifp, AC_DAD, HZ*120);
+   spin_unlock(&ifp->lock);
+   }
+#endif
goto out;
}

@@ -2545,10 +2585,30 @@ static void addrconf_rs_timer(unsigned l
   ifp->idev->cnf.rtr_solicit_interval);
spin_unlock(&ifp->lock);

+#if defined(CONFIG_IPV6_ISATAP)
+   /* ISATAP (RFC4214) - unicast RS */
+   if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
+   struct ip_tunnel *t = netdev_priv(ifp->idev->dev);
+   __be32 rtr = t->parms.i_key;
+
+   if (!rtr) goto out;
+
+   ipv6_addr_set(&all_routers, htonl(0xFE80), 0, 0, 0);
+   ipv6_isatap_eui64(all_routers.s6_addr + 8, rtr);
+   } else
+#endif
ipv6_addr_all_routers(&all_routers);

ndisc_send_rs(ifp->idev->dev, &ifp->addr, &all_routers);
} else {
+#if defined(CONFIG_IPV6_ISATAP)
+   /* ISATAP (RFC4214) - Re-DAD to trigger new RS/RA */
+   if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
+   ifp->probes = 0;
+   ifp->idev->if_flags &= ~(IF_RS_SENT|IF_RA_RCVD);
+   addrconf_mod_timer(ifp, AC_DAD, HZ*120);
+   }
+#endif
spin_unlock(&ifp->lock);
/*
 * Note: we do not support deprecated "all on-link"
@@ -2594,6 +2654,9 @@ static void addrconf_dad_start(struct in
spin_lock_bh(&ifp->lock);

if (dev->flags&(IFF_NOARP|IFF_LOOPBACK) ||
+#if defined(CONFIG_IPV6_ISATAP)
+   dev->priv_flags&IFF_ISATAP ||
+#endif
!(ifp->flags&IFA_F_TENTATIVE) ||
ifp->flags & IFA_F_NODAD) {
ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
@@ -2690,6 +2753,18 @@ static void addrconf_dad_completed(struc
(ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
struct in6_addr all_routers;

+#if defined(CONFIG_IPV6_ISATAP)
+   /* ISATAP (RFC4214) - unicast RS */
+   if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
+   struct ip_tunnel *t = netdev_

[PATCH 02/05] ipv6: RFC4214 Support (2)

[osprey67]

From: Fred L. Templin <[EMAIL PROTECTED]>

This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".

The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.

Signed-off-by: Fred L. Templin <[EMAIL PROTECTED]>

---

--- linux-2.6.24-rc2/include/net/addrconf.h.orig2007-11-08 
12:06:17.0 -0800
+++ linux-2.6.24-rc2/include/net/addrconf.h 2007-11-08 08:27:24.0 
-0800
@@ -241,6 +241,37 @@ static inline int ipv6_addr_is_ll_all_ro
addr->s6_addr32[3] == htonl(0x0002));
 }

+#if defined(CONFIG_IPV6_ISATAP)
+static inline int ipv6_isatap_eui64(u8 *eui, __be32 addr)
+{
+
+   /* RFC3330 Special-Use IPv4 Addresses */
+   eui[0] = (((addr & htonl(0xFF00)) == htonl(0x)) ||
+ ((addr & htonl(0xFF00)) == htonl(0x0A00)) ||
+ ((addr & htonl(0xFF00)) == htonl(0x0D00)) ||
+ ((addr & htonl(0xFF00)) == htonl(0x1800)) ||
+ ((addr & htonl(0xFF00)) == htonl(0x7F00)) ||
+ ((addr & htonl(0x)) == htonl(0xA9FE)) ||
+ ((addr & htonl(0xFFF0)) == htonl(0xAC10)) ||
+ ((addr & htonl(0xFF00)) == htonl(0xC200)) ||
+ ((addr & htonl(0xFF00)) == htonl(0xC0586300)) ||
+ ((addr & htonl(0x)) == htonl(0xC0A8)) ||
+ ((addr & htonl(0xFFFE)) == htonl(0xC612)) ||
+ ((addr & htonl(0xF000)) == htonl(0xE000)) ||
+ ((addr & htonl(0xF000)) == htonl(0xF000))) ?
+   0x00 : 0x02;
+
+   eui[1] = 0; eui[2] = 0x5E; eui[3] = 0xFE;
+   memcpy (eui+4, &addr, 4);
+   return 0;
+}
+
+static inline int ipv6_addr_is_isatap(const struct in6_addr *addr)
+{
+   return ((addr->s6_addr32[2] | htonl(0x0200)) == htonl(0x02005EFE));
+}
+#endif
+
 #ifdef CONFIG_PROC_FS
 extern int if6_proc_init(void);
 extern void if6_proc_exit(void);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/05] ipv6: RFC4214 Support (2)

[osprey67]

From: Fred L. Templin <[EMAIL PROTECTED]>

This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".

The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.

Signed-off-by: Fred L. Templin <[EMAIL PROTECTED]>

---

--- linux-2.6.24-rc2/include/linux/if.h.orig2007-11-08 12:05:47.0 
-0800
+++ linux-2.6.24-rc2/include/linux/if.h 2007-11-08 08:26:44.0 -0800
@@ -61,6 +61,7 @@
 #define IFF_MASTER_ALB 0x10/* bonding master, balance-alb. */
 #define IFF_BONDING0x20/* bonding master or slave  */
 #define IFF_SLAVE_NEEDARP 0x40 /* need ARPs for validation */
+#define IFF_ISATAP 0x80/* ISATAP interface (RFC4214)   */

 #define IF_GET_IFACE   0x0001  /* for querying only */
 #define IF_GET_PROTO   0x0002
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ipconfig.c : implement DHCP Class-identifier

[Ilpo Järvinen]

On Thu, 8 Nov 2007, Rainer Jochem wrote:

> @@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
>   *e++ = sizeof(ic_req_params);
>   memcpy(e, ic_req_params, sizeof(ic_req_params));
>   e += sizeof(ic_req_params);
> +
> + // Send it only if the according kernel parameter was set

No C99 comments please. Though I'm not sure if this comment is that 
necessary anyway...

> + if (*vendor_class_identifier) {
> + printk(KERN_INFO "Sending class identifier \"%s\"\n",
> +vendor_class_identifier);
> + *e++ = 60;  /* Class-identifier */
> + *e++ = strlen(vendor_class_identifier);
> + memcpy(e, vendor_class_identifier,
> +strlen(vendor_class_identifier));
> + e += strlen(vendor_class_identifier);
> + }
>   }
>  
>   *e++ = 255; /* End of the list */

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

Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file

[Scott Wood]

Sergej Stepanov wrote:

If both mdio and mdc controlling pins are on the same processor port,
one resource should be used.
Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.


How about:
The first reg resource is the I/O port register block on which MDIO 
resides.  The second reg resource is the I/O port register block on 
which MDC resides.  If there is only one reg resource, it is used for 
both MDIO and MDC.


We also need to change the reference to port C in fsl,mdio-pin and 
fsl,mdc-pin.


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

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Kim Phillips]

On Thu, 8 Nov 2007 21:39:52 +0300
Anton Vorontsov <[EMAIL PROTECTED]> wrote:

> On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
> > On Thu, 8 Nov 2007 17:16:11 +0300
> > Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> > 
> > > On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > > > Hello all,
> > > > 
> > > > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > > > according to erratum #2 (erratum text included below).  Basically the
> > > > most intrusive part is the addition of two new RGMII Internal Delay
> > > > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > > > both at the same time).
> > > > 
> > > > Please review, and since this affects both netdev and powerpc trees,
> > > > one maintainer should ack them for the other to push upstream (i.e,
> > > > Kumar acks them, and Leo picks them up to go through netdev or the
> > > > other way around; either way is fine with me).  I'm hoping they're
> > > > trivial enough to go in 2.6.24.
> > > > 
> > > > Depending on how the review goes, a follow-on patch to u-boot will be
> > > > sent out that fixes up the phy-connection-type in the device tree (from
> > > > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
> > > 
> > > I've upgraded CPU to rev2.1, board rev0.3.
> > > 
> > thanks for testing this.  I tested these patches on a "pilot assy 0.3".
> 
> Same here.
> 
> > > Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> > > the results:
> > > 
> > > If I use -rxid, then geth not able to transmit anything.
> > > With -txid geth not able to receive anything.
> > > 
> > > With just -id everything works fine though...
> > > 
> > > 
> > > Maybe there should be another condition, in addition to cpu rev2.1?
> > > 
> > the errata simply states 'pilot boards', but we can probably modify
> > u-boot to look at the cpu rev and the board rev (BCSR 12).
> > 
> > My bcsr12 looks like:
> > 
> > =>  md.b f80c 1
> > f80c: 10.
> > 
> > what is yours?
> 
> => md.b f80c 1
> f80c: 10.
> 
> :-/
> 
> U-Boot 1.3.0-rc3-g281df457-dirty (Nov  6 2007 - 18:19:35) MPC83XX
> CPU:   e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB:  264 MHz
> 
> [EMAIL PROTECTED]:~# cat /proc/cpuinfo 
> processor   : 0
> cpu : e300c1
> clock   : 528.00MHz
> revision: 3.1 (pvr 8083 0031)
> bogomips: 131.58
> timebase: 6600
> platform: MPC836x MDS
> 

check.  :/

> 
> +   /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
> +   svid = mfspr(SPRN_SVR);
> +   if (svid == 0x80480021) {
> 
> ^^ that branch executes on the board I'm testing.

right, but whether it does or not doesn't affect your failure outcome
either I'm assuming.

> > If it's something like 0x03, the u-boot patch will probably look like:
> > 
> > if ((bcsr[12] == 0x10) &&
> > (immr->sysconf.spridr == SPR_8360_REV21 ||
> >  immr->sysconf.spridr == SPR_8360E_REV21))
> > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > ...
> > 
> > but these linux patches would remain the same (the clk and data delay
> > settings for the UCC's are still valid; it's just the PHY config
> > that is triggering your problem from what I can tell).
> 
> Yup, most likely this is not UCC specific, but PHY. For some reason
> delays making harm here...

hmm..

Net:   UEC: PHY is Marvell 88E11x1 (1410cc2)

I have jumper JP1 set to 3.3V.

can you send me your:

=> md.b f800 15
f800: 04 04 00 c6 94 60 00 00 ac 2f 00 b8 10 3f 30 02.`.../...?0.
f810: 05 07 05 15 11.

and maybe try the following on top of these 5 patches (to specify rgmii
mode in the bcsr's):

diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c 
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0a72260..753071e 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -98,6 +98,11 @@ static void __init mpc836x_mds_setup_arch(void)
!= NULL){
uint svid;
 
+   /* configure RGMII mode for both GETH ports */
+#define BCSR8_TSECXM_RGMII 0xf0
+   clrbits8(&bcsr_regs[8], BCSR8_TSECXM_RGMII);
+
+
/* Reset the Ethernet PHY */
 #define BCSR9_GETHRST 0x20
clrbits8(&bcsr_regs[9], BCSR9_GETHRST);

Thanks,

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

Re: [2.6 patch] drivers/net/netxen/: cleanups

[Dhananjay Phadke]

This looks good to me, I might chop off these #if 0 'ed functions in
my next round of patches.

Acked-by: Dhananjay Phadke <[EMAIL PROTECTED]>

On 11/5/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch contains the following cleanups:
> - static functions in .c files shouldn't be marked inline
> - make needlessly global code static
> - #if 0 unused code
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
>  drivers/net/netxen/netxen_nic.h  |   14 
>  drivers/net/netxen/netxen_nic_hw.c   |   19 +++---
>  drivers/net/netxen/netxen_nic_hw.h   |8 --
>  drivers/net/netxen/netxen_nic_init.c |   70 ---
>  drivers/net/netxen/netxen_nic_isr.c  |7 +-
>  drivers/net/netxen/netxen_nic_main.c |9 +-
>  drivers/net/netxen/netxen_nic_niu.c  |   26 +---
>  drivers/net/netxen/netxen_nic_phan_reg.h |7 --
>  8 files changed, 76 insertions(+), 84 deletions(-)
>
> dbc7aeed37e41cd37a01cce259e5c0ab01f8dd88
> diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
> index fbc2553..ef9f986 100644
> --- a/drivers/net/netxen/netxen_nic.h
> +++ b/drivers/net/netxen/netxen_nic.h
> @@ -1015,14 +1015,8 @@ int netxen_niu_xgbe_enable_phy_interrupts(struct 
> netxen_adapter *adapter);
>  int netxen_niu_gbe_enable_phy_interrupts(struct netxen_adapter *adapter);
>  int netxen_niu_xgbe_disable_phy_interrupts(struct netxen_adapter *adapter);
>  int netxen_niu_gbe_disable_phy_interrupts(struct netxen_adapter *adapter);
> -int netxen_niu_xgbe_clear_phy_interrupts(struct netxen_adapter *adapter);
> -int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter);
>  void netxen_nic_xgbe_handle_phy_intr(struct netxen_adapter *adapter);
>  void netxen_nic_gbe_handle_phy_intr(struct netxen_adapter *adapter);
> -void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter, int port,
> -long enable);
> -void netxen_niu_gbe_set_gmii_mode(struct netxen_adapter *adapter, int port,
> - long enable);
>  int netxen_niu_gbe_phy_read(struct netxen_adapter *adapter, long reg,
> __u32 * readval);
>  int netxen_niu_gbe_phy_write(struct netxen_adapter *adapter,
> @@ -1045,7 +1039,6 @@ int netxen_nic_hw_write_wx(struct netxen_adapter 
> *adapter, u64 off, void *data,
>int len);
>  void netxen_crb_writelit_adapter(struct netxen_adapter *adapter,
>  unsigned long off, int data);
> -int netxen_nic_erase_pxe(struct netxen_adapter *adapter);
>
>  /* Functions from netxen_nic_init.c */
>  void netxen_free_adapter_offload(struct netxen_adapter *adapter);
> @@ -1064,15 +1057,10 @@ int netxen_flash_erase_secondary(struct 
> netxen_adapter *adapter);
>  int netxen_flash_erase_primary(struct netxen_adapter *adapter);
>  void netxen_halt_pegs(struct netxen_adapter *adapter);
>
> -int netxen_rom_fast_write(struct netxen_adapter *adapter, int addr, int 
> data);
>  int netxen_rom_se(struct netxen_adapter *adapter, int addr);
> -int netxen_do_rom_se(struct netxen_adapter *adapter, int addr);
>
>  /* Functions from netxen_nic_isr.c */
>  int netxen_nic_link_ok(struct netxen_adapter *adapter);
> -void netxen_nic_isr_other(struct netxen_adapter *adapter);
> -void netxen_indicate_link_status(struct netxen_adapter *adapter, u32 link);
> -void netxen_handle_port_int(struct netxen_adapter *adapter, u32 enable);
>  void netxen_initialize_adapter_sw(struct netxen_adapter *adapter);
>  void netxen_initialize_adapter_hw(struct netxen_adapter *adapter);
>  void *netxen_alloc(struct pci_dev *pdev, size_t sz, dma_addr_t * ptr,
> @@ -1089,8 +1077,6 @@ int netxen_nic_tx_has_work(struct netxen_adapter 
> *adapter);
>  void netxen_watchdog_task(struct work_struct *work);
>  void netxen_post_rx_buffers(struct netxen_adapter *adapter, u32 ctx,
> u32 ringid);
> -void netxen_post_rx_buffers_nodb(struct netxen_adapter *adapter, u32 ctx,
> -u32 ringid);
>  int netxen_process_cmd_ring(unsigned long data);
>  u32 netxen_process_rcv_ring(struct netxen_adapter *adapter, int ctx, int 
> max);
>  void netxen_nic_set_multi(struct net_device *netdev);
> diff --git a/drivers/net/netxen/netxen_nic_hw.c 
> b/drivers/net/netxen/netxen_nic_hw.c
> index 2c19b8d..b2c7861 100644
> --- a/drivers/net/netxen/netxen_nic_hw.c
> +++ b/drivers/net/netxen/netxen_nic_hw.c
> @@ -33,7 +33,6 @@
>
>  #include "netxen_nic.h"
>  #include "netxen_nic_hw.h"
> -#define DEFINE_GLOBAL_RECV_CRB
>  #include "netxen_nic_phan_reg.h"
>
>
> @@ -244,12 +243,15 @@ struct netxen_recv_crb recv_crb_registers[] = {
> },
>  };
>
> -u64 ctx_addr_sig_regs[][3] = {
> +static u64 ctx_addr_sig_regs[][3] = {
> {NETXEN_NIC_REG(0x188), NETXEN_NIC_REG(0x18c), NETXEN_NIC_REG(0x1c0)},
> {NETXEN_NIC_REG(0x190), NETXEN_NIC_REG(0x194), NETXEN_NIC_REG(0x1c4)},
> {NETXEN_NIC_REG(0x198), NETXEN_NIC_REG(0x1

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Anton Vorontsov]

On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
> On Thu, 8 Nov 2007 17:16:11 +0300
> Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> 
> > On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > > Hello all,
> > > 
> > > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > > according to erratum #2 (erratum text included below).  Basically the
> > > most intrusive part is the addition of two new RGMII Internal Delay
> > > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > > both at the same time).
> > > 
> > > Please review, and since this affects both netdev and powerpc trees,
> > > one maintainer should ack them for the other to push upstream (i.e,
> > > Kumar acks them, and Leo picks them up to go through netdev or the
> > > other way around; either way is fine with me).  I'm hoping they're
> > > trivial enough to go in 2.6.24.
> > > 
> > > Depending on how the review goes, a follow-on patch to u-boot will be
> > > sent out that fixes up the phy-connection-type in the device tree (from
> > > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
> > 
> > I've upgraded CPU to rev2.1, board rev0.3.
> > 
> thanks for testing this.  I tested these patches on a "pilot assy 0.3".

Same here.

> > Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> > the results:
> > 
> > If I use -rxid, then geth not able to transmit anything.
> > With -txid geth not able to receive anything.
> > 
> > With just -id everything works fine though...
> > 
> > 
> > Maybe there should be another condition, in addition to cpu rev2.1?
> > 
> the errata simply states 'pilot boards', but we can probably modify
> u-boot to look at the cpu rev and the board rev (BCSR 12).
> 
> My bcsr12 looks like:
> 
> =>  md.b f80c 1
> f80c: 10.
> 
> what is yours?

=> md.b f80c 1
f80c: 10.

:-/

U-Boot 1.3.0-rc3-g281df457-dirty (Nov  6 2007 - 18:19:35) MPC83XX
CPU:   e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB:  264 MHz

[EMAIL PROTECTED]:~# cat /proc/cpuinfo 
processor   : 0
cpu : e300c1
clock   : 528.00MHz
revision: 3.1 (pvr 8083 0031)
bogomips: 131.58
timebase: 6600
platform: MPC836x MDS


+   /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+   svid = mfspr(SPRN_SVR);
+   if (svid == 0x80480021) {

^^ that branch executes on the board I'm testing.

> If it's something like 0x03, the u-boot patch will probably look like:
> 
> if ((bcsr[12] == 0x10) &&
> (immr->sysconf.spridr == SPR_8360_REV21 ||
>  immr->sysconf.spridr == SPR_8360E_REV21))
>   /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> ...
> 
> but these linux patches would remain the same (the clk and data delay
> settings for the UCC's are still valid; it's just the PHY config
> that is triggering your problem from what I can tell).

Yup, most likely this is not UCC specific, but PHY. For some reason
delays making harm here...


Thanks,

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

Re: Why does a connect to IPv6 LLA address fail ?

[Karsten Keil]

On Thu, Nov 08, 2007 at 01:15:52PM -0500, Vlad Yasevich wrote:
> Andreas Gruenbacher wrote:
> > On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
> >> The reason is that 2 different hosts may have the same link-local
> >> address as long as they are on different links.  If the sender is
> >> connected to both links then it may send the packet to the wrong
> >> destination.
> > 
> > Good point.
> > 
> > What's confusing is that connect(2) fails even if the host itself has the 
> > specified address. This isn't necessary.
> 
> Yes and no.  Since linux doesn't have the concept of default zone, we have
> to fail, because from the perspective of the kernel, the address was not
> fully specified.  OTOH, since this is our address, we 'could' have all
> the info.
> 

> The problem is that this verification happens before we hit the routing logic.
> It's an explicit check the if the sin6_scope_id is not set and we are not 
> bound
> to an interface, it's an error.
> 

OK I run into this issue while running the TAHI testsuite. The test is as
follows:

  Check 03:
DNS Address: fec0::9
Candidate Source Addresses: fec0::1(SS) or LLA(LS)
Destination Address List: 3fff::2(GS) or fe80::2(LS)
Result: fe80::2 (src LLA) then 3fff::2 (src fec0::1)

Scope(fe80::2) = Scope(LLA) and Scope(3fff::2) <> Scope(fec0::1), then 
prefer fe80::2

the nameserver send following answer for the query:

| | | | DNS_Question(length:21)
| | | | | DNS_QuestionEntry   (length:21)
| | | | | | Name = server.tahi.org.
| | | | | | Type = 28 ()
| | | | | | Class= 1
| | | | DNS_Answer  (length:86)
| | | | | DNS_RR_ (length:43)
| | | | | | Name = server.tahi.org.
| | | | | | Type = 28
| | | | | | Class= 1
| | | | | | TTL  = 0
| | | | | | Length   = 16
| | | | | | Address  = 3fff::2
| | | | | DNS_RR_ (length:43)
| | | | | | Name = server.tahi.org.
| | | | | | Type = 28
| | | | | | Class= 1
| | | | | | TTL  = 0
| | | | | | Length   = 16
| | | | | | Address  = fe80::2



So how we should handle this issue, claim that the test is wrong, the test
should not use LLA for this ?

-- 
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 
16746 (AG Nuernberg)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Fix e100 on systems that have cache incoherent DMA

[Auke Kok]

From: David Acker <[EMAIL PROTECTED]>

On the systems that have cache incoherent DMA, including ARM, there
is a race condition between software allocating a new receive buffer
and hardware writing into a buffer.  The two race on touching the last
Receive Frame Descriptor (RFD).  It has its el-bit set and its next
link equal to 0.  When hardware encounters this buffer it attempts to
write data to it and then update Status Word bits and Actual Count in
the RFD.  At the same time software may try to clear the el-bit and
set the link address to a new buffer.

Since the entire RFD is once cache-line, the two write operations can
collide.  This can lead to the receive unit stalling or interpreting
random memory as its receive area.

The fix is to set the el-bit on and the size to 0 on the next to last
buffer in the chain.  When the hardware encounters this buffer it stops
and does not write to it at all.  The hardware issues an RNR interrupt
with the receive unit in the No Resources state.  Software can write
to the tail of the list because it knows hardware will stop on the
previous descriptor that was marked as the end of list.

Once it has a new next to last buffer prepared, it can clear the el-bit
and set the size on the previous one.  The race on this buffer is safe
since the link already points to a valid next buffer and the software
can handle the race setting the size (assuming aligned 16 bit writes
are atomic with respect to the DMA read). If the hardware sees the
el-bit cleared without the size set, it will move on to the next buffer
and skip this one.  If it sees the size set but the el-bit still set,
it will complete that buffer and then RNR interrupt and wait.

Signed-off-by: David Acker <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---

 drivers/net/e100.c |  128 
 1 files changed, 99 insertions(+), 29 deletions(-)

diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 3dbaec6..2153058 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -106,6 +106,13 @@
  * the RFD, the RFD must be dma_sync'ed to maintain a consistent
  * view from software and hardware.
  *
+ * In order to keep updates to the RFD link field from colliding with
+ * hardware writes to mark packets complete, we use the feature that
+ * hardware will not write to a size 0 descriptor and mark the previous
+ * packet as end-of-list (EL).   After updating the link, we remove EL
+ * and only then restore the size such that hardware may use the
+ * previous-to-end RFD.
+ *
  * Under typical operation, the  receive unit (RU) is start once,
  * and the controller happily fills RFDs as frames arrive.  If
  * replacement RFDs cannot be allocated, or the RU goes non-active,
@@ -281,6 +288,7 @@ struct csr {
 };
 
 enum scb_status {
+   rus_no_res   = 0x08,
rus_ready= 0x10,
rus_mask = 0x3C,
 };
@@ -952,7 +960,7 @@ static void e100_get_defaults(struct nic *nic)
((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));
 
/* Template for a freshly allocated RFD */
-   nic->blank_rfd.command = cpu_to_le16(cb_el);
+   nic->blank_rfd.command = 0;
nic->blank_rfd.rbd = 0x;
nic->blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
 
@@ -1791,15 +1799,12 @@ static int e100_rx_alloc_skb(struct nic *nic, struct rx 
*rx)
}
 
/* Link the RFD to end of RFA by linking previous RFD to
-* this one, and clearing EL bit of previous.  */
+* this one.  We are safe to touch the previous RFD because
+* it is protected by the before last buffer's el bit being set */
if(rx->prev->skb) {
struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data;
put_unaligned(cpu_to_le32(rx->dma_addr),
(u32 *)&prev_rfd->link);
-   wmb();
-   prev_rfd->command &= ~cpu_to_le16(cb_el);
-   pci_dma_sync_single_for_device(nic->pdev, rx->prev->dma_addr,
-   sizeof(struct rfd), PCI_DMA_TODEVICE);
}
 
return 0;
@@ -1824,8 +1829,19 @@ static int e100_rx_indicate(struct nic *nic, struct rx 
*rx,
DPRINTK(RX_STATUS, DEBUG, "status=0x%04X\n", rfd_status);
 
/* If data isn't ready, nothing to indicate */
-   if(unlikely(!(rfd_status & cb_complete)))
+   if (unlikely(!(rfd_status & cb_complete))) {
+   /* If the next buffer has the el bit, but we think the receiver
+* is still running, check to see if it really stopped while
+* we had interrupts off.
+* This allows for a fast restart without re-enabling
+* interrupts */
+   if ((le16_to_cpu(rfd->command) & cb_el) &&
+   (RU_RUNNING == nic->ru_running))
+
+   if (readb(&nic->csr->scb.status) & rus_no_res)
+ 

Re: Why does a connect to IPv6 LLA address fail ?

[Vlad Yasevich]

Andreas Gruenbacher wrote:
> On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
>> The reason is that 2 different hosts may have the same link-local
>> address as long as they are on different links.  If the sender is
>> connected to both links then it may send the packet to the wrong
>> destination.
> 
> Good point.
> 
> What's confusing is that connect(2) fails even if the host itself has the 
> specified address. This isn't necessary.

Yes and no.  Since linux doesn't have the concept of default zone, we have
to fail, because from the perspective of the kernel, the address was not
fully specified.  OTOH, since this is our address, we 'could' have all
the info.

The problem is that this verification happens before we hit the routing logic.
It's an explicit check the if the sin6_scope_id is not set and we are not bound
to an interface, it's an error.

> 
> What's even more confusing is that the kernel doesn't seem to honor the 
> interface in all cases: with
>fe80::20f:20ff:fe3b:e9c3 on eth0 and
>::1 on lo,
> I get the following:
> 
>   ping6 fe80::20f:20ff:fe3b:e9c3  fails with EINVAL
>   ping6 fe80::20f:20ff:fe3b:e9c3%eth0 succeeds

Yes, but if you run a capture, you'll see the packet on loopback.  That's
because you have a route to this address.

>   ping6 fe80::20f:20ff:fe3b:e9c3%lo   succeeds

Yes, same thing.  Routing code takes care of it.

> 
> At least the last ping should fail, shouldn't it?

No, because both pings really go over loopback.  You are on the same system
and have 'local' routes for those addresses:
  ip -6 r l t local

> 
>> A different and some might say 'better' alternative is to define a
>> default link.  Thus when the zone id is not specified the default is used.
>> This will work fine for link-scoped addresses.  A default zone would also
>> need to be defined for other scopes as well.  That's just one idea.
> 
> I think at least for host with only one link (in addition to loopback), 
> selecting that link for non-local addresses would make sense.
> 

Yes, you could do that.  Or you can push the interface check to the routing code
and do some logic to see if you can "select" an interface.

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

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Kim Phillips]

On Thu, 8 Nov 2007 17:16:11 +0300
Anton Vorontsov <[EMAIL PROTECTED]> wrote:

> On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > Hello all,
> > 
> > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > according to erratum #2 (erratum text included below).  Basically the
> > most intrusive part is the addition of two new RGMII Internal Delay
> > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > both at the same time).
> > 
> > Please review, and since this affects both netdev and powerpc trees,
> > one maintainer should ack them for the other to push upstream (i.e,
> > Kumar acks them, and Leo picks them up to go through netdev or the
> > other way around; either way is fine with me).  I'm hoping they're
> > trivial enough to go in 2.6.24.
> > 
> > Depending on how the review goes, a follow-on patch to u-boot will be
> > sent out that fixes up the phy-connection-type in the device tree (from
> > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
> 
> I've upgraded CPU to rev2.1, board rev0.3.
> 
thanks for testing this.  I tested these patches on a "pilot assy 0.3".

> Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> the results:
> 
> If I use -rxid, then geth not able to transmit anything.
> With -txid geth not able to receive anything.
> 
> With just -id everything works fine though...
> 
> 
> Maybe there should be another condition, in addition to cpu rev2.1?
> 
the errata simply states 'pilot boards', but we can probably modify
u-boot to look at the cpu rev and the board rev (BCSR 12).

My bcsr12 looks like:

=>  md.b f80c 1
f80c: 10.

what is yours?

If it's something like 0x03, the u-boot patch will probably look like:

if ((bcsr[12] == 0x10) &&
(immr->sysconf.spridr == SPR_8360_REV21 ||
 immr->sysconf.spridr == SPR_8360E_REV21))
/* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
...

but these linux patches would remain the same (the clk and data delay
settings for the UCC's are still valid; it's just the PHY config
that is triggering your problem from what I can tell).

Thanks,

Kim

> > mpc8360 rev 2.1 erratum #2:
> > ---
> > Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII  when working
> > with Rev Pilot MDS for proper RGMII operation:
> > 
> > IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2)
> > IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1)
> > IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's)
> > 
> > The Phy (Marvell 88e) should be configured NOT to work with RGMII
> > delay for TxD.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Why does a connect to IPv6 LLA address fail ?

[Andreas Gruenbacher]

On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
> The reason is that 2 different hosts may have the same link-local
> address as long as they are on different links.  If the sender is
> connected to both links then it may send the packet to the wrong
> destination.

Good point.

What's confusing is that connect(2) fails even if the host itself has the 
specified address. This isn't necessary.

What's even more confusing is that the kernel doesn't seem to honor the 
interface in all cases: with
   fe80::20f:20ff:fe3b:e9c3 on eth0 and
   ::1 on lo,
I get the following:

  ping6 fe80::20f:20ff:fe3b:e9c3fails with EINVAL
  ping6 fe80::20f:20ff:fe3b:e9c3%eth0   succeeds
  ping6 fe80::20f:20ff:fe3b:e9c3%lo succeeds

At least the last ping should fail, shouldn't it?

> A different and some might say 'better' alternative is to define a
> default link.  Thus when the zone id is not specified the default is used.
> This will work fine for link-scoped addresses.  A default zone would also
> need to be defined for other scopes as well.  That's just one idea.

I think at least for host with only one link (in addition to loopback), 
selecting that link for non-local addresses would make sense.

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

Re: Please pull 'fixes-jgarzik' branch of wireless-2.6 (3rd time is the charm?)

[Jeff Garzik]

On Thu, Nov 08, 2007 at 09:26:26AM -0500, John W. Linville wrote:
> Jeff,
> 
> OK, I think things are settled now.  I apologize for the confusion.
> 
> These are fixes intended for 2.6.24.  Please note that three of the
> patches from Michael Buesch in the list below were already sent to
> you directed for 2.6.25.  Upon further review, I think they belong in
> 2.6.24 instead.  I cherry-picked them, so I'm fairly certain git will
> be smart enough to drop them from your 2.6.25 branch when you rebase.
> 
> Please let me know if there are any problems.
> 
> Thanks!
> 
> John
> 
> ---
> 
> Individual patches are available here:
> 
>   
> http://www.kernel.org/pub//linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
> 

pulled into #upstream-fixes; please check the merge in #upstream


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

Re: ax88796: add superh to kconfig dependencies

[Jeff Garzik]

On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> ax88796: add superh to kconfig dependencies
> 
> This patch adds sh architecture support to the ax88796 kconfig.
> 
> Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>
> ---
> 
>  This patch was posted about a month ago but never picked up:
>  http://www.mail-archive.com/netdev@vger.kernel.org/msg50018.html
>  The rest of the sh support is already included in rc1. Please apply.
> 
>  drivers/net/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied


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

Re: [PATCH 1/2] qla3xxx: bugfix: Move link state machine into a worker thread

[Jeff Garzik]

On Wed, Nov 07, 2007 at 01:59:06PM -0800, Ron Mercer wrote:
> The link state machine requires access to some resources that
> are shared with the iSCSI function on the chip.  (See iSCSI
> driver at drivers/scsi/qla4xxx)  If the interface is being
> up/downed at a rapid pace this driver may need to sleep
> waiting to get access to the common resources. For this we
> are moving the state machine to run as a work thread.
> 
> Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>
> ---
>  drivers/net/qla3xxx.c |   27 +--
>  drivers/net/qla3xxx.h |1 +
>  2 files changed, 14 insertions(+), 14 deletions(-)

applied 1-2

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

Re: [PATCH 1/2] bonding: fix rtnl locking merge error

[Jeff Garzik]

On Tue, Nov 06, 2007 at 01:33:28PM -0800, Jay Vosburgh wrote:
>   Looks like I incorrectly merged one of the rtnl lock changes,
> so that one function, bonding_show_active_slave, held rtnl but didn't
> release it, and another, bonding_store_active_slave, never held rtnl but
> did release it.
> 
>   Fixed so the first function doesn't mess with rtnl, and the
> second correctly acquires and releases rtnl.
> 
>   Bug reported by Moni Shoua <[EMAIL PROTECTED]>
> 
> 
> Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>

applied 1-2

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

Re: [PATCH 1/2] pasemi_mac: Don't set replace-source-address descriptor bits

[Jeff Garzik]

On Tue, Nov 06, 2007 at 10:20:39PM -0600, Olof Johansson wrote:
> Don't use the "replace source address with local MAC address" bits, since
> it causes problems on some variations of the hardware due to an erratum.
> 
> 
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>

applied 1-2


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

Re: [PATCH] sky2: netpoll on port 0 only

[Jeff Garzik]

On Tue, Nov 06, 2007 at 11:45:40AM -0800, Stephen Hemminger wrote:
> Netpoll will only work on port 0 because of the restrictive
> relationship between NAPI and netpoll.
> 
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>

applied


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

Re: 2.6.24-rc1-gb4f5550 oops

[Grant Wilson]

On Thu, 8 Nov 2007 16:53:10 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> On Thursday, 8 of November 2007, Grant Wilson wrote:
> > On Thu, 8 Nov 2007 01:06:21 +0100
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > 
> > > On Monday, 5 of November 2007, Grant Wilson wrote:
> > > > Hi,
> > > > I got this oops on 2.6.24-rc1-641-gb4f5550:
> > > 
> > > (1) Is this reproducible?
> > > (2) Did it happen previously on your system?
> > >
> > > [18073.371126] Unable to handle kernel NULL pointer dereference at 
> > > 0120 RIP: 
> > > [18073.371134]  [] check_preempt_wakeup+0x6e/0x110
> > 
> > This has now happened twice - the second time was last night when
> > running 2.6.24-rc2.
> > 
> > Here's that second occurrence:
> > 
[snip]
> 
> Hmm.
> 
> Please run "gdb vmlinux" and see what code corresponds to
> check_preempt_wakeup+0x6e in your kernel.

Dump of assembler code for function check_preempt_wakeup:
0x80232940 :push   %rbp
0x80232941 :mov%rsp,%rbp
0x80232944 :sub$0x30,%rsp
0x80232948 :mov%r13,-0x18(%rbp)
0x8023294c :   mov%rbx,-0x28(%rbp)
0x80232950 :   mov%rsi,%r13
0x80232953 :   mov%r12,-0x20(%rbp)
0x80232957 :   mov%r14,-0x10(%rbp)
0x8023295b :   mov%r15,-0x8(%rbp)
0x8023295f :   cmpl   $0x63,0x20(%rsi)
0x80232963 :   mov0x750(%rdi),%r14
0x8023296a :   mov0x168(%r14),%r12
0x80232971 :   jle0x80232a1c 

0x80232977 :   cmpl   $0x3,0x17c(%rsi)
0x8023297e :   je 0x802329f8 

0x80232980 :   testb  $0x10,0x593cb9(%rip) 
   # 0x807c6640 
0x80232987 :   je 0x802329f8 

0x80232989 :   cmp0x168(%rsi),%r12
0x80232990 :   lea0x48(%r14),%rbx
0x80232994 :   lea0x48(%rsi),%rax
0x80232998 :   je 0x802329be 

0x8023299a :   nopw   0x0(%rax,%rax,1)
0x802329a0 :   mov0x118(%rbx),%rbx
0x802329a7 :  mov0x118(%rax),%rax
0x802329ae :  mov0x120(%rax),%rdx
0x802329b5 :  cmp%rdx,0x120(%rbx)
0x802329bc :  jne0x802329a0 

0x802329be :  cmpq   $0x400,(%rbx)
0x802329c5 :  mov0x40(%rbx),%r12
0x802329c9 :  mov0x40(%rax),%r15
0x802329cd :  mov0x593c81(%rip),%edi  
  # 0x807c6654 
0x802329d3 :  jne0x80232a37 

0x802329d5 :  sub%r15,%r12
0x802329d8 :  cmp%r12,%rdi
0x802329db :  jge0x802329f8 

0x802329dd :  testb  $0x20,0x593c5c(%rip) 
   # 0x807c6640 

Cheers,
Grant
-- 
Running Linux 2.6.24-rc2 on x86_64
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[VLAN]: Allow setting mac address while device is up

[Patrick McHardy]

This patch allows to change a VLAN device's MAC address while
the device is up. Doesn't seem worth to hold back until
2.6.25-rc since it can't break anything without actually
getting used (and it does work :))

[VLAN]: Allow setting mac address while device is up

Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>

---
commit 5efb3597bba3b223fcf3690a88394064dded87ba
tree a15ae1c12bcdc1277c5a5096f420437c1ded7414
parent f6d0e3b654d36bd87016b0626464990f3fc57ca7
author Patrick McHardy <[EMAIL PROTECTED]> Thu, 08 Nov 2007 18:12:20 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Thu, 08 Nov 2007 18:12:20 +0100

 net/8021q/vlan.c |1 +
 net/8021q/vlan.h |1 +
 net/8021q/vlan_dev.c |   26 ++
 3 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index d80afec..dd4086b 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -376,6 +376,7 @@ void vlan_setup(struct net_device *new_dev)
 	new_dev->init = vlan_dev_init;
 	new_dev->open = vlan_dev_open;
 	new_dev->stop = vlan_dev_stop;
+	new_dev->set_mac_address = vlan_set_mac_address;
 	new_dev->set_multicast_list = vlan_dev_set_multicast_list;
 	new_dev->change_rx_flags = vlan_change_rx_flags;
 	new_dev->destructor = free_netdev;
diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
index cf4a80d..2cd1393 100644
--- a/net/8021q/vlan.h
+++ b/net/8021q/vlan.h
@@ -60,6 +60,7 @@ int vlan_dev_hwaccel_hard_start_xmit(struct sk_buff *skb, struct net_device *dev
 int vlan_dev_change_mtu(struct net_device *dev, int new_mtu);
 int vlan_dev_open(struct net_device* dev);
 int vlan_dev_stop(struct net_device* dev);
+int vlan_set_mac_address(struct net_device *dev, void *p);
 int vlan_dev_ioctl(struct net_device* dev, struct ifreq *ifr, int cmd);
 void vlan_dev_set_ingress_priority(const struct net_device *dev,
    u32 skb_prio, short vlan_prio);
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 1a1740a..7a36878 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -665,6 +665,32 @@ int vlan_dev_stop(struct net_device *dev)
 	return 0;
 }
 
+int vlan_set_mac_address(struct net_device *dev, void *p)
+{
+	struct net_device *real_dev = VLAN_DEV_INFO(dev)->real_dev;
+	struct sockaddr *addr = p;
+	int err;
+
+	if (!is_valid_ether_addr(addr->sa_data))
+		return -EADDRNOTAVAIL;
+
+	if (!(dev->flags & IFF_UP))
+		goto out;
+
+	if (compare_ether_addr(addr->sa_data, real_dev->dev_addr)) {
+		err = dev_unicast_add(real_dev, addr->sa_data, ETH_ALEN);
+		if (err < 0)
+			return err;
+	}
+
+	if (compare_ether_addr(dev->dev_addr, real_dev->dev_addr))
+		dev_unicast_delete(real_dev, dev->dev_addr, ETH_ALEN);
+
+out:
+	memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN);
+	return 0;
+}
+
 int vlan_dev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
 {
 	struct net_device *real_dev = VLAN_DEV_INFO(dev)->real_dev;

[VLAN]: Don't synchronize addresses while the vlan device is down

[Patrick McHardy]

 [VLAN]: Don't synchronize addresses while the vlan device is down

While the VLAN device is down, the unicast addresses are not configured
on the underlying device, so we shouldn't attempt to sync them.

Noticed by Dmitry Butskoy <[EMAIL PROTECTED]>

Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>

---
commit f6d0e3b654d36bd87016b0626464990f3fc57ca7
tree 16ce232acdd1919e7ca42dc12b24f09f8d92f966
parent dbeeb816e805091e7cfc03baf36dc40b4adb2bbd
author Patrick McHardy <[EMAIL PROTECTED]> Thu, 08 Nov 2007 17:34:43 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Thu, 08 Nov 2007 17:34:43 +0100

 net/8021q/vlan.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 3fe4fc8..d80afec 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -636,6 +636,10 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
 			if (!vlandev)
 continue;
 
+			flgs = vlandev->flags;
+			if (!(flgs & IFF_UP))
+continue;
+
 			vlan_sync_address(dev, vlandev);
 		}
 		break;

[PATCH] NET: Fix skb_truesize_check() assertion

[Chuck Lever]

The intent of the assertion in skb_truesize_check() is to check
for skb->truesize being decremented too much by other code,
resulting in a wraparound below zero.

The type of the right side of the comparison causes the compiler to
promote the left side to an unsigned type, despite the presence of an
explicit type cast.  This defeats the check for negativity.

Ensure both sides of the comparison are a signed type to prevent the
implicit type conversion.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
---

 include/linux/skbuff.h |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 94e4991..91140fe 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -387,7 +387,9 @@ extern void   skb_truesize_bug(struct sk_buff *skb);
 
 static inline void skb_truesize_check(struct sk_buff *skb)
 {
-   if (unlikely((int)skb->truesize < sizeof(struct sk_buff) + skb->len))
+   int len = sizeof(struct sk_buff) + skb->len;
+
+   if (unlikely((int)skb->truesize < len))
skb_truesize_bug(skb);
 }
 

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

Re: [PATCH] [NETFILTER] Consolidate nf_sockopt and compat_nf_sockopt v2

[Patrick McHardy]

Pavel Emelyanov wrote:

Both lookup the nf_sockopt_ops object to call the get/set callbacks
from, but they perform it in a completely similar way.

Introduce the helper for finding the ops.

Ported at the top of today's net-2.6 tree to resolve conflict
with the patch from Alexey Dobriyan.



Applied, thanks Pavel.

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

[PATCH] sky2: new pci id's

[Stephen Hemminger]

Found a couple of more chips in the latest version of the vendor driver.
They are minor variations on existing chips, so please incorporate into
2.6.24.

Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
 

--- a/drivers/net/sky2.c2007-11-07 22:45:02.0 -0800
+++ b/drivers/net/sky2.c2007-11-07 22:46:29.0 -0800
@@ -121,6 +121,7 @@ static const struct pci_device_id sky2_i
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4353) }, /* 88E8039 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4354) }, /* 88E8040 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4356) }, /* 88EC033 */
+   { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4357) }, /* 88E8042 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x435A) }, /* 88E8048 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4360) }, /* 88E8052 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4361) }, /* 88E8050 */
@@ -134,6 +135,7 @@ static const struct pci_device_id sky2_i
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4369) }, /* 88EC042 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436A) }, /* 88E8058 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
+   { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436C) }, /* 88E8072 */
{ 0 }
 };
 
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':

[Randy Dunlap]

On Thu, 8 Nov 2007 04:30:10 +0100 Adrian Bunk wrote:

> On Wed, Nov 07, 2007 at 11:52:32PM +0100, Adrian Bunk wrote:
> > On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote:
> > > > > But on the other hand, it seems that only the ASIX code will work
> > > > > right; the DM9601 and MCS7830 Kconfig is different/wrong.
> > > > 
> > > > I'm not seeing the problem.
> > > > 
> > > > Which configuration will be handled wrongly?
> > > 
> > > Notice how only the ASIX kconfig depended on NET_ETHERNET...
> > > since MII depends on NET_ETHERNET, and (last I knew) the
> > > reverse dependencies didn't capture the complete dependency
> > > tree, selecting only MII would leave out some stuff.
> > 
> > Except for one s390 net driver (I'll check why it's doing this) the 
> > NET_ETHERNET option does not influence what code is being generated - 
> > it's just a Kconfig-internal option allowing to disable a huge bunch
> > of drivers at once.
> 
> Damn, I shouldn't have only grep'ed under drivers/.
> 
> @davem:
> 
> Please look at net/ipv4/arp.c:arp_process()
> 
> Am I right that CONFIG_NET_ETHERNET=n and CONFIG_NETDEV_1000=y or 
> CONFIG_NETDEV_1=y will not be handled correctly there?

I'd say yes, you are correct.

> And the best solution is to nuke all #ifdef's in this function and make 
> the code unconditionally available?



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

Re: Fwd: Re: [PATCH] iSCSI fix endieness of digest to be network byte order

[Vlad Yasevich]

Herbert Xu wrote:
> On Thu, Nov 08, 2007 at 05:04:09PM +0900, FUJITA Tomonori wrote:
>> I wonder why crc32c isn't used directly while crc32 is used directly
>> since they vary by only the polynomial.
> 
> It's because iSCSI uses it with scatterlists.  The crypto layer
> provides a nice interface for that while using it directly would
> require the user to do the scatterlist walk.
> 
>> Using crc32c directly might enable us to kill net/sctp/crc32c.c and
>> merge lib/crc32.c and lib/libcrc32c?
> 
> I'm pretty sure we can kill net/sctp/crc32c.c today by converting
> it over to use the crypto interface.


Funny, I looked for crc32c in the lib just the other week and didn't spot
it.  Need to look harder :)

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

Re: [PATCH] ipconfig.c : implement DHCP Class-identifier

[Patrick McHardy]

Rainer Jochem wrote:

--- net/ipv4/ipconfig.c.orig2007-11-08 14:54:11.001662860 +0100
+++ net/ipv4/ipconfig.c 2007-11-08 14:54:15.961480524 +0100
@@ -139,6 +139,8 @@ __be32 ic_servaddr = NONE;  /* Boot serve
 __be32 root_server_addr = NONE;/* Address of NFS server */
 u8 root_server_path[256] = { 0, }; /* Path to mount as root */
 
+char vendor_class_identifier[256] = { 0, }; /* vendor class identifier */


static please, no need to initialize.


+
 /* Persistent data: */
 
 static int ic_proto_used;			/* Protocol used, if any */

@@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
*e++ = sizeof(ic_req_params);
memcpy(e, ic_req_params, sizeof(ic_req_params));
e += sizeof(ic_req_params);
+
+   // Send it only if the according kernel parameter was set
+   if (*vendor_class_identifier) {
+   printk(KERN_INFO "Sending class identifier \"%s\"\n",
+  vendor_class_identifier);


Seems like useless noise.


+   *e++ = 60;  /* Class-identifier */
+   *e++ = strlen(vendor_class_identifier);
+   memcpy(e, vendor_class_identifier,
+  strlen(vendor_class_identifier));
+   e += strlen(vendor_class_identifier);


You could avoid these three strlen calls by using a temporary
variable to hold the length.


+   }
}
 
 	*e++ = 255;	/* End of the list */

@@ -1507,5 +1520,14 @@ static int __init nfsaddrs_config_setup(
return ip_auto_config_setup(addrs);
 }
 
+static int __init vendor_class_identifier_setup(char *addrs)

+{
+   if (strlcpy(vendor_class_identifier, addrs, 250) > 250)


sizeof(vendor_class_identifier). Why are you using 250 but the
array is 256 bytes large?


+   printk(KERN_WARNING "vendorclass too long, truncated to \"%s\"",
+  vendor_class_identifier);
+   return 1;
+}
+
 __setup("ip=", ip_auto_config_setup);
 __setup("nfsaddrs=", nfsaddrs_config_setup);
+__setup("dhcpclass=", vendor_class_identifier_setup);



--- ../linux-2.6.23.1/Documentation/kernel-parameters.txt   2007-10-12 
18:43:44.0 +0200
+++ Documentation/kernel-parameters.txt 2007-10-24 17:02:22.441454955 +0200
@@ -533,6 +533,10 @@ and is between 256 and 4096 characters. 
 	dhash_entries=	[KNL]

Set number of hash buckets for dentry cache.
 
+	dhcpclass=	[KNL]


[IP_PNP]


+   Set DHCP Vendor Class Identifier to be sent
+   by the client.
+
digi=   [HW,SERIAL]
IO parameters + enable/disable command.




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

Re: [Bug 9080] Weird network problems with 2.6.23-rc2

[Rafał J. Wysocki]

On Thursday, 8 of November 2007, [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9080
> 
> 
> [EMAIL PROTECTED] changed:
> 
>What|Removed |Added
> 
>  CC||[EMAIL PROTECTED]
> 
> 
> 
> 
> --- Comment #1 from [EMAIL PROTECTED]  2007-11-07 17:56 ---
> Rafael, we should probably email this to netdev.

OK, let's try. :-)


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

Re: 2.6.24-rc1-gb4f5550 oops

[Rafael J. Wysocki]

On Thursday, 8 of November 2007, Grant Wilson wrote:
> On Thu, 8 Nov 2007 01:06:21 +0100
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> 
> > On Monday, 5 of November 2007, Grant Wilson wrote:
> > > Hi,
> > > I got this oops on 2.6.24-rc1-641-gb4f5550:
> > 
> > (1) Is this reproducible?
> > (2) Did it happen previously on your system?
> >
> > [18073.371126] Unable to handle kernel NULL pointer dereference at 
> > 0120 RIP: 
> > [18073.371134]  [] check_preempt_wakeup+0x6e/0x110
> 
> This has now happened twice - the second time was last night when
> running 2.6.24-rc2.
> 
> Here's that second occurrence:
> 
> [ 7224.233621] Unable to handle kernel NULL pointer dereference at 
> 0120 RIP:
> [ 7224.233631]  [] check_preempt_wakeup+0x6e/0x110
> [ 7224.233644] PGD 0
> [ 7224.233650] Oops:  [1] PREEMPT SMP
> [ 7224.233660] CPU 0
> [ 7224.233716] Modules linked in:
> [ 7224.233722] Pid: 7622, comm: ssh Not tainted 2.6.24-rc2 #1
> [ 7224.233726] RIP: 0010:[]  [] 
> check_preempt_wakeup+0x6e/0x110
> [ 7224.233735] RSP: 0018:81000aafba78  EFLAGS: 00010006
> [ 7224.233738] RAX:  RBX:  RCX: 
> 5745
> [ 7224.233743] RDX: 81000442fbf0 RSI: 810006c96860 RDI: 
> 810004438b80
> [ 7224.233748] RBP: 81000aafbaa8 R08: 007e8e25cf71 R09: 
> 
> [ 7224.233752] R10: 81000442fbf0 R11: 0001 R12: 
> 810007479d80
> [ 7224.233756] R13: 810006c96860 R14: 810009924860 R15: 
> 81000442b8e0
> [ 7224.233760] FS:  2b8bf089d350() GS:808d7000() 
> knlGS:
> [ 7224.233764] CS:  0010 DS:  ES:  CR0: 8005003b
> [ 7224.233768] CR2: 0120 CR3: 0ab3f000 CR4: 
> 06e0
> [ 7224.233771] DR0:  DR1:  DR2: 
> 
> [ 7224.233775] DR3:  DR6: 0ff0 DR7: 
> 0400
> [ 7224.233779] Process ssh (pid: 7622, threadinfo 81000aafa000, task 
> 81000abc2000)
> [ 7224.233782] Stack:  810004438b80 0001 810006c96860 
> 810004438b80
> [ 7224.233796]   81000442b8e0 81000aafbb38 
> 8023061e
> [ 7224.233807]  0400 81000442fb80  
> 0001
> [ 7224.233816] Call Trace:
> [ 7224.233823]  [] try_to_wake_up+0x2fe/0x3a0
> [ 7224.233828]  [] default_wake_function+0xd/0x10
> [ 7224.233833]  [] __wake_up_common+0x5a/0x90
> [ 7224.233839]  [] __wake_up_sync+0x4a/0x70
> [ 7224.233845]  [] unix_write_space+0x8f/0xa0
> [ 7224.233850]  [] sock_wfree+0x49/0x50
> [ 7224.233854]  [] __kfree_skb+0x69/0xe0
> [ 7224.233859]  [] kfree_skb+0x17/0x30
> [ 7224.233863]  [] unix_stream_recvmsg+0x267/0x610
> [ 7224.233869]  [] sock_aio_read+0x107/0x110
> [ 7224.233875]  [] do_sync_read+0xf1/0x130
> [ 7224.233882]  [] __d_free+0x30/0x40
> [ 7224.233887]  [] autoremove_wake_function+0x0/0x40
> [ 7224.233892]  [] vfs_read+0x156/0x160
> [ 7224.233897]  [] sys_read+0x50/0x90
> [ 7224.233901]  [] system_call+0x7e/0x83
> [ 7224.233904]
> [ 7224.233907]
> [ 7224.233907] Code: 48 8b 90 20 01 00 00 48 39 93 20 01 00 00 75 e2 48 81 3b 
> 00
> [ 7224.233951] RIP  [] check_preempt_wakeup+0x6e/0x110
> [ 7224.233957]  RSP 
> [ 7224.233961] CR2: 0120
> [ 7224.233967] note: ssh[7622] exited with preempt_count 3

Hmm.

Please run "gdb vmlinux" and see what code corresponds to
check_preempt_wakeup+0x6e in your kernel.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

No implementation of NETLINK_USERSOCK ?

[Matti Aarnio]

Some 6 months ago I asked about a way to make network protocol
servers(s) that live in userspace, but whose application interface
still uses kernel socket calls.

I recall getting an answer that there is  NETLINK_USERSOCK for that
use.  I have tried to have a look into what NETLINK_USERSOCK
supplies to its users, but alas there appears to be no implementation
at all in existence.   Is it some sort of placeholder of things
to implement some day ?

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

[PATCH] ipconfig.c : implement DHCP Class-identifier

[Rainer Jochem]

This patch implements the DHCP Class identifier (see rfc1533) which is
used by DHCP clients to optionally identify the type and configuration of 
a DHCP client which is send as a string to the server. For example, the
identifier may encode the client's hardware configuration. If the newly 
introduced kernel-parameter 'dhcpclass' is set, then the kernel sends 
the given string in its DHCP-request to the server.
If the option is omitted, the behaviour is as before without this patch.


Patch applies to:
Version:2.6.23.1
File:   net/ipv4/ipconfig.c


Signed-off-by: Rainer Jochem <[EMAIL PROTECTED]>

---

--- net/ipv4/ipconfig.c.orig2007-11-08 14:54:11.001662860 +0100
+++ net/ipv4/ipconfig.c 2007-11-08 14:54:15.961480524 +0100
@@ -139,6 +139,8 @@ __be32 ic_servaddr = NONE;  /* Boot serve
 __be32 root_server_addr = NONE;/* Address of NFS server */
 u8 root_server_path[256] = { 0, }; /* Path to mount as root */
 
+char vendor_class_identifier[256] = { 0, }; /* vendor class identifier */
+
 /* Persistent data: */
 
 static int ic_proto_used;  /* Protocol used, if any */
@@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
*e++ = sizeof(ic_req_params);
memcpy(e, ic_req_params, sizeof(ic_req_params));
e += sizeof(ic_req_params);
+
+   // Send it only if the according kernel parameter was set
+   if (*vendor_class_identifier) {
+   printk(KERN_INFO "Sending class identifier \"%s\"\n",
+  vendor_class_identifier);
+   *e++ = 60;  /* Class-identifier */
+   *e++ = strlen(vendor_class_identifier);
+   memcpy(e, vendor_class_identifier,
+  strlen(vendor_class_identifier));
+   e += strlen(vendor_class_identifier);
+   }
}
 
*e++ = 255; /* End of the list */
@@ -1507,5 +1520,14 @@ static int __init nfsaddrs_config_setup(
return ip_auto_config_setup(addrs);
 }
 
+static int __init vendor_class_identifier_setup(char *addrs)
+{
+   if (strlcpy(vendor_class_identifier, addrs, 250) > 250)
+   printk(KERN_WARNING "vendorclass too long, truncated to \"%s\"",
+  vendor_class_identifier);
+   return 1;
+}
+
 __setup("ip=", ip_auto_config_setup);
 __setup("nfsaddrs=", nfsaddrs_config_setup);
+__setup("dhcpclass=", vendor_class_identifier_setup);



--- ../linux-2.6.23.1/Documentation/kernel-parameters.txt   2007-10-12 
18:43:44.0 +0200
+++ Documentation/kernel-parameters.txt 2007-10-24 17:02:22.441454955 +0200
@@ -533,6 +533,10 @@ and is between 256 and 4096 characters. 
dhash_entries=  [KNL]
Set number of hash buckets for dentry cache.
 
+   dhcpclass=  [KNL]
+   Set DHCP Vendor Class Identifier to be sent
+   by the client.
+
digi=   [HW,SERIAL]
IO parameters + enable/disable command.


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

Please pull 'fixes-jgarzik' branch of wireless-2.6 (3rd time is the charm?)

[John W. Linville]

Jeff,

OK, I think things are settled now.  I apologize for the confusion.

These are fixes intended for 2.6.24.  Please note that three of the
patches from Michael Buesch in the list below were already sent to
you directed for 2.6.25.  Upon further review, I think they belong in
2.6.24 instead.  I cherry-picked them, so I'm fairly certain git will
be smart enough to drop them from your 2.6.25 branch when you rebase.

Please let me know if there are any problems.

Thanks!

John

---

Individual patches are available here:


http://www.kernel.org/pub//linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/

---

The following changes since commit 2655e2cee2d77459fcb7e10228259e4ee0328697:
  Alan Cox (1):
ata_piix: Add additional PCI identifier for 40 wire short cable

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git 
fixes-jgarzik

Holger Schurig (1):
  libertas: fixes for slow hardware

Ivo van Doorn (1):
  rt2x00: Block adhoc & master mode

John W. Linville (1):
  hermes: clarify Intel reference in Kconfig help

Marcelo Tosatti (1):
  libertas: properly account for queue commands

Michael Buesch (7):
  b43: pcmcia-host initialization bugfixes
  b43: Fix rfkill callback deadlock
  b43: debugfs SHM read buffer overrun fix
  b43: Rewrite and fix rfkill init
  b43: properly request pcmcia IRQ
  b43legacy: Fix sparse warning
  b43: Fix kconfig dependencies for rfkill and leds

Pierre Ossman (1):
  libertas: make if_sdio align packets

Randy Dunlap (1):
  hostap: fix section mismatch warning

Roel Kluin (1):
  ipw2100: fix postfix decrement errors

Stefano Brivio (4):
  b43legacy: fix possible buffer overrun in debugfs
  b43legacy: add me as maintainer and fix URLs
  b43: fix shared IRQ race condition
  b43legacy: fix shared IRQ race condition

 MAINTAINERS  |   10 ++-
 drivers/net/wireless/Kconfig |2 +-
 drivers/net/wireless/b43/Kconfig |   10 ++-
 drivers/net/wireless/b43/debugfs.c   |2 +-
 drivers/net/wireless/b43/main.c  |   19 +++---
 drivers/net/wireless/b43/pcmcia.c|   52 +-
 drivers/net/wireless/b43/rfkill.c|  115 +
 drivers/net/wireless/b43/rfkill.h|   14 +---
 drivers/net/wireless/b43legacy/debugfs.c |2 +-
 drivers/net/wireless/b43legacy/main.c|   21 +++---
 drivers/net/wireless/hostap/hostap_pci.c |6 +-
 drivers/net/wireless/ipw2100.c   |4 +-
 drivers/net/wireless/libertas/cmd.c  |   10 ++-
 drivers/net/wireless/libertas/if_cs.c|7 ++-
 drivers/net/wireless/libertas/if_sdio.c  |4 +-
 drivers/net/wireless/rt2x00/rt2x00mac.c  |8 ++
 16 files changed, 154 insertions(+), 132 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1c7c229..6a97027 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -787,23 +787,25 @@ B43 WIRELESS DRIVER
 P: Michael Buesch
 M: [EMAIL PROTECTED]
 P: Stefano Brivio
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
-W: http://bcm43xx.berlios.de/
+W: http://linuxwireless.org/en/users/Drivers/b43
 S: Maintained
 
 B43LEGACY WIRELESS DRIVER
 P: Larry Finger
 M: [EMAIL PROTECTED]
+P: Stefano Brivio
+M: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
-W: http://bcm43xx.berlios.de/
+W: http://linuxwireless.org/en/users/Drivers/b43
 S: Maintained
 
 BCM43XX WIRELESS DRIVER (SOFTMAC BASED VERSION)
 P: Larry Finger
 M: [EMAIL PROTECTED]
 P: Stefano Brivio
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
 W: http://bcm43xx.berlios.de/
 S: Maintained
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index dae5c8d..2b733c5 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -325,7 +325,7 @@ config HERMES
  Cabletron/EnteraSys Roamabout, ELSA AirLancer, MELCO Buffalo, Avaya,
  IBM High Rate Wireless, Farralon Syyline, Samsung MagicLAN, Netgear
  MA401, LinkSys WPC-11, D-Link DWL-650, 3Com AirConnect, Intel
- PRO/Wireless, and Symbol Spectrum24 High Rate amongst others.
+ IPW2011, and Symbol Spectrum24 High Rate amongst others.
 
  This option includes the guts of the driver, but in order to
  actually use a card you will also need to enable support for PCMCIA
diff --git a/drivers/net/wireless/b43/Kconfig b/drivers/net/wireless/b43/Kconfig
index e3c573e..fdbc351 100644
--- a/drivers/net/wireless/b43/Kconfig
+++ b/drivers/net/wireless/b43/Kconfig
@@ -61,16 +61,18 @@ config B43_PCMCIA
 
  If unsure, say N.
 
-# LED support
+# This config option automatically enables b43 LEDS support,
+# if it's possible.
 config B43_LEDS
bool
-   depends on B43 && MAC80211_LEDS
+   depends on B43 && MAC80211_LEDS && (LEDS_CLASS = y || LE

Re: [PATCH 04/05] ipv6: RFC4214 Support

[YOSHIFUJI Hideaki / 吉藤英明]

In article <[EMAIL PROTECTED]> (at Wed, 7 Nov 2007 11:12:47 -0800), "Templin, 
Fred L" <[EMAIL PROTECTED]> says:

> > > The goal was to avoid requiring changes to applications such as
> > > 'iproute2', i.e., the intention was for a standalone code 
> > insertion point
> > > within the kernel itself. What do you suggest?
> > 
> > Agreed, magic names are evil.
> > 
> > Change iproute2 utilities, if it is more logical for administration.
> 
> This being an experimental release, I would prefer to go
> forward with a standalone kernel solution for the first
> iteration then come back with the iproute2 changes at a
> later time. IMHO, we should only touch iproute2 once, and
> it should be an architected solution - not just a quick
> hack. For the short term, timeliness of interoperability testing
> with the other major OS's should be the highest priority, IMHO.

Hmm, what is missing from API POV?

Since even if you do not change iproute2 now, users may need
to change their configuration script twice anyway, we should
be careful.

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

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Anton Vorontsov]

On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> Hello all,
> 
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below).  Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
> 
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me).  I'm hoping they're
> trivial enough to go in 2.6.24.
> 
> Depending on how the review goes, a follow-on patch to u-boot will be
> sent out that fixes up the phy-connection-type in the device tree (from
> "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).

I've upgraded CPU to rev2.1, board rev0.3.

Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
the results:

If I use -rxid, then geth not able to transmit anything.
With -txid geth not able to receive anything.

With just -id everything works fine though...


Maybe there should be another condition, in addition to cpu rev2.1?

> Thanks,
> 
> Kim
> 
> mpc8360 rev 2.1 erratum #2:
> ---
> Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII  when working
> with Rev Pilot MDS for proper RGMII operation:
> 
> IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2)
> IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1)
> IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's)
> 
> The Phy (Marvell 88e) should be configured NOT to work with RGMII
> delay for TxD.

Thanks,

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

Re: Please pull 'fixes-jgarzik' branch of wireless-2.6 (this time for real!)

[John W. Linville]

Clearly having a bad week...just ignore this thread and I'll post a
totally new request shortly.

Thanks,

John

On Wed, Nov 07, 2007 at 08:34:29PM -0500, John W. Linville wrote:
> On Wed, Nov 07, 2007 at 02:24:19PM -0500, Jeff Garzik wrote:
> > On Wed, Nov 07, 2007 at 02:13:29PM -0500, John W. Linville wrote:
> > > Jeff,
> > > 
> > > If you haven't already pulled this then please hold-off.  I'll post
> > > a new request soon.
> > 
> > Haven't pulled yet...
> 
> Jeff,
> 
> These fixes are additive on top of the previous request in this thread.
> That request is archived here:
> 
>   http://marc.info/?l=linux-wireless&m=119438263704232&w=2
> 
> Also, note that the first three from Michael Buesch in the list below
> were already sent to you directed for 2.6.25, but I think they belong in
> 2.6.24 instead.  I cherry-picked them, so I'm fairly certain git will be
> smart enough to drop them from your 2.6.25 branch when you rebase.
> 
> Let me know if there are any problems!
> 
> Thanks,
> 
> John
> 
> ---
> 
> The entire series (i.e. both from yesterday and today) is available
> here:
> 
>   
> http://www.kernel.org/pub//linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
> 
> ---
> 
> The following changes since commit 33a463d0c82cad08a64526c217f6d835a51dfc1c:
>   Michael Buesch (1):
> b43: pcmcia-host initialization bugfixes
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git 
> fixes-jgarzik
> 
> Michael Buesch (6):
>   b43: Fix rfkill callback deadlock
>   b43: debugfs SHM read buffer overrun fix
>   b43: Rewrite and fix rfkill init
>   b43: properly request pcmcia IRQ
>   b43legacy: Fix sparse warning
>   b43: Fix kconfig dependencies for rfkill and leds
> 
> Stefano Brivio (4):
>   b43legacy: fix possible buffer overrun in debugfs
>   b43legacy: add me as maintainer and fix URLs
>   b43: fix shared IRQ race condition
>   b43legacy: fix shared IRQ race condition
> 
>  MAINTAINERS  |   10 ++-
>  drivers/net/wireless/b43/Kconfig |   10 ++-
>  drivers/net/wireless/b43/debugfs.c   |2 +-
>  drivers/net/wireless/b43/main.c  |   19 +++---
>  drivers/net/wireless/b43/pcmcia.c|8 ++
>  drivers/net/wireless/b43/rfkill.c|  115 +
>  drivers/net/wireless/b43/rfkill.h|   14 +---
>  drivers/net/wireless/b43legacy/debugfs.c |2 +-
>  drivers/net/wireless/b43legacy/main.c|   21 +++---
>  9 files changed, 100 insertions(+), 101 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1c7c229..6a97027 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -787,23 +787,25 @@ B43 WIRELESS DRIVER
>  P:   Michael Buesch
>  M:   [EMAIL PROTECTED]
>  P:   Stefano Brivio
> -M:   [EMAIL PROTECTED]
> +M:   [EMAIL PROTECTED]
>  L:   [EMAIL PROTECTED]
> -W:   http://bcm43xx.berlios.de/
> +W:   http://linuxwireless.org/en/users/Drivers/b43
>  S:   Maintained
>  
>  B43LEGACY WIRELESS DRIVER
>  P:   Larry Finger
>  M:   [EMAIL PROTECTED]
> +P:   Stefano Brivio
> +M:   [EMAIL PROTECTED]
>  L:   [EMAIL PROTECTED]
> -W:   http://bcm43xx.berlios.de/
> +W:   http://linuxwireless.org/en/users/Drivers/b43
>  S:   Maintained
>  
>  BCM43XX WIRELESS DRIVER (SOFTMAC BASED VERSION)
>  P:   Larry Finger
>  M:   [EMAIL PROTECTED]
>  P:   Stefano Brivio
> -M:   [EMAIL PROTECTED]
> +M:   [EMAIL PROTECTED]
>  L:   [EMAIL PROTECTED]
>  W:   http://bcm43xx.berlios.de/
>  S:   Maintained
> diff --git a/drivers/net/wireless/b43/Kconfig 
> b/drivers/net/wireless/b43/Kconfig
> index e3c573e..fdbc351 100644
> --- a/drivers/net/wireless/b43/Kconfig
> +++ b/drivers/net/wireless/b43/Kconfig
> @@ -61,16 +61,18 @@ config B43_PCMCIA
>  
> If unsure, say N.
>  
> -# LED support
> +# This config option automatically enables b43 LEDS support,
> +# if it's possible.
>  config B43_LEDS
>   bool
> - depends on B43 && MAC80211_LEDS
> + depends on B43 && MAC80211_LEDS && (LEDS_CLASS = y || LEDS_CLASS = B43)
>   default y
>  
> -# RFKILL support
> +# This config option automatically enables b43 RFKILL support,
> +# if it's possible.
>  config B43_RFKILL
>   bool
> - depends on B43 && RFKILL && RFKILL_INPUT && INPUT_POLLDEV
> + depends on B43 && (RFKILL = y || RFKILL = B43) && RFKILL_INPUT && 
> (INPUT_POLLDEV = y || INPUT_POLLDEV = B43)
>   default y
>  
>  config B43_DEBUG
> diff --git a/drivers/net/wireless/b43/debugfs.c 
> b/drivers/net/wireless/b43/debugfs.c
> index 734e70e..ef0075d 100644
> --- a/drivers/net/wireless/b43/debugfs.c
> +++ b/drivers/net/wireless/b43/debugfs.c
> @@ -128,7 +128,7 @@ static ssize_t shm_read_file(struct b43_wldev *dev,
>   __le16 *le16buf = (__le16 *)buf;
>  
>   for (i = 0; i < 0x1000; i++) {
> - if (bufsize <= 0)
> + if (bufsize < sizeof(tmp))
>   break;
>   tmp = b43_shm_read16(dev, B43_SHM

[PATCH] drivers/net: remove duplicated defines

[Nicolas Kaiser]

Remove duplicated defines.

Signed-off-by: Nicolas Kaiser <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/regs.h  |   37 --
 drivers/net/e1000e/defines.h  |   23 +-
 drivers/net/ehea/ehea_phyp.c  |7 -
 drivers/net/hp100.c   |6 
 drivers/net/niu.h |1 
 drivers/net/tokenring/smctr.h |6 
 drivers/net/tulip/de4x5.c |6 
 drivers/net/usb/rtl8150.c |   26 -
 drivers/net/wan/dscc4.c   |1 
 drivers/net/wireless/atmel.c  |1 
 drivers/net/wireless/iwlwifi/iwl-eeprom.h |3 --
 drivers/net/wireless/libertas/host.h  |1 
 12 files changed, 3 insertions(+), 115 deletions(-)

diff -ur a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
--- a/drivers/net/cxgb3/regs.h  2007-11-07 11:26:12.0 +0100
+++ b/drivers/net/cxgb3/regs.h  2007-11-07 21:55:15.0 +0100
@@ -555,10 +555,6 @@
 #define V_BUSY(x) ((x) << S_BUSY)
 #define F_BUSYV_BUSY(1U)
 
-#define S_BUSY31
-#define V_BUSY(x) ((x) << S_BUSY)
-#define F_BUSYV_BUSY(1U)
-
 #define A_MC7_EXT_MODE1 0x108
 
 #define A_MC7_EXT_MODE2 0x10c
@@ -619,14 +615,6 @@
 
 #define A_MC7_CAL 0x128
 
-#define S_BUSY31
-#define V_BUSY(x) ((x) << S_BUSY)
-#define F_BUSYV_BUSY(1U)
-
-#define S_BUSY31
-#define V_BUSY(x) ((x) << S_BUSY)
-#define F_BUSYV_BUSY(1U)
-
 #define S_CAL_FAULT30
 #define V_CAL_FAULT(x) ((x) << S_CAL_FAULT)
 #define F_CAL_FAULTV_CAL_FAULT(1U)
@@ -685,7 +673,6 @@
 #define V_OP(x) ((x) << S_OP)
 #define F_OPV_OP(1U)
 
-#define F_OPV_OP(1U)
 #define A_SF_OP 0x6dc
 
 #define A_MC7_BIST_ADDR_BEG 0x168
@@ -700,8 +687,6 @@
 #define V_CONT(x) ((x) << S_CONT)
 #define F_CONTV_CONT(1U)
 
-#define F_CONTV_CONT(1U)
-
 #define A_MC7_INT_ENABLE 0x178
 
 #define S_AE17
@@ -805,8 +790,6 @@
 #define V_NICMODE(x) ((x) << S_NICMODE)
 #define F_NICMODEV_NICMODE(1U)
 
-#define F_NICMODEV_NICMODE(1U)
-
 #define S_IPV6ENABLE15
 #define V_IPV6ENABLE(x) ((x) << S_IPV6ENABLE)
 #define F_IPV6ENABLEV_IPV6ENABLE(1U)
@@ -1268,27 +1251,15 @@
 #define A_ULPRX_STAG_ULIMIT 0x530
 
 #define A_ULPRX_RQ_LLIMIT 0x534
-#define A_ULPRX_RQ_LLIMIT 0x534
 
 #define A_ULPRX_RQ_ULIMIT 0x538
-#define A_ULPRX_RQ_ULIMIT 0x538
 
 #define A_ULPRX_PBL_LLIMIT 0x53c
 
 #define A_ULPRX_PBL_ULIMIT 0x540
-#define A_ULPRX_PBL_ULIMIT 0x540
 
 #define A_ULPRX_TDDP_TAGMASK 0x524
 
-#define A_ULPRX_RQ_LLIMIT 0x534
-#define A_ULPRX_RQ_LLIMIT 0x534
-
-#define A_ULPRX_RQ_ULIMIT 0x538
-#define A_ULPRX_RQ_ULIMIT 0x538
-
-#define A_ULPRX_PBL_ULIMIT 0x540
-#define A_ULPRX_PBL_ULIMIT 0x540
-
 #define A_ULPTX_CONFIG 0x580
 
 #define S_CFG_RR_ARB0
@@ -1615,8 +1586,6 @@
 
 #define A_SF_DATA 0x6d8
 
-#define A_SF_OP 0x6dc
-
 #define S_BYTECNT1
 #define M_BYTECNT0x3
 #define V_BYTECNT(x) ((x) << S_BYTECNT)
@@ -1747,8 +1716,6 @@
 #define V_TMMODE(x) ((x) << S_TMMODE)
 #define F_TMMODEV_TMMODE(1U)
 
-#define F_TMMODEV_TMMODE(1U)
-
 #define A_MC5_DB_ROUTING_TABLE_INDEX 0x70c
 
 #define A_MC5_DB_FILTER_TABLE 0x710
@@ -2110,8 +2077,6 @@
 #define V_TXACTENABLE(x) ((x) << S_TXACTENABLE)
 #define F_TXACTENABLEV_TXACTENABLE(1U)
 
-#define A_XGM_SERDES_CTRL0 0x8e0
-
 #define S_RESET323
 #define V_RESET3(x) ((x) << S_RESET3)
 #define F_RESET3V_RESET3(1U)
@@ -2240,8 +2205,6 @@
 #define V_CMULOCK(x) ((x) << S_CMULOCK)
 #define F_CMULOCKV_CMULOCK(1U)
 
-#define A_XGM_RX_MAX_PKT_SIZE_ERR_CNT 0x9a4
-
 #define A_XGM_TX_SPI4_SOP_EOP_CNT 0x9a8
 
 #define S_TXSPI4SOPCNT16
diff -ur a/drivers/net/e1000e/defines.h b/drivers/net/e1000e/defines.h
--- a/drivers/net/e1000e/defines.h  2007-11-07 11:26:13.0 +0100
+++ b/drivers/net/e1000e/defines.h  2007-11-07 22:16:15.0 +0100
@@ -29,6 +29,8 @@
 #ifndef _E1000_DEFINES_H_
 #define _E1000_DEFINES_H_
 
+/* Transmit Descriptor bit definitions */
+#define E1000_TXD_DTYP_D 0x0010 /* Data Descriptor */
 #define E1000_TXD_POPTS_IXSM 0x01   /* Insert IP checksum */
 #define E1000_TXD_POPTS_TXSM 0x02   /* Insert TCP/UDP checksum */
 #define E1000_TXD_CMD_EOP0x0100 /* End of Packet */
@@ -256,27 +258,6 @@
 #define E1000_LEDCTL_MODE_LED_ON0xE
 #define E1000_LEDCTL_MODE_LED_OFF   0xF
 
-/* Transmit Descriptor bit definitions */
-#define E1000_TXD_DTYP_D 0x0010 /* Data Descriptor */
-#define E1000_TXD_POPTS_IXSM 0x01   /* Insert IP checksum */
-#define E1000_TXD_POPTS_TXSM 0x02   /* Insert TCP/UDP checksum */
-#define E1000_TXD_CMD_EOP0x0100 /* End of Packet */
-#define E1000_TXD_CMD_IFCS   0x0200 /* Insert FCS (Ethernet CRC) */
-#define E1000_TXD_CMD_IC 0x0400 /* Insert Checksum */
-#define E1000_TXD_CMD_RS 0x0800 /* Report Status */
-#define E1000_TXD_CMD_RPS0x1000 /* Report Packet Sent */
-#define E1000_TXD_CMD_DEXT   0x2000 /* Descr

Re: [PATCH] [PKT_SCHED] CLS_U32: Use ffs() instead of C code on hash mask to get first set bit.

[jamal]

On Thu, 2007-08-11 at 13:07 +0200, Radu Rendec wrote:
> Computing the rank of the first set bit in the hash mask (for using later
> in u32_hash_fold()) was done with plain C code. Using ffs() instead makes
> the code more readable and improves performance (since ffs() is better
> optimized in assembler).
> 
> Using the conditional operator on hash mask before applying ntohl() also
> saves one ntohl() call if mask is 0.
> 
> Signed-off-by: Radu Rendec <[EMAIL PROTECTED]>

Acked-by: Jamal Hadi Salim <[EMAIL PROTECTED]>


cheers,
jamal


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

Re: [PATCH] [PKT_SCHED] CLS_U32: Use ffs() instead of C code on hash mask to get first set bit.

[Jarek Poplawski]

On Thu, Nov 08, 2007 at 01:07:47PM +0200, Radu Rendec wrote:
> Computing the rank of the first set bit in the hash mask (for using later
> in u32_hash_fold()) was done with plain C code. Using ffs() instead makes
> the code more readable and improves performance (since ffs() is better
> optimized in assembler).
> 
> Using the conditional operator on hash mask before applying ntohl() also
> saves one ntohl() call if mask is 0.
> 
> Signed-off-by: Radu Rendec <[EMAIL PROTECTED]>

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

> ---
>  net/sched/cls_u32.c |   12 +---
>  1 files changed, 1 insertions(+), 11 deletions(-)
> 
> diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
> index 5317102..c390082 100644
> --- a/net/sched/cls_u32.c
> +++ b/net/sched/cls_u32.c
> @@ -613,17 +613,7 @@ static int u32_change(struct tcf_proto *tp, unsigned 
> long base, u32 handle,
>   memcpy(&n->sel, s, sizeof(*s) + s->nkeys*sizeof(struct tc_u32_key));
>   n->ht_up = ht;
>   n->handle = handle;
> -{
> - u8 i = 0;
> - u32 mask = ntohl(s->hmask);
> - if (mask) {
> - while (!(mask & 1)) {
> - i++;
> - mask>>=1;
> - }
> - }
> - n->fshift = i;
> -}
> + n->fshift = s->hmask ? ffs(ntohl(s->hmask)) - 1 : 0;
>  
>  #ifdef CONFIG_CLS_U32_MARK
>   if (tb[TCA_U32_MARK-1]) {
> -- 
> 1.5.3.2
> 
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 19/24] [IPSEC]: Merge most of the output path

[Herbert Xu]

On Thu, Nov 08, 2007 at 12:23:29PM +0100, Patrick McHardy wrote:
>
> We have a few places that go though the trouble of selecting the
> "correct" hook value for the address family, even though the numerical
> values are identical. How about we just get rid of the different
> naming and use NF_INET_... for both IPv4 and IPv6?

Nice work! Thanks Patrick.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [PKT_SCHED] CLS_U32: Use ffs() instead of C code on hash mask to get first set bit.

[Radu Rendec]

Computing the rank of the first set bit in the hash mask (for using later
in u32_hash_fold()) was done with plain C code. Using ffs() instead makes
the code more readable and improves performance (since ffs() is better
optimized in assembler).

Using the conditional operator on hash mask before applying ntohl() also
saves one ntohl() call if mask is 0.

Signed-off-by: Radu Rendec <[EMAIL PROTECTED]>
---
 net/sched/cls_u32.c |   12 +---
 1 files changed, 1 insertions(+), 11 deletions(-)

diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
index 5317102..c390082 100644
--- a/net/sched/cls_u32.c
+++ b/net/sched/cls_u32.c
@@ -613,17 +613,7 @@ static int u32_change(struct tcf_proto *tp, unsigned long 
base, u32 handle,
memcpy(&n->sel, s, sizeof(*s) + s->nkeys*sizeof(struct tc_u32_key));
n->ht_up = ht;
n->handle = handle;
-{
-   u8 i = 0;
-   u32 mask = ntohl(s->hmask);
-   if (mask) {
-   while (!(mask & 1)) {
-   i++;
-   mask>>=1;
-   }
-   }
-   n->fshift = i;
-}
+   n->fshift = s->hmask ? ffs(ntohl(s->hmask)) - 1 : 0;
 
 #ifdef CONFIG_CLS_U32_MARK
if (tb[TCA_U32_MARK-1]) {
-- 
1.5.3.2

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

Re: [PATCH] No need to inc/dec packet_socks_nr if PACKET_REFCNT_DEBUG is not set

[Denis V. Lunev]

pls disregard this, Pavel have sent one similar already

Denis V. Lunev wrote:
> No need to inc/dec packet_socks_nr if PACKET_REFCNT_DEBUG is not set.
> 
> Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
> 
> --- ./net/packet/af_packet.c.packetrefcnt 2007-11-08 13:48:22.0 
> +0300
> +++ ./net/packet/af_packet.c  2007-11-08 13:54:29.0 +0300
> @@ -135,7 +135,9 @@ dev->hard_header == NULL (ll header is a
> packet classifier depends on it.
>   */
>  
> +#ifdef PACKET_REFCNT_DEBUG
>  static atomic_t packet_socks_nr;
> +#endif
>  
>  
>  /* Private packet socket structures. */
> @@ -232,8 +234,8 @@ static void packet_sock_destruct(struct 
>   return;
>   }
>  
> - atomic_dec(&packet_socks_nr);
>  #ifdef PACKET_REFCNT_DEBUG
> + atomic_dec(&packet_socks_nr);
>   printk(KERN_DEBUG "PACKET socket %p is free, %d are alive\n", sk, 
> atomic_read(&packet_socks_nr));
>  #endif
>  }
> @@ -1005,7 +1007,9 @@ static int packet_create(struct net *net
>   po->num = proto;
>  
>   sk->sk_destruct = packet_sock_destruct;
> +#ifdef PACKET_REFCNT_DEBUG
>   atomic_inc(&packet_socks_nr);
> +#endif
>  
>   /*
>*  Attach a protocol block
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

Re: Fwd: Re: [PATCH] iSCSI fix endieness of digest to be network byte order

[Herbert Xu]

On Thu, Nov 08, 2007 at 05:04:09PM +0900, FUJITA Tomonori wrote:
>
> I wonder why crc32c isn't used directly while crc32 is used directly
> since they vary by only the polynomial.

It's because iSCSI uses it with scatterlists.  The crypto layer
provides a nice interface for that while using it directly would
require the user to do the scatterlist walk.

> Using crc32c directly might enable us to kill net/sctp/crc32c.c and
> merge lib/crc32.c and lib/libcrc32c?

I'm pretty sure we can kill net/sctp/crc32c.c today by converting
it over to use the crypto interface.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] No need to inc/dec packet_socks_nr if PACKET_REFCNT_DEBUG is not set

[Denis V. Lunev]

No need to inc/dec packet_socks_nr if PACKET_REFCNT_DEBUG is not set.

Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>

--- ./net/packet/af_packet.c.packetrefcnt   2007-11-08 13:48:22.0 
+0300
+++ ./net/packet/af_packet.c2007-11-08 13:54:29.0 +0300
@@ -135,7 +135,9 @@ dev->hard_header == NULL (ll header is a
packet classifier depends on it.
  */
 
+#ifdef PACKET_REFCNT_DEBUG
 static atomic_t packet_socks_nr;
+#endif
 
 
 /* Private packet socket structures. */
@@ -232,8 +234,8 @@ static void packet_sock_destruct(struct 
return;
}
 
-   atomic_dec(&packet_socks_nr);
 #ifdef PACKET_REFCNT_DEBUG
+   atomic_dec(&packet_socks_nr);
printk(KERN_DEBUG "PACKET socket %p is free, %d are alive\n", sk, 
atomic_read(&packet_socks_nr));
 #endif
 }
@@ -1005,7 +1007,9 @@ static int packet_create(struct net *net
po->num = proto;
 
sk->sk_destruct = packet_sock_destruct;
+#ifdef PACKET_REFCNT_DEBUG
atomic_inc(&packet_socks_nr);
+#endif
 
/*
 *  Attach a protocol block
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Andrew Morton]

> On Thu, 8 Nov 2007 08:18:54 + Al Viro <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> >  config AX88796
> > tristate "ASIX AX88796 NE2000 clone support"
> > -   depends on ARM || MIPS
> > +   depends on ARM || MIPS || SUPERH
> 
> You know, that really sucks more and more.  How about doing the following:
>   a) making it depend on PLAT_HAS_AX88796
>   b) adding selects for all subarchitectures that have the corresponding
> platform device
> and setting that as a uniform policy for platform drivers?

Yup, but we should be religious about the naming conventions.  ARCH_HAS_
and PLAT_HAS_ followed by the exact name of the thus-enabled config option.

>  For things like
> SM501 we would do
> config MFD_SM501
>   depends on PCI || PLAT_HAS_SM501
> etc.

See, bug.  That should be PLAT_HAS_MFD_SM501

> Seriously, folks, we are getting shitloads of platform drivers with no
> dependencies whatsoever, needed on a handful of targets and occasionally
> failing to build on unrelated architectures.  Moreover, having a list
> of architectures in dependencies for each of those suckers is a PITA
> from the conflict POV.  Not to mention platform drivers that fall into
> the mainline kernel with not a single platform device for them, etc.
> 
> Comments?

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

Re: ax88796: add superh to kconfig dependencies

[Paul Mundt]

On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> ax88796: add superh to kconfig dependencies
> 
> This patch adds sh architecture support to the ax88796 kconfig.
> 
> Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>
> ---
> 
>  This patch was posted about a month ago but never picked up:
>  http://www.mail-archive.com/netdev@vger.kernel.org/msg50018.html
>  The rest of the sh support is already included in rc1. Please apply.
> 
And as per:

http://www.mail-archive.com/netdev@vger.kernel.org/msg50027.html

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

[RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

[Al Viro]

On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
>  config AX88796
>   tristate "ASIX AX88796 NE2000 clone support"
> - depends on ARM || MIPS
> + depends on ARM || MIPS || SUPERH

You know, that really sucks more and more.  How about doing the following:
a) making it depend on PLAT_HAS_AX88796
b) adding selects for all subarchitectures that have the corresponding
platform device
and setting that as a uniform policy for platform drivers?  For things like
SM501 we would do
config MFD_SM501
depends on PCI || PLAT_HAS_SM501
etc.

Seriously, folks, we are getting shitloads of platform drivers with no
dependencies whatsoever, needed on a handful of targets and occasionally
failing to build on unrelated architectures.  Moreover, having a list
of architectures in dependencies for each of those suckers is a PITA
from the conflict POV.  Not to mention platform drivers that fall into
the mainline kernel with not a single platform device for them, etc.

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