aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/can/c_can
AgeCommit message (Collapse)AuthorFilesLines
2014-03-17can: Unify MTU settings for CAN interfacesOliver Hartkopp1-0/+1
CAN interfaces only support MTU values of 16 (CAN 2.0) and 72 (CAN FD). Setting the MTU to other values is pointless but it does not really hurt. With the introduction of the CAN FD support in drivers/net/can a new function to switch the MTU for CAN FD has been introduced. This patch makes use of this can_change_mtu() function to check for correct MTU settings also in legacy CAN (2.0) devices. Signed-off-by: Oliver Hartkopp <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-12-17can: c_can: Speed up rx_poll functionMarkus Pargmann1-10/+12
This patch speeds up the rx_poll function by reducing the number of register reads. Replace the 32bit register read by a 16bit register read. Currently the 32bit register read is implemented by using 2 16bit reads. This is inefficient as we only use the lower 16bit in rx_poll. The for loop reads the pending interrupts in every iteration. This leads up to 16 reads of pending interrupts. The patch introduces a new outer loop to read the pending interrupts as long as 'quota' is above 0. This reduces the total number of reads. The third change is to replace the for-loop by a ffs loop. Tested on AM335x. I removed all 'static' and 'inline' from c_can.c to see the timings for all functions. I used the function tracer with trace_stats. 125kbit: Function Hit Time Avg s^2 -------- --- ---- --- --- c_can_do_rx_poll 63960 10168178 us 158.977 us 1493056 us With patch: c_can_do_rx_poll 63941 3764057 us 58.867 us 776162.2 us 1Mbit: Function Hit Time Avg s^2 -------- --- ---- --- --- c_can_do_rx_poll 69489 30049498 us 432.435 us 9271851 us With patch: c_can_do_rx_poll 207109 24322185 us 117.436 us 171469047 us Signed-off-by: Markus Pargmann <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-11-25can: c_can: fix calculation of transmitted bytes on tx completeHolger Bechtold1-0/+1
The number of bytes transmitted was not updated correctly, if several CAN messages (with different length) were transmitted in one 'bunch'. Thus programs like 'ifconfig' showed wrong transmit byte counts. Reason was, that the message object whose DLC is to be read was not necessarily the active one at the time when priv->read_reg(priv, C_CAN_IFACE(MSGCTRL_REG, 0)) & IF_MCONT_DLC_MASK; was executed. Signed-off-by: Holger Bechtold <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-11-25can: c_can: don't call pm_runtime_get_sync() from interrupt contextMarc Kleine-Budde1-6/+15
The c_can driver contians a callpath (c_can_poll -> c_can_state_change -> c_can_get_berr_counter) which may call pm_runtime_get_sync() from the IRQ handler, which is not allowed and results in "BUG: scheduling while atomic". This problem is fixed by introducing __c_can_get_berr_counter, which will not call pm_runtime_get_sync(). Reported-by: Andrew Glen <[email protected]> Tested-by: Andrew Glen <[email protected]> Signed-off-by: Andrew Glen <[email protected]> Cc: linux-stable <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-11-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-3/+3
Conflicts: drivers/net/ethernet/emulex/benet/be.h drivers/net/netconsole.c net/bridge/br_private.h Three mostly trivial conflicts. The net/bridge/br_private.h conflict was a function signature (argument addition) change overlapping with the extern removals from Joe Perches. In drivers/net/netconsole.c we had one change adjusting a printk message whilst another changed "printk(KERN_INFO" into "pr_info(". Lastly, the emulex change was a new inline function addition overlapping with Joe Perches's extern removals. Signed-off-by: David S. Miller <[email protected]>
2013-10-31can: c_can: Fix RX message handling, handle lost message before EOBMarkus Pargmann1-3/+3
If we handle end of block messages with higher priority than a lost message, we can run into an endless interrupt loop. This is reproducable with a am335x processor and "cansequence -r" at 1Mbit. As soon as we loose a packet we can't escape from an interrupt loop. This patch fixes the problem by handling lost packets before EOB packets. Cc: linux-stable <[email protected]> Signed-off-by: Markus Pargmann <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-10-01net: can: c_can_platform: Remove redundant of_match_ptrSachin Kamat1-1/+1
The data structure of_match_ptr() protects is always compiled in. Hence of_match_ptr() is not needed. Signed-off-by: Sachin Kamat <[email protected]> Cc: Marc Kleine-Budde <[email protected]> Cc: [email protected] Signed-off-by: David S. Miller <[email protected]>
2013-09-21can: c_can: remove unnecessary pci_set_drvdata()Jingoo Han1-2/+0
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-08-22can: c_can: fix error checking of priv->instance in probe()Chen Gang1-1/+1
This patch adds a type cast from 'unsigned int' to 'int'. 'priv->instance' may less than zero, so need a type cast, the related warnings (allmodconfig, "EXTRA_CFLAGS=-W"): drivers/net/can/c_can/c_can_platform.c:198:3: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] Signed-off-by: Chen Gang <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-07-11drivers/net/can/c_can: don't use devm_pinctrl_get_select_default() in probeWolfram Sang1-7/+0
Since commit ab78029 (drivers/pinctrl: grab default handles from device core), we can rely on device core for setting the default pins. Compile tested only. Acked-by: Linus Walleij <[email protected]> (personally at LCE13) Signed-off-by: Wolfram Sang <[email protected]> Acked-by: Marc Kleine-Budde <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-06-12net: can: Convert to use devm_ioremap_resourceTushar Behera1-2/+2
Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()") introduced devm_ioremap_resource() and deprecated the use of devm_request_and_ioremap(). Signed-off-by: Tushar Behera <[email protected]> CC: [email protected] CC: [email protected] CC: Marc Kleine-Budde <[email protected]> CC: Wolfgang Grandegger <[email protected]> Acked-by: Marc Kleine-Budde <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-05-16net: can: c_can: remove unnecessary platform_set_drvdata()Jingoo Han1-2/+0
The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-02-05Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-1/+5
Conflicts: drivers/net/ethernet/intel/e1000e/ethtool.c drivers/net/vmxnet3/vmxnet3_drv.c drivers/net/wireless/iwlwifi/dvm/tx.c net/ipv6/route.c The ipv6 route.c conflict is simple, just ignore the 'net' side change as we fixed the same problem in 'net-next' by eliminating cached neighbours from ipv6 routes. The e1000e conflict is an addition of a new statistic in the ethtool code, trivial. The vmxnet3 conflict is about one change in 'net' removing a guarding conditional, whilst in 'net-next' we had a netdev_info() conversion. The iwlwifi conflict is dealing with a WARN_ON() conversion in 'net-next' vs. a revert happening in 'net'. Signed-off-by: David S. Miller <[email protected]>
2013-02-01can: c_can: Set reserved bit in IFx_MASK2 to 1 on writeAlexander Stein1-1/+5
According to C_CAN documentation, the reserved bit in IFx_MASK2 register is fixed 1. Cc: linux-stable <[email protected]> Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-01-29Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-2/+2
Bring in the 'net' tree so that we can get some ipv4/ipv6 bug fixes that some net-next work will build upon. Signed-off-by: David S. Miller <[email protected]>
2013-01-26can: c_can: fix invalid error codesOlivier Sobrie1-2/+2
Errors in CAN protocol (location) are reported in data[3] of the can frame instead of data[2]. Cc: linux-stable <[email protected]> Cc: Bhupesh Sharma <[email protected]> Signed-off-by: Olivier Sobrie <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-01-26can: c_can: add LED trigger supportFabio Baltieri1-0/+10
Add support for canbus activity led indicators on c_can devices by calling appropriate can_led functions. These are only enabled when CONFIG_CAN_LEDS is Y, becomes no-op otherwise. Cc: Bhupesh Sharma <[email protected]> Cc: AnilKumar Ch <[email protected]> Cc: Wolfgang Grandegger <[email protected]> Cc: Marc Kleine-Budde <[email protected]> Signed-off-by: Fabio Baltieri <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2013-01-26can: Kconfig: convert 'depends on CAN_DEV' into 'if CAN_DEV...endif' blockMarc Kleine-Budde1-1/+1
This patch adds an 'if CAN_DEV...endif' Block around the CAN driver symbols in drivers/net/can/Kconfig. So the 'depends on CAN' dependencies can be removed. Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-12-07drivers/net: fix up function prototypes after __dev* removalsGreg Kroah-Hartman1-1/+1
The __dev* removal patches for the network drivers ended up messing up the function prototypes for a bunch of drivers. This patch fixes all of them back up to be properly aligned. Bonus is that this almost removes 100 lines of code, always a nice surprise. Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-12-03can: remove __dev* attributesBill Pemberton2-6/+6
CONFIG_HOTPLUG is going away as an option. As result the __dev* markings will be going away. Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit. Signed-off-by: Bill Pemberton <[email protected]> Cc: Wolfgang Grandegger <[email protected]> Cc: Marc Kleine-Budde <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2012-11-27can: c_can_platform: add MODULE_DEVICE_TABLEMarc Kleine-Budde1-0/+2
This patch adds a MODULE_DEVICE_TABLE for the of and platform bindings, so that the module can be loaded automatically by udev. Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-11-27can: c_can: Add d_can raminit supportAnilKumar Ch3-1/+42
Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM, which holds all the message objects during transmission or receiving of data. This initialization/de-initialization should be done in synchronous with D_CAN clock. In case of AM335X-EVM (current user of D_CAN driver) message RAM is controlled through control module register for both instances. So control module register details is required to initialization or de-initialization of message RAM according to instance number. Control module memory resource is obtained from D_CAN dt node and instance number obtained from device tree aliases node. This patch was tested on AM335x-EVM along with pinctrl data addition patch, d_can dt aliases addition and control module data addition. pinctrl data addition is not added to am335x-evm.dts (only supports CPLD profile#0) because d_can1 is supported under CPLD profile#1. Signed-off-by: AnilKumar Ch <[email protected]> [mkl: fix instance for non DT in probe, cleaned up raminit] Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-09-27can: c_can: fix segfault during rmmodAnilKumar Ch1-3/+0
This patch fixes an oops which occurs during unloading the driver. unregister_c_can_dev() is doing c_can/d_can module interrupts disable, which requires module clock enable. c_can/d_can interrupts enable/disable is handled properly in c_can_start and c_can_stop, so removing from unregister_c_can_dev(). The problem was triggered by adding runtime PM support to the c_can driver by this commit: 4cdd34b can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller Signed-off-by: AnilKumar Ch <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-09-21can: c_can: Adopt pinctrl supportAnilKumar Ch1-0/+7
Adopt pinctrl support to c_can driver based on c_can device pointer, pinctrl driver configure SoC pins to d_can mode according to definitions provided in .dts file. In device specific device tree file 'pinctrl-names = "default";' and 'pinctrl-0 = <&d_can1_pins>;' needs to add to configure pins from c_can driver. d_can1_pins node contains the pinmux/config details of d_can L/H pins. Signed-off-by: AnilKumar Ch <[email protected]> Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-09-21can: c_can: Add d_can suspend resume supportAnilKumar Ch3-0/+148
Adds suspend resume support to DCAN driver which enables DCAN power down mode bit (PDR). Then DCAN will ack the local power-down mode by setting PDA bit in STATUS register. Signed-off-by: AnilKumar Ch <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-09-21can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controllerAnilKumar Ch3-2/+49
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM APIs control clocks for C_CAN/D_CAN IP and prevent access to the register of C_CAN/D_CAN IP when clock is turned off. Signed-off-by: AnilKumar Ch <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-09-21can: c_can: Add device tree support to Bosch C_CAN/D_CAN controllerAnilKumar Ch1-17/+38
Add device tree support to C_CAN/D_CAN controller and usage details are added to device tree documentation. Driver was tested on AM335x EVM. Signed-off-by: AnilKumar Ch <[email protected]> For the of binding doc: Reviewed-by: Stephen Warren <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-09-21can: c_can: Modify c_can device namesAnilKumar Ch3-13/+16
Modify c_can device names from *_CAN_DEVTYPE to BOSCH_*_CAN to make use of same names for array indexes in c_can_id_table[] as well as device names. This patch also add indexes to c_can_id_table array. Signed-off-by: AnilKumar Ch <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-07-30net/c_can: remove conditional compilation of clk codeViresh Kumar1-8/+0
With addition of dummy clk_*() calls for non CONFIG_HAVE_CLK cases in clk.h, there is no need to have clk code enclosed in #ifdef CONFIG_HAVE_CLK, #endif macros. Signed-off-by: Viresh Kumar <[email protected]> Acked-by: David S. Miller <[email protected]> Cc: Bhupesh Sharma <[email protected]> Cc: Russell King <[email protected]> Cc: Mike Turquette <[email protected]> Cc: Sergei Shtylyov <[email protected]> Cc: viresh kumar <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2012-07-20can: mark bittiming_const pointer in struct can_priv as constMarc Kleine-Budde1-1/+1
This patch marks the bittiming_const pointer as in the struct can_pric as "const". This allows us to mark the struct can_bittiming_const in the CAN drivers as "const", too. Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-06-20can: c_can_pci: fix compilation on non HAVE_CLK archsMarc Kleine-Budde1-22/+7
In commit: 5b92da0 c_can_pci: generic module for C_CAN/D_CAN on PCI the c_can_pci driver has been added. It uses clk_*() functions resulting in a link error on archs without clock support. This patch removed these clk_() functions as these parts of the driver are not tested. Cc: Federico Vaga <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-06-19c_can_pci: generic module for C_CAN/D_CAN on PCIFederico Vaga3-0/+244
Signed-off-by: Federico Vaga <[email protected]> Acked-by: Giancarlo Asnaghi <[email protected]> Cc: Alan Cox <[email protected]> Acked-by: Wolfgang Grandegger <[email protected]> Acked-by: Bhupesh Sharma <[email protected]> [mkl: fix call to pci_iounmap] Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-06-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-2/+2
Conflicts: net/ipv6/route.c This deals with a merge conflict between the net-next addition of the inetpeer network namespace ops, and Thomas Graf's bug fix in 2a0c451ade8e1783c5d453948289e4a978d417c9 which makes sure we don't register /proc/net/ipv6_route before it is actually safe to do so. Signed-off-by: David S. Miller <[email protected]>
2012-06-15can: c_can: precedence error in c_can_chip_config()Dan Carpenter1-2/+2
(CAN_CTRLMODE_LISTENONLY & CAN_CTRLMODE_LOOPBACK) is (0x02 & 0x01) which is zero so the condition is never true. The intent here was to test that both flags were set. Cc: <[email protected]> # 2.6.39+ Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Oliver Hartkopp <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-06-07can: c_can: Add support for Bosch D_CAN controllerAnilKumar Ch3-19/+94
This patch adds the support for D_CAN controller driver to the existing C_CAN driver. Bosch D_CAN controller is a full-CAN implementation which is compliant to CAN protocol version 2.0 part A and B. Bosch D_CAN user manual can be obtained from: http://www.semiconductors.bosch.de/media/en/pdf/ ipmodules_1/can/d_can_users_manual_111.pdf A new array is added for accessing the d_can registers, according to d_can controller register space. Current D_CAN implementation has following limitations, this is done to avoid large changes to the C_CAN driver. 1. Message objects are limited to 32, 16 for RX and 16 for TX. C_CAN IP supports upto 32 message objects but in case of D_CAN we can configure upto 128 message objects. 2. Using two 16bit reads/writes for accessing the 32bit D_CAN registers. 3. These patches have been tested on little endian machine, there might be some hidden endian-related issues due to the nature of the accesses (32-bit registers accessed as 2 16-bit registers). However, I do not have a big-endian D_CAN implementation to confirm. Signed-off-by: AnilKumar Ch <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-06-07can: c_can: Move overlay structure to array with offset as indexAnilKumar Ch3-107/+154
c_can uses overlay structure for accessing c_can module registers. With this kind of implementation it is difficult to add one more ip which is similar to c_can in functionality but different register offsets. This patch changes the overlay structure implementation to an array with register offset as index. This way we can overcome the above limitation. Signed-off-by: AnilKumar Ch <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-06-03can: c_can: fix race condition in c_can_open()AnilKumar Ch1-1/+2
Fix the issue of C_CAN interrupts getting disabled forever when canconfig utility is used multiple times. According to NAPI usage we disable all the hardware interrupts in ISR and re-enable them in poll(). Current implementation calls napi_enable() after hardware interrupts are enabled. If we get any interrupts between these two steps then we do not process those interrupts because napi is not enabled. Mostly these interrupts come because of STATUS is not 0x7 or ERROR interrupts. If napi_enable() happens before HW interrupts enabled then c_can_poll() function will be called eventual re-enabling. This patch moves the napi_enable() call before interrupts enabled. Cc: [email protected] # 2.6.39+ Signed-off-by: AnilKumar Ch <[email protected]> Acked-by: Wolfgang Grandegger <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-06-03can: c_can: fix an interrupt thrash issue with c_can driverAnilKumar Ch2-4/+4
This patch fixes an interrupt thrash issue with c_can driver. In c_can_isr() function interrupts are disabled and enabled only in c_can_poll() function. c_can_isr() & c_can_poll() both read the irqstatus flag. However, irqstatus is always read as 0 in c_can_poll() because all C_CAN interrupts are disabled in c_can_isr(). This causes all interrupts to be re-enabled in c_can_poll() which in turn causes another interrupt since the event is not really handled. This keeps happening causing a flood of interrupts. To fix this, read the irqstatus register in isr and use the same cached value in the poll function. Cc: [email protected] # 2.6.39+ Signed-off-by: AnilKumar Ch <[email protected]> Acked-by: Wolfgang Grandegger <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2012-06-03can: c_can: fix "BUG! echo_skb is occupied!" during transmitAnilKumar Ch1-2/+4
This patch fixes an issue with transmit routine, which causes "can_put_echo_skb: BUG! echo_skb is occupied!" message when using "cansequence -p" on D_CAN controller. In c_can driver, while transmitting packets tx_echo flag holds the no of can frames put for transmission into the hardware. As the comment above c_can_do_tx() indicates, if we find any packet which is not transmitted then we should stop looking for more. In the current implementation this is not taken care of causing the said message. Also, fix the condition used to find if the packet is transmitted or not. Current code skips the first tx message object and ends up checking one extra invalid object. While at it, fix the comment on top of c_can_do_tx() to use the terminology "packet" instead of "package" since it is more standard. Cc: [email protected] # 2.6.39+ Signed-off-by: AnilKumar Ch <[email protected]> Acked-by: Wolfgang Grandegger <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2011-11-29net/can: convert drivers/net/can/* to use module_platform_driver()Axel Lin1-11/+1
This patch converts the drivers in drivers/net/can/* to use the module_platform_driver() macro which makes the code smaller and a bit simpler. Cc: Wolfgang Grandegger <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Bhupesh Sharma <[email protected]> Cc: Jiri Kosina <[email protected]> Cc: Grant Likely <[email protected]> Cc: Anatolij Gustschin <[email protected]> Cc: Paul Bolle <[email protected]> Cc: Kurt Van Dijck <[email protected]> Cc: Alexey Dobriyan <[email protected]> Signed-off-by: Axel Lin <[email protected]> Acked-by: Marc Kleine-Budde <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2011-07-23can: c_can: remove duplicated #includeHuang Weiyi2-2/+0
Remove duplicated #include('s) in drivers/net/can/c_can/c_can.c drivers/net/can/c_can/c_can_platform.c Signed-off-by: Huang Weiyi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2011-06-24net: Remove unneeded version.h includes from drivers/net/Jesper Juhl2-2/+0
It was pointed out by 'make versioncheck' that some includes of linux/version.h are not needed in drivers/net/. This patch removes them. Signed-off-by: Jesper Juhl <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2011-03-31Fix common misspellingsLucas De Marchi1-2/+2
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <[email protected]>
2011-03-27can: c_can: Fix tx_bytes accountingJan Altenberg1-1/+1
The current SocketCAN implementation for the Bosch c_can cell doesn't account the TX bytes correctly, because it calls c_can_inval_msg_object() (which clears the msg ctrl register) before reading the DLC value: for (/* nix */; (priv->tx_next - priv->tx_echo) > 0; priv->tx_echo++) { msg_obj_no = get_tx_echo_msg_obj(priv); c_can_inval_msg_object(dev, 0, msg_obj_no); val = c_can_read_reg32(priv, &priv->regs->txrqst1); if (!(val & (1 << msg_obj_no))) { can_get_echo_skb(dev, msg_obj_no - C_CAN_MSG_OBJ_TX_FIRST); stats->tx_bytes += priv->read_reg(priv, &priv->regs->ifregs[0].msg_cntrl) & IF_MCONT_DLC_MASK; stats->tx_packets++; } } So, we will always read 0 for the DLC value and "ifconfig" will report *0* TX Bytes. The fix is quite easy: Just move c_can_inval_msg_object() to the end of the if() statement. So: * We only call c_can_inval_msg_object() if the message was actually transmitted * We read out the DLC value _before_ clearing the msg ctrl register Signed-off-by: Jan Altenberg <[email protected]> Acked-by: Kurt Van Dijck <[email protected]> Acked-by: Wolfgang Grandegger <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2011-03-27can: c_can_platform: fix irq check in probeMarc Kleine-Budde1-4/+5
This patch fixes the check in the probe function whether a IRQ was supplied to the driver. The original driver check the irq "struct resource *" against <= 0. Use "platform_get_irq" instead. Signed-off-by: Marc Kleine-Budde <[email protected]> Cc: Bhupesh Sharma <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2011-03-27can: c_can: disable one shot mode until driver is fixedMarc Kleine-Budde1-10/+4
This patch disables the one shot mode, until the driver has been fixed and tested to support it. > I'm quite sure I've seen a situation where msg_obj 17 "seemed" to be > pending, while msg_obj 18 and 19 already have been transmitted. But > in that case, I enabled ONESHOT for the can interface, which enables > the DA mode (automatic retransmission is disabled). Reported-by: Jan Altenberg <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Kurt Van Dijck <[email protected]> Cc: Bhupesh Sharma <[email protected]> Acked-by: Wolfgang Grandegger <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2011-03-21can: c_can: Do basic c_can configuration _before_ enabling the interruptsJan Altenberg1-3/+3
I ran into some trouble while testing the SocketCAN driver for the BOSCH C_CAN controller. The interface is not correctly initialized, if I put some CAN traffic on the line, _while_ the interface is being started (which means: the interface doesn't come up correcty, if there's some RX traffic while doing 'ifconfig can0 up'). The current implementation enables the controller interrupts _before_ doing the basic c_can configuration. I think, this should be done the other way round. The patch below fixes things for me. Signed-off-by: Jan Altenberg <[email protected]> Acked-by: Kurt Van Dijck <[email protected]> Acked-by: Wolfgang Grandegger <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2011-02-13can: c_can: Added support for Bosch C_CAN controllerBhupesh Sharma5-0/+1482
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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>