* [PATCH 03/12] NET: 3c59x: Fix section mismatch.
From: Ralf Baechle @ 2011-06-26 11:22 UTC (permalink / raw)
To: David S. Miller; +Cc: Steffen Klassert, netdev, linux-kernel, linux-mips
In-Reply-To: <17dd5038b15d7135791aadbe80464a13c80758d3.1309182742.git.ralf@linux-mips.org>
WARNING: drivers/net/3c59x.o(.data+0x40): Section mismatch in reference from the variable vortex_eisa_driver to the function .init.text:vortex_eisa_probe()
The variable vortex_eisa_driver references
the function __init vortex_eisa_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
---
drivers/net/3c59x.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 8cc2256..f33fecc 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -908,7 +908,7 @@ static struct eisa_device_id vortex_eisa_ids[] = {
};
MODULE_DEVICE_TABLE(eisa, vortex_eisa_ids);
-static int __init vortex_eisa_probe(struct device *device)
+static int __devinit vortex_eisa_probe(struct device *device)
{
void __iomem *ioaddr;
struct eisa_device *edev;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 05/12] NET: hp100: Fix section mismatches
From: Ralf Baechle @ 2011-06-26 11:24 UTC (permalink / raw)
To: David S. Miller; +Cc: Jaroslav Kysela, netdev, linux-mips
In-Reply-To: <17dd5038b15d7135791aadbe80464a13c80758d3.1309182742.git.ralf@linux-mips.org>
WARNING: drivers/net/hp100.o(.data+0x70): Section mismatch in reference from the variable hp100_eisa_driver to the function .init.text:hp100_eisa_probe()
The variable hp100_eisa_driver references
the function __init hp100_eisa_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: netdev@vger.kernel.org
Cc: linux-mips@linux-mips.org
---
drivers/net/hp100.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/hp100.c b/drivers/net/hp100.c
index c3ecb11..9cd575f 100644
--- a/drivers/net/hp100.c
+++ b/drivers/net/hp100.c
@@ -2843,7 +2843,7 @@ static void cleanup_dev(struct net_device *d)
}
#ifdef CONFIG_EISA
-static int __init hp100_eisa_probe (struct device *gendev)
+static int __devinit hp100_eisa_probe(struct device *gendev)
{
struct net_device *dev = alloc_etherdev(sizeof(struct hp100_private));
struct eisa_device *edev = to_eisa_device(gendev);
--
1.7.4.4
^ permalink raw reply related
* [PATCH 02/12] NET: 3c509: Fix section mismatch
From: Ralf Baechle @ 2011-06-26 11:21 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, linux-mips
In-Reply-To: <17dd5038b15d7135791aadbe80464a13c80758d3.1309182742.git.ralf@linux-mips.org>
WARNING: drivers/net/3c509.o(.data+0x190): Section mismatch in reference from the variable el3_eisa_driver to the function .init.text:el3_eisa_probe()
The variable el3_eisa_driver references
the function __init el3_eisa_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
---
drivers/net/3c509.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/3c509.c b/drivers/net/3c509.c
index 44b28b2..dc4bf07 100644
--- a/drivers/net/3c509.c
+++ b/drivers/net/3c509.c
@@ -671,7 +671,7 @@ static int __init el3_mca_probe(struct device *device)
#endif /* CONFIG_MCA */
#ifdef CONFIG_EISA
-static int __init el3_eisa_probe (struct device *device)
+static int __devinit el3_eisa_probe(struct device *device)
{
short i;
int ioaddr, irq, if_port;
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 3/9] myri10ge: rework parity error check and cleanup
From: Ben Hutchings @ 2011-06-27 15:27 UTC (permalink / raw)
To: Jon Mason; +Cc: davem, netdev, Andrew Gallatin
In-Reply-To: <1309187108-12715-3-git-send-email-mason@myri.com>
On Mon, 2011-06-27 at 10:05 -0500, Jon Mason wrote:
> Clean up watchdog reset code:
> - move code that checks for stuck slice to a common routine
> - unless there is a confirmed h/w fault, verify that a stuck
> slice is still stuck in the watchdog worker; if the slice is no
> longer stuck, abort the reset.
> - this removes an egregarious 2000ms pause in the watchdog worker that
[...]
Egregious & gregarious? Or maybe just egregious?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 9/9] myri10ge: Update MAINTAINERS
From: Jon Mason @ 2011-06-27 15:05 UTC (permalink / raw)
To: davem; +Cc: netdev, Andrew Gallatin
In-Reply-To: <1309187108-12715-1-git-send-email-mason@myri.com>
Update MAINTAINERS to refelect new people working on myri10ge
Signed-off-by: Jon Mason <mason@myri.com>
---
MAINTAINERS | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f0358cd..f3b5b65 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4279,8 +4279,8 @@ S: Maintained
F: drivers/usb/musb/
MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
+M: Jon Mason <mason@myri.com>
M: Andrew Gallatin <gallatin@myri.com>
-M: Brice Goglin <brice@myri.com>
L: netdev@vger.kernel.org
W: http://www.myri.com/scs/download-Myri10GE.html
S: Supported
--
1.7.5.4
^ permalink raw reply related
* [PATCH 8/9] myri10ge: update version
From: Jon Mason @ 2011-06-27 15:05 UTC (permalink / raw)
To: davem; +Cc: netdev, Andrew Gallatin
In-Reply-To: <1309187108-12715-1-git-send-email-mason@myri.com>
Update version and copyright
Signed-off-by: Jon Mason <mason@myri.com>
---
drivers/net/myri10ge/myri10ge.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 1e1681b..aae5de1 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -1,7 +1,7 @@
/*************************************************************************
* myri10ge.c: Myricom Myri-10G Ethernet driver.
*
- * Copyright (C) 2005 - 2009 Myricom, Inc.
+ * Copyright (C) 2005 - 2011 Myricom, Inc.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -79,7 +79,7 @@
#include "myri10ge_mcp.h"
#include "myri10ge_mcp_gen_header.h"
-#define MYRI10GE_VERSION_STR "1.5.2-1.459"
+#define MYRI10GE_VERSION_STR "1.5.3-1.534"
MODULE_DESCRIPTION("Myricom 10G driver (10GbE)");
MODULE_AUTHOR("Maintainer: help@myri.com");
--
1.7.5.4
^ permalink raw reply related
* [PATCH 7/9] myri10ge: misc style cleanups
From: Jon Mason @ 2011-06-27 15:05 UTC (permalink / raw)
To: davem; +Cc: netdev, Andrew Gallatin
In-Reply-To: <1309187108-12715-1-git-send-email-mason@myri.com>
Miscellaneous white space, style, and other cleanups
Signed-off-by: Jon Mason <mason@myri.com>
---
drivers/net/myri10ge/myri10ge.c | 29 ++++++++++++++---------------
1 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 851365c..1e1681b 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -1086,6 +1086,9 @@ static int myri10ge_toggle_relaxed(struct pci_dev *pdev, int on)
return 0;
err = pci_read_config_word(pdev, cap + PCI_EXP_DEVCTL, &ctl);
+ if (err)
+ return 0;
+
ret = (ctl & PCI_EXP_DEVCTL_RELAX_EN) >> 4;
if (ret != on) {
ctl &= ~PCI_EXP_DEVCTL_RELAX_EN;
@@ -1140,20 +1143,19 @@ static void myri10ge_setup_dca(struct myri10ge_priv *mgp)
mgp->ss[i].cpu = -1;
mgp->ss[i].cached_dca_tag = -1;
myri10ge_update_dca(&mgp->ss[i]);
- }
+ }
}
static void myri10ge_teardown_dca(struct myri10ge_priv *mgp)
{
struct pci_dev *pdev = mgp->pdev;
- int err;
if (!mgp->dca_enabled)
return;
mgp->dca_enabled = 0;
if (mgp->relaxed_order)
myri10ge_toggle_relaxed(pdev, 1);
- err = dca_remove_requester(&pdev->dev);
+ dca_remove_requester(&pdev->dev);
}
static int myri10ge_notify_dca_device(struct device *dev, void *data)
@@ -1314,7 +1316,7 @@ myri10ge_unmap_rx_page(struct pci_dev *pdev,
static inline int
myri10ge_rx_done(struct myri10ge_slice_state *ss, int len, __wsum csum,
- int lro_enabled)
+ bool lro_enabled)
{
struct myri10ge_priv *mgp = ss->mgp;
struct sk_buff *skb;
@@ -1474,11 +1476,9 @@ myri10ge_clean_rx_done(struct myri10ge_slice_state *ss, int budget)
{
struct myri10ge_rx_done *rx_done = &ss->rx_done;
struct myri10ge_priv *mgp = ss->mgp;
-
unsigned long rx_bytes = 0;
unsigned long rx_packets = 0;
unsigned long rx_ok;
-
int idx = rx_done->idx;
int cnt = rx_done->cnt;
int work_done = 0;
@@ -1538,9 +1538,10 @@ static inline void myri10ge_check_statblock(struct myri10ge_priv *mgp)
} else {
if (netif_msg_link(mgp))
netdev_info(mgp->dev, "link %s\n",
- link_up == MXGEFW_LINK_MYRINET ?
- "mismatch (Myrinet detected)" :
- "down");
+ (link_up ==
+ MXGEFW_LINK_MYRINET ?
+ "mismatch (Myrinet detected)"
+ : "down"));
netif_carrier_off(mgp->dev);
mgp->link_changes++;
}
@@ -1621,7 +1622,7 @@ static irqreturn_t myri10ge_intr(int irq, void *arg)
if (send_done_count != tx->pkt_done)
myri10ge_tx_done(ss, (int)send_done_count);
if (unlikely(i > myri10ge_max_irq_loops)) {
- netdev_err(mgp->dev, "irq stuck?\n");
+ netdev_warn(mgp->dev, "irq stuck?\n");
stats->valid = 0;
schedule_work(&mgp->watchdog_work);
}
@@ -1785,9 +1786,8 @@ static const char myri10ge_gstrings_slice_stats[][ETH_GSTRING_LEN] = {
"----------- slice ---------",
"tx_pkt_start", "tx_pkt_done", "tx_req", "tx_done",
"rx_small_cnt", "rx_big_cnt",
- "wake_queue", "stop_queue", "tx_linearized", "LRO aggregated",
- "LRO flushed",
- "LRO avg aggr", "LRO no_desc"
+ "wake_queue", "stop_queue", "tx_linearized",
+ "LRO aggregated", "LRO flushed", "LRO avg aggr", "LRO no_desc",
};
#define MYRI10GE_NET_STATS_LEN 21
@@ -3329,7 +3329,6 @@ abort:
/* fall back to using the unaligned firmware */
mgp->tx_boundary = 2048;
set_fw_name(mgp, myri10ge_fw_unaligned, false);
-
}
static void myri10ge_select_firmware(struct myri10ge_priv *mgp)
@@ -3715,8 +3714,8 @@ static void myri10ge_free_slices(struct myri10ge_priv *mgp)
dma_free_coherent(&pdev->dev, bytes,
ss->fw_stats, ss->fw_stats_bus);
ss->fw_stats = NULL;
- netif_napi_del(&ss->napi);
}
+ netif_napi_del(&ss->napi);
}
kfree(mgp->ss);
mgp->ss = NULL;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 6/9] myri10ge: remove unnecessary read of PCI_CAP_ID_EXP
From: Jon Mason @ 2011-06-27 15:05 UTC (permalink / raw)
To: davem; +Cc: netdev, Andrew Gallatin
In-Reply-To: <1309187108-12715-1-git-send-email-mason@myri.com>
The PCIE capability offset is saved during PCI bus walking. It will
remove an unnecessary search in the PCI configuration space if this
value is referenced instead of reacquiring it.
Signed-off-by: Jon Mason <mason@myri.com>
---
drivers/net/myri10ge/myri10ge.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 83cbf2c..851365c 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -1081,7 +1081,7 @@ static int myri10ge_toggle_relaxed(struct pci_dev *pdev, int on)
int ret, cap, err;
u16 ctl;
- cap = pci_find_capability(pdev, PCI_CAP_ID_EXP);
+ cap = pci_pcie_cap(pdev);
if (!cap)
return 0;
@@ -3191,7 +3191,7 @@ static void myri10ge_enable_ecrc(struct myri10ge_priv *mgp)
{
struct pci_dev *bridge = mgp->pdev->bus->self;
struct device *dev = &mgp->pdev->dev;
- unsigned cap;
+ int cap;
unsigned err_cap;
u16 val;
u8 ext_type;
@@ -3201,7 +3201,7 @@ static void myri10ge_enable_ecrc(struct myri10ge_priv *mgp)
return;
/* check that the bridge is a root port */
- cap = pci_find_capability(bridge, PCI_CAP_ID_EXP);
+ cap = pci_pcie_cap(bridge);
pci_read_config_word(bridge, cap + PCI_CAP_FLAGS, &val);
ext_type = (val & PCI_EXP_FLAGS_TYPE) >> 4;
if (ext_type != PCI_EXP_TYPE_ROOT_PORT) {
@@ -3219,8 +3219,7 @@ static void myri10ge_enable_ecrc(struct myri10ge_priv *mgp)
" to force ECRC\n");
return;
}
- cap =
- pci_find_capability(bridge, PCI_CAP_ID_EXP);
+ cap = pci_pcie_cap(bridge);
pci_read_config_word(bridge,
cap + PCI_CAP_FLAGS, &val);
ext_type = (val & PCI_EXP_FLAGS_TYPE) >> 4;
@@ -3341,7 +3340,7 @@ static void myri10ge_select_firmware(struct myri10ge_priv *mgp)
int link_width, exp_cap;
u16 lnk;
- exp_cap = pci_find_capability(mgp->pdev, PCI_CAP_ID_EXP);
+ exp_cap = pci_pcie_cap(mgp->pdev);
pci_read_config_word(mgp->pdev, exp_cap + PCI_EXP_LNKSTA, &lnk);
link_width = (lnk >> 4) & 0x3f;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 5/9] myri10ge: add support for set_phys_id
From: Jon Mason @ 2011-06-27 15:05 UTC (permalink / raw)
To: davem; +Cc: netdev, Andrew Gallatin
In-Reply-To: <1309187108-12715-1-git-send-email-mason@myri.com>
Add myri10ge driver support for the ethtool identify operation.
NOTE: Rather than blinking (which is the normal case), when identify is
used, the yellow LED turns solid.
Signed-off-by: Jon Mason <mason@myri.com>
---
drivers/net/myri10ge/myri10ge.c | 55 ++++++++++++++++++++++++
| 2 +
2 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 71461e5..83cbf2c 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -1911,6 +1911,60 @@ static u32 myri10ge_get_msglevel(struct net_device *netdev)
return mgp->msg_enable;
}
+/*
+ * Use a low-level command to change the LED behavior. Rather than
+ * blinking (which is the normal case), when identify is used, the
+ * yellow LED turns solid.
+ */
+static int myri10ge_led(struct myri10ge_priv *mgp, int on)
+{
+ struct mcp_gen_header *hdr;
+ struct device *dev = &mgp->pdev->dev;
+ size_t hdr_off, pattern_off, hdr_len;
+ u32 pattern = 0xfffffffe;
+
+ /* find running firmware header */
+ hdr_off = swab32(readl(mgp->sram + MCP_HEADER_PTR_OFFSET));
+ if ((hdr_off & 3) || hdr_off + sizeof(*hdr) > mgp->sram_size) {
+ dev_err(dev, "Running firmware has bad header offset (%d)\n",
+ (int)hdr_off);
+ return -EIO;
+ }
+ hdr_len = swab32(readl(mgp->sram + hdr_off +
+ offsetof(struct mcp_gen_header, header_length)));
+ pattern_off = hdr_off + offsetof(struct mcp_gen_header, led_pattern);
+ if (pattern_off >= (hdr_len + hdr_off)) {
+ dev_info(dev, "Firmware does not support LED identification\n");
+ return -EINVAL;
+ }
+ if (!on)
+ pattern = swab32(readl(mgp->sram + pattern_off + 4));
+ writel(htonl(pattern), mgp->sram + pattern_off);
+ return 0;
+}
+
+static int
+myri10ge_phys_id(struct net_device *netdev, enum ethtool_phys_id_state state)
+{
+ struct myri10ge_priv *mgp = netdev_priv(netdev);
+ int rc;
+
+ switch (state) {
+ case ETHTOOL_ID_ACTIVE:
+ rc = myri10ge_led(mgp, 1);
+ break;
+
+ case ETHTOOL_ID_INACTIVE:
+ rc = myri10ge_led(mgp, 0);
+ break;
+
+ default:
+ rc = -EINVAL;
+ }
+
+ return rc;
+}
+
static const struct ethtool_ops myri10ge_ethtool_ops = {
.get_settings = myri10ge_get_settings,
.get_drvinfo = myri10ge_get_drvinfo,
@@ -1925,6 +1979,7 @@ static const struct ethtool_ops myri10ge_ethtool_ops = {
.get_ethtool_stats = myri10ge_get_ethtool_stats,
.set_msglevel = myri10ge_set_msglevel,
.get_msglevel = myri10ge_get_msglevel,
+ .set_phys_id = myri10ge_phys_id,
};
static int myri10ge_allocate_rings(struct myri10ge_slice_state *ss)
--git a/drivers/net/myri10ge/myri10ge_mcp_gen_header.h b/drivers/net/myri10ge/myri10ge_mcp_gen_header.h
index 62a1cba..7ec4b86 100644
--- a/drivers/net/myri10ge/myri10ge_mcp_gen_header.h
+++ b/drivers/net/myri10ge/myri10ge_mcp_gen_header.h
@@ -45,6 +45,8 @@ struct mcp_gen_header {
unsigned bss_addr; /* start of bss */
unsigned features;
unsigned ee_hdr_addr;
+ unsigned led_pattern;
+ unsigned led_pattern_dflt;
/* 8 */
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH 4/9] myri10ge: allow small_bytes = 0
From: Jon Mason @ 2011-06-27 15:05 UTC (permalink / raw)
To: davem; +Cc: netdev, Andrew Gallatin
In-Reply-To: <1309187108-12715-1-git-send-email-mason@myri.com>
Allow page-based receive to work when small_bytes is set to 0.
Signed-off-by: Jon Mason <mason@myri.com>
---
drivers/net/myri10ge/myri10ge.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index f3df5eb..71461e5 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -2004,8 +2004,12 @@ static int myri10ge_allocate_rings(struct myri10ge_slice_state *ss)
ss->rx_big.page_offset = MYRI10GE_ALLOC_SIZE;
ss->rx_small.watchdog_needed = 0;
ss->rx_big.watchdog_needed = 0;
- myri10ge_alloc_rx_pages(mgp, &ss->rx_small,
- mgp->small_bytes + MXGEFW_PAD, 0);
+ if (mgp->small_bytes == 0) {
+ ss->rx_small.fill_cnt = ss->rx_small.mask + 1;
+ } else {
+ myri10ge_alloc_rx_pages(mgp, &ss->rx_small,
+ mgp->small_bytes + MXGEFW_PAD, 0);
+ }
if (ss->rx_small.fill_cnt < ss->rx_small.mask + 1) {
netdev_err(dev, "slice-%d: alloced only %d small bufs\n",
@@ -2031,6 +2035,8 @@ abort_with_rx_big_ring:
}
abort_with_rx_small_ring:
+ if (mgp->small_bytes == 0)
+ ss->rx_small.fill_cnt = ss->rx_small.cnt;
for (i = ss->rx_small.cnt; i < ss->rx_small.fill_cnt; i++) {
int idx = i & ss->rx_small.mask;
myri10ge_unmap_rx_page(mgp->pdev, &ss->rx_small.info[idx],
@@ -2081,6 +2087,8 @@ static void myri10ge_free_rings(struct myri10ge_slice_state *ss)
put_page(ss->rx_big.info[idx].page);
}
+ if (mgp->small_bytes == 0)
+ ss->rx_small.fill_cnt = ss->rx_small.cnt;
for (i = ss->rx_small.cnt; i < ss->rx_small.fill_cnt; i++) {
idx = i & ss->rx_small.mask;
if (i == ss->rx_small.fill_cnt - 1)
@@ -2418,7 +2426,7 @@ static int myri10ge_open(struct net_device *dev)
mgp->small_bytes = VLAN_ETH_FRAME_LEN;
/* Override the small buffer size? */
- if (myri10ge_small_bytes > 0)
+ if (myri10ge_small_bytes >= 0)
mgp->small_bytes = myri10ge_small_bytes;
/* Firmware needs the big buff size as a power of 2. Lie and
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/9] myri10ge: rework parity error check and cleanup
From: Jon Mason @ 2011-06-27 15:05 UTC (permalink / raw)
To: davem; +Cc: netdev, Andrew Gallatin
In-Reply-To: <1309187108-12715-1-git-send-email-mason@myri.com>
Clean up watchdog reset code:
- move code that checks for stuck slice to a common routine
- unless there is a confirmed h/w fault, verify that a stuck
slice is still stuck in the watchdog worker; if the slice is no
longer stuck, abort the reset.
- this removes an egregarious 2000ms pause in the watchdog worker that
was a diagnostic aid (to look for spurious resets) the snuck into
production code.
Signed-off-by: Jon Mason <mason@myri.com>
---
drivers/net/myri10ge/myri10ge.c | 100 +++++++++++++++++++++++---------------
1 files changed, 60 insertions(+), 40 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 0f0f83d..f3df5eb 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -193,6 +193,7 @@ struct myri10ge_slice_state {
int watchdog_tx_done;
int watchdog_tx_req;
int watchdog_rx_done;
+ int stuck;
#ifdef CONFIG_MYRI10GE_DCA
int cached_dca_tag;
int cpu;
@@ -3442,6 +3443,42 @@ static u32 myri10ge_read_reboot(struct myri10ge_priv *mgp)
return reboot;
}
+static void
+myri10ge_check_slice(struct myri10ge_slice_state *ss, int *reset_needed,
+ int *busy_slice_cnt, u32 rx_pause_cnt)
+{
+ struct myri10ge_priv *mgp = ss->mgp;
+ int slice = ss - mgp->ss;
+
+ if (ss->tx.req != ss->tx.done &&
+ ss->tx.done == ss->watchdog_tx_done &&
+ ss->watchdog_tx_req != ss->watchdog_tx_done) {
+ /* nic seems like it might be stuck.. */
+ if (rx_pause_cnt != mgp->watchdog_pause) {
+ if (net_ratelimit())
+ netdev_warn(mgp->dev, "slice %d: TX paused, "
+ "check link partner\n", slice);
+ } else {
+ netdev_warn(mgp->dev,
+ "slice %d: TX stuck %d %d %d %d %d %d\n",
+ slice, ss->tx.queue_active, ss->tx.req,
+ ss->tx.done, ss->tx.pkt_start,
+ ss->tx.pkt_done,
+ (int)ntohl(mgp->ss[slice].fw_stats->
+ send_done_count));
+ *reset_needed = 1;
+ ss->stuck = 1;
+ }
+ }
+ if (ss->watchdog_tx_done != ss->tx.done ||
+ ss->watchdog_rx_done != ss->rx_done.cnt) {
+ *busy_slice_cnt += 1;
+ }
+ ss->watchdog_tx_done = ss->tx.done;
+ ss->watchdog_tx_req = ss->tx.req;
+ ss->watchdog_rx_done = ss->rx_done.cnt;
+}
+
/*
* This watchdog is used to check whether the board has suffered
* from a parity error and needs to be recovered.
@@ -3450,10 +3487,12 @@ static void myri10ge_watchdog(struct work_struct *work)
{
struct myri10ge_priv *mgp =
container_of(work, struct myri10ge_priv, watchdog_work);
- struct myri10ge_tx_buf *tx;
- u32 reboot;
+ struct myri10ge_slice_state *ss;
+ u32 reboot, rx_pause_cnt;
int status, rebooted;
int i;
+ int reset_needed = 0;
+ int busy_slice_cnt = 0;
u16 cmd, vendor;
mgp->watchdog_resets++;
@@ -3465,8 +3504,7 @@ static void myri10ge_watchdog(struct work_struct *work)
* For now, just report it */
reboot = myri10ge_read_reboot(mgp);
netdev_err(mgp->dev, "NIC rebooted (0x%x),%s resetting\n",
- reboot,
- myri10ge_reset_recover ? "" : " not");
+ reboot, myri10ge_reset_recover ? " " : " not");
if (myri10ge_reset_recover == 0)
return;
rtnl_lock();
@@ -3498,23 +3536,24 @@ static void myri10ge_watchdog(struct work_struct *work)
return;
}
}
- /* Perhaps it is a software error. Try to reset */
-
- netdev_err(mgp->dev, "device timeout, resetting\n");
+ /* Perhaps it is a software error. See if stuck slice
+ * has recovered, reset if not */
+ rx_pause_cnt = ntohl(mgp->ss[0].fw_stats->dropped_pause);
for (i = 0; i < mgp->num_slices; i++) {
- tx = &mgp->ss[i].tx;
- netdev_err(mgp->dev, "(%d): %d %d %d %d %d %d\n",
- i, tx->queue_active, tx->req,
- tx->done, tx->pkt_start, tx->pkt_done,
- (int)ntohl(mgp->ss[i].fw_stats->
- send_done_count));
- msleep(2000);
- netdev_info(mgp->dev, "(%d): %d %d %d %d %d %d\n",
- i, tx->queue_active, tx->req,
- tx->done, tx->pkt_start, tx->pkt_done,
- (int)ntohl(mgp->ss[i].fw_stats->
- send_done_count));
+ ss = mgp->ss;
+ if (ss->stuck) {
+ myri10ge_check_slice(ss, &reset_needed,
+ &busy_slice_cnt,
+ rx_pause_cnt);
+ ss->stuck = 0;
+ }
}
+ if (!reset_needed) {
+ netdev_err(mgp->dev, "not resetting\n");
+ return;
+ }
+
+ netdev_err(mgp->dev, "device timeout, resetting\n");
}
if (!rebooted) {
@@ -3567,27 +3606,8 @@ static void myri10ge_watchdog_timer(unsigned long arg)
myri10ge_fill_thresh)
ss->rx_big.watchdog_needed = 0;
}
-
- if (ss->tx.req != ss->tx.done &&
- ss->tx.done == ss->watchdog_tx_done &&
- ss->watchdog_tx_req != ss->watchdog_tx_done) {
- /* nic seems like it might be stuck.. */
- if (rx_pause_cnt != mgp->watchdog_pause) {
- if (net_ratelimit())
- netdev_err(mgp->dev, "slice %d: TX paused, check link partner\n",
- i);
- } else {
- netdev_warn(mgp->dev, "slice %d stuck:", i);
- reset_needed = 1;
- }
- }
- if (ss->watchdog_tx_done != ss->tx.done ||
- ss->watchdog_rx_done != ss->rx_done.cnt) {
- busy_slice_cnt++;
- }
- ss->watchdog_tx_done = ss->tx.done;
- ss->watchdog_tx_req = ss->tx.req;
- ss->watchdog_rx_done = ss->rx_done.cnt;
+ myri10ge_check_slice(ss, &reset_needed, &busy_slice_cnt,
+ rx_pause_cnt);
}
/* if we've sent or received no traffic, poll the NIC to
* ensure it is still there. Otherwise, we risk not noticing
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/9] myri10ge: Mask PCI Surprise Link Down Events
From: Jon Mason @ 2011-06-27 15:05 UTC (permalink / raw)
To: davem; +Cc: netdev, Andrew Gallatin
In-Reply-To: <1309187108-12715-1-git-send-email-mason@myri.com>
A SRAM parity error can cause a surprise link down. Since We can
recover from SRAM parity errors, mask PCI surprise down events.
Signed-off-by: Jon Mason <mason@myri.com>
---
drivers/net/myri10ge/myri10ge.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index a8ae641..0f0f83d 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -3327,6 +3327,26 @@ static void myri10ge_select_firmware(struct myri10ge_priv *mgp)
mgp->fw_name);
}
+static void myri10ge_mask_surprise_down(struct pci_dev *pdev)
+{
+ struct pci_dev *bridge = pdev->bus->self;
+ int cap;
+ u32 mask;
+
+ if (bridge == NULL)
+ return;
+
+ cap = pci_find_ext_capability(bridge, PCI_EXT_CAP_ID_ERR);
+ if (cap) {
+ /* a sram parity error can cause a surprise link
+ * down; since we expect and can recover from sram
+ * parity errors, mask surprise link down events */
+ pci_read_config_dword(bridge, cap + PCI_ERR_UNCOR_MASK, &mask);
+ mask |= 0x20;
+ pci_write_config_dword(bridge, cap + PCI_ERR_UNCOR_MASK, mask);
+ }
+}
+
#ifdef CONFIG_PM
static int myri10ge_suspend(struct pci_dev *pdev, pm_message_t state)
{
@@ -3845,6 +3865,7 @@ static int myri10ge_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
goto abort_with_enabled;
}
+ myri10ge_mask_surprise_down(pdev);
pci_set_master(pdev);
dac_enabled = 1;
status = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/9] myri10ge: ensure tx queues remain stopped
From: Jon Mason @ 2011-06-27 15:05 UTC (permalink / raw)
To: davem; +Cc: netdev, Andrew Gallatin
Ensure that our tx queues remain stopped when we stop them in
myri10ge_close(). Not doing so can potentially lead to traffic being
transmitted when the interface is removed, which can lead to NULL
pointer dereferences.
Signed-off-by: Jon Mason <mason@myri.com>
---
drivers/net/myri10ge/myri10ge.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 3ed5f35..a8ae641 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -1461,7 +1461,8 @@ myri10ge_tx_done(struct myri10ge_slice_state *ss, int mcp_index)
/* start the queue if we've stopped it */
if (netif_tx_queue_stopped(dev_queue) &&
- tx->req - tx->done < (tx->mask >> 1)) {
+ tx->req - tx->done < (tx->mask >> 1) &&
+ ss->mgp->running == MYRI10GE_ETH_RUNNING) {
tx->wake_queue++;
netif_tx_wake_queue(dev_queue);
}
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] net/can: activate bit-timing calculation and netlink based drivers by default
From: Kurt Van Dijck @ 2011-06-27 15:00 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <1309160391-22486-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Mon, Jun 27, 2011 at 09:39:51AM +0200, Marc Kleine-Budde wrote:
> The two options "CAN bit-timing calculation" and
> "Platform CAN drivers with Netlink support" have a "default Y". In order to
> activate them by default, change to "default y".
>
> Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
^ permalink raw reply
* [PATCH] can: remove useless defaults in Kconfig
From: Kurt Van Dijck @ 2011-06-27 15:00 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w
There's no need for "default N' (or 'default n') as it's default.
Signed-off-by: Kurt Van Dijck <kurt.van.dijck-/BeEPy95v10@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 1d699e3..ac48574 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -4,7 +4,6 @@ menu "CAN Device Drivers"
config CAN_VCAN
tristate "Virtual Local CAN Interface (vcan)"
depends on CAN
- default N
---help---
Similar to the network loopback devices, vcan offers a
virtual local CAN interface.
@@ -15,7 +14,6 @@ config CAN_VCAN
config CAN_SLCAN
tristate "Serial / USB serial CAN Adaptors (slcan)"
depends on CAN
- default N
---help---
CAN driver for several 'low cost' CAN interfaces that are attached
via serial lines or via USB-to-serial adapters using the LAWICEL
@@ -124,7 +122,6 @@ source "drivers/net/can/softing/Kconfig"
config CAN_DEBUG_DEVICES
bool "CAN devices debugging messages"
depends on CAN
- default N
---help---
Say Y here if you want the CAN device drivers to produce a bunch of
debug messages to the system log. Select this if you are having
^ permalink raw reply related
* Re: [PATCH] gianfar v5: implement nfc
From: Sebastian.Poehn @ 2011-06-27 14:43 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <1308761280.10423.19.camel@Joe-Laptop>
Thanks for your feedback Joe!
> I'm a bit confused by this:
/*
* What we already have:
* A temporary copy of the filer table which will later replace the current one.
* In the filer table we always have one mask entry followed by a value (of action).
* Further we have the mask table which is a list of all mask in the filer table.
* To every entry we have the start and the end of the validity and a block index
* (same block indexes means dependency). We want to sort every dependent block!
*/
static void gfar_sort_mask_table(struct gfar_mask_entry *mask_table,
struct filer_table *temp_table, u32 and_index)
{
/* Pointer to compare function (_asc or _desc) */
int (*gfar_comp)(const void *, const void *);
u32 i, size = 0, start = 0, prev = 1;
u32 old_first, old_last, new_first, new_last;
gfar_comp = &gfar_comp_desc;
for (i = 0; i < and_index; i++) {
/* As long, as the block is the same (dependency) we only increase
* the size */
if (prev != mask_table[i].block) {
/* The +1 is because start is a mask and the important
* FF80 information is located in the next value element */
old_first = mask_table[start].start + 1;
/* -1 because we are already at the start of the next dependent block */
old_last = mask_table[i - 1].end;
/* Here the mask table is sorted! So the entries in the current
* block change may change their location */
sort(mask_table + start, size,
sizeof(struct gfar_mask_entry),
gfar_comp, &gfar_swap);
/* Toggle order for every block. This makes the
* thing more efficient! */
if (gfar_comp == gfar_comp_desc)
gfar_comp = &gfar_comp_asc;
else
gfar_comp = &gfar_comp_desc;
/* The same as above but the elements are others because of the sorting */
new_first = mask_table[start].start + 1;
new_last = mask_table[i - 1].end;
gfar_swap_bits(&temp_table->fe[new_first],
&temp_table->fe[old_first],
&temp_table->fe[new_last],
&temp_table->fe[old_last],
RQFCR_QUEUE | RQFCR_CLE |
RQFCR_RJE | RQFCR_AND
);
start = i;
size = 0;
}
size++;
prev = mask_table[i].block;
}
}
> Doesn't this just swap the same bits around twice?
Due to the masks are sorted numerically it is possible that a mask from any location changes its locations to ANY. Lets think of this example and the usage of the sequential swapping:
A has a header <- old_first new position after sorting: 2
B <- new_last new position after sorting: 4
C new position after sorting: 3
D has a trailer <- old_last and new_first new position after sorting: 1
First swap first:
A has a trailer
B
C
D has a header
Second swap:
A has a trailer
B has a header
C
D
And now after the sorted order is applied:
D
A has a trailer
C
B has a header
Thats not correct!
The concurrent swapper does:
A
B has a trailer
C
D has a header
And:
D has a header
A
C
B has a trailer
That's all right!
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
^ permalink raw reply
* Re: [PATCH] net/can: activate bit-timing calculation and netlink based drivers by default
From: Marc Kleine-Budde @ 2011-06-27 14:49 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <20110627135044.GF318-MxZ6Iy/zr/UdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1653 bytes --]
On 06/27/2011 03:50 PM, Kurt Van Dijck wrote:
> Is this modification then also the right thing to do?
yes - there's no need for "default N' (or 'default n') as it's default.
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index 1d699e3..ac48574 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -4,7 +4,6 @@ menu "CAN Device Drivers"
> config CAN_VCAN
> tristate "Virtual Local CAN Interface (vcan)"
> depends on CAN
> - default N
> ---help---
> Similar to the network loopback devices, vcan offers a
> virtual local CAN interface.
> @@ -15,7 +14,6 @@ config CAN_VCAN
> config CAN_SLCAN
> tristate "Serial / USB serial CAN Adaptors (slcan)"
> depends on CAN
> - default N
> ---help---
> CAN driver for several 'low cost' CAN interfaces that are attached
> via serial lines or via USB-to-serial adapters using the LAWICEL
> @@ -124,7 +122,6 @@ source "drivers/net/can/softing/Kconfig"
> config CAN_DEBUG_DEVICES
> bool "CAN devices debugging messages"
> depends on CAN
> - default N
> ---help---
> Say Y here if you want the CAN device drivers to produce a bunch of
> debug messages to the system log. Select this if you are having
If you make a patch from it...
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 191 bytes --]
_______________________________________________
Socketcan-users mailing list
Socketcan-users-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply
* Re: SKB paged fragment lifecycle on receive
From: Ian Campbell @ 2011-06-27 14:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jeremy Fitzhardinge, netdev@vger.kernel.org, xen-devel,
Rusty Russell
In-Reply-To: <1308938183.2532.8.camel@edumazet-laptop>
On Fri, 2011-06-24 at 18:56 +0100, Eric Dumazet wrote:
> Le vendredi 24 juin 2011 à 10:29 -0700, Jeremy Fitzhardinge a écrit :
> > On 06/24/2011 08:43 AM, Ian Campbell wrote:
> > > We've previously looked into solutions using the skb destructor callback
> > > but that falls over if the skb is cloned since you also need to know
> > > when the clone is destroyed. Jeremy Fitzhardinge and I subsequently
> > > looked at the possibility of a no-clone skb flag (i.e. always forcing a
> > > copy instead of a clone) but IIRC honouring it universally turned into a
> > > very twisty maze with a number of nasty corner cases etc. It also seemed
> > > that the proportion of SKBs which get cloned at least once appeared as
> > > if it could be quite high which would presumably make the performance
> > > impact unacceptable when using the flag. Another issue with using the
> > > skb destructor is that functions such as __pskb_pull_tail will eat (and
> > > free) pages from the start of the frag array such that by the time the
> > > skb destructor is called they are no longer there.
> > >
> > > AIUI Rusty Russell had previously looked into a per-page destructor in
> > > the shinfo but found that it couldn't be made to work (I don't remember
> > > why, or if I even knew at the time). Could that be an approach worth
> > > reinvestigating?
> > >
> > > I can't really think of any other solution which doesn't involve some
> > > sort of driver callback at the time a page is free()d.
> >
>
> This reminds me the packet mmap (tx path) games we play with pages.
>
> net/packet/af_packet.c : tpacket_destruct_skb(), poking
> TP_STATUS_AVAILABLE back to user to tell him he can reuse space...
This is OK because af_packet involves no kernel side protocol and hence
there can be no retransmits etc? Otherwise you would suffer from the
same sorts of issues as I described with NFS at [0]?
However it seems like this might still have a problem if your SKBs are
ever cloned. What happens in this case, e.g if a user of AF_PACKET sends
a broadcast via a device associated with a bridge[1] (where it would be
flooded)?
Wouldn't you get into the situation where the destructor of the initial
skb is called before one or more of the clones going to a different
destination were sent. So you would send TP_STATUS_AVAILABLE to
userspace before the stack was really finished with the page and run the
risk of userspace reusing the buffer, leading to incorrect bytes going
to some destinations?
It looks to me that anything which does any zero-copy type thing to the
network stack will have problems with one or both of protocol retransmit
or SKB clone. There's simply no mechanism to know when the stack is
really finished with a page.
Ian.
[0] http://marc.info/?l=linux-nfs&m=122424132729720&w=2
[1] Since dhcp clients typically use AF_PACKET and you typically put the
IP address on the bridge itself in these configurations this won't be
that unusual.
Ian.
^ permalink raw reply
* Re: [RFT PATCH v3 00/12] Cleanup and extension of netdev features
From: Michał Mirosław @ 2011-06-27 14:21 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, David S. Miller, Ben Hutchings
In-Reply-To: <4E0276A0.8010802@candelatech.com>
On Wed, Jun 22, 2011 at 04:11:28PM -0700, Ben Greear wrote:
> On 06/22/2011 09:04 AM, Michał Mirosław wrote:
> >v3 of a feature handling cleanup and extension series. For testing, you
> >might want user-space ethtool patched with:
> >
> >http://patchwork.ozlabs.org/patch/96374/
> There is a typo in one of those patches:
> CC fs/quota/netlink.o
> /home/greearb/git/net-next-2.6/net/core/dev.c: In function ‘__netdev_update_features’:
> /home/greearb/git/net-next-2.6/net/core/dev.c:5288: warning: too many arguments for format
> CC net/core/ethtool.o
> netdev_dbg(dev, "Features changed: %pNF -> pNF\n",
> &dev->features, &features);
Noted for next version.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] net/can: activate bit-timing calculation and netlink based drivers by default
From: Kurt Van Dijck @ 2011-06-27 13:50 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <1309160391-22486-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Is this modification then also the right thing to do?
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 1d699e3..ac48574 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -4,7 +4,6 @@ menu "CAN Device Drivers"
config CAN_VCAN
tristate "Virtual Local CAN Interface (vcan)"
depends on CAN
- default N
---help---
Similar to the network loopback devices, vcan offers a
virtual local CAN interface.
@@ -15,7 +14,6 @@ config CAN_VCAN
config CAN_SLCAN
tristate "Serial / USB serial CAN Adaptors (slcan)"
depends on CAN
- default N
---help---
CAN driver for several 'low cost' CAN interfaces that are attached
via serial lines or via USB-to-serial adapters using the LAWICEL
@@ -124,7 +122,6 @@ source "drivers/net/can/softing/Kconfig"
config CAN_DEBUG_DEVICES
bool "CAN devices debugging messages"
depends on CAN
- default N
---help---
Say Y here if you want the CAN device drivers to produce a bunch of
debug messages to the system log. Select this if you are having
^ permalink raw reply related
* Re: [PATCH] NET: TC35815: Only build driver on Toshiba eval boards.
From: Atsushi Nemoto @ 2011-06-27 12:57 UTC (permalink / raw)
To: ralf; +Cc: davem, netdev, linux-mips
In-Reply-To: <20110625165409.GA1760@linux-mips.org>
On Sat, 25 Jun 2011 17:54:09 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> That's the only place where the TC35815 is known to be used.
>
> Ralf
>
> drivers/net/Kconfig | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index be25e92..2b4ebfb 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -1516,7 +1516,8 @@ config CS89x0_NONISA_IRQ
>
> config TC35815
> tristate "TOSHIBA TC35815 Ethernet support"
> - depends on NET_PCI && PCI && MIPS
> + depends on NET_PCI && PCI && MACH_TXX9
> + default y
> select PHYLIB
>
> config E100
Yes, OK for me.
Acked-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
^ permalink raw reply
* Re: SKB paged fragment lifecycle on receive
From: Michael S. Tsirkin @ 2011-06-27 11:19 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, Jeremy Fitzhardinge, xen-devel,
mashirle@us.ibm.com, Rusty Russell
In-Reply-To: <1309172042.32717.199.camel@zakaz.uk.xensource.com>
On Mon, Jun 27, 2011 at 11:54:02AM +0100, Ian Campbell wrote:
> On Mon, 2011-06-27 at 11:21 +0100, Michael S. Tsirkin wrote:
> > On Mon, Jun 27, 2011 at 10:41:35AM +0100, Ian Campbell wrote:
> > > On Sun, 2011-06-26 at 11:25 +0100, Michael S. Tsirkin wrote:
> > > > On Fri, Jun 24, 2011 at 04:43:22PM +0100, Ian Campbell wrote:
> > > > > In this mode guest data pages ("foreign pages") were mapped into the
> > > > > backend domain (using Xen grant-table functionality) and placed into the
> > > > > skb's paged frag list (skb_shinfo(skb)->frags, I hope I am using the
> > > > > right term). Once the page is finished with netback unmaps it in order
> > > > > to return it to the guest (we really want to avoid returning such pages
> > > > > to the general allocation pool!).
> > > >
> > > > Are the pages writeable by the source guest while netback processes
> > > > them? If yes, firewalling becomes unreliable as the packet can be
> > > > modified after it's checked, right?
> > >
> > > We only map the paged frags, the linear area is always copied (enough to
> > > cover maximally sized TCP/IP, including options), for this reason.
> >
> > Hmm. That'll cover the most common scenarios
> > (such as port filtering) but not deep inspection.
>
> Right.
>
> > Not sure how important that is.
> >
> > > > Also, for guest to guest communication, do you wait for
> > > > the destination to stop looking at the packet in order
> > > > to return it to the source? If yes, can source guest
> > > > networking be disrupted by a slow destination?
> > >
> > > There is a timeout which ultimately does a copy into dom0 memory and
> > > frees up the domain grant for return to the sending guest.
> >
> > Interesting. How long's the timeout?
>
> 1 second IIRC.
I think that's unlikely to prevent networking disruption, only
complete loss of networking.
> > > I suppose one difference with this is that it deals with data from
> > > "dom0" userspace buffers rather than (what looks like) kernel memory,
> > > although I don't know if that matters yet. Also it hangs off of struct
> > > sock which netback doesn't have. Anyway I'll check it out.
> >
> > I think the most important detail is the copy on clone approach.
> > We can make it controlled by an skb flag if necessary.
> >
> > > > > but IIRC honouring it universally turned into a
> > > > > very twisty maze with a number of nasty corner cases etc.
> > > >
> > > > Any examples? Are they covered by the patchset above?
> > >
> > > It was quite a while ago so I don't remember many of the specifics.
> > > Jeremy might remember better but for example any broadcast traffic
> > > hitting a bridge (a very interesting case for Xen), seems like a likely
> > > case? pcap was another one which I do remember, but that's obviously
> > > less critical.
> >
> > Last I looked I thought these clone the skb, so if a copy happens on
> > clone things will work correctly?
>
> Things should be correct, but won't necessarily perform well.
>
> In particular if the clones (which become copies with this flag) are
> frequent enough then there is no advantage to doing mapping instead of
> just copying upfront, in fact it probably hurts overall.
True. Further, the CPU used up by the copy isn't accounted for in the
appropriate cgroup.
> Taking a quick look at the callers of skb_clone I also see skb_segment
> in there. Since Xen tries to pass around large skbs (using LRO/GSO over
> the PV interface) in order to amortise costs it is quite common for
> things to undergo GSO as they hit the physical device. I'm not sure if
> these commonly hit the specific code path which causes a clone though.
Probably not, I think this patchset was tested with GSO as well.
> > > I presume with the TX zero-copy support the "copying due to attempted
> > > clone" rate is low?
> >
> > Yes. My understanding is that this version targets a non-bridged setup
> > (guest connected to a macvlan on a physical dev) as the first step.
>
> OK.
>
> > > > > FWIW I proposed a session on the subject for LPC this year.
> > > > We also plan to discuss this on kvm forum 2011
> > > > (colocated with linuxcon 2011).
> > > > http://www.linux-kvm.org/page/KVM_Forum_2011
> > >
> > > I had already considered coming to LinuxCon for other reasons but
> > > unfortunately I have family commitments around then :-(
>
> > And I'm not coming to LPC this year :(
>
> That's a shame.
>
> Ian.
>
^ permalink raw reply
* [PATCH v2] NET: AX88796: Tighten up Kconfig dependencies
From: Ralf Baechle @ 2011-06-27 11:13 UTC (permalink / raw)
To: David S. Miller, Eric Miao, Russell King, Ben Dooks, Pa
Cc: linux-arm-kernel, linux-kernel, linux-sh, netdev, linux-mips
In def47c5095d53814512bb0c62ec02dfdec769db1 [[netdrvr] Fix dependencies for
ax88796 ne2k clone driver] the AX88796 driver got restricted to just be
build for ARM and MIPS on the sole merrit that it was written for some ARM
sytems and the driver had the misfortune to just build on MIPS, so MIPS was
throw into the dependency for a good measure. Later
8687991a734a67f1638782c968f46fff0f94bb1f [ax88796: add superh to kconfig
dependencies] added SH but only one in-tree SH system actually has an
AX88796.
Tighten up dependencies by using an auxilliary config sysmbol
HAS_NET_AX88796 which is selected only by the platforms that actually
have or may have an AX88796. This also means the driver won't be built
anymore for any MIPS platform.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
---
v2: fixed Sergei's complaints about the log message
arch/arm/mach-pxa/Kconfig | 2 ++
arch/arm/mach-s3c2410/Kconfig | 1 +
arch/arm/mach-s3c2440/Kconfig | 1 +
arch/sh/boards/Kconfig | 1 +
drivers/net/Kconfig | 5 ++++-
5 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index cd19309..37ce06f 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -247,11 +247,13 @@ config MACH_COLIBRI300
select PXA3xx
select CPU_PXA300
select CPU_PXA310
+ select HAS_NET_AX88796
config MACH_COLIBRI320
bool "Toradex Colibri PXA320"
select PXA3xx
select CPU_PXA320
+ select HAS_NET_AX88796
config MACH_COLIBRI_EVALBOARD
bool "Toradex Colibri Evaluation Carrier Board support"
diff --git a/arch/arm/mach-s3c2410/Kconfig b/arch/arm/mach-s3c2410/Kconfig
index 7245a55..d665f92 100644
--- a/arch/arm/mach-s3c2410/Kconfig
+++ b/arch/arm/mach-s3c2410/Kconfig
@@ -122,6 +122,7 @@ config ARCH_BAST
select S3C_DEV_HWMON
select S3C_DEV_USB_HOST
select S3C_DEV_NAND
+ select HAS_NET_AX88796
help
Say Y here if you are using the Simtec Electronics EB2410ITX
development board (also known as BAST)
diff --git a/arch/arm/mach-s3c2440/Kconfig b/arch/arm/mach-s3c2440/Kconfig
index 50825a3..7ddbd22 100644
--- a/arch/arm/mach-s3c2440/Kconfig
+++ b/arch/arm/mach-s3c2440/Kconfig
@@ -86,6 +86,7 @@ config MACH_ANUBIS
select S3C24XX_GPIO_EXTRA64
select S3C2440_XTAL_12000000
select S3C_DEV_USB_HOST
+ select HAS_NET_AX88796
help
Say Y here if you are using the Simtec Electronics ANUBIS
development system
diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig
index d893411..f23f332 100644
--- a/arch/sh/boards/Kconfig
+++ b/arch/sh/boards/Kconfig
@@ -162,6 +162,7 @@ config SH_HIGHLANDER
depends on CPU_SUBTYPE_SH7780 || CPU_SUBTYPE_SH7785
select SYS_SUPPORTS_PCI
select IO_TRAPPED if MMU
+ select HAS_NET_AX88796
config SH_SH7757LCR
bool "SH7757LCR"
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index be25e92..85d18c4 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -237,13 +237,16 @@ source "drivers/net/arm/Kconfig"
config AX88796
tristate "ASIX AX88796 NE2000 clone support"
- depends on ARM || MIPS || SUPERH
+ depends on HAS_NET_AX88796
select PHYLIB
select MDIO_BITBANG
help
AX88796 driver, using platform bus to provide
chip detection and resources
+config HAS_NET_AX88796
+ bool
+
config AX88796_93CX6
bool "ASIX AX88796 external 93CX6 eeprom support"
depends on AX88796
^ permalink raw reply related
* Re: SKB paged fragment lifecycle on receive
From: Ian Campbell @ 2011-06-27 10:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jeremy Fitzhardinge, xen-devel, netdev@vger.kernel.org,
mashirle@us.ibm.com, Russell, Rusty
In-Reply-To: <20110627102129.GB12978@redhat.com>
On Mon, 2011-06-27 at 11:21 +0100, Michael S. Tsirkin wrote:
> On Mon, Jun 27, 2011 at 10:41:35AM +0100, Ian Campbell wrote:
> > On Sun, 2011-06-26 at 11:25 +0100, Michael S. Tsirkin wrote:
> > > On Fri, Jun 24, 2011 at 04:43:22PM +0100, Ian Campbell wrote:
> > > > In this mode guest data pages ("foreign pages") were mapped into the
> > > > backend domain (using Xen grant-table functionality) and placed into the
> > > > skb's paged frag list (skb_shinfo(skb)->frags, I hope I am using the
> > > > right term). Once the page is finished with netback unmaps it in order
> > > > to return it to the guest (we really want to avoid returning such pages
> > > > to the general allocation pool!).
> > >
> > > Are the pages writeable by the source guest while netback processes
> > > them? If yes, firewalling becomes unreliable as the packet can be
> > > modified after it's checked, right?
> >
> > We only map the paged frags, the linear area is always copied (enough to
> > cover maximally sized TCP/IP, including options), for this reason.
>
> Hmm. That'll cover the most common scenarios
> (such as port filtering) but not deep inspection.
Right.
> Not sure how important that is.
>
> > > Also, for guest to guest communication, do you wait for
> > > the destination to stop looking at the packet in order
> > > to return it to the source? If yes, can source guest
> > > networking be disrupted by a slow destination?
> >
> > There is a timeout which ultimately does a copy into dom0 memory and
> > frees up the domain grant for return to the sending guest.
>
> Interesting. How long's the timeout?
1 second IIRC.
> > I suppose one difference with this is that it deals with data from
> > "dom0" userspace buffers rather than (what looks like) kernel memory,
> > although I don't know if that matters yet. Also it hangs off of struct
> > sock which netback doesn't have. Anyway I'll check it out.
>
> I think the most important detail is the copy on clone approach.
> We can make it controlled by an skb flag if necessary.
>
> > > > but IIRC honouring it universally turned into a
> > > > very twisty maze with a number of nasty corner cases etc.
> > >
> > > Any examples? Are they covered by the patchset above?
> >
> > It was quite a while ago so I don't remember many of the specifics.
> > Jeremy might remember better but for example any broadcast traffic
> > hitting a bridge (a very interesting case for Xen), seems like a likely
> > case? pcap was another one which I do remember, but that's obviously
> > less critical.
>
> Last I looked I thought these clone the skb, so if a copy happens on
> clone things will work correctly?
Things should be correct, but won't necessarily perform well.
In particular if the clones (which become copies with this flag) are
frequent enough then there is no advantage to doing mapping instead of
just copying upfront, in fact it probably hurts overall.
Taking a quick look at the callers of skb_clone I also see skb_segment
in there. Since Xen tries to pass around large skbs (using LRO/GSO over
the PV interface) in order to amortise costs it is quite common for
things to undergo GSO as they hit the physical device. I'm not sure if
these commonly hit the specific code path which causes a clone though.
> > I presume with the TX zero-copy support the "copying due to attempted
> > clone" rate is low?
>
> Yes. My understanding is that this version targets a non-bridged setup
> (guest connected to a macvlan on a physical dev) as the first step.
OK.
> > > > FWIW I proposed a session on the subject for LPC this year.
> > > We also plan to discuss this on kvm forum 2011
> > > (colocated with linuxcon 2011).
> > > http://www.linux-kvm.org/page/KVM_Forum_2011
> >
> > I had already considered coming to LinuxCon for other reasons but
> > unfortunately I have family commitments around then :-(
> And I'm not coming to LPC this year :(
That's a shame.
Ian.
^ permalink raw reply
* Re: SKB paged fragment lifecycle on receive
From: Michael S. Tsirkin @ 2011-06-27 10:21 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, Jeremy Fitzhardinge, xen-devel,
mashirle@us.ibm.com, Rusty Russell
In-Reply-To: <1309167695.32717.181.camel@zakaz.uk.xensource.com>
On Mon, Jun 27, 2011 at 10:41:35AM +0100, Ian Campbell wrote:
> On Sun, 2011-06-26 at 11:25 +0100, Michael S. Tsirkin wrote:
> > On Fri, Jun 24, 2011 at 04:43:22PM +0100, Ian Campbell wrote:
> > > In this mode guest data pages ("foreign pages") were mapped into the
> > > backend domain (using Xen grant-table functionality) and placed into the
> > > skb's paged frag list (skb_shinfo(skb)->frags, I hope I am using the
> > > right term). Once the page is finished with netback unmaps it in order
> > > to return it to the guest (we really want to avoid returning such pages
> > > to the general allocation pool!).
> >
> > Are the pages writeable by the source guest while netback processes
> > them? If yes, firewalling becomes unreliable as the packet can be
> > modified after it's checked, right?
>
> We only map the paged frags, the linear area is always copied (enough to
> cover maximally sized TCP/IP, including options), for this reason.
Hmm. That'll cover the most common scenarios
(such as port filtering) but not deep inspection.
Not sure how important that is.
> > Also, for guest to guest communication, do you wait for
> > the destination to stop looking at the packet in order
> > to return it to the source? If yes, can source guest
> > networking be disrupted by a slow destination?
>
> There is a timeout which ultimately does a copy into dom0 memory and
> frees up the domain grant for return to the sending guest.
Interesting. How long's the timeout?
> > > Jeremy Fitzhardinge and I subsequently
> > > looked at the possibility of a no-clone skb flag (i.e. always forcing a
> > > copy instead of a clone)
> >
> > I think this is the approach that the patchset
> > 'macvtap/vhost TX zero-copy support' takes.
>
> That's TX from the guests PoV, the same as I am looking at here,
> correct?
Right.
> I should definitely check this work out, thanks for the pointer. Is V7
> (http://marc.info/?l=linux-kernel&m=130661128431312&w=2) the most recent
> posting?
I think so.
> I suppose one difference with this is that it deals with data from
> "dom0" userspace buffers rather than (what looks like) kernel memory,
> although I don't know if that matters yet. Also it hangs off of struct
> sock which netback doesn't have. Anyway I'll check it out.
I think the most important detail is the copy on clone approach.
We can make it controlled by an skb flag if necessary.
> > > but IIRC honouring it universally turned into a
> > > very twisty maze with a number of nasty corner cases etc.
> >
> > Any examples? Are they covered by the patchset above?
>
> It was quite a while ago so I don't remember many of the specifics.
> Jeremy might remember better but for example any broadcast traffic
> hitting a bridge (a very interesting case for Xen), seems like a likely
> case? pcap was another one which I do remember, but that's obviously
> less critical.
Last I looked I thought these clone the skb, so if a copy happens on
clone things will work correctly?
> I presume with the TX zero-copy support the "copying due to attempted
> clone" rate is low?
Yes. My understanding is that this version targets a non-bridged setup
(guest connected to a macvlan on a physical dev) as the first step.
> > > FWIW I proposed a session on the subject for LPC this year.
> > We also plan to discuss this on kvm forum 2011
> > (colocated with linuxcon 2011).
> > http://www.linux-kvm.org/page/KVM_Forum_2011
>
> I had already considered coming to LinuxCon for other reasons but
> unfortunately I have family commitments around then :-(
>
> Ian.
And I'm not coming to LPC this year :(
--
MST
^ 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