* [PATCH] net/neighbour.h: fix typo
From: Kulikov Vasiliy @ 2010-06-30 16:08 UTC (permalink / raw)
To: Jiri Kosina
Cc: David S. Miller, Tejun Heo, Eric W. Biederman, Eric Dumazet,
Stephen Hemminger, netdev, linux-kernel
'Shoul' must be 'should'.
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
include/net/neighbour.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index eb21340..242879b 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -151,7 +151,7 @@ struct neigh_table {
void (*proxy_redo)(struct sk_buff *skb);
char *id;
struct neigh_parms parms;
- /* HACK. gc_* shoul follow parms without a gap! */
+ /* HACK. gc_* should follow parms without a gap! */
int gc_interval;
int gc_thresh1;
int gc_thresh2;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: Anton Vorontsov @ 2010-06-30 16:38 UTC (permalink / raw)
To: David Miller
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100629.151626.90794001.davem@davemloft.net>
On Tue, Jun 29, 2010 at 03:16:26PM -0700, David Miller wrote:
>
> I really don't see any value at all to this config option,
> the errata fixup code should be there all the time.
Well, at least for eTSEC76 erratum (patch 2/3) we have to touch
fast path (i.e. start_xmit), so I just wanted to make zero
overhead for controllers that don't need any fixups.
Not that there's much of the overhead in a single additional
'if' condition, no. ;-)
> It really does no harm to be there in the cases where it isn't
> used, and forcing users to turn this on is just another
> obscure way to end up with an incorrect configuration.
OK, resending the new patches, without Kconfig stuff...
If we'll have too many or too big errata so that it would cause
major performance or code size penalty for non-affected SOCs, we
can always do:
enum gfar_errata {
#ifdef CONFIG_PPC_FOO
GFAR_ERRATA_FOO = 0x01,
#else
GFAR_ERRATA_FOO = 0,
#endif
}
And then, priv->errata & GFAR_ERRATA_FOO will be optimized
away by the compiler.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH v2 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: Anton Vorontsov @ 2010-06-30 16:39 UTC (permalink / raw)
To: David Miller
Cc: Manfred Rudigier, Sandeep Gopalpet, Andy Fleming, netdev,
linuxppc-dev
In-Reply-To: <20100630163804.GA636@oksana.dev.rtsoft.ru>
MPC8313ECE says:
"If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
which are larger than MAXFRM, the controller truncates the frames to
length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller
also erroneously marks RxBD[TR]=1 if the received frame length is MAXFRM
or MAXFRM-1, even though those frames are not truncated.
No truncation or truncation error occurs if MACCFG2[Huge Frame]=1."
There are two options to workaround the issue:
"1. Set MACCFG2[Huge Frame]=1, so no truncation occurs for invalid large
frames. Software can determine if a frame is larger than MAXFRM by
reading RxBD[LG] or RxBD[Data Length].
2. Set MAXFRM to 1538 (0x602) instead of the default 1536 (0x600), so
normal-length frames are not marked as truncated. Software can examine
RxBD[Data Length] to determine if the frame was larger than MAXFRM-2."
This patch implements the first workaround option by setting HUGEFRAME
bit, and gfar_clean_rx_ring() already checks the RxBD[Data Length].
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/gianfar.c | 29 +++++++++++++++++++++++++++--
drivers/net/gianfar.h | 11 +++++++++++
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 28b53d1..9abcb39 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -85,6 +85,7 @@
#include <linux/net_tstamp.h>
#include <asm/io.h>
+#include <asm/reg.h>
#include <asm/irq.h>
#include <asm/uaccess.h>
#include <linux/module.h>
@@ -928,6 +929,24 @@ static void gfar_init_filer_table(struct gfar_private *priv)
}
}
+static void gfar_detect_errata(struct gfar_private *priv)
+{
+ struct device *dev = &priv->ofdev->dev;
+ unsigned int pvr = mfspr(SPRN_PVR);
+ unsigned int svr = mfspr(SPRN_SVR);
+ unsigned int mod = (svr >> 16) & 0xfff6; /* w/o E suffix */
+ unsigned int rev = svr & 0xffff;
+
+ /* MPC8313 Rev 2.0 and higher; All MPC837x */
+ if ((pvr == 0x80850010 && mod == 0x80b0 && rev >= 0x0020) ||
+ (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
+ priv->errata |= GFAR_ERRATA_74;
+
+ if (priv->errata)
+ dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
+ priv->errata);
+}
+
/* Set up the ethernet device structure, private data,
* and anything else we need before we start */
static int gfar_probe(struct of_device *ofdev,
@@ -960,6 +979,8 @@ static int gfar_probe(struct of_device *ofdev,
dev_set_drvdata(&ofdev->dev, priv);
regs = priv->gfargrp[0].regs;
+ gfar_detect_errata(priv);
+
/* Stop the DMA engine now, in case it was running before */
/* (The firmware could have used it, and left it running). */
gfar_halt(dev);
@@ -974,7 +995,10 @@ static int gfar_probe(struct of_device *ofdev,
gfar_write(®s->maccfg1, tempval);
/* Initialize MACCFG2. */
- gfar_write(®s->maccfg2, MACCFG2_INIT_SETTINGS);
+ tempval = MACCFG2_INIT_SETTINGS;
+ if (gfar_has_errata(priv, GFAR_ERRATA_74))
+ tempval |= MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK;
+ gfar_write(®s->maccfg2, tempval);
/* Initialize ECNTRL */
gfar_write(®s->ecntrl, ECNTRL_INIT_SETTINGS);
@@ -2300,7 +2324,8 @@ static int gfar_change_mtu(struct net_device *dev, int new_mtu)
* to allow huge frames, and to check the length */
tempval = gfar_read(®s->maccfg2);
- if (priv->rx_buffer_size > DEFAULT_RX_BUFFER_SIZE)
+ if (priv->rx_buffer_size > DEFAULT_RX_BUFFER_SIZE ||
+ gfar_has_errata(priv, GFAR_ERRATA_74))
tempval |= (MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK);
else
tempval &= ~(MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK);
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index ac4a92e..0a0483c 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1025,6 +1025,10 @@ struct gfar_priv_grp {
char int_name_er[GFAR_INT_NAME_MAX];
};
+enum gfar_errata {
+ GFAR_ERRATA_74 = 0x01,
+};
+
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
* (Ok, that's not so true anymore, but there is a family resemblence)
* The GFAR buffer descriptors track the ring buffers. The rx_bd_base
@@ -1049,6 +1053,7 @@ struct gfar_private {
struct device_node *node;
struct net_device *ndev;
struct of_device *ofdev;
+ enum gfar_errata errata;
struct gfar_priv_grp gfargrp[MAXGROUPS];
struct gfar_priv_tx_q *tx_queue[MAX_TX_QS];
@@ -1111,6 +1116,12 @@ struct gfar_private {
extern unsigned int ftp_rqfpr[MAX_FILER_IDX + 1];
extern unsigned int ftp_rqfcr[MAX_FILER_IDX + 1];
+static inline int gfar_has_errata(struct gfar_private *priv,
+ enum gfar_errata err)
+{
+ return priv->errata & err;
+}
+
static inline u32 gfar_read(volatile unsigned __iomem *addr)
{
u32 val;
--
1.7.0.5
^ permalink raw reply related
* [PATCH v2 2/3] gianfar: Implement workaround for eTSEC76 erratum
From: Anton Vorontsov @ 2010-06-30 16:39 UTC (permalink / raw)
To: David Miller
Cc: Manfred Rudigier, Sandeep Gopalpet, Andy Fleming, netdev,
linuxppc-dev
In-Reply-To: <20100630163804.GA636@oksana.dev.rtsoft.ru>
MPC8313ECE says:
"For TOE=1 huge or jumbo frames, the data required to generate the
checksum may exceed the 2500-byte threshold beyond which the controller
constrains itself to one memory fetch every 256 eTSEC system clocks.
This throttling threshold is supposed to trigger only when the
controller has sufficient data to keep transmit active for the duration
of the memory fetches. The state machine handling this threshold,
however, fails to take large TOE frames into account. As a result,
TOE=1 frames larger than 2500 bytes often see excess delays before start
of transmission."
This patch implements the workaround as suggested by the errata
document, i.e.:
"Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to
memory throttling.
When using packets larger than 2700 bytes, it is recommended to turn TOE
off."
To be sure, we limit the TOE frames to 2500 bytes, and do software
checksumming instead.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/gianfar.c | 19 +++++++++++++++++++
drivers/net/gianfar.h | 1 +
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 9abcb39..8ba2973 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -942,6 +942,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_74;
+ /* MPC8313 and MPC837x all rev */
+ if ((pvr == 0x80850010 && mod == 0x80b0) ||
+ (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
+ priv->errata |= GFAR_ERRATA_76;
+
if (priv->errata)
dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
priv->errata);
@@ -2011,6 +2016,20 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
unsigned int nr_frags, nr_txbds, length;
union skb_shared_tx *shtx;
+ /*
+ * TOE=1 frames larger than 2500 bytes may see excess delays
+ * before start of transmission.
+ */
+ if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_76) &&
+ skb->ip_summed == CHECKSUM_PARTIAL &&
+ skb->len > 2500)) {
+ int ret;
+
+ ret = skb_checksum_help(skb);
+ if (ret)
+ return ret;
+ }
+
rq = skb->queue_mapping;
tx_queue = priv->tx_queue[rq];
txq = netdev_get_tx_queue(dev, rq);
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index 0a0483c..c414374 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1027,6 +1027,7 @@ struct gfar_priv_grp {
enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
+ GFAR_ERRATA_76 = 0x02,
};
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
--
1.7.0.5
^ permalink raw reply related
* [PATCH v2 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
From: Anton Vorontsov @ 2010-06-30 16:39 UTC (permalink / raw)
To: David Miller
Cc: Manfred Rudigier, Sandeep Gopalpet, Andy Fleming, netdev,
linuxppc-dev
In-Reply-To: <20100630163804.GA636@oksana.dev.rtsoft.ru>
MPC8313ECE says:
"If the controller receives a 1- or 2-byte frame (such as an illegal
runt packet or a packet with RX_ER asserted) before GRS is asserted
and does not receive any other frames, the controller may fail to set
GRSC even when the receive logic is completely idle. Any subsequent
receive frame that is larger than two bytes will reset the state so
the graceful stop can complete. A MAC receiver (Rx) reset will also
reset the state."
This patch implements the proposed workaround:
"If IEVENT[GRSC] is still not set after the timeout, read the eTSEC
register at offset 0xD1C. If bits 7-14 are the same as bits 23-30,
the eTSEC Rx is assumed to be idle and the Rx can be safely reset.
If the register fields are not equal, wait for another timeout
period and check again."
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/gianfar.c | 40 +++++++++++++++++++++++++++++++++++++---
drivers/net/gianfar.h | 1 +
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8ba2973..35626eb 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -947,6 +947,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_76;
+ /* MPC8313 and MPC837x all rev */
+ if ((pvr == 0x80850010 && mod == 0x80b0) ||
+ (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
+ priv->errata |= GFAR_ERRATA_A002;
+
if (priv->errata)
dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
priv->errata);
@@ -1570,6 +1575,29 @@ static void init_registers(struct net_device *dev)
gfar_write(®s->minflr, MINFLR_INIT_SETTINGS);
}
+static int __gfar_is_rx_idle(struct gfar_private *priv)
+{
+ u32 res;
+
+ /*
+ * Normaly TSEC should not hang on GRS commands, so we should
+ * actually wait for IEVENT_GRSC flag.
+ */
+ if (likely(!gfar_has_errata(priv, GFAR_ERRATA_A002)))
+ return 0;
+
+ /*
+ * Read the eTSEC register at offset 0xD1C. If bits 7-14 are
+ * the same as bits 23-30, the eTSEC Rx is assumed to be idle
+ * and the Rx can be safely reset.
+ */
+ res = gfar_read((void __iomem *)priv->gfargrp[0].regs + 0xd1c);
+ res &= 0x7f807f80;
+ if ((res & 0xffff) == (res >> 16))
+ return 1;
+
+ return 0;
+}
/* Halt the receive and transmit queues */
static void gfar_halt_nodisable(struct net_device *dev)
@@ -1593,12 +1621,18 @@ static void gfar_halt_nodisable(struct net_device *dev)
tempval = gfar_read(®s->dmactrl);
if ((tempval & (DMACTRL_GRS | DMACTRL_GTS))
!= (DMACTRL_GRS | DMACTRL_GTS)) {
+ int ret;
+
tempval |= (DMACTRL_GRS | DMACTRL_GTS);
gfar_write(®s->dmactrl, tempval);
- spin_event_timeout(((gfar_read(®s->ievent) &
- (IEVENT_GRSC | IEVENT_GTSC)) ==
- (IEVENT_GRSC | IEVENT_GTSC)), -1, 0);
+ do {
+ ret = spin_event_timeout(((gfar_read(®s->ievent) &
+ (IEVENT_GRSC | IEVENT_GTSC)) ==
+ (IEVENT_GRSC | IEVENT_GTSC)), 1000000, 0);
+ if (!ret && !(gfar_read(®s->ievent) & IEVENT_GRSC))
+ ret = __gfar_is_rx_idle(priv);
+ } while (!ret);
}
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index c414374..710810e 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1028,6 +1028,7 @@ struct gfar_priv_grp {
enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
GFAR_ERRATA_76 = 0x02,
+ GFAR_ERRATA_A002 = 0x04,
};
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
--
1.7.0.5
^ permalink raw reply related
* Re: [PATCH 3/3] pm_qos: get rid of the allocation in pm_qos_add_request()
From: Daniel Walker @ 2010-06-30 16:45 UTC (permalink / raw)
To: James Bottomley; +Cc: Takashi Iwai, linux-pm, markgross, netdev
In-Reply-To: <1277763049.10879.204.camel@mulgrave.site>
On Mon, 2010-06-28 at 17:10 -0500, James Bottomley wrote:
> On Mon, 2010-06-28 at 23:59 +0200, Rafael J. Wysocki wrote:
> > On Monday, June 28, 2010, James Bottomley wrote:
> > > Since every caller has to squirrel away the returned pointer anyway,
> > > they might as well supply the memory area. This fixes a bug in a few of
> > > the call sites where the returned pointer was dereferenced without
> > > checking it for NULL (which gets returned if the kzalloc failed).
> > >
> > > I'd like to hear how sound and netdev feels about this: it will add
> > > about two more pointers worth of data to struct netdev and struct
> > > snd_pcm_substream .. but I think it's worth it. If you're OK, I'll add
> > > your acks and send through the pm tree.
> > >
> > > This also looks to me like an android independent clean up (even though
> > > it renders the request_add atomically callable). I also added include
> > > guards to include/linux/pm_qos_params.h
> > >
> > > cc: netdev@vger.kernel.org
> > > cc: Takashi Iwai <tiwai@suse.de>
> > > Signed-off-by: James Bottomley <James.Bottomley@suse.de>
> >
> > I like all of the patches in this series, thanks a lot for doing this!
> >
> > I guess it might be worth sending a CC to the LKML next round so that people
> > can see [1/3] (I don't expect any objections, but anyway it would be nice).
>
> I cc'd the latest owners of plist.h ... although Daniel Walker has
> apparently since left MontaVista, Thomas Gleixner is still current ...
> and he can speak for the RT people, who are the primary plist users.
>
> I can do another round and cc lkml, I was just hoping this would be the
> last revision.
I'm still paying attention tho .. I didn't see anything objection worthy
in the plist changes.. If you do send another round you might want to
add Oleg Nesterov , most of the code was redone by him ..
Daniel
^ permalink raw reply
* RE: [Pv-drivers] [PATCH net-next-2.6 3/3] vmxnet3: Remove incorrect implementation of ethtool_ops::get_flags()
From: Bhavesh Davda @ 2010-06-30 16:46 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, VMware, Inc., netdev@vger.kernel.org
In-Reply-To: <1277913534.2082.28.camel@achroite.uk.solarflarecom.com>
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Wednesday, June 30, 2010 8:59 AM
>
> On Wed, 2010-06-30 at 08:44 -0700, Bhavesh Davda wrote:
> > Thanks for fixing this, Ben! Had to look at ethtool-2.6.34 src to
> > convince myself of the correctness. Looks good to me.
> >
> > Signed-off-by: Bhavesh Davda <bhavesh@vmware.com>
> >
> > ps: I do wonder, however, why not always use ethtool_op_get_flags for
> > all drivers, and mask whatever is returned by the driver specific
> > dev->ethtool_ops->get_flags with flags_dup_features instead of this
> > approach?
>
> I think you're right that ethtool_op_get_flags could be the implicit
> default (i.e. used if ethtool_ops::get_flags is NULL) and drivers
> should
> not have to set it. Following this change, no drivers in net-next-2.6
> will be using any other implementation. However, I don't think
> ethtool_ops::get_flags should be removed - in future there are likely
> to
> be additional ethtool flags that do not correspond to net device
> feature
> flags, and some drivers will need a different implementation.
>
> Ben.
>
Hi Ben,
I'm not suggesting nuking ethtool_ops::get_flags. What I was suggesting is *always* calling ethtool_ops_get_flags from dev_ethtool for case ETHTOOL_GFLAGS, but doing something like this simple patch:
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index a0f4964..f5da6ed 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -139,8 +139,9 @@ u32 ethtool_op_get_flags(struct net_device *dev)
* handling for flags which are not so easily handled
* by a simple masking operation
*/
-
- return dev->features & flags_dup_features;
+ return (dev->ethtool_ops->get_flags ?
+ dev->ethtool_ops->get_flags(dev) :
+ dev->features) & flags_dup_features;
}
EXPORT_SYMBOL(ethtool_op_get_flags);
@@ -1495,9 +1496,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
break;
case ETHTOOL_GFLAGS:
rc = ethtool_get_value(dev, useraddr, ethcmd,
- (dev->ethtool_ops->get_flags ?
- dev->ethtool_ops->get_flags :
- ethtool_op_get_flags));
+ ethtool_op_get_flags);
break;
case ETHTOOL_SFLAGS:
rc = ethtool_set_value(dev, useraddr,
Plus nuking all such code in the netdev drivers:
.get_flags = ethtool_op_get_flags,
This is still pretty fragile and could lead to infinite recursion if some drivers are missed. But you get the idea.
Thanks
- Bhavesh
^ permalink raw reply related
* Re: [PATCH] igbvf: avoid name clash between PF and VF
From: Casey Leedom @ 2010-06-30 16:59 UTC (permalink / raw)
To: Stefan Assmann
Cc: netdev, e1000-devel, Duyck, Alexander H, gregory.v.rose,
jeffrey.t.kirsher, Andy Gospodarek
In-Reply-To: <4C2B0614.9040004@redhat.com>
| From: Stefan Assmann <sassmann@redhat.com>
| Date: Wednesday, June 30, 2010 01:53 am
|
| This is not a udev bug since udev doesn't create persistent rules for
| VFs as their MAC address changes every reboot.
|
| To avoid this problem we could change the kernel name for the VFs and
| thus avoid confusion between VFs and PFs.
|
| I've already discussed this with Alexander Duyck and Greg Rose, so far
| they have no objection. However this problem appears for all drivers that
| support PFs and VFs and thus the changes should be applied consistently
| to all of these drivers.
I'm not sure that this problem affects "all drivers which support PFs and VFs."
I think that you might mean "all drivers which support PFs and VFs with non-
persistent MAC addresses for the VFs." For instance, the MAC addresses
associated with the new cxgb4vf VFs are persistent so, from what I understand of
the scenario you outlined, I don't think that they would trigger the problem you
describe. Please correct me if I've missed something. Thanks.
Casey
^ permalink raw reply
* Re: [PATCH] usb: pegasus: fixed coding style issues
From: David Miller @ 2010-06-30 17:26 UTC (permalink / raw)
To: nikai-bVCNqDZ4lKNeoWH0uzbU5w
Cc: petkan-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100626185854.4a3eff43-m0oTu1HmxXpuhsjpcywf5g@public.gmane.org>
From: Nicolas Kaiser <nikai-bVCNqDZ4lKNeoWH0uzbU5w@public.gmane.org>
Date: Sat, 26 Jun 2010 18:58:54 +0200
> Fixed brace, static initialization, comment, whitespace and spacing
> coding style issues.
>
> Signed-off-by: Nicolas Kaiser <nikai-bVCNqDZ4lKNeoWH0uzbU5w@public.gmane.org>
Applied to net-next-2.6, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 1/2] ipv6: Clamp reported valid_lft to a minimum of 0
From: David Miller @ 2010-06-30 17:28 UTC (permalink / raw)
To: ben; +Cc: yoshfuji, kaber, 514644, piotr.lewandowski, netdev
In-Reply-To: <1277588267.26161.300.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sat, 26 Jun 2010 22:37:47 +0100
> Since addresses are only revalidated every 2 minutes, the reported
> valid_lft can underflow shortly before the address is deleted.
> Clamp it to a minimum of 0, as for prefered_lft.
>
> Reported-by: Piotr Lewandowski <piotr.lewandowski@gmail.com>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/2] ipv6: Use interface max_desync_factor instead of static default
From: David Miller @ 2010-06-30 17:29 UTC (permalink / raw)
To: ben; +Cc: yoshfuji, kaber, 514646, piotr.lewandowski, netdev
In-Reply-To: <1277588575.26161.311.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sat, 26 Jun 2010 22:42:55 +0100
> max_desync_factor can be configured per-interface, but nothing is
> using the value.
>
> Reported-by: Piotr Lewandowski <piotr.lewandowski@gmail.com>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH v2] net/core: use ntohs for skb->protocol
From: David Miller @ 2010-06-30 17:39 UTC (permalink / raw)
To: sebastian; +Cc: netdev
In-Reply-To: <20100630090229.GB25541@Chamillionaire.breakpoint.cc>
From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Date: Wed, 30 Jun 2010 11:02:29 +0200
> From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
> This is only noticed by people that are not doing everything correct in
> the first place.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] xfrm: fix XFRMA_MARK extraction in xfrm_mark_get
From: David Miller @ 2010-06-30 17:41 UTC (permalink / raw)
To: andreas.steffen; +Cc: netdev, hadi
In-Reply-To: <4C2AF8EE.8030508@strongswan.org>
From: Andreas Steffen <andreas.steffen@strongswan.org>
Date: Wed, 30 Jun 2010 09:57:34 +0200
> Determine the size of the xfrm_mark struct, not of its pointer.
>
> Signed-off-by: Andreas Steffen <andreas.steffen@strongswan.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] netfilter: remove deprecated config option NF_CT_ACCT
From: David Miller @ 2010-06-30 17:48 UTC (permalink / raw)
To: kaber; +Cc: jpirko, netdev, ole
In-Reply-To: <4C2B49B9.5050302@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 30 Jun 2010 15:42:17 +0200
> I usually leave those for the architecture maintainers.
Right, that's how this is supposed to work. If we update defconfigs
every time we make some Kconfig change it's going to be nothing but
pain for arch folks.
^ permalink raw reply
* TCP not triggering a fast retransmit?
From: Ivan Novick @ 2010-06-30 18:04 UTC (permalink / raw)
To: netdev; +Cc: jmatthews, Tim Heath
[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]
Hello all,
Attached is a packet capture from my application that is running on
RedHat Enterprise Linux 5.4
I am seeing a Retransmission timeout but I was hoping this case would
go into fast retransmit and not RTO.
I am wondering why did the sender not send more data? If the sender
was to send more data and extend the window then it would seem the
duplicate acks or SACKS should trigger fast retransmit.
The application does not constantly send data, but data should arrive
to be sent before 200 milliseconds that it takes for the RTO.
Is it possible that there was no data to send and the window is not
advanced and the sender is waiting for an ACK. Then data arrives half
way into the RTO 200 milliseconds while waiting for an outstanding ACK
but the window is not advanced?
You can see right after the RTO and retransmission additional data is
sent, so there is additional data. In theory that additional data
could be arriving right at the 200 milliseconds point, but we see this
pattern in the dump regularly and I believe data is there before the
end of the 200 milliseconds RTO.
As a related point the advertised window from the receiver seems to be
a constant value of 22060, so either the receiver is handling its data
fast enough to never have to reduce its window... or this number is
really not used to indicate space available currently in the receive
window?
Any feedback to help understand why we are not doing fast retransmit
and or why the sender is not extending the window would be greatly
appreciated.
Cheers,
Ivan Novick
[-- Attachment #2: sender_backoff.cap --]
[-- Type: application/octet-stream, Size: 3076 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163804.GA636@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:38:04 +0400
> On Tue, Jun 29, 2010 at 03:16:26PM -0700, David Miller wrote:
>>
>> I really don't see any value at all to this config option,
>> the errata fixup code should be there all the time.
>
> Well, at least for eTSEC76 erratum (patch 2/3) we have to touch
> fast path (i.e. start_xmit), so I just wanted to make zero
> overhead for controllers that don't need any fixups.
>
> Not that there's much of the overhead in a single additional
> 'if' condition, no. ;-)
The register accesses will dominate the costs with this chip.
The only case where a if() test is going to potentially create
some practical performance impact is if the TX is performed
purely using changes to a shared memory data structure and
absolutely no MMIO register reads or writes.
^ permalink raw reply
* Re: [PATCH v2 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163912.GA23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:12 +0400
> MPC8313ECE says:
>
> "If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
> which are larger than MAXFRM, the controller truncates the frames to
> length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller
> also erroneously marks RxBD[TR]=1 if the received frame length is MAXFRM
> or MAXFRM-1, even though those frames are not truncated.
> No truncation or truncation error occurs if MACCFG2[Huge Frame]=1."
>
> There are two options to workaround the issue:
>
> "1. Set MACCFG2[Huge Frame]=1, so no truncation occurs for invalid large
> frames. Software can determine if a frame is larger than MAXFRM by
> reading RxBD[LG] or RxBD[Data Length].
>
> 2. Set MAXFRM to 1538 (0x602) instead of the default 1536 (0x600), so
> normal-length frames are not marked as truncated. Software can examine
> RxBD[Data Length] to determine if the frame was larger than MAXFRM-2."
>
> This patch implements the first workaround option by setting HUGEFRAME
> bit, and gfar_clean_rx_ring() already checks the RxBD[Data Length].
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/3] gianfar: Implement workaround for eTSEC76 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163913.GB23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:13 +0400
> MPC8313ECE says:
>
> "For TOE=1 huge or jumbo frames, the data required to generate the
> checksum may exceed the 2500-byte threshold beyond which the controller
> constrains itself to one memory fetch every 256 eTSEC system clocks.
>
> This throttling threshold is supposed to trigger only when the
> controller has sufficient data to keep transmit active for the duration
> of the memory fetches. The state machine handling this threshold,
> however, fails to take large TOE frames into account. As a result,
> TOE=1 frames larger than 2500 bytes often see excess delays before start
> of transmission."
>
> This patch implements the workaround as suggested by the errata
> document, i.e.:
>
> "Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to
> memory throttling.
> When using packets larger than 2700 bytes, it is recommended to turn TOE
> off."
>
> To be sure, we limit the TOE frames to 2500 bytes, and do software
> checksumming instead.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163915.GC23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:15 +0400
> MPC8313ECE says:
>
> "If the controller receives a 1- or 2-byte frame (such as an illegal
> runt packet or a packet with RX_ER asserted) before GRS is asserted
> and does not receive any other frames, the controller may fail to set
> GRSC even when the receive logic is completely idle. Any subsequent
> receive frame that is larger than two bytes will reset the state so
> the graceful stop can complete. A MAC receiver (Rx) reset will also
> reset the state."
>
> This patch implements the proposed workaround:
>
> "If IEVENT[GRSC] is still not set after the timeout, read the eTSEC
> register at offset 0xD1C. If bits 7-14 are the same as bits 23-30,
> the eTSEC Rx is assumed to be idle and the Rx can be safely reset.
> If the register fields are not equal, wait for another timeout
> period and check again."
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* pull request: wireless-2.6 2010-06-30
From: John W. Linville @ 2010-06-30 18:53 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
David,
Here are a few more fixes intended for 2.6.35. Included are a couple of
small regression fixes for iwlwifi, one that causes connection stalls with
802.11n on some devices and another which could disable multicast traffic.
Also included is an ath9k fix which avoids a null pointer dereference
resulting from a timer leak.
Please let me know if there are problems!
John
---
The following changes since commit d3ead2413cb99d3e6265577b12537434e229d8c2:
Guillaume Gaudonville (1):
ixgbe: skip non IPv4 packets in ATR filter
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Johannes Berg (1):
iwlwifi: fix multicast
Vasanthakumar Thiagarajan (1):
ath9k: Fix bug in starting ani
Wey-Yi Guy (1):
iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 11 ++++++++++-
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 6 +-----
drivers/net/wireless/iwlwifi/iwl-core.c | 7 ++++++-
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index fbb7dec..5ea8773 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -445,6 +445,7 @@ void ath_deinit_leds(struct ath_softc *sc);
#define SC_OP_TSF_RESET BIT(11)
#define SC_OP_BT_PRIORITY_DETECTED BIT(12)
#define SC_OP_BT_SCAN BIT(13)
+#define SC_OP_ANI_RUN BIT(14)
/* Powersave flags */
#define PS_WAIT_FOR_BEACON BIT(0)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index abfa049..1e2a68e 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -336,6 +336,10 @@ set_timer:
static void ath_start_ani(struct ath_common *common)
{
unsigned long timestamp = jiffies_to_msecs(jiffies);
+ struct ath_softc *sc = (struct ath_softc *) common->priv;
+
+ if (!(sc->sc_flags & SC_OP_ANI_RUN))
+ return;
common->ani.longcal_timer = timestamp;
common->ani.shortcal_timer = timestamp;
@@ -872,11 +876,13 @@ static void ath9k_bss_assoc_info(struct ath_softc *sc,
/* Reset rssi stats */
sc->sc_ah->stats.avgbrssi = ATH_RSSI_DUMMY_MARKER;
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
} else {
ath_print(common, ATH_DBG_CONFIG, "Bss Info DISASSOC\n");
common->curaid = 0;
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
}
}
@@ -1478,8 +1484,10 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
if (vif->type == NL80211_IFTYPE_AP ||
vif->type == NL80211_IFTYPE_ADHOC ||
- vif->type == NL80211_IFTYPE_MONITOR)
+ vif->type == NL80211_IFTYPE_MONITOR) {
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
+ }
out:
mutex_unlock(&sc->mutex);
@@ -1500,6 +1508,7 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
mutex_lock(&sc->mutex);
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
/* Reclaim beacon resources */
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
index 44ef5d9..01658cf 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
@@ -212,11 +212,7 @@ static void iwlagn_chain_noise_reset(struct iwl_priv *priv)
static void iwlagn_rts_tx_cmd_flag(struct ieee80211_tx_info *info,
__le32 *tx_flags)
{
- if ((info->control.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS) ||
- (info->control.rates[0].flags & IEEE80211_TX_RC_USE_CTS_PROTECT))
- *tx_flags |= TX_CMD_FLG_RTS_CTS_MSK;
- else
- *tx_flags &= ~TX_CMD_FLG_RTS_CTS_MSK;
+ *tx_flags |= TX_CMD_FLG_RTS_CTS_MSK;
}
/* Calc max signal level (dBm) among 3 possible receivers */
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 426e955..5bbc529 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -1314,7 +1314,6 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
changed_flags, *total_flags);
CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
- CHK(FIF_ALLMULTI, RXON_FILTER_ACCEPT_GRP_MSK);
CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
@@ -1329,6 +1328,12 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
mutex_unlock(&priv->mutex);
+ /*
+ * Receiving all multicast frames is always enabled by the
+ * default flags setup in iwl_connection_init_rx_config()
+ * since we currently do not support programming multicast
+ * filters into the device.
+ */
*total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
}
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: pull request: wireless-2.6 2010-06-30
From: David Miller @ 2010-06-30 19:05 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100630185319.GA2618-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 30 Jun 2010 14:53:20 -0400
> Here are a few more fixes intended for 2.6.35. Included are a couple of
> small regression fixes for iwlwifi, one that causes connection stalls with
> 802.11n on some devices and another which could disable multicast traffic.
> Also included is an ath9k fix which avoids a null pointer dereference
> resulting from a timer leak.
>
> Please let me know if there are problems!
...
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Pulled, thanks John.
> @@ -1329,6 +1328,12 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
>
> mutex_unlock(&priv->mutex);
>
> + /*
> + * Receiving all multicast frames is always enabled by the
> + * default flags setup in iwl_connection_init_rx_config()
> + * since we currently do not support programming multicast
> + * filters into the device.
> + */
> *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
> FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
Note that this is an amazingly serious limitation.
This basically makes iwl chips unsuitable for use on networks where
real multicast use is common.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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/neighbour.h: fix typo
From: David Miller @ 2010-06-30 19:07 UTC (permalink / raw)
To: segooon
Cc: trivial, tj, ebiederm, eric.dumazet, shemminger, netdev,
linux-kernel
In-Reply-To: <1277914095-25905-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Wed, 30 Jun 2010 20:08:15 +0400
> 'Shoul' must be 'should'.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] act_nat: use stack variable
From: David Miller @ 2010-06-30 19:12 UTC (permalink / raw)
To: herbert; +Cc: hadi, xiaosuo, netdev
In-Reply-To: <20100630103005.GA24688@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 30 Jun 2010 18:30:05 +0800
> On Wed, Jun 30, 2010 at 06:25:21AM -0400, jamal wrote:
>> On Wed, 2010-06-30 at 17:07 +0800, Changli Gao wrote:
>> > act_nat: use stack variable
>> >
>> > structure tc_nat isn't too big for stack, so we can put it in stack.
>> >
>> > Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>>
>> Doesnt look unreasonable - will let Herbert make the call..
>
> Looks good to me too.
Applied.
^ permalink raw reply
* Re: [PATCH] act_mirred: combine duplicate code
From: David Miller @ 2010-06-30 19:13 UTC (permalink / raw)
To: hadi; +Cc: xiaosuo, netdev
In-Reply-To: <1277894942.3509.25.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Wed, 30 Jun 2010 06:49:02 -0400
> On Wed, 2010-06-30 at 06:24 -0400, jamal wrote:
>
>> m->tcf_qstats.drops.
>
> Sorry - this nagged me - we are already incrementing overlimits - we
> should increment drops. Scratch that too. I am going to say your patch
> as is:
> signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied.
Jamal, please capitalize "Signed-off-by" in the future, thanks.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-06-30
From: Johannes Berg @ 2010-06-30 19:15 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20100630.120551.170116973.davem@davemloft.net>
On Wed, 2010-06-30 at 12:05 -0700, David Miller wrote:
> > + /*
> > + * Receiving all multicast frames is always enabled by the
> > + * default flags setup in iwl_connection_init_rx_config()
> > + * since we currently do not support programming multicast
> > + * filters into the device.
> > + */
> > *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
> > FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
>
> Note that this is an amazingly serious limitation.
>
> This basically makes iwl chips unsuitable for use on networks where
> real multicast use is common.
Lots of wireless devices have this limitation unfortunately. I think we
-might- be able to have proper filters for iwl, but haven't found out
quite how yet unfortunately, if it's actually implemented properly on
the device and there's not just some fake API.
johannes
^ 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