* [patch-net-next 1/3] net: ethernet: cpsw: unroll IRQ request loop
From: Felipe Balbi @ 2015-01-13 19:44 UTC (permalink / raw)
To: davem
Cc: Tony Lindgren, Linux OMAP Mailing List, mugunthanvnm, netdev,
Felipe Balbi
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 e61ee8351272..6e04128b9543 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
* RE: [PATCH] i40e: don't enable and init FCOE by default when do PF reset
From: Dev, Vasu @ 2015-01-13 19:38 UTC (permalink / raw)
To: Ethan Zhao
Cc: Ronciak, John, Ethan Zhao, Kirsher, Jeffrey T, Brandeburg, Jesse,
Allan, Bruce W, Wyborny, Carolyn, Skidmore, Donald C,
Rose, Gregory V, Vick, Matthew, Williams, Mitch A, Parikh, Neerav,
Linux NICS, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
brian.maly@oracle.com
In-Reply-To: <CABawtvN_afL4B=fwtRJF_YJpe7tv6yf-OHJipWkGd-AiAjtckg@mail.gmail.com>
> -----Original Message-----
> >> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> >> > b/drivers/net/ethernet/intel/i40e/i40e_main.c
> >> > index a5f2660..a2572cc 100644
> >> > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> >> > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> >> > @@ -6180,9 +6180,12 @@ static void i40e_reset_and_rebuild(struct
> >> > i40e_pf *pf, bool reinit)
> >> > }
> >> > #endif /* CONFIG_I40E_DCB */
> >> > #ifdef I40E_FCOE
> >> > - ret = i40e_init_pf_fcoe(pf);
> >> > - if (ret)
> >> > - dev_info(&pf->pdev->dev, "init_pf_fcoe failed: %d\n", ret);
> >> > + if (pf->flags & I40E_FLAG_FCOE_ENABLED) {
> >> > + ret = i40e_init_pf_fcoe(pf);
> >
> > Calling i40e_init_pf_fcoe() here conflicts with its
> I40E_FLAG_FCOE_ENABLED pre-condition since I40E_FLAG_FCOE_ENABLED is
> set by very same i40e_init_pf_fcoe(), in turn i40e_init_pf_fcoe() will never get
> called.
>
> I don't think so, here ,i40e_reset_and_rebuild() is not the only and the first
> place that i40e_init_pf_fcoe() is called, see i40e_probe(), that is the first
> chance.
>
> i40e_probe()
> -->i40e_sw_init()
> -->i40e_init_pf_fcoe()
>
> And the I40E_FLAG_FCOE_ENABLED is possible be set by
> i40e_fcoe_enable() or i40e_fcoe_disable() interface before the reset action is
> to be done.
>
It is set by i40e_init_pf_fcoe() and you are right that the modified call flow by your patch won't impact setting of I40E_FLAG_FCOE_ENABLED anyway which could have prevented calling i40e_init_pf_fcoe() as I described above, so this is not an issue with the patch.
> BTW, the reason I post this patch is that we hit a bug, after setup vlan, the PF
> is enabled to FCOE.
>
Then that BUG would still remain un-fixed and calling i40e_init_pf_fcoe() under I40E_FLAG_FCOE_ENABLED flag really won't affect call flow to fix anything. I mean I40E_FLAG_FCOE_ENABLED condition will be true with "pf->hw.func_caps.fcoe == true" and otherwise calling i40e_init_pf_fcoe() simply returns back early on after checking "pf->hw.func_caps.fcoe == false", so how that bug is fixed here by added I40E_FLAG_FCOE_ENABLED condition ? What is the bug ?
> >
> > Jeff Kirsher should be getting out a patch queued by me which adds
> I40E_FCoE Kbuild option, in that FCoE is disabled by default and user could
> enable FCoE only if needed, that patch would do same of skipping
> i40e_init_pf_fcoe() whether FCoE capability in device enabled or not in
> default config.
> >
>
> The following patch will not fix the above issue -- configuration of PF will be
> changed via reset.
> How about the FCOE is configured and disabled by i40e_fcoe_disable() ,
> then reset happens ?
>
May be but if the BUG is due to FCoE being enabled then having it disabled in config will avoid the bug for non FCoE config option and once bug is understood then that has to be fixed for FCoE enabled config also as I asked above.
Thanks Ethan for detailed response.
Vasu
> > From patchwork Wed Oct 2 23:26:08 2013
> > Content-Type: text/plain; charset="utf-8"
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > Subject: [net] i40e: adds FCoE configure option
> > Date: Thu, 03 Oct 2013 07:26:08 -0000
> > From: Vasu Dev <vasu.dev@intel.com>
> > X-Patchwork-Id: 11797
> >
> > Adds FCoE config option I40E_FCOE, so that FCoE can be enabled as
> > needed but otherwise have it disabled by default.
> >
> > This also eliminate multiple FCoE config checks, instead now just one
> > config check for CONFIG_I40E_FCOE.
> >
> > The I40E FCoE was added with 3.17 kernel and therefore this patch
> > shall be applied to stable 3.17 kernel also.
> >
> > CC: <stable@vger.kernel.org>
> > Signed-off-by: Vasu Dev <vasu.dev@intel.com>
> > Tested-by: Jim Young <jamesx.m.young@intel.com>
> >
> > ---
> > drivers/net/ethernet/intel/Kconfig | 11 +++++++++++
> > drivers/net/ethernet/intel/i40e/Makefile | 2 +-
> > drivers/net/ethernet/intel/i40e/i40e_osdep.h | 4 ++--
> > 3 files changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/Kconfig
> > b/drivers/net/ethernet/intel/Kconfig
> > index 5b8300a..4d61ef5 100644
> > --- a/drivers/net/ethernet/intel/Kconfig
> > +++ b/drivers/net/ethernet/intel/Kconfig
> > @@ -281,6 +281,17 @@ config I40E_DCB
> >
> > If unsure, say N.
> >
> > +config I40E_FCOE
> > + bool "Fibre Channel over Ethernet (FCoE)"
> > + default n
> > + depends on I40E && DCB && FCOE
> > + ---help---
> > + Say Y here if you want to use Fibre Channel over Ethernet (FCoE)
> > + in the driver. This will create new netdev for exclusive FCoE
> > + use with XL710 FCoE offloads enabled.
> > +
> > + If unsure, say N.
> > +
> > config I40EVF
> > tristate "Intel(R) XL710 X710 Virtual Function Ethernet support"
> > depends on PCI_MSI
> > diff --git a/drivers/net/ethernet/intel/i40e/Makefile
> > b/drivers/net/ethernet/intel/i40e/Makefile
> > index 4b94ddb..c405819 100644
> > --- a/drivers/net/ethernet/intel/i40e/Makefile
> > +++ b/drivers/net/ethernet/intel/i40e/Makefile
> > @@ -44,4 +44,4 @@ i40e-objs := i40e_main.o \
> > i40e_virtchnl_pf.o
> >
> > i40e-$(CONFIG_I40E_DCB) += i40e_dcb.o i40e_dcb_nl.o
> > -i40e-$(CONFIG_FCOE:m=y) += i40e_fcoe.o
> > +i40e-$(CONFIG_I40E_FCOE) += i40e_fcoe.o
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_osdep.h
> > b/drivers/net/ethernet/intel/i40e/i40e_osdep.h
> > index 045b5c4..ad802dd 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_osdep.h
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_osdep.h
> > @@ -78,7 +78,7 @@ do { \
> > } while (0)
> >
> > typedef enum i40e_status_code i40e_status; -#if defined(CONFIG_FCOE)
> > || defined(CONFIG_FCOE_MODULE)
> > +#ifdef CONFIG_I40E_FCOE
> > #define I40E_FCOE
> > -#endif /* CONFIG_FCOE or CONFIG_FCOE_MODULE */
> > +#endif
> > #endif /* _I40E_OSDEP_H_ */
> >
> >> > + if (ret)
> >> > + dev_info(&pf->pdev->dev,
> >> > + "init_pf_fcoe failed: %d\n", ret);
> >> > + }
> >> >
> >> > #endif
> >> > /* do basic switch setup */
> >> > --
> >> > 1.8.3.1
> >
>
> Thanks,
> Ethan
^ permalink raw reply
* Re: [patch net-next v2] tc: add BPF based action
From: David Miller @ 2015-01-13 19:36 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, dborkman, ast, hannes
In-Reply-To: <1421078978-10904-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 12 Jan 2015 17:09:38 +0100
> + bpf_len = nla_get_u16(tb[TCA_ACT_BPF_OPS_LEN]);
> + if (bpf_len > BPF_MAXINSNS || bpf_len == 0)
> + return -EINVAL;
> +
> + bpf_size = bpf_len * sizeof(*bpf_ops);
When I see variables named 'len' and 'size', I expect them to be
in unit bytes.
I think it's clearer to call bpf_len something like "bpf_num_insns",
or "bpf_num_ops", or something like that.
Also, is the OPS_LEN attribute really necessary? Can't you just
figure this out using nla_len() on the OPS attribute? Or is that not
always accurate due to alignment?
^ permalink raw reply
* Re: [PATCH 1/6] net: davinci_emac: Fix hangs with interrupts
From: Felipe Balbi @ 2015-01-13 19:36 UTC (permalink / raw)
To: Tony Lindgren
Cc: David Miller, netdev, linux-omap, Brian Hutchinson, Felipe Balbi
In-Reply-To: <1421177368-19756-2-git-send-email-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2989 bytes --]
On Tue, Jan 13, 2015 at 11:29:23AM -0800, Tony Lindgren wrote:
> On davinci_emac, we have pulse interrupts. This means that we need to
> clear the EOI bits when disabling interrupts as otherwise the interrupts
> keep happening. And we also need to not clear the EOI bits again when
> enabling the interrupts as otherwise we will get tons of:
>
> unexpected IRQ trap at vector 00
>
> These errors almost certainly mean that the omap-intc.c is signaling
> a spurious interrupt with the reserved irq 127 as we've seen earlier
> on omap3.
>
> Let's fix the issue by clearing the EOI bits when disabling the
> interrupts. Let's also keep the comment for "Rx Threshold and Misc
> interrupts are not enabled" for both enable and disable so people
> are aware of this when potentially adding more support.
>
> Note that eventually we should handle the RX and TX interrupts
> separately like cpsw is now doing. However, so far I have not seen
> any issues with this based on my testing, so it seems to behave a
> little different compared to the cpsw that had a similar issue.
>
> Cc: Brian Hutchinson <b.hutchman@gmail.com>
> Cc: Felipe Balbi <balbi@ti.com>
pretty much the same thing that happens with CPSW, I think that a future
patch might want to change things so that we only write EOI to the IRQ
that actually fires, though.
Reviewed-by: Felipe Balbi <balbi@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/net/ethernet/ti/davinci_emac.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index ea71251..383ed52 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -922,6 +922,16 @@ static void emac_int_disable(struct emac_priv *priv)
> if (priv->int_disable)
> priv->int_disable();
>
> + /* NOTE: Rx Threshold and Misc interrupts are not enabled */
> +
> + /* ack rxen only then a new pulse will be generated */
> + emac_write(EMAC_DM646X_MACEOIVECTOR,
> + EMAC_DM646X_MAC_EOI_C0_RXEN);
> +
> + /* ack txen- only then a new pulse will be generated */
> + emac_write(EMAC_DM646X_MACEOIVECTOR,
> + EMAC_DM646X_MAC_EOI_C0_TXEN);
> +
> local_irq_restore(flags);
>
> } else {
> @@ -951,15 +961,6 @@ static void emac_int_enable(struct emac_priv *priv)
> * register */
>
> /* NOTE: Rx Threshold and Misc interrupts are not enabled */
> -
> - /* ack rxen only then a new pulse will be generated */
> - emac_write(EMAC_DM646X_MACEOIVECTOR,
> - EMAC_DM646X_MAC_EOI_C0_RXEN);
> -
> - /* ack txen- only then a new pulse will be generated */
> - emac_write(EMAC_DM646X_MACEOIVECTOR,
> - EMAC_DM646X_MAC_EOI_C0_TXEN);
> -
> } else {
> /* Set DM644x control registers for interrupt control */
> emac_ctrl_write(EMAC_CTRL_EWCTL, 0x1);
> --
> 2.1.4
>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 4/6] net: davinci_emac: Fix incomplete code for getting the phy from device tree
From: Tony Lindgren @ 2015-01-13 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-omap, Brian Hutchinson, Felipe Balbi
In-Reply-To: <1421177368-19756-1-git-send-email-tony@atomide.com>
Looks like the phy_id is never set up beyond getting the phandle.
Note that we can remove the ifdef for phy_node as there is a stub
for of_phy_connec() if CONFIG_OF is not set.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index e9efc74..4c8d82c 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -62,6 +62,7 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_device.h>
+#include <linux/of_mdio.h>
#include <linux/of_irq.h>
#include <linux/of_net.h>
@@ -343,9 +344,7 @@ struct emac_priv {
u32 multicast_hash_cnt[EMAC_NUM_MULTICAST_BITS];
u32 rx_addr_type;
const char *phy_id;
-#ifdef CONFIG_OF
struct device_node *phy_node;
-#endif
struct phy_device *phydev;
spinlock_t lock;
/*platform specific members*/
@@ -1597,8 +1596,20 @@ static int emac_dev_open(struct net_device *ndev)
cpdma_ctlr_start(priv->dma);
priv->phydev = NULL;
+
+ if (priv->phy_node) {
+ priv->phydev = of_phy_connect(ndev, priv->phy_node,
+ &emac_adjust_link, 0, 0);
+ if (!priv->phydev) {
+ dev_err(emac_dev, "could not connect to phy %s\n",
+ priv->phy_node->full_name);
+ ret = -ENODEV;
+ goto err;
+ }
+ }
+
/* use the first phy on the bus if pdata did not give us a phy id */
- if (!priv->phy_id) {
+ if (!priv->phydev && !priv->phy_id) {
struct device *phy;
phy = bus_find_device(&mdio_bus_type, NULL, NULL,
@@ -1607,7 +1618,7 @@ static int emac_dev_open(struct net_device *ndev)
priv->phy_id = dev_name(phy);
}
- if (priv->phy_id && *priv->phy_id) {
+ if (!priv->phydev && priv->phy_id && *priv->phy_id) {
priv->phydev = phy_connect(ndev, priv->phy_id,
&emac_adjust_link,
PHY_INTERFACE_MODE_MII);
@@ -1628,7 +1639,9 @@ static int emac_dev_open(struct net_device *ndev)
"(mii_bus:phy_addr=%s, id=%x)\n",
priv->phydev->drv->name, dev_name(&priv->phydev->dev),
priv->phydev->phy_id);
- } else {
+ }
+
+ if (!priv->phydev) {
/* No PHY , fix the link, speed and duplex settings */
dev_notice(emac_dev, "no phy, defaulting to 100/full\n");
priv->link = 1;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/6] net: davinci_emac: Fix hangs with interrupts
From: Tony Lindgren @ 2015-01-13 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-omap, Brian Hutchinson, Felipe Balbi
In-Reply-To: <1421177368-19756-1-git-send-email-tony@atomide.com>
On davinci_emac, we have pulse interrupts. This means that we need to
clear the EOI bits when disabling interrupts as otherwise the interrupts
keep happening. And we also need to not clear the EOI bits again when
enabling the interrupts as otherwise we will get tons of:
unexpected IRQ trap at vector 00
These errors almost certainly mean that the omap-intc.c is signaling
a spurious interrupt with the reserved irq 127 as we've seen earlier
on omap3.
Let's fix the issue by clearing the EOI bits when disabling the
interrupts. Let's also keep the comment for "Rx Threshold and Misc
interrupts are not enabled" for both enable and disable so people
are aware of this when potentially adding more support.
Note that eventually we should handle the RX and TX interrupts
separately like cpsw is now doing. However, so far I have not seen
any issues with this based on my testing, so it seems to behave a
little different compared to the cpsw that had a similar issue.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index ea71251..383ed52 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -922,6 +922,16 @@ static void emac_int_disable(struct emac_priv *priv)
if (priv->int_disable)
priv->int_disable();
+ /* NOTE: Rx Threshold and Misc interrupts are not enabled */
+
+ /* ack rxen only then a new pulse will be generated */
+ emac_write(EMAC_DM646X_MACEOIVECTOR,
+ EMAC_DM646X_MAC_EOI_C0_RXEN);
+
+ /* ack txen- only then a new pulse will be generated */
+ emac_write(EMAC_DM646X_MACEOIVECTOR,
+ EMAC_DM646X_MAC_EOI_C0_TXEN);
+
local_irq_restore(flags);
} else {
@@ -951,15 +961,6 @@ static void emac_int_enable(struct emac_priv *priv)
* register */
/* NOTE: Rx Threshold and Misc interrupts are not enabled */
-
- /* ack rxen only then a new pulse will be generated */
- emac_write(EMAC_DM646X_MACEOIVECTOR,
- EMAC_DM646X_MAC_EOI_C0_RXEN);
-
- /* ack txen- only then a new pulse will be generated */
- emac_write(EMAC_DM646X_MACEOIVECTOR,
- EMAC_DM646X_MAC_EOI_C0_TXEN);
-
} else {
/* Set DM644x control registers for interrupt control */
emac_ctrl_write(EMAC_CTRL_EWCTL, 0x1);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 1/1 net-next] openvswitch: Remove unnecessary version.h inclusion
From: David Miller @ 2015-01-13 19:31 UTC (permalink / raw)
To: s.syam; +Cc: netdev, dev, pshelar, syamsidhardh
In-Reply-To: <1421075975-27483-1-git-send-email-s.syam@samsung.com>
From: Syam Sidhardhan <s.syam@samsung.com>
Date: Mon, 12 Jan 2015 20:49:35 +0530
> version.h inclusion is not necessary as detected by versioncheck.
>
> Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
> Acked-by: Pravin B Shelar <pshelar@nicira.com>
> ---
> No code changes. Add net-next prefix flag for net-next tree.
Applied, thanks.
^ permalink raw reply
* [PATCH 6/6] net: davinci_emac: Add support for emac on dm816x
From: Tony Lindgren @ 2015-01-13 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-omap, Brian Hutchinson, Felipe Balbi
In-Reply-To: <1421177368-19756-1-git-send-email-tony@atomide.com>
On dm816x we have two emac controllers with separate memory
areas.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
Documentation/devicetree/bindings/net/davinci_emac.txt | 3 ++-
drivers/net/ethernet/ti/davinci_emac.c | 5 +++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/davinci_emac.txt b/Documentation/devicetree/bindings/net/davinci_emac.txt
index 0328088..24c5cda 100644
--- a/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ b/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -4,7 +4,8 @@ This file provides information, what the device node
for the davinci_emac interface contains.
Required properties:
-- compatible: "ti,davinci-dm6467-emac" or "ti,am3517-emac"
+- compatible: "ti,davinci-dm6467-emac", "ti,am3517-emac" or
+ "ti,dm816-emac"
- reg: Offset and length of the register set for the device
- ti,davinci-ctrl-reg-offset: offset to control register
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 0342273..5caee66 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -2101,9 +2101,14 @@ static const struct emac_platform_data am3517_emac_data = {
.hw_ram_addr = 0x01e20000,
};
+static const struct emac_platform_data dm816_emac_data = {
+ .version = EMAC_VERSION_2,
+};
+
static const struct of_device_id davinci_emac_of_match[] = {
{.compatible = "ti,davinci-dm6467-emac", },
{.compatible = "ti,am3517-emac", .data = &am3517_emac_data, },
+ {.compatible = "ti,dm816-emac", .data = &dm816_emac_data, },
{},
};
MODULE_DEVICE_TABLE(of, davinci_emac_of_match);
--
2.1.4
^ permalink raw reply related
* [PATCH 5/6] net: davinci_emac: Fix ioremap for devices with MDIO within the EMAC address space
From: Tony Lindgren @ 2015-01-13 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-omap, Brian Hutchinson, Felipe Balbi
In-Reply-To: <1421177368-19756-1-git-send-email-tony@atomide.com>
Some devices like dm816x have the MDIO registers within the first EMAC
instance address space. Let's fix the issue by allowing to pass an
optional second IO range for the EMAC control register area.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 4c8d82c..0342273 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1877,7 +1877,7 @@ davinci_emac_of_get_pdata(struct platform_device *pdev, struct emac_priv *priv)
static int davinci_emac_probe(struct platform_device *pdev)
{
int rc = 0;
- struct resource *res;
+ struct resource *res, *res_ctrl;
struct net_device *ndev;
struct emac_priv *priv;
unsigned long hw_ram_addr;
@@ -1936,11 +1936,20 @@ static int davinci_emac_probe(struct platform_device *pdev)
rc = PTR_ERR(priv->remap_addr);
goto no_pdata;
}
+
+ res_ctrl = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (res_ctrl) {
+ priv->ctrl_base =
+ devm_ioremap_resource(&pdev->dev, res_ctrl);
+ if (IS_ERR(priv->ctrl_base))
+ goto no_pdata;
+ } else {
+ priv->ctrl_base = priv->remap_addr + pdata->ctrl_mod_reg_offset;
+ }
+
priv->emac_base = priv->remap_addr + pdata->ctrl_reg_offset;
ndev->base_addr = (unsigned long)priv->remap_addr;
- priv->ctrl_base = priv->remap_addr + pdata->ctrl_mod_reg_offset;
-
hw_ram_addr = pdata->hw_ram_addr;
if (!hw_ram_addr)
hw_ram_addr = (u32 __force)res->start + pdata->ctrl_ram_offset;
--
2.1.4
^ permalink raw reply related
* [PATCH 3/6] net: davinci_emac: Free clock after checking the frequency
From: Tony Lindgren @ 2015-01-13 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-omap, Brian Hutchinson, Felipe Balbi
In-Reply-To: <1421177368-19756-1-git-send-email-tony@atomide.com>
We only use clk_get() to get the frequency, the rest is done by
the runtime PM calls. Let's free the clock too.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index deb43b3..e9efc74 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1881,6 +1881,7 @@ static int davinci_emac_probe(struct platform_device *pdev)
return -EBUSY;
}
emac_bus_frequency = clk_get_rate(emac_clk);
+ clk_put(emac_clk);
/* TODO: Probe PHY here if possible */
--
2.1.4
^ permalink raw reply related
* [PATCH 2/6] net: davinci_emac: Fix runtime pm calls for davinci_emac
From: Tony Lindgren @ 2015-01-13 19:29 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-omap, Brian Hutchinson, Felipe Balbi, Mark A. Greer
In-Reply-To: <1421177368-19756-1-git-send-email-tony@atomide.com>
Commit 3ba97381343b ("net: ethernet: davinci_emac: add pm_runtime support")
added support for runtime PM, but it causes issues on omap3 related devices
that actually gate the clocks:
Unhandled fault: external abort on non-linefetch (0x1008)
...
[<c04160f0>] (emac_dev_getnetstats) from [<c04d6a3c>] (dev_get_stats+0x78/0xc8)
[<c04d6a3c>] (dev_get_stats) from [<c04e9ccc>] (rtnl_fill_ifinfo+0x3b8/0x938)
[<c04e9ccc>] (rtnl_fill_ifinfo) from [<c04eade4>] (rtmsg_ifinfo+0x68/0xd8)
[<c04eade4>] (rtmsg_ifinfo) from [<c04dd35c>] (register_netdevice+0x3a0/0x4ec)
[<c04dd35c>] (register_netdevice) from [<c04dd4bc>] (register_netdev+0x14/0x24)
[<c04dd4bc>] (register_netdev) from [<c041755c>] (davinci_emac_probe+0x408/0x5c8)
[<c041755c>] (davinci_emac_probe) from [<c0396d78>] (platform_drv_probe+0x48/0xa4)
Let's fix it by moving the pm_runtime_get() call earlier, and also
add it to the emac_dev_getnetstats(). Also note that we want to use
pm_rutime_get_sync() as we don't want to have deferred_resume happen.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 383ed52..deb43b3 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1538,7 +1538,7 @@ static int emac_dev_open(struct net_device *ndev)
int i = 0;
struct emac_priv *priv = netdev_priv(ndev);
- pm_runtime_get(&priv->pdev->dev);
+ pm_runtime_get_sync(&priv->pdev->dev);
netif_carrier_off(ndev);
for (cnt = 0; cnt < ETH_ALEN; cnt++)
@@ -1726,6 +1726,8 @@ static struct net_device_stats *emac_dev_getnetstats(struct net_device *ndev)
u32 mac_control;
u32 stats_clear_mask;
+ pm_runtime_get_sync(&priv->pdev->dev);
+
/* update emac hardware stats and reset the registers*/
mac_control = emac_read(EMAC_MACCONTROL);
@@ -1767,6 +1769,8 @@ static struct net_device_stats *emac_dev_getnetstats(struct net_device *ndev)
ndev->stats.tx_fifo_errors += emac_read(EMAC_TXUNDERRUN);
emac_write(EMAC_TXUNDERRUN, stats_clear_mask);
+ pm_runtime_put(&priv->pdev->dev);
+
return &ndev->stats;
}
@@ -1981,12 +1985,16 @@ static int davinci_emac_probe(struct platform_device *pdev)
ndev->ethtool_ops = ðtool_ops;
netif_napi_add(ndev, &priv->napi, emac_poll, EMAC_POLL_WEIGHT);
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get_sync(&pdev->dev);
+
/* register the network device */
SET_NETDEV_DEV(ndev, &pdev->dev);
rc = register_netdev(ndev);
if (rc) {
dev_err(&pdev->dev, "error in register_netdev\n");
rc = -ENODEV;
+ pm_runtime_put(&pdev->dev);
goto no_cpdma_chan;
}
@@ -1996,9 +2004,7 @@ static int davinci_emac_probe(struct platform_device *pdev)
"(regs: %p, irq: %d)\n",
(void *)priv->emac_base_phys, ndev->irq);
}
-
- pm_runtime_enable(&pdev->dev);
- pm_runtime_resume(&pdev->dev);
+ pm_runtime_put(&pdev->dev);
return 0;
--
2.1.4
^ permalink raw reply related
* [PATCH 0/6] Fixes for davinci_emac
From: Tony Lindgren @ 2015-01-13 19:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-omap
Hi,
Here are some fixes for davinci_emac for the issues I've noticed
recently.
Regards,
Tony
Tony Lindgren (6):
net: davinci_emac: Fix hangs with interrupts
net: davinci_emac: Fix runtime pm calls for davinci_emac
net: davinci_emac: Free clock after checking the frequency
net: davinci_emac: Fix incomplete code for getting the phy from device
tree
net: davinci_emac: Fix ioremap for devices with MDIO within the EMAC
address space
net: davinci_emac: Add support for emac on dm816x
.../devicetree/bindings/net/davinci_emac.txt | 3 +-
drivers/net/ethernet/ti/davinci_emac.c | 77 ++++++++++++++++------
2 files changed, 58 insertions(+), 22 deletions(-)
--
2.1.4
^ permalink raw reply
* Re: Fwd: [rhashtable] WARNING: CPU: 0 PID: 10 at kernel/locking/mutex.c:570 mutex_lock_nested()
From: Thomas Graf @ 2015-01-13 19:28 UTC (permalink / raw)
To: Cong Wang; +Cc: Ying Xue, linux-kernel@vger.kernel.org, lkp, Netdev
In-Reply-To: <CAHA+R7M1ZSCF+FwKVtZUbsJ05zesNg-WVTqH13=oFe5gM--3gw@mail.gmail.com>
On 01/13/15 at 11:14am, Cong Wang wrote:
> On Tue, Jan 13, 2015 at 12:41 AM, Thomas Graf <tgraf@suug.ch> wrote:
> > I can't reproduce it in my KVM box either so far. It looks like a
> > mutex_lock() on an uninitialized mutex or use after free but I can't
> > find such a code path so far.
>
> Couldn't that be the delayed work is still running after rhashtable
> is destroyed by its caller? I mean, cancel_delayed_work_sync()
> should be called in rhashtable_destroy()?
>
> Of course, it may be caller's responsibility to ensure that, I haven't
> looked into it that much.
Yes, we came to the very same conclusion in a different email thread
and found the offending race condition.
^ permalink raw reply
* Re: [PATCH] af_packet: fix typo of "unlikely" conditional in packet_snd
From: David Miller @ 2015-01-13 19:26 UTC (permalink / raw)
To: linville; +Cc: netdev, dborkman, hannes
In-Reply-To: <1421176811-22594-1-git-send-email-linville@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 13 Jan 2015 14:20:11 -0500
> Change "unlikely(offset) < 0" to "unlikely(offset < 0)"...
>
> Coverity: CID 1259984
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Should be fixed in the 'net' tree by:
commit 46d2cfb192b30d729aef064808ed5ece47cee369
Author: Christoph Jaeger <cj@linux.com>
Date: Sun Jan 11 13:01:16 2015 -0500
packet: bail out of packet_snd() if L2 header creation fails
^ permalink raw reply
* Re: [PATCH] bridge: only provide proxy ARP when CONFIG_INET is enabled
From: Cong Wang @ 2015-01-13 19:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: netdev, Kyeyoon Park, bridge@lists.linux-foundation.org,
David Miller
In-Reply-To: <56868207.rHBDZL3pbk@wuerfel>
On Tue, Jan 13, 2015 at 6:10 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> When IPV4 support is disabled, we cannot call arp_send from
> the bridge code, which would result in a kernel link error:
>
> net/built-in.o: In function `br_handle_frame_finish':
> :(.text+0x59914): undefined reference to `arp_send'
> :(.text+0x59a50): undefined reference to `arp_tbl'
>
> This makes the newly added proxy ARP support in the bridge
> code depend on the CONFIG_INET symbol and lets the compiler
> optimize the code out to avoid the link error.
>
Not sure how much sense to make CONFIG_BRIDGE depend
on CONFIG_INET, at least CONFIG_BONDING does.
^ permalink raw reply
* Re: [PATCH net-next v3] tcp: avoid reducing cwnd when ACK+DSACK is received
From: David Miller @ 2015-01-13 19:22 UTC (permalink / raw)
To: sebastien.barre
Cc: ncardwell, ycheng, eric.dumazet, netdev, gregory.detal, nanditad
In-Reply-To: <1421055040-8732-1-git-send-email-sebastien.barre@uclouvain.be>
From: Sébastien Barré <sebastien.barre@uclouvain.be>
Date: Mon, 12 Jan 2015 10:30:40 +0100
> With TLP, the peer may reply to a probe with an
> ACK+D-SACK, with ack value set to tlp_high_seq. In the current code,
> such ACK+DSACK will be missed and only at next, higher ack will the TLP
> episode be considered done. Since the DSACK is not present anymore,
> this will cost a cwnd reduction.
>
> This patch ensures that this scenario does not cause a cwnd reduction, since
> receiving an ACK+DSACK indicates that both the initial segment and the probe
> have been received by the peer.
>
> The following packetdrill test, from Neal Cardwell, validates this patch:
...
> Credits:
> -Gregory helped in finding that tcp_process_tlp_ack was where the cwnd
> got reduced in our MPTCP tests.
> -Neal wrote the packetdrill test above
> -Yuchung reworked the patch to make it more readable.
>
> Cc: Gregory Detal <gregory.detal@uclouvain.be>
> Cc: Nandita Dukkipati <nanditad@google.com>
> Tested-by: Neal Cardwell <ncardwell@google.com>
> Reviewed-by: Yuchung Cheng <ycheng@google.com>
> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Sébastien Barré <sebastien.barre@uclouvain.be>
Applied, thanks everyone.
^ permalink raw reply
* [PATCH] af_packet: fix typo of "unlikely" conditional in packet_snd
From: John W. Linville @ 2015-01-13 19:20 UTC (permalink / raw)
To: netdev
Cc: Daniel Borkmann, David S. Miller, Hannes Frederic Sowa,
John W. Linville
Change "unlikely(offset) < 0" to "unlikely(offset < 0)"...
Coverity: CID 1259984
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Compile tested only...
net/packet/af_packet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 6880f34a529a..9cfe2e1dd8b5 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2517,7 +2517,7 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)
err = -EINVAL;
if (sock->type == SOCK_DGRAM) {
offset = dev_hard_header(skb, dev, ntohs(proto), addr, NULL, len);
- if (unlikely(offset) < 0)
+ if (unlikely(offset < 0))
goto out_free;
} else {
if (ll_header_truncated(dev, len))
--
2.1.0
^ permalink raw reply related
* Re: Fwd: [rhashtable] WARNING: CPU: 0 PID: 10 at kernel/locking/mutex.c:570 mutex_lock_nested()
From: Cong Wang @ 2015-01-13 19:14 UTC (permalink / raw)
To: Thomas Graf; +Cc: Ying Xue, linux-kernel@vger.kernel.org, lkp, Netdev
In-Reply-To: <20150113084126.GE20387@casper.infradead.org>
On Tue, Jan 13, 2015 at 12:41 AM, Thomas Graf <tgraf@suug.ch> wrote:
> On 01/13/15 at 03:50pm, Ying Xue wrote:
>> On 01/12/2015 08:42 PM, Thomas Graf wrote:
>> > On 01/12/15 at 09:38am, Ying Xue wrote:
>> >> Hi Thomas,
>> >>
>> >> I am really unable to see where is wrong leading to below warning
>> >> complaints. Can you please help me check it?
>> >
>> > Not sure yet. It's not your patch that introduced the issue though.
>> > It merely exposed the affected code path.
>> >
>> > Just wondering, did you test with CONFIG_DEBUG_MUTEXES enabled?
>> >
>> >
>>
>> After I enable above option, I don't find similar complaints during my
>> testing.
>
> I can't reproduce it in my KVM box either so far. It looks like a
> mutex_lock() on an uninitialized mutex or use after free but I can't
> find such a code path so far.
Couldn't that be the delayed work is still running after rhashtable
is destroyed by its caller? I mean, cancel_delayed_work_sync()
should be called in rhashtable_destroy()?
Of course, it may be caller's responsibility to ensure that, I haven't
looked into it that much.
^ permalink raw reply
* Re: [PATCH] Corrected the comment describing the ndo operations to reflect the actual prototype for couple of operations
From: David Miller @ 2015-01-13 19:04 UTC (permalink / raw)
To: marichika4; +Cc: netdev
In-Reply-To: <1421054185-10249-1-git-send-email-marichika4@gmail.com>
From: B Viswanath <marichika4@gmail.com>
Date: Mon, 12 Jan 2015 14:46:25 +0530
> Corrected the comment describing the ndo operations to
> reflect the actual prototype for couple of operations
>
> Signed-off-by: B Viswanath <marichika4@gmail.com>
Applied, thanks.
Please in the future put proper subsystem prefixes in your Subject lines,
in this case it should have been "[PATCH] net: Corrected ..."
^ permalink raw reply
* Re: [PATCH] i40e: avoid use of uninitialized v_budget in i40e_init_msix
From: Jeff Kirsher @ 2015-01-13 19:03 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, Linux NICS
In-Reply-To: <1421174908-20445-1-git-send-email-linville@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
On Tue, 2015-01-13 at 13:48 -0500, John W. Linville wrote:
> This I40E_FCOE block increments v_budget before it has been
> initialized,
> then v_budget gets overwritten a few lines later. This patch just
> reorders the code hunks in what I believe was the intended sequence.
>
> Coverity: CID 1260099
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> Compile tested only...
>
> drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
Thanks John, I will add your patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net-next 00/15][pull request] Intel Wired LAN Driver Updates 2015-01-13
From: Jeff Kirsher @ 2015-01-13 19:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20150113.135751.1359752961454701029.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 395 bytes --]
On Tue, 2015-01-13 at 13:57 -0500, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Tue, 13 Jan 2015 03:33:16 -0800
>
> > This series contains updates to i40e and i40evf.
>
> There was minor feedback for patch #3, please address and
> respin, thanks.
I was just about to send you email saying I am re-spinning the series
with an updated patch #3. :-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] remove nl_sk_hash_lock from netlink socket
From: David Miller @ 2015-01-13 19:01 UTC (permalink / raw)
To: ying.xue; +Cc: tgraf, netdev
In-Reply-To: <1421045544-13670-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Mon, 12 Jan 2015 14:52:21 +0800
> After tipc socket successfully avoids the involvement of an extra lock
> with rhashtable_lookup_insert(), it's possible for netlink socket to
> remove its hash socket lock now. But as netlink socket needs a compare
> function to look for an object, we first introduce a new function
> called rhashtable_lookup_compare_insert() in commit #1 which is
> implemented based on original rhashtable_lookup_insert(). We
> subsequently remove nl_sk_hash_lock from netlink socket with the new
> introduced function in commit #2. Lastly, as Thomas requested, we add
> commit #3 to indicate the implementation of what the grow and shrink
> decision function must enforce min/max shift.
>
> v2:
> As Thomas pointed out, there was a race between checking portid and
> then setting it in commit #2. Now use socket lock to make the process
> of both checking and setting portid atomic, and then eliminate the
> race.
Series applied, thanks.
^ permalink raw reply
* [PATCH] i40e: avoid use of uninitialized v_budget in i40e_init_msix
From: John W. Linville @ 2015-01-13 18:48 UTC (permalink / raw)
To: netdev; +Cc: Jeff Kirsher, Linux NICS, John W. Linville
This I40E_FCOE block increments v_budget before it has been initialized,
then v_budget gets overwritten a few lines later. This patch just
reorders the code hunks in what I believe was the intended sequence.
Coverity: CID 1260099
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Compile tested only...
drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index a5f2660d552d..5415d9fd7c63 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -6881,17 +6881,17 @@ static int i40e_init_msix(struct i40e_pf *pf)
if (pf->flags & I40E_FLAG_FD_SB_ENABLED)
other_vecs++;
+ /* Scale down if necessary, and the rings will share vectors */
+ pf->num_lan_msix = min_t(int, pf->num_lan_msix,
+ (hw->func_caps.num_msix_vectors - other_vecs));
+ v_budget = pf->num_lan_msix + other_vecs;
+
#ifdef I40E_FCOE
if (pf->flags & I40E_FLAG_FCOE_ENABLED) {
pf->num_fcoe_msix = pf->num_fcoe_qps;
v_budget += pf->num_fcoe_msix;
}
-
#endif
- /* Scale down if necessary, and the rings will share vectors */
- pf->num_lan_msix = min_t(int, pf->num_lan_msix,
- (hw->func_caps.num_msix_vectors - other_vecs));
- v_budget = pf->num_lan_msix + other_vecs;
pf->msix_entries = kcalloc(v_budget, sizeof(struct msix_entry),
GFP_KERNEL);
--
2.1.0
^ permalink raw reply related
* Re: [net-next 00/15][pull request] Intel Wired LAN Driver Updates 2015-01-13
From: David Miller @ 2015-01-13 18:57 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1421148811-9763-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 13 Jan 2015 03:33:16 -0800
> This series contains updates to i40e and i40evf.
There was minor feedback for patch #3, please address and
respin, thanks.
^ permalink raw reply
* Re: [RFC PATCH v2 2/2] net: ixgbe: implement af_packet direct queue mappings
From: Willem de Bruijn @ 2015-01-13 18:58 UTC (permalink / raw)
To: John Fastabend
Cc: Network Development, Zhou, Danny, Neil Horman, Daniel Borkmann,
Ronciak, John, Hannes Frederic Sowa, brouer
In-Reply-To: <20150113043542.29985.15658.stgit@nitbit.x32>
On Mon, Jan 12, 2015 at 11:35 PM, John Fastabend
<john.fastabend@gmail.com> wrote:
> This allows driver queues to be split off and mapped into user
> space using af_packet.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 17 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 23 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 407 ++++++++++++++++++++++
> drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1
> 4 files changed, 440 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> index 38fc64c..aa4960e 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> @@ -204,6 +204,20 @@ struct ixgbe_tx_queue_stats {
> u64 tx_done_old;
> };
>
> +#define MAX_USER_DMA_REGIONS_PER_SOCKET 16
> +
> +struct ixgbe_user_dma_region {
> + dma_addr_t dma_region_iova;
> + unsigned long dma_region_size;
> + int direction;
> +};
> +
> +struct ixgbe_user_queue_info {
> + struct sock *sk_handle;
> + struct ixgbe_user_dma_region regions[MAX_USER_DMA_REGIONS_PER_SOCKET];
> + int num_of_regions;
> +};
> +
> struct ixgbe_rx_queue_stats {
> u64 rsc_count;
> u64 rsc_flush;
> @@ -673,6 +687,9 @@ struct ixgbe_adapter {
>
> struct ixgbe_q_vector *q_vector[MAX_Q_VECTORS];
>
> + /* Direct User Space Queues */
> + struct ixgbe_user_queue_info user_queue_info[MAX_RX_QUEUES];
> +
> /* DCB parameters */
> struct ieee_pfc *ixgbe_ieee_pfc;
> struct ieee_ets *ixgbe_ieee_ets;
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> index e5be0dd..f180a58 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> @@ -2598,12 +2598,17 @@ static int ixgbe_add_ethtool_fdir_entry(struct ixgbe_adapter *adapter,
> if (!(adapter->flags & IXGBE_FLAG_FDIR_PERFECT_CAPABLE))
> return -EOPNOTSUPP;
>
> + if (fsp->ring_cookie > MAX_RX_QUEUES)
> + return -EINVAL;
> +
> /*
> * Don't allow programming if the action is a queue greater than
> - * the number of online Rx queues.
> + * the number of online Rx queues unless it is a user space
> + * queue.
> */
> if ((fsp->ring_cookie != RX_CLS_FLOW_DISC) &&
> - (fsp->ring_cookie >= adapter->num_rx_queues))
> + (fsp->ring_cookie >= adapter->num_rx_queues) &&
> + !adapter->user_queue_info[fsp->ring_cookie].sk_handle)
> return -EINVAL;
>
> /* Don't allow indexes to exist outside of available space */
> @@ -2680,12 +2685,18 @@ static int ixgbe_add_ethtool_fdir_entry(struct ixgbe_adapter *adapter,
> /* apply mask and compute/store hash */
> ixgbe_atr_compute_perfect_hash_82599(&input->filter, &mask);
>
> + /* Set input action to reg_idx for driver owned queues otherwise
> + * use the absolute index for user space queues.
> + */
> + if (fsp->ring_cookie < adapter->num_rx_queues &&
> + fsp->ring_cookie != IXGBE_FDIR_DROP_QUEUE)
> + input->action = adapter->rx_ring[input->action]->reg_idx;
> +
> /* program filters to filter memory */
> err = ixgbe_fdir_write_perfect_filter_82599(hw,
> - &input->filter, input->sw_idx,
> - (input->action == IXGBE_FDIR_DROP_QUEUE) ?
> - IXGBE_FDIR_DROP_QUEUE :
> - adapter->rx_ring[input->action]->reg_idx);
> + &input->filter,
> + input->sw_idx,
> + input->action);
> if (err)
> goto err_out_w_lock;
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 2ed2c7d..be5bde86 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -50,6 +50,9 @@
> #include <linux/if_bridge.h>
> #include <linux/prefetch.h>
> #include <scsi/fc/fc_fcoe.h>
> +#include <linux/mm.h>
> +#include <linux/if_packet.h>
> +#include <linux/iommu.h>
>
> #ifdef CONFIG_OF
> #include <linux/of_net.h>
> @@ -80,6 +83,12 @@ const char ixgbe_driver_version[] = DRV_VERSION;
> static const char ixgbe_copyright[] =
> "Copyright (c) 1999-2014 Intel Corporation.";
>
> +static unsigned int *dummy_page_buf;
> +
> +#ifndef CONFIG_DMA_MEMORY_PROTECTION
> +#define CONFIG_DMA_MEMORY_PROTECTION
> +#endif
> +
> static const struct ixgbe_info *ixgbe_info_tbl[] = {
> [board_82598] = &ixgbe_82598_info,
> [board_82599] = &ixgbe_82599_info,
> @@ -167,6 +176,76 @@ MODULE_DESCRIPTION("Intel(R) 10 Gigabit PCI Express Network Driver");
> MODULE_LICENSE("GPL");
> MODULE_VERSION(DRV_VERSION);
>
> +enum ixgbe_legacy_rx_enum {
> + IXGBE_LEGACY_RX_FIELD_PKT_ADDR = 0, /* Packet buffer address */
> + IXGBE_LEGACY_RX_FIELD_LENGTH, /* Packet length */
> + IXGBE_LEGACY_RX_FIELD_CSUM, /* Fragment checksum */
> + IXGBE_LEGACY_RX_FIELD_STATUS, /* Descriptors status */
> + IXGBE_LEGACY_RX_FIELD_ERRORS, /* Receive errors */
> + IXGBE_LEGACY_RX_FIELD_VLAN, /* VLAN tag */
> +};
> +
> +enum ixgbe_legacy_tx_enum {
> + IXGBE_LEGACY_TX_FIELD_PKT_ADDR = 0, /* Packet buffer address */
> + IXGBE_LEGACY_TX_FIELD_LENGTH, /* Packet length */
> + IXGBE_LEGACY_TX_FIELD_CSO, /* Checksum offset*/
> + IXGBE_LEGACY_TX_FIELD_CMD, /* Descriptor control */
> + IXGBE_LEGACY_TX_FIELD_STATUS, /* Descriptor status */
> + IXGBE_LEGACY_TX_FIELD_RSVD, /* Reserved */
> + IXGBE_LEGACY_TX_FIELD_CSS, /* Checksum start */
> + IXGBE_LEGACY_TX_FIELD_VLAN_TAG, /* VLAN tag */
> +};
> +
> +/* IXGBE Receive Descriptor - Legacy */
> +static const struct tpacket_nic_desc_fld ixgbe_legacy_rx_desc[] = {
> + /* Packet buffer address */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_RX_FIELD_PKT_ADDR,
> + 0, 64, 64, BO_NATIVE)},
> + /* Packet length */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_RX_FIELD_LENGTH,
> + 64, 16, 8, BO_NATIVE)},
> + /* Fragment checksum */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_RX_FIELD_CSUM,
> + 80, 16, 8, BO_NATIVE)},
> + /* Descriptors status */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_RX_FIELD_STATUS,
> + 96, 8, 8, BO_NATIVE)},
> + /* Receive errors */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_RX_FIELD_ERRORS,
> + 104, 8, 8, BO_NATIVE)},
> + /* VLAN tag */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_RX_FIELD_VLAN,
> + 112, 16, 8, BO_NATIVE)},
> +};
> +
> +/* IXGBE Transmit Descriptor - Legacy */
> +static const struct tpacket_nic_desc_fld ixgbe_legacy_tx_desc[] = {
> + /* Packet buffer address */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_TX_FIELD_PKT_ADDR,
> + 0, 64, 64, BO_NATIVE)},
> + /* Data buffer length */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_TX_FIELD_LENGTH,
> + 64, 16, 8, BO_NATIVE)},
> + /* Checksum offset */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_TX_FIELD_CSO,
> + 80, 8, 8, BO_NATIVE)},
> + /* Command byte */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_TX_FIELD_CMD,
> + 88, 8, 8, BO_NATIVE)},
> + /* Transmitted status */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_TX_FIELD_STATUS,
> + 96, 4, 1, BO_NATIVE)},
> + /* Reserved */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_TX_FIELD_RSVD,
> + 100, 4, 1, BO_NATIVE)},
> + /* Checksum start */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_TX_FIELD_CSS,
> + 104, 8, 8, BO_NATIVE)},
> + /* VLAN tag */
> + {PACKET_NIC_DESC_FIELD(IXGBE_LEGACY_TX_FIELD_VLAN_TAG,
> + 112, 16, 8, BO_NATIVE)},
> +};
> +
> static bool ixgbe_check_cfg_remove(struct ixgbe_hw *hw, struct pci_dev *pdev);
>
> static int ixgbe_read_pci_cfg_word_parent(struct ixgbe_adapter *adapter,
> @@ -3137,6 +3216,17 @@ static void ixgbe_enable_rx_drop(struct ixgbe_adapter *adapter,
> IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(reg_idx), srrctl);
> }
>
> +static bool ixgbe_have_user_queues(struct ixgbe_adapter *adapter)
> +{
> + int i;
> +
> + for (i = 0; i < MAX_RX_QUEUES; i++) {
> + if (adapter->user_queue_info[i].sk_handle)
> + return true;
> + }
> + return false;
> +}
> +
> static void ixgbe_disable_rx_drop(struct ixgbe_adapter *adapter,
> struct ixgbe_ring *ring)
> {
> @@ -3171,7 +3261,8 @@ static void ixgbe_set_rx_drop_en(struct ixgbe_adapter *adapter)
> * and performance reasons.
> */
> if (adapter->num_vfs || (adapter->num_rx_queues > 1 &&
> - !(adapter->hw.fc.current_mode & ixgbe_fc_tx_pause) && !pfc_en)) {
> + !(adapter->hw.fc.current_mode & ixgbe_fc_tx_pause) && !pfc_en) ||
> + ixgbe_have_user_queues(adapter)) {
> for (i = 0; i < adapter->num_rx_queues; i++)
> ixgbe_enable_rx_drop(adapter, adapter->rx_ring[i]);
> } else {
> @@ -7938,6 +8029,306 @@ static void ixgbe_fwd_del(struct net_device *pdev, void *priv)
> kfree(fwd_adapter);
> }
>
> +static int ixgbe_ndo_split_queue_pairs(struct net_device *dev,
> + unsigned int start_from,
> + unsigned int qpairs_num,
> + struct sock *sk)
> +{
> + struct ixgbe_adapter *adapter = netdev_priv(dev);
> + unsigned int qpair_index;
> +
> + /* allocate whatever available qpairs */
> + if (start_from == -1) {
When is this wildcard case used? If the nic is configured to send
specific traffic to a specific rxqueue, then that queue has to be
mapped. When is an arbitrary queue acceptable?
> + unsigned int count = 0;
> +
> + for (qpair_index = adapter->num_rx_queues;
> + qpair_index < MAX_RX_QUEUES;
> + qpair_index++) {
> + if (!adapter->user_queue_info[qpair_index].sk_handle) {
> + count++;
> + if (count == qpairs_num) {
> + start_from = qpair_index - count + 1;
> + break;
> + }
> + } else {
> + count = 0;
> + }
> + }
> + }
> +
> + /* otherwise the caller specified exact queues */
> + if ((start_from > MAX_TX_QUEUES) ||
> + (start_from > MAX_RX_QUEUES) ||
> + (start_from + qpairs_num > MAX_TX_QUEUES) ||
> + (start_from + qpairs_num > MAX_RX_QUEUES))
> + return -EINVAL;
> +
> + /* If the qpairs are being used by the driver do not let user space
> + * consume the queues. Also if the queue has already been allocated
> + * to a socket do fail the request.
> + */
> + for (qpair_index = start_from;
> + qpair_index < start_from + qpairs_num;
> + qpair_index++) {
> + if ((qpair_index < adapter->num_tx_queues) ||
> + (qpair_index < adapter->num_rx_queues))
> + return -EINVAL;
is there a similar check to ensure that the driver does not increase its
number of queues with ethtool -X and subsumes user queues?
> +
> + if (adapter->user_queue_info[qpair_index].sk_handle)
> + return -EBUSY;
> + }
> +
> + /* remember the sk handle for each queue pair */
> + for (qpair_index = start_from;
> + qpair_index < start_from + qpairs_num;
> + qpair_index++) {
> + adapter->user_queue_info[qpair_index].sk_handle = sk;
> + adapter->user_queue_info[qpair_index].num_of_regions = 0;
> + }
> +
> + return 0;
> +}
> +
> +static int ixgbe_ndo_get_split_queue_pairs(struct net_device *dev,
> + unsigned int *start_from,
> + unsigned int *qpairs_num,
> + struct sock *sk)
> +{
> + struct ixgbe_adapter *adapter = netdev_priv(dev);
> + unsigned int qpair_index;
> + *qpairs_num = 0;
> +
> + for (qpair_index = adapter->num_tx_queues;
> + qpair_index < MAX_RX_QUEUES;
> + qpair_index++) {
> + if (adapter->user_queue_info[qpair_index].sk_handle == sk) {
> + if (*qpairs_num == 0)
> + *start_from = qpair_index;
> + *qpairs_num = *qpairs_num + 1;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int ixgbe_ndo_return_queue_pairs(struct net_device *dev, struct sock *sk)
> +{
> + struct ixgbe_adapter *adapter = netdev_priv(dev);
> + struct ixgbe_user_queue_info *info;
> + unsigned int qpair_index;
> +
> + for (qpair_index = adapter->num_tx_queues;
> + qpair_index < MAX_RX_QUEUES;
> + qpair_index++) {
> + info = &adapter->user_queue_info[qpair_index];
> +
> + if (info->sk_handle == sk) {
> + info->sk_handle = NULL;
> + info->num_of_regions = 0;
> + }
> + }
> +
> + return 0;
> +}
> +
> +/* Rx descriptor starts from 0x1000 and Tx descriptor starts from 0x6000
> + * both the TX and RX descriptors use 4K pages.
> + */
> +#define RX_DESC_ADDR_OFFSET 0x1000
> +#define TX_DESC_ADDR_OFFSET 0x6000
> +#define PAGE_SIZE_4K 4096
> +
> +static int
> +ixgbe_ndo_qpair_map_region(struct net_device *dev,
> + struct tpacket_dev_qpair_map_region_info *info)
> +{
> + struct ixgbe_adapter *adapter = netdev_priv(dev);
> +
> + /* no need to map systme memory to userspace for ixgbe */
> + info->tp_dev_sysm_sz = 0;
> + info->tp_num_sysm_map_regions = 0;
> +
> + info->tp_dev_bar_sz = pci_resource_len(adapter->pdev, 0);
> + info->tp_num_map_regions = 2;
> +
> + info->tp_regions[0].page_offset = RX_DESC_ADDR_OFFSET;
> + info->tp_regions[0].page_sz = PAGE_SIZE;
> + info->tp_regions[0].page_cnt = 1;
> + info->tp_regions[1].page_offset = TX_DESC_ADDR_OFFSET;
> + info->tp_regions[1].page_sz = PAGE_SIZE;
> + info->tp_regions[1].page_cnt = 1;
> +
> + return 0;
> +}
> +
> +static int ixgbe_ndo_get_device_desc_info(struct net_device *dev,
> + struct tpacket_dev_info *dev_info)
> +{
> + struct ixgbe_adapter *adapter = netdev_priv(dev);
> + int max_queues;
> + int i;
> + __u8 flds_rx = sizeof(ixgbe_legacy_rx_desc) /
> + sizeof(struct tpacket_nic_desc_fld);
> + __u8 flds_tx = sizeof(ixgbe_legacy_tx_desc) /
> + sizeof(struct tpacket_nic_desc_fld);
> +
> + max_queues = max(adapter->num_rx_queues, adapter->num_tx_queues);
> +
> + dev_info->tp_device_id = adapter->hw.device_id;
> + dev_info->tp_vendor_id = adapter->hw.vendor_id;
> + dev_info->tp_subsystem_device_id = adapter->hw.subsystem_device_id;
> + dev_info->tp_subsystem_vendor_id = adapter->hw.subsystem_vendor_id;
> + dev_info->tp_revision_id = adapter->hw.revision_id;
> + dev_info->tp_numa_node = dev_to_node(&dev->dev);
> +
> + dev_info->tp_num_total_qpairs = min(MAX_RX_QUEUES, MAX_TX_QUEUES);
> + dev_info->tp_num_inuse_qpairs = max_queues;
> +
> + dev_info->tp_num_rx_desc_fmt = 1;
> + dev_info->tp_num_tx_desc_fmt = 1;
> +
> + dev_info->tp_rx_dexpr[0].version = 1;
> + dev_info->tp_rx_dexpr[0].size = sizeof(union ixgbe_adv_rx_desc);
> + dev_info->tp_rx_dexpr[0].byte_order = BO_NATIVE;
> + dev_info->tp_rx_dexpr[0].num_of_fld = flds_rx;
> + for (i = 0; i < dev_info->tp_rx_dexpr[0].num_of_fld; i++)
> + memcpy(&dev_info->tp_rx_dexpr[0].fields[i],
> + &ixgbe_legacy_rx_desc[i],
> + sizeof(struct tpacket_nic_desc_fld));
> +
> + dev_info->tp_tx_dexpr[0].version = 1;
> + dev_info->tp_tx_dexpr[0].size = sizeof(union ixgbe_adv_tx_desc);
> + dev_info->tp_tx_dexpr[0].byte_order = BO_NATIVE;
> + dev_info->tp_tx_dexpr[0].num_of_fld = flds_tx;
> + for (i = 0; i < dev_info->tp_rx_dexpr[0].num_of_fld; i++)
> + memcpy(&dev_info->tp_tx_dexpr[0].fields[i],
> + &ixgbe_legacy_tx_desc[i],
> + sizeof(struct tpacket_nic_desc_fld));
> +
> + return 0;
> +}
> +
> +static int
> +ixgbe_ndo_qpair_page_map(struct vm_area_struct *vma, struct net_device *dev)
> +{
> + struct ixgbe_adapter *adapter = netdev_priv(dev);
> + phys_addr_t phy_addr = pci_resource_start(adapter->pdev, 0);
> + unsigned long pfn_rx = (phy_addr + RX_DESC_ADDR_OFFSET) >> PAGE_SHIFT;
> + unsigned long pfn_tx = (phy_addr + TX_DESC_ADDR_OFFSET) >> PAGE_SHIFT;
> + unsigned long dummy_page_phy;
> + pgprot_t pre_vm_page_prot;
> + unsigned long start;
> + unsigned int i;
> + int err;
> +
> + if (!dummy_page_buf) {
> + dummy_page_buf = kzalloc(PAGE_SIZE_4K, GFP_KERNEL);
> + if (!dummy_page_buf)
> + return -ENOMEM;
> +
> + for (i = 0; i < PAGE_SIZE_4K / sizeof(unsigned int); i++)
> + dummy_page_buf[i] = 0xdeadbeef;
> + }
> +
> + dummy_page_phy = virt_to_phys(dummy_page_buf);
> + pre_vm_page_prot = vma->vm_page_prot;
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> +
> + /* assume the vm_start is 4K aligned address */
> + for (start = vma->vm_start;
> + start < vma->vm_end;
> + start += PAGE_SIZE_4K) {
> + if (start == vma->vm_start + RX_DESC_ADDR_OFFSET) {
> + err = remap_pfn_range(vma, start, pfn_rx, PAGE_SIZE_4K,
> + vma->vm_page_prot);
> + if (err)
> + return -EAGAIN;
> + } else if (start == vma->vm_start + TX_DESC_ADDR_OFFSET) {
> + err = remap_pfn_range(vma, start, pfn_tx, PAGE_SIZE_4K,
> + vma->vm_page_prot);
> + if (err)
> + return -EAGAIN;
> + } else {
> + unsigned long addr = dummy_page_phy > PAGE_SHIFT;
> +
> + err = remap_pfn_range(vma, start, addr, PAGE_SIZE_4K,
> + pre_vm_page_prot);
> + if (err)
> + return -EAGAIN;
> + }
> + }
> + return 0;
> +}
> +
> +static int
> +ixgbe_ndo_val_dma_mem_region_map(struct net_device *dev,
> + struct tpacket_dma_mem_region *region,
> + struct sock *sk)
> +{
> + struct ixgbe_adapter *adapter = netdev_priv(dev);
> + unsigned int qpair_index, i;
> + struct ixgbe_user_queue_info *info;
> +
> +#ifdef CONFIG_DMA_MEMORY_PROTECTION
> + /* IOVA not equal to physical address means IOMMU takes effect */
> + if (region->phys_addr == region->iova)
> + return -EFAULT;
> +#endif
> +
> + for (qpair_index = adapter->num_tx_queues;
> + qpair_index < MAX_RX_QUEUES;
> + qpair_index++) {
> + info = &adapter->user_queue_info[qpair_index];
> + i = info->num_of_regions;
> +
> + if (info->sk_handle != sk)
> + continue;
> +
> + if (info->num_of_regions >= MAX_USER_DMA_REGIONS_PER_SOCKET)
> + return -EFAULT;
> +
> + info->regions[i].dma_region_size = region->size;
> + info->regions[i].direction = region->direction;
> + info->regions[i].dma_region_iova = region->iova;
> + info->num_of_regions++;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +ixgbe_get_dma_region_info(struct net_device *dev,
> + struct tpacket_dma_mem_region *region,
> + struct sock *sk)
> +{
> + struct ixgbe_adapter *adapter = netdev_priv(dev);
> + struct ixgbe_user_queue_info *info;
> + unsigned int qpair_index;
> +
> + for (qpair_index = adapter->num_tx_queues;
> + qpair_index < MAX_RX_QUEUES;
> + qpair_index++) {
> + int i;
> +
> + info = &adapter->user_queue_info[qpair_index];
> + if (info->sk_handle != sk)
> + continue;
> +
> + for (i = 0; i <= info->num_of_regions; i++) {
> + struct ixgbe_user_dma_region *r;
> +
> + r = &info->regions[i];
> + if ((r->dma_region_size == region->size) &&
> + (r->direction == region->direction)) {
> + region->iova = r->dma_region_iova;
> + return 0;
> + }
> + }
> + }
> +
> + return -1;
> +}
> +
> static const struct net_device_ops ixgbe_netdev_ops = {
> .ndo_open = ixgbe_open,
> .ndo_stop = ixgbe_close,
> @@ -7982,6 +8373,15 @@ static const struct net_device_ops ixgbe_netdev_ops = {
> .ndo_bridge_getlink = ixgbe_ndo_bridge_getlink,
> .ndo_dfwd_add_station = ixgbe_fwd_add,
> .ndo_dfwd_del_station = ixgbe_fwd_del,
> +
> + .ndo_split_queue_pairs = ixgbe_ndo_split_queue_pairs,
> + .ndo_get_split_queue_pairs = ixgbe_ndo_get_split_queue_pairs,
> + .ndo_return_queue_pairs = ixgbe_ndo_return_queue_pairs,
> + .ndo_get_device_desc_info = ixgbe_ndo_get_device_desc_info,
> + .ndo_direct_qpair_page_map = ixgbe_ndo_qpair_page_map,
> + .ndo_get_dma_region_info = ixgbe_get_dma_region_info,
> + .ndo_get_device_qpair_map_region_info = ixgbe_ndo_qpair_map_region,
> + .ndo_validate_dma_mem_region_map = ixgbe_ndo_val_dma_mem_region_map,
> };
>
> /**
> @@ -8203,7 +8603,9 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> hw->back = adapter;
> adapter->msg_enable = netif_msg_init(debug, DEFAULT_MSG_ENABLE);
>
> - hw->hw_addr = ioremap(pci_resource_start(pdev, 0),
> + hw->pci_hw_addr = pci_resource_start(pdev, 0);
> +
> + hw->hw_addr = ioremap(hw->pci_hw_addr,
> pci_resource_len(pdev, 0));
> adapter->io_addr = hw->hw_addr;
> if (!hw->hw_addr) {
> @@ -8875,6 +9277,7 @@ module_init(ixgbe_init_module);
> **/
> static void __exit ixgbe_exit_module(void)
> {
> + kfree(dummy_page_buf);
> #ifdef CONFIG_IXGBE_DCA
> dca_unregister_notify(&dca_notifier);
> #endif
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
> index d101b25..4034d31 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
> @@ -3180,6 +3180,7 @@ struct ixgbe_mbx_info {
>
> struct ixgbe_hw {
> u8 __iomem *hw_addr;
> + phys_addr_t pci_hw_addr;
> void *back;
> struct ixgbe_mac_info mac;
> struct ixgbe_addr_filter_info addr_ctrl;
>
> --
> 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
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