Linux bluetooth development
 help / color / mirror / Atom feed
* [PATCH] bluetooth: fix unaligned access to l2cap conf data
From: Mike Frysinger @ 2010-10-16 22:29 UTC (permalink / raw)
  To: linux-bluetooth, Marcel Holtmann
  Cc: uclinux-dist-devel, linux-kernel, Andrew Morton, steven miao

From: steven miao <realmz6@gmail.com>

In function l2cap_get_conf_opt() and l2cap_add_conf_opt() the address of
opt->val sometimes is not at the edge of 2-bytes/4-bytes, so 2-bytes/4 bytes
access will cause data misalignment exeception.  Use get_unaligned_le16/32
and put_unaligned_le16/32 function to avoid data misalignment execption.

Signed-off-by: steven miao <realmz6@gmail.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
was posted a month ago with no feedback ...

 net/bluetooth/l2cap.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 0b54b7d..65bcdc1 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2401,11 +2401,11 @@ static inline int l2cap_get_conf_opt(void **ptr, int *type, int *olen, unsigned
 		break;
 
 	case 2:
-		*val = __le16_to_cpu(*((__le16 *) opt->val));
+		*val = get_unaligned_le16(opt->val);
 		break;
 
 	case 4:
-		*val = __le32_to_cpu(*((__le32 *) opt->val));
+		*val = get_unaligned_le32(opt->val);
 		break;
 
 	default:
@@ -2432,11 +2432,11 @@ static void l2cap_add_conf_opt(void **ptr, u8 type, u8 len, unsigned long val)
 		break;
 
 	case 2:
-		*((__le16 *) opt->val) = cpu_to_le16(val);
+		put_unaligned_le16(cpu_to_le16(val), opt->val);
 		break;
 
 	case 4:
-		*((__le32 *) opt->val) = cpu_to_le32(val);
+		put_unaligned_le32(cpu_to_le32(val), opt->val);
 		break;
 
 	default:
-- 
1.7.3.1

^ permalink raw reply related

* problem in Multiple Connection
From: nirav rabara @ 2010-10-16 10:59 UTC (permalink / raw)
  To: linux-bluetooth

Hi,

I am using one Headset and one Serial port Device.

1) I create the ACL connection and then SCO connection with HS.
2) Try to create connection with Serial Port Device but during Service
Discovery i receive HCI PAGE TIMOUT.

But, If i create the only ACL Connection with HS,then able to connect
with Serial port device.

What is wrong with SCO connection? when I connect SCO link after that
not able to connect other Device.

Please can anybody suggest me what I am missing?


--
With Regards,
Nirav Rabara

^ permalink raw reply

* [PATCH] Bluetooth: btwilink driver
From: pavan_savoy @ 2010-10-15 20:58 UTC (permalink / raw)
  To: padovan, marcel; +Cc: linux-bluetooth, linux-kernel, Pavan Savoy

From: Pavan Savoy <pavan_savoy@ti.com>

Gustavo, Marcel,

Renaming the patch, since the driver is renamed to btwilink.
Thanks for the comments,
Please review and provide your comments on this version of patch,

-- patch description --

This is the bluetooth protocol driver for the TI WiLink7 chipsets.
Texas Instrument's WiLink chipsets combine wireless technologies
like BT, FM, GPS and WLAN onto a single chip.

This Bluetooth driver works on top of the TI_ST shared transport
line discipline driver which also allows other drivers like
FM V4L2 and GPS character driver to make use of the same UART interface.

Kconfig and Makefile modifications to enable the Bluetooth
driver for Texas Instrument's WiLink 7 chipset.

Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
 drivers/bluetooth/Kconfig    |   10 +
 drivers/bluetooth/Makefile   |    1 +
 drivers/bluetooth/btwilink.c |  424 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 435 insertions(+), 0 deletions(-)
 create mode 100644 drivers/bluetooth/btwilink.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 02deef4..e0d67dd 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -219,4 +219,14 @@ config BT_ATH3K
 	  Say Y here to compile support for "Atheros firmware download driver"
 	  into the kernel or say M to compile it as module (ath3k).
 
+config BT_WILINK
+	tristate "BlueZ bluetooth driver for TI ST"
+	depends on TI_ST
+	help
+	  This enables the Bluetooth driver for Texas Instrument's BT/FM/GPS
+	  combo devices. This makes use of shared transport line discipline
+	  core driver to communicate with the BT core of the combo chip.
+
+	  Say Y here to compile support for Texas Instrument's WiLink7 driver
+	  into the kernel or say M to compile it as module.
 endmenu
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 71bdf13..f4460f4 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_BT_HCIBTSDIO)	+= btsdio.o
 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
 
 btmrvl-y			:= btmrvl_main.o
 btmrvl-$(CONFIG_DEBUG_FS)	+= btmrvl_debugfs.o
diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
new file mode 100644
index 0000000..f67791f
--- /dev/null
+++ b/drivers/bluetooth/btwilink.c
@@ -0,0 +1,424 @@
+/*
+ *  Texas Instrument's Bluetooth Driver For Shared Transport.
+ *
+ *  Bluetooth Driver acts as interface between HCI CORE and
+ *  TI Shared Transport Layer.
+ *
+ *  Copyright (C) 2009-2010 Texas Instruments
+ *  Author: Raja Mani <raja_mani@ti.com>
+ *	Pavan Savoy <pavan_savoy@ti.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  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/platform_device.h>
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include <linux/ti_wilink_st.h>
+
+/* Bluetooth Driver Version */
+#define VERSION               "1.0"
+
+/* Defines number of seconds to wait for reg completion
+ * callback getting called from ST (in case,registration
+ * with ST returns PENDING status)
+ */
+#define BT_REGISTER_TIMEOUT   6000	/* 6 sec */
+
+/**
+ * struct ti_st - BT driver operation structure
+ * @hdev: hci device pointer which binds to bt driver
+ * @flags: used locally,to maintain various BT driver status
+ * @streg_cbdata: to hold ST registration callback status
+ * @st_write: write function pointer of ST driver
+ * @wait_reg_completion - completion sync between ti_st_open
+ *	and ti_st_registration_completion_cb.
+ */
+struct ti_st {
+	struct hci_dev *hdev;
+	char streg_cbdata;
+	long (*st_write) (struct sk_buff *);
+	struct completion wait_reg_completion;
+};
+
+static int reset;
+
+/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
+static inline void ti_st_tx_complete(struct ti_st *hst, int pkt_type)
+{
+	struct hci_dev *hdev;
+	hdev = hst->hdev;
+
+	/* Update HCI stat counters */
+	switch (pkt_type) {
+	case HCI_COMMAND_PKT:
+		hdev->stat.cmd_tx++;
+		break;
+
+	case HCI_ACLDATA_PKT:
+		hdev->stat.acl_tx++;
+		break;
+
+	case HCI_SCODATA_PKT:
+		hdev->stat.sco_tx++;
+		break;
+	}
+}
+
+/* ------- Interfaces to Shared Transport ------ */
+
+/* Called by ST layer to indicate protocol registration completion
+ * status.ti_st_open() function will wait for signal from this
+ * API when st_register() function returns ST_PENDING.
+ */
+static void st_registration_completion_cb(void *priv_data, char data)
+{
+	struct ti_st *lhst = (struct ti_st *)priv_data;
+	/* ti_st_open() function needs value of 'data' to know
+	 * the registration status(success/fail),So have a back
+	 * up of it.
+	 */
+	lhst->streg_cbdata = data;
+
+	/* Got a feedback from ST for BT driver registration
+	 * request.Wackup ti_st_open() function to continue
+	 * it's open operation.
+	 */
+	complete(&lhst->wait_reg_completion);
+}
+
+/* Called by Shared Transport layer when receive data is
+ * available */
+static long st_receive(void *priv_data, struct sk_buff *skb)
+{
+	int err;
+	struct ti_st *lhst = (struct ti_st *)priv_data;
+
+	if (!skb)
+		return -EFAULT;
+
+	if (!lhst) {
+		kfree_skb(skb);
+		return -EFAULT;
+	}
+
+	skb->dev = (struct net_device *)lhst->hdev;
+
+	/* Forward skb to HCI CORE layer */
+	err = hci_recv_frame(skb);
+	if (err) {
+		kfree_skb(skb);
+		BT_ERR("Unable to push skb to HCI CORE(%d)", err);
+		return err;
+	}
+
+	lhst->hdev->stat.byte_rx += skb->len;
+	return 0;
+}
+
+/* ------- Interfaces to HCI layer ------ */
+/* protocol structure registered with shared transport */
+static struct st_proto_s ti_st_proto = {
+	.type = ST_BT,
+	.recv = st_receive,
+	.reg_complete_cb = st_registration_completion_cb,
+	.priv_data = NULL,
+};
+
+/* Called from HCI core to initialize the device */
+static int ti_st_open(struct hci_dev *hdev)
+{
+	unsigned long timeleft;
+	struct ti_st *hst;
+	int err;
+
+	BT_DBG("%s %p", hdev->name, hdev);
+
+	/* provide contexts for callbacks from ST */
+	hst = hdev->driver_data;
+	ti_st_proto.priv_data = hst;
+
+	err = st_register(&ti_st_proto);
+	if (err == -EINPROGRESS) {
+		/* Prepare wait-for-completion handler data structures.
+		 * Needed to syncronize this and st_registration_completion_cb()
+		 * functions.
+		 */
+		init_completion(&hst->wait_reg_completion);
+
+		/* Reset ST registration callback status flag , this value
+		 * will be updated in ti_st_registration_completion_cb()
+		 * function whenever it called from ST driver.
+		 */
+		hst->streg_cbdata = -EINPROGRESS;
+
+		/* ST is busy with other protocol registration(may be busy with
+		 * firmware download).So,Wait till the registration callback
+		 * (passed as a argument to st_register() function) getting
+		 * called from ST.
+		 */
+		BT_DBG(" waiting for reg completion signal from ST");
+
+		timeleft = wait_for_completion_timeout
+			(&hst->wait_reg_completion,
+			 msecs_to_jiffies(BT_REGISTER_TIMEOUT));
+		if (!timeleft) {
+			BT_ERR("Timeout(%d sec),didn't get reg"
+					"completion signal from ST",
+					BT_REGISTER_TIMEOUT / 1000);
+			return -ETIMEDOUT;
+		}
+
+		/* Is ST registration callback called with ERROR value? */
+		if (hst->streg_cbdata != 0) {
+			BT_ERR("ST reg completion CB called with invalid"
+					"status %d", hst->streg_cbdata);
+			return -EAGAIN;
+		}
+		err = 0;
+	} else if (err == -EPERM) {
+		BT_ERR("st_register failed %d", err);
+		return -EAGAIN;
+	}
+
+	/* Do we have proper ST write function? */
+	if (ti_st_proto.write != NULL) {
+		/* We need this pointer for sending any Bluetooth pkts */
+		hst->st_write = ti_st_proto.write;
+	} else {
+		BT_ERR("failed to get ST write func pointer");
+
+		/* Undo registration with ST */
+		err = st_unregister(ST_BT);
+		if (err)
+			BT_ERR("st_unregister failed %d", err);
+
+		hst->st_write = NULL;
+		return -EAGAIN;
+	}
+
+	/* Registration with ST layer is completed successfully,
+	 * now chip is ready to accept commands from HCI CORE.
+	 * Mark HCI Device flag as RUNNING
+	 */
+	set_bit(HCI_RUNNING, &hdev->flags);
+	return err;
+}
+
+/* Close device */
+static int ti_st_close(struct hci_dev *hdev)
+{
+	int err = 0;
+	struct ti_st *hst;
+
+	hst = hdev->driver_data;
+
+	/* Clear HCI device RUNNING flag */
+	if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags))
+		BT_ERR("HCI not RUNNING?");
+
+	/* continue to unregister from transport */
+	err = st_unregister(ST_BT);
+	if (err)
+		BT_ERR("st_unregister failed %d", err);
+
+	hst->st_write = NULL;
+	return err;
+}
+
+/* Called from HCI CORE , Sends frames to Shared Transport */
+static int ti_st_send_frame(struct sk_buff *skb)
+{
+	struct hci_dev *hdev;
+	struct ti_st *hst;
+	long len;
+
+	if (!skb)
+		return -ENOMEM;
+
+	hdev = (struct hci_dev *)skb->dev;
+	if (!hdev)
+		return -ENODEV;
+
+	if (!test_bit(HCI_RUNNING, &hdev->flags))
+		return -EBUSY;
+
+	hst = (struct ti_st *)hdev->driver_data;
+
+	/* Prepend skb with frame type */
+	memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
+
+	BT_DBG(" %s: type %d len %d", hdev->name, bt_cb(skb)->pkt_type,
+			skb->len);
+
+	/* Insert skb to shared transport layer's transmit queue.
+	 * Freeing skb memory is taken care in shared transport layer,
+	 * so don't free skb memory here.
+	 */
+	if (!hst->st_write) {
+		kfree_skb(skb);
+		BT_ERR(" Can't write to ST, st_write null?");
+		return -EAGAIN;
+	}
+
+	len = hst->st_write(skb);
+	if (len < 0) {
+		kfree_skb(skb);
+		BT_ERR(" ST write failed (%ld)", len);
+		return -EAGAIN;
+	}
+
+	/* ST accepted our skb. So, Go ahead and do rest */
+	hdev->stat.byte_tx += len;
+	ti_st_tx_complete(hst, bt_cb(skb)->pkt_type);
+
+	return 0;
+}
+
+static void ti_st_destruct(struct hci_dev *hdev)
+{
+	if (!hdev)
+		BT_ERR("Destruct called with invalid HCI Device"
+				"(hdev=NULL)");
+
+	BT_DBG("%s", hdev->name);
+
+	/* free ti_st memory */
+	kfree(hdev->driver_data);
+	return;
+}
+
+/* Creates new HCI device */
+static int ti_st_register_dev(struct ti_st *hst)
+{
+	struct hci_dev *hdev;
+
+	/* Initialize and register HCI device */
+	hdev = hci_alloc_dev();
+	if (!hdev)
+		return -ENOMEM;
+
+	BT_DBG(" HCI device allocated. hdev= %p", hdev);
+
+	hst->hdev = hdev;
+	hdev->bus = HCI_UART;
+	hdev->driver_data = hst;
+	hdev->open = ti_st_open;
+	hdev->close = ti_st_close;
+	hdev->flush = NULL;
+	hdev->send = ti_st_send_frame;
+	hdev->destruct = ti_st_destruct;
+	hdev->owner = THIS_MODULE;
+
+	if (reset)
+		set_bit(HCI_QUIRK_NO_RESET, &hdev->quirks);
+
+	if (hci_register_dev(hdev) < 0) {
+		BT_ERR("Can't register HCI device");
+		hci_free_dev(hdev);
+		return -ENODEV;
+	}
+
+	BT_DBG(" HCI device registered. hdev= %p", hdev);
+	return 0;
+}
+
+
+static int bt_ti_probe(struct platform_device *pdev)
+{
+	int err;
+	static struct ti_st *hst;
+	err = 0;
+
+	BT_DBG(" Bluetooth Driver Version %s", VERSION);
+
+	hst = kzalloc(sizeof(struct ti_st), GFP_KERNEL);
+	if (!hst) {
+		BT_ERR("Can't allocate control structure");
+		return -ENOMEM;
+	}
+
+	/* Expose "hciX" device to user space */
+	err = ti_st_register_dev(hst);
+	if (err) {
+		kfree(hst);
+		BT_ERR("Unable to expose hciX device(%d)", err);
+		return err;
+	}
+
+	dev_set_drvdata(&pdev->dev, hst);
+	return err;
+}
+
+static int bt_ti_remove(struct platform_device *pdev)
+{
+	struct ti_st *hst;
+
+	hst = dev_get_drvdata(&pdev->dev);
+	/* Deallocate local resource's memory  */
+	if (hst) {
+		struct hci_dev *hdev = hst->hdev;
+		if (!hdev) {
+			BT_ERR("Invalid hdev memory");
+			kfree(hst);
+		} else {
+			ti_st_close(hdev);
+			hci_unregister_dev(hdev);
+			/* Free HCI device memory */
+			hci_free_dev(hdev);
+		}
+	}
+	return 0;
+}
+
+static struct platform_driver btwilink_driver = {
+	.probe = bt_ti_probe,
+	.remove = bt_ti_remove,
+	.driver = {
+		.name = "btwilink",
+		.owner = THIS_MODULE,
+	},
+};
+
+/* ------- Module Init/Exit interfaces ------ */
+static int __init bt_drv_init(void)
+{
+	long ret;
+
+	ret = platform_driver_register(&btwilink_driver);
+	if (ret != 0) {
+		BT_ERR("btwilink platform drv registration failed");
+		return -EPERM;
+	}
+	return 0;
+}
+
+static void __exit bt_drv_exit(void)
+{
+	platform_driver_unregister(&btwilink_driver);
+}
+
+module_init(bt_drv_init);
+module_exit(bt_drv_exit);
+
+/* ------ Module Info ------ */
+
+module_param(reset, bool, 0644);
+MODULE_PARM_DESC(reset, "Send HCI reset command on initialization");
+MODULE_AUTHOR("Raja Mani <raja_mani@ti.com>");
+MODULE_DESCRIPTION("Bluetooth Driver for TI Shared Transport" VERSION);
+MODULE_VERSION(VERSION);
+MODULE_LICENSE("GPL");
-- 
1.6.5

^ permalink raw reply related

* Re: pull request: bluetooth-next-2.6 2010-10-13
From: John W. Linville @ 2010-10-15 20:04 UTC (permalink / raw)
  To: Gustavo F. Padovan; +Cc: marcel, linux-wireless, linux-bluetooth
In-Reply-To: <20101013034808.GA3205@vigoh>

On Wed, Oct 13, 2010 at 12:48:08AM -0300, Gustavo F. Padovan wrote:
> Hi John,
> 
> Here goes the Bluetooth patches for the next merge window. In this
> patchset we have a new stream-oriented recvmsg() which is used in L2CAP
> and RFCOMM. Support for two new MacBookPro devices. A buffer overflow
> check for L2CAP to prevent frames exceeding the receiving MTU. All the
> rest are simple bugfixes. No big features this time.
> 
> One notable change is in the MAINTAINERS file, From now and on I'm going
> to maintain the Bluetooth trees as well as send the pull requests to you.
> Despite this maintenance change, Marcel will remain helping with patch
> review, and ACK/NAK in the Bluetooth subsystem as he always did. Not a
> big change in the end. ;)
> 
> Thanks,
> 
> The following changes since commit 29b4433d991c88d86ca48a4c1cc33c671475be4b:
> 
>   net: percpu net_device refcount (2010-10-12 12:35:25 -0700)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6.git master

Pulled, thanks -- I plan to send a pull request to Dave later today.

John
-- 
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] Fix linkage failure for bluetoothd
From: Gustavo F. Padovan @ 2010-10-15 19:46 UTC (permalink / raw)
  To: linux-bluetooth

Adding -lrt fix the following errors in one of my systems:

health/mcap_sync.o: In function `initialize_caps':
/root/bluez/health/mcap_sync.c:341: undefined reference to `clock_getres'
/root/bluez/health/mcap_sync.c:350: undefined reference to `clock_gettime'
/root/bluez/health/mcap_sync.c:358: undefined reference to `clock_gettime'
/root/bluez/health/mcap_sync.c:363: undefined reference to `clock_gettime'
health/mcap_sync.o: In function `reset_tmstamp':
/root/bluez/health/mcap_sync.c:163: undefined reference to `clock_gettime'
health/mcap_sync.o: In function `mcap_get_timestamp':
/root/bluez/health/mcap_sync.c:309: undefined reference to `clock_gettime'
health/mcap_sync.o:/root/bluez/health/mcap_sync.c:514: more undefined references to `clock_gettime' follow
collect2: ld returned 1 exit status
make[1]: *** [src/bluetoothd] Error 1
make: *** [all] Error 2
---
 Makefile.am |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 8f9f5d3..6e8fc7d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -240,7 +240,7 @@ src_bluetoothd_SOURCES = $(gdbus_sources) $(builtin_sources) \
 			src/dbus-common.c src/dbus-common.h \
 			src/dbus-hci.h src/dbus-hci.c
 src_bluetoothd_LDADD = lib/libbluetooth.la @GLIB_LIBS@ @DBUS_LIBS@ \
-							@CAPNG_LIBS@ -ldl
+							@CAPNG_LIBS@ -ldl -lrt
 src_bluetoothd_LDFLAGS = -Wl,--export-dynamic \
 				-Wl,--version-script=$(srcdir)/src/bluetooth.ver
 
-- 
1.7.3.1


^ permalink raw reply related

* Re: [PATCH] fix oops in l2cap_connect_req
From: Marcel Holtmann @ 2010-10-15 19:35 UTC (permalink / raw)
  To: Nathan Holstein; +Cc: Gustavo F. Padovan, linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTi=xxj81e__fH1Bh8KuL_rmHVi0=ia9ELPUMThr-@mail.gmail.com>

Hi Nathan,

> > * Nathan Holstein <nathan.holstein@gmail.com> [2010-10-14 18:37:53 -0400]:
> >
> >> (Please keep me in the CC list, I'm not subscribed to lkml)
> >>
> >> [1] L2CAP module dereferences an uninitialized pointer within l2cap_connect_req.
> >>
> >> [2] I'm currently testing a 2.6.35 kernel on a Nexus One with backported
> >> patches from bluetooth-2.6.  When testing against certain BT devices, I'm seeing
> >> a null-pointer deref.  The crash is caused by this portion of commit e9aeb2dd:
> >>
> >> @@ -2966,6 +2991,15 @@ sendresp:
> >>                                         L2CAP_INFO_REQ, sizeof(info), &info);
> >>         }
> >>
> >> +       if (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_REQ_SENT) &&
> >> +                               result == L2CAP_CR_SUCCESS) {
> >> +               u8 buf[128];
> >> +               l2cap_pi(sk)->conf_state |= L2CAP_CONF_REQ_SENT;
> >> +               l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
> >> +                                       l2cap_build_conf_req(sk, buf), buf);
> >> +               l2cap_pi(sk)->num_conf_req++;
> >> +       }
> >> +
> >>         return 0;
> >>  }
> >>
> >> Multiple error cases jump to the response & sendresp labels prior to
> >> initializing
> >> the "sk" variable.  In the case I'm currently seeing, the remote BT
> >> device fails to
> >> properly secure the ACL, making this crash 100% reproducible.
> >>
> >> [3] Bluetooth, L2CAP
> >>
> >> [4] This bug appears to be in the mainline 2.6.36-rc? kernel, in addition to
> >>  multiple Bluetooth development trees
> >>
> >> The following patch fixes the crash.
> >>
> >>
> >>    --nathan

please send new patches with [PATCH v2] prefix to make it easier for
Gustavo to keep track.

> >> In error cases when the ACL is insecure or we fail to allocate a new
> >> struct sock, we jump to the "response" label.  If so, "sk" will be
> >> uninitialized and the kernel crashes.
> >>
> >> Signed-off-by: Nathan Holstein <nathan.holstein@gmail.com>

Acked-by: Marcel Holtmann <marcel@holtmann.org>

Regards

Marcel



^ permalink raw reply

* Re: [PATCH] fix oops in l2cap_connect_req
From: Nathan Holstein @ 2010-10-15 15:54 UTC (permalink / raw)
  To: Gustavo F. Padovan; +Cc: linux-kernel, linux-bluetooth
In-Reply-To: <20101014213709.GD9250@vigoh>

On Thu, Oct 14, 2010 at 5:37 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Nathan,
>
> * Nathan Holstein <nathan.holstein@gmail.com> [2010-10-14 18:37:53 -0400]:
>
>> (Please keep me in the CC list, I'm not subscribed to lkml)
>>
>> [1] L2CAP module dereferences an uninitialized pointer within l2cap_connect_req.
>>
>> [2] I'm currently testing a 2.6.35 kernel on a Nexus One with backported
>> patches from bluetooth-2.6.  When testing against certain BT devices, I'm seeing
>> a null-pointer deref.  The crash is caused by this portion of commit e9aeb2dd:
>>
>> @@ -2966,6 +2991,15 @@ sendresp:
>>                                         L2CAP_INFO_REQ, sizeof(info), &info);
>>         }
>>
>> +       if (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_REQ_SENT) &&
>> +                               result == L2CAP_CR_SUCCESS) {
>> +               u8 buf[128];
>> +               l2cap_pi(sk)->conf_state |= L2CAP_CONF_REQ_SENT;
>> +               l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
>> +                                       l2cap_build_conf_req(sk, buf), buf);
>> +               l2cap_pi(sk)->num_conf_req++;
>> +       }
>> +
>>         return 0;
>>  }
>>
>> Multiple error cases jump to the response & sendresp labels prior to
>> initializing
>> the "sk" variable.  In the case I'm currently seeing, the remote BT
>> device fails to
>> properly secure the ACL, making this crash 100% reproducible.
>>
>> [3] Bluetooth, L2CAP
>>
>> [4] This bug appears to be in the mainline 2.6.36-rc? kernel, in addition to
>>  multiple Bluetooth development trees
>>
>> The following patch fixes the crash.
>>
>>
>>    --nathan
>>
>> ---
>> In error cases when the ACL is insecure or we fail to allocate a new
>> struct sock, we jump to the "response" label.  If so, "sk" will be
>> uninitialized and the kernel crashes.
>>
>> Signed-off-by: Nathan Holstein <nathan.holstein@gmail.com>
>> ---
>>  net/bluetooth/l2cap.c |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index d527b10..10ae0af 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -2911,7 +2911,7 @@ static inline int l2cap_connect_req(struct
>> l2cap_conn *conn, struct l2cap_cmd_hd
>>       struct l2cap_chan_list *list = &conn->chan_list;
>>       struct l2cap_conn_req *req = (struct l2cap_conn_req *) data;
>>       struct l2cap_conn_rsp rsp;
>> -     struct sock *parent, *uninitialized_var(sk);
>> +     struct sock *parent, *sk = 0;
>
> Your fix is right, but please make *sk = NULL here.
> When I wrote that code I thought is was a false positive, but no, it's
> bug. :(

Updated patch below.

> --
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
>

---
In error cases when the ACL is insecure or we fail to allocate a new
struct sock, we jump to the "response" label.  If so, "sk" will be
null and the kernel crashes.

Signed-off-by: Nathan Holstein <nathan.holstein@gmail.com>
---
 net/bluetooth/l2cap.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 4ded76e..4a4aa63 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2911,7 +2911,7 @@ static inline int l2cap_connect_req(struct
l2cap_conn *conn, struct l2cap_cmd_hd
 	struct l2cap_chan_list *list = &conn->chan_list;
 	struct l2cap_conn_req *req = (struct l2cap_conn_req *) data;
 	struct l2cap_conn_rsp rsp;
-	struct sock *parent, *uninitialized_var(sk);
+	struct sock *parent, *sk = NULL;
 	int result, status = L2CAP_CS_NO_INFO;

 	u16 dcid = 0, scid = __le16_to_cpu(req->scid);
@@ -3024,7 +3024,7 @@ sendresp:
 					L2CAP_INFO_REQ, sizeof(info), &info);
 	}

-	if (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_REQ_SENT) &&
+	if (sk && !(l2cap_pi(sk)->conf_state & L2CAP_CONF_REQ_SENT) &&
 				result == L2CAP_CR_SUCCESS) {
 		u8 buf[128];
 		l2cap_pi(sk)->conf_state |= L2CAP_CONF_REQ_SENT;
-- 
1.7.2.3

^ permalink raw reply related

* Re: [PATCH] Add INdT developers in AUTHORS
From: Johan Hedberg @ 2010-10-15 13:56 UTC (permalink / raw)
  To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1287149783-15672-1-git-send-email-claudio.takahasi@openbossa.org>

Hi Claudio,

On Fri, Oct 15, 2010, Claudio Takahasi wrote:
> ---
>  AUTHORS |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)

Thanks. The patch has been pushed upstream.

Johan

^ permalink raw reply

* Re: [PATCH] TODO: Define attribute server API
From: Johan Hedberg @ 2010-10-15 13:55 UTC (permalink / raw)
  To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1287147783-14998-2-git-send-email-claudio.takahasi@openbossa.org>

Hi Claudio,

On Fri, Oct 15, 2010, Claudio Takahasi wrote:
> ---
>  TODO |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)

This one's also upstream.

Johan

^ permalink raw reply

* Re: [PATCH] TODO: Avoid Characteristic discovery for non connectable device
From: Johan Hedberg @ 2010-10-15 13:55 UTC (permalink / raw)
  To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1287147783-14998-1-git-send-email-claudio.takahasi@openbossa.org>

Hi Claudio,

On Fri, Oct 15, 2010, Claudio Takahasi wrote:
> ---
>  TODO |   13 +++++++++++--
>  1 files changed, 11 insertions(+), 2 deletions(-)

Pushed upstream.

Johan

^ permalink raw reply

* [PATCH] Add INdT developers in AUTHORS
From: Claudio Takahasi @ 2010-10-15 13:36 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Claudio Takahasi

---
 AUTHORS |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index e063569..15351a3 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -50,3 +50,6 @@ Santiago Carot-Nemesio <scarot@libresoft.es>
 José Antonio Santos Cadenas <jcaden@libresoft.es>
 Francisco Alecrim <francisco.alecrim@openbossa.org>
 Daniel Orstadius <daniel.orstadius@gmail.com>
+Anderson Briglia <anderson.briglia@openbossa.org>
+Anderson Lizardo <anderson.lizardo@openbossa.org>
+Bruna Moreira <bruna.moreira@openbossa.org>
-- 
1.7.3.1


^ permalink raw reply related

* [PATCH] TODO: Define attribute server API
From: Claudio Takahasi @ 2010-10-15 13:03 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1287147783-14998-1-git-send-email-claudio.takahasi@openbossa.org>

---
 TODO |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/TODO b/TODO
index 1d4e789..b4682e8 100644
--- a/TODO
+++ b/TODO
@@ -129,3 +129,11 @@ ATT/GATT
 
   Priority: Low
   Complexity: C2
+
+- Define attribute server API. External applications needs to register,
+  change attributes and to be notified about changes. Example: Proximity,
+  Time and Alert Profiles. "Local Service hierarchy" in the attribute-api
+  needs to be proposed and a RFC shall be sent to the ML.
+
+  Priority: Low
+  Complexity: C2
-- 
1.7.3.1


^ permalink raw reply related

* [PATCH] TODO: Avoid Characteristic discovery for non connectable device
From: Claudio Takahasi @ 2010-10-15 13:03 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Claudio Takahasi

---
 TODO |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/TODO b/TODO
index 2c17c6b..1d4e789 100644
--- a/TODO
+++ b/TODO
@@ -14,8 +14,17 @@ Background
   Higher complexity tasks should be refined into several lower complexity tasks
   once the task is better understood.
 
-LE Generic Access Profile
-=========================
+Low Energy
+==========
+
+- Avoid Characteristic discovery for non connectable devices. Proper parsing
+  of LE Advertising Report Event is missing. Event_Type field needs to be
+  extracted and its value shall be considered before to start the LE
+  connection on the channel 4. Characteristic discovery should not be
+  started for non connectable devices.
+
+  Priority: Medium
+  Complexity: C2
 
 - Device Name Characteristic is a GAP characteristic for Low Energy. This
   characteristic shall be integrated/used in the discovery procedure. The
-- 
1.7.3.1


^ permalink raw reply related

* Re: [PATCH] Type conversion in read and write obex streams
From: Johan Hedberg @ 2010-10-15 11:52 UTC (permalink / raw)
  To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1287143179-22136-2-git-send-email-dmitriy.paliy@nokia.com>

Hi Dmitriy,

On Fri, Oct 15, 2010, Dmitriy Paliy wrote:
> Integer types in obex_write_stream and obex_read_stream shell be the
> same as those returned by read and write function prototypes of
> obex_mime_type_driver.
> ---
>  src/obex.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)

Thanks. Pushed upstream.

Johan

^ permalink raw reply

* [PATCH] Type conversion in read and write obex streams
From: Dmitriy Paliy @ 2010-10-15 11:46 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Dmitriy Paliy
In-Reply-To: <1287143179-22136-1-git-send-email-dmitriy.paliy@nokia.com>

Integer types in obex_write_stream and obex_read_stream shell be the
same as those returned by read and write function prototypes of
obex_mime_type_driver.
---
 src/obex.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/obex.c b/src/obex.c
index adfcc95..f37cd90 100644
--- a/src/obex.c
+++ b/src/obex.c
@@ -555,7 +555,7 @@ static int obex_read_stream(struct obex_session *os, obex_t *obex,
 						obex_object_t *obj)
 {
 	int size;
-	int32_t len = 0;
+	ssize_t len = 0;
 	const uint8_t *buffer;
 
 	DBG("name=%s type=%s rx_mtu=%d file=%p",
@@ -596,7 +596,7 @@ static int obex_read_stream(struct obex_session *os, obex_t *obex,
 
 write:
 	while (os->pending > 0) {
-		int w;
+		ssize_t w;
 
 		w = os->driver->write(os->object, os->buf + len,
 					os->pending);
@@ -622,7 +622,7 @@ static int obex_write_stream(struct obex_session *os,
 {
 	obex_headerdata_t hd;
 	uint8_t *ptr;
-	int32_t len;
+	ssize_t len;
 	unsigned int flags;
 	uint8_t hi;
 
@@ -644,7 +644,7 @@ static int obex_write_stream(struct obex_session *os,
 
 	len = os->driver->read(os->object, os->buf, os->tx_mtu, &hi);
 	if (len < 0) {
-		error("read(): %s (%d)", strerror(-len), -len);
+		error("read(): %s (%zd)", strerror(-len), -len);
 		if (len == -EAGAIN)
 			return len;
 		else if (len == -ENOSTR)
-- 
1.7.0.4


^ permalink raw reply related

* [PATCH 0/1] Type conversion in read and write obex streams
From: Dmitriy Paliy @ 2010-10-15 11:46 UTC (permalink / raw)
  To: linux-bluetooth

Hi,

This is to correct previous patch on change of int32_t to ssize_t
types. Printing out is also fixed.

Br,
Dmitriy


^ permalink raw reply

* Re: [PATCH] Type conversion in read and write obex streams
From: Johan Hedberg @ 2010-10-15 11:10 UTC (permalink / raw)
  To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1287138458-10780-1-git-send-email-dmitriy.paliy@nokia.com>

Hi Dmitriy,

On Fri, Oct 15, 2010, Dmitriy Paliy wrote:
> Integer types in obex_write_stream and obex_read_stream shell be the
> same as those returned by read and write function prototypes of
> obex_mime_type_driver.
> ---
>  src/obex.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)

Not good:

src/obex.c: In function ‘obex_write_stream’:
src/obex.c:647: error: format ‘%d’ expects type ‘int’, but argument 3 has type ‘ssize_t’

Always compile-check your patches with ./bootstrap-configure.

The correct format specifier for ssize_t is %zd

Johan

^ permalink raw reply

* [PATCH] Type conversion in read and write obex streams
From: Dmitriy Paliy @ 2010-10-15 10:27 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Dmitriy Paliy

Integer types in obex_write_stream and obex_read_stream shell be the
same as those returned by read and write function prototypes of
obex_mime_type_driver.
---
 src/obex.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/obex.c b/src/obex.c
index adfcc95..0a0b6b9 100644
--- a/src/obex.c
+++ b/src/obex.c
@@ -555,7 +555,7 @@ static int obex_read_stream(struct obex_session *os, obex_t *obex,
 						obex_object_t *obj)
 {
 	int size;
-	int32_t len = 0;
+	ssize_t len = 0;
 	const uint8_t *buffer;
 
 	DBG("name=%s type=%s rx_mtu=%d file=%p",
@@ -596,7 +596,7 @@ static int obex_read_stream(struct obex_session *os, obex_t *obex,
 
 write:
 	while (os->pending > 0) {
-		int w;
+		ssize_t w;
 
 		w = os->driver->write(os->object, os->buf + len,
 					os->pending);
@@ -622,7 +622,7 @@ static int obex_write_stream(struct obex_session *os,
 {
 	obex_headerdata_t hd;
 	uint8_t *ptr;
-	int32_t len;
+	ssize_t len;
 	unsigned int flags;
 	uint8_t hi;
 
-- 
1.7.0.4


^ permalink raw reply related

* Re: [PATCH] Fix not responding Not Found for filtered vcard-listing
From: Johan Hedberg @ 2010-10-15  9:58 UTC (permalink / raw)
  To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1287135959-6605-1-git-send-email-luiz.dentz@gmail.com>

Hi Luiz,

On Fri, Oct 15, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
> 
> In this case entries may be found but it still may not match the filter
> criteria.
> ---
>  plugins/pbap.c |   12 ++++++------
>  1 files changed, 6 insertions(+), 6 deletions(-)

Thanks. Pushed upstream.

Johan

^ permalink raw reply

* [PATCH] Fix not responding Not Found for filtered vcard-listing
From: Luiz Augusto von Dentz @ 2010-10-15  9:45 UTC (permalink / raw)
  To: linux-bluetooth

From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>

In this case entries may be found but it still may not match the filter
criteria.
---
 plugins/pbap.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/plugins/pbap.c b/plugins/pbap.c
index 13742da..11cb678 100644
--- a/plugins/pbap.c
+++ b/plugins/pbap.c
@@ -398,12 +398,6 @@ static void cache_ready_notify(void *user_data)
 		goto done;
 	}
 
-	if (pbap->cache.entries == NULL) {
-		pbap->cache.valid = TRUE;
-		obex_object_set_io_flags(pbap, G_IO_ERR, -ENOENT);
-		return;
-	}
-
 	/*
 	 * Don't free the sorted list content: this list contains
 	 * only the reference for the "real" cache entry.
@@ -412,6 +406,12 @@ static void cache_ready_notify(void *user_data)
 			pbap->params->searchattrib,
 			(const char *) pbap->params->searchval);
 
+	if (sorted == NULL) {
+		pbap->cache.valid = TRUE;
+		obex_object_set_io_flags(pbap, G_IO_ERR, -ENOENT);
+		return;
+	}
+
 	/* Computing offset considering first entry of the phonebook */
 	l = g_slist_nth(sorted, pbap->params->liststartoffset);
 
-- 
1.7.1


^ permalink raw reply related

* Re: [PATCH] Bluetooth: Fix non-SSP auth request for HIGH security level sockets
From: Marcel Holtmann @ 2010-10-15  9:16 UTC (permalink / raw)
  To: johan.hedberg; +Cc: linux-bluetooth, Johan Hedberg
In-Reply-To: <1287128769-5078-1-git-send-email-johan.hedberg@gmail.com>

Hi Johan,

> When initiating dedicated bonding a L2CAP raw socket with HIGH security
> level is used. The kernel is supposed to trigger the authentication
> request in this case but this doesn't happen currently for non-SSP
> (pre-2.1) devices. The reason is that the authentication request happens
> in the remote extended features callback which never gets called for
> non-SSP devices. This patch fixes the issue by requesting also
> authentiation in the (normal) remote features callback in the case of
> non-SSP devices.
> 
> This rule is applied only for HIGH security level which might at first
> seem unintuitive since on the server socket side MEDIUM is already
> enough for authentication. However, for the clients we really want to
> prefer the server side to decide the authentication requrement in most
> cases, and since most client sockets use MEDIUM it's better to be
> avoided on the kernel side for these sockets. The important socket to
> request it for is the dedicated bonding one and that socket uses HIGH
> security level.
> 
> The patch is based on the initial investigation and patch proposal from
> Andrei Emeltchenko <endrei.emeltchenko@nokia.com>.
> 
> Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>

so I had a quick review here on this one. Looks fine to me and it makes
sense.

Acked-by: Marcel Holtmann <marcel@holtmann.org>

Regards

Marcel



^ permalink raw reply

* [PATCH] Bluetooth: Fix non-SSP auth request for HIGH security level sockets
From: johan.hedberg @ 2010-10-15  7:46 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Johan Hedberg

From: Johan Hedberg <johan.hedberg@nokia.com>

When initiating dedicated bonding a L2CAP raw socket with HIGH security
level is used. The kernel is supposed to trigger the authentication
request in this case but this doesn't happen currently for non-SSP
(pre-2.1) devices. The reason is that the authentication request happens
in the remote extended features callback which never gets called for
non-SSP devices. This patch fixes the issue by requesting also
authentiation in the (normal) remote features callback in the case of
non-SSP devices.

This rule is applied only for HIGH security level which might at first
seem unintuitive since on the server socket side MEDIUM is already
enough for authentication. However, for the clients we really want to
prefer the server side to decide the authentication requrement in most
cases, and since most client sockets use MEDIUM it's better to be
avoided on the kernel side for these sockets. The important socket to
request it for is the dedicated bonding one and that socket uses HIGH
security level.

The patch is based on the initial investigation and patch proposal from
Andrei Emeltchenko <endrei.emeltchenko@nokia.com>.

Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
 net/bluetooth/hci_event.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index bfef5ba..84093b0 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1175,6 +1175,12 @@ static inline void hci_remote_features_evt(struct hci_dev *hdev, struct sk_buff
 				hci_send_cmd(hdev,
 					HCI_OP_READ_REMOTE_EXT_FEATURES,
 							sizeof(cp), &cp);
+			} else if (!ev->status && conn->out &&
+					conn->sec_level == BT_SECURITY_HIGH) {
+				struct hci_cp_auth_requested cp;
+				cp.handle = ev->handle;
+				hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED,
+							sizeof(cp), &cp);
 			} else {
 				conn->state = BT_CONNECTED;
 				hci_proto_connect_cfm(conn, ev->status);
-- 
1.7.1


^ permalink raw reply related

* Re: [PATCH 0/2] Fix regression on suspend on opening
From: Johan Hedberg @ 2010-10-15  7:21 UTC (permalink / raw)
  To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1287125828-5479-1-git-send-email-dmitriy.paliy@nokia.com>

Hi Dmitriy,

On Fri, Oct 15, 2010, Dmitriy Paliy wrote:
> This fixes regression when doing suspend on opening obex stream. If
> obex_write_stream returns length of buffer, it is treated as an error
> response later on, which is not correct.
> 
> Negative values returned by obex_write_stream are error codes, while
> positive ones mean length of buffer. Positive values are never used
> afterwards in the code. Therefore, due to this reason, and for being
> compliant with obex_read_stream, which also returns 0 only, it was
> decided to remove return of positive value representing length at all.
> 
> Result of such is also some code cleanup that removes unnecessary return
> len when it is zero.
> 
> A typo is fixed in comments as well.

Both patches have been pushed upstream. Thanks. Btw, don't be afraid to
put this kind of explanations in the commit messages themselves since
that info is easier to find in a couple of years time than this cover
letter email.

Johan

^ permalink raw reply

* [PATCH 2/2] Code cleanup: unnecessary operation and typo removed
From: Dmitriy Paliy @ 2010-10-15  6:57 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Dmitriy Paliy
In-Reply-To: <1287125828-5479-1-git-send-email-dmitriy.paliy@nokia.com>

Code cleanup: unnecessary operation 'return len;' removed and typo in
comments immidiately to immediately corrected.
---
 src/obex.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/src/obex.c b/src/obex.c
index 4e1db9c..adfcc95 100644
--- a/src/obex.c
+++ b/src/obex.c
@@ -678,7 +678,6 @@ add_header:
 	if (len == 0) {
 		g_free(os->buf);
 		os->buf = NULL;
-		return len;
 	}
 
 	os->offset += len;
@@ -818,7 +817,7 @@ static void cmd_get(struct obex_session *os, obex_t *obex, obex_object_t *obj)
 		OBEX_ObjectAddHeader (obex, obj, OBEX_HDR_BODY,
 				hd, 0, OBEX_FL_STREAM_START);
 
-		/* Try to write to stream and suspend the stream immidiately
+		/* Try to write to stream and suspend the stream immediately
 		 * if no data available to send. */
 		err = obex_write_stream(os, obex, obj);
 		if (err == -EAGAIN) {
-- 
1.7.0.4


^ permalink raw reply related

* [PATCH 1/2] Fix regression on suspend on opening
From: Dmitriy Paliy @ 2010-10-15  6:57 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Dmitriy Paliy
In-Reply-To: <1287125828-5479-1-git-send-email-dmitriy.paliy@nokia.com>

This fixes regression on suspend on opening when obex_write_stream
returns length of buffer, which is treated as error response
afterwards.
---
 src/obex.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/obex.c b/src/obex.c
index d1ac339..4e1db9c 100644
--- a/src/obex.c
+++ b/src/obex.c
@@ -683,7 +683,7 @@ add_header:
 
 	os->offset += len;
 
-	return len;
+	return 0;
 }
 
 static gboolean handle_async_io(void *object, int flags, int err,
-- 
1.7.0.4


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox