* Re: [PATCHv1 11/12] Bluetooth: AMP: Use l2cap_physical_cfm in phylink complete evt
From: Gustavo Padovan @ 2012-10-31 18:51 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1351691197-8394-12-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Andrei Emeltchenko <Andrei.Emeltchenko.news@gmail.com> [2012-10-31 15:46:36 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>
> When receiving HCI Phylink Complete event run amp_physical_cfm
> which initialize BR/EDR L2CAP channel associated with High Speed
> link and run l2cap_physical_cfm which shall send L2CAP Create
> Chan Request.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> include/net/bluetooth/amp.h | 1 +
> include/net/bluetooth/l2cap.h | 1 +
> net/bluetooth/amp.c | 24 ++++++++++++++++++++++++
> net/bluetooth/hci_event.c | 15 ++-------------
> 4 files changed, 28 insertions(+), 13 deletions(-)
Patches 1-11 have been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Notify about device registration before power on
From: Johan Hedberg @ 2012-10-31 19:09 UTC (permalink / raw)
To: Gustavo Padovan, Marcel Holtmann, linux-bluetooth
In-Reply-To: <20121031181801.GB1679@joana>
Hi Gustavo,
On Wed, Oct 31, 2012, Gustavo Padovan wrote:
> > It is important that the monitor interface gets notified about
> > a new device before its power on procedure has been started.
> >
> > For some reason that is no longer working as expected and the power
> > on procedure runs first. It is safe to just notify about device
> > registration and trigger the power on procedure afterwards.
> >
> > Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> > ---
> > net/bluetooth/hci_core.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Patch has been applied to bluetooth-next. Thanks.
I guess you mean bluetooth.git? (that's where the patch is right now -
not bluetooth-next). Also, I don't think the Cc: stable addition was
necessary since this scheduling behavior seems to be something only
introduced for 3.7 (not 100% sure about this though).
Johan
^ permalink raw reply
* BLE kernel supported
From: John Tobias @ 2012-10-31 19:25 UTC (permalink / raw)
To: linux-bluetooth
Hello all,
I am evaluating a dev board based on iMX6 chipset from freescale with
Bluetooth LE in the next few days or so. The stable kernel for the
said chipset is based on linux kernel 3.0.35.x and I am not sure if
the Bluetooth "Low Energy" support is already part of the linux kernel
3.0.35.x.
Anyone could give me some input?.
Regards,
john
^ permalink raw reply
* Re: BLE kernel supported
From: Marcel Holtmann @ 2012-10-31 19:31 UTC (permalink / raw)
To: John Tobias; +Cc: linux-bluetooth
In-Reply-To: <CACUGKYNaeyTq-1+5=4DNhb6hc0jVCp=xsh705qXLCtgJ37z6Nw@mail.gmail.com>
Hi John,
> I am evaluating a dev board based on iMX6 chipset from freescale with
> Bluetooth LE in the next few days or so. The stable kernel for the
> said chipset is based on linux kernel 3.0.35.x and I am not sure if
> the Bluetooth "Low Energy" support is already part of the linux kernel
> 3.0.35.x.
you need at least a 3.5.x kernel. Any previous kernel does not have Low
Energy enabled.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Notify about device registration before power on
From: Marcel Holtmann @ 2012-10-31 19:34 UTC (permalink / raw)
To: Johan Hedberg; +Cc: Gustavo Padovan, linux-bluetooth
In-Reply-To: <20121031190907.GA3631@x220.P-661HNU-F1>
Hi Gustavo,
> > > It is important that the monitor interface gets notified about
> > > a new device before its power on procedure has been started.
> > >
> > > For some reason that is no longer working as expected and the power
> > > on procedure runs first. It is safe to just notify about device
> > > registration and trigger the power on procedure afterwards.
> > >
> > > Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> > > ---
> > > net/bluetooth/hci_core.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Patch has been applied to bluetooth-next. Thanks.
>
> I guess you mean bluetooth.git? (that's where the patch is right now -
> not bluetooth-next). Also, I don't think the Cc: stable addition was
> necessary since this scheduling behavior seems to be something only
> introduced for 3.7 (not 100% sure about this though).
I did not send this to stable, because I think it is 3.7-rc only
behavior. Feel free to test it. With the help of btmon it is really easy
to see if the New Index event arrives before the first HCI command or
not. Remember that this only applies for newly attached devices and
btmon already running.
Regards
Marcel
^ permalink raw reply
* Re: BLE kernel supported
From: John Tobias @ 2012-10-31 19:41 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1351711915.1828.15.camel@aeonflux>
Hi Marcel,
I am using a pandaboard ES too and the kernel that I am using is 3.4.x
and I confirmed that it support the BLE.
Regards,
john
On Wed, Oct 31, 2012 at 12:31 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi John,
>
>> I am evaluating a dev board based on iMX6 chipset from freescale with
>> Bluetooth LE in the next few days or so. The stable kernel for the
>> said chipset is based on linux kernel 3.0.35.x and I am not sure if
>> the Bluetooth "Low Energy" support is already part of the linux kernel
>> 3.0.35.x.
>
> you need at least a 3.5.x kernel. Any previous kernel does not have Low
> Energy enabled.
>
> Regards
>
> Marcel
>
>
^ permalink raw reply
* Re: [PATCHv1 12/12] Bluetooth: Process Create Chan Request
From: Andrei Emeltchenko @ 2012-11-01 8:55 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1351700642.1828.13.camel@aeonflux>
Hi Marcel,
On Wed, Oct 31, 2012 at 09:24:02AM -0700, Marcel Holtmann wrote:
> Hi Andrei,
>
> > Add processing L2CAP Create Chan Request. When channel is created
> > save associated high speed link hs_hcon.
> >
> > Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> > ---
> > net/bluetooth/l2cap_core.c | 63 ++++++++++++++++++++++++++++++--------------
> > 1 file changed, 43 insertions(+), 20 deletions(-)
> >
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > index bdffc4c..783ffae 100644
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -4237,7 +4237,9 @@ static int l2cap_create_channel_req(struct l2cap_conn *conn,
> > u16 cmd_len, void *data)
> > {
> > struct l2cap_create_chan_req *req = data;
> > + struct l2cap_create_chan_rsp rsp;
> > struct l2cap_chan *chan;
> > + struct hci_dev *hdev = NULL;
>
> why is this one set to NULL. Can we avoid that please.
Sorry, forgot to clean this up from the previous patch. With the new patch
we do not need to set this NULL.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* [PATCH] Bluetooth: Fix parameter order of hci_get_route
From: Johan Hedberg @ 2012-11-01 11:27 UTC (permalink / raw)
To: linux-bluetooth
From: Johan Hedberg <johan.hedberg@intel.com>
The actual parameter order of hci_get_route is (dst, src) and not (src,
dst). All current callers use the right order but the header file shows
the parameters in the wrong order.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
include/net/bluetooth/hci_core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index b3490c6..ce6dbeb 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -685,7 +685,7 @@ static inline uint8_t __hci_num_ctrl(void)
}
struct hci_dev *hci_dev_get(int index);
-struct hci_dev *hci_get_route(bdaddr_t *src, bdaddr_t *dst);
+struct hci_dev *hci_get_route(bdaddr_t *dst, bdaddr_t *src);
struct hci_dev *hci_alloc_dev(void);
void hci_free_dev(struct hci_dev *hdev);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] Bluetooth: Process Create Chan Request
From: Andrei Emeltchenko @ 2012-11-01 13:37 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1351700642.1828.13.camel@aeonflux>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Add processing L2CAP Create Chan Request. When channel is created
save associated high speed link hs_hcon.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
net/bluetooth/l2cap_core.c | 63 ++++++++++++++++++++++++++++++--------------
1 file changed, 43 insertions(+), 20 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index bdffc4c..2f0e165 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4237,7 +4237,9 @@ static int l2cap_create_channel_req(struct l2cap_conn *conn,
u16 cmd_len, void *data)
{
struct l2cap_create_chan_req *req = data;
+ struct l2cap_create_chan_rsp rsp;
struct l2cap_chan *chan;
+ struct hci_dev *hdev;
u16 psm, scid;
if (cmd_len != sizeof(*req))
@@ -4251,36 +4253,57 @@ static int l2cap_create_channel_req(struct l2cap_conn *conn,
BT_DBG("psm 0x%2.2x, scid 0x%4.4x, amp_id %d", psm, scid, req->amp_id);
- if (req->amp_id) {
- struct hci_dev *hdev;
-
- /* Validate AMP controller id */
- hdev = hci_dev_get(req->amp_id);
- if (!hdev || hdev->dev_type != HCI_AMP ||
- !test_bit(HCI_UP, &hdev->flags)) {
- struct l2cap_create_chan_rsp rsp;
+ /* For controller id 0 make BR/EDR connection */
+ if (req->amp_id == HCI_BREDR_ID) {
+ l2cap_connect(conn, cmd, data, L2CAP_CREATE_CHAN_RSP,
+ req->amp_id);
+ return 0;
+ }
- rsp.dcid = 0;
- rsp.scid = cpu_to_le16(scid);
- rsp.result = __constant_cpu_to_le16(L2CAP_CR_BAD_AMP);
- rsp.status = __constant_cpu_to_le16(L2CAP_CS_NO_INFO);
+ /* Validate AMP controller id */
+ hdev = hci_dev_get(req->amp_id);
+ if (!hdev)
+ goto error;
- l2cap_send_cmd(conn, cmd->ident, L2CAP_CREATE_CHAN_RSP,
- sizeof(rsp), &rsp);
+ if (hdev->dev_type != HCI_AMP || !test_bit(HCI_UP, &hdev->flags)) {
+ hci_dev_put(hdev);
+ goto error;
+ }
- if (hdev)
- hci_dev_put(hdev);
+ chan = l2cap_connect(conn, cmd, data, L2CAP_CREATE_CHAN_RSP,
+ req->amp_id);
+ if (chan) {
+ struct amp_mgr *mgr = conn->hcon->amp_mgr;
+ struct hci_conn *hs_hcon;
- return 0;
+ hs_hcon = hci_conn_hash_lookup_ba(hdev, AMP_LINK, conn->dst);
+ if (!hs_hcon) {
+ hci_dev_put(hdev);
+ return -EFAULT;
}
- hci_dev_put(hdev);
+ BT_DBG("mgr %p bredr_chan %p hs_hcon %p", mgr, chan, hs_hcon);
+
+ chan->local_amp_id = req->amp_id;
+ mgr->bredr_chan = chan;
+ chan->hs_hcon = hs_hcon;
+ conn->mtu = hdev->block_mtu;
}
- chan = l2cap_connect(conn, cmd, data, L2CAP_CREATE_CHAN_RSP,
- req->amp_id);
+ hci_dev_put(hdev);
return 0;
+
+error:
+ rsp.dcid = 0;
+ rsp.scid = cpu_to_le16(scid);
+ rsp.result = __constant_cpu_to_le16(L2CAP_CR_BAD_AMP);
+ rsp.status = __constant_cpu_to_le16(L2CAP_CS_NO_INFO);
+
+ l2cap_send_cmd(conn, cmd->ident, L2CAP_CREATE_CHAN_RSP,
+ sizeof(rsp), &rsp);
+
+ return -EFAULT;
}
static void l2cap_send_move_chan_req(struct l2cap_chan *chan, u8 dest_amp_id)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] Bluetooth: Rename ctrl_id to remote_amp_id
From: Andrei Emeltchenko @ 2012-11-01 13:37 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1351777023-10018-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Since we have started to use local_amp_id for local AMP
Controller Id it makes sense to rename ctrl_id to remote_amp_id
since it represents remote AMP controller Id.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
include/net/bluetooth/l2cap.h | 3 +--
net/bluetooth/a2mp.c | 4 ++--
net/bluetooth/amp.c | 5 ++---
net/bluetooth/l2cap_core.c | 2 +-
4 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 18149c8..d65db45 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -481,6 +481,7 @@ struct l2cap_chan {
unsigned long conn_state;
unsigned long flags;
+ __u8 remote_amp_id;
__u8 local_amp_id;
__u8 move_id;
__u8 move_state;
@@ -518,8 +519,6 @@ struct l2cap_chan {
__u32 remote_acc_lat;
__u32 remote_flush_to;
- __u8 ctrl_id;
-
struct delayed_work chan_timer;
struct delayed_work retrans_timer;
struct delayed_work monitor_timer;
diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
index d5136cf..2f67d5e 100644
--- a/net/bluetooth/a2mp.c
+++ b/net/bluetooth/a2mp.c
@@ -423,7 +423,7 @@ static int a2mp_getampassoc_rsp(struct amp_mgr *mgr, struct sk_buff *skb,
BT_DBG("Created hcon %p: loc:%d -> rem:%d", hcon, hdev->id, rsp->id);
- mgr->bredr_chan->ctrl_id = rsp->id;
+ mgr->bredr_chan->remote_amp_id = rsp->id;
amp_create_phylink(hdev, mgr, hcon);
@@ -939,7 +939,7 @@ void a2mp_send_create_phy_link_req(struct hci_dev *hdev, u8 status)
goto clean;
req->local_id = hdev->id;
- req->remote_id = bredr_chan->ctrl_id;
+ req->remote_id = bredr_chan->remote_amp_id;
memcpy(req->amp_assoc, loc_assoc->data, loc_assoc->len);
a2mp_send(mgr, A2MP_CREATEPHYSLINK_REQ, __next_ident(mgr), len, req);
diff --git a/net/bluetooth/amp.c b/net/bluetooth/amp.c
index 650bb8d..4b2fea6 100644
--- a/net/bluetooth/amp.c
+++ b/net/bluetooth/amp.c
@@ -387,7 +387,7 @@ void amp_physical_cfm(struct hci_conn *bredr_hcon, struct hci_conn *hs_hcon)
bredr_chan = mgr->bredr_chan;
set_bit(FLAG_EFS_ENABLE, &bredr_chan->flags);
- bredr_chan->ctrl_id = hs_hcon->remote_id;
+ bredr_chan->remote_amp_id = hs_hcon->remote_id;
bredr_chan->hs_hcon = hs_hcon;
bredr_chan->conn->mtu = hs_hcon->hdev->block_mtu;
bredr_chan->fcs = L2CAP_FCS_NONE;
@@ -412,8 +412,7 @@ void amp_create_logical_link(struct l2cap_chan *chan)
if (!hdev)
return;
- BT_DBG("chan %p ctrl_id %d dst %pMR", chan, chan->ctrl_id,
- chan->conn->dst);
+ BT_DBG("chan %p dst %pMR", chan, chan->conn->dst);
hcon = hci_conn_hash_lookup_ba(hdev, AMP_LINK, chan->conn->dst);
if (!hcon)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 2f0e165..a1faaab 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4615,7 +4615,7 @@ static void l2cap_do_move_cancel(struct l2cap_chan *chan, int result)
void l2cap_physical_cfm(struct l2cap_chan *chan, int result)
{
u8 local_amp_id = chan->local_amp_id;
- u8 remote_amp_id = chan->ctrl_id;
+ u8 remote_amp_id = chan->remote_amp_id;
BT_DBG("chan %p, result %d, local_amp_id %d, remote_amp_id %d",
chan, result, local_amp_id, remote_amp_id);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCHv1 11/12] Bluetooth: AMP: Use l2cap_physical_cfm in phylink complete evt
From: Mat Martineau @ 2012-11-01 17:51 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1351691197-8394-12-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Andrei -
On Wed, 31 Oct 2012, Andrei Emeltchenko wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>
> When receiving HCI Phylink Complete event run amp_physical_cfm
> which initialize BR/EDR L2CAP channel associated with High Speed
> link and run l2cap_physical_cfm which shall send L2CAP Create
> Chan Request.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> include/net/bluetooth/amp.h | 1 +
> include/net/bluetooth/l2cap.h | 1 +
> net/bluetooth/amp.c | 24 ++++++++++++++++++++++++
> net/bluetooth/hci_event.c | 15 ++-------------
> 4 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/include/net/bluetooth/amp.h b/include/net/bluetooth/amp.h
> index f1c0017..7ea3db7 100644
> --- a/include/net/bluetooth/amp.h
> +++ b/include/net/bluetooth/amp.h
> @@ -46,6 +46,7 @@ void amp_accept_phylink(struct hci_dev *hdev, struct amp_mgr *mgr,
> struct hci_conn *hcon);
> void amp_write_remote_assoc(struct hci_dev *hdev, u8 handle);
> void amp_write_rem_assoc_continue(struct hci_dev *hdev, u8 handle);
> +void amp_physical_cfm(struct hci_conn *bredr_hcon, struct hci_conn *hs_hcon);
> void amp_create_logical_link(struct l2cap_chan *chan);
> void amp_disconnect_logical_link(struct hci_chan *hchan);
> void amp_destroy_logical_link(struct hci_chan *hchan, u8 reason);
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index 24c61ef..18149c8 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -812,5 +812,6 @@ void l2cap_send_conn_req(struct l2cap_chan *chan);
> void l2cap_move_start(struct l2cap_chan *chan);
> void l2cap_logical_cfm(struct l2cap_chan *chan, struct hci_chan *hchan,
> u8 status);
> +void l2cap_physical_cfm(struct l2cap_chan *chan, int result);
>
> #endif /* __L2CAP_H */
> diff --git a/net/bluetooth/amp.c b/net/bluetooth/amp.c
> index 917e034..650bb8d 100644
> --- a/net/bluetooth/amp.c
> +++ b/net/bluetooth/amp.c
> @@ -373,6 +373,30 @@ void amp_accept_phylink(struct hci_dev *hdev, struct amp_mgr *mgr,
> hci_send_cmd(hdev, HCI_OP_ACCEPT_PHY_LINK, sizeof(cp), &cp);
> }
>
> +void amp_physical_cfm(struct hci_conn *bredr_hcon, struct hci_conn *hs_hcon)
> +{
> + struct hci_dev *bredr_hdev = hci_dev_hold(bredr_hcon->hdev);
> + struct amp_mgr *mgr = hs_hcon->amp_mgr;
> + struct l2cap_chan *bredr_chan;
> +
> + BT_DBG("bredr_hcon %p hs_hcon %p mgr %p", bredr_hcon, hs_hcon, mgr);
> +
> + if (!bredr_hdev || !mgr || !mgr->bredr_chan)
> + return;
> +
> + bredr_chan = mgr->bredr_chan;
> +
> + set_bit(FLAG_EFS_ENABLE, &bredr_chan->flags);
> + bredr_chan->ctrl_id = hs_hcon->remote_id;
> + bredr_chan->hs_hcon = hs_hcon;
> + bredr_chan->conn->mtu = hs_hcon->hdev->block_mtu;
> + bredr_chan->fcs = L2CAP_FCS_NONE;
Sorry I missed this earlier: bredr_chan needs to be locked before
changing it. I suggest passing the information to l2cap_physical_cfm
and letting that function update the structure members while it holds
the lock.
> +
> + l2cap_physical_cfm(bredr_chan, 0);
> +
> + hci_dev_put(bredr_hdev);
> +}
> +
> void amp_create_logical_link(struct l2cap_chan *chan)
> {
> struct hci_cp_create_accept_logical_link cp;
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 03d51a1..0b37f55 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -3697,20 +3697,9 @@ static void hci_phy_link_complete_evt(struct hci_dev *hdev,
> hci_conn_hold_device(hcon);
> hci_conn_add_sysfs(hcon);
>
> - hci_dev_unlock(hdev);
> -
> - if (hcon->out) {
> - struct hci_dev *bredr_hdev = hci_dev_hold(bredr_hcon->hdev);
> -
> - if (!bredr_hdev)
> - return;
> + amp_physical_cfm(bredr_hcon, hcon);
>
> - /* Placeholder - create chan req
> - l2cap_chan_create_cfm(bredr_hcon, hcon->remote_id);
> - */
> -
> - hci_dev_put(bredr_hdev);
> - }
> + hci_dev_unlock(hdev);
> }
>
> static void hci_loglink_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
> --
> 1.7.9.5
>
>
Regards,
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [RFC v2 obexd 04/11] fuse: Add request helpers and setpath operation
From: Michał Poczwardowski @ 2012-11-01 21:59 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZJorono572HhGqRrxNT2uDvz2PV1n4rdHs0mWJ8CRKqSg@mail.gmail.com>
Hi Luiz,
On 30 October 2012 10:35, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
> Hi Michal,
>
> On Sun, Oct 28, 2012 at 2:29 AM, Michał Poczwardowski
> <dmp0x7c5@gmail.com> wrote:
>> ---
>> fuse/helpers.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 108 insertions(+), 0 deletions(-)
>>
>> diff --git a/fuse/helpers.c b/fuse/helpers.c
>> index 856e1d5..1b8082f 100644
>> --- a/fuse/helpers.c
>> +++ b/fuse/helpers.c
>> @@ -273,3 +273,111 @@ void gobexhlp_disconnect(struct gobexhlp_session* session)
>>
>> g_free(session);
>> }
>> +
>> +void request_new(struct gobexhlp_session *session,
>> + gchar *name)
>> +{
>> + g_print("REQUEST %s\n", name);
>> +
>> + if (session->request != NULL)
>> + g_error("Another request (%s) active!\n",
>> + session->request->name);
>> +
>> + session->status = 0;
>> + session->request = g_malloc0(sizeof(struct gobexhlp_request));
>> + session->request->name = name;
>> +
>> + /*
>> + * suspend/resume operations recreates g_io_add_watch(),
>> + * it fixes obex->io freeze during transfer
>> + */
>> + g_obex_suspend(session->obex);
>> + g_obex_resume(session->obex);
>
> It seems the issue here is that the mainloop is blocked then you have
> to force the io checking by doing g_io_add_watch in a different
> thread, we have dealt with this kind of problem before using
> g_main_context_iteration. I would have been better if fuse supported
> async io, but apparently all operations are blocking.
>
> --
> Luiz Augusto von Dentz
I'll try g_main_context_iteration way to avoid the io freeze.
Unfortunately fuse with obex should use blocking operations.
Thanks,
Michal
^ permalink raw reply
* Re: BLE kernel supported
From: Claudio Takahasi @ 2012-11-01 22:00 UTC (permalink / raw)
To: John Tobias; +Cc: linux-bluetooth, Ganir, Chen
In-Reply-To: <CACUGKYN4uyVKpB6FPBydiFvNXofnwbBrF2w_w=q+x7N3VUv00g@mail.gmail.com>
Hi John:
On Wed, Oct 31, 2012 at 4:41 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hi Marcel,
>
> I am using a pandaboard ES too and the kernel that I am using is 3.4.x
> and I confirmed that it support the BLE.
>
> Regards,
>
> john
You will need a modified firmware to enable BLE. Maybe Chen Ganir can help you.
Regards,
Claudio
^ permalink raw reply
* Re: [RFC v2 obexd 03/11] fuse: Add obexhlp_connect/disconnect functions with helpers
From: Michał Poczwardowski @ 2012-11-01 22:33 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZLoiM=-f3D5mUc_t96P=vbU2i__Cw3eBxskjComBxS27g@mail.gmail.com>
Hi Luiz,
On 30 October 2012 10:08, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
> Hi Michal,
>
> On Sun, Oct 28, 2012 at 2:29 AM, Michał Poczwardowski
> <dmp0x7c5@gmail.com> wrote:
>> ---
>> fuse/helpers.c | 221 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> fuse/helpers.h | 4 +
>> fuse/obexfuse.c | 40 ++++++++++
>> 3 files changed, 265 insertions(+), 0 deletions(-)
>>
>> diff --git a/fuse/helpers.c b/fuse/helpers.c
>> index c36072d..856e1d5 100644
>> --- a/fuse/helpers.c
>> +++ b/fuse/helpers.c
>> @@ -43,6 +43,9 @@
>>
>> #define OBEX_FTP_LS "x-obex/folder-listing"
>>
>> +static GCond *gobexhlp_cond;
>> +static GMutex *gobexhlp_mutex;
>> +
>> struct gobexhlp_request {
>> gchar *name;
>> gboolean complete;
>> @@ -52,3 +55,221 @@ struct gobexhlp_location {
>> gchar *dir;
>> gchar *file;
>> };
>> +
>> +static uint16_t find_rfcomm_uuid(void *user_data)
>> +{
>> + sdp_list_t *pds = (sdp_list_t*) user_data;
>> + uint16_t channel = 0;
>> +
>> + for (;pds;pds = pds->next) {
>> + sdp_data_t *d = (sdp_data_t*)pds->data;
>> + int proto = 0;
>> + for (; d; d = d->next) {
>> + switch(d->dtd) {
>> + case SDP_UUID16:
>> + case SDP_UUID32:
>> + case SDP_UUID128:
>> + proto = sdp_uuid_to_proto(&d->val.uuid);
>> + break;
>> + case SDP_UINT8:
>> + if (proto == RFCOMM_UUID)
>> + channel = d->val.int8;
>> + break;
>> + }
>> + }
>> + }
>> + return channel;
>> +}
>> +
>> +static uint16_t get_ftp_channel(bdaddr_t *src, bdaddr_t *dst)
>> +{
>> + sdp_session_t *sdp;
>> + sdp_list_t *r, *search_list, *attrid_list;
>> + sdp_list_t *response_list = NULL;
>> + uuid_t uuid;
>> +
>> + /* FTP_SDP_UUID "00001106-0000-1000-8000-00805f9b34fb" */
>> + uint8_t uuid_int[] = {0, 0, 0x11, 0x06, 0, 0, 0x10, 0, 0x80,
>> + 0, 0, 0x80, 0x5f, 0x9b, 0x34, 0xfb};
>> + uint32_t range = 0x0000ffff;
>> + uint16_t channel = 0;
>> +
>> + sdp = sdp_connect(src, dst, SDP_RETRY_IF_BUSY );
>> + if (sdp == NULL)
>> + return channel;
>> +
>> + sdp_uuid128_create(&uuid, uuid_int);
>> + search_list = sdp_list_append(NULL, &uuid);
>> + attrid_list = sdp_list_append(NULL, &range);
>> + sdp_service_search_attr_req(sdp, search_list, SDP_ATTR_REQ_RANGE,
>> + attrid_list, &response_list);
>> + r = response_list;
>> +
>> + for (; r;r = r->next) {
>> + sdp_record_t *rec = (sdp_record_t*) r->data;
>> + sdp_list_t *proto_list;
>> +
>> + if (sdp_get_access_protos(rec, &proto_list ) == 0) {
>> + sdp_list_t *p = proto_list;
>> + for (; p; p = p->next) {
>> + sdp_list_t *pds = (sdp_list_t*) p->data;
>> + channel = find_rfcomm_uuid(pds);
>> + sdp_list_free((sdp_list_t*) p->data, 0);
>
> You dont really need to iterate in the list of protos there exist a
> function that does that for you take a look at sdp_get_proto_port, btw
> there exist a similar code in client/bluetooth.c
>
I didn't notice sdp_get_proto_port when I was reading client/bluetooth.c code :)
>> + }
>> + sdp_list_free(proto_list, 0);
>> + }
>> + sdp_record_free(rec);
>> + }
>> + sdp_close(sdp);
>> +
>> + g_free(search_list);
>> + g_free(attrid_list);
>> + g_free(response_list);
>> +
>> + return channel;
>> +}
>> +
>> +/* taken from client/bluetooth.c - bluetooth_getpacketopt */
>> +static int get_packet_opt(GIOChannel *io, int *tx_mtu, int *rx_mtu)
>> +{
>> + int sk = g_io_channel_unix_get_fd(io);
>> + int type;
>> + int omtu = -1;
>> + int imtu = -1;
>> + socklen_t len = sizeof(int);
>> +
>> + if (getsockopt(sk, SOL_SOCKET, SO_TYPE, &type, &len) < 0)
>> + return -errno;
>> +
>> + if (type != SOCK_SEQPACKET)
>> + return -EINVAL;
>> +
>> + if (!bt_io_get(io, BT_IO_L2CAP, NULL, BT_IO_OPT_OMTU, &omtu,
>> + BT_IO_OPT_IMTU, &imtu,
>> + BT_IO_OPT_INVALID))
>> + return -EINVAL;
>> +
>> + if (tx_mtu)
>> + *tx_mtu = omtu;
>> +
>> + if (rx_mtu)
>> + *rx_mtu = imtu;
>> +
>> + return 0;
>> +}
>> +
>> +static void obex_callback(GObex *obex, GError *err, GObexPacket *rsp,
>> + gpointer user_data)
>> +{
>> + if (err != NULL) {
>> + g_debug("Connect failed: %s\n", err->message);
>> + g_error_free(err);
>> + } else {
>> + g_debug("Connect succeeded\n");
>> + }
>> +}
>> +
>> +static void bt_io_callback(GIOChannel *io, GError *err, gpointer user_data)
>> +{
>> + struct gobexhlp_session *session = user_data;
>> + GObexTransportType type;
>> + int tx_mtu = -1;
>> + int rx_mtu = -1;
>> +
>> + if (err != NULL) {
>> + g_printerr("%s\n", err->message);
>> + g_error_free(err);
>> + return;
>> + }
>> +
>> + g_debug("Bluetooth socket connected\n");
>> +
>> + g_io_channel_set_flags(session->io, G_IO_FLAG_NONBLOCK, NULL);
>> + g_io_channel_set_close_on_unref(session->io, TRUE);
>> +
>> + if (get_packet_opt(session->io, &tx_mtu, &rx_mtu) == 0) {
>> + type = G_OBEX_TRANSPORT_PACKET;
>> + g_debug("PACKET transport tx:%d rx:%d\n", tx_mtu, rx_mtu);
>> + } else {
>> + type = G_OBEX_TRANSPORT_STREAM;
>> + g_debug("STREAM transport\n");
>> + }
>> +
>> + session->obex = g_obex_new(io, type, tx_mtu, rx_mtu);
>> + g_obex_connect(session->obex, obex_callback, session, NULL,
>> + G_OBEX_HDR_TARGET, OBEX_FTP_UUID,
>> + OBEX_FTP_UUID_LEN, G_OBEX_HDR_INVALID);
>> +}
>> +
>> +struct gobexhlp_session* gobexhlp_connect(const char *srcstr,
>> + const char *dststr)
>> +{
>> + struct gobexhlp_session *session;
>> + uint16_t channel;
>> + bdaddr_t src, dst;
>> +
>> + session = g_try_malloc0(sizeof(struct gobexhlp_session));
>> + if (session == NULL)
>> + return NULL;
>> +
>> + if (srcstr == NULL)
>> + bacpy(&src, BDADDR_ANY);
>> + else
>> + str2ba(srcstr, &src);
>> +
>> + str2ba(dststr, &dst);
>> + channel = get_ftp_channel(&src, &dst);
>> +
>> + if (channel == 0)
>> + return NULL;
>
> Currently you are not checking for L2CAP psm just RFCOMM channel so
> the code bellow would never be used.
>
In client/bluetooth.c these lines (in search_callback):
data = sdp_data_get(rec, 0x0200);
/* PSM must be odd and lsb of upper byte must be 0 */
if (data != NULL && (data->val.uint16 & 0x0101) == 0x0001)
ch = data->val.uint16;
Are responsible for L2CAP psm, right?
>> + if (channel > 31)
>> + session->io = bt_io_connect(BT_IO_L2CAP, bt_io_callback,
>> + session, NULL, &session->err,
>> + BT_IO_OPT_SOURCE_BDADDR, &src,
>> + BT_IO_OPT_DEST_BDADDR, &dst,
>> + BT_IO_OPT_PSM, channel,
>> + BT_IO_OPT_MODE, BT_IO_MODE_ERTM,
>> + BT_IO_OPT_OMTU, BT_TX_MTU,
>> + BT_IO_OPT_IMTU, BT_RX_MTU,
>> + BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_LOW,
>> + BT_IO_OPT_INVALID);
>> + else
>> + session->io = bt_io_connect(BT_IO_RFCOMM, bt_io_callback,
>> + session, NULL, &session->err,
>> + BT_IO_OPT_SOURCE_BDADDR, &src,
>> + BT_IO_OPT_DEST_BDADDR, &dst,
>> + BT_IO_OPT_CHANNEL, channel,
>> + BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_LOW,
>> + BT_IO_OPT_INVALID);
>> +
>> + if (session->err != NULL)
>> + return NULL;
>> +
>> + session->file_stat = g_hash_table_new_full( g_str_hash, g_str_equal,
>> + g_free, g_free);
>> + session->setpath = g_strdup("/");
>> +
>> + gobexhlp_mutex = g_mutex_new();
>> + gobexhlp_cond = g_cond_new();
>> +
>> + return session;
>> +}
>> +
>> +void gobexhlp_disconnect(struct gobexhlp_session* session)
>> +{
>> + if (session == NULL)
>> + return;
>> +
>> + g_obex_unref(session->obex);
>> + g_free(session->io);
>> +
>> + g_hash_table_remove_all(session->file_stat);
>> + g_list_free_full(session->lsfiles, g_free);
>> + g_free(session->setpath);
>> +
>> + g_mutex_free(gobexhlp_mutex);
>> + g_cond_free(gobexhlp_cond);
>> +
>> + g_free(session);
>> +}
>> diff --git a/fuse/helpers.h b/fuse/helpers.h
>> index 142403f..29dc6cf 100644
>> --- a/fuse/helpers.h
>> +++ b/fuse/helpers.h
>> @@ -46,3 +46,7 @@ struct gobexhlp_session {
>> int status;
>> GError *err;
>> };
>> +
>> +struct gobexhlp_session* gobexhlp_connect(const char *srcstr,
>> + const char *dstsrc);
>> +void gobexhlp_disconnect(struct gobexhlp_session* session);
>> diff --git a/fuse/obexfuse.c b/fuse/obexfuse.c
>> index fe4f4da..79eb990 100644
>> --- a/fuse/obexfuse.c
>> +++ b/fuse/obexfuse.c
>> @@ -33,6 +33,10 @@
>>
>> #include "helpers.h"
>>
>> +struct gobexhlp_session* session = NULL;
>> +static GMainLoop *main_loop;
>> +static GThread *main_gthread;
>> +
>> struct options {
>> char* dststr;
>> char* srcstr;
>> @@ -60,7 +64,34 @@ static struct fuse_opt obexfuse_opts[] =
>> FUSE_OPT_END
>> };
>>
>> +gpointer main_loop_func(gpointer user_data)
>> +{
>> + main_loop = g_main_loop_new(NULL, FALSE);
>> + g_main_loop_run(main_loop);
>> +
>> + return 0;
>> +}
>> +
>> +void* obexfuse_init(struct fuse_conn_info *conn)
>> +{
>> + main_gthread = g_thread_create(main_loop_func, NULL, TRUE, NULL);
>> +
>> + conn->async_read = 0;
>> + conn->want &= ~FUSE_CAP_ASYNC_READ;
>> +
>> + return 0;
>> +}
>> +
>> +void obexfuse_destroy()
>> +{
>> + gobexhlp_disconnect(session);
>> + g_main_loop_quit(main_loop);
>> + g_thread_join(main_gthread);
>> +}
>> +
>> static struct fuse_operations obexfuse_oper = {
>> + .init = obexfuse_init,
>> + .destroy = obexfuse_destroy,
>> };
>>
>> static int obexfuse_opt_proc(void *data, const char *arg, int key,
>> @@ -111,6 +142,15 @@ int main(int argc, char *argv[])
>>
>> g_thread_init(NULL);
>>
>
> I would suggest not mixing gobex prefix with your helper functions, in
> fact it is probably fine to just use obexfuse e.g. obexfuse_connect.
>
Right, when I was removing 'g' from gobexfuse I forgot to change
gobexhlp to obexhlp.
I'll send RFC v3 after LinuxCon :)
>> + session = gobexhlp_connect(options.srcstr, options.dststr);
>> + if (session == NULL || session->io == NULL) {
>> + g_printerr("Connection to %s failed\n", options.dststr);
>> + gobexhlp_disconnect(session);
>> + return -EHOSTUNREACH;
>> + } else {
>> + g_print("Connected\nMounting %s\n", options.dststr);
>> + }
>> +
>> fuse_opt_add_arg(&args, "-s"); /* force single threaded mode */
>> retfuse = fuse_main(args.argc, args.argv, &obexfuse_oper, NULL);
>>
>> --
>> 1.7.8.6
>>
>> --
>> 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
>
>
>
> --
> Luiz Augusto von Dentz
Thanks,
Michal
^ permalink raw reply
* pull request: bluetooth-next 2012-11-01
From: Gustavo Padovan @ 2012-11-01 22:37 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 5320 bytes --]
Hi John,
Another set of patches for integration in wireless-next. There are two big set
of changes in it: Andrei Emeltchenko and Mat Martineau added more patches
towards a full Bluetooth High Speed support and Johan Hedberg improve the
single mode support for Bluetooth dongles. Apart from that we have small fixes
and improvements.
Please pull. Thanks a lot.
Gustavo
---
The following changes since commit 9917c85b06c2eb9d61c0f2dadd2d5d8788f7e563:
brcm80211: remove some truely barftastic code (2012-10-19 16:20:56 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next for-upstream
for you to fetch changes up to 0c0afedf55ff409be9db0b0aeeaa1c6fe0f3cd3c:
Bluetooth: Fix parameter order of hci_get_route (2012-11-01 20:27:11 -0200)
----------------------------------------------------------------
Andrei Emeltchenko (18):
Bluetooth: trivial: Remove unneeded assignment
Bluetooth: Use helper function sending EFS conf rsp
Bluetooth: AMP: Process Physical Link Complete evt
Bluetooth: AMP: Process Logical Link complete evt
Bluetooth: Add put(hcon) when deleting hchan
Bluetooth: trivial: Fix braces style and remove empty line
Bluetooth: Save hs_hchan instead of hs_hcon in loglink complete
Bluetooth: Return correct L2CAP response type
Bluetooth: Derive remote and local amp id from chan struct
Bluetooth: AMP: Add Logical Link Create function
Bluetooth: AMP: Process Disc Logical Link
Bluetooth: AMP: Process Disc Physical Link Complete evt
Bluetooth: AMP: Remove hci_conn receiving error command status
Bluetooth: Disconnect logical link when deleting chan
Bluetooth: AMP: Check for hs_hcon instead of ctrl_id
Bluetooth: AMP: Use l2cap_physical_cfm in phylink complete evt
Bluetooth: Process Create Chan Request
Bluetooth: Rename ctrl_id to remote_amp_id
Denis Kirjanov (1):
Bluetooth:Replace list_for_each with list_for_each_entry() helper
Gustavo Padovan (1):
Bluetooth: Replace *_init() for *_setup()
Johan Hedberg (16):
Bluetooth: Add initial support for LE-only controllers
Bluetooth: Fix LE MTU reporting for HCIGETDEVINFO
Bluetooth: Add setting of the LE event mask
Bluetooth: Read adversiting channel TX power during init sequence
Bluetooth: Fix HCI command sending when powering on LE-only adapters
Bluetooth: mgmt: Restrict BR/EDR settings to BR/EDR-only adapters
Bluetooth: Fix updating host feature bits for LE
Bluetooth: Add missing feature test macros
Bluetooth: Make use feature test macros
Bluetooth: Add flag for LE GAP Peripheral role
Bluetooth: Disallow LE scanning and connecting in peripheral role
Bluetooth: Fix setting host feature bits for SSP
Bluetooth: Fix sending unnecessary HCI_Write_SSP_Mode command
Bluetooth: Fix unnecessary EIR update during powering on
Bluetooth: Fix sending unnecessary HCI_LE_Host_Enable
Bluetooth: Fix parameter order of hci_get_route
Mat Martineau (18):
Bluetooth: Add new l2cap_chan struct members for high speed channels
Bluetooth: Add L2CAP create channel request handling
Bluetooth: Remove unnecessary intermediate function
Bluetooth: Lookup channel structure based on DCID
Bluetooth: Channel move request handling
Bluetooth: Add new ERTM receive states for channel move
Bluetooth: Add move channel confirm handling
Bluetooth: Add state to hci_chan
Bluetooth: Move channel response
Bluetooth: Add logical link confirm
Bluetooth: Add move confirm response handling
Bluetooth: Handle physical link completion
Bluetooth: Flag ACL frames as complete for AMP controllers
Bluetooth: Do not send data during channel move
Bluetooth: Configure appropriate timeouts for AMP controllers
Bluetooth: Ignore BR/EDR packet size constraints when fragmenting for AMP
Bluetooth: Do not retransmit data during a channel move
Bluetooth: Start channel move when socket option is changed
Syam Sidhardhan (4):
Bluetooth: trivial: Remove newline before EOF
Bluetooth: Replace include linux/module.h with linux/export.h
Bluetooth: Remove unnecessary include export.h
Bluetooth: mgmt: Use __constant when dealing with constants
include/net/bluetooth/amp.h | 4 +
include/net/bluetooth/hci.h | 7 +
include/net/bluetooth/hci_core.h | 44 +-
include/net/bluetooth/l2cap.h | 38 +-
net/bluetooth/Kconfig | 1 -
net/bluetooth/a2mp.c | 4 +-
net/bluetooth/amp.c | 93 ++++
net/bluetooth/bnep/netdev.c | 1 -
net/bluetooth/cmtp/capi.c | 2 +-
net/bluetooth/cmtp/sock.c | 2 +-
net/bluetooth/hci_conn.c | 6 +
net/bluetooth/hci_core.c | 65 +--
net/bluetooth/hci_event.c | 309 +++++++++++--
net/bluetooth/l2cap_core.c | 1000 +++++++++++++++++++++++++++++++++++++---
net/bluetooth/l2cap_sock.c | 5 +
net/bluetooth/mgmt.c | 98 ++--
16 files changed, 1486 insertions(+), 193 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ath3k: Add support for VAIO VPCEH [0489:e027]
From: Marcos Chaparro @ 2012-11-01 22:40 UTC (permalink / raw)
To: Gustavo Padovan
Cc: Marcel Holtmann, Johan Hedberg, linux-bluetooth, linux-kernel
In-Reply-To: <20121031182532.GD1679@joana>
Added Atheros AR3011 internal bluetooth device found in Sony VAIO VPCEH to the
devices list.
Before this, the bluetooth module was identified as an Foxconn / Hai bluetooth
device [0489:e027], now it claims to be an AtherosAR3011 Bluetooth
[0cf3:3005].
# cat /sys/kernel/debug/usb/devices
T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 11 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=3005 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off by: Marcos A Chaparro <marcos@mrkindustries.com.ar>
---
Thanks Gustavo for pointing me out to the SubmittingPatches help file. Please
let me know if the patch is actually merged to the mainstream.
diff --git a/linux-3.7-rc3.orig/drivers/bluetooth/ath3k.c b/linux-3.7-
rc3.new/drivers/bluetooth/ath3k.c
index fc2de55..b00000e 100644
--- a/linux-3.7-rc3.orig/drivers/bluetooth/ath3k.c
+++ b/linux-3.7-rc3.new/drivers/bluetooth/ath3k.c
@@ -67,6 +67,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x13d3, 0x3304) },
{ USB_DEVICE(0x0930, 0x0215) },
{ USB_DEVICE(0x0489, 0xE03D) },
+ { USB_DEVICE(0x0489, 0xE027) },
/* Atheros AR9285 Malbec with sflash firmware */
{ USB_DEVICE(0x03F0, 0x311D) },
diff --git a/linux-3.7-rc3.orig/drivers/bluetooth/btusb.c b/linux-3.7-
rc3.new/drivers/bluetooth/btusb.c
index debda27..ee82f2f 100644
--- a/linux-3.7-rc3.orig/drivers/bluetooth/btusb.c
+++ b/linux-3.7-rc3.new/drivers/bluetooth/btusb.c
@@ -124,6 +124,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3304), .driver_info = BTUSB_IGNORE },
{ USB_DEVICE(0x0930, 0x0215), .driver_info = BTUSB_IGNORE },
{ USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE },
+ { USB_DEVICE(0x0489, 0xe027), .driver_info = BTUSB_IGNORE },
/* Atheros AR9285 Malbec with sflash firmware */
{ USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
--
Marcos
^ permalink raw reply related
* Re: [PATCH] ath3k: Add support for VAIO VPCEH [0489:e027]
From: Gustavo Padovan @ 2012-11-01 22:53 UTC (permalink / raw)
To: Marcos Chaparro
Cc: Marcel Holtmann, Johan Hedberg, linux-bluetooth, linux-kernel
In-Reply-To: <201211011940.45569.marcos@mrkindustries.com.ar>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
Hi Marcos,
* Marcos Chaparro <marcos@mrkindustries.com.ar> [2012-11-01 19:40:45 -0300]:
> Added Atheros AR3011 internal bluetooth device found in Sony VAIO VPCEH to the
> devices list.
> Before this, the bluetooth module was identified as an Foxconn / Hai bluetooth
> device [0489:e027], now it claims to be an AtherosAR3011 Bluetooth
> [0cf3:3005].
>
> # cat /sys/kernel/debug/usb/devices
> T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 11 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0cf3 ProdID=3005 Rev= 0.01
I actually need the output without the patch in, showing the 0x0489 vendor id.
Sorry, but we like to document the devices we add support properly.
Gustavo
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ath3k: Add support for VAIO VPCEH [0489:e027]
From: Marcos Chaparro @ 2012-11-01 23:19 UTC (permalink / raw)
To: Gustavo Padovan
Cc: Marcel Holtmann, Johan Hedberg, linux-bluetooth, linux-kernel
In-Reply-To: <20121101225331.GB1915@joana>
On Thursday, November 01, 2012 19:53:31 Gustavo Padovan wrote:
> > # cat /sys/kernel/debug/usb/devices
> > T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 11 Spd=12 MxCh= 0
> > D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> > P: Vendor=0cf3 ProdID=3005 Rev= 0.01
>
> I actually need the output without the patch in, showing the 0x0489 vendor
> id. Sorry, but we like to document the devices we add support properly.
I rebooted with an old (3.2.0-3-amd64) kernel and I still have the correct ID
0cf3:3005, I can't see the old usb ID.
I tried reloading all the bluetooth related modules but it still gets
identified as an 0cf3:3005.
Do you know how can I delete the device firmware to revert it to the original
state?
Apparently its keeping the firmware from my patched kernel.
root@bluestreak:/home/marcos# lsusb
Bus 001 Device 004: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
Best regards
--
Marcos
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Process Create Chan Request
From: Marcel Holtmann @ 2012-11-02 0:30 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1351777023-10018-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> Add processing L2CAP Create Chan Request. When channel is created
> save associated high speed link hs_hcon.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 63 ++++++++++++++++++++++++++++++--------------
> 1 file changed, 43 insertions(+), 20 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Rename ctrl_id to remote_amp_id
From: Marcel Holtmann @ 2012-11-02 0:31 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1351777023-10018-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> Since we have started to use local_amp_id for local AMP
> Controller Id it makes sense to rename ctrl_id to remote_amp_id
> since it represents remote AMP controller Id.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> include/net/bluetooth/l2cap.h | 3 +--
> net/bluetooth/a2mp.c | 4 ++--
> net/bluetooth/amp.c | 5 ++---
> net/bluetooth/l2cap_core.c | 2 +-
> 4 files changed, 6 insertions(+), 8 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix parameter order of hci_get_route
From: Marcel Holtmann @ 2012-11-02 0:32 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1351769246-28854-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> The actual parameter order of hci_get_route is (dst, src) and not (src,
> dst). All current callers use the right order but the header file shows
> the parameters in the wrong order.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> include/net/bluetooth/hci_core.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I trust you that you triple checked this.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] ath3k: Add support for VAIO VPCEH [0489:e027]
From: Marcos Chaparro @ 2012-11-02 0:38 UTC (permalink / raw)
To: Gustavo Padovan
Cc: Marcel Holtmann, Johan Hedberg, linux-bluetooth, linux-kernel
Added Atheros AR3011 internal bluetooth device found in Sony VAIO VPCEH to the
devices list.
Before this, the bluetooth module was identified as an Foxconn / Hai bluetooth
device [0489:e027], now it claims to be an AtherosAR3011 Bluetooth
[0cf3:3005].
# cat /sys/kernel/debug/usb/devices
T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e027 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off by: Marcos A Chaparro <marcos@mrkindustries.com.ar>
---
Updated usb /sys/kernel/debug/usb/devices output. A complete powercycle flushed
the device firmware.
diff --git a/linux-3.7-rc3.orig/drivers/bluetooth/ath3k.c b/linux-3.7-
rc3.new/drivers/bluetooth/ath3k.c
index fc2de55..b00000e 100644
--- a/linux-3.7-rc3.orig/drivers/bluetooth/ath3k.c
+++ b/linux-3.7-rc3.new/drivers/bluetooth/ath3k.c
@@ -67,6 +67,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x13d3, 0x3304) },
{ USB_DEVICE(0x0930, 0x0215) },
{ USB_DEVICE(0x0489, 0xE03D) },
+ { USB_DEVICE(0x0489, 0xE027) },
/* Atheros AR9285 Malbec with sflash firmware */
{ USB_DEVICE(0x03F0, 0x311D) },
diff --git a/linux-3.7-rc3.orig/drivers/bluetooth/btusb.c b/linux-3.7-
rc3.new/drivers/bluetooth/btusb.c
index debda27..ee82f2f 100644
--- a/linux-3.7-rc3.orig/drivers/bluetooth/btusb.c
+++ b/linux-3.7-rc3.new/drivers/bluetooth/btusb.c
@@ -124,6 +124,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3304), .driver_info = BTUSB_IGNORE },
{ USB_DEVICE(0x0930, 0x0215), .driver_info = BTUSB_IGNORE },
{ USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE },
+ { USB_DEVICE(0x0489, 0xe027), .driver_info = BTUSB_IGNORE },
/* Atheros AR9285 Malbec with sflash firmware */
{ USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
--
Marcos
^ permalink raw reply related
* Re: [PATCHv1 11/12] Bluetooth: AMP: Use l2cap_physical_cfm in phylink complete evt
From: Andrei Emeltchenko @ 2012-11-02 7:48 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth
In-Reply-To: <alpine.DEB.2.02.1211011045260.9973@mathewm-linux>
Hi Mat,
On Thu, Nov 01, 2012 at 10:51:19AM -0700, Mat Martineau wrote:
>
> Andrei -
>
> On Wed, 31 Oct 2012, Andrei Emeltchenko wrote:
>
> >From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >
> >When receiving HCI Phylink Complete event run amp_physical_cfm
> >which initialize BR/EDR L2CAP channel associated with High Speed
> >link and run l2cap_physical_cfm which shall send L2CAP Create
> >Chan Request.
> >
> >Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >Acked-by: Marcel Holtmann <marcel@holtmann.org>
> >---
> >include/net/bluetooth/amp.h | 1 +
> >include/net/bluetooth/l2cap.h | 1 +
> >net/bluetooth/amp.c | 24 ++++++++++++++++++++++++
> >net/bluetooth/hci_event.c | 15 ++-------------
> >4 files changed, 28 insertions(+), 13 deletions(-)
> >
> >diff --git a/include/net/bluetooth/amp.h b/include/net/bluetooth/amp.h
> >index f1c0017..7ea3db7 100644
> >--- a/include/net/bluetooth/amp.h
> >+++ b/include/net/bluetooth/amp.h
> >@@ -46,6 +46,7 @@ void amp_accept_phylink(struct hci_dev *hdev, struct amp_mgr *mgr,
> > struct hci_conn *hcon);
> >void amp_write_remote_assoc(struct hci_dev *hdev, u8 handle);
> >void amp_write_rem_assoc_continue(struct hci_dev *hdev, u8 handle);
> >+void amp_physical_cfm(struct hci_conn *bredr_hcon, struct hci_conn *hs_hcon);
> >void amp_create_logical_link(struct l2cap_chan *chan);
> >void amp_disconnect_logical_link(struct hci_chan *hchan);
> >void amp_destroy_logical_link(struct hci_chan *hchan, u8 reason);
> >diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> >index 24c61ef..18149c8 100644
> >--- a/include/net/bluetooth/l2cap.h
> >+++ b/include/net/bluetooth/l2cap.h
> >@@ -812,5 +812,6 @@ void l2cap_send_conn_req(struct l2cap_chan *chan);
> >void l2cap_move_start(struct l2cap_chan *chan);
> >void l2cap_logical_cfm(struct l2cap_chan *chan, struct hci_chan *hchan,
> > u8 status);
> >+void l2cap_physical_cfm(struct l2cap_chan *chan, int result);
> >
> >#endif /* __L2CAP_H */
> >diff --git a/net/bluetooth/amp.c b/net/bluetooth/amp.c
> >index 917e034..650bb8d 100644
> >--- a/net/bluetooth/amp.c
> >+++ b/net/bluetooth/amp.c
> >@@ -373,6 +373,30 @@ void amp_accept_phylink(struct hci_dev *hdev, struct amp_mgr *mgr,
> > hci_send_cmd(hdev, HCI_OP_ACCEPT_PHY_LINK, sizeof(cp), &cp);
> >}
> >
> >+void amp_physical_cfm(struct hci_conn *bredr_hcon, struct hci_conn *hs_hcon)
> >+{
> >+ struct hci_dev *bredr_hdev = hci_dev_hold(bredr_hcon->hdev);
> >+ struct amp_mgr *mgr = hs_hcon->amp_mgr;
> >+ struct l2cap_chan *bredr_chan;
> >+
> >+ BT_DBG("bredr_hcon %p hs_hcon %p mgr %p", bredr_hcon, hs_hcon, mgr);
> >+
> >+ if (!bredr_hdev || !mgr || !mgr->bredr_chan)
> >+ return;
> >+
> >+ bredr_chan = mgr->bredr_chan;
> >+
> >+ set_bit(FLAG_EFS_ENABLE, &bredr_chan->flags);
> >+ bredr_chan->ctrl_id = hs_hcon->remote_id;
> >+ bredr_chan->hs_hcon = hs_hcon;
> >+ bredr_chan->conn->mtu = hs_hcon->hdev->block_mtu;
> >+ bredr_chan->fcs = L2CAP_FCS_NONE;
>
> Sorry I missed this earlier: bredr_chan needs to be locked before
> changing it. I suggest passing the information to
> l2cap_physical_cfm and letting that function update the structure
> members while it holds the lock.
what about locking here and changing l2cap_physical_cfm to unlocked
__l2cap_physical_cfm ?
>
>
> >+
> >+ l2cap_physical_cfm(bredr_chan, 0);
> >+
> >+ hci_dev_put(bredr_hdev);
> >+}
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Bluez/Obexd upstream test result_20121102(bluez-4.101.767+ obexd-0.47.67)
From: Li, XiaX @ 2012-11-02 9:38 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
Hi all,
QA finished upstream testing. The test is for bluez-4.101.767 and obexd-0.47.67. Against last, BlueZ is changed from 4.101.681 to 4.101.767, Obexd is changed from 0.47.66 to 0.47.67.
In this test, totally ran 100 case: 72 Pass, 10 Fail. Other 18 are blocked or unavailable (some cases validation method is still in investigating). The pass rate is 88% (pass / <pass + fail>). Ofono has not caught up with the BlueZ API changing in HFP profile.
New bugs:
===============================================
No
Re-open bugs:
===============================================
No
Verified bugs:
===============================================
No
Testing Environment
==============================================
Hardware: netbook Eeepc 1005HA | Acer AspireOne NAV50
Image: netbook-ia32-pinetrail-tizen_20120424.2
Linux Kernel: v3.4-rc7
bluez-4.101.767.g862e89c-1.1.i586
obexd-0.47.67.g01636c0-2.1.i586
obexd-server-0.47.67.g01636c0-2.1.i586
connman-1.8.48.gde9e458-1.1.i586
ofono-1.11.160.gd28d473-1.1.i586
Pulseaudio: 67602d8743e8e529919bb9fbb956aa77724a8e50 (oct, 6th)
For detailed test results, please see attached file.
Thanks
Li Xia
[-- Attachment #2: Bluetooth_upstream_quality_20121102.txt --]
[-- Type: text/plain, Size: 7550 bytes --]
== Detail Result ==
[PASS]: case passed <br>
[FAIL]: case failed <br>
[Block]: case is blocked by one bug <br>
[N/A]: case not available to be tested
=== Audio-A2DP ===
[PASS] A2DP_001: audio sink connect/re-connect
[PASS] A2DP_002: stereo headset playback
[PASS] A2DP_003: stereo headset voice record
[PASS] A2DP_004: Codec support: SBC
[PASS] A2DP_005: Playback music on line
[PASS] A2DP_006: SINK role, as speaker for other device music playing
With some BT headset, we ever met issue [https://bugs.meego.com/show_bug.cgi?id=25480 Bug#25480 A2DP-source: pulseaudio fails to create bluez_sink and bluez_source]
=== Audio-AVRCP ===
[PASS] AVRCP_001: Volume Up/Down
[Block] AVRCP_002: Play/Pause (by unavailable media-player)
[Block] AVRCP_003: Next/Privious (by unavailable media-player)
[PASS] AVRCP_004: Connection Establish/Release
[N/A] AVRCP_005: Audio metadata get.
We still try to find avaliable media-player to support AVRCP-1.4
=== Audio-HFP ===
Ofono needs to update its API, since BlueZ already took the changes. Here is bug [https://bugs.meego.com/show_bug.cgi?id=25748 Bug#25748 HFP: Ofono List-modems shows no modem after paired with phone]
[FAIL] HFP_001: RFCOMM connection on AG
Need install sbc for latest pulseaudio
[FAIL] HFP_002: list (ofono) hfp modem
[FAIL] HFP_003: HFP modem establishment (Ofono)
[FAIL] HFP_004: Audio SNK and SRC establishment
[FAIL] HFP_005: voicecall, audio creates BT SNK/SRC
[FAIL] HFP_006: redirect AG SNK/SRC to local SRC/SNK
BlueZ interface has some regression, bug is reported as [https://bugs.meego.com/show_bug.cgi?id=25473 Bug#25473 HFP: latest bluez cannot support pulseaudio to create bluez_sink and bluez_source]
Pulseaudio has new crash bug: [https://bugs.meego.com/show_bug.cgi?id=25593 Bug#25593 Pulseaudio crashes after connect BT sink to alsa source]
[FAIL] HFP_007: Check AT-commands from HF part
[FAIL] HFP_008: Connect BT Headset to HFP phone
=== Audio-HSP ===
[PASS] HSP_001: Use mono headset to play music
*** DUT is a Netbook, unable to take phone ***
[N/A] HSP_002: Take incoming call by button-press
[N/A] HSP_003: Audio transfer between AG and HS
[PASS] HSP_004: Adjust Volume Up/Down
=== OBEX-FTP ===
[PASS] FTP_001: pull/push files from/to server.
[PASS] FTP_002: browse server files
[PASS] FTP_003: Client "delete file", "rename file"
[PASS] FTP_004: Server enables FTP parameter
[PASS] FTP_005: Server sets sharing root path
[PASS] FTP_006: Server handles all requirements
[PASS] FTP_007: Server has ability to set permission for FTP
[PASS] FTP_008: FTP data-rate about 30k/s~230k/s
[PASS] FTP_009: Big size file transferred stable
=== OBEX-OPP ===
[PASS] OPP_001: pull un-patterned object from server.
[PASS] OPP_002: Server enables OPP parameter
[PASS] OPP_003: During object transferring, the progress is clear
=== OBEX-PBAP ===
[PASS] PBAP_001: Client gets phone book entries from server
[PASS] PBAP_002: Client gets ICH, OCH, MCH and CCH from server
[FAIL] PBAP_003: PSE can provide PBAP daemon by enabling corresponding parameter
Case failed due to [https://bugs.meego.com/show_bug.cgi?id=25598 Bug#25598, PBAP server fails to open /telecom/pb.vcf file]
[PASS] PBAP_004: Both sides support vCard2.1/vCard3.0
=== OBEX-SYNC ===
[PASS] SYNC_001: Server enables SYNC daemon
[PASS] SYNC_002: During sync, Server can show "syncing..."
[PASS] SYNC_003: client can set PIM fetching from INT
[PASS] SYNC_004: Server get/put entire phonebook from/to client.
[PASS] SYNC_005: Client can support vCard2.1, vCard3.0
=== OBEX-MAP MCE ===
[FAIL] MAP_001: MCE can browse message/folder list on MSE
Regression happened on client side, bug is reported as [https://bugs.meego.com/show_bug.cgi?id=25595 Bug#25595 MAP client fail to get message list from Samsung GT-i9100]
[BLOCK] MAP_002: MCE can upload local message to MSE
[BLOCK] MAP_003: MCE can delete the message on MSE side
[BLOCK] MAP_004: MCE can take use of MSE to send message
=== Network-PAN ===
[PASS] PAN_001: PANU can init nap0 device connect to NAP
[PASS] PAN_002: PANU can get ip address or assigned static ip
[PASS] PAN_003: PANU can logon internet website
[N/A] PAN_004: NAP can init bridge bnep
[N/A] PAN_005: NAP can support one or multiple PANU connection
[N/A] PAN_006: NAP can have DHCP responding to each PANU
Current connman does not support DHCP functions.
=== Network-BNEP ===
[PASS] BNEP_001: Check BNEP support on DUT
=== Network-DUN ===
[PASS] DUN_001: GW (DUT) can parse a series of AT commands from the data terminal.
[PASS] DUN_002: DT can build up rfcomm device by bluetooth and DUN modem by Ofono.
[PASS] DUN_003: DT can use Ofono to dial up special service number ("*99#").
[PASS] DUN_004: When network connected, DT can log on website in internet.
=== SIM-SAP ===
The SAP test method is still in investigation.
[N/A] SAP_001: Server can enable a module to register Client
[N/A] SAP_002: Server can power on/off SIM Card or reset it
[N/A] SAP_003: Server can disconnect Client
[N/A] SAP_004: Server can disconnect SIM
[N/A] SAP_005: Client can connect to Server SIM
[N/A] SAP_006: Client can power on Server SIM
[N/A] SAP_007: Client can disconnect Server
=== Generic-GAP ===
[PASS] GAP_001: PSCAN/ISCAN mode setting.
[PASS] GAP_002: Active pairing to another bluetooth device.
[PASS] GAP_003: Passive pairing, accepte pair master requirement
[PASS] GAP_004: SSP supports
[PASS] GAP_005: If lost link-key, it needs re-pair
[PASS] GAP_006: reboot DUT with link-key restored, no need to re-pair
[PASS] GAP_007: Pair can be released
=== Generic-SDP ===
[PASS] SDP_001: browse available service list in local
[PASS] SDP_002: browse available service list from remote
[PASS] SDP_003: browse service by RecHandle for detail info
[PASS] SDP_004: Server can answer SDP searching request
[PASS] SDP_005: Server can add/del/update service records
=== Others-HID ===
[PASS] HID_001: Host can search nearby HID device.
[PASS] HID_002: [BAT] Host can connect to HID device.
[PASS] HID_003: Host can handle multiple human input/output devices.
=== HCI ===
[PASS] HCI_001: Build hci connection between Dev_A and Dev_B.
[PASS] HCI_002: Receive ACL data with HCI.
[PASS] HCI_003: Send ACL data with HCI.
[PASS] HCI_004: Change name of remote Dev by HCI.
[PASS] HCI_005: Change class of remote Dev by HCI.
[PASS] HCI_006: Read local HCI controller information.
[PASS] HCI_007: Read remote HCI controller information.
=== L2CAP ===
[PASS] L2CAP_001: Build l2cap connection between Dev_A and Dev_B.
[PASS] L2CAP_002: Dev_A and Dev_B take l2cap protocol to do pingpong.
=== RFCOMM ===
[PASS] RFCOMM_001: Build rfcomm connection between Dev_A and Dev_B.
[PASS] RFCOMM_002: Dev_A and Dev_B take rfcomm protocol to do pingpong.
=== Settings ===
[PASS] SET_001: [BAT] No error output during bluetoothd startup process.
=== Bluetooth Utils ===
Some basic checking for hciconfig, hcitool, sdptool commands.
[PASS] BTCMD_001: hciconfig -a
[PASS] BTCMD_002: hciconfig <adapter> piscan
[PASS] BTCMD_003: hciconfig <adapter> up/down
[PASS] BTCMD_004: hcitool scan
[PASS] BTCMD_005: sdptool browse local
[PASS] BTCMD_006: sdptool browse <ermote MAC>
[PASS] BTCMD_007: sdptool add/del
^ permalink raw reply
* Cybertan MM230-M issue
From: Yegor Yefremov @ 2012-11-02 9:55 UTC (permalink / raw)
To: linux-bluetooth
I'm using this WLAN-BT-combo card with linux 3.2 and TI am335x based
board. WLAN (88W8686/B1 (Marvell) ) is working, but Bluetooth
(BC4ROM/21e (CSR)) only partly.
I can connect to the card via hciattach ttyO5 bcsp and then I can
bring it up and enable pscan. But hcitool scan delivers nothing.
I get following values via bccmd:
Chip revision: 0x0030 (BC4-ROM)
Build name: odj_4hci_rom_bt2.0_21e_0604241634_encr128 2006-04-24
bccmd -t BCSP -d /dev/ttyO5 -b 115200 enabletx returns with error:
Can't execute command: No such device or address (6)
Any idea how to get the card working?
Regards,
Yegor
^ 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