FCSI, EWLI trigger and handling
The interrupt triggering improved much in last revisions, still there are some issues.
HW
[ 140.658852] ctucanfd c0052000.ctu_can_fd can1: ctu_can_fd device registered
[ 140.658872] ctucanfd c0052000.ctu_can_fd can1: ctucan_err_interrupt: ISR = 0x00000010, rxerr 0, txerr 0, error type 0, pos 31, ALC id_field 0, bit 0
[ 140.679047] ctucanfd c0052000.ctu_can_fd can1: Fault conf: state = 0
[ 140.685546] ctucanfd c0052000.ctu_can_fd can1: reached error active state
[ 140.692811] IPv6: ADDRCONF(NETDEV_CHANGE): can1: link becomes ready
[ 167.194387] ctucanfd c0052000.ctu_can_fd can1: ctucan_err_interrupt: ISR = 0x00000004, rxerr 0, txerr 96, error type 0, pos 2, ALC id_field 0, bit 0
[ 167.207662] ctucanfd c0052000.ctu_can_fd can1: error_warning
EWL triggers when txerr reaches txerr limit. That's good.
[ 167.213520] ctucanfd c0052000.ctu_can_fd can1: ctucan_err_interrupt: ISR = 0x00000c10, rxerr 0, txerr 163, error type 2, pos 7, ALC id_field 0, bit 0
[ 167.226875] ctucanfd c0052000.ctu_can_fd can1: Fault conf: state = 1
[ 167.233394] ctucanfd c0052000.ctu_can_fd can1: error_warning, but ISR[FCSI] was set! (HW bug?)
[ 167.242331] ctucanfd c0052000.ctu_can_fd can1: error_warning
FCSI triggers, because txerr > 128. Then the controller should become ERROR-PASSIVE, but there is Fault conf: state = 1
, which means ERROR-WARNING. This ERROR-WARNING state is returned by ctucan_hw_read_error_state
function, that reads CTU_CAN_FD_EWL register and finds that reg.s.era
is set. It shouldn't be, right?
Another matter is that when error counters fall down below the error warning limit, the EWLI should trigger too (but it doesn't), so driver can change back to ERROR-ACTIVE state.
Driver
I would then suggest to rewrite error interrupt handling in a way that FCSI and EWLI are handled together in one if
block and get rid of the error_warning, but ISR[FCSI] was set! (HW bug?)
. Or is there a reason to keep it separate?