Hi,
On 9.4.2020 17.15, Aleksander Morgado wrote:
After investigating further, I suspect the problem could be in
mm_port_qmi_close(); it should probably wait for
qmi_device_release_client() completions before proceeding with closing
the device.
As long as the client release message is sent to the device, which
should happen as soon as qmi_device_release_client() is executed, it
shouldn't matter whether we go and close the device afterwards or not.
I'll try to repro this myself.
Possibly this could also be something in qmi-proxy side. I assume it is
expected that even after MM disconnects from it, it's supposed to
execute all queued QMI operations. Looking at the code, it seems that if
sending the response from device_command_ready() fails for the first of
the QMI Release CID operations (which sounds plausible, in case MM has
disconnected), untrack_client() gets called and it may close the QMI
device, blocking the execution of the remaining QMI commands.
I didn't actually debug it yet to find out if this is what really
happens, but maybe I can look at it tomorrow.
BR,
- Teijo
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
