Ira W. Snyder wrote: > Hello all, > > I posted last week asking about a driver for boards running on a PLX > chip. It turns out that these are passive boards. I have been looking > for a driver for the Janz CMOD-IO board CAN interfaces. > > I finally found the datasheets and took the time to write a driver. This > board is an intelligent CAN interface: it has onboard microprocessors to > help process CAN traffic. > > This is a very rough first try at a CAN driver. I'm sure it still has > problems, and I would appreciate if you can take a look and help me add > what is needed. I'm am not extremely knowledgeable about the CAN bus.
You are welcome. I think the esd_pci331 drive should answer most of your questions. > The things that are known to be wrong: > > - bus-on / bus-off handling > > I did this straight in the network device open()/stop() methods. I don't > handle the condition where we get too many bus errors and the bus goes > into bus-off state. What should I be doing here? Search for "can_bus_off" in esd_pci331.c. The controller (hardware) goes bus-off if to much errors occurred and it's necessary to handle that event in the driver and report it to the apps. Yon can only recover from a bus-off initiating a so called bus-off recovery, which is done via esd331_set_mode(CAN_MODE_START). > - state changes, bit timing, etc. Search for "alloc_can_err_skb" and "CAN_ERR" in esd_pci331.c. We report CAN error state changes and errors via so called CAN error messages, which the apps can receive on request. > I'm not at all sure how this is supposed to work. Perhaps someone that > knows CAN bus better that I do can help. > > - CAN bus termination > > This board supports optionally terminating the CAN bus. In order to test > this driver, I connected both CAN modules on a single board together. To > get this to work, I needed to turn on termination on both modules. > > Is this wrong? Is there a way to enable/disable termination via the "ip" > tool? No, that's specific to this driver and could be implemented via SysFS, as Kurt suggested. > - module probing > > This board is really a MODULbus carrier board, into which plugs 4 > daughterboards. These can be CAN modules, or others. On my board, I have > 2x CAN modules and 1x TTL GPIO module. I need support for both of these > for my application. For the time being, I *did not* add support for the > TTL module. That will come once the CAN part is finished. The modules are connected to the PCI bus, I assume. The TTL module should be handled by a dedicated driver. > Also, there is no way I am aware of to determine what type of board is > plugged into which MODULbus slot on the carrier board. My CAN modules > support identification, but the TTL module does not. > > I hard-coded the module layout into the driver itself. This is > sufficient for my purposes, but probably is not sufficient for mainline > Linux :'(. Any ideas or suggestions? This information could be provide via module parameter, for example. > Any review will be much appreciated! Puh, that's a lot of untested code. Some general comments/questions: - You use NAPI and a work-queue. Why do you need both? - I do not see how you control the flow of TX messages? To be more precise, I do not find netif_stop_queue() in your xmit path. - You can use the standard bit-timing calculation. See how it's done in sja1000/sja1000.c. Search for sja1000_bittiming_const and sja1000_set_bittiming. - You do not handle echo skb's. Search for can_get_echo_skb() and can_put_echo_skb() for local loopback. As I see it, this code does not run or even compile yet... too early for a full review. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
