* Re: SAP profile implementation
From: Pavan Savoy @ 2010-07-23 7:28 UTC (permalink / raw)
To: Suraj; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <4C493F90.10008@Atheros.com>
i saw a bluez-sap project recently on gitorious ..
On 7/23/10, Suraj <suraj@atheros.com> wrote:
> Hi,
>
> Is there anyone currently working on SAP profile?
> I know that Claudio Takahasi was working on the SAP Client implementation.
>
> Regards
> Suraj
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Virtual cable unplug not supported in BlueZ?
From: Luiz Augusto von Dentz @ 2010-07-23 7:25 UTC (permalink / raw)
To: Liang Bao; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikYDIOyiXLTst3R3K-TC81pMFfvtbPpmRwJqVan@mail.gmail.com>
Hi,
On Fri, Jul 23, 2010 at 5:03 AM, Liang Bao <tim.bao@gmail.com> wrote:
> Adapter.RemoveDevice() also removes the pair information according to
> the document doc/adapter-api.txt. However, unplug a virtual cable in
> HID spec doesn't mean unpair. Anyway, let me check the source once
> again. Thanks.
The question is, why do you want to use virtual cable unplug manually?
There doesn't seems to be any useful use case for that, there is no
"Virtual Cable Plug" either so if we do export virtual cable unplug
feature how we plug it again?
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* SAP profile implementation
From: Suraj @ 2010-07-23 7:06 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Hi,
Is there anyone currently working on SAP profile?
I know that Claudio Takahasi was working on the SAP Client implementation.
Regards
Suraj
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Defer SCO setup if mode change is pending
From: Marcel Holtmann @ 2010-07-23 2:48 UTC (permalink / raw)
To: Ron Shaffer; +Cc: linux-bluetooth
In-Reply-To: <1279827933-4180-1-git-send-email-rshaffer@codeaurora.org>
Hi Ron,
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 6c57fc7..9aee8c5 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -775,9 +775,6 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
>
> BT_DBG("%s status 0x%x", hdev->name, status);
>
> - if (!status)
> - return;
> -
> cp = hci_sent_cmd_data(hdev, HCI_OP_SNIFF_MODE);
> if (!cp)
> return;
> @@ -785,8 +782,15 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
> hci_dev_lock(hdev);
>
> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
> - if (conn)
> - clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> + if (conn) {
> + if (status) {
> + clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> +
> + if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
> + &conn->pend))
> + hci_sco_setup(conn, status);
> + }
> + }
>
> hci_dev_unlock(hdev);
> }
this change now makes it worse, please revert to initial
if (!status)
return;
check at the top and the just do
if (conn) {
clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND, &conn->pend))
hci_sco_setup(conn, status);
}
The only reason why I moved the status check down, because I was not
thinking straight and overlooked that in case of success we don't wanna
do a single thing here.
> @@ -798,9 +802,6 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
>
> BT_DBG("%s status 0x%x", hdev->name, status);
>
> - if (!status)
> - return;
> -
> cp = hci_sent_cmd_data(hdev, HCI_OP_EXIT_SNIFF_MODE);
> if (!cp)
> return;
> @@ -808,8 +809,15 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
> hci_dev_lock(hdev);
>
> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
> - if (conn)
> - clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> + if (conn) {
> + if (status) {
> + clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
> +
> + if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
> + &conn->pend))
> + hci_sco_setup(conn, status);
> + }
> + }
>
> hci_dev_unlock(hdev);
> }
Same applies here btw.
> @@ -915,20 +923,8 @@ static inline void hci_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *s
> } else
> conn->state = BT_CLOSED;
>
> - if (conn->type == ACL_LINK) {
> - struct hci_conn *sco = conn->link;
> - if (sco) {
> - if (!ev->status) {
> - if (lmp_esco_capable(hdev))
> - hci_setup_sync(sco, conn->handle);
> - else
> - hci_add_sco(sco, conn->handle);
> - } else {
> - hci_proto_connect_cfm(sco, ev->status);
> - hci_conn_del(sco);
> - }
> - }
> - }
> + if (conn->type == ACL_LINK)
> + hci_sco_setup(conn, ev->status);
>
> if (ev->status) {
> hci_proto_connect_cfm(conn, ev->status);
> @@ -1478,6 +1474,9 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
> conn->power_save = 1;
> else
> conn->power_save = 0;
> + } else if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
> + &conn->pend)) {
> + hci_sco_setup(conn, ev->status);
> }
> }
Please don't do else if here. Just add a separate check like I had in my
initial patch. We don't wanna depend on two flags pending flags set
here. If the SCO setup is pending, then we execute it. No matter how we
reached that point. It is important that even if we receive a mode
change without us triggering it, that we clear any potential SCO pending
flag.
Regards
Marcel
^ permalink raw reply
* Re: Virtual cable unplug not supported in BlueZ?
From: Liang Bao @ 2010-07-23 2:03 UTC (permalink / raw)
To: Liang Bao, linux-bluetooth
In-Reply-To: <20100720093732.GA3210@jh-x301>
Adapter.RemoveDevice() also removes the pair information according to
the document doc/adapter-api.txt. However, unplug a virtual cable in
HID spec doesn't mean unpair. Anyway, let me check the source once
again. Thanks.
2010/7/20 Johan Hedberg <johan.hedberg@gmail.com>:
> Hi,
>
> On Tue, Jul 20, 2010, Liang Bao wrote:
>> I have a question on "Virtual Cable Unplug" in current BlueZ version.
>>
>> Currently BlueZ doesn't expose a D-Bus method in input/device.c for
>> virtually unplug cable which is a mandatory requirement to pass
>> TC_HOS_HCR_BV_03_I. Actually the support in kernel is already there.
>> Can anyone give some insight to why this is not exposed at the DBUS
>> API level like Connect/Disconnect/GetProperties? Can I think the
>> reason behind this design is we only need one of "Disconnect" and
>> "VirtualUnplug" to allow user to disconnect?
>
> AFAIK the unplug should be sent when you do Adapter.RemoveDevice()
>
> Johan
>
^ permalink raw reply
* Re: [PATCH 19/60] Process response to std. op. codes
From: Gustavo F. Padovan @ 2010-07-23 0:09 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1279789001-4587-1-git-send-email-santoscadenas@gmail.com>
Hi Jose,
* Jose Antonio Santos Cadenas <santoscadenas@gmail.com> [2010-07-22 10:56:12 +0200]:
> From: José Antonio Santos-Cadenas <santoscadenas@gmail.com>
>
> ---
> mcap/mcap.c | 141 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 140 insertions(+), 1 deletions(-)
>
> diff --git a/mcap/mcap.c b/mcap/mcap.c
> index 6f6e08a..c775501 100644
> --- a/mcap/mcap.c
> +++ b/mcap/mcap.c
> @@ -1170,9 +1170,112 @@ static void proc_req_active(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
> }
> }
>
> +static gboolean process_md_create_mdl_rsp(struct mcap_mcl *mcl,
> + uint8_t *cmd, uint32_t len)
> +{
> + return FALSE;
> +}
> +
> +static gboolean process_md_reconnect_mdl_rsp(struct mcap_mcl *mcl,
> + uint8_t *cmd, uint32_t len)
> +{
> + return FALSE;
> +}
> +
> +static gboolean process_md_abort_mdl_rsp(struct mcap_mcl *mcl,
> + uint8_t *cmd, uint32_t len)
> +{
> + return FALSE;
> +}
> +
> +static gboolean process_md_delete_mdl_rsp(struct mcap_mcl *mcl, uint8_t *cmd,
> + uint32_t len)
> +{
> + return FALSE;
> +}
> +
> +static gboolean check_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
> +{
> + mcap4B_rsp *rsp;
> + GError *gerr = NULL;
> +
> + /* Check if the response matches with the last request */
> + if ((cmd[0] != MCAP_ERROR_RSP) && ((mcl->lcmd[0] + 1) != cmd[0]))
> + goto close_mcl;
> +
> + if (len < 4)
> + goto close_mcl;
> +
> + rsp = (mcap4B_rsp *)cmd;
> +
> + if (rsp->rc == MCAP_REQUEST_NOT_SUPPORTED) {
> + DBG("Remote does not support opcodes");
> + g_set_error(&gerr, MCAP_ERROR, MCAP_ERROR_REQUEST_NOT_SUPPORTED,
> + "%s", error2str(rsp->rc));
> + mcap_notify_error(mcl, gerr);
> + g_error_free(gerr);
> +
> + g_free(mcl->lcmd);
> + mcl->lcmd = NULL;
> + mcl->ctrl &= ~MCAP_CTRL_STD_OP;
> + mcl->req = MCL_AVAILABLE;
> + update_mcl_state(mcl);
> + return FALSE;
> + }
> +
> + if (rsp->rc == MCAP_UNSPECIFIED_ERROR)
> + goto close_mcl;
> +
> + return TRUE;
> +close_mcl:
Always put a blank line before labels.
> + if (rsp->rc == MCAP_UNSPECIFIED_ERROR)
> + g_set_error(&gerr, MCAP_ERROR, MCAP_ERROR_UNSPECIFIED_ERROR,
> + "%s", error2str(rsp->rc));
> + else
> + g_set_error(&gerr, MCAP_ERROR, MCAP_ERROR_FAILED,
> + "Protocol error");
> + mcap_notify_error(mcl, gerr);
> + g_error_free(gerr);
> + mcl->ms->mcl_disconnected_cb(mcl, mcl->ms->user_data);
> + mcap_cache_mcl(mcl);
> + return FALSE;
> +}
> +
> static void proc_response(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
> {
> - /* TODO */
> + gboolean close;
> + RELEASE_TIMER(mcl);
> +
> + if (!check_rsp(mcl, cmd, len))
> + return;
> +
> + switch (cmd[0]) {
> + case MCAP_ERROR_RSP:
> + error("MCAP_ERROR_RSP received");
> + close = TRUE;
> + break;
> + case MCAP_MD_CREATE_MDL_RSP:
> + close = process_md_create_mdl_rsp(mcl, cmd, len);
> + break;
> + case MCAP_MD_RECONNECT_MDL_RSP:
> + close = process_md_reconnect_mdl_rsp(mcl, cmd, len);
> + break;
> + case MCAP_MD_ABORT_MDL_RSP:
> + close = process_md_abort_mdl_rsp(mcl, cmd, len);
> + break;
> + case MCAP_MD_DELETE_MDL_RSP:
> + close = process_md_delete_mdl_rsp(mcl, cmd, len);
> + break;
> + default:
> + DBG("Unknown cmd response received (op code = %d)",cmd[0]);
> + close = TRUE;
> + break;
> + }
> +
> + if (close) {
> + mcl->ms->mcl_disconnected_cb(mcl, mcl->ms->user_data);
> + mcap_cache_mcl(mcl);
> + }
> }
>
> static void rsend_req(struct mcap_mcl *mcl)
> @@ -1631,3 +1734,39 @@ void mcap_release_instance(struct mcap_instance *ms)
>
> g_free(ms);
> }
> +
> +uint16_t mcap_get_ctrl_psm(struct mcap_instance *ms, GError **err)
> +{
> + uint16_t lpsm;
> +
> + if (!(ms && ms->ccio)) {
> + g_set_error(err, MCAP_ERROR, MCAP_ERROR_INVALID_ARGS,
> + "Invalid MCAP instance");
> + return 0;
> + }
> +
> + bt_io_get(ms->ccio, BT_IO_L2CAP, err,
> + BT_IO_OPT_PSM, &lpsm,
> + BT_IO_OPT_INVALID);
> + if (*err)
> + return 0;
> + return lpsm;
> +}
> +
> +uint16_t mcap_get_data_psm(struct mcap_instance *ms, GError **err)
> +{
> + uint16_t lpsm;
> +
> + if (!(ms && ms->dcio)) {
> + g_set_error(err, MCAP_ERROR, MCAP_ERROR_INVALID_ARGS,
> + "Invalid MCAP instance");
> + return 0;
> + }
> +
> + bt_io_get(ms->dcio, BT_IO_L2CAP, err,
> + BT_IO_OPT_PSM, &lpsm,
> + BT_IO_OPT_INVALID);
> + if (*err)
> + return 0;
> + return lpsm;
> +}
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 18/60] Implement function to send md_abort_mdl_req
From: Gustavo F. Padovan @ 2010-07-23 0:07 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1279788733-2324-19-git-send-email-sancane@gmail.com>
Hi Santiago,
* Santiago Carot-Nemesio <sancane@gmail.com> [2010-07-22 10:52:13 +0200]:
> ---
> mcap/mcap.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/mcap/mcap.c b/mcap/mcap.c
> index 5419d54..6f6e08a 100644
> --- a/mcap/mcap.c
> +++ b/mcap/mcap.c
> @@ -519,6 +519,38 @@ void mcap_req_mdl_deletion(struct mcap_mdl *mdl, GError **err,
> g_free(con);
> }
>
> +void mcap_mdl_abort(struct mcap_mdl *mdl, GError **err,
> + mcap_mdl_del_cb abort_cb, gpointer user_data)
> +{
> + struct mcap_mdl_op_cb *con;
> + struct mcap_mcl *mcl = mdl->mcl;
> + uint8_t *cmd;
> +
> + if (mdl->state != MDL_WAITING) {
> + g_set_error(err, MCAP_ERROR, MCAP_ERROR_FAILED,
> + "Mdl in invalid state");
> + return;
> + }
> +
> + con = g_new0(struct mcap_mdl_op_cb, 1);
> + cmd = create_req(MCAP_MD_ABORT_MDL_REQ, mdl->mdlid);
> + mcap_send_std_opcode(mcl, cmd, sizeof(mcap_md_req), err);
> + if (*err) {
> + g_free(con);
> + g_free(cmd);
> + return;
> + }
> +
> + con->mdl = mdl;
> + con->cb.del = abort_cb;
> + con->user_data = user_data;
> +
> + mcl->priv_data = con;
> +
> + mcl->tid = g_timeout_add_seconds(RESPONSE_TIMER, wait_response_timer,
> + mcl);
> +}
> +
> static void update_mcl_state(struct mcap_mcl *mcl)
> {
> GSList *l;
> @@ -554,6 +586,22 @@ static struct mcap_mcl *find_mcl(GSList *list, const bdaddr_t *addr)
> return NULL;
> }
>
> +int mcap_mdl_get_fd(struct mcap_mdl *mdl)
> +{
> + if ((!mdl) || (mdl->state != MDL_CONNECTED))
> + return -1;
A proper Unix error is better than -1 here.
> +
> + return g_io_channel_unix_get_fd(mdl->dc);
> +}
> +
> +uint16_t mcap_mdl_get_mdlid(struct mcap_mdl *mdl)
> +{
> + if (!mdl)
> + return MCAP_MDLID_RESERVED;
> +
> + return mdl->mdlid;
> +}
> +
> static void shutdown_mdl(struct mcap_mdl *mdl)
> {
> mdl->state = MDL_CLOSED;
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 12/60] Managing connection of Data Channels
From: Gustavo F. Padovan @ 2010-07-22 23:54 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1279788733-2324-13-git-send-email-sancane@gmail.com>
Hi Santiago,
* Santiago Carot-Nemesio <sancane@gmail.com> [2010-07-22 10:52:07 +0200]:
> ---
> mcap/mcap.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 70 insertions(+), 1 deletions(-)
>
> diff --git a/mcap/mcap.c b/mcap/mcap.c
> index cf44472..1d86c51 100644
> --- a/mcap/mcap.c
> +++ b/mcap/mcap.c
> @@ -754,6 +754,27 @@ static void proc_cmd(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
> proc_req[mcl->state](mcl, cmd, len);
> }
>
> +static gboolean mdl_event_cb(GIOChannel *chan, GIOCondition cond, gpointer data)
> +{
> +
> + struct mcap_mdl *mdl = data;
> + gboolean notify;
> +
> + DBG("Close MDL %d", mdl->mdlid);
> +
> + notify = (mdl->state == MDL_CONNECTED);
You actually don't need 'notify', just put the comparison in the if
below.
> + shutdown_mdl(mdl);
> +
> + update_mcl_state(mdl->mcl);
> +
> + if (notify) {
> + /*Callback to upper layer */
> + mdl->mcl->cb->mdl_closed(mdl, mdl->mcl->cb->user_data);
> + }
> +
> + return FALSE;
> +}
> +
> static gboolean mcl_control_cb(GIOChannel *chan, GIOCondition cond,
> gpointer data)
> {
> @@ -779,9 +800,57 @@ fail:
> return FALSE;
> }
>
> +static void connect_dc_event_cb(GIOChannel *chan, GError *err,
> + gpointer user_data)
> +{
> + struct mcap_mdl *mdl = user_data;
> + struct mcap_mcl *mcl = mdl->mcl;
> +
> + mdl->state = MDL_CONNECTED;
> + mdl->dc = g_io_channel_ref(chan);
> + mdl->wid = g_io_add_watch(mdl->dc, G_IO_ERR | G_IO_HUP | G_IO_NVAL,
> + (GIOFunc) mdl_event_cb, mdl);
> +
> + mcl->state = MCL_ACTIVE;
> + mcl->cb->mdl_connected(mdl, mcl->cb->user_data);
> +}
> +
> static void confirm_dc_event_cb(GIOChannel *chan, gpointer user_data)
> {
> - /* TODO */
> + struct mcap_instance *ms = user_data;
> + struct mcap_mcl *mcl;
> + struct mcap_mdl *mdl;
> + GError *err = NULL;
> + bdaddr_t dst;
> + GSList *l;
> +
> + bt_io_get(chan, BT_IO_L2CAP, &err,
> + BT_IO_OPT_DEST_BDADDR, &dst,
> + BT_IO_OPT_INVALID);
> + if (err) {
> + error("%s", err->message);
> + g_error_free(err);
> + goto drop;
> + }
> +
> + mcl = find_mcl(ms->mcls, &dst);
> + if (!mcl || (mcl->state != MCL_PENDING))
No need for () in the '!=' comparison.
> + goto drop;
> +
> + for (l = mcl->mdls; l; l = l->next) {
> + mdl = l->data;
> + if (mdl->state == MDL_WAITING) {
> + if (!bt_io_accept(chan, connect_dc_event_cb, mdl, NULL,
> + &err)) {
> + error("MDL accept error %s", err->message);
> + g_error_free(err);
> + goto drop;
> + }
> + return;
> + }
> + }
> +drop:
> + g_io_channel_shutdown(chan, TRUE, NULL);
> }
>
> static void connect_mcl_event_cb(GIOChannel *chan, GError *err,
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 10/60] Process md_abort_mdl_req in PENDING state
From: Gustavo F. Padovan @ 2010-07-22 23:50 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1279788733-2324-11-git-send-email-sancane@gmail.com>
Hi Santiago,
* Santiago Carot-Nemesio <sancane@gmail.com> [2010-07-22 10:52:05 +0200]:
> ---
> mcap/mcap.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 49 insertions(+), 1 deletions(-)
>
> diff --git a/mcap/mcap.c b/mcap/mcap.c
> index d6a9760..9f41c6b 100644
> --- a/mcap/mcap.c
> +++ b/mcap/mcap.c
> @@ -551,6 +551,51 @@ static void process_md_reconnect_mdl_req(struct mcap_mcl *mcl, uint8_t *cmd,
> send4B_cmd(mcl, MCAP_MD_RECONNECT_MDL_RSP, MCAP_SUCCESS, mdl_id);
> }
>
> +static void process_md_abort_mdl_req(struct mcap_mcl *mcl, uint8_t *cmd,
> + uint32_t len)
> +{
> + mcap_md_req *req;
> + GSList *l;
> + struct mcap_mdl *mdl, *del;
> + uint16_t mdl_id;
> +
> + if (len != sizeof(mcap_md_req)) {
> + send4B_cmd(mcl, MCAP_MD_ABORT_MDL_RSP,
> + MCAP_INVALID_PARAM_VALUE, MCAP_MDLID_RESERVED);
I remenber about a Johan's comment on send4B_cmd(). It was basically,
wouldn't be better have function to send data of a arbritrary size. I
think I saw a send5B_cmd() in these patches as well.
> + return;
> + }
> +
> + req = (mcap_md_req *)cmd;
> + mdl_id = ntohs(req->mdl);
> + mcl->state = MCL_CONNECTED;
> + for (l = mcl->mdls; l; l = l->next) {
> + mdl = l->data;
> + if ((mdl_id == mdl->mdlid) && (mdl->state == MDL_WAITING)) {
> + del = mdl;
> + if (mcl->state != MCL_CONNECTED)
> + break;
> + continue;
> + }
> + if ((mdl->state == MDL_CONNECTED) && (mcl->state != MCL_ACTIVE))
> + mcl->state = MCL_ACTIVE;
> +
> + if ((del) && (mcl->state == MCL_ACTIVE))
> + break;
> + }
> +
> + if (!del) {
> + send4B_cmd(mcl, MCAP_MD_ABORT_MDL_RSP, MCAP_INVALID_MDL,
> + mdl_id);
> + return;
> + }
> +
> + mcl->cb->mdl_aborted(del, mcl->cb->user_data);
> +
> + mcl->mdls = g_slist_remove(mcl->mdls, del);
> + g_free(del);
> + send4B_cmd(mcl, MCAP_MD_ABORT_MDL_RSP, MCAP_SUCCESS, mdl_id);
> +}
> +
> static void process_md_delete_mdl_req(struct mcap_mcl *mcl, uint8_t *cmd,
> uint32_t len)
> {
> @@ -626,7 +671,10 @@ static void proc_req_connected(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
>
> static void proc_req_pending(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
> {
> - /* TODO */
> + if (cmd[0] == MCAP_MD_ABORT_MDL_REQ)
> + process_md_abort_mdl_req(mcl, cmd, len);
> + else
> + error_cmd_rsp(mcl, cmd, len);
> }
>
> static void proc_req_active(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 16/60] Implement function to send md_reconnect_mdl_req
From: Gustavo F. Padovan @ 2010-07-22 23:47 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1279788733-2324-17-git-send-email-sancane@gmail.com>
* Santiago Carot-Nemesio <sancane@gmail.com> [2010-07-22 10:52:11 +0200]:
> ---
> mcap/mcap.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 51 insertions(+), 0 deletions(-)
>
> diff --git a/mcap/mcap.c b/mcap/mcap.c
> index dc55cda..a0f00af 100644
> --- a/mcap/mcap.c
> +++ b/mcap/mcap.c
> @@ -261,6 +261,20 @@ static uint16_t generate_mdlid(struct mcap_mcl *mcl)
> return mdlid;
> }
>
> +static uint8_t *create_req(uint8_t op, uint16_t mdl_id)
> +{
> + uint8_t *req;
> + mcap_md_req *req_cmd;
> +
> + req = g_malloc0(sizeof(mcap_md_req));
> +
> + req_cmd = (mcap_md_req *)req;
> + req_cmd->op = op;
> + req_cmd->mdl = htons(mdl_id);
> +
> + return req;
> +}
Why are you casting here? I would expect mcap_md_req * as return type
here. If the problem is with mcap_send_std_opcode() you can used "void *" as
parameter type there.
> +
> static uint8_t *create_mdl_req(uint16_t mdl_id, uint8_t mdep, uint8_t conf)
> {
> uint8_t *req;
> @@ -356,6 +370,43 @@ void mcap_req_mdl_creation(struct mcap_mcl *mcl,
> mcl);
> }
>
> +void mcap_req_mdl_reconnect(struct mcap_mdl *mdl,
> + GError **err,
> + mcap_mdl_operation_cb reconnect_cb,
> + gpointer user_data)
> +{
> + struct mcap_mdl_op_cb *con;
> + struct mcap_mcl *mcl = mdl->mcl;
> + uint8_t *cmd;
> +
> + if (mdl->state != MDL_CLOSED) {
> + g_set_error(err, MCAP_ERROR, MCAP_ERROR_FAILED,
> + "MDL is not closed");
> + return;
> + }
> + con = g_new0(struct mcap_mdl_op_cb, 1);
> +
> + cmd = create_req(MCAP_MD_RECONNECT_MDL_REQ, mdl->mdlid);
> + mcap_send_std_opcode(mcl, cmd, sizeof(mcap_md_req), err);
> + if (*err) {
> + g_free(con);
> + g_free(cmd);
> + return;
> + }
> +
> + mdl->state = MDL_WAITING;
> +
> + con->mdl = mdl;
> + con->cb.op = reconnect_cb;
> + con->user_data = user_data;
> +
> + mcl->state = MCL_ACTIVE;
> + mcl->priv_data = con;
> +
> + mcl->tid = g_timeout_add_seconds(RESPONSE_TIMER, wait_response_timer,
> + mcl);
> +}
> +
> static void update_mcl_state(struct mcap_mcl *mcl)
> {
> GSList *l;
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: Any update on software caused connection abort issue??
From: Lukas Hetzenecker @ 2010-07-22 23:44 UTC (permalink / raw)
To: john michelle; +Cc: linux-bluetooth
In-Reply-To: <AANLkTinRSokfhf68OMIsFH9ccMd18Z7pq705KGWnKt8S@mail.gmail.com>
I also noticed these kernel messages during the disconnect in my
/var/log/messages log
Jul 22 23:52:35 erde kernel: btusb_intr_complete: hci0 urb ffff88010d409540
failed to resubmit (1)
Jul 22 23:52:35 erde kernel: btusb_bulk_complete: hci0 urb ffff88010d409900
failed to resubmit (1)
Jul 22 23:52:35 erde kernel: btusb_bulk_complete: hci0 urb ffff88010d409b40
failed to resubmit (1)
[these messages are repeated for several times, even before the disconnect]
Jul 22 23:52:36 erde kernel: usb 5-1: reset full speed USB device using
uhci_hcd and address 2
Jul 22 23:52:36 erde kernel: btusb 5-1:1.0: no reset_resume for driver btusb?
Jul 22 23:52:36 erde bluetoothd[1580]: HCI dev 0 down
Jul 22 23:52:36 erde bluetoothd[1580]: Adapter /org/bluez/1574/hci0 has been
disabled
Jul 22 23:52:36 erde bluetoothd[1580]: Stopping security manager 0
Jul 22 23:52:36 erde kernel: btusb 5-1:1.1: no reset_resume for driver btusb?
Jul 22 23:52:37 erde bluetoothd[1580]: HCI dev 0 unregistered
Jul 22 23:52:37 erde bluetoothd[1580]: Unregister path: /org/bluez/1574/hci0
Jul 22 23:52:37 erde NetworkManager[1520]: <info> BT device 00:1B:AF:84:FF:E2
removed
Jul 22 23:52:37 erde bluetoothd[1580]: HCI dev 0 registered
Jul 22 23:52:37 erde bluetoothd[1580]: HCI dev 0 up
Jul 22 23:52:37 erde bluetoothd[1580]: Starting security manager 0
Jul 22 23:52:37 erde bluetoothd[1580]: Parsing /etc/bluetooth/serial.conf
failed: No such file or directory
Jul 22 23:52:37 erde bluetoothd[1580]: probe failed with driver input-headset
for device /org/bluez/1574/hci0/dev_00_1B_AF_84_FF_E2
Jul 22 23:52:37 erde bluetoothd[1580]: Adapter /org/bluez/1574/hci0 has been
enabled
It is also strange that this error affects only my PC with an USB bluetooth
stick, not my notebook with an integrated Intel PRO Wireless
4965AGN bluetooth module.
Do you need any more informations for debugging?
On Thursday 22 July 2010 16:17:57 john michelle wrote:
> Hi Lukas,
>
> > It would be great to see this problem fixed soon, because it's nearly
> > impossible to use bluetooth on my PC.
>
> I think it's useless to get any reply from this mailing list, i have
> been reporting this
> Problem for a long time and no one simply cares.
>
> John
>
> On Wed, Jul 21, 2010 at 5:53 PM, Lukas <LuHe@gmx.at> wrote:
> > Hello,
> >
> > On Wednesday 21 July 2010 17:35:15 john michelle wrote:
> >> Any update on software caused connection abort issue
> >
> > I also noticed this error when I used the software suite Series60-Remote
> > to connect to my mobile phone.
> >
> > Shortly after the connection establishment is completed I get the error
> > message "software caused connection abort" and the device gets
> > disconnected.
> >
> > I also see the HCI reset, as described below, when I try to investigate
> > this error using hcidump.
> >
> > The software uses the RFCOMM protocol for the connection.
> > I use an USB bluetooth adapter from Belkin, lsusb reports the following
> > device id:
> > ID 050d:0131 Belkin Components Bluetooth Device with trace filter
> >
> > This bug happens with the following kernel:
> > root@erde ~ # rpm -q kernel bluez
> > kernel-2.6.33.6-147.fc13.x86_64
> > bluez-4.64-1.fc13.x86_64
> >
> > You can also look at this thread in my mailing list for further
> > informations:
> > https://sourceforge.net/mailarchive/forum.php?thread_name=201007192136.2
> > 7723.LuHe%40gmx.at&forum_name=series60- remote-devel
> >
> > It would be great to see this problem fixed soon, because it's nearly
> > impossible to use bluetooth on my PC.
> >
> > Thanks,
> > Lukas
> >
> >> >>On Wed, Jun 23, 2010 at 12:48 AM, john michelle
> >> >><jhnmichelle@gmail.com>
> >
> > wrote:
> >> >> Dear Bluetooth community,
> >> >>
> >> >> You are committing version after version and have time to add new
> >> >> Features and the core stack have a major bug (software Caused
> >> >> connection abort) that i
> >> >> Have reported on the 7th of may the problem seems to be either in the
> >> >> usb part of the
> >> >> Kernel or the bluez stack, i am no kernel engineer so i came directly
> >> >> to you for reporting
> >> >> This problem and my requests to look into this problem are just
> >> >> ignored. this is a blocker
> >> >> Issue that would prevent and discourage any one from developing
> >> >> application that rely on
> >> >> Bluez sco capabilities, since during transmission the above mentioned
> >> >> error just occurs.
> >> >> I hope that my voice is heared and i would get a reply from the bluez
> >> >> community.
> >> >>
> >> >> John
> >> >>
> >> >> On Wed, Jun 16, 2010 at 3:11 PM, john michelle
> >> >> <jhnmichelle@gmail.com>
> >
> > wrote:
> >> >>> On Sun, May 30, 2010 at 1:12 PM, john michelle
> >> >>> <jhnmichelle@gmail.com>
> >
> > wrote:
> >> >>>> Hi Gustavo,
> >> >>>>
> >> >>>>>> Please post the output of hcidump when the connection abort
> >> >>>>>> happens.
> >> >>>>
> >> >>>> Below is the output of hcidump the moments the software caused
> >> >>>> connection abort
> >> >>>>
> >> >>>> Dongle 1:
> >> >>>>> HCI Event: Number of Completed Packets (0x13) plen 5
> >> >>>>
> >> >>>> . * . . .
> >> >>>> < HCI Command: Reset (0x03|0x0003) plen 0
> >> >>>> device: disconnected
> >> >>>>
> >> >>>> Dongle 2:
> >> >>>>> HCI Event: Number of Completed Packets (0x13) plen 5
> >> >>>>
> >> >>>> . * . . .
> >> >>>> < HCI Command: Reset (0x03|0x0003) plen 0
> >> >>>> device: disconnected
> >> >>>>
> >> >>>>
> >> >>>> I think something triggers hci reset which causes this problem, but
> >> >>>> what exactly Triggers it i don't know.
> >> >>>>
> >> >>>>
> >> >>>> John
> >> >>>
> >> >>> Hi all,
> >> >>>
> >> >>> Is anyone going to give this problem a try, it has been like a month
> >> >>> now This is a real problem in the bluez stack and someone have to
> >> >>> look in this Issue.
> >> >>>
> >> >>> John
> >> >>>
> >> >>>> On Mon, May 17, 2010 at 5:21 PM, john michelle
> >> >>>> <jhnmichelle@gmail.com>
> >
> > wrote:
> >> >>>>>> Hi Jonh,
> >> >>>>>>
> >> >>>>>> First of all, don't do top posting in this mailing list. ;)
> >> >>>>>
> >> >>>>> Thanks for the advise , will keep that in mind for future posts.
> >> >>>>>
> >> >>>>>> In which bluez/kernel version the problem started? Any hardware
> >> >>>>>> update during this time? The problem happens when you are already
> >> >>>>>> tranfering SCO data?
> >> >>>>>
> >> >>>>> I tried bluez versions 3.XX and kernel 2.6.26(I think) the
> >> >>>>> problem occurs and the kernel panics with no core dumps.then i
> >> >>>>> tried with bluez 4.53-4.62 with
> >> >>>>> Kernel 2.6.31 and 2.6.32. the connection abort problem occurs but
> >> >>>>> the kernel doesn't
> >> >>>>> Panic. regarding the hardware update you mean the dongle or the
> >> >>>>> box.Anyway i changed both and tried different box's, this even
> >> >>>>> happens on a box with 2 giga ram
> >> >>>>> And core2 processor . as for the dongles i am using trust
> >> >>>>>
> >> >>>>> http://www.twenga.co.uk/prices-Bluetooth-2-USB-Adapter-10m-BT-2250
> >> >>>>> p-T RUST-Wireless-network-card-adapter-176178-0
> >> >>>>>
> >> >>>>> and also using no name dongles all the same problem.
> >> >>>>>
> >> >>>>>> Please post the output of hcidump when the connection abort
> >> >>>>>> happens.
> >> >>>>>
> >> >>>>> well that is going to be a hard one since i have more than one
> >> >>>>> dongle in place And very hard to predict which one will crash.i
> >> >>>>> will work on this and update You as soon as i have the hcidump
> >> >>>>> log.
> >> >>>>>
> >> >>>>>> I tried reproduce this issue in L2CAP but it is a bit hard, lets
> >> >>>>>> say it happen once in a thousand, so it's not easy to track it. I
> >> >>>>>> have to try reproduce that using the SCO, but I'm not used to
> >> >>>>>> that layer yet. ;)
> >> >>>>>
> >> >>>>> I hoped that it happens 1 in 1000 in SCO , but it actually happens
> >> >>>>> 1 in 15
> >> >>>>>
> >> >>>>>
> >> >>>>> John
> >> >>>>>
> >> >>>>>> Regards,
> >> >>>>>>
> >> >>>>>>> John
> >> >>>>>>>
> >> >>>>>>> On Fri, May 7, 2010 at 3:53 PM, Gustavo F. Padovan
> >
> > <gustavo@padovan.org> wrote:
> >> >>>>>>> > * john michelle <jhnmichelle@gmail.com> [2010-05-07 15:49:05
> >
> > -0400]:
> >> >>>>>>> >> Hi Bluetooth hackers,
> >> >>>>>>> >>
> >> >>>>>>> >> i am having this consistent problem with bluez , from time to
> >> >>>>>>> >> time i get the error Software caused connection abort (103 )
> >> >>>>>>> >> And the bluetooth stick seems to disconnect and reconnects.
> >> >>>>>>> >> this happens during an sco connection and it occurs even
> >> >>>>>>> >> More when i am having the voice stream comming through the
> >> >>>>>>> >> internet rather than the lan.i don't know what exact
> >> >>>>>>> >> Details you need to solve this problem please tell me and i
> >> >>>>>>> >> will give you an immediate reply . i have linux kernel
> >> >>>>>>> >> 2.6.33 and bluez 4.62
> >> >>>>>>> >
> >> >>>>>>> > I get the same problem sometimes when testing ERTM with
> >> >>>>>>> > l2test. So the problem is on l2cap too. I didn't have time to
> >> >>>>>>> > debug this yet. Now that someone else have confirmed it too,
> >> >>>>>>> > I'll to take a look at the problem.
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> Gustavo F. Padovan
> >> >>>>>> http://padovan.org
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-bluetooth" in the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 29/60] Fix missed state transition in MCAP
From: Gustavo F. Padovan @ 2010-07-22 23:40 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <20100722233722.GC2620@vigoh>
Hi Jose,
* Gustavo F. Padovan <gustavo@padovan.org> [2010-07-22 20:37:22 -0300]:
> Hi Jose,
>
> * Jose Antonio Santos Cadenas <santoscadenas@gmail.com> [2010-07-22 10:56:22 +0200]:
>
> > From: José Antonio Santos-Cadenas <santoscadenas@gmail.com>
> >
> > MCL should transite to properly state when a create_mdl_req is
> > not SUCCESS
> > ---
> > mcap/mcap.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/mcap/mcap.c b/mcap/mcap.c
> > index cf92368..1dfe083 100644
> > --- a/mcap/mcap.c
> > +++ b/mcap/mcap.c
> > @@ -1260,6 +1260,7 @@ fail:
> > mcl->mdls = g_slist_remove(mcl->mdls, mdl);
> > g_free(mdl);
> > g_error_free(gerr);
> > + update_mcl_state(mcl);
> > return close;
> > }
>
> The same should apply here. Can you merge this with the original commit
> that implemented create_mdl_req(), can't you?
There should be another patches here in the same situation, I'm not
checking all of them for this. Please check them and fix into the
original commits when possible. That can make the review easier. ;)
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 29/60] Fix missed state transition in MCAP
From: Gustavo F. Padovan @ 2010-07-22 23:37 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1279789001-4587-11-git-send-email-santoscadenas@gmail.com>
Hi Jose,
* Jose Antonio Santos Cadenas <santoscadenas@gmail.com> [2010-07-22 10:56:22 +0200]:
> From: José Antonio Santos-Cadenas <santoscadenas@gmail.com>
>
> MCL should transite to properly state when a create_mdl_req is
> not SUCCESS
> ---
> mcap/mcap.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/mcap/mcap.c b/mcap/mcap.c
> index cf92368..1dfe083 100644
> --- a/mcap/mcap.c
> +++ b/mcap/mcap.c
> @@ -1260,6 +1260,7 @@ fail:
> mcl->mdls = g_slist_remove(mcl->mdls, mdl);
> g_free(mdl);
> g_error_free(gerr);
> + update_mcl_state(mcl);
> return close;
> }
The same should apply here. Can you merge this with the original commit
that implemented create_mdl_req(), can't you?
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: MCAP Patches
From: Gustavo F. Padovan @ 2010-07-22 23:36 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1279788733-2324-1-git-send-email-sancane@gmail.com>
Hi Santiago,
* Santiago Carot-Nemesio <sancane@gmail.com> [2010-07-22 10:51:55 +0200]:
> Hello,
>
> Next you are MCAP patches that José Antonio Santos Cadenas and me have generated for BlueZ.
> We still believe that MCAP should be an independent library from HDP because other profiles
> non health related may want to use it in the future, if we set this health dependency we will
> force to import health features in plugins that only require MCAP.
> Nevertheless, as we accorded last week in Brazil we are sending a last patch to set MCAP
> into health directory with HDP. We leave in your hands upload it as health plugin or not.
Please provide a git tree link for theses patches too. Thanks.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH 27/60] Fix wrong response code rejecting reconnections
From: Gustavo F. Padovan @ 2010-07-22 23:31 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1279789001-4587-9-git-send-email-santoscadenas@gmail.com>
Hi Jose,
* Jose Antonio Santos Cadenas <santoscadenas@gmail.com> [2010-07-22 10:56:20 +0200]:
> From: José Antonio Santos-Cadenas <santoscadenas@gmail.com>
>
> ---
> mcap/mcap.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mcap/mcap.c b/mcap/mcap.c
> index 43b215b..7098a8d 100644
> --- a/mcap/mcap.c
> +++ b/mcap/mcap.c
> @@ -1024,7 +1024,7 @@ static void process_md_reconnect_mdl_req(struct mcap_mcl *mcl, uint8_t *cmd,
> return;
>
> if (rsp != MCAP_SUCCESS) {
> - send4B_cmd(mcl, MCAP_MD_CREATE_MDL_RSP, rsp, mdl_id);
> + send4B_cmd(mcl, MCAP_MD_RECONNECT_MDL_RSP, rsp, mdl_id);
> return;
> }
As we do not merged any patches for MCAP this fix could be amended with
the patch the implements process_md_reconnect_mdl_req().
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* [PATCH v2] Bluetooth: Defer SCO setup if mode change is pending
From: Ron Shaffer @ 2010-07-22 19:45 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Ron Shaffer
In-Reply-To: <1279644961.4572.60.camel@localhost.localdomain>
From: Marcel Holtmann <marcel@holtmann.org>
Certain headsets such as the Motorola H350 will reject SCO and eSCO
connection requests while the ACL is transitioning from sniff mode
to active mode. Add synchronization so that SCO and eSCO connection
requests will wait until the ACL has fully transitioned to active mode.
< HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
handle 12
> HCI Event: Command Status (0x0f) plen 4
Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
handle 12 voice setting 0x0040
> HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 1
> HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 12 mode 0x00 interval 0
Mode: Active
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO
Error: Connection Accept Timeout Exceeded
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org>
---
include/net/bluetooth/hci_core.h | 2 +
net/bluetooth/hci_conn.c | 32 ++++++++++++++++++++++---
net/bluetooth/hci_event.c | 47 ++++++++++++++++++-------------------
3 files changed, 53 insertions(+), 28 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index e42f6ed..edf3dfe 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -250,6 +250,7 @@ enum {
HCI_CONN_ENCRYPT_PEND,
HCI_CONN_RSWITCH_PEND,
HCI_CONN_MODE_CHANGE_PEND,
+ HCI_CONN_SCO_SETUP_PEND,
};
static inline void hci_conn_hash_init(struct hci_dev *hdev)
@@ -330,6 +331,7 @@ void hci_acl_connect(struct hci_conn *conn);
void hci_acl_disconn(struct hci_conn *conn, __u8 reason);
void hci_add_sco(struct hci_conn *conn, __u16 handle);
void hci_setup_sync(struct hci_conn *conn, __u16 handle);
+void hci_sco_setup(struct hci_conn *conn, __u8 status);
struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst);
int hci_conn_del(struct hci_conn *conn);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index b10e3cd..805a22c 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -155,6 +155,27 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp);
}
+/* Device _must_ be locked */
+void hci_sco_setup(struct hci_conn *conn, __u8 status)
+{
+ struct hci_conn *sco = conn->link;
+
+ BT_DBG("%p", conn);
+
+ if (!sco)
+ return;
+
+ if (!status) {
+ if (lmp_esco_capable(conn->hdev))
+ hci_setup_sync(sco, conn->handle);
+ else
+ hci_add_sco(sco, conn->handle);
+ } else {
+ hci_proto_connect_cfm(sco, status);
+ hci_conn_del(sco);
+ }
+}
+
static void hci_conn_timeout(unsigned long arg)
{
struct hci_conn *conn = (void *) arg;
@@ -380,10 +401,13 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8
acl->power_save = 1;
hci_conn_enter_active_mode(acl);
- if (lmp_esco_capable(hdev))
- hci_setup_sync(sco, acl->handle);
- else
- hci_add_sco(sco, acl->handle);
+ if (test_bit(HCI_CONN_MODE_CHANGE_PEND, &acl->pend)) {
+ /* defer SCO setup until mode change completed */
+ set_bit(HCI_CONN_SCO_SETUP_PEND, &acl->pend);
+ return sco;
+ }
+
+ hci_sco_setup(acl, 0x00);
}
return sco;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 6c57fc7..9aee8c5 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -775,9 +775,6 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
BT_DBG("%s status 0x%x", hdev->name, status);
- if (!status)
- return;
-
cp = hci_sent_cmd_data(hdev, HCI_OP_SNIFF_MODE);
if (!cp)
return;
@@ -785,8 +782,15 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
- if (conn)
- clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+ if (conn) {
+ if (status) {
+ clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+
+ if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
+ &conn->pend))
+ hci_sco_setup(conn, status);
+ }
+ }
hci_dev_unlock(hdev);
}
@@ -798,9 +802,6 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
BT_DBG("%s status 0x%x", hdev->name, status);
- if (!status)
- return;
-
cp = hci_sent_cmd_data(hdev, HCI_OP_EXIT_SNIFF_MODE);
if (!cp)
return;
@@ -808,8 +809,15 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
- if (conn)
- clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+ if (conn) {
+ if (status) {
+ clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+
+ if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
+ &conn->pend))
+ hci_sco_setup(conn, status);
+ }
+ }
hci_dev_unlock(hdev);
}
@@ -915,20 +923,8 @@ static inline void hci_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *s
} else
conn->state = BT_CLOSED;
- if (conn->type == ACL_LINK) {
- struct hci_conn *sco = conn->link;
- if (sco) {
- if (!ev->status) {
- if (lmp_esco_capable(hdev))
- hci_setup_sync(sco, conn->handle);
- else
- hci_add_sco(sco, conn->handle);
- } else {
- hci_proto_connect_cfm(sco, ev->status);
- hci_conn_del(sco);
- }
- }
- }
+ if (conn->type == ACL_LINK)
+ hci_sco_setup(conn, ev->status);
if (ev->status) {
hci_proto_connect_cfm(conn, ev->status);
@@ -1478,6 +1474,9 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
conn->power_save = 1;
else
conn->power_save = 0;
+ } else if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
+ &conn->pend)) {
+ hci_sco_setup(conn, ev->status);
}
}
--
1.7.0.2
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* Re: [PATCH 1/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Alan Ott @ 2010-07-22 16:58 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Jiri Kosina, David S Miller, Michael Poole, Bastien Nocera,
Eric Dumazet, linux-bluetooth, linux-kernel, netdev
In-Reply-To: <1279812115.2621.6.camel@localhost.localdomain>
On 07/22/2010 11:21 AM, Marcel Holtmann wrote:
>>>>>>> what is usb-hid.ko doing here? I would expect a bunch of code
>>>>>>> duplication with minor difference between USB and Bluetooth.
>>>>>>>
>>>>>>>
>>>>>> usbhid doesn't have a lot of code for hidraw. Two functions are involved:
>>>>>> usbhid_output_raw_report()
>>>>>> - calls usb_control_msg() with Get_Report
>>>>>> usbhid_get_raw_report()
>>>>>> - calls usb_control_msg() with Set_Report
>>>>>> OR
>>>>>> - calls usb_interrupt_msg() on the Ouput pipe.
>>>>>>
>>>>>> This is of course easier than bluetooth because usb_control_msg() is
>>>>>> synchronous, even when requesting reports, mostly because of the nature
>>>>>> of USB, where the request and response are part of the same transfer.
>>>>>>
>>>>>> For Bluetooth, it's a bit more complicated since the kernel treats it
>>>>>> more like a networking interface (and indeed it is). My understanding is
>>>>>> that to make a synchronous transfer in bluetooth, one must:
>>>>>> - send the request packet
>>>>>> - block (wait_event_*())
>>>>>> - when the response is received in the input handler, wake_up_*().
>>>>>>
>>>>>> There's not really any code duplication, mostly because initiating
>>>>>> synchronous USB transfers (input and output) is easy (because of the
>>>>>> usb_*_msg() functions), while making synchronous Bluetooth transfers
>>>>>> must be done manually. If there's a nice, convenient, synchronous
>>>>>> function in Bluetooth similar to usb_control_msg() that I've missed,
>>>>>> then let me know, as it would simplify this whole thing.
>>>>>>
>>>>>>
>>>>> there is not and I don't think we ever get one. My question here was
>>>>> more in the direction why HID core is doing these synchronously in the
>>>>> first place. Especially since USB can do everything async as well.
>>>>>
>>>> I'm open to suggestions. The way I see it is from a user space
>>>> perspective. With Get_Feature being on an ioctl(), I don't see any clean
>>>> way to do it other than synchronously. Other operating systems (I can
>>>> say for sure Windows, Mac OS X, and FreeBSD) handle Get/Set Feature the
>>>> same way (synchronously) from user space.
>>>>
>>>> You seem to be proposing an asynchronous interface. What would that look
>>>> like from user space?
>>>>
>>> not necessarily from user space, but at least from HID core to HIDP and
>>> usb-hid transports. At least that is what I would expect, Jiri?
>>>
>> Sorry for this taking too long (vacations, conferences, you name it) for
>> me to respond.
>>
>> As all the _raw() callbacks are purely intended for userspace interaction
>> anyway, it's perfectly fine (and in fact desirable) for the low-level
>> transport drivers to perform these operations synchronously (and that's
>> what USB implementation does as well).
>>
>> Marcel, if your opposition to synchronous interface is strong, we'll have
>> to think about other aproaches, but from my POV, the patch is fine as-is
>> for Bluetooth.
>>
> that the ioctl() API is synchronous is fine to me, however pushing that
> down to the transport drivers seems wrong to me. I think the HID core
> should be able to handle a fully asynchronous transport driver. I know
> that with the USB subsystem you are little bit spoiled here, but for
> Bluetooth it is not the case. And in the end even using the asynchronous
> USB URB calls would be nice as well.
>
How are the URB calls better than using the synchronous calls? (see below)
> So why not make the core actually wait for responses from the transport
> driver.
Because this makes the USB side a lot more complicated, and it would
introduce transport specific code into the core. Further, it would
involve the transport driver calling hidraw with _every_ single packet
it receives. Further, it would have to call hidraw with HANDSHAKE
protocol error packets as well.
> I would make the transport drivers a lot simpler in the long
> run.
It would make the USB transport driver and drivers/hid/hidraw much more
complicated right now, at the expense of making the BT transport driver
marginally simpler (and I'm not even convinced whether it would really
be simpler). (see below for more)
> And I know that most likely besides Bluetooth and USB you won't see
> another, but you never know.
>
>
I just don't understand the objection. In each transport type, the
waiting will have to be done in a different way. USB and BT are
different enough that this is the case already, without having to
imagine future buses which use HID. In BT, you have to check each packet
which comes back from the BT network to see whether it is the response
packet that hidraw is waiting for. Further, you have to check for
HANDSHAKE packets indicating protocol error. Where better for this to be
done than in hidp? Further, how can this possibly happen in
drivers/hid/hidraw, as it doesn't know about the details of bluetooth to
make this determination, and why should it? In my last email (
http://lkml.org/lkml/2010/7/9/231 ) to which I got no response, I laid
out how doing the blocking in drivers/hid/hidraw would only make all the
parts except bluetooth more complicated (including the core, and the USB
side), and would also introduce bluetooth-specific things into the core.
Further, you're saying that using the asynchronous USB URB calls would
be a benefit. How is it a benefit to replace a single function call
which does exactly what I want, with a set of asynchronous calls and
then adding my own blocking to make it do the same thing? This sounds to
me like it would be 1: more text, 2: duplication of code, 3: error
prone. I can't understand how this is of benefit. Please explain to me
what I'm missing.
In theory, what you're saying makes sense. Making common code and logic
actually common is always good. In practice though, in this case, I
submit that there really isn't any commonality, and the only way for
there to be commonality is to do the USB side the hard way. Further,
drivers/hid/hidraw can't wait for a bluetooth packet without having code
that's bluetooth-specific. It seems just that simple to me.
I'll give it some more thought, and take another look at the code to see
if there's something obvious that I'm missing. If you know what I'm
missing in my understanding of the problem, please tell me :)
Alan.
^ permalink raw reply
* [PATCH 5/5] Extended support for generating dictionary value of service UUIDs
From: Inga Stotland @ 2010-07-22 16:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, marcel, johan.hedberg, Inga Stotland
In-Reply-To: <1279814780-29673-1-git-send-email-ingas@codeaurora.org>
---
src/adapter.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
src/adapter.h | 4 +-
src/dbus-hci.c | 6 ++--
3 files changed, 97 insertions(+), 8 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index b22b086..2438c29 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2763,8 +2763,84 @@ static void emit_device_found(const char *path, const char *address,
g_dbus_send_message(connection, signal);
}
+static int get_uuid_count_eir(uint8_t *eir_data)
+{
+ uint8_t len = 0;
+ int count = 0;
+
+ while (len < EIR_DATA_LENGTH) {
+ uint8_t type = eir_data[1];
+ uint8_t field_len = eir_data[0];
+ if (type == EIR_UUID16_SOME || type == EIR_UUID16_ALL)
+ count += field_len/2;
+ else if (type == EIR_UUID32_SOME || type == EIR_UUID32_ALL)
+ count += field_len/4;
+ else if (type == EIR_UUID128_SOME || type == EIR_UUID128_ALL)
+ count += field_len/16;
+ len += field_len + 1;
+ eir_data += field_len + 1;
+ }
+
+ return count;
+}
+
+static void get_uuids_eir(char **uuids, uint8_t *eir_data)
+{
+ uint8_t len = 0;
+
+ /* Count UUID16, UUID32 and UUID128 */
+ while (len < EIR_DATA_LENGTH) {
+ uint8_t field_len = eir_data[0];
+ uint8_t type = eir_data[1];
+ int count;
+ uuid_t service;
+ int size;
+ uint8_t *data = &eir_data[2];
+ int i, k;
+
+ /* Generate uuids in SDP format (EIR data is Little Endian) */
+ if (type == EIR_UUID16_SOME || type == EIR_UUID16_ALL) {
+ size = 2;
+ count = field_len/size;
+ service.type = SDP_UUID16;
+ for (i = 0; i < count; i++) {
+ uint16_t val16 = data[1];
+ val16 = (val16<<8) + data[0];
+ service.value.uuid16 = val16;
+ *uuids++ = bt_uuid2string(&service);
+ data += size;
+ }
+ } else if (type == EIR_UUID32_SOME || type == EIR_UUID32_ALL) {
+ size = 4;
+ count = field_len/size;
+ service.type = SDP_UUID32;
+ for (i = 0; i < count; i++) {
+ uint32_t val32 = data[3];
+ for (k = size-2; k >= 0; k--)
+ val32 = (val32<<8) + data[k];
+ service.value.uuid32 = val32;
+ *uuids++ = bt_uuid2string(&service);
+ data += size;
+ }
+ } else if (type == EIR_UUID128_SOME || type == EIR_UUID128_ALL) {
+ size = 16;
+ count = field_len/size;
+ service.type = SDP_UUID128;
+ for (i = 0; i < count; i++) {
+ for (k = 0; k < size; k++)
+ service.value.uuid128.data[k] = data[size-k-1];
+ *uuids++ = bt_uuid2string(&service);
+ data += size;
+ }
+ }
+
+ len += field_len + 1;
+ eir_data += field_len + 1;
+ }
+}
+
void adapter_emit_device_found(struct btd_adapter *adapter,
- struct remote_dev_info *dev)
+ struct remote_dev_info *dev, uint8_t *eir_data)
{
struct btd_device *device;
char peer_addr[18], local_addr[18];
@@ -2772,6 +2848,8 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
dbus_bool_t paired = FALSE;
dbus_int16_t rssi = dev->rssi;
char *alias;
+ char **uuids = NULL;
+ int uuid_count = 0;
ba2str(&dev->bdaddr, peer_addr);
ba2str(&adapter->bdaddr, local_addr);
@@ -2791,6 +2869,15 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
} else
alias = g_strdup(dev->alias);
+ /* Extract UUIDs from extended inquiry response if any*/
+ if (eir_data != NULL)
+ uuid_count = get_uuid_count_eir(eir_data);
+
+ if (uuid_count > 0) {
+ uuids = g_new0(char *, uuid_count + 1);
+ get_uuids_eir(uuids, eir_data);
+ }
+
emit_device_found(adapter->path, paddr,
"Address", DBUS_TYPE_STRING, &paddr,
"Class", DBUS_TYPE_UINT32, &dev->class,
@@ -2800,15 +2887,17 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
"Alias", DBUS_TYPE_STRING, &alias,
"LegacyPairing", DBUS_TYPE_BOOLEAN, &dev->legacy,
"Paired", DBUS_TYPE_BOOLEAN, &paired,
+ "UUIDs", DBUS_TYPE_ARRAY, &uuids, uuid_count,
NULL);
g_free(alias);
+ g_strfreev(uuids);
}
void adapter_update_found_devices(struct btd_adapter *adapter, bdaddr_t *bdaddr,
int8_t rssi, uint32_t class, const char *name,
const char *alias, gboolean legacy,
- name_status_t name_status)
+ name_status_t name_status, uint8_t *eir_data)
{
struct remote_dev_info *dev, match;
@@ -2847,7 +2936,7 @@ done:
adapter->found_devices = g_slist_sort(adapter->found_devices,
(GCompareFunc) dev_rssi_cmp);
- adapter_emit_device_found(adapter, dev);
+ adapter_emit_device_found(adapter, dev, eir_data);
}
int adapter_remove_found_device(struct btd_adapter *adapter, bdaddr_t *bdaddr)
diff --git a/src/adapter.h b/src/adapter.h
index f72eb0b..231d2c9 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -113,10 +113,10 @@ struct remote_dev_info *adapter_search_found_devices(struct btd_adapter *adapter
void adapter_update_found_devices(struct btd_adapter *adapter, bdaddr_t *bdaddr,
int8_t rssi, uint32_t class, const char *name,
const char *alias, gboolean legacy,
- name_status_t name_status);
+ name_status_t name_status, uint8_t *eir_data);
int adapter_remove_found_device(struct btd_adapter *adapter, bdaddr_t *bdaddr);
void adapter_emit_device_found(struct btd_adapter *adapter,
- struct remote_dev_info *dev);
+ struct remote_dev_info *dev, uint8_t *eir_data);
void adapter_update_oor_devices(struct btd_adapter *adapter);
void adapter_mode_changed(struct btd_adapter *adapter, uint8_t scan_mode);
void adapter_setname_complete(bdaddr_t *local, uint8_t status);
diff --git a/src/dbus-hci.c b/src/dbus-hci.c
index b83506f..6d27caa 100644
--- a/src/dbus-hci.c
+++ b/src/dbus-hci.c
@@ -515,7 +515,7 @@ void hcid_dbus_inquiry_result(bdaddr_t *local, bdaddr_t *peer, uint32_t class,
if (dev) {
adapter_update_found_devices(adapter, peer, rssi, class,
NULL, NULL, dev->legacy,
- NAME_NOT_REQUIRED);
+ NAME_NOT_REQUIRED, data);
return;
}
@@ -566,7 +566,7 @@ void hcid_dbus_inquiry_result(bdaddr_t *local, bdaddr_t *peer, uint32_t class,
/* add in the list to track name sent/pending */
adapter_update_found_devices(adapter, peer, rssi, class, name, alias,
- legacy, name_status);
+ legacy, name_status, data);
g_free(name);
g_free(alias);
@@ -642,7 +642,7 @@ void hcid_dbus_remote_name(bdaddr_t *local, bdaddr_t *peer, uint8_t status,
if (dev_info) {
g_free(dev_info->name);
dev_info->name = g_strdup(name);
- adapter_emit_device_found(adapter, dev_info);
+ adapter_emit_device_found(adapter, dev_info, NULL);
}
if (device)
--
1.7.1
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 4/5] Handle arrays in device properties dictionary
From: Inga Stotland @ 2010-07-22 16:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, marcel, johan.hedberg, Inga Stotland
In-Reply-To: <1279814780-29673-1-git-send-email-ingas@codeaurora.org>
---
src/adapter.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index c1e1768..b22b086 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2715,6 +2715,7 @@ static void append_dict_valist(DBusMessageIter *iter,
DBusMessageIter dict;
const char *key;
int type;
+ int n_elements;
void *val;
dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY,
@@ -2726,7 +2727,12 @@ static void append_dict_valist(DBusMessageIter *iter,
while (key) {
type = va_arg(var_args, int);
val = va_arg(var_args, void *);
- dict_append_entry(&dict, key, type, val);
+ if (type == DBUS_TYPE_ARRAY) {
+ n_elements = va_arg(var_args, int);
+ if (n_elements > 0)
+ dict_append_array(&dict, key, DBUS_TYPE_STRING, val, n_elements);
+ } else
+ dict_append_entry(&dict, key, type, val);
key = va_arg(var_args, char *);
}
--
1.7.1
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 3/5] Update EIR whenever record is added or removed
From: Inga Stotland @ 2010-07-22 16:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, marcel, johan.hedberg, Inga Stotland
In-Reply-To: <1279814780-29673-1-git-send-email-ingas@codeaurora.org>
---
plugins/service.c | 18 ++++++++++++++++++
src/adapter.c | 23 ++++++++++++++++++++++-
src/adapter.h | 1 +
3 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/plugins/service.c b/plugins/service.c
index 96280bd..ee9176b 100644
--- a/plugins/service.c
+++ b/plugins/service.c
@@ -445,6 +445,8 @@ static DBusMessage *update_record(DBusConnection *conn, DBusMessage *msg,
strerror(EIO));
}
+ adapter_update_eir_data(&src);
+
return dbus_message_new_method_return(msg);
}
@@ -516,6 +518,7 @@ static DBusMessage *add_service_record(DBusConnection *conn,
const char *sender, *record;
dbus_uint32_t handle;
int err;
+ bdaddr_t bdaddr;
if (dbus_message_get_args(msg, NULL,
DBUS_TYPE_STRING, &record, DBUS_TYPE_INVALID) == FALSE)
@@ -526,6 +529,13 @@ static DBusMessage *add_service_record(DBusConnection *conn,
if (err < 0)
return failed_strerror(msg, err);
+ if (serv_adapter->adapter)
+ adapter_get_address(serv_adapter->adapter, &bdaddr);
+ else
+ bacpy(&bdaddr, BDADDR_ANY);
+
+ adapter_update_eir_data(&bdaddr);
+
reply = dbus_message_new_method_return(msg);
if (!reply)
return NULL;
@@ -550,6 +560,7 @@ static DBusMessage *remove_service_record(DBusConnection *conn,
struct service_adapter *serv_adapter = data;
dbus_uint32_t handle;
const char *sender;
+ bdaddr_t bdaddr;
if (dbus_message_get_args(msg, NULL, DBUS_TYPE_UINT32, &handle,
DBUS_TYPE_INVALID) == FALSE)
@@ -560,6 +571,13 @@ static DBusMessage *remove_service_record(DBusConnection *conn,
if (remove_record(conn, sender, serv_adapter, handle) < 0)
return not_available(msg);
+ if (serv_adapter->adapter)
+ adapter_get_address(serv_adapter->adapter, &bdaddr);
+ else
+ bacpy(&bdaddr, BDADDR_ANY);
+
+ adapter_update_eir_data(&bdaddr);
+
return dbus_message_new_method_return(msg);
}
diff --git a/src/adapter.c b/src/adapter.c
index 789a196..c1e1768 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -820,7 +820,7 @@ static DBusMessage *set_pairable_timeout(DBusConnection *conn,
static void update_ext_inquiry_response(struct btd_adapter *adapter)
{
- uint8_t fec = 0, data[240];
+ uint8_t fec = 0, data[EIR_DATA_LENGTH];
struct hci_dev *dev = &adapter->dev;
int dd;
@@ -846,6 +846,27 @@ static void update_ext_inquiry_response(struct btd_adapter *adapter)
hci_close_dev(dd);
}
+void adapter_update_eir_data(const bdaddr_t *src)
+{
+ struct btd_adapter *adapter;
+ GSList *adapters;
+
+ if (bacmp(src, BDADDR_ANY) != 0) {
+ adapter = manager_find_adapter(src);
+ if (adapter)
+ update_ext_inquiry_response(adapter);
+ else
+ error("Updating EIR failed: device not found");
+ } else {
+
+ /* Update extended inquiry reponse for ANY adapter */
+ for (adapters = manager_get_adapters(); adapters; adapters = adapters->next) {
+ adapter = adapters->data;
+ update_ext_inquiry_response(adapter);
+ }
+ }
+}
+
void adapter_set_class_complete(bdaddr_t *bdaddr, uint8_t status)
{
uint8_t class[3];
diff --git a/src/adapter.h b/src/adapter.h
index 8226514..f72eb0b 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -126,6 +126,7 @@ void adapter_service_insert(const bdaddr_t *bdaddr, void *rec);
void adapter_service_remove(const bdaddr_t *bdaddr, void *rec);
sdp_list_t *adapter_get_services(struct btd_adapter *adapter);
void adapter_set_class_complete(bdaddr_t *bdaddr, uint8_t status);
+void adapter_update_eir_data(const bdaddr_t *src);
struct agent *adapter_get_agent(struct btd_adapter *adapter);
void adapter_add_connection(struct btd_adapter *adapter,
--
1.7.1
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 2/5] Support for adding UUID128 to extended inquiry response
From: Inga Stotland @ 2010-07-22 16:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, marcel, johan.hedberg, Inga Stotland
In-Reply-To: <1279814780-29673-1-git-send-email-ingas@codeaurora.org>
---
src/sdpd-service.c | 108 ++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 92 insertions(+), 16 deletions(-)
diff --git a/src/sdpd-service.c b/src/sdpd-service.c
index cdbb4f4..1314ada 100644
--- a/src/sdpd-service.c
+++ b/src/sdpd-service.c
@@ -49,6 +49,8 @@
#include "manager.h"
#include "adapter.h"
+#define SIZEOF_UUID128 16
+
static sdp_record_t *server = NULL;
static uint16_t did_vendor = 0x0000;
@@ -174,41 +176,103 @@ static void update_svclass_list(const bdaddr_t *src)
}
+static void eir_generate_uuid128(sdp_list_t *list,
+ uint8_t *ptr, uint16_t *eir_len)
+{
+ int i, k, index = 0;
+ uint16_t len = *eir_len;
+ uint8_t *uuid128;
+ gboolean truncated = FALSE;
+
+ /* Store UUID128 in place, skip 2 bytes to insert type and length later */
+ uuid128 = ptr + 2;
+
+ for (; list; list = list->next) {
+ sdp_record_t *rec = (sdp_record_t *) list->data;
+
+ if (rec->svclass.type != SDP_UUID128)
+ continue;
+
+ /* Stop if not enough space to put next UUID128 */
+ if ((len + 2 + SIZEOF_UUID128) > EIR_DATA_LENGTH) {
+ truncated = TRUE;
+ break;
+ }
+
+ /* Check for duplicates, EIR data is Little Endian */
+ for (i = 0; i < index; i++) {
+ for (k = 0; k < SIZEOF_UUID128; k++) {
+ if (uuid128[i*SIZEOF_UUID128 + k] !=
+ rec->svclass.value.uuid128.data[SIZEOF_UUID128 - k])
+ break;
+ }
+ if (k == SIZEOF_UUID128)
+ break;
+ }
+
+ if (i < index)
+ continue;
+
+ /* EIR data is Little Endian */
+ for (k = 0; k < SIZEOF_UUID128; k++)
+ uuid128[index*SIZEOF_UUID128 + k] =
+ rec->svclass.value.uuid128.data[SIZEOF_UUID128 - 1 - k];
+
+ len += SIZEOF_UUID128;
+ index++;
+ }
+
+ if (index > 0 || truncated) {
+ /* EIR Data length */
+ ptr[0] = (index * SIZEOF_UUID128) + 1;
+ /* EIR Data type */
+ ptr[1] = (truncated) ? EIR_UUID128_SOME : EIR_UUID128_ALL;
+ len += 2;
+ *eir_len = len;
+ }
+}
+
void create_ext_inquiry_response(const char *name,
int8_t tx_power, sdp_list_t *services,
uint8_t *data)
{
sdp_list_t *list = services;
uint8_t *ptr = data;
- uint16_t uuid[24];
+ uint16_t eir_len = 0;
+ uint16_t uuid16[EIR_DATA_LENGTH/2];
int i, index = 0;
+ gboolean truncated = FALSE;
if (name) {
int len = strlen(name);
+ /* EIR Data type */
if (len > 48) {
len = 48;
- ptr[1] = 0x08;
+ ptr[1] = EIR_NAME_SHORT;
} else
- ptr[1] = 0x09;
+ ptr[1] = EIR_NAME_COMPLETE;
+ /* EIR Data length */
ptr[0] = len + 1;
memcpy(ptr + 2, name, len);
- ptr += len + 2;
+ eir_len += (len + 2);
+ ptr += (len + 2);
}
if (tx_power != 0) {
*ptr++ = 2;
- *ptr++ = 0x0a;
+ *ptr++ = EIR_TX_POWER;
*ptr++ = (uint8_t) tx_power;
+ eir_len += 3;
}
if (did_vendor != 0x0000) {
uint16_t source = 0x0002;
*ptr++ = 9;
- *ptr++ = 0x10;
+ *ptr++ = EIR_DEVICE_ID;
*ptr++ = (source & 0x00ff);
*ptr++ = (source & 0xff00) >> 8;
*ptr++ = (did_vendor & 0x00ff);
@@ -217,10 +281,10 @@ void create_ext_inquiry_response(const char *name,
*ptr++ = (did_product & 0xff00) >> 8;
*ptr++ = (did_version & 0x00ff);
*ptr++ = (did_version & 0xff00) >> 8;
+ eir_len += 10;
}
- ptr[1] = 0x03;
-
+ /* Group all UUID16 types */
for (; list; list = list->next) {
sdp_record_t *rec = (sdp_record_t *) list->data;
@@ -233,30 +297,42 @@ void create_ext_inquiry_response(const char *name,
if (rec->svclass.value.uuid16 == PNP_INFO_SVCLASS_ID)
continue;
- if (index > 23) {
- ptr[1] = 0x02;
+ /* Stop if not enough space to put next UUID16 */
+ if ((eir_len + 2 + sizeof(uint16_t)) > EIR_DATA_LENGTH) {
+ truncated = TRUE;
break;
}
+ /* Check for duplicates */
for (i = 0; i < index; i++)
- if (uuid[i] == rec->svclass.value.uuid16)
+ if (uuid16[i] == rec->svclass.value.uuid16)
break;
- if (i == index - 1)
+ if (i < index)
continue;
- uuid[index++] = rec->svclass.value.uuid16;
+ uuid16[index++] = rec->svclass.value.uuid16;
+ eir_len += sizeof(uint16_t);
}
if (index > 0) {
- ptr[0] = (index * 2) + 1;
+ /* EIR Data length */
+ ptr[0] = (index * sizeof(uint16_t)) + 1;
+ /* EIR Data type */
+ ptr[1] = (truncated) ? EIR_UUID16_SOME : EIR_UUID16_ALL;
+
ptr += 2;
+ eir_len += 2;
for (i = 0; i < index; i++) {
- *ptr++ = (uuid[i] & 0x00ff);
- *ptr++ = (uuid[i] & 0xff00) >> 8;
+ *ptr++ = (uuid16[i] & 0x00ff);
+ *ptr++ = (uuid16[i] & 0xff00) >> 8;
}
}
+
+ /* Group all UUID128 types */
+ if (eir_len <= EIR_DATA_LENGTH - 2)
+ eir_generate_uuid128(services, ptr, &eir_len);
}
void register_public_browse_group(void)
--
1.7.1
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 1/5] Spec constants for Extended Inquiry Response field types
From: Inga Stotland @ 2010-07-22 16:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, marcel, johan.hedberg, Inga Stotland
In-Reply-To: <1279814780-29673-1-git-send-email-ingas@codeaurora.org>
---
src/sdpd.h | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/sdpd.h b/src/sdpd.h
index e93b0b6..c1d69a9 100644
--- a/src/sdpd.h
+++ b/src/sdpd.h
@@ -34,6 +34,19 @@
#define SDPDBG(fmt...)
#endif
+#define EIR_DATA_LENGTH 240
+
+#define EIR_UUID16_SOME 0x02 /* 16-bit UUID, more available */
+#define EIR_UUID16_ALL 0x03 /* 16-bit UUID, all listed */
+#define EIR_UUID32_SOME 0x04 /* 32-bit UUID, more available */
+#define EIR_UUID32_ALL 0x05 /* 32-bit UUID, all listed */
+#define EIR_UUID128_SOME 0x06 /* 128-bit UUID, more available */
+#define EIR_UUID128_ALL 0x07 /* 128-bit UUID, all listed */
+#define EIR_NAME_SHORT 0x08 /* shortened local name */
+#define EIR_NAME_COMPLETE 0x09 /* complete local name */
+#define EIR_TX_POWER 0x0A /* Transmit power level */
+#define EIR_DEVICE_ID 0x10 /* device ID */
+
typedef struct request {
bdaddr_t device;
bdaddr_t bdaddr;
--
1.7.1
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH v4 0/5] Enhanced support for extended inquiry response
From: Inga Stotland @ 2010-07-22 16:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, marcel, johan.hedberg
EIR is updated whenever local SDP record database changes.
Added support for UUID128 service descriptors in EIR to allow peek at available
services offered by a remote device without establishing SDP connection.
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Marcel Holtmann @ 2010-07-22 15:21 UTC (permalink / raw)
To: Jiri Kosina
Cc: Alan Ott, David S Miller, Michael Poole, Bastien Nocera,
Eric Dumazet, linux-bluetooth, linux-kernel, netdev
In-Reply-To: <alpine.LNX.2.00.1007221612450.4741@pobox.suse.cz>
Hi Jiri,
> > > >>> what is usb-hid.ko doing here? I would expect a bunch of code
> > > >>> duplication with minor difference between USB and Bluetooth.
> > > >>>
> > > >> usbhid doesn't have a lot of code for hidraw. Two functions are involved:
> > > >> usbhid_output_raw_report()
> > > >> - calls usb_control_msg() with Get_Report
> > > >> usbhid_get_raw_report()
> > > >> - calls usb_control_msg() with Set_Report
> > > >> OR
> > > >> - calls usb_interrupt_msg() on the Ouput pipe.
> > > >>
> > > >> This is of course easier than bluetooth because usb_control_msg() is
> > > >> synchronous, even when requesting reports, mostly because of the nature
> > > >> of USB, where the request and response are part of the same transfer.
> > > >>
> > > >> For Bluetooth, it's a bit more complicated since the kernel treats it
> > > >> more like a networking interface (and indeed it is). My understanding is
> > > >> that to make a synchronous transfer in bluetooth, one must:
> > > >> - send the request packet
> > > >> - block (wait_event_*())
> > > >> - when the response is received in the input handler, wake_up_*().
> > > >>
> > > >> There's not really any code duplication, mostly because initiating
> > > >> synchronous USB transfers (input and output) is easy (because of the
> > > >> usb_*_msg() functions), while making synchronous Bluetooth transfers
> > > >> must be done manually. If there's a nice, convenient, synchronous
> > > >> function in Bluetooth similar to usb_control_msg() that I've missed,
> > > >> then let me know, as it would simplify this whole thing.
> > > >>
> > > > there is not and I don't think we ever get one. My question here was
> > > > more in the direction why HID core is doing these synchronously in the
> > > > first place. Especially since USB can do everything async as well.
> > >
> > > I'm open to suggestions. The way I see it is from a user space
> > > perspective. With Get_Feature being on an ioctl(), I don't see any clean
> > > way to do it other than synchronously. Other operating systems (I can
> > > say for sure Windows, Mac OS X, and FreeBSD) handle Get/Set Feature the
> > > same way (synchronously) from user space.
> > >
> > > You seem to be proposing an asynchronous interface. What would that look
> > > like from user space?
> >
> > not necessarily from user space, but at least from HID core to HIDP and
> > usb-hid transports. At least that is what I would expect, Jiri?
>
> Sorry for this taking too long (vacations, conferences, you name it) for
> me to respond.
>
> As all the _raw() callbacks are purely intended for userspace interaction
> anyway, it's perfectly fine (and in fact desirable) for the low-level
> transport drivers to perform these operations synchronously (and that's
> what USB implementation does as well).
>
> Marcel, if your opposition to synchronous interface is strong, we'll have
> to think about other aproaches, but from my POV, the patch is fine as-is
> for Bluetooth.
that the ioctl() API is synchronous is fine to me, however pushing that
down to the transport drivers seems wrong to me. I think the HID core
should be able to handle a fully asynchronous transport driver. I know
that with the USB subsystem you are little bit spoiled here, but for
Bluetooth it is not the case. And in the end even using the asynchronous
USB URB calls would be nice as well.
So why not make the core actually wait for responses from the transport
driver. I would make the transport drivers a lot simpler in the long
run. And I know that most likely besides Bluetooth and USB you won't see
another, but you never know.
Regards
Marcel
^ permalink raw reply
* Re: Any update on software caused connection abort issue??
From: john michelle @ 2010-07-22 14:17 UTC (permalink / raw)
To: Lukas; +Cc: linux-bluetooth
In-Reply-To: <201007211753.26822.LuHe@gmx.at>
Hi Lukas,
> It would be great to see this problem fixed soon, because it's nearly
> impossible to use bluetooth on my PC.
I think it's useless to get any reply from this mailing list, i have
been reporting this
Problem for a long time and no one simply cares.
John
On Wed, Jul 21, 2010 at 5:53 PM, Lukas <LuHe@gmx.at> wrote:
> Hello,
>
> On Wednesday 21 July 2010 17:35:15 john michelle wrote:
>> Any update on software caused connection abort issue
>
> I also noticed this error when I used the software suite Series60-Remote to
> connect to my mobile phone.
>
> Shortly after the connection establishment is completed I get the error
> message "software caused connection abort" and the device gets disconnected.
>
> I also see the HCI reset, as described below, when I try to investigate this
> error using hcidump.
>
> The software uses the RFCOMM protocol for the connection.
> I use an USB bluetooth adapter from Belkin, lsusb reports the following device
> id:
> ID 050d:0131 Belkin Components Bluetooth Device with trace filter
>
> This bug happens with the following kernel:
> root@erde ~ # rpm -q kernel bluez
> kernel-2.6.33.6-147.fc13.x86_64
> bluez-4.64-1.fc13.x86_64
>
> You can also look at this thread in my mailing list for further informations:
> https://sourceforge.net/mailarchive/forum.php?thread_name=201007192136.27723.LuHe%40gmx.at&forum_name=series60-
> remote-devel
>
> It would be great to see this problem fixed soon, because it's nearly
> impossible to use bluetooth on my PC.
>
> Thanks,
> Lukas
>
>> >>On Wed, Jun 23, 2010 at 12:48 AM, john michelle <jhnmichelle@gmail.com>
> wrote:
>> >> Dear Bluetooth community,
>> >>
>> >> You are committing version after version and have time to add new
>> >> Features and the core stack have a major bug (software Caused
>> >> connection abort) that i
>> >> Have reported on the 7th of may the problem seems to be either in the
>> >> usb part of the
>> >> Kernel or the bluez stack, i am no kernel engineer so i came directly
>> >> to you for reporting
>> >> This problem and my requests to look into this problem are just
>> >> ignored. this is a blocker
>> >> Issue that would prevent and discourage any one from developing
>> >> application that rely on
>> >> Bluez sco capabilities, since during transmission the above mentioned
>> >> error just occurs.
>> >> I hope that my voice is heared and i would get a reply from the bluez
>> >> community.
>> >>
>> >> John
>> >>
>> >> On Wed, Jun 16, 2010 at 3:11 PM, john michelle <jhnmichelle@gmail.com>
> wrote:
>> >>> On Sun, May 30, 2010 at 1:12 PM, john michelle <jhnmichelle@gmail.com>
> wrote:
>> >>>> Hi Gustavo,
>> >>>>
>> >>>>>> Please post the output of hcidump when the connection abort happens.
>> >>>>
>> >>>> Below is the output of hcidump the moments the software caused
>> >>>> connection abort
>> >>>>
>> >>>> Dongle 1:
>> >>>>> HCI Event: Number of Completed Packets (0x13) plen 5
>> >>>>
>> >>>> . * . . .
>> >>>> < HCI Command: Reset (0x03|0x0003) plen 0
>> >>>> device: disconnected
>> >>>>
>> >>>> Dongle 2:
>> >>>>> HCI Event: Number of Completed Packets (0x13) plen 5
>> >>>>
>> >>>> . * . . .
>> >>>> < HCI Command: Reset (0x03|0x0003) plen 0
>> >>>> device: disconnected
>> >>>>
>> >>>>
>> >>>> I think something triggers hci reset which causes this problem, but
>> >>>> what exactly Triggers it i don't know.
>> >>>>
>> >>>>
>> >>>> John
>> >>>
>> >>> Hi all,
>> >>>
>> >>> Is anyone going to give this problem a try, it has been like a month
>> >>> now This is a real problem in the bluez stack and someone have to look
>> >>> in this Issue.
>> >>>
>> >>> John
>> >>>
>> >>>> On Mon, May 17, 2010 at 5:21 PM, john michelle <jhnmichelle@gmail.com>
> wrote:
>> >>>>>> Hi Jonh,
>> >>>>>>
>> >>>>>> First of all, don't do top posting in this mailing list. ;)
>> >>>>>
>> >>>>> Thanks for the advise , will keep that in mind for future posts.
>> >>>>>
>> >>>>>> In which bluez/kernel version the problem started? Any hardware
>> >>>>>> update during this time? The problem happens when you are already
>> >>>>>> tranfering SCO data?
>> >>>>>
>> >>>>> I tried bluez versions 3.XX and kernel 2.6.26(I think) the problem
>> >>>>> occurs and the kernel panics with no core dumps.then i tried with
>> >>>>> bluez 4.53-4.62 with
>> >>>>> Kernel 2.6.31 and 2.6.32. the connection abort problem occurs but the
>> >>>>> kernel doesn't
>> >>>>> Panic. regarding the hardware update you mean the dongle or the
>> >>>>> box.Anyway i changed both and tried different box's, this even
>> >>>>> happens on a box with 2 giga ram
>> >>>>> And core2 processor . as for the dongles i am using trust
>> >>>>>
>> >>>>> http://www.twenga.co.uk/prices-Bluetooth-2-USB-Adapter-10m-BT-2250p-T
>> >>>>> RUST-Wireless-network-card-adapter-176178-0
>> >>>>>
>> >>>>> and also using no name dongles all the same problem.
>> >>>>>
>> >>>>>> Please post the output of hcidump when the connection abort happens.
>> >>>>>
>> >>>>> well that is going to be a hard one since i have more than one dongle
>> >>>>> in place And very hard to predict which one will crash.i will work
>> >>>>> on this and update You as soon as i have the hcidump log.
>> >>>>>
>> >>>>>> I tried reproduce this issue in L2CAP but it is a bit hard, lets
>> >>>>>> say it happen once in a thousand, so it's not easy to track it. I
>> >>>>>> have to try reproduce that using the SCO, but I'm not used to that
>> >>>>>> layer yet. ;)
>> >>>>>
>> >>>>> I hoped that it happens 1 in 1000 in SCO , but it actually happens 1
>> >>>>> in 15
>> >>>>>
>> >>>>>
>> >>>>> John
>> >>>>>
>> >>>>>> Regards,
>> >>>>>>
>> >>>>>>> John
>> >>>>>>>
>> >>>>>>> On Fri, May 7, 2010 at 3:53 PM, Gustavo F. Padovan
> <gustavo@padovan.org> wrote:
>> >>>>>>> > * john michelle <jhnmichelle@gmail.com> [2010-05-07 15:49:05
> -0400]:
>> >>>>>>> >> Hi Bluetooth hackers,
>> >>>>>>> >>
>> >>>>>>> >> i am having this consistent problem with bluez , from time to
>> >>>>>>> >> time i get the error Software caused connection abort (103 )
>> >>>>>>> >> And the bluetooth stick seems to disconnect and reconnects. this
>> >>>>>>> >> happens during an sco connection and it occurs even
>> >>>>>>> >> More when i am having the voice stream comming through the
>> >>>>>>> >> internet rather than the lan.i don't know what exact
>> >>>>>>> >> Details you need to solve this problem please tell me and i will
>> >>>>>>> >> give you an immediate reply . i have linux kernel 2.6.33 and
>> >>>>>>> >> bluez 4.62
>> >>>>>>> >
>> >>>>>>> > I get the same problem sometimes when testing ERTM with l2test.
>> >>>>>>> > So the problem is on l2cap too. I didn't have time to debug this
>> >>>>>>> > yet. Now that someone else have confirmed it too, I'll to take a
>> >>>>>>> > look at the problem.
>> >>>>>>
>> >>>>>> --
>> >>>>>> Gustavo F. Padovan
>> >>>>>> http://padovan.org
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>> in the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox