* [PATCH 1/3] avdtp: Remove not used pending_auth from struct avdtp
From: Szymon Janc @ 2013-09-11 13:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
---
profiles/audio/avdtp.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c
index 818dbdd..61f55d6 100644
--- a/profiles/audio/avdtp.c
+++ b/profiles/audio/avdtp.c
@@ -41,7 +41,6 @@
#include <bluetooth/sdp_lib.h>
#include <glib.h>
-#include <dbus/dbus.h>
#include <btio/btio.h>
#include "log.h"
@@ -426,8 +425,6 @@ struct avdtp {
/* Attempt stream setup instead of disconnecting */
gboolean stream_setup;
-
- DBusPendingCall *pending_auth;
};
static GSList *servers = NULL;
@@ -2325,12 +2322,8 @@ static struct avdtp *avdtp_get_internal(struct btd_device *device)
return NULL;
session = find_session(server->sessions, device);
- if (session) {
- if (session->pending_auth)
- return NULL;
- else
- return session;
- }
+ if (session)
+ return session;
session = g_new0(struct avdtp, 1);
--
1.8.4
^ permalink raw reply related
* [Bluetooth Low Energy] Pairing and writing characteristic property issue
From: Nedim Hadzic @ 2013-09-11 12:34 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Hello everyone,
Recently I started working with Bluetooth Low Energy devices on Linux (developing some applications, testing devices etc). I am using two Bluetooth Low Energy devices SensorTag from Texas Instruments and HearRateMonitor BlueHR.
Bluez version: 4.101-0ubuntu8b1
SensorTag: I can connect to the device, read and write characteristic values using gatttool and I can pair with the device using a simple-agent tool for this. After I pair with the device, I want to change value of the characteristic using org.bluez.Characteristic interface and SetProperty method, but it does not change; nor PropertyChanged signal is emitted nor I get any error. I checked hcidump:
2013-09-11 12:07:15.827211 < ACL data: handle 75 flags 0x00 dlen 8
ATT: Write cmd (0x52)
handle 0x0029 value 0x01
In case of changing the characteristic value with gatttool hcidump is following:
2013-09-11 12:20:07.239012 < ACL data: handle 75 flags 0x00 dlen 8
ATT: Write req (0x12)
handle 0x0029 value 0x01
Difference is in part of write cmd and req. Only difference between these two approaches is that with gatttool, you first connect to LE device (LE Create Connection in hcidump), and in hcdump when accessing through interface and using method SetProperty there is no interface or method for connecting. Any guesses what can be done?
HearRateMonitor: I can connect to the device, read characteristic values using gatttool ( with adding "-t random" part to the command), but I can not pair with the device using simple-agent: Error: Creating device failed: org.bluez.Error.AuthenticationFailed: Authentication Failed.
Hcidump is the following:
2013-09-11 11:58:41.747749 < HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr D5:EA:8B:A9:EC:70 type 1
2013-09-11 11:58:41.751989 > HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
2013-09-11 11:58:44.311996 > HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 75, role master
bdaddr D5:EA:8B:A9:EC:70 (Random)
2013-09-11 11:58:44.312173 < ACL data: handle 75 flags 0x00 dlen 11
SMP: Pairing Request (0x01)
capability 0x04 oob 0x00 auth req 0x01
max key size 0x10 init key dist 0x00 resp key dist 0x01
Capability: KeyboardDisplay (OOB data not present)
Authentication: Bonding (No MITM Protection)
Initiator Key Distribution:
Responder Key Distribution: LTK
2013-09-11 11:58:44.348985 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 75 packets 1
2013-09-11 11:58:44.418969 > ACL data: handle 75 flags 0x02 dlen 6
SMP: Pairing Failed (0x05)
reason 0x05
Reason Pairing Not Supported
2013-09-11 11:58:44.560004 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 75 reason 0x13
Reason: Remote User Terminated Connection
This device is using random device address, but I do not know how to pair with it in that case. I try to pair with it using a smartphone with support and it is working. Any help, or input on this?
Looking forward to reply;
Kind regards,
Nedim Hadzic
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
^ permalink raw reply
* [PATCH 2/2] Bluetooth: Fix rfkill functionality during the HCI setup stage
From: johan.hedberg @ 2013-09-11 11:33 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378899239-5138-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
We need to let the setup stage complete cleanly even when the HCI device
is rfkilled. Otherwise the HCI device will stay in an undefined state
and never get notified to user space through mgmt (even when it gets
unblocked through rfkill).
This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
stage, that blocking the device doesn't abort the setup stage, and that
the device gets proper powered down as soon as the setup stage completes
in case it was blocked meanwhile.
The bug that this patch fixed can be very easily reproduced using e.g.
the rfkill command line too. By running "rfkill block all" before
inserting a Bluetooth dongle the resulting HCI device goes into a state
where it is never announced over mgmt, not even when "rfkill unblock all"
is run.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
---
net/bluetooth/hci_core.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 70efa16..3ff99f2 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1148,7 +1148,11 @@ int hci_dev_open(__u16 dev)
goto done;
}
- if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
+ /* Check for rfkill but allow the HCI setup stage to proceed
+ * (which in itself doesn't cause any RF activity).
+ */
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags) &&
+ !test_bit(HCI_SETUP, &hdev->dev_flags)) {
ret = -ERFKILL;
goto done;
}
@@ -1599,7 +1603,8 @@ static int hci_rfkill_set_block(void *data, bool blocked)
if (blocked) {
set_bit(HCI_RFKILLED, &hdev->dev_flags);
- hci_dev_do_close(hdev);
+ if (!test_bit(HCI_SETUP, &hdev->dev_flags))
+ hci_dev_do_close(hdev);
} else {
clear_bit(HCI_RFKILLED, &hdev->dev_flags);
}
@@ -1624,6 +1629,11 @@ static void hci_power_on(struct work_struct *work)
return;
}
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
+ clear_bit(HCI_AUTO_OFF, &hdev->dev_flags);
+ hci_dev_do_close(hdev);
+ }
+
if (test_bit(HCI_AUTO_OFF, &hdev->dev_flags))
queue_delayed_work(hdev->req_workqueue, &hdev->power_off,
HCI_AUTO_OFF_TIMEOUT);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 1/2] Bluetooth: Introduce a new HCI_RFKILLED flag
From: johan.hedberg @ 2013-09-11 11:33 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378899239-5138-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
This makes it more convenient to check for rfkill (no need to check for
dev->rfkill before calling rfkill_blocked()) and also avoids potential
races if the RFKILL state needs to be checked from within the rfkill
callback.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
---
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_core.c | 12 +++++++-----
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 30c88b5..ba008d5 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -104,6 +104,7 @@ enum {
enum {
HCI_SETUP,
HCI_AUTO_OFF,
+ HCI_RFKILLED,
HCI_MGMT,
HCI_PAIRABLE,
HCI_SERVICE_CACHE,
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 4dbb6cb..70efa16 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1148,7 +1148,7 @@ int hci_dev_open(__u16 dev)
goto done;
}
- if (hdev->rfkill && rfkill_blocked(hdev->rfkill)) {
+ if (test_bit(HCI_RFKILLED, &hdev->dev_flags)) {
ret = -ERFKILL;
goto done;
}
@@ -1597,10 +1597,12 @@ static int hci_rfkill_set_block(void *data, bool blocked)
if (test_bit(HCI_USER_CHANNEL, &hdev->dev_flags))
return -EBUSY;
- if (!blocked)
- return 0;
-
- hci_dev_do_close(hdev);
+ if (blocked) {
+ set_bit(HCI_RFKILLED, &hdev->dev_flags);
+ hci_dev_do_close(hdev);
+ } else {
+ clear_bit(HCI_RFKILLED, &hdev->dev_flags);
+ }
return 0;
}
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 0/2] Bluetooth: Fix race condition with rfkill handling
From: johan.hedberg @ 2013-09-11 11:33 UTC (permalink / raw)
To: linux-bluetooth
Hi,
These two patches fix a pretty severe (hence Cc: stable) race condition
with rfkill handling. If a device gets rfkilled before the HCI setup
stage completes it stays unaccessible through the mgmt interface even it
eventually gets unblocked through rfkill.
The situation is easy to reproduce by running "rfkill block all" before
inserting a dongle, "rfkill unblock all" a bit later and then trying
to do e.g. "btmgmt info". The device will not show up there.
Johan
----------------------------------------------------------------
Johan Hedberg (2):
Bluetooth: Introduce a new HCI_RFKILLED flag
Bluetooth: Fix rfkill functionality during the HCI setup stage
include/net/bluetooth/hci.h | 1 +
net/bluetooth/hci_core.c | 22 +++++++++++++++++-----
2 files changed, 18 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] Change __FUNCTION__ to __func__
From: Johan Hedberg @ 2013-09-11 10:23 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1378454530-24686-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Fri, Sep 06, 2013, Andrei Emeltchenko wrote:
> checkpatch.pl recommends to use __func__ instead of __FUNCTION__.
> ---
> attrib/gattrib.c | 2 +-
> gobex/gobex-debug.h | 2 +-
> obexd/src/log.h | 2 +-
> src/log.h | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
I've applied this patch with a more thorough explanation in the commit
message.
Johan
^ permalink raw reply
* Re: Can't initialize a Bluetooth antenna.
From: atar @ 2013-09-11 10:02 UTC (permalink / raw)
To: Gustavo Padovan; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CAFsbExJKeWnm-xFjh=E4iZjHLpSJHdAZLyKJpu2XKpvp8Zpq+w@mail.gmail.com>
Gustavo Padovan <gustavo@padovan.org> wrote:
> Hi Atar,
>
> Please don't forget to CC the linux-bluetooth mailing list when
> replying to e-mails.
>
> On Tue, Sep 10, 2013 at 10:43 PM, atar <atar.yosef@gmail.com> wrote:
>> 'hciconfig hci0 up', Gustavo Padovan <gustavo@padovan.org> wrote:
>>>
>>> Hi Atar,
>>>
>>>> 2013-09-09 atar <atar.yosef@gmail.com>:
>>>
>>>
>>>> Hi there!!
>>>>
>>>> When I try to use the hciconfig command to initialized my Bluetooth
>>>> antenna like the command:
>>>>
>>>> hciconfig hci0 up OR hciconfig hci0 reset
>>>>
>>>> it emits an error message saying:
>>>>
>>>> Can't init device hci0: Connection timed out (110).
>
> which kernel are you running? can you provide the output of
> /sys/kernel/debug/usb/devices for the bluetooth controller.
>
> Gustavo
Hi Gustavo!
here's the output of the 'uname -a' command:
Linux linuxbox 3.2.0-4-686-pae #1 SMP Debian 3.2.46-1+deb7u1 i686 GNU/Linux
unfortunately, my Distro don't have a /sys/kernel/debug/usb/devices file.
Regards,
atar.
^ permalink raw reply
* Re: Can't initialize a Bluetooth antenna.
From: Gustavo Padovan @ 2013-09-10 21:08 UTC (permalink / raw)
To: atar; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <op.w27ta0kge4gg2u@localhost>
Hi Atar,
Please don't forget to CC the linux-bluetooth mailing list when
replying to e-mails.
On Tue, Sep 10, 2013 at 10:43 PM, atar <atar.yosef@gmail.com> wrote:
> 'hciconfig hci0 up', Gustavo Padovan <gustavo@padovan.org> wrote:
>>
>> Hi Atar,
>>
>>> 2013-09-09 atar <atar.yosef@gmail.com>:
>>
>>
>>> Hi there!!
>>>
>>> When I try to use the hciconfig command to initialized my Bluetooth
>>> antenna like the command:
>>>
>>> hciconfig hci0 up OR hciconfig hci0 reset
>>>
>>> it emits an error message saying:
>>>
>>> Can't init device hci0: Connection timed out (110).
which kernel are you running? can you provide the output of
/sys/kernel/debug/usb/devices for the bluetooth controller.
Gustavo
^ permalink raw reply
* Device discovery/pairing issue w/ BlueZ on Debian
From: Clemens Vasters @ 2013-09-10 18:47 UTC (permalink / raw)
To: linux-bluetooth
I’ve got a cheap Bluetooth car diagnostics dongle (OBD-2, ELM327) that
gets discovered by and pairs with Windows 8, Windows Phone 8, OSX
Mountain Lion, iOS 6, and Android Jelly Bean.
I can’t get it to be either discovered or paired with BlueZ on Debian
Wheezy on my Notebook (bare metal, ThinkPad W510) or Raspbian Wheezy
on the Raspberry Pi. On the latter I even went so far to pull the
source for BlueZ 5.8 and install it from source. No dice.
I’m pretty puzzled about this. How would I go about debugging or,
rather, what data do I need to gather (and how) for someone to help me
with this.
Thanks
Clemens
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add Intel Bluetooth Bootloader driver
From: Marcel Holtmann @ 2013-09-10 18:22 UTC (permalink / raw)
To: Fry, Don
Cc: An, Tedd, linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
Hedberg, Johan
In-Reply-To: <CE54ABF8.3D4D%don.fry@intel.com>
Hi Don,
small reminder to not top post on this mailing list please
> What is the status of this patch? Is it something that can go upstream
> or does it need more rework?
I have not had a chance too look at it in detail. I will try to get to it by the end of this week.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add Intel Bluetooth Bootloader driver
From: Fry, Don @ 2013-09-10 18:00 UTC (permalink / raw)
To: An, Tedd, linux-bluetooth@vger.kernel.org, gustavo@padovan.org
Cc: marcel@holtmann.org, Hedberg, Johan
In-Reply-To: <1979791.SXvDHP8xUh@tedd-ubuntu>
Hi Gustavo,
What is the status of this patch? Is it something that can go upstream
or does it need more rework?
Thanks,
Don
On 8/23/13 9:21 AM, "An, Tedd" <tedd.an@intel.com> wrote:
>From: Tedd Ho-Jeong An <tedd.an@intel.com>
>
>This patch adds Intel Bluetooth Bootloader driver for Intel BT device.
>
>It downloads the full FW image file from firmware/intel to the device.
>Once downloading is done successfully, the device reset and bootup as
>Bluetooth class device.
>
>Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
>Tested-by: Don Fry <don.fry@intel.com>
>---
> drivers/bluetooth/Kconfig | 13 ++
> drivers/bluetooth/Makefile | 1 +
> drivers/bluetooth/intel_bl.c | 370
>++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 384 insertions(+)
> create mode 100644 drivers/bluetooth/intel_bl.c
>
>diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
>index fdfd61a..060dd10 100644
>--- a/drivers/bluetooth/Kconfig
>+++ b/drivers/bluetooth/Kconfig
>@@ -242,4 +242,17 @@ config BT_WILINK
>
> Say Y here to compile support for Texas Instrument's WiLink7 driver
> into the kernel or say M to compile it as module.
>+
>+config BT_INTEL_BL
>+ tristate "Intel firmware download driver"
>+ depends on USB
>+ select FW_LOADER
>+ help
>+ Intel Bluetooth firmware download driver.
>+ This driver loads the full firmware into the Intel Bluetooth
>+ chipset.
>+
>+ Say Y here to compile support for "Intel firmware download driver"
>+ into the kernel or say M to compile it as module.
>+
> endmenu
>diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
>index 4afae20..edfcdb5 100644
>--- a/drivers/bluetooth/Makefile
>+++ b/drivers/bluetooth/Makefile
>@@ -19,6 +19,7 @@ obj-$(CONFIG_BT_ATH3K) += ath3k.o
> obj-$(CONFIG_BT_MRVL) += btmrvl.o
> obj-$(CONFIG_BT_MRVL_SDIO) += btmrvl_sdio.o
> obj-$(CONFIG_BT_WILINK) += btwilink.o
>+obj-$(CONFIG_BT_INTEL_BL) += intel_bl.o
>
> btmrvl-y := btmrvl_main.o
> btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
>diff --git a/drivers/bluetooth/intel_bl.c b/drivers/bluetooth/intel_bl.c
>new file mode 100644
>index 0000000..4c8296b
>--- /dev/null
>+++ b/drivers/bluetooth/intel_bl.c
>@@ -0,0 +1,387 @@
>+/*
>+ *
>+ * Intel Bluetooth BootLoader driver
>+ *
>+ * Copyright (C) 2012 Intel Corporation
>+ *
>+ *
>+ * This program is free software; you can redistribute it and/or modify
>+ * it under the terms of the GNU General Public License as published by
>+ * the Free Software Foundation; either version 2 of the License, or
>+ * (at your option) any later version.
>+ *
>+ * This program is distributed in the hope that it will be useful,
>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>+ * GNU General Public License for more details.
>+ *
>+ * You should have received a copy of the GNU General Public License
>+ * along with this program; if not, write to the Free Software
>+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
> USA
>+ *
>+ */
>+#include <linux/module.h>
>+#include <linux/errno.h>
>+#include <linux/usb.h>
>+#include <linux/firmware.h>
>+
>+#include <net/bluetooth/bluetooth.h>
>+#include <net/bluetooth/hci_core.h>
>+
>+#define VERSION "1.0"
>+
>+static struct usb_driver intel_bl_driver;
>+
>+static const struct usb_device_id intel_bl_table[] = {
>+ /* Intel Bluetooth USB BootLoader(RAM module) */
>+ { USB_DEVICE(0x8087, 0x0A5A) },
>+
>+ { } /* Terminating entry */
>+};
>+MODULE_DEVICE_TABLE(usb, intel_bl_table);
>+
>+#define MAX_DATA_SIZE 260
>+
>+#define CMD_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
>+
>+struct intel_version {
>+ u8 status;
>+ u8 hw_platform;
>+ u8 hw_variant;
>+ u8 hw_revision;
>+ u8 fw_variant;
>+ u8 fw_revision;
>+ u8 fw_build_num;
>+ u8 fw_build_ww;
>+ u8 fw_build_yy;
>+ u8 fw_patch_num;
>+} __packed;
>+
>+struct intel_bl_data {
>+ struct usb_device *udev;
>+
>+ u8 evt_buff[MAX_DATA_SIZE];
>+ int evt_len;
>+
>+ struct work_struct work;
>+ atomic_t shutdown;
>+};
>+
>+static int intel_bl_send_cmd_sync(struct intel_bl_data *data,
>+ const u8 *cmd_buff, int cmd_len, u32 timeout)
>+{
>+ u8 *buff;
>+ int err;
>+
>+ BT_DBG("send cmd len %d", cmd_len);
>+
>+ buff = kmalloc(cmd_len, GFP_KERNEL);
>+ if (!buff)
>+ return -ENOMEM;
>+
>+ memcpy(buff, cmd_buff, cmd_len);
>+
>+ err = usb_control_msg(data->udev, usb_sndctrlpipe(data->udev, 0x00),
>+ 0, USB_TYPE_CLASS, 0, 0,
>+ buff, cmd_len, USB_CTRL_SET_TIMEOUT);
>+ if (err < 0) {
>+ BT_ERR("failed to send control message (%d)", err);
>+ goto exit_error;
>+ }
>+
>+ err = usb_interrupt_msg(data->udev, usb_rcvintpipe(data->udev, 0x81),
>+ data->evt_buff, MAX_DATA_SIZE, &data->evt_len,
>+ 5000);
>+ if (err < 0) {
>+ BT_ERR("failed to receive interrupt message (%d)", err);
>+ goto exit_error;
>+ }
>+
>+ BT_DBG("received event(%d): %02x %02x %02x %02x %02x %02x",
>+ data->evt_len, data->evt_buff[0], data->evt_buff[1],
>+ data->evt_buff[2], data->evt_buff[3], data->evt_buff[4],
>+ data->evt_buff[5]);
>+
>+exit_error:
>+ kfree(buff);
>+
>+ return err;
>+}
>+
>+static const struct firmware *intel_bl_get_fw(struct intel_bl_data *data,
>+ struct intel_version *ver)
>+{
>+ const struct firmware *fw;
>+ char fwname[64];
>+ int err;
>+
>+ snprintf(fwname, sizeof(fwname),
>+ "intel/ibt-hw-%x.%x.%x-fw-%x.%x.%x.%x.%x.bseq",
>+ ver->hw_platform, ver->hw_variant, ver->hw_revision,
>+ ver->fw_variant, ver->fw_revision, ver->fw_build_num,
>+ ver->fw_build_ww, ver->fw_build_yy);
>+
>+ BT_INFO("Intel Bluetooth firmware file: %s", fwname);
>+
>+ err = request_firmware(&fw, fwname, &data->udev->dev);
>+ if (err < 0) {
>+ BT_ERR("failed to open the Intel firmware file (%d)", err);
>+ return NULL;
>+ }
>+
>+ return fw;
>+}
>+
>+static int intel_bl_downloading(struct intel_bl_data *data,
>+ const struct firmware *fw,
>+ const u8 **fw_ptr)
>+{
>+ struct hci_command_hdr *cmd;
>+ const u8 *cmd_ptr;
>+ struct hci_event_hdr *evt = NULL;
>+ const u8 *evt_ptr = NULL;
>+ int err;
>+
>+ int remain = fw->size - (*fw_ptr - fw->data);
>+
>+ if (atomic_read(&data->shutdown)) {
>+ BT_ERR("firmware download aborted.");
>+ return -EFAULT;
>+ }
>+
>+ BT_DBG("downloading fw data: remain %d", remain);
>+
>+
>+ if (remain <= HCI_COMMAND_HDR_SIZE || *fw_ptr[0] != 0x01) {
>+ BT_ERR("fw file is corrupted: invalid cmd read");
>+ return -EINVAL;
>+ }
>+ (*fw_ptr)++;
>+ remain--;
>+
>+ cmd = (struct hci_command_hdr *)(*fw_ptr);
>+ cmd_ptr = *fw_ptr;
>+
>+ /* push HCI command header */
>+ *fw_ptr += sizeof(*cmd);
>+ remain -= sizeof(*cmd);
>+
>+ if (remain < cmd->plen) {
>+ BT_ERR("fw file is corrupted. invalid cmd len");
>+ return -EFAULT;
>+ }
>+
>+ /* push HCI command parameter */
>+ *fw_ptr += cmd->plen;
>+ remain -= cmd->plen;
>+
>+ /* read event */
>+ if (remain <= HCI_EVENT_HDR_SIZE || *fw_ptr[0] != 0x02) {
>+ BT_ERR("fw file is corrupted: invalid evt read");
>+ return -EINVAL;
>+ }
>+
>+ (*fw_ptr)++;
>+ remain--;
>+
>+ evt = (struct hci_event_hdr *)(*fw_ptr);
>+ evt_ptr = *fw_ptr;
>+
>+ /* push HCI event header */
>+ *fw_ptr += sizeof(*evt);
>+ remain -= sizeof(*evt);
>+
>+ if (remain < evt->plen) {
>+ BT_ERR("fw file is corrupted: invalid evt len");
>+ return -EFAULT;
>+ }
>+
>+ *fw_ptr += evt->plen;
>+ remain -= evt->plen;
>+
>+ err = intel_bl_send_cmd_sync(data, cmd_ptr, cmd->plen + 3, CMD_TIMEOUT);
>+ if (err) {
>+ BT_ERR("failed to send patch command %d", err);
>+ return -EFAULT;
>+ }
>+
>+ if (evt->plen + 2 != data->evt_len) {
>+ BT_ERR("mismatch event length");
>+ return -EFAULT;
>+ }
>+
>+ if (memcmp(data->evt_buff, evt_ptr, evt->plen + 2)) {
>+ BT_ERR("mismatch event parameter");
>+ return -EFAULT;
>+ }
>+
>+ return 0;
>+}
>+
>+static void intel_bl_setup(struct work_struct *work)
>+{
>+ struct intel_bl_data *data =
>+ container_of(work, struct intel_bl_data, work);
>+ const struct firmware *fw;
>+ const u8 *fw_ptr;
>+ struct intel_version *ver;
>+ int err;
>+
>+ const u8 get_version[] = { 0x05, 0xFC, 0x00 };
>+ const u8 mfg_enable[] = { 0x11, 0xFC, 0x02, 0x01, 0x00 };
>+ const u8 mfg_reset_deactivate[] = { 0x11, 0xFC, 0x02, 0x00, 0x01 };
>+ const u8 mfg_reset_activate[] = { 0x11, 0xFC, 0x02, 0x00, 0x02 };
>+
>+ BT_DBG("start Intel fw setup: data %p", data);
>+
>+ /* get version */
>+ err = intel_bl_send_cmd_sync(data, get_version, 3, CMD_TIMEOUT);
>+ if (err < 0) {
>+ BT_ERR("failed to send get_version command (%d)", err);
>+ return;
>+ }
>+
>+ BT_DBG("received get_version event");
>+ if (data->evt_len != 15) {
>+ BT_ERR("received invalid get_version event: (%d)",
>+ data->evt_len);
>+ return;
>+ }
>+
>+ ver = (struct intel_version *)&data->evt_buff[5];
>+ if (ver->status) {
>+ BT_ERR("get_version event failed (%02x)", ver->status);
>+ return;
>+ }
>+
>+ BT_DBG("Intel fw version: %02x%02x%02x%02x%02x%02x%02x%02x%02x",
>+ ver->hw_platform, ver->hw_variant, ver->hw_revision,
>+ ver->fw_variant, ver->fw_revision, ver->fw_build_num,
>+ ver->fw_build_ww, ver->fw_build_yy, ver->fw_patch_num);
>+
>+ if (ver->fw_patch_num) {
>+ BT_INFO("fw is already loaded. skip the downloading");
>+ return;
>+ }
>+
>+ fw = intel_bl_get_fw(data, ver);
>+ if (!fw)
>+ return;
>+
>+ fw_ptr = fw->data;
>+
>+ /* make sure the first byte is FF */
>+ if (fw->data[0] != 0xFF) {
>+ BT_ERR("invalid fw image file: %02x", fw->data[0]);
>+ release_firmware(fw);
>+ return;
>+ }
>+ fw_ptr++;
>+
>+ /* enter mfg mode */
>+ err = intel_bl_send_cmd_sync(data, mfg_enable, 5, CMD_TIMEOUT);
>+ if (err < 0) {
>+ BT_ERR("failed to enable mfg mode (%d)", err);
>+ release_firmware(fw);
>+ return;
>+ }
>+
>+ while (fw->size > fw_ptr - fw->data) {
>+ err = intel_bl_downloading(data, fw, &fw_ptr);
>+ if (err < 0) {
>+ release_firmware(fw);
>+ goto exit_mfg_deactivate;
>+ }
>+ }
>+
>+ release_firmware(fw);
>+
>+ /* patching success */
>+ err = intel_bl_send_cmd_sync(data, mfg_reset_activate, 5, CMD_TIMEOUT);
>+ if (err < 0) {
>+ BT_ERR("failed to disable mfg mode: (%d)", err);
>+ return;
>+ }
>+
>+ BT_INFO("Intel fw downloading is completed");
>+
>+ return;
>+
>+exit_mfg_deactivate:
>+ err = intel_bl_send_cmd_sync(data, mfg_reset_deactivate, 5,
>+ CMD_TIMEOUT);
>+ if (err < 0) {
>+ BT_ERR("failed to disable mfg mode(deactivate fw): (%d)", err);
>+ return;
>+ }
>+
>+ BT_INFO("device is reset without enabling fw");
>+ return;
>+
>+}
>+
>+static int intel_bl_probe(struct usb_interface *intf,
>+ const struct usb_device_id *id)
>+{
>+ struct intel_bl_data *data;
>+ int err;
>+
>+ BT_DBG("intf %p id %p", intf, id);
>+
>+ /* interface numbers are hardcoded in the spec */
>+ if (intf->cur_altsetting->desc.bInterfaceNumber != 0)
>+ return -ENODEV;
>+
>+ data = devm_kzalloc(&intf->dev, sizeof(*data), GFP_KERNEL);
>+ if (!data)
>+ return -ENOMEM;
>+
>+ data->udev = interface_to_usbdev(intf);
>+
>+ usb_set_intfdata(intf, data);
>+
>+ /* There is a bug in the bootloader that interrupt interface is only
>+ * enabled after receiving SetInterface(0, AltSetting=0).
>+ */
>+ err = usb_set_interface(data->udev, 0, 0);
>+ if (err < 0) {
>+ BT_ERR("failed to set interface 0, alt 0 %d", err);
>+ return err;
>+ }
>+
>+ INIT_WORK(&data->work, intel_bl_setup);
>+
>+ /* use workqueue to have a small delay */
>+ schedule_work(&data->work);
>+
>+ return 0;
>+}
>+
>+static void intel_bl_disconnect(struct usb_interface *intf)
>+{
>+ struct intel_bl_data *data = usb_get_intfdata(intf);
>+
>+ BT_DBG("intf %p", intf);
>+
>+ atomic_inc(&data->shutdown);
>+ cancel_work_sync(&data->work);
>+
>+ BT_DBG("intel_bl_disconnect");
>+
>+ usb_set_intfdata(intf, NULL);
>+}
>+
>+static struct usb_driver intel_bl_driver = {
>+ .name = "intel_bl",
>+ .probe = intel_bl_probe,
>+ .disconnect = intel_bl_disconnect,
>+ .id_table = intel_bl_table,
>+ .disable_hub_initiated_lpm = 1,
>+};
>+
>+module_usb_driver(intel_bl_driver);
>+
>+MODULE_AUTHOR("Tedd Ho-Jeong An <tedd.an@intel.com>");
>+MODULE_DESCRIPTION("Intel Bluetooth USB Bootloader driver ver " VERSION);
>+MODULE_VERSION(VERSION);
>+MODULE_LICENSE("GPL");
>--
>1.7.9.5
>
>
>--
>Regards
>Tedd Ho-Jeong An
>Intel Corporation
^ permalink raw reply
* [PATCH 3/3] profile: Remove support for Cancel method
From: Denis Kenzior @ 2013-09-10 16:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Denis Kenzior
In-Reply-To: <1378831343-3534-1-git-send-email-denkenz@gmail.com>
---
src/profile.c | 18 ------------------
1 file changed, 18 deletions(-)
diff --git a/src/profile.c b/src/profile.c
index 57aead7..523e119 100644
--- a/src/profile.c
+++ b/src/profile.c
@@ -678,20 +678,9 @@ static struct ext_profile *find_ext_profile(const char *owner,
return NULL;
}
-static void ext_cancel(struct ext_profile *ext)
-{
- DBusMessage *msg;
-
- msg = dbus_message_new_method_call(ext->owner, ext->path,
- "org.bluez.Profile1", "Cancel");
- if (msg)
- g_dbus_send_message(btd_get_dbus_connection(), msg);
-}
-
static void ext_io_destroy(gpointer p)
{
struct ext_io *ext_io = p;
- struct ext_profile *ext = ext_io->ext;
if (ext_io->io_id > 0)
g_source_remove(ext_io->io_id);
@@ -711,7 +700,6 @@ static void ext_io_destroy(gpointer p)
if (ext_io->pending) {
dbus_pending_call_cancel(ext_io->pending);
dbus_pending_call_unref(ext_io->pending);
- ext_cancel(ext);
}
if (ext_io->resolving)
@@ -783,9 +771,6 @@ static void new_conn_reply(DBusPendingCall *call, void *user_data)
btd_service_connecting_complete(conn->service, -ECONNREFUSED);
- if (dbus_error_has_name(&err, DBUS_ERROR_NO_REPLY))
- ext_cancel(ext);
-
dbus_error_free(&err);
ext->conns = g_slist_remove(ext->conns, conn);
@@ -817,9 +802,6 @@ static void disconn_reply(DBusPendingCall *call, void *user_data)
btd_service_disconnecting_complete(conn->service, -ECONNREFUSED);
- if (dbus_error_has_name(&err, DBUS_ERROR_NO_REPLY))
- ext_cancel(ext);
-
dbus_error_free(&err);
disconnect:
--
1.8.1.5
^ permalink raw reply related
* [PATCH 2/3] doc: Remove Profile1.Cancel() method
From: Denis Kenzior @ 2013-09-10 16:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Denis Kenzior
In-Reply-To: <1378831343-3534-1-git-send-email-denkenz@gmail.com>
There does not seem to be any actual need for this method.
The current implementation calls Cancel when a pending
NewConnection() or RequestDisconnection() method call fails.
Additionally it calls Cancel() when the remote client has disconnected.
In either case BlueZ calls shutdown on the file descriptor associated
with the agent and issues a Cancel() method call.
The closing of the file descriptor will trigger a HUP on the agent side,
which will trigger normal cleanup procedures. The received Cancel()
method call is redundant in both cases.
---
doc/profile-api.txt | 8 --------
1 file changed, 8 deletions(-)
diff --git a/doc/profile-api.txt b/doc/profile-api.txt
index 96cfce9..ec18034 100644
--- a/doc/profile-api.txt
+++ b/doc/profile-api.txt
@@ -145,11 +145,3 @@ Methods void Release() [noreply]
Possible errors: org.bluez.Error.Rejected
org.bluez.Error.Canceled
-
- void Cancel()
-
- This method gets called to indicate that the profile
- request failed before a reply was returned.
-
- All request are queued and there will be only one
- pending pequest at a time per profile.
--
1.8.1.5
^ permalink raw reply related
* [PATCH 1/3] doc: Label Profile1.Release() method as no reply
From: Denis Kenzior @ 2013-09-10 16:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Denis Kenzior
The current implementation does not expect a reply, nor would it make
sense for BlueZ to wait for one from the agent. So explicitly label
this method as noreply.
---
doc/profile-api.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/profile-api.txt b/doc/profile-api.txt
index 03b7d2b..96cfce9 100644
--- a/doc/profile-api.txt
+++ b/doc/profile-api.txt
@@ -108,7 +108,7 @@ Service unique name
Interface org.bluez.Profile1
Object path freely definable
-Methods void Release()
+Methods void Release() [noreply]
This method gets called when the service daemon
unregisters the profile. A profile can use it to do
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH bluetooth-next] Bluetooth: Add support for BCM20702A0 [0a5c, 21e6]
From: Dan Aloni @ 2013-09-10 16:14 UTC (permalink / raw)
To: Gustavo Padovan, Marcel Holtmann, linux-bluetooth, linux-kernel,
Johan Hedberg
In-Reply-To: <20130910154532.GB1916@joana>
On Tue, Sep 10, 2013 at 04:45:32PM +0100, Gustavo Padovan wrote:
> Hi Dan,
>
> 2013-09-03 Dan Aloni <alonid@postram.com>:
>
> > Tested with this patch and a Bluetooth mouse on 3.10.10, on ThinkPad W530.
> >
> > Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
> >
> > T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
> > D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> > P: Vendor=0a5c ProdID=21e6 Rev=01.12
> > S: Manufacturer=Broadcom Corp
> > S: Product=BCM20702A0
> > S: SerialNumber=F4B7E2F6E438
> > C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
> > I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> > I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> > I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> > I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
> >
> > Signed-off-by: Dan Aloni <alonid@postram.com>
> > ---
> > drivers/bluetooth/btusb.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index de4cf4d..e6313f8 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -104,6 +104,7 @@ static struct usb_device_id btusb_table[] = {
> > { USB_DEVICE(0x0b05, 0x17b5) },
> > { USB_DEVICE(0x04ca, 0x2003) },
> > { USB_DEVICE(0x0489, 0xe042) },
> > + { USB_DEVICE(0x0a5c, 0x21e6) },
>
> In which kernel have you seen this issue? We have a generic rule to catch all
> 0x0a5c Broadcom devices. And before we added this the device ID for your
> device was there, so in theory your device always worked.
Seem you are correct. I verified just now that on 3.10.11 the device is
detected without the patch.
Originally I rebased this patch for my laptop's kernel without noticing it
isn't needed anymore.
--
Dan Aloni
^ permalink raw reply
* Re: Can't initialize a Bluetooth antenna.
From: Gustavo Padovan @ 2013-09-10 15:51 UTC (permalink / raw)
To: atar; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <op.w24t4yu9e4gg2u@localhost>
Hi Atar,
2013-09-09 atar <atar.yosef@gmail.com>:
> Hi there!!
>
> When I try to use the hciconfig command to initialized my Bluetooth
> antenna like the command:
>
> hciconfig hci0 up OR hciconfig hci0 reset
>
> it emits an error message saying:
>
> Can't init device hci0: Connection timed out (110).
Could you please collect logs with hcidump or btmon and send them to us?
Gustavo
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Only schedule raw queue when user channel is active
From: Gustavo Padovan @ 2013-09-10 15:49 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1378256918-50836-2-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-09-03 Marcel Holtmann <marcel@holtmann.org>:
> When the user channel is set and an user application has full control
> over the device, do not bother trying to schedule any queues except
> the raw queue.
>
> This is an optimization since with user channel, only the raw queue
> is in use.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_core.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Use GFP_KERNEL when cloning SKB in a workqueue
From: Gustavo Padovan @ 2013-09-10 15:48 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1378257067-52933-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-09-03 Marcel Holtmann <marcel@holtmann.org>:
> There is no need to use GFP_ATOMIC with skb_clone() when the code is
> executed in a workqueue.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Disable upper layer connections when user channel is active
From: Gustavo Padovan @ 2013-09-10 15:47 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1378256918-50836-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-09-03 Marcel Holtmann <marcel@holtmann.org>:
> When the device has the user channel flag set, it means it is driven by
> an user application. In that case do not allow any connections from
> L2CAP or SCO sockets.
>
> This is the same situation as when the device has the raw flag set and
> it will then return EHOSTUNREACH.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_conn.c | 1 +
> 1 file changed, 1 insertion(+)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH bluetooth-next] Bluetooth: Add support for BCM20702A0 [0a5c, 21e6]
From: Gustavo Padovan @ 2013-09-10 15:45 UTC (permalink / raw)
To: Dan Aloni; +Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, Johan Hedberg
In-Reply-To: <1378208542-30729-1-git-send-email-alonid@postram.com>
Hi Dan,
2013-09-03 Dan Aloni <alonid@postram.com>:
> Tested with this patch and a Bluetooth mouse on 3.10.10, on ThinkPad W530.
>
> Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
>
> T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0a5c ProdID=21e6 Rev=01.12
> S: Manufacturer=Broadcom Corp
> S: Product=BCM20702A0
> S: SerialNumber=F4B7E2F6E438
> C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
> I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
>
> Signed-off-by: Dan Aloni <alonid@postram.com>
> ---
> drivers/bluetooth/btusb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index de4cf4d..e6313f8 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -104,6 +104,7 @@ static struct usb_device_id btusb_table[] = {
> { USB_DEVICE(0x0b05, 0x17b5) },
> { USB_DEVICE(0x04ca, 0x2003) },
> { USB_DEVICE(0x0489, 0xe042) },
> + { USB_DEVICE(0x0a5c, 0x21e6) },
In which kernel have you seen this issue? We have a generic rule to catch all
0x0a5c Broadcom devices. And before we added this the device ID for your
device was there, so in theory your device always worked.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support creating virtual AMP controllers
From: Gustavo Padovan @ 2013-09-10 15:33 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1378143699-51039-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-09-02 Marcel Holtmann <marcel@holtmann.org>:
> So far the only option to create a virtual AMP controller was by
> setting a module parameter for the hci_vhci driver. This patch adds
> the functionality to define inline to create either a BR/EDR or an
> AMP controller.
>
> In addition the client will be informed which HCI controller index
> it got assigned. That is especially useful for automated end-to-end
> testing.
>
> To keep backwards compatibility with existing userspace, the command
> for creating a controller type needs to be send right after opening
> the device node. If the command is not send, it defaults back to
> automatically creating a BR/EDR controller.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> drivers/bluetooth/hci_vhci.c | 169 +++++++++++++++++++++++++++++++------------
> 1 file changed, 123 insertions(+), 46 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* AVRCP controller role
From: Nikhil Verma @ 2013-09-10 12:26 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Please let me know if AVRCP controller role is supported in Bluez 5.1 or above?
Since I am new to Bluez, please let me know if there is a test code to
understand how Bluez AVRCP controller APIs can be used.
Thanks & Regards,
Nikhil
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Samuel Ortiz @ 2013-09-10 9:46 UTC (permalink / raw)
To: Marcel Holtmann
Cc: John W.Linville, Dan Williams, linux-wireless, johannes,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <6D969CDD-C551-4C4C-A674-A7518B3EE0AC@holtmann.org>
Hi Marcel, John,
On Mon, 2013-09-09 at 13:48 -0700, Marcel Holtmann wrote:
> Hi John,
>
> >>>> Sorry, forgot to copy linux-bluetooth and linux-nfc...
> >>>>
> >>>> On Thu, Aug 08, 2013 at 02:54:11PM -0400, John W. Linville wrote:
> >>>>> Greetings!
> >>>>>
> >>>>> This is a reminder that we will have a Linux Wireless Mini-Summit in
> >>>>> New Orleans this year on 19-20 September. This will immediately follow
> >>>>> LinuxCon and will run concurrently with Linux Plumber's Conference.
> >>>>> This event includes Linux developers for wireless LAN (802.11),
> >>>>> Bluetooth, and NFC technologies. Both kernel and userland developers
> >>>>> are welcomed and heartily encouraged to attend!
> >>>>>
> >>>>> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
> >>>>>
> >>>>> The link above is a Wiki. We are using it to collect discussion
> >>>>> topics and to negotiate agenda/scheduling options for the event.
> >>>>> Please go there to record your intent to attend the event and to
> >>>>> propopse topics for discussion.
> >>>>>
> >>>>> Please be aware that in order to attend the event above one must
> >>>>> register for either LinuxCon or for Linux Plumbers Conference.
> >>>>> Act now, before those events fill-up and close their registrations!
> >>>>>
> >>>>> We are allotted one "large" room (up to ~80 people "theater style"), and
> >>>>> two "small" rooms (up to ~25 people) for this event. Based on history
> >>>>> and the numbers of contributors, the larger room will primarily be
> >>>>> for the 802.11 discussions and any "plenary" topics while the smaller
> >>>>> rooms will be for Bluetooth, NFC, and any "breakout" topics.
> >>>>>
> >>>>> So...thoughts? Topics to discuss?
> >>>
> >>> Ping? We're now just 2 weeks away!
> >>>
> >>> Is our topic list complete? It looks a bit light...
> >>>
> >>> Anyone have any input on scheduling the topics? Are there any
> >>> overlapping LPC sessions that it would make sense to work around?
> >>
> >> I'm attending though I haven't put my name on the wiki yet.
> >>
> >> Random thoughts; it doesn't look like any of these are covered in the
> >> regular LinuxConf or LPC sessions.
> >>
> >> 1) State of the Union (maybe by multiple people in the same session per
> >> their expertise), since perhaps not everyone doing eg 802.11 stuff knows
> >> what's happening in BT or NFC land, or not everyone working on a
> >> specific driver may know what new stuff their driver might need to be
> >> fixed up for. Maybe 5 minutes or less for things like:
> >>
> >> * what's under the most active development right now?
> >> * upcoming new driver, hardware, and new capabilities
> >> * new 802.11 standards
> >> * and what's coming up in the next year from the standards orgs
> >> * what people will start working on soon
> >> * what will 3.13 or 3.14 look like from a wireless perspective?
> >> * 11s mesh status?
> >> * anything interesting in wpa_supplicant land?
> >> * anything new/interesting on the Android front?
> >>
> >> 2) Bluetooth - update about what's new and what's coming up in Bluez
> >> land, and interaction with kernel 802.11 if any,
> >>
> >> 3) NFC - update about what's new and what's coming up in NFC land, where
> >> it's getting used, what the stack looks like
> >>
> >> 4) What are users having the most problems with and how these problems
> >> be fixed better/more quickly? Are they driver bugs? Are they stack
> >> bugs? Supplicant bugs? NM/GUI/etc bugs? Is there anything in our
> >> development processes that's not working as smoothly as it could be?
> >
> > Thanks, Dan -- those all look like decent discussion points.
> > I've added most of the points above to the topic list:
> >
> > http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
> >
> > Now, we need a few volunteers...
> >
> > Gustavo, can you do a session on Bluetooth developments?
> >
> > Samuel, can you cover NFC?
>
> I can do the Bluetooth part and I am just volunteering Samuel for NFC ;)
Thanks Marcel for the initiative ;)
John, I'll do the NFC part, sorry for not being able to reply earlier.
Cheers,
Samuel.
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Arend van Spriel @ 2013-09-10 7:59 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
On 09/09/2013 09:23 PM, John W. Linville wrote:
> Arend, Kalle, Johannes, Luca, etc -- anyone want to talk about driver
> developments and/or issues between drivers and mac80211 or other
> parts of the stack?
Hi John
Because of personal reasons I am not attending this year. I would have
loved to celebrate my birthday in New Orleans and have a couple of beers
with you guys. Oh well. Guess I owe you.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] build: use -lrt for clock_gettime on glibc < 2.17
From: Johan Hedberg @ 2013-09-10 7:55 UTC (permalink / raw)
To: Dirk-Jan C. Binnema; +Cc: linux-bluetooth, Dirk-Jan C. Binnema
In-Reply-To: <1378454956-26605-1-git-send-email-djcb.bulk@gmail.com>
Hi Dirk-Jan,
On Fri, Sep 06, 2013, Dirk-Jan C. Binnema wrote:
> From: "Dirk-Jan C. Binnema" <djcb@djcbsoftware.nl>
>
> glibc before 2.17 (e.g., fedora 18) requires -lrt for clock_gettime;
> add -lrt where needed in that case.
> ---
> Makefile.am | 2 +-
> configure.ac | 6 ++++--
> 2 files changed, 5 insertions(+), 3 deletions(-)
It seems Marcel went ahead and applied his own patch for this (I think
he didn't realize there was a pending one here). Could you check if
latest git now works for you?
Johan
^ 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