gmane.linux.bluez.kernel

Re: GATT Clients and Servers in the kernel (was Re:[PATCH BlueZ v3 06/16] attrib...)

Marcel Holtmann — 2013-05-21T19:25:24

Hi Andre,


I am not worried about the mgmt commands actually. My main point is that after a reboot they need to be reloaded into the kernel. So something else is needed here as well. And I do not want to hold file descriptors for devices that say are know, but only connect once per week.

What I want is that we tell the kernel what device we know about and what we expect to connect automatically once in range. So that we can program the controller properly. And to that effect not have this controller via L2CAP layer connect(). Since that layer has nothing to do with it actually.

This mgmt commands does not have to LE specific, but are most likely LE specific. I have not a big problem with this. We already have the LE long term key loading command that LE specific already. Maybe there are some common features between LE and BR/EDR possible. For example we have been talking about remote wakeup in the past. That can fit on BR/EDR and LE.


Actually connect() will stay relevant, but I can not go into specifics

Re: GATT Clients and Servers in the kernel (was Re:[PATCH BlueZ v3 06/16] attrib...)

Andre Guedes — 2013-05-21T19:05:10

Hi all,

Last week we did some brainstorming about the two LE connection
approaches. So far, the only drawback we see in this accept() approach
is that it requires at least three new mgmt LE-specific commands to
add, remove and clear the set of devices we want to connect to. IIRC,
we don't want commands LE-specific in Management Interface.

Also, during discussion, some questions were raised and we'd like to
share with the ML:

* What happens with connect()? What should it implement?

* How this approach integrates with peripheral role and advertising support?

BR,

Andre

On Fri, May 3, 2013 at 12:17 PM, Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw< at >public.gmane.org> wrote:

Re: [PATCH 1/1] profile: Fix incoming connections without SDP record

Mikel Astiz — 2013-05-21T16:46:26

Hi Christian,

On Tue, May 21, 2013 at 5:26 PM, Christian Fetzer
<christian.fetzer-Y0tyK2LzuKvpgbXj0Ix11Q< at >public.gmane.org> wrote:

Ack from my side.

A comment might be helpful to clarify that the condition below (i.e.
service == NULL) is now unlikely and only possible due to issues
during profile probe.

Cheers,
Mikel

Re: [PATCH rebased] Bluetooth: Add missing reset_resume dev_pm_ops

Gustavo Padovan — 2013-05-21T15:36:09

Hi Shuah,

* Shuah Khan <shuah.kh-Sze3O3UU22JBDgjK7y7TUQ< at >public.gmane.org> [2013-05-21 09:32:06 -0600]:


Patch has been applied to bluetooth-next. Thanks.

Gustavo

[PATCH 1/1] profile: Fix incoming connections without SDP record

Christian Fetzer — 2013-05-21T15:26:24

From: Christian Fetzer <christian.fetzer-98C5kh4wR6ohFhg+JK9F0w< at >public.gmane.org>

After commit 7bd3626b6715ac6a117d56b95b455960f7cf34de, incoming connections
require the service being available from SDP. This is not always guaranteed
because some services might not be listed in SDP (like MNS).
---
 src/profile.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/profile.c b/src/profile.c
index 8fd0424..9f98d65 100644
--- a/src/profile.c
+++ b/src/profile.c
< at >< at > -1056,6 +1056,7 < at >< at > static struct ext_io *create_conn(struct ext_io *server, GIOChannel *io,
 return NULL;
 }
 
+btd_device_add_uuid(device, server->ext->remote_uuid);
 service = btd_device_get_service(device, server->ext->remote_uuid);
 if (service == NULL) {
 ba2str(dst, addr);

Re: [PATCH rebased] Bluetooth: Add missing reset_resume dev_pm_ops

Shuah Khan — 2013-05-21T15:32:51

On Tue, 2013-05-21 at 00:28 -0300, Gustavo Padovan wrote:

I saved the patch from the email I sent and applied to your latest git
and it applies. I am not sure what happened. In any case, I just resent
it using git-send-email. Hope that works.

[PATCH BlueZ v3 1/2] plugins: Use open()/read() instead of fopen()/fread() on autopair

Anderson Lizardo — 2013-05-21T13:06:43

open()/read() is more common on BlueZ code. Incidentally, get rid of
this compilation error (using gcc 4.6.3):

plugins/autopair.c: In function ‘autopair_init’:
plugins/autopair.c:154:8: error: ignoring return value of ‘fread’,
declared with attribute warn_unused_result [-Werror=unused-result]
---
 plugins/autopair.c |   22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

v3:

* Fix buggy logic
* The obvious code path is tested by just starting bluetoothd, which will call
  autopair_init()
* Maybe overkill, but I used this mockup code to test other unreachable code
  paths: http://ix.io/5JC
* I agree with Marcel that we should just fail if /dev/urandom is not readable.
  Otherwise, we are introducing code that will 99% of the time not be run
  (unless someone confirms that we have systems with unusable /dev/urandom).

diff --git a/plugins/autopair.c b/plugins/autopair.c
index 5d90f9d..5aa80df 100644
--- a/plugins/autopair.c
+++ b/plugins/autopair.c
< at >< at > -27,6 +27,8 < at >< at >
 
 #inclu

[PATCH BlueZ 2/2] core: Avoid unnecessary gboolean on pincode callback API

Anderson Lizardo — 2013-05-21T13:06:44

Use standard "bool" type instead. Callers in plugins/* are fixed on the
same commit to avoid compilation errors.
---
 plugins/autopair.c |    8 ++++----
 plugins/wiimote.c  |    3 ++-
 src/adapter.c      |    5 ++---
 src/adapter.h      |    2 +-
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/plugins/autopair.c b/plugins/autopair.c
index 5aa80df..e6e5035 100644
--- a/plugins/autopair.c
+++ b/plugins/autopair.c
< at >< at > -51,9 +51,9 < at >< at >
  */
 
 static ssize_t autopair_pincb(struct btd_adapter *adapter,
-struct btd_device *device,
-char *pinbuf, gboolean *display,
-unsigned int attempt)
+struct btd_device *device,
+char *pinbuf, bool *display,
+unsigned int attempt)
 {
 char addr[18];
 char pinstr[7];
< at >< at > -109,7 +109,7 < at >< at > static ssize_t autopair_pincb(struct btd_adapter *adapter,
 
 snprintf(pinstr, sizeof(pinstr), "%06d",
 rand() % 1000000);
-*display = TRUE;
+*display = true;
 memcpy(pinbuf, pinstr, 6);
 return 6;
 
diff --git a/plugins/wiimote.

Re: [PATCH BlueZ v2 1/2] plugins: Use open()/read() instead of fopen()/fread() on autopair

Anderson Lizardo — 2013-05-21T11:02:42

Hi Johan,

On Mon, May 20, 2013 at 7:51 PM, Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Sorry about letting this pass. I actually reviewed the snippet, but
was induced to some "braino" which now seems obvious.

I'll try to be more careful, specially given I could not test this
change (as I mentioned on the original patch, but not on this one).

Regards,

Re: [PATCH BlueZ v2 1/2] plugins: Use open()/read() instead of fopen()/fread() on autopair

Marcel Holtmann — 2013-05-21T06:10:58

Hi Johan,


good one.

Having to read this again, can someone please tell when a Linux platform will not have /dev/urandom and we really need to care? Wouldn't it be better to bail out loudly with an error message and do not use any auto pair feature at all.

Regards

Marcel

Re: BlueZ - First timer

Suresh Kumar N. — 2013-05-21T05:56:42

Thank you Luiz

On Tue, May 21, 2013 at 3:37 AM, Luiz Augusto von Dentz
<luiz.dentz-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: [PATCH rebased] Bluetooth: Add missing reset_resume dev_pm_ops

Gustavo Padovan — 2013-05-21T03:28:06

Hi Shuan,

* Shuah Khan <shuah.kh-Sze3O3UU22JBDgjK7y7TUQ< at >public.gmane.org> [2013-05-21 01:02:58 +0000]:


Patch still doesn't apply, are you sending it with git-send-email?

Applying: Bluetooth: Add missing reset_resume dev_pm_ops
/home/padovan/p/linux-trees/bluetooth-next/.git/rebase-apply/patch:13: trailing whitespace.
        .reset_resume   = btusb_resume,
error: patch failed: drivers/bluetooth/btusb.c:1616
error: drivers/bluetooth/btusb.c: patch does not apply
Patch failed at 0001 Bluetooth: Add missing reset_resume dev_pm_ops

Gustavo

[BUG] Set Powered=true doesn't power up the adapter

Alex Deymo — 2013-05-21T02:07:23

Hello,

I'm seeing a problem while trying to power on the adapter once in a
while just after reboot. What happens is that sending a dbus call to
power on the adapter doesn't return. You can read a more detailed
description of the bug here [1] but the resume is as follows:

Sending org.freedesktop.DBus.Properties.Set for power up the adapter
doesn't return (dbus timeouts after a while) just after reboot. Is a
very rare bug, but happens from time to time. Restarting bluetoothd
with -n -d to get the logs made it start returning with the error
org.bluez.Error.Failed to the same call. I don't see any HCI command
with btmon while doing this, so I think it's not a firmware issue at
that point (could be some other thing before). From this state, I can
call Set several times to power up the adapter, but doesn't work.
What is interesting is that if instead of sending MGMT_OP_SET_POWERED
from bluetoothd, we try to power up the adapter with hciconfig
(calling ioctl(ctl, HCIDEVUP, hdev) ) the adapter goes up and
everythi

[PATCH rebased] Bluetooth: Add missing reset_resume dev_pm_ops

Shuah Khan — 2013-05-21T01:02:58

Add missing reset_resume dev_pm_ops. Missing reset_resume results in the
following message after power management device test. This change sets
reset_resume to btusb_resume().

[ 2506.936134] btusb 1-1.5:1.0: no reset_resume for driver btusb?
[ 2506.936137] btusb 1-1.5:1.1: no reset_resume for driver btusb?

Signed-off-by: Shuah Khan <shuah.kh< at >samsung.com>
---
 drivers/bluetooth/btusb.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7a7e5f8..1eb90c0 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
< at >< at > -1616,6 +1616,7 < at >< at > static struct usb_driver btusb_driver = {
 #ifdef CONFIG_PM
 .suspend= btusb_suspend,
 .resume= btusb_resume,
+.reset_resume= btusb_resume,
 #endif
 .id_table= btusb_table,
 .supports_autosuspend = 1,

Re: [PATCH BlueZ v2 1/2] plugins: Use open()/read() instead of fopen()/fread() on autopair

Johan Hedberg — 2013-05-20T23:51:42

Hi Lizardo,

On Fri, May 17, 2013, Anderson Lizardo wrote:

So, it's not always wise to go blindly copying code examples/suggestions
from Marcel without thinking a bit. You're checking for invalid fd when
you should be checking for a valid one (>= 0).

Johan

Re: [PATCH] Bluetooth: Add missing reset_resume dev_pm_ops

Shuah Khan — 2013-05-20T23:34:51

On Mon, 2013-05-20 at 20:08 -0300, Gustavo Padovan wrote:

Hi Gustavo,

Yes. I will rebase and resend it you shortly.

Re: [PATCH] Bluetooth: Add missing reset_resume dev_pm_ops

Gustavo Padovan — 2013-05-20T23:08:32

Hi Shuah,

* Shuah Khan <shuah.kh-Sze3O3UU22JBDgjK7y7TUQ< at >public.gmane.org> [2013-04-29 15:45:34 +0000]:


This patch needs rebase on latest bluetooth-next. It doesn't apply anymore.
Please re-send it.

Gustavo

Re: BlueZ - First timer

Luiz Augusto von Dentz — 2013-05-20T22:07:32

Hi,

On Mon, May 20, 2013 at 10:19 AM, Suresh Kumar N. <suri.injun-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

To get start please visit www.bluez.org, there is some documentation
about the D-Bus API under doc but you can read the source code which
is the best documentation one can get.


--
Luiz Augusto von Dentz

Re: [PATCH v3] Bluetooth: hidp: using strlcpy instead of strncpy, also beautify code.

Gustavo Padovan — 2013-05-20T21:52:24

Hi Chen,

* Chen Gang <gang.chen-bOixZGp5f+dBDgjK7y7TUQ< at >public.gmane.org> [2013-05-13 10:07:11 +0800]:


Sorry for the big delay on this, patches has now been applied to
bluetooth-next. Thanks all.

Gustavo

Re: [PATCHv2 2/2] Bluetooth: Remove unneeded flag

Gustavo Padovan — 2013-05-20T21:44:32

Hi Andrei,

* Gustavo Padovan <gustavo-THi1TnShQwVAfugRpC6u6w< at >public.gmane.org> [2013-05-20 17:59:41 -0300]:


I was told by Johan that this only happens in your experimental code, so both
patches are now applied to bluetooth-next nad not anymore to bluetooth.git.
Thanks.

Gustavo

Re: [PATCHv2 2/2] Bluetooth: Remove unneeded flag

Gustavo Padovan — 2013-05-20T20:59:41

Hi Andrei,

* Andrei Emeltchenko <Andrei.Emeltchenko.news-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> [2013-05-14 11:44:17 +0300]:


Since patch one went to bluetooth.git, I'll have to wait for a merge of both
trees to apply this one. Once the bluetooth.git gets merged in
bluetooth-next.git I'll apply this patch.

Gustavo