user/sven/linux.git/drivers/net/can, branch v3.18.37

can: fix oops caused by wrong rtnl dellink usage

2016-07-12T12:47:02Z

[ Upstream commit 25e1ed6e64f52a692ba3191c4fde650aab3ecc07 ] For 'real' hardware CAN devices the netlink interface is used to set CAN specific communication parameters. Real CAN hardware can not be created nor removed with the ip tool ... This patch adds a private dellink function for the CAN device driver interface that does just nothing. It's a follow up to commit 993e6f2fd ("can: fix oops caused by wrong rtnl newlink usage") but for dellink. Reported-by: ajneu Signed-off-by: Oliver Hartkopp Cc: Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: fix handling of unmodifiable configuration options fix

2016-07-12T12:47:01Z

[ Upstream commit bce271f255dae8335dc4d2ee2c4531e09cc67f5a ] With upstream commit bb208f144cf3f59 (can: fix handling of unmodifiable configuration options) a new can_validate() function was introduced. When invoking 'ip link set can0 type can' without any configuration data can_validate() tries to validate the content without taking into account that there's totally no content. This patch adds a check for missing content. Reported-by: ajneu Signed-off-by: Oliver Hartkopp Cc: Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: at91_can: RX queue could get stuck at high bus load

2016-07-12T12:46:56Z

[ Upstream commit 43200a4480cbbe660309621817f54cbb93907108 ] At high bus load it could happen that "at91_poll()" enters with all RX message boxes filled up. If then at the end the "quota" is exceeded as well, "rx_next" will not be reset to the first RX mailbox and hence the interrupts remain disabled. Signed-off-by: Wolfgang Grandegger Tested-by: Amr Bekhit Cc: Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: c_can: Update D_CAN TX and RX functions to 32 bit - fix Altera Cyclone access

2016-07-12T12:46:55Z

[ Upstream commit 427460c83cdf55069eee49799a0caef7dde8df69 ] When testing CAN write floods on Altera's CycloneV, the first 2 bytes are sometimes 0x00, 0x00 or corrupted instead of the values sent. Also observed bytes 4 & 5 were corrupted in some cases. The D_CAN Data registers are 32 bits and changing from 16 bit writes to 32 bit writes fixes the problem. Testing performed on Altera CycloneV (D_CAN). Requesting tests on other C_CAN & D_CAN platforms. Reported-by: Richard Andrysek Signed-off-by: Thor Thayer Cc: Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: fix handling of unmodifiable configuration options

2016-06-03T15:30:37Z

[ Upstream commit bb208f144cf3f59d8f89a09a80efd04389718907 ] As described in 'can: m_can: tag current CAN FD controllers as non-ISO' (6cfda7fbebe) it is possible to define fixed configuration options by setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'. This leads to the incovenience that the fixed configuration bits can not be passed by netlink even when they have the correct values (e.g. non-ISO, FD). This patch fixes that issue and not only allows fixed set bit values to be set again but now requires(!) to provide these fixed values at configuration time. A valid CAN FD configuration consists of a nominal/arbitration bittiming, a data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now enforced by a new can_validate() function. This fix additionally removed the inconsistency that was prohibiting the support of 'CANFD-only' controller drivers, like the RCar CAN FD. For this reason a new helper can_set_static_ctrlmode() has been introduced to provide a proper interface to handle static enabled CAN controller options. Reported-by: Ramesh Shanmugasundaram Signed-off-by: Oliver Hartkopp Reviewed-by: Ramesh Shanmugasundaram Cc: # >= 3.18 Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: gs_usb: fixed disconnect bug by removing erroneous use of kfree()

2016-03-21T02:14:25Z

[ Upstream commit e9a2d81b1761093386a0bb8a4f51642ac785ef63 ] gs_destroy_candev() erroneously calls kfree() on a struct gs_can *, which is allocated through alloc_candev() and should instead be freed using free_candev() alone. The inappropriate use of kfree() causes the kernel to hang when gs_destroy_candev() is called. Only the struct gs_usb * which is allocated through kzalloc() should be freed using kfree() when the device is disconnected. Signed-off-by: Maximilian Schneider Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: ems_usb: Fix possible tx overflow

2016-03-08T06:13:49Z

[ Upstream commit 90cfde46586d2286488d8ed636929e936c0c9ab2 ] This patch fixes the problem that more CAN messages could be sent to the interface as could be send on the CAN bus. This was more likely for slow baud rates. The sleeping _start_xmit was woken up in the _write_bulk_callback. Under heavy TX load this produced another bulk transfer without checking the free_slots variable and hence caused the overflow in the interface. Signed-off-by: Gerhard Uttenthaler Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

Revert "can: fix loss of CAN frames in raw_rcv"

2015-08-04T17:32:39Z

This reverts commit c215cf258214858a5a6c3e63cd7ee78b92d210b2. Signed-off-by: Sasha Levin

can: fix loss of CAN frames in raw_rcv

2015-07-12T16:50:46Z

[ Upstream commit 36c01245eb8046c16eee6431e7dbfbb302635fa8 ] As reported by Manfred Schlaegl here http://marc.info/?l=linux-netdev&m=143482089824232&w=2 commit 514ac99c64b "can: fix multiple delivery of a single CAN frame for overlapping CAN filters" requires the skb->tstamp to be set to check for identical CAN skbs. As net timestamping is influenced by several players (netstamp_needed and netdev_tstamp_prequeue) Manfred missed a proper timestamp which leads to CAN frame loss. As skb timestamping became now mandatory for CAN related skbs this patch makes sure that received CAN skbs always have a proper timestamp set. Maybe there's a better solution in the future but this patch fixes the CAN frame loss so far. Reported-by: Manfred Schlaegl Signed-off-by: Oliver Hartkopp Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: flexcan: Deferred on Regulator return EPROBE_DEFER

2015-04-24T21:13:56Z

[ Upstream commit 555828ef45f825d6ee06559f0304163550eed380 ] Return EPROBE_DEFER if Regulator returns EPROBE_DEFER If the Flexcan driver is built into kernel and a regulator is used to enable the CAN transceiver, the Flexcan driver may not use the regulator. When initializing the Flexcan device with a regulator defined in the device tree, but not initialized, the regulator subsystem returns EPROBE_DEFER, hence the Flexcan init fails. The solution for this is to return EPROBE_DEFER if regulator is not initialized and wait until the regulator is initialized. Signed-off-by: Andreas Werner Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin