About LIBQMI APIs

[Aleksander Morgado]

Hey,

On Fri, Mar 19, 2021 at 12:57 PM Sai Chaitanya <msaichaitanya at gmail.com> wrote:
>
> Thanks for the detailed reply. So I presume that qmi_device_open(), qmi_device_ready() and correspondingly qmi_device_close_async() are not required?

Looks like l missed the open step, sorry :). You do need the
qmi_device_open() between _new() and _allocate_client():

 * qmi_device_new()  --> this just defines how the underlying control
port is accessed, doesn't really do anything else
 * qmi_device_open()  --> this attempts to establish a new
communication channel with the underlying control port.
 * qmi_device_allocate_client (device, WDS)
  * qmi_client_wds_set_ip_family(client, ....)     --> optional if
ip-type not set in start network
  * qmi_client_wds_start_network(client, ...)    --> returns packet-data-handle

And once you want to stop the connection:
  * qmi_client_wds_stop_network(client, packet-data-handle)
  * qmi_device_release_client(device,client)

After the release client, you may or may not want to run
qmi_device_close(), depending on your needs. The close() will NOT
release your clients implicitly, it just stops the communication
channel with the underlying control port. If the program exits before
calling close() nothing bad should happen, as the channel is also
stopped in that case.

Regarding qmi_device_ready(), I think you're missing something. All
the _ready() methods would really be needed because you're running an
async application with async methods scheduled via a main loop. You
would need a ready() method for every async method you call for which
you want to know the response, as you'd be running the associated
finish() method inside the ready() to get the result of the operation.
You could run async methods with a NULL callback if you don't require
to know the result of the operation.

-- 
Aleksander
https://aleksander.es