RE: [PATCH net-next-2.6 v3 1/1] can: c_can: Added support for Bosch C_CAN controller

Hi Oliver and Wolfgang,

From: Wolfgang Grandegger [mailto:wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org]
Hi Oliver,

On 01/09/2011 12:01 PM, Oliver Hartkopp wrote:

quoted

On 06.01.2011 21:08, Wolfgang Grandegger wrote:

quoted

Hi Marc,

On 01/06/2011 08:44 PM, Marc Kleine-Budde wrote:

quoted

quoted

If this driver will be merged, we'll have two drivers for the same

can

quoted

quoted

quoted

core in the tree. The other one is the pch_can. What do you think

should

quoted

quoted

quoted

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

quoted

quoted

for the C_CAN, which would allow us to provide an alternative PCI

driver

quoted

quoted

"pch_pci.c" for the PCH. If that driver works well on the PCH

hardware

quoted

quoted

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.

quoted

At least for me this looks great. The idea to have a similar approach

as we

quoted

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.

quoted

BTW. for the next submission of Bhupeshs patchset, i would propose to

name the

quoted

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.

quoted

Checking directory names in linux/drivers with

    find . -type d | grep '_'

driver names with underscores are pretty unusual and mostly selected

without

quoted

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.

Regards,
Bhupesh