* [PATCH v3 0/8] net: can: Use syscon regmap for TI specific RAMINIT register
From: Roger Quadros @ 2014-11-04 10:20 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
Hi,
Some hardware (TI am43xx) has a buggy RAMINIT DONE mechanism and it might
not always set the DONE bit. This will result in a lockup in c_can_hw_raminit_wait_ti(),
so patch 1 adds a timeout mechanism there.
There is a non compliancy within TI platforms with respect to the
layout of the RAMINIT register. The patches 2 and 3 address this issue
and make a flexible but standard way of defining the RAMINIT hardware register
layout in the device tree. The RAMINIT register is accessed using the syscon
regmap framework.
Patches available at
git@github.com:rogerq/linux.git [for-v3.19/can]
Patches are tested on am335x-evm, am437x-gp-evm and dra7-evm.
Board support files to allow CAN testing on these boards are available at
git@github.com:rogerq/linux.git [for-v3.19/omap-dts-dcan]
Changelog:
v3:
- allow driver data to be more than just CAN_ID
- RAMINIT register data moved to driver data instead of device tree file.
v2:
- added "ti" vendor prefix to TI specific raminit properties.
- split DTS changes into a separate series
cheers,
-roger
---
Roger Quadros (8):
net: can: c_can: Add timeout to c_can_hw_raminit_ti()
net: can: c_can: Introduce c_can_driver_data structure
net: can: c_can: Add RAMINIT register information to driver data
net: can: c_can: Add syscon/regmap RAMINIT mechanism
net: can: c_can: Add support for START pulse in RAMINIT sequence
net: can: c_can: Disable pins when CAN interface is down
net: can: c_can: Add support for TI DRA7 DCAN
net: can: c_can: Add support for TI am3352 DCAN
.../devicetree/bindings/net/can/c_can.txt | 5 +
drivers/net/can/c_can/c_can.c | 20 ++
drivers/net/can/c_can/c_can.h | 20 +-
drivers/net/can/c_can/c_can_platform.c | 207 +++++++++++++++------
4 files changed, 191 insertions(+), 61 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH v3 1/8] net: can: c_can: Add timeout to c_can_hw_raminit_ti()
From: Roger Quadros @ 2014-11-04 10:20 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415096461-25576-1-git-send-email-rogerq@ti.com>
TI's RAMINIT DONE mechanism is buggy on AM43xx SoC and may not always
be set after the START bit is set. Although it seems to work fine even
in that case. So add a timeout mechanism to c_can_hw_raminit_wait_ti().
Don't bail out in that failure case but just print an error message.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/net/can/c_can/c_can_platform.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index fb279d6..b144e71 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -75,10 +75,18 @@ static void c_can_plat_write_reg_aligned_to_32bit(const struct c_can_priv *priv,
static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
u32 val)
{
+ int timeout = 0;
/* We look only at the bits of our instance. */
val &= mask;
- while ((readl(priv->raminit_ctrlreg) & mask) != val)
+ while ((readl(priv->raminit_ctrlreg) & mask) != val) {
udelay(1);
+ timeout++;
+
+ if (timeout == 1000) {
+ dev_err(&priv->dev->dev, "%s: time out\n", __func__);
+ break;
+ }
+ }
}
static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 2/8] net: can: c_can: Introduce c_can_driver_data structure
From: Roger Quadros @ 2014-11-04 10:20 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415096461-25576-1-git-send-email-rogerq@ti.com>
We want to have more data than just can_dev_id to be present
in the driver data e.g. TI platforms need RAMINIT register
description. Introduce the c_can_driver_data structure and move
the can_dev_id into it.
Tidy up the way it is used on probe().
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/net/can/c_can/c_can.h | 4 +++
drivers/net/can/c_can/c_can_platform.c | 52 +++++++++++++++++++---------------
2 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 99ad1aa..26c975d 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -169,6 +169,10 @@ enum c_can_dev_id {
BOSCH_D_CAN,
};
+struct c_can_driver_data {
+ enum c_can_dev_id id;
+};
+
/* c_can private data structure */
struct c_can_priv {
struct can_priv can; /* must be the first member */
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index b144e71..1546c2b 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -167,26 +167,34 @@ static void c_can_hw_raminit(const struct c_can_priv *priv, bool enable)
}
}
+static struct c_can_driver_data c_can_drvdata = {
+ .id = BOSCH_C_CAN,
+};
+
+static struct c_can_driver_data d_can_drvdata = {
+ .id = BOSCH_D_CAN,
+};
+
static struct platform_device_id c_can_id_table[] = {
- [BOSCH_C_CAN_PLATFORM] = {
+ {
.name = KBUILD_MODNAME,
- .driver_data = BOSCH_C_CAN,
+ .driver_data = (kernel_ulong_t)&c_can_drvdata,
},
- [BOSCH_C_CAN] = {
+ {
.name = "c_can",
- .driver_data = BOSCH_C_CAN,
+ .driver_data = (kernel_ulong_t)&c_can_drvdata,
},
- [BOSCH_D_CAN] = {
+ {
.name = "d_can",
- .driver_data = BOSCH_D_CAN,
- }, {
- }
+ .driver_data = (kernel_ulong_t)&d_can_drvdata,
+ },
+ { /* sentinel */ },
};
MODULE_DEVICE_TABLE(platform, c_can_id_table);
static const struct of_device_id c_can_of_table[] = {
- { .compatible = "bosch,c_can", .data = &c_can_id_table[BOSCH_C_CAN] },
- { .compatible = "bosch,d_can", .data = &c_can_id_table[BOSCH_D_CAN] },
+ { .compatible = "bosch,c_can", .data = &c_can_drvdata },
+ { .compatible = "bosch,d_can", .data = &d_can_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
@@ -198,21 +206,19 @@ static int c_can_plat_probe(struct platform_device *pdev)
struct net_device *dev;
struct c_can_priv *priv;
const struct of_device_id *match;
- const struct platform_device_id *id;
struct resource *mem, *res;
int irq;
struct clk *clk;
-
- if (pdev->dev.of_node) {
- match = of_match_device(c_can_of_table, &pdev->dev);
- if (!match) {
- dev_err(&pdev->dev, "Failed to find matching dt id\n");
- ret = -EINVAL;
- goto exit;
- }
- id = match->data;
+ const struct c_can_driver_data *drvdata;
+
+ match = of_match_device(c_can_of_table, &pdev->dev);
+ if (match) {
+ drvdata = match->data;
+ } else if (pdev->id_entry->driver_data) {
+ drvdata = (struct c_can_driver_data *)
+ pdev->id_entry->driver_data;
} else {
- id = platform_get_device_id(pdev);
+ return -ENODEV;
}
/* get the appropriate clk */
@@ -244,7 +250,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
}
priv = netdev_priv(dev);
- switch (id->driver_data) {
+ switch (drvdata->id) {
case BOSCH_C_CAN:
priv->regs = reg_map_c_can;
switch (mem->flags & IORESOURCE_MEM_TYPE_MASK) {
@@ -303,7 +309,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
priv->device = &pdev->dev;
priv->can.clock.freq = clk_get_rate(clk);
priv->priv = clk;
- priv->type = id->driver_data;
+ priv->type = drvdata->id;
platform_set_drvdata(pdev, dev);
SET_NETDEV_DEV(dev, &pdev->dev);
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 4/8] net: can: c_can: Add syscon/regmap RAMINIT mechanism
From: Roger Quadros @ 2014-11-04 10:20 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415096461-25576-1-git-send-email-rogerq@ti.com>
Some TI SoCs like DRA7 have a RAMINIT register specification
different from the other AMxx SoCs and as expected by the
existing driver.
To add more insanity, this register is shared with other
IPs like DSS, PCIe and PWM.
Provides a more generic mechanism to specify the RAMINIT
register location and START/DONE bit position and use the
syscon/regmap framework to access the register.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
.../devicetree/bindings/net/can/c_can.txt | 3 +
drivers/net/can/c_can/c_can.h | 9 ++-
drivers/net/can/c_can/c_can_platform.c | 93 +++++++++++++---------
3 files changed, 65 insertions(+), 40 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt
index 8f1ae81..917ac0e 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -12,6 +12,9 @@ Required properties:
Optional properties:
- ti,hwmods : Must be "d_can<n>" or "c_can<n>", n being the
instance number
+- syscon-raminit : Handle to system control region that contains the
+ RAMINIT register and register offset to the RAMINIT
+ register.
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index c3b2108..b5067bd 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -178,6 +178,12 @@ struct c_can_driver_data {
bool raminit_pulse; /* If set, sets and clears START bit (pulse) */
};
+/* Out of band RAMINIT register access via syscon regmap */
+struct c_can_raminit {
+ struct regmap *syscon; /* for raminit ctrl. reg. access */
+ unsigned int reg; /* register index within syscon */
+};
+
/* c_can private data structure */
struct c_can_priv {
struct can_priv can; /* must be the first member */
@@ -195,8 +201,7 @@ struct c_can_priv {
const u16 *regs;
void *priv; /* for board-specific data */
enum c_can_dev_id type;
- u32 __iomem *raminit_ctrlreg;
- int instance;
+ struct c_can_raminit raminit_sys; /* RAMINIT via syscon regmap */
void (*raminit) (const struct c_can_priv *priv, bool enable);
u32 comm_rcv_high;
u32 rxmasked;
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index 11946e8..d0ce439 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,14 +32,13 @@
#include <linux/clk.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
#include <linux/can/dev.h>
#include "c_can.h"
-#define CAN_RAMINIT_START_MASK(i) (0x001 << (i))
-#define CAN_RAMINIT_DONE_MASK(i) (0x100 << (i))
-#define CAN_RAMINIT_ALL_MASK(i) (0x101 << (i))
#define DCAN_RAM_INIT_BIT (1 << 3)
static DEFINE_SPINLOCK(raminit_lock);
/*
@@ -72,47 +71,61 @@ static void c_can_plat_write_reg_aligned_to_32bit(const struct c_can_priv *priv,
writew(val, priv->base + 2 * priv->regs[index]);
}
-static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
- u32 val)
+static void c_can_hw_raminit_wait_syscon(const struct c_can_priv *priv,
+ u32 mask, u32 val)
{
int timeout = 0;
+ const struct c_can_raminit *raminit = &priv->raminit_sys;
+ u32 ctrl;
+
/* We look only at the bits of our instance. */
val &= mask;
- while ((readl(priv->raminit_ctrlreg) & mask) != val) {
+ do {
udelay(1);
timeout++;
+ regmap_read(raminit->syscon, raminit->reg, &ctrl);
if (timeout == 1000) {
dev_err(&priv->dev->dev, "%s: time out\n", __func__);
break;
}
- }
+ } while ((ctrl & mask) != val);
}
-static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
+static void c_can_hw_raminit_syscon(const struct c_can_priv *priv, bool enable)
{
- u32 mask = CAN_RAMINIT_ALL_MASK(priv->instance);
+ u32 mask;
u32 ctrl;
+ const struct c_can_raminit *raminit = &priv->raminit_sys;
+ u8 start_bit, done_bit;
+
+ start_bit = priv->drvdata->raminit_start_bit;
+ done_bit = priv->drvdata->raminit_done_bit;
spin_lock(&raminit_lock);
- ctrl = readl(priv->raminit_ctrlreg);
+ mask = 1 << start_bit | 1 << done_bit;
+ regmap_read(raminit->syscon, raminit->reg, &ctrl);
+
/* We clear the done and start bit first. The start bit is
* looking at the 0 -> transition, but is not self clearing;
* And we clear the init done bit as well.
+ * NOTE: DONE must be written with 1 to clear it.
*/
- ctrl &= ~CAN_RAMINIT_START_MASK(priv->instance);
- ctrl |= CAN_RAMINIT_DONE_MASK(priv->instance);
- writel(ctrl, priv->raminit_ctrlreg);
- ctrl &= ~CAN_RAMINIT_DONE_MASK(priv->instance);
- c_can_hw_raminit_wait_ti(priv, mask, ctrl);
+ ctrl &= ~(1 << start_bit);
+ ctrl |= 1 << done_bit;
+ regmap_write(raminit->syscon, raminit->reg, ctrl);
+
+ ctrl &= ~(1 << done_bit);
+ c_can_hw_raminit_wait_syscon(priv, mask, ctrl);
if (enable) {
/* Set start bit and wait for the done bit. */
- ctrl |= CAN_RAMINIT_START_MASK(priv->instance);
- writel(ctrl, priv->raminit_ctrlreg);
- ctrl |= CAN_RAMINIT_DONE_MASK(priv->instance);
- c_can_hw_raminit_wait_ti(priv, mask, ctrl);
+ ctrl |= 1 << start_bit;
+ regmap_write(raminit->syscon, raminit->reg, ctrl);
+
+ ctrl |= 1 << done_bit;
+ c_can_hw_raminit_wait_syscon(priv, mask, ctrl);
}
spin_unlock(&raminit_lock);
}
@@ -206,10 +219,11 @@ static int c_can_plat_probe(struct platform_device *pdev)
struct net_device *dev;
struct c_can_priv *priv;
const struct of_device_id *match;
- struct resource *mem, *res;
+ struct resource *mem;
int irq;
struct clk *clk;
const struct c_can_driver_data *drvdata;
+ struct device_node *np = pdev->dev.of_node;
match = of_match_device(c_can_of_table, &pdev->dev);
if (match) {
@@ -279,27 +293,30 @@ static int c_can_plat_probe(struct platform_device *pdev)
priv->read_reg32 = d_can_plat_read_reg32;
priv->write_reg32 = d_can_plat_write_reg32;
- if (pdev->dev.of_node)
- priv->instance = of_alias_get_id(pdev->dev.of_node, "d_can");
- else
- priv->instance = pdev->id;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- /* Not all D_CAN modules have a separate register for the D_CAN
- * RAM initialization. Use default RAM init bit in D_CAN module
- * if not specified in DT.
+ /* Check if we need custom RAMINIT via syscon. Mostly for TI
+ * platforms. Only supported with DT boot.
*/
- if (!res) {
+ if (np && of_property_read_bool(np, "syscon-raminit")) {
+ ret = -EINVAL;
+ priv->raminit_sys.syscon = syscon_regmap_lookup_by_phandle(np,
+ "syscon-raminit");
+ if (IS_ERR(priv->raminit_sys.syscon)) {
+ dev_err(&pdev->dev,
+ "couldn't get syscon regmap for RAMINIT reg.\n");
+ goto exit_free_device;
+ }
+
+ if (of_property_read_u32_index(np, "syscon-raminit", 1,
+ &priv->raminit_sys.reg)) {
+ dev_err(&pdev->dev,
+ "couldn't get the RAMINIT reg. offset!\n");
+ goto exit_free_device;
+ }
+
+ priv->raminit = c_can_hw_raminit_syscon;
+ } else {
priv->raminit = c_can_hw_raminit;
- break;
}
-
- priv->raminit_ctrlreg = devm_ioremap(&pdev->dev, res->start,
- resource_size(res));
- if (!priv->raminit_ctrlreg || priv->instance < 0)
- dev_info(&pdev->dev, "control memory is not used for raminit\n");
- else
- priv->raminit = c_can_hw_raminit_ti;
break;
default:
ret = -EINVAL;
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 6/8] net: can: c_can: Disable pins when CAN interface is down
From: Roger Quadros @ 2014-11-04 10:20 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415096461-25576-1-git-send-email-rogerq@ti.com>
DRA7 CAN IP suffers from a problem which causes it to be prevented
from fully turning OFF (i.e. stuck in transition) if the module was
disabled while there was traffic on the CAN_RX line.
To work around this issue we select the SLEEP pin state by default
on probe and use the DEFAULT pin state on CAN up and back to the
SLEEP pin state on CAN down.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/net/can/c_can/c_can.c | 20 ++++++++++++++++++++
drivers/net/can/c_can/c_can.h | 1 +
drivers/net/can/c_can/c_can_platform.c | 20 ++++++++++++++++++++
3 files changed, 41 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 8e78bb4..4dfc3ce 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -35,6 +35,7 @@
#include <linux/list.h>
#include <linux/io.h>
#include <linux/pm_runtime.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/can.h>
#include <linux/can/dev.h>
@@ -603,6 +604,15 @@ static int c_can_start(struct net_device *dev)
priv->can.state = CAN_STATE_ERROR_ACTIVE;
+ /* activate pins */
+ if (!IS_ERR(priv->pinctrl)) {
+ struct pinctrl_state *s;
+
+ s = pinctrl_lookup_state(priv->pinctrl, PINCTRL_STATE_DEFAULT);
+ if (!IS_ERR(s))
+ pinctrl_select_state(priv->pinctrl, s);
+ }
+
return 0;
}
@@ -611,6 +621,16 @@ static void c_can_stop(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_irq_control(priv, false);
+
+ /* deactivate pins */
+ if (!IS_ERR(priv->pinctrl)) {
+ struct pinctrl_state *s;
+
+ s = pinctrl_lookup_state(priv->pinctrl, PINCTRL_STATE_SLEEP);
+ if (!IS_ERR(s))
+ pinctrl_select_state(priv->pinctrl, s);
+ }
+
priv->can.state = CAN_STATE_STOPPED;
}
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index b5067bd..6b4ed1f 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -207,6 +207,7 @@ struct c_can_priv {
u32 rxmasked;
u32 dlc[C_CAN_MSG_OBJ_TX_NUM];
const struct c_can_driver_data *drvdata;
+ struct pinctrl *pinctrl;
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index ef1f5ce..d058820 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -34,6 +34,7 @@
#include <linux/of_device.h>
#include <linux/mfd/syscon.h>
#include <linux/regmap.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/can/dev.h>
@@ -230,6 +231,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
struct clk *clk;
const struct c_can_driver_data *drvdata;
struct device_node *np = pdev->dev.of_node;
+ struct pinctrl *pinctrl;
match = of_match_device(c_can_of_table, &pdev->dev);
if (match) {
@@ -241,6 +243,23 @@ static int c_can_plat_probe(struct platform_device *pdev)
return -ENODEV;
}
+ pinctrl = devm_pinctrl_get(&pdev->dev);
+ if (!IS_ERR(pinctrl)) {
+ struct pinctrl_state *s;
+
+ /* Deactivate pins to prevent DRA7 DCAN IP from being
+ * stuck in transition when module is disabled.
+ * Pins are activated in c_can_start() and deactivated
+ * in c_can_stop()
+ */
+ s = pinctrl_lookup_state(pinctrl, PINCTRL_STATE_SLEEP);
+ if (!IS_ERR(s))
+ pinctrl_select_state(pinctrl, s);
+ } else {
+ dev_warn(&pdev->dev,
+ "failed to get pinctrl\n");
+ }
+
/* get the appropriate clk */
clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(clk)) {
@@ -271,6 +290,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
priv = netdev_priv(dev);
priv->drvdata = drvdata;
+ priv->pinctrl = pinctrl;
switch (drvdata->id) {
case BOSCH_C_CAN:
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 7/8] net: can: c_can: Add support for TI DRA7 DCAN
From: Roger Quadros @ 2014-11-04 10:21 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415096461-25576-1-git-send-email-rogerq@ti.com>
DRA7 SoC has 2 CAN IPs. Provide compatible IDs and RAMINIT
register data for both.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Documentation/devicetree/bindings/net/can/c_can.txt | 1 +
drivers/net/can/c_can/c_can_platform.c | 16 ++++++++++++++++
2 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt
index 917ac0e..746cc07 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -4,6 +4,7 @@ Bosch C_CAN/D_CAN controller Device Tree Bindings
Required properties:
- compatible : Should be "bosch,c_can" for C_CAN controllers and
"bosch,d_can" for D_CAN controllers.
+ Can be "ti,dra7-d_can1" or "ti,dra7-d_can2".
- reg : physical base address and size of the C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index d058820..dc618ce 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -195,6 +195,20 @@ static struct c_can_driver_data d_can_drvdata = {
.id = BOSCH_D_CAN,
};
+static struct c_can_driver_data dra7_dcan1_drvdata = {
+ .id = BOSCH_D_CAN,
+ .raminit_start_bit = 3,
+ .raminit_done_bit = 1,
+ .raminit_pulse = true,
+};
+
+static struct c_can_driver_data dra7_dcan2_drvdata = {
+ .id = BOSCH_D_CAN,
+ .raminit_start_bit = 5,
+ .raminit_done_bit = 2,
+ .raminit_pulse = true,
+};
+
static struct platform_device_id c_can_id_table[] = {
{
.name = KBUILD_MODNAME,
@@ -215,6 +229,8 @@ MODULE_DEVICE_TABLE(platform, c_can_id_table);
static const struct of_device_id c_can_of_table[] = {
{ .compatible = "bosch,c_can", .data = &c_can_drvdata },
{ .compatible = "bosch,d_can", .data = &d_can_drvdata },
+ { .compatible = "ti,dra7-d_can1", .data = &dra7_dcan1_drvdata },
+ { .compatible = "ti,dra7-d_can2", .data = &dra7_dcan2_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 3/8] net: can: c_can: Add RAMINIT register information to driver data
From: Roger Quadros @ 2014-11-04 10:20 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415096461-25576-1-git-send-email-rogerq@ti.com>
Some platforms (e.g. TI) need special RAMINIT register handling.
Provide a way to store RAMINIT register description in driver data.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/net/can/c_can/c_can.h | 6 ++++++
drivers/net/can/c_can/c_can_platform.c | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 26c975d..c3b2108 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -171,6 +171,11 @@ enum c_can_dev_id {
struct c_can_driver_data {
enum c_can_dev_id id;
+
+ /* RAMINIT register description. Optional. */
+ u8 raminit_start_bit; /* START bit position in RAMINIT reg. */
+ u8 raminit_done_bit; /* DONE bit position in RAMINIT reg. */
+ bool raminit_pulse; /* If set, sets and clears START bit (pulse) */
};
/* c_can private data structure */
@@ -196,6 +201,7 @@ struct c_can_priv {
u32 comm_rcv_high;
u32 rxmasked;
u32 dlc[C_CAN_MSG_OBJ_TX_NUM];
+ const struct c_can_driver_data *drvdata;
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index 1546c2b..11946e8 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -250,6 +250,8 @@ static int c_can_plat_probe(struct platform_device *pdev)
}
priv = netdev_priv(dev);
+ priv->drvdata = drvdata;
+
switch (drvdata->id) {
case BOSCH_C_CAN:
priv->regs = reg_map_c_can;
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 5/8] net: can: c_can: Add support for START pulse in RAMINIT sequence
From: Roger Quadros @ 2014-11-04 10:20 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415096461-25576-1-git-send-email-rogerq@ti.com>
Some SoCs e.g. (TI DRA7xx) need a START pulse to start the
RAMINIT sequence i.e. START bit must be set and cleared before
checking for the DONE bit status.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/net/can/c_can/c_can_platform.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index d0ce439..ef1f5ce 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -124,6 +124,12 @@ static void c_can_hw_raminit_syscon(const struct c_can_priv *priv, bool enable)
ctrl |= 1 << start_bit;
regmap_write(raminit->syscon, raminit->reg, ctrl);
+ /* clear START bit if start pulse is needed */
+ if (priv->drvdata->raminit_pulse) {
+ ctrl &= ~(1 << start_bit);
+ regmap_write(raminit->syscon, raminit->reg, ctrl);
+ }
+
ctrl |= 1 << done_bit;
c_can_hw_raminit_wait_syscon(priv, mask, ctrl);
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH v3 8/8] net: can: c_can: Add support for TI am3352 DCAN
From: Roger Quadros @ 2014-11-04 10:21 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415096461-25576-1-git-send-email-rogerq@ti.com>
AM3352 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for am3352 DCAN.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Documentation/devicetree/bindings/net/can/c_can.txt | 3 ++-
drivers/net/can/c_can/c_can_platform.c | 14 ++++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt
index 746cc07..27205d9 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -4,7 +4,8 @@ Bosch C_CAN/D_CAN controller Device Tree Bindings
Required properties:
- compatible : Should be "bosch,c_can" for C_CAN controllers and
"bosch,d_can" for D_CAN controllers.
- Can be "ti,dra7-d_can1" or "ti,dra7-d_can2".
+ Can be "ti,dra7-d_can1" or "ti,dra7-d_can2" or
+ "ti,am3352-d_can0" or "ti,am3352-d_can1".
- reg : physical base address and size of the C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index dc618ce..7dcdcde 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -209,6 +209,18 @@ static struct c_can_driver_data dra7_dcan2_drvdata = {
.raminit_pulse = true,
};
+static struct c_can_driver_data am3352_dcan0_drvdata = {
+ .id = BOSCH_D_CAN,
+ .raminit_start_bit = 0,
+ .raminit_done_bit = 8,
+};
+
+static struct c_can_driver_data am3352_dcan1_drvdata = {
+ .id = BOSCH_D_CAN,
+ .raminit_start_bit = 1,
+ .raminit_done_bit = 9,
+};
+
static struct platform_device_id c_can_id_table[] = {
{
.name = KBUILD_MODNAME,
@@ -231,6 +243,8 @@ static const struct of_device_id c_can_of_table[] = {
{ .compatible = "bosch,d_can", .data = &d_can_drvdata },
{ .compatible = "ti,dra7-d_can1", .data = &dra7_dcan1_drvdata },
{ .compatible = "ti,dra7-d_can2", .data = &dra7_dcan2_drvdata },
+ { .compatible = "ti,am3352-d_can0", .data = &am3352_dcan0_drvdata },
+ { .compatible = "ti,am3352-d_can1", .data = &am3352_dcan1_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
--
1.8.3.2
^ permalink raw reply related
* RE: [PATCH] net: eth: realtek: atp: checkpatch errors and warnings corrected
From: David Laight @ 2014-11-04 10:19 UTC (permalink / raw)
To: 'Roberto Medina', Joe Perches
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <5457D2DF.5000508@gmail.com>
From: Roberto Medina
> On 11/03/2014 07:51 PM, Joe Perches wrote:
> >
> > Some ancient drivers could be regarded as neolithic
> > curiosities that never need updating. This may be one.
> >
> > But if you really want to change it, could you please
> > make sure that objdiff shows no changes?
> >
>
> I see some changes with objdiff, maybe this is caused by the include
> file that I changed to linux/io.h instead of asm/io.h
>
> ---
> /home/vov/Git/linux-next/.tmp_objdiff/a641d0e/drivers/net/ethernet/realtek/atp.dis
> 2014-11-03 19:59:18.723954900 +0100
> +++
> /home/vov/Git/linux-next/.tmp_objdiff/5f19b70/drivers/net/ethernet/realtek/atp.dis
> 2014-11-03 20:00:34.133954217 +0100
> @@ -1753,9 +1753,8 @@
> ...
> : e3 0a jrcxz 4c4 <__gcov_.atp_probe1+0x14>
> : 00 00 add %al,(%rax)
> -: e2 e2 loop 4a0 <__gcov_.atp_init+0x20>
> -: 9c pushfq
> -: 9a (bad)
> +: 4b b4 98 rex.WXB mov $0x98,%r12b
> +: ac lods %ds:(%rsi),%al
> : 67 2f addr32 (bad)
> : e4 e3 in $0xe3,%al
> : 00 00 add %al,(%rax)
That code (and all the ones below) are gibberish, neither the old or new
sequences make any sense.
Almost as though you used the wrong instruction set!
David
^ permalink raw reply
* RE: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on arndale platform
From: Stam, Michel [FINT] @ 2014-11-04 10:23 UTC (permalink / raw)
To: Riku Voipio
Cc: davem, linux-usb, netdev, linux-kernel, linux-samsung-soc,
ckeepax, David Miller
In-Reply-To: <20141104094336.GA3145@afflict.kos.to>
Hello Riku,
>Fixing a bug (ethtool support) must not cause breakage elsewhere (in
this case on arndale). This is now a regression of functionality from
3.17.
>
>I think it would better to revert the change now and with less hurry
introduce a ethtool fix that doesn't break arndale.
I don't fully agree here;
I would like to point out that this commit is a revert itself. Fixing
the armdale will then cause breakage in other implementations, such as
ours. Blankly reverting breaks other peoples' implementations.
The PHY reset is the thing that breaks ethtool support, so any fix that
appeases all would have to take existing PHY state into account.
I'm not an expert on the ASIX driver, nor the MII, but I think this is
the cause;
drivers/net/usb/asix_devices.c:
361 asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR,
BMCR_RESET);
362 asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
363 ADVERTISE_ALL | ADVERTISE_CSMA);
364 mii_nway_restart(&dev->mii);
I would think that the ADVERTISE_ALL is the cause here, as it will reset
the MII back to default, thus overriding ethtool settings.
Would an:
Int reg;
reg = asix_mdio_read(dev->net,dev->mii.phy_id,MII_ADVERTISE);
prior to the offending lines, and then;
362 asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
363 reg);
solve the problem for you guys?
Mind, maybe the read function should take into account the reset value
of the MII, and set it to ADVERTISE_ALL | ADVERTISE_CSMA. I don't have
any documention here at the moment.
Is anyone able to confirm my suspicions?
Kind regards,
Michel Stam
-----Original Message-----
From: Riku Voipio [mailto:riku.voipio@iki.fi]
Sent: Tuesday, November 04, 2014 10:44 AM
To: Stam, Michel [FINT]
Cc: Riku Voipio; davem@davemloft.net; linux-usb@vger.kernel.org;
netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-samsung-soc@vger.kernel.org; ckeepax@opensource.wolfsonmicro.com
Subject: Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net
on arndale platform
On Tue, Nov 04, 2014 at 09:19:26AM +0100, Stam, Michel [FINT] wrote:
> Interesting, as the commit itself is a revert from a kernel back to
> 2.6 somewhere. The problem I had is related to the PHY being reset on
> interface-up, can you confirm that you require this?
I can't confirm what exactly is needed on arndale. I'm neither expert in
USB or ethernet. However, I can confirm that without the PHY reset,
networking doesn't work on arndale.
I now see someone else has the same problem, adding Charles to CC.
http://www.spinics.net/lists/linux-usb/msg116656.html
> Reverting this
> breaks ethtool support in turn.
Fixing a bug (ethtool support) must not cause breakage elsewhere (in
this case on arndale). This is now a regression of functionality from
3.17.
I think it would better to revert the change now and with less hurry
introduce a ethtool fix that doesn't break arndale.
> Kind regards,
>
> Michel Stam
>
> -----Original Message-----
> From: Riku Voipio [mailto:riku.voipio@iki.fi]
> Sent: Tuesday, November 04, 2014 8:23 AM
> To: davem@davemloft.net; Stam, Michel [FINT]
> Cc: linux-usb@vger.kernel.org; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-samsung-soc@vger.kernel.org
> Subject: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net on
> arndale platform
>
> Hi,
>
> With 3.18-rc3, asix on arndale (samsung exynos 5250 based board),
> fails to work. Interface is initialized but network traffic seem not
> to pass through. With kernel IP config the result looks like:
>
> [ 3.323275] usb 3-3.2.4: new high-speed USB device number 4 using
> exynos-ehci
> [ 3.419151] usb 3-3.2.4: New USB device found, idVendor=0b95,
> idProduct=772a
> [ 3.424735] usb 3-3.2.4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 3.432196] usb 3-3.2.4: Product: AX88772
> [ 3.436279] usb 3-3.2.4: Manufacturer: ASIX Elec. Corp.
> [ 3.441486] usb 3-3.2.4: SerialNumber: 000001
> [ 3.447530] asix 3-3.2.4:1.0 (unnamed net_device) (uninitialized):
> invalid hw address, using random
> [ 3.764352] asix 3-3.2.4:1.0 eth0: register 'asix' at
> usb-12110000.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet,
de:a2:66:bf:ca:4f
> [ 4.488773] asix 3-3.2.4:1.0 eth0: link down
> [ 5.690025] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex,
lpa
> 0xC5E1
> [ 5.712947] Sending DHCP requests ...... timed out!
> [ 83.165303] IP-Config: Retrying forever (NFS root)...
> [ 83.170397] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex,
lpa
> 0xC5E1
> [ 83.192944] Sending DHCP requests .....
>
> Similar results also with dhclient. Git bisect identified the breaking
> commit as:
>
> commit 3cc81d85ee01e5a0b7ea2f4190e2ed1165f53c31
> Author: Michel Stam <m.stam@fugro.nl>
> Date: Thu Oct 2 10:22:02 2014 +0200
>
> asix: Don't reset PHY on if_up for ASIX 88772
>
> Taking 3.18-rc3 and that commit reverted, network works again:
>
> [ 3.303500] usb 3-3.2.4: new high-speed USB device number 4 using
> exynos-ehci
> [ 3.399375] usb 3-3.2.4: New USB device found, idVendor=0b95,
> idProduct=772a
> [ 3.404963] usb 3-3.2.4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 3.412424] usb 3-3.2.4: Product: AX88772
> [ 3.416508] usb 3-3.2.4: Manufacturer: ASIX Elec. Corp.
> [ 3.421715] usb 3-3.2.4: SerialNumber: 000001
> [ 3.427755] asix 3-3.2.4:1.0 (unnamed net_device) (uninitialized):
> invalid hw address, using random
> [ 3.744837] asix 3-3.2.4:1.0 eth0: register 'asix' at
> usb-12110000.usb-3.2.4, ASIX AX88772 USB 2.0 Ethernet,
12:59:f1:a8:43:90
> [ 7.098998] asix 3-3.2.4:1.0 eth0: link up, 100Mbps, full-duplex,
lpa
> 0xC5E1
> [ 7.118258] Sending DHCP requests ., OK
> [ 9.753259] IP-Config: Got DHCP answer from 192.168.1.1, my address
> is 192.168.1.111
>
> There might something wrong on the samsung platform code (I understand
> the USB on arndale is "funny"), but this is still an regression from
> 3.17.
>
> Riku
^ permalink raw reply
* Re: net: fec: fix regression on i.MX28 introduced by rx_copybreak support
From: Lothar Waßmann @ 2014-11-04 10:29 UTC (permalink / raw)
To: David Miller
Cc: Lothar Waßmann, fabio.estevam, Frank.Li, netdev,
linux-kernel, rmk+kernel, linux-arm-kernel
In-Reply-To: <20141031063210.69004315@ipc1.ka-ro>
Hi David,
Lothar Waßmann wrote:
> David Miller wrote:
> > From: Lothar Waßmann <LW@KARO-electronics.de>
> > Date: Thu, 30 Oct 2014 07:51:04 +0100
> >
> > >> Also, I don't thnk your DIV_ROUND_UP() eliminate for the loop
> > >> in swap_buffer() is valid. The whole point is that the current
> > >> code handles buffers which have a length which is not a multiple
> > >> of 4 properly, after your change it will no longer do so.
> > >>
> > > Do you really think so?
> >
> > Yes, because you're rounding down so you'll miss the final
> > partial word (if any).
> >
> Nope. DIV_ROUND_UP() would give '1' as upper bound for lengths from 1 to
> 4, '2' for lengths from 5 to 8 and so on.
>
> The loop with increment 4 and i < len does exactly the same.
> Try it for yourself, if you don't believe it.
>
>
Do you still think, the loop without DIV_ROUND_UP() is incorrect,
or can this patch be applied?
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: [PATCH 7/7] can: m_can: workaround for transmit data less than 4 bytes
From: Marc Kleine-Budde @ 2014-11-04 10:33 UTC (permalink / raw)
To: Dong Aisheng
Cc: linux-can, wg, varkabhadram, netdev, socketcan, linux-arm-kernel
In-Reply-To: <20141104092651.GC8060@shlinux1.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]
On 11/04/2014 10:27 AM, Dong Aisheng wrote:
>>>> It should be possible to change the for loop to go always to 8, or
>>>> simply unroll the loop:
>>>>
>>>> /* errata description goes here */
>>>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
>>>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
>>>>
>>>
>>> Yes, i tried to fix it as follows.
>>>
>>> /* FIXME: we meet an IC issue that we have to write the full 8
>>> * bytes (whatever value for the second word) in Message RAM to
>>> * avoid bit error for transmit data less than 4 bytes
>>> */
>>> if (cf->len <= 4) {
>>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0),
>>> *(u32 *)(cf->data + 0));
>>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1),
>>> *(u32 *)(cf->data + 4));
>>> } else {
>>> for (i = 0; i < cf->len; i += 4)
>>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
>>> *(u32 *)(cf->data + i));
>>>
>>> Will update the patch.
>>
>> Both branches of the above if are doing the same thing, I think you can
>> replace the while if ... else ... for with this:
>>
>
> Not the same thing.
> The later one will cover payload up to 64 bytes.
Doh! I'm not used to CAN-FD, yet :) However, I'll apply this fix before
adding the CAN-FD support.
>> /* errata description goes here */
>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
>> m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
>>
>> However if writing to DATA(0) and DATA(1) once in the open() function is
>> enough this code should stay as it is.
>
> I tried put them into open() function and the quick test showed it worked.
>
> Do you think it's ok to put things into open() function for this issue
> as follows?
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 065e4f1..ca55988 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -901,6 +901,15 @@ static void m_can_chip_config(struct net_device *dev)
> /* set bittiming params */
> m_can_set_bittiming(dev);
>
> + /* We meet an IC issue that we have to write the full 8
At least on the *insert SoC name here*, an issue with the Message RAM
was discovered. Sending CAN frames with dlc less than 4 bytes will lead
to bit errors, when the first 8 bytes of the Message RAM have not been
initialized (i.e. written to). To work around this issue, the first 8
bytes are initialized here.
> + * bytes (whatever value for the second word) in Message RAM to
> + * avoid bit error for transmit data less than 4 bytes at the first
> + * time. By initializing the first 8 bytes of tx buffer before using
> + * it can avoid such issue.
> + */
> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
> +
> m_can_config_endisable(priv, false);
> }
Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
< 64?
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] ip-link: in human readable output use dynamic precision length
From: Christian Hesse @ 2014-11-04 10:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <1415093990-22632-1-git-send-email-mail@eworm.de>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Christian Hesse <mail@eworm.de> on Tue, 2014/11/04 10:39:
> Now that we use floating point numbers for human readable output we can
> calculate precision length on the fly.
> ---
> ip/ipaddress.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index e240bb5..0ddcb0d 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -343,8 +343,8 @@ static void print_num(FILE *fp, unsigned width,
> uint64_t count) ++prefix;
> }
>
> - snprintf(buf, sizeof(buf), "%.1f%c%s", (double) count / powi,
> - *prefix, use_iec ? "i" : "");
> + snprintf(buf, sizeof(buf), "%.*f%c%s", 3 - snprintf(NULL, 0,
> "%"PRIu64, count / powi),
> + (double) count / powi, *prefix, use_iec ? "i" : "");
>
> fprintf(fp, "%-*s ", width, buf);
> }
Damn... In IEC mode we have negative precision length for values between 1000
and 1024. Will send a new patch.
--
Best Regards,
Christian Hesse
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v2 1/1] ip-link: in human readable output use dynamic precision length
From: Christian Hesse @ 2014-11-04 10:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Christian Hesse
In-Reply-To: <20141104114421.6a7f9de5@leda.localdomain>
---
ip/ipaddress.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index e240bb5..55cbc77 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -324,6 +324,7 @@ static void print_num(FILE *fp, unsigned width, uint64_t count)
const char *prefix = "kMGTPE";
const unsigned int base = use_iec ? 1024 : 1000;
uint64_t powi = 1;
+ int precision;
char buf[64];
if (!human_readable || count < base) {
@@ -343,8 +344,11 @@ static void print_num(FILE *fp, unsigned width, uint64_t count)
++prefix;
}
- snprintf(buf, sizeof(buf), "%.1f%c%s", (double) count / powi,
- *prefix, use_iec ? "i" : "");
+ if ((precision = 3 - snprintf(NULL, 0, "%"PRIu64, count / powi)) < 0)
+ precision = 0;
+
+ snprintf(buf, sizeof(buf), "%.*f%c%s", precision,
+ (double) count / powi, *prefix, use_iec ? "i" : "");
fprintf(fp, "%-*s ", width, buf);
}
--
2.1.3
^ permalink raw reply related
* Re: [PATCH] Add missing descriptions for fwmark_reflect for ipv4 and ipv6.
From: Loganaden Velvindron @ 2014-11-04 10:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141030.161137.1421672304905070027.davem@davemloft.net>
t was initially sent by Lorenzo Colitti, but was subsequently
lost in the final diff he submitted.
Signed-off-by: Loganaden Velvindron <logan@elandsys.com>
---
Documentation/networking/ip-sysctl.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 0307e28..a476b08 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -56,6 +56,13 @@ ip_forward_use_pmtu - BOOLEAN
0 - disabled
1 - enabled
+fwmark_reflect - BOOLEAN
+ Controls the fwmark of kernel-generated IPv4 reply packets that are not
+ associated with a socket for example, TCP RSTs or ICMP echo replies).
+ If unset, these packets have a fwmark of zero. If set, they have the
+ fwmark of the packet they are replying to.
+ Default: 0
+
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
@@ -1201,6 +1208,13 @@ conf/all/forwarding - BOOLEAN
proxy_ndp - BOOLEAN
Do proxy ndp.
+fwmark_reflect - BOOLEAN
+ Controls the fwmark of kernel-generated IPv6 reply packets that are not
+ associated with a socket for example, TCP RSTs or ICMPv6 echo replies).
+ If unset, these packets have a fwmark of zero. If set, they have the
+ fwmark of the packet they are replying to.
+ Default: 0
+
conf/interface/*:
Change special settings per interface.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] Add missing descriptions for fwmark_reflect for ipv4 and ipv6.
From: Loganaden Velvindron @ 2014-11-04 11:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141104105650.GA5233@mx.elandsys.com>
It was initially sent by Lorenzo Colitti, but was subsequently
lost in the final diff he submitted.
Signed-off-by: Loganaden Velvindron <logan@elandsys.com>
---
Documentation/networking/ip-sysctl.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 0307e28..a476b08 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -56,6 +56,13 @@ ip_forward_use_pmtu - BOOLEAN
0 - disabled
1 - enabled
+fwmark_reflect - BOOLEAN
+ Controls the fwmark of kernel-generated IPv4 reply packets that are not
+ associated with a socket for example, TCP RSTs or ICMP echo replies).
+ If unset, these packets have a fwmark of zero. If set, they have the
+ fwmark of the packet they are replying to.
+ Default: 0
+
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
@@ -1201,6 +1208,13 @@ conf/all/forwarding - BOOLEAN
proxy_ndp - BOOLEAN
Do proxy ndp.
+fwmark_reflect - BOOLEAN
+ Controls the fwmark of kernel-generated IPv6 reply packets that are not
+ associated with a socket for example, TCP RSTs or ICMPv6 echo replies).
+ If unset, these packets have a fwmark of zero. If set, they have the
+ fwmark of the packet they are replying to.
+ Default: 0
+
conf/interface/*:
Change special settings per interface.
--
1.9.1
^ permalink raw reply related
* RE: [PATCH v2 1/1] ip-link: in human readable output use dynamic precision length
From: David Laight @ 2014-11-04 11:06 UTC (permalink / raw)
To: 'Christian Hesse', Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <1415098208-17942-1-git-send-email-mail@eworm.de>
From: Christian Hesse
...
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index e240bb5..55cbc77 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -324,6 +324,7 @@ static void print_num(FILE *fp, unsigned width, uint64_t count)
> const char *prefix = "kMGTPE";
> const unsigned int base = use_iec ? 1024 : 1000;
> uint64_t powi = 1;
> + int precision;
> char buf[64];
>
> if (!human_readable || count < base) {
> @@ -343,8 +344,11 @@ static void print_num(FILE *fp, unsigned width, uint64_t count)
> ++prefix;
> }
>
> - snprintf(buf, sizeof(buf), "%.1f%c%s", (double) count / powi,
> - *prefix, use_iec ? "i" : "");
> + if ((precision = 3 - snprintf(NULL, 0, "%"PRIu64, count / powi)) < 0)
Don't put assignments in conditionals.
> + precision = 0;
> +
> + snprintf(buf, sizeof(buf), "%.*f%c%s", precision,
> + (double) count / powi, *prefix, use_iec ? "i" : "");
>
> fprintf(fp, "%-*s ", width, buf);
> }
> --
> 2.1.3
The above will go wrong in all sorts of horrid ways....
For instance you are doing a truncating integer divide, but the FP
value will get rounded for display.
It would be safer to use integers throughout.
Oh, and a 2Mbit E1 link is actually 2048000 :-)
David
^ permalink raw reply
* Re: [PATCH ipsec-next] xfrm: add XFRMA_REPLAY_VAL attribute to SA messages
From: Steffen Klassert @ 2014-11-04 11:33 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, netdev, dingzhi, Adrien Mazarguil
In-Reply-To: <1414658376-4207-1-git-send-email-nicolas.dichtel@6wind.com>
On Thu, Oct 30, 2014 at 09:39:36AM +0100, Nicolas Dichtel wrote:
> From: dingzhi <zhi.ding@6wind.com>
>
> After this commit, the attribute XFRMA_REPLAY_VAL is added when no ESN replay
> value is defined. Thus sequence number values are always notified to userspace.
>
> Signed-off-by: dingzhi <zhi.ding@6wind.com>
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied to ipsec-next, thanks!
^ permalink raw reply
* Re: TCP NewReno and single retransmit
From: Marcelo Ricardo Leitner @ 2014-11-04 13:12 UTC (permalink / raw)
To: Yuchung Cheng, Neal Cardwell; +Cc: netdev, Eric Dumazet
In-Reply-To: <CAK6E8=cgkznkAWTps7aA+txuETpZ2RNiU3rbQf9WxLjawhgNog@mail.gmail.com>
On 04-11-2014 05:59, Yuchung Cheng wrote:
> On Tue, Nov 4, 2014 at 7:17 AM, Neal Cardwell <ncardwell@google.com> wrote:
>> On Mon, Nov 3, 2014 at 4:35 PM, Marcelo Ricardo Leitner
>> <mleitner@redhat.com> wrote:
>>> So by sticking with the recovery for a bit longer will help disambiguate the
>>> 3 dupacks on high_seq, if they ever happen, and with that avoid re-entering
>>> Fast Retransmit if initial (2) happen. It's at the cost of leaving the fast
>>> retransmit an ack later but if (2) happens the impact would be much worse,
>>> AFAICS.
>>
>> Yes, that's my sense.
>>
>>> Cool, thanks Neal. If Yuchung is okay with it, I'll proceed with just
>>> zeroing that tstamp as initially proposed.
>>
>> Yes, that sounds good to me for a short-term fix for the "net" branch,
>> as long as it's:
>>
>> + if (!tcp_any_retrans_done(sk))
>> + tp->retrans_stamp = 0;
>>
>> Longer-term ("net-next"?) perhaps it makes sense to remove the hold
>> state and protect against this spurious FR situation at the time we
>> decide to enter Fast Recovery, which seems to be the model the RFC is
>> suggesting.
> Thanks for checking. So my suggested fix of removing the hold state is
> the "less careful variant" that RFC does not recommend. I would rather
> have the proposed 2-liner fix than implementing the section 6
> heuristics to detect spurious retransmit. It's not worth the effort.
> Everyone should use SACK.
Yup, agreed.
Thanks,
Marcelo
^ permalink raw reply
* Re: [PATCH 7/7] can: m_can: workaround for transmit data less than 4 bytes
From: Oliver Hartkopp @ 2014-11-04 13:13 UTC (permalink / raw)
To: Marc Kleine-Budde, Dong Aisheng
Cc: linux-can, wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <5458AB65.7000500@pengutronix.de>
On 04.11.2014 11:33, Marc Kleine-Budde wrote:
> On 11/04/2014 10:27 AM, Dong Aisheng wrote:
>> + /* We meet an IC issue that we have to write the full 8
>
> At least on the *insert SoC name here*, an issue with the Message RAM
> was discovered. Sending CAN frames with dlc less than 4 bytes will lead
> to bit errors, when the first 8 bytes of the Message RAM have not been
> initialized (i.e. written to). To work around this issue, the first 8
> bytes are initialized here.
Yes. Also put the current IP revision (3.0.x) into the comment.
Did inform the Bosch guys from this issue - or is it already in some errata sheet?
>
>> + * bytes (whatever value for the second word) in Message RAM to
>> + * avoid bit error for transmit data less than 4 bytes at the first
>> + * time. By initializing the first 8 bytes of tx buffer before using
>> + * it can avoid such issue.
>> + */
>> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
>> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
>> +
>> m_can_config_endisable(priv, false);
>> }
>
> Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
> < 64?
Just a nitpick:
DLC can just be 0 .. 15
and the length (struct canfd_frame.len) can be from 0 .. 64
See:
http://lxr.free-electrons.com/source/include/uapi/linux/can.h#L83
That's the reason for all these helpers
http://lxr.free-electrons.com/source/drivers/net/can/dev.c#L36
that hide the evil "DLC" from userspace now and make 'len' a usable loop
variable as we were able to use the former dlc for classic CAN :-)
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH 7/7] can: m_can: workaround for transmit data less than 4 bytes
From: Marc Kleine-Budde @ 2014-11-04 13:28 UTC (permalink / raw)
To: Oliver Hartkopp, Dong Aisheng
Cc: linux-can, wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <5458D0FA.1040504@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]
On 11/04/2014 02:13 PM, Oliver Hartkopp wrote:
>
>
> On 04.11.2014 11:33, Marc Kleine-Budde wrote:
>> On 11/04/2014 10:27 AM, Dong Aisheng wrote:
>
>
>>> + /* We meet an IC issue that we have to write the full 8
>>
>> At least on the *insert SoC name here*, an issue with the Message RAM
>> was discovered. Sending CAN frames with dlc less than 4 bytes will lead
>> to bit errors, when the first 8 bytes of the Message RAM have not been
>> initialized (i.e. written to). To work around this issue, the first 8
>> bytes are initialized here.
>
> Yes. Also put the current IP revision (3.0.x) into the comment.
Good idea - also add the SoC's mask revision.
> Did inform the Bosch guys from this issue - or is it already in some
> errata sheet?
>
>>
>>> + * bytes (whatever value for the second word) in Message RAM to
>>> + * avoid bit error for transmit data less than 4 bytes at the
>>> first
>>> + * time. By initializing the first 8 bytes of tx buffer
>>> before using
>>> + * it can avoid such issue.
>>> + */
>>> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
>>> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
>>> +
>>> m_can_config_endisable(priv, false);
>>> }
>>
>> Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
>> < 64?
>
> Just a nitpick:
>
> DLC can just be 0 .. 15
Correct, I was talking about the length
> and the length (struct canfd_frame.len) can be from 0 .. 64
>
> See:
>
> http://lxr.free-electrons.com/source/include/uapi/linux/can.h#L83
>
> That's the reason for all these helpers
>
> http://lxr.free-electrons.com/source/drivers/net/can/dev.c#L36
>
> that hide the evil "DLC" from userspace now and make 'len' a usable loop
> variable as we were able to use the former dlc for classic CAN :-)
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net] vxlan: Do not reuse sockets for a different address family
From: Marcelo Ricardo Leitner @ 2014-11-04 13:46 UTC (permalink / raw)
To: netdev; +Cc: stephen
Currently, we only match against local port number in order to reuse
socket. But if this new vxlan wants an IPv6 socket and a IPv4 one bound
to that port, vxlan will reuse an IPv4 socket as IPv6 and a panic will
follow. The following steps reproduce it:
# ip link add vxlan6 type vxlan id 42 group 229.10.10.10 \
srcport 5000 6000 dev eth0
# ip link add vxlan7 type vxlan id 43 group ff0e::110 \
srcport 5000 6000 dev eth0
# ip link set vxlan6 up
# ip link set vxlan7 up
<panic>
[ 4.187481] BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
[ 4.187509] IP: [<ffffffff81667c98>] ipv6_sock_mc_join+0x88/0x630
...
[ 4.188076] Call Trace:
[ 4.188085] [<ffffffff81667c4a>] ? ipv6_sock_mc_join+0x3a/0x630
[ 4.188098] [<ffffffffa05a6ad6>] vxlan_igmp_join+0x66/0xd0 [vxlan]
[ 4.188113] [<ffffffff810a3430>] process_one_work+0x220/0x710
[ 4.188125] [<ffffffff810a33c4>] ? process_one_work+0x1b4/0x710
[ 4.188138] [<ffffffff810a3a3b>] worker_thread+0x11b/0x3a0
[ 4.188149] [<ffffffff810a3920>] ? process_one_work+0x710/0x710
So address family must also match in order to reuse a socket.
Reported-by: Jean-Tsung Hsiao <jhsiao@redhat.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
---
drivers/net/vxlan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ca309820d39e1ba7995f38d3a2f9bacbd1c1f857..c0fa76d55ae3cc07fb14b70656d6b13b5bab091c 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -281,7 +281,8 @@ static struct vxlan_sock *vxlan_find_sock(struct net *net, __be16 port)
struct vxlan_sock *vs;
hlist_for_each_entry_rcu(vs, vs_head(net, port), hlist) {
- if (inet_sk(vs->sock->sk)->inet_sport == port)
+ if ((inet_sk(vs->sock->sk)->inet_sport == port) &&
+ (inet_sk(vs->sock->sk)->sk.sk_family == family))
return vs;
}
return NULL;
--
1.9.3
^ permalink raw reply related
* [PATCH net] tcp: zero retrans_stamp if all retrans were acked
From: Marcelo Ricardo Leitner @ 2014-11-04 14:18 UTC (permalink / raw)
To: netdev; +Cc: ncardwell, ycheng, edumazet
Ueki Kohei reported that when we are using NewReno with connections that
have a very low traffic, we may timeout the connection too early if a
second loss occurs after the first one was successfully acked but no
data was transfered later. Below is his description of it:
When SACK is disabled, and a socket suffers multiple separate TCP
retransmissions, that socket's ETIMEDOUT value is calculated from the
time of the *first* retransmission instead of the *latest*
retransmission.
This happens because the tcp_sock's retrans_stamp is set once then never
cleared.
Take the following connection:
Linux remote-machine
| |
send#1---->(*1)|--------> data#1 --------->|
| | |
RTO : :
| | |
---(*2)|----> data#1(retrans) ---->|
| (*3)|<---------- ACK <----------|
| | |
| : :
| : :
| : :
16 minutes (or more) :
| : :
| : :
| : :
| | |
send#2---->(*4)|--------> data#2 --------->|
| | |
RTO : :
| | |
---(*5)|----> data#2(retrans) ---->|
| | |
| | |
RTO*2 : :
| | |
| | |
ETIMEDOUT<----(*6)| |
(*1) One data packet sent.
(*2) Because no ACK packet is received, the packet is retransmitted.
(*3) The ACK packet is received. The transmitted packet is acknowledged.
At this point the first "retransmission event" has passed and been
recovered from. Any future retransmission is a completely new "event".
(*4) After 16 minutes (to correspond with retries2=15), a new data
packet is sent. Note: No data is transmitted between (*3) and (*4).
The socket's timeout SHOULD be calculated from this point in time, but
instead it's calculated from the prior "event" 16 minutes ago.
(*5) Because no ACK packet is received, the packet is retransmitted.
(*6) At the time of the 2nd retransmission, the socket returns
ETIMEDOUT.
Therefore, now we clear retrans_stamp as soon as all data during the
loss window is fully acked.
Reported-by: Ueki Kohei
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
---
net/ipv4/tcp_input.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index a12b455928e52211efdc6b471ef54de6218f5df0..65686efeaaf3c36706390d3bfd260fd1fb942b7f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2410,6 +2410,8 @@ static bool tcp_try_undo_recovery(struct sock *sk)
* is ACKed. For Reno it is MUST to prevent false
* fast retransmits (RFC2582). SACK TCP is safe. */
tcp_moderate_cwnd(tp);
+ if (!tcp_any_retrans_done(sk))
+ tp->retrans_stamp = 0;
return true;
}
tcp_set_ca_state(sk, TCP_CA_Open);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 0/1] mv643xx_eth: Disable TSO by default
From: Karl Beldan @ 2014-11-04 14:20 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: netdev, David Miller, Thomas Petazzoni, Gregory Clement,
Tawfik Bayouk, Lior Amsalem, Nadav Haklai
In-Reply-To: <1414855820-15094-1-git-send-email-ezequiel.garcia@free-electrons.com>
On Sat, Nov 01, 2014 at 12:30:19PM -0300, Ezequiel Garcia wrote:
> Several users ([1], [2]) have been reporting data corruption with TSO on
> Kirkwood platforms (i.e. using the mv643xx_eth driver).
>
> Until we manage to find what's causing this, this simple patch will make
> the TSO path disabled by default. This patch should be queued for stable,
> fixing the TSO feature introduced in v3.16.
>
> The corruption itself is very easy to reproduce: checking md5sum on a mounted
> NFS directory gives a different result each time. Same tests using the mvneta
> driver (Armada 370/38x/XP SoC) pass with no issues.
>
> Frankly, I'm a bit puzzled about this, and so any ideas or debugging hints
> are well received.
>
Hi,
Can you try this :
@@ -1067,7 +1082,8 @@ static int txq_reclaim(struct tx_queue *txq, int budget, int force)
txq->tx_desc_count--;
skb = NULL;
- if (cmd_sts & TX_LAST_DESC)
+ if ((cmd_sts & (TX_LAST_DESC | TX_ENABLE_INTERRUPT)) ==
+ (TX_LAST_DESC | TX_ENABLE_INTERRUPT))
skb = __skb_dequeue(&txq->tx_skb);
if (cmd_sts & ERROR_SUMMARY) {
--
Karl
^ 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