CAN/USB Interface Socket-CAN

[Greg KH]

On Tue, Apr 14, 2009 at 09:44:26AM +0200, Sebastian Haas wrote:
> 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.

That's not a problem, we can clean them up quite easily in the staging
tree.

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

Great!  Although 300 lines of code does seem like a lot, we can write a
virtual filesystem for Linux in less these days :)

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

I'll start it out, as you already have code, and then other developers
will pick it up and go from there.

Send me the code you have when you are ready to start.

thanks,

greg k-h