On 01/11/2011 05:13 AM, Bhupesh SHARMA wrote: > Hi Oliver and Wolfgang, > >> From: Wolfgang Grandegger [mailto:[email protected]] >> Hi Oliver, >> >> On 01/09/2011 12:01 PM, Oliver Hartkopp wrote: >>> On 06.01.2011 21:08, Wolfgang Grandegger wrote: >>>> Hi Marc, >>>> >>>> On 01/06/2011 08:44 PM, Marc Kleine-Budde wrote: >>> >>>>> If this driver will be merged, we'll have two drivers for the same >> can >>>>> core in the tree. The other one is the pch_can. What do you think >> should >>>>> be the mid term perspective for ccan based hardware? >>>> >>>> Yes, I know. Unfortunately, we did realize rather late the the PCH >>>> controller is a C_CAN clone and the OKI/Intel ppls did not tell us >>>> either. Therefore I asked Bhupesh to provide a SJA1000-a-like >> interface >>>> for the C_CAN, which would allow us to provide an alternative PCI >> driver >>>> "pch_pci.c" for the PCH. If that driver works well on the PCH >> hardware >>>> as well, we should merge the best of both, if necessary, and then >>>> finally remove the pch_can driver. Would that be a reasonable >> proposal. >>> >>> At least for me this looks great. The idea to have a similar approach >> as we >>> successfully implemented for the sja1000 will solve future hardware >>> implementations based on the ccan controller core. >> >> A common driver for c_can based devices will stabilize more quickly and >> does also especially reduce the maintanance effort significantly. >> >>> BTW. for the next submission of Bhupeshs patchset, i would propose to >> name the >>> driver 'ccan' instead of 'c_can', so that we have a >>> >>> linux/drivers/net/can/ccan/... >>> >>> path. >> >> You are late ;-). Bosch named the controller *C_CAN* and therefore I >> asked Bhupesh some time ago to change the file name and variable name >> prefix from ccan to c_can. > > Actually V1 of this patchset used the naming convention ccan. > But as was rightly pointed out by Wolfgang and Mark, Bosch > has officially named this core as C_CAN and the naming convention > is kept as C_CAN throughout their user-manual and technical articles. > IMHO, `c_can` seems to represent this Bosch core in a better way > than ccan. > >>> Checking directory names in linux/drivers with >>> >>> find . -type d | grep '_' >>> >>> driver names with underscores are pretty unusual and mostly selected >> without >>> fortune: >>> >>> ./staging/olpc_dcon >>> ./staging/wlags49_h2 >>> ./staging/wlags49_h2/man >>> ./staging/serqt_usb2 >>> ./staging/intel_sst >>> ./staging/quatech_usb2 >>> ./staging/asus_oled >>> ./staging/wlags49_h25 >>> ./staging/ath6kl/hif/sdio/linux_sdio <- Ugh! >>> ./staging/ath6kl/hif/sdio/linux_sdio/src >>> ./staging/ath6kl/hif/sdio/linux_sdio/include >>> ./net/pch_gbe >>> ./net/fs_enet >>> ./net/wireless/libertas_tf >>> ./net/ibm_newemacds >>> >>> For that reason i would prefer 'ccan' to name this driver core. >> >> Well, not really a strong argument. But well, if other people do >> *prefer* ccan I would not object against it. Bhupesh, what's your >> opinion. > > I also prefer c_can :), because it makes the driver name similar to the > core name. Please let me know if you agree for the same.
I fully agree and if nobody else complains, we should keep "c_can". Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
