All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
To: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
	Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Subject: Re: [PATCH net-next-2.6 v3 1/1] can: c_can: Added support for Bosch C_CAN controller
Date: Sun, 09 Jan 2011 15:40:54 +0100	[thread overview]
Message-ID: <4D29C8F6.5030806@grandegger.com> (raw)
In-Reply-To: <4D299583.10909-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>

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.

> 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.

Wolfgang.

  parent reply	other threads:[~2011-01-09 14:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-04  9:59 [PATCH net-next-2.6 v3 1/1] can: c_can: Added support for Bosch C_CAN controller Bhupesh Sharma
     [not found] ` <1294135195-9448-1-git-send-email-bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
2011-01-06 19:33   ` David Miller
     [not found]     ` <20110106.113356.102556872.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2011-01-06 19:40       ` Wolfgang Grandegger
     [not found]         ` <4D261AAA.5030005-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2011-01-06 19:44           ` Marc Kleine-Budde
     [not found]             ` <4D261BA4.2020003-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2011-01-06 20:08               ` Wolfgang Grandegger
     [not found]                 ` <4D262158.4030301-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2011-01-09 11:01                   ` Oliver Hartkopp
     [not found]                     ` <4D299583.10909-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
2011-01-09 14:40                       ` Wolfgang Grandegger [this message]
     [not found]                         ` <4D29C8F6.5030806-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2011-01-11  4:13                           ` Bhupesh SHARMA
     [not found]                             ` <D5ECB3C7A6F99444980976A8C6D896384DEAFA2D56-8vAmw3ZAcdzhJTuQ9jeba9BPR1lH4CV8@public.gmane.org>
2011-01-11  8:31                               ` Wolfgang Grandegger
2011-01-11 21:01                               ` Oliver Hartkopp
2011-01-08  9:09   ` Wolfgang Grandegger
     [not found]     ` <4D2829C5.5020206-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2011-01-11  4:50       ` Bhupesh SHARMA
     [not found]         ` <D5ECB3C7A6F99444980976A8C6D896384DEAFA2D9D-8vAmw3ZAcdzhJTuQ9jeba9BPR1lH4CV8@public.gmane.org>
2011-01-11  8:29           ` Wolfgang Grandegger
     [not found]             ` <4D2C14FE.7080903-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2011-01-11 18:25               ` Wolfgang Grandegger
     [not found]                 ` <4D2CA0AA.6080505-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2011-01-11 22:01                   ` Marc Kleine-Budde
     [not found]                     ` <4D2CD34B.8000609-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2011-01-11 22:38                       ` Wolfram Sang
     [not found]                         ` <20110111223843.GB18762-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2011-01-11 22:48                           ` Marc Kleine-Budde
     [not found]                             ` <4D2CDE49.3030302-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2011-01-11 23:05                               ` Wolfram Sang
2011-01-12  8:47                       ` Wolfgang Grandegger
     [not found]                         ` <4D2D6ABE.7000405-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2011-01-12  8:53                           ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D29C8F6.5030806@grandegger.com \
    --to=wg-5yr1bzd7o62+xt7jha+gda@public.gmane.org \
    --cc=Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.