* [PATCH v11 3/6] flexcan: Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-11 16:07 UTC (permalink / raw)
To: Robin Holt, Kumar Gala, Wolfgang Grandegger, Marc Kleine-Budde,
U Bhaskar-B22300
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, PPC list
In-Reply-To: <1313078831-2511-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>
To: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
To: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>,
To: U Bhaskar-B22300 <B22300-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
To: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: 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 | 69 ++++---------------
arch/powerpc/boot/dts/p1010rdb.dts | 10 +--
arch/powerpc/boot/dts/p1010si.dtsi | 10 +--
3 files changed, 21 insertions(+), 68 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 1a729f0..c78dcbb 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 processors
-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" and "fsl,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";
- 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>;
- };
+ can@1c000 {
+ compatible = "fsl,p1010-flexcan", "fsl,flexcan";
+ reg = <0x1c000 0x1000>;
+ interrupts = <48 0x2>;
+ interrupt-parent = <&mpic>;
+ };
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..f00076b 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", "fsl,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", "fsl,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 v11 2/6] flexcan: Abstract off read/write for big/little endian.
From: Robin Holt @ 2011-08-11 16:07 UTC (permalink / raw)
To: Robin Holt, Kumar Gala, Wolfgang Grandegger, Marc Kleine-Budde,
U Bhaskar-B22300
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
PPC list, Wolfgang Grandegger
In-Reply-To: <1313078831-2511-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 v11 1/6] flexcan: Remove #include <mach/clock.h>
From: Robin Holt @ 2011-08-11 16:07 UTC (permalink / raw)
To: Robin Holt, Kumar Gala, Wolfgang Grandegger, Marc Kleine-Budde,
U Bhaskar-B22300
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Marc Kleine-Budde,
PPC list, Wolfgang Grandegger
In-Reply-To: <1313078831-2511-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 v12 0/6] flexcan/powerpc: Add support for powerpc flexcan (freescale p1010)
From: Robin Holt @ 2011-08-11 16:07 UTC (permalink / raw)
To: Robin Holt, Kumar Gala, Wolfgang Grandegger, Marc Kleine-Budde,
U Bhaskar-B22300
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, PPC list, Marc Kleine-Budde
With all the patches applied, my p1010rdb works for communicating between
its two can ports and also can communicate with an external PSOC.
I have done no testing beyond compile testing for an arm system as I
have no access to an arm based system.
With the latest version, changes to the arch tree really only reflect
changes in the drivers/net/can tree. I, therefore, believe it is
probably best to route them through David S. Miller's netdev tree.
Wolfgang and Kumar, does that seem correct to you?
Thanks,
Robin Holt
^ permalink raw reply
* Re: Bridge stays down until a port is added
From: Stephen Hemminger @ 2011-08-11 15:17 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev
In-Reply-To: <20110811070659.GA21307@torres.zugschlus.de>
On Thu, 11 Aug 2011 09:06:59 +0200
Marc Haber <mh+netdev@zugschlus.de> wrote:
> Hi,
>
> since a few kernel versions, I think since 2.6.39, I have noticed that
> a bridge interface stays in NO CARRIER state unless the first port is
> added:
>
> $ sudo brctl show
> bridge name bridge id STP enabled interfaces
> br0 8000.000000000000 no
> $ ip a show dev br0
> 9: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> inet6 2001:db8::1/64 scope global tentative
> valid_lft forever preferred_lft forever
> $ ping6 2001:db8::1
> PING 2001:db8::1(2001:db8::1) 56 data bytes
> ^C
> --- 2001:db8::1 ping statistics ---
> 3 packets transmitted, 0 received, 100% packet loss, time 2016ms
>
> $ sudo modprobe dummy
> $ sudo brctl addif br0 dummy0
> $ sudo ip link set dev dummy0 up
> $ ping6 2001:db8::1
> PING 2001:db8::1(2001:db8::1) 56 data bytes
> 64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=0.019 ms
> 64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=0.023 ms
> ^C
> --- 2001:db8::1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 999ms
> rtt min/avg/max/mdev = 0.019/0.021/0.023/0.002 ms
> $ ip a show dev br0
> 9: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
> link/ether da:1c:11:bc:3e:54 brd ff:ff:ff:ff:ff:ff
> inet6 2001:db8::1/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::d81c:11ff:febc:3e54/64 scope link
> valid_lft forever preferred_lft forever
> $
>
> Is that a feature? If so, why does the interface stay pingable after
> removing the dummy0 interface from the bridge?
Yes, there are no links to send a packet so it seems logical
that there would be no carrier.
> Can I somehow get the old behavior back, that the bridge is
> immediately up, and addresses configured on the bridge interfaces are
> immediately pingable?
> New new behavior is somewhat unhandy when one uses the bridge address
> for services that the host offers, to save on IP addresses and
> networks (for example, when one has only a single IP address and a
> single additional network), since one has to take extra measures to
> have the addresses on the bridge interface reachable.
>
> Or am I doing things wrong?
The goal is to make the bridge behave the same as a vlan or
a physical device. Could you explain better what the application(s)
would expect.
^ permalink raw reply
* Re: [patch net-next-2.6 0/2] bonding: create same number of queues on all creations
From: David Miller @ 2011-08-11 14:44 UTC (permalink / raw)
To: jpirko; +Cc: netdev, eric.dumazet, fubar, andy, tgraf, ebiederm
In-Reply-To: <1312992585-1201-1-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Wed, 10 Aug 2011 18:09:43 +0200
> When bonding device is created via /sys/class/net/bonding_masters,
> correct number of queues is created. But if bonding device is created via rtnl,
> default single queue is created. This little patchset makes it behaves the same.
>
> Jiri Pirko (2):
> bonding: implement get_tx_queues rtnk_link_op
> rtnetlink: remove initialization of dev->real_num_tx_queues
Both applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH] PCnet: Fix section mismatch
From: David Miller @ 2011-08-11 14:42 UTC (permalink / raw)
To: ralf; +Cc: pcnet32, netdev, tsbogend, linux-mips
In-Reply-To: <20110810152346.GA6092@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 10 Aug 2011 16:23:46 +0100
> Building MIPS mtx1_defconfig results in:
>
> MODPOST 735 modules
> WARNING: drivers/net/pcnet32.o(.devinit.text+0x11ec): Section mismatch in reference from the function pcnet32_probe_vlbus.constprop.22() to the variable .init.data:pcnet32_portlist
> The function __devinit pcnet32_probe_vlbus.constprop.22() references
> a variable __initdata pcnet32_portlist.
> If pcnet32_portlist is only used by pcnet32_probe_vlbus.constprop.22 then
> annotate pcnet32_portlist with a matching annotation.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks Ralf.
^ permalink raw reply
* Re: Influencing triggering of xfrm acquire messages?
From: David Miller @ 2011-08-11 14:36 UTC (permalink / raw)
To: david.martin.mailbox; +Cc: netdev
In-Reply-To: <CAGsyNe2oAkT+idnC-fuOoULTdEubbL8CabLesacjp=2tPiWVmA@mail.gmail.com>
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.
^ permalink raw reply
* Re: [PATCH 0/8] bna: Update bna driver version to 3.0.2.0
From: David Miller @ 2011-08-11 14:33 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1312856502-31242-1-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Mon, 8 Aug 2011 19:21:34 -0700
> The following patch set contains changes for driver re-architecture and
> code re-organisazion. This includes driver firmware interface change,
> tx and rx re-design and corresponding changes required to use/enable new
> code and also keep the patch set bisectable. It also removes obsolete
> files and cleans up unused code.
>
> This updates the Brocade BNA driver to v3.0.2.0.
>
> The driver has been compiled & tested against net-next-2.6(3.0.0-rc7)
All applied, thanks.
^ permalink raw reply
* Re: [PATCH net 5/5] bnx2x: disable dcb on 578xx since not supported yet
From: David Miller @ 2011-08-11 14:27 UTC (permalink / raw)
To: dmitry; +Cc: netdev, vladz, eilong
In-Reply-To: <1312895473.21856.4.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 9 Aug 2011 16:11:13 +0300
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 4/5] bnx2x: properly clean indirect addresses
From: David Miller @ 2011-08-11 14:26 UTC (permalink / raw)
To: dmitry; +Cc: netdev, vladz, eilong
In-Reply-To: <1312895429.21856.3.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 9 Aug 2011 16:10:29 +0300
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: add Documentation/networking/scaling.txt
From: Will de Bruijn @ 2011-08-11 14:26 UTC (permalink / raw)
To: Rick Jones; +Cc: rdunlap, linux-doc, davem, netdev, therbert
In-Reply-To: <4E418030.2010102@hp.com>
> Any other worries I have a probably a matter of opinion or ignorance on my
> part.
I'll be happy to revise it once more. This version also lacks the
required one-line description in Documentation/networking/00-INDEX, so
I will have to resubmit, either way.
The 'suggested configuration' heuristics are certainly debatable, so
any questionable statements there can just be dropped. If the
technical description of the mechanisms is contentious, that would be
a more serious error.
willem
^ permalink raw reply
* Re: [PATCH net 3/5] bnx2x: prevent race between undi_unload and load flows
From: David Miller @ 2011-08-11 14:26 UTC (permalink / raw)
To: dmitry; +Cc: netdev, vladz, eilong
In-Reply-To: <1312895392.21856.2.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 9 Aug 2011 16:09:52 +0300
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 1/5] bnx2x: init FCOE FP only once
From: David Miller @ 2011-08-11 14:26 UTC (permalink / raw)
To: dmitry; +Cc: netdev, eilong, vladz
In-Reply-To: <1312895290.21856.0.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 9 Aug 2011 16:08:09 +0300
> From: Vladislav Zolotarov <vladz@broadcom.com>
>
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/5] bnx2x: fix select_queue when FCoE is disabled
From: David Miller @ 2011-08-11 14:26 UTC (permalink / raw)
To: dmitry; +Cc: netdev, vladz, eilong
In-Reply-To: <1312895335.21856.1.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 9 Aug 2011 16:08:55 +0300
> From: Vladislav Zolotarov <vladz@broadcom.com>
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Influencing triggering of xfrm acquire messages?
From: David Martin @ 2011-08-11 14:21 UTC (permalink / raw)
To: netdev
Hi,
I have got a question regarding the triggering of xfrm acquire messages.
The setup is the following:
I'm using HIPL (https://launchpad.net/hipl) which implements the
Host Identity Protocol (HIP) and provides a control channel for the mutual peer
authentication and the generation of keying material. In the end of the initial
handshake, HIPL sets up the Linux Kernel IPsec implementation for the protection
of payload data.
The initial exchange is triggered by the following policy for outgoing traffic.
Note that 2001:10::/28 is the prefix for HIP addresses.
> martin@pisa1:~$ sudo ip xfrm policy
> src 2001:10::/28 dst 2001:10::/28
> dir out priority 0
> tmpl src :: dst ::
> proto 0 reqid 0 mode transport
Anything matching the policy (eg. a ping matching the address prefix) triggers
an acquire message, so far so good. Everytime an acquire is triggered the kernel
sets up a SA looking like this:
> 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
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.
Greetings, David
^ permalink raw reply
* Re: [PATCH v11 4/5] powerpc: Add flexcan device support for p1010rdb.
From: Kumar Gala @ 2011-08-11 14:17 UTC (permalink / raw)
To: Robin Holt
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300, PPC list,
Wolfgang Grandegger
In-Reply-To: <20110811104252.GC4926-sJ/iWh9BUns@public.gmane.org>
On Aug 11, 2011, at 5:42 AM, Robin Holt wrote:
> On Wed, Aug 10, 2011 at 11:46:27PM -0500, Kumar Gala wrote:
>>
>> On Aug 10, 2011, at 1:16 PM, Wolfgang Grandegger wrote:
>>
>>> On 08/10/2011 07:01 PM, Kumar Gala wrote:
>>>>
>>>> On Aug 10, 2011, at 11:27 AM, Robin Holt wrote:
>>>>
>>>>> I added a simple clock source for the p1010rdb so the flexcan driver
>>>>> could determine a clock frequency. The p1010 flexcan device only has
>>>>> an oscillator of system bus frequency divided by 2.
>>>>>
>>>>> 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/platforms/85xx/Kconfig | 2 +
>>>>> arch/powerpc/platforms/85xx/Makefile | 2 +
>>>>> arch/powerpc/platforms/85xx/clock.c | 52 ++++++++++++++++++++++++++++++++
>>>>> arch/powerpc/platforms/85xx/p1010rdb.c | 8 +++++
>>>>> 4 files changed, 64 insertions(+), 0 deletions(-)
>>>>> create mode 100644 arch/powerpc/platforms/85xx/clock.c
>>>>
>>>> I dont understand how mpc85xx_clk_functions() ends up being associated with the frequency the flexcan is running at.
>>>
>>> The function mpc85xx_clk_get_rate() returns "fsl_get_sys_freq() / 2" for
>>> Flexcan devices.
>>>
>>>> This either seems to global or I'm missing something.
>>>
>>> This patch extends the existing Flexcan platform driver for ARM for the
>>> PowerPC using the device tree. Due to the nice integration of the device
>>> tree (of-platform) into the platform driver and devices, the difference
>>> are quite small (see patches 1..3). Apart from the endianess issue, only
>>> the clock needs to be handled in a common way. As ARM already uses the
>>> clk interface, we found it straight-forward to implement it for the
>>> P1010, or more general for the 85xx, as well, instead of using an
>>> additional helper function.
>>
>> I see, that. What concerns me is there are numerous clocks /
>> frequencies that exist inside a MPC85xx/P1010 SOC. The code I'm seeing
>> does NOT seem to do anything to relate this clock JUST to the flexcan.
>
> if (!dev->of_node ||
> !of_device_is_compatible(dev->of_node, "fsl,flexcan"))
> return ERR_PTR(-ENOENT);
>
> That should relate it just to flexcan, right? Plus it has the added
> benefit of being a baby-step in the direction of implementing a clkdev
> type thing for powerpc which did look fairly slick to me, but I may
> be confused.
>
> It sounds like Wolfgang is defering to you. Give it an honest evaluation
> and tell me which direction you would like me to go. I don't have a
> strong preference either way. The alternative I gave to Wolfgang of
> using a flexcan property to avoid needing any clk_get_rate seems fairly
> hackish at this point, but I have had more time to get used to the
> 'hack in a 85xx clock' method.
For some time we've been adding 'clock-frequency' nodes in the device tree to abstract having to know this headache in the kernel and adding a bunch of SoC specific code all the time. So pushing this to the firmware is exactly where we want it for FSL PPC SoCs.
We need to make sure the device tree binding has details on a 'clock-frequency' property.
- k
^ permalink raw reply
* Re: 2.6.35.11 bridge drops fragmented packets
From: Eric Dumazet @ 2011-08-11 14:17 UTC (permalink / raw)
To: ierdnah; +Cc: netdev
In-Reply-To: <1313070275.814.2.camel@ierdnac-hp>
Le jeudi 11 août 2011 à 16:44 +0300, Andrei Popa a écrit :
> On Thu, 2011-08-11 at 15:39 +0200, Eric Dumazet wrote:
> > Le jeudi 11 août 2011 à 15:43 +0300, Andrei Popa a écrit :
> > > Hello,
> > >
> > > We've got a problem with kernel 2.6.35.11 as it does not forward
> > > fragmented packets on a bridge.
> > > I've seen this thread
> > > http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
> > > thought to email you.
> > >
> > > The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
> > > fixes the problem.
> > >
> > > The config from the kernel is attached.
> > > The network configuration is as follows:
> > > cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
> > > cisco, interface in mode trunk with allowed vlan 1501
> > >
> > > The MTU on cisco and on linux interfaces is set to 1500.
> > > Packets with size 1500 and no fragments are forwarded succesfully,
> > > packets with size 1500 and fragments are not forwaded.
> > > On linux it's a bond comprised of eth1.1501 and eth0.1501.
> > > root@shaper_b2b_bucuresti:~# brctl show
> > > bridge name bridge id STP enabled interfaces
> > > br1501 8000.0015170ae7b8 no eth0.1501
> > > eth1.1501
> > > I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
> > > don't see them leaving on eth1 or eth1.1501.
> > >
> > > Andrei
> > >
> >
> > Could you give us output of 'netstat -s' to check if IP defrag drops
> > some packets ?
> root@shaper_b2b_bucuresti:~# echo 1
> > /proc/sys/net/bridge/bridge-nf-call-iptables
>
> On a server behind the shaper:
>
> nl2 ~ # ping -s 65000 lg.telia.net
> PING juniperlg1-sn4.m-sp.skanova.net (81.228.10.74) 65000(65028) bytes
> of data.
> ^C
> ---
65000 bytes means 43 frames, and your network seems a bit busy.
If _one_ frame is lost (becasue of shaping for example), IP
fragmentation in bridge will fail -> all frames are discarded.
Could you try with "-s 2000" ?
I could not reproduce your problem on my dev machine (admitidly using a
more recent kernel)
^ permalink raw reply
* Re: 2.6.35.11 bridge drops fragmented packets
From: Andrei Popa @ 2011-08-11 13:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1313069946.3261.1.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, 2011-08-11 at 15:39 +0200, Eric Dumazet wrote:
> Le jeudi 11 août 2011 à 15:43 +0300, Andrei Popa a écrit :
> > Hello,
> >
> > We've got a problem with kernel 2.6.35.11 as it does not forward
> > fragmented packets on a bridge.
> > I've seen this thread
> > http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
> > thought to email you.
> >
> > The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
> > fixes the problem.
> >
> > The config from the kernel is attached.
> > The network configuration is as follows:
> > cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
> > cisco, interface in mode trunk with allowed vlan 1501
> >
> > The MTU on cisco and on linux interfaces is set to 1500.
> > Packets with size 1500 and no fragments are forwarded succesfully,
> > packets with size 1500 and fragments are not forwaded.
> > On linux it's a bond comprised of eth1.1501 and eth0.1501.
> > root@shaper_b2b_bucuresti:~# brctl show
> > bridge name bridge id STP enabled interfaces
> > br1501 8000.0015170ae7b8 no eth0.1501
> > eth1.1501
> > I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
> > don't see them leaving on eth1 or eth1.1501.
> >
> > Andrei
> >
>
> Could you give us output of 'netstat -s' to check if IP defrag drops
> some packets ?
root@shaper_b2b_bucuresti:~# echo 1
> /proc/sys/net/bridge/bridge-nf-call-iptables
On a server behind the shaper:
nl2 ~ # ping -s 65000 lg.telia.net
PING juniperlg1-sn4.m-sp.skanova.net (81.228.10.74) 65000(65028) bytes
of data.
^C
--- juniperlg1-sn4.m-sp.skanova.net ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8021ms
nl2 ~ #
root@shaper_b2b_bucuresti:~# netstat -s
Ip:
12783151 total packets received
10960 with invalid addresses
0 forwarded
0 incoming packets discarded
2738144 incoming packets delivered
2224918 requests sent out
20 dropped because of missing route
2380122 fragments dropped after timeout
1502102174 reassemblies required
662730406 packets reassembled ok
3060985 packet reassembles failed
5 fragments received ok
10 fragments created
Icmp:
352 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
destination unreachable: 327
echo requests: 9
echo replies: 16
340 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 304
echo request: 27
echo replies: 9
IcmpMsg:
InType0: 16
InType3: 327
InType8: 9
OutType0: 9
OutType3: 304
OutType8: 27
Tcp:
193 active connections openings
14926 passive connection openings
8 failed connection attempts
17 connection resets received
2 connections established
1603905 segments received
1248972 segments send out
1140 segments retransmited
0 bad segments received.
19 resets sent
Udp:
991041 packets received
2 packets to unknown port received.
0 packet receive errors
991110 packets sent
UdpLite:
TcpExt:
8 resets received for embryonic SYN_RECV sockets
16113 delayed acks sent
1 delayed acks further delayed because of locked socket
Quick ack mode was activated 46 times
27639 packets directly queued to recvmsg prequeue.
1894178 bytes directly in process context from backlog
18824 bytes directly received in process context from prequeue
380110 packet headers predicted
1356 packets header predicted and directly queued to user
160586 acknowledgments not containing data payload received
730360 predicted acknowledgments
10 times recovered from packet loss by selective acknowledgements
Detected reordering 7 times using time stamp
4 congestion windows fully recovered without slow start
9 congestion windows partially recovered using Hoe heuristic
4 congestion windows recovered without slow start by DSACK
16 fast retransmits
7 forward retransmits
21 retransmits in slow start
229 other TCP timeouts
46 DSACKs sent for old packets
24 DSACKs received
13 connections reset due to early user close
4 connections aborted due to timeout
TCPDSACKIgnoredOld: 12
TCPDSACKIgnoredNoUndo: 3
TCPSackMerged: 2
TCPSackShiftFallback: 30
IpExt:
InMcastPkts: 12981
InBcastPkts: 129863
InOctets: 1509979125
OutOctets: 551230551
InMcastOctets: 363468
InBcastOctets: 8832164
^ permalink raw reply
* Re: 2.6.35.11 bridge drops fragmented packets
From: Eric Dumazet @ 2011-08-11 13:39 UTC (permalink / raw)
To: ierdnah; +Cc: netdev
In-Reply-To: <1313066585.14145.18.camel@ierdnac-hp>
Le jeudi 11 août 2011 à 15:43 +0300, Andrei Popa a écrit :
> Hello,
>
> We've got a problem with kernel 2.6.35.11 as it does not forward
> fragmented packets on a bridge.
> I've seen this thread
> http://lkml.indiana.edu/hypermail/linux/kernel/0604.0/0201.html and I
> thought to email you.
>
> The command "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables"
> fixes the problem.
>
> The config from the kernel is attached.
> The network configuration is as follows:
> cisco, interace in mode trunk with allowed vlan 1501,299 -> linux ->
> cisco, interface in mode trunk with allowed vlan 1501
>
> The MTU on cisco and on linux interfaces is set to 1500.
> Packets with size 1500 and no fragments are forwarded succesfully,
> packets with size 1500 and fragments are not forwaded.
> On linux it's a bond comprised of eth1.1501 and eth0.1501.
> root@shaper_b2b_bucuresti:~# brctl show
> bridge name bridge id STP enabled interfaces
> br1501 8000.0015170ae7b8 no eth0.1501
> eth1.1501
> I cand see the fragmented packets arriving on eth0 and eth0.1501 but I
> don't see them leaving on eth1 or eth1.1501.
>
> Andrei
>
Could you give us output of 'netstat -s' to check if IP defrag drops
some packets ?
^ permalink raw reply
* Re: [net-next 04/10] 8390: Move the 8390 related drivers
From: Ben Hutchings @ 2011-08-11 13:07 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Donald Becker, Paul Gortmaker,
Alain Malek, Peter De Schrijver, David Huggins-Daines, Wim Dumon,
Yoshinori Sato, David Hinds, Russell King
In-Reply-To: <1313033278-7337-5-git-send-email-jeffrey.t.kirsher@intel.com>
On Wed, 2011-08-10 at 20:27 -0700, Jeff Kirsher wrote:
> Moves the drivers for the National Semi-conductor 8390 chipset into
> drivers/net/ethernet/8390/ and the necessary Kconfig and Makefile
> changes.
[...]
> --- /dev/null
> +++ b/drivers/net/ethernet/8390/Kconfig
[...]
> +config EL2
> + tristate "3c503 \"EtherLink II\" support"
> + depends on ISA
> + select CRC32
> + ---help---
> + If you have a network (Ethernet) card of this type, say Y and read
> + the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + To compile this driver as a module, choose M here. The module
> + will be called 3c503.
[...]
Minor issue: you add the EL2 config here correctly, but don't remove it
from drivers/net/Kconfig until patch 10.
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
* Re: [PATCH] ipv4: some rt_iif -> rt_route_iif conversions
From: David Miller @ 2011-08-11 13:01 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1108091651290.1527@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Tue, 9 Aug 2011 17:01:16 +0300 (EEST)
>
> As rt_iif represents input device even for packets
> coming from loopback with output route, it is not an unique
> key specific to input routes. Now rt_route_iif has such role,
> it was fl.iif in 2.6.38, so better to change the checks at
> some places to save CPU cycles and to restore 2.6.38 semantics.
>
> compare_keys:
> - input routes: only rt_route_iif matters, rt_iif is same
> - output routes: only rt_oif matters, rt_iif is not
> used for matching in __ip_route_output_key
> - now we are back to 2.6.38 state
>
> ip_route_input_common:
> - matching rt_route_iif implies input route
> - compared to 2.6.38 we eliminated one rth->fl.oif check
> because it was not needed even for 2.6.38
>
> compare_hash_inputs:
> Only the change here is not an optimization, it has
> effect only for output routes. I assume I'm restoring
> the original intention to ignore oif, it was using fl.iif
> - now we are back to 2.6.38 state
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
Applied, thanks a lot for doing these audits.
^ permalink raw reply
* Re: return of ip_rt_bug()
From: David Miller @ 2011-08-11 13:00 UTC (permalink / raw)
To: ja; +Cc: selinux, davej, netdev
In-Reply-To: <alpine.LFD.2.00.1108091645351.1527@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Tue, 9 Aug 2011 16:51:26 +0300 (EEST)
> There are other places that used fl.iif (0 for output
> routes) but are now using rt_iif instead of rt_route_iif,
> not sure if this change is fatal for them because:
>
> - net/sched/cls_route.c, route4_classify() gets optional
> iif, so it can be 0, may be to match output route? And
> later route4_classify does exact match for rt_iif. Does
> it mean that now we can not match output packets without
> providing "fromif OUTDEV" ?
>
> - net/sched/em_meta.c: now int_rtiif (being rt_iif) is
> always != 0, may be not good to match output routes?
>
> In short, the fl.iif -> rt_iif conversion is risky
> at some places.
If we convert em_meta.c and cls_route.c to use rt_route_iif
we should be OK right? Please patches to do this if so.
Thanks.
^ permalink raw reply
* Re: [PATCH] slcan: ldisc generated skbs are received in softirq context
From: David Miller @ 2011-08-11 12:56 UTC (permalink / raw)
To: socketcan; +Cc: netdev, matvejchikov, alan
In-Reply-To: <4E42A163.5030208@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Wed, 10 Aug 2011 17:18:59 +0200
> As this discussion pointed out
>
> http://marc.info/?l=linux-netdev&m=131257225602375
>
> netdevices that are based on serial line disciplines should use netif_rx_ni()
> when pushing received socketbuffers into the netdev rx queue.
>
> Following commit 614851601c121b1320a35757ab88292d6272f906 ("slip: fix NOHZ
> local_softirq_pending 08 warning") this patch updates the slcan driver
> accordingly.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
> CC: Matvejchikov Ilya <matvejchikov@gmail.com>
> CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] net/irda: sh_sir: tidyup compile warning
From: David Miller @ 2011-08-11 12:54 UTC (permalink / raw)
To: kuninori.morimoto.gx; +Cc: kuninori.morimoto.gx, netdev
In-Reply-To: <8739h8wb79.wl%kuninori.morimoto.gx@renesas.com>
From: kuninori.morimoto.gx@gmail.com
Date: Thu, 11 Aug 2011 02:26:37 -0700 (PDT)
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch tidyup below warning
>
> ${LINUX}/drivers/net/irda/sh_sir.c:514:6: warning:
> 'val' may be used uninitialized in this function
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Applied.
^ 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