bug: v/80811
Rootcause: In certain scenarios, users of `euv_pipe` must ensure all UV requests have completed execution before releasing resources. Consequently, it is necessary to notify users that `euv_pipe` has been fully released after its close operation is completed, thereby permitting subsequent operational procedures to proceed. Support for the close callback has therefore been added.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
Rootcause: `uv_close` does not guarantee the order in which close callbacks run.
There is a case where `euv_pipe_close2` and `euv_pipe_close` are called in sequence: if the `uv_close` initiated by `euv_pipe_close` completes first and frees the `euv_pipe_t` instance, `euv_pipe_close2` must access the invaliad address during its execution.
Therefore, add a status flag to ensure the `euv_pipe_t` instance is freed safely.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>
Signed-off-by: miot-robot <miot-robot@xiaomi.com>
Rootcause: When using SPP capability in cross-core scenario, it is necessary to perform cross-core communication through RPMSG. Since the Bluetooth service does not know which pipe connection method the application uses when establishing an SPP connection, it waits for the application to connect using both local and RPMSG pipes, and closes the unused pipe after connecting. When not in a cross-core scenario, the Bluetooth service does not use both pipes, which causes the subsequent closing behavior to result in runtime errors, causing the Bluetooth thread to be cleared by the system, thereby stopping the Bluetooth service.
Signed-off-by: chejinxian1 <chejinxian1@xiaomi.com>