can: xilinx_can: xcan_chip_start(): fix failure with invalid bus
authorAnssi Hannula <anssi.hannula@bitwise.fi>
Wed, 3 Apr 2019 12:18:53 +0000 (15:18 +0300)
committerMarc Kleine-Budde <mkl@pengutronix.de>
Tue, 13 Aug 2019 14:42:05 +0000 (16:42 +0200)
commit3486cc40ccbfe4cbf55feecce88a792e3043c178
treefade36b3c95a9949967b572435f8c195397f16e5
parent7123e1c7ea29f841819900bcf99763aa51ecda58
can: xilinx_can: xcan_chip_start(): fix failure with invalid bus

Currently the xilinx_can xcan_chip_start() function, called from
.ndo_open() and via CAN_MODE_START (bus-off restart), waits for the SR
register to show the wanted operating state, with a 1 sec timeout.

However, that register bit will only be set once the HW has observed 11
consecutive recessive bits (BusIdle) on the bus.

If the bus will not see the 11 bits (e.g. it is stuck dominant), the
function will timeout and return an error. If this was done as part of a
scheduled restart from bus-off, the interface will stay in bus-off state
forever even if the bus recovers later.

According to M_CAN and FLEXCAN documentation they also wait for 11
consecutive recessive bits, but their drivers do not seem to wait for
that.

To make the behavior consistent, modify xilinx_can to also not wait for
the synchronization to complete.

The only way for users to know for sure that the bus has been joined
successfully is to see successfully received or transmitted frames. That
does not seem optimal, but it is consistent with other drivers and we
should have a properly working restart-ms with xilinx_can.

Tested on ZynqMP with Xilinx CAN-FD 1.0.

Fixes: b1201e44f50b ("can: xilinx CAN controller support")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Tested-by: Appana Durga Kedareswara Rao <appana.durga.rao@xilinx.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
drivers/net/can/xilinx_can.c