From: "Sottas Guillaume (LMB)" <Guillaume.Sottas@liebherr.com>
To: "mkl@pengutronix.de" <mkl@pengutronix.de>
Cc: "Sottas Guillaume (LMB)" <Guillaume.Sottas@liebherr.com>,
"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
"socketcan@hartkopp.net" <socketcan@hartkopp.net>
Subject: Re: [PATCH] can: isotp: return -ECOMM on FC timeout on TX path
Date: Wed, 28 Apr 2021 11:43:47 +0000 [thread overview]
Message-ID: <7146dee416c049b5a29fd3cca8a1b773@liebherr.com> (raw)
Hello,
First of all thank you for your fast reply.
From my point of view, I think it would make sense to return an error to the user when CAN_ISOTP_WAIT_TX_DONE option is set. Otherwise, I don't understand the use case of this option?
If the CAN_ISOTP_WAIT_TX_DONE option is not set, then not receiving an error on timeout could be the expected behavior, as the user does not explicitly ask for completion.
Concerning the way of reporting the error, setting the errno would be a nice solution, as it would not require that much modifications. However, as Mark mentioned, the errno is not set.
I'm not an expert in how this sk_error_report works internally, but I will try to get more infos about it.
In both cases, the documentation in the isotp.c (https://elixir.bootlin.com/linux/latest/source/net/can/isotp.c#L7) file is not correct, as it is not the actual behavior (most likely the expected).
Additionally, I guess the -ETIMEOUT, -EILSEQ, -EBADMSG,... described in the same documentation are most likely not working that way either, but would be fixed if the errno is reported correctly.
Best Regards,
Guillaume
next reply other threads:[~2021-04-28 11:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-28 11:43 Sottas Guillaume (LMB) [this message]
2021-04-28 11:48 ` [PATCH] can: isotp: return -ECOMM on FC timeout on TX path Oliver Hartkopp
-- strict thread matches above, loose matches on Subject: below --
2021-05-06 12:45 Sottas Guillaume (LMB)
2021-05-06 13:38 ` Marc Kleine-Budde
2021-04-28 9:09 Marc Kleine-Budde
2021-04-28 9:12 ` Marc Kleine-Budde
2021-04-28 9:26 ` Oliver Hartkopp
2021-04-28 10:24 ` Oliver Hartkopp
2021-04-28 10:47 ` Marc Kleine-Budde
2021-04-28 11:45 ` Oliver Hartkopp
2021-04-28 12:07 ` Marc Kleine-Budde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7146dee416c049b5a29fd3cca8a1b773@liebherr.com \
--to=guillaume.sottas@liebherr.com \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=socketcan@hartkopp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox