linux-stable.git/drivers/net/can, branch v3.12.65

can: dev: fix deadlock reported after bus-off

2016-10-07T08:03:57+00:00

commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] https://github.com/victronenergy/venus/issues/24

Signed-off-by: Sergei Miroshnichenko 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: flexcan: fix resume function

2016-10-06T06:21:57+00:00

commit 4de349e786a3a2d51bd02d56f3de151bbc3c3df9 upstream.

On a imx6ul-pico board the following error is seen during system suspend:

dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110
PM: Device 2090000.flexcan failed to resume: error -110

The reason for this suspend error is because when the CAN interface is not
active the clocks are disabled and then flexcan_chip_enable() will
always fail due to a timeout error.

In order to fix this issue, only call flexcan_chip_enable/disable()
when the CAN interface is active.

Based on a patch from Dong Aisheng in the NXP kernel.

Signed-off-by: Fabio Estevam 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

Revert "can: fix handling of unmodifiable configuration options fix"

2016-09-29T09:13:52+00:00

This reverts commit ded1c127d6dc1a1827f3ff657a4cb7edd646092e which was
bce271f255dae8335dc4d2ee2c4531e09cc67f5a upstream.

It was applied incorrectly, and isn't needed for 3.12-stable.

Reported-by: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

can: fix oops caused by wrong rtnl dellink usage

2016-08-19T07:50:59+00:00

commit 25e1ed6e64f52a692ba3191c4fde650aab3ecc07 upstream.

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 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: fix handling of unmodifiable configuration options fix

2016-08-19T07:50:58+00:00

commit bce271f255dae8335dc4d2ee2c4531e09cc67f5a upstream.

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 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

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

2016-08-19T07:50:58+00:00

commit 43200a4480cbbe660309621817f54cbb93907108 upstream.

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 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: ems_usb: Fix possible tx overflow

2016-03-03T11:45:52+00:00

commit 90cfde46586d2286488d8ed636929e936c0c9ab2 upstream.

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 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: sja1000: clear interrupts on start

2016-01-05T15:23:35+00:00

commit 7cecd9ab80f43972c056dc068338f7bcc407b71c upstream.

According to SJA1000 data sheet error-warning (EI) interrupt is not
cleared by setting the controller in to reset-mode.

Then if we have the following case:
- system is suspended (echo mem > /sys/power/state) and SJA1000 is left
  in operating state
- A bus error condition occurs which activates EI interrupt, system is
  still suspended which means EI interrupt will be not be handled nor
  cleared.

If the above two events occur, on resume there is no way to return the
SJA1000 to operating state, except to cycle power to it.

By simply reading the IR register on start we will clear any previous
conditions that could be present.

Signed-off-by: Mirza Krak 
Reported-by: Christian Magnusson 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: flexcan: Deferred on Regulator return EPROBE_DEFER

2015-04-22T06:58:40+00:00

commit 555828ef45f825d6ee06559f0304163550eed380 upstream.

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 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby

can: add missing initialisations in CAN related skbuffs

2015-04-09T11:14:05+00:00

commit 969439016d2cf61fef53a973d7e6d2061c3793b1 upstream.

When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
this can lead to a skb_under_panic due to missing skb initialisations.

Add the missing initialisations at the CAN skbuff creation times on driver
level (rx path) and in the network layer (tx path).

Reported-by: Austin Schuh 
Reported-by: Daniel Steer 
Signed-off-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Jiri Slaby