Message-ID: <D5ECB3C7A6F99444980976A8C6D896384DEAFA2D56@EAPEX1MAIL1.st.com>
Date:	Tue, 11 Jan 2011 12:13:18 +0800
From:	Bhupesh SHARMA <bhupesh.sharma@...com>
To:	Wolfgang Grandegger <wg@...ndegger.com>,
	Oliver Hartkopp <socketcan@...tkopp.net>
Cc:	Tomoya MORINAGA <tomoya-linux@....okisemi.com>,
	Marc Kleine-Budde <mkl@...gutronix.de>,
	David Miller <davem@...emloft.net>,
	"Socketcan-core@...ts.berlios.de" <Socketcan-core@...ts.berlios.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: 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@...ndegger.com]
> 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.

Regards,
Bhupesh

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists