Hi Alfonso, >>> @@ -356,6 +356,9 @@ static void hci_conn_timeout(struct work_struct *work) >>> conn->state = BT_CLOSED; >>> break; >>> } >>> + >>> + if (test_and_clear_bit(HCI_CONN_PARAM_REMOVAL_PEND, &conn->flags)) >>> + hci_conn_params_del(conn->hdev, &conn->dst, conn->dst_type); >> >> do we really need this one? The hci_conn_timeout should trigger when the connection establishment has a timeout and that is really non of the concerns here. And in case we hit an idle disconnect timeout, we are still ending up in hci_conn_del eventually, right? If not, I am having the slight feeling that you might have uncovered a bug that we should fix. > > It's probably just lack of familiarity with the code, but it wasn't > all that clear to me that hci_conn_del is called after > hci_conn_timeout kicks in. I removed it. there is always a possibility that you found an actual bug that we trigger, but has not done any harm. At least not harm that anybody has noticed so far. So if this happens, then I like to fix the actual bug. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
