* Re: [PATCH] seastar - SeaStar Ethernet driver (review comments addressed)
From: Stephen Hemminger @ 2010-02-03 2:07 UTC (permalink / raw)
To: Joe Perches
Cc: Kevin Pedretti, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1265162522.1945.148.camel@Joe-Laptop.home>
On Tue, 02 Feb 2010 18:02:01 -0800
Joe Perches <joe@perches.com> wrote:
> Presumably SeaStar doesn't support multicast either, so maybe:
> if (dest_low_mac & 0x01)
Why not:
if (is_multicast_ether_addr(ethdr->h_dest))
...
^ permalink raw reply
* KS8851: Performance Improvement
From: Abraham Arce @ 2010-02-03 2:25 UTC (permalink / raw)
To: netdev
Hi,
I am working with ks8851 snl ethernet controller attached to a OMAP4
board and did a nuttcp benchmark, the result is
12.9375 MB / 10.49 sec = 10.3491 Mbps 1 %TX 0 %RX
According to a previous post from Ha, Tristram he did get ~11 Mbps
with a Beagle Zippy combo board.
Are there any pending changes at the driver level so performance can
be increased ~100 Mbps? do we have any hardware limitation? any extra
SPI specifications?
Thanks for your comments...
Best Regards
Abraham
^ permalink raw reply
* linux-next: manual merge of the trivial tree with the net tree
From: Stephen Rothwell @ 2010-02-03 2:30 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-next, linux-kernel, Lennart Sorensen, David Miller, netdev,
Daniel Mack
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
drivers/net/ppp_generic.c between commit
fa44a73cc766c7f3bac71a66d564e0049b800325 ("ppp_generic.c severly
whitespace damanged by 9c705260feea6ae329bc6b6d5f6d2ef0227eda0a") from
the net tree and commit 09e1aa00f106a476f5b90d94fc0139544bbded75
("tree-wide: fix 'lenght' typo in comments and code") from the trivial
tree.
I fixed it up (by using the trivial tree version) and can carry the fix
as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] sky2: receive dma mapping error handling
From: Michael Breuer @ 2010-02-03 4:07 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jarek Poplawski, David Miller, akpm, flyboy, linux-kernel, netdev,
Michael Chan, Don Fry, Francois Romieu, Matt Carlson
In-Reply-To: <20100201102018.7b597992@nehalam>
On 2/1/2010 1:20 PM, Stephen Hemminger wrote:
> This fixes the fact that re->flags is always zero without causing
> other confusion.
>
> --- a/drivers/net/sky2.c 2010-02-01 10:07:42.676296236 -0800
> +++ b/drivers/net/sky2.c 2010-02-01 10:18:12.575044064 -0800
> @@ -1025,11 +1025,8 @@ static void sky2_prefetch_init(struct sk
> static inline struct sky2_tx_le *get_tx_le(struct sky2_port *sky2, u16 *slot)
> {
> struct sky2_tx_le *le = sky2->tx_le + *slot;
> - struct tx_ring_info *re = sky2->tx_ring + *slot;
>
> *slot = RING_NEXT(*slot, sky2->tx_ring_size);
> - re->flags = 0;
> - re->skb = NULL;
> le->ctrl = 0;
> return le;
> }
> @@ -1622,8 +1619,7 @@ static unsigned tx_le_req(const struct s
> return count;
> }
>
> -static void sky2_tx_unmap(struct pci_dev *pdev,
> - const struct tx_ring_info *re)
> +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re)
> {
> if (re->flags& TX_MAP_SINGLE)
> pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr),
> @@ -1633,6 +1629,7 @@ static void sky2_tx_unmap(struct pci_dev
> pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr),
> pci_unmap_len(re, maplen),
> PCI_DMA_TODEVICE);
> + re->flags = 0;
> }
>
> /*
> @@ -1839,6 +1836,7 @@ static void sky2_tx_complete(struct sky2
> dev->stats.tx_packets++;
> dev->stats.tx_bytes += skb->len;
>
> + re->skb = NULL;
> dev_kfree_skb_any(skb);
>
> sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Just a brief update - this has been up and stable for about 32 hours -
I've been periodically generating load on the system. No kernel errors
of any sort so far. Actually, in retrospect, I believe the dma issue was
triggering other bad things - including an rcu lockup (patched in tip -
sched.c).
Just as an FYI - (and this should probably be in a new thread) I am
seeing an large number (>9,000,000) of dropped rx packets, however at
this time I see no errors resulting from that (on this or client
machines). As the # of dropped packets hasn't incremented at any time I
was observing things, I can't say what this is about. Probably nothing,
but I'll see if I can track down what is going on. I did see some of
this earlier on while troubleshooting the sky2 issues that now seem
resolved. Quick crosschecking of other machines do not show high error
or retransmission rates. I'm also not seeing any evidence of other
errors (no errors reported by ifconfig, or ethtool, or printk (debug is
enabled).
I'm wondering whether these dropped packets are due mostly to hitting
GMR_FS_RX_OK in sky2_receive. I'm also guessing that the high numbers of
this that I'm seeing is an artifact of being able to pump more traffic
through with the above patch. Given the description of the status code
in sky2.h (receive ok) I'm wondering whether a) this should be reported
as dropped, b) whether resubmit is necessary, c) whether it's possible
that eth1 events coinciding with eth0 events are the cause and d)
whether or not there's another issue entirely.
^ permalink raw reply
* [RFC Patch] net: reserve ports for applications using fixed port numbers
From: Amerigo Wang @ 2010-02-03 4:30 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Eric Dumazet, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Neil Horman,
linux-sctp-u79uwXL29TY76Z2rM5mHXA, Amerigo Wang, David Miller
This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports,
it can be used like ip_local_port_range, but this is used to
reserve ports for third-party applications which use fixed
port numbers within ip_local_port_range.
This only affects the applications which call socket functions
like bind(2) with port number 0, to prevent the kernel getting the ports
within the specified range for them. For applications which use fixed
port number, it will have no effects.
Any comments are welcome.
Signed-off-by: WANG Cong <amwang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Cc: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Cc: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index cc9b594..8248fc6 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -1979,6 +1979,8 @@ retry:
/* FIXME: add proper port randomization per like inet_csk_get_port */
do {
ret = idr_get_new_above(ps, bind_list, next_port, &port);
+ if (inet_is_reserved_local_port(port))
+ ret = -EAGAIN;
} while ((ret == -EAGAIN) && idr_pre_get(ps, GFP_KERNEL));
if (ret)
@@ -2997,10 +2999,13 @@ static int __init cma_init(void)
{
int ret, low, high, remaining;
- get_random_bytes(&next_port, sizeof next_port);
inet_get_local_port_range(&low, &high);
+again:
+ get_random_bytes(&next_port, sizeof next_port);
remaining = (high - low) + 1;
next_port = ((unsigned int) next_port % remaining) + low;
+ if (inet_is_reserved_local_port(next_port))
+ goto again;
cma_wq = create_singlethread_workqueue("rdma_cm");
if (!cma_wq)
diff --git a/include/net/ip.h b/include/net/ip.h
index fb63371..f70acad 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -181,8 +181,10 @@ extern void snmp_mib_free(void *ptr[2]);
extern struct local_ports {
seqlock_t lock;
int range[2];
-} sysctl_local_ports;
+} sysctl_local_ports, sysctl_local_reserved_ports;
extern void inet_get_local_port_range(int *low, int *high);
+extern void inet_get_local_reserved_ports(int *from, int *to);
+extern int inet_is_reserved_local_port(int port);
extern int sysctl_ip_default_ttl;
extern int sysctl_ip_nonlocal_bind;
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index ee16475..ee13e48 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -37,6 +37,11 @@ struct local_ports sysctl_local_ports __read_mostly = {
.range = { 32768, 61000 },
};
+struct local_ports sysctl_local_reserved_ports __read_mostly = {
+ .lock = SEQLOCK_UNLOCKED,
+ .range = { 0, 0 },
+};
+
void inet_get_local_port_range(int *low, int *high)
{
unsigned seq;
@@ -49,6 +54,28 @@ void inet_get_local_port_range(int *low, int *high)
}
EXPORT_SYMBOL(inet_get_local_port_range);
+void inet_get_local_reserved_ports(int *from, int *to)
+{
+ unsigned int seq;
+ do {
+ seq = read_seqbegin(&sysctl_local_reserved_ports.lock);
+
+ *from = sysctl_local_reserved_ports.range[0];
+ *to = sysctl_local_reserved_ports.range[1];
+ } while (read_seqretry(&sysctl_local_reserved_ports.lock, seq));
+}
+
+int inet_is_reserved_local_port(int port)
+{
+ int min, max;
+
+ inet_get_local_reserved_ports(&min, &max);
+ if (min && max)
+ return (port >= min && port <= max);
+ return 0;
+}
+EXPORT_SYMBOL(inet_is_reserved_local_port);
+
int inet_csk_bind_conflict(const struct sock *sk,
const struct inet_bind_bucket *tb)
{
@@ -105,6 +132,8 @@ again:
inet_get_local_port_range(&low, &high);
remaining = (high - low) + 1;
smallest_rover = rover = net_random() % remaining + low;
+ if (inet_is_reserved_local_port(rover))
+ goto again;
smallest_size = -1;
do {
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 2b79377..d3e160a 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -456,6 +456,8 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row,
local_bh_disable();
for (i = 1; i <= remaining; i++) {
port = low + (i + offset) % remaining;
+ if (inet_is_reserved_local_port(port))
+ continue;
head = &hinfo->bhash[inet_bhashfn(net, port,
hinfo->bhash_size)];
spin_lock(&head->lock);
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 7e3712c..9adf1a5 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -23,6 +23,7 @@
static int zero;
static int tcp_retr1_max = 255;
+static int ip_local_reserved_ports_min[] = {0, 0 };
static int ip_local_port_range_min[] = { 1, 1 };
static int ip_local_port_range_max[] = { 65535, 65535 };
@@ -63,6 +64,51 @@ static int ipv4_local_port_range(ctl_table *table, int write,
return ret;
}
+static void set_reserved_port_range(int range[2])
+{
+ write_seqlock(&sysctl_local_reserved_ports.lock);
+ sysctl_local_reserved_ports.range[0] = range[0];
+ sysctl_local_reserved_ports.range[1] = range[1];
+ write_sequnlock(&sysctl_local_reserved_ports.lock);
+}
+
+static int ipv4_local_reserved_ports(ctl_table *table, int write,
+ void __user *buffer,
+ size_t *lenp, loff_t *ppos)
+{
+ int ret;
+ int range[2];
+ int reserved_range[2];
+ ctl_table tmp = {
+ .data = &reserved_range,
+ .maxlen = sizeof(reserved_range),
+ .mode = table->mode,
+ .extra1 = &ip_local_reserved_ports_min,
+ .extra2 = &ip_local_port_range_max,
+ };
+
+ inet_get_local_reserved_ports(reserved_range, reserved_range+1);
+ ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
+
+ if (write && ret == 0) {
+ inet_get_local_port_range(range, range + 1);
+ if (!reserved_range[0] && !reserved_range[1]) {
+ set_reserved_port_range(reserved_range);
+ } else {
+ if (reserved_range[1] < reserved_range[0])
+ ret = -EINVAL;
+ else if (reserved_range[0] < range[0])
+ ret = -EINVAL;
+ else if (reserved_range[1] > range[1])
+ ret = -EINVAL;
+ else
+ set_reserved_port_range(reserved_range);
+ }
+ }
+
+ return ret;
+}
+
static int proc_tcp_congestion_control(ctl_table *ctl, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
@@ -298,6 +344,13 @@ static struct ctl_table ipv4_table[] = {
.mode = 0644,
.proc_handler = ipv4_local_port_range,
},
+ {
+ .procname = "ip_local_reserved_ports",
+ .data = &sysctl_local_reserved_ports.range,
+ .maxlen = sizeof(sysctl_local_reserved_ports.range),
+ .mode = 0644,
+ .proc_handler = ipv4_local_reserved_ports,
+ },
#ifdef CONFIG_IP_MULTICAST
{
.procname = "igmp_max_memberships",
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index f0126fd..83045ca 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -210,8 +210,11 @@ int udp_lib_get_port(struct sock *sk, unsigned short snum,
inet_get_local_port_range(&low, &high);
remaining = (high - low) + 1;
+again:
rand = net_random();
first = (((u64)rand * remaining) >> 32) + low;
+ if (inet_is_reserved_local_port(first))
+ goto again;
/*
* force rand to be an odd multiple of UDP_HTABLE_SIZE
*/
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 67fdac9..d685141 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -5432,6 +5432,8 @@ static long sctp_get_port_local(struct sock *sk, union sctp_addr *addr)
rover++;
if ((rover < low) || (rover > high))
rover = low;
+ if (inet_is_reserved_local_port(rover))
+ continue;
index = sctp_phashfn(rover);
head = &sctp_port_hashtable[index];
sctp_spin_lock(&head->lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC Patch] net: reserve ports for applications using fixed port numbers
From: Eric Dumazet @ 2010-02-03 4:39 UTC (permalink / raw)
To: Amerigo Wang
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Neil Horman, linux-sctp-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <20100203043332.3817.27932.sendpatchset-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
Le mardi 02 février 2010 à 23:30 -0500, Amerigo Wang a écrit :
> This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports,
> it can be used like ip_local_port_range, but this is used to
> reserve ports for third-party applications which use fixed
> port numbers within ip_local_port_range.
>
> This only affects the applications which call socket functions
> like bind(2) with port number 0, to prevent the kernel getting the ports
> within the specified range for them. For applications which use fixed
> port number, it will have no effects.
>
> Any comments are welcome.
>
> Signed-off-by: WANG Cong <amwang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Cc: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> .procname = "igmp_max_memberships",
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index f0126fd..83045ca 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -210,8 +210,11 @@ int udp_lib_get_port(struct sock *sk, unsigned short snum,
> inet_get_local_port_range(&low, &high);
> remaining = (high - low) + 1;
>
> +again:
> rand = net_random();
> first = (((u64)rand * remaining) >> 32) + low;
> + if (inet_is_reserved_local_port(first))
> + goto again;
> /*
> * force rand to be an odd multiple of UDP_HTABLE_SIZE
> */
Unless I misread the patch, you are checking only the 'first' port that
udp_lib_get_port() chose.
I would use inet_get_local_reserved_ports(&min_res, &max_res);
and check every port that we chose in the loop to avoid it if necessary.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC Patch] net: reserve ports for applications using fixed port numbers
From: Cong Wang @ 2010-02-03 5:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Neil Horman, linux-sctp-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <1265171993.3274.3.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le mardi 02 février 2010 à 23:30 -0500, Amerigo Wang a écrit :
>> This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports,
>> it can be used like ip_local_port_range, but this is used to
>> reserve ports for third-party applications which use fixed
>> port numbers within ip_local_port_range.
>>
>> This only affects the applications which call socket functions
>> like bind(2) with port number 0, to prevent the kernel getting the ports
>> within the specified range for them. For applications which use fixed
>> port number, it will have no effects.
>>
>> Any comments are welcome.
>>
>> Signed-off-by: WANG Cong <amwang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>> Cc: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
>> Cc: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
>> .procname = "igmp_max_memberships",
>> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
>> index f0126fd..83045ca 100644
>> --- a/net/ipv4/udp.c
>> +++ b/net/ipv4/udp.c
>> @@ -210,8 +210,11 @@ int udp_lib_get_port(struct sock *sk, unsigned short snum,
>> inet_get_local_port_range(&low, &high);
>> remaining = (high - low) + 1;
>>
>> +again:
>> rand = net_random();
>> first = (((u64)rand * remaining) >> 32) + low;
>> + if (inet_is_reserved_local_port(first))
>> + goto again;
>> /*
>> * force rand to be an odd multiple of UDP_HTABLE_SIZE
>> */
>
> Unless I misread the patch, you are checking only the 'first' port that
> udp_lib_get_port() chose.
>
> I would use inet_get_local_reserved_ports(&min_res, &max_res);
> and check every port that we chose in the loop to avoid it if necessary.
>
Hmm, right, 'first' is used to do iteration, but I did missed 'last'.
Thanks! I will fix this in the next update.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv2 08/11] fec: fix uninitialized rx buffer usage
From: Amit Kucheria @ 2010-02-03 5:16 UTC (permalink / raw)
To: List Linux Kernel
Cc: linux, Dinh.Nguyen, netdev, s.hauer, grant.likely, Rob Herring,
valentin.longchamp, daniel, bryan.wu, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1265173480.git.amit.kucheria@canonical.com>
From: Rob Herring <r.herring@freescale.com>
The fec driver was enabling receive buffer descriptor without allocating
the buffers. Make sure the buffer descriptors are initialized to not
start receiving packets.
Open also calls fec_restart after the rx buffers are allocated. With the code
in fec_restart, it zeroes out the buffer descriptors that have just been
setup.
Signed-off-by: Rob Herring <r.herring@freescale.com>
Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
drivers/net/fec.c | 57 +++++++++++++++++++++++++++--------------------------
1 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 16a1d58..9a8743d 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -1658,6 +1658,7 @@ static int fec_enet_init(struct net_device *dev, int index)
{
struct fec_enet_private *fep = netdev_priv(dev);
struct bufdesc *cbd_base;
+ struct bufdesc *bdp;
int i;
/* Allocate memory for buffer descriptors. */
@@ -1710,6 +1711,34 @@ static int fec_enet_init(struct net_device *dev, int index)
/* Set MII speed to 2.5 MHz */
fep->phy_speed = ((((clk_get_rate(fep->clk) / 2 + 4999999)
/ 2500000) / 2) & 0x3F) << 1;
+
+ /* Initialize the receive buffer descriptors. */
+ bdp = fep->rx_bd_base;
+ for (i = 0; i < RX_RING_SIZE; i++) {
+
+ /* Initialize the BD for every fragment in the page. */
+ bdp->cbd_sc = 0;
+ bdp++;
+ }
+
+ /* Set the last buffer to wrap */
+ bdp--;
+ bdp->cbd_sc |= BD_SC_WRAP;
+
+ /* ...and the same for transmit */
+ bdp = fep->tx_bd_base;
+ for (i = 0; i < TX_RING_SIZE; i++) {
+
+ /* Initialize the BD for every fragment in the page. */
+ bdp->cbd_sc = 0;
+ bdp->cbd_bufaddr = 0;
+ bdp++;
+ }
+
+ /* Set the last buffer to wrap */
+ bdp--;
+ bdp->cbd_sc |= BD_SC_WRAP;
+
fec_restart(dev, 0);
/* Queue up command to detect the PHY and initialize the
@@ -1730,7 +1759,6 @@ static void
fec_restart(struct net_device *dev, int duplex)
{
struct fec_enet_private *fep = netdev_priv(dev);
- struct bufdesc *bdp;
int i;
/* Whack a reset. We should wait for this. */
@@ -1768,33 +1796,6 @@ fec_restart(struct net_device *dev, int duplex)
}
}
- /* Initialize the receive buffer descriptors. */
- bdp = fep->rx_bd_base;
- for (i = 0; i < RX_RING_SIZE; i++) {
-
- /* Initialize the BD for every fragment in the page. */
- bdp->cbd_sc = BD_ENET_RX_EMPTY;
- bdp++;
- }
-
- /* Set the last buffer to wrap */
- bdp--;
- bdp->cbd_sc |= BD_SC_WRAP;
-
- /* ...and the same for transmit */
- bdp = fep->tx_bd_base;
- for (i = 0; i < TX_RING_SIZE; i++) {
-
- /* Initialize the BD for every fragment in the page. */
- bdp->cbd_sc = 0;
- bdp->cbd_bufaddr = 0;
- bdp++;
- }
-
- /* Set the last buffer to wrap */
- bdp--;
- bdp->cbd_sc |= BD_SC_WRAP;
-
/* Enable MII mode */
if (duplex) {
/* MII enable / FD enable */
--
1.6.3.3
^ permalink raw reply related
* [PATCHv2 09/11] fec: Add LAN8700 phy support
From: Amit Kucheria @ 2010-02-03 5:16 UTC (permalink / raw)
To: List Linux Kernel
Cc: David S. Miller, netdev, linux-arm-kernel, linux, s.hauer,
valentin.longchamp, daniel, grant.likely, Dinh.Nguyen, r.herring,
bryan.wu
In-Reply-To: <cover.1265173480.git.amit.kucheria@canonical.com>
The i.MX51 babbage board has a FEC ethernet controller with this phy.
In the long term we should resurrect the phylib patches for fec.
Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
drivers/net/fec.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 9a8743d..5d0d332 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -1128,6 +1128,26 @@ static phy_info_t phy_info_dp83848= {
},
};
+static phy_info_t phy_info_lan8700 = {
+ 0x0007C0C,
+ "LAN8700",
+ (const phy_cmd_t []) { /* config */
+ { mk_mii_read(MII_REG_CR), mii_parse_cr },
+ { mk_mii_read(MII_REG_ANAR), mii_parse_anar },
+ { mk_mii_end, }
+ },
+ (const phy_cmd_t []) { /* startup */
+ { mk_mii_write(MII_REG_CR, 0x1200), NULL }, /* autonegotiate */
+ { mk_mii_read(MII_REG_SR), mii_parse_sr },
+ { mk_mii_end, }
+ },
+ (const phy_cmd_t []) { /* act_int */
+ { mk_mii_end, }
+ },
+ (const phy_cmd_t []) { /* shutdown */
+ { mk_mii_end, }
+ },
+};
/* ------------------------------------------------------------------------- */
static phy_info_t const * const phy_info[] = {
@@ -1137,6 +1157,7 @@ static phy_info_t const * const phy_info[] = {
&phy_info_am79c874,
&phy_info_ks8721bl,
&phy_info_dp83848,
+ &phy_info_lan8700,
NULL
};
--
1.6.3.3
^ permalink raw reply related
* [PATCHv2 10/11] fec: Add ARCH_MX5 as a dependency
From: Amit Kucheria @ 2010-02-03 5:16 UTC (permalink / raw)
To: List Linux Kernel
Cc: David S. Miller, netdev, linux-arm-kernel, linux, s.hauer,
valentin.longchamp, daniel, grant.likely, Dinh.Nguyen, r.herring,
bryan.wu
In-Reply-To: <cover.1265173480.git.amit.kucheria@canonical.com>
i.MX51 babbage board has a FEC ethernet controller
Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
drivers/net/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index dd9a09c..515658e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1883,7 +1883,8 @@ config 68360_ENET
config FEC
bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
- depends on M523x || M527x || M5272 || M528x || M520x || M532x || MACH_MX27 || ARCH_MX35 || ARCH_MX25
+ depends on M523x || M527x || M5272 || M528x || M520x || M532x || \
+ MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5
help
Say Y here if you want to use the built-in 10/100 Fast ethernet
controller on some Motorola ColdFire and Freescale i.MX processors.
--
1.6.3.3
^ permalink raw reply related
* linux-next: manual merge of the percpu tree with the net tree
From: Stephen Rothwell @ 2010-02-03 5:38 UTC (permalink / raw)
To: Tejun Heo, Rusty Russell, Christoph Lameter, Ingo Molnar
Cc: linux-next, linux-kernel, Alexey Dobriyan, David Miller, netdev,
Linus, Andrew Morton
Hi all,
Today's linux-next merge of the percpu tree got a conflict in
net/ipv6/proc.c between commit 5833929cc2ad2b3064b4fac8c44e293972d240d8
("net: constify MIB name tables") from the net tree and commit
d3f5fa4075414c7754126fbdc7c8fbd3906db7c8 ("percpu: add __percpu sparse
annotations to net") from the percpu tree.
I fixed it up (see below) and can carry the fix as necessary.
Maybe you guys could send Linus a simple one line patch for v2.6.33 that
adds
#define __percpu
to include/linux/compiler.h (unconditionally) and then farm out the
patches that add the __percpu annotations to other maintainers.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/ipv6/proc.c
index bfe2598,e3744d1..0000000
--- a/net/ipv6/proc.c
+++ b/net/ipv6/proc.c
@@@ -170,8 -170,9 +170,8 @@@ static void snmp6_seq_show_icmpv6msg(st
return;
}
- static void snmp6_seq_show_item(struct seq_file *seq, void **mib,
-static inline void
-snmp6_seq_show_item(struct seq_file *seq, void __percpu **mib,
- struct snmp_mib *itemlist)
++static void snmp6_seq_show_item(struct seq_file *seq, void __percpu **mib,
+ const struct snmp_mib *itemlist)
{
int i;
for (i=0; itemlist[i].name; i++)
^ permalink raw reply
* Re: linux-next: manual merge of the percpu tree with the net tree
From: Tejun Heo @ 2010-02-03 6:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Rusty Russell, Christoph Lameter, Ingo Molnar, linux-next,
linux-kernel, Alexey Dobriyan, David Miller, netdev, Linus,
Andrew Morton
In-Reply-To: <20100203163803.820597d1.sfr@canb.auug.org.au>
Hello,
On 02/03/2010 02:38 PM, Stephen Rothwell wrote:
> Today's linux-next merge of the percpu tree got a conflict in
> net/ipv6/proc.c between commit 5833929cc2ad2b3064b4fac8c44e293972d240d8
> ("net: constify MIB name tables") from the net tree and commit
> d3f5fa4075414c7754126fbdc7c8fbd3906db7c8 ("percpu: add __percpu sparse
> annotations to net") from the percpu tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
>
> Maybe you guys could send Linus a simple one line patch for v2.6.33 that
> adds
>
> #define __percpu
>
> to include/linux/compiler.h (unconditionally) and then farm out the
> patches that add the __percpu annotations to other maintainers.
How about just adding dummy #define __percpu in each tree? I don't
think git will have much problem merging them.
--
tejun
^ permalink raw reply
* Re: [PATCH v2 1/1] dccp: fix auto-loading of dccp(_probe)
From: Gerrit Renker @ 2010-02-03 6:16 UTC (permalink / raw)
To: Neil Horman; +Cc: davem, dccp, netdev
In-Reply-To: <20100202153929.GA12697@hmsreliant.think-freely.org>
Hi Neil,
I have tested your patch, it works fine thanks to the repeated execution of the macro
argument. I have reformatted it, removing the inner parentheses, which I think is
justified since macros copy their arguments in full. Also converted your email to a
drafted commit message. Due to this, have not copied your signed-off -- if you are
ok, please add, this should be submitted asap.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Patch v2 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
dccp: fix loading of dccp_probe
This fixes commit (38ff3e6bb987ec583268da8eb22628293095d43b) ("dccp_probe:
Fix module load dependencies between dccp and dccp_probe", from 15 Jan).
It fixes the construction of the first argument of try_then_request_module(),
where only valid return codes from the first argument should be returned.
What we do now is assign the result of register_jprobe() to ret, without
the side effect of the comparison.
Acked-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/probe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -161,8 +161,8 @@ static __init int dccpprobe_init(void)
if (!proc_net_fops_create(&init_net, procname, S_IRUSR, &dccpprobe_fops))
goto err0;
- ret = try_then_request_module((register_jprobe(&dccp_send_probe) == 0),
- "dccp");
+ try_then_request_module((ret = register_jprobe(&dccp_send_probe)) == 0,
+ "dccp");
if (ret)
goto err1;
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: mcp251x: Move to threaded interrupts instead of workqueues.
From: christian pellegrin @ 2010-02-03 7:23 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: socketcan-core, netdev
In-Reply-To: <4B67F7B3.8060509@grandegger.com>
On Tue, Feb 2, 2010 at 11:00 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Hi Christian,
>
Hi,
>
> The MERR should not come when the device is in bus-off. Nevertheless, it
yes, sorry it's in error-passive state!
> space via error messages. For exactly that reason we do not disable bus
> errors on other CAN controllers, like the SJA1000 or the AT91, even if
> they may produce high load. But we may discuss some generic interface to
> disable bus-errors somehow, maybe configurable via ctrlmode. What do you
> think?
The transition of CAN error states is handled by the ERR interrupt,
the MERR means "message error" and is fired when a transmission or
receptions leads to an error. The problems with this interrupt are:
1) it's impossible to know if it was a TX or RX error.
2) if the error is accounted (for example) to TX the user will see
ton's of TX errors even if he sent just one packet (this happens in
error-passive mode for example) which could be confusing.
3) I guess that microchip has a specific use of this interrupt in mind
which explains it's drawbacks. From the data sheet:
"7.4 Message Error Interrupt
When an error occurs during transmission or reception
of a message the message error flag (CAN-
INTF.MERRF) will be set and, if the CANINTE.MERRE
bit is set, an interrupt will be generated on the INT pin.
This is intended to be used to facilitate baud rate deter-
mination when used in conjunction with listen-only
mode."
I think that a much more useful information to somehow export to the
user are the TEC and REC counters. I checked other CAN drivers but no
one seems to do this. Anyway let me know what do you think so I could
prepere the final patch now that OSM problems where sorted out.
--
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: mcp251x: Move to threaded interrupts instead of workqueues.
From: Wolfgang Grandegger @ 2010-02-03 7:49 UTC (permalink / raw)
To: christian pellegrin
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cabda6421002022323m6ea676afu6c73843280b75e24-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
christian pellegrin wrote:
> On Tue, Feb 2, 2010 at 11:00 AM, Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org> wrote:
>> Hi Christian,
>>
>
> Hi,
>
>> The MERR should not come when the device is in bus-off. Nevertheless, it
>
> yes, sorry it's in error-passive state!
Yep. That's where it sits if you send a message with no cable connected
or no other node on the bus.
>> space via error messages. For exactly that reason we do not disable bus
>> errors on other CAN controllers, like the SJA1000 or the AT91, even if
>> they may produce high load. But we may discuss some generic interface to
>> disable bus-errors somehow, maybe configurable via ctrlmode. What do you
>> think?
>
> The transition of CAN error states is handled by the ERR interrupt,
> the MERR means "message error" and is fired when a transmission or
> receptions leads to an error. The problems with this interrupt are:
>
> 1) it's impossible to know if it was a TX or RX error.
>
> 2) if the error is accounted (for example) to TX the user will see
> ton's of TX errors even if he sent just one packet (this happens in
> error-passive mode for example) which could be confusing.
It's the same on the SJA1000, our reference controller.
> 3) I guess that microchip has a specific use of this interrupt in mind
> which explains it's drawbacks. From the data sheet:
>
> "7.4 Message Error Interrupt
> When an error occurs during transmission or reception
> of a message the message error flag (CAN-
> INTF.MERRF) will be set and, if the CANINTE.MERRE
> bit is set, an interrupt will be generated on the INT pin.
> This is intended to be used to facilitate baud rate deter-
> mination when used in conjunction with listen-only
> mode."
OK. If the bus-error does not provide additional information, like ack,
form, stuff, bit, etc. error, it's maybe not worth to support it.
Therefore, not enabling MERR is fine for the moment.
> I think that a much more useful information to somehow export to the
> user are the TEC and REC counters. I checked other CAN drivers but no
> one seems to do this. Anyway let me know what do you think so I could
> prepere the final patch now that OSM problems where sorted out.
CAN experts told me/us, that the bus-errors might be important
information for an apps. I just started a thread on how to improve our
current bus-error handling implementation.
Wolfgang.
^ permalink raw reply
* [PATCH 2.6.27.7-9-pae #7 SMP 1/1] networking tcp: Writing tcp socket be atomic
From: john ye @ 2010-02-03 9:12 UTC (permalink / raw)
To: davem, kuznet, netdev, jmorris, kaber; +Cc: linux-kernel
Subject: [PATCH 2.6.27.7-9-pae #7 SMP 1/1] networking tcp: Writing tcp socket be atomic
from: John Ye <johny@asimco.com.cn>
Writing tcp socket is not atomic in current kernel. When a socket is written by
multi-processes or threads,the other end will read interleaved garbage data.
This simple patch is to resolve this issue, to make the stream socket writing
be atomic under certain data size limit.
Similar to file system pipe ( with a max atomic write limit ), an atomic
socket can be written by multi processes or threads.
But it’s more than pipe. The pipe can only be used by multi processes in a
local system, the atomic stream socket can be used remotely to send data
among machines without user level locking involved.
How to test this patch:
1) apply the patch to kernel and modules, reboot from the new patched kernel
2) #define TCP_ATOMIC 20 in your test.c (TCP_ATOMIC is defined as 20 in kernel)
3) create a tcp socket, set the atomic option.
for example:
int val = 512;
int len = 4;
if(setsockopt(s, IPPROTO_TCP, TCP_ATOMIC, &val, len) == -1) {
perror("setsockopt");
return -1 ;
}
will set the atomic max data size to 512 bytes
to get the current atomic size for socket s,
val = 0;
len = 4;
if(getsockopt(s, IPPROTO_TCP, TCP_ATOMIC, &val, &len) == -1) {
perror("setsockopt");
return -1 ;
}
4) Then, connect to a tcp server, fork a child process.
let both main process and child process write() or send() its own data block to the server.
From the server, the received data bytes will be interleaved if no TCP_ATOMIC is set.
(I have a testing c code ready)
Signed-off-by: John Ye (Seeker) johny@asimco.com.cn
---
--- linux/net/ipv4/tcp.c 2008-12-05 09:48:57.000000000 +0800
+++ linux/net/ipv4/tcp.c 2010-02-03 15:15:11.000000000 +0800
@@ -822,6 +822,7 @@
int mss_now, size_goal;
int err, copied;
long timeo;
+ int atomic; /* is atomic write? johnye. Feb 2, 2010 */
lock_sock(sk);
TCP_CHECK_TIMER(sk);
@@ -849,6 +850,11 @@
if (sk->sk_err || (sk->sk_shutdown & SEND_SHUTDOWN))
goto do_error;
+
+ /* for multi-seg data or too big chunk, no atomic. johnye. */
+ atomic = tp->atomic_size;
+ if(iovlen > 1 || iov->iov_len > atomic) atomic = 0;
+
while (--iovlen >= 0) {
int seglen = iov->iov_len;
unsigned char __user *from = iov->iov_base;
@@ -889,14 +895,28 @@
if (copy > seglen)
copy = seglen;
+ /* if atomic write. johnye */
+ if (atomic)
+ copy = seglen;
+
/* Where to copy to? */
if (skb_tailroom(skb) > 0) {
/* We have some space in skb head. Superb! */
- if (copy > skb_tailroom(skb))
+ /* consider atomic write, johnye */
+ if (copy > skb_tailroom(skb)) {
+ if(atomic)
+ goto skb_page_start; /* q mark yet, johnye */
+
copy = skb_tailroom(skb);
+ }
if ((err = skb_add_data(skb, from, copy)) != 0)
goto do_fault;
- } else {
+
+ goto skb_page_done;
+ //} else {
+ }
+ skb_page_start:
+ {
int merge = 0;
int i = skb_shinfo(skb)->nr_frags;
struct page *page = TCP_PAGE(sk);
@@ -925,8 +945,17 @@
} else
off = 0;
- if (copy > PAGE_SIZE - off)
- copy = PAGE_SIZE - off;
+ /* consider atomic write, johnye */
+ if (copy > PAGE_SIZE - off) {
+ if (atomic && page) {
+ put_page(page);
+ TCP_PAGE(sk) = page = NULL;
+ off = 0;
+ merge = 0;
+ } else {
+ copy = PAGE_SIZE - off;
+ }
+ }
if (!sk_wmem_schedule(sk, copy))
goto wait_for_memory;
@@ -968,6 +997,7 @@
TCP_OFF(sk) = off + copy;
}
+ skb_page_done:
if (!copied)
TCP_SKB_CB(skb)->flags &= ~TCPCB_FLAG_PSH;
@@ -2019,6 +2049,16 @@
lock_sock(sk);
switch (optname) {
+
+ /* set the atomic write max size. johnye */
+ case TCP_ATOMIC:
+ if(val > 1024) {
+ err = -EINVAL;
+ break;
+ }
+ tp->atomic_size = val;
+ break;
+
case TCP_MAXSEG:
/* Values greater than interface MTU won't take effect. However
* at the point when this call is done we typically don't yet
@@ -2276,6 +2316,12 @@
return -EINVAL;
switch (optname) {
+
+ /* get the atomic write max size. johnye */
+ case TCP_ATOMIC:
+ val = tp->atomic_size;
+ break;
+
case TCP_MAXSEG:
val = tp->mss_cache;
if (!val && ((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN)))
--- linux/include/linux/tcp.h 2008-10-10 06:13:53.000000000 +0800
+++ linux/include/linux/tcp.h 2010-02-03 13:54:55.000000000 +0800
@@ -97,6 +97,8 @@
#define TCP_CONGESTION 13 /* Congestion control algorithm */
#define TCP_MD5SIG 14 /* TCP MD5 Signature (RFC2385) */
+#define TCP_ATOMIC 20 /* atomic TCP socket writting */
+
#define TCPI_OPT_TIMESTAMPS 1
#define TCPI_OPT_SACK 2
#define TCPI_OPT_WSCALE 4
@@ -411,6 +413,7 @@
#endif
int linger2;
+ u32 atomic_size; /* for atomic tcp socket write, johnye. Feb 2, 2010 */
};
static inline struct tcp_sock *tcp_sk(const struct sock *sk)
---
^ permalink raw reply
* Re: linux-next: manual merge of the trivial tree with the net tree
From: Jiri Kosina @ 2010-02-03 10:39 UTC (permalink / raw)
To: Stephen Rothwell, David Miller
Cc: linux-next, linux-kernel, Lennart Sorensen, netdev, Daniel Mack
In-Reply-To: <20100203133011.75aef1d3.sfr@canb.auug.org.au>
On Wed, 3 Feb 2010, Stephen Rothwell wrote:
> Today's linux-next merge of the trivial tree got a conflict in
> drivers/net/ppp_generic.c between commit
> fa44a73cc766c7f3bac71a66d564e0049b800325 ("ppp_generic.c severly
> whitespace damanged by 9c705260feea6ae329bc6b6d5f6d2ef0227eda0a") from
> the net tree and commit 09e1aa00f106a476f5b90d94fc0139544bbded75
> ("tree-wide: fix 'lenght' typo in comments and code") from the trivial
> tree.
>
> I fixed it up (by using the trivial tree version) and can carry the fix
> as necessary.
Hi,
I think the best thing is me dropping the net/ and drivers/net hunks of
this patch and taking it through Davem's tree ... I have already dropped
those hunks from my tree. Dave, the patch is below, please consider
applying.
From: Daniel Mack <daniel@caiaq.de>
Subject: [PATCH] net: fix 'lenght' typo in comments and code
Some misspelled occurences of 'octet' and some comments were also fixed
as I was on it.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Jiri Kosina <trivial@kernel.org>
Cc: Joe Perches <joe@perches.com>
Cc: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
index 2282e72..16cb124 100644
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -1436,17 +1436,16 @@ static int ppp_mp_explode(struct ppp *ppp, struct sk_buff *skb)
}
/*
- *check if we are on the last channel or
- *we exceded the lenght of the data to
- *fragment
+ * check if we are on the last channel or we exceeded the length
+ * of the data to fragment
*/
if ((nfree <= 0) || (flen > len))
flen = len;
/*
- *it is not worth to tx on slow channels:
- *in that case from the resulting flen according to the
- *above formula will be equal or less than zero.
- *Skip the channel in this case
+ * it is not worth to tx on slow channels:
+ * in that case from the resulting flen according to the above
+ * formula will be equal or less than zero.
+ * skip the channel in this case.
*/
if (flen <= 0) {
pch->avail = 2;
@@ -1466,7 +1465,7 @@ static int ppp_mp_explode(struct ppp *ppp, struct sk_buff *skb)
goto noskb;
q = skb_put(frag, flen + hdrlen);
- /* make the MP header */
+ /* make the MP header */
q[0] = PPP_MP >> 8;
q[1] = PPP_MP;
if (ppp->flags & SC_MP_XSHORTSEQ) {
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index f03e2e4..a3f9c3f 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -578,7 +578,7 @@ static int r6040_rx(struct net_device *dev, int limit)
/* RX dribble */
if (err & DSC_RX_ERR_DRI)
dev->stats.rx_frame_errors++;
- /* Buffer lenght exceeded */
+ /* Buffer length exceeded */
if (err & DSC_RX_ERR_BUF)
dev->stats.rx_length_errors++;
/* Packet too long */
diff --git a/drivers/net/sb1000.c b/drivers/net/sb1000.c
index 9f83a11..dab3ac7 100644
--- a/drivers/net/sb1000.c
+++ b/drivers/net/sb1000.c
@@ -65,7 +65,7 @@ static const int sb1000_debug = 1;
static const int SB1000_IO_EXTENT = 8;
/* SB1000 Maximum Receive Unit */
-static const int SB1000_MRU = 1500; /* octects */
+static const int SB1000_MRU = 1500; /* octets */
#define NPIDS 4
struct sb1000_private {
diff --git a/drivers/net/stmmac/common.h b/drivers/net/stmmac/common.h
index e49e518..81e5def 100644
--- a/drivers/net/stmmac/common.h
+++ b/drivers/net/stmmac/common.h
@@ -169,7 +169,7 @@ struct stmmac_extra_stats {
unsigned long rx_toolong;
unsigned long rx_collision;
unsigned long rx_crc;
- unsigned long rx_lenght;
+ unsigned long rx_length;
unsigned long rx_mii;
unsigned long rx_multicast;
unsigned long rx_gmac_overflow;
diff --git a/drivers/net/stmmac/gmac.c b/drivers/net/stmmac/gmac.c
index 52586ee..620b204 100644
--- a/drivers/net/stmmac/gmac.c
+++ b/drivers/net/stmmac/gmac.c
@@ -257,7 +257,7 @@ static int gmac_coe_rdes0(int ipc_err, int type, int payload_err)
/* bits 5 7 0 | Frame status
* ----------------------------------------------------------
- * 0 0 0 | IEEE 802.3 Type frame (lenght < 1536 octects)
+ * 0 0 0 | IEEE 802.3 Type frame (length < 1536 octets)
* 1 0 0 | IPv4/6 No CSUM errorS.
* 1 0 1 | IPv4/6 CSUM PAYLOAD error
* 1 1 0 | IPv4/6 CSUM IP HR error
@@ -358,7 +358,7 @@ static int gmac_get_rx_frame_status(void *data, struct stmmac_extra_stats *x,
}
if (unlikely(p->des01.erx.length_error)) {
DBG(KERN_ERR "GMAC RX: length_error error\n");
- x->rx_lenght++;
+ x->rx_length++;
ret = discard_frame;
}
#ifdef STMMAC_VLAN_TAG_USED
diff --git a/drivers/net/stmmac/mac100.c b/drivers/net/stmmac/mac100.c
index 625171b..1f6b608 100644
--- a/drivers/net/stmmac/mac100.c
+++ b/drivers/net/stmmac/mac100.c
@@ -262,7 +262,7 @@ static int mac100_get_rx_frame_status(void *data, struct stmmac_extra_stats *x,
ret = discard_frame;
if (unlikely(p->des01.rx.length_error)) {
- x->rx_lenght++;
+ x->rx_length++;
ret = discard_frame;
}
if (unlikely(p->des01.rx.mii_error)) {
diff --git a/drivers/net/stmmac/stmmac_ethtool.c b/drivers/net/stmmac/stmmac_ethtool.c
index 694ebe6..9edda5d 100644
--- a/drivers/net/stmmac/stmmac_ethtool.c
+++ b/drivers/net/stmmac/stmmac_ethtool.c
@@ -61,7 +61,7 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
STMMAC_STAT(rx_toolong),
STMMAC_STAT(rx_collision),
STMMAC_STAT(rx_crc),
- STMMAC_STAT(rx_lenght),
+ STMMAC_STAT(rx_length),
STMMAC_STAT(rx_mii),
STMMAC_STAT(rx_multicast),
STMMAC_STAT(rx_gmac_overflow),
diff --git a/drivers/net/wimax/i2400m/i2400m-usb.h b/drivers/net/wimax/i2400m/i2400m-usb.h
index 5cc0f27..9c61e5f 100644
--- a/drivers/net/wimax/i2400m/i2400m-usb.h
+++ b/drivers/net/wimax/i2400m/i2400m-usb.h
@@ -105,7 +105,7 @@ static inline void edc_init(struct edc *edc)
*
* @edc: pointer to error density counter.
* @max_err: maximum number of errors we can accept over the timeframe
- * @timeframe: lenght of the timeframe (in jiffies).
+ * @timeframe: length of the timeframe (in jiffies).
*
* Returns: !0 1 if maximum acceptable errors per timeframe has been
* exceeded. 0 otherwise.
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index afd26bf..c4e4121 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -279,7 +279,7 @@ static void p54spi_power_on(struct p54s_priv *priv)
enable_irq(gpio_to_irq(p54spi_gpio_irq));
/*
- * need to wait a while before device can be accessed, the lenght
+ * need to wait a while before device can be accessed, the length
* is just a guess
*/
msleep(10);
diff --git a/drivers/net/wireless/wl12xx/wl1251_cmd.c b/drivers/net/wireless/wl12xx/wl1251_cmd.c
index 770f260..ff446a0 100644
--- a/drivers/net/wireless/wl12xx/wl1251_cmd.c
+++ b/drivers/net/wireless/wl12xx/wl1251_cmd.c
@@ -103,7 +103,7 @@ int wl1251_cmd_test(struct wl1251 *wl, void *buf, size_t buf_len, u8 answer)
* @wl: wl struct
* @id: acx id
* @buf: buffer for the response, including all headers, must work with dma
- * @len: lenght of buf
+ * @len: length of buf
*/
int wl1251_cmd_interrogate(struct wl1251 *wl, u16 id, void *buf, size_t len)
{
diff --git a/drivers/net/wireless/wl12xx/wl1251_rx.c b/drivers/net/wireless/wl12xx/wl1251_rx.c
index f84cc89..0a45528 100644
--- a/drivers/net/wireless/wl12xx/wl1251_rx.c
+++ b/drivers/net/wireless/wl12xx/wl1251_rx.c
@@ -135,7 +135,7 @@ static void wl1251_rx_body(struct wl1251 *wl,
rx_buffer = skb_put(skb, length);
wl1251_mem_read(wl, rx_packet_ring_addr, rx_buffer, length);
- /* The actual lenght doesn't include the target's alignment */
+ /* The actual length doesn't include the target's alignment */
skb->len = desc->length - PLCP_HEADER_LENGTH;
fc = (u16 *)skb->data;
diff --git a/drivers/net/wireless/wl12xx/wl1271_cmd.c b/drivers/net/wireless/wl12xx/wl1271_cmd.c
index c3385b3..1e3d4b0 100644
--- a/drivers/net/wireless/wl12xx/wl1271_cmd.c
+++ b/drivers/net/wireless/wl12xx/wl1271_cmd.c
@@ -437,7 +437,7 @@ int wl1271_cmd_test(struct wl1271 *wl, void *buf, size_t buf_len, u8 answer)
* @wl: wl struct
* @id: acx id
* @buf: buffer for the response, including all headers, must work with dma
- * @len: lenght of buf
+ * @len: length of buf
*/
int wl1271_cmd_interrogate(struct wl1271 *wl, u16 id, void *buf, size_t len)
{
diff --git a/net/dccp/ackvec.h b/net/dccp/ackvec.h
index 7ea557b..fd278d8 100644
--- a/net/dccp/ackvec.h
+++ b/net/dccp/ackvec.h
@@ -73,7 +73,7 @@ struct dccp_ackvec {
* @avr_ack_ackno - sequence number being acknowledged
* @avr_ack_ptr - pointer into av_buf where this record starts
* @avr_ack_nonce - av_ack_nonce at the time this record was sent
- * @avr_sent_len - lenght of the record in av_buf
+ * @avr_sent_len - length of the record in av_buf
*/
struct dccp_ackvec_record {
struct list_head avr_node;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index eb6d097..cb4c91d 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1206,7 +1206,7 @@ int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
* Let's try using as much space as possible.
* Use MTU if total length of the message fits into the MTU.
* Otherwise, we need to reserve fragment header and
- * fragment alignment (= 8-15 octects, in total).
+ * fragment alignment (= 8-15 octets, in total).
*
* Note that we may need to "move" the data from the tail of
* of the buffer to the new fragment when we split
--
1.6.4.2
^ permalink raw reply related
* Re: Panic at tcp_xmit_retransmit_queue
From: Ilpo Järvinen @ 2010-02-03 11:02 UTC (permalink / raw)
To: sbs; +Cc: Netdev, LKML
In-Reply-To: <53cc795f1002010645w54b98b51s3dbdea18e5eb73f2@mail.gmail.com>
On Mon, 1 Feb 2010, sbs wrote:
> actually removing netconsole from kernel didnt help.
> i found many guys with the same problem but with different hardware
> configurations here:
>
> freez in TCP stack :
> http://bugzilla.kernel.org/show_bug.cgi?id=14470
>
> is there someone who can investigate it?
>
>
> On Tue, Jan 19, 2010 at 7:13 PM, sbs <gexlie@gmail.com> wrote:
> > We are hiting kernel panics on servers with nVidia MCP55 NICs once a day;
> > it appears usualy under a high network trafic ( around 10000Mbit/s) but
> > it is not a rule, it has happened even on low trafic.
> >
> > Servers are used as nginx+static content
> > On 2 equal servers this panic happens aprox 2 times a day depending on
> > network load. Machine completly freezes till the netconsole reboots.
> >
> > Kernel: 2.6.32.3
> >
> > what can it be? whats wrong with tcp_xmit_retransmit_queue() function ?
> > can anyone explain or fix?
You might want to try with to debug patch below. It might even make the
box to survive the event (if I got it coded right).
--
i.
--
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 383ce23..f4600fb 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2186,6 +2186,42 @@ static int tcp_can_forward_retransmit(struct sock *sk)
return 1;
}
+static void print_queue(struct sock *sk, struct sk_buff *old, struct sk_buff *hole)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct sk_buff *skb, *prev;
+
+ skb = tcp_write_queue_head(sk);
+ prev = (struct sk_buff *)(&sk->sk_write_queue);
+
+ if (skb == NULL) {
+ printk("NULL head, pkts %u\n", tp->packets_out);
+ return;
+ }
+ printk("head %p tail %p sendhead %p oldhint %p now %p hole %p high %u\n",
+ tcp_write_queue_head(sk), tcp_write_queue_tail(sk),
+ tcp_send_head(sk), old, tp->retransmit_skb_hint, hole,
+ tp->retransmit_high);
+
+ while (skb) {
+ printk("skb %p (%u-%u) next %p prev %p sacked %u\n",
+ skb, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq,
+ skb->next, skb->prev, TCP_SKB_CB(skb)->sacked);
+ if (prev != skb->prev)
+ printk("Inconsistent prev\n");
+
+ if (skb == tcp_write_queue_tail(sk)) {
+ if (skb->next != (struct sk_buff *)(&sk->sk_write_queue))
+ printk("Improper next at tail\n");
+ return;
+ }
+
+ prev = skb;
+ skb = skb->next;
+ }
+ printk("Encountered unexpected NULL\n");
+}
+
/* This gets called after a retransmit timeout, and the initially
* retransmitted data is acknowledged. It tries to continue
* resending the rest of the retransmit queue, until either
@@ -2194,12 +2230,15 @@ static int tcp_can_forward_retransmit(struct sock *sk)
* based retransmit packet might feed us FACK information again.
* If so, we use it to avoid unnecessarily retransmissions.
*/
+static int caught_it = 0;
+
void tcp_xmit_retransmit_queue(struct sock *sk)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
struct sk_buff *hole = NULL;
+ struct sk_buff *old = tp->retransmit_skb_hint;
u32 last_lost;
int mib_idx;
int fwd_rexmitting = 0;
@@ -2217,6 +2256,16 @@ void tcp_xmit_retransmit_queue(struct sock *sk)
last_lost = tp->snd_una;
}
+checknull:
+ if (skb == NULL) {
+ if (!caught_it)
+ print_queue(sk, old, hole);
+ caught_it++;
+ if (net_ratelimit())
+ printk("Errors caught so far %u\n", caught_it);
+ return;
+ }
+
tcp_for_write_queue_from(skb, sk) {
__u8 sacked = TCP_SKB_CB(skb)->sacked;
@@ -2257,7 +2306,7 @@ begin_fwd:
} else if (!(sacked & TCPCB_LOST)) {
if (hole == NULL && !(sacked & (TCPCB_SACKED_RETRANS|TCPCB_SACKED_ACKED)))
hole = skb;
- continue;
+ goto checknull;
} else {
last_lost = TCP_SKB_CB(skb)->end_seq;
@@ -2268,7 +2317,7 @@ begin_fwd:
}
if (sacked & (TCPCB_SACKED_ACKED|TCPCB_SACKED_RETRANS))
- continue;
+ goto checknull;
if (tcp_retransmit_skb(sk, skb))
return;
@@ -2278,6 +2327,7 @@ begin_fwd:
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
inet_csk(sk)->icsk_rto,
TCP_RTO_MAX);
+ goto checknull;
}
}
^ permalink raw reply related
* Re: [RFC Patch] net: reserve ports for applications using fixed port numbers
From: Octavian Purdila @ 2010-02-03 11:12 UTC (permalink / raw)
To: Amerigo Wang
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eric Dumazet,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Neil Horman, linux-sctp-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <20100203043332.3817.27932.sendpatchset-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Wednesday 03 February 2010 06:30:07 you wrote:
> This patch introduces /proc/sys/net/ipv4/ip_local_reserved_ports,
> it can be used like ip_local_port_range, but this is used to
> reserve ports for third-party applications which use fixed
> port numbers within ip_local_port_range.
>
> This only affects the applications which call socket functions
> like bind(2) with port number 0, to prevent the kernel getting the ports
> within the specified range for them. For applications which use fixed
> port number, it will have no effects.
It also affects the case where applications do connect, without previously
doing bind, right?
>
> Any comments are welcome.
I think it might be useful to allow setting individual ports as reserved, not
only ranges, for example by using a bitmap.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/1] dccp: fix auto-loading of dccp(_probe)
From: Neil Horman @ 2010-02-03 11:58 UTC (permalink / raw)
To: Gerrit Renker, davem, dccp, netdev
In-Reply-To: <20100203061656.GA5415@gerrit.erg.abdn.ac.uk>
On Wed, Feb 03, 2010 at 07:16:56AM +0100, Gerrit Renker wrote:
> Hi Neil,
>
> I have tested your patch, it works fine thanks to the repeated execution of the macro
> argument. I have reformatted it, removing the inner parentheses, which I think is
> justified since macros copy their arguments in full. Also converted your email to a
> drafted commit message. Due to this, have not copied your signed-off -- if you are
> ok, please add, this should be submitted asap.
>
Understood, and thank you. This looks fine to me
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Patch v2 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> dccp: fix loading of dccp_probe
>
> This fixes commit (38ff3e6bb987ec583268da8eb22628293095d43b) ("dccp_probe:
> Fix module load dependencies between dccp and dccp_probe", from 15 Jan).
>
> It fixes the construction of the first argument of try_then_request_module(),
> where only valid return codes from the first argument should be returned.
>
> What we do now is assign the result of register_jprobe() to ret, without
> the side effect of the comparison.
>
> Acked-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
> ---
> net/dccp/probe.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/net/dccp/probe.c
> +++ b/net/dccp/probe.c
> @@ -161,8 +161,8 @@ static __init int dccpprobe_init(void)
> if (!proc_net_fops_create(&init_net, procname, S_IRUSR, &dccpprobe_fops))
> goto err0;
>
> - ret = try_then_request_module((register_jprobe(&dccp_send_probe) == 0),
> - "dccp");
> + try_then_request_module((ret = register_jprobe(&dccp_send_probe)) == 0,
> + "dccp");
> if (ret)
> goto err1;
>
>
^ permalink raw reply
* Re: [PATCH] netfilter: per netns nf_conntrack_cachep
From: Patrick McHardy @ 2010-02-03 12:10 UTC (permalink / raw)
To: Jon Masters
Cc: Alexey Dobriyan, Eric Dumazet, linux-kernel, netdev,
netfilter-devel, Paul E. McKenney
In-Reply-To: <4B6870AF.6060109@trash.net>
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]
Patrick McHardy wrote:
> Jon Masters wrote:
>> On Tue, 2010-02-02 at 19:58 +0200, Alexey Dobriyan wrote:
>>
>>> Yes, moving to init_net-only function is fine.
>> So moving the "setup up fake conntrack" bits to init_init_net from
>> init_net still results in the panic, which means that the use count
>> really is dropping to zero and we really are trying to free it when
>> using multiple namespaces. Per ns is probably an easier way to go.
>
> Agreed, that will also avoid problems in the future with the
> ct_net pointer pointing to &init_net. I'll take care of this
> tommorrow.
Unfortunately a per-namespace conntrack is not easily possible without
larger changes (most of which are already queued in nf-next-2.6.git
though). So for now I just moved the untrack handling to the init_net
setup and cleanup functions and we can try to fix the remainder in
2.6.34.
Jon, could you give this patch a try please?
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 3006 bytes --]
commit 056ff3e3bd1563969a311697323ff929df94415c
Author: Patrick McHardy <kaber@trash.net>
Date: Wed Feb 3 12:58:06 2010 +0100
netfilter: nf_conntrack: fix memory corruption with multiple namespaces
As discovered by Jon Masters <jonathan@jonmasters.org>, the "untracked"
conntrack, which is located in the data section, might be accidentally
freed when a new namespace is instantiated while the untracked conntrack
is attached to a skb because the reference count it re-initialized.
The best fix would be to use a seperate untracked conntrack per
namespace since it includes a namespace pointer. Unfortunately this is
not possible without larger changes since the namespace is not easily
available everywhere we need it. For now move the untracked conntrack
initialization to the init_net setup function to make sure the reference
count is not re-initialized and handle cleanup in the init_net cleanup
function to make sure namespaces can exit properly while the untracked
conntrack is in use in other namespaces.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 0e98c32..37e2b88 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1113,6 +1113,10 @@ static void nf_ct_release_dying_list(struct net *net)
static void nf_conntrack_cleanup_init_net(void)
{
+ /* wait until all references to nf_conntrack_untracked are dropped */
+ while (atomic_read(&nf_conntrack_untracked.ct_general.use) > 1)
+ schedule();
+
nf_conntrack_helper_fini();
nf_conntrack_proto_fini();
kmem_cache_destroy(nf_conntrack_cachep);
@@ -1127,9 +1131,6 @@ static void nf_conntrack_cleanup_net(struct net *net)
schedule();
goto i_see_dead_people;
}
- /* wait until all references to nf_conntrack_untracked are dropped */
- while (atomic_read(&nf_conntrack_untracked.ct_general.use) > 1)
- schedule();
nf_ct_free_hashtable(net->ct.hash, net->ct.hash_vmalloc,
nf_conntrack_htable_size);
@@ -1288,6 +1289,14 @@ static int nf_conntrack_init_init_net(void)
if (ret < 0)
goto err_helper;
+ /* Set up fake conntrack: to never be deleted, not in any hashes */
+#ifdef CONFIG_NET_NS
+ nf_conntrack_untracked.ct_net = &init_net;
+#endif
+ atomic_set(&nf_conntrack_untracked.ct_general.use, 1);
+ /* - and look it like as a confirmed connection */
+ set_bit(IPS_CONFIRMED_BIT, &nf_conntrack_untracked.status);
+
return 0;
err_helper:
@@ -1333,15 +1342,6 @@ static int nf_conntrack_init_net(struct net *net)
if (ret < 0)
goto err_ecache;
- /* Set up fake conntrack:
- - to never be deleted, not in any hashes */
-#ifdef CONFIG_NET_NS
- nf_conntrack_untracked.ct_net = &init_net;
-#endif
- atomic_set(&nf_conntrack_untracked.ct_general.use, 1);
- /* - and look it like as a confirmed connection */
- set_bit(IPS_CONFIRMED_BIT, &nf_conntrack_untracked.status);
-
return 0;
err_ecache:
^ permalink raw reply related
* [PATCH net-next-2.6] net: use helpers to access mc list V2
From: Jiri Pirko @ 2010-02-03 12:59 UTC (permalink / raw)
To: netdev; +Cc: davem
This patch introduces the similar helpers as those already done for uc list.
However multicast lists are no list_head lists but "mademanually". The three
macros added by this patch will make the transition of mc_list to list_head
smooth in two steps:
1) convert all drivers to use these macros (with the original iterator of type
"struct dev_mc_list")
2) once all drivers are converted, convert list type and iterators to "struct
netdev_hw_addr" in one patch.
>From now on, drivers can (and should) use "netdev_for_each_mc_addr" to iterate
over the addresses with iterator of type "struct netdev_hw_addr". Also macros
"netdev_mc_count" and "netdev_mc_empty" to read list's length. This is the state
which should be reached in all drivers.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
include/linux/netdevice.h | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 93a32a5..3f1c4a8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -268,6 +268,12 @@ struct netdev_hw_addr_list {
#define netdev_for_each_uc_addr(ha, dev) \
list_for_each_entry(ha, &dev->uc.list, list)
+#define netdev_mc_count(dev) ((dev)->mc_count)
+#define netdev_mc_empty(dev) (netdev_mc_count(dev) == 0)
+
+#define netdev_for_each_mc_addr(mclist, dev) \
+ for (mclist = dev->mc_list; mclist; mclist = mclist->next)
+
struct hh_cache {
struct hh_cache *hh_next; /* Next entry */
atomic_t hh_refcnt; /* number of users */
--
1.6.6
^ permalink raw reply related
* [PATCH net-next-2.6] libphy: add phy_find_first function
From: Jiri Pirko @ 2010-02-03 15:34 UTC (permalink / raw)
To: netdev; +Cc: davem
Many drivers do this in them manually. Now they can use this function.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index adbc0fd..db17945 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -277,6 +277,22 @@ int phy_device_register(struct phy_device *phydev)
EXPORT_SYMBOL(phy_device_register);
/**
+ * phy_find_first - finds the first PHY device on the bus
+ * @bus: the target MII bus
+ */
+struct phy_device *phy_find_first(struct mii_bus *bus)
+{
+ int addr;
+
+ for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
+ if (bus->phy_map[addr])
+ return bus->phy_map[addr];
+ }
+ return NULL;
+}
+EXPORT_SYMBOL(phy_find_first);
+
+/**
* phy_prepare_link - prepares the PHY layer to monitor link status
* @phydev: target phy_device struct
* @handler: callback function for link status change notifications
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 6a7eb40..14d7fdf 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -452,6 +452,7 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
u32 flags, phy_interface_t interface);
struct phy_device * phy_attach(struct net_device *dev,
const char *bus_id, u32 flags, phy_interface_t interface);
+struct phy_device *phy_find_first(struct mii_bus *bus);
int phy_connect_direct(struct net_device *dev, struct phy_device *phydev,
void (*handler)(struct net_device *), u32 flags,
phy_interface_t interface);
^ permalink raw reply related
* [PATCH] obsolete config in kernel source (IP_ROUTE_PERVASIVE)
From: Christoph Egger @ 2010-02-03 16:05 UTC (permalink / raw)
To: linux-kernel, netdev, davem, kuznet; +Cc: siccegge, vamos
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
Hi all!
As part of the VAMOS[0] research project at the University of
Erlangen we're checking referential integrity between kernel KConfig
options and in-code Conditional blocks.
According to my search CONFIG_IP_ROUTE_PERVASIVE is not
defined in any 2.4-2.6 kernel (not #define d and not in
KConfig). However some tiny piece of code still checks it. If this is
really a leftover (as I expect) it might be a good idea to actually
remove that unreachable bit of code.
Please keep me informed of this patch getting confirmed /
merged so we can keep track of it.
Regards
Christoph Egger
[0] http://vamos1.informatik.uni-erlangen.de/
[-- Attachment #2: 0001-Get-rid-of-CONFIG_IP_ROUTE_PERVASIVE.patch --]
[-- Type: text/x-diff, Size: 1178 bytes --]
>From 3c33c76fba95a529b67799cefbddbb688807c0fa Mon Sep 17 00:00:00 2001
From: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
Date: Wed, 3 Feb 2010 16:37:43 +0100
Subject: [PATCH] Get rid of CONFIG_IP_ROUTE_PERVASIVE
CONFIG_IP_ROUTE_PERVASIVE is missing a corresponding config
IP_ROUTE_PERVASIVE somewhere in KConfig (and missing it for ages
already) so it looks like some aging artefact no longer needed.
Therefor this patch kills of the only remaining reference to that
config Item removing the already unrechable code snipet.
Signed-off-by: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de>
---
net/ipv4/fib_semantics.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index ed19aa6..235c1ac 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -527,10 +527,6 @@ static int fib_check_nh(struct fib_config *cfg, struct fib_info *fi,
if (nh->nh_gw) {
struct fib_result res;
-#ifdef CONFIG_IP_ROUTE_PERVASIVE
- if (nh->nh_flags&RTNH_F_PERVASIVE)
- return 0;
-#endif
if (nh->nh_flags&RTNH_F_ONLINK) {
struct net_device *dev;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] seastar - SeaStar Ethernet driver
From: Randy Dunlap @ 2010-02-03 16:12 UTC (permalink / raw)
To: Kevin Pedretti
Cc: David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1265160242.15726.20.camel@hawkeye.sandia.gov>
On 02/02/10 17:24, Kevin Pedretti wrote:
> Thank you all for the review comments. I believe most of the issues
> have been addressed in the patch just posted. I apologize if there are
> still issues, and certainly appreciate further comments.
>
>
> Randy Dunlap's comments:
> 2. Odd spacing -> I'm not seeing this. Spacing looks correct to me.
Thanks. Seems to be something that Thunderbird 3.0 is doing for me. :(
--
~Randy
^ 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