Hi Szymon,
On Sun, Jun 10, 2012, Szymon Janc wrote:
> +static void mgmt_add_uuid_resend(int sk, uint16_t index)
> +{
> + struct controller_info *info;
> + struct pending_uuid *pending;
> +
> + DBG("index %d", index);
> +
> + info = &controllers[index];
> +
> + pending = info->pending_uuids->data;
> +
> + send_uuid(index, &pending->uuid, pending->svc_hint);
> +}
> +
> static void mgmt_cmd_status(int sk, uint16_t index, void *buf, size_t len)
> {
> struct mgmt_ev_cmd_status *ev = buf;
> @@ -1460,6 +1479,10 @@ static void mgmt_cmd_status(int sk, uint16_t index, void *buf, size_t len)
> case MGMT_OP_READ_LOCAL_OOB_DATA:
> read_local_oob_data_failed(sk, index);
> break;
> + case MGMT_OP_ADD_UUID:
> + if (ev->status == MGMT_STATUS_BUSY)
> + mgmt_add_uuid_resend(sk, index);
> + break;
> }
> }
It's there a risk that this ends up in an infinite loop if the kernel is
in some state where it always keeps sending STATUS_BUSY? Would it make
sense to add a counter for retries and give up after 5 or 10 attempts?
Would it also make sense to add a small delay before resending the
command?
Johan
--
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
