Mike Frysinger wrote: > On Sunday 01 November 2009 11:16:59 Wolfgang Grandegger wrote: >> Mike Frysinger wrote: >>> On Sunday 01 November 2009 06:33:33 Wolfgang Grandegger wrote: >>>> --- /dev/null >>>> +++ b/drivers/can/can.c >>>> >>>> +static char *baudrates[] = { "125K", "250K", "500K" }; >>> so we're restricting ourselves to these three speeds ? i have passing >>> familiarity with CAN, but i didnt think the protocol was restricted to >>> specific speeds. >> Well, this is an RFC and as I wrote in the introduction some features >> need to be added or extended, especially for CAN device configuration. >> My idea is to have a more complete default bit-timing table, which board >> specific code may overwrite using, for example: >> >> sja1000_register(&my_sja1000, &my_config_opts); >> >> This would also allow to set the CAN clock, cdr and ocr registers. > > this makes sense if the device supports a limited number of baud rates. but > what if the baud rate is arbitrary (between two limits) ?
Board specific code can define what ever table it likes, including non-standard bit-rate and bit-timings. Nevertheless, for most CAN controllers the default bit-timing parameters are just fine. >>>> +int can_register (struct can_dev* can_dev) >>> no space before the paren, and the * is cuddled on the wrong side of the >>> space. seems like a lot of this code suffers from these two issues. >> U-Boot coding style requires a space after the function name and before >> "(". But the "*" is misplaced, of course. > > it's (thankfully) been changing to Linux kernel style I really appreciate that. >>>> +struct can_dev *can_init (int dev_num, int ibaud) >>> wonder if we should have a generic device list code base since this looks >>> similar to a lot of other u-boot device lists ... >> Do we already have a generic interface? > > i dont think so Nor do I. Wolfgang. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot