* [PATCH v13 1/6] flexcan: Remove #include <mach/clock.h>
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
PPC list, Wolfgang Grandegger
In-Reply-To: <1313551944-28603-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
powerpc does not have a mach-####/clock.h. When testing, I found neither
arm nor powerpc needed the mach/clock.h at all so I removed it.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
---
drivers/net/can/flexcan.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 1767811..586b2cd 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -35,8 +35,6 @@
#include <linux/module.h>
#include <linux/platform_device.h>
-#include <mach/clock.h>
-
#define DRV_NAME "flexcan"
/* 8 for RX fifo and 2 error handling */
--
1.7.2.1
^ permalink raw reply related
* [PATCH v13 2/6] flexcan: Abstract off read/write for big/little endian.
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
PPC list, Wolfgang Grandegger
In-Reply-To: <1313551944-28603-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
Make flexcan driver handle register reads in the appropriate endianess.
This was a basic search and replace and then define some inlines.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
---
drivers/net/can/flexcan.c | 140 ++++++++++++++++++++++++++------------------
1 files changed, 83 insertions(+), 57 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 586b2cd..68cbe52 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -190,6 +190,31 @@ static struct can_bittiming_const flexcan_bittiming_const = {
};
/*
+ * Abstract off the read/write for arm versus ppc.
+ */
+#if defined(__BIG_ENDIAN)
+static inline u32 flexcan_read(void __iomem *addr)
+{
+ return in_be32(addr);
+}
+
+static inline void flexcan_write(u32 val, void __iomem *addr)
+{
+ out_be32(addr, val);
+}
+#else
+static inline u32 flexcan_read(void __iomem *addr)
+{
+ return readl(addr);
+}
+
+static inline void flexcan_write(u32 val, void __iomem *addr)
+{
+ writel(val, addr);
+}
+#endif
+
+/*
* Swtich transceiver on or off
*/
static void flexcan_transceiver_switch(const struct flexcan_priv *priv, int on)
@@ -210,9 +235,9 @@ static inline void flexcan_chip_enable(struct flexcan_priv *priv)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg &= ~FLEXCAN_MCR_MDIS;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
udelay(10);
}
@@ -222,9 +247,9 @@ static inline void flexcan_chip_disable(struct flexcan_priv *priv)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg |= FLEXCAN_MCR_MDIS;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
}
static int flexcan_get_berr_counter(const struct net_device *dev,
@@ -232,7 +257,7 @@ static int flexcan_get_berr_counter(const struct net_device *dev,
{
const struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->base;
- u32 reg = readl(®s->ecr);
+ u32 reg = flexcan_read(®s->ecr);
bec->txerr = (reg >> 0) & 0xff;
bec->rxerr = (reg >> 8) & 0xff;
@@ -266,15 +291,15 @@ static int flexcan_start_xmit(struct sk_buff *skb, struct net_device *dev)
if (cf->can_dlc > 0) {
u32 data = be32_to_cpup((__be32 *)&cf->data[0]);
- writel(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[0]);
+ flexcan_write(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[0]);
}
if (cf->can_dlc > 3) {
u32 data = be32_to_cpup((__be32 *)&cf->data[4]);
- writel(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[1]);
+ flexcan_write(data, ®s->cantxfg[FLEXCAN_TX_BUF_ID].data[1]);
}
- writel(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
- writel(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
+ flexcan_write(can_id, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_id);
+ flexcan_write(ctrl, ®s->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
kfree_skb(skb);
@@ -462,8 +487,8 @@ static void flexcan_read_fifo(const struct net_device *dev,
struct flexcan_mb __iomem *mb = ®s->cantxfg[0];
u32 reg_ctrl, reg_id;
- reg_ctrl = readl(&mb->can_ctrl);
- reg_id = readl(&mb->can_id);
+ reg_ctrl = flexcan_read(&mb->can_ctrl);
+ reg_id = flexcan_read(&mb->can_id);
if (reg_ctrl & FLEXCAN_MB_CNT_IDE)
cf->can_id = ((reg_id >> 0) & CAN_EFF_MASK) | CAN_EFF_FLAG;
else
@@ -473,12 +498,12 @@ static void flexcan_read_fifo(const struct net_device *dev,
cf->can_id |= CAN_RTR_FLAG;
cf->can_dlc = get_can_dlc((reg_ctrl >> 16) & 0xf);
- *(__be32 *)(cf->data + 0) = cpu_to_be32(readl(&mb->data[0]));
- *(__be32 *)(cf->data + 4) = cpu_to_be32(readl(&mb->data[1]));
+ *(__be32 *)(cf->data + 0) = cpu_to_be32(flexcan_read(&mb->data[0]));
+ *(__be32 *)(cf->data + 4) = cpu_to_be32(flexcan_read(&mb->data[1]));
/* mark as read */
- writel(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->iflag1);
- readl(®s->timer);
+ flexcan_write(FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->iflag1);
+ flexcan_read(®s->timer);
}
static int flexcan_read_frame(struct net_device *dev)
@@ -514,17 +539,17 @@ static int flexcan_poll(struct napi_struct *napi, int quota)
* The error bits are cleared on read,
* use saved value from irq handler.
*/
- reg_esr = readl(®s->esr) | priv->reg_esr;
+ reg_esr = flexcan_read(®s->esr) | priv->reg_esr;
/* handle state changes */
work_done += flexcan_poll_state(dev, reg_esr);
/* handle RX-FIFO */
- reg_iflag1 = readl(®s->iflag1);
+ reg_iflag1 = flexcan_read(®s->iflag1);
while (reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_AVAILABLE &&
work_done < quota) {
work_done += flexcan_read_frame(dev);
- reg_iflag1 = readl(®s->iflag1);
+ reg_iflag1 = flexcan_read(®s->iflag1);
}
/* report bus errors */
@@ -534,8 +559,8 @@ static int flexcan_poll(struct napi_struct *napi, int quota)
if (work_done < quota) {
napi_complete(napi);
/* enable IRQs */
- writel(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
- writel(priv->reg_ctrl_default, ®s->ctrl);
+ flexcan_write(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
+ flexcan_write(priv->reg_ctrl_default, ®s->ctrl);
}
return work_done;
@@ -549,9 +574,9 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg_iflag1, reg_esr;
- reg_iflag1 = readl(®s->iflag1);
- reg_esr = readl(®s->esr);
- writel(FLEXCAN_ESR_ERR_INT, ®s->esr); /* ACK err IRQ */
+ reg_iflag1 = flexcan_read(®s->iflag1);
+ reg_esr = flexcan_read(®s->esr);
+ flexcan_write(FLEXCAN_ESR_ERR_INT, ®s->esr); /* ACK err IRQ */
/*
* schedule NAPI in case of:
@@ -567,16 +592,16 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
* save them for later use.
*/
priv->reg_esr = reg_esr & FLEXCAN_ESR_ERR_BUS;
- writel(FLEXCAN_IFLAG_DEFAULT & ~FLEXCAN_IFLAG_RX_FIFO_AVAILABLE,
- ®s->imask1);
- writel(priv->reg_ctrl_default & ~FLEXCAN_CTRL_ERR_ALL,
+ flexcan_write(FLEXCAN_IFLAG_DEFAULT &
+ ~FLEXCAN_IFLAG_RX_FIFO_AVAILABLE, ®s->imask1);
+ flexcan_write(priv->reg_ctrl_default & ~FLEXCAN_CTRL_ERR_ALL,
®s->ctrl);
napi_schedule(&priv->napi);
}
/* FIFO overflow */
if (reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_OVERFLOW) {
- writel(FLEXCAN_IFLAG_RX_FIFO_OVERFLOW, ®s->iflag1);
+ flexcan_write(FLEXCAN_IFLAG_RX_FIFO_OVERFLOW, ®s->iflag1);
dev->stats.rx_over_errors++;
dev->stats.rx_errors++;
}
@@ -585,7 +610,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
if (reg_iflag1 & (1 << FLEXCAN_TX_BUF_ID)) {
/* tx_bytes is incremented in flexcan_start_xmit */
stats->tx_packets++;
- writel((1 << FLEXCAN_TX_BUF_ID), ®s->iflag1);
+ flexcan_write((1 << FLEXCAN_TX_BUF_ID), ®s->iflag1);
netif_wake_queue(dev);
}
@@ -599,7 +624,7 @@ static void flexcan_set_bittiming(struct net_device *dev)
struct flexcan_regs __iomem *regs = priv->base;
u32 reg;
- reg = readl(®s->ctrl);
+ reg = flexcan_read(®s->ctrl);
reg &= ~(FLEXCAN_CTRL_PRESDIV(0xff) |
FLEXCAN_CTRL_RJW(0x3) |
FLEXCAN_CTRL_PSEG1(0x7) |
@@ -623,11 +648,11 @@ static void flexcan_set_bittiming(struct net_device *dev)
reg |= FLEXCAN_CTRL_SMP;
dev_info(dev->dev.parent, "writing ctrl=0x%08x\n", reg);
- writel(reg, ®s->ctrl);
+ flexcan_write(reg, ®s->ctrl);
/* print chip status */
dev_dbg(dev->dev.parent, "%s: mcr=0x%08x ctrl=0x%08x\n", __func__,
- readl(®s->mcr), readl(®s->ctrl));
+ flexcan_read(®s->mcr), flexcan_read(®s->ctrl));
}
/*
@@ -648,10 +673,10 @@ static int flexcan_chip_start(struct net_device *dev)
flexcan_chip_enable(priv);
/* soft reset */
- writel(FLEXCAN_MCR_SOFTRST, ®s->mcr);
+ flexcan_write(FLEXCAN_MCR_SOFTRST, ®s->mcr);
udelay(10);
- reg_mcr = readl(®s->mcr);
+ reg_mcr = flexcan_read(®s->mcr);
if (reg_mcr & FLEXCAN_MCR_SOFTRST) {
dev_err(dev->dev.parent,
"Failed to softreset can module (mcr=0x%08x)\n",
@@ -673,12 +698,12 @@ static int flexcan_chip_start(struct net_device *dev)
* choose format C
*
*/
- reg_mcr = readl(®s->mcr);
+ reg_mcr = flexcan_read(®s->mcr);
reg_mcr |= FLEXCAN_MCR_FRZ | FLEXCAN_MCR_FEN | FLEXCAN_MCR_HALT |
FLEXCAN_MCR_SUPV | FLEXCAN_MCR_WRN_EN |
FLEXCAN_MCR_IDAM_C;
dev_dbg(dev->dev.parent, "%s: writing mcr=0x%08x", __func__, reg_mcr);
- writel(reg_mcr, ®s->mcr);
+ flexcan_write(reg_mcr, ®s->mcr);
/*
* CTRL
@@ -696,7 +721,7 @@ static int flexcan_chip_start(struct net_device *dev)
* (FLEXCAN_CTRL_ERR_MSK), too. Otherwise we don't get any
* warning or bus passive interrupts.
*/
- reg_ctrl = readl(®s->ctrl);
+ reg_ctrl = flexcan_read(®s->ctrl);
reg_ctrl &= ~FLEXCAN_CTRL_TSYN;
reg_ctrl |= FLEXCAN_CTRL_BOFF_REC | FLEXCAN_CTRL_LBUF |
FLEXCAN_CTRL_ERR_STATE | FLEXCAN_CTRL_ERR_MSK;
@@ -704,38 +729,39 @@ static int flexcan_chip_start(struct net_device *dev)
/* save for later use */
priv->reg_ctrl_default = reg_ctrl;
dev_dbg(dev->dev.parent, "%s: writing ctrl=0x%08x", __func__, reg_ctrl);
- writel(reg_ctrl, ®s->ctrl);
+ flexcan_write(reg_ctrl, ®s->ctrl);
for (i = 0; i < ARRAY_SIZE(regs->cantxfg); i++) {
- writel(0, ®s->cantxfg[i].can_ctrl);
- writel(0, ®s->cantxfg[i].can_id);
- writel(0, ®s->cantxfg[i].data[0]);
- writel(0, ®s->cantxfg[i].data[1]);
+ flexcan_write(0, ®s->cantxfg[i].can_ctrl);
+ flexcan_write(0, ®s->cantxfg[i].can_id);
+ flexcan_write(0, ®s->cantxfg[i].data[0]);
+ flexcan_write(0, ®s->cantxfg[i].data[1]);
/* put MB into rx queue */
- writel(FLEXCAN_MB_CNT_CODE(0x4), ®s->cantxfg[i].can_ctrl);
+ flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
+ ®s->cantxfg[i].can_ctrl);
}
/* acceptance mask/acceptance code (accept everything) */
- writel(0x0, ®s->rxgmask);
- writel(0x0, ®s->rx14mask);
- writel(0x0, ®s->rx15mask);
+ flexcan_write(0x0, ®s->rxgmask);
+ flexcan_write(0x0, ®s->rx14mask);
+ flexcan_write(0x0, ®s->rx15mask);
flexcan_transceiver_switch(priv, 1);
/* synchronize with the can bus */
- reg_mcr = readl(®s->mcr);
+ reg_mcr = flexcan_read(®s->mcr);
reg_mcr &= ~FLEXCAN_MCR_HALT;
- writel(reg_mcr, ®s->mcr);
+ flexcan_write(reg_mcr, ®s->mcr);
priv->can.state = CAN_STATE_ERROR_ACTIVE;
/* enable FIFO interrupts */
- writel(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
+ flexcan_write(FLEXCAN_IFLAG_DEFAULT, ®s->imask1);
/* print chip status */
dev_dbg(dev->dev.parent, "%s: reading mcr=0x%08x ctrl=0x%08x\n",
- __func__, readl(®s->mcr), readl(®s->ctrl));
+ __func__, flexcan_read(®s->mcr), flexcan_read(®s->ctrl));
return 0;
@@ -757,12 +783,12 @@ static void flexcan_chip_stop(struct net_device *dev)
u32 reg;
/* Disable all interrupts */
- writel(0, ®s->imask1);
+ flexcan_write(0, ®s->imask1);
/* Disable + halt module */
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg |= FLEXCAN_MCR_MDIS | FLEXCAN_MCR_HALT;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
flexcan_transceiver_switch(priv, 0);
priv->can.state = CAN_STATE_STOPPED;
@@ -854,24 +880,24 @@ static int __devinit register_flexcandev(struct net_device *dev)
/* select "bus clock", chip must be disabled */
flexcan_chip_disable(priv);
- reg = readl(®s->ctrl);
+ reg = flexcan_read(®s->ctrl);
reg |= FLEXCAN_CTRL_CLK_SRC;
- writel(reg, ®s->ctrl);
+ flexcan_write(reg, ®s->ctrl);
flexcan_chip_enable(priv);
/* set freeze, halt and activate FIFO, restrict register access */
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
reg |= FLEXCAN_MCR_FRZ | FLEXCAN_MCR_HALT |
FLEXCAN_MCR_FEN | FLEXCAN_MCR_SUPV;
- writel(reg, ®s->mcr);
+ flexcan_write(reg, ®s->mcr);
/*
* Currently we only support newer versions of this core
* featuring a RX FIFO. Older cores found on some Coldfire
* derivates are not yet supported.
*/
- reg = readl(®s->mcr);
+ reg = flexcan_read(®s->mcr);
if (!(reg & FLEXCAN_MCR_FEN)) {
dev_err(dev->dev.parent,
"Could not enable RX FIFO, unsupported core\n");
--
1.7.2.1
^ permalink raw reply related
* [PATCH v13 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Kumar Gala, Grant Likely, Marc Kleine-Budde, Scott Wood, PPC list,
Wolfgang Grandegger
In-Reply-To: <1313551944-28603-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
This patch cleans up the documentation of the device-tree binding for
the Flexcan devices on Freescale's PowerPC and ARM cores. Extra
properties are not used by the driver so we are removing them.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
---
.../devicetree/bindings/net/can/fsl-flexcan.txt | 61 ++++----------------
arch/powerpc/boot/dts/p1010rdb.dts | 10 +---
arch/powerpc/boot/dts/p1010si.dtsi | 10 +--
3 files changed, 17 insertions(+), 64 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 1a729f0..8dfb98b 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -1,61 +1,22 @@
-CAN Device Tree Bindings
-------------------------
-2011 Freescale Semiconductor, Inc.
+Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
-fsl,flexcan-v1.0 nodes
------------------------
-In addition to the required compatible-, reg- and interrupt-properties, you can
-also specify which clock source shall be used for the controller.
+Required properties:
-CPI Clock- Can Protocol Interface Clock
- This CLK_SRC bit of CTRL(control register) selects the clock source to
- the CAN Protocol Interface(CPI) to be either the peripheral clock
- (driven by the PLL) or the crystal oscillator clock. The selected clock
- is the one fed to the prescaler to generate the Serial Clock (Sclock).
- The PRESDIV field of CTRL(control register) controls a prescaler that
- generates the Serial Clock (Sclock), whose period defines the
- time quantum used to compose the CAN waveform.
+- compatible : Should be "fsl,<processor>-flexcan"
-Can Engine Clock Source
- There are two sources for CAN clock
- - Platform Clock It represents the bus clock
- - Oscillator Clock
+ An implementation should also claim any of the following compatibles
+ that it is fully backwards compatible with:
- Peripheral Clock (PLL)
- --------------
- |
- --------- -------------
- | |CPI Clock | Prescaler | Sclock
- | |---------------->| (1.. 256) |------------>
- --------- -------------
- | |
- -------------- ---------------------CLK_SRC
- Oscillator Clock
+ - fsl,p1010-flexcan
-- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
- the peripheral clock. PLL clock is fed to the
- prescaler to generate the Serial Clock (Sclock).
- Valid values are "oscillator" and "platform"
- "oscillator": CAN engine clock source is oscillator clock.
- "platform" The CAN engine clock source is the bus clock
- (platform clock).
+- reg : Offset and length of the register set for this device
+- interrupts : Interrupt tuple for this device
-- fsl,flexcan-clock-divider : for the reference and system clock, an additional
- clock divider can be specified.
-- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
+Example:
-Note:
- - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
- - P1010 does not have oscillator as the Clock Source.So the default
- Clock Source is platform clock.
-Examples:
-
- can0@1c000 {
- compatible = "fsl,flexcan-v1.0";
+ can@1c000 {
+ compatible = "fsl,p1010-flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
- fsl,flexcan-clock-source = "platform";
- fsl,flexcan-clock-divider = <2>;
- clock-frequency = <fixed by u-boot>;
};
diff --git a/arch/powerpc/boot/dts/p1010rdb.dts b/arch/powerpc/boot/dts/p1010rdb.dts
index 6b33b73..d6c669c 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dts
+++ b/arch/powerpc/boot/dts/p1010rdb.dts
@@ -23,6 +23,8 @@
ethernet2 = &enet2;
pci0 = &pci0;
pci1 = &pci1;
+ can0 = &can0;
+ can1 = &can1;
};
memory {
@@ -169,14 +171,6 @@
};
};
- can0@1c000 {
- fsl,flexcan-clock-source = "platform";
- };
-
- can1@1d000 {
- fsl,flexcan-clock-source = "platform";
- };
-
usb@22000 {
phy_type = "utmi";
};
diff --git a/arch/powerpc/boot/dts/p1010si.dtsi b/arch/powerpc/boot/dts/p1010si.dtsi
index 7f51104..cabe0a4 100644
--- a/arch/powerpc/boot/dts/p1010si.dtsi
+++ b/arch/powerpc/boot/dts/p1010si.dtsi
@@ -140,20 +140,18 @@
interrupt-parent = <&mpic>;
};
- can0@1c000 {
- compatible = "fsl,flexcan-v1.0";
+ can0: can@1c000 {
+ compatible = "fsl,p1010-flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
- fsl,flexcan-clock-divider = <2>;
};
- can1@1d000 {
- compatible = "fsl,flexcan-v1.0";
+ can1: can@1d000 {
+ compatible = "fsl,p1010-flexcan";
reg = <0x1d000 0x1000>;
interrupts = <61 0x2>;
interrupt-parent = <&mpic>;
- fsl,flexcan-clock-divider = <2>;
};
L2: l2-cache-controller@20000 {
--
1.7.2.1
^ permalink raw reply related
* [PATCH v13 4/6] flexcan: Add of_match to platform_device definition.
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, U Bhaskar-B22300,
Grant Likely, Marc Kleine-Budde, PPC list, Wolfgang Grandegger
In-Reply-To: <1313551944-28603-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
On powerpc, the OpenFirmware devices are not matched without specifying
an of_match array. Introduce that array as that is used for matching
on the Freescale P1010 processor.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
---
drivers/net/can/flexcan.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 68cbe52..cc1e0a7 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -1027,8 +1027,19 @@ static int __devexit flexcan_remove(struct platform_device *pdev)
return 0;
}
+static struct of_device_id flexcan_of_match[] = {
+ {
+ .compatible = "fsl,p1010-flexcan",
+ },
+ {},
+};
+
static struct platform_driver flexcan_driver = {
- .driver.name = DRV_NAME,
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = flexcan_of_match,
+ },
.probe = flexcan_probe,
.remove = __devexit_p(flexcan_remove),
};
--
1.7.2.1
^ permalink raw reply related
* [PATCH v13 6/6] flexcan: Add flexcan device support for p1010rdb.
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, Kumar Gala,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
PPC list, Wolfgang Grandegger
In-Reply-To: <1313551944-28603-1-git-send-email-holt-sJ/iWh9BUns@public.gmane.org>
Allow the p1010 processor to select the flexcan network driver.
Signed-off-by: Robin Holt <holt-sJ/iWh9BUns@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
Cc: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Cc: PPC list <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Cc: Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
---
arch/powerpc/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6926b61..47682b6 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -656,6 +656,8 @@ config SBUS
config FSL_SOC
bool
+ select HAVE_CAN_FLEXCAN if NET && CAN
+ select PPC_CLOCK if CAN_FLEXCAN
config FSL_PCI
bool
--
1.7.2.1
^ permalink raw reply related
* [PATCH v13 5/6] flexcan: Prefer device tree clock frequency if available.
From: Robin Holt @ 2011-08-17 3:32 UTC (permalink / raw)
To: Robin Holt, David S. Miller, Kumar Gala, Wolfgang Grandegger,
Marc Kleine-Budde
Cc: Robin Holt, Wolfgang Grandegger, Kumar Gala, Marc Kleine-Budde,
U Bhaskar-B22300, Scott Wood, Grant Likely, socketcan-core,
netdev, PPC list, devicetree-discuss
In-Reply-To: <1313551944-28603-1-git-send-email-holt@sgi.com>
If our CAN device's device tree node has a clock-frequency property,
then use that value for the can devices clock frequency. If not, fall
back to asking the platform/mach code for the clock frequency associated
with the flexcan device.
Signed-off-by: Robin Holt <holt@sgi.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>,
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
Cc: U Bhaskar-B22300 <B22300@freescale.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: socketcan-core@lists.berlios.de,
Cc: netdev@vger.kernel.org,
Cc: PPC list <linuxppc-dev@lists.ozlabs.org>
Cc: devicetree-discuss@lists.ozlabs.org
---
.../devicetree/bindings/net/can/fsl-flexcan.txt | 2 +
drivers/net/can/flexcan.c | 34 ++++++++++++++-----
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 8dfb98b..1ad80d5 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -11,6 +11,7 @@ Required properties:
- reg : Offset and length of the register set for this device
- interrupts : Interrupt tuple for this device
+- clock-frequency : The oscillator frequency driving the flexcan device
Example:
@@ -19,4 +20,5 @@ Example:
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
+ clock-frequency = <200000000>; // filled in by bootloader
};
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index cc1e0a7..e023379 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -33,6 +33,7 @@
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#define DRV_NAME "flexcan"
@@ -925,16 +926,29 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
struct net_device *dev;
struct flexcan_priv *priv;
struct resource *mem;
- struct clk *clk;
+ struct clk *clk = NULL;
void __iomem *base;
resource_size_t mem_size;
int err, irq;
+ u32 clock_freq = 0;
+
+ if (pdev->dev.of_node) {
+ const u32 *clock_freq_p;
- clk = clk_get(&pdev->dev, NULL);
- if (IS_ERR(clk)) {
- dev_err(&pdev->dev, "no clock defined\n");
- err = PTR_ERR(clk);
- goto failed_clock;
+ clock_freq_p = of_get_property(pdev->dev.of_node,
+ "clock-frequency", NULL);
+ if (clock_freq_p)
+ clock_freq = *clock_freq_p;
+ }
+
+ if (!clock_freq) {
+ clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "no clock defined\n");
+ err = PTR_ERR(clk);
+ goto failed_clock;
+ }
+ clock_freq = clk_get_rate(clk);
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -967,7 +981,7 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
dev->flags |= IFF_ECHO; /* we support local echo in hardware */
priv = netdev_priv(dev);
- priv->can.clock.freq = clk_get_rate(clk);
+ priv->can.clock.freq = clock_freq;
priv->can.bittiming_const = &flexcan_bittiming_const;
priv->can.do_set_mode = flexcan_set_mode;
priv->can.do_get_berr_counter = flexcan_get_berr_counter;
@@ -1002,7 +1016,8 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
failed_map:
release_mem_region(mem->start, mem_size);
failed_get:
- clk_put(clk);
+ if (clk)
+ clk_put(clk);
failed_clock:
return err;
}
@@ -1020,7 +1035,8 @@ static int __devexit flexcan_remove(struct platform_device *pdev)
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(mem->start, resource_size(mem));
- clk_put(priv->clk);
+ if (priv->clk)
+ clk_put(priv->clk);
free_candev(dev);
--
1.7.2.1
^ permalink raw reply related
* PROTECTED PROJECT
From: Mr. Vincent Cheng @ 2011-08-17 4:44 UTC (permalink / raw)
I am Mr. Vincent Cheng, GBS, JP Chairman of the Hong Kong and Shanghai
Banking Corporation Limited.
i have a business proposal of Twenty Two million Five Hundred Thousand
United State Dollars only for you to
transact with me from my bank to your country.Having gone through a
methodical search, I decided to contact you hoping
that you will find this proposal interesting. Please on your
confirmation of this message and indicating your interest
All confirmable documents to back up the claims will be made available
to you prior to your acceptance
and as soon as I receive your return mail Via my email
address:vincent.cheng@qatar.io and I will let
you know what is required of you,your earliest response to this letter
will be appreciated.
Endeavor to let me know your decision rather than keep me waiting
Best Regards,
Mr. Vincent Cheng
^ permalink raw reply
* IXGBE driver indicates "not enough MMIO resources for SR-IOV"
From: J.Hwan Kim @ 2011-08-17 5:38 UTC (permalink / raw)
To: netdev
Hi, everyone
When I set SR-IOV function in driver base on intel ixgbe,
the driver shows error message "not enough MMIO resources for SR-IOV".
My cpu is XEON E5450.
I set Intel Virutualization Technology option enable in BIOS.
How can I fix this problem?
Thanks in advance
Best Regards,
J.Hwan Kim
^ permalink raw reply
* Re: [Bugme-new] [Bug 41152] New: kernel 3.0 and above fails to handle vlan id 0 (802.1p) packets properly without hardware acceleration
From: Jiri Pirko @ 2011-08-17 5:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugme-daemon, netdev, mike.auty
In-Reply-To: <20110816150918.5b2d7067.akpm@linux-foundation.org>
Wed, Aug 17, 2011 at 12:09:18AM CEST, akpm@linux-foundation.org wrote:
>
>(switched to email. Please respond via emailed reply-to-all, not via the
>bugzilla web interface).
>
>On Sun, 14 Aug 2011 12:48:16 GMT
>bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=41152
>>
>> Summary: kernel 3.0 and above fails to handle vlan id 0
>> (802.1p) packets properly without hardware
>> acceleration
>> Product: Networking
>> Version: 2.5
>> Kernel Version: 3.0
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Other
>> AssignedTo: acme@ghostprotocols.net
>> ReportedBy: mike.auty@gmail.com
>> Regression: Yes
>>
>>
>> Hi there,
>>
>> I recently found that packets tagged with a vlan id of 0 are no longer received
>> on the main interface. There were no dmesg entries on the dropped packets. I
>> attempted to setup a vlan 0 interface and configure it, but couldn't
>> successfully route traffic to the device. I can recreate this on two of the
>> three networking devices I have, my guess is that the third does successfully
>> handle hardware acceleration of vlan tags.
>>
>> After a bisection this appears to be related to commit
>> bcc6d47903612c3861201cc3a866fb604f26b8b2, which seems to try to merge the
>> non-hardware accelerated and hardware accelerated code paths for handling
>> vlans. In the process, it appears vlan id 0 (802.1p) packets are no longer
>> handled correctly.
>>
>> Unfortunately I don't know the code paths well enough to figure out what's
>> going wrong, but I'd be happy to provide more information, run tests or try out
>> patches if it would help, just let me know. Thanks... 5:)
>>
>> Mike 5:)
Hi Mike. May I ask what NIC are you seeing the regression on?
It may have something to do with dev->vlangrp and ndo_vlan_add/kill_vid.
VID 0 was recently only added by the latter ones. So if driver only
depended on dev->vlangrp, 0 was not there. This was changed recently by
my "vlan cleanup" patches. It may work for you again on net-next today.
Jirka
>
^ permalink raw reply
* Re: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: John Fastabend @ 2011-08-17 5:47 UTC (permalink / raw)
To: Rasesh Mody
Cc: Ben Hutchings, davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86A94D9953ED@HQ1-EXCH01.corp.brocade.com>
On 8/16/2011 7:14 PM, Rasesh Mody wrote:
>> From: John Fastabend [mailto:john.r.fastabend@intel.com]
>> Sent: Tuesday, August 16, 2011 5:18 PM
>>
>> On 8/16/2011 4:43 PM, Ben Hutchings wrote:
>>> On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
>>>>> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>>>>> Sent: Tuesday, August 16, 2011 2:49 PM
>>>>>
>>>>> On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>>>>>> Change details:
>>>>>> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
>>>>>> bna_is_iscsi_over_cee
>>>>>> - Added support for multipe Tx queues with a separate iSCSI Tx
>> queue
>>>>> based
>>>>>> on the default value of iSCSI port number. The feature is
>> supported
>>>>> based
>>>>>> on the underlying hardware and enabled for DCB (CEE) mode only.
>>>>>> - Allocate multiple TxQ resource in netdev
>>>>>> - Implement bnad_tx_select_queue() which enables the correct
>>>>> selection of
>>>>>> TxQ Id (and tcb). This function is called either by the kernel
>> to
>>>>> channel
>>>>>> packets to the right TxQ
>>>>>> - bnad_tx_select_queue() returns priority, while only a few
>> packets
>>>>> during
>>>>>> transition could have wrong priority, all will be associated
>> with a
>>>>> valid
>>>>>> non-NULL tcb.
>>>>>> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
>>>>> packet
>>>>>> inspection and retrieval of tcb corresponding to the iSCSI
>>>>> priority.
>>>>>> - Construction of priority indirection table to be used by bnad to
>>>>> direct
>>>>>> packets into TxQs
>>>>> [...]
>>>>>
>>>>> You probably should implement TX priority classes through the
>>>>> ndo_setup_tc operation, not ndo_select_queue.
>>>>
>>>> The reason we went with ndo_select_queue is due to the need for
>> mapping
>>>> iSCSI packets (TCP port 3260) to a priority derived from DCB
>> configuration.
>>>> Here the iSCSI packets may not have any tc defined in the packet
>> header.
>>>
>>> There is an skb priority, which is derived from the socket priority
>>> option (SO_PRIORITY). If you implement ndo_setup_tc then the
>> networking
>>> core will take care of mapping the skb priority onto a different queue
>>> (or range of queues).
>>>
>>> I don't know whether the socket priority option is easily configurable
>>> for the existing iSCSI implementations. But looking at port numbers
>>> really doesn't seem like the right way to do this.
>>>
>>> Ben.
>>>
>>
>> At least open-iscsi supports DCB by listening to the RTNLGRP_DCB for
>> events.
>> These are generated with dcbnl_cee_notify and dcbnl_ieee_notify. To
>> support
>> this in your driver you need to call dcb_setapp() or dcb_ieee_setapp()
>> to
>> add the application data and follow this with the appropriate notify
>> call.
>> Then assuming you do the necessary tc setup work the stack will handle
>> the
>> mapping of priority to queues.
>
> This is how iSCSI over DCB feature is expected to works in BNA driver:-
> FW running in the BNA adapter implements the DCB protocol. It learns the
> iSCSI priority from the switch through iSCSI TLV exchange. BNA driver
> extracts the iSCSI priority from the FW that needs to be used for iSCSI
> packets.
Up to here this is fine. What I was suggesting was to then use the
dcb_setapp() routines to program the iSCSI TLV and generate an event
so any user space applications listening to DCB events could handle
this. It would also be nice if your driver notified user space of
any PG or PFC changes as well. Then management agents (lldpad) could
use the DCB attributes to make policy decisions.
> For every outgoing packet, BNA driver does a TCP header
> inspection to classify iSCSI packet and attach right 802.1q priority &
> send it on the correct TX queue.
>
> This is expected to work with iSCSI applications that do not configure the
> priority with SO_PRIORITY - here the iSCSI priority configuration actually
> comes from the switch to the adapter.
>
Although this works I don't think it is optimal for a few reason. Your
L2 driver is inspecting TCP frames which is bad layering IMHO. The
iSCSI port number is hard coded into the driver so it will only work
with the well known port number. Also it adds more driver specific
behavior into select_queue() where I think the trend is to try to
use select_queue() less not more.
To address iSCSI applications that do not configure the priority
we could either work on adding the DCB hooks needed in those
applications. Or look at adding a hook in the qdisc layer to
to do what your select_queue() hook does here. I started prototyping
this awhile ago but this requires running the packet classifiers
and associated actions before picking a queue assuming you want
to use mq or mqprio. I hope to get back to this soon I have some
more details to flush out wrt this and need to run it by some other
folks to make sure its a sane idea.
> The goal of this iSCSI priority is:
> a) adapter applies prioritized scheduling for packets in its egress - to
> guarantee minimum bandwidth as per ETS
> b) packets are tagged with right priority so that switch can also identify
> and guarantee BW on its egress.
Correct. This is the same for other drivers that support DCB and
use tc_setup as Ben suggested. See the bnx2x driver for an example
that also uses a FW based LLDP engine and does this.
>
> Hope this explains.
I think the one valid item is the unsupported applications but
hopefully that can be addressed. Thanks for the details.
John.
>
> Thanks,
> Rasesh
^ permalink raw reply
* Re: [Bugme-new] [Bug 41152] New: kernel 3.0 and above fails to handle vlan id 0 (802.1p) packets properly without hardware acceleration
From: Mike Auty @ 2011-08-17 6:36 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <20110817053737.GA1936@minipsycho>
On 17/08/11 06:37, Jiri Pirko wrote:
>
> Hi Mike. May I ask what NIC are you seeing the regression on?
> It may have something to do with dev->vlangrp and ndo_vlan_add/kill_vid.
> VID 0 was recently only added by the latter ones. So if driver only
> depended on dev->vlangrp, 0 was not there. This was changed recently by
> my "vlan cleanup" patches. It may work for you again on net-next today.
>
Hi there,
I'm finding it on the following two NICs:
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
Ethernet Adapter (rev b0)
05:01.0 Network controller [0280]: Broadcom Corporation BCM4306
802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
and (on a different machine):
02:00.0 Network controller [0280]: Intel Corporation WiFi Link 6000
Series [8086:422c] (rev 35)
The only one I have had any success with is:
00:19.0 Ethernet controller [0200]: Intel Corporation 82577LM Gigabit
Network Connection [8086:10ea] (rev 05)
Which I assume is because it has actual hardware acceleration. I may be
able to put net-next on the Intel Wifi box for testing at some point,
but I don't know how soon I'll be able to do that. Please let me know
whether that would be a worthwhile test, and if so I'll try and get it
done. Thanks...
Mike 5:)
^ permalink raw reply
* Re: Influencing triggering of xfrm acquire messages?
From: David Martin @ 2011-08-17 10:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110811.073645.142128983331087817.davem@davemloft.net>
Hi,
On Thu, Aug 11, 2011 at 4:36 PM, David Miller <davem@davemloft.net> wrote:
> From: David Martin <david.martin.mailbox@googlemail.com>
> Date: Thu, 11 Aug 2011 16:21:07 +0200
>
>> As long as it exists no additional acquire will be triggered which is a problem,
>> for example when shortly after an exchange the daemon is restarted and needs to
>> start another exchange with the same peer host.
>>
>> Is this state supposed to be set up? Is it supposed to be removed automatically
>> once we set up our own SA? Is there a way to remove it manually to
>> trigger another acquire? Any input is welcome, thanks a lot in advance.
>
> The usage model is that the IPSEC daemon, like a routing daemon, manages
> all IPSEC state. And therefore it flushes all IPSEC state when it starts
> up.
>
> If you want the acquire messages, you need to flush the entries for which
> you want the acquire to trigger when you startup.
thanks for your reply, that sounds reasonable. The problem is this
specific state I
mentioned (see below).
> martin@pisa1:~$ sudo ip xfrm state
> src 2001:1a:a148:104c:92bb:671e:8100:9354 dst 2001:1c:5000:45b6:2d33:2c10:2726:a043
> proto 0 reqid 0 mode transport
> replay-window 0
> sel src 2001:1a:a148:104c:92bb:671e:8100:9354/128 dst 2001:1c:5000:45b6:2d33:2c10:2726:a043/128 proto udp sport 49024 dport 1025
It is not set up explicitly by us but on its own when the acquire is triggered.
We already take care of "our" states and flush them on exit / startup so that
they do not prohibit another acquire. This one though remains for a certain
time and the question is: how can I remove it? Which parameters do I need
to pass to the xfrm interface to flush it?
It does not seem to be possible with the iproute2 implementation
('ip xfrm state delete ...') as it requires a protocol in
{esp | ah | comp | route2 | hao} to delete a state. proto 0 as it is here is not
supported and refused as invalid. I have tried to adapt our code and send
a delete request with protocol, spi and ports set to 0 but this does not have
the desired effect.
Any idea how to tackle this?
David
^ permalink raw reply
* Re: [Bugme-new] [Bug 41152] New: kernel 3.0 and above fails to handle vlan id 0 (802.1p) packets properly without hardware acceleration
From: Jiri Pirko @ 2011-08-17 10:59 UTC (permalink / raw)
To: Mike Auty; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <4E4B615F.8060403@gmail.com>
Wed, Aug 17, 2011 at 08:36:15AM CEST, mike.auty@gmail.com wrote:
>On 17/08/11 06:37, Jiri Pirko wrote:
>>
>> Hi Mike. May I ask what NIC are you seeing the regression on?
>> It may have something to do with dev->vlangrp and ndo_vlan_add/kill_vid.
>> VID 0 was recently only added by the latter ones. So if driver only
>> depended on dev->vlangrp, 0 was not there. This was changed recently by
>> my "vlan cleanup" patches. It may work for you again on net-next today.
>>
>
>Hi there,
>
>I'm finding it on the following two NICs:
>
>02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
>Ethernet Adapter (rev b0)
>
>05:01.0 Network controller [0280]: Broadcom Corporation BCM4306
>802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
>
>and (on a different machine):
>
>02:00.0 Network controller [0280]: Intel Corporation WiFi Link 6000
>Series [8086:422c] (rev 35)
I just obtained very similar card (8086:422b). Going to look at it right
away.
One more thing. What do you use to generate vlan0 tagged packets? I'm
using pktgen with "vlan_id 0". Would you please try that it behaves the
same for you?
>
>The only one I have had any success with is:
>
>00:19.0 Ethernet controller [0200]: Intel Corporation 82577LM Gigabit
>Network Connection [8086:10ea] (rev 05)
>
>Which I assume is because it has actual hardware acceleration. I may be
>able to put net-next on the Intel Wifi box for testing at some point,
>but I don't know how soon I'll be able to do that. Please let me know
>whether that would be a worthwhile test, and if so I'll try and get it
>done. Thanks...
>
>Mike 5:)
>
^ permalink raw reply
* Re: [net-next RFC PATCH 7/7] virtio-net changes
From: WANG Cong @ 2011-08-17 13:24 UTC (permalink / raw)
To: netdev; +Cc: qemu-devel, linux-kernel, kvm
In-Reply-To: <20110812015551.31613.13885.stgit@intel-e5620-16-2.englab.nay.redhat.com>
On Fri, 12 Aug 2011 09:55:51 +0800, Jason Wang wrote:
> From: Krishna Kumar <krkumar2@in.ibm.com>
>
> Implement mq virtio-net driver.
>
> Though struct virtio_net_config changes, it works with the old qemu
> since the last element is not accessed unless qemu sets
> VIRTIO_NET_F_MULTIQUEUE.
>
...
> +
> +#if 1
<...>
> +#else
<...>
> +#endif
Any reason to keep this #else code of #if 1? which is dead.
^ permalink raw reply
* Re: [PATCH V2 net-next 1/3] bnx2x: Remove local defines for %pM and mac address
From: Eilon Greenstein @ 2011-08-17 13:42 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <194d8f8008a965d68812738f7530e07856952d3a.1313360100.git.joe@perches.com>
On Sun, 2011-08-14 at 15:16 -0700, Joe Perches wrote:
> Use %pM and mac address directly instead.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Eilon Greenstein <eilong@broadcom.com>
^ permalink raw reply
* Re: [PATCH V2 net-next 0/3] bnx2x: Message logging cleanups
From: Eilon Greenstein @ 2011-08-17 13:42 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <cover.1313360100.git.joe@perches.com>
On Sun, 2011-08-14 at 15:16 -0700, Joe Perches wrote:
> Joe Perches (3):
> bnx2x: Remove local defines for %pM and mac address
> bnx2x: Coalesce pr_cont uses and fix DP typos
> bnx2x: Use pr_fmt and message logging cleanups
>
> drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 67 ++++-----
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 48 ++++---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 4 +-
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c | 5 +-
> .../net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 23 ++--
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 153 ++++++++++----------
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 72 ++++-----
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 67 ++++-----
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c | 46 +++---
> 9 files changed, 244 insertions(+), 241 deletions(-)
>
Thanks Joe, sorry it took a while - but ACK for all :)
Eilon
^ permalink raw reply
* Re: [PATCH V2 net-next 2/3] bnx2x: Coalesce pr_cont uses and fix DP typos
From: Eilon Greenstein @ 2011-08-17 13:42 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <88e0b7cd0aa9fdb34acae665d8bc235f8aa33ddf.1313360100.git.joe@perches.com>
On Sun, 2011-08-14 at 15:16 -0700, Joe Perches wrote:
> Uses of pr_cont should be avoided where reasonably possible
> because they can be interleaved by other threads and processes.
>
> Coalesce pr_cont uses.
>
> Fix typos, duplicated words and spacing in DP uses caused
> by split multi-line formats. Coalesce some of these
> split formats. Add missing terminating newlines to DP uses.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Eilon Greenstein <eilong@broadcom.com>
^ permalink raw reply
* Re: [PATCH V2 net-next 3/3] bnx2x: Use pr_fmt and message logging cleanups
From: Eilon Greenstein @ 2011-08-17 13:42 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <2d33739418a06602c817d002b30fedd57cbe5f11.1313360101.git.joe@perches.com>
On Sun, 2011-08-14 at 15:16 -0700, Joe Perches wrote:
> Add pr_fmt(fmt) KBUILD_MODNAME ": " to prefix messages with "bnx2x: ".
> Remove #define DP_LEVEL and use pr_notice.
> Repeating KERN_<LEVEL> isn't necessary in multi-line printks.
> printk macro neatening, use fmt and ##__VA_ARGS__.
> Coalesce long formats.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Eilon Greenstein <eilong@broadcom.com>
^ permalink raw reply
* Re: [PATCH 0/2] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods (v3)
From: Ben Hutchings @ 2011-08-17 15:07 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev
In-Reply-To: <1311696338-4739-1-git-send-email-nhorman@tuxdriver.com>
On Tue, 2011-07-26 at 12:05 -0400, Neil Horman wrote:
> Ok, after considering all your comments, Dave suggested this as an alternate
> approach:
>
> 1) We create a new priv_flag, IFF_SKB_TX_SHARED, to identify drivers capable of
> handling shared skbs. Default is to not set this flag
>
> 2) Modify ether_setup to enable this flag, under the assumption that any driver
> calling this function is initalizing a real ethernet device and as such can
> handle shared skbs since they don't tend to store state in the skb struct.
> Pktgen can then query this flag when a user script attempts to issue the
> clone_skb command and decide if it is to be alowed or not.
[...]
A bunch of Ethernet drivers do skb_pad() or skb_padto() in their
ndo_start_xmit implementations, either to avoid hardware bugs or because
the MAC doesn't automatically pad to the minimum frame length. This
presumably means they can't generally handle shared skbs, though in the
specific case of pktgen it should be safe as long as a single skb is not
submitted by multiple threads at once.
Ben.
--
Ben Hutchings, Staff 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] bnx2x: downgrade Max BW error message to debug
From: Michal Schmidt @ 2011-08-17 15:50 UTC (permalink / raw)
To: eilong; +Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <1313498708.24298.0.camel@lb-tlvb-eilong.il.broadcom.com>
There are valid configurations where Max BW is configured to zero for
some VNs.
Print the message only if debugging is enabled and do not call the
configuration "illegal".
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
index 223bfee..8245e02 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
@@ -1481,8 +1481,7 @@ static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, u32 mf_cfg)
u16 max_cfg = (mf_cfg & FUNC_MF_CFG_MAX_BW_MASK) >>
FUNC_MF_CFG_MAX_BW_SHIFT;
if (!max_cfg) {
- BNX2X_ERR("Illegal configuration detected for Max BW - "
- "using 100 instead\n");
+ BNX2X_DBG_ERR("Max BW configured to 0 - using 100 instead\n");
max_cfg = 100;
}
return max_cfg;
--
1.7.6
^ permalink raw reply related
* Linux vs FreeBSD Which is correct.
From: Stephen Clark @ 2011-08-17 17:03 UTC (permalink / raw)
To: Linux Kernel Network Developers
Hello List,
Firstly thank you for your patience. I am replacing a bunch of FreeBSD
vpn/fw/routers
with a Linux based system.
I have run into a situation where if I ping our HQ the response comes
back on a different
interface than what the request went out on. FreeBSD is happy and says
it got the response,
Linux is not and gives no indication it got a response.
So is FreeBSD wrong or is Linux wrong?
Or is there some sysctl I can fiddle with on Linux to make it see the
response. This happens
with the iptables set to accept on all chains.
Thanks again for your indulgence. I googled this and didn't find
anything germane.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: Linux vs FreeBSD Which is correct.
From: Emil S Tantilov @ 2011-08-17 17:10 UTC (permalink / raw)
To: sclark46; +Cc: Linux Kernel Network Developers
In-Reply-To: <4E4BF456.9000807@earthlink.net>
On Wed, Aug 17, 2011 at 10:03 AM, Stephen Clark <sclark46@earthlink.net> wrote:
> Hello List,
>
> Firstly thank you for your patience. I am replacing a bunch of FreeBSD
> vpn/fw/routers
> with a Linux based system.
>
> I have run into a situation where if I ping our HQ the response comes back
> on a different
> interface than what the request went out on. FreeBSD is happy and says it
> got the response,
> Linux is not and gives no indication it got a response.
Try enabling ARP filtering:
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
Thanks,
Emil
^ permalink raw reply
* Re: Linux vs FreeBSD Which is correct.
From: Rémi Denis-Courmont @ 2011-08-17 17:17 UTC (permalink / raw)
To: sclark46; +Cc: Linux Kernel Network Developers
In-Reply-To: <4E4BF456.9000807@earthlink.net>
Le mercredi 17 août 2011 20:03:18 Stephen Clark, vous avez écrit :
> I have run into a situation where if I ping our HQ the response comes
> back on a different
> interface than what the request went out on. FreeBSD is happy and says
> it got the response,
> Linux is not and gives no indication it got a response.
>
> So is FreeBSD wrong or is Linux wrong?
Most distributions enable reverse path filtering by default.
It can be disabled:
# echo -n 0 > /proc/sys/net/ipv4/conf/all/rp_filter
But you should probably fix the configuration instead (e.g. /etc/sysctl.conf).
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: [PATCH] bnx2x: downgrade Max BW error message to debug
From: Eilon Greenstein @ 2011-08-17 17:44 UTC (permalink / raw)
To: Michal Schmidt
Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <20110817175037.2777724a@brian.englab.brq.redhat.com>
On Wed, 2011-08-17 at 08:50 -0700, Michal Schmidt wrote:
> There are valid configurations where Max BW is configured to zero for
> some VNs.
> Print the message only if debugging is enabled and do not call the
> configuration "illegal".
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
>
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
> index 223bfee..8245e02 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
> @@ -1481,8 +1481,7 @@ static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, u32 mf_cfg)
> u16 max_cfg = (mf_cfg & FUNC_MF_CFG_MAX_BW_MASK) >>
> FUNC_MF_CFG_MAX_BW_SHIFT;
> if (!max_cfg) {
> - BNX2X_ERR("Illegal configuration detected for Max BW - "
> - "using 100 instead\n");
> + BNX2X_DBG_ERR("Max BW configured to 0 - using 100 instead\n");
I think that we should use DP instead of DBG_ERR. How about this one:
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
index 223bfee..70dc7bc 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
@@ -1481,8 +1481,7 @@ static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, u32 mf_cfg)
u16 max_cfg = (mf_cfg & FUNC_MF_CFG_MAX_BW_MASK) >>
FUNC_MF_CFG_MAX_BW_SHIFT;
if (!max_cfg) {
- BNX2X_ERR("Illegal configuration detected for Max BW - "
- "using 100 instead\n");
+ DP(NETIF_MSG_LINK, "Max BW configured to 0 - using 100 instead\n");
max_cfg = 100;
}
return max_cfg;
Can you sing-off on somethign like this?
Thanks,
Eilon
^ permalink raw reply related
* Re: [Bugme-new] [Bug 41152] New: kernel 3.0 and above fails to handle vlan id 0 (802.1p) packets properly without hardware acceleration
From: Jiri Pirko @ 2011-08-17 17:50 UTC (permalink / raw)
To: Mike Auty; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <20110817105950.GA4259@minipsycho.brq.redhat.com>
Wed, Aug 17, 2011 at 12:59:51PM CEST, jpirko@redhat.com wrote:
>Wed, Aug 17, 2011 at 08:36:15AM CEST, mike.auty@gmail.com wrote:
>>On 17/08/11 06:37, Jiri Pirko wrote:
>>>
>>> Hi Mike. May I ask what NIC are you seeing the regression on?
>>> It may have something to do with dev->vlangrp and ndo_vlan_add/kill_vid.
>>> VID 0 was recently only added by the latter ones. So if driver only
>>> depended on dev->vlangrp, 0 was not there. This was changed recently by
>>> my "vlan cleanup" patches. It may work for you again on net-next today.
>>>
>>
>>Hi there,
>>
>>I'm finding it on the following two NICs:
>>
>>02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
>>Ethernet Adapter (rev b0)
>>
>>05:01.0 Network controller [0280]: Broadcom Corporation BCM4306
>>802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
>>
>>and (on a different machine):
>>
>>02:00.0 Network controller [0280]: Intel Corporation WiFi Link 6000
>>Series [8086:422c] (rev 35)
>
>I just obtained very similar card (8086:422b). Going to look at it right
>away.
>
>One more thing. What do you use to generate vlan0 tagged packets? I'm
>using pktgen with "vlan_id 0". Would you please try that it behaves the
>same for you?
I'm using following pktgen script:
http://pastebin.com/E3f4R8XY
On rx site with Intel wireless card I use following stap script to
observe incoming packets:
http://pastebin.com/VeXLhauu
All is looking good there. What do you use to look at incoming packets?
Jirka
>
>>
>>The only one I have had any success with is:
>>
>>00:19.0 Ethernet controller [0200]: Intel Corporation 82577LM Gigabit
>>Network Connection [8086:10ea] (rev 05)
>>
>>Which I assume is because it has actual hardware acceleration. I may be
>>able to put net-next on the Intel Wifi box for testing at some point,
>>but I don't know how soon I'll be able to do that. Please let me know
>>whether that would be a worthwhile test, and if so I'll try and get it
>>done. Thanks...
>>
>>Mike 5:)
>>
^ 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