* Re: [PATCH 0/5] SBC encoder optimizations for ARM processors
From: Johan Hedberg @ 2010-07-02 19:04 UTC (permalink / raw)
To: Siarhei Siamashka; +Cc: linux-bluetooth, Siarhei Siamashka
In-Reply-To: <1278073542-14859-1-git-send-email-siarhei.siamashka@gmail.com>
Hi Siarhei,
On Fri, Jul 02, 2010, Siarhei Siamashka wrote:
> This patch series adds a bunch of ARM assembly optimizations.
>
> Now all the functions from 'sbc_primitives.c' got NEON optimized
> variants. As benchmarked with the common A2DP case (44100kHz audio
> with bitpool set to 53, 8 subbands, joint stereo), SBC encoding is
> now approximately 1.6x faster overall when compared to bluez-4.66.
> Some more room for improvement still exists though.
>
> For ARMv6 processors, only analysis filter has been implemented
> (using dual 16-bit multiply-accumulate instructions). But that's
> the most important optimization and it doubles performance already.
> And older processors such as ARM11 are much slower, so they
> definitely benefit more on a relative scale (Nokia N800/N810 users
> may find this update useful).
>
> All the optimizations are bitexact. Given the same input, they provide
> the same output as the SBC encoder from the previous bluez versions.
>
> Patches are also available in the branch 'sbc-arm-optimizations' here:
> git://gitorious.org/system-performance/bluez-sbc.git
>
> Siarhei Siamashka (5):
> sbc: ARM NEON optimized joint stereo processing in SBC encoder
> sbc: ARM NEON optimizations for input permutation in SBC encoder
> sbc: slightly faster 'sbc_calc_scalefactors_neon'
> sbc: faster 'sbc_calculate_bits' function
> sbc: ARMv6 optimized version of analysis filter for SBC encoder
>
> Makefile.am | 3 +-
> sbc/sbc.c | 43 ++-
> sbc/sbc_primitives.c | 4 +
> sbc/sbc_primitives_armv6.c | 299 +++++++++++++++++++++
> sbc/sbc_primitives_armv6.h | 52 ++++
> sbc/sbc_primitives_neon.c | 618 ++++++++++++++++++++++++++++++++++++++++++-
> 6 files changed, 988 insertions(+), 31 deletions(-)
> create mode 100644 sbc/sbc_primitives_armv6.c
> create mode 100644 sbc/sbc_primitives_armv6.h
Thanks for these! They've all been pushed upstream now.
Johan
^ permalink raw reply
* Re: Bug with Alias
From: Luiz Augusto von Dentz @ 2010-07-02 20:28 UTC (permalink / raw)
To: Vinicius Gomes; +Cc: linux-bluetooth
In-Reply-To: <AANLkTik1haoPxJzpRsQ2FPFhOjYCcOqYVtug9eQVNIkc@mail.gmail.com>
Hi,
On Fri, Jul 2, 2010 at 4:56 PM, Vinicius Gomes
<vinicius.gomes@openbossa.org> wrote:
> Hi Peter,
>
> On Thu, Jul 1, 2010 at 10:33 AM, Peter Kornatowski <pkorn@gmx.net> wrote:
>> Hello,
>>
>> I have several headsets of the same model, so I set an Alias for each to
>> distinguish them in my own application. But since bluez 4.64 the Alias is
>> bugged. Sometimes after a reboot or after a bluez restart when i read out
>> the Alias through the dbus api, I get the Name instead. I also tried to read
>> it with d-feet or through a dbus-send call (dbus-send --system --print-reply
>> --dest=org.bluez /org/bluez/11344/hci0/dev_00_XX_XX_XX_XX_XX
>> org.bluez.Device.GetProperties) and also got the Name instead of the Alias.
>> But in the aliases file under /var/lib/bluetooth/XX:XX:XX:XX:XX:XX/aliases
>> is the correct Alias. The bug seems to have something to do with the commit
>> 48a2c31cdbc1f2ac2a2bbadbd505976f84a9eaca
>> (http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=48a2c31cdbc1f2ac2a2bbadbd505976f84a9eaca).
>
> Thanks for the bug report.
>
> I suggested a fix[1], waiting for review.
>
>> I hope someone can resolve this issue.
>>
>> Thanks,
>> Peter
Thanks vinicius, that should fix the problem and thanks peter to find
out about this.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* hciconfig manual page bug
From: Göran Uddeborg @ 2010-07-04 17:25 UTC (permalink / raw)
To: linux-bluetooth
Is this the right place to report a bug in the manual page for
hciconfig? If so, the synopsis on the page says
hciconfig [-a] [command [command parameters]]
but the correct syntax seems to be
hciconfig [-a] hciX [command [command parameters]]
for some X. That is also what "hciconfig -h" says.
^ permalink raw reply
* [PATCH] bluetooth: btmrvl_sdio: silence warning
From: Kulikov Vasiliy @ 2010-07-05 8:01 UTC (permalink / raw)
To: Kernel Janitors
Cc: Marcel Holtmann, Bing Zhao, Ben Hutchings,
André Goddard Rosa, Julia Lawall, linux-bluetooth,
linux-kernel
Clone checking of ret to simplify the code.
This patch silences a compiler warning:
drivers/bluetooth/btmrvl_sdio.c: In function ‘btmrvl_sdio_verify_fw_download’:
drivers/bluetooth/btmrvl_sdio.c:80: warning: ‘fws1’ may be used uninitialized in this function
drivers/bluetooth/btmrvl_sdio.c:80: note: ‘fws1’ was declared here
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/bluetooth/btmrvl_sdio.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index df0773e..47f0f91 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -83,10 +83,10 @@ static int btmrvl_sdio_read_fw_status(struct btmrvl_sdio_card *card, u16 *dat)
*dat = 0;
fws0 = sdio_readb(card->func, CARD_FW_STATUS0_REG, &ret);
+ if (ret)
+ return -EIO;
- if (!ret)
- fws1 = sdio_readb(card->func, CARD_FW_STATUS1_REG, &ret);
-
+ fws1 = sdio_readb(card->func, CARD_FW_STATUS1_REG, &ret);
if (ret)
return -EIO;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] bluetooth: btmrvl_sdio: silence warning
From: Dan Carpenter @ 2010-07-05 9:24 UTC (permalink / raw)
To: Kulikov Vasiliy
Cc: Kernel Janitors, Marcel Holtmann, Bing Zhao, Ben Hutchings,
André Goddard Rosa, Julia Lawall, linux-bluetooth,
linux-kernel
In-Reply-To: <1278316883-29784-1-git-send-email-segooon@gmail.com>
On Mon, Jul 05, 2010 at 12:01:22PM +0400, Kulikov Vasiliy wrote:
> Clone checking of ret to simplify the code.
>
> This patch silences a compiler warning:
> drivers/bluetooth/btmrvl_sdio.c: In function ‘btmrvl_sdio_verify_fw_download’:
> drivers/bluetooth/btmrvl_sdio.c:80: warning: ‘fws1’ may be used uninitialized in this function
> drivers/bluetooth/btmrvl_sdio.c:80: note: ‘fws1’ was declared here
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
> ---
> drivers/bluetooth/btmrvl_sdio.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
> index df0773e..47f0f91 100644
> --- a/drivers/bluetooth/btmrvl_sdio.c
> +++ b/drivers/bluetooth/btmrvl_sdio.c
> @@ -83,10 +83,10 @@ static int btmrvl_sdio_read_fw_status(struct btmrvl_sdio_card *card, u16 *dat)
> *dat = 0;
>
> fws0 = sdio_readb(card->func, CARD_FW_STATUS0_REG, &ret);
> + if (ret)
> + return -EIO;
Normally it would be better to just "return ret;" here. But the caller
doesn't use the return code so it doesn't really matter...
Reviewed-by: Dan Carpenter <error27@gmail.com>
regards,
dan carpenter
>
> - if (!ret)
> - fws1 = sdio_readb(card->func, CARD_FW_STATUS1_REG, &ret);
> -
> + fws1 = sdio_readb(card->func, CARD_FW_STATUS1_REG, &ret);
> if (ret)
> return -EIO;
>
^ permalink raw reply
* [RFC] Bluetooth: Add firmware load infrastructure for BT devices
From: Bala Shanmugam @ 2010-07-05 12:37 UTC (permalink / raw)
To: marcel; +Cc: linux-bluetooth, Bala Shanmugam
Added support to load firmware to target RAM from Bluetooth USB transport
driver. Each BT device vendor need to specify the product ID, firmware file,
load and unload function. When the device is inserted, btusb will call
appropriate firmware load function to load firmware to target RAM.
This framework is needed for devices that are detected as BT devices when
powered on and still require firmware to be downaloded.
Signed-off-by: Bala Shanmugam <sbalashanmugam@atheros.com>
---
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/btusb.c | 50 ++++++++++++
drivers/bluetooth/fwload.c | 187 ++++++++++++++++++++++++++++++++++++++++++++
drivers/bluetooth/fwload.h | 37 +++++++++
4 files changed, 275 insertions(+), 0 deletions(-)
create mode 100644 drivers/bluetooth/fwload.c
create mode 100644 drivers/bluetooth/fwload.h
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 7e5aed5..43df710 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_BT_HCIBLUECARD) += bluecard_cs.o
obj-$(CONFIG_BT_HCIBTUART) += btuart_cs.o
obj-$(CONFIG_BT_HCIBTUSB) += btusb.o
+obj-$(CONFIG_BT_HCIBTUSB) += fwload.o
obj-$(CONFIG_BT_HCIBTSDIO) += btsdio.o
obj-$(CONFIG_BT_ATH3K) += ath3k.o
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5d9cc53..816c772 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -34,6 +34,7 @@
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
+#include "fwload.h"
#define VERSION "0.6"
@@ -55,6 +56,24 @@ static struct usb_driver btusb_driver;
#define BTUSB_BROKEN_ISOC 0x20
#define BTUSB_WRONG_SCO_MTU 0x40
+static struct usb_device_id ath_table[] = {
+ /* Atheros AR3011 */
+ { USB_DEVICE(0x0CF3, 0x3002) },
+ { } /* Terminating entry */
+};
+
+/* Add firmware file, load and unload function
+ * to download the firmware to target RAM
+ */
+static struct fw_cb_config btusb_fwcbs[] = {
+ {
+ .fwfile = "ath3k-1.fw",
+ .usb_id_table = ath_table,
+ .fwload = ath_fw_load,
+ .fwunload = ath_fw_unload,
+ },
+ {}
+};
static struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
@@ -862,6 +881,7 @@ static int btusb_probe(struct usb_interface *intf,
struct btusb_data *data;
struct hci_dev *hdev;
int i, err;
+ const struct usb_device_id *match;
BT_DBG("intf %p id %p", intf, id);
@@ -921,6 +941,15 @@ static int btusb_probe(struct usb_interface *intf,
data->udev = interface_to_usbdev(intf);
data->intf = intf;
+ for (i = 0; btusb_fwcbs[i].fwfile; i++) {
+ match = usb_match_id(intf, btusb_fwcbs[i].usb_id_table);
+ if (match && btusb_fwcbs[i].fwload) {
+ btusb_fwcbs[i].data = btusb_fwcbs[i].fwload(intf,
+ btusb_fwcbs[i].fwfile);
+ break;
+ }
+ }
+
spin_lock_init(&data->lock);
INIT_WORK(&data->work, btusb_work);
@@ -1029,12 +1058,25 @@ static void btusb_disconnect(struct usb_interface *intf)
{
struct btusb_data *data = usb_get_intfdata(intf);
struct hci_dev *hdev;
+ const struct usb_device_id *match;
+ int i;
BT_DBG("intf %p", intf);
if (!data)
return;
+ for (i = 0; btusb_fwcbs[i].fwfile; i++) {
+ match = usb_match_id(intf, btusb_fwcbs[i].usb_id_table);
+ if (match) {
+ if (btusb_fwcbs[i].fwunload) {
+ btusb_fwcbs[i].fwunload(btusb_fwcbs[i].data);
+ btusb_fwcbs[i].data = NULL;
+ }
+ break;
+ }
+ }
+
hdev = data->hdev;
__hci_dev_hold(hdev);
@@ -1178,6 +1220,14 @@ static int __init btusb_init(void)
static void __exit btusb_exit(void)
{
+ int i;
+
+ for (i = 0; btusb_fwcbs[i].fwfile; i++) {
+ if (btusb_fwcbs[i].fwunload && btusb_fwcbs[i].data) {
+ btusb_fwcbs[i].fwunload(btusb_fwcbs[i].data);
+ btusb_fwcbs[i].data = NULL;
+ }
+ }
usb_deregister(&btusb_driver);
}
diff --git a/drivers/bluetooth/fwload.c b/drivers/bluetooth/fwload.c
new file mode 100644
index 0000000..1135abc
--- /dev/null
+++ b/drivers/bluetooth/fwload.c
@@ -0,0 +1,187 @@
+/*
+ *
+ * Generic Bluetooth USB DFU driver to download firmware to target RAM
+ *
+ * Copyright (c) 2009-2010 Atheros Communications Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/device.h>
+#include <linux/firmware.h>
+#include <linux/usb.h>
+#include <net/bluetooth/bluetooth.h>
+
+#define USB_REQ_DFU_DNLOAD 1
+#define USB_REQ_GET_STATE 5
+#define USB_FIRMWARE_RAM_MODE 11
+#define USB_FIRMWARE_FLASH_MODE 12
+#define BULK_SIZE 4096
+#define VERSION "1.0"
+
+struct firmware_data {
+ struct usb_device *udev;
+ u8 *fw_data;
+ u32 fw_size;
+ u32 fw_sent;
+};
+
+static int load_firmware(struct firmware_data *data,
+ unsigned char *firmware,
+ int count)
+{
+ u8 *send_buf;
+ int err, pipe, len, size, sent = 0;
+ char ucFirmware = 0;
+
+ BT_DBG("ath3k %p udev %p", data, data->udev);
+
+ if ((usb_control_msg(data->udev, usb_rcvctrlpipe(data->udev, 0),
+ USB_REQ_GET_STATE,
+ USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
+ &ucFirmware, 1, USB_CTRL_SET_TIMEOUT)) < 0) {
+ BT_ERR("Can't change to loading configuration err");
+ return -EBUSY;
+ }
+
+ if (ucFirmware == USB_FIRMWARE_RAM_MODE) {
+ /* RAM based firmware is available in the target.
+ * No need to load the firmware to RAM */
+ BT_DBG("RAM based firmware is available");
+ return 0;
+ }
+
+ pipe = usb_sndctrlpipe(data->udev, 0);
+ if ((usb_control_msg(data->udev, pipe,
+ USB_REQ_DFU_DNLOAD,
+ USB_TYPE_VENDOR, 0, 0,
+ firmware, 20, USB_CTRL_SET_TIMEOUT)) < 0) {
+ BT_ERR("Can't change to loading configuration err");
+ return -EBUSY;
+ }
+ sent += 20;
+ count -= 20;
+
+ send_buf = kmalloc(BULK_SIZE, GFP_ATOMIC);
+ if (!send_buf) {
+ BT_ERR("Can't allocate memory chunk for firmware");
+ return -ENOMEM;
+ }
+
+ while (count) {
+ size = min_t(uint, count, BULK_SIZE);
+ pipe = usb_sndbulkpipe(data->udev, 0x02);
+ memcpy(send_buf, firmware + sent, size);
+
+ err = usb_bulk_msg(data->udev, pipe, send_buf, size,
+ &len, 3000);
+
+ if (err || (len != size)) {
+ BT_ERR("Error in firmware loading err = %d,"
+ "len = %d, size = %d", err, len, size);
+ goto error;
+ }
+
+ sent += size;
+ count -= size;
+ }
+
+ kfree(send_buf);
+ return 0;
+
+error:
+ kfree(send_buf);
+ return err;
+}
+
+void *ath_fw_load(struct usb_interface *intf, const char *fwfile)
+{
+ const struct firmware *firmware;
+ struct usb_device *udev = interface_to_usbdev(intf);
+ struct firmware_data *data;
+ int size;
+
+ BT_DBG("intf %p ", intf);
+
+ if (intf->cur_altsetting->desc.bInterfaceNumber != 0)
+ return NULL;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return NULL;
+
+ data->udev = udev;
+
+ if (request_firmware(&firmware, fwfile, &udev->dev) < 0) {
+ kfree(data);
+ return NULL;
+ }
+
+ size = max_t(uint, firmware->size, 4096);
+ data->fw_data = kmalloc(size, GFP_KERNEL);
+ if (!data->fw_data) {
+ release_firmware(firmware);
+ kfree(data);
+ return NULL;
+ }
+
+ memcpy(data->fw_data, firmware->data, firmware->size);
+ data->fw_size = firmware->size;
+ data->fw_sent = 0;
+ release_firmware(firmware);
+
+ if (load_firmware(data, data->fw_data, data->fw_size)) {
+ kfree(data->fw_data);
+ kfree(data);
+ return NULL;
+ }
+ return data;
+}
+EXPORT_SYMBOL(ath_fw_load);
+
+void ath_fw_unload(void *pdata)
+{
+ struct firmware_data *data = (struct firmware_data *)pdata;
+ if (data == NULL)
+ return;
+ kfree(data->fw_data);
+ kfree(data);
+}
+EXPORT_SYMBOL(ath_fw_unload);
+
+static int __init fwload_init(void)
+{
+ BT_INFO("Firmware load driver init. Version:%s", VERSION);
+ return 0;
+}
+
+static void __exit fwload_deinit(void)
+{
+ BT_INFO("Firmware load driver deinit");
+}
+
+module_init(fwload_init);
+module_exit(fwload_deinit);
+
+MODULE_AUTHOR("Atheros Communications");
+MODULE_DESCRIPTION("Firmware load driver");
+MODULE_VERSION(VERSION);
+MODULE_LICENSE("GPL");
diff --git a/drivers/bluetooth/fwload.h b/drivers/bluetooth/fwload.h
new file mode 100644
index 0000000..ce1c841
--- /dev/null
+++ b/drivers/bluetooth/fwload.h
@@ -0,0 +1,37 @@
+/*
+ *
+ * Generic Bluetooth USB DFU driver to download firmware to target RAM
+ *
+ * Copyright (c) 2009-2010 Atheros Communications Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+#ifndef __FWLOAD_H_
+#define __FWLOAD_H_
+
+/* callbacks to load firmware to BT device RAM
+ * when it is inserted */
+struct fw_cb_config {
+ const char *fwfile;
+ void * (*fwload)(struct usb_interface *intf, const char *fwfile);
+ void (*fwunload)(void *);
+ const struct usb_device_id *usb_id_table;
+ void *data;
+};
+void *ath_fw_load(struct usb_interface *intf, const char *);
+void ath_fw_unload(void *pdata);
+
+#endif /* __FWLOAD_H_ */
--
1.6.3.3
^ permalink raw reply related
* Next BlueZ developer meeting
From: Marcel Holtmann @ 2010-07-05 20:55 UTC (permalink / raw)
To: linux-bluetooth
Hello everyone,
our next BlueZ developer meeting will be held as mini-summit as part of
the LinuxCon in Boston.
http://events.linuxfoundation.org/events/linuxcon/mini-summits
I like to invite interested developers to join us in Boston. The summit
will be held on Sunday, 8th and Monday, 9th of July. On Sunday we will
have a half day event with introductions, lighting talks and defining
the agenda for Monday. On Monday we will have the technical discussion.
The core topics are Bluetooth 3.0 (aka High Speed) and Bluetooth 4.0
support (aka Low Energy). This includes subtopics like AMP, Security
Manager, eL2CAP, Attribute Protocol & Profile. Additionally new profiles
like HDP, MAP etc. will be discussed. Also the integration of BlueZ into
oFono and ConnMan is part of the discussion points as well.
For attending the mini-summit it is required to register with the
LinuxCon. If you plan to attend, please let me know by private email so
we can finalize the planning.
Regards
Marcel
^ permalink raw reply
* Re: Next BlueZ developer meeting
From: Marcel Holtmann @ 2010-07-06 1:28 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1278363322.2789.23.camel@localhost.localdomain>
Hello again,
> our next BlueZ developer meeting will be held as mini-summit as part of
> the LinuxCon in Boston.
>
> http://events.linuxfoundation.org/events/linuxcon/mini-summits
>
> I like to invite interested developers to join us in Boston. The summit
> will be held on Sunday, 8th and Monday, 9th of July.
I obviously meant 8th and 9th of August. Sorry for the confusion.
Regards
Marcel
^ permalink raw reply
* RE: Modem emulator and DUN server side for oFono and BlueZ
From: suraj @ 2010-07-06 8:30 UTC (permalink / raw)
To: Zhang, Zhenhua; +Cc: ofono@ofono.org, linux-bluetooth@vger.kernel.org
In-Reply-To: <33AB447FBD802F4E932063B962385B351E6578C9@shsmsx501.ccr.corp.intel.com>
Hi Zhenhua,
On Wed, 2010-05-05 at 06:27 +0530, Zhang, Zhenhua wrote:
> Hi Padovan,
>
> Gustavo F. Padovan wrote:
> > Hi Zhenhua,
> >
> > * Zhang, Zhenhua <zhenhua.zhang@intel.com> [2010-04-27 15:53:54
> > +0800]:
> >
> >> Hi,
> >>
> >> I am now working on modem emulator and one usage is for DUN
> > server role. Since Padovan is working on client role, it's
> > good to share my rough thinking for server side
> > implementation. Here are the simple steps I have:
> >>
> >> 1. Create an oFono emulator atom in oFono. It's the emulator
> > manager that could create DUN, HFP AG or SPP type emulators.
> > It exposes dbus methods like CreateEmulator, DestroyEmulator,
> > GetProperty, etc.
> >>
> >> 2. DUN agent server in BlueZ watch oFono and call
> > CreateEmulator and pass the file descriptor to oFono. This
> > server could further implement HFP AG and SPP connection.
> >
> >
> > Shouldn't the emulator register itself on the BlueZ agent server?
>
> It's fine to register the emulator like HFP client. In this way, we might able to share the agent with DUN server as well. Thanks.
>
> >
> > --
> > Gustavo F. Padovan
> > http://padovan.org
> > _______________________________________________
> > ofono mailing list
> > ofono@ofono.org
> > http://lists.ofono.org/listinfo/ofono
>
>
>
> Regards,
> Zhenhua
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Do you have DUNP server emulator implemented?
I was thinking about implementing the same. But would like to use your
implementation if you have already done it.
Regards
Suraj
^ permalink raw reply
* RE: Modem emulator and DUN server side for oFono and BlueZ
From: Zhang, Zhenhua @ 2010-07-06 9:30 UTC (permalink / raw)
To: suraj; +Cc: ofono@ofono.org, linux-bluetooth@vger.kernel.org
In-Reply-To: <1278405050.4538.5.camel@atheros013-desktop>
SGkgU3VyYWosDQoNCnN1cmFqIHdyb3RlOg0KPiBIaSBaaGVuaHVhLA0KPiANCj4gDQo+IE9uIFdl
ZCwgMjAxMC0wNS0wNSBhdCAwNjoyNyArMDUzMCwgWmhhbmcsIFpoZW5odWEgd3JvdGU6DQo+PiBI
aSBQYWRvdmFuLA0KPj4gDQo+PiBHdXN0YXZvIEYuIFBhZG92YW4gd3JvdGU6DQo+Pj4gSGkgWmhl
bmh1YSwNCj4+PiANCj4+PiAqIFpoYW5nLCBaaGVuaHVhIDx6aGVuaHVhLnpoYW5nQGludGVsLmNv
bT4gWzIwMTAtMDQtMjcgMTU6NTM6NTQNCj4+PiArMDgwMF06IA0KPj4+IA0KPj4+PiBIaSwNCj4+
Pj4gDQo+Pj4+IEkgYW0gbm93IHdvcmtpbmcgb24gbW9kZW0gZW11bGF0b3IgYW5kIG9uZSB1c2Fn
ZSBpcyBmb3IgRFVODQo+Pj4gc2VydmVyIHJvbGUuIFNpbmNlIFBhZG92YW4gaXMgd29ya2luZyBv
biBjbGllbnQgcm9sZSwgaXQncw0KPj4+IGdvb2QgdG8gc2hhcmUgbXkgcm91Z2ggdGhpbmtpbmcg
Zm9yIHNlcnZlciBzaWRlDQo+Pj4gaW1wbGVtZW50YXRpb24uIEhlcmUgYXJlIHRoZSBzaW1wbGUg
c3RlcHMgSSBoYXZlOg0KPj4+PiANCj4+Pj4gMS4gQ3JlYXRlIGFuIG9Gb25vIGVtdWxhdG9yIGF0
b20gaW4gb0Zvbm8uIEl0J3MgdGhlIGVtdWxhdG9yDQo+Pj4gbWFuYWdlciB0aGF0IGNvdWxkIGNy
ZWF0ZSBEVU4sIEhGUCBBRyBvciBTUFAgdHlwZSBlbXVsYXRvcnMuDQo+Pj4gSXQgZXhwb3NlcyBk
YnVzIG1ldGhvZHMgbGlrZSBDcmVhdGVFbXVsYXRvciwgRGVzdHJveUVtdWxhdG9yLA0KPj4+IEdl
dFByb3BlcnR5LCBldGMuDQo+Pj4+IA0KPj4+PiAyLiBEVU4gYWdlbnQgc2VydmVyIGluIEJsdWVa
IHdhdGNoIG9Gb25vIGFuZCBjYWxsDQo+Pj4gQ3JlYXRlRW11bGF0b3IgYW5kIHBhc3MgdGhlIGZp
bGUgZGVzY3JpcHRvciB0byBvRm9uby4gVGhpcw0KPj4+IHNlcnZlciBjb3VsZCBmdXJ0aGVyIGlt
cGxlbWVudCBIRlAgQUcgYW5kIFNQUCBjb25uZWN0aW9uLg0KPj4+IA0KPj4+IA0KPj4+IFNob3Vs
ZG4ndCB0aGUgZW11bGF0b3IgcmVnaXN0ZXIgaXRzZWxmIG9uIHRoZSBCbHVlWiBhZ2VudCBzZXJ2
ZXI/DQo+PiANCj4+IEl0J3MgZmluZSB0byByZWdpc3RlciB0aGUgZW11bGF0b3IgbGlrZSBIRlAg
Y2xpZW50LiBJbiB0aGlzDQo+IHdheSwgd2UgbWlnaHQgYWJsZSB0byBzaGFyZSB0aGUgYWdlbnQg
d2l0aCBEVU4gc2VydmVyIGFzIHdlbGwuIFRoYW5rcy4NCj4+IA0KPj4+IA0KPj4+IC0tDQo+Pj4g
R3VzdGF2byBGLiBQYWRvdmFuDQo+Pj4gaHR0cDovL3BhZG92YW4ub3JnDQo+Pj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBvZm9ubyBtYWlsaW5n
IGxpc3QNCj4+PiBvZm9ub0BvZm9uby5vcmcNCj4+PiBodHRwOi8vbGlzdHMub2Zvbm8ub3JnL2xp
c3RpbmZvL29mb25vDQo+PiANCj4+IA0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gWmhlbmh1YQ0KPj4g
DQo+PiAtLQ0KPj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUg
InVuc3Vic2NyaWJlDQo+PiBsaW51eC1ibHVldG9vdGgiIGluIHRoZSBib2R5IG9mIGEgbWVzc2Fn
ZSB0bw0KPj4gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZyANCj4+IE1vcmUgbWFqb3Jkb21vIGlu
Zm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0KPiANCj4g
RG8geW91IGhhdmUgRFVOUCBzZXJ2ZXIgZW11bGF0b3IgaW1wbGVtZW50ZWQ/DQo+IEkgd2FzIHRo
aW5raW5nIGFib3V0IGltcGxlbWVudGluZyB0aGUgc2FtZS4gQnV0IHdvdWxkIGxpa2UgdG8gdXNl
IHlvdXINCj4gaW1wbGVtZW50YXRpb24gaWYgeW91IGhhdmUgYWxyZWFkeSBkb25lIGl0Lg0KPiAN
Cj4gUmVnYXJkcw0KPiBTdXJhag0KDQpZZXMsIEkgYW0gd29ya2luZyBEVU4gc2VydmVyIHBhcnQg
bm93LiAoSSBhc3N1bWUgJ0RVTlAnIHlvdSBtZW50aW9uZWQgaXMgJ0RVTicsIGRpYWxpbmcgdXAg
bmV0d29ya2luZykuIEkgYW0gdHJ5aW5nIHRvIHN1Ym1pdCBwYXRjaGVzIHRvIHVwc3RyZWFtIG5v
dy4gSG9wZSBpdCBjb3VsZCBiZSByZWFkeSBhc2FwIHNvIHlvdSBjYW4gdHJ5IGl0IGlmIGludGVy
ZXN0ZWQuIFRoYW5rcy4NCg0KUmVnYXJkcywNClpoZW5odWENCg0K
^ permalink raw reply
* RE: Modem emulator and DUN server side for oFono and BlueZ
From: suraj @ 2010-07-06 9:37 UTC (permalink / raw)
To: Zhang, Zhenhua
Cc: Suraj Sumangala, ofono@ofono.org, linux-bluetooth@vger.kernel.org
In-Reply-To: <33AB447FBD802F4E932063B962385B351F6F2256@shsmsx501.ccr.corp.intel.com>
Hi Zhenhua,
On Tue, 2010-07-06 at 15:00 +0530, Zhang, Zhenhua wrote:
> Hi Suraj,
>
> suraj wrote:
> > Hi Zhenhua,
> >
> >
> > On Wed, 2010-05-05 at 06:27 +0530, Zhang, Zhenhua wrote:
> >> Hi Padovan,
> >>
> >> Gustavo F. Padovan wrote:
> >>> Hi Zhenhua,
> >>>
> >>> * Zhang, Zhenhua <zhenhua.zhang@intel.com> [2010-04-27 15:53:54
> >>> +0800]:
> >>>
> >>>> Hi,
> >>>>
> >>>> I am now working on modem emulator and one usage is for DUN
> >>> server role. Since Padovan is working on client role, it's
> >>> good to share my rough thinking for server side
> >>> implementation. Here are the simple steps I have:
> >>>>
> >>>> 1. Create an oFono emulator atom in oFono. It's the emulator
> >>> manager that could create DUN, HFP AG or SPP type emulators.
> >>> It exposes dbus methods like CreateEmulator, DestroyEmulator,
> >>> GetProperty, etc.
> >>>>
> >>>> 2. DUN agent server in BlueZ watch oFono and call
> >>> CreateEmulator and pass the file descriptor to oFono. This
> >>> server could further implement HFP AG and SPP connection.
> >>>
> >>>
> >>> Shouldn't the emulator register itself on the BlueZ agent server?
> >>
> >> It's fine to register the emulator like HFP client. In this
> > way, we might able to share the agent with DUN server as well. Thanks.
> >>
> >>>
> >>> --
> >>> Gustavo F. Padovan
> >>> http://padovan.org
> >>> _______________________________________________
> >>> ofono mailing list
> >>> ofono@ofono.org
> >>> http://lists.ofono.org/listinfo/ofono
> >>
> >>
> >>
> >> Regards,
> >> Zhenhua
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-bluetooth" in the body of a message to
> >> majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > Do you have DUNP server emulator implemented?
> > I was thinking about implementing the same. But would like to use your
> > implementation if you have already done it.
> >
> > Regards
> > Suraj
>
> Yes, I am working DUN server part now. (I assume 'DUNP' you mentioned is 'DUN', dialing up networking). I am trying to submit patches to upstream now. Hope it could be ready asap so you can try it if interested. Thanks.
>
> Regards,
> Zhenhua
>
Thank you. You are right, I meant DUN server.
I will use your patches when it is ready.
Regards
Suraj
^ permalink raw reply
* Re: [PATCH] Bluetooth: check l2cap pending status before sending l2cap connect request
From: Andrei Emeltchenko @ 2010-07-06 10:11 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1277278237-29377-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
On Wed, Jun 23, 2010 at 10:30 AM, Emeltchenko Andrei
<Andrei.Emeltchenko.news@gmail.com> wrote:
ping
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Due to race condition in L2CAP state machine L2CAP Connection Request
> may be sent twice for SDP with the same source channel id. Problems
> reported connecting to Apple products, some carkit, Blackberry phones.
>
> ...
> 2010-06-07 21:18:03.651031 < ACL data: handle 1 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 1 scid 0x0040
> 2010-06-07 21:18:03.653473 > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 1 packets 1
> 2010-06-07 21:18:03.653808 > HCI Event: Auth Complete (0x06) plen 3
> status 0x00 handle 1
> 2010-06-07 21:18:03.653869 < ACL data: handle 1 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 1 scid 0x0040
> ...
>
> Patch uses L2CAP_CONF_CONNECT_PEND flag to mark that L2CAP Connection
> Request has been sent.
>
> Modified version of Ville Tervo patch.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/l2cap.c | 11 +++++++++--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index bb00015..7f82f7b 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -409,13 +409,16 @@ static void l2cap_do_start(struct sock *sk)
> if (!(conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE))
> return;
>
> - if (l2cap_check_security(sk)) {
> + if (l2cap_check_security(sk) &&
> + !(l2cap_pi(sk)->conf_state &
> + L2CAP_CONF_CONNECT_PEND)) {
> struct l2cap_conn_req req;
> req.scid = cpu_to_le16(l2cap_pi(sk)->scid);
> req.psm = l2cap_pi(sk)->psm;
>
> l2cap_pi(sk)->ident = l2cap_get_ident(conn);
>
> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
> l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
> L2CAP_CONN_REQ, sizeof(req), &req);
> }
> @@ -464,13 +467,16 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
> }
>
> if (sk->sk_state == BT_CONNECT) {
> - if (l2cap_check_security(sk)) {
> + if (l2cap_check_security(sk) &&
> + !(l2cap_pi(sk)->conf_state &
> + L2CAP_CONF_CONNECT_PEND)) {
> struct l2cap_conn_req req;
> req.scid = cpu_to_le16(l2cap_pi(sk)->scid);
> req.psm = l2cap_pi(sk)->psm;
>
> l2cap_pi(sk)->ident = l2cap_get_ident(conn);
>
> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
> l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
> L2CAP_CONN_REQ, sizeof(req), &req);
> }
> @@ -4407,6 +4413,7 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
>
> l2cap_pi(sk)->ident = l2cap_get_ident(conn);
>
> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
> l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
> L2CAP_CONN_REQ, sizeof(req), &req);
> } else {
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv1 0/2] Don't delete l2cap chan and sk when sk is owned by user
From: Andrei Emeltchenko @ 2010-07-06 10:20 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTinfV50-6wEG8ylEc6XTZXtCpcwZDYick-0GcIlO@mail.gmail.com>
On Mon, Jun 7, 2010 at 5:11 PM, Andrei Emeltchenko
<andrei.emeltchenko.news@gmail.com> wrote:
> On Wed, May 26, 2010 at 5:21 PM, Emeltchenko Andrei
> <Andrei.Emeltchenko.news@gmail.com> wrote:
>> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>>
>> When sk is owned by user we shall not delete l2cap shannel structures and socket sk.
>> The first patch which is less hackish than using timer to delete l2cap channel.
>>
>> Andrei Emeltchenko (2):
>> Bluetooth: Check sk is not owned before freeing l2cap_conn
>> Bluetooth: Prevent sk freeing in tasklet using refcount
>>
>> net/bluetooth/l2cap.c | 16 +++++++++++++---
>> 1 files changed, 13 insertions(+), 3 deletions(-)
>
> Ping
Ping
^ permalink raw reply
* using hci0 interface without DEVUP
From: Pavan Savoy @ 2010-07-06 12:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcel Holtmann, kobile, pavan savoy
Hi,=0A=0AIn certain cases, as in using VS commads to communicate with diffe=
rent cores on the combo chips (say, BT, FM, GPS) - we would have to use the=
hci0 interface without it being UP.=0A=0AAs in the hci0 interface still ne=
eds to be invisible (via dbus/bluetoothd) to the system but to be available=
to be use.=0A=0AIs there a way we can do this while registering with the h=
ci ?=0Asay a flag in the struct hci_dev to be by default during registratio=
n HCI_DEV_DOWN to be default state ?=0A=0A
^ permalink raw reply
* Re: using hci0 interface without DEVUP
From: Marcel Holtmann @ 2010-07-06 12:55 UTC (permalink / raw)
To: pavan_savoy; +Cc: linux-bluetooth, kobile, pavan savoy
In-Reply-To: <250863.34433.qm@web94911.mail.in2.yahoo.com>
Hi Pavan,
> In certain cases, as in using VS commads to communicate with different cores on the combo chips (say, BT, FM, GPS) - we would have to use the hci0 interface without it being UP.
>
> As in the hci0 interface still needs to be invisible (via dbus/bluetoothd) to the system but to be available to be use.
>
> Is there a way we can do this while registering with the hci ?
> say a flag in the struct hci_dev to be by default during registration HCI_DEV_DOWN to be default state ?
it is a pretty simple fact that the HCI device has to up. Otherwise it
is not going to work. Same with an Ethernet interface. That is the
proper state for such interfaces.
What you want is to set RAW mode on the HCI device before bringing it
up. Then bluetoothd will actually ignore it.
However I am not sure what you are really trying to achieve here since
every device will be brought up automatically by bluetoothd. And so you
are already to late to the game at that point.
Regards
Marcel
^ permalink raw reply
* [PATCH] Add "hciX" to hciconfig man page
From: Gustavo F. Padovan @ 2010-07-06 13:00 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <19504.50180.287560.834476@gargle.gargle.HOWL>
---
tools/hciconfig.8 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tools/hciconfig.8 b/tools/hciconfig.8
index 13f52c6..35956c4 100644
--- a/tools/hciconfig.8
+++ b/tools/hciconfig.8
@@ -10,6 +10,7 @@ hciconfig \- configure Bluetooth devices
.br
.B hciconfig
.RB [\| \-a \|]
+.B hciX
.RI [\| command
.RI [\| "command parameters" \|]\|]
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Add "hciX" to hciconfig man page
From: Johan Hedberg @ 2010-07-06 13:46 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <1278421242-21854-1-git-send-email-gustavo@padovan.org>
Hi Gustavo,
On Tue, Jul 06, 2010, Gustavo F. Padovan wrote:
> ---
> tools/hciconfig.8 | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/tools/hciconfig.8 b/tools/hciconfig.8
> index 13f52c6..35956c4 100644
> --- a/tools/hciconfig.8
> +++ b/tools/hciconfig.8
> @@ -10,6 +10,7 @@ hciconfig \- configure Bluetooth devices
> .br
> .B hciconfig
> .RB [\| \-a \|]
> +.B hciX
> .RI [\| command
> .RI [\| "command parameters" \|]\|]
Thanks. The patch is now upstream.
Johan
^ permalink raw reply
* Re: using hci0 interface without DEVUP
From: Pavan Savoy @ 2010-07-06 13:51 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth, Leibovitch, Kobi, pavan savoy
In-Reply-To: <1278420904.2789.41.camel@localhost.localdomain>
----- Original Message -----
From: "Marcel Holtmann" <marcel@holtmann.org>
To: "Savoy, Pavan" <pavan_savoy@ti.com>
Cc: <linux-bluetooth@vger.kernel.org>; "Leibovitch, Kobi" <kobile@ti.com>; "pavan savoy"
<pavan_savoy@yahoo.co.in>
Sent: Tuesday, July 06, 2010 6:25 PM
Subject: Re: using hci0 interface without DEVUP
> Hi Pavan,
>
>> In certain cases, as in using VS commads to communicate with different cores on the combo chips
>> (say, BT, FM, GPS) - we would have to use the hci0 interface without it being UP.
>>
>> As in the hci0 interface still needs to be invisible (via dbus/bluetoothd) to the system but to be
>> available to be use.
>>
>> Is there a way we can do this while registering with the hci ?
>> say a flag in the struct hci_dev to be by default during registration HCI_DEV_DOWN to be default
>> state ?
>
> it is a pretty simple fact that the HCI device has to up. Otherwise it
> is not going to work. Same with an Ethernet interface. That is the
> proper state for such interfaces.
device should be UP and RUNNING, I agree, But somehow to hide this from the bluetoothd !! is my
concern,
hide this from bluetoothd, and hence hide this from dbus, so as to hide it from rest of the system
...
> What you want is to set RAW mode on the HCI device before bringing it
> up. Then bluetoothd will actually ignore it.
You mean to say HCI_RAW to the hdev->flags ?
But that has the same effect even now because our HCI commands are HCI_VS, ogf of 0x3f.
> However I am not sure what you are really trying to achieve here since
> every device will be brought up automatically by bluetoothd. And so you
> are already to late to the game at that point.
exactly what I am trying to avoid, as in during hci_register_dev, I provide a flag from my hdev,
telling whether
hci_notify and hence sock internal notification should happen at all ...
Thereby, when I do
set_bit(hdev, NO_NOTIFY);
hci_register_dev(hdev); --> bluetoothd doesn't get notification of a HCI-REG itself.
But the problem would then be, how would I do a DEVUP internally ...
Any hints ??
> Regards
>
> Marcel
>
>
>
^ permalink raw reply
* Re: using hci0 interface without DEVUP
From: Marcel Holtmann @ 2010-07-06 14:08 UTC (permalink / raw)
To: Pavan Savoy; +Cc: linux-bluetooth, Leibovitch, Kobi, pavan savoy
In-Reply-To: <010f01cb1d12$67fecdc0$LocalHost@minx0099669>
Hi Pavan,
> >> In certain cases, as in using VS commads to communicate with different cores on the combo chips
> >> (say, BT, FM, GPS) - we would have to use the hci0 interface without it being UP.
> >>
> >> As in the hci0 interface still needs to be invisible (via dbus/bluetoothd) to the system but to be
> >> available to be use.
> >>
> >> Is there a way we can do this while registering with the hci ?
> >> say a flag in the struct hci_dev to be by default during registration HCI_DEV_DOWN to be default
> >> state ?
> >
> > it is a pretty simple fact that the HCI device has to up. Otherwise it
> > is not going to work. Same with an Ethernet interface. That is the
> > proper state for such interfaces.
>
> device should be UP and RUNNING, I agree, But somehow to hide this from the bluetoothd !! is my
> concern,
> hide this from bluetoothd, and hence hide this from dbus, so as to hide it from rest of the system
> ...
>
> > What you want is to set RAW mode on the HCI device before bringing it
> > up. Then bluetoothd will actually ignore it.
>
> You mean to say HCI_RAW to the hdev->flags ?
> But that has the same effect even now because our HCI commands are HCI_VS, ogf of 0x3f.
>
> > However I am not sure what you are really trying to achieve here since
> > every device will be brought up automatically by bluetoothd. And so you
> > are already to late to the game at that point.
>
> exactly what I am trying to avoid, as in during hci_register_dev, I provide a flag from my hdev,
> telling whether
> hci_notify and hence sock internal notification should happen at all ...
> Thereby, when I do
>
> set_bit(hdev, NO_NOTIFY);
> hci_register_dev(hdev); --> bluetoothd doesn't get notification of a HCI-REG itself.
>
> But the problem would then be, how would I do a DEVUP internally ...
> Any hints ??
listen to what I said. If you wanna set this as RAW device from the
kernel, then that is fine as well. You can do that. Only exception is
that you can never take this back from userspace:
set_bit(HCI_QUIRK_RAW_DEVICE, &hdev->quirks);
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: check l2cap pending status before sending l2cap connect request
From: Marcel Holtmann @ 2010-07-06 15:14 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1277278237-29377-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> Due to race condition in L2CAP state machine L2CAP Connection Request
> may be sent twice for SDP with the same source channel id. Problems
> reported connecting to Apple products, some carkit, Blackberry phones.
>
> ...
> 2010-06-07 21:18:03.651031 < ACL data: handle 1 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 1 scid 0x0040
> 2010-06-07 21:18:03.653473 > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 1 packets 1
> 2010-06-07 21:18:03.653808 > HCI Event: Auth Complete (0x06) plen 3
> status 0x00 handle 1
> 2010-06-07 21:18:03.653869 < ACL data: handle 1 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 1 scid 0x0040
> ...
>
> Patch uses L2CAP_CONF_CONNECT_PEND flag to mark that L2CAP Connection
> Request has been sent.
patch in general looks fine, but I do have some comments.
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index bb00015..7f82f7b 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -409,13 +409,16 @@ static void l2cap_do_start(struct sock *sk)
> if (!(conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE))
> return;
>
> - if (l2cap_check_security(sk)) {
> + if (l2cap_check_security(sk) &&
> + !(l2cap_pi(sk)->conf_state &
> + L2CAP_CONF_CONNECT_PEND)) {
I think having some l2cap_check_pending() would be a good idea. This
high indentation is not easy to read.
> struct l2cap_conn_req req;
> req.scid = cpu_to_le16(l2cap_pi(sk)->scid);
> req.psm = l2cap_pi(sk)->psm;
>
> l2cap_pi(sk)->ident = l2cap_get_ident(conn);
>
> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
> l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
> L2CAP_CONN_REQ, sizeof(req), &req);
If we look at the other cases we have done this, then either have an
empty line between these two commands. Or remove the other empty line.
> }
> @@ -464,13 +467,16 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
> }
>
> if (sk->sk_state == BT_CONNECT) {
> - if (l2cap_check_security(sk)) {
> + if (l2cap_check_security(sk) &&
> + !(l2cap_pi(sk)->conf_state &
> + L2CAP_CONF_CONNECT_PEND)) {
See above.
> struct l2cap_conn_req req;
> req.scid = cpu_to_le16(l2cap_pi(sk)->scid);
> req.psm = l2cap_pi(sk)->psm;
>
> l2cap_pi(sk)->ident = l2cap_get_ident(conn);
>
> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
> l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
> L2CAP_CONN_REQ, sizeof(req), &req);
See above.
> }
> @@ -4407,6 +4413,7 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
>
> l2cap_pi(sk)->ident = l2cap_get_ident(conn);
>
> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
> l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
> L2CAP_CONN_REQ, sizeof(req), &req);
> } else {
See above.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv1 1/2] Bluetooth: Check sk is not owned before freeing l2cap_conn
From: Marcel Holtmann @ 2010-07-06 15:21 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1274883694-18120-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> Check that socket sk is not locked in user process before removing
> l2cap connection handler.
>
> krfcommd kernel thread may be preempted with l2cap tasklet which remove
> l2cap_conn structure. If krfcommd is in process of sending of RFCOMM reply
> (like "RFCOMM UA" reply to "RFCOMM DISC") then kernel crash happens.
>
> ...
> [ 694.175933] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [ 694.184936] pgd = c0004000
> [ 694.187683] [00000000] *pgd=00000000
> [ 694.191711] Internal error: Oops: 5 [#1] PREEMPT
> [ 694.196350] last sysfs file: /sys/devices/platform/hci_h4p/firmware/hci_h4p/loading
> [ 694.260375] CPU: 0 Not tainted (2.6.32.10 #1)
> [ 694.265106] PC is at l2cap_sock_sendmsg+0x43c/0x73c [l2cap]
> [ 694.270721] LR is at 0xd7017303
> ...
> [ 694.525085] Backtrace:
> [ 694.527587] [<bf266be0>] (l2cap_sock_sendmsg+0x0/0x73c [l2cap]) from [<c02f2cc8>] (sock_sendmsg+0xb8/0xd8)
> [ 694.537292] [<c02f2c10>] (sock_sendmsg+0x0/0xd8) from [<c02f3044>] (kernel_sendmsg+0x48/0x80)
> ...
>
> Modified version after comments of Gustavo F. Padovan <gustavo@padovan.org>
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
the patch seems to be fine, but I have some extra questions/concerns.
Who is now taking care of deleting the channel in this case? I think you
need to show that the code flow is still valid.
Also the question is how RFCOMM can send this UA or DISC with not
locking the socket. The comment on l2cap_chan_del clearly states that
the socket must be locked and inside L2CAP we do that. Is RFCOMM maybe
at fault here?
Regards
Marcel
^ permalink raw reply
* Re: [RFC] Bluetooth: Add firmware load infrastructure for BT devices
From: Marcel Holtmann @ 2010-07-06 17:24 UTC (permalink / raw)
To: Bala Shanmugam; +Cc: linux-bluetooth
In-Reply-To: <1278333422-10368-1-git-send-email-sbalashanmugam@atheros.com>
Hi Bala,
> Added support to load firmware to target RAM from Bluetooth USB transport
> driver. Each BT device vendor need to specify the product ID, firmware file,
> load and unload function. When the device is inserted, btusb will call
> appropriate firmware load function to load firmware to target RAM.
>
> This framework is needed for devices that are detected as BT devices when
> powered on and still require firmware to be downaloded.
we have discussed this a long time ago and the better approach would be
to create a setup stage for all HCI drivers. For example for special HCI
commands to set BD_ADDR and other details. Maybe also a firmware loading
stage should be used. Making this USB specific sounds pretty much wrong
to me at this point. At least SDIO might have similar issues.
The current approach looks more hackish than actually nicely integrated.
Regards
Marcel
^ permalink raw reply
* RE: [RFC] Bluetooth: Add firmware load infrastructure for BT devices
From: Perelet, Oleg @ 2010-07-06 20:29 UTC (permalink / raw)
To: Marcel Holtmann, Bala Shanmugam; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1278437061.2789.62.camel@localhost.localdomain>
>> Added support to load firmware to target RAM from Bluetooth USB transpor=
t
>> driver.=20
>we have discussed this a long time ago and the better approach would be
>to create a setup stage for all HCI drivers. For example for special HCI
>commands to set BD_ADDR and other details. Maybe also a firmware loading
>stage should be used. Making this USB specific sounds pretty much wrong
>to me at this point. At least SDIO might have similar issues.
>>The current approach looks more hackish than actually nicely integrated.
Thanks for bringing up old topic. We discussed this few years ago and thing=
s been somehow stalled. Besides, USB, SDIO there's UART which is used in a =
lot of embedded platforms and everybody hacks custom code around.
Overall Marcel suggests to have intermediate stage between DOWN and UP stat=
es for hci device aka - SETUP (call it any name).
Here are low level BT setup states that I "think" are common for majority o=
f embedded implementations:
1. low level GPIO, CLC etc setup - can not talk to chip before that.
2. Initial firmware/patch download - at this state one can talk HCI to chip=
, but chip is barely functional, firmware, patches etc are downloaded at th=
is stage.
3. "Run time config download" (often combined with #2, but I suggest to sep=
arate) this is when BDADDR is programmed and chip run time parameters for g=
iven platform are set up. For majority of chips this stage also defines Sle=
ep algorithm to be used. There are few ways of doing BT sleep - HCI, UART s=
ignaling or usage of extra WAKE GPIO's to determine sleep condition. Most o=
f them require initial HCI setup.
4. Enable Sleep and low power mode. Currently everybody hardcodes this step=
, some platforms have programmatic ifaces (aka sysfs)
5. WiFI coex setup if needed.
Feel free to add more here ....
At this stage hci can be brought to UP stage and be functional.
All of that is tight with RFKILL of course and also suspend/resume entries =
in transport driver. I'm also not doing in to details of sleep mode impleme=
ntation in this thread but welcome to discuss it in separate thread.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv2] Bluetooth: Check l2cap pending status before sending l2cap connect request
From: Emeltchenko Andrei @ 2010-07-07 9:05 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Due to race condition in L2CAP state machine L2CAP Connection Request
may be sent twice for SDP with the same source channel id. Problems
reported connecting to Apple products, some carkit, Blackberry phones.
...
2010-06-07 21:18:03.651031 < ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
2010-06-07 21:18:03.653473 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 1 packets 1
2010-06-07 21:18:03.653808 > HCI Event: Auth Complete (0x06) plen 3
status 0x00 handle 1
2010-06-07 21:18:03.653869 < ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
...
Patch uses L2CAP_CONF_CONNECT_PEND flag to mark that L2CAP Connection
Request has been sent already.
Modified version of Ville Tervo patch.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index bb00015..899cca5 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -401,6 +401,11 @@ static inline void l2cap_send_rr_or_rnr(struct l2cap_pinfo *pi, u16 control)
l2cap_send_sframe(pi, control);
}
+static inline int l2cap_check_pending(struct sock *sk)
+{
+ return l2cap_pi(sk)->conf_state & L2CAP_CONF_CONNECT_PEND;
+}
+
static void l2cap_do_start(struct sock *sk)
{
struct l2cap_conn *conn = l2cap_pi(sk)->conn;
@@ -409,12 +414,13 @@ static void l2cap_do_start(struct sock *sk)
if (!(conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE))
return;
- if (l2cap_check_security(sk)) {
+ if (l2cap_check_security(sk) && !l2cap_check_pending(sk)) {
struct l2cap_conn_req req;
req.scid = cpu_to_le16(l2cap_pi(sk)->scid);
req.psm = l2cap_pi(sk)->psm;
l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+ l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
@@ -464,12 +470,14 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
}
if (sk->sk_state == BT_CONNECT) {
- if (l2cap_check_security(sk)) {
+ if (l2cap_check_security(sk) &&
+ !l2cap_check_pending(sk)) {
struct l2cap_conn_req req;
req.scid = cpu_to_le16(l2cap_pi(sk)->scid);
req.psm = l2cap_pi(sk)->psm;
l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+ l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
@@ -2914,7 +2922,6 @@ static inline int l2cap_connect_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hd
l2cap_pi(sk)->ident = 0;
l2cap_pi(sk)->dcid = dcid;
l2cap_pi(sk)->conf_state |= L2CAP_CONF_REQ_SENT;
-
l2cap_pi(sk)->conf_state &= ~L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
@@ -4406,6 +4413,7 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
req.psm = l2cap_pi(sk)->psm;
l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+ l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Added empty VCARD N: parameter handling
From: ext-jablonski.radoslaw @ 2010-07-07 12:45 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
Some of the devices are expecting that N: parameter in VCARD is always filled (by example Nokia BH-903)
When this field is empty (N:;;;;) then list of dialed/incoming calls on carkit is useless - carkit then shows only blank lines and it's impossible to determine who made call ( phone number are invisible too in this case)
If none of the contact fields is available, then setting telephone number as the first attribute for "N:" parameter.
Carkit will see that number as contact name - it is only used in case when none of more detailed contact information is available on the phone.
BR,
Radek
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Added-empty-N-parameter-handling-in-VCARD.patch --]
[-- Type: text/x-patch; name="0001-Added-empty-N-parameter-handling-in-VCARD.patch", Size: 1946 bytes --]
From 6d88e3d7c1a5014e60ca8f53f7163e3a51148530 Mon Sep 17 00:00:00 2001
From: Radoslaw Jablonski <ext-jablonski.radoslaw@nokia.com>
Date: Wed, 7 Jul 2010 15:07:58 +0300
Subject: [PATCH] Added empty N: parameter handling in VCARD
Some of the devices are expecting that N: parameter in VCARD is always filled (by example Nokia BH-903)
When this field is empty (N:;;;;) then list of dialed/incoming calls on carkit is useless.
If none of fields is available then setting telephone number as the first attribute for "N:" parameter.
Carkit will see that number as contact name - it is only used in case when none of more detailed contact information is available on phone.
---
plugins/vcard.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/plugins/vcard.c b/plugins/vcard.c
index 5948a4a..b2ab30a 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -136,9 +136,20 @@ static void vcard_printf_begin(GString *vcards, uint8_t format)
static void vcard_printf_name(GString *vcards,
struct phonebook_contact *contact)
{
- vcard_printf(vcards, "N:%s;%s;%s;%s;%s", contact->family,
- contact->given, contact->additional,
- contact->prefix, contact->suffix);
+ /* at least one of fields is present */
+ if ((contact->family && strlen(contact->family)) ||
+ (contact->given && strlen (contact->given)) ||
+ (contact->additional && strlen(contact->additional)) ||
+ (contact->prefix && strlen (contact->prefix)) ||
+ (contact->suffix && strlen (contact->suffix)))
+ vcard_printf(vcards, "N:%s;%s;%s;%s;%s", contact->family,
+ contact->given, contact->additional,
+ contact->prefix, contact->suffix);
+ else {
+ /* if all fields are empty we're using first phone number as name */
+ struct phonebook_number *number = contact->numbers->data;
+ vcard_printf(vcards, "N:%s;;;;", number->tel);
+ }
}
static void vcard_printf_fullname(GString *vcards, const char *text)
--
1.6.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox