Netdev List
 help / color / mirror / Atom feed
* [PATCH net-next V2 7/7] microblaze: include the new timecounter header.
From: Richard Cochran @ 2015-01-02 19:22 UTC (permalink / raw)
  To: netdev; +Cc: David Miller, John Stultz
In-Reply-To: <cover.1420226266.git.richardcochran@gmail.com>

The timecounter/cyclecounter code has moved, so users need the new include.

Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
 arch/microblaze/kernel/timer.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
index dd96f0e..c897745 100644
--- a/arch/microblaze/kernel/timer.c
+++ b/arch/microblaze/kernel/timer.c
@@ -17,6 +17,7 @@
 #include <linux/clockchips.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/timecounter.h>
 #include <asm/cpuinfo.h>
 
 static void __iomem *timer_baseaddr;
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH net-next V2 6/7] mlx4: include clocksource.h again
From: Richard Cochran @ 2015-01-02 19:22 UTC (permalink / raw)
  To: netdev; +Cc: David Miller, John Stultz
In-Reply-To: <cover.1420226266.git.richardcochran@gmail.com>

This driver uses the function, clocksource_khz2mult, and so it really must
include clocksource.h.

Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
 drivers/net/ethernet/mellanox/mlx4/en_clock.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_clock.c b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
index e9cce4f..90b5309 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_clock.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
@@ -32,6 +32,7 @@
  */
 
 #include <linux/mlx4/device.h>
+#include <linux/clocksource.h>
 
 #include "mlx4_en.h"
 
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH net-next V2 5/7] ixgbe: convert to CYCLECOUNTER_MASK macro.
From: Richard Cochran @ 2015-01-02 19:22 UTC (permalink / raw)
  To: netdev; +Cc: David Miller, John Stultz
In-Reply-To: <cover.1420226266.git.richardcochran@gmail.com>

Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
index 47c29ea..79c00f5 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
@@ -793,7 +793,7 @@ void ixgbe_ptp_start_cyclecounter(struct ixgbe_adapter *adapter)
 
 	memset(&adapter->cc, 0, sizeof(adapter->cc));
 	adapter->cc.read = ixgbe_ptp_read;
-	adapter->cc.mask = CLOCKSOURCE_MASK(64);
+	adapter->cc.mask = CYCLECOUNTER_MASK(64);
 	adapter->cc.shift = shift;
 	adapter->cc.mult = 1;
 
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH net-next V2 4/7] igb: convert to CYCLECOUNTER_MASK macro.
From: Richard Cochran @ 2015-01-02 19:22 UTC (permalink / raw)
  To: netdev; +Cc: David Miller, John Stultz
In-Reply-To: <cover.1420226266.git.richardcochran@gmail.com>

Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
 drivers/net/ethernet/intel/igb/igb_ptp.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
index 8baf3fd..5e7a4e3 100644
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -19,7 +19,6 @@
 #include <linux/device.h>
 #include <linux/pci.h>
 #include <linux/ptp_classify.h>
-#include <linux/clocksource.h>
 
 #include "igb.h"
 
@@ -766,7 +765,7 @@ void igb_ptp_init(struct igb_adapter *adapter)
 		adapter->ptp_caps.settime = igb_ptp_settime_82576;
 		adapter->ptp_caps.enable = igb_ptp_feature_enable;
 		adapter->cc.read = igb_ptp_read_82576;
-		adapter->cc.mask = CLOCKSOURCE_MASK(64);
+		adapter->cc.mask = CYCLECOUNTER_MASK(64);
 		adapter->cc.mult = 1;
 		adapter->cc.shift = IGB_82576_TSYNC_SHIFT;
 		/* Dial the nominal frequency. */
@@ -786,7 +785,7 @@ void igb_ptp_init(struct igb_adapter *adapter)
 		adapter->ptp_caps.settime = igb_ptp_settime_82576;
 		adapter->ptp_caps.enable = igb_ptp_feature_enable;
 		adapter->cc.read = igb_ptp_read_82580;
-		adapter->cc.mask = CLOCKSOURCE_MASK(IGB_NBITS_82580);
+		adapter->cc.mask = CYCLECOUNTER_MASK(IGB_NBITS_82580);
 		adapter->cc.mult = 1;
 		adapter->cc.shift = 0;
 		/* Enable the timer functions by clearing bit 31. */
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH net-next V2 3/7] e1000e: convert to CYCLECOUNTER_MASK macro.
From: Richard Cochran @ 2015-01-02 19:22 UTC (permalink / raw)
  To: netdev; +Cc: David Miller, John Stultz
In-Reply-To: <cover.1420226266.git.richardcochran@gmail.com>

Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
 drivers/net/ethernet/intel/e1000e/netdev.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 2537d36a..332a298 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -43,7 +43,6 @@
 #include <linux/pm_runtime.h>
 #include <linux/aer.h>
 #include <linux/prefetch.h>
-#include <linux/clocksource.h>
 
 #include "e1000.h"
 
@@ -4190,7 +4189,7 @@ static int e1000_sw_init(struct e1000_adapter *adapter)
 	/* Setup hardware time stamping cyclecounter */
 	if (adapter->flags & FLAG_HAS_HW_TIMESTAMP) {
 		adapter->cc.read = e1000e_cyclecounter_read;
-		adapter->cc.mask = CLOCKSOURCE_MASK(64);
+		adapter->cc.mask = CYCLECOUNTER_MASK(64);
 		adapter->cc.mult = 1;
 		/* cc.shift set in e1000e_get_base_tininca() */
 
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH net-next V2 2/7] bnx2x: convert to CYCLECOUNTER_MASK macro.
From: Richard Cochran @ 2015-01-02 19:22 UTC (permalink / raw)
  To: netdev; +Cc: David Miller, John Stultz
In-Reply-To: <cover.1420226266.git.richardcochran@gmail.com>

Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 2c95132..0758c8b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -14610,7 +14610,7 @@ static void bnx2x_init_cyclecounter(struct bnx2x *bp)
 {
 	memset(&bp->cyclecounter, 0, sizeof(bp->cyclecounter));
 	bp->cyclecounter.read = bnx2x_cyclecounter_read;
-	bp->cyclecounter.mask = CLOCKSOURCE_MASK(64);
+	bp->cyclecounter.mask = CYCLECOUNTER_MASK(64);
 	bp->cyclecounter.shift = 1;
 	bp->cyclecounter.mult = 1;
 }
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH net-next V2 0/7] Fixing the "Time Counter fixes and improvements"
From: Richard Cochran @ 2015-01-02 19:22 UTC (permalink / raw)
  To: netdev; +Cc: David Miller, John Stultz
In-Reply-To: <20141231.183347.862533634176009078.davem@davemloft.net>

Dave,

For this series I had only tested the build with ARCH=x86 and arm, but
others like sparc64, microblaze, powerpc, and s390 will fail because
they somehow don't indirectly include clocksource.h for the drivers in
question.

This series fixes the build issues reported by:
 kbuild test robot <fengguang.wu@intel.com>

Thanks,
Richard


Richard Cochran (7):
  timecounter: provide a macro to initialize the cyclecounter mask
    field.
  bnx2x: convert to CYCLECOUNTER_MASK macro.
  e1000e: convert to CYCLECOUNTER_MASK macro.
  igb: convert to CYCLECOUNTER_MASK macro.
  ixgbe: convert to CYCLECOUNTER_MASK macro.
  mlx4: include clocksource.h again
  microblaze: include the new timecounter header.

 arch/microblaze/kernel/timer.c                   |    1 +
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |    2 +-
 drivers/net/ethernet/intel/e1000e/netdev.c       |    3 +--
 drivers/net/ethernet/intel/igb/igb_ptp.c         |    5 ++---
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c     |    2 +-
 drivers/net/ethernet/mellanox/mlx4/en_clock.c    |    1 +
 include/linux/timecounter.h                      |    5 ++++-
 7 files changed, 11 insertions(+), 8 deletions(-)

-- 
1.7.10.4

^ permalink raw reply

* Re: [PATCH 3/4] net: ethernet: cpsw: split out IRQ handler
From: Felipe Balbi @ 2015-01-02 19:03 UTC (permalink / raw)
  To: Dave Taht; +Cc: Felipe Balbi, netdev, Linux OMAP Mailing List
In-Reply-To: <CAA93jw7=aFM3yQLO+vtN4uHW2gMnfNaY=BdbA+b0WYq-0+gSYQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6806 bytes --]

Hi,

(please use reply-all to keep mailing lists in Cc, also avoid
top-posting)

On Fri, Jan 02, 2015 at 10:58:29AM -0800, Dave Taht wrote:
> The beaglebone only has a 100mbit phy, so you aren't going to get more
> than that.

very true :-) Still, with AM437x SK which is definitely GigE, I'm
getting 201Mbits/sec.

> (so do a lot of IoT devices).
> 
> So you have the two patches that went by on BQL and on NAPI for the beagle?

no, got any pointers ?

> On Fri, Jan 2, 2015 at 10:55 AM, Felipe Balbi <balbi@ti.com> wrote:
> > Hi,
> >
> > On Fri, Jan 02, 2015 at 10:49:49AM -0800, Dave Taht wrote:
> >> +1.
> >>
> >> We'd had a thread on netdev (can't find it now) where we discussed
> >> adding BQL support and also something saner for the NAPI handling to
> >> this driver.
> >
> > yeah, currently is completely borked. I'm on a gigabit network and I'm
> > getting 94Mbits/sec, total crap.
> >
> >> Initial results for the beaglebone black were pretty spectacular, and
> >> it does look like this is way cleaner infrastructure underneat th deal
> >> with. Are you testing
> >
> > cool, if I new more about networking I'd certainly help, but I can help
> > testing for sure, just keep me in Cc ;-)
> >
> >> on the beaglebone black.? do you remember that convo?
> >
> > yeah, testing on beagleboneblack and AM437x SK.
> >
> > cheers
> >
> >> On Fri, Jan 2, 2015 at 10:10 AM, Felipe Balbi <balbi@ti.com> wrote:
> >> > Now we can introduce dedicated IRQ handlers
> >> > for each of the IRQ events. This helps with
> >> > cleaning up a little bit of the clutter in
> >> > cpsw_interrupt() while also making sure that
> >> > TX IRQs will try to handle TX buffers while
> >> > RX IRQs will try to handle RX buffers.
> >> >
> >> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> >> > ---
> >> >  drivers/net/ethernet/ti/cpsw.c | 41 ++++++++++++++++++++++++++++++-----------
> >> >  1 file changed, 30 insertions(+), 11 deletions(-)
> >> >
> >> > diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> >> > index 6e04128..c9081bd 100644
> >> > --- a/drivers/net/ethernet/ti/cpsw.c
> >> > +++ b/drivers/net/ethernet/ti/cpsw.c
> >> > @@ -754,18 +754,36 @@ requeue:
> >> >                 dev_kfree_skb_any(new_skb);
> >> >  }
> >> >
> >> > -static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
> >> > +static irqreturn_t cpsw_dummy_interrupt(int irq, void *dev_id)
> >> >  {
> >> >         struct cpsw_priv *priv = dev_id;
> >> >         int value = irq - priv->irqs_table[0];
> >> >
> >> > -       /* NOTICE: Ending IRQ here. The trick with the 'value' variable above
> >> > -        * is to make sure we will always write the correct value to the EOI
> >> > -        * register. Namely 0 for RX_THRESH Interrupt, 1 for RX Interrupt, 2
> >> > -        * for TX Interrupt and 3 for MISC Interrupt.
> >> > -        */
> >> >         cpdma_ctlr_eoi(priv->dma, value);
> >> >
> >> > +       return IRQ_HANDLED;
> >> > +}
> >> > +
> >> > +static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
> >> > +{
> >> > +       struct cpsw_priv *priv = dev_id;
> >> > +
> >> > +       cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
> >> > +       cpdma_chan_process(priv->txch, 128);
> >> > +
> >> > +       priv = cpsw_get_slave_priv(priv, 1);
> >> > +       if (priv)
> >> > +               cpdma_chan_process(priv->txch, 128);
> >> > +
> >> > +       return IRQ_HANDLED;
> >> > +}
> >> > +
> >> > +static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
> >> > +{
> >> > +       struct cpsw_priv *priv = dev_id;
> >> > +
> >> > +       cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
> >> > +
> >> >         cpsw_intr_disable(priv);
> >> >         if (priv->irq_enabled == true) {
> >> >                 cpsw_disable_irq(priv);
> >> > @@ -1617,7 +1635,8 @@ static void cpsw_ndo_poll_controller(struct net_device *ndev)
> >> >
> >> >         cpsw_intr_disable(priv);
> >> >         cpdma_ctlr_int_ctrl(priv->dma, false);
> >> > -       cpsw_interrupt(ndev->irq, priv);
> >> > +       cpsw_rx_interrupt(priv->irq[1], priv);
> >> > +       cpsw_tx_interrupt(priv->irq[2], priv);
> >> >         cpdma_ctlr_int_ctrl(priv->dma, true);
> >> >         cpsw_intr_enable(priv);
> >> >  }
> >> > @@ -2351,7 +2370,7 @@ static int cpsw_probe(struct platform_device *pdev)
> >> >                 goto clean_ale_ret;
> >> >
> >> >         priv->irqs_table[0] = irq;
> >> > -       ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
> >> > +       ret = devm_request_irq(&pdev->dev, irq, cpsw_dummy_interrupt,
> >> >                         0, dev_name(&pdev->dev), priv);
> >> >         if (ret < 0) {
> >> >                 dev_err(priv->dev, "error attaching irq (%d)\n", ret);
> >> > @@ -2363,7 +2382,7 @@ static int cpsw_probe(struct platform_device *pdev)
> >> >                 goto clean_ale_ret;
> >> >
> >> >         priv->irqs_table[1] = irq;
> >> > -       ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
> >> > +       ret = devm_request_irq(&pdev->dev, irq, cpsw_rx_interrupt,
> >> >                         0, dev_name(&pdev->dev), priv);
> >> >         if (ret < 0) {
> >> >                 dev_err(priv->dev, "error attaching irq (%d)\n", ret);
> >> > @@ -2375,7 +2394,7 @@ static int cpsw_probe(struct platform_device *pdev)
> >> >                 goto clean_ale_ret;
> >> >
> >> >         priv->irqs_table[2] = irq;
> >> > -       ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
> >> > +       ret = devm_request_irq(&pdev->dev, irq, cpsw_tx_interrupt,
> >> >                         0, dev_name(&pdev->dev), priv);
> >> >         if (ret < 0) {
> >> >                 dev_err(priv->dev, "error attaching irq (%d)\n", ret);
> >> > @@ -2387,7 +2406,7 @@ static int cpsw_probe(struct platform_device *pdev)
> >> >                 goto clean_ale_ret;
> >> >
> >> >         priv->irqs_table[3] = irq;
> >> > -       ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
> >> > +       ret = devm_request_irq(&pdev->dev, irq, cpsw_dummy_interrupt,
> >> >                         0, dev_name(&pdev->dev), priv);
> >> >         if (ret < 0) {
> >> >                 dev_err(priv->dev, "error attaching irq (%d)\n", ret);
> >> > --
> >> > 2.2.0
> >> >
> >> > --
> >> > 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
> >>
> >>
> >>
> >> --
> >> Dave Täht
> >>
> >> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> >
> > --
> > balbi
> 
> 
> 
> -- 
> Dave Täht
> 
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH 3/4] net: ethernet: cpsw: split out IRQ handler
From: Felipe Balbi @ 2015-01-02 18:55 UTC (permalink / raw)
  To: Dave Taht; +Cc: Felipe Balbi, Linux OMAP Mailing List, netdev
In-Reply-To: <CAA93jw7qyZjdHGKXjiBhiYp4BWBFrUFM6FF-Lzc0i7eOnM6cNg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5700 bytes --]

Hi,

On Fri, Jan 02, 2015 at 10:49:49AM -0800, Dave Taht wrote:
> +1.
> 
> We'd had a thread on netdev (can't find it now) where we discussed
> adding BQL support and also something saner for the NAPI handling to
> this driver.

yeah, currently is completely borked. I'm on a gigabit network and I'm
getting 94Mbits/sec, total crap.

> Initial results for the beaglebone black were pretty spectacular, and
> it does look like this is way cleaner infrastructure underneat th deal
> with. Are you testing

cool, if I new more about networking I'd certainly help, but I can help
testing for sure, just keep me in Cc ;-)

> on the beaglebone black.? do you remember that convo?

yeah, testing on beagleboneblack and AM437x SK.

cheers

> On Fri, Jan 2, 2015 at 10:10 AM, Felipe Balbi <balbi@ti.com> wrote:
> > Now we can introduce dedicated IRQ handlers
> > for each of the IRQ events. This helps with
> > cleaning up a little bit of the clutter in
> > cpsw_interrupt() while also making sure that
> > TX IRQs will try to handle TX buffers while
> > RX IRQs will try to handle RX buffers.
> >
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >  drivers/net/ethernet/ti/cpsw.c | 41 ++++++++++++++++++++++++++++++-----------
> >  1 file changed, 30 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> > index 6e04128..c9081bd 100644
> > --- a/drivers/net/ethernet/ti/cpsw.c
> > +++ b/drivers/net/ethernet/ti/cpsw.c
> > @@ -754,18 +754,36 @@ requeue:
> >                 dev_kfree_skb_any(new_skb);
> >  }
> >
> > -static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
> > +static irqreturn_t cpsw_dummy_interrupt(int irq, void *dev_id)
> >  {
> >         struct cpsw_priv *priv = dev_id;
> >         int value = irq - priv->irqs_table[0];
> >
> > -       /* NOTICE: Ending IRQ here. The trick with the 'value' variable above
> > -        * is to make sure we will always write the correct value to the EOI
> > -        * register. Namely 0 for RX_THRESH Interrupt, 1 for RX Interrupt, 2
> > -        * for TX Interrupt and 3 for MISC Interrupt.
> > -        */
> >         cpdma_ctlr_eoi(priv->dma, value);
> >
> > +       return IRQ_HANDLED;
> > +}
> > +
> > +static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
> > +{
> > +       struct cpsw_priv *priv = dev_id;
> > +
> > +       cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
> > +       cpdma_chan_process(priv->txch, 128);
> > +
> > +       priv = cpsw_get_slave_priv(priv, 1);
> > +       if (priv)
> > +               cpdma_chan_process(priv->txch, 128);
> > +
> > +       return IRQ_HANDLED;
> > +}
> > +
> > +static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
> > +{
> > +       struct cpsw_priv *priv = dev_id;
> > +
> > +       cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
> > +
> >         cpsw_intr_disable(priv);
> >         if (priv->irq_enabled == true) {
> >                 cpsw_disable_irq(priv);
> > @@ -1617,7 +1635,8 @@ static void cpsw_ndo_poll_controller(struct net_device *ndev)
> >
> >         cpsw_intr_disable(priv);
> >         cpdma_ctlr_int_ctrl(priv->dma, false);
> > -       cpsw_interrupt(ndev->irq, priv);
> > +       cpsw_rx_interrupt(priv->irq[1], priv);
> > +       cpsw_tx_interrupt(priv->irq[2], priv);
> >         cpdma_ctlr_int_ctrl(priv->dma, true);
> >         cpsw_intr_enable(priv);
> >  }
> > @@ -2351,7 +2370,7 @@ static int cpsw_probe(struct platform_device *pdev)
> >                 goto clean_ale_ret;
> >
> >         priv->irqs_table[0] = irq;
> > -       ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
> > +       ret = devm_request_irq(&pdev->dev, irq, cpsw_dummy_interrupt,
> >                         0, dev_name(&pdev->dev), priv);
> >         if (ret < 0) {
> >                 dev_err(priv->dev, "error attaching irq (%d)\n", ret);
> > @@ -2363,7 +2382,7 @@ static int cpsw_probe(struct platform_device *pdev)
> >                 goto clean_ale_ret;
> >
> >         priv->irqs_table[1] = irq;
> > -       ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
> > +       ret = devm_request_irq(&pdev->dev, irq, cpsw_rx_interrupt,
> >                         0, dev_name(&pdev->dev), priv);
> >         if (ret < 0) {
> >                 dev_err(priv->dev, "error attaching irq (%d)\n", ret);
> > @@ -2375,7 +2394,7 @@ static int cpsw_probe(struct platform_device *pdev)
> >                 goto clean_ale_ret;
> >
> >         priv->irqs_table[2] = irq;
> > -       ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
> > +       ret = devm_request_irq(&pdev->dev, irq, cpsw_tx_interrupt,
> >                         0, dev_name(&pdev->dev), priv);
> >         if (ret < 0) {
> >                 dev_err(priv->dev, "error attaching irq (%d)\n", ret);
> > @@ -2387,7 +2406,7 @@ static int cpsw_probe(struct platform_device *pdev)
> >                 goto clean_ale_ret;
> >
> >         priv->irqs_table[3] = irq;
> > -       ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
> > +       ret = devm_request_irq(&pdev->dev, irq, cpsw_dummy_interrupt,
> >                         0, dev_name(&pdev->dev), priv);
> >         if (ret < 0) {
> >                 dev_err(priv->dev, "error attaching irq (%d)\n", ret);
> > --
> > 2.2.0
> >
> > --
> > 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
> 
> 
> 
> -- 
> Dave Täht
> 
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH net-next] MAINTAINERS: Update Open vSwitch entry.
From: Pravin Shelar @ 2015-01-02 18:54 UTC (permalink / raw)
  To: Joe Perches; +Cc: David Miller, netdev
In-Reply-To: <1420224077.23591.2.camel@perches.com>

On Fri, Jan 2, 2015 at 10:41 AM, Joe Perches <joe@perches.com> wrote:
> On Fri, 2015-01-02 at 10:24 -0800, Pravin B Shelar wrote:
>> OVS development is moved to netdev mailing list. Update tree and
>> list in MAINTAINERS file.
> []
>> diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> @@ -7008,9 +7008,11 @@ F:     arch/openrisc/
>>
>>  OPENVSWITCH
>>  M:   Pravin Shelar <pshelar@nicira.com>
>> +L:   netdev@vger.kernel.org
>>  L:   dev@openvswitch.org
>>  W:   http://openvswitch.org
>> -T:   git git://git.kernel.org/pub/scm/linux/kernel/git/pshelar/openvswitch.git
>> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
>> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>>  S:   Maintained
>>  F:   net/openvswitch/
>>
>
> Are those git entries really appropriate?
>

I am not maintaining my tree on kernel.org. All OVS development will
be done on net-next tree, I guess there is no need to explicitly
mention the tree. I will remove the tree information.

^ permalink raw reply

* Re: [PATCH net-next 00/11] Time Counter fixes and improvements
From: Richard Cochran @ 2015-01-02 18:49 UTC (permalink / raw)
  To: John Stultz
  Cc: netdev, lkml, Amir Vadai, Ariel Elior, Carolyn Wyborny,
	David Miller, Frank Li, Jeff Kirsher, Matthew Vick,
	Miroslav Lichvar, Mugunthan V N, Or Gerlitz, Thomas Gleixner,
	Tom Lendacky
In-Reply-To: <CALAqxLUVU3XmBMiNGH-X5KjGbEjDYtaR2WRXDOHfGNads9caOw@mail.gmail.com>

On Fri, Jan 02, 2015 at 10:37:09AM -0800, John Stultz wrote:
> Though, this does start to sound like issues the timekeeping code had
> to resolve, so while its probably time to let some flowers bloom and
> see what happens, we should be somewhat watchful for too much logic
> duplication.

You took the words right out of my mouth.

My feeling is that this timecounter code might become more
complicated, and if the core time keeping becomes more
straightforward, then maybe one day the two will join.

Thanks,
Richard

^ permalink raw reply

* Re: [PATCH net-next] MAINTAINERS: Update Open vSwitch entry.
From: Joe Perches @ 2015-01-02 18:41 UTC (permalink / raw)
  To: Pravin B Shelar; +Cc: davem, netdev
In-Reply-To: <1420223098-1591-1-git-send-email-pshelar@nicira.com>

On Fri, 2015-01-02 at 10:24 -0800, Pravin B Shelar wrote:
> OVS development is moved to netdev mailing list. Update tree and
> list in MAINTAINERS file.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -7008,9 +7008,11 @@ F:	arch/openrisc/
>  
>  OPENVSWITCH
>  M:	Pravin Shelar <pshelar@nicira.com>
> +L:	netdev@vger.kernel.org
>  L:	dev@openvswitch.org
>  W:	http://openvswitch.org
> -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/pshelar/openvswitch.git
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>  S:	Maintained
>  F:	net/openvswitch/
>  

Are those git entries really appropriate?

^ permalink raw reply

* Re: [PATCH net-next 00/11] Time Counter fixes and improvements
From: John Stultz @ 2015-01-02 18:37 UTC (permalink / raw)
  To: Richard Cochran
  Cc: netdev, lkml, Amir Vadai, Ariel Elior, Carolyn Wyborny,
	David Miller, Frank Li, Jeff Kirsher, Matthew Vick,
	Miroslav Lichvar, Mugunthan V N, Or Gerlitz, Thomas Gleixner,
	Tom Lendacky
In-Reply-To: <cover.1418504883.git.richardcochran@gmail.com>

On Sun, Dec 21, 2014 at 10:46 AM, Richard Cochran
<richardcochran@gmail.com> wrote:
> Several PTP Hardware Clock (PHC) drivers implement the clock in
> software using the timecounter/cyclecounter code. This series adds one
> simple improvement and one more subtle fix to the shared timecounter
> facility. Credit for this series goes to Janusz Użycki, who pointed
> the issues out to me off list.
>
> Patch #1 simply move the timecounter code into its own file. When
> working on this series, it was really annoying to see half the kernel
> recompile after every tweak to the timecounter stuff. There is no
> reason to keep this together with the clocksource code.

I did have some faint hope we could merge the cyclecounter and
clocksource struct at some point, and while we've gotten closer with
much of the time-specific values being kept in the timekeeper, the
full cleanup hasn't happened in a few years here, so its clearly not
something I've prioritized.

So no objection in concept.


> Patch #2 implements an improved adjtime() method, and patches 3-10
> convert all of the drivers over to the new method.
>
> Patch #11 fixes a subtle but important issue with the timecounter WRT
> frequency adjustment. As it stands now, a timecounter based PHC will
> exhibit a variable frequency resolution (and variable time error)
> depending on how often the clock is read.
>
> In timecounter_read_delta(), the expression
>
>    (delta * cc->mult) >> cc->shift;
>
> can lose resolution from the adjusted value of 'mult'. If the value
> of 'delta' is too small, then small changes in 'mult' have no effect.
> However, if the delta value is large enough, then small changes in
> 'mult' will have an effect.
>
> Reading the clock too often means smaller 'delta' values which in turn
> will spoil the fine adjustments made to 'mult'. Up until now, this
> effect did not show up in my testing. The following example explains
> why.
>
> The CPTS has an input clock of 250 MHz, and the clock source uses
> mult=0x80000000 and shift=29, making the ticks to nanoseconds
> conversion like this:
>
>    ticks * 2^31
>    ------------
>        2^29
>
> Imagine what happens if the clock is read every 10 milliseconds. Ten
> milliseconds are about 2500000 ticks, which corresponds to about 21
> bits. The product in the numerator has then 52 bits. After the shift
> operation, 23 bits are preserved. This results in a frequency
> adjustment resolution of about 0.1 ppm (not _too_ bad.)
>
> A frequency resolution of 1 ppm requires 20 bits.
> A frequency resolution of 1 ppb requires 30 bits.
>
> For the 250 MHz CPTS clock, reading every 4 seconds yields a 1 ppb
> resolution (which is the finest that our API allows).
>
> However, the error can be much higher if the clock is read too often
> or if time stamps occur close in time to read operations. In general
> it is really not acceptable to allow the rate of clock readings to
> influence the clock accuracy.

Though, this does start to sound like issues the timekeeping code had
to resolve, so while its probably time to let some flowers bloom and
see what happens, we should be somewhat watchful for too much logic
duplication.

The patch set itself seems fairly straight forward (at least to my
back from vacation brain), so..
Acked-by: John Stultz <john.stultz@linaro.org>

thanks
-john

^ permalink raw reply

* Re: [PATCH 02/11] rtlwifi: rtl8723be: Improve modinfo output
From: Sergei Shtylyov @ 2015-01-02 18:35 UTC (permalink / raw)
  To: Larry Finger, kvalo-sgV2jX0FEOL9JmXXK+q4OQ
  Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1420217908-1382-3-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>

Hello.

On 1/2/2015 7:58 PM, Larry Finger wrote:

> The description of the power-save variables for this driver is not as
> clear as for the others. The wording is changed to match the others.

> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
>   drivers/net/wireless/rtlwifi/rtl8723be/sw.c | 11 ++++++-----
>   1 file changed, 6 insertions(+), 5 deletions(-)

> diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/sw.c b/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
> index 223eb42..52a6d90 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
> @@ -387,12 +387,13 @@ module_param_named(swlps, rtl8723be_mod_params.swctrl_lps, bool, 0444);
>   module_param_named(fwlps, rtl8723be_mod_params.fwctrl_lps, bool, 0444);
>   module_param_named(disable_watchdog, rtl8723be_mod_params.disable_watchdog,
>   		   bool, 0444);
> -MODULE_PARM_DESC(swenc, "using hardware crypto (default 0 [hardware])\n");
> -MODULE_PARM_DESC(ips, "using no link power save (default 1 is open)\n");
> -MODULE_PARM_DESC(fwlps, "using linked fw control power save (default 1 is open)\n");
> -MODULE_PARM_DESC(msi, "Set to 1 to use MSI interrupts mode (default 0)\n");

    You are completely removing this description. Is it intentional?

> +MODULE_PARM_DESC(swenc, "Set to 1 for software crypto (default 0)\n");
> +MODULE_PARM_DESC(ips, "Set to 0 to not use link power save (default 1)\n");
> +MODULE_PARM_DESC(swlps, "Set to 1 to use SW control power save (default 0)\n");
> +MODULE_PARM_DESC(fwlps, "Set to 1 to use FW control power save (default 1)\n");
>   MODULE_PARM_DESC(debug, "Set debug level (0-5) (default 0)");
> -MODULE_PARM_DESC(disable_watchdog, "Set to 1 to disable the watchdog (default 0)\n");
> +MODULE_PARM_DESC(disable_watchdog,
> +		 "Set to 1 to disable the watchdog (default 0)\n");

WBR, Sergei

--
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

* [PATCH net-next] openvswitch: Do not set skb ignore_df
From: Pravin B Shelar @ 2015-01-02 18:27 UTC (permalink / raw)
  To: davem; +Cc: netdev, dev, Pravin B Shelar

Tunnel transmit code clear this bit, so setting ignore_df has
no effect.

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
 net/openvswitch/vport-geneve.c |    1 -
 net/openvswitch/vport-gre.c    |    2 --
 net/openvswitch/vport-vxlan.c  |    2 --
 3 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/net/openvswitch/vport-geneve.c b/net/openvswitch/vport-geneve.c
index 484864d..8769be9 100644
--- a/net/openvswitch/vport-geneve.c
+++ b/net/openvswitch/vport-geneve.c
@@ -209,7 +209,6 @@ static int geneve_tnl_send(struct vport *vport, struct sk_buff *skb)
 	df = tun_key->tun_flags & TUNNEL_DONT_FRAGMENT ? htons(IP_DF) : 0;
 	sport = udp_flow_src_port(net, skb, 1, USHRT_MAX, true);
 	tunnel_id_to_vni(tun_key->tun_id, vni);
-	skb->ignore_df = 1;
 
 	err = geneve_xmit_skb(geneve_port->gs, rt, skb, fl.saddr,
 			      tun_key->ipv4_dst, tun_key->ipv4_tos,
diff --git a/net/openvswitch/vport-gre.c b/net/openvswitch/vport-gre.c
index d4168c4..ec57221 100644
--- a/net/openvswitch/vport-gre.c
+++ b/net/openvswitch/vport-gre.c
@@ -194,8 +194,6 @@ static int gre_tnl_send(struct vport *vport, struct sk_buff *skb)
 	df = tun_key->tun_flags & TUNNEL_DONT_FRAGMENT ?
 		htons(IP_DF) : 0;
 
-	skb->ignore_df = 1;
-
 	return iptunnel_xmit(skb->sk, rt, skb, fl.saddr,
 			     tun_key->ipv4_dst, IPPROTO_GRE,
 			     tun_key->ipv4_tos, tun_key->ipv4_ttl, df, false);
diff --git a/net/openvswitch/vport-vxlan.c b/net/openvswitch/vport-vxlan.c
index d7c46b3..dc6f625 100644
--- a/net/openvswitch/vport-vxlan.c
+++ b/net/openvswitch/vport-vxlan.c
@@ -175,8 +175,6 @@ static int vxlan_tnl_send(struct vport *vport, struct sk_buff *skb)
 	df = tun_key->tun_flags & TUNNEL_DONT_FRAGMENT ?
 		htons(IP_DF) : 0;
 
-	skb->ignore_df = 1;
-
 	src_port = udp_flow_src_port(net, skb, 0, 0, true);
 
 	err = vxlan_xmit_skb(vxlan_port->vs, rt, skb,
-- 
1.7.1

^ permalink raw reply related

* [PATCH net-next] MAINTAINERS: Update Open vSwitch entry.
From: Pravin B Shelar @ 2015-01-02 18:24 UTC (permalink / raw)
  To: davem; +Cc: netdev, Pravin B Shelar

OVS development is moved to netdev mailing list. Update tree and
list in MAINTAINERS file.

Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
 MAINTAINERS |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index ddb9ac8..5c976cc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7008,9 +7008,11 @@ F:	arch/openrisc/
 
 OPENVSWITCH
 M:	Pravin Shelar <pshelar@nicira.com>
+L:	netdev@vger.kernel.org
 L:	dev@openvswitch.org
 W:	http://openvswitch.org
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/pshelar/openvswitch.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
 S:	Maintained
 F:	net/openvswitch/
 
-- 
1.7.1

^ permalink raw reply related

* Re: tcp: Do not apply TSO segment limit to non-TSO packets
From: Eric Dumazet @ 2015-01-02 18:24 UTC (permalink / raw)
  To: Herbert Xu
  Cc: Thomas Jarosch, netdev, edumazet, Steffen Klassert, Ben Hutchings,
	David S. Miller
In-Reply-To: <20141231134217.GB30248@gondor.apana.org.au>

On Thu, 2015-01-01 at 00:42 +1100, Herbert Xu wrote:
> On Thu, Jan 01, 2015 at 12:39:23AM +1100, Herbert Xu wrote:
> >
> > Thomas Jarosch reported IPsec TCP stalls when a PMTU event occurs.
> > 
> > In fact the problem was completely unrelated to IPsec.  The bug is
> > also reproducible if you just disable TSO/GSO.
> 
> This raises two interesting questions.
> 
> Firstly not many people test non-TSO code paths anymore so bugs
> are likely to persist for a long time there.  Perhaps it's time
> to remove the non-TSO code path altogether? The GSO code path
> should provide enough speed-up in terms of boosting the effective
> MTU to offset the cost of copying.

> Secondly why are we dealing with hardware TSO segment limits
> by limiting the size of the TSO packet in the TCP stack? Surely
> in this case GSO is free since there won't be any copying?

It might depends on the device capabilities.

Non TSO/GSO path is known to be better for devices unable to perform TX
checksumming, as we compute the checksum at the time we copy data from
user to kernel (csum_and_copy_from_user() from tcp_sendmsg())).

With BQL+TSQ, having to compute the TX hash means bringing data into cpu
caches a second time right before ndo_start_xmit()

But maybe this gain is very relative in a full blown configuration, with
netfilter / complex qdisc being used.

Thanks Herbert !

^ permalink raw reply

* [PATCH] staging: r8188eu: Fix memory leak in firmware loading
From: Larry Finger @ 2015-01-02 18:17 UTC (permalink / raw)
  To: gregkh; +Cc: devel, netdev, Larry Finger

The driver allocates memory to store the firmware image; however, that
memory is never released. The kmemleak facility was used to find this
error.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
 drivers/staging/rtl8188eu/hal/fw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rtl8188eu/hal/fw.c b/drivers/staging/rtl8188eu/hal/fw.c
index 3b28754..a5b7fc4 100644
--- a/drivers/staging/rtl8188eu/hal/fw.c
+++ b/drivers/staging/rtl8188eu/hal/fw.c
@@ -231,6 +231,7 @@ int rtl88eu_download_fw(struct adapter *adapt)
 	_rtl88e_enable_fw_download(adapt, false);
 
 	err = _rtl88e_fw_free_to_go(adapt);
+	kfree(pfwdata);
 
 	return err;
 }
-- 
2.1.2

^ permalink raw reply related

* [PATCH 4/4] net: ethernet: cpsw: don't requests IRQs we don't use
From: Felipe Balbi @ 2015-01-02 18:10 UTC (permalink / raw)
  To: David Miller
  Cc: Mugunthan V N, Yegor Yefremov, Linux OMAP Mailing List, netdev,
	Felipe Balbi
In-Reply-To: <1420222228-31949-1-git-send-email-balbi@ti.com>

CPSW never uses RX_THRESHOLD or MISC interrupts. In
fact, they are always kept masked in their appropriate
IRQ Enable register.

Instead of allocating an IRQ that never fires, it's best
to remove that code altogether and let future patches
implement it if anybody needs those.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/net/ethernet/ti/cpsw.c | 55 ++++++++++++------------------------------
 1 file changed, 15 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c9081bd..fd0acd9 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -754,16 +754,6 @@ requeue:
 		dev_kfree_skb_any(new_skb);
 }
 
-static irqreturn_t cpsw_dummy_interrupt(int irq, void *dev_id)
-{
-	struct cpsw_priv *priv = dev_id;
-	int value = irq - priv->irqs_table[0];
-
-	cpdma_ctlr_eoi(priv->dma, value);
-
-	return IRQ_HANDLED;
-}
-
 static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
 {
 	struct cpsw_priv *priv = dev_id;
@@ -1635,8 +1625,8 @@ static void cpsw_ndo_poll_controller(struct net_device *ndev)
 
 	cpsw_intr_disable(priv);
 	cpdma_ctlr_int_ctrl(priv->dma, false);
-	cpsw_rx_interrupt(priv->irq[1], priv);
-	cpsw_tx_interrupt(priv->irq[2], priv);
+	cpsw_rx_interrupt(priv->irq[0], priv);
+	cpsw_tx_interrupt(priv->irq[1], priv);
 	cpdma_ctlr_int_ctrl(priv->dma, true);
 	cpsw_intr_enable(priv);
 }
@@ -2358,30 +2348,27 @@ static int cpsw_probe(struct platform_device *pdev)
 		goto clean_dma_ret;
 	}
 
-	ndev->irq = platform_get_irq(pdev, 0);
+	ndev->irq = platform_get_irq(pdev, 1);
 	if (ndev->irq < 0) {
 		dev_err(priv->dev, "error getting irq resource\n");
 		ret = -ENOENT;
 		goto clean_ale_ret;
 	}
 
-	irq = platform_get_irq(pdev, 0);
-	if (irq < 0)
-		goto clean_ale_ret;
-
-	priv->irqs_table[0] = irq;
-	ret = devm_request_irq(&pdev->dev, irq, cpsw_dummy_interrupt,
-			0, dev_name(&pdev->dev), priv);
-	if (ret < 0) {
-		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
-		goto clean_ale_ret;
-	}
+	/* Grab RX and TX IRQs. Note that we also have RX_THRESHOLD and
+	 * MISC IRQs which are always kept disabled with this driver so
+	 * we will not request them.
+	 *
+	 * If anyone wants to implement support for those, make sure to
+	 * first request and append them to irqs_table array.
+	 */
 
+	/* RX IRQ */
 	irq = platform_get_irq(pdev, 1);
 	if (irq < 0)
 		goto clean_ale_ret;
 
-	priv->irqs_table[1] = irq;
+	priv->irqs_table[0] = irq;
 	ret = devm_request_irq(&pdev->dev, irq, cpsw_rx_interrupt,
 			0, dev_name(&pdev->dev), priv);
 	if (ret < 0) {
@@ -2389,31 +2376,19 @@ static int cpsw_probe(struct platform_device *pdev)
 		goto clean_ale_ret;
 	}
 
+	/* TX IRQ */
 	irq = platform_get_irq(pdev, 2);
 	if (irq < 0)
 		goto clean_ale_ret;
 
-	priv->irqs_table[2] = irq;
+	priv->irqs_table[1] = irq;
 	ret = devm_request_irq(&pdev->dev, irq, cpsw_tx_interrupt,
 			0, dev_name(&pdev->dev), priv);
 	if (ret < 0) {
 		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
 		goto clean_ale_ret;
 	}
-
-	irq = platform_get_irq(pdev, 3);
-	if (irq < 0)
-		goto clean_ale_ret;
-
-	priv->irqs_table[3] = irq;
-	ret = devm_request_irq(&pdev->dev, irq, cpsw_dummy_interrupt,
-			0, dev_name(&pdev->dev), priv);
-	if (ret < 0) {
-		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
-		goto clean_ale_ret;
-	}
-
-	priv->num_irqs = 4;
+	priv->num_irqs = 2;
 
 	ndev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
 
-- 
2.2.0

^ permalink raw reply related

* [PATCH 3/4] net: ethernet: cpsw: split out IRQ handler
From: Felipe Balbi @ 2015-01-02 18:10 UTC (permalink / raw)
  To: David Miller
  Cc: Mugunthan V N, Yegor Yefremov, Linux OMAP Mailing List, netdev,
	Felipe Balbi
In-Reply-To: <1420222228-31949-1-git-send-email-balbi@ti.com>

Now we can introduce dedicated IRQ handlers
for each of the IRQ events. This helps with
cleaning up a little bit of the clutter in
cpsw_interrupt() while also making sure that
TX IRQs will try to handle TX buffers while
RX IRQs will try to handle RX buffers.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/net/ethernet/ti/cpsw.c | 41 ++++++++++++++++++++++++++++++-----------
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 6e04128..c9081bd 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -754,18 +754,36 @@ requeue:
 		dev_kfree_skb_any(new_skb);
 }
 
-static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
+static irqreturn_t cpsw_dummy_interrupt(int irq, void *dev_id)
 {
 	struct cpsw_priv *priv = dev_id;
 	int value = irq - priv->irqs_table[0];
 
-	/* NOTICE: Ending IRQ here. The trick with the 'value' variable above
-	 * is to make sure we will always write the correct value to the EOI
-	 * register. Namely 0 for RX_THRESH Interrupt, 1 for RX Interrupt, 2
-	 * for TX Interrupt and 3 for MISC Interrupt.
-	 */
 	cpdma_ctlr_eoi(priv->dma, value);
 
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t cpsw_tx_interrupt(int irq, void *dev_id)
+{
+	struct cpsw_priv *priv = dev_id;
+
+	cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
+	cpdma_chan_process(priv->txch, 128);
+
+	priv = cpsw_get_slave_priv(priv, 1);
+	if (priv)
+		cpdma_chan_process(priv->txch, 128);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t cpsw_rx_interrupt(int irq, void *dev_id)
+{
+	struct cpsw_priv *priv = dev_id;
+
+	cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
+
 	cpsw_intr_disable(priv);
 	if (priv->irq_enabled == true) {
 		cpsw_disable_irq(priv);
@@ -1617,7 +1635,8 @@ static void cpsw_ndo_poll_controller(struct net_device *ndev)
 
 	cpsw_intr_disable(priv);
 	cpdma_ctlr_int_ctrl(priv->dma, false);
-	cpsw_interrupt(ndev->irq, priv);
+	cpsw_rx_interrupt(priv->irq[1], priv);
+	cpsw_tx_interrupt(priv->irq[2], priv);
 	cpdma_ctlr_int_ctrl(priv->dma, true);
 	cpsw_intr_enable(priv);
 }
@@ -2351,7 +2370,7 @@ static int cpsw_probe(struct platform_device *pdev)
 		goto clean_ale_ret;
 
 	priv->irqs_table[0] = irq;
-	ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
+	ret = devm_request_irq(&pdev->dev, irq, cpsw_dummy_interrupt,
 			0, dev_name(&pdev->dev), priv);
 	if (ret < 0) {
 		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
@@ -2363,7 +2382,7 @@ static int cpsw_probe(struct platform_device *pdev)
 		goto clean_ale_ret;
 
 	priv->irqs_table[1] = irq;
-	ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
+	ret = devm_request_irq(&pdev->dev, irq, cpsw_rx_interrupt,
 			0, dev_name(&pdev->dev), priv);
 	if (ret < 0) {
 		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
@@ -2375,7 +2394,7 @@ static int cpsw_probe(struct platform_device *pdev)
 		goto clean_ale_ret;
 
 	priv->irqs_table[2] = irq;
-	ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
+	ret = devm_request_irq(&pdev->dev, irq, cpsw_tx_interrupt,
 			0, dev_name(&pdev->dev), priv);
 	if (ret < 0) {
 		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
@@ -2387,7 +2406,7 @@ static int cpsw_probe(struct platform_device *pdev)
 		goto clean_ale_ret;
 
 	priv->irqs_table[3] = irq;
-	ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
+	ret = devm_request_irq(&pdev->dev, irq, cpsw_dummy_interrupt,
 			0, dev_name(&pdev->dev), priv);
 	if (ret < 0) {
 		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
-- 
2.2.0


^ permalink raw reply related

* [PATCH 2/4] net: ethernet: cpsw: unroll IRQ request loop
From: Felipe Balbi @ 2015-01-02 18:10 UTC (permalink / raw)
  To: David Miller
  Cc: Mugunthan V N, Yegor Yefremov, Linux OMAP Mailing List, netdev,
	Felipe Balbi
In-Reply-To: <1420222228-31949-1-git-send-email-balbi@ti.com>

This patch is in preparation for a nicer IRQ
handling scheme where we use different IRQ
handlers for each IRQ line (as it should be).

Later, we will also drop IRQs offset 0 and 3
because they are always disabled in this driver.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/net/ethernet/ti/cpsw.c | 62 ++++++++++++++++++++++++++++++++----------
 1 file changed, 47 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index e61ee83..6e04128 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2156,7 +2156,8 @@ static int cpsw_probe(struct platform_device *pdev)
 	void __iomem			*ss_regs;
 	struct resource			*res, *ss_res;
 	u32 slave_offset, sliver_offset, slave_size;
-	int ret = 0, i, k = 0;
+	int ret = 0, i;
+	int irq;
 
 	ndev = alloc_etherdev(sizeof(struct cpsw_priv));
 	if (!ndev) {
@@ -2345,24 +2346,55 @@ static int cpsw_probe(struct platform_device *pdev)
 		goto clean_ale_ret;
 	}
 
-	while ((res = platform_get_resource(priv->pdev, IORESOURCE_IRQ, k))) {
-		if (k >= ARRAY_SIZE(priv->irqs_table)) {
-			ret = -EINVAL;
-			goto clean_ale_ret;
-		}
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		goto clean_ale_ret;
 
-		ret = devm_request_irq(&pdev->dev, res->start, cpsw_interrupt,
-				       0, dev_name(&pdev->dev), priv);
-		if (ret < 0) {
-			dev_err(priv->dev, "error attaching irq (%d)\n", ret);
-			goto clean_ale_ret;
-		}
+	priv->irqs_table[0] = irq;
+	ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
+			0, dev_name(&pdev->dev), priv);
+	if (ret < 0) {
+		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
+		goto clean_ale_ret;
+	}
 
-		priv->irqs_table[k] = res->start;
-		k++;
+	irq = platform_get_irq(pdev, 1);
+	if (irq < 0)
+		goto clean_ale_ret;
+
+	priv->irqs_table[1] = irq;
+	ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
+			0, dev_name(&pdev->dev), priv);
+	if (ret < 0) {
+		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
+		goto clean_ale_ret;
+	}
+
+	irq = platform_get_irq(pdev, 2);
+	if (irq < 0)
+		goto clean_ale_ret;
+
+	priv->irqs_table[2] = irq;
+	ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
+			0, dev_name(&pdev->dev), priv);
+	if (ret < 0) {
+		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
+		goto clean_ale_ret;
+	}
+
+	irq = platform_get_irq(pdev, 3);
+	if (irq < 0)
+		goto clean_ale_ret;
+
+	priv->irqs_table[3] = irq;
+	ret = devm_request_irq(&pdev->dev, irq, cpsw_interrupt,
+			0, dev_name(&pdev->dev), priv);
+	if (ret < 0) {
+		dev_err(priv->dev, "error attaching irq (%d)\n", ret);
+		goto clean_ale_ret;
 	}
 
-	priv->num_irqs = k;
+	priv->num_irqs = 4;
 
 	ndev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
 
-- 
2.2.0


^ permalink raw reply related

* [PATCH 1/4] net: ethernet: cpsw: fix hangs with interrupts
From: Felipe Balbi @ 2015-01-02 18:10 UTC (permalink / raw)
  To: David Miller
  Cc: Mugunthan V N, Yegor Yefremov, Linux OMAP Mailing List, netdev,
	Felipe Balbi, stable
In-Reply-To: <1420222228-31949-1-git-send-email-balbi@ti.com>

The CPSW IP implements pulse-signaled interrupts. Due to
that we must write a correct, pre-defined value to the
CPDMA_MACEOIVECTOR register so the controller generates
a pulse on the correct IRQ line to signal the End Of
Interrupt.

The way the driver is written today, all four IRQ lines
are requested using the same IRQ handler and, because of
that, we could fall into situations where a TX IRQ fires
but we tell the controller that we ended an RX IRQ (or
vice-versa). This situation triggers an IRQ storm on the
reserved IRQ 127 of INTC which will in turn call ack_bad_irq()
which will, then, print a ton of:

	unexpected IRQ trap at vector 00

In order to fix the problem, we are moving all calls to
cpdma_ctlr_eoi() inside the IRQ handler and making sure
we *always* write the correct value to the CPDMA_MACEOIVECTOR
register. Note that the algorithm assumes that IRQ numbers and
value-to-be-written-to-EOI are proportional, meaning that a
write of value 0 would trigger an EOI pulse for the RX_THRESHOLD
Interrupt and that's the IRQ number sitting in the 0-th index
of our irqs_table array.

This, however, is safe at least for current implementations of
CPSW so we will refrain from making the check smarter (and, as
a side-effect, slower) until we actually have a platform where
IRQ lines are swapped.

This patch has been tested for several days with AM335x- and
AM437x-based platforms. AM57x was left out because there are
still pending patches to enable ethernet in mainline for that
platform. A read of the TRM confirms the statement on previous
paragraph.

Reported-by: Yegor Yefremov <yegorslists@googlemail.com>
Fixes: 510a1e7 (drivers: net: davinci_cpdma: acknowledge interrupt properly)
Cc: <stable@vger.kernel.org> # v3.9+
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/net/ethernet/ti/cpsw.c | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c560f9a..e61ee83 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -757,6 +757,14 @@ requeue:
 static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
 {
 	struct cpsw_priv *priv = dev_id;
+	int value = irq - priv->irqs_table[0];
+
+	/* NOTICE: Ending IRQ here. The trick with the 'value' variable above
+	 * is to make sure we will always write the correct value to the EOI
+	 * register. Namely 0 for RX_THRESH Interrupt, 1 for RX Interrupt, 2
+	 * for TX Interrupt and 3 for MISC Interrupt.
+	 */
+	cpdma_ctlr_eoi(priv->dma, value);
 
 	cpsw_intr_disable(priv);
 	if (priv->irq_enabled == true) {
@@ -786,8 +794,6 @@ static int cpsw_poll(struct napi_struct *napi, int budget)
 	int			num_tx, num_rx;
 
 	num_tx = cpdma_chan_process(priv->txch, 128);
-	if (num_tx)
-		cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
 
 	num_rx = cpdma_chan_process(priv->rxch, budget);
 	if (num_rx < budget) {
@@ -795,7 +801,6 @@ static int cpsw_poll(struct napi_struct *napi, int budget)
 
 		napi_complete(napi);
 		cpsw_intr_enable(priv);
-		cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
 		prim_cpsw = cpsw_get_slave_priv(priv, 0);
 		if (prim_cpsw->irq_enabled == false) {
 			prim_cpsw->irq_enabled = true;
@@ -1310,8 +1315,6 @@ static int cpsw_ndo_open(struct net_device *ndev)
 	napi_enable(&priv->napi);
 	cpdma_ctlr_start(priv->dma);
 	cpsw_intr_enable(priv);
-	cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
-	cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
 
 	prim_cpsw = cpsw_get_slave_priv(priv, 0);
 	if (prim_cpsw->irq_enabled == false) {
@@ -1578,9 +1581,6 @@ static void cpsw_ndo_tx_timeout(struct net_device *ndev)
 	cpdma_chan_start(priv->txch);
 	cpdma_ctlr_int_ctrl(priv->dma, true);
 	cpsw_intr_enable(priv);
-	cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
-	cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
-
 }
 
 static int cpsw_ndo_set_mac_address(struct net_device *ndev, void *p)
@@ -1620,9 +1620,6 @@ static void cpsw_ndo_poll_controller(struct net_device *ndev)
 	cpsw_interrupt(ndev->irq, priv);
 	cpdma_ctlr_int_ctrl(priv->dma, true);
 	cpsw_intr_enable(priv);
-	cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_RX);
-	cpdma_ctlr_eoi(priv->dma, CPDMA_EOI_TX);
-
 }
 #endif
 
-- 
2.2.0


^ permalink raw reply related

* [PATCH 0/4] net: cpsw: fix hangs and improve IRQ handling
From: Felipe Balbi @ 2015-01-02 18:10 UTC (permalink / raw)
  To: David Miller
  Cc: Mugunthan V N, Yegor Yefremov, Linux OMAP Mailing List, netdev,
	Felipe Balbi

Hi folks,

patch 1 fixes the bug reported by Yegor Yefremov <yegorslists@googlemail.com>.

patches 2 - 4 improve IRQ handling a little bit.

Tested with BeagleBone Black and AM437x SK. The bug fix has been
tested for almost 3 days non-stop while the following patches
have been tested for a couple of hours with iperf and nuttcp and
NFS root.

Note that we also have a slight throughput improvement after patch 3
when running with AM437x SK (10.0.1.13 below):

===== pre-patch =====

$ iperf -c 10.0.1.13
------------------------------------------------------------
Client connecting to 10.0.1.13, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 10.0.1.2 port 38430 connected with 10.0.1.13 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   240 MBytes   201 Mbits/sec
$ iperf -c 10.0.1.101
------------------------------------------------------------
Client connecting to 10.0.1.101, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 10.0.1.2 port 35143 connected with 10.0.1.101 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   113 MBytes  94.7 Mbits/sec


===== post-patch =====

$ iperf -c 10.0.1.13
------------------------------------------------------------
Client connecting to 10.0.1.13, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 10.0.1.2 port 38447 connected with 10.0.1.13 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   283 MBytes   237 Mbits/sec
$ iperf -c 10.0.1.101
------------------------------------------------------------
Client connecting to 10.0.1.101, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 10.0.1.2 port 35157 connected with 10.0.1.101 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   113 MBytes  94.4 Mbits/sec

That minor decrease on beagleboneblack (10.0.1.101) is so small that's
likely into the error margin, but I'll run some further profiling as
I have a feeling INTC's IRQ handling can be improved.

In any case, patch 1 should go in during the -rc an get backported
all the way back to v3.9, while the other patches can (should) be
delayed for v3.20 merge window.

Felipe Balbi (4):
  net: ethernet: cpsw: fix hangs with interrupts
  net: ethernet: cpsw: unroll IRQ request loop
  net: ethernet: cpsw: split out IRQ handler
  net: ethernet: cpsw: don't requests IRQs we don't use

 drivers/net/ethernet/ti/cpsw.c | 81 +++++++++++++++++++++++++++---------------
 1 file changed, 52 insertions(+), 29 deletions(-)

-- 
2.2.0


^ permalink raw reply

* Re: [PATCH iproute2 v2] bridge/link: add learning_sync policy flag
From: Scott Feldman @ 2015-01-02 17:57 UTC (permalink / raw)
  To: Siva Mannem
  Cc: stephen@networkplumber.org, Netdev, Jiří Pírko,
	Roopa Prabhu
In-Reply-To: <CA+CtxLS7x8zKQ-9xwjoH3=pidkXS9s5b2+K_VO4eDHJTWo5tYQ@mail.gmail.com>

On Fri, Jan 2, 2015 at 9:14 AM, Siva Mannem <siva.mannem.lnx@gmail.com> wrote:
> Hi,
>
>
>> +.BR "learning_sync on " or " learning_sync off "
>> +Controls whether a given port will sync MAC addresses learned on device port to
>> +bridge FDB.
>> +
>
> For the FDB entries synced from device port to bridge FDB, can the
> device port also mention that it will take care of aging the synced
> entries? I am thinking of a use case where the port supports hardware
> learning and hardware aging?

I think the aging settings are per-bridge, not per-bridge-port, so the
policy control you're talking about wouldn't end up here on
/sbin/bridge link.

However, I would argue even with hardware aging capability, we still
should use Linux for aging since all the controls are already there
and it just works.  It keeps the swdev model simple and the swdev
driver simple.  Do you have a counter-argument for why enabling
hardware aging would be better?

-scott

^ permalink raw reply

* Re: [PATCH net-next v1 2/5] ixgbevf: Add a RETA query code
From: Vlad Zolotarov @ 2015-01-02 17:49 UTC (permalink / raw)
  To: Alexander Duyck, netdev
  Cc: gleb, avi, jeffrey.t.kirsher, Don Skidmore, tantilov, Emil S
In-Reply-To: <54A58D69.7080706@gmail.com>


On 01/01/15 20:09, Alexander Duyck wrote:
> On 12/31/2014 10:33 AM, Vlad Zolotarov wrote:
>> On 12/31/14 20:00, Alexander Duyck wrote:
>>> I suspect this code is badly broken as it doesn't take several things
>>> into account.
>>>
>>> First the PF redirection table can have values outside of the range
>>> supported by the VF.  This is allowed as the VF can set how many bits of
>>> the redirection table it actually wants to use.  This is controlled via
>>> the PSRTYPE register.  So for example the PF can be running with 4
>>> queues, and the VF can run either in single queue or as just a pair of
>>> queues.
>>>
>>> Second you could compress this data much more tightly by taking
>>> advantage of the bit widths allowed.  So for everything x540 and older
>>> they only use a 4 bit value per entry.  That means you could
>>> theoretically stuff 8 entries per u32 instead of just 4.
>> Compression is nice but I think ethtool expects it in a certain
>> format: one entry per byte. And since this patch is targeting the
>> ethtool the output format should be as ethtool expects it to be and
>> this is what this patch does. However I agree that masking the
>> appropriate bits according to PSRTYPE is required. Good catch!
> The idea of compression comes into play when you consider there is
> significant latency trying to get messages across the mailbox.  By
> reducing the number of messages needed to get the redirection table you
> should be able to significantly reduce the amount of time needed to
> fetch it.  The job of compressing/expanding the values is actually
> pretty straight forward when you consider all that should be needed is a
> simple loop to perform some shift, and, and or operations.

We are talking about a super slow path here. So, regardless how slow it 
is it should be done only once between boots. Therefore IMHO any code 
complication is not justified here.

>
> - Alex

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox