summaryrefslogtreecommitdiffstats
path: root/utils.c
diff options
context:
space:
mode:
authorDenis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>2021-01-19 17:29:55 +0100
committerDenis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>2021-02-28 17:06:43 +0100
commite042bd9967851448e550142c4d8cdb0a557d8927 (patch)
treefa341c495a04d8d73ba3409c3db0029fe51b06fc /utils.c
parent54c23545b1a47e952a2dfeb981b30556e1309296 (diff)
downloadhardware_replicant_libsamsung-ril-e042bd9967851448e550142c4d8cdb0a557d8927.tar.gz
hardware_replicant_libsamsung-ril-e042bd9967851448e550142c4d8cdb0a557d8927.tar.bz2
hardware_replicant_libsamsung-ril-e042bd9967851448e550142c4d8cdb0a557d8927.zip
utils: eventfd_recv: report errors
This enables to distinguish different kind of loop failures. The loop handler comes directly from libsamsung-ipc device drivers, which in turn wrap the vendor kernel interfaces. Given that there is some possible variation between the way that the .loop implementations behaves, it's a good idea to add prints to understand better what is going on in case of issues. With the development of a new set of kernel drivers and libsamsung-ipc device driver for Replicant 11, we had a situation where that code was triggered. Note that, at the time of writing, we are not (yet) aware of any behavior difference with the different .loop implementations, but it would be worth checking if they all behave in the same way. Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Diffstat (limited to 'utils.c')
-rw-r--r--utils.c7
1 files changed, 6 insertions, 1 deletions
diff --git a/utils.c b/utils.c
index 10b4529..cc2e9d9 100644
--- a/utils.c
+++ b/utils.c
@@ -21,6 +21,7 @@
#define LOG_TAG "RIL"
#include <ctype.h>
+#include <errno.h>
#include <stdlib.h>
#include <string.h>
@@ -229,8 +230,12 @@ int eventfd_recv(int fd, eventfd_t *event)
int rc;
rc = eventfd_read(fd, event);
- if (rc < 0)
+ if (rc < 0) {
+ rc = errno;
+ RIL_LOGE("%s: eventfd_read error %d: %s", __func__,
+ rc, strerror(rc));
return -1;
+ }
return 0;
}