netdev - Re: [PATCH net-next-2.6 v3 1/1] can: c_can: Added support for Bosch C

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 09 Jan 2011 15:40:54 +0100
From:	Wolfgang Grandegger <wg@...ndegger.com>
To:	Oliver Hartkopp <socketcan@...tkopp.net>
CC:	Tomoya MORINAGA <tomoya-linux@....okisemi.com>,
	Bhupesh Sharma <bhupesh.sharma@...com>,
	Marc Kleine-Budde <mkl@...gutronix.de>,
	David Miller <davem@...emloft.net>,
	Socketcan-core@...ts.berlios.de, 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,

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