* Re: [PATCH] fix ACK processing after netlink_dump_start
From: Thomas Graf @ 2007-10-23 16:34 UTC (permalink / raw)
To: Denis V. Lunev; +Cc: dcbw, jfannin, davem, netdev, kuznet
In-Reply-To: <20071023144023.GA15035@iris.sw.ru>
* Denis V. Lunev <den@openvz.org> 2007-10-23 18:40
> Revert to original netlink behavior. Do not reply with ACK if the
> netlink dump has bees successfully started.
>
> libnl has been broken by the cd40b7d3983c708aabe3d3008ec64ffce56d33b0
> The following command reproduce the problem:
> /nl-route-get 192.168.1.1
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
ACK. Thank you for taking care of this.
^ permalink raw reply
* [PATCH] Cleanup the IPv6 addresses printing in /proc files
From: Pavel Emelyanov @ 2007-10-23 16:37 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
The /proc/net udp6, tcp6 and raw6 files print the IPs of
the connection ends. Make a NIP6Lxxx macros (L stands for
"long") for making the printing code look nicer.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 94bc996..5d199ae 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -307,6 +307,13 @@ static inline int __attribute__ ((format (printf, 1, 2))) pr_debug(const char *
#define NIP6_FMT "%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x"
#define NIP6_SEQFMT "%04x%04x%04x%04x%04x%04x%04x%04x"
+#define NIP6L(addr) \
+ ((addr).s6_addr32[0]), \
+ ((addr).s6_addr32[1]), \
+ ((addr).s6_addr32[2]), \
+ ((addr).s6_addr32[3])
+#define NIP6L_FMT "%08X%08X%08X%08X"
+
#if defined(__LITTLE_ENDIAN)
#define HIPQUAD(addr) \
((unsigned char *)&addr)[3], \
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index ca24ef1..c3a1939 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -1250,13 +1250,9 @@ static void raw6_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
destp = 0;
srcp = inet_sk(sp)->num;
seq_printf(seq,
- "%4d: %08X%08X%08X%08X:%04X %08X%08X%08X%08X:%04X "
+ "%4d: " NIP6L_FMT ":%04X " NIP6L_FMT ":%04X "
"%02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p\n",
- i,
- src->s6_addr32[0], src->s6_addr32[1],
- src->s6_addr32[2], src->s6_addr32[3], srcp,
- dest->s6_addr32[0], dest->s6_addr32[1],
- dest->s6_addr32[2], dest->s6_addr32[3], destp,
+ i, NIP6L(*src), srcp, NIP6L(*dest), destp,
sp->sk_state,
atomic_read(&sp->sk_wmem_alloc),
atomic_read(&sp->sk_rmem_alloc),
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 737b755..0041be3 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1945,15 +1945,10 @@ static void get_openreq6(struct seq_file *seq,
ttd = 0;
seq_printf(seq,
- "%4d: %08X%08X%08X%08X:%04X %08X%08X%08X%08X:%04X "
+ "%4d: " NIP6L_FMT ":%04X " NIP6L_FMT ":%04X "
"%02X %08X:%08X %02X:%08lX %08X %5d %8d %d %d %p\n",
- i,
- src->s6_addr32[0], src->s6_addr32[1],
- src->s6_addr32[2], src->s6_addr32[3],
- ntohs(inet_sk(sk)->sport),
- dest->s6_addr32[0], dest->s6_addr32[1],
- dest->s6_addr32[2], dest->s6_addr32[3],
- ntohs(inet_rsk(req)->rmt_port),
+ i, NIP6L(*src), ntohs(inet_sk(sk)->sport),
+ NIP6L(*dest), ntohs(inet_rsk(req)->rmt_port),
TCP_SYN_RECV,
0,0, /* could print option size, but that is af dependent. */
1, /* timers active (only the expire timer) */
@@ -1996,13 +1991,9 @@ static void get_tcp6_sock(struct seq_file *seq, struct sock *sp, int i)
}
seq_printf(seq,
- "%4d: %08X%08X%08X%08X:%04X %08X%08X%08X%08X:%04X "
+ "%4d: " NIP6L_FMT ":%04X " NIP6L_FMT ":%04X "
"%02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p %u %u %u %u %d\n",
- i,
- src->s6_addr32[0], src->s6_addr32[1],
- src->s6_addr32[2], src->s6_addr32[3], srcp,
- dest->s6_addr32[0], dest->s6_addr32[1],
- dest->s6_addr32[2], dest->s6_addr32[3], destp,
+ i, NIP6L(*src), srcp, NIP6L(*dest), destp,
sp->sk_state,
tp->write_seq-tp->snd_una,
(sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog : (tp->rcv_nxt - tp->copied_seq),
@@ -2037,13 +2028,9 @@ static void get_timewait6_sock(struct seq_file *seq,
srcp = ntohs(tw->tw_sport);
seq_printf(seq,
- "%4d: %08X%08X%08X%08X:%04X %08X%08X%08X%08X:%04X "
+ "%4d: " NIP6L_FMT ":%04X " NIP6L_FMT ":%04X "
"%02X %08X:%08X %02X:%08lX %08X %5d %8d %d %d %p\n",
- i,
- src->s6_addr32[0], src->s6_addr32[1],
- src->s6_addr32[2], src->s6_addr32[3], srcp,
- dest->s6_addr32[0], dest->s6_addr32[1],
- dest->s6_addr32[2], dest->s6_addr32[3], destp,
+ i, NIP6L(*src), srcp, NIP6L(*dest), destp,
tw->tw_substate, 0, 0,
3, jiffies_to_clock_t(ttd), 0, 0, 0, 0,
atomic_read(&tw->tw_refcnt), tw);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index caebad6..bcc5f8e 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -919,13 +919,9 @@ static void udp6_sock_seq_show(struct seq_file *seq, struct sock *sp, int bucket
destp = ntohs(inet->dport);
srcp = ntohs(inet->sport);
seq_printf(seq,
- "%4d: %08X%08X%08X%08X:%04X %08X%08X%08X%08X:%04X "
+ "%4d: " NIP6L_FMT ":%04X " NIP6L_FMT ":%04X "
"%02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p\n",
- bucket,
- src->s6_addr32[0], src->s6_addr32[1],
- src->s6_addr32[2], src->s6_addr32[3], srcp,
- dest->s6_addr32[0], dest->s6_addr32[1],
- dest->s6_addr32[2], dest->s6_addr32[3], destp,
+ bucket, NIP6L(*src), srcp, NIP6L(*dest), destp,
sp->sk_state,
atomic_read(&sp->sk_wmem_alloc),
atomic_read(&sp->sk_rmem_alloc),
^ permalink raw reply related
* [VLAN]: MAINTAINERS update
From: Patrick McHardy @ 2007-10-23 16:37 UTC (permalink / raw)
To: David Miller; +Cc: Ben Greear, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 618 bytes --]
[VLAN]: MAINTAINERS update
Ben stepped down from VLAN maintainership due to a lack of time,
add myself as new maintainer.
Cc: Ben Greear <greearb@candelatech.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/MAINTAINERS b/MAINTAINERS
index 1fd6d02..0ad7447 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4160,6 +4160,12 @@ W: http://linuxtv.org
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
S: Maintained
+VLAN (802.1Q)
+P: Patrick McHardy
+M: kaber@trash.net
+L: netdev@vger.kernel.org
+S: Maintained
+
VT1211 HARDWARE MONITOR DRIVER
P: Juerg Haefliger
M: juergh@gmail.com
^ permalink raw reply related
* Re: [PATCH] USB: net: Fix asix read transfer buffer allocations.
From: Ingo Oeser @ 2007-10-23 17:00 UTC (permalink / raw)
To: Valentine Barshak; +Cc: netdev, Oliver Neukum, linux-usb-devel
In-Reply-To: <471CF893.3050605@ru.mvista.com>
Valentine Barshak schrieb:
> Oliver Neukum wrote:
> > Am Montag 22 Oktober 2007 schrieb Valentine Barshak:
> >> static int asix_mdio_read(struct net_device *netdev, int phy_id, int loc)
> >> {
> >> struct usbnet *dev = netdev_priv(netdev);
> >> + void *buf;
> >> u16 res;
> >>
> >> mutex_lock(&dev->phy_mutex);
> >> asix_set_sw_mii(dev);
> >> +
> >> + buf = kmalloc(2, GFP_KERNEL);
> >
> > This is done under lock. Can you allocate the buffer once and reuse it?
> I think we can use 2 bytes of the usbnet data buffer for this.
> I'll submit a new patch soon.
If this cannot be done for some reason, then you can at least kmalloc() before
you do "mutex_lock(&dev->phy_mutex);" and kfree() after you did
"mutex_unlock(&dev->phy_mutex);"
The reason to can do this, is that "buf" has a life time limited to this function.
The reason you should do this, is that kmalloc(, GFP_KERNEL) is allowed to sleep,
which will block the mutex for that time. While this is technically ok,
since mutexes can sleep, it is not desireable, since other users of that mutex
are blocked until the allocation is done.
If you are able to implement the "2 bytes of usbnet data buffer" version,
please ignore that mail :-)
Best Regards
Ingo Oeser
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* Re: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
From: Scott Wood @ 2007-10-23 17:10 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1; +Cc: David Miller, netdev, jgarzik, linuxppc-dev
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2701685446@az33exm24.fsl.freescale.net>
On Mon, Oct 22, 2007 at 06:47:32AM -0700, Medve Emilian-EMMEDVE1 wrote:
> Are you suggesting we leave those warnings there until somebody decides
> to fix all the portability issues of this driver? My patch is a small
> and insignificant improvement and not the revolution you're asking for,
> but is an small improvement today (I dislike warnings) vs. an improbable
> big one in the future.
It is not an improvement, as it moves the driver further away from being
64-bit clean. A better fix would be to change the definition of
tx/rx_bd_ring_offset to unsigned long (or better yet, a union).
-Scott
^ permalink raw reply
* Re: [PATCH][MIPS] AR7 ethernet
From: Matteo Croce @ 2007-10-23 17:12 UTC (permalink / raw)
To: Jeff Garzik
Cc: linux-mips, Eugene Konev, netdev, davem, kuznet, pekkas, jmorris,
yoshfuji, kaber, Andrew Morton
In-Reply-To: <4713B055.802@pobox.com>
Il Monday 15 October 2007 20:24:21 Jeff Garzik ha scritto:
> applied
Small update to the driver, please apply
Signed-off-by: Matteo Croce <technoboy85@gmail.com>
Signed-off-by: Eugene Konev <ejka@imfi.kspu.ru>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
diff --git a/drivers/net/cpmac.c b/drivers/net/cpmac.c
index ae41973..57541d2 100644
--- a/drivers/net/cpmac.c
+++ b/drivers/net/cpmac.c
@@ -460,18 +460,11 @@ static int cpmac_start_xmit(struct sk_buff *skb, struct net_device *dev)
struct cpmac_desc *desc;
struct cpmac_priv *priv = netdev_priv(dev);
- if (unlikely(skb_padto(skb, ETH_ZLEN))) {
- if (netif_msg_tx_err(priv) && net_ratelimit())
- printk(KERN_WARNING
- "%s: tx: padding failed, dropping\n", dev->name);
- spin_lock(&priv->lock);
- dev->stats.tx_dropped++;
- spin_unlock(&priv->lock);
- return -ENOMEM;
- }
+ if (unlikely(skb_padto(skb, ETH_ZLEN)))
+ return NETDEV_TX_OK;
len = max(skb->len, ETH_ZLEN);
- queue = skb_get_queue_mapping(skb);
+ queue = skb->queue_mapping;
#ifdef CONFIG_NETDEVICES_MULTIQUEUE
netif_stop_subqueue(dev, queue);
#else
@@ -481,13 +474,9 @@ static int cpmac_start_xmit(struct sk_buff *skb, struct net_device *dev)
desc = &priv->desc_ring[queue];
if (unlikely(desc->dataflags & CPMAC_OWN)) {
if (netif_msg_tx_err(priv) && net_ratelimit())
- printk(KERN_WARNING "%s: tx dma ring full, dropping\n",
+ printk(KERN_WARNING "%s: tx dma ring full\n",
dev->name);
- spin_lock(&priv->lock);
- dev->stats.tx_dropped++;
- spin_unlock(&priv->lock);
- dev_kfree_skb_any(skb);
- return -ENOMEM;
+ return NETDEV_TX_BUSY;
}
spin_lock(&priv->lock);
@@ -509,7 +498,7 @@ static int cpmac_start_xmit(struct sk_buff *skb, struct net_device *dev)
cpmac_dump_skb(dev, skb);
cpmac_write(priv->regs, CPMAC_TX_PTR(queue), (u32)desc->mapping);
- return 0;
+ return NETDEV_TX_OK;
}
static void cpmac_end_xmit(struct net_device *dev, int queue)
@@ -646,12 +635,14 @@ static void cpmac_clear_tx(struct net_device *dev)
int i;
if (unlikely(!priv->desc_ring))
return;
- for (i = 0; i < CPMAC_QUEUES; i++)
+ for (i = 0; i < CPMAC_QUEUES; i++) {
+ priv->desc_ring[i].dataflags = 0;
if (priv->desc_ring[i].skb) {
dev_kfree_skb_any(priv->desc_ring[i].skb);
if (netif_subqueue_stopped(dev, i))
netif_wake_subqueue(dev, i);
}
+ }
}
static void cpmac_hw_error(struct work_struct *work)
@@ -727,11 +718,13 @@ static void cpmac_tx_timeout(struct net_device *dev)
#ifdef CONFIG_NETDEVICES_MULTIQUEUE
for (i = 0; i < CPMAC_QUEUES; i++)
if (priv->desc_ring[i].skb) {
+ priv->desc_ring[i].dataflags = 0;
dev_kfree_skb_any(priv->desc_ring[i].skb);
netif_wake_subqueue(dev, i);
break;
}
#else
+ priv->desc_ring[0].dataflags = 0;
if (priv->desc_ring[0].skb)
dev_kfree_skb_any(priv->desc_ring[0].skb);
netif_wake_queue(dev);
@@ -794,7 +787,7 @@ static int cpmac_set_ringparam(struct net_device *dev, struct ethtool_ringparam*
{
struct cpmac_priv *priv = netdev_priv(dev);
- if (dev->flags && IFF_UP)
+ if (netif_running(dev))
return -EBUSY;
priv->ring_size = ring->rx_pending;
return 0;
^ permalink raw reply related
* Re: [PATCH] USB: net: Fix asix read transfer buffer allocations.
From: Valentine Barshak @ 2007-10-23 17:20 UTC (permalink / raw)
To: Ingo Oeser; +Cc: netdev, Oliver Neukum, linux-usb-devel
In-Reply-To: <200710231900.14696.netdev@axxeo.de>
Ingo Oeser wrote:
> Valentine Barshak schrieb:
>> Oliver Neukum wrote:
>>> Am Montag 22 Oktober 2007 schrieb Valentine Barshak:
>>>> static int asix_mdio_read(struct net_device *netdev, int phy_id, int loc)
>>>> {
>>>> struct usbnet *dev = netdev_priv(netdev);
>>>> + void *buf;
>>>> u16 res;
>>>>
>>>> mutex_lock(&dev->phy_mutex);
>>>> asix_set_sw_mii(dev);
>>>> +
>>>> + buf = kmalloc(2, GFP_KERNEL);
>>> This is done under lock. Can you allocate the buffer once and reuse it?
>> I think we can use 2 bytes of the usbnet data buffer for this.
>> I'll submit a new patch soon.
>
> If this cannot be done for some reason, then you can at least kmalloc() before
> you do "mutex_lock(&dev->phy_mutex);" and kfree() after you did
> "mutex_unlock(&dev->phy_mutex);"
>
> The reason to can do this, is that "buf" has a life time limited to this function.
>
> The reason you should do this, is that kmalloc(, GFP_KERNEL) is allowed to sleep,
> which will block the mutex for that time. While this is technically ok,
> since mutexes can sleep, it is not desireable, since other users of that mutex
> are blocked until the allocation is done.
>
> If you are able to implement the "2 bytes of usbnet data buffer" version,
> please ignore that mail :-)
>
>
> Best Regards
>
> Ingo Oeser
Looks like we cannot use usbnet data buffer for read transfers either,
because it's just a part of the usbnet structure and we may still lose
data while invalidating cache the same way we do using buffers on stack.
Allocating a permanent buffer for phy transfer needs more driver
changes: we should add unbind finction to the device_info for all asix
devices to deallocate the buffer at exit.
And we still need to allocate buffers for other transfers dynamically,
so having just one permanent buffer for phy doesn't help much.
I've reworked the original patch a bit: moved kmalloc out of the
phy_mutex and added more clean-ups.
Will submit shortly.
Thanks,
Valentine.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* [PATCH] USB: net: Fix asix read transfer buffer allocations.
From: Valentine Barshak @ 2007-10-23 17:40 UTC (permalink / raw)
To: linux-usb-devel; +Cc: netdev
In-Reply-To: <471E2D52.5060404@ru.mvista.com>
On systems with noncoherent cache, allocating dma buffers
on the stack for USB IN transfers causes kernel crash,
because usb map_urb_for_dma() code calls dma_map_single(),
that invalidates data cache for DMA_FROM_DEVICE transfer direction
and causes stack data loss if transfer size is less than cache line
and not cache-line aligned. This patch makes asix usb network
driver allocate USB IN transfer buffers with kmalloc instead of
directly using variables on stack. It also sets data parameter to NULL
for zero-length transfers and uses ETH_ALEN size for allocating MAC
address buffer.
diff -pruN linux-2.6.orig/drivers/net/usb/asix.c linux-2.6/drivers/net/usb/asix.c
--- linux-2.6.orig/drivers/net/usb/asix.c 2007-10-23 20:52:11.000000000 +0400
+++ linux-2.6/drivers/net/usb/asix.c 2007-10-23 20:57:38.000000000 +0400
@@ -568,15 +568,23 @@ static void asix_set_multicast(struct ne
static int asix_mdio_read(struct net_device *netdev, int phy_id, int loc)
{
struct usbnet *dev = netdev_priv(netdev);
+ void *buf;
u16 res;
+ buf = kmalloc(2, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
mutex_lock(&dev->phy_mutex);
asix_set_sw_mii(dev);
asix_read_cmd(dev, AX_CMD_READ_MII_REG, phy_id,
- (__u16)loc, 2, (u16 *)&res);
+ (__u16)loc, 2, buf);
asix_set_hw_mii(dev);
mutex_unlock(&dev->phy_mutex);
+ res = *((u16 *)buf);
+ kfree(buf);
+
devdbg(dev, "asix_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x", phy_id, loc, le16_to_cpu(res & 0xffff));
return le16_to_cpu(res & 0xffff);
@@ -622,13 +630,22 @@ static void
asix_get_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
{
struct usbnet *dev = netdev_priv(net);
+ void *buf;
u8 opt;
- if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, &opt) < 0) {
+ buf = kmalloc(1, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, buf) < 0) {
wolinfo->supported = 0;
wolinfo->wolopts = 0;
+ kfree(buf);
return;
}
+ opt = *((u8 *)buf);
+ kfree(buf);
+
wolinfo->supported = WAKE_PHY | WAKE_MAGIC;
wolinfo->wolopts = 0;
if (opt & AX_MONITOR_MODE) {
@@ -644,7 +661,6 @@ asix_set_wol(struct net_device *net, str
{
struct usbnet *dev = netdev_priv(net);
u8 opt = 0;
- u8 buf[1];
if (wolinfo->wolopts & WAKE_PHY)
opt |= AX_MONITOR_LINK;
@@ -654,7 +670,7 @@ asix_set_wol(struct net_device *net, str
opt |= AX_MONITOR_MODE;
if (asix_write_cmd(dev, AX_CMD_WRITE_MONITOR_MODE,
- opt, 0, 0, &buf) < 0)
+ opt, 0, 0, NULL) < 0)
return -EINVAL;
return 0;
@@ -820,7 +836,7 @@ static int ax88172_bind(struct usbnet *d
for (i = 2; i >= 0; i--) {
if ((ret = asix_write_cmd(dev, AX_CMD_WRITE_GPIOS,
(gpio_bits >> (i * 8)) & 0xff, 0, 0,
- buf)) < 0)
+ NULL)) < 0)
goto out2;
msleep(5);
}
@@ -831,7 +847,7 @@ static int ax88172_bind(struct usbnet *d
/* Get the MAC address */
memset(buf, 0, ETH_ALEN);
if ((ret = asix_read_cmd(dev, AX88172_CMD_READ_NODE_ID,
- 0, 0, 6, buf)) < 0) {
+ 0, 0, ETH_ALEN, buf)) < 0) {
dbg("read AX_CMD_READ_NODE_ID failed: %d", ret);
goto out2;
}
@@ -909,7 +925,7 @@ static int ax88772_bind(struct usbnet *d
usbnet_get_endpoints(dev,intf);
- buf = kmalloc(6, GFP_KERNEL);
+ buf = kmalloc(ETH_ALEN, GFP_KERNEL);
if(!buf) {
dbg ("Cannot allocate memory for buffer");
ret = -ENOMEM;
@@ -923,7 +939,7 @@ static int ax88772_bind(struct usbnet *d
/* 0x10 is the phy id of the embedded 10/100 ethernet phy */
embd_phy = ((asix_get_phy_addr(dev) & 0x1f) == 0x10 ? 1 : 0);
if ((ret = asix_write_cmd(dev, AX_CMD_SW_PHY_SELECT,
- embd_phy, 0, 0, buf)) < 0) {
+ embd_phy, 0, 0, NULL)) < 0) {
dbg("Select PHY #1 failed: %d", ret);
goto out2;
}
@@ -998,7 +1014,7 @@ static int ax88772_bind(struct usbnet *d
if ((ret = asix_write_cmd(dev, AX_CMD_WRITE_IPG0,
AX88772_IPG0_DEFAULT | AX88772_IPG1_DEFAULT,
- AX88772_IPG2_DEFAULT, 0, buf)) < 0) {
+ AX88772_IPG2_DEFAULT, 0, NULL)) < 0) {
dbg("Write IPG,IPG1,IPG2 failed: %d", ret);
goto out2;
}
@@ -1202,20 +1218,22 @@ static int ax88178_bind(struct usbnet *d
usbnet_get_endpoints(dev,intf);
- buf = kmalloc(6, GFP_KERNEL);
+ buf = kmalloc(ETH_ALEN, GFP_KERNEL);
if(!buf) {
dbg ("Cannot allocate memory for buffer");
ret = -ENOMEM;
goto out1;
}
- eeprom = 0;
- asix_read_cmd(dev, AX_CMD_READ_GPIOS, 0, 0, 1, &eeprom);
+ memset(buf, 0, ETH_ALEN);
+ asix_read_cmd(dev, AX_CMD_READ_GPIOS, 0, 0, 1, buf);
+ eeprom = *(u8 *)buf;
dbg("GPIO Status: 0x%04x", eeprom);
asix_write_cmd(dev, AX_CMD_WRITE_ENABLE, 0, 0, 0, NULL);
- asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x0017, 0, 2, &eeprom);
+ asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x0017, 0, 2, buf);
asix_write_cmd(dev, AX_CMD_WRITE_DISABLE, 0, 0, 0, NULL);
+ eeprom = *(u16 *)buf;
dbg("EEPROM index 0x17 is 0x%04x", eeprom);
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* [PATCH] UDP: Make use of inet_iif() when doing socket lookups.
From: Vlad Yasevich @ 2007-10-23 18:40 UTC (permalink / raw)
To: netdev
UDP currently uses skb->dev->ifindex which may provide the wrong
information when the socket bound to a specific interface.
This patch makes inet_iif() accessible to UDP and makes UDP use it.
The scenario we are trying to fix is when a client is running on
the same system and the server and both client and server bind to
a non-loopback device.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
---
include/net/inet_hashtables.h | 6 ------
include/net/inet_sock.h | 7 +++++++
net/ipv4/udp.c | 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
index 8228b57..4427dcd 100644
--- a/include/net/inet_hashtables.h
+++ b/include/net/inet_hashtables.h
@@ -26,7 +26,6 @@
#include <net/inet_connection_sock.h>
#include <net/inet_sock.h>
-#include <net/route.h>
#include <net/sock.h>
#include <net/tcp_states.h>
@@ -266,11 +265,6 @@ out:
wake_up(&hashinfo->lhash_wait);
}
-static inline int inet_iif(const struct sk_buff *skb)
-{
- return ((struct rtable *)skb->dst)->rt_iif;
-}
-
extern struct sock *__inet_lookup_listener(struct inet_hashinfo *hashinfo,
const __be32 daddr,
const unsigned short hnum,
diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 62daf21..70013c5 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -24,6 +24,7 @@
#include <net/flow.h>
#include <net/sock.h>
#include <net/request_sock.h>
+#include <net/route.h>
/** struct ip_options - IP Options
*
@@ -190,4 +191,10 @@ static inline int inet_sk_ehashfn(const struct sock *sk)
return inet_ehashfn(laddr, lport, faddr, fport);
}
+
+static inline int inet_iif(const struct sk_buff *skb)
+{
+ return ((struct rtable *)skb->dst)->rt_iif;
+}
+
#endif /* _INET_SOCK_H */
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 35d2b0e..4bc25b4 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1152,7 +1152,7 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct hlist_head udptable[],
return __udp4_lib_mcast_deliver(skb, uh, saddr, daddr, udptable);
sk = __udp4_lib_lookup(saddr, uh->source, daddr, uh->dest,
- skb->dev->ifindex, udptable );
+ inet_iif(skb), udptable);
if (sk != NULL) {
int ret = udp_queue_rcv_skb(sk, skb);
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH RESEND] ip_gre: sendto/recvfrom NBMA address
From: Alexey Kuznetsov @ 2007-10-23 19:03 UTC (permalink / raw)
To: Timo Ter?s; +Cc: Patrick McHardy, davem, netdev
In-Reply-To: <471E19E5.5040509@iki.fi>
Hello!
> When GRE tunnel is in NBMA mode, this patch allows an application to use
> a PF_PACKET socket to:
> - send a packet to specific NBMA address with sendto()
> - use recvfrom() to receive packet and check which NBMA address it came from
>
> This is required to implement properly NHRP over GRE tunnel.
Ack. This is good idea.
Frankly, I was sure ip_gre worked in this way all these years.
I do not remember any reasons why it was crippled.
The only dubious case is when next hop is set using routing tables.
But code in ipgre_tunnel_xmit() is ready to accept this situation,
it checks for zero destination address and fixes it when it is able to.
Alexey
^ permalink raw reply
* [PATCH] e1000: alternate MAC address support
From: Bill Hayes @ 2007-10-23 19:14 UTC (permalink / raw)
To: jeff, auke-jan.h.kok, netdev, andy
Port alternate MAC address support from the sourceforge
e1000 driver to the upstream e1000 driver.
Signed-off-by: Bill Hayes <bill.hayes@hp.com>
---
drivers/net/e1000/e1000_hw.c | 42 +++++++++++++++++++++++++++++++++++++++---
drivers/net/e1000/e1000_hw.h | 2 ++
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index 8fa0fe4..07e3178 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -719,6 +719,11 @@ e1000_reset_hw(struct e1000_hw *hw)
DEBUGOUT("Masking off all interrupts\n");
E1000_WRITE_REG(hw, IMC, 0xffffffff);
+ if (hw->mac_type == e1000_82571 && hw->alt_mac_addr_is_present) {
+ hw->laa_is_present = 1;
+ e1000_rar_set(hw, hw->mac_addr, E1000_RAR_ENTRIES - 1);
+ }
+
/* Clear any pending interrupt events. */
icr = E1000_READ_REG(hw, ICR);
@@ -5693,11 +5698,41 @@ e1000_read_mac_addr(struct e1000_hw * hw)
{
uint16_t offset;
uint16_t eeprom_data, i;
+ u16 mac_addr_offset = 0;
DEBUGFUNC("e1000_read_mac_addr");
+ if (hw->mac_type == e1000_82571) {
+ /* Check for an alternate MAC address. An alternate MAC address can
+ * be setup by pre-boot software and must be treated like a permanent
+ * address and must override the actual permanent MAC address. */
+ if (e1000_read_eeprom(hw, EEPROM_ALT_MAC_ADDR_PTR, 1,
+ &mac_addr_offset) < 0) {
+ DEBUGOUT("EEPROM Read Error\n");
+ return -E1000_ERR_EEPROM;
+ }
+ if (mac_addr_offset == 0xFFFF)
+ mac_addr_offset = 0;
+
+ if (mac_addr_offset) {
+ if (E1000_READ_REG(hw, STATUS) & E1000_STATUS_FUNC_1)
+ mac_addr_offset += NODE_ADDRESS_SIZE/sizeof(u16);
+
+ /* make sure we have a valid mac address here before using it */
+ if (e1000_read_eeprom(hw, mac_addr_offset, 1, &eeprom_data) < 0) {
+ DEBUGOUT("EEPROM Read Error\n");
+ return -E1000_ERR_EEPROM;
+ }
+ if (eeprom_data & 0x0001)
+ mac_addr_offset = 0;
+ }
+
+ if (mac_addr_offset)
+ hw->alt_mac_addr_is_present = 1;
+ }
+
for (i = 0; i < NODE_ADDRESS_SIZE; i += 2) {
- offset = i >> 1;
+ offset = mac_addr_offset + (i >> 1);
if (e1000_read_eeprom(hw, offset, 1, &eeprom_data) < 0) {
DEBUGOUT("EEPROM Read Error\n");
return -E1000_ERR_EEPROM;
@@ -5713,8 +5748,9 @@ e1000_read_mac_addr(struct e1000_hw * hw)
case e1000_82546_rev_3:
case e1000_82571:
case e1000_80003es2lan:
- if (E1000_READ_REG(hw, STATUS) & E1000_STATUS_FUNC_1)
- hw->perm_mac_addr[5] ^= 0x01;
+ if (!mac_addr_offset &&
+ (E1000_READ_REG(hw, STATUS) & E1000_STATUS_FUNC_1))
+ hw->perm_mac_addr[5] ^= 0x01;
break;
}
diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h
index a2a86c5..e18760d 100644
--- a/drivers/net/e1000/e1000_hw.h
+++ b/drivers/net/e1000/e1000_hw.h
@@ -1456,6 +1456,7 @@ struct e1000_hw {
boolean_t tbi_compatibility_en;
boolean_t tbi_compatibility_on;
boolean_t laa_is_present;
+ boolean_t alt_mac_addr_is_present;
boolean_t phy_reset_disable;
boolean_t initialize_hw_bits_disable;
boolean_t fc_send_xon;
@@ -2286,6 +2287,7 @@ struct e1000_host_command_info {
#define EEPROM_INIT_CONTROL3_PORT_A 0x0024
#define EEPROM_CFG 0x0012
#define EEPROM_FLASH_VERSION 0x0032
+#define EEPROM_ALT_MAC_ADDR_PTR 0x0037
#define EEPROM_CHECKSUM_REG 0x003F
#define E1000_EEPROM_CFG_DONE 0x00040000 /* MNG config cycle done */
^ permalink raw reply related
* [PATCH] e1000e: alternate MAC address support
From: Bill Hayes @ 2007-10-23 19:13 UTC (permalink / raw)
To: jeff, auke-jan.h.kok, netdev, andy
Port alternate MAC address support from the sourceforge
e1000 driver to the upstream e1000e driver.
Signed-off-by: Bill Hayes <bill.hayes@hp.com>
---
drivers/net/e1000e/82571.c | 4 ++++
drivers/net/e1000e/lib.c | 39 +++++++++++++++++++++++++++++++++++++--
drivers/net/e1000e/hw.h | 1 +
drivers/net/e1000e/defines.h | 1 +
4 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/82571.c b/drivers/net/e1000e/82571.c
index cf70522..4bef111 100644
--- a/drivers/net/e1000e/82571.c
+++ b/drivers/net/e1000e/82571.c
@@ -752,6 +752,10 @@ static s32 e1000_reset_hw_82571(struct e1000_hw *hw)
ew32(IMC, 0xffffffff);
icr = er32(ICR);
+ if (hw->mac.type == e1000_82571 &&
+ hw->dev_spec.e82571.alt_mac_addr_is_present)
+ e1000e_set_laa_state_82571(hw, TRUE);
+
return 0;
}
diff --git a/drivers/net/e1000e/lib.c b/drivers/net/e1000e/lib.c
index 0bdeca3..16f35fa 100644
--- a/drivers/net/e1000e/lib.c
+++ b/drivers/net/e1000e/lib.c
@@ -2059,9 +2059,44 @@ s32 e1000e_read_mac_addr(struct e1000_hw *hw)
{
s32 ret_val;
u16 offset, nvm_data, i;
+ u16 mac_addr_offset = 0;
+
+ if (hw->mac.type == e1000_82571) {
+ /* Check for an alternate MAC address. An alternate MAC
+ * address can be setup by pre-boot software and must be
+ * treated like a permanent address and must override the
+ * actual permanent MAC address. */
+ ret_val = e1000_read_nvm(hw, NVM_ALT_MAC_ADDR_PTR, 1,
+ &mac_addr_offset);
+ if (ret_val) {
+ hw_dbg(hw, "NVM Read Error\n");
+ return ret_val;
+ }
+ if (mac_addr_offset == 0xFFFF)
+ mac_addr_offset = 0;
+
+ if (mac_addr_offset) {
+ if (hw->bus.func == E1000_FUNC_1)
+ mac_addr_offset += ETH_ALEN/sizeof(u16);
+
+ /* make sure we have a valid mac address here
+ * before using it */
+ ret_val = e1000_read_nvm(hw, mac_addr_offset, 1,
+ &nvm_data);
+ if (ret_val) {
+ hw_dbg(hw, "NVM Read Error\n");
+ return ret_val;
+ }
+ if (nvm_data & 0x0001)
+ mac_addr_offset = 0;
+ }
+
+ if (mac_addr_offset)
+ hw->dev_spec.e82571.alt_mac_addr_is_present = 1;
+ }
for (i = 0; i < ETH_ALEN; i += 2) {
- offset = i >> 1;
+ offset = mac_addr_offset + (i >> 1);
ret_val = e1000_read_nvm(hw, offset, 1, &nvm_data);
if (ret_val) {
hw_dbg(hw, "NVM Read Error\n");
@@ -2072,7 +2107,7 @@ s32 e1000e_read_mac_addr(struct e1000_hw *hw)
}
/* Flip last bit of mac address if we're on second port */
- if (hw->bus.func == E1000_FUNC_1)
+ if (!mac_addr_offset && hw->bus.func == E1000_FUNC_1)
hw->mac.perm_addr[5] ^= 1;
for (i = 0; i < ETH_ALEN; i++)
diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h
index 6451578..1bb2052 100644
--- a/drivers/net/e1000e/hw.h
+++ b/drivers/net/e1000e/hw.h
@@ -816,6 +816,7 @@ struct e1000_bus_info {
struct e1000_dev_spec_82571 {
bool laa_is_present;
+ bool alt_mac_addr_is_present;
};
struct e1000_shadow_ram {
diff --git a/drivers/net/e1000e/defines.h b/drivers/net/e1000e/defines.h
index b32ed45..f2175ea 100644
--- a/drivers/net/e1000e/defines.h
+++ b/drivers/net/e1000e/defines.h
@@ -557,6 +557,7 @@
#define NVM_INIT_3GIO_3 0x001A
#define NVM_INIT_CONTROL3_PORT_A 0x0024
#define NVM_CFG 0x0012
+#define NVM_ALT_MAC_ADDR_PTR 0x0037
#define NVM_CHECKSUM_REG 0x003F
#define E1000_NVM_CFG_DONE_PORT_0 0x40000 /* MNG config cycle done */
^ permalink raw reply related
* Re: [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
From: jamal @ 2007-10-23 19:47 UTC (permalink / raw)
To: Masahide NAKAMURA; +Cc: Herbert Xu, David Miller, netdev
In-Reply-To: <200710231608.34661.nakam@linux-ipv6.org>
On Tue, 2007-23-10 at 16:08 +0900, Masahide NAKAMURA wrote:
> Thanks. I would like you to find too much item at my patch
> for the statistics, too.
I am not anywhere close to a machine where i can give you precise
details to this; the one thing that sticks out in my brain cells is the
SPI mismatch. This (in static setups) seemed to be the most common
mistake i saw (other than a mismatched key). Your stats as you have them
now and as is will catch both in one spot - which is a good start.
> This point is one of what I want to hear comment.
> My patch uses "XFRM_MIB_XXX" because I found "LINUX_MIB_XXX" definition at
> include/linux/snmp.h for TCP extended statistics at /proc/net/netstat and
> it does not seem to be defined by any RFC specification.
I thought those were part of some MIB somewhere. Doesnt RFC 4898 cover
them?
In any case, it seems to me to be more accurate to not call them MIB
stats if they are not. This doesnt qualify using the macros, utilities
etc used for MIBs.
> Then I feel it is not so bad to
> use _MIB_ for them. Maybe we have another idea to merge them into LINUX_MIB.
>
> Now we have the following candidates:
>
> (1) my patch XFRM_MIB_INHDRERROR
> (2) some extender XFRM_XXX_INHDRERROR (XXX is requested)
> (3) not-mib extender XFRM_NOTMIB_INHDRERROR
> (4) no extender XFRM_INHDRERROR
> (5) merge linux-mib LINUX_MIB_XFRMINHDRERROR
>
> Comments?
I am very tempted to say #4. And when you push this to be a real MIB
stat then
>
> > 2) Why /proc? Are you going to make these available also via netlink?
>
> Because /proc is easy to see it without any modified application.
> If you want the netlink interface, I can do it as the next step. Do you want it?
Absolutely - it would be much appreciated. And if you dont have time, I
will write and test the user space part extension.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] USB: net: Fix asix read transfer buffer allocations.
From: David Brownell @ 2007-10-23 20:00 UTC (permalink / raw)
To: vbarshak, linux-usb-devel; +Cc: netdev
In-Reply-To: <20071023174018.GA21102@ru.mvista.com>
> From linux-usb-devel-bounces@lists.sourceforge.net Tue Oct 23 10:51:00 2007
> Date: Tue, 23 Oct 2007 21:40:18 +0400
> From: Valentine Barshak <vbarshak@ru.mvista.com>
> To: linux-usb-devel@lists.sourceforge.net
> Cc: netdev@vger.kernel.org
> Subject: [linux-usb-devel] [PATCH] USB: net: Fix asix read transfer buffer
> allocations.
>
> On systems with noncoherent cache, allocating dma buffers
> on the stack for USB IN transfers causes kernel crash,
> because usb map_urb_for_dma() code calls dma_map_single(),
> that invalidates data cache for DMA_FROM_DEVICE transfer direction
> and causes stack data loss if transfer size is less than cache line
> and not cache-line aligned. This patch makes asix usb network
> driver allocate USB IN transfer buffers with kmalloc instead of
> directly using variables on stack. It also sets data parameter to NULL
> for zero-length transfers and uses ETH_ALEN size for allocating MAC
> address buffer.
Looks plausible to me, on a quick scan, but you should CC Dave Hollis
for updates to this drver ... last I knew, he was still maintaining
this code. (Though he's not listed in MAINTAINERS...)
This is missing a Signed-Off-By line ...
> diff -pruN linux-2.6.orig/drivers/net/usb/asix.c linux-2.6/drivers/net/usb/asix.c
> --- linux-2.6.orig/drivers/net/usb/asix.c 2007-10-23 20:52:11.000000000 +0400
> +++ linux-2.6/drivers/net/usb/asix.c 2007-10-23 20:57:38.000000000 +0400
> @@ -568,15 +568,23 @@ static void asix_set_multicast(struct ne
> static int asix_mdio_read(struct net_device *netdev, int phy_id, int loc)
> {
> struct usbnet *dev = netdev_priv(netdev);
> + void *buf;
> u16 res;
>
> + buf = kmalloc(2, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> mutex_lock(&dev->phy_mutex);
> asix_set_sw_mii(dev);
> asix_read_cmd(dev, AX_CMD_READ_MII_REG, phy_id,
> - (__u16)loc, 2, (u16 *)&res);
> + (__u16)loc, 2, buf);
> asix_set_hw_mii(dev);
> mutex_unlock(&dev->phy_mutex);
>
> + res = *((u16 *)buf);
> + kfree(buf);
> +
> devdbg(dev, "asix_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x", phy_id, loc, le16_to_cpu(res & 0xffff));
>
> return le16_to_cpu(res & 0xffff);
> @@ -622,13 +630,22 @@ static void
> asix_get_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
> {
> struct usbnet *dev = netdev_priv(net);
> + void *buf;
> u8 opt;
>
> - if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, &opt) < 0) {
> + buf = kmalloc(1, GFP_KERNEL);
> + if (!buf)
> + return;
> +
> + if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, buf) < 0) {
> wolinfo->supported = 0;
> wolinfo->wolopts = 0;
> + kfree(buf);
> return;
> }
> + opt = *((u8 *)buf);
> + kfree(buf);
> +
> wolinfo->supported = WAKE_PHY | WAKE_MAGIC;
> wolinfo->wolopts = 0;
> if (opt & AX_MONITOR_MODE) {
> @@ -644,7 +661,6 @@ asix_set_wol(struct net_device *net, str
> {
> struct usbnet *dev = netdev_priv(net);
> u8 opt = 0;
> - u8 buf[1];
>
> if (wolinfo->wolopts & WAKE_PHY)
> opt |= AX_MONITOR_LINK;
> @@ -654,7 +670,7 @@ asix_set_wol(struct net_device *net, str
> opt |= AX_MONITOR_MODE;
>
> if (asix_write_cmd(dev, AX_CMD_WRITE_MONITOR_MODE,
> - opt, 0, 0, &buf) < 0)
> + opt, 0, 0, NULL) < 0)
> return -EINVAL;
>
> return 0;
> @@ -820,7 +836,7 @@ static int ax88172_bind(struct usbnet *d
> for (i = 2; i >= 0; i--) {
> if ((ret = asix_write_cmd(dev, AX_CMD_WRITE_GPIOS,
> (gpio_bits >> (i * 8)) & 0xff, 0, 0,
> - buf)) < 0)
> + NULL)) < 0)
> goto out2;
> msleep(5);
> }
> @@ -831,7 +847,7 @@ static int ax88172_bind(struct usbnet *d
> /* Get the MAC address */
> memset(buf, 0, ETH_ALEN);
> if ((ret = asix_read_cmd(dev, AX88172_CMD_READ_NODE_ID,
> - 0, 0, 6, buf)) < 0) {
> + 0, 0, ETH_ALEN, buf)) < 0) {
> dbg("read AX_CMD_READ_NODE_ID failed: %d", ret);
> goto out2;
> }
> @@ -909,7 +925,7 @@ static int ax88772_bind(struct usbnet *d
>
> usbnet_get_endpoints(dev,intf);
>
> - buf = kmalloc(6, GFP_KERNEL);
> + buf = kmalloc(ETH_ALEN, GFP_KERNEL);
> if(!buf) {
> dbg ("Cannot allocate memory for buffer");
> ret = -ENOMEM;
> @@ -923,7 +939,7 @@ static int ax88772_bind(struct usbnet *d
> /* 0x10 is the phy id of the embedded 10/100 ethernet phy */
> embd_phy = ((asix_get_phy_addr(dev) & 0x1f) == 0x10 ? 1 : 0);
> if ((ret = asix_write_cmd(dev, AX_CMD_SW_PHY_SELECT,
> - embd_phy, 0, 0, buf)) < 0) {
> + embd_phy, 0, 0, NULL)) < 0) {
> dbg("Select PHY #1 failed: %d", ret);
> goto out2;
> }
> @@ -998,7 +1014,7 @@ static int ax88772_bind(struct usbnet *d
>
> if ((ret = asix_write_cmd(dev, AX_CMD_WRITE_IPG0,
> AX88772_IPG0_DEFAULT | AX88772_IPG1_DEFAULT,
> - AX88772_IPG2_DEFAULT, 0, buf)) < 0) {
> + AX88772_IPG2_DEFAULT, 0, NULL)) < 0) {
> dbg("Write IPG,IPG1,IPG2 failed: %d", ret);
> goto out2;
> }
> @@ -1202,20 +1218,22 @@ static int ax88178_bind(struct usbnet *d
>
> usbnet_get_endpoints(dev,intf);
>
> - buf = kmalloc(6, GFP_KERNEL);
> + buf = kmalloc(ETH_ALEN, GFP_KERNEL);
> if(!buf) {
> dbg ("Cannot allocate memory for buffer");
> ret = -ENOMEM;
> goto out1;
> }
>
> - eeprom = 0;
> - asix_read_cmd(dev, AX_CMD_READ_GPIOS, 0, 0, 1, &eeprom);
> + memset(buf, 0, ETH_ALEN);
> + asix_read_cmd(dev, AX_CMD_READ_GPIOS, 0, 0, 1, buf);
> + eeprom = *(u8 *)buf;
> dbg("GPIO Status: 0x%04x", eeprom);
>
> asix_write_cmd(dev, AX_CMD_WRITE_ENABLE, 0, 0, 0, NULL);
> - asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x0017, 0, 2, &eeprom);
> + asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x0017, 0, 2, buf);
> asix_write_cmd(dev, AX_CMD_WRITE_DISABLE, 0, 0, 0, NULL);
> + eeprom = *(u16 *)buf;
>
> dbg("EEPROM index 0x17 is 0x%04x", eeprom);
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> linux-usb-devel@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
^ permalink raw reply
* Re: [PATCH RESEND] ip_gre: sendto/recvfrom NBMA address
From: Alexey Kuznetsov @ 2007-10-23 20:20 UTC (permalink / raw)
To: Timo Ter?s; +Cc: Patrick McHardy, davem, netdev
In-Reply-To: <471E19E5.5040509@iki.fi>
Hello!
Me wrote:
> Ack. This is good idea.
>
> Frankly, I was sure ip_gre worked in this way all these years.
> I do not remember any reasons why it was crippled.
>
> The only dubious case is when next hop is set using routing tables.
> But code in ipgre_tunnel_xmit() is ready to accept this situation,
> it checks for zero destination address and fixes it when it is able to.
Nevertheless, it does not work.
The reason is that NOARP arp entries on device with initialized
hard_header are initialized not to all zeros, but to dev->dev_addr.
So that, netxthop from routing tables is ignored and all gre packets
are lost in loopback. Not good.
The problem can be ignored. I am even not sure that someone uses
this feature. Actually, it was not recommended in documentation.
Alternatively, arp.c can be changed to generate 0 addresses instead
of dev->dev_addr. Normally it is equally good, but I am not sure
about possible side effects.
Another thoughts?
Alexey
^ permalink raw reply
* Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.
From: Jeff Garzik @ 2007-10-23 20:40 UTC (permalink / raw)
To: Kok, Auke; +Cc: Adam Jackson, linux-kernel, David Miller, netdev
In-Reply-To: <471E2AD0.1000500@intel.com>
Kok, Auke wrote:
> Adam Jackson wrote:
>> On Tue, 2007-10-23 at 09:18 -0700, Kok, Auke wrote:
>>> Adam Jackson wrote:
>>>> When the EEPROM gets corrupted, you can fix it with ethtool, but only if
>>>> the module loads and creates a network device. But, without this option,
>>>> if the EEPROM is corrupted, the driver will not create a network device.
>>>>
>>>> Signed-off-by: Adam Jackson <ajax@redhat.com>
>>> NAK
>>>
>>> wrong list, not sent to me, and while for e100 I was OK with this patch, for e1000
>>> it really does not make sense to 'just allow' a bad checksum - if your eeprom is
>>> randomly messed up then you cannot just fix it like this anyway.
>> That's strange, I managed to recover an otherwise horked e1000 with it.
>> What should I have done instead?
>
>
> Dump the eeprom and send us a copy, plus any and all information to the card,
> system etc.. I realize that you need the patch to actually create it but the
> danger is that people will start using it *without* troubleshooting the real
> issue. In various systems the eeprom checksum failure is actually due to a
> misconfigured powersavings feature and the checksum is really not bad at all, but
> the card just reports random values.
>
> In any case, this patch should not be merged. We often send it around to users to
> debug their issue in case it involves eeproms, but merging it will just conceal
> the real issue and all of a sudden a flood of people stop reporting *real* issues
> to us.
Sorry, I disagree. Just as with e100, if there is a clear way the user
can recover their setup -- and Adam says his was effective -- I don't
see why we should be denying users the ability to use their own hardware.
Jeff
^ permalink raw reply
* Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.
From: Kok, Auke @ 2007-10-23 21:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Adam Jackson, linux-kernel, David Miller, netdev
In-Reply-To: <471E5C21.8030908@garzik.org>
Jeff Garzik wrote:
> Kok, Auke wrote:
>> Adam Jackson wrote:
>>> On Tue, 2007-10-23 at 09:18 -0700, Kok, Auke wrote:
>>>> Adam Jackson wrote:
>>>>> When the EEPROM gets corrupted, you can fix it with ethtool, but
>>>>> only if
>>>>> the module loads and creates a network device. But, without this
>>>>> option,
>>>>> if the EEPROM is corrupted, the driver will not create a network
>>>>> device.
>>>>>
>>>>> Signed-off-by: Adam Jackson <ajax@redhat.com>
>>>> NAK
>>>>
>>>> wrong list, not sent to me, and while for e100 I was OK with this
>>>> patch, for e1000
>>>> it really does not make sense to 'just allow' a bad checksum - if
>>>> your eeprom is
>>>> randomly messed up then you cannot just fix it like this anyway.
>>> That's strange, I managed to recover an otherwise horked e1000 with it.
>>> What should I have done instead?
>>
>>
>> Dump the eeprom and send us a copy, plus any and all information to
>> the card,
>> system etc.. I realize that you need the patch to actually create it
>> but the
>> danger is that people will start using it *without* troubleshooting
>> the real
>> issue. In various systems the eeprom checksum failure is actually due
>> to a
>> misconfigured powersavings feature and the checksum is really not bad
>> at all, but
>> the card just reports random values.
>>
>> In any case, this patch should not be merged. We often send it around
>> to users to
>> debug their issue in case it involves eeproms, but merging it will
>> just conceal
>> the real issue and all of a sudden a flood of people stop reporting
>> *real* issues
>> to us.
>
>
> Sorry, I disagree. Just as with e100, if there is a clear way the user
> can recover their setup -- and Adam says his was effective -- I don't
> see why we should be denying users the ability to use their own hardware.
That's not even relevant, I already offer the same patch offline to people who
*really* only have a wrong checksum, AFTER we check the contents of their eeprom
for them.
We help everyone out, and if you merge this patch you will prevent users from
getting to us for support in the first place.
I realize that we should probably document the "bad eeprom checksum" case more
decently but I think merging this patch is a bad idea for the *user* in all cases.
You completely bypass the fact that e100 eeproms and e1000 eeproms are completely
different beasts as well, one can be practically empty in all cases (e100), the
other one every bit counts (most e1000's), which is an unfair representation and
falsely tells the user that he can just do this without any information or
disclaimer as to what he may expect afterwards.
Auke
^ permalink raw reply
* Please pull bug-fixes branch of linux-2.6-mv643xx_eth.git
From: Dale Farnsworth @ 2007-10-23 21:13 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
The following changes since commit e8b8c977734193adedf2b0f607d6252c78e86394:
Linus Torvalds (1):
Revert "kconfig: tristate choices with mixed tristate and boolean values"
are available in the git repository at:
git://farnsworth.org/dale/linux-2.6-mv643xx_eth.git bug-fixes
Dale Farnsworth (1):
mv643xx_eth: Hook up mv643xx_get_sset_count
drivers/net/mv643xx_eth.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
It may be also viewed at:
http://www.farnsworth.org/git?p=dale/linux-2.6-mv643xx_eth.git;a=shortlog;h=bug-fixes
Thanks,
-Dale
Here is the single commit:
Author: Dale Farnsworth <dale@farnsworth.org>
Date: Sat Oct 20 12:16:27 2007 -0700
mv643xx_eth: Hook up mv643xx_get_sset_count
Commit b9f2c044 replaced mv643xx_get_stats_count() with
mv643xx_get_sset_count(), but forgot to hook it up.
drivers/net/mv643xx_eth.c:2678: warning: mv643xx_get_sset_count defined but not used
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 84f2d63..54e4828 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2742,6 +2742,7 @@ static const struct ethtool_ops mv643xx_ethtool_ops = {
.get_drvinfo = mv643xx_get_drvinfo,
.get_link = mv643xx_eth_get_link,
.set_sg = ethtool_op_set_sg,
+ .get_sset_count = mv643xx_get_sset_count,
.get_ethtool_stats = mv643xx_get_ethtool_stats,
.get_strings = mv643xx_get_strings,
.nway_reset = mv643xx_eth_nway_restart,
^ permalink raw reply related
* Please pull features branch of linux-2.6-mv643xx_eth.git
From: Dale Farnsworth @ 2007-10-23 21:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
The following changes since commit e8b8c977734193adedf2b0f607d6252c78e86394:
Linus Torvalds (1):
Revert "kconfig: tristate choices with mixed tristate and boolean values"
are available in the git repository at:
git://farnsworth.org/dale/linux-2.6-mv643xx_eth.git features
Dale Farnsworth (1):
mv643xx_eth: Remove obsolete checksum offload comment
Lennert Buytenhek (9):
mv643xx_eth: Split off mv643xx_eth platform device data
mv643xx_eth: Move ethernet register definitions into private header
mv643xx_eth: Disable RX/TX byte swapping on little-endian systems
mv643xx_eth: Enable use on Orion platforms
mv643xx_eth: Remove SHARED_REGS register address bias
mv643xx_eth: Remove MV643XX_ETH_ register prefix
mv643xx_eth: Clean up mv643xx_eth.h
mv643xx_eth: Remove unused register defines
mv643xx_eth: Merge drivers/net/mv643xx_eth.h into mv643xx_eth.c
drivers/net/Kconfig | 13 +-
drivers/net/mv643xx_eth.c | 806 +++++++++++++++++++++++++++++++++++--------
drivers/net/mv643xx_eth.h | 370 --------------------
include/linux/mv643xx.h | 328 +------------------
include/linux/mv643xx_eth.h | 31 ++
5 files changed, 709 insertions(+), 839 deletions(-)
delete mode 100644 drivers/net/mv643xx_eth.h
create mode 100644 include/linux/mv643xx_eth.h
It may also be viewed at:
http://www.farnsworth.org/git?p=dale/linux-2.6-mv643xx_eth.git;a=shortlog;h=features
Of course, it would be nice to get this into 2.6.24, but as a feature
addition, it could wait.
Thanks,
-Dale
^ permalink raw reply
* Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.
From: Dave Jones @ 2007-10-23 21:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Kok, Auke, Adam Jackson, linux-kernel, David Miller, netdev
In-Reply-To: <471E5C21.8030908@garzik.org>
On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote:
> > In any case, this patch should not be merged. We often send it around to users to
> > debug their issue in case it involves eeproms, but merging it will just conceal
> > the real issue and all of a sudden a flood of people stop reporting *real* issues
> > to us.
>
> Sorry, I disagree. Just as with e100, if there is a clear way the user
> can recover their setup -- and Adam says his was effective -- I don't
> see why we should be denying users the ability to use their own hardware.
Indeed. This is a common enough problem that not including it causes more pain
than its worth. I have two affected boxes myself that I actually thought
the hardware was dead before I tried ajax's patch.
People aren't going to report this as a bug. They aren't going to try out patches,
they're going to do what I did and stick another network card in the box and
go on with life.
Our users deserve better than this.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.
From: Alan Cox @ 2007-10-23 21:38 UTC (permalink / raw)
To: Dave Jones
Cc: Jeff Garzik, Kok, Auke, Adam Jackson, linux-kernel, David Miller,
netdev
In-Reply-To: <20071023212026.GF7793@redhat.com>
> People aren't going to report this as a bug. They aren't going to try out patches,
> they're going to do what I did and stick another network card in the box and
> go on with life.
>
> Our users deserve better than this.
Agreed. By all means warn people, or give them a 1-800 Intel number to
phone, but they should be able to continue as well.
Alan
^ permalink raw reply
* Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.
From: David Miller @ 2007-10-23 21:48 UTC (permalink / raw)
To: jeff; +Cc: auke-jan.h.kok, ajax, linux-kernel, netdev
In-Reply-To: <471E5C21.8030908@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Tue, 23 Oct 2007 16:40:01 -0400
> Sorry, I disagree. Just as with e100, if there is a clear way the user
> can recover their setup -- and Adam says his was effective -- I don't
> see why we should be denying users the ability to use their own hardware.
I'd like to second these sentiments.
Just because you can come up with cases where using a wrong
eeprom would fail, does not mean the facility should not be
provided at all.
^ permalink raw reply
* Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.
From: David Miller @ 2007-10-23 21:51 UTC (permalink / raw)
To: auke-jan.h.kok; +Cc: jeff, ajax, linux-kernel, netdev
In-Reply-To: <471E6121.9010008@intel.com>
From: "Kok, Auke" <auke-jan.h.kok@intel.com>
Date: Tue, 23 Oct 2007 14:01:21 -0700
> We help everyone out, and if you merge this patch you will prevent
> users from getting to us for support in the first place.
If using the bad eeprom has to be explicitly enabled by the user, your
argument holds no water. We just need to make sure the patch does
that.
^ permalink raw reply
* Re: [PATCH] Add eeprom_bad_csum_allow module option to e1000.
From: David Miller @ 2007-10-23 21:53 UTC (permalink / raw)
To: davej; +Cc: jeff, auke-jan.h.kok, ajax, linux-kernel, netdev
In-Reply-To: <20071023212026.GF7793@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Tue, 23 Oct 2007 17:20:26 -0400
> Indeed. This is a common enough problem that not including it causes
> more pain than its worth. I have two affected boxes myself that I
> actually thought the hardware was dead before I tried ajax's patch.
>
> People aren't going to report this as a bug. They aren't going to
> try out patches, they're going to do what I did and stick another
> network card in the box and go on with life.
>
> Our users deserve better than this.
Seconded. The resistence to this patch is just flat-out rediculious,
just like it was in the e100 case.
And I think all of this "e1000 is different!" talk is merely a
scarecrow for the fact that Intel simply doesn't want this patch
merged for some other reason.
^ permalink raw reply
* Re: [VLAN]: MAINTAINERS update
From: Ben Greear @ 2007-10-23 22:17 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, Linux Netdev List
In-Reply-To: <471E2362.7040104@trash.net>
Patrick McHardy wrote:
>
> ------------------------------------------------------------------------
>
> [VLAN]: MAINTAINERS update
>
> Ben stepped down from VLAN maintainership due to a lack of time,
> add myself as new maintainer.
>
ACK. Thanks Patrick!
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox