* Re: [PATCH] hso: remove setting of low_latency flag
From: Filip Aben @ 2010-06-17 9:03 UTC (permalink / raw)
To: davem, gregkh; +Cc: linux-usb, netdev
In-Reply-To: <alpine.DEB.2.00.1006111100250.6812@filip-linux>
Hi all,
Did the patch below get accepted or is there a problem with it ?
Haven't seen it appearing in any git trees so far.
Thanks,
Filip-
On Fri, 2010-06-11 at 11:17 +0200, f.aben@option.com wrote:
> This patch removes the setting of the low_latency flag.
> tty_flip_buffer_push() is occasionally being called in irq context, which
> causes a hang if the low_latency flag is set.
> Removing the low_latency flag only seems to impact the flush to ldisc,
> which will now be put on a workqueue.
>
> Signed-off-by: Filip Aben <f.aben@option.com>
>
> ---
>
> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> index 0a3c41f..4dd2351 100644
> --- a/drivers/net/usb/hso.c
> +++ b/drivers/net/usb/hso.c
> @@ -1334,7 +1334,6 @@ static int hso_serial_open(struct tty_struct *tty, struct file *filp)
> /* check for port already opened, if not set the termios */
> serial->open_count++;
> if (serial->open_count == 1) {
> - tty->low_latency = 1;
> serial->rx_state = RX_IDLE;
> /* Force default termio settings */
> _hso_serial_set_termios(tty, NULL);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 v2 2/2] broadcom: Add 5241 support
From: Dmitry Eremin-Solenikov @ 2010-06-17 9:02 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Matt Carlson, Michael Chan
In-Reply-To: <1276765344-12675-1-git-send-email-dbaryshkov@gmail.com>
This patch adds the 5241 PHY ID to the broadcom module.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/net/phy/broadcom.c | 22 ++++++++++++++++++++++
include/linux/brcmphy.h | 1 +
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index b743d37..4accd83 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -834,6 +834,21 @@ static struct phy_driver bcmac131_driver = {
.driver = { .owner = THIS_MODULE },
};
+static struct phy_driver bcm5241_driver = {
+ .phy_id = PHY_ID_BCM5241,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM5241",
+ .features = PHY_BASIC_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = brcm_fet_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = brcm_fet_ack_interrupt,
+ .config_intr = brcm_fet_config_intr,
+ .driver = { .owner = THIS_MODULE },
+};
+
static int __init broadcom_init(void)
{
int ret;
@@ -868,8 +883,13 @@ static int __init broadcom_init(void)
ret = phy_driver_register(&bcmac131_driver);
if (ret)
goto out_ac131;
+ ret = phy_driver_register(&bcm5241_driver);
+ if (ret)
+ goto out_5241;
return ret;
+out_5241:
+ phy_driver_unregister(&bcmac131_driver);
out_ac131:
phy_driver_unregister(&bcm57780_driver);
out_57780:
@@ -894,6 +914,7 @@ out_5411:
static void __exit broadcom_exit(void)
{
+ phy_driver_unregister(&bcm5241_driver);
phy_driver_unregister(&bcmac131_driver);
phy_driver_unregister(&bcm57780_driver);
phy_driver_unregister(&bcm50610m_driver);
@@ -920,6 +941,7 @@ static struct mdio_device_id broadcom_tbl[] = {
{ PHY_ID_BCM50610M, 0xfffffff0 },
{ PHY_ID_BCM57780, 0xfffffff0 },
{ PHY_ID_BCMAC131, 0xfffffff0 },
+ { PHY_ID_BCM5241, 0xfffffff0 },
{ }
};
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index c14c3a1..b840a49 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -1,5 +1,6 @@
#define PHY_ID_BCM50610 0x0143bd60
#define PHY_ID_BCM50610M 0x0143bd70
+#define PHY_ID_BCM5241 0x0143bc30
#define PHY_ID_BCMAC131 0x0143bc70
#define PHY_ID_BCM5481 0x0143bca0
#define PHY_ID_BCM5482 0x0143bcb0
--
1.7.1
^ permalink raw reply related
* [PATCH v2 1/2] broadcom: move all PHY_ID's to header
From: Dmitry Eremin-Solenikov @ 2010-06-17 9:02 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Matt Carlson, Michael Chan
Move all PHY IDs to brcmphy.h header for completeness and unification of code.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/net/phy/broadcom.c | 24 ++++++++++++------------
include/linux/brcmphy.h | 6 ++++++
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index cecdbbd..b743d37 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -685,7 +685,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
}
static struct phy_driver bcm5411_driver = {
- .phy_id = 0x00206070,
+ .phy_id = PHY_ID_BCM5411,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5411",
.features = PHY_GBIT_FEATURES |
@@ -700,7 +700,7 @@ static struct phy_driver bcm5411_driver = {
};
static struct phy_driver bcm5421_driver = {
- .phy_id = 0x002060e0,
+ .phy_id = PHY_ID_BCM5421,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5421",
.features = PHY_GBIT_FEATURES |
@@ -715,7 +715,7 @@ static struct phy_driver bcm5421_driver = {
};
static struct phy_driver bcm5461_driver = {
- .phy_id = 0x002060c0,
+ .phy_id = PHY_ID_BCM5461,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5461",
.features = PHY_GBIT_FEATURES |
@@ -730,7 +730,7 @@ static struct phy_driver bcm5461_driver = {
};
static struct phy_driver bcm5464_driver = {
- .phy_id = 0x002060b0,
+ .phy_id = PHY_ID_BCM5464,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5464",
.features = PHY_GBIT_FEATURES |
@@ -745,7 +745,7 @@ static struct phy_driver bcm5464_driver = {
};
static struct phy_driver bcm5481_driver = {
- .phy_id = 0x0143bca0,
+ .phy_id = PHY_ID_BCM5481,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5481",
.features = PHY_GBIT_FEATURES |
@@ -760,7 +760,7 @@ static struct phy_driver bcm5481_driver = {
};
static struct phy_driver bcm5482_driver = {
- .phy_id = 0x0143bcb0,
+ .phy_id = PHY_ID_BCM5482,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5482",
.features = PHY_GBIT_FEATURES |
@@ -910,12 +910,12 @@ module_init(broadcom_init);
module_exit(broadcom_exit);
static struct mdio_device_id broadcom_tbl[] = {
- { 0x00206070, 0xfffffff0 },
- { 0x002060e0, 0xfffffff0 },
- { 0x002060c0, 0xfffffff0 },
- { 0x002060b0, 0xfffffff0 },
- { 0x0143bca0, 0xfffffff0 },
- { 0x0143bcb0, 0xfffffff0 },
+ { PHY_ID_BCM5411, 0xfffffff0 },
+ { PHY_ID_BCM5421, 0xfffffff0 },
+ { PHY_ID_BCM5461, 0xfffffff0 },
+ { PHY_ID_BCM5464, 0xfffffff0 },
+ { PHY_ID_BCM5482, 0xfffffff0 },
+ { PHY_ID_BCM5482, 0xfffffff0 },
{ PHY_ID_BCM50610, 0xfffffff0 },
{ PHY_ID_BCM50610M, 0xfffffff0 },
{ PHY_ID_BCM57780, 0xfffffff0 },
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 7f437ca..c14c3a1 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -1,6 +1,12 @@
#define PHY_ID_BCM50610 0x0143bd60
#define PHY_ID_BCM50610M 0x0143bd70
#define PHY_ID_BCMAC131 0x0143bc70
+#define PHY_ID_BCM5481 0x0143bca0
+#define PHY_ID_BCM5482 0x0143bcb0
+#define PHY_ID_BCM5411 0x00206070
+#define PHY_ID_BCM5421 0x002060e0
+#define PHY_ID_BCM5464 0x002060b0
+#define PHY_ID_BCM5461 0x002060c0
#define PHY_ID_BCM57780 0x03625d90
#define PHY_BCM_OUI_MASK 0xfffffc00
--
1.7.1
^ permalink raw reply related
* RE: [PATCH] vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
From: Vladislav Zolotarov @ 2010-06-17 8:56 UTC (permalink / raw)
To: Eric Dumazet, Arnd Bergmann
Cc: Patrick McHardy, Pedro Garcia, netdev@vger.kernel.org,
Ben Hutchings
In-Reply-To: <1276714691.2970.9.camel@edumazet-laptop>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Eric Dumazet
> Sent: Wednesday, June 16, 2010 9:58 PM
> To: Arnd Bergmann
> Cc: Patrick McHardy; Pedro Garcia; netdev@vger.kernel.org; Ben Hutchings
> Subject: Re: [PATCH] vlan_dev: VLAN 0 should be treated as "no vlan tag"
> (802.1p packet)
>
> Le mercredi 16 juin 2010 à 20:26 +0200, Arnd Bergmann a écrit :
> > On Wednesday 16 June 2010 17:28:23 Patrick McHardy wrote:
> >
> > > Since we don't have any special VLAN handling in the bridging code, I
> > > guess it comes down to optionally using a different ethertype value
> > > (0x88a8) in the VLAN code. We probably also need some indication from
> > > device drivers whether they are able to add these headers to avoid
> > > trying to offload tagging in case they're not.
> >
> > It's probably a little more than just supporting the new ethertype, but not
> > much. The outer tag can be handled like our current VLAN module does,
> > but the standard does not allow a regular frame to be encapsulated
> directly,
> > but rather requires one of
> >
> > 1. In 802.1ad: an 802.1Q VLAN tag (ethertype 0x8100) followed by the frame
> > 2. In 802.1ah: A service tag (ethertype 0x88e7) followed by the 802.1Q VLAN
> tag
> > and then the frame.
> >
> > Maybe what we can do is extend the vlan code to understand all three frame
> > formats (q, ad and ah) or at least the first two so we configure both the
> > provider VID and the Customer VID for the interface in case of 802.1ad but
> > only the regular VID in 802.1Q.
> >
> > Device drivers can then flag whether they support both formats or just
> > the regular Q tag.
> >
> > Arnd
>
> Speaking of device drivers, I see bnx2 (hardware accelerated) is able to
> insert a 8021q tag in case no vlgrp is defined (the 8201q tag that was
> removed by NIC)... interesting ping pong games, since our 8021q stack
> will remove it again, eventually.
>
> So VLAN 0 'problem' on bnx2 could be solved with following patch
> (avoiding this insert if vtag==0)
>
>
>
> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
> index 522de9f..b5d4d05 100644
> --- a/drivers/net/bnx2.c
> +++ b/drivers/net/bnx2.c
> @@ -3192,7 +3192,7 @@ bnx2_rx_int(struct bnx2 *bp, struct bnx2_napi *bnapi,
> int budget)
> hw_vlan = 1;
> else
> #endif
> - {
> + if (vtag) {
> struct vlan_ethhdr *ve = (struct vlan_ethhdr *)
> __skb_push(skb, 4);
>
>
>
> --
This way u will loose all the priority information that was on the VLAN header.
> 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
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Michael Chan @ 2010-06-17 6:24 UTC (permalink / raw)
To: 'davem@davemloft.net', 'Paul Mundt'
Cc: 'Mike Frysinger', James Bottomley, netdev@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
FUJITA Tomonori
In-Reply-To: <C27F8246C663564A84BB7AB3439772421B79CBCA1D@IRVEXCHCCR01.corp.ad.broadcom.com>
Michael Chan wrote:
>
> Paul Mundt wrote:
>
> > If you want to have a micro-optimization for the consistent DMA
> > case, you can check dma_is_consistent(), which is part of the API and
> > will be variable on certain platform configurations (ie, some may be
> > consistent with PCI but not on other busses, etc.)
> >
> >
>
> Thanks for the tip. I didn't know about the dma_is_consistent() API.
> I'll use this to fix it then.
>
David, why is dma_is_consistent() always returning 1 on sparc? The
streaming DMA is not consistent.
^ permalink raw reply
* RE: mpd client timeouts (bisected) 2.6.35-rc3
From: Shi, Alex @ 2010-06-17 5:16 UTC (permalink / raw)
To: Fastabend, John R, David Miller, markus@trippelsdorf.de
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
yanmin_zhang@linux.intel.com, Chen, Tim C
In-Reply-To: <4C15414E.5090201@intel.com>
It fixed the aim7/specjbb2005 issues!
Tested-by: Alex Shi <alex.shi@intel.com>
Regards!
Alex
>
>Needed to set the wcard bit in copy_skb_header otherwise it will not be cleared
>when called from skb_clone. Which then hits the loopback device gets pushed
>into the rx path and is eventually dropped. The following patch fixes this.
>Hopefully, this is easy and fast enough for you Dave.
>
>
>[PATCH] net: fix deliver_no_wcard regression on loopback device
>
>deliver_no_wcard is not being set in skb_copy_header.
>In the skb_cloned case it is not being cleared and
>may cause the skb to be dropped when the loopback device
>pushes it back up the stack.
>
>Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>---
>
> net/core/skbuff.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
>diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>index 9f07e74..bcf2fa3 100644
>--- a/net/core/skbuff.c
>+++ b/net/core/skbuff.c
>@@ -532,6 +532,7 @@ static void __copy_skb_header(struct sk_buff *new, const
>struct sk_buff *old)
> new->ip_summed = old->ip_summed;
> skb_copy_queue_mapping(new, old);
> new->priority = old->priority;
>+ new->deliver_no_wcard = old->deliver_no_wcard;
> #if defined(CONFIG_IP_VS) || defined(CONFIG_IP_VS_MODULE)
> new->ipvs_property = old->ipvs_property;
> #endif
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: James Bottomley @ 2010-06-17 4:20 UTC (permalink / raw)
To: Michael Chan
Cc: 'Mike Frysinger', netdev@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
FUJITA Tomonori
In-Reply-To: <C27F8246C663564A84BB7AB3439772421B79CBCA1C@IRVEXCHCCR01.corp.ad.broadcom.com>
On Wed, 2010-06-16 at 20:53 -0700, Michael Chan wrote:
> Mike Frysinger wrote:
>
> > On Wed, Jun 16, 2010 at 9:13 PM, James Bottomley wrote:
> > > I'm not quite sure whose fault this one is.
> > >
> > > However, this code in bnx2.c:
> > >
> > > if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
> > > next_rx_buf =
> > > &rxr->rx_buf_ring[
> > > RX_RING_IDX(NEXT_RX_BD(sw_cons))];
> > > prefetch(next_rx_buf->desc);
> > > }
> > >
> > > Looks remarkably fragile: what exactly is it trying to do?
>
> If sync_single is not defined, that means the CPU has a consistent
> view of next_rx_buf and so it makes sense to prefetch it.
That's not entirely a correct statement. Many architectures make a DMA
area coherent by turning off the CPU cache over it. In that case,
prefetching makes absolutely no sense (although it usually works but is
a nop).
> > > The commit that causes the problem:
> > >
> > > commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
> > > Author: Michael Chan <mchan@broadcom.com>
> > > Date: Thu May 6 08:58:13 2010 +0000
> > >
> > > bnx2: Add prefetches to rx path.
> > >
> > > Looks fairly innocuous by the description.
> > >
> > > Should parisc have a get_dma_ops()? We don't need one
> > because our dma
> > > ops are per platform not per bus.
> >
> > looks like it'll be broken on more than just parisc:
> > $ grep get_dma_ops arch/*/include/asm/ -rl | cut -d/ -f 2
> > alpha
> > ia64
> > microblaze
> > powerpc
> > sh
> > sparc
> > x86
>
> Most of these archs use the dma functions in:
>
> <asm-genric/dma-mapping-common.h>
>
> so it's not a problem.
Parisc begs to differ.
Plus you're making assumptions about the contents of the ops structure
which is an internal architecture object ... that's bound to run into
portability problems even if we make it compile on all platform.
> I think I'll send in a patch to remove that part of the code
> from bnx2.c for now.
I think that's the best solution.
James
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Michael Chan @ 2010-06-17 4:10 UTC (permalink / raw)
To: 'Paul Mundt'
Cc: 'Mike Frysinger', James Bottomley, netdev@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
FUJITA Tomonori
In-Reply-To: <20100617040356.GA8105@linux-sh.org>
Paul Mundt wrote:
> On Wed, Jun 16, 2010 at 08:53:57PM -0700, Michael Chan wrote:
> > If sync_single is not defined, that means the CPU has a consistent
> > view of next_rx_buf and so it makes sense to prefetch it.
> >
> Except that's not a valid assertion, there are platforms that
> implement
> it for sanity checks yet still have consistent DMA. You are making
> inherently non-portable assumptions for a PCI driver, which is a good
> example of why drivers should never be side-stepping the API
> in the first
> place. If you want to have a micro-optimization for the consistent DMA
> case, you can check dma_is_consistent(), which is part of the API and
> will be variable on certain platform configurations (ie, some may be
> consistent with PCI but not on other busses, etc.)
>
>
Thanks for the tip. I didn't know about the dma_is_consistent() API.
I'll use this to fix it then.
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Paul Mundt @ 2010-06-17 4:03 UTC (permalink / raw)
To: Michael Chan
Cc: 'Mike Frysinger', James Bottomley, netdev@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
FUJITA Tomonori
In-Reply-To: <C27F8246C663564A84BB7AB3439772421B79CBCA1C@IRVEXCHCCR01.corp.ad.broadcom.com>
On Wed, Jun 16, 2010 at 08:53:57PM -0700, Michael Chan wrote:
> Mike Frysinger wrote:
>
> > On Wed, Jun 16, 2010 at 9:13 PM, James Bottomley wrote:
> > > I'm not quite sure whose fault this one is.
> > >
> > > However, this code in bnx2.c:
> > >
> > > if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
> > > next_rx_buf =
> > > &rxr->rx_buf_ring[
> > > RX_RING_IDX(NEXT_RX_BD(sw_cons))];
> > > prefetch(next_rx_buf->desc);
> > > }
> > >
> > > Looks remarkably fragile: what exactly is it trying to do?
>
> If sync_single is not defined, that means the CPU has a consistent
> view of next_rx_buf and so it makes sense to prefetch it.
>
Except that's not a valid assertion, there are platforms that implement
it for sanity checks yet still have consistent DMA. You are making
inherently non-portable assumptions for a PCI driver, which is a good
example of why drivers should never be side-stepping the API in the first
place. If you want to have a micro-optimization for the consistent DMA
case, you can check dma_is_consistent(), which is part of the API and
will be variable on certain platform configurations (ie, some may be
consistent with PCI but not on other busses, etc.)
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Mike Frysinger @ 2010-06-17 4:00 UTC (permalink / raw)
To: Michael Chan
Cc: James Bottomley, netdev@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
FUJITA Tomonori
In-Reply-To: <C27F8246C663564A84BB7AB3439772421B79CBCA1C@IRVEXCHCCR01.corp.ad.broadcom.com>
On Wed, Jun 16, 2010 at 11:53 PM, Michael Chan wrote:
> Mike Frysinger wrote:
>> > The commit that causes the problem:
>> >
>> > commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
>> > Author: Michael Chan <mchan@broadcom.com>
>> > Date: Thu May 6 08:58:13 2010 +0000
>> >
>> > bnx2: Add prefetches to rx path.
>> >
>> > Looks fairly innocuous by the description.
>> >
>> > Should parisc have a get_dma_ops()? We don't need one
>> because our dma
>> > ops are per platform not per bus.
>>
>> looks like it'll be broken on more than just parisc:
>> $ grep get_dma_ops arch/*/include/asm/ -rl | cut -d/ -f 2
>> alpha
>> ia64
>> microblaze
>> powerpc
>> sh
>> sparc
>> x86
>
> Most of these archs use the dma functions in:
>
> <asm-genric/dma-mapping-common.h>
>
> so it's not a problem.
the grep is showing only the arches that define get_dma_ops (and so
the new code works). you'd have to invert the list to see the ones
which do not define get_dma_ops(), and the inverted list is larger.
that was merely my point.
-mike
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Michael Chan @ 2010-06-17 3:53 UTC (permalink / raw)
To: 'Mike Frysinger', James Bottomley
Cc: netdev@vger.kernel.org, linux-parisc@vger.kernel.org,
linux-kernel@vger.kernel.org, FUJITA Tomonori
In-Reply-To: <AANLkTilSfOwwT87mgDcWBogL4gPnM7VBTOALKpZv_upN@mail.gmail.com>
Mike Frysinger wrote:
> On Wed, Jun 16, 2010 at 9:13 PM, James Bottomley wrote:
> > I'm not quite sure whose fault this one is.
> >
> > However, this code in bnx2.c:
> >
> > if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
> > next_rx_buf =
> > &rxr->rx_buf_ring[
> > RX_RING_IDX(NEXT_RX_BD(sw_cons))];
> > prefetch(next_rx_buf->desc);
> > }
> >
> > Looks remarkably fragile: what exactly is it trying to do?
If sync_single is not defined, that means the CPU has a consistent
view of next_rx_buf and so it makes sense to prefetch it.
> >
> > The commit that causes the problem:
> >
> > commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
> > Author: Michael Chan <mchan@broadcom.com>
> > Date: Thu May 6 08:58:13 2010 +0000
> >
> > bnx2: Add prefetches to rx path.
> >
> > Looks fairly innocuous by the description.
> >
> > Should parisc have a get_dma_ops()? We don't need one
> because our dma
> > ops are per platform not per bus.
>
> looks like it'll be broken on more than just parisc:
> $ grep get_dma_ops arch/*/include/asm/ -rl | cut -d/ -f 2
> alpha
> ia64
> microblaze
> powerpc
> sh
> sparc
> x86
Most of these archs use the dma functions in:
<asm-genric/dma-mapping-common.h>
so it's not a problem.
I think I'll send in a patch to remove that part of the code
from bnx2.c for now.
Thanks.
^ permalink raw reply
* Re: ftp on udp and tcp .
From: Narendra Choyal @ 2010-06-17 2:31 UTC (permalink / raw)
To: Ben Hutchings; +Cc: ratheesh k, netdev, linux-net
In-Reply-To: <1276602615.14011.464.camel@localhost>
TCP handles segmentation and bandwidth/congestion management. It
recovers from packet loss and reordering. Recent implementations are
also quite resilient to address spoofing. The downsides are higher
latency (potentially very high when recovering from packet loss), higher
setup cost (3-way handshake), and lack of multicast support.
UDP does none of that. It gives you flexibility and control, but the
downside is you have to handle all of those problems yourself.
Its nice but.
Initial checking of availability for both active port & passive port.
^ permalink raw reply
* [PATCH] sky2: enable rx/tx in sky2_phy_reinit()
From: Brandon Philips @ 2010-06-17 2:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem
sky2_phy_reinit is called by the ethtool helpers sky2_set_settings,
sky2_nway_reset and sky2_set_pauseparam when netif_running.
However, at the end of sky2_phy_init GM_GP_CTRL has GM_GPCR_RX_ENA and
GM_GPCR_TX_ENA cleared. So, doing these commands causes the device to
stop working:
$ ethtool -r eth0
$ ethtool -A eth0 autoneg off
Fix this issue by enabling Rx/Tx after running sky2_phy_init in
sky2_phy_reinit.
Signed-off-by: Brandon Philips <bphilips@suse.de>
Tested-by: Brandon Philips <bphilips@suse.de>
Cc: stable@kernel.org
---
drivers/net/sky2.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 2111c7b..7985165 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -717,11 +717,24 @@ static void sky2_phy_power_down(struct sky2_hw *hw, unsigned port)
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
+/* Enable Rx/Tx */
+static void sky2_enable_rx_tx(struct sky2_port *sky2)
+{
+ struct sky2_hw *hw = sky2->hw;
+ unsigned port = sky2->port;
+ u16 reg;
+
+ reg = gma_read16(hw, port, GM_GP_CTRL);
+ reg |= GM_GPCR_RX_ENA | GM_GPCR_TX_ENA;
+ gma_write16(hw, port, GM_GP_CTRL, reg);
+}
+
/* Force a renegotiation */
static void sky2_phy_reinit(struct sky2_port *sky2)
{
spin_lock_bh(&sky2->phy_lock);
sky2_phy_init(sky2->hw, sky2->port);
+ sky2_enable_rx_tx(sky2);
spin_unlock_bh(&sky2->phy_lock);
}
@@ -2040,7 +2053,6 @@ static void sky2_link_up(struct sky2_port *sky2)
{
struct sky2_hw *hw = sky2->hw;
unsigned port = sky2->port;
- u16 reg;
static const char *fc_name[] = {
[FC_NONE] = "none",
[FC_TX] = "tx",
@@ -2048,10 +2060,7 @@ static void sky2_link_up(struct sky2_port *sky2)
[FC_BOTH] = "both",
};
- /* enable Rx/Tx */
- reg = gma_read16(hw, port, GM_GP_CTRL);
- reg |= GM_GPCR_RX_ENA | GM_GPCR_TX_ENA;
- gma_write16(hw, port, GM_GP_CTRL, reg);
+ sky2_enable_rx_tx(sky2);
gm_phy_write(hw, port, PHY_MARV_INT_MASK, PHY_M_DEF_MSK);
--
1.7.1
^ permalink raw reply related
* Re: iputils flowlabel
From: YOSHIFUJI Hideaki @ 2010-06-17 2:20 UTC (permalink / raw)
To: Jiri Skala; +Cc: netdev
In-Reply-To: <1272444708.3035.39.camel@localhost.localdomain>
Jiri Skala wrote:
> I'd like to ask about current state of FLOWLABEL functionality. This is
> currently wrapped into define and disabled by default.
>
> Trying to enable it means to define (somehow = in proprietary header)
> in6_flowlabel_req structure because usage of linux/in6.h conflicts with
> glibc's headers.
>
> Is flowlabel fnc inside ifdef due to described 'header' issue? Any other
> comment to this topic?
Yes, that's right.
--yoshfuji
^ permalink raw reply
* Re: [PATCH] iputils/ping_common.c: avoid gethostbyaddr during ping flood
From: YOSHIFUJI Hideaki @ 2010-06-17 2:08 UTC (permalink / raw)
To: Chris Caputo; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.1006170104000.26819@nacho.alt.net>
Chris Caputo wrote:
> On Wed, 6 Feb 2008, Chris Caputo wrote:
>> Unless a destination is specified by IP address, a ping flood results in a
>> gethostbyaddr() for every echo reply. Thus a DNS flood can accompany a
>> ping flood.
>
> Updated for iputils-s20100418... Can someone review and work into next
> release?
Applied, thanks.
--yoshfuji
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Mike Frysinger @ 2010-06-17 1:17 UTC (permalink / raw)
To: James Bottomley
Cc: netdev, linux-parisc, linux-kernel, FUJITA Tomonori, Michael Chan
In-Reply-To: <1276737229.2847.853.camel@mulgrave.site>
On Wed, Jun 16, 2010 at 9:13 PM, James Bottomley wrote:
> I'm not quite sure whose fault this one is.
>
> However, this code in bnx2.c:
>
> if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
> next_rx_buf =
> &rxr->rx_buf_ring[
> RX_RING_IDX(NEXT_RX_BD(sw_cons))];
> prefetch(next_rx_buf->desc);
> }
>
> Looks remarkably fragile: what exactly is it trying to do?
>
> The commit that causes the problem:
>
> commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
> Author: Michael Chan <mchan@broadcom.com>
> Date: Thu May 6 08:58:13 2010 +0000
>
> bnx2: Add prefetches to rx path.
>
> Looks fairly innocuous by the description.
>
> Should parisc have a get_dma_ops()? We don't need one because our dma
> ops are per platform not per bus.
looks like it'll be broken on more than just parisc:
$ grep get_dma_ops arch/*/include/asm/ -rl | cut -d/ -f 2
alpha
ia64
microblaze
powerpc
sh
sparc
x86
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" 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
* Re: [PATCH v2] ucc_geth: fix for RX skb buffers recycling
From: David Miller @ 2010-06-17 1:17 UTC (permalink / raw)
To: geomatsi; +Cc: netdev, leoli, avorontsov
In-Reply-To: <20100614203520.23a02c25@realm>
From: Sergey Matyukevich <geomatsi@gmail.com>
Date: Mon, 14 Jun 2010 20:35:20 +0400
> This patch implements a proper modification of RX skb buffers before
> recycling. Adjusting only skb->data is not enough because after that
> skb->tail and skb->len become incorrect.
>
> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: David Miller @ 2010-06-17 1:16 UTC (permalink / raw)
To: JBottomley; +Cc: netdev, linux-parisc, linux-kernel, fujita.tomonori, mchan
In-Reply-To: <1276737229.2847.853.camel@mulgrave.site>
From: James Bottomley <JBottomley@Novell.com>
Date: Wed, 16 Jun 2010 20:13:49 -0500
> However, this code in bnx2.c:
>
> if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
> next_rx_buf =
> &rxr->rx_buf_ring[
> RX_RING_IDX(NEXT_RX_BD(sw_cons))];
> prefetch(next_rx_buf->desc);
> }
>
> Looks remarkably fragile: what exactly is it trying to do?
>
> The commit that causes the problem:
>
> commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
> Author: Michael Chan <mchan@broadcom.com>
> Date: Thu May 6 08:58:13 2010 +0000
>
> bnx2: Add prefetches to rx path.
>
> Looks fairly innocuous by the description.
>
> Should parisc have a get_dma_ops()? We don't need one because our dma
> ops are per platform not per bus.
I think asking for get_dma_ops() directly in a driver is dodgy at
best, especially one that is meant to compile on any PCI supporting
system. At least right now.
^ permalink raw reply
* Re: [PATCH] iputils/ping_common.c: avoid gethostbyaddr during ping flood
From: Chris Caputo @ 2010-06-17 1:08 UTC (permalink / raw)
To: netdev, Yoshifuji Hideaki
In-Reply-To: <Pine.LNX.4.64.0802061401370.31285@nacho.alt.net>
On Wed, 6 Feb 2008, Chris Caputo wrote:
> Unless a destination is specified by IP address, a ping flood results in a
> gethostbyaddr() for every echo reply. Thus a DNS flood can accompany a
> ping flood.
Updated for iputils-s20100418... Can someone review and work into next
release?
Thanks,
Chris
---
Unless a destination is specified by IP address, a ping flood results in a
gethostbyaddr() for every echo reply. Thus a DNS flood can accompany a
ping flood.
This patch makes it so a gethostbyaddr() is not performed with each echo
reply during a ping flood.
Signed-off-by: Chris Caputo <ccaputo@alt.net>
-------
--- iputils-s20100418/ping_common.c 2010-04-18 04:45:45.000000000 +0000
+++ iputils-dev/ping_common.c 2010-06-17 01:00:59.000000000 +0000
@@ -118,10 +118,6 @@ void common_options(int ch)
case 'D':
options |= F_PTIMEOFDAY;
break;
- case 'f':
- options |= F_FLOOD;
- setbuf(stdout, (char *)NULL);
- break;
case 'i': /* wait between sending packets */
{
if (strchr(optarg, '.')) {
@@ -183,6 +179,10 @@ void common_options(int ch)
exit(2);
}
break;
+ case 'f':
+ options |= F_FLOOD;
+ setbuf(stdout, (char *)NULL);
+ /* fallthrough to numeric - avoid gethostbyaddr during flood */
case 'n':
options |= F_NUMERIC;
break;
^ permalink raw reply
* bnx2 fails to compile on parisc because of missing get_dma_ops()
From: James Bottomley @ 2010-06-17 1:13 UTC (permalink / raw)
To: netdev, linux-parisc, linux-kernel, FUJITA Tomonori; +Cc: Michael Chan
I'm not quite sure whose fault this one is.
However, this code in bnx2.c:
if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
next_rx_buf =
&rxr->rx_buf_ring[
RX_RING_IDX(NEXT_RX_BD(sw_cons))];
prefetch(next_rx_buf->desc);
}
Looks remarkably fragile: what exactly is it trying to do?
The commit that causes the problem:
commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
Author: Michael Chan <mchan@broadcom.com>
Date: Thu May 6 08:58:13 2010 +0000
bnx2: Add prefetches to rx path.
Looks fairly innocuous by the description.
Should parisc have a get_dma_ops()? We don't need one because our dma
ops are per platform not per bus.
James
^ permalink raw reply
* Re: [PATCH net-next-2.6] be2net: enable ipv6 tso support
From: David Miller @ 2010-06-17 1:13 UTC (permalink / raw)
To: ajitk; +Cc: netdev
In-Reply-To: <20100614145557.GA12552@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Mon, 14 Jun 2010 20:26:07 +0530
> Add ipv6 support to the be2net driver.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied, thanks.
^ permalink raw reply
* Re: Broken rndis_host with #define DEBUG (by a475f603d23392f386e45cf377b17c30ed3bbb80)
From: David Miller @ 2010-06-17 1:11 UTC (permalink / raw)
To: david-b; +Cc: jussi.kivilinna, joe, netdev, dbrownell
In-Reply-To: <299618.58880.qm@web180304.mail.gq1.yahoo.com>
From: David Brownell <david-b@pacbell.net>
Date: Sat, 12 Jun 2010 19:49:27 -0700 (PDT)
> --- On Sat, 6/12/10, Joe Perches <joe@perches.com> wrote:
>
>> > rndis_host oopses with #define DEBUG, in
>> generic_rndis_bind() when
>> > calling netif_dbg(). Problem is that
>> (netdev)->dev.parent is NULL
>
>> > (used in netdev_printk) while generic_rndis_bind is
>> called.Thanks.
>
> Should have been assigned by SET_NETDEV_DEV()
> in usbnet_probe() ... before calling the
> bind() routine
>
> Maybe just moving that SET_NETDEV_DEV earlier
> would suffice.
Can someone please submit a patch which does this?
Thanks!
^ permalink raw reply
* Re: [PATCH kernel 2.6.35-rc2] pcnet_cs: add new id (TOSHIBA Modem/LAN Card)
From: David Miller @ 2010-06-17 1:11 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20100612191728.2d272cc1.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sat, 12 Jun 2010 19:17:28 +0900
>
> pcnet_cs:
> serial_cs:
> add new id (TOSHIBA Modem/LAN Card)
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] gianfar: Fix oversized packets handling
From: David Miller @ 2010-06-17 1:09 UTC (permalink / raw)
To: avorontsov; +Cc: Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100611205103.GA4255@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Sat, 12 Jun 2010 00:51:03 +0400
> Issuing the following command on host:
>
> $ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1
>
> Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0)
> oops like this:
...
> Dumped buffer descriptors showed that eTSEC's length/truncation
> logic sometimes passes oversized packets, i.e. for the above ICMP
> packet the following two buffer descriptors may become ready:
>
> status=1400 length=1536
> status=1800 length=1541
>
> So, it seems that gianfar actually receives the whole big frame,
> and it tries to place the packet into two BDs. This situation
> confuses the driver, and so the skb_put() sanity check fails.
>
> This patch fixes the issue by adding an appropriate check, i.e.
> the driver should not try to process frames with buffer
> descriptor's length over rx_buffer_size (i.e. maxfrm and mrblr).
>
> Note that sometimes eTSEC works correctly, i.e. in the second
> (last) buffer descriptor bits 'truncated' and 'crcerr' are set,
> and so there's no oops. Though I couldn't find any logic when
> it works correctly and when not.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied, thanks Anton.
^ permalink raw reply
* Re: udp: Add UFO to NETIF_F_SOFTWARE_GSO
From: David Miller @ 2010-06-17 1:08 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20100615062104.GA4779@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 15 Jun 2010 16:21:04 +1000
> udp: Add UFO to NETIF_F_SOFTWARE_GSO
>
> This patch adds UFO to the list of GSO features with a software
> fallback. This allows UFO to be used even if the hardware does
> not support it.
>
> In particular, this allows us to test the UFO fallback, as it
> has been reported to not work in some cases.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied to net-next-2.6, thanks.
^ 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