gmane.linux.can

Re: [PATCH v2] can: flexcan: remove HAVE_CAN_FLEXCAN Kconfig symbol

Shawn Guo — 2013-05-17T09:09:51

Acked-by: Shawn Guo <shawn.guo< at >linaro.org>


--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] can: flexcan: remove HAVE_CAN_FLEXCAN Kconfig symbol

Marc Kleine-Budde — 2013-05-17T08:59:17

This patch removes the Kconfig symbol HAVE_CAN_FLEXCAN from arch/{arm,powerpc}
and allowing compilation unconditionally on all arm and powerpc platforms.

This brings a bigger compile time coverage and removes the following dependency
warning found by Arnd Bergmann:

    warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 && IMX_HAVE_PLATFORM_FLEXCAN &&
        SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
    which has unmet direct dependencies (NET && CAN && CAN_DEV)

Cc: Arnd Bergmann <arnd< at >arndb.de>
Cc: Shawn Guo <shawn.guo< at >linaro.org>
Cc: Sascha Hauer <s.hauer< at >pengutronix.de>
Cc: Kumar Gala <galak< at >kernel.crashing.org>
Cc: U Bhaskar-B22300 <B22300< at >freescale.com>
Cc: linux-arm-kernel< at >lists.infradead.org
Cc: linuxppc-dev< at >lists.ozlabs.org
Signed-off-by: Marc Kleine-Budde <mkl< at >pengutronix.de>
---
Changes since v1:
- don't remove IMX_HAVE_PLATFORM_FLEXCAN, which breaks non DT imx platforms
  tnx Shawn

 arch/arm/mach-imx/Kconfig         | 4 ----
 arch/arm/mach-imx/devices/Kconfig | 1 -
 arch/arm/mach-mxs/Kconfig

Re: [PATCH] can: flexcan: allow compilation on arm and powerpc

Marc Kleine-Budde — 2013-05-17T08:51:00

Doh! - I've removed too much, will change.

Tnx,
Marc

Re: [PATCH] can: flexcan: allow compilation on arm and powerpc

Shawn Guo — 2013-05-17T02:03:52

Hi Marc,

On Thu, May 16, 2013 at 03:42:36PM +0200, Marc Kleine-Budde wrote:

I'm generally fine with the approach.  But with Kconfig symbol
IMX_HAVE_PLATFORM_FLEXCAN removed, how does the build of
platform-flexcan.o work?

arch/arm/mach-imx/devices/Makefile:obj-$(CONFIG_IMX_HAVE_PLATFORM_FLEXCAN) += platform-flexcan.o

Shawn

--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull-request: can-next 2013-05-16

David Miller — 2013-05-17T00:12:46

From: Marc Kleine-Budde <mkl< at >pengutronix.de>
Date: Thu, 16 May 2013 14:51:56 +0200

 ...

Pulled, thanks Marc.
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: command ip -details -statistics link show wlan0

Ernast Sevo — 2013-05-16T16:37:27

Great! Thank you very much for all your help! And I will take a closer
look at that optimized driver.

Best,

 Ernast

On Thu, May 16, 2013 at 11:43 AM, Wolfgang Grandegger <wg< at >grandegger.com> wrote:

--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: command ip -details -statistics link show wlan0

Wolfgang Grandegger — 2013-05-16T15:43:01

Hi Ernast,

please don't frop the CC to the mailing list...

On 05/16/2013 05:32 PM, Ernast Sevo wrote:

That would be my guess as well.


You may try to increase the priority of the MCP2515 IRQ thread.

Recently I also stumbled over the following optimized driver for the
MCP2515:

  http://clientes.netvisao.pt/anbadeol/mcp2515.html

But that would required some effort to update and test it.

Wolfgang.

--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: command ip -details -statistics link show wlan0

Marc Kleine-Budde — 2013-05-16T15:37:53



Yes, exactly.


If you don't get any dropped frames reported via SO_RXQ_OVFL (see
Wolfgang mail) you can be sure they are lost at the hardware level. I
suggest don't use the mcp251x, it's really slow and puts heavy load on
the machine. However there might be some knobs to tune in your SPI
controller/driver.

Marc

Re: command ip -details -statistics link show wlan0

Ernast Sevo — 2013-05-16T15:32:00

Yes I am using MCP2515. I am getting a couple of rx buffer overflow errors
so I was wondering how these errors corresponded to packet loss,
whether this is a 1:1 relationship or 1:N relationship (if i am
interpretting Marc's post
correctly should I assume 1:1 for best case and 1:N for worst case? ).
Essentially I am trying to determine at what speed i can have stuff
coming in before
I start losing packets for any reason. I know how to account packets
lost in userspace
 and packets lost by the driver (which you mentioned above) and now I
am trying to
account for packets lost at the hardware level. Knowing how these rx buffer
overflow/overrun errors correspond to packet loss would help make my
data more accurate and reliable.

Thanks,

Ernast
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: command ip -details -statistics link show wlan0

Marc Kleine-Budde — 2013-05-16T13:45:16

This depends on the hardware/driver. But usually that means 11 overrun
events, which means _at_least_ 11 CAN frames lost.

Marc

command ip -details -statistics link show wlan0

Ernast Sevo — 2013-05-16T13:43:38



Hi Wolfgang,

That definitely clears things up a bit. One more question though. Does
the number in
overrun or the number in errors from the command above then directly
refer to the number
of packets lost on the hardware level due to there being no space to
store it (i.e 11 overrun or
errors means 11 packets lost) ?

Thanks again,

Ernast
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull-request: can-next 2013-05-16

Marc Kleine-Budde — 2013-05-16T12:51:56

Hello David,

this is a pull-request for net-next/master. It consists of 4 patches by
Jingoo Han, which remove the unnecessary platform_set_drvdata() and a
patch by Laurent Navet converting the grcan driver to use
devm_ioremap_resource().

regards,
Marc

---

The following changes since commit dbbffe6898fd0d7bac66ded5d3c58835b13ddefc:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-05-13 13:25:36 -0700)

are available in the git repository at:


  git://gitorious.org/linux-can/linux-can-next.git for-davem

for you to fetch changes up to 5727dc6bf5b70dd278e58e26137e2df729b9c107:

  net: can: ti_hecc: remove unnecessary platform_set_drvdata() (2013-05-16 13:27:20 +0200)

----------------------------------------------------------------
Jingoo Han (4):
      net: can: at91_can: remove unnecessary platform_set_drvdata()
      net: can: c_can: remove unnecessary platform_set_drvdata()
      net: can: flexcan: remove unnecessary platform_set_drvdata()
      net: can: ti_hecc: remove unnecessa

Re: [PATCH] drivers: net: can: grcan: use devm_ioremap_resource()

Marc Kleine-Budde — 2013-05-16T11:50:00

The "IS_ERR(base)" ...


... introduces this sparse warning:


I think it's the __iomem annotation of the void pointer that
devm_ioremap_resource() returns. Is there a clever way to improve IS_ERR
and PTR_ERR?

Marc

Re: Usb to can driver

Marc Kleine-Budde — 2013-05-16T11:40:34

Please fix these errors, too:


You should not use memory on stack for usb transfers. Use kmalloc(), or
kzalloc() (and kfree) instead.

Marc

[PATCH v2] net: can: peak_usb: Do not do dma on the stack

Marc Kleine-Budde — 2013-05-16T10:01:26

smatch reports the following warnings:
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:514 pcan_usb_pro_drv_loaded() error: doing dma on the stack (buffer)
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:878 pcan_usb_pro_init() error: doing dma on the stack (&fi)
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:889 pcan_usb_pro_init() error: doing dma on the stack (&bi)

See "Documentation/DMA-API-HOWTO.txt" section "What memory is DMA'able?"

Cc: Stephane Grosjean <s.grosjean< at >peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl< at >pengutronix.de>
---

Changes since v1:
- use kmalloc instead of kzalloc for fi and bi

 drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 61 +++++++++++++++++++----------
 drivers/net/can/usb/peak_usb/pcan_usb_pro.h |  1 +
 2 files changed, 41 insertions(+), 21 deletions(-)

diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
index 30d79bf..8ee9d15 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_

Re: [PATCH] net: can: peak_usb: Do not do dma on the stack

Marc Kleine-Budde — 2013-05-16T09:41:43

I think I can use plain kmalloc for fi and bi.

[PATCH] net: can: peak_usb: Do not do dma on the stack

Marc Kleine-Budde — 2013-05-16T09:40:36

smatch reports the following warnings:
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:514 pcan_usb_pro_drv_loaded() error: doing dma on the stack (buffer)
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:878 pcan_usb_pro_init() error: doing dma on the stack (&fi)
drivers/net/can/usb/peak_usb/pcan_usb_pro.c:889 pcan_usb_pro_init() error: doing dma on the stack (&bi)

See "Documentation/DMA-API-HOWTO.txt" section "What memory is DMA'able?"

Cc: Stephane Grosjean <s.grosjean< at >peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl< at >pengutronix.de>
---
Hello Stephane,

can you please test this patch. It applies to current net/master, but any
recent kernel should do.

regards,
Marc

 drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 61 +++++++++++++++++++----------
 drivers/net/can/usb/peak_usb/pcan_usb_pro.h |  1 +
 2 files changed, 41 insertions(+), 21 deletions(-)

diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
index 30d79bf..b94bf9f 100644
--- a/drivers/net/can/usb/pea

Re: command ip -details -statistics link show wlan0

Wolfgang Grandegger — 2013-05-16T07:02:03

Hi Ernast,

On 05/15/2013 08:58 PM, Ernast Sevo wrote:

They refer to packets dropped in the driver for some reason, maily
because memory is short (ENOMEM). The overrun errors above are reported
by the hardware due to messages arrived but there was no space to store
it. Messages dropped because the socket buffer was full can be reported
with the candump option "-d" as shown here:

https://gitorious.org/linux-can/can-utils/blobs/master/candump.c#line549

Hope that helps.

Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

command ip -details -statistics link show wlan0

Ernast Sevo — 2013-05-15T18:58:03

Hello,

 I am quite new to socket can and I had a question about the output of
the command: ip -details -statistics link show can0. When I run the
above command I get the following output:

re-started bus-errors arbit-lost error-warn error-pass bus-off
    0          0          0          0          0          0
    RX: bytes  packets  errors  dropped overrun mcast
    3956387    948121    11      0           11          0
    TX: bytes  packets  errors  dropped carrier collsns
    100        44       0       0       0       0


I see that I received 11 errors packets (all of them being rx overrun
errors) and that no packets were dropped. Does the dropped field refer
to packets lost in userspace (i.e because they weren't being read fast
enough and the socket receive buffer overflowed) or does the dropped
packet field refer to dropped packets being dropped somewhere other
than userspace?

Thanks,

Ernast
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majord

Re: CAN driver for the Holt HI-3110

Heinz-Jürgen Oertel — 2013-05-15T13:11:29

Am Mittwoch 15 Mai 2013, 09:24:22 schrieb Marc Kleine-Budde:

I know :-)
but at least the HI-3110 has a bigger receive FIFO.

Re: [PATCH v3] can: kvaser_usb: handle rx msg correctly

Olivier Sobrie — 2013-05-15T11:50:25

Hi Marc,

On Wed, May 15, 2013 at 12:05:31PM +0200, Marc Kleine-Budde wrote:

No, grrr I mixed up kvaser_usb_rx_can_msg and kvaser_usb_rx_can_err in my
comment. I meant kvaser_usb_rx_can_err() and kvaser_usb_rx_error().


Yes that's what I'll maybe do, merging the two error functions in one.
I'll look at this more deeply when I've a more time.


Ok fine for me.

Thanks,