Re: PEAK CAN USB driver v0.4.0

Re: PEAK CAN USB driver v0.4.0

[Oliver Hartkopp]

Please send the patch inline for review! (!!)

Like e.g. this one is sent: http://article.gmane.org/gmane.linux.can/301

Preferably based on this git tree https://gitorious.org/linux-can/linux-can-next

Thanks,
Oliver

----- original Nachricht --------

Betreff: PEAK CAN USB driver v0.4.0
Gesendet: Fr, 09. Dez 2011
Von: Grosjean Stephane<s.grosjean@peak-system.com>

> Hi Oliver,
> 
> Please find a new version of the candev driver for our PEAK USB adapters.
> I tried to follow your suggestions, especially those concerning the 
> names of the files and the Kconfig file content. However, I kept the 
> original Kbuild file since I didn't find (for the moment) another way to 
> add one or the other pcan_usb.o/pcan_usb_pro.o file, according to their 
> corresponding CONFIG_xxx ...
> 
> This version also handles the PCAN-USB Pro adapter as well as the 
> timestamps coming from PCAN-USB and PCAN-USB Pro (new from v0.2.0).
> There's something which should be fixed too and I wanted to talk about 
> that too:
> 
> I don't know why for the moment, but sending data through the adapters 
> works without any problems, except when data are sent through one or the 
> other can channel of the the PCAN-USB Pro: the data are correclty sent 
> on the bus but, for each sent frame, the Kernel adds the following text 
> to the syslog:
> 
>      [98724.131218] ehci_hcd 0000:00:1a.7: dma_pool_free buffer-32, 
> f4e93000/34e93000 (bad dma)
> 
> Seems to be a warning-like, since nothing else occurs anywhere (data are 
> sent, the kernel is/seems always stable...).
> That's the main reason why I decided to give you that new version, and 
> also to ask you if you had got any idea about the reason of such a log? 
> I mean, that "problem" doesnot occur when sending through PCAN-USB 
> adapter channel... If you have a look to the sources, the management of 
> the tx buffer(s) is done into pcan_usb_core.c, that is, tx buffers 
> allocation/free doesn't depend on the type of USB adapter (well I 
> suppose it is, but why and where?).
> 
> So, while I'm delving into the code, I hope you'll be able to have 
> enough time to test'n play with your PEAK USB CAN adapters and this new 
> driver.
> 
> Many thanks and regards,
> 
> Stéphane
> 
> 

--- original Nachricht Ende ----

Re: PEAK CAN USB driver patch

[Oliver Hartkopp]

On 09.12.2011 18:08, Grosjean Stephane wrote:

> Hi Oliver,
> 
> Please find below the patch to apply to linux-can-next, which adds support for
> the PEAK System CAN USB adapters.


Whow - thanks!

I already transferred your original patch into my tree by hand :-)

And the first thing i stumble when compiling was here:

> diff --git a/drivers/net/can/usb/pcan_usb.c b/drivers/net/can/usb/pcan_usb.c
> new file mode 100644
> index 0000000..eb2329d
> --- /dev/null
> +++ b/drivers/net/can/usb/pcan_usb.c
> @@ -0,0 +1,740 @@
> +/*
> + * CAN driver for PEAK System PCAN-USB adapter
> + *
> + * Copyright (C) 2011-2012 PEAK-System GmbH
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published
> + * by the Free Software Foundation; version 2 of the License.
> + *
> + * 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.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +#include <linux/netdevice.h>
> +#include <linux/usb.h>


here

#include <linux/module.h>

is missing to expand this:

> +MODULE_SUPPORTED_DEVICE("PEAK-System PCAN-USB adapter");

> new file mode 100644
> index 0000000..c81b42d
> --- /dev/null
> +++ b/drivers/net/can/usb/pcan_usb_pro.c
> @@ -0,0 +1,1426 @@
> +/*
> + * CAN driver for PEAK System PCAN-USB-PRO adapter
> + *
> + * Copyright (C) 2011-2012 PEAK-System GmbH
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published
> + * by the Free Software Foundation; version 2 of the License.
> + *
> + * 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.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +#include <linux/netdevice.h>
> +#include <linux/usb.h>
> +#include <linux/stringify.h>



here

#include <linux/module.h>

is missing to expand this:

> +MODULE_SUPPORTED_DEVICE("PEAK-System PCAN-USB-PRO adapter");


More remarks following soon ...

Have a nice weekend,

Oliver

PEAK CAN USB driver v0.4.0

[Grosjean Stephane]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

Hi Oliver,

Please find a new version of the candev driver for our PEAK USB adapters.
I tried to follow your suggestions, especially those concerning the 
names of the files and the Kconfig file content. However, I kept the 
original Kbuild file since I didn't find (for the moment) another way to 
add one or the other pcan_usb.o/pcan_usb_pro.o file, according to their 
corresponding CONFIG_xxx ...

This version also handles the PCAN-USB Pro adapter as well as the 
timestamps coming from PCAN-USB and PCAN-USB Pro (new from v0.2.0).
There's something which should be fixed too and I wanted to talk about 
that too:

I don't know why for the moment, but sending data through the adapters 
works without any problems, except when data are sent through one or the 
other can channel of the the PCAN-USB Pro: the data are correclty sent 
on the bus but, for each sent frame, the Kernel adds the following text 
to the syslog:

     [98724.131218] ehci_hcd 0000:00:1a.7: dma_pool_free buffer-32, 
f4e93000/34e93000 (bad dma)

Seems to be a warning-like, since nothing else occurs anywhere (data are 
sent, the kernel is/seems always stable...).
That's the main reason why I decided to give you that new version, and 
also to ask you if you had got any idea about the reason of such a log? 
I mean, that "problem" doesnot occur when sending through PCAN-USB 
adapter channel... If you have a look to the sources, the management of 
the tx buffer(s) is done into pcan_usb_core.c, that is, tx buffers 
allocation/free doesn't depend on the type of USB adapter (well I 
suppose it is, but why and where?).

So, while I'm delving into the code, I hope you'll be able to have 
enough time to test'n play with your PEAK USB CAN adapters and this new 
driver.

Many thanks and regards,

Stéphane


[-- Attachment #2: peak_usb-0.4.0.tar.gz --]
[-- Type: application/gzip, Size: 45725 bytes --]