From aa3cf8cb3a966e4ca52a94b8d28f50739fbfe24c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Karel=20Ko=C4=8D=C3=AD?= Date: Wed, 5 Nov 2025 09:12:47 +0100 Subject: [PATCH] nuttx/can: report error and not EOF at the empty FIFO MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The empty FIFO can happen only in two cases. Either there is some inconsistency that made rx_sem ready but buffer is empty (that might happen if multiple reads are blocked in parallel, or just due to the bug in the logic), or if close is used. Until now the 0 would be returned and thus EOF. The error is not EOF and actually it is still possible to read afterwards. Thus we for sure should not signal EOF for the first cause. The second cause for close matches the behavior that is expressed even on glibc for some file descriptors (the waiting read will commonly get error EINVAL there). We can't decide on the real cause of this situation and thus we always report EIO error and thus generic input/output error. Signed-off-by: Karel Kočí --- drivers/can/can.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/can/can.c b/drivers/can/can.c index 389700a03a9..a61142b75f6 100644 --- a/drivers/can/can.c +++ b/drivers/can/can.c @@ -453,6 +453,9 @@ static ssize_t can_read(FAR struct file *filep, FAR char *buffer, if (fifo->rx_head == fifo->rx_tail) { + /* This happens either due to bug or on reader close. */ + + ret = -EIO; canerr("RX FIFO sem posted but FIFO is empty.\n"); goto return_with_irqdisabled; }