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
| ||
|
Date: Mon, 14 Feb 2011 13:30:45 +0800 From: Bhupesh SHARMA <bhupesh.sharma@...com> To: David Miller <davem@...emloft.net>, "mkl@...gutronix.de" <mkl@...gutronix.de> Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Socketcan-core@...ts.berlios.de" <Socketcan-core@...ts.berlios.de> Subject: RE: [PATCH net-next-2.6 v7 1/1] can: c_can: Added support for Bosch C_CAN controller Hi David, > -----Original Message----- > From: Bhupesh SHARMA > Sent: Monday, February 14, 2011 9:25 AM > To: 'David Miller'; mkl@...gutronix.de > Cc: netdev@...r.kernel.org; Socketcan-core@...ts.berlios.de > Subject: RE: [PATCH net-next-2.6 v7 1/1] can: c_can: Added support for > Bosch C_CAN controller > > Hi David, > > > -----Original Message----- > > From: David Miller [mailto:davem@...emloft.net] > > Sent: Monday, February 14, 2011 12:36 AM > > To: mkl@...gutronix.de > > Cc: Bhupesh SHARMA; netdev@...r.kernel.org; Socketcan- > > core@...ts.berlios.de > > Subject: Re: [PATCH net-next-2.6 v7 1/1] can: c_can: Added support > for > > Bosch C_CAN controller > > > > From: David Miller <davem@...emloft.net> > > Date: Sun, 13 Feb 2011 10:52:16 -0800 (PST) > > > > > From: Marc Kleine-Budde <mkl@...gutronix.de> > > > Date: Sat, 12 Feb 2011 18:18:37 +0100 > > > > > >> On 02/11/2011 11:17 AM, Bhupesh Sharma wrote: > > >>> Bosch C_CAN controller is a full-CAN implementation which is > > compliant > > >>> to CAN protocol version 2.0 part A and B. Bosch C_CAN user manual > > can be > > >>> obtained from: > > >>> http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/ > > >>> c_can/users_manual_c_can.pdf > > >>> > > >>> This patch adds the support for this controller. > > >>> The following are the design choices made while writing the > > controller > > >>> driver: > > >>> 1. Interface Register set IF1 has be used only in the current > > design. > > >>> 2. Out of the 32 Message objects available, 16 are kept aside for > > RX > > >>> purposes and the rest for TX purposes. > > >>> 3. NAPI implementation is such that both the TX and RX paths > > function > > >>> in polling mode. > > >>> > > >>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@...com> > > >> > > >> Good work! > > >> > > >> Acked-by: Marc Kleine-Budde <mkl@...gutronix.de> > > > > > > Applied. > > > > Actually, I'm reverting because this causes build regressions: > > > > ERROR: "clk_get_rate" [drivers/net/can/c_can/c_can_platform.ko] > > undefined! > > ERROR: "clk_get" [drivers/net/can/c_can/c_can_platform.ko] undefined! > > ERROR: "clk_put" [drivers/net/can/c_can/c_can_platform.ko] undefined! > > Oops.. I will send a v8 to correct this compilation issue a.s.a.p. > I realized the problem happens when one compiles c_can files for x86 platform. As I have a ARM based platform, I get the "clk_get_rate", "clk_get" and "clk_put" definitions correctly when I perform the build operations. Now there can be two approaches to solve this issue: 1. Restrict C_CAN build only for ARM based platforms by adding the dependency "depends on HAVE_CLK" in the Kconfig file for C_CAN. For e.g. see the I2C_DESIGNWARE case: http://lxr.linux.no/linux+v2.6.31/drivers/i2c/busses/Kconfig#L329 2. Add #if defined(CONFIG_HAVE_CLK) macros to protect this code in "c_can_platform.c" For e.g. see: http://lxr.linux.no/linux+v2.6.31/drivers/serial/sh-sci.c#L1085 IMHO, approach 2 seems better as it will allow C_CAN to work on x86 platforms as well which will suit Intel TopCliff platform also. Please let me know your views on the same and I will send a v8 accordingly. 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