FlexCAN on i.MX28 interrupt flooding retrying send

FlexCAN on i.MX28 interrupt flooding retrying send

[Stanislav Meduna]

Hi,

I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
If a packet is being sent when the bus is disconnected, I am getting
an interrupt flooed that basically kills the machine.

This is _not_ the same problem as [2] - my kernel already has
the fix.

The first interrupt comes with ESR 0x00028652, i.e.

TXWRN_INT
BIT1_ERR
STF_ERR
TX_WRN
TXRX
FLT_CONF error passive
ERR_INT

The next ones come the same without the acked TXWRN_INT.
Reading the ESR again immediately after acking gives
0x00000250, i.e.

TX_WRN
TXRX
FLT_CONF error passive

so everything ackable has actually been acked.

I think that the problem is that the FlexCAN tries to retransmit
the frame indefinitely. Each retry senses the bus in the invalid
state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
this I aborted the transmitted frame in the error state in the
interrupt handler

#define FLEXCAN_ESR_ERR_TRANSMIT \
	(FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)

if (reg_esr & FLEXCAN_ESR_ERR_TRANSMIT) {

	/* In case of a transmission error the packet is retried and
	 * if the error persists, we will get another interrupt right
	 * away. Abort the transmission - a lost packet is better than
	 * an irq storm.
	 */
	if(printk_ratelimit())
		netdev_err(dev, "Aborted transmission, ESR %08x\n", reg_esr);

	can_get_echo_skb(dev, 0);
	flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
		&regs->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
	netif_wake_queue(dev);
}

and the problem disappeared as expected. However, the correct
way is probably to retry during some reasonable (configurable?)
time interval.

What puzzles me is that I did not found any other instance
of this problem in the relevant mailing lists, only the original [2].

I am using the 3.4.77 kernel with the realtime patches, but the
code in the latest mainline looks the same in this respect.
Maybe the realtime patches change some bevaviour, but I don't
think they affect the core problem. I am not really an expert
in the network devices, NAPI etc - maybe in that case the error
interrupt should be disabled and re-enabled only if the
error condition goes away? - I don't know...

Please Cc: me when answering to the list.

[1] http://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma28/extb/Main/productdetail/
[2] https://gitorious.org/linux-can/wg-linux-can-next/commit/8ad94fa

Thanks
-- 
                                           Stano

Re: FlexCAN on i.MX28 interrupt flooding retrying send

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]

Adding the linux-can mailinglist to Cc.

Marc

On 03/07/2014 09:08 AM, Stanislav Meduna wrote:
> Hi,
> 
> I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
> If a packet is being sent when the bus is disconnected, I am getting
> an interrupt flooed that basically kills the machine.
> 
> This is _not_ the same problem as [2] - my kernel already has
> the fix.
> 
> The first interrupt comes with ESR 0x00028652, i.e.
> 
> TXWRN_INT
> BIT1_ERR
> STF_ERR
> TX_WRN
> TXRX
> FLT_CONF error passive
> ERR_INT
> 
> The next ones come the same without the acked TXWRN_INT.
> Reading the ESR again immediately after acking gives
> 0x00000250, i.e.
> 
> TX_WRN
> TXRX
> FLT_CONF error passive
> 
> so everything ackable has actually been acked.
> 
> I think that the problem is that the FlexCAN tries to retransmit
> the frame indefinitely. Each retry senses the bus in the invalid
> state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
> this I aborted the transmitted frame in the error state in the
> interrupt handler
> 
> #define FLEXCAN_ESR_ERR_TRANSMIT \
> 	(FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)
> 
> if (reg_esr & FLEXCAN_ESR_ERR_TRANSMIT) {
> 
> 	/* In case of a transmission error the packet is retried and
> 	 * if the error persists, we will get another interrupt right
> 	 * away. Abort the transmission - a lost packet is better than
> 	 * an irq storm.
> 	 */
> 	if(printk_ratelimit())
> 		netdev_err(dev, "Aborted transmission, ESR %08x\n", reg_esr);
> 
> 	can_get_echo_skb(dev, 0);
> 	flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
> 		&regs->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
> 	netif_wake_queue(dev);
> }
> 
> and the problem disappeared as expected. However, the correct
> way is probably to retry during some reasonable (configurable?)
> time interval.
> 
> What puzzles me is that I did not found any other instance
> of this problem in the relevant mailing lists, only the original [2].
> 
> I am using the 3.4.77 kernel with the realtime patches, but the
> code in the latest mainline looks the same in this respect.
> Maybe the realtime patches change some bevaviour, but I don't
> think they affect the core problem. I am not really an expert
> in the network devices, NAPI etc - maybe in that case the error
> interrupt should be disabled and re-enabled only if the
> error condition goes away? - I don't know...
> 
> Please Cc: me when answering to the list.
> 
> [1] http://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma28/extb/Main/productdetail/
> [2] https://gitorious.org/linux-can/wg-linux-can-next/commit/8ad94fa
> 
> Thanks
> 


-- 
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   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

Re: FlexCAN on i.MX28 interrupt flooding retrying send

[Matthias Klein]

Hello Stanislav,

I made a similar observation on an i.MX537 with the 3.12.12-rt19 kernel: 
I see the same interrupt flooed when the bus is disconnected.

What do you mean with "kills the machine"? I have a high interrupt load, 
but the machine is still responsive.


Best regards,

Matthias


------ Originalnachricht ------
Von: "Stanislav Meduna" <stano@meduna.org>
An: wg@grandegger.com; mkl@pengutronix.de; linux-can@vger.kernel.org; 
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>; 
"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>
Gesendet: 07.03.2014 09:08:42
Betreff: FlexCAN on i.MX28 interrupt flooding retrying send
>Hi,
>
>I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
>If a packet is being sent when the bus is disconnected, I am getting
>an interrupt flooed that basically kills the machine.
>
>This is _not_ the same problem as [2] - my kernel already has
>the fix.
>
>The first interrupt comes with ESR 0x00028652, i.e.
>
>TXWRN_INT
>BIT1_ERR
>STF_ERR
>TX_WRN
>TXRX
>FLT_CONF error passive
>ERR_INT
>
>The next ones come the same without the acked TXWRN_INT.
>Reading the ESR again immediately after acking gives
>0x00000250, i.e.
>
>TX_WRN
>TXRX
>FLT_CONF error passive
>
>so everything ackable has actually been acked.
>
>I think that the problem is that the FlexCAN tries to retransmit
>the frame indefinitely. Each retry senses the bus in the invalid
>state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
>this I aborted the transmitted frame in the error state in the
>interrupt handler
>
>#define FLEXCAN_ESR_ERR_TRANSMIT \
>  (FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)
>
>if (reg_esr & FLEXCAN_ESR_ERR_TRANSMIT) {
>
>  /* In case of a transmission error the packet is retried and
>   * if the error persists, we will get another interrupt right
>   * away. Abort the transmission - a lost packet is better than
>   * an irq storm.
>   */
>  if(printk_ratelimit())
>   netdev_err(dev, "Aborted transmission, ESR %08x\n", reg_esr);
>
>  can_get_echo_skb(dev, 0);
>  flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
>   &regs->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
>  netif_wake_queue(dev);
>}
>
>and the problem disappeared as expected. However, the correct
>way is probably to retry during some reasonable (configurable?)
>time interval.
>
>What puzzles me is that I did not found any other instance
>of this problem in the relevant mailing lists, only the original [2].
>
>I am using the 3.4.77 kernel with the realtime patches, but the
>code in the latest mainline looks the same in this respect.
>Maybe the realtime patches change some bevaviour, but I don't
>think they affect the core problem. I am not really an expert
>in the network devices, NAPI etc - maybe in that case the error
>interrupt should be disabled and re-enabled only if the
>error condition goes away? - I don't know...
>
>Please Cc: me when answering to the list.
>
>[1] 
>http://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma28/extb/Main/productdetail/
>[2] https://gitorious.org/linux-can/wg-linux-can-next/commit/8ad94fa
>
>Thanks
>--
>                                            Stano
>--
>To unsubscribe from this list: send the line "unsubscribe 
>linux-rt-users" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>

Re: FlexCAN on i.MX28 interrupt flooding retrying send

[Wolfgang Grandegger]

On 03/07/2014 09:16 AM, Marc Kleine-Budde wrote:
> Adding the linux-can mailinglist to Cc.
> 
> Marc
> 
> On 03/07/2014 09:08 AM, Stanislav Meduna wrote:
>> Hi,
>>
>> I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
>> If a packet is being sent when the bus is disconnected, I am getting
>> an interrupt flooed that basically kills the machine.
>>
>> This is _not_ the same problem as [2] - my kernel already has
>> the fix.
>>
>> The first interrupt comes with ESR 0x00028652, i.e.
>>
>> TXWRN_INT
>> BIT1_ERR
>> STF_ERR
>> TX_WRN
>> TXRX
>> FLT_CONF error passive
>> ERR_INT
>>
>> The next ones come the same without the acked TXWRN_INT.
>> Reading the ESR again immediately after acking gives
>> 0x00000250, i.e.
>>
>> TX_WRN
>> TXRX
>> FLT_CONF error passive
>>
>> so everything ackable has actually been acked.
>>
>> I think that the problem is that the FlexCAN tries to retransmit
>> the frame indefinitely. Each retry senses the bus in the invalid
>> state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
>> this I aborted the transmitted frame in the error state in the
>> interrupt handler
>>
>> #define FLEXCAN_ESR_ERR_TRANSMIT \
>> 	(FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)
>>
>> if (reg_esr & FLEXCAN_ESR_ERR_TRANSMIT) {
>>
>> 	/* In case of a transmission error the packet is retried and
>> 	 * if the error persists, we will get another interrupt right
>> 	 * away. Abort the transmission - a lost packet is better than
>> 	 * an irq storm.
>> 	 */
>> 	if(printk_ratelimit())
>> 		netdev_err(dev, "Aborted transmission, ESR %08x\n", reg_esr);
>>
>> 	can_get_echo_skb(dev, 0);
>> 	flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
>> 		&regs->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
>> 	netif_wake_queue(dev);
>> }
>>
>> and the problem disappeared as expected. However, the correct
>> way is probably to retry during some reasonable (configurable?)
>> time interval.
>>
>> What puzzles me is that I did not found any other instance
>> of this problem in the relevant mailing lists, only the original [2].
>>
>> I am using the 3.4.77 kernel with the realtime patches, but the
>> code in the latest mainline looks the same in this respect.
>> Maybe the realtime patches change some bevaviour, but I don't
>> think they affect the core problem. I am not really an expert
>> in the network devices, NAPI etc - maybe in that case the error
>> interrupt should be disabled and re-enabled only if the
>> error condition goes away? - I don't know...
>>
>> Please Cc: me when answering to the list.
>>
>> [1] http://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma28/extb/Main/productdetail/
>> [2] https://gitorious.org/linux-can/wg-linux-can-next/commit/8ad94fa

If bus-error reporting is enabled, you will get an interrupt for each
TX retry. That's normal behavior. But for the i.MX28 it should not be
enabled:

  $ cat flexcan.c
  ...
        /*
         * enable the "error interrupt" (FLEXCAN_CTRL_ERR_MSK),
         * on most Flexcan cores, too. Otherwise we don't get
         * any error warning or passive interrupts.
         */
        if (priv->devtype_data->features & FLEXCAN_HAS_BROKEN_ERR_STATE ||
            priv->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING)
                reg_ctrl |= FLEXCAN_CTRL_ERR_MSK;

Maybe there is something wrong with you platform code or DTS file. What
kernel are you using and how is the DTS can node defined in your DTS file?

Wolfgang.

Re: FlexCAN on i.MX28 interrupt flooding retrying send

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 3095 bytes --]

On 03/07/2014 09:08 AM, Stanislav Meduna wrote:
> Hi,
> 
> I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
> If a packet is being sent when the bus is disconnected, I am getting
> an interrupt flooed that basically kills the machine.
> 
> This is _not_ the same problem as [2] - my kernel already has
> the fix.
> 
> The first interrupt comes with ESR 0x00028652, i.e.
> 
> TXWRN_INT
> BIT1_ERR
> STF_ERR
> TX_WRN
> TXRX
> FLT_CONF error passive
> ERR_INT
> 
> The next ones come the same without the acked TXWRN_INT.
> Reading the ESR again immediately after acking gives
> 0x00000250, i.e.
> 
> TX_WRN
> TXRX
> FLT_CONF error passive
> 
> so everything ackable has actually been acked.
> 
> I think that the problem is that the FlexCAN tries to retransmit
> the frame indefinitely. Each retry senses the bus in the invalid
> state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
> this I aborted the transmitted frame in the error state in the
> interrupt handler
> 
> #define FLEXCAN_ESR_ERR_TRANSMIT \
> 	(FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)
> 
> if (reg_esr & FLEXCAN_ESR_ERR_TRANSMIT) {
> 
> 	/* In case of a transmission error the packet is retried and
> 	 * if the error persists, we will get another interrupt right
> 	 * away. Abort the transmission - a lost packet is better than
> 	 * an irq storm.
> 	 */
> 	if(printk_ratelimit())
> 		netdev_err(dev, "Aborted transmission, ESR %08x\n", reg_esr);
> 
> 	can_get_echo_skb(dev, 0);
> 	flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
> 		&regs->cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
> 	netif_wake_queue(dev);
> }
> 
> and the problem disappeared as expected. However, the correct
> way is probably to retry during some reasonable (configurable?)
> time interval.
> 
> What puzzles me is that I did not found any other instance
> of this problem in the relevant mailing lists, only the original [2].
> 
> I am using the 3.4.77 kernel with the realtime patches, but the
> code in the latest mainline looks the same in this respect.
> Maybe the realtime patches change some bevaviour, but I don't
> think they affect the core problem. I am not really an expert
> in the network devices, NAPI etc - maybe in that case the error
> interrupt should be disabled and re-enabled only if the
> error condition goes away? - I don't know...

Your kernel is missing the patch:

e358784 can: flexcan: fix mx28 detection by rearanging OF match table

With this patch the CAN core properly detected as an mx28, so that bus
errors stay disabled (unless you enable them). If you need bus errors to
detect not connected CAN busses, you need another patchset berr_limit,
which is not yet mainline. I can repost it here, if you need it.

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   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

Re: FlexCAN on i.MX28 interrupt flooding retrying send

[Stanislav Meduna]

On 07.03.2014 09:46, Marc Kleine-Budde wrote:

> Adding the linux-can mailinglist to Cc.

I am not subscribed so maybe that's why the original mail
did not get through - I did Cc: linux-can@vger.kernel.org

> Your kernel is missing the patch:
> 
> e358784 can: flexcan: fix mx28 detection by rearanging OF match table
> 
> With this patch the CAN core properly detected as an mx28, so that bus
> errors stay disabled (unless you enable them). If you need bus errors to
> detect not connected CAN busses, you need another patchset berr_limit,
> which is not yet mainline. I can repost it here, if you need it.

Ah ok.

Thank you, this probably points me to the right direction - I'll try
to implement this behaviour in my kernel (unfortunately
I cannot move to more recent one at the moment).

On 07.03.2014 09:40, Wolfgang Grandegger wrote:

> Maybe there is something wrong with you platform code or DTS file. What
> kernel are you using and how is the DTS can node defined in your DTS file?

This is a the 3.4.77 kernel with the realtime patches and without
the device tree, so these settings are missing and the patch does
not apply.

On 07.03.2014 09:32, Matthias Klein wrote:

> I made a similar observation on an i.MX537 with the 3.12.12-rt19
> kernel: I see the same interrupt flooed when the bus is
> disconnected.
>
> What do you mean with "kills the machine"? I have a high interrupt
> load, but the machine is still responsive.

In my case the ssh connection became hung or updated once per several
seconds etc. In one case it was even necessary to ifconfig down/up
the ethernet interface (NAPI overload? - no idea). The exact behaviour
might be related to the realtime patches - we need guaranteed response
times and runaway interrupt processing hogging the CPU at the realtime
priority is a problem.

Many thanks
-- 
                                      Stano

Re: FlexCAN on i.MX28 interrupt flooding retrying send

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On 03/07/2014 02:36 PM, Stanislav Meduna wrote:
>> Adding the linux-can mailinglist to Cc.
> 
> I am not subscribed so maybe that's why the original mail
> did not get through - I did Cc: linux-can@vger.kernel.org

My bad, linux-can was on Cc, but it arrived on linux-can late.

>> Your kernel is missing the patch:
>>
>> e358784 can: flexcan: fix mx28 detection by rearanging OF match table
>>
>> With this patch the CAN core properly detected as an mx28, so that bus
>> errors stay disabled (unless you enable them). If you need bus errors to
>> detect not connected CAN busses, you need another patchset berr_limit,
>> which is not yet mainline. I can repost it here, if you need it.
> 
> Ah ok.
> 
> Thank you, this probably points me to the right direction - I'll try
> to implement this behaviour in my kernel (unfortunately
> I cannot move to more recent one at the moment).

The flexcan driver in you kernel doesn't have the improvements for mx28,
i.e. that the bus error is not needed on that CAN core. I think for non
DT we never added that support.

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   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

Re: FlexCAN on i.MX28 interrupt flooding retrying send

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

On 03/07/2014 03:24 PM, Jason R1 White wrote:
> Marc,
> 
> What do you mean that flexcan driver doesn't have the improvement for the
> mx28?  What do you mean by non DT?  I see e358784 in the kernel tree, but

Your flexcan driver does always enable bus errors, because on most older
socks you need the bus errors as a workaround to detect the warning and
passive interrupt. With modern kernel on the mx28, the bus error is not
enabled by default.

In the development of the kernel, the mx28 was first switched to Device
Tree (DT) only, then we figured out, that the mx28 doesn't have the
above mentioned problem and the bus error is disabled by default.

> we are not yet picking it up.  Is there any other fixes for the mx28 that
> you are aware of?  Can you send the patch set for the berror_limit?  We
> experienced a lot of issues with the error interrupt causing a lot of
> cpu usage and ended up having to disable it.  Normally I like to at
> least detect the bus error condition.

I'm in the hot phase of two projects, so it will take some time to dig
into the berr_limit again, as it needs some work.

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   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

Re: FlexCAN on i.MX28 interrupt flooding retrying send

[Wolfgang Grandegger]

On 03/07/2014 03:41 PM, Jason R1 White wrote:
> Do you know why this is the case?  Is there a bug in the iMX28?  I've
> never had issues with other controls not being to handle this properly.

There are a few Flexcan core variants around which do not behave the
same way. For further information have a look to the following comment
in the Flexcan driver:

  http://lxr.linux.no/#linux+v3.13.5/drivers/net/can/flexcan.c#L147

Wolfgang.

Re: FlexCAN on i.MX28 interrupt flooding retrying send

[Wolfgang Grandegger]

On 03/07/2014 02:36 PM, Stanislav Meduna wrote:
> On 07.03.2014 09:46, Marc Kleine-Budde wrote:
> 
>> Adding the linux-can mailinglist to Cc.
> 
> I am not subscribed so maybe that's why the original mail
> did not get through - I did Cc: linux-can@vger.kernel.org
> 
>> Your kernel is missing the patch:
>>
>> e358784 can: flexcan: fix mx28 detection by rearanging OF match table
>>
>> With this patch the CAN core properly detected as an mx28, so that bus
>> errors stay disabled (unless you enable them). If you need bus errors to
>> detect not connected CAN busses, you need another patchset berr_limit,
>> which is not yet mainline. I can repost it here, if you need it.
> 
> Ah ok.
> 
> Thank you, this probably points me to the right direction - I'll try
> to implement this behaviour in my kernel (unfortunately
> I cannot move to more recent one at the moment).

The following hack should fix the problem:

diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index eb4014a..a6be018 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -727,7 +727,16 @@ static int flexcan_chip_start(struct net_device *dev)
 	reg_ctrl = flexcan_read(&regs->ctrl);
 	reg_ctrl &= ~FLEXCAN_CTRL_TSYN;
 	reg_ctrl |= FLEXCAN_CTRL_BOFF_REC | FLEXCAN_CTRL_LBUF |
-		FLEXCAN_CTRL_ERR_STATE | FLEXCAN_CTRL_ERR_MSK;
+		FLEXCAN_CTRL_ERR_STATE;
+
+	/*
+	 * Quick and dirty hack to enable the "error interrupt"
+	 * (FLEXCAN_CTRL_ERR_MSK) for the i.MX8. Warning: this
+	 * does not work on most other Flexcan cores. There, we
+	 * then don't get any error warning or passive interrupts.
+	 */
+	if (priv->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING)
+		reg_ctrl |= FLEXCAN_CTRL_ERR_MSK;
 
 	/* save for later use */
 	priv->reg_ctrl_default = reg_ctrl;

Anyway, you should check if there are other important improvement and
fixes a pending.

Wolfgang.