<div dir="ltr"> On Jul 19, 2013 6:32 AM, "Tanu Kaskinen" <<a href="mailto:tanu.kaskinen@linux.intel.com" target="_blank">tanu.kaskinen@linux.intel.com</a>> wrote: > > On Thu, 2013-07-18 at 18:31 +0300, Tanu Kaskinen wrote: > > On Fri, 2013-07-12 at 15:06 -0300, <a href="mailto:jprvita@gmail.com" target="_blank">jprvita@gmail.com</a> wrote: > > > static void pa_bluetooth_device_free(pa_bluetooth_device *d) { > > > + unsigned i; > > > + > > > pa_assert(d); > > > > > > + for (i = 0; i < PA_BLUETOOTH_PROFILE_COUNT; i++) { > > > + pa_bluetooth_transport *t; > > > + > > > + if (!(t = d->transports[i])) > > > + continue; > > > + > > > + d->transports[i] = NULL; > > > + t->state = PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED; > > > + pa_hook_fire(&d->discovery->hooks[PA_BLUETOOTH_HOOK_TRANSPORT_STATE_CHANGED], t); > > > > Can the transport state be DISCONNECTED already before we set it here? > > If it can, please fire the hook only if the state actually changes. > > Also, I'd like a log message (debug level) whenever t->state changes. > There could be set_state() helper function that checks whether the new > state is different than the old state, and if it is, then sets t->state, > logs a message (including the old state, "state changed from <old> to > <new>") and fires the STATE_CHANGED hook. > > This is just a wish, so I won't continue arguing if you for some reason > don't think this is a good idea. > I like the idea of having a helper function to handle transport state changes, also because this would factor code used in other parts of bluez5-util.c. I'll look into that for the next series. -- João Paulo Rechi Vita <a href="http://about.me/jprvita" target="_blank">http://about.me/jprvita</a> </div>