* [PATCH net-next v3 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: Wolfgang Grandegger @ 2011-11-28 11:30 UTC (permalink / raw)
To: netdev
Cc: linux-can, socketcan-users, IreneV, Stanislav Yelenskiy,
Wolfgang Zarre, Wolfgang Grandegger, devicetree-discuss,
linuxppc-dev, Kumar Gala
In-Reply-To: <1322479858-4874-1-git-send-email-wg@grandegger.com>
This patch enables or updates support for the CC770 and AN82527
CAN controller on the TQM8548 and TQM8xx boards.
CC: devicetree-discuss@lists.ozlabs.org
CC: linuxppc-dev@ozlabs.org
CC: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 19 ++++++++++++++-----
arch/powerpc/boot/dts/tqm8548.dts | 19 ++++++++++++++-----
arch/powerpc/boot/dts/tqm8xx.dts | 25 +++++++++++++++++++++++++
3 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
index 9452c3c..d918752 100644
--- a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -352,7 +352,7 @@
ranges = <
0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
- 2 0x0 0xa3000000 0x00008000 // CAN (2 x i82527)
+ 2 0x0 0xa3000000 0x00008000 // CAN (2 x CC770)
3 0x0 0xa3010000 0x00008000 // NAND FLASH
>;
@@ -393,18 +393,27 @@
};
/* Note: CAN support needs be enabled in U-Boot */
- can0@2,0 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,0 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x0 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <16000000>;
};
- can1@2,100 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,100 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x100 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
};
/* Note: NAND support needs to be enabled in U-Boot */
diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
index 619776f..988d887 100644
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -352,7 +352,7 @@
ranges = <
0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
- 2 0x0 0xe3000000 0x00008000 // CAN (2 x i82527)
+ 2 0x0 0xe3000000 0x00008000 // CAN (2 x CC770)
3 0x0 0xe3010000 0x00008000 // NAND FLASH
>;
@@ -393,18 +393,27 @@
};
/* Note: CAN support needs be enabled in U-Boot */
- can0@2,0 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,0 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x0 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <16000000>;
};
- can1@2,100 {
- compatible = "intel,82527"; // Bosch CC770
+ can@2,100 {
+ compatible = "bosch,cc770"; // Bosch CC770
reg = <2 0x100 0x100>;
interrupts = <4 1>;
interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
};
/* Note: NAND support needs to be enabled in U-Boot */
diff --git a/arch/powerpc/boot/dts/tqm8xx.dts b/arch/powerpc/boot/dts/tqm8xx.dts
index f6da7ec..c3dba25 100644
--- a/arch/powerpc/boot/dts/tqm8xx.dts
+++ b/arch/powerpc/boot/dts/tqm8xx.dts
@@ -57,6 +57,7 @@
ranges = <
0x0 0x0 0x40000000 0x800000
+ 0x3 0x0 0xc0000000 0x200
>;
flash@0,0 {
@@ -67,6 +68,30 @@
bank-width = <4>;
device-width = <2>;
};
+
+ /* Note: CAN support needs be enabled in U-Boot */
+ can@3,0 {
+ compatible = "intc,82527";
+ reg = <3 0x0 0x80>;
+ interrupts = <8 1>;
+ interrupt-parent = <&PIC>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ bosch,clock-out-frequency = <16000000>;
+ };
+
+ can@3,100 {
+ compatible = "intc,82527";
+ reg = <3 0x100 0x80>;
+ interrupts = <8 1>;
+ interrupt-parent = <&PIC>;
+ bosch,external-clock-frequency = <16000000>;
+ bosch,disconnect-rx1-input;
+ bosch,disconnect-tx1-output;
+ bosch,iso-low-speed-mux;
+ };
};
soc@fff00000 {
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next v3 3/4] can: cc770: add platform bus driver for the CC770 and AN82527
From: Wolfgang Grandegger @ 2011-11-28 11:30 UTC (permalink / raw)
To: netdev
Cc: linux-can, socketcan-users, IreneV, Stanislav Yelenskiy,
Wolfgang Zarre, Wolfgang Grandegger, Devicetree-discuss,
linuxppc-dev, Kumar Gala
In-Reply-To: <1322479858-4874-1-git-send-email-wg@grandegger.com>
This driver works with both, static platform data and device tree
bindings. It has been tested on a TQM855L board with two AN82527
CAN controllers on the local bus.
CC: Devicetree-discuss@lists.ozlabs.org
CC: linuxppc-dev@ozlabs.org
CC: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
.../devicetree/bindings/net/can/cc770.txt | 56 ++++
drivers/net/can/cc770/Kconfig | 7 +
drivers/net/can/cc770/Makefile | 1 +
drivers/net/can/cc770/cc770_platform.c | 280 ++++++++++++++++++++
4 files changed, 344 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/cc770.txt
create mode 100644 drivers/net/can/cc770/cc770_platform.c
diff --git a/Documentation/devicetree/bindings/net/can/cc770.txt b/Documentation/devicetree/bindings/net/can/cc770.txt
new file mode 100644
index 0000000..01e282d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/cc770.txt
@@ -0,0 +1,56 @@
+Memory mapped Bosch CC770 and Intel AN82527 CAN controller
+
+Note: The CC770 is a CAN controller from Bosch, which is 100%
+compatible with the old AN82527 from Intel, but with "bugs" being fixed.
+
+Required properties:
+
+- compatible : should be "bosch,cc770" for the CC770 and "intc,82527"
+ for the AN82527.
+
+- reg : should specify the chip select, address offset and size required
+ to map the registers of the controller. The size is usually 0x80.
+
+- interrupts : property with a value describing the interrupt source
+ (number and sensitivity) required for the controller.
+
+Optional properties:
+
+- bosch,external-clock-frequency : frequency of the external oscillator
+ clock in Hz. Note that the internal clock frequency used by the
+ controller is half of that value. If not specified, a default
+ value of 16000000 (16 MHz) is used.
+
+- bosch,clock-out-frequency : slock frequency in Hz on the CLKOUT pin.
+ If not specified or if the specified value is 0, the CLKOUT pin
+ will be disabled.
+
+- bosch,slew-rate : slew rate of the CLKOUT signal. If not specified,
+ a resonable value will be calculated.
+
+- bosch,disconnect-rx0-input : see data sheet.
+
+- bosch,disconnect-rx1-input : see data sheet.
+
+- bosch,disconnect-tx1-output : see data sheet.
+
+- bosch,polarity-dominant : see data sheet.
+
+- bosch,divide-memory-clock : see data sheet.
+
+- bosch,iso-low-speed-mux : see data sheet.
+
+For further information, please have a look to the CC770 or AN82527.
+
+Examples:
+
+can@3,100 {
+ compatible = "bosch,cc770";
+ reg = <3 0x100 0x80>;
+ interrupts = <2 0>;
+ interrupt-parent = <&mpic>;
+ bosch,external-clock-frequency = <16000000>;
+};
+
+
+
diff --git a/drivers/net/can/cc770/Kconfig b/drivers/net/can/cc770/Kconfig
index 28e4d48..22c07a8 100644
--- a/drivers/net/can/cc770/Kconfig
+++ b/drivers/net/can/cc770/Kconfig
@@ -11,4 +11,11 @@ config CAN_CC770_ISA
connected to the ISA bus using I/O port, memory mapped or
indirect access.
+config CAN_CC770_PLATFORM
+ tristate "Generic Platform Bus based CC770 driver"
+ ---help---
+ This driver adds support for the CC770 and AN82527 chips
+ connected to the "platform bus" (Linux abstraction for directly
+ to the processor attached devices).
+
endif
diff --git a/drivers/net/can/cc770/Makefile b/drivers/net/can/cc770/Makefile
index 872ecff..9fb8321 100644
--- a/drivers/net/can/cc770/Makefile
+++ b/drivers/net/can/cc770/Makefile
@@ -4,5 +4,6 @@
obj-$(CONFIG_CAN_CC770) += cc770.o
obj-$(CONFIG_CAN_CC770_ISA) += cc770_isa.o
+obj-$(CONFIG_CAN_CC770_PLATFORM) += cc770_platform.o
ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
diff --git a/drivers/net/can/cc770/cc770_platform.c b/drivers/net/can/cc770/cc770_platform.c
new file mode 100644
index 0000000..65e177e
--- /dev/null
+++ b/drivers/net/can/cc770/cc770_platform.c
@@ -0,0 +1,280 @@
+/*
+ * Driver for CC770 and AN82527 CAN controllers on the platform bus
+ *
+ * Copyright (C) 2009, 2011 Wolfgang Grandegger <wg@grandegger.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the version 2 of the GNU General Public License
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ * If platform data are used you should have similar definitions
+ * in your board-specific code:
+ *
+ * static struct cc770_platform_data myboard_cc770_pdata = {
+ * .osc_freq = 16000000,
+ * .cir = 0x41,
+ * .cor = 0x20,
+ * .bcr = 0x40,
+ * };
+ *
+ * Please see include/linux/can/platform/cc770.h for description of
+ * above fields.
+ *
+ * If the device tree is used, you need a CAN node definition in your
+ * DTS file similar to:
+ *
+ * can@3,100 {
+ * compatible = "bosch,cc770";
+ * reg = <3 0x100 0x80>;
+ * interrupts = <2 0>;
+ * interrupt-parent = <&mpic>;
+ * bosch,external-clock-frequency = <16000000>;
+ * };
+ *
+ * See "Documentation/devicetree/bindings/net/can/cc770.txt" for further
+ * information.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/netdevice.h>
+#include <linux/delay.h>
+#include <linux/can.h>
+#include <linux/can/dev.h>
+#include <linux/can/platform/cc770.h>
+
+#include <linux/of_platform.h>
+
+#include "cc770.h"
+
+#define DRV_NAME "cc770_platform"
+
+MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>");
+MODULE_DESCRIPTION("Socket-CAN driver for CC770 on the platform bus");
+MODULE_LICENSE("GPL v2");
+
+#define CC770_PLATFORM_CAN_CLOCK 16000000
+
+static u8 cc770_platform_read_reg(const struct cc770_priv *priv, int reg)
+{
+ return in_8(priv->reg_base + reg);
+}
+
+static void cc770_platform_write_reg(const struct cc770_priv *priv, int reg,
+ u8 val)
+{
+ out_8(priv->reg_base + reg, val);
+}
+
+static int __devinit cc770_get_of_node_data(struct platform_device *pdev,
+ struct cc770_priv *priv)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const u32 *prop;
+ int prop_size;
+ u32 clkext;
+
+ prop = of_get_property(np, "bosch,external-clock-frequency",
+ &prop_size);
+ if (prop && (prop_size == sizeof(u32)))
+ clkext = *prop;
+ else
+ clkext = CC770_PLATFORM_CAN_CLOCK; /* default */
+ priv->can.clock.freq = clkext;
+
+ /* The system clock may not exceed 10 MHz */
+ if (priv->can.clock.freq > 10000000) {
+ priv->cpu_interface |= CPUIF_DSC;
+ priv->can.clock.freq /= 2;
+ }
+
+ /* The memory clock may not exceed 8 MHz */
+ if (priv->can.clock.freq > 8000000)
+ priv->cpu_interface |= CPUIF_DMC;
+
+ if (of_get_property(np, "bosch,divide-memory-clock", NULL))
+ priv->cpu_interface |= CPUIF_DMC;
+ if (of_get_property(np, "bosch,iso-low-speed-mux", NULL))
+ priv->cpu_interface |= CPUIF_MUX;
+
+ if (!of_get_property(np, "bosch,no-comperator-bypass", NULL))
+ priv->bus_config |= BUSCFG_CBY;
+ if (of_get_property(np, "bosch,disconnect-rx0-input", NULL))
+ priv->bus_config |= BUSCFG_DR0;
+ if (of_get_property(np, "bosch,disconnect-rx1-input", NULL))
+ priv->bus_config |= BUSCFG_DR1;
+ if (of_get_property(np, "bosch,disconnect-tx1-output", NULL))
+ priv->bus_config |= BUSCFG_DT1;
+ if (of_get_property(np, "bosch,polarity-dominant", NULL))
+ priv->bus_config |= BUSCFG_POL;
+
+ prop = of_get_property(np, "bosch,clock-out-frequency", &prop_size);
+ if (prop && (prop_size == sizeof(u32)) && *prop > 0) {
+ u32 cdv = clkext / *prop;
+ int slew;
+
+ if (cdv > 0 && cdv < 16) {
+ priv->cpu_interface |= CPUIF_CEN;
+ priv->clkout |= (cdv - 1) & CLKOUT_CD_MASK;
+
+ prop = of_get_property(np, "bosch,slew-rate",
+ &prop_size);
+ if (prop && (prop_size == sizeof(u32))) {
+ slew = *prop;
+ } else {
+ /* Determine default slew rate */
+ slew = (CLKOUT_SL_MASK >>
+ CLKOUT_SL_SHIFT) -
+ ((cdv * clkext - 1) / 8000000);
+ if (slew < 0)
+ slew = 0;
+ }
+ priv->clkout |= (slew << CLKOUT_SL_SHIFT) &
+ CLKOUT_SL_MASK;
+ } else {
+ dev_dbg(&pdev->dev, "invalid clock-out-frequency\n");
+ }
+ }
+
+ return 0;
+}
+
+static int __devinit cc770_get_platform_data(struct platform_device *pdev,
+ struct cc770_priv *priv)
+{
+
+ struct cc770_platform_data *pdata = pdev->dev.platform_data;
+
+ priv->can.clock.freq = pdata->osc_freq;
+ if (priv->cpu_interface | CPUIF_DSC)
+ priv->can.clock.freq /= 2;
+ priv->clkout = pdata->cor;
+ priv->bus_config = pdata->bcr;
+ priv->cpu_interface = pdata->cir;
+
+ return 0;
+}
+
+static int __devinit cc770_platform_probe(struct platform_device *pdev)
+{
+ struct net_device *dev;
+ struct cc770_priv *priv;
+ struct resource *mem;
+ resource_size_t mem_size;
+ void __iomem *base;
+ int err, irq;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ irq = platform_get_irq(pdev, 0);
+ if (!mem || irq <= 0)
+ return -ENODEV;
+
+ mem_size = resource_size(mem);
+ if (!request_mem_region(mem->start, mem_size, pdev->name))
+ return -EBUSY;
+
+ base = ioremap(mem->start, mem_size);
+ if (!base) {
+ err = -ENOMEM;
+ goto exit_release_mem;
+ }
+
+ dev = alloc_cc770dev(0);
+ if (!dev) {
+ err = -ENOMEM;
+ goto exit_unmap_mem;
+ }
+
+ dev->irq = irq;
+ priv = netdev_priv(dev);
+ priv->read_reg = cc770_platform_read_reg;
+ priv->write_reg = cc770_platform_write_reg;
+ priv->irq_flags = IRQF_SHARED;
+ priv->reg_base = base;
+
+ if (pdev->dev.of_node)
+ err = cc770_get_of_node_data(pdev, priv);
+ else if (pdev->dev.platform_data)
+ err = cc770_get_platform_data(pdev, priv);
+ else
+ err = -ENODEV;
+ if (err)
+ goto exit_free_cc770;
+
+ dev_dbg(&pdev->dev,
+ "reg_base=0x%p irq=%d clock=%d cpu_interface=0x%02x "
+ "bus_config=0x%02x clkout=0x%02x\n",
+ priv->reg_base, dev->irq, priv->can.clock.freq,
+ priv->cpu_interface, priv->bus_config, priv->clkout);
+
+ dev_set_drvdata(&pdev->dev, dev);
+ SET_NETDEV_DEV(dev, &pdev->dev);
+
+ err = register_cc770dev(dev);
+ if (err) {
+ dev_err(&pdev->dev,
+ "couldn't register CC700 device (err=%d)\n", err);
+ goto exit_free_cc770;
+ }
+
+ return 0;
+
+exit_free_cc770:
+ free_cc770dev(dev);
+exit_unmap_mem:
+ iounmap(base);
+exit_release_mem:
+ release_mem_region(mem->start, mem_size);
+
+ return err;
+}
+
+static int __devexit cc770_platform_remove(struct platform_device *pdev)
+{
+ struct net_device *dev = dev_get_drvdata(&pdev->dev);
+ struct cc770_priv *priv = netdev_priv(dev);
+ struct resource *mem;
+
+ unregister_cc770dev(dev);
+ iounmap(priv->reg_base);
+ free_cc770dev(dev);
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (mem)
+ release_mem_region(mem->start, resource_size(mem));
+ else
+ dev_err(&pdev->dev, "couldn't release mem region");
+
+ return 0;
+}
+
+static struct of_device_id __devinitdata cc770_platform_table[] = {
+ {.compatible = "bosch,cc770"}, /* CC770 from Bosch */
+ {.compatible = "intc,82527"}, /* AN82527 from Intel CP */
+ {},
+};
+
+static struct platform_driver cc770_platform_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = cc770_platform_table,
+ },
+ .probe = cc770_platform_probe,
+ .remove = __devexit_p(cc770_platform_remove),
+};
+
+module_platform_driver(cc770_platform_driver);
+
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: Wolfgang Zarre @ 2011-11-28 12:03 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Oliver Hartkopp, netdev, linux-can, socketcan-users, IreneV,
Stanislav Yelenskiy
In-Reply-To: <4ED351A8.8000102@grandegger.com>
Hello Wolfgang,
> On 11/28/2011 09:56 AM, Wolfgang Zarre wrote:
>> Hello Oliver,
>>
>>> Hello Wolfgang,
>>>
>>> many thanks for posting this driver. Indeed this is the last from the
>>> missing
>>> drivers in the SVN ...
>>
>> @Wolfgang
>>
>> The same her, thanks a lot.
>>
>>>
>>> I added Wolfgang Zarre to the list of recipients who tested your CC770
>>> driver
>>> recently:
>>>
>>> http://old.nabble.com/Compile-Fails-On-2.6.39-2-td32259346.html
>>>
>>> Maybe he can check this latest version and can send a "Tested-by:"
>>>
>>> @Wolfgang Zarre: The entire patch set from Wolfgang Grandegger is here:
>>>
>>> http://patchwork.ozlabs.org/patch/127653/
>>> http://patchwork.ozlabs.org/patch/127651/
>>> http://patchwork.ozlabs.org/patch/127654/
>>> http://patchwork.ozlabs.org/patch/127652/
>>
>> In fact a month ago we discovered a problem with the previous isa driver
>> but were not
>> able to reproduce it.
>>
>> Last Friday during a test run we got the same problem and with some
>> further tests I
>> was able to reproduce and started with some investigation.
>>
>> So the patches came in quite handy and even not to waste time I was
>> applying the
>> patches to an updated svn tree but had to do some manual corrections to
>> get it
>> compiled.
>>
>> So far the driver is functioning quite good and I was hoping that our
>> problem would
>> be solved as well.
>
> Well, I do not remember any fix... apart from
Of course not, was never reported because we couldn't reproduce.
>
>> But unfortunately that is not the case and it would be great if somebody
>> would have
>> an idea or similar experience and maybe a solution.
>>
>> In use:
>> ISA card: B&R with CC770 (40007) Series Bosch CAN Controller - LQFP-44
>> Kernel: 2.6.39.4
>> Module: modprobe cc770_isa irq=0xa port=0x384 indirect=1
>> Commands: ip link set can0 up type can bitrate 500000;ip link set can0
>> txqueuelen 2000
>
> ... using a reasonable default for bcr of 0x40. But you may need to
> provide better values for cir, bcr and cor.
>
OMG, sorry that I was bothering You but You are absolutely right and with Your
statement You brought be back on track and You made my day. Thank You !!!!!!
I just took the values for cpu and bus I was using in my lincan driver and funny
enough now it's working absolutely perfect.
Module: modprobe cc770_isa irq=0xa port=0x384 indirect=1 cir=0x61 bcr=0x4A
Was just sending 50000 telegrams, perfect and no problem at all.
Thanks a lot again!!!!
>> dmesg:
>> [190911.144337] CAN device driver interface
>> [190911.153316] cc770 CAN netdevice driver
>> [190911.159708] cc770_isa: platform device 0: port=0x384, mem=0x0, irq=10
>> [190911.159740] cc770_isa cc770_isa.0: probing idx=0: port=0x384,
>> mem=0x0, irq=10
>> [190911.159799] cc770_isa cc770_isa.0: (unregistered net_device): i82527
>> mode with additional functions
>> [190911.161338] cc770_isa cc770_isa.0: cc770_isa device registered
>> (reg_base=0x00000384, irq=10)
>> [190911.161384] Legacy cc770_isa driver for max. 8 devices registered
>> [190912.173762] cc770_isa cc770_isa.0: can0: setting BTR0=0x00 BTR1=0x1c
>> [190912.173835] cc770_isa cc770_isa.0: can0: Message object 15 for RX
>> data, RTR, SFF and EFF
>> [190912.173852] cc770_isa cc770_isa.0: can0: Message object 11 for TX
>> data, RTR, SFF and EFF
>>
>>
>> Description of problem:
>> After a while sending quite some telegrams the driver of a sudden stops
>> transmitting
>> and the queue is running full but still capable to receive telegrams.
>> This issue is not depending on the amount of transmitted telegrams and
>> also no logfile
>> entries.
>
> What do you get with "candump -t d any,0:0,#FFFFFFFF"? What does "ip -d
> -s link show" show?
>
> Wolfgang.
>
Wolfgang
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: Marc Kleine-Budde @ 2011-11-28 12:09 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev, linux-can, socketcan-users, IreneV, Stanislav Yelenskiy
In-Reply-To: <1322214204-1121-3-git-send-email-wg@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 13074 bytes --]
On 11/25/2011 10:43 AM, Wolfgang Grandegger wrote:
> This patch adds support for legacy Bosch CC770 and Intel AN82527 CAN
> controllers on the ISA or PC-104 bus. The I/O port or memory address
> and the IRQ number must be specified via module parameters:
>
> insmod cc770_isa.ko port=0x310,0x380 irq=7,11
>
> for ISA devices using I/O ports or:
>
> insmod cc770_isa.ko mem=0xd1000,0xd1000 irq=7,11
>
> for memory mapped ISA devices.
>
> Indirect access via address and data port is supported as well:
>
> insmod cc770_isa.ko port=0x310,0x380 indirect=1 irq=7,11
>
> Furthermore, the following mode parameter can be defined:
>
> clk: External oscillator clock frequency (default=16000000 [16 MHz])
> cir: CPU interface register (default=0x40 [DSC])
> ocr, Bus configuration register (default=0x40 [CBY])
> cor, Clockout register (default=0x00)
>
> Note: for clk, cir, bcr and cor, the first argument re-defines the
> default for all other devices, e.g.:
>
> insmod cc770_isa.ko mem=0xd1000,0xd1000 irq=7,11 clk=24000000
>
> is equivalent to
>
> insmod cc770_isa.ko mem=0xd1000,0xd1000 irq=7,11 clk=24000000,24000000
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Some nitpicking inside.
Marc
> ---
> drivers/net/can/cc770/Kconfig | 11 ++
> drivers/net/can/cc770/Makefile | 1 +
> drivers/net/can/cc770/cc770_isa.c | 336 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 348 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/can/cc770/cc770_isa.c
>
> diff --git a/drivers/net/can/cc770/Kconfig b/drivers/net/can/cc770/Kconfig
> index 225131b..28e4d48 100644
> --- a/drivers/net/can/cc770/Kconfig
> +++ b/drivers/net/can/cc770/Kconfig
> @@ -1,3 +1,14 @@
> menuconfig CAN_CC770
> tristate "Bosch CC770 and Intel AN82527 devices"
> depends on CAN_DEV && HAS_IOMEM
> +
> +if CAN_CC770
> +
> +config CAN_CC770_ISA
> + tristate "ISA Bus based legacy CC770 driver"
> + ---help---
> + This driver adds legacy support for CC770 and AN82527 chips
> + connected to the ISA bus using I/O port, memory mapped or
> + indirect access.
> +
> +endif
> diff --git a/drivers/net/can/cc770/Makefile b/drivers/net/can/cc770/Makefile
> index 34e8180..872ecff 100644
> --- a/drivers/net/can/cc770/Makefile
> +++ b/drivers/net/can/cc770/Makefile
> @@ -3,5 +3,6 @@
> #
>
> obj-$(CONFIG_CAN_CC770) += cc770.o
> +obj-$(CONFIG_CAN_CC770_ISA) += cc770_isa.o
>
> ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
> diff --git a/drivers/net/can/cc770/cc770_isa.c b/drivers/net/can/cc770/cc770_isa.c
> new file mode 100644
> index 0000000..3aaecd5
> --- /dev/null
> +++ b/drivers/net/can/cc770/cc770_isa.c
> @@ -0,0 +1,336 @@
> +/*
> + * Copyright (C) 2009, 2011 Wolfgang Grandegger <wg@grandegger.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the version 2 of the GNU General Public License
> + * as published by the Free Software Foundation
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Please remove the address.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/interrupt.h>
> +#include <linux/netdevice.h>
> +#include <linux/delay.h>
> +#include <linux/irq.h>
> +#include <linux/io.h>
> +#include <linux/can.h>
> +#include <linux/can/dev.h>
> +
> +#include "cc770.h"
> +
> +#define DRV_NAME "cc770_isa"
> +
> +#define MAXDEV 8
> +
> +MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>");
> +MODULE_DESCRIPTION("Socket-CAN driver for CC770 on the ISA bus");
> +MODULE_LICENSE("GPL v2");
> +
> +#define CLK_DEFAULT 16000000 /* 16 MHz */
> +#define COR_DEFAULT 0x00
> +#define BCR_DEFAULT BUSCFG_CBY
> +
> +static unsigned long port[MAXDEV];
> +static unsigned long mem[MAXDEV];
> +static int __devinitdata irq[MAXDEV];
> +static int __devinitdata clk[MAXDEV];
> +static u8 __devinitdata cir[MAXDEV] = {[0 ... (MAXDEV - 1)] = 0xff};
> +static u8 __devinitdata cor[MAXDEV] = {[0 ... (MAXDEV - 1)] = 0xff};
> +static u8 __devinitdata bcr[MAXDEV] = {[0 ... (MAXDEV - 1)] = 0xff};
> +static int __devinitdata indirect[MAXDEV] = {[0 ... (MAXDEV - 1)] = -1};
> +
> +module_param_array(port, ulong, NULL, S_IRUGO);
> +MODULE_PARM_DESC(port, "I/O port number");
> +
> +module_param_array(mem, ulong, NULL, S_IRUGO);
> +MODULE_PARM_DESC(mem, "I/O memory address");
> +
> +module_param_array(indirect, int, NULL, S_IRUGO);
> +MODULE_PARM_DESC(indirect, "Indirect access via address and data port");
> +
> +module_param_array(irq, int, NULL, S_IRUGO);
> +MODULE_PARM_DESC(irq, "IRQ number");
> +
> +module_param_array(clk, int, NULL, S_IRUGO);
> +MODULE_PARM_DESC(clk, "External oscillator clock frequency "
> + "(default=16000000 [16 MHz])");
> +
> +module_param_array(cir, byte, NULL, S_IRUGO);
> +MODULE_PARM_DESC(cir, "CPU interface register (default=0x40 [DSC])");
> +
> +module_param_array(cor, byte, NULL, S_IRUGO);
> +MODULE_PARM_DESC(cor, "Clockout register (default=0x00)");
> +
> +module_param_array(bcr, byte, NULL, S_IRUGO);
> +MODULE_PARM_DESC(bcr, "Bus configuration register (default=0x40 [CBY])");
> +
> +#define CC770_IOSIZE 0x20
> +#define CC770_IOSIZE_INDIRECT 0x02
> +
> +static struct platform_device *cc770_isa_devs[MAXDEV];
> +
> +static u8 cc770_isa_mem_read_reg(const struct cc770_priv *priv, int reg)
> +{
> + return readb(priv->reg_base + reg);
> +}
> +
> +static void cc770_isa_mem_write_reg(const struct cc770_priv *priv,
> + int reg, u8 val)
> +{
> + writeb(val, priv->reg_base + reg);
> +}
> +
> +static u8 cc770_isa_port_read_reg(const struct cc770_priv *priv, int reg)
> +{
> + return inb((unsigned long)priv->reg_base + reg);
> +}
> +
> +static void cc770_isa_port_write_reg(const struct cc770_priv *priv,
> + int reg, u8 val)
> +{
> + outb(val, (unsigned long)priv->reg_base + reg);
> +}
> +
> +static u8 cc770_isa_port_read_reg_indirect(const struct cc770_priv *priv,
> + int reg)
> +{
> + unsigned long base = (unsigned long)priv->reg_base;
> +
> + outb(reg, base);
> + return inb(base + 1);
> +}
> +
> +static void cc770_isa_port_write_reg_indirect(const struct cc770_priv *priv,
> + int reg, u8 val)
> +{
> + unsigned long base = (unsigned long)priv->reg_base;
> +
> + outb(reg, base);
> + outb(val, base + 1);
> +}
> +
> +static int __devinit cc770_isa_probe(struct platform_device *pdev)
> +{
> + struct net_device *dev;
> + struct cc770_priv *priv;
> + void __iomem *base = NULL;
> + int iosize = CC770_IOSIZE;
> + int idx = pdev->id;
> + int err;
> + u32 clktmp;
> +
> + dev_dbg(&pdev->dev, "probing idx=%d: port=%#lx, mem=%#lx, irq=%d\n",
> + idx, port[idx], mem[idx], irq[idx]);
> + if (mem[idx]) {
> + if (!request_mem_region(mem[idx], iosize, DRV_NAME)) {
> + err = -EBUSY;
> + goto exit;
> + }
> + base = ioremap_nocache(mem[idx], iosize);
> + if (!base) {
> + err = -ENOMEM;
> + goto exit_release;
> + }
> + } else {
> + if (indirect[idx] > 0 ||
> + (indirect[idx] == -1 && indirect[0] > 0))
> + iosize = CC770_IOSIZE_INDIRECT;
> + if (!request_region(port[idx], iosize, DRV_NAME)) {
> + err = -EBUSY;
> + goto exit;
> + }
> + }
> +
> + dev = alloc_cc770dev(0);MAXDEV
> + if (!dev) {
> + err = -ENOMEM;
> + goto exit_unmap;
> + }
> + priv = netdev_priv(dev);
> +
> + dev->irq = irq[idx];
> + priv->irq_flags = IRQF_SHARED;
> + if (mem[idx]) {
> + priv->reg_base = base;
> + dev->base_addr = mem[idx];
> + priv->read_reg = cc770_isa_mem_read_reg;
> + priv->write_reg = cc770_isa_mem_write_reg;
> + } else {
> + priv->reg_base = (void __iomem *)port[idx];
> + dev->base_addr = port[idx];
> +
> + if (iosize == CC770_IOSIZE_INDIRECT) {
> + priv->read_reg = cc770_isa_port_read_reg_indirect;
> + priv->write_reg = cc770_isa_port_write_reg_indirect;
> + } else {
> + priv->read_reg = cc770_isa_port_read_reg;
> + priv->write_reg = cc770_isa_port_write_reg;
> + }
> + }
> +
> + if (clk[idx])
> + clktmp = clk[idx];
> + else if (clk[0])
> + clktmp = clk[0];
> + else
> + clktmp = CLK_DEFAULT;
> + priv->can.clock.freq = clktmp;
> +
> + if (cir[idx] != 0xff) {
> + priv->cpu_interface = cir[idx] & 0xff;
> + } else if (cir[0] != 0xff) {
> + priv->cpu_interface = cir[0] & 0xff;
> + } else {
> + /* The system clock may not exceed 10 MHz */
> + if (clktmp > 10000000) {
> + priv->cpu_interface |= CPUIF_DSC;
> + clktmp /= 2;
> + }
> + /* The memory clock may not exceed 8 MHz */
> + if (clktmp > 8000000)
> + priv->cpu_interface |= CPUIF_DMC;
> + }
> +
> + if (priv->cpu_interface & CPUIF_DSC)
> + priv->can.clock.freq /= 2;
> +
> + if (bcr[idx] != 0xff)
> + priv->bus_config = bcr[idx] & 0xff;
> + else if (bcr[0] != 0xff)
> + priv->bus_config = bcr[0] & 0xff;
bus_config is u8
> + else
> + priv->bus_config = BCR_DEFAULT;
> +
> + if (cor[idx] != 0xff)
> + priv->clkout = cor[idx];
> + else if (cor[0] != 0xff)
> + priv->clkout = cor[0] & 0xff;
> + else
> + priv->clkout = COR_DEFAULT;
> +
> + dev_set_drvdata(&pdev->dev, dev);
> + SET_NETDEV_DEV(dev, &pdev->dev);
> +
> + err = register_cc770dev(dev);
> + if (err) {
> + dev_err(&pdev->dev, "registering %s failed (err=%d)\n",
> + DRV_NAME, err);
> + goto exit_unmap;
> + }
> +
> + dev_info(&pdev->dev, "%s device registered (reg_base=0x%p, irq=%d)\n",
> + DRV_NAME, priv->reg_base, dev->irq);
> + return 0;
> +
> + exit_unmap:
> + if (mem[idx])
> + iounmap(base);
> + exit_release:
> + if (mem[idx])
> + release_mem_region(mem[idx], iosize);
> + else
> + release_region(port[idx], iosize);
> + exit:
> + return err;
> +}
> +
> +static int __devexit cc770_isa_remove(struct platform_device *pdev)
> +{
> + struct net_device *dev = dev_get_drvdata(&pdev->dev);
> + struct cc770_priv *priv = netdev_priv(dev);
> + int idx = pdev->id;
> +
> + unregister_cc770dev(dev);
> + dev_set_drvdata(&pdev->dev, NULL);
> +
> + if (mem[idx]) {
> + iounmap(priv->reg_base);
> + release_mem_region(mem[idx], CC770_IOSIZE);
> + } else {
> + if (priv->read_reg == cc770_isa_port_read_reg_indirect)
> + release_region(port[idx], CC770_IOSIZE_INDIRECT);
> + else
> + release_region(port[idx], CC770_IOSIZE);
> + }
> + free_cc770dev(dev);
> +
> + return 0;
> +}
> +
> +static struct platform_driver cc770_isa_driver = {
> + .probe = cc770_isa_probe,
> + .remove = __devexit_p(cc770_isa_remove),
> + .driver = {
> + .name = DRV_NAME,
> + .owner = THIS_MODULE,
> + },
> +};
> +
> +static int __init cc770_isa_init(void)
> +{
> + int idx, err;
> +
> + for (idx = 0; idx < MAXDEV; idx++) {
ARRAY_SIZE?
> + if ((port[idx] || mem[idx]) && irq[idx]) {
> + cc770_isa_devs[idx] =
> + platform_device_alloc(DRV_NAME, idx);
> + if (!cc770_isa_devs[idx]) {
> + err = -ENOMEM;
> + goto exit_free_devices;
> + }
> + err = platform_device_add(cc770_isa_devs[idx]);
> + if (err) {
> + platform_device_put(cc770_isa_devs[idx]);
> + goto exit_free_devices;
> + }
> + pr_debug("%s: platform device %d: port=%#lx, mem=%#lx, "
> + "irq=%d\n",
> + DRV_NAME, idx, port[idx], mem[idx], irq[idx]);
> + } else if (idx == 0 || port[idx] || mem[idx]) {
> + pr_err("%s: insufficient parameters supplied\n",
> + DRV_NAME);
> + err = -EINVAL;
> + goto exit_free_devices;
> + }
> + }
> +
> + err = platform_driver_register(&cc770_isa_driver);
> + if (err)
> + goto exit_free_devices;
> +
> + pr_info("Legacy %s driver for max. %d devices registered\n",
> + DRV_NAME, MAXDEV);
> +
> + return 0;
> +
> +exit_free_devices:
> + while (--idx >= 0) {
> + if (cc770_isa_devs[idx])
> + platform_device_unregister(cc770_isa_devs[idx]);
> + }
> +
> + return err;
> +}
> +module_init(cc770_isa_init);
> +
> +static void __exit cc770_isa_exit(void)
> +{
> + int idx;
> +
> + platform_driver_unregister(&cc770_isa_driver);
> + for (idx = 0; idx < MAXDEV; idx++) {
ARRAY_SIZE
> + if (cc770_isa_devs[idx])
> + platform_device_unregister(cc770_isa_devs[idx]);
> + }
> +}
> +module_exit(cc770_isa_exit);
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re[2]: [v4 PATCH 2/2] NETFILTER userspace part for target HMARK
From: Jan Engelhardt @ 2011-11-28 12:23 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Hans Schillström, kaber@trash.net, pablo@netfilter.org,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <hr62jai.f4f5223b83b31ae9b337edbf22b93bdf@obelix.schillstrom.com>
On Monday 2011-11-28 09:37, Hans Schillstrom wrote:
>>>>>+Parameters:
>>>>>+For all masks default is all "1:s", to disable a field use mask 0
>>>>>+For IPv6 it's just the last 32 bits that is included in the hash
>>>>
>>>>Why limit IPv6 to 32?
>>>
>>>Performance, and the gain of adding another 192 bits to jhash ain't much.
>>>However there is some cases when it hurts, i.e. when you can't mask of an subnet
>>>I'm not sure it it's a problem or not...
>>
>>I was thinking about the case where two particular hosts have the same
>>trailing 32 bits in their source address. For example, assuming IPv6
>>starts to take a stronghold in the real world and home customers start
>>assigning <myprefix>::1 to the little home server (i.e. the PPP
>>endpoint) of theirs for remote login.
>
>Yes that's a good point, I will have a look at this and see haw to speed-up the IPv6 calc.
>
>btw
>parsing by using xoption.c is there a way to allow both hex format and mask length ?
>i.e. --smask 0xffff0000 or --smask /16
That has never been used before, so no, you will need to use
XTTYPE_STRING and then parse it out.
Having /n besides n looks like feature creep (for values up to 2^32-1).
xt_mark does not have a /n, just saying.
^ permalink raw reply
* Re: [PATCH net-next v3 3/4] can: cc770: add platform bus driver for the CC770 and AN82527
From: Marc Kleine-Budde @ 2011-11-28 12:33 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev, linux-can, socketcan-users, IreneV, Stanislav Yelenskiy,
Wolfgang Zarre, Devicetree-discuss, linuxppc-dev, Kumar Gala
In-Reply-To: <1322479858-4874-4-git-send-email-wg@grandegger.com>
[-- Attachment #1: Type: text/plain, Size: 13373 bytes --]
On 11/28/2011 12:30 PM, Wolfgang Grandegger wrote:
> This driver works with both, static platform data and device tree
> bindings. It has been tested on a TQM855L board with two AN82527
> CAN controllers on the local bus.
>
> CC: Devicetree-discuss@lists.ozlabs.org
> CC: linuxppc-dev@ozlabs.org
> CC: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
See comment in the _remove function. Otherwise good. Add my:
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
> ---
> .../devicetree/bindings/net/can/cc770.txt | 56 ++++
> drivers/net/can/cc770/Kconfig | 7 +
> drivers/net/can/cc770/Makefile | 1 +
> drivers/net/can/cc770/cc770_platform.c | 280 ++++++++++++++++++++
> 4 files changed, 344 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/can/cc770.txt
> create mode 100644 drivers/net/can/cc770/cc770_platform.c
>
> diff --git a/Documentation/devicetree/bindings/net/can/cc770.txt b/Documentation/devicetree/bindings/net/can/cc770.txt
> new file mode 100644
> index 0000000..01e282d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/can/cc770.txt
> @@ -0,0 +1,56 @@
> +Memory mapped Bosch CC770 and Intel AN82527 CAN controller
> +
> +Note: The CC770 is a CAN controller from Bosch, which is 100%
> +compatible with the old AN82527 from Intel, but with "bugs" being fixed.
> +
> +Required properties:
> +
> +- compatible : should be "bosch,cc770" for the CC770 and "intc,82527"
> + for the AN82527.
> +
> +- reg : should specify the chip select, address offset and size required
> + to map the registers of the controller. The size is usually 0x80.
> +
> +- interrupts : property with a value describing the interrupt source
> + (number and sensitivity) required for the controller.
> +
> +Optional properties:
> +
> +- bosch,external-clock-frequency : frequency of the external oscillator
> + clock in Hz. Note that the internal clock frequency used by the
> + controller is half of that value. If not specified, a default
> + value of 16000000 (16 MHz) is used.
> +
> +- bosch,clock-out-frequency : slock frequency in Hz on the CLKOUT pin.
> + If not specified or if the specified value is 0, the CLKOUT pin
> + will be disabled.
> +
> +- bosch,slew-rate : slew rate of the CLKOUT signal. If not specified,
> + a resonable value will be calculated.
> +
> +- bosch,disconnect-rx0-input : see data sheet.
> +
> +- bosch,disconnect-rx1-input : see data sheet.
> +
> +- bosch,disconnect-tx1-output : see data sheet.
> +
> +- bosch,polarity-dominant : see data sheet.
> +
> +- bosch,divide-memory-clock : see data sheet.
> +
> +- bosch,iso-low-speed-mux : see data sheet.
> +
> +For further information, please have a look to the CC770 or AN82527.
> +
> +Examples:
> +
> +can@3,100 {
> + compatible = "bosch,cc770";
> + reg = <3 0x100 0x80>;
> + interrupts = <2 0>;
> + interrupt-parent = <&mpic>;
> + bosch,external-clock-frequency = <16000000>;
> +};
> +
> +
> +
> diff --git a/drivers/net/can/cc770/Kconfig b/drivers/net/can/cc770/Kconfig
> index 28e4d48..22c07a8 100644
> --- a/drivers/net/can/cc770/Kconfig
> +++ b/drivers/net/can/cc770/Kconfig
> @@ -11,4 +11,11 @@ config CAN_CC770_ISA
> connected to the ISA bus using I/O port, memory mapped or
> indirect access.
>
> +config CAN_CC770_PLATFORM
> + tristate "Generic Platform Bus based CC770 driver"
> + ---help---
> + This driver adds support for the CC770 and AN82527 chips
> + connected to the "platform bus" (Linux abstraction for directly
> + to the processor attached devices).
> +
> endif
> diff --git a/drivers/net/can/cc770/Makefile b/drivers/net/can/cc770/Makefile
> index 872ecff..9fb8321 100644
> --- a/drivers/net/can/cc770/Makefile
> +++ b/drivers/net/can/cc770/Makefile
> @@ -4,5 +4,6 @@
>
> obj-$(CONFIG_CAN_CC770) += cc770.o
> obj-$(CONFIG_CAN_CC770_ISA) += cc770_isa.o
> +obj-$(CONFIG_CAN_CC770_PLATFORM) += cc770_platform.o
>
> ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
> diff --git a/drivers/net/can/cc770/cc770_platform.c b/drivers/net/can/cc770/cc770_platform.c
> new file mode 100644
> index 0000000..65e177e
> --- /dev/null
> +++ b/drivers/net/can/cc770/cc770_platform.c
> @@ -0,0 +1,280 @@
> +/*
> + * Driver for CC770 and AN82527 CAN controllers on the platform bus
> + *
> + * Copyright (C) 2009, 2011 Wolfgang Grandegger <wg@grandegger.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the version 2 of the GNU General Public License
> + * as published by the Free Software Foundation
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software Foundation,
> + * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
please remove the address.
> + */
> +
> +/*
> + * If platform data are used you should have similar definitions
> + * in your board-specific code:
> + *
> + * static struct cc770_platform_data myboard_cc770_pdata = {
> + * .osc_freq = 16000000,
> + * .cir = 0x41,
> + * .cor = 0x20,
> + * .bcr = 0x40,
> + * };
> + *
> + * Please see include/linux/can/platform/cc770.h for description of
> + * above fields.
> + *
> + * If the device tree is used, you need a CAN node definition in your
> + * DTS file similar to:
> + *
> + * can@3,100 {
> + * compatible = "bosch,cc770";
> + * reg = <3 0x100 0x80>;
> + * interrupts = <2 0>;
> + * interrupt-parent = <&mpic>;
> + * bosch,external-clock-frequency = <16000000>;
> + * };
> + *
> + * See "Documentation/devicetree/bindings/net/can/cc770.txt" for further
> + * information.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/netdevice.h>
> +#include <linux/delay.h>
> +#include <linux/can.h>
> +#include <linux/can/dev.h>
> +#include <linux/can/platform/cc770.h>
> +
> +#include <linux/of_platform.h>
> +
> +#include "cc770.h"
> +
> +#define DRV_NAME "cc770_platform"
> +
> +MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>");
> +MODULE_DESCRIPTION("Socket-CAN driver for CC770 on the platform bus");
> +MODULE_LICENSE("GPL v2");
> +
> +#define CC770_PLATFORM_CAN_CLOCK 16000000
> +
> +static u8 cc770_platform_read_reg(const struct cc770_priv *priv, int reg)
> +{
> + return in_8(priv->reg_base + reg);
> +}
> +
> +static void cc770_platform_write_reg(const struct cc770_priv *priv, int reg,
> + u8 val)
> +{
> + out_8(priv->reg_base + reg, val);
> +}
> +
> +static int __devinit cc770_get_of_node_data(struct platform_device *pdev,
> + struct cc770_priv *priv)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + const u32 *prop;
> + int prop_size;
> + u32 clkext;
> +
> + prop = of_get_property(np, "bosch,external-clock-frequency",
> + &prop_size);
> + if (prop && (prop_size == sizeof(u32)))
> + clkext = *prop;
> + else
> + clkext = CC770_PLATFORM_CAN_CLOCK; /* default */
> + priv->can.clock.freq = clkext;
> +
> + /* The system clock may not exceed 10 MHz */
> + if (priv->can.clock.freq > 10000000) {
> + priv->cpu_interface |= CPUIF_DSC;
> + priv->can.clock.freq /= 2;
> + }
> +
> + /* The memory clock may not exceed 8 MHz */
> + if (priv->can.clock.freq > 8000000)
> + priv->cpu_interface |= CPUIF_DMC;
> +
> + if (of_get_property(np, "bosch,divide-memory-clock", NULL))
> + priv->cpu_interface |= CPUIF_DMC;
> + if (of_get_property(np, "bosch,iso-low-speed-mux", NULL))
> + priv->cpu_interface |= CPUIF_MUX;
> +
> + if (!of_get_property(np, "bosch,no-comperator-bypass", NULL))
> + priv->bus_config |= BUSCFG_CBY;
> + if (of_get_property(np, "bosch,disconnect-rx0-input", NULL))
> + priv->bus_config |= BUSCFG_DR0;
> + if (of_get_property(np, "bosch,disconnect-rx1-input", NULL))
> + priv->bus_config |= BUSCFG_DR1;
> + if (of_get_property(np, "bosch,disconnect-tx1-output", NULL))
> + priv->bus_config |= BUSCFG_DT1;
> + if (of_get_property(np, "bosch,polarity-dominant", NULL))
> + priv->bus_config |= BUSCFG_POL;
> +
> + prop = of_get_property(np, "bosch,clock-out-frequency", &prop_size);
> + if (prop && (prop_size == sizeof(u32)) && *prop > 0) {
> + u32 cdv = clkext / *prop;
> + int slew;
> +
> + if (cdv > 0 && cdv < 16) {
> + priv->cpu_interface |= CPUIF_CEN;
> + priv->clkout |= (cdv - 1) & CLKOUT_CD_MASK;
> +
> + prop = of_get_property(np, "bosch,slew-rate",
> + &prop_size);
> + if (prop && (prop_size == sizeof(u32))) {
> + slew = *prop;
> + } else {
> + /* Determine default slew rate */
> + slew = (CLKOUT_SL_MASK >>
> + CLKOUT_SL_SHIFT) -
> + ((cdv * clkext - 1) / 8000000);
> + if (slew < 0)
> + slew = 0;
> + }
> + priv->clkout |= (slew << CLKOUT_SL_SHIFT) &
> + CLKOUT_SL_MASK;
> + } else {
> + dev_dbg(&pdev->dev, "invalid clock-out-frequency\n");
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int __devinit cc770_get_platform_data(struct platform_device *pdev,
> + struct cc770_priv *priv)
> +{
> +
> + struct cc770_platform_data *pdata = pdev->dev.platform_data;
> +
> + priv->can.clock.freq = pdata->osc_freq;
> + if (priv->cpu_interface | CPUIF_DSC)
> + priv->can.clock.freq /= 2;
> + priv->clkout = pdata->cor;
> + priv->bus_config = pdata->bcr;
> + priv->cpu_interface = pdata->cir;
> +
> + return 0;
> +}
> +
> +static int __devinit cc770_platform_probe(struct platform_device *pdev)
> +{
> + struct net_device *dev;
> + struct cc770_priv *priv;
> + struct resource *mem;
> + resource_size_t mem_size;
> + void __iomem *base;
> + int err, irq;
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + irq = platform_get_irq(pdev, 0);
> + if (!mem || irq <= 0)
> + return -ENODEV;
> +
> + mem_size = resource_size(mem);
> + if (!request_mem_region(mem->start, mem_size, pdev->name))
> + return -EBUSY;
> +
> + base = ioremap(mem->start, mem_size);
> + if (!base) {
> + err = -ENOMEM;
> + goto exit_release_mem;
> + }
> +
> + dev = alloc_cc770dev(0);
> + if (!dev) {
> + err = -ENOMEM;
> + goto exit_unmap_mem;
> + }
> +
> + dev->irq = irq;
> + priv = netdev_priv(dev);
> + priv->read_reg = cc770_platform_read_reg;
> + priv->write_reg = cc770_platform_write_reg;
> + priv->irq_flags = IRQF_SHARED;
> + priv->reg_base = base;
> +
> + if (pdev->dev.of_node)
> + err = cc770_get_of_node_data(pdev, priv);
> + else if (pdev->dev.platform_data)
> + err = cc770_get_platform_data(pdev, priv);
> + else
> + err = -ENODEV;
> + if (err)
> + goto exit_free_cc770;
> +
> + dev_dbg(&pdev->dev,
> + "reg_base=0x%p irq=%d clock=%d cpu_interface=0x%02x "
> + "bus_config=0x%02x clkout=0x%02x\n",
> + priv->reg_base, dev->irq, priv->can.clock.freq,
> + priv->cpu_interface, priv->bus_config, priv->clkout);
> +
> + dev_set_drvdata(&pdev->dev, dev);
> + SET_NETDEV_DEV(dev, &pdev->dev);
> +
> + err = register_cc770dev(dev);
> + if (err) {
> + dev_err(&pdev->dev,
> + "couldn't register CC700 device (err=%d)\n", err);
> + goto exit_free_cc770;
> + }
> +
> + return 0;
> +
> +exit_free_cc770:
> + free_cc770dev(dev);
> +exit_unmap_mem:
> + iounmap(base);
> +exit_release_mem:
> + release_mem_region(mem->start, mem_size);
> +
> + return err;
> +}
> +
> +static int __devexit cc770_platform_remove(struct platform_device *pdev)
> +{
> + struct net_device *dev = dev_get_drvdata(&pdev->dev);
> + struct cc770_priv *priv = netdev_priv(dev);
> + struct resource *mem;
> +
> + unregister_cc770dev(dev);
> + iounmap(priv->reg_base);
> + free_cc770dev(dev);
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
Can this fail?
> + if (mem)
> + release_mem_region(mem->start, resource_size(mem));
> + else
> + dev_err(&pdev->dev, "couldn't release mem region");
> +
> + return 0;
> +}
> +
> +static struct of_device_id __devinitdata cc770_platform_table[] = {
> + {.compatible = "bosch,cc770"}, /* CC770 from Bosch */
> + {.compatible = "intc,82527"}, /* AN82527 from Intel CP */
> + {},
> +};
> +
> +static struct platform_driver cc770_platform_driver = {
> + .driver = {
> + .name = DRV_NAME,
> + .owner = THIS_MODULE,
> + .of_match_table = cc770_platform_table,
> + },
> + .probe = cc770_platform_probe,
> + .remove = __devexit_p(cc770_platform_remove),
> +};
> +
> +module_platform_driver(cc770_platform_driver);
nice, I like the new module_platform_driver.
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [GIT PULL v2] Open vSwitch
From: Herbert Xu @ 2011-11-28 13:04 UTC (permalink / raw)
To: jhs-jkUAjuhPggJWk0Htik3J/w
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
David Miller
In-Reply-To: <1322050976.2039.125.camel@mojatatu>
On Wed, Nov 23, 2011 at 07:22:56AM -0500, jamal wrote:
>
> For a classifier, u32 or em matches would do the job - but they may
> need a wrapper around it in user space; so from a usability pov, it
> would make sense to have a new classifier that is specific to them.
> All the VLAN actions could go into one tc action; the checksum action
> is already present. The IP/TCP/UDP header re-writes may require
> their own actions - I think one would be sufficient for all.
> So in my estimate one classifier and two actions.
> Then you get rid of half the code (they use generic netlink to set/get
> policies)
You're right, a new classifier for the hash table would be the
best option.
> I cant find one - you may. After staring at the code, I am also now
> questioning if the existing bridge code couldnt have been re-used with
> some small tweaks.
I wasn't able to find any functionality that could not be easily
done with the existing classifier/action code.
Whether we want to go down this route though is open to debate
as someone would have to actually implement this :)
However, what's more worrying for me right now is the gaping
DoS opportunities that exist in the patch as is.
In particular, the whole design principle of punting all new
flows to user-space is an excellent way of attacking the system.
A would-be attacker would only need to continuously inject new
flows to prevent flow creation on all ports, since every single
port on a data path shares the same receive queue in user-space.
Considering that this is meant to be used in virtualisation
environments, where hostile entities may indeed exist on the
network, I think this needs to be addressed.
Cheers,
--
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Michal Schmidt @ 2011-11-28 13:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Valdis.Kletnieks, Tim Chen, David Miller, zheng.z.yan, yanzheng,
netdev, sfr, jirislaby, sedat.dilek, alex.shi
In-Reply-To: <1316492170.2455.43.camel@edumazet-laptop>
On 09/20/2011 06:16 AM, Eric Dumazet wrote:
> Note : The man page does states :
>
> "To receive a struct ucred message the SO_PASSCRED option must be
> enabled on the socket."
>
> But it doesnt say if the SO_PASSCRED option must be enabled before the
> sender sends its message, or before receiver attempts to read it.
>
> Once a message is queued on an unix socket, flipping SO_PASSCRED cant
> change its content (adding or removing credentials), since sender might
> already have disappeared.
>
> So current code includes credentials in all sent messages, just in case
> receiver actually fetch credentials.
>
> There are probably programs that assume they can set SO_PASSCRED right
> before calling recvmsg(). Are we taking risk to break them, or are we
> gentle and provide a sysctl option to ease the transition, I dont
> know...
Such a case has just appeared:
https://bugzilla.redhat.com/show_bug.cgi?id=757628
systemd allows on-demand socket activation of services. It creates a
listening socket without the SO_PASSCRED flag. When the first message
arrives to the socket, systemd spawns the service and passes the
socket's fd to it. The service sets SO_PASSCRED before actually
receiving the message.
I can fix that in systemd, but there may be more cases like this.
Michal
^ permalink raw reply
* [PATCH] net/can/mscan: Enable interrupts when all TX buffers are occupied to get notified when they are available again
From: Mosler, Martin @ 2011-11-28 13:25 UTC (permalink / raw)
To: linux-can@vger.kernel.org
Cc: wg@grandegger.com, socketcan@hartkopp.net,
lucas.demarchi@profusion.mobi, davem@davemloft.net,
mkl@pengutronix.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
When all TX buffers of the mscan are occupied the network layer is told to stop sending further packets. However the TX interrupts are not enabled and therefore the driver has no chance to tell the network layer when it is ready to accept further packets.
Signed-off-by: Martin Mosler <mmo@zuehlke.com>
--- linux-2.6/drivers/net/can/mscan/mscan.c.orig 2011-11-28 13:54:29.547850661 +0100
+++ linux-2.6/drivers/net/can/mscan/mscan.c 2011-11-28 13:55:52.427849601 +0100
@@ -214,6 +214,7 @@ static netdev_tx_t mscan_start_xmit(stru
case 0:
netif_stop_queue(dev);
dev_err(dev->dev.parent, "Tx Ring full when queue awake!\n");
+ out_8(®s->cantier, priv->tx_active);
return NETDEV_TX_BUSY;
case 1:
/*
^ permalink raw reply
* Re: [PATCH] net/can/mscan: Enable interrupts when all TX buffers are occupied to get notified when they are available again
From: Wolfgang Grandegger @ 2011-11-28 13:37 UTC (permalink / raw)
To: Mosler, Martin
Cc: linux-can@vger.kernel.org, socketcan@hartkopp.net,
lucas.demarchi@profusion.mobi, davem@davemloft.net,
mkl@pengutronix.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <C3745E3C7FD07D429C54EB3D7606A5A7677E7C@ZRHEX021.ads.zuehlke.com>
On 11/28/2011 02:25 PM, Mosler, Martin wrote:
> When all TX buffers of the mscan are occupied the network layer is told to stop sending further packets. However the TX interrupts are not enabled and therefore the driver has no chance to tell the network layer when it is ready to accept further packets.
>
> Signed-off-by: Martin Mosler <mmo@zuehlke.com>
>
> --- linux-2.6/drivers/net/can/mscan/mscan.c.orig 2011-11-28 13:54:29.547850661 +0100
> +++ linux-2.6/drivers/net/can/mscan/mscan.c 2011-11-28 13:55:52.427849601 +0100
> @@ -214,6 +214,7 @@ static netdev_tx_t mscan_start_xmit(stru
> case 0:
> netif_stop_queue(dev);
> dev_err(dev->dev.parent, "Tx Ring full when queue awake!\n");
> + out_8(®s->cantier, priv->tx_active);
> return NETDEV_TX_BUSY;
> case 1:
> /*
Hm, did you see the error message. Actually, it should never happen, IIRC.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Eric Dumazet @ 2011-11-28 13:38 UTC (permalink / raw)
To: Michal Schmidt
Cc: Valdis.Kletnieks, Tim Chen, David Miller, zheng.z.yan, yanzheng,
netdev, sfr, jirislaby, sedat.dilek, alex.shi
In-Reply-To: <4ED38B39.5010206@redhat.com>
Le lundi 28 novembre 2011 à 14:23 +0100, Michal Schmidt a écrit :
> On 09/20/2011 06:16 AM, Eric Dumazet wrote:
> > Note : The man page does states :
> >
> > "To receive a struct ucred message the SO_PASSCRED option must be
> > enabled on the socket."
> >
> > But it doesnt say if the SO_PASSCRED option must be enabled before the
> > sender sends its message, or before receiver attempts to read it.
> >
> > Once a message is queued on an unix socket, flipping SO_PASSCRED cant
> > change its content (adding or removing credentials), since sender might
> > already have disappeared.
> >
> > So current code includes credentials in all sent messages, just in case
> > receiver actually fetch credentials.
> >
> > There are probably programs that assume they can set SO_PASSCRED right
> > before calling recvmsg(). Are we taking risk to break them, or are we
> > gentle and provide a sysctl option to ease the transition, I dont
> > know...
>
> Such a case has just appeared:
> https://bugzilla.redhat.com/show_bug.cgi?id=757628
>
> systemd allows on-demand socket activation of services. It creates a
> listening socket without the SO_PASSCRED flag. When the first message
> arrives to the socket, systemd spawns the service and passes the
> socket's fd to it. The service sets SO_PASSCRED before actually
> receiving the message.
>
> I can fix that in systemd, but there may be more cases like this.
Yes, we were afraid of this.
Performance drop is really huge and deserves some fixes in userland...
People add features to kernel (in this case namespaces) without thinking
on performance regression. So poor guys like us have to "fix" things
later, in a reasonable way.
^ permalink raw reply
* Re: [Socketcan-users] [PATCH net-next v2 1/4] can: cc770: add driver core for the Bosch CC770 and Intel AN82527
From: Wolfgang Grandegger @ 2011-11-28 13:52 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: netdev, socketcan-users, linux-can
In-Reply-To: <4ED3704D.5020903@pengutronix.de>
Hi Marc,
thanks for reviewing...
On 11/28/2011 12:28 PM, Marc Kleine-Budde wrote:
> On 11/25/2011 10:43 AM, Wolfgang Grandegger wrote:
>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>> ---
>> drivers/net/can/Kconfig | 2 +
>> drivers/net/can/Makefile | 1 +
>> drivers/net/can/cc770/Kconfig | 3 +
>> drivers/net/can/cc770/Makefile | 7 +
>> drivers/net/can/cc770/cc770.c | 895 ++++++++++++++++++++++++++++++++++++
>> drivers/net/can/cc770/cc770.h | 234 ++++++++++
>> include/linux/can/platform/cc770.h | 33 ++
>> 7 files changed, 1175 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/net/can/cc770/Kconfig
>> create mode 100644 drivers/net/can/cc770/Makefile
>> create mode 100644 drivers/net/can/cc770/cc770.c
>> create mode 100644 drivers/net/can/cc770/cc770.h
>> create mode 100644 include/linux/can/platform/cc770.h
>
> I don't know the hardware, but the code looks good to me, some comments:
> - The driver doesn't use NAPI, can this be added
In principle yes but there is little benefit. This CAN controller does
buffer not more than two messages (on msg object 15) and bus errors are
not reported individually, therefore no irq flooding.
> - The rx-handlers have a while(1) loop
Yes, they should be limited.
> For NAPI you have to add accounting, for the non NAPI case it would
> be good, too.
> - I think you can move a large number of lines from the .h file into
> the driver. Code that's not used in the different binding drivers.
Well, not sure if it's worth the effort.
...
>> diff --git a/drivers/net/can/cc770/cc770.c b/drivers/net/can/cc770/cc770.c
>> new file mode 100644
>> index 0000000..47a6965
>> --- /dev/null
>> +++ b/drivers/net/can/cc770/cc770.c
>> @@ -0,0 +1,895 @@
>> +/*
>> + * cc770.c - Bosch CC770 and Intel AN82527 network device driver
>> + *
>> + * Copyright (C) 2009, 2011 Wolfgang Grandegger <wg@grandegger.com>
>> + *
>> + * Derived from the old Socket-CAN i82527 driver:
>> + *
>> + * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
>> + * All rights reserved.
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + * 1. Redistributions of source code must retain the above copyright
>> + * notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + * notice, this list of conditions and the following disclaimer in the
>> + * documentation and/or other materials provided with the distribution.
>> + * 3. Neither the name of Volkswagen nor the names of its contributors
>> + * may be used to endorse or promote products derived from this software
>> + * without specific prior written permission.
>> + *
>> + * Alternatively, provided that this notice is retained in full, this
>> + * software may be distributed under the terms of the GNU General
>> + * Public License ("GPL") version 2, in which case the provisions of the
>> + * GPL apply INSTEAD OF those given above.
>> + *
>> + * The provided data structures and external interfaces from this code
>> + * are not restricted to be used by modules with a GPL compatible license.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
>> + * DAMAGE.
>> + *
>> + * Send feedback to <socketcan-users@lists.berlios.de>
>
> please remove :)
Already done in v3.
>> +#include <linux/module.h>
>> +#include <linux/init.h>
>> +#include <linux/kernel.h>
>> +#include <linux/sched.h>
>> +#include <linux/types.h>
>> +#include <linux/fcntl.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/ptrace.h>
>> +#include <linux/string.h>
>> +#include <linux/errno.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/if_arp.h>
>> +#include <linux/if_ether.h>
>> +#include <linux/skbuff.h>
>> +#include <linux/delay.h>
>> +
>> +#include <linux/can.h>
>> +#include <linux/can/dev.h>
>> +#include <linux/can/error.h>
>> +#include <linux/can/dev.h>
>> +#include <linux/can/platform/cc770.h>
>> +
>> +#include "cc770.h"
>
> Can you move all the definitions that are not needed in the other
> drivers (e.g. ISA, etc.) into this .c file?
Makes sense if the bus drivers are not allowed to access chips
registers, which is currently not the case...
>> +
>> +#define DRV_NAME "cc770"
>> +
>> +MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION(DRV_NAME "CAN netdevice driver");
>> +
>> +/*
>> + * The CC770 is a CAN controller from Bosch, which is 100% compatible
>> + * with the AN82527 from Intel, but with "bugs" being fixed and some
>> + * additional functionality, mainly:
>> + *
>> + * 1. RX and TX error counters are readable.
>> + * 2. Support of silent (listen-only) mode.
>> + * 3. Message object 15 can receive all types of frames, also RTR and EFF.
>> + *
>> + * Details are available from Bosch's "CC770_Product_Info_2007-01.pdf",
>> + * which explains in detail the compatibility between the CC770 and the
>> + * 82527. This driver use the additional functionality 3. on real CC770
>> + * devices. Unfortunately, the CC770 does still not store the message
>> + * identifier of received remote transmission request frames and
>> + * therefore it's set to 0.
>> + *
>> + * The message objects 1..14 can be used for TX and RX while the message
>> + * objects 15 is optimized for RX. It has a shadow register for reliable
>> + * data receiption under heavy bus load. Therefore it makes sense to use
>> + * this message object for the needed use case. The frame type (EFF/SFF)
>> + * for the message object 15 can be defined via kernel module parameter
>> + * "msgobj15_eff". If not equal 0, it will receive 29-bit EFF frames,
>> + * otherwise 11 bit SFF messages.
>> + */
>> +static int msgobj15_eff;
>> +module_param(msgobj15_eff, int, S_IRUGO);
>> +MODULE_PARM_DESC(msgobj15_eff, "Extended 29-bit frames for message object 15 "
>> + "(default: 11-bit standard frames)");
>> +
>> +static int i82527_compat;
>> +module_param(i82527_compat, int, S_IRUGO);
>> +MODULE_PARM_DESC(i82527_compat, "Strict Intel 82527 comptibility mode "
>> + "without using additional functions");
>> +
>> +/*
>> + * This driver uses the last 5 message objects 11..15. The definitions
>> + * and structure below allows to configure and assign them to the real
>> + * message object.
>> + */
>> +static unsigned char cc770_obj_flags[CC770_OBJ_MAX] = {
>> + [CC770_OBJ_RX0] = CC770_OBJ_FLAG_RX,
>> + [CC770_OBJ_RX1] = CC770_OBJ_FLAG_RX | CC770_OBJ_FLAG_EFF,
>> + [CC770_OBJ_RX_RTR0] = CC770_OBJ_FLAG_RX | CC770_OBJ_FLAG_RTR,
>> + [CC770_OBJ_RX_RTR1] = CC770_OBJ_FLAG_RX | CC770_OBJ_FLAG_RTR |
>> + CC770_OBJ_FLAG_EFF,
>> + [CC770_OBJ_TX] = 0,
>> +};
>
> Is is worth the trouble making this a per device instance option? In a
> OF-Tree world should this become an "attribute" (or what's the correct
> of-tree word for it?)
Well, only msg object 15 does have double buffering and should therefore
be used for bulk data reception. Therefore we have for the i82527 the
module parameter:
MODULE_PARM_DESC(msgobj15_eff,
"Extended 29-bit frames for message object 15 "
"(default: 11-bit standard frames)");
For TX we currently use just one object. Anyway, the device tree is not
the right place to define such parameters because it's too static. The
user may want to select it at runtime depending on the application, if
at all. We can change it when there is a *real* requirement.
>> + for (o = 0; o < CC770_OBJ_MAX; o++) {
> ^^^^^^^^^^^^^
>
> what about ARRAY_SIZE(priv->obj_flags)
CC770_OBJ_MAX is not derived from a static array definition but as show
below:
enum {
CC770_OBJ_RX0 = 0, /* for receiving normal messages */
CC770_OBJ_RX1, /* for receiving normal messages */
CC770_OBJ_RX_RTR0, /* for receiving remote transmission requests */
CC770_OBJ_RX_RTR1, /* for receiving remote transmission requests */
CC770_OBJ_TX, /* for sending messages */
CC770_OBJ_MAX <================
};
> nitpick:
> o is probalby short for object, but usually we use "i" for a for loop
>
>> + obj_flags = priv->obj_flags[o];
>> + mo = obj2msgobj(o);
>> +
>> + if (obj_flags & CC770_OBJ_FLAG_RX) {
>> + /*
>> + * We don't need extra objects for RTR and EFF if
>> + * the additional CC770 functions are enabled.
>> + */
>> + if (priv->control_normal_mode & CTRL_EAF) {
>> + if (o > 0)
>> + continue;
>> + netdev_dbg(dev, "Message object %d for "
>> + "RX data, RTR, SFF and EFF\n", mo);
>> + } else {
>> + netdev_dbg(dev,
>> + "Message object %d for RX %s %s\n",
>> + mo, obj_flags & CC770_OBJ_FLAG_RTR ?
>> + "RTR" : "data",
>> + obj_flags & CC770_OBJ_FLAG_EFF ?
>> + "EFF" : "SFF");
>> + }
>> +
>> + if (obj_flags & CC770_OBJ_FLAG_EFF)
>> + msgcfg = MSGCFG_XTD;
>> + else
>> + msgcfg = 0;
>> + if (obj_flags & CC770_OBJ_FLAG_RTR)
>> + msgcfg |= MSGCFG_DIR;
>> +
>> + cc770_write_reg(priv, msgobj[mo].config, msgcfg);
>> + cc770_write_reg(priv, msgobj[mo].ctrl0,
>> + MSGVAL_SET | TXIE_RES |
>> + RXIE_SET | INTPND_RES);
>> +
>> + if (obj_flags & CC770_OBJ_FLAG_RTR)
>> + cc770_write_reg(priv, msgobj[mo].ctrl1,
>> + NEWDAT_RES | CPUUPD_SET |
>> + TXRQST_RES | RMTPND_RES);
>> + else
>> + cc770_write_reg(priv, msgobj[mo].ctrl1,
>> + NEWDAT_RES | MSGLST_RES |
>> + TXRQST_RES | RMTPND_RES);
>> + } else {
>> + netdev_dbg(dev, "Message object %d for "
>> + "TX data, RTR, SFF and EFF\n", mo);
>> +
>> + cc770_write_reg(priv, msgobj[mo].ctrl1,
>> + RMTPND_RES | TXRQST_RES |
>> + CPUUPD_RES | NEWDAT_RES);
>> + cc770_write_reg(priv, msgobj[mo].ctrl0,
>> + MSGVAL_RES | TXIE_RES |
>> + RXIE_RES | INTPND_RES);
>> + }
>> + }
>> +}
>> +
>> +static void disable_all_objs(const struct cc770_priv *priv)
>> +{
>> + int i, mo;
>
> here you use "i"
OK, will fix.
>> +static int cc770_probe_chip(struct net_device *dev)
>
> nitpick: This chip returns 1 on success and 0 on failure, IMHO unusual
> return value. Why not make it return -ENODEV in case of failure?
OK, will fix.
...
> Are these Hex numbers arbitrary values?
Looks like. Not really a clever probing, though. A comment would be
useful, at least.
>> + cc770_write_reg(priv, msgobj[1].data[1], 0x25);
>> + cc770_write_reg(priv, msgobj[2].data[3], 0x52);
>> + cc770_write_reg(priv, msgobj[10].data[6], 0xc3);
>> + if ((cc770_read_reg(priv, msgobj[1].data[1]) != 0x25) ||
>> + (cc770_read_reg(priv, msgobj[2].data[3]) != 0x52) ||
>> + (cc770_read_reg(priv, msgobj[10].data[6]) != 0xc3)) {
>> + netdev_info(dev, "probing @0x%p failed (pattern)\n",
>> + priv->reg_base);
>> + return 0;
>> + }
>> +
>> + /* Check if this chip is a CC770 supporting additional functions */
>> + if (cc770_read_reg(priv, control) & CTRL_EAF)
>> + priv->control_normal_mode |= CTRL_EAF;
>> +
>> + return 1;
>> +}
>> +
>> +static void cc770_start(struct net_device *dev)
>> +{
>> + struct cc770_priv *priv = netdev_priv(dev);
>> +
>> + /* leave reset mode */
>> + if (priv->can.state != CAN_STATE_STOPPED)
>> + set_reset_mode(dev);
>> +
>> + /* leave reset mode */
>> + set_normal_mode(dev);
>> +}
>> +
>> +static int cc770_set_mode(struct net_device *dev, enum can_mode mode)
>> +{
>> + struct cc770_priv *priv = netdev_priv(dev);
>> +
>> + if (!priv->open_time)
>> + return -EINVAL;
>> +
>> + switch (mode) {
>> + case CAN_MODE_START:
>> + cc770_start(dev);
>> + if (netif_queue_stopped(dev))
>> + netif_wake_queue(dev);
>
> The "if (netif_queue_stopped(dev))" is not needed.
OK.
>> + if (id & CAN_EFF_FLAG) {
>> + id &= CAN_EFF_MASK;
>> + cc770_write_reg(priv, msgobj[mo].config,
>> + (dlc << 4) + rtr + MSGCFG_XTD);
>
> + is the same as | here, but IMHO bitwise or is more common coding styele.
OK, will fix.
>> + cc770_write_reg(priv, msgobj[mo].id[3],
>> + (id << 3) & 0xFFU);
>> + cc770_write_reg(priv, msgobj[mo].id[2],
>> + (id >> 5) & 0xFFU);
>> + cc770_write_reg(priv, msgobj[mo].id[1],
>> + (id >> 13) & 0xFFU);
>> + cc770_write_reg(priv, msgobj[mo].id[0],
>> + (id >> 21) & 0xFFU);
>
> msgobj[].id[] is an u8, so & 0xff is not needed.
OK.
>> + } else {
>> + id &= CAN_SFF_MASK;
>> + cc770_write_reg(priv, msgobj[mo].config,
>> + (dlc << 4) + rtr);
>> + cc770_write_reg(priv, msgobj[mo].id[0],
>> + (id >> 3) & 0xFFU);
>> + cc770_write_reg(priv, msgobj[mo].id[1],
>> + (id << 5) & 0xFFU);
> dito
>> + }
>> +
>> + dlc &= 0x0f; /* restore length only */
>
> is this needed? The dlc should be valid.
No, can_dropped_invalid_skb() already does the check before.
>> + for (i = 0; i < dlc; i++)
>> + cc770_write_reg(priv, msgobj[mo].data[i], cf->data[i]);
>> +
>> + cc770_write_reg(priv, msgobj[mo].ctrl1,
>> + RMTPND_RES | TXRQST_SET | CPUUPD_RES | NEWDAT_UNC);
>> +
>> + stats->tx_bytes += dlc;
>> +
>> + can_put_echo_skb(skb, dev, 0);
>> +
>> + /*
>> + * HM: We had some cases of repeated IRQs so make sure the
>
> Who is HM?
Don't know ;-(.
>> + if (ctrl1 & RMTPND_SET) {
>> + /*
>> + * Unfortunately, the chip does not store the real message
>> + * identifier of the received remote transmission request
>> + * frame. Therefore we set it to 0.
>
> What a bug!
Well, it's a basic CAN controller, which is usually handled in a
different way (a CAN id is handled by a dedicated msg object).
>> + skb = alloc_can_err_skb(dev, &cf);
>> + if (skb == NULL)
> !skb
Ok, will change.
>> +static void cc770_rx_interrupt(struct net_device *dev, unsigned int o)
>> +{
>> + struct cc770_priv *priv = netdev_priv(dev);
>> + struct net_device_stats *stats = &dev->stats;
>> + unsigned int mo = obj2msgobj(o);
>> + u8 ctrl1;
>> +
>> + while (1) {
>
> What about limiting this?
It does make sense.
>> + err = request_irq(dev->irq, &cc770_interrupt, priv->irq_flags,
>> + dev->name, (void *)dev);
>
> the (void *) cast ist not needed
OK.
>> + if (err) {
>> + close_candev(dev);
>> + return -EAGAIN;
>> + }
>> +
>> + /* init and start chip */
>> + cc770_start(dev);
>> + priv->open_time = jiffies;
>
> open_time is used to track if the netdev is open, right? Can we use
> "ndev->flags & IFF_UP" instead?
Probably, we have similar code in the sja1000.c but not in any other
driver. It is just used in cc770_set_mode(). I guess it's not needed at
all. I will remove it therefore. Need to check if there is a race with
can_restart(), though.
>> +
>> + netif_start_queue(dev);
>> +
>> + return 0;
>> +}
>> +
>> +static int cc770_close(struct net_device *dev)
>> +{
>> + struct cc770_priv *priv = netdev_priv(dev);
>> +
>> + netif_stop_queue(dev);
>> + set_reset_mode(dev);
>> +
>> + free_irq(dev->irq, (void *)dev);
> cast not needed
OK.
...
>> +static __init int cc770_init(void)
>> +{
>> + if (msgobj15_eff) {
>> + cc770_obj_flags[CC770_OBJ_RX0] |= CC770_OBJ_FLAG_EFF;
>> + cc770_obj_flags[CC770_OBJ_RX1] &= ~CC770_OBJ_FLAG_EFF;
>> + }
>> +
>> + pr_info("%s CAN netdevice driver\n", DRV_NAME);
>
> You can add a #define pr_fmt(fmt), to get rid of the "%s", DRV_NAME.
Will add:
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> diff --git a/drivers/net/can/cc770/cc770.h b/drivers/net/can/cc770/cc770.h
>> new file mode 100644
>> index 0000000..c6b5800
>> --- /dev/null
>> +++ b/drivers/net/can/cc770/cc770.h
>> @@ -0,0 +1,234 @@
>> +/*
>> + * cc770.h - Bosch CC770 and Intel AN82527 network device driver
>> + *
>> + * Copyright (C) 2009, 2011 Wolfgang Grandegger <wg@grandegger.com>
>> + *
>> + * Derived from the old Socket-CAN i82527 driver:
>> + *
>> + * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
>> + * All rights reserved.
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + * 1. Redistributions of source code must retain the above copyright
>> + * notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + * notice, this list of conditions and the following disclaimer in the
>> + * documentation and/or other materials provided with the distribution.
>> + * 3. Neither the name of Volkswagen nor the names of its contributors
>> + * may be used to endorse or promote products derived from this software
>> + * without specific prior written permission.
>> + *
>> + * Alternatively, provided that this notice is retained in full, this
>> + * software may be distributed under the terms of the GNU General
>> + * Public License ("GPL") version 2, in which case the provisions of the
>> + * GPL apply INSTEAD OF those given above.
>> + *
>> + * The provided data structures and external interfaces from this code
>> + * are not restricted to be used by modules with a GPL compatible license.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
>> + * DAMAGE.
>> + *
>> + * Send feedback to <socketcan-users@lists.berlios.de>
>
> please remove
Already done in v3.
Wolfgang.
^ permalink raw reply
* Re: [GIT PULL v2] Open vSwitch
From: Fischer, Anna @ 2011-11-28 13:54 UTC (permalink / raw)
To: Herbert Xu, jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Miller
In-Reply-To: <20111128130409.GB16828-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
> Subject: Re: [GIT PULL v2] Open vSwitch
>
> On Wed, Nov 23, 2011 at 07:22:56AM -0500, jamal wrote:
> >
> > For a classifier, u32 or em matches would do the job - but they may
> > need a wrapper around it in user space; so from a usability pov, it
> > would make sense to have a new classifier that is specific to them.
> > All the VLAN actions could go into one tc action; the checksum action
> > is already present. The IP/TCP/UDP header re-writes may require
> > their own actions - I think one would be sufficient for all.
> > So in my estimate one classifier and two actions.
> > Then you get rid of half the code (they use generic netlink to
> set/get
> > policies)
>
> You're right, a new classifier for the hash table would be the
> best option.
>
> > I cant find one - you may. After staring at the code, I am also now
> > questioning if the existing bridge code couldnt have been re-used
> with
> > some small tweaks.
>
> I wasn't able to find any functionality that could not be easily
> done with the existing classifier/action code.
>
> Whether we want to go down this route though is open to debate
> as someone would have to actually implement this :)
>
> However, what's more worrying for me right now is the gaping
> DoS opportunities that exist in the patch as is.
>
> In particular, the whole design principle of punting all new
> flows to user-space is an excellent way of attacking the system.
>
> A would-be attacker would only need to continuously inject new
> flows to prevent flow creation on all ports, since every single
> port on a data path shares the same receive queue in user-space.
>
> Considering that this is meant to be used in virtualisation
> environments, where hostile entities may indeed exist on the
> network, I think this needs to be addressed.
Yes, I mentioned this months ago, and I am surprised this critical issue has never been picked up on and addressed. With a flaw like this there is no chance this component can be used in any serious virtualization deployment where different customers share the same physical server.
The path up to user-space needs to be designed in a multi-queue fashion, so that each vPort has its own queue up to user-space. Ideally those queues also need to be rate controlled in some form, so that no DoS is possible.
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: Wolfgang Grandegger @ 2011-11-28 13:59 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w,
linux-can-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4ED379F3.1070206-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 11/28/2011 01:09 PM, Marc Kleine-Budde wrote:
> On 11/25/2011 10:43 AM, Wolfgang Grandegger wrote:
>> This patch adds support for legacy Bosch CC770 and Intel AN82527 CAN
>> controllers on the ISA or PC-104 bus. The I/O port or memory address
>> and the IRQ number must be specified via module parameters:
>>
>> insmod cc770_isa.ko port=0x310,0x380 irq=7,11
>>
>> for ISA devices using I/O ports or:
>>
>> insmod cc770_isa.ko mem=0xd1000,0xd1000 irq=7,11
>>
>> for memory mapped ISA devices.
>>
>> Indirect access via address and data port is supported as well:
>>
>> insmod cc770_isa.ko port=0x310,0x380 indirect=1 irq=7,11
>>
>> Furthermore, the following mode parameter can be defined:
>>
>> clk: External oscillator clock frequency (default=16000000 [16 MHz])
>> cir: CPU interface register (default=0x40 [DSC])
>> ocr, Bus configuration register (default=0x40 [CBY])
>> cor, Clockout register (default=0x00)
>>
>> Note: for clk, cir, bcr and cor, the first argument re-defines the
>> default for all other devices, e.g.:
>>
>> insmod cc770_isa.ko mem=0xd1000,0xd1000 irq=7,11 clk=24000000
>>
>> is equivalent to
>>
>> insmod cc770_isa.ko mem=0xd1000,0xd1000 irq=7,11 clk=24000000,24000000
>>
>> Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>
> Some nitpicking inside.
>
> Marc
>> ---
>> drivers/net/can/cc770/Kconfig | 11 ++
>> drivers/net/can/cc770/Makefile | 1 +
>> drivers/net/can/cc770/cc770_isa.c | 336 +++++++++++++++++++++++++++++++++++++
>> 3 files changed, 348 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/net/can/cc770/cc770_isa.c
>>
>> diff --git a/drivers/net/can/cc770/Kconfig b/drivers/net/can/cc770/Kconfig
>> index 225131b..28e4d48 100644
>> --- a/drivers/net/can/cc770/Kconfig
>> +++ b/drivers/net/can/cc770/Kconfig
>> @@ -1,3 +1,14 @@
>> menuconfig CAN_CC770
>> tristate "Bosch CC770 and Intel AN82527 devices"
>> depends on CAN_DEV && HAS_IOMEM
>> +
>> +if CAN_CC770
>> +
>> +config CAN_CC770_ISA
>> + tristate "ISA Bus based legacy CC770 driver"
>> + ---help---
>> + This driver adds legacy support for CC770 and AN82527 chips
>> + connected to the ISA bus using I/O port, memory mapped or
>> + indirect access.
>> +
>> +endif
>> diff --git a/drivers/net/can/cc770/Makefile b/drivers/net/can/cc770/Makefile
>> index 34e8180..872ecff 100644
>> --- a/drivers/net/can/cc770/Makefile
>> +++ b/drivers/net/can/cc770/Makefile
>> @@ -3,5 +3,6 @@
>> #
>>
>> obj-$(CONFIG_CAN_CC770) += cc770.o
>> +obj-$(CONFIG_CAN_CC770_ISA) += cc770_isa.o
>>
>> ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
>> diff --git a/drivers/net/can/cc770/cc770_isa.c b/drivers/net/can/cc770/cc770_isa.c
...
>> + for (idx = 0; idx < MAXDEV; idx++) {
> ARRAY_SIZE?
Well, I think ARRAY_SIZE is useful to derive the number of elements from
a static array of the type:
static const int array[] = { 1, 2, 3, 4, }
but not if its declared as:
static array[MAXDEV]:
... or have I missed something?
I'm fine with all other comments.
Wolfgang.
^ permalink raw reply
* AW: [PATCH] net/can/mscan: Enable interrupts when all TX buffers are occupied to get notified when they are available again
From: Mosler, Martin @ 2011-11-28 13:59 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: linux-can@vger.kernel.org, socketcan@hartkopp.net,
lucas.demarchi@profusion.mobi, davem@davemloft.net,
mkl@pengutronix.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4ED38EB1.6030806@grandegger.com>
>> When all TX buffers of the mscan are occupied the network layer is told to stop sending further packets. However the TX interrupts are not enabled and therefore the driver has no chance to tell the network layer when it is ready to accept further packets.
>>
>> Signed-off-by: Martin Mosler <mmo@zuehlke.com>
>>
>> --- linux-2.6/drivers/net/can/mscan/mscan.c.orig 2011-11-28 13:54:29.547850661 +0100
>> +++ linux-2.6/drivers/net/can/mscan/mscan.c 2011-11-28 13:55:52.427849601 +0100
>> @@ -214,6 +214,7 @@ static netdev_tx_t mscan_start_xmit(stru
>> case 0:
>> netif_stop_queue(dev);
>> dev_err(dev->dev.parent, "Tx Ring full when queue awake!\n");
>> + out_8(®s->cantier, priv->tx_active);
>> return NETDEV_TX_BUSY;
>> case 1:
>> /*
>
>Hm, did you see the error message. Actually, it should never happen, IIRC.
>
>Wolfgang.
It is in fact a very rare condition, but it was triggered during testing when pulling CAN-HI and CAN-LO lines
to GND and VCC in various combinations to verify how the system is recovering. I am working with a MPC5125
if this is valuable information. (This was only one issue I ran into, I had to do other modifications for other
issues as well, but I think they are chip specific, I'll share them in a separate thread if you like).
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] can: cc770: add driver core for the Bosch CC770 and Intel AN82527
From: Marc Kleine-Budde @ 2011-11-28 14:01 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w,
linux-can-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4ED3922A.50704-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2360 bytes --]
On 11/28/2011 02:52 PM, Wolfgang Grandegger wrote:
[...]
>>> +/*
>>> + * This driver uses the last 5 message objects 11..15. The definitions
>>> + * and structure below allows to configure and assign them to the real
>>> + * message object.
>>> + */
>>> +static unsigned char cc770_obj_flags[CC770_OBJ_MAX] = {
>>> + [CC770_OBJ_RX0] = CC770_OBJ_FLAG_RX,
>>> + [CC770_OBJ_RX1] = CC770_OBJ_FLAG_RX | CC770_OBJ_FLAG_EFF,
>>> + [CC770_OBJ_RX_RTR0] = CC770_OBJ_FLAG_RX | CC770_OBJ_FLAG_RTR,
>>> + [CC770_OBJ_RX_RTR1] = CC770_OBJ_FLAG_RX | CC770_OBJ_FLAG_RTR |
>>> + CC770_OBJ_FLAG_EFF,
>>> + [CC770_OBJ_TX] = 0,
>>> +};
>>
>> Is is worth the trouble making this a per device instance option? In a
>> OF-Tree world should this become an "attribute" (or what's the correct
>> of-tree word for it?)
>
> Well, only msg object 15 does have double buffering and should therefore
> be used for bulk data reception. Therefore we have for the i82527 the
> module parameter:
>
> MODULE_PARM_DESC(msgobj15_eff,
> "Extended 29-bit frames for message object 15 "
> "(default: 11-bit standard frames)");
>
> For TX we currently use just one object. Anyway, the device tree is not
> the right place to define such parameters because it's too static. The
> user may want to select it at runtime depending on the application, if
> at all. We can change it when there is a *real* requirement.
Fine with me.
>>> + for (o = 0; o < CC770_OBJ_MAX; o++) {
>> ^^^^^^^^^^^^^
>>
>> what about ARRAY_SIZE(priv->obj_flags)
>
> CC770_OBJ_MAX is not derived from a static array definition but as show
> below:
Okay...
> enum {
> CC770_OBJ_RX0 = 0, /* for receiving normal messages */
> CC770_OBJ_RX1, /* for receiving normal messages */
> CC770_OBJ_RX_RTR0, /* for receiving remote transmission requests */
> CC770_OBJ_RX_RTR1, /* for receiving remote transmission requests */
> CC770_OBJ_TX, /* for sending messages */
> CC770_OBJ_MAX <================
...then add a "," here :P
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 191 bytes --]
_______________________________________________
Socketcan-users mailing list
Socketcan-users-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply
* RE: [Socketcan-users] [PATCH net-next v2 1/4] can: cc770: add driver core for the Bosch CC770 and Intel AN82527
From: David Laight @ 2011-11-28 14:01 UTC (permalink / raw)
To: Marc Kleine-Budde, Wolfgang Grandegger; +Cc: netdev, socketcan-users, linux-can
In-Reply-To: <4ED3941D.3070302@pengutronix.de>
> > enum {
> > CC770_OBJ_RX0 = 0, /* for receiving normal messages */
> > CC770_OBJ_RX1, /* for receiving normal messages */
> > CC770_OBJ_RX_RTR0, /* for receiving remote transmission
requests */
> > CC770_OBJ_RX_RTR1, /* for receiving remote transmission
requests */
> > CC770_OBJ_TX, /* for sending messages */
> > CC770_OBJ_MAX <================
>
> ...then add a "," here :P
Not if the code might have to go through the C++ compiler.
C++ doesn't allow a trailing , in enums (some compilers
will error this....).
David
^ permalink raw reply
* Re: [GIT PULL v2] Open vSwitch
From: Jamal Hadi Salim @ 2011-11-28 14:02 UTC (permalink / raw)
To: Herbert Xu
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
David Miller
In-Reply-To: <20111128130409.GB16828-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On Mon, 2011-11-28 at 21:04 +0800, Herbert Xu wrote:
> You're right, a new classifier for the hash table would be the
> best option.
>
> > I cant find one - you may. After staring at the code, I am also now
> > questioning if the existing bridge code couldnt have been re-used with
> > some small tweaks.
>
> I wasn't able to find any functionality that could not be easily
> done with the existing classifier/action code.
Thanks for validating Herbert.
> Whether we want to go down this route though is open to debate
> as someone would have to actually implement this :)
I empathize that effort has been invested in coding the way it was.
But this is where an RFC to netdev would have been useful instead of
reinventing things. I dont see it as a huge effort really; the
refactoring should be mostly in user space.
Along the same lines:
Even for the integration with existing silicon I am worried that using
openvswitch as a proxy is not the right thing to do (the Intel approach
or the DSA approach where Linux is the proxy is the right thing to
do(TM).
> However, what's more worrying for me right now is the gaping
> DoS opportunities that exist in the patch as is.
>
> In particular, the whole design principle of punting all new
> flows to user-space is an excellent way of attacking the system.
Indeed this is an issue with openflow in general.
The general solution is to rate limit how much goes to the controller
but even that is insufficient.
cheers,
jamal
^ permalink raw reply
* RE: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: David Laight @ 2011-11-28 14:03 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: netdev, linux-can, socketcan-users, IreneV, Stanislav Yelenskiy
In-Reply-To: <4ED393B0.2030004@grandegger.com>
...
> >> + for (idx = 0; idx < MAXDEV; idx++) {
> > ARRAY_SIZE?
>
> Well, I think ARRAY_SIZE is useful to derive the number of
> elements from a static array of the type:
>
> static const int array[] = { 1, 2, 3, 4, }
>
> but not if its declared as:
>
> static array[MAXDEV]:
>
> ... or have I missed something?
Yes - if you use ARRAY_SIZE() then someone reading the code
doesn't need to find the array definition to ensure the loop
upper bound is correct.
David
^ permalink raw reply
* Issues with openflow protocol WAS(RE: [GIT PULL v2] Open vSwitch
From: Jamal Hadi Salim @ 2011-11-28 14:07 UTC (permalink / raw)
To: Fischer, Anna
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Herbert Xu,
David Miller
In-Reply-To: <0199E0D51A61344794750DC57738F58E7586A74137-1IhDuF6AwYvulpxXP3Mx0dVKv6DIAtwysh7EHKopUjU@public.gmane.org>
On Mon, 2011-11-28 at 13:54 +0000, Fischer, Anna wrote:
> Yes, I mentioned this months ago, and I am surprised this critical
> issue has never been picked up on and addressed. With a flaw like
> this there is no chance this component can be used in any serious
> virtualization deployment where different customers share the same physical server.
>
> The path up to user-space needs to be designed in a multi-queue fashion, so that
> each vPort has its own queue up to user-space. Ideally those queues also need to
> be rate controlled in some form, so that no DoS is possible.
Good - more folks scrutinizing openflow ;->
That would resolve the kernel->user if in addition you then add
prioritization of those queues.
But even then also the same problem exists with open flow in the
northbound direction towards the external controller where
there is a single (TCP) socket.
cheers,
jamal
^ permalink raw reply
* Re: AW: [PATCH] net/can/mscan: Enable interrupts when all TX buffers are occupied to get notified when they are available again
From: Wolfgang Grandegger @ 2011-11-28 14:08 UTC (permalink / raw)
To: Mosler, Martin
Cc: linux-can@vger.kernel.org, socketcan@hartkopp.net,
lucas.demarchi@profusion.mobi, davem@davemloft.net,
mkl@pengutronix.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <C3745E3C7FD07D429C54EB3D7606A5A7677EB2@ZRHEX021.ads.zuehlke.com>
On 11/28/2011 02:59 PM, Mosler, Martin wrote:
>>> When all TX buffers of the mscan are occupied the network layer is told to stop sending further packets. However the TX interrupts are not enabled and therefore the driver has no chance to tell the network layer when it is ready to accept further packets.
>>>
>>> Signed-off-by: Martin Mosler <mmo@zuehlke.com>
>>>
>>> --- linux-2.6/drivers/net/can/mscan/mscan.c.orig 2011-11-28 13:54:29.547850661 +0100
>>> +++ linux-2.6/drivers/net/can/mscan/mscan.c 2011-11-28 13:55:52.427849601 +0100
>>> @@ -214,6 +214,7 @@ static netdev_tx_t mscan_start_xmit(stru
>>> case 0:
>>> netif_stop_queue(dev);
>>> dev_err(dev->dev.parent, "Tx Ring full when queue awake!\n");
>>> + out_8(®s->cantier, priv->tx_active);
>>> return NETDEV_TX_BUSY;
>>> case 1:
>>> /*
>>
>> Hm, did you see the error message. Actually, it should never happen, IIRC.
>>
>> Wolfgang.
>
> It is in fact a very rare condition, but it was triggered during testing when pulling CAN-HI and CAN-LO lines
> to GND and VCC in various combinations to verify how the system is recovering. I am working with a MPC5125
> if this is valuable information. (This was only one issue I ran into, I had to do other modifications for other
> issues as well, but I think they are chip specific, I'll share them in a separate thread if you like).
Sounds like a problem with bus-off recovery. The software has restarted
the queue but the TX objects are still active. How do you handle
bus-offs? Manually? restart-ms = ?
Would be great if you post patches for your other issues.
Wolfgang.
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: Marc Kleine-Budde @ 2011-11-28 14:09 UTC (permalink / raw)
To: David Laight
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-can-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w, Wolfgang Grandegger
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AEE9-CgBM+Bx2aUAnGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 862 bytes --]
On 11/28/2011 03:03 PM, David Laight wrote:
>>>> + for (idx = 0; idx < MAXDEV; idx++) {
>>> ARRAY_SIZE?
>>
>> Well, I think ARRAY_SIZE is useful to derive the number of
>> elements from a static array of the type:
>>
>> static const int array[] = { 1, 2, 3, 4, }
>>
>> but not if its declared as:
>>
>> static array[MAXDEV]:
>>
>> ... or have I missed something?
>
> Yes - if you use ARRAY_SIZE() then someone reading the code
> doesn't need to find the array definition to ensure the loop
> upper bound is correct.
Yep, that
was my intention, too.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 191 bytes --]
_______________________________________________
Socketcan-users mailing list
Socketcan-users-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] can: cc770: add driver core for the Bosch CC770 and Intel AN82527
From: Wolfgang Grandegger @ 2011-11-28 14:10 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w,
linux-can-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4ED3941D.3070302-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 11/28/2011 03:01 PM, Marc Kleine-Budde wrote:
> On 11/28/2011 02:52 PM, Wolfgang Grandegger wrote:
>
> [...]
>
>>>> +/*
>>>> + * This driver uses the last 5 message objects 11..15. The definitions
>>>> + * and structure below allows to configure and assign them to the real
>>>> + * message object.
>>>> + */
>>>> +static unsigned char cc770_obj_flags[CC770_OBJ_MAX] = {
>>>> + [CC770_OBJ_RX0] = CC770_OBJ_FLAG_RX,
>>>> + [CC770_OBJ_RX1] = CC770_OBJ_FLAG_RX | CC770_OBJ_FLAG_EFF,
>>>> + [CC770_OBJ_RX_RTR0] = CC770_OBJ_FLAG_RX | CC770_OBJ_FLAG_RTR,
>>>> + [CC770_OBJ_RX_RTR1] = CC770_OBJ_FLAG_RX | CC770_OBJ_FLAG_RTR |
>>>> + CC770_OBJ_FLAG_EFF,
>>>> + [CC770_OBJ_TX] = 0,
>>>> +};
>>>
>>> Is is worth the trouble making this a per device instance option? In a
>>> OF-Tree world should this become an "attribute" (or what's the correct
>>> of-tree word for it?)
>>
>> Well, only msg object 15 does have double buffering and should therefore
>> be used for bulk data reception. Therefore we have for the i82527 the
>> module parameter:
>>
>> MODULE_PARM_DESC(msgobj15_eff,
>> "Extended 29-bit frames for message object 15 "
>> "(default: 11-bit standard frames)");
>>
>> For TX we currently use just one object. Anyway, the device tree is not
>> the right place to define such parameters because it's too static. The
>> user may want to select it at runtime depending on the application, if
>> at all. We can change it when there is a *real* requirement.
>
> Fine with me.
>
>>>> + for (o = 0; o < CC770_OBJ_MAX; o++) {
>>> ^^^^^^^^^^^^^
>>>
>>> what about ARRAY_SIZE(priv->obj_flags)
>>
>> CC770_OBJ_MAX is not derived from a static array definition but as show
>> below:
>
> Okay...
>
>> enum {
>> CC770_OBJ_RX0 = 0, /* for receiving normal messages */
>> CC770_OBJ_RX1, /* for receiving normal messages */
>> CC770_OBJ_RX_RTR0, /* for receiving remote transmission requests */
>> CC770_OBJ_RX_RTR1, /* for receiving remote transmission requests */
>> CC770_OBJ_TX, /* for sending messages */
>> CC770_OBJ_MAX <================
>
> ...then add a "," here :P
Why?
Wolfgang.
^ permalink raw reply
* AW: AW: [PATCH] net/can/mscan: Enable interrupts when all TX buffers are occupied to get notified when they are available again
From: Mosler, Martin @ 2011-11-28 14:13 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: linux-can@vger.kernel.org, socketcan@hartkopp.net,
lucas.demarchi@profusion.mobi, davem@davemloft.net,
mkl@pengutronix.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4ED395C8.5070009@grandegger.com>
>>>> When all TX buffers of the mscan are occupied the network layer is told to stop sending further packets. However the TX interrupts are not enabled and therefore the driver has no chance to tell the network layer when it is ready to accept further packets.
>>>>
>>>> Signed-off-by: Martin Mosler <mmo@zuehlke.com>
>>>>
>>>> --- linux-2.6/drivers/net/can/mscan/mscan.c.orig 2011-11-28 13:54:29.547850661 +0100
>>>> +++ linux-2.6/drivers/net/can/mscan/mscan.c 2011-11-28 13:55:52.427849601 +0100
>>>> @@ -214,6 +214,7 @@ static netdev_tx_t mscan_start_xmit(stru
>>>> case 0:
>>>> netif_stop_queue(dev);
>>>> dev_err(dev->dev.parent, "Tx Ring full when queue awake!\n");
>>>> + out_8(®s->cantier, priv->tx_active);
>>>> return NETDEV_TX_BUSY;
>>>> case 1:
>>>> /*
>>>
>>> Hm, did you see the error message. Actually, it should never happen, IIRC.
>>>
>>> Wolfgang.
>>
>> It is in fact a very rare condition, but it was triggered during testing when pulling CAN-HI and CAN-LO lines
>> to GND and VCC in various combinations to verify how the system is recovering. I am working with a MPC5125
>> if this is valuable information. (This was only one issue I ran into, I had to do other modifications for other
>> issues as well, but I think they are chip specific, I'll share them in a separate thread if you like).
>
>Sounds like a problem with bus-off recovery. The software has restarted
>the queue but the TX objects are still active. How do you handle
>bus-offs? Manually? restart-ms = ?
>
>Would be great if you post patches for your other issues.
>
>Wolfgang.
We are using restart-ms = 500 for now.
I'll post the other patches after I know I did the submit process correctly for this one and when I reviewed
them more closely, as it is my first submission to the kernel.
^ permalink raw reply
* iwlagn failed resume from S3
From: Udo Steinberg @ 2011-11-28 14:14 UTC (permalink / raw)
To: Guy, Wey-Yi, Linux Kernel Mailing List
Cc: Linux Network Mailing List, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 13318 bytes --]
Hi,
After coming out of Suspend-to-RAM with Linux-3.1.0, the Centrino Advanced-N
6205 WiFi failed to resume with the following warnings in dmesg. So far this
has happened just once and it's not easily reproducible.
Cheers,
- Udo
iwlagn 0000:03:00.0: restoring config space at offset 0xf (was 0x100, writing 0x1ff)
iwlagn 0000:03:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xf2500004)
iwlagn 0000:03:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
iwlagn 0000:03:00.0: L1 Disabled; Enabling L0S
iwlagn 0000:03:00.0: Radio type=0x1-0x2-0x0
------------[ cut here ]------------
WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c:765 iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]()
Hardware name: 4290W4H
wrong command queue 2 (should be 9), sequence 0x2FA readp=0 writep=0
Modules linked in: iwlagn
Pid: 0, comm: swapper Not tainted 3.1.0 #1
Call Trace:
<IRQ> [<ffffffff81036e2d>] ? warn_slowpath_common+0x78/0x8c
[<ffffffff81036ee2>] ? warn_slowpath_fmt+0x45/0x4a
[<ffffffffa0027199>] ? iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]
[<ffffffffa001c15c>] ? iwl_rx_dispatch+0x147/0x20f [iwlagn]
[<ffffffffa00251d0>] ? iwl_irq_tasklet+0x7c9/0xb52 [iwlagn]
[<ffffffffa0025fc3>] ? iwl_isr_ict+0x563/0x628 [iwlagn]
[<ffffffff8103b439>] ? tasklet_action+0x67/0xa7
[<ffffffff8103b95b>] ? __do_softirq+0x7f/0x106
[<ffffffff813c10ec>] ? call_softirq+0x1c/0x26
[<ffffffff8100351e>] ? do_softirq+0x31/0x67
[<ffffffff8103bc0f>] ? irq_exit+0x44/0xb0
[<ffffffff8100325f>] ? do_IRQ+0x94/0xad
[<ffffffff813bf62b>] ? common_interrupt+0x6b/0x6b
<EOI> [<ffffffff8104fe71>] ? __hrtimer_start_range_ns+0x2c6/0x2d9
[<ffffffff81190656>] ? intel_idle+0xcd/0xe9
[<ffffffff81190632>] ? intel_idle+0xa9/0xe9
[<ffffffff812cb231>] ? cpuidle_idle_call+0xa0/0xdb
[<ffffffff810007b9>] ? cpu_idle+0x53/0x7c
[<ffffffff816869fa>] ? start_kernel+0x2be/0x2c9
---[ end trace 0107c607401edcc1 ]---
iwl data: 00000000: 00 00 35 02 00 00 fa 02 00 00 34 02 00 00 fa 02 ..5.......4.....
iwl data: 00000010: 00 00 35 02 00 00 34 02 00 00 35 02 00 00 f7 02 ..5...4...5.....
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 209 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 215 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 221 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 214 is out of range [0-256] 0 0.
------------[ cut here ]------------
WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c:765 iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]()
Hardware name: 4290W4H
wrong command queue 20 (should be 9), sequence 0x1447 readp=0 writep=0
Modules linked in: iwlagn
Pid: 0, comm: swapper Tainted: G W 3.1.0 #1
Call Trace:
<IRQ> [<ffffffff81036e2d>] ? warn_slowpath_common+0x78/0x8c
[<ffffffff81036ee2>] ? warn_slowpath_fmt+0x45/0x4a
[<ffffffffa0027199>] ? iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]
[<ffffffffa001c15c>] ? iwl_rx_dispatch+0x147/0x20f [iwlagn]
[<ffffffffa00251d0>] ? iwl_irq_tasklet+0x7c9/0xb52 [iwlagn]
[<ffffffffa0025fc3>] ? iwl_isr_ict+0x563/0x628 [iwlagn]
[<ffffffff8103b439>] ? tasklet_action+0x67/0xa7
[<ffffffff8103b95b>] ? __do_softirq+0x7f/0x106
[<ffffffff813c10ec>] ? call_softirq+0x1c/0x26
[<ffffffff8100351e>] ? do_softirq+0x31/0x67
[<ffffffff8103bc0f>] ? irq_exit+0x44/0xb0
[<ffffffff8100325f>] ? do_IRQ+0x94/0xad
[<ffffffff813bf62b>] ? common_interrupt+0x6b/0x6b
<EOI> [<ffffffff8104fe71>] ? __hrtimer_start_range_ns+0x2c6/0x2d9
[<ffffffff81190656>] ? intel_idle+0xcd/0xe9
[<ffffffff81190632>] ? intel_idle+0xa9/0xe9
[<ffffffff812cb231>] ? cpuidle_idle_call+0xa0/0xdb
[<ffffffff810007b9>] ? cpu_idle+0x53/0x7c
[<ffffffff816869fa>] ? start_kernel+0x2be/0x2c9
---[ end trace 0107c607401edcc2 ]---
iwl data: 00000000: cc 0e ba 13 e6 5d 47 14 14 13 7c 6c 42 dc f5 1a .....]G...|lB...
iwl data: 00000010: 5a f8 f3 ba 2f b8 6d 20 10 0e 10 b2 c0 38 e7 0b Z.../.m .....8..
------------[ cut here ]------------
WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c:765 iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]()
Hardware name: 4290W4H
wrong command queue 0 (should be 9), sequence 0xE1 readp=0 writep=0
Modules linked in: iwlagn
Pid: 0, comm: swapper Tainted: G W 3.1.0 #1
Call Trace:
<IRQ> [<ffffffff81036e2d>] ? warn_slowpath_common+0x78/0x8c
[<ffffffff81036ee2>] ? warn_slowpath_fmt+0x45/0x4a
[<ffffffffa0027199>] ? iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]
[<ffffffffa001e577>] ? iwl_rx_scan_complete_notif+0x163/0x1d3 [iwlagn]
[<ffffffffa00251d0>] ? iwl_irq_tasklet+0x7c9/0xb52 [iwlagn]
[<ffffffffa0025fc3>] ? iwl_isr_ict+0x563/0x628 [iwlagn]
[<ffffffff8103b439>] ? tasklet_action+0x67/0xa7
[<ffffffff8103b95b>] ? __do_softirq+0x7f/0x106
[<ffffffff813c10ec>] ? call_softirq+0x1c/0x26
[<ffffffff8100351e>] ? do_softirq+0x31/0x67
[<ffffffff8103bc0f>] ? irq_exit+0x44/0xb0
[<ffffffff8100325f>] ? do_IRQ+0x94/0xad
[<ffffffff813bf62b>] ? common_interrupt+0x6b/0x6b
<EOI> [<ffffffff8104fe71>] ? __hrtimer_start_range_ns+0x2c6/0x2d9
[<ffffffff81190656>] ? intel_idle+0xcd/0xe9
[<ffffffff81190632>] ? intel_idle+0xa9/0xe9
[<ffffffff812cb231>] ? cpuidle_idle_call+0xa0/0xdb
[<ffffffff810007b9>] ? cpu_idle+0x53/0x7c
[<ffffffff816869fa>] ? start_kernel+0x2be/0x2c9
---[ end trace 0107c607401edcc3 ]---
iwl data: 00000000: 35 18 04 00 84 c5 e1 00 f1 00 e0 00 58 00 4e 00 5...........X.N.
iwl data: 00000010: 35 08 04 00 85 c5 e1 00 2a b0 e1 00 15 00 13 00 5.......*.......
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 208 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 232 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 213 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 210 is out of range [0-256] 0 0.
------------[ cut here ]------------
WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c:765 iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]()
Hardware name: 4290W4H
wrong command queue 0 (should be 9), sequence 0x61 readp=0 writep=0
Modules linked in: iwlagn
Pid: 0, comm: swapper Tainted: G W 3.1.0 #1
Call Trace:
<IRQ> [<ffffffff81036e2d>] ? warn_slowpath_common+0x78/0x8c
[<ffffffff81036ee2>] ? warn_slowpath_fmt+0x45/0x4a
[<ffffffffa0027199>] ? iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]
[<ffffffffa001c15c>] ? iwl_rx_dispatch+0x147/0x20f [iwlagn]
[<ffffffffa00251d0>] ? iwl_irq_tasklet+0x7c9/0xb52 [iwlagn]
[<ffffffffa0025fc3>] ? iwl_isr_ict+0x563/0x628 [iwlagn]
[<ffffffff8103b439>] ? tasklet_action+0x67/0xa7
[<ffffffff8103b95b>] ? __do_softirq+0x7f/0x106
[<ffffffff813c10ec>] ? call_softirq+0x1c/0x26
[<ffffffff8100351e>] ? do_softirq+0x31/0x67
[<ffffffff8103bc0f>] ? irq_exit+0x44/0xb0
[<ffffffff8100325f>] ? do_IRQ+0x94/0xad
[<ffffffff813bf62b>] ? common_interrupt+0x6b/0x6b
<EOI> [<ffffffff8104fe71>] ? __hrtimer_start_range_ns+0x2c6/0x2d9
[<ffffffff81190656>] ? intel_idle+0xcd/0xe9
[<ffffffff81190632>] ? intel_idle+0xa9/0xe9
[<ffffffff812cb231>] ? cpuidle_idle_call+0xa0/0xdb
[<ffffffff810007b9>] ? cpu_idle+0x53/0x7c
[<ffffffff816869fa>] ? start_kernel+0x2be/0x2c9
---[ end trace 0107c607401edcc4 ]---
iwl data: 00000000: 35 18 04 00 47 10 61 00 45 10 61 00 0c 00 0c 00 5...G.a.E.a.....
iwl data: 00000010: 37 00 04 00 48 10 61 00 45 10 61 00 00 00 00 00 7...H.a.E.a.....
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 219 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 220 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 212 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 230 is out of range [0-256] 0 0.
------------[ cut here ]------------
WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c:765 iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]()
Hardware name: 4290W4H
wrong command queue 0 (should be 9), sequence 0x0 readp=0 writep=0
Modules linked in: iwlagn
Pid: 0, comm: swapper Tainted: G W 3.1.0 #1
Call Trace:
<IRQ> [<ffffffff81036e2d>] ? warn_slowpath_common+0x78/0x8c
[<ffffffff81036ee2>] ? warn_slowpath_fmt+0x45/0x4a
[<ffffffffa0027199>] ? iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]
[<ffffffffa001c15c>] ? iwl_rx_dispatch+0x147/0x20f [iwlagn]
[<ffffffffa00251d0>] ? iwl_irq_tasklet+0x7c9/0xb52 [iwlagn]
[<ffffffffa0025fc3>] ? iwl_isr_ict+0x563/0x628 [iwlagn]
[<ffffffff8103b439>] ? tasklet_action+0x67/0xa7
[<ffffffff8103b95b>] ? __do_softirq+0x7f/0x106
[<ffffffff813c10ec>] ? call_softirq+0x1c/0x26
[<ffffffff8100351e>] ? do_softirq+0x31/0x67
[<ffffffff8103bc0f>] ? irq_exit+0x44/0xb0
[<ffffffff8100325f>] ? do_IRQ+0x94/0xad
[<ffffffff813bf62b>] ? common_interrupt+0x6b/0x6b
<EOI> [<ffffffff8104fe71>] ? __hrtimer_start_range_ns+0x2c6/0x2d9
[<ffffffff81190656>] ? intel_idle+0xcd/0xe9
[<ffffffff81190632>] ? intel_idle+0xa9/0xe9
[<ffffffff812cb231>] ? cpuidle_idle_call+0xa0/0xdb
[<ffffffff810007b9>] ? cpu_idle+0x53/0x7c
[<ffffffff816869fa>] ? start_kernel+0x2be/0x2c9
---[ end trace 0107c607401edcc5 ]---
iwl data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 fe 01 00 00 ................
iwl data: 00000010: b8 c0 0c 04 00 ea ff ff c8 d7 09 07 00 ea ff ff ................
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 216 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 224 is out of range [0-256] 0 0.
iwlagn 0000:03:00.0: iwl_hcmd_queue_reclaim: Read index for DMA queue txq id (9), index 223 is out of range [0-256] 0 0.
------------[ cut here ]------------
WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-tx-pcie.c:765 iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]()
Hardware name: 4290W4H
wrong command queue 18 (should be 9), sequence 0x5259 readp=0 writep=0
Modules linked in: iwlagn
Pid: 0, comm: swapper Tainted: G W 3.1.0 #1
Call Trace:
<IRQ> [<ffffffff81036e2d>] ? warn_slowpath_common+0x78/0x8c
[<ffffffff81036ee2>] ? warn_slowpath_fmt+0x45/0x4a
[<ffffffffa0027199>] ? iwl_tx_cmd_complete+0xa4/0x335 [iwlagn]
[<ffffffffa001c15c>] ? iwl_rx_dispatch+0x147/0x20f [iwlagn]
[<ffffffffa00251d0>] ? iwl_irq_tasklet+0x7c9/0xb52 [iwlagn]
[<ffffffffa0025fc3>] ? iwl_isr_ict+0x563/0x628 [iwlagn]
[<ffffffff8103b439>] ? tasklet_action+0x67/0xa7
[<ffffffff8103b95b>] ? __do_softirq+0x7f/0x106
[<ffffffff813c10ec>] ? call_softirq+0x1c/0x26
[<ffffffff8100351e>] ? do_softirq+0x31/0x67
[<ffffffff8103bc0f>] ? irq_exit+0x44/0xb0
[<ffffffff8100325f>] ? do_IRQ+0x94/0xad
[<ffffffff813bf62b>] ? common_interrupt+0x6b/0x6b
<EOI> [<ffffffff8104fe71>] ? __hrtimer_start_range_ns+0x2c6/0x2d9
[<ffffffff81190656>] ? intel_idle+0xcd/0xe9
[<ffffffff81190632>] ? intel_idle+0xa9/0xe9
[<ffffffff812cb231>] ? cpuidle_idle_call+0xa0/0xdb
[<ffffffff810007b9>] ? cpu_idle+0x53/0x7c
[<ffffffff816869fa>] ? start_kernel+0x2be/0x2c9
---[ end trace 0107c607401edcc6 ]---
iwl data: 00000000: d0 26 c9 95 25 33 59 52 20 38 a2 2c 91 27 48 90 .&..%3YR 8.,.'H.
iwl data: 00000010: fb 08 36 49 c5 1a a6 ee 13 48 03 62 44 30 77 60 ..6I.....H.bD0w`
iwlagn 0000:03:00.0: Failed to start RT ucode: -110
iwlagn 0000:03:00.0: Unable to initialize device.
------------[ cut here ]------------
WARNING: at net/mac80211/util.c:1182 ieee80211_reconfig+0x110/0x407()
Hardware name: 4290W4H
Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.
Modules linked in: iwlagn
Pid: 4801, comm: acpi_handler.sh Tainted: G W 3.1.0 #1
Call Trace:
[<ffffffff81036e2d>] ? warn_slowpath_common+0x78/0x8c
[<ffffffff81379cbf>] ? wiphy_suspend+0x5f/0x5f
[<ffffffff81036ee2>] ? warn_slowpath_fmt+0x45/0x4a
[<ffffffff813a7c7e>] ? ieee80211_reconfig+0x110/0x407
[<ffffffff81379cbf>] ? wiphy_suspend+0x5f/0x5f
[<ffffffff81379d2b>] ? wiphy_resume+0x6c/0x7c
[<ffffffff8123d6ed>] ? legacy_resume+0x1e/0x4e
[<ffffffff8123db3a>] ? device_resume+0xb7/0x100
[<ffffffff8123e16f>] ? dpm_resume+0xd7/0x182
[<ffffffff8123e36c>] ? dpm_resume_end+0x8/0x10
[<ffffffff81062179>] ? suspend_devices_and_enter+0x1b3/0x1ec
[<ffffffff8106228a>] ? enter_state+0xd8/0x12b
[<ffffffff810619aa>] ? state_store+0xaa/0xca
[<ffffffff810f08e1>] ? sysfs_write_file+0xd3/0x10f
[<ffffffff810ac20b>] ? vfs_write+0xaf/0x129
[<ffffffff810ac45e>] ? sys_write+0x45/0x6e
[<ffffffff813bfc7b>] ? system_call_fastpath+0x16/0x1b
---[ end trace 0107c607401edcc7 ]---
legacy_resume(): wiphy_resume+0x0/0x7c returns -110
PM: Device phy0 failed to resume: error -110
PM: resume of devices complete after 2777.958 msecs
PM: Finishing wakeup.
Restarting tasks ... done.
video LNXVIDEO:00: Restoring backlight state
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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