CAN/USB Interface Socket-CAN

Sebastian Haas haas at ems-wuensche.com
Tue Apr 14 07:44:37 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg KH wrote:
> On Wed, Apr 08, 2009 at 10:50:30AM +0200, Sebastian Haas wrote:
>> Dear Project-Managers,
>>
>> we offer a wide range of CAN PC Interfaces and would love to see our
>> products being supported out of the box of the mainline kernel.
>>
>> First some words about CAN. CAN (Controller Area Network) is fieldbus for
>> industrial communication. Since 2.6.25 the Socket-CAN project got merged
>> into the mainline kernel (drivers/net/can), it provides a generic API to
>> access CAN PC Interfaces (PCI boards, USB, ISA, ...).
>>
>> See also http://developer.berlios.de/projects/socketcan/
>>
>> We already provide GPLv2 Linux drivers to our customers but these drivers
>> use a proprietary character device interface and are far away from getting
>> merged into the kernel.
> 
> Do you have a pointer to these drivers anywhere?  If we convert them to
> use the proper in-kernel api, do you see a problem with them being
> merged?
No. They don't use any exotic constructions nor binary blobs. I've already
tried to fix some coding style issues. There are some #IFDEFs to
support older kernels and they don't make use of modern USB and driver
functions (USB anchors or dev_info(...)) also with respect to older kernels.

>> In the past we have worked together with the Socket-CAN project to support
>> our PCI interface (CPC-PCI) and PCMCIA interface (CPC-CARD).
>>
>> We have 2 products left which must be supported, one of it is the CPC-104M
>> a PC-104 CAN interfaces and the other one is the CPC-USB a USB 1.1 CAN
>> interface. The CPC-104M is a pretty simple device (memory mapped access to
>> the CAN controller), which we will support in Socket-CAN ourself.
>>
>> The CPC-USB is a bit more trickier.
> 
> Why do you think it is trickier?
Socket-CAN already has support for the onboard CAN controllers at our PCI
boards. So supporting them is just a matter of 300lines of simple code.

In our proprietary API, most configuration stuff comes from the
application which uses the CPC-USB device. Socket-CAN does it all in
kernel space as it provides a single device to many applications
(networking like). So the configuration process and some specific
processing needs to be moved to kernel space (nothing exciting but just
more work).

>> What needs to be done:
>> - porting existing driver to Socket-CAN API
>> - implement power management
> 
> Sounds very reasonable, and doable.
> 
>> We provide a test device and I will be the technical contact person (I've
>> wrote our Linux driver before).
> 
> Great!
> 
> So, how do you want to do this?  I suggest:
> 	- point us at the current drivers and we add them to the
> 	  staging tree
> 	- work on converting them to the socket-can api
> 	- test with the devices provided all along the way
> 
> Would that be acceptable?
Yes, sounds great. Give me some days to prepare everything.

Who will be the responsible developer at the Linux driver project?

> thanks,
> 
> greg k-h

Thank you too.

- --
Mit freundlichen Gruessen/Best Regards,

Sebastian Haas
Software Entwicklung/Software Development

Phone: +49-9451-9432-22
Fax  : +49-9451-9432-12
Email: haas at ems-wuensche.com
Web  : www.ems-wuensche.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknkPtQACgkQpqRB8PJG7XxboQCghUmWpcuOlQ5fcK+2LEBzRmLK
MQkAmQEHi1/seHpEmkXt8lurjbUvTP4O
=cQ/L
-----END PGP SIGNATURE-----
-- 
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106
Phone: +49-8441-490260
Fax  : +49-8441-81860
http://www.ems-wuensche.com



More information about the prjmgr mailing list