linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: PEAK CAN USB driver v0.4.0
@ 2011-12-09 14:21 Oliver Hartkopp
       [not found] ` <4EE24089.5090300@peak-system.com>
  0 siblings, 1 reply; 2+ messages in thread
From: Oliver Hartkopp @ 2011-12-09 14:21 UTC (permalink / raw)
  To: Grosjean Stephane; +Cc: linux-can

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 ----


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-12-09 18:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-09 14:21 PEAK CAN USB driver v0.4.0 Oliver Hartkopp
     [not found] ` <4EE24089.5090300@peak-system.com>
2011-12-09 18:58   ` PEAK CAN USB driver patch Oliver Hartkopp

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).