A note on the expected result, since the test is written to fail on a tree
that still has the bug it pins down.
On current mainline the suite reports pass:3 fail:2. The two failures are
the two CAN XL cases, which is the bug; the three passing cases are the
controls. With the fix applied it is pass:5 fail:0. I would rather say
this up front than have someone build it, see two red lines and assume the
test is broken.
The fix it is aimed at is Kaixuan's:
[PATCH v2] can: isotp: check the frame type, not just the length
which was posted on 09-20 and is in the CAN patchwork, not yet in
net-next as far as I can tell. I sent a Reviewed-by for it this morning
and I am not asking for it to be expedited -- only flagging that if this
test lands first, the two failures are real and are what it documents.
If a maintainer would rather not have a red selftest in the tree at all,
the alternative is to take this only after the fix, and I am fine with
that. Say so and I will resend it as a follow-up to the fix instead.
One detail on the skips: the two Classic CAN cases need only any CAN
interface, and the CAN FD acceptance case needs one that carries CAN FD.
The two XL cases and the FD case are skipped rather than failed when the
interface cannot carry the frame type, so a tree built without CAN XL
support still gets flow control and padding coverage rather than a red
result.
v7.3-rc5, vcan, in-kernel isotp sockets on both channels:
stock pass:3 fail:2
Classic-only guard pass:4 fail:1
Kaixuan's v2 pass:5 fail:0
Thanks,
Quchaosheng
