summaryrefslogtreecommitdiffstats
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:01:38 +0100
commit38a78945abf29077a2760a9de1f3fb54f32a4139 (patch)
treeacdb903db2bf581d1eb8ebe113e882967bec669f
parent84850f63d36d85116e29b4877bcade44e105ebbf (diff)
downloadhardware_replicant_libsamsung-ril-38a78945abf29077a2760a9de1f3fb54f32a4139.tar.gz
hardware_replicant_libsamsung-ril-38a78945abf29077a2760a9de1f3fb54f32a4139.tar.bz2
hardware_replicant_libsamsung-ril-38a78945abf29077a2760a9de1f3fb54f32a4139.zip
ipc: ipc_fmt_loop: Complete logging
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>
-rw-r--r--ipc.c12
1 files changed, 11 insertions, 1 deletions
diff --git a/ipc.c b/ipc.c
index 1a6c877..e41823f 100644
--- a/ipc.c
+++ b/ipc.c
@@ -445,14 +445,24 @@ int ipc_fmt_loop(struct ril_client *client)
if (fds.fds[0] == data->event_fd && fds.count > 0) {
rc = eventfd_recv(data->event_fd, &event);
- if (rc < 0)
+ if (rc < 0) {
+ RIL_LOGE("Receiving %s data with eventfd_recv "
+ "failed with error %d",
+ client->name, rc);
goto error;
+ }
switch (event) {
case IPC_CLIENT_CLOSE:
+ RIL_LOGE("Closing %s due to "
+ "IPC_CLIENT_CLOSE",
+ client->name);
rc = 0;
goto complete;
case IPC_CLIENT_IO_ERROR:
+ RIL_LOGE("Exiting %s due to "
+ "IPC_CLIENT_IO_ERROR",
+ client->name);
goto error;
}
}