* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Luis R. Rodriguez @ 2013-07-31 0:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, mcgrof, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings
In-Reply-To: <20130730235508.GA25319@kroah.com>
On Tue, Jul 30, 2013 at 04:55:08PM -0700, Greg Kroah-Hartman wrote:
> On Tue, Jul 30, 2013 at 03:48:09PM -0700, Luis R. Rodriguez wrote:
> > > We are planning to take one extra step and split this into a
> > > mini-driver approach similar to what has been done for usbnet, but we
> > > are not there yet.
> >
> > Neat. Perhaps we need something that we can share with 802.11 or other
> > hardare I highly doubt we're the only ones patching ROM. Don't we even
> > patch up core CPUs? I'm wondering if firmware_class could be expanded to
> > support serialized ROM patching. The biggest hurdle I see with splititng
> > ROM patching from a single firmware is serializing that, addressing
> > revision dependencies and of course kernel dependencies.
>
> What does the firmware_class need to do here that it doesn't do today?
It will depend on the requirements for ROM patches and if or not
firmware can be split up into patches rather than getting a full
firmware.fw update for any single patch update. If ROM patches
get split up then how I can imagine driver code firmware getting
to become a pain in the ass to maintain and nasty. It'd seem
better to build relationships between these and possible patch
depdendencies on ROM and let firmware_class do the management
of that.
> > > However the ROM patching drivers need to be in the kernel since
> > > otherwise they will race with the core init sequence.
> >
> > Sure and depending on the architecture -- if this is kicked off to
> > userspace helpers or not then we may need to consider dbus in
> > kernel thing to help with speed / races, dependenecies / async
> > loading, -EPROBE_DEFER, etc.
>
> How would dbus in the kernel change anything here?
> The kernel directly loads firmware from the filesystem now, no userspace
> helpers are involved, so no need for udev, libusb, etc. And as such, no
> need for any "dbus" in the kernel to do this either.
> I don't understand how it could, please explain.
Yeah nevermind :D too much coffee today made my brain fart.
> Also note, for those not knowing, we have been working on dbus in the
> kernel (google "kdbus" for the github repo), but it is all
> outward-facing (i.e. userspace using the kdbus code to interact with
> other processes with a dbus-like protocol, not for in-kernel dbus
> things, although adding it wouldn't be that hard, just really strange.
Thanks!
Luis
^ permalink raw reply
* [PATCH v2] Bluetooth: btmrvl: add calibration data download support
From: Bing Zhao @ 2013-07-31 1:05 UTC (permalink / raw)
To: linux-bluetooth
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-wireless,
Bing Zhao, Amitkumar Karwar
From: Amitkumar Karwar <akarwar@marvell.com>
A text file containing calibration data in hex format can
be provided at following path:
/lib/firmware/mrvl/sd8797_caldata.conf
The data will be downloaded to firmware during initialization.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
v2: Remove module parameter. The calibration data will be downloaded
only when the device speicific data file is provided.
(Marcel Holtmann)
drivers/bluetooth/btmrvl_drv.h | 10 ++-
drivers/bluetooth/btmrvl_main.c | 140 +++++++++++++++++++++++++++++++++++++++-
drivers/bluetooth/btmrvl_sdio.c | 9 ++-
drivers/bluetooth/btmrvl_sdio.h | 2 +
4 files changed, 157 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index 27068d1..5ef5e84 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -23,6 +23,8 @@
#include <linux/bitops.h>
#include <linux/slab.h>
#include <net/bluetooth/bluetooth.h>
+#include <linux/ctype.h>
+#include <linux/firmware.h>
#define BTM_HEADER_LEN 4
#define BTM_UPLD_SIZE 2312
@@ -41,6 +43,8 @@ struct btmrvl_thread {
struct btmrvl_device {
void *card;
struct hci_dev *hcidev;
+ struct device *dev;
+ const char *cal_data;
u8 dev_type;
@@ -91,6 +95,7 @@ struct btmrvl_private {
#define BT_CMD_HOST_SLEEP_CONFIG 0x59
#define BT_CMD_HOST_SLEEP_ENABLE 0x5A
#define BT_CMD_MODULE_CFG_REQ 0x5B
+#define BT_CMD_LOAD_CONFIG_DATA 0x61
/* Sub-commands: Module Bringup/Shutdown Request/Response */
#define MODULE_BRINGUP_REQ 0xF1
@@ -116,10 +121,13 @@ struct btmrvl_private {
#define PS_SLEEP 0x01
#define PS_AWAKE 0x00
+#define BT_CMD_DATA_SIZE 32
+#define BT_CAL_DATA_SIZE 28
+
struct btmrvl_cmd {
__le16 ocf_ogf;
u8 length;
- u8 data[4];
+ u8 data[BT_CMD_DATA_SIZE];
} __packed;
struct btmrvl_event {
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 9a9f518..9487684 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -57,8 +57,9 @@ bool btmrvl_check_evtpkt(struct btmrvl_private *priv, struct sk_buff *skb)
ocf = hci_opcode_ocf(opcode);
ogf = hci_opcode_ogf(opcode);
- if (ocf == BT_CMD_MODULE_CFG_REQ &&
- priv->btmrvl_dev.sendcmdflag) {
+ if ((ocf == BT_CMD_MODULE_CFG_REQ ||
+ ocf == BT_CMD_LOAD_CONFIG_DATA) &&
+ priv->btmrvl_dev.sendcmdflag) {
priv->btmrvl_dev.sendcmdflag = false;
priv->adapter->cmd_complete = true;
wake_up_interruptible(&priv->adapter->cmd_wait_q);
@@ -552,6 +553,132 @@ static int btmrvl_service_main_thread(void *data)
return 0;
}
+static int btmrvl_parse_cal_cfg(const u8 *src, u32 len, u8 *dst, u32 dst_size)
+{
+ const u8 *s = src;
+ u8 *d = dst;
+ int ret;
+ u8 tmp[3];
+
+ while ((s - src) < len) {
+ if (*s && (isspace(*s) || *s == '\t')) {
+ s++;
+ continue;
+ }
+
+ if (isxdigit(*s)) {
+ if ((d - dst) >= dst_size) {
+ BT_ERR("calibration data file too big!!!");
+ return -EINVAL;
+ }
+
+ memcpy(tmp, s, 2);
+ tmp[2] = '\0';
+
+ ret = kstrtol(tmp, 16, (long *)d++);
+ if (ret < 0)
+ return ret;
+
+ s += 2;
+ } else {
+ s++;
+ }
+ }
+ if (d == dst)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int btmrvl_load_cal_data(struct btmrvl_private *priv,
+ u8 *config_data)
+{
+ struct sk_buff *skb;
+ struct btmrvl_cmd *cmd;
+ int i;
+
+ skb = bt_skb_alloc(sizeof(*cmd), GFP_ATOMIC);
+ if (!skb)
+ return -ENOMEM;
+
+ cmd = (struct btmrvl_cmd *)skb->data;
+ cmd->ocf_ogf =
+ cpu_to_le16(hci_opcode_pack(OGF, BT_CMD_LOAD_CONFIG_DATA));
+ cmd->length = BT_CMD_DATA_SIZE;
+ cmd->data[0] = 0x00;
+ cmd->data[1] = 0x00;
+ cmd->data[2] = 0x00;
+ cmd->data[3] = BT_CMD_DATA_SIZE - 4;
+
+ /* swap cal-data bytes */
+ for (i = 4; i < BT_CMD_DATA_SIZE; i++)
+ cmd->data[i] = config_data[(i/4)*8 - 1 - i];
+
+ bt_cb(skb)->pkt_type = MRVL_VENDOR_PKT;
+ skb_put(skb, sizeof(*cmd));
+ skb->dev = (void *)priv->btmrvl_dev.hcidev;
+ skb_queue_head(&priv->adapter->tx_queue, skb);
+ priv->btmrvl_dev.sendcmdflag = true;
+ priv->adapter->cmd_complete = false;
+
+ print_hex_dump_bytes("Calibration data: ",
+ DUMP_PREFIX_OFFSET, cmd->data, BT_CMD_DATA_SIZE);
+
+ wake_up_interruptible(&priv->main_thread.wait_q);
+ if (!wait_event_interruptible_timeout(priv->adapter->cmd_wait_q,
+ priv->adapter->cmd_complete,
+ msecs_to_jiffies(WAIT_UNTIL_CMD_RESP))) {
+ BT_ERR("Timeout while loading calibration data");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int
+btmrvl_process_cal_cfg(struct btmrvl_private *priv, u8 *data, u32 size)
+{
+ u8 cal_data[BT_CAL_DATA_SIZE];
+ int ret;
+
+ ret = btmrvl_parse_cal_cfg(data, size, cal_data, sizeof(cal_data));
+ if (ret)
+ return ret;
+
+ ret = btmrvl_load_cal_data(priv, cal_data);
+ if (ret) {
+ BT_ERR("Fail to load calibrate data");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int btmrvl_cal_data_config(struct btmrvl_private *priv)
+{
+ const struct firmware *cfg;
+ int ret;
+ const char *cal_data = priv->btmrvl_dev.cal_data;
+
+ if (!cal_data)
+ return 0;
+
+ ret = request_firmware(&cfg, cal_data, priv->btmrvl_dev.dev);
+ if (ret < 0) {
+ BT_DBG("Failed to get %s file, skipping cal data download",
+ cal_data);
+ ret = 0;
+ goto done;
+ }
+
+ ret = btmrvl_process_cal_cfg(priv, (u8 *)cfg->data, cfg->size);
+done:
+ if (cfg)
+ release_firmware(cfg);
+
+ return ret;
+}
+
int btmrvl_register_hdev(struct btmrvl_private *priv)
{
struct hci_dev *hdev = NULL;
@@ -583,12 +710,21 @@ int btmrvl_register_hdev(struct btmrvl_private *priv)
goto err_hci_register_dev;
}
+ ret = btmrvl_cal_data_config(priv);
+ if (ret) {
+ BT_ERR("Set cal data failed");
+ goto err_cal_data_config;
+ }
+
#ifdef CONFIG_DEBUG_FS
btmrvl_debugfs_init(hdev);
#endif
return 0;
+err_cal_data_config:
+ hci_unregister_dev(hdev);
+
err_hci_register_dev:
hci_free_dev(hdev);
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 75c2626..292fd92 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -18,7 +18,6 @@
* this warranty disclaimer.
**/
-#include <linux/firmware.h>
#include <linux/slab.h>
#include <linux/mmc/sdio_ids.h>
@@ -102,6 +101,7 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_88xx = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
.helper = "mrvl/sd8688_helper.bin",
.firmware = "mrvl/sd8688.bin",
+ .cal_data = NULL,
.reg = &btmrvl_reg_8688,
.sd_blksz_fw_dl = 64,
};
@@ -109,6 +109,7 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8787 = {
.helper = NULL,
.firmware = "mrvl/sd8787_uapsta.bin",
+ .cal_data = NULL,
.reg = &btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
@@ -116,6 +117,7 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8787 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8797 = {
.helper = NULL,
.firmware = "mrvl/sd8797_uapsta.bin",
+ .cal_data = "mrvl/sd8797_caldata.conf",
.reg = &btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
@@ -123,6 +125,7 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8797 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8897 = {
.helper = NULL,
.firmware = "mrvl/sd8897_uapsta.bin",
+ .cal_data = NULL,
.reg = &btmrvl_reg_88xx,
.sd_blksz_fw_dl = 256,
};
@@ -1006,6 +1009,7 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
struct btmrvl_sdio_device *data = (void *) id->driver_data;
card->helper = data->helper;
card->firmware = data->firmware;
+ card->cal_data = data->cal_data;
card->reg = data->reg;
card->sd_blksz_fw_dl = data->sd_blksz_fw_dl;
}
@@ -1034,6 +1038,8 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
}
card->priv = priv;
+ priv->btmrvl_dev.dev = &card->func->dev;
+ priv->btmrvl_dev.cal_data = card->cal_data;
/* Initialize the interface specific function pointers */
priv->hw_host_to_card = btmrvl_sdio_host_to_card;
@@ -1222,4 +1228,5 @@ MODULE_FIRMWARE("mrvl/sd8688_helper.bin");
MODULE_FIRMWARE("mrvl/sd8688.bin");
MODULE_FIRMWARE("mrvl/sd8787_uapsta.bin");
MODULE_FIRMWARE("mrvl/sd8797_uapsta.bin");
+MODULE_FIRMWARE("mrvl/sd8797_caldata.conf");
MODULE_FIRMWARE("mrvl/sd8897_uapsta.bin");
diff --git a/drivers/bluetooth/btmrvl_sdio.h b/drivers/bluetooth/btmrvl_sdio.h
index 43d35a6..6872d9e 100644
--- a/drivers/bluetooth/btmrvl_sdio.h
+++ b/drivers/bluetooth/btmrvl_sdio.h
@@ -85,6 +85,7 @@ struct btmrvl_sdio_card {
u32 ioport;
const char *helper;
const char *firmware;
+ const char *cal_data;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
u8 rx_unit;
@@ -94,6 +95,7 @@ struct btmrvl_sdio_card {
struct btmrvl_sdio_device {
const char *helper;
const char *firmware;
+ const char *cal_data;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
};
--
1.8.0
^ permalink raw reply related
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Johannes Berg @ 2013-07-31 6:46 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, mcgrof, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings, Greg Kroah-Hartman
In-Reply-To: <20130730224809.GN17130@pogo>
On Tue, 2013-07-30 at 15:48 -0700, Luis R. Rodriguez wrote:
> Neat. Perhaps we need something that we can share with 802.11 or other
> hardare I highly doubt we're the only ones patching ROM. Don't we even
> patch up core CPUs? I'm wondering if firmware_class could be expanded to
> support serialized ROM patching. The biggest hurdle I see with splititng
> ROM patching from a single firmware is serializing that, addressing
> revision dependencies and of course kernel dependencies.
I don't really see what you're trying to get it so I arbitrarily picked
this ...
I think "ROM patching" like in BT and 802.11 are two completely
different things. In BT at least you have a common transport to the
device, a more-or-less common command set (HCI) etc. None of that exists
for wireless (today) so trying to find common ground between firmware
(patches) for different 802.11 hardware seems completely futile?
johannes
^ permalink raw reply
* Re: [PATCH] core: Use proper header for S_IRUSR/S_IWUSR
From: Szymon Janc @ 2013-07-31 7:39 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1373355600-12674-1-git-send-email-szymon.janc@tieto.com>
On Tuesday 09 of July 2013 09:40:00 Szymon Janc wrote:
> According to open() manual one should include <sys/stat.h>.
> This fix build with bionic library:
>
> target thumb C: libbluetoothd <= external/bluetooth/bluez/src/attrib-server.c
> external/bluetooth/bluez/src/attrib-server.c: In function 'write_value':
> external/bluetooth/bluez/src/attrib-server.c:922:26: error: 'S_IRUSR'
> undeclared (first use in this function)
> external/bluetooth/bluez/src/attrib-server.c:922:26: note: each undeclared
> identifier is reported only once for each function it appears in
> external/bluetooth/bluez/src/attrib-server.c:922:36: error: 'S_IWUSR'
> undeclared (first use in this function)
ping
^ permalink raw reply
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Luis R. Rodriguez @ 2013-07-31 7:48 UTC (permalink / raw)
To: Johannes Berg
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings, Greg Kroah-Hartman
In-Reply-To: <1375253182.8289.3.camel@jlt4.sipsolutions.net>
On Tue, Jul 30, 2013 at 11:46 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2013-07-30 at 15:48 -0700, Luis R. Rodriguez wrote:
>
>> Neat. Perhaps we need something that we can share with 802.11 or other
>> hardare I highly doubt we're the only ones patching ROM. Don't we even
>> patch up core CPUs? I'm wondering if firmware_class could be expanded to
>> support serialized ROM patching. The biggest hurdle I see with splititng
>> ROM patching from a single firmware is serializing that, addressing
>> revision dependencies and of course kernel dependencies.
>
> I don't really see what you're trying to get it so I arbitrarily picked
> this ...
>
> I think "ROM patching" like in BT and 802.11 are two completely
> different things. In BT at least you have a common transport to the
> device, a more-or-less common command set (HCI) etc.
Sure.
> None of that exists
> for wireless (today) so trying to find common ground between firmware
> (patches) for different 802.11 hardware seems completely futile?
So long as we can gaurantee mobile drivers get fw updated as much as
is really needed in the industry great.
Luis
^ permalink raw reply
* Re: [PATCH] core: Use proper header for S_IRUSR/S_IWUSR
From: Johan Hedberg @ 2013-07-31 7:57 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1668276.7oGYD4Lvyj@uw000953>
Hi Szymon,
On Wed, Jul 31, 2013, Szymon Janc wrote:
> On Tuesday 09 of July 2013 09:40:00 Szymon Janc wrote:
> > According to open() manual one should include <sys/stat.h>.
> > This fix build with bionic library:
> >
> > target thumb C: libbluetoothd <= external/bluetooth/bluez/src/attrib-server.c
> > external/bluetooth/bluez/src/attrib-server.c: In function 'write_value':
> > external/bluetooth/bluez/src/attrib-server.c:922:26: error: 'S_IRUSR'
> > undeclared (first use in this function)
> > external/bluetooth/bluez/src/attrib-server.c:922:26: note: each undeclared
> > identifier is reported only once for each function it appears in
> > external/bluetooth/bluez/src/attrib-server.c:922:36: error: 'S_IWUSR'
> > undeclared (first use in this function)
>
> ping
This was applied already a few weeks ago (July 15th) and I even sent the
usual "applied" email about it.
Johan
^ permalink raw reply
* Re: [PATCH] core: Use proper header for S_IRUSR/S_IWUSR
From: Szymon Janc @ 2013-07-31 8:32 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20130731075751.GA13668@x220.p-661hnu-f1>
Hi,
On Wednesday 31 of July 2013 10:57:51 Johan Hedberg wrote:
> This was applied already a few weeks ago (July 15th) and I even sent the
> usual "applied" email about it.
ahh right, not-enough-coffee-in-the-morning syndrome :)
--
BR
Szymon Janc
^ permalink raw reply
* [PATCH] monitor: Opencode strndupa in print_string
From: Szymon Janc @ 2013-07-31 8:51 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
Strndupa is GNU extension. print_string is simple and opencoding
strndupa is not a big loss.
This fix linkage error with bionic library which doesn't provide
strndupa.
target Executable: btmon (out/target/product/grouper/obj/EXECUTABLES/
btmon_intermediates/LINKED/btmon)
prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/bin/../lib/gcc/
arm-linux-androideabi/4.6.x-google/../../../../
arm-linux-androideabi/bin/ld: out/target/product/grouper/obj/
EXECUTABLES/btmon_intermediates/monitor/sdp.o: in function
print_string:external/bluetooth/bluez/monitor/sdp.c:146: error:
undefined reference to 'strndupa'
collect2: ld returned 1 exit status
make: *** [out/target/product/grouper/obj/EXECUTABLES/
btmon_intermediates/LINKED/btmon] Error
---
monitor/sdp.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/monitor/sdp.c b/monitor/sdp.c
index 45ee59b..4eb398b 100644
--- a/monitor/sdp.c
+++ b/monitor/sdp.c
@@ -143,7 +143,11 @@ static void print_uuid(uint8_t indent, const uint8_t *data, uint32_t size)
static void print_string(uint8_t indent, const uint8_t *data, uint32_t size)
{
- char *str = strndupa((const char *) data, size);
+ char *str = alloca(size + 1);
+
+ str[size] = '\0';
+ strncpy(str, (const char *) data, size);
+
print_field("%*c%s [len %d]", indent, ' ', str, size);
}
--
1.8.3.4
^ permalink raw reply related
* [PATCH BlueZ] audio/player: Fix overflowing position
From: Luiz Augusto von Dentz @ 2013-07-31 11:27 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The position should stop at UINT32_MAX after that the progress can no
longer be calculated, this should also prevent the position to change
when the remote stack doesn't support it which is also indicated with
UINT32_MAX which apparently is the case of Spotify on Android 4.3:
[CHG] Player /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/player0 Position: 0xffffffff
[CHG] Player /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/player0 Status: playing
[CHG] Player /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/player0 Position: 0x000000
---
profiles/audio/player.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/profiles/audio/player.c b/profiles/audio/player.c
index ce5e75b..6150c8a 100644
--- a/profiles/audio/player.c
+++ b/profiles/audio/player.c
@@ -151,7 +151,8 @@ static uint32_t media_player_get_position(struct media_player *mp)
double timedelta;
uint32_t sec, msec;
- if (g_strcmp0(mp->status, "playing") != 0)
+ if (g_strcmp0(mp->status, "playing") != 0 ||
+ mp->position == UINT32_MAX)
return mp->position;
timedelta = g_timer_elapsed(mp->progress, NULL);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH BlueZ] audio/player: Fix overflowing position
From: Johan Hedberg @ 2013-07-31 11:37 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1375270072-13140-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Wed, Jul 31, 2013, Luiz Augusto von Dentz wrote:
> The position should stop at UINT32_MAX after that the progress can no
> longer be calculated, this should also prevent the position to change
> when the remote stack doesn't support it which is also indicated with
> UINT32_MAX which apparently is the case of Spotify on Android 4.3:
>
> [CHG] Player /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/player0 Position: 0xffffffff
> [CHG] Player /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/player0 Status: playing
> [CHG] Player /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX/player0 Position: 0x000000
> ---
> profiles/audio/player.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH v5 0/6] rfcomm: Implement rfcomm as a proper tty_port
From: Peter Hurley @ 2013-07-31 17:50 UTC (permalink / raw)
To: Gianluca Anzolin; +Cc: gustavo, marcel, linux-bluetooth, gregkh, jslaby
In-Reply-To: <1375110493-5237-1-git-send-email-gianluca@sottospazio.it>
On 07/29/2013 11:08 AM, Gianluca Anzolin wrote:
> This patchset addresses an issue with the rfcomm tty driver in the
> current stable kernels that manifests itself as a sudden lockup of the
> whole machine or as a OOPS if we are lucky enough (I wasn't).
>
> Triggering the problem is very easy:
>
> 1) establish a bluetooth connection with a bluetooth host
> 2) open the tty it provides with some program
> 3) turn off the bluetooth host or take it out of range
>
> After a timeout the machine freezes.
>
> Another way to trigger these lockups is to simply release the rfcomm
> tty.
>
> This happens beacuse the underlying tty_struct objects and tty_port
> objects are freed while being used: the code doesn't take proper
> references to them.
>
> The following patches address the problem by implementing a proper
> tty_port driver for rfcomm.
>
> There are still some issues left: one relevant to flow control (which is
> also missing in the current code) and another relevant to a corner case
> in rfcomm_dev_state_change() that I intend to fix with a future patch.
> They are commented with a FIXME.
>
> Changes from v4:
> [PATCH 3/6]: left the debug message in rfcomm_tty_open()
> [PATCH 5/6]: always use !test_and_set_bit() to release the tty_port
I reviewed these changes and retested. All ok.
Regards,
Peter Hurley
>
> Thank you,
> Gianluca
>
> Gianluca Anzolin (6):
> rfcomm: Take proper tty_struct references
> rfcomm: Remove the device from the list in the destructor
> rfcomm: Move the tty initialization and cleanup out of open/close
> rfcomm: Implement .activate, .shutdown and .carrier_raised methods
> rfcomm: Fix the reference counting of tty_port
> rfcomm: Purge the dlc->tx_queue to avoid circular dependency
>
> net/bluetooth/rfcomm/tty.c | 271 +++++++++++++++++++++------------------------
> 1 file changed, 126 insertions(+), 145 deletions(-)
>
^ permalink raw reply
* Re: pull request: bluetooth 2013-07-30
From: John W. Linville @ 2013-07-31 19:08 UTC (permalink / raw)
To: Gustavo Padovan, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20130730123848.GE5975@joana>
On Tue, Jul 30, 2013 at 01:38:48PM +0100, Gustavo Padovan wrote:
> Hi John,
>
> A few fixes and devices ID additions for 3.11:
>
> * There are 4 new ath3k device ids
> * Fixed stack memory usage in ath3k.
> * Fixed the init process of BlueFRITZ! devices, they were failing to init
> due to an unsupported command we sent.
> * Fixed wrong use of PTR_ERR in btusb code that was preventing intel devices
> to work properly.
> * Fixed race condition between hci_register_dev() and hci_dev_open() that
> could cause a NULL pointer dereference.
> * Fixed race condition that could call hci_req_cmd_complete() and make some
> devices to fail as showed in the log added to the commit message.
>
> Please pull or let me know of any issues. Thanks.
>
> Gustavo
>
> --
> The following changes since commit 075163bbb0f51174359947e1bce84f5edb23f21e:
>
> ath9k_htc: Handle IDLE state transition properly (2013-06-24 13:52:52 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master
>
> for you to fetch changes up to 53e21fbc288218a423959f878c86471a0e323a9a:
>
> Bluetooth: Fix calling request callback more than once (2013-07-29 12:28:04 +0100)
Pulling now...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH 1/2] Bluetooth: Fix security level for peripheral role
From: Andre Guedes @ 2013-07-31 19:25 UTC (permalink / raw)
To: linux-bluetooth
While playing the peripheral role, the host gets a LE Long Term Key
Request Event from the controller when a connection is established
with a bonded device. The host then informs the LTK which should be
used for the connection. Once the link is encrypted, the host gets
an Encryption Change Event.
Therefore we should set conn->pending_sec_level instead of conn->
sec_level in hci_le_ltk_request_evt. This way, conn->sec_level is
properly updated in hci_encrypt_change_evt.
Moreover, since we have a LTK associated to the device, we have at
least BT_SECURITY_MEDIUM security level.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
---
net/bluetooth/hci_event.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 50e39f4..ea993ab 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3556,7 +3556,9 @@ static void hci_le_ltk_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
cp.handle = cpu_to_le16(conn->handle);
if (ltk->authenticated)
- conn->sec_level = BT_SECURITY_HIGH;
+ conn->pending_sec_level = BT_SECURITY_HIGH;
+ else
+ conn->pending_sec_level = BT_SECURITY_MEDIUM;
hci_send_cmd(hdev, HCI_OP_LE_LTK_REPLY, sizeof(cp), &cp);
--
1.8.3.4
^ permalink raw reply related
* [PATCH 2/2] Bluetooth: Fix encryption key size for peripheral role
From: Andre Guedes @ 2013-07-31 19:25 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1375298729-23513-1-git-send-email-andre.guedes@openbossa.org>
This patch fixes the connection encryption key size information when
the host is playing the peripheral role. We should set conn->enc_key_
size in hci_le_ltk_request_evt, otherwise it is left uninitialized.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
---
net/bluetooth/hci_event.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index ea993ab..bc56245 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3560,6 +3560,8 @@ static void hci_le_ltk_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
else
conn->pending_sec_level = BT_SECURITY_MEDIUM;
+ conn->enc_key_size = ltk->enc_size;
+
hci_send_cmd(hdev, HCI_OP_LE_LTK_REPLY, sizeof(cp), &cp);
if (ltk->type & HCI_SMP_STK) {
--
1.8.3.4
^ permalink raw reply related
* Re: gatt advertising
From: Dirk-Jan Binnema @ 2013-07-31 20:18 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <CAJdJm_NgnH5N93Xv1342XGoyUi7Fo1DYmCOr3n6kZGcJ+8kFmQ@mail.gmail.com>
Hi,
Thanks again for your insights!
anderson.lizardo@openbossa.org writes:
> If I remember correctly, indeed we only support Read/Write Long
> Characteristic Values on the GATT client code. We have been working on
> refactoring the attribute server, but the code is not ready yet to be
> sent upstream.
Okay, would you expect this feature to be available in the new attribute
server?
>> Are there plans to add long-writes/reads to ATT? Or would this be very
>> easy to add? (I suppose not!).
>
> I'm not aware of anyone working on this at the moment on the attribute
> server code. Regarding complexity, I think implementing Read Blob
> Request would be easy, Prepare Write / Execute Write Request may be
> more difficult, as you need to keep state saved and support more than
> one active client at the same time.
Okay, I can take a look...
A related thing are notifications -- I'm trying to send notifications of
changed characteristics to connected clients (I'm trying to use Bluez as
a peripheral for some mobile devices); I roughly follow the approach in
alert/server.c; however, I never get the callback from
btd_device_add_attio_callback, since device's attrib == NULL, and so I
never get the chance to send the notification.
Any hint on what I could do?
(Frankly, I was expecting framework to take care of notifications, but
it seems I need to do so by hand. Or?)
Thanks in advance!
Dirk.
--
Dirk-Jan C. Binnema Helsinki, Finland
e:djcb@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
On Tue, Jul 30, 2013 at 4:08 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi Dirk,
>
> On Tue, Jul 30, 2013 at 6:50 PM, Dirk-Jan Binnema <djcb.bulk@gmail.com> wrote:
>> One other thing I've hit upon is that apparently, long-writes/reads are
>> supported by ATT yet (looking at channel_handler, and seeing some
>> 'Unsupported request 0x16'), although it seems Bluez can do long-writes
>> itself.
>
> If I remember correctly, indeed we only support Read/Write Long
> Characteristic Values on the GATT client code. We have been working on
> refactoring the attribute server, but the code is not ready yet to be
> sent upstream.
>
>> Are there plans to add long-writes/reads to ATT? Or would this be very
>> easy to add? (I suppose not!).
>
> I'm not aware of anyone working on this at the moment on the attribute
> server code. Regarding complexity, I think implementing Read Blob
> Request would be easy, Prepare Write / Execute Write Request may be
> more difficult, as you need to keep state saved and support more than
> one active client at the same time.
>
> Best Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
^ permalink raw reply
* Re: [PATCH] monitor: Opencode strndupa in print_string
From: Johan Hedberg @ 2013-08-01 7:55 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1375260699-7271-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Wed, Jul 31, 2013, Szymon Janc wrote:
> Strndupa is GNU extension. print_string is simple and opencoding
> strndupa is not a big loss.
>
> This fix linkage error with bionic library which doesn't provide
> strndupa.
>
> target Executable: btmon (out/target/product/grouper/obj/EXECUTABLES/
> btmon_intermediates/LINKED/btmon)
> prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/bin/../lib/gcc/
> arm-linux-androideabi/4.6.x-google/../../../../
> arm-linux-androideabi/bin/ld: out/target/product/grouper/obj/
> EXECUTABLES/btmon_intermediates/monitor/sdp.o: in function
> print_string:external/bluetooth/bluez/monitor/sdp.c:146: error:
> undefined reference to 'strndupa'
> collect2: ld returned 1 exit status
> make: *** [out/target/product/grouper/obj/EXECUTABLES/
> btmon_intermediates/LINKED/btmon] Error
> ---
> monitor/sdp.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [RFC v2 6/6] sco-tester: Test BT_VOICE option with 1.1 adapter
From: Johan Hedberg @ 2013-08-01 9:57 UTC (permalink / raw)
To: Frédéric Dalleau, linux-bluetooth
In-Reply-To: <20130709114245.GC22976@x220.p-661hnu-f1>
Hi Frederic,
On Tue, Jul 09, 2013, Johan Hedberg wrote:
> Hi Frederic,
>
> On Fri, Jul 05, 2013, Frédéric Dalleau wrote:
> > ---
> > emulator/btdev.c | 25 +++++++++++++++++++
> > emulator/btdev.h | 1 +
> > src/shared/hciemu.c | 8 +++++++
> > src/shared/hciemu.h | 1 +
> > tools/sco-tester.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++-
> > 5 files changed, 100 insertions(+), 1 deletion(-)
>
> Here also, please split the emulator and hciemu changes to separate
> patches before the sco-tester patch.
Since you never came back with these fixes and we need to get this
feature progressing I went ahead and did the necessary changes myself.
The patches are now upstream.
Johan
^ permalink raw reply
* [PATCH] profile: Fix error message in ext_auth
From: Frederic Danis @ 2013-08-01 14:12 UTC (permalink / raw)
To: linux-bluetooth
---
src/profile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/profile.c b/src/profile.c
index 4a980f2..90c3535 100644
--- a/src/profile.c
+++ b/src/profile.c
@@ -1010,7 +1010,7 @@ static void ext_auth(DBusError *err, void *user_data)
bt_io_get(conn->io, &gerr, BT_IO_OPT_DEST, addr, BT_IO_OPT_INVALID);
if (gerr != NULL) {
error("Unable to get connect data for %s: %s",
- ext->name, err->message);
+ ext->name, gerr->message);
g_error_free(gerr);
goto drop;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] profile: Fix error message in ext_auth
From: Johan Hedberg @ 2013-08-01 15:53 UTC (permalink / raw)
To: Frederic Danis; +Cc: linux-bluetooth
In-Reply-To: <1375366378-20689-1-git-send-email-frederic.danis@linux.intel.com>
Hi Frederic,
On Thu, Aug 01, 2013, Frederic Danis wrote:
> ---
> src/profile.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: Accessing information transmitted by Ble tag.
From: James Baker @ 2013-08-01 21:53 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <CAJdJm_OFtRR1kT+F4zrnSYzPeC+m4SF1w-WkWa686isXF7wo6g@mail.gmail.com>
On 26 July 2013 14:01, Anderson Lizardo <anderson.lizardo@openbossa.org> wrote:
> Hi James,
>
> On Thu, Jul 25, 2013 at 7:42 PM, James Baker <j.baker@outlook.com> wrote:
>> As part of my summer placement, I've been introduced to some
>> non-connectable Ble tags. These are effectively beacons - advertising
>> and transmitting data every 250ms.
>>
>> Now, this is where I'm less clear:
>> I am something of a bluetooth newbie as it were, but I know for sure
>> they're transmitting more than just the address and name of the device
>> (as displayed in hcidump when running hcitool lescan). I know this
>> because the data is picked up on an iPhone app I have lying around.
>>
>> My question is, how would I read data from a connectionless Ble broadcaster?
>
> You forgot to mention what you need to do with the data once you get
> it at which "level" you want to program to get this data.
>
> On Linux, you have basically two "levels" to communicate with
> Bluetooth devices. At the highest level, you have a D-Bus API
> (documented on doc/*-api.txt files on the BlueZ source code) that
> usually is the easiest way to get information from devices, because
> you don't have to worry about packet details. The Broadaster/Observer
> API you found works at this level, but as you noticed, it has not
> evolved yet to go upstream. It's not being actively developed at the
> moment.
>
> The second, lower level is to program using Bluetooth sockets. At this
> level you talk directly to the kernel and BlueZ is not involved. It's
> much like programming for TCP sockets, if you have some experience
> with socket programming on Linux it will not be much different.
> hcitool works at this level.
>
> You already mentioned that with hcidump + hcitool lescan you were able
> to see the data you need to access. hcidump is just a "sniffer" that
> shows all the incoming/outgoing communication going through the
> bluetooth adapter. My advice is to take a look at the hcitool source
> code (tools/hcitool.c) and try to understand how lescan is
> implemented. With some effort, you will be able to modify hcitool to
> print the information you need.
>
Hi, thank you,
Just to give an update, I have done exactly that - I've gutted hcitool
in order to give me the individual packets, which I'm now decoding on
the fly. Now just to deal with connectable devices!
All best,
James
^ permalink raw reply
* [PATCH] btmrvl_sdio: use DIV_ROUND_UP in suitable places
From: Andy Shevchenko @ 2013-08-02 11:10 UTC (permalink / raw)
To: linux-bluetooth, Marcel Holtmann, Gustavo Padovan; +Cc: Andy Shevchenko
There are two places where DIV_ROUND_UP may be used. It makes code a bit
clearer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/bluetooth/btmrvl_sdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 75c2626..00da6df 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -486,7 +486,7 @@ static int btmrvl_sdio_download_fw_w_helper(struct btmrvl_sdio_card *card)
if (firmwarelen - offset < txlen)
txlen = firmwarelen - offset;
- tx_blocks = (txlen + blksz_dl - 1) / blksz_dl;
+ tx_blocks = DIV_ROUND_UP(txlen, blksz_dl);
memcpy(fwbuf, &firmware[offset], txlen);
}
@@ -873,7 +873,7 @@ static int btmrvl_sdio_host_to_card(struct btmrvl_private *priv,
}
blksz = SDIO_BLOCK_SIZE;
- buf_block_len = (nb + blksz - 1) / blksz;
+ buf_block_len = DIV_ROUND_UP(nb, blksz);
sdio_claim_host(card->func);
--
1.8.4.rc0
^ permalink raw reply related
* Re: [RFC BlueZ v0 00/10] HSP plugin
From: Luiz Augusto von Dentz @ 2013-08-02 14:18 UTC (permalink / raw)
To: Mikel Astiz; +Cc: Marcel Holtmann, linux-bluetooth@vger.kernel.org
In-Reply-To: <CANT-zCU9HFLUB0=ooxJHGeRXQLvbfTHnjPaQnmJ7adMSN6icqQ@mail.gmail.com>
Hi Mikel,
On Fri, Jul 12, 2013 at 4:48 PM, Mikel Astiz <mikel.astiz.oss@gmail.com> wrote:
> Besides the issues pointed out by Luiz, which I could fix in a next
> proposal, can you give your opinion on this approach?
>
> It makes little sense to try to advance in this direction if it
> doesn't fit the project plan.
>
> Johan also suggested that such a feature could be automatically
> disabled when an external profile (oFono) registers.
So as some know the initial idea was reject due to the use of Media
API which is now supposed to be A2DP specific, so Im currently
discussing with PulseAudio folks where this should be done then, so
far we come up with 3 options:
1. External profile implemented inside PA
2. BlueZ plugin with a different API
3. Dedicated daemon
I guess 1 or 2 is preferable as 3 might be overkill to maintain
independently, for solution 2 probably the API would be very similar
to the one implemented by oFono for HFP.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: Fix ACL alive for long in case of non pariable devices
From: Syam Sidhardhan @ 2013-08-05 16:47 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: User Name, Syam Sidhardhan
In-Reply-To: <C019B2D1-71D5-4054-8FBC-A49CB7F25633@holtmann.org>
Hi Marcel,
On Mon, Jul 29, 2013 at 7:13 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Syam,
>
>> For certain devices (ex: HID mouse), support for authentication,
>> pairing and bonding is optional. For such devices, the ACL alive
>> for too long after the L2CAP disconnection.
>>
>> To avoid the ACL alive for too long after L2CAP disconnection, reset the ACL
>> disconnect timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
>>
>> While merging the commit id:a9ea3ed9b71cc3271dd59e76f65748adcaa76422
>> this issue might have introduced.
>>
>> Signed-off-by: Sang-Ki Park <sangki79.park@samsung.com>
>> Signed-off-by: Chan-yeol Park <chanyeol.park@samsung.com>
>> Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
>> Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
>> ---
>> v1 -> Modified the code as per the latest code.
>> v2 -> Add descriptive comment as per Marcel request.
>> v3 -> Moved from l2cap_conn_ready() to l2cap_connect() inorder to fix remote
>> non ssp pairing timeout. Generated the patch based on bluetooth.git tree.
>>
>> net/bluetooth/l2cap_core.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>
> is the any chance you have btmon or hcidump traces that would show this kind of behavior. Adding these to the commit message might be really helpful in case we have understand again why we did this.
Yes, I found the particular mouse device after a long search and
captured the hcidump log.
I'll send another patch version with the logs. Sorry for the delay.
Regards,
Syam
^ permalink raw reply
* [PATCH 1/1 v4] Bluetooth: Fix ACL alive for long in case of non pariable devices
From: Syam Sidhardhan @ 2013-08-05 16:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Syam Sidhardhan
From: Syam Sidhardhan <s.syam@samsung.com>
For certain devices (ex: HID mouse), support for authentication,
pairing and bonding is optional. For such devices, the ACL alive
for too long after the L2CAP disconnection.
To avoid the ACL alive for too long after L2CAP disconnection, reset the
ACL disconnect timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
While merging the commit id:a9ea3ed9b71cc3271dd59e76f65748adcaa76422
this issue might have introduced.
Hcidump info:
sh-4.1# /opt/hcidump -Xt
HCI sniffer - Bluetooth packet analyzer ver 2.4
device: hci0 snap_len: 1500 filter: 0xffffffff
2013-08-05 16:48:47.847053 > HCI Event: Connect Request (0x04) plen 10
bdaddr 00:12:A1:65:E5:B2 class 0x002580 type ACL
2013-08-05 16:48:47.847310 < HCI Command: Accept Connection Request (0x01
|0x0009) plen 7
bdaddr 00:12:A1:65:E5:B2 role 0x00
Role: Master
2013-08-05 16:48:47.848436 > HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
2013-08-05 16:48:48.007120 > HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:12:A1:65:E5:B2 role 0x00
Role: Master
2013-08-05 16:48:48.050475 > HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 12 bdaddr 00:12:A1:65:E5:B2 type ACL encrypt 0x00
2013-08-05 16:48:48.051235 < HCI Command: Read Remote Supported Features
(0x01|0x001b) plen 2
handle 12
2013-08-05 16:48:48.051691 > HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2013-08-05 16:48:48.051864 > HCI Event: Read Remote Supported Features
(0x0b) plen 11
status 0x00 handle 12
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
2013-08-05 16:48:48.051899 < HCI Command: Remote Name Request (0x01|
0x0019) plen 10
bdaddr 00:12:A1:65:E5:B2 mode 2 clkoffset 0x0000
2013-08-05 16:48:48.052530 > HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2013-08-05 16:48:48.056407 > ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0049
2013-08-05 16:48:48.056492 < ACL data: handle 12 flags 0x00 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0049 result 1 status 0
Connection pending - No futher information available
2013-08-05 16:48:48.056510 < ACL data: handle 12 flags 0x00 dlen 10
L2CAP(s): Info req: type 2
2013-08-05 16:48:48.061404 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2013-08-05 16:48:48.064019 > ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0004
Bi-directional QoS
2013-08-05 16:48:48.064059 < ACL data: handle 12 flags 0x00 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0049 result 0 status 0
Connection successful
2013-08-05 16:48:48.064071 < ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Config req: dcid 0x0049 flags 0x00 clen 0
2013-08-05 16:48:48.067220 > HCI Event: Remote Name Req Complete (0x07)
plen 255
status 0x00 bdaddr 00:12:A1:65:E5:B2 name 'Bluetooth Mouse'
2013-08-05 16:48:48.067627 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2013-08-05 16:48:48.070114 > ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 185
2013-08-05 16:48:48.070148 < ACL data: handle 12 flags 0x00 dlen 18
L2CAP(s): Config rsp: scid 0x0049 flags 0x00 result 0 clen 4
MTU 185
2013-08-05 16:48:48.072642 > ACL data: handle 12 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 185
2013-08-05 16:48:48.075123 > ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x004a
2013-08-05 16:48:48.075196 < ACL data: handle 12 flags 0x00 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x004a result 1 status 2
Connection pending - Authorization pending
2013-08-05 16:48:48.075364 < ACL data: handle 12 flags 0x00 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x004a result 0 status 0
Connection successful
2013-08-05 16:48:48.075403 < ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Config req: dcid 0x004a flags 0x00 clen 0
2013-08-05 16:48:48.077633 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2013-08-05 16:48:48.080127 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2013-08-05 16:48:48.081355 > ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 185
2013-08-05 16:48:48.081402 < ACL data: handle 12 flags 0x00 dlen 18
L2CAP(s): Config rsp: scid 0x004a flags 0x00 result 0 clen 4
MTU 185
2013-08-05 16:48:48.082633 > ACL data: handle 12 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
MTU 185
2013-08-05 16:48:48.084838 < ACL data: handle 12 flags 0x00 dlen 12
L2CAP(d): cid 0x004a len 8 [psm 19]
HIDP: Data: Output report
0000: 02 00 00 00 00 00 00 .......
...
...
2013-08-05 16:49:00.894129 < ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Disconn req: dcid 0x004a scid 0x0041
2013-08-05 16:49:00.894195 < HCI Command: Exit Sniff Mode (0x02|0x0004)
plen 2
handle 12
2013-08-05 16:49:00.894269 < ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Disconn req: dcid 0x0049 scid 0x0040
2013-08-05 16:49:00.895645 > HCI Event: Command Status (0x0f) plen 4
Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
2013-08-05 16:49:00.934391 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 12 mode 0x00 interval 0
Mode: Active
2013-08-05 16:49:00.936592 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2013-08-05 16:49:00.951577 > ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x004a scid 0x0041
2013-08-05 16:49:00.952820 > ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0049 scid 0x0040
2013-08-05 16:49:00.969165 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 12 mode 0x02 interval 50
Mode: Sniff
2013-08-05 16:49:48.175533 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 12 mode 0x00 interval 0
Mode: Active
2013-08-05 16:49:48.219045 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 12 mode 0x02 interval 108
Mode: Sniff
2013-08-05 16:51:00.968209 < HCI Command: Disconnect (0x01|0x0006) plen 3
handle 12 reason 0x13
Reason: Remote User Terminated Connection
2013-08-05 16:51:00.969056 > HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
2013-08-05 16:51:01.013495 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 12 mode 0x00 interval 0
Mode: Active
2013-08-05 16:51:01.073777 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 12 reason 0x16
Reason: Connection Terminated by Local Host
========================= Conn status =================================
sh-4.1# date; hcitool con
Mon Aug 5 16:49:16 KST 2013
Connections:
> ACL 00:12:A1:65:E5:B2 handle 12 state 1 lm MASTER
sh-4.1# date; hcitool con
Mon Aug 5 16:50:32 KST 2013
Connections:
> ACL 00:12:A1:65:E5:B2 handle 12 state 1 lm MASTER
sh-4.1# date; hcitool con
Mon Aug 5 16:50:59 KST 2013
Connections:
> ACL 00:12:A1:65:E5:B2 handle 12 state 1 lm MASTER
sh-4.1# date; hcitool con
Mon Aug 5 16:51:01 KST 2013
Connections:
sh-4.1#
============================ After fix ================================
2013-08-05 16:57:35.986648 < ACL data: handle 11 flags 0x00 dlen 12
L2CAP(s): Disconn req: dcid 0x004c scid 0x0041
2013-08-05 16:57:35.986713 < HCI Command: Exit Sniff Mode (0x02|0x0004)
plen 2
handle 11
2013-08-05 16:57:35.986785 < ACL data: handle 11 flags 0x00 dlen 12
L2CAP(s): Disconn req: dcid 0x004b scid 0x0040
2013-08-05 16:57:35.988110 > HCI Event: Command Status (0x0f) plen 4
Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
2013-08-05 16:57:36.030714 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 11 mode 0x00 interval 0
Mode: Active
2013-08-05 16:57:36.032950 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 11 packets 2
2013-08-05 16:57:36.047926 > ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x004c scid 0x0041
2013-08-05 16:57:36.049200 > ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x004b scid 0x0040
2013-08-05 16:57:36.065509 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 11 mode 0x02 interval 50
Mode: Sniff
2013-08-05 16:57:40.052006 < HCI Command: Disconnect (0x01|0x0006) plen 3
handle 11 reason 0x13
Reason: Remote User Terminated Connection
2013-08-05 16:57:40.052869 > HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
2013-08-05 16:57:40.104731 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 11 mode 0x00 interval 0
Mode: Active
2013-08-05 16:57:40.146935 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 11 reason 0x16
Reason: Connection Terminated by Local Host
Signed-off-by: Sang-Ki Park <sangki79.park@samsung.com>
Signed-off-by: Chan-yeol Park <chanyeol.park@samsung.com>
Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
---
v1 -> Modified the code as per the latest code.
v2 -> Add descriptive comment as per Marcel request.
v3 -> Moved from l2cap_conn_ready() to l2cap_connect() inorder to fix remote
non ssp pairing timeout. Generated the patch based on bluetooth.git tree.
v4 -> Include hcidump logs showing the conn status before and after fix.
This patch is generated the patch based on bluetooth.git tree.
net/bluetooth/l2cap_core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 68843a2..8179fc3 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3753,6 +3753,13 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn,
hci_conn_hold(conn->hcon);
+ /* For certain devices (ex: HID mouse), support for authentication,
+ * pairing and bonding is optional. For such devices, inorder to avoid
+ * the ACL alive for too long after L2CAP disconnection, reset the ACL
+ * disc_timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.
+ */
+ conn->hcon->disc_timeout = HCI_DISCONN_TIMEOUT;
+
bacpy(&bt_sk(sk)->src, conn->src);
bacpy(&bt_sk(sk)->dst, conn->dst);
chan->psm = psm;
--
1.7.9.5
^ permalink raw reply related
* fail to configure and compile the source of bluez-5.7
From: atar @ 2013-08-07 4:36 UTC (permalink / raw)
To: linux-bluetooth
Hi there!!
My machine is running Debian Wheezy from the live-boot Debian project
which is installed on my USB stick.
I've downloaded from bluez.org the source of the 5.7 package but when I
ran ./configure on it, it emitted an error message at the bottom of all
the messages saying:
> "checking for GLIB... no
> configure: error: GLib >= 2.28 is required"
This, although I've the glib libraries installed.
How can this problem be solved?
Thanks in advance!!
atar.
^ 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