| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has several advantages:
- It makes the header context more obvious: #include "xmm626.h" could
mislead people into thinking that the xmm626.h header is in the same
directory than the file using that directive, while it is instead in
another location. This in turn could make people suppose that there
is a "xmm626.h" header specific to the galaxys2 driver.
Instead the #include "modems/xmm616/xmm616.h" directive is much more
clear.
- We can have two headers with the same filename.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way <> and "" are included are implementation defined according to
the C18 standard[1]:
A preprocessing directive of the form
# include < h-char-sequence > new-line
searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters, and causes the replacement of that directive by the entire
contents of the header. How the places are specified or the header
identified is implementation-defined.
A preprocessing directive of the form
# include " q-char-sequence " new-line
causes the replacement of that directive by the entire contents of the
source file identified by the specified sequence between the "
delimiters. The named source file is searched for in an
implementation-defined manner. If this search is not supported, or if
the search fails, the directive is reprocessed as if it read
And the GCC documentation has the following on #include directives[2]:
Both user and system header files are included using the preprocessing
directive ‘#include’. It has two variants:
#include <file>
This variant is used for system header files. It searches for a file
named file in a standard list of system directories. You can prepend
directories to this list with the -I option (see Invocation).
#include "file"
This variant is used for header files of your own program. It searches
for a file named file first in the directory containing the current
file, then in the quote directories and then the same directories used
for <file>. You can prepend directories to the list of quote
directories with the -iquote option.
References:
-----------
[1]The standard doesn't seem to be available for free, but the draft
can be downloaded from the following URL:
https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf
[2]https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
| |
This contains no functional changes.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Reviewed-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
|
|
|
|
|
|
|
|
|
| |
This enables to use logging inside the callbacks.
At this point the ipc_client struct is already available,
so it is safe to do that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
|
| |
This enables to use logging inside the callbacks.
At this point the ipc_client struct is already available,
so it is safe to do that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The XMM626 is the modem model, and SEC is a reference to
Samsung Electronics.
However, in practice the xmm626_sec_modem file and
functions are tied to a specific kernel interface which is
not upstream.
In CyanogenMod, LineageOS and Replicant (up to the 6.0
version), most of the devices supported by libsamsung-ipc
use a kernel named android_kernel_samsung_smdk4412, which
implements this interface.
So it is more clear to use a name that reflects that
instead of using the generic xmm626_sec_modem name.
Even if SMDK4412 is also a Samsung evaluation board for the
Exynos 4412 System on a chip, the kernel name is probably
way more known to people working on supporting devices with
an XMM626 modem in libsamsung-ipc.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
|
| |
This enables to use logging inside the callbacks.
At this point the ipc_client struct is already available,
so it is safe to do that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
|
| |
This enables to use logging inside the callbacks.
At this point the ipc_client struct is already available,
so it is safe to do that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
|
|
|
| |
This enables to use logging inside the handlers:
ipc_client_log needs access to the ipc_client struct to
work.
At this point the ipc_client struct is already available,
so it is safe to do that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
|
|
|
| |
This enables to use logging inside the handlers:
ipc_client_log needs access to the ipc_client struct to
work.
At this point the ipc_client struct is already available,
so it is safe to do that.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
| |
Acked-by: Fil Lupin <fillupin@protonmail.com>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
| |
Acked-by: Fil Lupin <fillupin@protonmail.com>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
| |
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
| |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
|
|
|
| |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
|
|
|
| |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
|
|
|
| |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
|
|
|
| |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
|
|
|
| |
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|
|
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
|