linux-toradex.git/drivers/net/can/usb, branch v3.12.51

can: kvaser_usb: Fix state handling upon BUS_ERROR events

2015-02-08T19:01:54+00:00

commit e638642b08c170d2021b706f0b1c4f4ae93d8cbd upstream.

While being in an ERROR_WARNING state, and receiving further
bus error events with error counters still in the ERROR_WARNING
range of 97-127 inclusive, the state handling code erroneously
reverts back to ERROR_ACTIVE.

Per the CAN standard, only revert to ERROR_ACTIVE when the
error counters are less than 96.

Moreover, in certain Kvaser models, the BUS_ERROR flag is
always set along with undefined bits in the M16C status
register. Thus use bitwise operators instead of full equality
for checking that register against bus errors.

Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: kvaser_usb: Retry the first bulk transfer on -ETIMEDOUT

2015-02-08T19:01:53+00:00

commit 14c10c2a1dd8eb8e00b750b521753260befa2789 upstream.

On some x86 laptops, plugging a Kvaser device again after an
unplug makes the firmware always ignore the very first command.
For such a case, provide some room for retries instead of
completely exiting the driver init code.

Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: kvaser_usb: Send correct context to URB completion

2015-02-08T19:01:52+00:00

commit 3803fa6977f1de15fda4e8646c8fec97c8045cae upstream.

Send expected argument to the URB completion hander: a CAN
netdevice instead of the network interface private context
`kvaser_usb_net_priv'.

This was discovered by having some garbage in the kernel
log in place of the netdevice names: can0 and can1.

Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: kvaser_usb: Do not sleep in atomic context

2015-02-08T19:01:52+00:00

commit ded5006667318c06df875609535176bd33f243a1 upstream.

Upon receiving a hardware event with the BUS_RESET flag set,
the driver kills all of its anchored URBs and resets all of
its transmit URB contexts.

Unfortunately it does so under the context of URB completion
handler `kvaser_usb_read_bulk_callback()', which is often
called in an atomic context.

While the device is flooded with many received error packets,
usb_kill_urb() typically sleeps/reschedules till the transfer
request of each killed URB in question completes, leading to
the sleep in atomic bug. [3]

In v2 submission of the original driver patch [1], it was
stated that the URBs kill and tx contexts reset was needed
since we don't receive any tx acknowledgments later and thus
such resources will be locked down forever. Fortunately this
is no longer needed since an earlier bugfix in this patch
series is now applied: all tx URB contexts are reset upon CAN
channel close. [2]

Moreover, a BUS_RESET is now treated _exactly_ like a BUS_OFF
event, which is the recommended handling method advised by
the device manufacturer.

[1] http://article.gmane.org/gmane.linux.network/239442
    http://www.webcitation.org/6Vr2yagAQ

[2] can: kvaser_usb: Reset all URB tx contexts upon channel close
    889b77f7fd2bcc922493d73a4c51d8a851505815

[3] Stacktrace:

   [] dump_stack+0x45/0x57
 [] __schedule_bug+0x41/0x4f
 [] __schedule+0x5f1/0x700
 [] ? _raw_spin_unlock_irqrestore+0xa/0x10
 [] schedule+0x24/0x70
 [] usb_kill_urb+0x65/0xa0
 [] ? prepare_to_wait_event+0x110/0x110
 [] usb_kill_anchored_urbs+0x48/0x80
 [] kvaser_usb_unlink_tx_urbs+0x18/0x50 [kvaser_usb]
 [] kvaser_usb_rx_error+0xc0/0x400 [kvaser_usb]
 [] ? vprintk_default+0x1a/0x20
 [] kvaser_usb_read_bulk_callback+0x4c1/0x5f0 [kvaser_usb]
 [] __usb_hcd_giveback_urb+0x5e/0xc0
 [] usb_hcd_giveback_urb+0x41/0x110
 [] finish_urb+0x98/0x180 [ohci_hcd]
 [] ? acct_account_cputime+0x17/0x20
 [] ? local_clock+0x15/0x30
 [] ohci_work+0x1fb/0x5a0 [ohci_hcd]
 [] ? process_backlog+0xb1/0x130
 [] ohci_irq+0xeb/0x270 [ohci_hcd]
 [] usb_hcd_irq+0x21/0x30
 [] handle_irq_event_percpu+0x43/0x120
 [] handle_irq_event+0x3d/0x60
 [] handle_fasteoi_irq+0x74/0x110
 [] handle_irq+0x1d/0x30
 [] do_IRQ+0x57/0x100
 [] common_interrupt+0x6a/0x6a

Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: kvaser_usb: Don't send a RESET_CHIP for non-existing channels

2015-01-29T14:44:42+00:00

commit 5e7e6e0c9b47a45576c38b4a72d67927a5e049f7 upstream.

Recent Leaf firmware versions (>= 3.1.557) do not allow to send
commands for non-existing channels.  If a command is sent for a
non-existing channel, the firmware crashes.

Reported-by: Christopher Storah 
Signed-off-by: Olivier Sobrie 
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: kvaser_usb: Reset all URB tx contexts upon channel close

2015-01-29T14:44:41+00:00

commit 889b77f7fd2bcc922493d73a4c51d8a851505815 upstream.

Flooding the Kvaser CAN to USB dongle with multiple reads and
writes in very high frequency (*), closing the CAN channel while
all the transmissions are on (#), opening the device again (@),
then sending a small number of packets would make the driver
enter an almost infinite loop of:

[....]
[15959.853988] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853990] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853991] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853993] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853994] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853995] kvaser_usb 4-3:1.0 can0: cannot find free context
[....]

_dragging the whole system down_ in the process due to the
excessive logging output.

Initially, this has caused random panics in the kernel due to a
buggy error recovery path.  That got fixed in an earlier commit.(%)
This patch aims at solving the root cause. -->

16 tx URBs and contexts are allocated per CAN channel per USB
device. Such URBs are protected by:

a) A simple atomic counter, up to a value of MAX_TX_URBS (16)
b) A flag in each URB context, stating if it's free
c) The fact that ndo_start_xmit calls are themselves protected
   by the networking layers higher above

After grabbing one of the tx URBs, if the driver noticed that all
of them are now taken, it stops the netif transmission queue.
Such queue is worken up again only if an acknowedgment was received
from the firmware on one of our earlier-sent frames.

Meanwhile, upon channel close (#), the driver sends a CMD_STOP_CHIP
to the firmware, effectively closing all further communication.  In
the high traffic case, the atomic counter remains at MAX_TX_URBS,
and all the URB contexts remain marked as active.  While opening
the channel again (@), it cannot send any further frames since no
more free tx URB contexts are available.

Reset all tx URB contexts upon CAN channel close.

(*) 50 parallel instances of `cangen0 -g 0 -ix`
(#) `ifconfig can0 down`
(@) `ifconfig can0 up`
(%) "can: kvaser_usb: Don't free packets when tight on URBs"

Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: kvaser_usb: Don't free packets when tight on URBs

2015-01-29T14:44:41+00:00

commit b442723fcec445fb0ae1104888dd22cd285e0a91 upstream.

Flooding the Kvaser CAN to USB dongle with multiple reads and
writes in high frequency caused seemingly-random panics in the
kernel.

On further inspection, it seems the driver erroneously freed the
to-be-transmitted packet upon getting tight on URBs and returning
NETDEV_TX_BUSY, leading to invalid memory writes and double frees
at a later point in time.

Note:

Finding no more URBs/transmit-contexts and returning NETDEV_TX_BUSY
is a driver bug in and out of itself: it means that our start/stop
queue flow control is broken.

This patch only fixes the (buggy) error handling code; the root
cause shall be fixed in a later commit.

Acked-by: Olivier Sobrie 
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: peak_usb: fix memset() usage

2015-01-14T13:42:52+00:00

commit dc50ddcd4c58a5a0226038307d6ef884bec9f8c2 upstream.

This patchs fixes a misplaced call to memset() that fills the request
buffer with 0. The problem was with sending PCAN_USBPRO_REQ_FCT
requests, the content set by the caller was thus lost.

With this patch, the memory area is zeroed only when requesting info
from the device.

Signed-off-by: Stephane Grosjean 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: peak_usb: fix cleanup sequence order in case of error during init

2015-01-14T13:42:52+00:00

commit af35d0f1cce7a990286e2b94c260a2c2d2a0e4b0 upstream.

This patch sets the correct reverse sequence order to the instructions
set to run, when any failure occurs during the initialization steps.
It also adds the missing unregistration call of the can device if the
failure appears after having been registered.

Signed-off-by: Stephane Grosjean 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: esd_usb2: fix memory leak on disconnect

2014-12-06T14:18:18+00:00

commit efbd50d2f62fc1f69a3dcd153e63ba28cc8eb27f upstream.

It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
the missing deallocation.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Acked-by: Matthias Fuchs 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby