Message ID | 20250422054547.132400-1-sanchayan@asymptotic.io |
---|---|
Headers | show |
Series | Fixes for re-connection issues with ASHA profile | expand |
Hi Sanchayan, On Tue, Apr 22, 2025 at 1:46 AM Sanchayan Maity <sanchayan@asymptotic.io> wrote: > > This fixes the issue of an ASHA device failing to re-connect after > getting disconnected since `asha->state` was not set to STOPPED on > a disconnect. > --- > profiles/audio/asha.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/profiles/audio/asha.c b/profiles/audio/asha.c > index 10115b92d..df283dd22 100644 > --- a/profiles/audio/asha.c > +++ b/profiles/audio/asha.c > @@ -478,20 +478,21 @@ static int asha_source_disconnect(struct btd_service *service) > DBG("Disconnecting ASHA on %s", addr); > > if (!asha_dev) { > /* Can this actually happen? */ > DBG("Not handlihng ASHA profile"); > return -1; > } > > asha_source_endpoint_unregister(asha_dev); > bt_asha_reset(asha_dev->asha); > + bt_asha_state_reset(asha_dev->asha); Any reason why the state reset is not handled inside bt_asha_reset? Also perhaps it would make it more clear if we use the term detach, since the general idea for src/shared is to handle the sessions not the driver logic like probe, so whenever there is a connection you attach function and on disconnect detach function. > btd_service_disconnecting_complete(service, 0); > > return 0; > } > > static struct btd_profile asha_source_profile = { > .name = "asha-source", > .priority = BTD_PROFILE_PRIORITY_MEDIUM, > .remote_uuid = ASHA_PROFILE_UUID, > -- > 2.49.0 > >