* [PATCH v3 01/10] net/fec: fix MMFR_OP type in fec_enet_mdio_write
From: Shawn Guo @ 2011-01-05 14:07 UTC (permalink / raw)
To: davem, gerg, baruch, eric, bryan.wu, r64343, B32542,
u.kleine-koenig
Cc: Shawn Guo
In-Reply-To: <1294236457-17476-1-git-send-email-shawn.guo@freescale.com>
FEC_MMFR_OP_WRITE should be used than FEC_MMFR_OP_READ in
a mdio write operation.
It's probably a typo introduced by commit:
e6b043d512fa8d9a3801bf5d72bfa3b8fc3b3cc8
netdev/fec.c: add phylib supporting to enable carrier detection (v2)
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
drivers/net/fec.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index cce32d4..52e9ca8 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -651,8 +651,8 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int mii_id, int regnum,
fep->mii_timeout = 0;
init_completion(&fep->mdio_done);
- /* start a read op */
- writel(FEC_MMFR_ST | FEC_MMFR_OP_READ |
+ /* start a write op */
+ writel(FEC_MMFR_ST | FEC_MMFR_OP_WRITE |
FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(regnum) |
FEC_MMFR_TA | FEC_MMFR_DATA(value),
fep->hwp + FEC_MII_DATA);
--
1.7.1
^ permalink raw reply related
* [PATCH v3 00/10] net/fec: add dual fec support for i.MX28
From: Shawn Guo @ 2011-01-05 14:07 UTC (permalink / raw)
To: davem, gerg, baruch, eric, bryan.wu, r64343, B32542,
u.kleine-koenig
This patch series is to add dual fec support for mx28, which is
a mxs-based soc. Some code changes related to the following commits
are also made in this patch set for some reasons.
e6b043d512fa8d9a3801bf5d72bfa3b8fc3b3cc8
netdev/fec.c: add phylib supporting to enable carrier detection (v2)
e3fe8558c7fc182972c3d947d88744482111f304
net/fec: fix pm to survive to suspend/resume
It's been tested on mx28 evk and mx51 babbage. For mx28, it has
to work against the tree
git://git.pengutronix.de/git/imx/linux-2.6.git imx-for-2.6.38
plus patch
[PATCH v4] ARM: mxs: Change duart device to use amba-pl011
Changes for v3:
- Move v2 changes on patch #5 to #3
- Use device name to detect the running of mx28 fec controller
naming ENET-MAC
The 3 patches below preceding with * have changes since v2, and
the detailed change log can be found in individual patch.
[PATCH v3 01/10] net/fec: fix MMFR_OP type in fec_enet_mdio_write
[PATCH v3 02/10] net/fec: remove the use of "index" which is legacy
*[PATCH v3 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac
[PATCH v3 04/10] net/fec: improve pm for better suspend/resume
*[PATCH v3 05/10] net/fec: add dual fec support for mx28
*[PATCH v3 06/10] ARM: mx28: update clock and device name for dual fec support
[PATCH v3 07/10] ARM: mx28: add the second fec device registration
[PATCH v3 08/10] ARM: mxs: add ocotp read function
[PATCH v3 09/10] ARM: mx28: read fec mac address from ocotp
[PATCH v3 10/10] ARM: mxs: add initial pm support
Thanks for the review.
Regards,
Shawn
^ permalink raw reply
* [PATCH] ipv4: IP defragmentation must be ECN aware
From: Eric Dumazet @ 2011-01-05 13:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1294186431.3420.19.camel@edumazet-laptop>
RFC3168 (The Addition of Explicit Congestion Notification to IP)
states :
5.3. Fragmentation
ECN-capable packets MAY have the DF (Don't Fragment) bit set.
Reassembly of a fragmented packet MUST NOT lose indications of
congestion. In other words, if any fragment of an IP packet to be
reassembled has the CE codepoint set, then one of two actions MUST be
taken:
* Set the CE codepoint on the reassembled packet. However, this
MUST NOT occur if any of the other fragments contributing to
this reassembly carries the Not-ECT codepoint.
* The packet is dropped, instead of being reassembled, for any
other reason.
This patch implements this requirement for IPv4, choosing the first
action :
If one fragment had NO-ECT codepoint
reassembled frame has NO-ECT
ElIf one fragment had CE codepoint
reassembled frame has CE
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/ip_fragment.c | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index e6215bd..e6b53a7 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -45,6 +45,7 @@
#include <linux/udp.h>
#include <linux/inet.h>
#include <linux/netfilter_ipv4.h>
+#include <net/inet_ecn.h>
/* NOTE. Logic of IP defragmentation is parallel to corresponding IPv6
* code now. If you change something here, _PLEASE_ update ipv6/reassembly.c
@@ -70,11 +71,28 @@ struct ipq {
__be32 daddr;
__be16 id;
u8 protocol;
+ u8 ecn; /* RFC3168 support */
int iif;
unsigned int rid;
struct inet_peer *peer;
};
+#define IPFRAG_ECN_CLEAR 0x01 /* one frag had INET_ECN_NOT_ECT */
+#define IPFRAG_ECN_SET_CE 0x04 /* one frag had INET_ECN_CE */
+
+static inline int ip4_frag_ecn(int tos)
+{
+ tos = (tos & INET_ECN_MASK) + 1;
+ /*
+ * After the last operation we have (in binary):
+ * INET_ECN_NOT_ECT => 001
+ * INET_ECN_ECT_1 => 010
+ * INET_ECN_ECT_0 => 011
+ * INET_ECN_CE => 100
+ */
+ return (tos & 2) ? 0 : tos;
+}
+
static struct inet_frags ip4_frags;
int ip_frag_nqueues(struct net *net)
@@ -137,6 +155,7 @@ static void ip4_frag_init(struct inet_frag_queue *q, void *a)
qp->protocol = arg->iph->protocol;
qp->id = arg->iph->id;
+ qp->ecn = ip4_frag_ecn(arg->iph->tos);
qp->saddr = arg->iph->saddr;
qp->daddr = arg->iph->daddr;
qp->user = arg->user;
@@ -316,6 +335,7 @@ static int ip_frag_reinit(struct ipq *qp)
qp->q.fragments = NULL;
qp->q.fragments_tail = NULL;
qp->iif = 0;
+ qp->ecn = 0;
return 0;
}
@@ -328,6 +348,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb)
int flags, offset;
int ihl, end;
int err = -ENOENT;
+ u8 ecn;
if (qp->q.last_in & INET_FRAG_COMPLETE)
goto err;
@@ -339,6 +360,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb)
goto err;
}
+ ecn = ip4_frag_ecn(ip_hdr(skb)->tos);
offset = ntohs(ip_hdr(skb)->frag_off);
flags = offset & ~IP_OFFSET;
offset &= IP_OFFSET;
@@ -472,6 +494,7 @@ found:
}
qp->q.stamp = skb->tstamp;
qp->q.meat += skb->len;
+ qp->ecn |= ecn;
atomic_add(skb->truesize, &qp->q.net->mem);
if (offset == 0)
qp->q.last_in |= INET_FRAG_FIRST_IN;
@@ -583,6 +606,17 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
iph = ip_hdr(head);
iph->frag_off = 0;
iph->tot_len = htons(len);
+ /* RFC3168 5.3 Fragmentation support :
+ * If one fragment had INET_ECN_NOT_ECT,
+ * reassembled frame also has INET_ECN_NOT_ECT
+ * Elif one fragment had INET_ECN_CE
+ * reassembled frame also has INET_ECN_CE
+ */
+ if (qp->ecn & IPFRAG_ECN_CLEAR)
+ iph->tos &= ~INET_ECN_MASK;
+ else if (qp->ecn & IPFRAG_ECN_SET_CE)
+ iph->tos |= INET_ECN_CE;
+
IP_INC_STATS_BH(net, IPSTATS_MIB_REASMOKS);
qp->q.fragments = NULL;
qp->q.fragments_tail = NULL;
^ permalink raw reply related
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Kirill A. Shutemov @ 2011-01-05 13:40 UTC (permalink / raw)
To: Al Viro
Cc: Kirill A. Shutemov, Trond Myklebust, J. Bruce Fields, Neil Brown,
Pavel Emelyanov, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110105114155.GN19804-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
On Wed, Jan 05, 2011 at 11:41:55AM +0000, Al Viro wrote:
> On Wed, Dec 29, 2010 at 03:14:18PM +0200, Kirill A. Shutemov wrote:
> > Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
>
> Won't that make sunrpc impossible to rmmod once you've got it in?
Oops.. Nice catch.
I'll fix it by relacing remaing references of init_rpc_pipefs with
get_rpc_pipefs(NULL) at the end of the patchset and move init_rpc_pipefs
mounting to get_rpc_pipefs(). So, we will have temporary regression in the
middle of the patchset, but I think it's not a problem.
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: Changli Gao @ 2011-01-05 13:37 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, bridge, netdev
In-Reply-To: <20110103.121336.212692696.davem@davemloft.net>
On Tue, Jan 4, 2011 at 4:13 AM, David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@linux-foundation.org>
>>
>> Because PPPOE happens afterwards and is not part the calculation.
>> The check should be moved until after skb has reached final form.
>
> That works for me.
>
So, is my patch acceptable?
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH] xen: netfront: Drop GSO SKBs which do not have csum_blank.
From: Ian Campbell @ 2011-01-05 13:23 UTC (permalink / raw)
To: netdev; +Cc: Ian Campbell, Jeremy Fitzhardinge, xen-devel
The Linux network stack expects all GSO SKBs to have ip_summed ==
CHECKSUM_PARTIAL (which implies that the frame contains a partial
checksum) and the Xen network ring protocol similarly expects an SKB
which has GSO set to also have NETRX_csum_blank (which also implies a
partial checksum). Therefore drop such frames on receive otherwise
they will trigger the warning in skb_gso_segment.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Cc: netdev@vger.kernel.org
---
drivers/net/xen-netfront.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index cdbeec9..8b8c480 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -836,6 +836,11 @@ static int handle_incoming_queue(struct net_device *dev,
dev->stats.rx_errors++;
continue;
}
+ } else if (skb_is_gso(skb)) {
+ kfree_skb(skb);
+ packets_dropped++;
+ dev->stats.rx_errors++;
+ continue;
}
dev->stats.rx_packets++;
--
1.5.6.5
^ permalink raw reply related
* unmet direct dependencies (NET && NET_SCHED)
From: Toralf Förster @ 2011-01-05 13:22 UTC (permalink / raw)
To: netfilter; +Cc: netdev
Hello,
a "make randconfig 1>/dev/null" gave today :
tfoerste@n22 ~/devel/linux-2.6 $ make randconfig 1>/dev/null
warning: (NETFILTER_XT_MATCH_REALM && NET && INET && NETFILTER &&
NETFILTER_XTABLES && NETFILTER_ADVANCED || NET_CLS_ROUTE4 && NET && NET_SCHED)
selects NET_CLS_ROUTE which has unmet direct dependencies (NET && NET_SCHED)
for the current git kernel sources.
Is this an already known issue ?
--
MfG/Kind regards
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* [RFC] ipmr: About origin IP address of flow in multicast routing API
From: François-Xavier Le Bail @ 2011-01-05 12:59 UTC (permalink / raw)
To: netdev
Hello,
Context: IGMP Proxying.
For using multicast routing API with setsockopt and MRT_ADD_MFC, we need to set the mfcc_origin in a struct mfcctl.
Is there a way to use a wildcard for mfcc_origin to say "any origin" IP address, by example 0.0.0.0 ?
Thus we could add a MFC with only the multicast group and the mfcc_parent, reading a SOCK_RAW/IPPROTO_IGMP socket, without the need to listen the multicast flow to find the origin IP.
Any thought ?
Francois-Xavier Le Bail
^ permalink raw reply
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Al Viro @ 2011-01-05 11:41 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Trond Myklebust, J. Bruce Fields, Neil Brown, Pavel Emelyanov,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1293628470-28386-1-git-send-email-kas-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
On Wed, Dec 29, 2010 at 03:14:18PM +0200, Kirill A. Shutemov wrote:
> Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
Won't that make sunrpc impossible to rmmod once you've got it in?
Note that having a reference to vfsmount pins it down, which pins
the superblock down, which pins the file_system_type down, which
pins the damn module down. So cleanup_sunrpc() won't be ever called,
AFAICS...
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* السلام عليكم أخي
From: aliamdulilahi2 @ 2011-01-05 10:13 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: salamiah.doc --]
[-- Type: application/msword, Size: 28672 bytes --]
^ permalink raw reply
* Re: [PATCH] net: r6040: Return proper error for r6040_init_one
From: Florian Fainelli @ 2011-01-05 9:50 UTC (permalink / raw)
To: Axel Lin; +Cc: linux-kernel, David S. Miller, netdev
In-Reply-To: <1294216804.19064.2.camel@mola>
On Wednesday 05 January 2011 09:40:04 Axel Lin wrote:
> Return -ENOMEM instead of 0 for the case of mdiobus_alloc and kmalloc
> failure.
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Florian Fainelli <florian@openwrt.org>
> ---
> drivers/net/r6040.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
> index 0b014c89..27e6f6d 100644
> --- a/drivers/net/r6040.c
> +++ b/drivers/net/r6040.c
> @@ -1153,6 +1153,7 @@ static int __devinit r6040_init_one(struct pci_dev
> *pdev, lp->mii_bus = mdiobus_alloc();
> if (!lp->mii_bus) {
> dev_err(&pdev->dev, "mdiobus_alloc() failed\n");
> + err = -ENOMEM;
> goto err_out_unmap;
> }
>
> @@ -1165,6 +1166,7 @@ static int __devinit r6040_init_one(struct pci_dev
> *pdev, lp->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
> if (!lp->mii_bus->irq) {
> dev_err(&pdev->dev, "mii_bus irq allocation failed\n");
> + err = -ENOMEM;
> goto err_out_mdio;
> }
^ permalink raw reply
* Re: [PATCH v2 05/10] net/fec: add dual fec support for mx28
From: Shawn Guo @ 2011-01-05 9:40 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Sascha Hauer, Baruch Siach, B32542, netdev, bryan.wu, gerg,
w.sang, r64343, eric, davem, linux-arm-kernel, lw
In-Reply-To: <20110105090312.GO25121@pengutronix.de>
On Wed, Jan 05, 2011 at 10:03:12AM +0100, Uwe Kleine-König wrote:
> Hello Shawn,
>
> On Wed, Jan 05, 2011 at 09:45:13AM +0100, Sascha Hauer wrote:
> > On Tue, Jan 04, 2011 at 10:13:09PM +0800, Shawn Guo wrote:
> > > Hi Baruch,
> > >
> > > On Tue, Jan 04, 2011 at 11:59:16AM +0200, Baruch Siach wrote:
> > > > Hi Shawn,
> > > >
> > > > On Tue, Jan 04, 2011 at 05:24:11PM +0800, Shawn Guo wrote:
> > > > > This patch is to add mx28 dual fec support. Here are some key notes
> > > > > for mx28 fec controller.
> > > > >
> > > > > - mx28 fec design made an assumption that it runs on a
> > > > > big-endian system, which is incorrect. As the result, the
> > > > > driver has to swap every frame going to and coming from
> > > > > the controller.
> > > > > - external phys can only be configured by fec0, which means
> > > > > fec1 can not work independently and both phys need to be
> > > > > configured by mii_bus attached on fec0.
> > > > > - mx28 fec reset will get mac address registers reset too.
> > > > > - MII/RMII mode and 10M/100M speed are configured differently
> > > > > from i.mx/mxs fec controller.
> > > > > - ETHER_EN bit must be set to get interrupt work.
> > > > >
> > > > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > > > ---
> > > > > Changes for v2:
> > > > > - Use module parameter fec.macaddr over new kernel command line
> > > > > fec_mac to pass mac address
> > > >
> > > > Since you introduce this new kernel command line parameter in patch #3 of this
> > > > series, why not just make it right in the first place? This should make both
> > > > patches smaller and easier for review.
> > > >
> > > > > - Update comment in fec_get_mac() to stop using confusing word
> > > > > "default"
> > > > > - Fix copyright breakage in fec.h
> > > >
> > > > Ditto.
> > > >
> > > Sorry for rushing to send the patch set out. All these updates
> > > should happen on patch #3 than #5. This is a serious problem,
> > > and I will fix it soon and resend as v3.
> > >
> > > > > drivers/net/Kconfig | 7 ++-
> > > > > drivers/net/fec.c | 139 ++++++++++++++++++++++++++++++++++++++++----------
> > > > > drivers/net/fec.h | 5 +-
> > > > > include/linux/fec.h | 3 +-
> > > > > 4 files changed, 120 insertions(+), 34 deletions(-)
> > > >
> > > > [snip]
> > > >
> > > > > diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> > > > > index f147508..b2b3e37 100644
> > > > > --- a/drivers/net/fec.c
> > > > > +++ b/drivers/net/fec.c
> > > > > @@ -17,6 +17,8 @@
> > > > > *
> > > > > * Bug fixes and cleanup by Philippe De Muyter (phdm@macqel.be)
> > > > > * Copyright (c) 2004-2006 Macq Electronique SA.
> > > > > + *
> > > > > + * Copyright (C) 2010 Freescale Semiconductor, Inc.
> > > > > */
> > > > >
> > > > > #include <linux/module.h>
> > > > > @@ -45,21 +47,34 @@
> > > > >
> > > > > #include <asm/cacheflush.h>
> > > > >
> > > > > -#ifndef CONFIG_ARCH_MXC
> > > > > +#if !defined(CONFIG_ARCH_MXC) && !defined(CONFIG_SOC_IMX28)
> > > > > #include <asm/coldfire.h>
> > > > > #include <asm/mcfsim.h>
> > > > > #endif
> > > > >
> > > > > #include "fec.h"
> > > > >
> > > > > -#ifdef CONFIG_ARCH_MXC
> > > > > -#include <mach/hardware.h>
> > > >
> > > > Since you now remove mach/hardware.h for ARCH_MXC, does this build for all
> > > > i.MX variants?
> > > >
> > > Did the test build for mx25, mx27, mx3 and mx51.
> > >
> > > > > +#ifdef CONFIG_SOC_IMX28
> > > > > +/*
> > > > > + * mx28 does not have MIIGSK registers
> > > > > + */
> > > > > +#undef FEC_MIIGSK_ENR
> > > > > +#include <mach/mxs.h>
> > > > > +#else
> > > > > +#define cpu_is_mx28() (0)
> > > > > +#endif
> > > >
> > > > This breaks kernels for multiple archs (e.g. i.MX28 and i.MX25). Please use
> > > > run-time detection of CPU type, and do the MII/RMII etc. configuration
> > > > accordingly.
> > > >
> > > I do not find a good way to detect cpu type. Neither adding a new
> > > platform data field nor using __machine_arch_type to enumerate all
> > > mx28 based machine (though there is only one currently) seems to be
> > > good for me.
> > >
> > > I will try to manipulate some mx28 unique register to identify mx28
> > > from other i.mx variants. Hopefully, it will work.
> >
> > There won't be a register which you can safely read on all i.MX
> > variants.FEC_TRUNC_FL
Register FEC_TRUNC_FL (offset 0x1b0) is one I found I can use to
distinguish ENET-MAC from FEC. This address is being reserved on
FEC, and I knew from designer that access the address on FEC
will not generate exception as it's valid in FEC address range.
I proved it on mx51.
/*
* Detect ENET-MAC by writing and reading back on TRUNC_FL register,
* which is accessible on ENET-MAC while always return 0 on FEC.
*/
writel(0x7ff, fep->hwp + 0x1b0);
if (readl(fep->hwp + 0x1b0) == 0x7ff)
fec_is_enetmac = 1;
But it does not matter. I more like the solution that offered by Uwe
below.
Thanks, Sascha.
> > Why don't you implement it the same way the other i.MX do? They do not
> > need SoC detection and the macro expands to 0 at compile time when the
> > cpu is not enabled.
> Alternatively you can use the approach I used for spi-imx and identify
> the device by name.
>
Thanks, Uwe.
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH v2 05/10] net/fec: add dual fec support for mx28
From: Uwe Kleine-König @ 2011-01-05 9:03 UTC (permalink / raw)
To: Shawn Guo
Cc: Sascha Hauer, Baruch Siach, B32542, netdev, bryan.wu, gerg,
w.sang, r64343, eric, davem, linux-arm-kernel, lw
In-Reply-To: <20110105084513.GA26617@pengutronix.de>
Hello Shawn,
On Wed, Jan 05, 2011 at 09:45:13AM +0100, Sascha Hauer wrote:
> On Tue, Jan 04, 2011 at 10:13:09PM +0800, Shawn Guo wrote:
> > Hi Baruch,
> >
> > On Tue, Jan 04, 2011 at 11:59:16AM +0200, Baruch Siach wrote:
> > > Hi Shawn,
> > >
> > > On Tue, Jan 04, 2011 at 05:24:11PM +0800, Shawn Guo wrote:
> > > > This patch is to add mx28 dual fec support. Here are some key notes
> > > > for mx28 fec controller.
> > > >
> > > > - mx28 fec design made an assumption that it runs on a
> > > > big-endian system, which is incorrect. As the result, the
> > > > driver has to swap every frame going to and coming from
> > > > the controller.
> > > > - external phys can only be configured by fec0, which means
> > > > fec1 can not work independently and both phys need to be
> > > > configured by mii_bus attached on fec0.
> > > > - mx28 fec reset will get mac address registers reset too.
> > > > - MII/RMII mode and 10M/100M speed are configured differently
> > > > from i.mx/mxs fec controller.
> > > > - ETHER_EN bit must be set to get interrupt work.
> > > >
> > > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > > ---
> > > > Changes for v2:
> > > > - Use module parameter fec.macaddr over new kernel command line
> > > > fec_mac to pass mac address
> > >
> > > Since you introduce this new kernel command line parameter in patch #3 of this
> > > series, why not just make it right in the first place? This should make both
> > > patches smaller and easier for review.
> > >
> > > > - Update comment in fec_get_mac() to stop using confusing word
> > > > "default"
> > > > - Fix copyright breakage in fec.h
> > >
> > > Ditto.
> > >
> > Sorry for rushing to send the patch set out. All these updates
> > should happen on patch #3 than #5. This is a serious problem,
> > and I will fix it soon and resend as v3.
> >
> > > > drivers/net/Kconfig | 7 ++-
> > > > drivers/net/fec.c | 139 ++++++++++++++++++++++++++++++++++++++++----------
> > > > drivers/net/fec.h | 5 +-
> > > > include/linux/fec.h | 3 +-
> > > > 4 files changed, 120 insertions(+), 34 deletions(-)
> > >
> > > [snip]
> > >
> > > > diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> > > > index f147508..b2b3e37 100644
> > > > --- a/drivers/net/fec.c
> > > > +++ b/drivers/net/fec.c
> > > > @@ -17,6 +17,8 @@
> > > > *
> > > > * Bug fixes and cleanup by Philippe De Muyter (phdm@macqel.be)
> > > > * Copyright (c) 2004-2006 Macq Electronique SA.
> > > > + *
> > > > + * Copyright (C) 2010 Freescale Semiconductor, Inc.
> > > > */
> > > >
> > > > #include <linux/module.h>
> > > > @@ -45,21 +47,34 @@
> > > >
> > > > #include <asm/cacheflush.h>
> > > >
> > > > -#ifndef CONFIG_ARCH_MXC
> > > > +#if !defined(CONFIG_ARCH_MXC) && !defined(CONFIG_SOC_IMX28)
> > > > #include <asm/coldfire.h>
> > > > #include <asm/mcfsim.h>
> > > > #endif
> > > >
> > > > #include "fec.h"
> > > >
> > > > -#ifdef CONFIG_ARCH_MXC
> > > > -#include <mach/hardware.h>
> > >
> > > Since you now remove mach/hardware.h for ARCH_MXC, does this build for all
> > > i.MX variants?
> > >
> > Did the test build for mx25, mx27, mx3 and mx51.
> >
> > > > +#ifdef CONFIG_SOC_IMX28
> > > > +/*
> > > > + * mx28 does not have MIIGSK registers
> > > > + */
> > > > +#undef FEC_MIIGSK_ENR
> > > > +#include <mach/mxs.h>
> > > > +#else
> > > > +#define cpu_is_mx28() (0)
> > > > +#endif
> > >
> > > This breaks kernels for multiple archs (e.g. i.MX28 and i.MX25). Please use
> > > run-time detection of CPU type, and do the MII/RMII etc. configuration
> > > accordingly.
> > >
> > I do not find a good way to detect cpu type. Neither adding a new
> > platform data field nor using __machine_arch_type to enumerate all
> > mx28 based machine (though there is only one currently) seems to be
> > good for me.
> >
> > I will try to manipulate some mx28 unique register to identify mx28
> > from other i.mx variants. Hopefully, it will work.
>
> There won't be a register which you can safely read on all i.MX
> variants.
> Why don't you implement it the same way the other i.MX do? They do not
> need SoC detection and the macro expands to 0 at compile time when the
> cpu is not enabled.
Alternatively you can use the approach I used for spi-imx and identify
the device by name.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: 'tcp: bind() fix when many ports are bound' problem
From: Daniel Baluta @ 2011-01-05 9:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Gaspar Chilingarov, netdev
In-Reply-To: <1294140172.3579.81.camel@edumazet-laptop>
On Tue, Jan 4, 2011 at 1:22 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 04 janvier 2011 à 13:12 +0400, Gaspar Chilingarov a écrit :
>> Hi there!
>>
>> Well, that looks strange.
>>
>> On my own side I've just put workaround (manually binding to all ports
>> in sequence :)
>> and moved production code to FreeBSD as it has better scalable network stack.
>>
>> I can see the potential problem with that bind() problem on highly
>> loaded DNS servers/resolvers which establish tons of outgoing UDP
>> connections.
>>
>> In some cases that connections could fail and as not receiving the
>> answer it is normal condition for DNS this will go totally unnoticed.
>>
>> I don't think anyone will hit this bug in production environment
>> except the very high load applications.
>
> Dont mix TCP and UDP, they are not the same.
>
> Problem with TCP is you can have TIME_WAIT sockets, disallowing a port
> to be reused. Not with UDP.
Isn't SO_REUSEADDR supposed to fix this problem?
Anyhow, inet_csk_get_port the function used by bind(0) performs bad.
Short reminder:
100 IP addr - 70K sockets created => 700 sockets per IP.
bind(0) for all sockets will results in a large number of
(port, addr) duplicates although there are more than 30000 ports available.
This wouldn't be so bad if you won't try to connect duplicates to the same
remote (addr, port) which will result in a connect failure.
Eric's patch introduced the restriction 'forbid two reuse enabled sockets
to bind on same (addr, port) tuple with a (non ANY addr)'.
Well, I think this will break rule #2 from inet_hastable.h:
"
If all sockets have sk->sk_reuse set, and none of them are in
TCP_LISTEN state, the port may be shared.
"
and also caused problem ([1]), don't really know if they are the same.
An attempt, to fix this was to "always allow a reuse listen if
no other listen is already active on the same IP".
The problem with this fix, is that at the moment of bind() we
don't know what will be the usage of this socket. It can be,
bind -> connect or bind -> listen.
>
> The connect() [without a previous bind()], or a sendto() [without a
> previous bind()] problem is more an API problem.
Can you share your thoughts on this?
Going back to my first email, are there any follow ups on your
"tcp: bind() fix when many ports are bound" patch. I've searched
netdev archives but no luck. I might have missed something.
I really appreciate your help.
thanks,
Daniel.
^ permalink raw reply
* Re: [PATCH v2 05/10] net/fec: add dual fec support for mx28
From: Sascha Hauer @ 2011-01-05 8:45 UTC (permalink / raw)
To: Shawn Guo
Cc: Baruch Siach, gerg, B32542, netdev, u.kleine-koenig, w.sang,
r64343, eric, bryan.wu, davem, linux-arm-kernel, lw
In-Reply-To: <20110104141259.GA21274@freescale.com>
On Tue, Jan 04, 2011 at 10:13:09PM +0800, Shawn Guo wrote:
> Hi Baruch,
>
> On Tue, Jan 04, 2011 at 11:59:16AM +0200, Baruch Siach wrote:
> > Hi Shawn,
> >
> > On Tue, Jan 04, 2011 at 05:24:11PM +0800, Shawn Guo wrote:
> > > This patch is to add mx28 dual fec support. Here are some key notes
> > > for mx28 fec controller.
> > >
> > > - mx28 fec design made an assumption that it runs on a
> > > big-endian system, which is incorrect. As the result, the
> > > driver has to swap every frame going to and coming from
> > > the controller.
> > > - external phys can only be configured by fec0, which means
> > > fec1 can not work independently and both phys need to be
> > > configured by mii_bus attached on fec0.
> > > - mx28 fec reset will get mac address registers reset too.
> > > - MII/RMII mode and 10M/100M speed are configured differently
> > > from i.mx/mxs fec controller.
> > > - ETHER_EN bit must be set to get interrupt work.
> > >
> > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > ---
> > > Changes for v2:
> > > - Use module parameter fec.macaddr over new kernel command line
> > > fec_mac to pass mac address
> >
> > Since you introduce this new kernel command line parameter in patch #3 of this
> > series, why not just make it right in the first place? This should make both
> > patches smaller and easier for review.
> >
> > > - Update comment in fec_get_mac() to stop using confusing word
> > > "default"
> > > - Fix copyright breakage in fec.h
> >
> > Ditto.
> >
> Sorry for rushing to send the patch set out. All these updates
> should happen on patch #3 than #5. This is a serious problem,
> and I will fix it soon and resend as v3.
>
> > > drivers/net/Kconfig | 7 ++-
> > > drivers/net/fec.c | 139 ++++++++++++++++++++++++++++++++++++++++----------
> > > drivers/net/fec.h | 5 +-
> > > include/linux/fec.h | 3 +-
> > > 4 files changed, 120 insertions(+), 34 deletions(-)
> >
> > [snip]
> >
> > > diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> > > index f147508..b2b3e37 100644
> > > --- a/drivers/net/fec.c
> > > +++ b/drivers/net/fec.c
> > > @@ -17,6 +17,8 @@
> > > *
> > > * Bug fixes and cleanup by Philippe De Muyter (phdm@macqel.be)
> > > * Copyright (c) 2004-2006 Macq Electronique SA.
> > > + *
> > > + * Copyright (C) 2010 Freescale Semiconductor, Inc.
> > > */
> > >
> > > #include <linux/module.h>
> > > @@ -45,21 +47,34 @@
> > >
> > > #include <asm/cacheflush.h>
> > >
> > > -#ifndef CONFIG_ARCH_MXC
> > > +#if !defined(CONFIG_ARCH_MXC) && !defined(CONFIG_SOC_IMX28)
> > > #include <asm/coldfire.h>
> > > #include <asm/mcfsim.h>
> > > #endif
> > >
> > > #include "fec.h"
> > >
> > > -#ifdef CONFIG_ARCH_MXC
> > > -#include <mach/hardware.h>
> >
> > Since you now remove mach/hardware.h for ARCH_MXC, does this build for all
> > i.MX variants?
> >
> Did the test build for mx25, mx27, mx3 and mx51.
>
> > > +#ifdef CONFIG_SOC_IMX28
> > > +/*
> > > + * mx28 does not have MIIGSK registers
> > > + */
> > > +#undef FEC_MIIGSK_ENR
> > > +#include <mach/mxs.h>
> > > +#else
> > > +#define cpu_is_mx28() (0)
> > > +#endif
> >
> > This breaks kernels for multiple archs (e.g. i.MX28 and i.MX25). Please use
> > run-time detection of CPU type, and do the MII/RMII etc. configuration
> > accordingly.
> >
> I do not find a good way to detect cpu type. Neither adding a new
> platform data field nor using __machine_arch_type to enumerate all
> mx28 based machine (though there is only one currently) seems to be
> good for me.
>
> I will try to manipulate some mx28 unique register to identify mx28
> from other i.mx variants. Hopefully, it will work.
There won't be a register which you can safely read on all i.MX
variants.
Why don't you implement it the same way the other i.MX do? They do not
need SoC detection and the macro expands to 0 at compile time when the
cpu is not enabled.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] net: r6040: Return proper error for r6040_init_one
From: Axel Lin @ 2011-01-05 8:40 UTC (permalink / raw)
To: linux-kernel; +Cc: Florian Fainelli, David S. Miller, netdev
Return -ENOMEM instead of 0 for the case of mdiobus_alloc and kmalloc failure.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/net/r6040.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 0b014c89..27e6f6d 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -1153,6 +1153,7 @@ static int __devinit r6040_init_one(struct pci_dev *pdev,
lp->mii_bus = mdiobus_alloc();
if (!lp->mii_bus) {
dev_err(&pdev->dev, "mdiobus_alloc() failed\n");
+ err = -ENOMEM;
goto err_out_unmap;
}
@@ -1165,6 +1166,7 @@ static int __devinit r6040_init_one(struct pci_dev *pdev,
lp->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
if (!lp->mii_bus->irq) {
dev_err(&pdev->dev, "mii_bus irq allocation failed\n");
+ err = -ENOMEM;
goto err_out_mdio;
}
--
1.7.2
^ permalink raw reply related
* [patch 2/2] dcb: use after free in dcb_flushapp()
From: Dan Carpenter @ 2011-01-05 7:03 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Shmulik Ravid, kernel-janitors, David S. Miller
The original code has a use after free bug because it's not using the
_safe() version of the list_for_each_entry() macro.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index 8881cb5..11bf6a2 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1650,9 +1650,10 @@ EXPORT_SYMBOL(dcb_setapp);
static void dcb_flushapp(void)
{
struct dcb_app_type *app;
+ struct dcb_app_type *tmp;
spin_lock(&dcb_lock);
- list_for_each_entry(app, &dcb_app_list, list) {
+ list_for_each_entry_safe(app, tmp, &dcb_app_list, list) {
list_del(&app->list);
kfree(app);
}
^ permalink raw reply related
* [patch 1/2] dcb: unlock on error in dcbnl_ieee_get()
From: Dan Carpenter @ 2011-01-05 7:03 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Shmulik Ravid, David S. Miller, kernel-janitors
There is a "goto nla_put_failure" hidden inside the NLA_PUT() macro, but
we're holding the dcb_lock so we need to unlock first.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index ff3c12d..8881cb5 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1264,9 +1264,14 @@ static int dcbnl_ieee_get(struct net_device *netdev, struct nlattr **tb,
spin_lock(&dcb_lock);
list_for_each_entry(itr, &dcb_app_list, list) {
- if (strncmp(itr->name, netdev->name, IFNAMSIZ) == 0)
- NLA_PUT(skb, DCB_ATTR_IEEE_APP,
- sizeof(itr->app), &itr->app);
+ if (strncmp(itr->name, netdev->name, IFNAMSIZ) == 0) {
+ err = nla_put(skb, DCB_ATTR_IEEE_APP, sizeof(itr->app),
+ &itr->app);
+ if (err) {
+ spin_unlock(&dcb_lock);
+ goto nla_put_failure;
+ }
+ }
}
spin_unlock(&dcb_lock);
nla_nest_end(skb, app);
^ permalink raw reply related
* Re: [RFC] sched: CHOKe packet scheduler
From: Eric Dumazet @ 2011-01-05 6:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110104162930.6fa672e3@nehalam>
Le mardi 04 janvier 2011 à 16:29 -0800, Stephen Hemminger a écrit :
> +static struct sk_buff *skb_peek_random(struct sk_buff_head *list)
> +{
> + struct sk_buff *skb = list->next;
> + unsigned int idx = net_random() % list->qlen;
> +
> + while (skb && idx-- > 0)
> + skb = skb->next;
> +
> + return skb;
> +}
You could avoid the divide op :
unsigned int idx = reciprocal_divide(random32(), list->qlen);
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler
From: Eric Dumazet @ 2011-01-05 6:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110104162930.6fa672e3@nehalam>
Le mardi 04 janvier 2011 à 16:29 -0800, Stephen Hemminger a écrit :
> This implements the CHOKe packet scheduler based on the existing
> Linux RED scheduler based on the algorithm described in the paper.
> Configuration is the same as RED; only the name changes.
>
> The core idea is:
> For every packet arrival:
> Calculate Qave
> if (Qave < minth) {
> Queue the new packet
> }
> Else {
> Select randomly a packet from the queue for their flow id
> Compare arriving packet with a randomly selected packet.
> If they have the same flow id {
> Drop both the packets
> }
> Else {
> if (Qave ≥ maxth) {
you mean if (Qave is less than maxth) ?
> Calculate the dropping probability pa
> Drop the packet with probability pa
> }
> Else {
> Drop the new packet
> }
> }
> }
>
> This an early access version.
>
No ECN support at all ? even RED supports it :)
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> net/sched/Kconfig | 11 +
> net/sched/Makefile | 1
> net/sched/sch_choke.c | 364 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 376 insertions(+)
>
> --- a/net/sched/Kconfig 2011-01-04 16:25:18.000000000 -0800
> +++ b/net/sched/Kconfig 2011-01-04 16:26:02.335973715 -0800
> @@ -205,6 +205,17 @@ config NET_SCH_DRR
>
> If unsure, say N.
>
> +config NET_SCH_CHOKE
> + tristate "CHOose and Keep responsive flow scheduler (CHOKE)"
> + help
> + Say Y here if you want to use the CHOKe packet scheduler (CHOose
> + and Keep for responsive flows, CHOose and Kill for unresponsive
> + flows). This is a variation of RED which trys to penalize flows
> + that monopolize the queue.
> +
> + To compile this code as a module, choose M here: the
> + module will be called sch_choke.
> +
> config NET_SCH_INGRESS
> tristate "Ingress Qdisc"
> depends on NET_CLS_ACT
> --- a/net/sched/Makefile 2011-01-04 16:25:18.000000000 -0800
> +++ b/net/sched/Makefile 2011-01-04 16:26:16.048938937 -0800
> @@ -32,6 +32,7 @@ obj-$(CONFIG_NET_SCH_MULTIQ) += sch_mult
> obj-$(CONFIG_NET_SCH_ATM) += sch_atm.o
> obj-$(CONFIG_NET_SCH_NETEM) += sch_netem.o
> obj-$(CONFIG_NET_SCH_DRR) += sch_drr.o
> +obj-$(CONFIG_NET_SCH_CHOKE) += sch_choke.o
> obj-$(CONFIG_NET_CLS_U32) += cls_u32.o
> obj-$(CONFIG_NET_CLS_ROUTE4) += cls_route.o
> obj-$(CONFIG_NET_CLS_FW) += cls_fw.o
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ b/net/sched/sch_choke.c 2011-01-04 16:25:33.913971468 -0800
> @@ -0,0 +1,364 @@
> +/*
> + * net/sched/sch_choke.c CHOKE scheduler
> + *
> + * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/skbuff.h>
> +#include <linux/ipv6.h>
> +#include <linux/jhash.h>
> +#include <net/pkt_sched.h>
> +#include <net/ip.h>
> +#include <net/red.h>
> +#include <net/ipv6.h>
> +
> +/* CHOKe stateless AQM for fair bandwidth allocation
> + =================================================
> +
> + Source:
> + R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
> + Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
> + IEEE INFOCOM, 2000.
> +
> + A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
> + Characteristics", IEEE/ACM Transactions on Networking, 2004
> +
> + ADVANTAGE:
> + - Penalizes unfair flows
> + - Random drop provide gradual feedback
> +
> + DRAWBACKS:
> + - Small queue for single flow
> + - Can be gamed by opening lots of connections
> + - Hard to get correct paremeters (same problem as RED)
Big packets are really unfair. Must disable TSO/GRO :)
> +
> + */
> +
> +struct choke_sched_data
> +{
> + u32 limit;
> + unsigned char flags;
> +
> + struct red_parms parms;
> + struct red_stats stats;
> +};
> +
> +/* Select a packet at random from the list.
> + * Same caveats as skb_peek.
> + */
> +static struct sk_buff *skb_peek_random(struct sk_buff_head *list)
> +{
> + struct sk_buff *skb = list->next;
> + unsigned int idx = net_random() % list->qlen;
> +
> + while (skb && idx-- > 0)
> + skb = skb->next;
Ouch... A linked list (using in skb anchors) is not appropriate data
structure. Thats too many cache lines misses.
Maybe using a q->limit array of skb pointers ?
> +
> + return skb;
> +}
> +
> +/* Given IP header and size find src/dst port pair */
> +static inline u32 get_ports(const void *hdr, size_t hdr_size, int offset)
> +{
> + return *(u32 *)(hdr + hdr_size + offset);
> +}
> +
> +
> +static bool same_flow(struct sk_buff *nskb, const struct sk_buff *oskb)
> +{
> + if (nskb->protocol != oskb->protocol)
> + return false;
> +
> + switch (nskb->protocol) {
> + case htons(ETH_P_IP):
> + {
> + const struct iphdr *iph1, *iph2;
> + int poff;
> +
> + if (!pskb_network_may_pull(nskb, sizeof(*iph1)))
> + return false;
Why isnt it necessary to also may_pull test oskb ?
> +
> + iph1 = ip_hdr(nskb);
> + iph2 = ip_hdr(oskb);
> +
> + if (iph1->protocol != iph2->protocol ||
> + iph1->daddr != iph2->daddr ||
> + iph1->saddr != iph2->saddr)
> + return false;
> +
> + /* Be hostile to new fragmented packets */
> + if (iph1->frag_off & htons(IP_MF|IP_OFFSET))
> + return true;
> +
> + if (iph2->frag_off & htons(IP_MF|IP_OFFSET))
> + return false;
> +
> + poff = proto_ports_offset(iph1->protocol);
> + if (poff >= 0 &&
> + pskb_network_may_pull(nskb, iph1->ihl * 4 + 4 + poff)) {
> + iph1 = ip_hdr(nskb);
> +
> + return get_ports(iph1, iph1->ihl * 4, poff)
> + == get_ports(iph2, iph2->ihl * 4, poff);
> + }
> +
> + return false;
> + }
> +
> + case htons(ETH_P_IPV6):
> + {
> + const struct ipv6hdr *iph1, *iph2;
> + int poff;
> +
> + if (!pskb_network_may_pull(nskb, sizeof(*iph1)))
> + return false;
same here.
> +
> + iph1 = ipv6_hdr(nskb);
> + iph2 = ipv6_hdr(oskb);
> +
> + if (iph1->nexthdr != iph2->nexthdr ||
> + ipv6_addr_cmp(&iph1->daddr, &iph2->daddr) != 0 ||
> + ipv6_addr_cmp(&iph1->saddr, &iph2->saddr) != 0)
> + return false;
> +
> + poff = proto_ports_offset(iph1->nexthdr);
> + if (poff >= 0 &&
> + pskb_network_may_pull(nskb, sizeof(*iph1) + 4 + poff)) {
> + iph1 = ipv6_hdr(nskb);
> +
> + return get_ports(iph1, sizeof(*iph1), poff)
> + == get_ports(iph2, sizeof(*iph2), poff);
> + }
> + return false;
> + }
> + default:
> + return false;
> + }
> +
> +}
> +
> +/*
> + * Decide what to do with new packet based on queue size.
> + * returns 1 if packet should be admitted
> + * 0 if packet should be dropped
> + */
> +static int choke_enqueue(struct sk_buff *skb, struct Qdisc *sch)
> +{
> + struct choke_sched_data *q = qdisc_priv(sch);
> + struct red_parms *p = &q->parms;
> +
> + p->qavg = red_calc_qavg(p, skb_queue_len(&sch->q));
> + if (red_is_idling(p))
> + red_end_of_idle_period(p);
> +
> + if (p->qavg <= p->qth_min)
> + p->qcount = -1;
> + else {
> + struct sk_buff *oskb;
> +
> + /* Draw a packet at random from queue */
> + oskb = skb_peek_random(&sch->q);
> +
> + /* Both packets from same flow? */
> + if (same_flow(skb, oskb)) {
> + /* Drop both packets */
> + __skb_unlink(oskb, &sch->q);
> + qdisc_drop(oskb, sch);
> + goto congestion_drop;
> + }
> +
> + if (p->qavg > p->qth_max) {
ok, maybe CHOKe paper used : if (p->qavg >= p->qth_max) ?
> + p->qcount = -1;
> +
> + sch->qstats.overlimits++;
> + q->stats.forced_drop++;
> + goto congestion_drop;
> + }
> +
> + if (++p->qcount) {
> + if (red_mark_probability(p, p->qavg)) {
> + p->qcount = 0;
> + p->qR = red_random(p);
> +
> + sch->qstats.overlimits++;
> + q->stats.prob_drop++;
> + goto congestion_drop;
> + }
> + } else
> + p->qR = red_random(p);
> + }
> +
> + /* Admit new packet */
> + if (likely(skb_queue_len(&sch->q) < q->limit))
> + return qdisc_enqueue_tail(skb, sch);
> +
> + q->stats.pdrop++;
> + sch->qstats.drops++;
> + kfree_skb(skb);
> + return NET_XMIT_DROP;
> +
> + congestion_drop:
> + qdisc_drop(skb, sch);
> + return NET_XMIT_CN;
> +}
> +
^ permalink raw reply
* Re: [PATCH] skge: 32bit DMA for ASUS A8N-SLI Premium
From: Shannon Wynter @ 2011-01-05 5:55 UTC (permalink / raw)
To: netdev
In-Reply-To: <4CF004EF.90107@fremnet.net>
I don't mean to be impatient but any progress with this?
On 27/11/10 05:05, Shannon Wynter wrote:
> Stephen Hemminger wrote:
>> On Fri, 26 Nov 2010 23:51:46 +1000
>> Shannon Wynter <kernel.org.alias@fremnet.net> wrote:
>>
>>> Add ASUS A8N-SLI Premium to the list of boards that require the
>>> quirk to
>>> limit DMA to 32bit in the skge.c module.
>>>
>>> Signed-off-by: Shannon Wynter <kernel.org.alias@fremnet.net>
>>> ---
>>> --- a/drivers/net/skge.c 2010-11-26 08:35:21.000000000 +1000
>>> +++ b/drivers/net/skge.c 2010-11-26 08:58:52.000000000 +1000
>>> @@ -4158,6 +4158,13 @@
>>> DMI_MATCH(DMI_BOARD_NAME, "nForce"),
>>> },
>>> },
>>> + {
>>> + .ident = "ASUSTeK A8N-SLI Premium",
>>> + .matches = {
>>> + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
>>> + DMI_MATCH(DMI_BOARD_NAME, "A8N-SLI Premium"),
>>> + },
>>> + },
>>> {}
>>> };
>>>
>>>
>>
>> Ok. Maybe I have to buy one of these beasts to find the root
>> cause of this.
>>
>
> It's quite an old board, I'd let you on mine and say go for your life
> but it's actually kind of mission critical (in so much as a home
> server can be).
>
> Is there anything I can provide/do/run for you to give you a head
> start in the right direction?
> The problem showed up when I upgraded from 1gb to 4gb of memory (the
> maximum the board can handle)
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] net: ixp4xx_eth: Return proper error for eth_init_one
From: Axel Lin @ 2011-01-05 5:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Krzysztof Halasa, David S. Miller, netdev
Return PTR_ERR(port->phydev) instead of 1 if phy_connect failed.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/net/arm/ixp4xx_eth.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/arm/ixp4xx_eth.c b/drivers/net/arm/ixp4xx_eth.c
index 6028226..9eb9b98 100644
--- a/drivers/net/arm/ixp4xx_eth.c
+++ b/drivers/net/arm/ixp4xx_eth.c
@@ -1229,8 +1229,10 @@ static int __devinit eth_init_one(struct platform_device *pdev)
snprintf(phy_id, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, "0", plat->phy);
port->phydev = phy_connect(dev, phy_id, &ixp4xx_adjust_link, 0,
PHY_INTERFACE_MODE_MII);
- if ((err = IS_ERR(port->phydev)))
+ if (IS_ERR(port->phydev)) {
+ err = PTR_ERR(port->phydev);
goto err_free_mem;
+ }
port->phydev->irq = PHY_POLL;
--
1.7.2
^ permalink raw reply related
* Re: [RFC] ECN and IP defragmentation
From: David Miller @ 2011-01-05 2:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1294186431.3420.19.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 05 Jan 2011 01:13:51 +0100
> It seems ip_fragment.c doesnt comply with RFC3168, section 5.3
>
> 5.3. Fragmentation
>
> ECN-capable packets MAY have the DF (Don't Fragment) bit set.
> Reassembly of a fragmented packet MUST NOT lose indications of
> congestion. In other words, if any fragment of an IP packet to be
> reassembled has the CE codepoint set, then one of two actions MUST be
> taken:
>
> * Set the CE codepoint on the reassembled packet. However, this
> MUST NOT occur if any of the other fragments contributing to
> this reassembly carries the Not-ECT codepoint.
>
> * The packet is dropped, instead of being reassembled, for any
> other reason.
>
> Should we fix this ?
Definitely, yes.
^ permalink raw reply
* [PATCH] include/linux/if_ether.h: Add #define ETH_P_LINK_CTL for HPNA and wlan local tunnel
From: Henry Ptasinski @ 2011-01-05 2:07 UTC (permalink / raw)
To: davem, joe; +Cc: henryp, brudley, arend, rvossen, dowan, netdev
In-Reply-To: <1292298831.26970.263.camel@Joe-Laptop>
Ethertype used by HPNA control protocols (LARQ, rate, link, etc) and by
Broadcom wlan drivers for local signalling.
Signed-off-by: Henry Ptasinski <henryp@broadcom.com>
---
include/linux/if_ether.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
index f9c3df0..be69043 100644
--- a/include/linux/if_ether.h
+++ b/include/linux/if_ether.h
@@ -72,6 +72,7 @@
#define ETH_P_MPLS_UC 0x8847 /* MPLS Unicast traffic */
#define ETH_P_MPLS_MC 0x8848 /* MPLS Multicast traffic */
#define ETH_P_ATMMPOA 0x884c /* MultiProtocol Over ATM */
+#define ETH_P_LINK_CTL 0x886c /* HPNA, wlan link local tunnel */
#define ETH_P_ATMFATE 0x8884 /* Frame-based ATM Transport
* over Ethernet
*/
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.
From: Mahesh Bandewar @ 2011-01-05 2:06 UTC (permalink / raw)
To: Rick Jones
Cc: Stephen Hemminger, Ben Hutchings, David Miller, Laurent Chavey,
Tom Herbert, netdev
In-Reply-To: <4D23CAA5.7060902@hp.com>
On Tue, Jan 4, 2011 at 5:34 PM, Rick Jones <rick.jones2@hp.com> wrote:
>>>> Since this is a boolean it SHOULD go into ethtool_flags rather than
>>>> being a high level operation.
>>>
>>> It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
>>> controlling offload features.
>>
>>
>> It just seems the number of hooks keeps growing which takes more space
>> and increases complexity.
>
> Is there any complication/downside to using flags in the (un?)likely event
> of wanting different flavors of loopback in the card?
The purpose of the patch is to stress / exercise the ingress/egress
path(s). So like Ben had suggested earlier to keep the loopback
implementation as near as possible to the host would streamline /
simplify the implementation & usage.
This is not a new patch and the earlier thread has an answer for this.
It's just that when I re-submitted this patch today, it went in as a
new patch! Here are the reference(s) the old thread -
http://marc.info/?l=linux-netdev&w=3&r=1&s=Allow+ethtool+to+set+interface&q=t
>
> rick jones
>
^ 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