hardware_replicant_libsamsung-ril/ipc.c, branch main

ipc: ipc_rfs_loop: Complete logging

2021-02-28T16:04:50+00:00

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

ipc: ipc_fmt_loop: Complete logging

2021-02-28T16:01:38+00:00

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

ipc: ipc_rfs_loop: be more verbose about loop failures

2021-02-28T15:58:25+00:00

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

ipc: ipc_fmt_loop: be more verbose about loop failures

2021-02-28T15:58:25+00:00

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

ipc.c: break lines over 80 characters

2021-02-28T15:58:23+00:00

Signed-off-by: Denis 'GNUtoo' Carikli

ipc.c: sort #includes alphabetically

2021-02-28T15:58:21+00:00

This makes it easier to spot duplicated headers, find missing
headers, or check if a specific header is present.

Signed-off-by: Denis 'GNUtoo' Carikli

Silence warnings about unused parameters

2019-07-24T14:25:31+00:00

Signed-off-by: Denis 'GNUtoo' Carikli

Remove unused labels

2019-06-18T19:00:59+00:00

Signed-off-by: Denis 'GNUtoo' Carikli 
Reviewed-by: Joonas Kylmälä

client: RIL state update delegation, no client destroy, IPC client boot in open

2014-10-04T21:22:20+00:00

Signed-off-by: Paul Kocialkowski

Samsung-RIL rewrite: harder, better, probably not faster but definitely stronger

2014-08-07T11:12:15+00:00

Signed-off-by: Paul Kocialkowski