* 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] 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: [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: 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
* [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: [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
* 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] 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: 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
* [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
* [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 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 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 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
* 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 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
* [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
* 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
* 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] 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
* [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
* [patch-net-next 3/3] net: ethernet: cpsw: don't requests IRQs we don't use
From: Felipe Balbi @ 2015-01-13 19:44 UTC (permalink / raw)
To: davem
Cc: Tony Lindgren, Linux OMAP Mailing List, mugunthanvnm, netdev,
Felipe Balbi
In-Reply-To: <1421178288-7393-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 c9081bdbbcbc..fd0acd9b41ae 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-net-next 2/3] net: ethernet: cpsw: split out IRQ handler
From: Felipe Balbi @ 2015-01-13 19:44 UTC (permalink / raw)
To: davem
Cc: Tony Lindgren, Linux OMAP Mailing List, mugunthanvnm, netdev,
Felipe Balbi
In-Reply-To: <1421178288-7393-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 6e04128b9543..c9081bdbbcbc 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
* Re: [PATCH 3/6] net: davinci_emac: Free clock after checking the frequency
From: Tom Lendacky @ 2015-01-13 19:48 UTC (permalink / raw)
To: Tony Lindgren, David Miller
Cc: netdev, linux-omap, Brian Hutchinson, Felipe Balbi
In-Reply-To: <1421177368-19756-4-git-send-email-tony@atomide.com>
On 01/13/2015 01:29 PM, Tony Lindgren wrote:
> 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);
The devm_clk_get call is used to get the clock so either a devm_clk_put
needs to be used here or just let the devm_ call do its thing and
automatically do the put when the module is unloaded.
Thanks,
Tom
>
> /* TODO: Probe PHY here if possible */
>
>
^ permalink raw reply
* Re: [PATCH 1/6] net: davinci_emac: Fix hangs with interrupts
From: Tony Lindgren @ 2015-01-13 19:45 UTC (permalink / raw)
To: Felipe Balbi; +Cc: David Miller, netdev, linux-omap, Brian Hutchinson
In-Reply-To: <20150113193634.GQ16533@saruman>
* Felipe Balbi <balbi@ti.com> [150113 11:40]:
> On Tue, Jan 13, 2015 at 11:29:23AM -0800, Tony Lindgren wrote:
> >
> > 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.
>
> 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.
Yeah I agree that's totally the way to go for the future. I've tried to
expose that issue here with nuttcp but so far no luck.
Regards,
Tony
^ 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