* Re: [PATCH v2] Add sap_disconnect_ind interface for sap-sim drivers
From: Johan Hedberg @ 2011-03-25 9:17 UTC (permalink / raw)
To: Waldemar Rymarkiewicz; +Cc: linux-bluetooth
In-Reply-To: <1300983402-2970-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
Hi Waldek,
On Thu, Mar 24, 2011, Waldemar Rymarkiewicz wrote:
> The sap_disconnect_ind() let's the sim driver to indicate
> immediate disconnection.
>
> Add support of immediate disconnection in sap-dummy driver
> as well as a card status change in order to pass all PTS tests.
> ---
> sap/sap-dummy.c | 31 ++++++++++++++++++++++++-------
> sap/sap.h | 1 +
> sap/server.c | 7 +++++++
> 3 files changed, 32 insertions(+), 7 deletions(-)
Are you planning to have some additional Disconnect* method in the
future since you didn't reuse the existing "Disconnect" method name for
this? The patch is also missing the corresponding update to sap-api.txt.
Johan
^ permalink raw reply
* Re: [PATCH v2] Sim Access Profile test scripts
From: Johan Hedberg @ 2011-03-25 9:14 UTC (permalink / raw)
To: Waldemar Rymarkiewicz; +Cc: linux-bluetooth
In-Reply-To: <1300973581-32639-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
Hi Waldek,
On Thu, Mar 24, 2011, Waldemar Rymarkiewicz wrote:
> Add simple SAP client python implementation and a test script.
>
> To run test-sap-server you need Python 2.6 or newer (tested with 2.6 only)
> and PyBluez package installed.
> ---
> Makefile.tools | 17 +-
> test/sap-client | 944 ++++++++++++++++++++++++++++++++++++++++++++++++++
> test/test-sap-server | 138 ++++++++
> 3 files changed, 1091 insertions(+), 8 deletions(-)
> create mode 100644 test/sap-client
> create mode 100755 test/test-sap-server
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Fix error message when getting SCO connection handle
From: Johan Hedberg @ 2011-03-25 9:11 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1300968593-25442-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Mar 24, 2011, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> Error message should indicate the transport correctly which is SCO
> not RFCOMM.
> ---
> btio/btio.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Both of your patches have been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [RFCv1 3/3] Bluetooth: delete hanging L2CAP channel
From: Andrei Emeltchenko @ 2011-03-25 8:57 UTC (permalink / raw)
To: Emeltchenko Andrei, linux-bluetooth; +Cc: Gustavo F. Padovan
In-Reply-To: <20110324191242.GD2236@joana>
Hi Gustavo,
On Thu, Mar 24, 2011 at 9:12 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Andrei,
>
> * Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2011-03-24 17:16:08 +0200]:
>
>> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>>
>> Sometimes L2CAP connection remains hanging. Make sure that
>> L2CAP channel is deleted.
>>
>> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>> ---
>> net/bluetooth/l2cap_sock.c | 5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> This one is applied. Thanks.
Where it is applied? Cannot find it here:
http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-next-2.6.git;a=shortlog;h=refs/heads/master
Regards,
Andrei
^ permalink raw reply
* Re: [PATCH v6 4/6] Add D-Bus OOB plugin
From: Johan Hedberg @ 2011-03-25 8:54 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1300974459-24076-5-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Thu, Mar 24, 2011, Szymon Janc wrote:
> +static GDBusMethodTable oob_methods[] = {
> + {"AddRemoteOobData", "sayay", "", add_remote_data},
> + {"RemoveRemoteOobData", "s", "", remove_remote_data},
> + {"ReadLocalOobData", "", "ayay", read_local_data,
> + G_DBUS_METHOD_FLAG_ASYNC},
> + { }
> +};
You're using mixing spaces and tabs for indentation within this table.
Just use table if you want to align the columns.
> +static void oob_remove(struct btd_adapter *adapter)
> +{
> + local_data_read(adapter, NULL, NULL);
> +
> + g_dbus_unregister_interface(connection, adapter_get_path(adapter),
> + OOB_INTERFACE);
> +}
> +
> +
> +static struct btd_adapter_driver oob_driver = {
There should never be the need to have two consecutive empty lines.
Please remove one.
> + while ((match = g_slist_next(oob_requests))) {
> + oob_request = match->data;
> + oob_remove(oob_request->adapter);
> + }
This loop looks flawed to me. Why are you skipping the first element in
the list? It also took some time to see that you don't have an infinite
loop here as it's a quite indirect way that the elements get removed.
Furthermore, you've got functions called "local_data_read" and
"read_local_data". Do you think someone would immediately understand the
difference from those names? Maybe local_data_read could be named
read_local_data_complete or read_local_data_cb or something similar?
Johan
^ permalink raw reply
* Re: [PATCH v6 3/6] Add support for Out of Band (OOB) association model in hciops
From: Johan Hedberg @ 2011-03-25 8:33 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1300974459-24076-4-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Thu, Mar 24, 2011, Szymon Janc wrote:
> +static void remote_oob_data_request(int index, bdaddr_t *bdaddr)
> {
> struct dev_info *dev = &devs[index];
> + GSList *match;
>
> DBG("hci%d", index);
>
> - hci_send_cmd(dev->sk, OGF_LINK_CTL,
> - OCF_REMOTE_OOB_DATA_NEG_REPLY, 6, ptr);
> + match = g_slist_find_custom(dev->oob_data, bdaddr, oob_bdaddr_cmp);
> +
> + if (match) {
> + struct oob_data *data;
> + remote_oob_data_reply_cp cp;
> +
> + data = match->data;
> +
> + bacpy(&cp.bdaddr, &data->bdaddr);
> + memcpy(cp.hash, data->hash, sizeof(cp.hash));
> + memcpy(cp.randomizer, data->randomizer, sizeof(cp.randomizer));
> +
> + dev->oob_data = g_slist_delete_link(dev->oob_data, match);
> +
> + hci_send_cmd(dev->sk, OGF_LINK_CTL, OCF_REMOTE_OOB_DATA_REPLY,
> + REMOTE_OOB_DATA_REPLY_CP_SIZE, &cp);
> +
> + } else {
> + hci_send_cmd(dev->sk, OGF_LINK_CTL,
> + OCF_REMOTE_OOB_DATA_NEG_REPLY, 6, bdaddr);
> + }
> +
> }
Unnecessary empty line at the end of the function.
> + data = g_new(struct oob_data, 1);
> + bacpy(&data->bdaddr, bdaddr);
> + dev->oob_data = g_slist_prepend(dev->oob_data, data);
Probably g_new0 would be better here (doesn't oob_data have more members
than just the bdaddr?
Johan
^ permalink raw reply
* Re: [PATCH v6 2/6] Add support for Out of Band (OOB) association model in mgmtops
From: Johan Hedberg @ 2011-03-25 8:30 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1300974459-24076-3-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Thu, Mar 24, 2011, Szymon Janc wrote:
> @@ -1132,6 +1185,10 @@ static void mgmt_cmd_status(int sk, uint16_t index, void *buf, size_t len)
> opcode = btohs(bt_get_unaligned(&ev->opcode));
>
> DBG("status %u opcode %u (index %u)", ev->status, opcode, index);
> +
> + if (opcode == MGMT_OP_READ_LOCAL_OOB_DATA)
> + read_local_oob_data_failed(sk, index);
> +
> }
Firstly, unnecessary empty line at the end of the function. Secondly,
since it's likely that we'll have to deal with cmd_status messages for
other commands as well I think it'd make sense to start a swtich
statement here (with just one case entry for now).
Johan
^ permalink raw reply
* Re: [PATCH v6 1/6] Add initial support for Out of Band (OOB) association model
From: Johan Hedberg @ 2011-03-25 8:28 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1300974459-24076-2-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
Some coding style issues that still need fixing before this can be
pushed upstream:
On Thu, Mar 24, 2011, Szymon Janc wrote:
> +static int hciops_read_local_oob_data (int index)
No space before (
> +static int hciops_add_remote_oob_data (int index, bdaddr_t *bdaddr,
> + uint8_t *hash, uint8_t *randomizer)
Same here.
> +static int hciops_remove_remote_oob_data (int index, bdaddr_t *bdaddr)
And here.
> +static int mgmt_read_local_oob_data (int index)
And here.
> +static int mgmt_add_remote_oob_data (int index, bdaddr_t *bdaddr,
> + uint8_t *hash, uint8_t *randomizer)
And here.
> +static int mgmt_remove_remote_oob_data (int index, bdaddr_t *bdaddr)
And here.
> +static void (*local_oob_read_cb)(struct btd_adapter *adapter, uint8_t *hash,
> + uint8_t *randomizer) = NULL;
Usually we try to avoid unnecessary typedefs, but since this function
pointer type is used in three different places and takes several
arguments, I think it'd make sense to have a typedef for it in oob.h,
e.g. oob_read_cb_t
> +void oob_register_cb( void (*cb)(struct btd_adapter *adapter, uint8_t *hash,
> + uint8_t *randomizer))
No space before between ( and void
Johan
^ permalink raw reply
* Re: [bluetooth-next 04/15] Bluetooth: Add support for using the crypto subsystem
From: Vinicius Costa Gomes @ 2011-03-24 23:58 UTC (permalink / raw)
To: Brian Gix; +Cc: Claudio Takahasi, Anderson Briglia, linux-bluetooth
In-Reply-To: <4D8BCEC2.7090309@codeaurora.org>
On 16:07 Thu 24 Mar, Brian Gix wrote:
> On 3/24/2011 7:14 AM, Claudio Takahasi wrote:
> >Hi all developers interested on LE,
> >
[ ... ]
> >
> >Patches not upstream(bluetooth-next) are available here:
> >git://gitorious.org/bluetooth-next/for-upstream.git
> >
> >Contains patches for SM just works method, advertising cache and MTU.
>
> Are these rebased off of bluetooth-next on kernel.org?
>
Now they are.
I also pushed the patches that add support for storing (and using) LTKs
to this repository. It needs a userspace that supports this[1].
I am not sending them for proper review yet, because they depend
strongly on the first SMP patches. But comments are welcome.
>
> >BR,
> >Claudio
>
>
> --
> Brian Gix
> bgix@codeaurora.org
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
> --
> 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
Cheers,
--
Vinicius
[1] git://gitorious.org/~vcgomes/bluez/vcgomes-bluez.git (branch mgmt)
^ permalink raw reply
* Re: [bluetooth-next 04/15] Bluetooth: Add support for using the crypto subsystem
From: Brian Gix @ 2011-03-24 23:07 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: Anderson Briglia, Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <AANLkTin_yLAyWjLjqk-5Z-gerWeVxQhk4ONtngqt1zKT@mail.gmail.com>
On 3/24/2011 7:14 AM, Claudio Takahasi wrote:
> Hi all developers interested on LE,
>
> On Tue, Mar 15, 2011 at 4:12 PM, Brian Gix<bgix@codeaurora.org> wrote:
>> On 3/15/2011 12:03 PM, Anderson Briglia wrote:
>>>
>>> Hi all,
>>>
>>> On Wed, Mar 9, 2011 at 6:52 PM, Vinicius Costa Gomes
>>> <vinicius.gomes@openbossa.org> wrote:
>>>>
>>>> On 14:45 Thu 03 Mar, Vinicius Costa Gomes wrote:
>>>>>
>>>>> Hi Marcel,
>>>>>
>>>>> On 14:28 Mon 28 Feb, Gustavo F. Padovan wrote:
>>>>>>
>>>>>> Hi Vinicius,
>>>>>>
>>>>>> * Vinicius Gomes<vinicius.gomes@openbossa.org> [2011-02-27 21:49:39
>>>>>> -0300]:
>>>>>>
>>>>>>> Hi Gustavo,
>>>>>>>
>>>>>>> On Sun, Feb 27, 2011 at 5:20 PM, Gustavo F. Padovan
>>>>>>> <padovan@profusion.mobi> wrote:
>>>>>>>>
>>>>>>>> Hi Vinicius,
>>>>>>>>
>>>>>>>> * Vinicius Costa Gomes<vinicius.gomes@openbossa.org> [2011-02-21
>>>>>>>> 14:23:51 -0300]:
>>>>>>>>
>>
>> [...]
>>
>>>>>
>>>>> Any ideas?
>>>>
>>>> Still no ideas?
>>>>
>>>
>>> We at INdT have some patches based on top of this series. What is the
>>> maintainer's opinion about this series? I'm asking it because should
>>> be great to know if we are doing the right stuff or we need to change
>>> our approach. The number of features and patches that have this series
>>> as dependency is growing.
>>
>> I am also developing patches off of this series and have signed off on their
>> baseline functionality.
>>
>>> Regards,
>>>
>>> Anderson Briglia
>>
>>
>> --
>> Brian Gix
>> bgix@codeaurora.org
>> Employee of Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
>> --
>> 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
>>
>
> Patches not upstream(bluetooth-next) are available here:
> git://gitorious.org/bluetooth-next/for-upstream.git
>
> Contains patches for SM just works method, advertising cache and MTU.
Are these rebased off of bluetooth-next on kernel.org?
> BR,
> Claudio
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* pull request: bluetooth-2.6 2011-03-24
From: Gustavo F. Padovan @ 2011-03-24 20:43 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth
Hi John,
Here is my first pull request of fixes for 2.6.39-rc1, the two critical fixes
are HCI_RESET command synchronization that fixes an issues with loosing some
HCI commands responses. And a warning shut up in HCI code by Thomas Gleixner.
The other fixes are all important.
Please pull, thanks. :)
The following changes since commit d78f4b3e2c4dfb9487624f7157af04ab4260e189:
ath9k: Fix TX queue stuck issue. (2011-03-23 15:22:05 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master
Andrei Emeltchenko (1):
Bluetooth: delete hanging L2CAP channel
Gustavo F. Padovan (1):
Bluetooth: Fix HCI_RESET command synchronization
Johan Hedberg (1):
Bluetooth: Fix missing hci_dev_lock_bh in user_confirm_reply
Marc-Antoine Perennou (1):
Bluetooth: add support for Apple MacBook Pro 8,2
Suraj Sumangala (1):
Bluetooth: Increment unacked_frames count only the first transmit
Thomas Gleixner (1):
Bluetooth: Fix warning with hci_cmd_timer
Vinicius Costa Gomes (1):
Bluetooth: Fix sending LE data over USB
drivers/bluetooth/btusb.c | 6 +++++-
include/net/bluetooth/hci.h | 2 ++
net/bluetooth/hci_core.c | 10 ++++++++--
net/bluetooth/hci_event.c | 4 +++-
net/bluetooth/l2cap_core.c | 4 +++-
net/bluetooth/l2cap_sock.c | 5 +++--
net/bluetooth/mgmt.c | 2 ++
7 files changed, 26 insertions(+), 7 deletions(-)
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 1/5] Inline ATT dump functions
From: Gustavo F. Padovan @ 2011-03-24 20:33 UTC (permalink / raw)
To: André Dieb
Cc: Szymon Janc, linux-bluetooth@vger.kernel.org, Johan Hedberg
In-Reply-To: <AANLkTik_wfOuhUg1qJWG6XdNukbs-maH9nyPeJecGxkB@mail.gmail.com>
Hi André,
Please stop the top-posting on this mailing list.
* André Dieb <andre.dieb@signove.com> [2011-03-24 09:59:28 -0300]:
> Hello,
>
> In case most agree with this, I can change my patch and provide some
> patches changing old code.
I agree, let the compiler decide. It know exactly how to handle this.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH v5 0/5] Support for OOB in mgmt interface
From: Gustavo F. Padovan @ 2011-03-24 20:29 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1300795943-6681-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
* Szymon Janc <szymon.janc@tieto.com> [2011-03-22 13:12:18 +0100]:
> Changes since v4:
> - include comments from Anderson Lizardo
> - use sizeof instead of hardcoded size in memcpy calls
>
> BR,
> Szymon Janc
> on behalf of ST-Ericsson
>
> Szymon Janc (5):
> Bluetooth: Rename cmd to param in pending_cmd
> Bluetooth: Allow for NULL data in mgmt_pending_add
> Bluetooth: Add read_local_oob_data management command
> Bluetooth: Add add/remove_remote_oob_data management commands
> Bluetooth: Enable support for out of band association model
All 5 patches applied. Thanks for implement this.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: Bluetooth git tree
From: Gustavo F. Padovan @ 2011-03-24 20:24 UTC (permalink / raw)
To: Bing Zhao; +Cc: Marcel Holtmann, linux-bluetooth@vger.kernel.org
In-Reply-To: <477F20668A386D41ADCC57781B1F704307FA791446@SC-VEXCH1.marvell.com>
Hi Bing,
* Bing Zhao <bzhao@marvell.com> [2011-03-22 17:10:26 -0700]:
> Hi Gustavo,
>
> I'm planning to add SD8787 support to 'btmrvl' driver.
>
> Should I get started from the git tree below?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6.git
Yes, that is the bluetooth git tree for new developments.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 09/10] Bluetooth: Fix checkpatch error in cmtp.h
From: Gustavo F. Padovan @ 2011-03-24 20:23 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1300713606-23523-10-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
* Szymon Janc <szymon.janc@tieto.com> [2011-03-21 14:20:05 +0100]:
> Do not use C99 // comments.
>
> Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
> ---
> net/bluetooth/cmtp/cmtp.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
All patches applied, except the 3 kthread ones. I'll wait your reply on them.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 04/10] Bluetooth: Use kthread API in bnep
From: Gustavo F. Padovan @ 2011-03-24 20:12 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1300713606-23523-5-git-send-email-szymon.janc@tieto.com>
Hy Szymon,
* Szymon Janc <szymon.janc@tieto.com> [2011-03-21 14:20:00 +0100]:
> kernel_thread() is a low-level implementation detail and
> EXPORT_SYMBOL(kernel_thread) is scheduled for removal.
> Use the <linux/kthread.h> API instead.
Just to be sure. Have you tested the kernel_thread removal patches for bnep
and hipd?
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] ath3k: Add ASUS BT Support
From: Gustavo F. Padovan @ 2011-03-24 19:14 UTC (permalink / raw)
To: Lee Trager; +Cc: marcel, linux-bluetooth
In-Reply-To: <4D8477B8.4010803@cs.drexel.edu>
Hi Lee,
* Lee Trager <lt73@cs.drexel.edu> [2011-03-19 05:30:32 -0400]:
> The ASUS USB Bluetooth module that comes with my motherboard(ASUS P8P67
> Pro) is simply a re-branded Atheros AR3011. This patch add support for
> it in the driver
>
> Signed-off-by: Lee Trager <lt73@cs.drexel.edu>
>
> --- drivers/bluetooth/ath3k.c.old 2011-03-18 04:27:26.160161039 -0400
> +++ drivers/bluetooth/ath3k.c 2011-03-18 04:29:05.853945455 -0400
> @@ -36,9 +36,12 @@
> /* Atheros AR3011 */
> { USB_DEVICE(0x0CF3, 0x3000) },
>
> - /* Atheros AR3011 with sflash firmware*/
> + /* Atheros AR3011 with sflash firmware */
> { USB_DEVICE(0x0CF3, 0x3002) },
>
> + /* ASUS branded Atheros AR3011 */
> + { USB_DEVICE(0x0B05, 0x179C) },
> +
This patch doesn't apply to bluetooth-2.6 (or the not yet released
2.6.39-rc1). Please rebase, thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [RFCv1 3/3] Bluetooth: delete hanging L2CAP channel
From: Gustavo F. Padovan @ 2011-03-24 19:12 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1300979768-31963-4-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2011-03-24 17:16:08 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Sometimes L2CAP connection remains hanging. Make sure that
> L2CAP channel is deleted.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/l2cap_sock.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
This one is applied. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [RFCv1 1/3] Bluetooth: check info_rsp ident and states
From: Gustavo F. Padovan @ 2011-03-24 19:11 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1300979768-31963-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2011-03-24 17:16:06 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Information requests/responses are unbound to L2CAP channel. Patch
> fixes issue arising when two devices connects at the same time to
> each other. This way we do not process out of the context messages.
> We are safe dropping info_rsp since info_timer is left running.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/l2cap_core.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index ca27f3a..fd58b8f 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -2462,6 +2462,16 @@ static inline int l2cap_information_rsp(struct l2cap_conn *conn, struct l2cap_cm
>
> BT_DBG("type 0x%4.4x result 0x%2.2x", type, result);
>
> + if (cmd->ident != conn->info_ident) {
> + BT_DBG("Collision receiving info response");
> + return 0;
> + }
> +
> + if (conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE) {
> + BT_DBG("Information request already done");
> + return 0;
> + }
This patch is good, but without the BT_DBG(). They are not needed.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [RFCv1 2/3] Bluetooth: remove duplicated code
From: Gustavo F. Padovan @ 2011-03-24 18:57 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1300979768-31963-3-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2011-03-24 17:16:07 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> info_timer takes care about removed code
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/l2cap_core.c | 12 +++---------
> 1 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index fd58b8f..4255f00 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -2472,16 +2472,10 @@ static inline int l2cap_information_rsp(struct l2cap_conn *conn, struct l2cap_cm
> return 0;
> }
>
> - del_timer(&conn->info_timer);
> -
> - if (result != L2CAP_IR_SUCCESS) {
> - conn->info_state |= L2CAP_INFO_FEAT_MASK_REQ_DONE;
> - conn->info_ident = 0;
> -
> - l2cap_conn_start(conn);
Are you sure? Does remove this code won't create a delay to call
l2cap_conn_start()?
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 2.6.38] bluetooth: add support for Apple MacBook Pro 8,2
From: Gustavo F. Padovan @ 2011-03-24 17:58 UTC (permalink / raw)
To: Grant Likely
Cc: Marc-Antoine Perennou, Marcel Holtmann, linux-kernel,
linux-bluetooth, stable, Travis Watkins
In-Reply-To: <AANLkTi=-mGD670m9G31mYQjoj7Rt4_OveXOi2dTPYkxY@mail.gmail.com>
Hi all,
On Thu, Mar 24, 2011 at 1:10 PM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> On Mon, Mar 21, 2011 at 10:28 AM, Marc-Antoine Perennou
> <Marc-Antoine@perennou.com> wrote:
>> Just adding the vendor details makes it work fine.
>>
>> Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
>
> Acked by: Grant Likely <grant.likely@secretlab.ca>
>
> Marcel, this one is pretty trivial. =C2=A0Can we get it picked up for
> 2.6.39? =C2=A0It would also be useful to backport it to stable once it hi=
ts
> Linus' tree.
I applied this patch to the bluetooth tree and will send it mainline.
Thanks all.
--=20
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH v2 0/3] Another try for the Sixaxis plugin
From: Antonio Ospite @ 2011-03-24 17:32 UTC (permalink / raw)
To: Bastien Nocera
Cc: linux-bluetooth, linux-input, Jim Paris, Ranulf Doswell,
Pascal A . Brisset, Marcin Tolysz, Christian Birchinger,
Filipe Lopes, Alan Ott, Mikko Virkkila
In-Reply-To: <1298637244.10364.19.camel@novo.hadess.net>
[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]
On Fri, 25 Feb 2011 12:34:02 +0000
Bastien Nocera <hadess@hadess.net> wrote:
> On Fri, 2011-02-25 at 11:04 +0100, Antonio Ospite wrote:
[...]
> >
> > TODO before merging:
> > - Check the routine about bluetooth association. Also, is it strictly
> > necessary to grant manually the first connection?
>
> The line setting the device trust should be enough to not have to
> manually grant the first connection. You might want to double-check what
> changes between the state of /var/lib/bluetooth after cable pairing and
> before connecting for the first time.
>
Calling write_trust() before adapter_get_device() fixes the prompt on
the first association, AFAICS adapter_get_device() reads the trust file.
> > - When the controller is connected via USB after it is working over BT
> > it is seen as a second controller and the second LED is turned on,
> > should we force BT disconnection on USB connection?
>
> If we can assert that the device is the same one, yes, I think we
> should.
>
With regard to that, I'd like to see some USB dumps of a Sixaxis
talking with GameOS to check if the PS3 can turn off BT on the
controller explicitly, can anyone help here? (Pascal? Do you have
access to a USB analyzer?):
The scenarios I am interested in are:
1. Connect a non-paired Sixaxis to the PS3 via USB
2. Connect an already paired Sixaxis to the PS3 via USB
3. Connect a Sixaxis already associated via BT to a PS3 via USB
> > - Test with multiple controllers, and/or multiple BT adapters, which I
> > can't do right now.
> > - Remove the XXX comment about the lowercase hex bdaddr format.
> >
Another TODO item: avoid setting the led before the controller sends
input events (this is the GameOS behavior as well): I am planning to add
a blocking read() in order to wait for the user to press the PS button
before setting the led, I'll emphasize that in the next review round.
> >
> > FUTURE plans:
> > - Add support for battery status report
>
> Where is the battery level exported currently?
>
It is exported in the input report.
> > - Add support for Playstation Move (I don't have the hardware, tho),
> > Pascal?
>
> The PS3 add-on keyboard, and the PS3 headset both use cable pairing. I
> have them around, but was unable to get them to pair.
>
I don't have the hardware so I never searched to see what the
differences with the Sixaxis are.
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH v2] Add sap_disconnect_ind interface for sap-sim drivers
From: Waldemar Rymarkiewicz @ 2011-03-24 16:16 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg, Waldemar Rymarkiewicz
In-Reply-To: <1300982971-2869-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
The sap_disconnect_ind() let's the sim driver to indicate
immediate disconnection.
Add support of immediate disconnection in sap-dummy driver
as well as a card status change in order to pass all PTS tests.
---
sap/sap-dummy.c | 31 ++++++++++++++++++++++++-------
sap/sap.h | 1 +
sap/server.c | 7 +++++++
3 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/sap/sap-dummy.c b/sap/sap-dummy.c
index 39e1fc9..37982be 100644
--- a/sap/sap-dummy.c
+++ b/sap/sap-dummy.c
@@ -260,11 +260,15 @@ static DBusMessage *max_msg_size(DBusConnection *conn, DBusMessage *msg,
return dbus_message_new_method_return(msg);
}
-static DBusMessage *disconnect(DBusConnection *conn, DBusMessage *msg,
+static DBusMessage *disconnect_immediate(DBusConnection *conn, DBusMessage *msg,
void *data)
{
+ if (sim_card_conn_status == SIM_DISCONNECTED)
+ return g_dbus_create_error(msg, "org.bluez.Error.Failed",
+ "Already disconnected.");
+
sim_card_conn_status = SIM_DISCONNECTED;
- sap_status_ind(sap_data, SAP_STATUS_CHANGE_CARD_NOT_ACCESSIBLE);
+ sap_disconnect_ind(sap_data, SAP_DISCONNECTION_TYPE_IMMEDIATE);
return dbus_message_new_method_return(msg);
}
@@ -284,15 +288,28 @@ static DBusMessage *card_status(DBusConnection *conn, DBusMessage *msg,
DBUS_TYPE_INVALID))
return invalid_args(msg);
- if (status) {
+ switch (status) {
+ case 0: /* card removed */
+ sim_card_conn_status = SIM_MISSING;
+ sap_status_ind(sap_data, SAP_STATUS_CHANGE_CARD_REMOVED);
+ break;
+
+ case 1: /* card inserted */
if (sim_card_conn_status == SIM_MISSING) {
sim_card_conn_status = SIM_CONNECTED;
sap_status_ind(sap_data,
SAP_STATUS_CHANGE_CARD_INSERTED);
}
- } else {
- sim_card_conn_status = SIM_MISSING;
- sap_status_ind(sap_data, SAP_STATUS_CHANGE_CARD_REMOVED);
+ break;
+
+ case 2: /* card not longer available*/
+ sim_card_conn_status = SIM_POWERED_OFF;
+ sap_status_ind(sap_data, SAP_STATUS_CHANGE_CARD_NOT_ACCESSIBLE);
+ break;
+
+ default:
+ return g_dbus_create_error(msg, "org.bluez.Error.Failed",
+ "Unknown card status. Use 0, 1 or 2.");
}
DBG("Card status changed to %d", status);
@@ -303,7 +320,7 @@ static DBusMessage *card_status(DBusConnection *conn, DBusMessage *msg,
static GDBusMethodTable dummy_methods[] = {
{ "OngoingCall", "b", "", ongoing_call},
{ "MaxMessageSize", "u", "", max_msg_size},
- { "Disconnect", "", "", disconnect},
+ { "DisconnectImmediate", "", "", disconnect_immediate},
{ "CardStatus", "u", "", card_status},
{ }
};
diff --git a/sap/sap.h b/sap/sap.h
index 24240ca..7c4a815 100644
--- a/sap/sap.h
+++ b/sap/sap.h
@@ -184,3 +184,4 @@ int sap_transport_protocol_rsp(void *sap_device, uint8_t result);
/* Event indication. Implemented by server.c*/
int sap_status_ind(void *sap_device, uint8_t status_change);
+int sap_disconnect_ind(void *sap_device, uint8_t disc_type);
diff --git a/sap/server.c b/sap/server.c
index 35abffb..e3f756c 100644
--- a/sap/server.c
+++ b/sap/server.c
@@ -1000,6 +1000,13 @@ int sap_status_ind(void *sap_device, uint8_t status_change)
return send_message(sap_device, buf, size);
}
+int sap_disconnect_ind(void *sap_device, uint8_t disc_type)
+{
+ struct sap_connection *conn = sap_device;
+
+ return disconnect_req(conn, SAP_DISCONNECTION_TYPE_IMMEDIATE);
+}
+
static int handle_cmd(void *data, void *buf, size_t size)
{
struct sap_message *msg = buf;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2.6.38] bluetooth: add support for Apple MacBook Pro 8,2
From: Grant Likely @ 2011-03-24 16:10 UTC (permalink / raw)
To: Marc-Antoine Perennou
Cc: Gustavo F. Padovan, Marcel Holtmann, linux-kernel,
linux-bluetooth, stable, Travis Watkins
In-Reply-To: <AANLkTik20MfB5yta5mRoSny8NYOt3c0Rncg-rJY1SS9R@mail.gmail.com>
On Mon, Mar 21, 2011 at 10:28 AM, Marc-Antoine Perennou
<Marc-Antoine@perennou.com> wrote:
> Just adding the vendor details makes it work fine.
>
> Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
Acked by: Grant Likely <grant.likely@secretlab.ca>
Marcel, this one is pretty trivial. Can we get it picked up for
2.6.39? It would also be useful to backport it to stable once it hits
Linus' tree.
g.
>
> ---
> =A0drivers/bluetooth/btusb.c | =A0 =A03 +++
> =A01 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 8668114..2af2e77 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -71,6 +71,9 @@ static struct usb_device_id btusb_table[] =3D {
> =A0 =A0 /* Apple MacBookAir3,1, MacBookAir3,2 */
> =A0 =A0 { USB_DEVICE(0x05ac, 0x821b) },
>
> + =A0 =A0/* Apple MacBookPro8,2 */
> + =A0 =A0{ USB_DEVICE(0x05ac, 0x821a) },
> +
> =A0 =A0 /* AVM BlueFRITZ! USB v2.0 */
> =A0 =A0 { USB_DEVICE(0x057c, 0x3800) },
>
> --
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at =A0http://www.tux.org/lkml/
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] Add sap_disconnect_ind interface for sap-sim drivers.
From: Waldemar Rymarkiewicz @ 2011-03-24 16:09 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg, Waldemar Rymarkiewicz
The sap_disconnect_ind() let's the sim driver to indicate
immediate disconnection.
Add support of immediate disconnection in sap-dummy driver
as well as a card status change in order to pass all PTS tests.
---
sap/sap-dummy.c | 31 ++++++++++++++++++++++++-------
sap/sap.h | 1 +
sap/server.c | 8 ++++++++
3 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/sap/sap-dummy.c b/sap/sap-dummy.c
index 39e1fc9..37982be 100644
--- a/sap/sap-dummy.c
+++ b/sap/sap-dummy.c
@@ -260,11 +260,15 @@ static DBusMessage *max_msg_size(DBusConnection *conn, DBusMessage *msg,
return dbus_message_new_method_return(msg);
}
-static DBusMessage *disconnect(DBusConnection *conn, DBusMessage *msg,
+static DBusMessage *disconnect_immediate(DBusConnection *conn, DBusMessage *msg,
void *data)
{
+ if (sim_card_conn_status == SIM_DISCONNECTED)
+ return g_dbus_create_error(msg, "org.bluez.Error.Failed",
+ "Already disconnected.");
+
sim_card_conn_status = SIM_DISCONNECTED;
- sap_status_ind(sap_data, SAP_STATUS_CHANGE_CARD_NOT_ACCESSIBLE);
+ sap_disconnect_ind(sap_data, SAP_DISCONNECTION_TYPE_IMMEDIATE);
return dbus_message_new_method_return(msg);
}
@@ -284,15 +288,28 @@ static DBusMessage *card_status(DBusConnection *conn, DBusMessage *msg,
DBUS_TYPE_INVALID))
return invalid_args(msg);
- if (status) {
+ switch (status) {
+ case 0: /* card removed */
+ sim_card_conn_status = SIM_MISSING;
+ sap_status_ind(sap_data, SAP_STATUS_CHANGE_CARD_REMOVED);
+ break;
+
+ case 1: /* card inserted */
if (sim_card_conn_status == SIM_MISSING) {
sim_card_conn_status = SIM_CONNECTED;
sap_status_ind(sap_data,
SAP_STATUS_CHANGE_CARD_INSERTED);
}
- } else {
- sim_card_conn_status = SIM_MISSING;
- sap_status_ind(sap_data, SAP_STATUS_CHANGE_CARD_REMOVED);
+ break;
+
+ case 2: /* card not longer available*/
+ sim_card_conn_status = SIM_POWERED_OFF;
+ sap_status_ind(sap_data, SAP_STATUS_CHANGE_CARD_NOT_ACCESSIBLE);
+ break;
+
+ default:
+ return g_dbus_create_error(msg, "org.bluez.Error.Failed",
+ "Unknown card status. Use 0, 1 or 2.");
}
DBG("Card status changed to %d", status);
@@ -303,7 +320,7 @@ static DBusMessage *card_status(DBusConnection *conn, DBusMessage *msg,
static GDBusMethodTable dummy_methods[] = {
{ "OngoingCall", "b", "", ongoing_call},
{ "MaxMessageSize", "u", "", max_msg_size},
- { "Disconnect", "", "", disconnect},
+ { "DisconnectImmediate", "", "", disconnect_immediate},
{ "CardStatus", "u", "", card_status},
{ }
};
diff --git a/sap/sap.h b/sap/sap.h
index 24240ca..7c4a815 100644
--- a/sap/sap.h
+++ b/sap/sap.h
@@ -184,3 +184,4 @@ int sap_transport_protocol_rsp(void *sap_device, uint8_t result);
/* Event indication. Implemented by server.c*/
int sap_status_ind(void *sap_device, uint8_t status_change);
+int sap_disconnect_ind(void *sap_device, uint8_t disc_type);
diff --git a/sap/server.c b/sap/server.c
index 35abffb..a051a85 100644
--- a/sap/server.c
+++ b/sap/server.c
@@ -1000,6 +1000,14 @@ int sap_status_ind(void *sap_device, uint8_t status_change)
return send_message(sap_device, buf, size);
}
+int sap_disconnect_ind(void *sap_device, uint8_t disc_type)
+{
+ struct sap_connection *conn = sap_device;
+
+ return disconnect_req(conn, SAP_DISCONNECTION_TYPE_IMMEDIATE);
+}
+
+
static int handle_cmd(void *data, void *buf, size_t size)
{
struct sap_message *msg = buf;
--
1.7.1
^ permalink raw reply related
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