Current we can meet timeout issue when setting a small bitrate like 10000
as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock = 30MHZ):
root@imx6ul7d:~# ip link set can0 up type can bitrate 10000
A link change request failed with some changes committed already.
Interface can0 may have been left with an inconsistent configuration, please check.
RTNETLINK answers: Connection timed out
It is caused by calling of flexcan_chip_unfreeze() timeout.
Originally the code is using usleep_range(10, 20) for unfreeze operation,
but the patch (8badd65 can: flexcan: avoid calling usleep_range from interrupt
context) changed it into udelay(10) which is only a half delay of before,
there're also some other delay changes.
After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue.
Signed-off-by: Joakim Zhang <redacted>
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-----Original Message-----
From: Joakim Zhang
Sent: Thursday, January 31, 2019 5:37 PM
To: mkl@pengutronix.de; linux-can@vger.kernel.org
Cc: wg@grandegger.com; netdev@vger.kernel.org;
linux-kernel@vger.kernel.org; dl-linux-imx [off-list ref]; Joakim
Zhang [off-list ref]
Subject: [PATCH] can: flexcan: fix timeout when set small bitrate
Current we can meet timeout issue when setting a small bitrate like 10000 as
follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock = 30MHZ):
root@imx6ul7d:~# ip link set can0 up type can bitrate 10000 A link change
request failed with some changes committed already.
Interface can0 may have been left with an inconsistent configuration, please
check.
RTNETLINK answers: Connection timed out
It is caused by calling of flexcan_chip_unfreeze() timeout.
Originally the code is using usleep_range(10, 20) for unfreeze operation, but
the patch (8badd65 can: flexcan: avoid calling usleep_range from interrupt
context) changed it into udelay(10) which is only a half delay of before,
there're also some other delay changes.
After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue.
Signed-off-by: Joakim Zhang <redacted>
Kindly Ping...
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Best Regards,
Joakim Zhang
quoted hunk
-----Original Message-----
From: Joakim Zhang
Sent: 2019年1月31日 17:37
To: mkl@pengutronix.de; linux-can@vger.kernel.org
Cc: wg@grandegger.com; netdev@vger.kernel.org;
linux-kernel@vger.kernel.org; dl-linux-imx [off-list ref]; Joakim
Zhang [off-list ref]
Subject: [PATCH] can: flexcan: fix timeout when set small bitrate
Current we can meet timeout issue when setting a small bitrate like 10000 as
follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock = 30MHZ):
root@imx6ul7d:~# ip link set can0 up type can bitrate 10000 A link change
request failed with some changes committed already.
Interface can0 may have been left with an inconsistent configuration, please
check.
RTNETLINK answers: Connection timed out
It is caused by calling of flexcan_chip_unfreeze() timeout.
Originally the code is using usleep_range(10, 20) for unfreeze operation, but
the patch (8badd65 can: flexcan: avoid calling usleep_range from interrupt
context) changed it into udelay(10) which is only a half delay of before,
there're also some other delay changes.
After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue.
Signed-off-by: Joakim Zhang <redacted>
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2019-02-27 11:06:36
On 1/31/19 10:37 AM, Joakim Zhang wrote:
Current we can meet timeout issue when setting a small bitrate like 10000
as follows on i.MX6UL EVK board (ipg clock = 66MHZ, per clock = 30MHZ):
root@imx6ul7d:~# ip link set can0 up type can bitrate 10000
A link change request failed with some changes committed already.
Interface can0 may have been left with an inconsistent configuration, please check.
RTNETLINK answers: Connection timed out
It is caused by calling of flexcan_chip_unfreeze() timeout.
Originally the code is using usleep_range(10, 20) for unfreeze operation,
but the patch (8badd65 can: flexcan: avoid calling usleep_range from interrupt
context) changed it into udelay(10) which is only a half delay of before,
there're also some other delay changes.
After double to FLEXCAN_TIMEOUT_US to 100 can fix the issue.
Signed-off-by: Joakim Zhang <redacted>
Applied to linux-can
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |