* [PATCH 03/10] Bluetooth: Fix configuration of the MPS value
From: Gustavo F. Padovan @ 2010-03-30 18:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo, jprvita
In-Reply-To: <1269975160-9994-2-git-send-email-padovan@profusion.mobi>
We were accepting values bigger than we can accept. This was leading
ERTM to drop packets because of wrong FCS checks.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi>
---
include/net/bluetooth/l2cap.h | 3 ++-
net/bluetooth/l2cap.c | 36 ++++++++++++++++++++----------------
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 48f10f4..0f4e423 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -343,7 +343,8 @@ struct l2cap_pinfo {
__u8 remote_max_tx;
__u16 retrans_timeout;
__u16 monitor_timeout;
- __u16 max_pdu_size;
+ __u16 remote_mps;
+ __u16 mps;
__le16 sport;
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 40aff8d..4c98e3c 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1605,21 +1605,21 @@ static inline int l2cap_sar_segment_sdu(struct sock *sk, struct msghdr *msg, siz
__skb_queue_head_init(&sar_queue);
control = L2CAP_SDU_START;
- skb = l2cap_create_iframe_pdu(sk, msg, pi->max_pdu_size, control, len);
+ skb = l2cap_create_iframe_pdu(sk, msg, pi->remote_mps, control, len);
if (IS_ERR(skb))
return PTR_ERR(skb);
__skb_queue_tail(&sar_queue, skb);
- len -= pi->max_pdu_size;
- size +=pi->max_pdu_size;
+ len -= pi->remote_mps;
+ size +=pi->remote_mps;
control = 0;
while (len > 0) {
size_t buflen;
- if (len > pi->max_pdu_size) {
+ if (len > pi->remote_mps) {
control |= L2CAP_SDU_CONTINUE;
- buflen = pi->max_pdu_size;
+ buflen = pi->remote_mps;
} else {
control |= L2CAP_SDU_END;
buflen = len;
@@ -1697,7 +1697,7 @@ static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct ms
case L2CAP_MODE_ERTM:
case L2CAP_MODE_STREAMING:
/* Entire SDU fits into one PDU */
- if (len <= pi->max_pdu_size) {
+ if (len <= pi->remote_mps) {
control = L2CAP_SDU_UNSEGMENTED;
skb = l2cap_create_iframe_pdu(sk, msg, len, control, 0);
if (IS_ERR(skb)) {
@@ -2326,7 +2326,7 @@ done:
rfc.monitor_timeout = 0;
rfc.max_pdu_size = cpu_to_le16(L2CAP_DEFAULT_MAX_PDU_SIZE);
if (L2CAP_DEFAULT_MAX_PDU_SIZE > pi->conn->mtu - 10)
- rfc.max_pdu_size = pi->conn->mtu - 10;
+ rfc.max_pdu_size = cpu_to_le16(pi->conn->mtu - 10);
l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
sizeof(rfc), (unsigned long) &rfc);
@@ -2349,7 +2349,7 @@ done:
rfc.monitor_timeout = 0;
rfc.max_pdu_size = cpu_to_le16(L2CAP_DEFAULT_MAX_PDU_SIZE);
if (L2CAP_DEFAULT_MAX_PDU_SIZE > pi->conn->mtu - 10)
- rfc.max_pdu_size = pi->conn->mtu - 10;
+ rfc.max_pdu_size = cpu_to_le16(pi->conn->mtu - 10);
l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
sizeof(rfc), (unsigned long) &rfc);
@@ -2478,7 +2478,10 @@ done:
case L2CAP_MODE_ERTM:
pi->remote_tx_win = rfc.txwin_size;
pi->remote_max_tx = rfc.max_transmit;
- pi->max_pdu_size = rfc.max_pdu_size;
+ if (rfc.max_pdu_size > pi->conn->mtu - 10)
+ rfc.max_pdu_size = le16_to_cpu(pi->conn->mtu - 10);
+
+ pi->remote_mps = le16_to_cpu(rfc.max_pdu_size);
rfc.retrans_timeout = L2CAP_DEFAULT_RETRANS_TO;
rfc.monitor_timeout = L2CAP_DEFAULT_MONITOR_TO;
@@ -2491,7 +2494,10 @@ done:
break;
case L2CAP_MODE_STREAMING:
- pi->max_pdu_size = rfc.max_pdu_size;
+ if (rfc.max_pdu_size > pi->conn->mtu - 10)
+ rfc.max_pdu_size = le16_to_cpu(pi->conn->mtu - 10);
+
+ pi->remote_mps = le16_to_cpu(rfc.max_pdu_size);
pi->conf_state |= L2CAP_CONF_MODE_DONE;
@@ -2570,11 +2576,10 @@ static int l2cap_parse_conf_rsp(struct sock *sk, void *rsp, int len, void *data,
pi->remote_tx_win = rfc.txwin_size;
pi->retrans_timeout = rfc.retrans_timeout;
pi->monitor_timeout = rfc.monitor_timeout;
- pi->max_pdu_size = le16_to_cpu(rfc.max_pdu_size);
+ pi->mps = le16_to_cpu(rfc.max_pdu_size);
break;
case L2CAP_MODE_STREAMING:
- pi->max_pdu_size = le16_to_cpu(rfc.max_pdu_size);
- break;
+ pi->mps = le16_to_cpu(rfc.max_pdu_size);
}
}
@@ -3758,7 +3763,7 @@ static inline int l2cap_data_channel(struct l2cap_conn *conn, u16 cid, struct sk
* Receiver will miss it and start proper recovery
* procedures and ask retransmission.
*/
- if (len > L2CAP_DEFAULT_MAX_PDU_SIZE)
+ if (len > pi->mps)
goto drop;
if (l2cap_check_fcs(pi, skb))
@@ -3789,8 +3794,7 @@ static inline int l2cap_data_channel(struct l2cap_conn *conn, u16 cid, struct sk
if (pi->fcs == L2CAP_FCS_CRC16)
len -= 2;
- if (len > L2CAP_DEFAULT_MAX_PDU_SIZE || len < 4
- || __is_sframe(control))
+ if (len > pi->mps || len < 4 || __is_sframe(control))
goto drop;
if (l2cap_check_fcs(pi, skb))
--
1.6.4.4
^ permalink raw reply related
* [PATCH 02/10] Bluetooth: Read RFC conf option on a successful Conf RSP
From: Gustavo F. Padovan @ 2010-03-30 18:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo, jprvita
In-Reply-To: <1269975160-9994-1-git-send-email-padovan@profusion.mobi>
On Enhanced Retransmission Mode and Streaming Mode a entity can send, on
a successful Conf RSP, new values for the RFC fields. For example, the
entity can send txWindow and MPS values less than the value received on
a Conf REQ.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi>
---
net/bluetooth/l2cap.c | 39 ++++++++++++++++++++++++++++++++++++++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 2cfad45..40aff8d 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2598,6 +2598,42 @@ static int l2cap_build_conf_rsp(struct sock *sk, void *data, u16 result, u16 fla
return ptr - data;
}
+static void l2cap_conf_rfc_get(struct sock *sk, void *rsp, int len)
+{
+ struct l2cap_pinfo *pi = l2cap_pi(sk);
+ int type, olen;
+ unsigned long val;
+ struct l2cap_conf_rfc rfc;
+
+ BT_DBG("sk %p, rsp %p, len %d", sk, rsp, len);
+
+ if ((pi->mode != L2CAP_MODE_ERTM) && (pi->mode != L2CAP_MODE_STREAMING))
+ return;
+
+ while (len >= L2CAP_CONF_OPT_SIZE) {
+ len -= l2cap_get_conf_opt(&rsp, &type, &olen, &val);
+
+ switch (type) {
+ case L2CAP_CONF_RFC:
+ if (olen == sizeof(rfc))
+ memcpy(&rfc, (void *)val, olen);
+ goto done;
+ }
+ }
+
+done:
+ switch (rfc.mode) {
+ case L2CAP_MODE_ERTM:
+ pi->remote_tx_win = rfc.txwin_size;
+ pi->retrans_timeout = rfc.retrans_timeout;
+ pi->monitor_timeout = rfc.monitor_timeout;
+ pi->mps = le16_to_cpu(rfc.max_pdu_size);
+ break;
+ case L2CAP_MODE_STREAMING:
+ pi->mps = le16_to_cpu(rfc.max_pdu_size);
+ }
+}
+
static inline int l2cap_command_rej(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd, u8 *data)
{
struct l2cap_cmd_rej *rej = (struct l2cap_cmd_rej *) data;
@@ -2877,6 +2913,7 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hdr
struct l2cap_conf_rsp *rsp = (struct l2cap_conf_rsp *)data;
u16 scid, flags, result;
struct sock *sk;
+ int len = cmd->len - sizeof(*rsp);
scid = __le16_to_cpu(rsp->scid);
flags = __le16_to_cpu(rsp->flags);
@@ -2891,11 +2928,11 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hdr
switch (result) {
case L2CAP_CONF_SUCCESS:
+ l2cap_conf_rfc_get(sk, rsp->data, len);
break;
case L2CAP_CONF_UNACCEPT:
if (l2cap_pi(sk)->num_conf_rsp <= L2CAP_CONF_MAX_CONF_RSP) {
- int len = cmd->len - sizeof(*rsp);
char req[64];
if (len > sizeof(req) - sizeof(struct l2cap_conf_req)) {
--
1.6.4.4
^ permalink raw reply related
* [PATCH 01/10] Bluetooth: Ignore Tx Window value with Streaming mode
From: Gustavo F. Padovan @ 2010-03-30 18:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo, jprvita
In-Reply-To: <1269373726-13209-20-git-send-email-padovan@profusion.mobi>
Tx Window value shall not be used with Streaming Mode and the receiver
of the config Request shall ignore its value.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi>
---
net/bluetooth/l2cap.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 8c8b5d9..2cfad45 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2491,7 +2491,6 @@ done:
break;
case L2CAP_MODE_STREAMING:
- pi->remote_tx_win = rfc.txwin_size;
pi->max_pdu_size = rfc.max_pdu_size;
pi->conf_state |= L2CAP_CONF_MODE_DONE;
--
1.6.4.4
^ permalink raw reply related
* [PATCH] Add new S-frame types to l2cap parser
From: Gustavo F. Padovan @ 2010-03-30 18:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo
In-Reply-To: <1269972441-24242-1-git-send-email-jprvita@gmail.com>
---
parser/l2cap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/parser/l2cap.c b/parser/l2cap.c
index 799d4b7..ad3b7ff 100644
--- a/parser/l2cap.c
+++ b/parser/l2cap.c
@@ -352,8 +352,9 @@ static char *supervisory2str(uint8_t supervisory)
case 0x01:
return "Reject (REJ)";
case 0x02:
+ return "Receiver Not Ready (RNR)";
case 0x03:
- return "Reserved Supervisory";
+ return "Select Reject (SREJ)";
default:
return "Bad Supervisory";
}
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH] Fix bootstrap-configure command line parsing
From: João Paulo Rechi Vita @ 2010-03-30 18:08 UTC (permalink / raw)
To: linux-bluetooth; +Cc: João Paulo Rechi Vita
In-Reply-To: <1269972441-24242-1-git-send-email-jprvita@gmail.com>
2010/3/30 João Paulo Rechi Vita <jprvita@gmail.com>:
> ---
> bootstrap-configure | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/bootstrap-configure b/bootstrap-configure
> index 44e7ee8..5b7b88f 100755
> --- a/bootstrap-configure
> +++ b/bootstrap-configure
> @@ -8,4 +8,4 @@ fi
> ./configure --enable-maintainer-mode \
> --enable-debug \
> --prefix=/usr \
> - --mandir=/usr/share/man
> + --mandir=/usr/share/man $*
> --
> 1.6.3.3
>
>
This patch is to bluez-hcidump.
--
João Paulo Rechi Vita
http://jprvita.wordpress.com/
^ permalink raw reply
* [PATCH] Fix bootstrap-configure command line parsing
From: João Paulo Rechi Vita @ 2010-03-30 18:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: João Paulo Rechi Vita
---
bootstrap-configure | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/bootstrap-configure b/bootstrap-configure
index 44e7ee8..5b7b88f 100755
--- a/bootstrap-configure
+++ b/bootstrap-configure
@@ -8,4 +8,4 @@ fi
./configure --enable-maintainer-mode \
--enable-debug \
--prefix=/usr \
- --mandir=/usr/share/man
+ --mandir=/usr/share/man $*
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
From: Marcel Holtmann @ 2010-03-30 1:21 UTC (permalink / raw)
To: Johan Hedberg; +Cc: Francisco Alecrim, Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <20100329225643.GA5460@jh-x301>
Hi Johan,
> > >> IMO, it should be the same list as we export in extended inquiry
> > >> response, so perhaps we could use the data from
> > >> create_ext_inquiry_response which already filter those away. Perhaps
> > >> some refactoring could also be done since this code seems to be called
> > >> multiple times in case of new services because it also changes class
> > >> which then triggers create_ext_inquiry_response again.
> >
> > I'm not so sure about it but create_ext_inquiry_response list all
> > services to any adapters. Shouldn't it list just services per
> > adapter(access_db)?
>
> It should be per-adapter (or records registered to BDADDR_ANY) since EIR
> is also per-adapter, so looks like a possible bug in the current
> implementation.
>
> Btw, another restriction to note with the current EIR UUID list
> implementation is that it only supports 16-bit UUIDs. The EIR format
> itself would support also 32 and 128 bit formats but probably for
> simplicity these have been left out. The Adapter UUIDs list should
> however contain all UUIDs (with the exceptions that we already
> discussed).
it should also contain the UUID-128 ones (the UUID-32 are pointless and
with LE they are gone for good). The reason why these were left out is
because it is pretty hard to fit them into the limited space of EIR. If
you are up for fixing this, then I am more than happy to have this. I
think we need to introduce some priority mapping here to decide which
UUID list to cut in favor of others. Same as how we can shortcut the
device name etc.
So in general the DID information and at least a short device name
should be present. For the short name, we might need another config file
option or some plugin way of retrieving the short name. Also I want to
have the TX power information available if the chip supports it.
The rest of the space can be used for UUIDs in whatever way fits. The
more UUIDs are in the list the better actually.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
From: Johan Hedberg @ 2010-03-29 22:56 UTC (permalink / raw)
To: Francisco Alecrim
Cc: Luiz Augusto von Dentz, Marcel Holtmann, linux-bluetooth
In-Reply-To: <4BB125E8.1090200@openbossa.org>
Hi Alecrim,
On Mon, Mar 29, 2010, Francisco Alecrim wrote:
> >> IMO, it should be the same list as we export in extended inquiry
> >> response, so perhaps we could use the data from
> >> create_ext_inquiry_response which already filter those away. Perhaps
> >> some refactoring could also be done since this code seems to be called
> >> multiple times in case of new services because it also changes class
> >> which then triggers create_ext_inquiry_response again.
>
> I'm not so sure about it but create_ext_inquiry_response list all
> services to any adapters. Shouldn't it list just services per
> adapter(access_db)?
It should be per-adapter (or records registered to BDADDR_ANY) since EIR
is also per-adapter, so looks like a possible bug in the current
implementation.
Btw, another restriction to note with the current EIR UUID list
implementation is that it only supports 16-bit UUIDs. The EIR format
itself would support also 32 and 128 bit formats but probably for
simplicity these have been left out. The Adapter UUIDs list should
however contain all UUIDs (with the exceptions that we already
discussed).
Johan
^ permalink raw reply
* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
From: Francisco Alecrim @ 2010-03-29 22:12 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Marcel Holtmann, Francisco Alecrim,
linux-bluetooth
In-Reply-To: <20100329215239.GA3748@jh-x301>
Hi Johan and Luiz,
Johan Hedberg wrote:
> Hi Luiz,
>
> On Mon, Mar 29, 2010, Luiz Augusto von Dentz wrote:
>> On Mon, Mar 29, 2010 at 11:29 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
>>> Hi Johan,
>>>
>>>>> Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus message
>>>>> to inform that adapter properties changed.
>>>>> ---
>>>>> src/adapter.c | 75 ++++++++++++++++++++++++++++++++++++++++++++------
>>>>> src/adapter.h | 1 +
>>>>> src/sdpd-database.c | 3 ++
>>>>> 3 files changed, 70 insertions(+), 9 deletions(-)
>>>> Thanks for the patches. In principle they look good, but I haven't
>>>> applied them yet due to one thing that looks a bit strange: both the SDP
>>>> server record UUID (0x1000) as well as the public browse group UUID
>>>> (0x1001) always show up in the UUIDs list. I wonder if there'd be any
>>>> clean way to avoid getting them into the list. Marcel, do you have any
>>>> idea about this or is it even a problem that these UUIDs are always in
>>>> the list?
>>> these UUIDs are always in the server, but not in the public browse group
>>> and we skip them on purpose. The only reason why they are always present
>>> is that the specification requires it.
>> IMO, it should be the same list as we export in extended inquiry
>> response, so perhaps we could use the data from
>> create_ext_inquiry_response which already filter those away. Perhaps
>> some refactoring could also be done since this code seems to be called
>> multiple times in case of new services because it also changes class
>> which then triggers create_ext_inquiry_response again.
I'm not so sure about it but create_ext_inquiry_response list all
services to any adapters. Shouldn't it list just services per
adapter(access_db)?
>
> That makes quite a lot sense, and is actually what I was chatting with
> Marcel about earlier today on irc. The EIR UUIDs list does have a few
> restrictions though that the Adapter UUIDs property doesn't have, such
> as a maximum limit on the amount of UUIDs (since EIR data is quite
> limited in size), so the lists will not always be exactly the same.
>
> You can see the creation of the EIR list in the for-loop of the
> create_ext_inquiry_response function in sdpd-service.c. The most
> important part for the Adapter UUIDs property would be the following
> code snippet which also answers the original question I had about how to
> best get rid of the unnecessary UUIDs:
>
> if (rec->svclass.value.uuid16 < 0x1100)
> continue;
> if (rec->svclass.value.uuid16 == PNP_INFO_SVCLASS_ID)
> continue;
>
> In addition those there's also the duplicate UUID check which I think
> the original patch was missing. So, if the same code could somehow be
> reused for EIR and the Adapter UUIDs property it'd be great. However, if
> it's too messy, the above two filters and the duplicate UUID check
> should at least be applied to the Adapter UUIDs property.
Great! That's the piece of code I was trying to find. I'll try
re-organize this code.
Thanks,
Alecrim.
^ permalink raw reply
* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
From: Johan Hedberg @ 2010-03-29 21:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Francisco Alecrim, linux-bluetooth
In-Reply-To: <2d5a2c101003291148u1836742w1222097fb865ef61@mail.gmail.com>
Hi Luiz,
On Mon, Mar 29, 2010, Luiz Augusto von Dentz wrote:
> On Mon, Mar 29, 2010 at 11:29 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> > Hi Johan,
> >
> >> > Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus message
> >> > to inform that adapter properties changed.
> >> > ---
> >> > src/adapter.c | 75 ++++++++++++++++++++++++++++++++++++++++++++------
> >> > src/adapter.h | 1 +
> >> > src/sdpd-database.c | 3 ++
> >> > 3 files changed, 70 insertions(+), 9 deletions(-)
> >>
> >> Thanks for the patches. In principle they look good, but I haven't
> >> applied them yet due to one thing that looks a bit strange: both the SDP
> >> server record UUID (0x1000) as well as the public browse group UUID
> >> (0x1001) always show up in the UUIDs list. I wonder if there'd be any
> >> clean way to avoid getting them into the list. Marcel, do you have any
> >> idea about this or is it even a problem that these UUIDs are always in
> >> the list?
> >
> > these UUIDs are always in the server, but not in the public browse group
> > and we skip them on purpose. The only reason why they are always present
> > is that the specification requires it.
>
> IMO, it should be the same list as we export in extended inquiry
> response, so perhaps we could use the data from
> create_ext_inquiry_response which already filter those away. Perhaps
> some refactoring could also be done since this code seems to be called
> multiple times in case of new services because it also changes class
> which then triggers create_ext_inquiry_response again.
That makes quite a lot sense, and is actually what I was chatting with
Marcel about earlier today on irc. The EIR UUIDs list does have a few
restrictions though that the Adapter UUIDs property doesn't have, such
as a maximum limit on the amount of UUIDs (since EIR data is quite
limited in size), so the lists will not always be exactly the same.
You can see the creation of the EIR list in the for-loop of the
create_ext_inquiry_response function in sdpd-service.c. The most
important part for the Adapter UUIDs property would be the following
code snippet which also answers the original question I had about how to
best get rid of the unnecessary UUIDs:
if (rec->svclass.value.uuid16 < 0x1100)
continue;
if (rec->svclass.value.uuid16 == PNP_INFO_SVCLASS_ID)
continue;
In addition those there's also the duplicate UUID check which I think
the original patch was missing. So, if the same code could somehow be
reused for EIR and the Adapter UUIDs property it'd be great. However, if
it's too messy, the above two filters and the duplicate UUID check
should at least be applied to the Adapter UUIDs property.
Johan
^ permalink raw reply
* [PATCH] Return error when modem_obj_path is NULL
From: Forrest Zhao @ 2010-03-29 21:02 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, forrest.zhao, Forrest Zhao
This could prevent crash in case modem_obj_path is NULL.
---
audio/telephony-ofono.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/audio/telephony-ofono.c b/audio/telephony-ofono.c
index 45c3905..30f8b27 100644
--- a/audio/telephony-ofono.c
+++ b/audio/telephony-ofono.c
@@ -281,6 +281,12 @@ void telephony_dial_number_req(void *telephony_device, const char *number)
debug("telephony-ofono: dial request to %s", number);
+ if (!modem_obj_path) {
+ telephony_dial_number_rsp(telephony_device,
+ CME_ERROR_AG_FAILURE);
+ return;
+ }
+
if (!strncmp(number, "*31#", 4)) {
number += 4;
clir = "enabled";
@@ -311,6 +317,12 @@ void telephony_transmit_dtmf_req(void *telephony_device, char tone)
debug("telephony-ofono: transmit dtmf: %c", tone);
+ if (!modem_obj_path) {
+ telephony_transmit_dtmf_rsp(telephony_device,
+ CME_ERROR_AG_FAILURE);
+ return;
+ }
+
tone_string = g_strdup_printf("%c", tone);
ret = send_method_call(OFONO_BUS_NAME, modem_obj_path,
OFONO_VCMANAGER_INTERFACE,
@@ -531,6 +543,9 @@ done:
static int get_registration_and_signal_status()
{
+ if (!modem_obj_path)
+ return -ENOENT;
+
return send_method_call(OFONO_BUS_NAME, modem_obj_path,
OFONO_NETWORKREG_INTERFACE,
"GetProperties", get_registration_reply,
--
1.6.1.3
^ permalink raw reply related
* [PATCH] Check modem_obj_path is not NULL
From: Forrest Zhao @ 2010-03-29 20:32 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, forrest.zhao, Forrest Zhao
This could prevent crash in case modem_obj_path is NULL.
---
audio/telephony-ofono.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/audio/telephony-ofono.c b/audio/telephony-ofono.c
index 45c3905..c145e87 100644
--- a/audio/telephony-ofono.c
+++ b/audio/telephony-ofono.c
@@ -281,6 +281,10 @@ void telephony_dial_number_req(void *telephony_device, const char *number)
debug("telephony-ofono: dial request to %s", number);
+ if (!modem_obj_path)
+ telephony_dial_number_rsp(telephony_device,
+ CME_ERROR_AG_FAILURE);
+
if (!strncmp(number, "*31#", 4)) {
number += 4;
clir = "enabled";
@@ -311,6 +315,10 @@ void telephony_transmit_dtmf_req(void *telephony_device, char tone)
debug("telephony-ofono: transmit dtmf: %c", tone);
+ if (!modem_obj_path)
+ telephony_transmit_dtmf_rsp(telephony_device,
+ CME_ERROR_AG_FAILURE);
+
tone_string = g_strdup_printf("%c", tone);
ret = send_method_call(OFONO_BUS_NAME, modem_obj_path,
OFONO_VCMANAGER_INTERFACE,
@@ -531,6 +539,9 @@ done:
static int get_registration_and_signal_status()
{
+ if (!modem_obj_path)
+ return -ENOENT;
+
return send_method_call(OFONO_BUS_NAME, modem_obj_path,
OFONO_NETWORKREG_INTERFACE,
"GetProperties", get_registration_reply,
--
1.6.1.3
^ permalink raw reply related
* [PATCH] Allow bccmd psset to get words along with bytes
From: Manuel Naranjo @ 2010-03-29 19:50 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 996 bytes --]
Hello guys,
This patch allows bccmd psset input to be compatible with psget output,
psget returns words not bytes, but when you want to get that back into
psset it complains. This patch fixes the problem by allowing words to be
input.
Here's the output that shows it works:
[root@laptop:bluez-4.61]$ tools/bccmd psset -r -s psi 0x0031 0x3714
0x0100 0x411e 0x7100 0x00f4 0x4410 0x0100 0x4123 0x7100 0x00f8 0x4e11
0x0100 0x4123 0x6100 0x00fc 0x5d10 0x0100 0x4123 0x5100 0x0000 0x6914
0x0100 0x4b23 0x4000 0x0004 0x7317 0x0100 0x4123 0x3000 0x000a 0x731c
0x0100 0x4123 0x2000 0x000e 0x7321 0x0100 0x4123 0x1000 0x0014
[root@laptop:bluez-4.61]$ tools/bccmd psget 0x0031
Radio power table: 0x3714 0x0100 0x411e 0x7100 0x00f4 0x4410 0x0100
0x4123 0x7100 0x00f8 0x4e11 0x0100 0x4123 0x6100 0x00fc 0x5d10 0x0100
0x4123 0x5100 0x0000 0x6914 0x0100 0x4b23 0x4000 0x0004 0x7317 0x0100
0x4123 0x3000 0x000a 0x731c 0x0100 0x4123 0x2000 0x000e 0x7321 0x0100
0x4123 0x1000 0x0014
Cheers,
Manuel
[-- Attachment #2: bccmd.patch --]
[-- Type: text/plain, Size: 914 bytes --]
--- ../bluez-4.59/tools/bccmd.c 2009-02-01 23:30:43.000000000 -0200
+++ tools/bccmd.c 2010-03-29 16:47:04.000000000 -0300
@@ -823,16 +823,32 @@ static int cmd_psset(int transport, int
break;
default:
- if (argc != length * 2) {
+ if (argc != length * 2 && argc != length) {
errno = EINVAL;
return -1;
}
- for (i = 0; i < length * 2; i++)
- if (!strncasecmp(argv[0], "0x", 2))
+ if (argc == length * 2) {
+ for (i = 0; i < length * 2; i++)
+ if (!strncasecmp(argv[0], "0x", 2)){
array[i + 6] = strtol(argv[i] + 2, NULL, 16);
+ }
else
array[i + 6] = atoi(argv[i]);
+ }
+ else {
+ for (i = 0; i < length; i++){
+ uint16_t val = 0;
+
+ if (!strncasecmp(argv[0], "0x", 2))
+ val = strtol(argv[i] + 2, NULL, 16);
+ else
+ val = atoi(argv[i]);
+
+ array[i*2 + 7] = val % 0x100;
+ array[i*2 + 6] = (val / 0x100);
+ }
+ }
break;
}
^ permalink raw reply
* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
From: Luiz Augusto von Dentz @ 2010-03-29 18:48 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Johan Hedberg, Francisco Alecrim, linux-bluetooth
In-Reply-To: <1269851341.11714.203.camel@localhost.localdomain>
Hi,
On Mon, Mar 29, 2010 at 11:29 AM, Marcel Holtmann <marcel@holtmann.org> wro=
te:
> Hi Johan,
>
>> > Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus messa=
ge
>> > to inform that adapter properties changed.
>> > ---
>> > =A0src/adapter.c =A0 =A0 =A0 | =A0 75 ++++++++++++++++++++++++++++++++=
++++++++++++------
>> > =A0src/adapter.h =A0 =A0 =A0 | =A0 =A01 +
>> > =A0src/sdpd-database.c | =A0 =A03 ++
>> > =A03 files changed, 70 insertions(+), 9 deletions(-)
>>
>> Thanks for the patches. In principle they look good, but I haven't
>> applied them yet due to one thing that looks a bit strange: both the SDP
>> server record UUID (0x1000) as well as the public browse group UUID
>> (0x1001) always show up in the UUIDs list. I wonder if there'd be any
>> clean way to avoid getting them into the list. Marcel, do you have any
>> idea about this or is it even a problem that these UUIDs are always in
>> the list?
>
> these UUIDs are always in the server, but not in the public browse group
> and we skip them on purpose. The only reason why they are always present
> is that the specification requires it.
IMO, it should be the same list as we export in extended inquiry
response, so perhaps we could use the data from
create_ext_inquiry_response which already filter those away. Perhaps
some refactoring could also be done since this code seems to be called
multiple times in case of new services because it also changes class
which then triggers create_ext_inquiry_response again.
--=20
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH] Added support for Atheros AR300x Bluetooth Chip
From: suraj @ 2010-03-29 9:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Luis.Rodriguez, Jothikumar.Mothilal
In-Reply-To: <1269408445.23163.0.camel@atheros013-desktop>
On Wed, 2010-03-24 at 10:57 +0530, suraj wrote:
> On Mon, 2010-03-15 at 10:31 +0530, suraj wrote:
> > This protocol implements support for power management feature provided by AR300x chip.
> > This lets the controller chip go to sleep mode if there is no Bluetooth activity for some time.
> > It then wakes up the chip in case of a Bluetooth activity.
> >
> >
> > Signed-off-by: Suraj <suraj@atheros.com>
> >
> > ---
> > drivers/bluetooth/Kconfig | 11 ++
> > drivers/bluetooth/Makefile | 1 +
> > drivers/bluetooth/hci_ath.c | 353 +++++++++++++++++++++++++++++++++++++++++
> > drivers/bluetooth/hci_ldisc.c | 6 +
> > drivers/bluetooth/hci_uart.h | 8 +-
> > 5 files changed, 378 insertions(+), 1 deletions(-)
> > create mode 100755 drivers/bluetooth/hci_ath.c
> >
> > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > index 058fbcc..81abeff 100644
> > --- a/drivers/bluetooth/Kconfig
> > +++ b/drivers/bluetooth/Kconfig
> > @@ -58,6 +58,17 @@ config BT_HCIUART_BCSP
> >
> > Say Y here to compile support for HCI BCSP protocol.
> >
> > +config BT_HCIUART_ATH
> > + bool "Atheros AR300x Board support"
> > + depends on BT_HCIUART
> > + help
> > + HCIATH (HCI Atheros) is a serial protocol for communication
> > + between Bluetooth device and host with support for Atheros AR300x
> > + power management feature. This protocol is required for
> > + serial Bluetooth devices that are based on Atheros AR300x chips.
> > +
> > + Say Y here to compile support for HCIATH protocol.
> > +
> > config BT_HCIUART_LL
> > bool "HCILL protocol support"
> > depends on BT_HCIUART
> > diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> > index 7e5aed5..1481faa 100644
> > --- a/drivers/bluetooth/Makefile
> > +++ b/drivers/bluetooth/Makefile
> > @@ -26,4 +26,5 @@ hci_uart-y := hci_ldisc.o
> > hci_uart-$(CONFIG_BT_HCIUART_H4) += hci_h4.o
> > hci_uart-$(CONFIG_BT_HCIUART_BCSP) += hci_bcsp.o
> > hci_uart-$(CONFIG_BT_HCIUART_LL) += hci_ll.o
> > +hci_uart-$(CONFIG_BT_HCIUART_ATH) += hci_ath.o
> > hci_uart-objs := $(hci_uart-y)
> > diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
> > new file mode 100755
> > index 0000000..13e4404
> > --- /dev/null
> > +++ b/drivers/bluetooth/hci_ath.c
> > @@ -0,0 +1,353 @@
> > +/*
> > + * 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/tty.h>
> > +#include <linux/errno.h>
> > +#include <linux/ioctl.h>
> > +#include <linux/skbuff.h>
> > +
> > +#include <net/bluetooth/bluetooth.h>
> > +#include <net/bluetooth/hci_core.h>
> > +
> > +#include "hci_uart.h"
> > +
> > +
> > +/* HCIATH receiver States */
> > +#define HCIATH_W4_PACKET_TYPE 0
> > +#define HCIATH_W4_EVENT_HDR 1
> > +#define HCIATH_W4_ACL_HDR 2
> > +#define HCIATH_W4_SCO_HDR 3
> > +#define HCIATH_W4_DATA 4
> > +
> > +struct ath_struct {
> > + struct hci_uart *hu;
> > + unsigned int rx_state;
> > + unsigned int rx_count;
> > + unsigned int cur_sleep;
> > +
> > + spinlock_t hciath_lock;
> > + struct sk_buff *rx_skb;
> > + struct sk_buff_head txq;
> > + wait_queue_head_t wqevt;
> > + struct work_struct ctxtsw;
> > +};
> > +
> > +int ath_wakeup_ar3001(struct tty_struct *tty)
> > +{
> > + struct termios settings;
> > + int status = 0x00;
> > + mm_segment_t oldfs;
> > + status = tty->driver->ops->tiocmget(tty, NULL);
> > +
> > + if ((status & TIOCM_CTS))
> > + return status;
> > +
> > + oldfs = get_fs();
> > + set_fs(KERNEL_DS);
> > + n_tty_ioctl_helper(tty, NULL, TCGETS, (unsigned long)&settings);
> > +
> > + settings.c_cflag &= ~CRTSCTS;
> > + n_tty_ioctl_helper(tty, NULL, TCSETS, (unsigned long)&settings);
> > + set_fs(oldfs);
> > + status = tty->driver->ops->tiocmget(tty, NULL);
> > +
> > + /* Wake up board */
> > + tty->driver->ops->tiocmset(tty, NULL, 0x00, TIOCM_RTS);
> > + mdelay(20);
> > +
> > + status = tty->driver->ops->tiocmget(tty, NULL);
> > +
> > + tty->driver->ops->tiocmset(tty, NULL, TIOCM_RTS, 0x00);
> > + mdelay(20);
> > +
> > + status = tty->driver->ops->tiocmget(tty, NULL);
> > + oldfs = get_fs();
> > + set_fs(KERNEL_DS);
> > + n_tty_ioctl_helper(tty, NULL, TCGETS, (unsigned long)&settings);
> > +
> > + settings.c_cflag |= CRTSCTS;
> > + n_tty_ioctl_helper(tty, NULL, TCSETS, (unsigned long)&settings);
> > + set_fs(oldfs);
> > + return status;
> > +}
> > +
> > +static void ath_context_switch(struct work_struct *work)
> > +{
> > + int status;
> > + struct ath_struct *ath;
> > + struct hci_uart *hu;
> > + struct tty_struct *tty;
> > +
> > + ath = container_of(work, struct ath_struct, ctxtsw);
> > +
> > + hu = ath->hu;
> > + tty = hu->tty;
> > +
> > + /* verify and wake up controller */
> > + if (ath->cur_sleep) {
> > +
> > + status = ath_wakeup_ar3001(tty);
> > + if (!(status & TIOCM_CTS))
> > + return;
> > + }
> > +
> > + /* Ready to send Data */
> > + clear_bit(HCI_UART_SENDING, &hu->tx_state);
> > + hci_uart_tx_wakeup(hu);
> > +}
> > +
> > +int ath_check_sleep_cmd(struct ath_struct *ath, unsigned char *packet)
> > +{
> > + if (packet[0] == 0x04 && packet[1] == 0xFC)
> > + ath->cur_sleep = packet[3];
> > +
> > + return 0;
> > +}
> > +
> > +
> > +/* Initialize protocol */
> > +static int ath_open(struct hci_uart *hu)
> > +{
> > + struct ath_struct *ath;
> > + BT_DBG("hu %p", hu);
> > +
> > + ath = kzalloc(sizeof(*ath), GFP_ATOMIC);
> > + if (!ath)
> > + return -ENOMEM;
> > +
> > + skb_queue_head_init(&ath->txq);
> > + spin_lock_init(&ath->hciath_lock);
> > +
> > + ath->cur_sleep = 0;
> > + hu->priv = ath;
> > + ath->hu = hu;
> > +
> > + init_waitqueue_head(&ath->wqevt);
> > + INIT_WORK(&ath->ctxtsw, ath_context_switch);
> > + return 0;
> > +}
> > +
> > +/* Flush protocol data */
> > +static int ath_flush(struct hci_uart *hu)
> > +{
> > + struct ath_struct *ath = hu->priv;
> > + BT_DBG("hu %p", hu);
> > + skb_queue_purge(&ath->txq);
> > +
> > + return 0;
> > +}
> > +
> > +/* Close protocol */
> > +static int ath_close(struct hci_uart *hu)
> > +{
> > + struct ath_struct *ath = hu->priv;
> > + BT_DBG("hu %p", hu);
> > +
> > + skb_queue_purge(&ath->txq);
> > +
> > + if (ath->rx_skb)
> > + kfree_skb(ath->rx_skb);
> > +
> > + wake_up_interruptible(&ath->wqevt);
> > + hu->priv = NULL;
> > + kfree(ath);
> > + return 0;
> > +}
> > +
> > +/* Enqueue frame for transmittion */
> > +static int ath_enqueue(struct hci_uart *hu, struct sk_buff *skb)
> > +{
> > + struct ath_struct *ath = hu->priv;
> > + if (bt_cb(skb)->pkt_type == HCI_SCODATA_PKT) {
> > +
> > + /* Discard SCO packet.AR3001 does not support SCO over HCI */
> > + BT_DBG("SCO Packet over HCI received Dropping\n");
> > + kfree(skb);
> > + return 0;
> > + }
> > + BT_DBG("hu %p skb %p", hu, skb);
> > +
> > + /* Prepend skb with frame type */
> > + memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
> > +
> > + skb_queue_tail(&ath->txq, skb);
> > + set_bit(HCI_UART_SENDING, &hu->tx_state);
> > +
> > + schedule_work(&ath->ctxtsw);
> > + return 0;
> > +}
> > +
> > +static struct sk_buff *ath_dequeue(struct hci_uart *hu)
> > +{
> > + struct ath_struct *ath = hu->priv;
> > + struct sk_buff *skbuf;
> > +
> > + skbuf = skb_dequeue(&ath->txq);
> > + if (skbuf != NULL)
> > + ath_check_sleep_cmd(ath, &skbuf->data[1]);
> > +
> > + return skbuf;
> > +}
> > +
> > +static inline int ath_check_data_len(struct ath_struct *ath, int len)
> > +{
> > + register int room = skb_tailroom(ath->rx_skb);
> > + BT_DBG("len %d room %d", len, room);
> > +
> > + if (len > room) {
> > + BT_ERR("Data length is too large");
> > + kfree_skb(ath->rx_skb);
> > + ath->rx_state = HCIATH_W4_PACKET_TYPE;
> > + ath->rx_skb = NULL;
> > + ath->rx_count = 0;
> > + } else {
> > + ath->rx_state = HCIATH_W4_DATA;
> > + ath->rx_count = len;
> > + return len;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/* Recv data */
> > +static int ath_recv(struct hci_uart *hu, void *data, int count)
> > +{
> > + struct ath_struct *ath = hu->priv;
> > + register char *ptr;
> > + struct hci_event_hdr *eh;
> > + struct hci_acl_hdr *ah;
> > + struct hci_sco_hdr *sh;
> > + struct sk_buff *skbuf;
> > + register int len, type, dlen;
> > +
> > + skbuf = NULL;
> > + BT_DBG("hu %p count %d rx_state %d rx_count %d", hu, count,
> > + ath->rx_state, ath->rx_count);
> > + ptr = data;
> > + while (count) {
> > + if (ath->rx_count) {
> > +
> > + len = min_t(unsigned int, ath->rx_count, count);
> > + memcpy(skb_put(ath->rx_skb, len), ptr, len);
> > + ath->rx_count -= len;
> > + count -= len;
> > + ptr += len;
> > +
> > + if (ath->rx_count)
> > + continue;
> > + switch (ath->rx_state) {
> > + case HCIATH_W4_DATA:
> > + hci_recv_frame(ath->rx_skb);
> > + ath->rx_state = HCIATH_W4_PACKET_TYPE;
> > + ath->rx_skb = NULL;
> > + ath->rx_count = 0;
> > + continue;
> > + case HCIATH_W4_EVENT_HDR:
> > + eh = (struct hci_event_hdr *)ath->rx_skb->data;
> > + BT_DBG("Event header: evt 0x%2.2x plen %d",
> > + eh->evt, eh->plen);
> > + ath_check_data_len(ath, eh->plen);
> > + continue;
> > + case HCIATH_W4_ACL_HDR:
> > + ah = (struct hci_acl_hdr *)ath->rx_skb->data;
> > + dlen = __le16_to_cpu(ah->dlen);
> > + BT_DBG("ACL header: dlen %d", dlen);
> > + ath_check_data_len(ath, dlen);
> > + continue;
> > + case HCIATH_W4_SCO_HDR:
> > + sh = (struct hci_sco_hdr *)ath->rx_skb->data;
> > + BT_DBG("SCO header: dlen %d", sh->dlen);
> > + ath_check_data_len(ath, sh->dlen);
> > + continue;
> > + }
> > + }
> > +
> > + /* HCIATH_W4_PACKET_TYPE */
> > + switch (*ptr) {
> > + case HCI_EVENT_PKT:
> > + BT_DBG("Event packet");
> > + ath->rx_state = HCIATH_W4_EVENT_HDR;
> > + ath->rx_count = HCI_EVENT_HDR_SIZE;
> > + type = HCI_EVENT_PKT;
> > + break;
> > + case HCI_ACLDATA_PKT:
> > + BT_DBG("ACL packet");
> > + ath->rx_state = HCIATH_W4_ACL_HDR;
> > + ath->rx_count = HCI_ACL_HDR_SIZE;
> > + type = HCI_ACLDATA_PKT;
> > + break;
> > + case HCI_SCODATA_PKT:
> > + BT_DBG("SCO packet");
> > + ath->rx_state = HCIATH_W4_SCO_HDR;
> > + ath->rx_count = HCI_SCO_HDR_SIZE;
> > + type = HCI_SCODATA_PKT;
> > + break;
> > + default:
> > + BT_ERR("Unknown HCI packet type %2.2x", (__u8) *ptr);
> > + hu->hdev->stat.err_rx++;
> > + ptr++;
> > + count--;
> > + continue;
> > + };
> > + ptr++;
> > + count--;
> > +
> > + /* Allocate packet */
> > + ath->rx_skb = bt_skb_alloc(HCI_MAX_FRAME_SIZE, GFP_ATOMIC);
> > + if (!ath->rx_skb) {
> > + BT_ERR("Can't allocate mem for new packet");
> > + ath->rx_state = HCIATH_W4_PACKET_TYPE;
> > + ath->rx_count = 0;
> > + return -ENOMEM;
> > + }
> > + ath->rx_skb->dev = (void *)hu->hdev;
> > + bt_cb(ath->rx_skb)->pkt_type = type;
> > + } return count;
> > +}
> > +
> > +static struct hci_uart_proto athp = {
> > + .id = HCI_UART_ATH,
> > + .open = ath_open,
> > + .close = ath_close,
> > + .recv = ath_recv,
> > + .enqueue = ath_enqueue,
> > + .dequeue = ath_dequeue,
> > + .flush = ath_flush,
> > +};
> > +
> > +int ath_init(void)
> > +{
> > + int err = hci_uart_register_proto(&athp);
> > + if (!err)
> > + BT_INFO("HCIATH protocol initialized");
> > +
> > + else
> > + BT_ERR("HCIATH protocol registration failed");
> > + return err;
> > +}
> > +
> > +int ath_deinit(void)
> > +{
> > + return hci_uart_unregister_proto(&athp);
> > +}
> > diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> > index 76a1abb..7dd76d1 100644
> > --- a/drivers/bluetooth/hci_ldisc.c
> > +++ b/drivers/bluetooth/hci_ldisc.c
> > @@ -542,6 +542,9 @@ static int __init hci_uart_init(void)
> > #ifdef CONFIG_BT_HCIUART_LL
> > ll_init();
> > #endif
> > +#ifdef CONFIG_BT_HCIUART_ATH
> > + ath_init();
> > +#endif
> >
> > return 0;
> > }
> > @@ -559,6 +562,9 @@ static void __exit hci_uart_exit(void)
> > #ifdef CONFIG_BT_HCIUART_LL
> > ll_deinit();
> > #endif
> > +#ifdef CONFIG_BT_HCIUART_ATH
> > + ath_deinit();
> > +#endif
> >
> > /* Release tty registration of line discipline */
> > if ((err = tty_unregister_ldisc(N_HCI)))
> > diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
> > index 50113db..385537f 100644
> > --- a/drivers/bluetooth/hci_uart.h
> > +++ b/drivers/bluetooth/hci_uart.h
> > @@ -33,13 +33,14 @@
> > #define HCIUARTGETDEVICE _IOR('U', 202, int)
> >
> > /* UART protocols */
> > -#define HCI_UART_MAX_PROTO 5
> > +#define HCI_UART_MAX_PROTO 6
> >
> > #define HCI_UART_H4 0
> > #define HCI_UART_BCSP 1
> > #define HCI_UART_3WIRE 2
> > #define HCI_UART_H4DS 3
> > #define HCI_UART_LL 4
> > +#define HCI_UART_ATH 5
> >
> > struct hci_uart;
> >
> > @@ -91,3 +92,8 @@ int bcsp_deinit(void);
> > int ll_init(void);
> > int ll_deinit(void);
> > #endif
> > +
> > +#ifdef CONFIG_BT_HCIUART_ATH
> > +int ath_init(void);
> > +int ath_deinit(void);
> > +#endif
>
> Hi Marcel,
>
> Can you please give your comments regarding the patch that I have sent
> you?
>
> Regards
> Suraj
Hi marcel,
A gentle remainder.
Can you please update the above driver to the Linux tree? If you find
any issues please let me know so that I can do the needful.
Regards
Suraj
^ permalink raw reply
* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
From: Marcel Holtmann @ 2010-03-29 8:29 UTC (permalink / raw)
To: Johan Hedberg; +Cc: Francisco Alecrim, linux-bluetooth
In-Reply-To: <20100329074539.GA20839@jh-x301>
Hi Johan,
> > Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus message
> > to inform that adapter properties changed.
> > ---
> > src/adapter.c | 75 ++++++++++++++++++++++++++++++++++++++++++++------
> > src/adapter.h | 1 +
> > src/sdpd-database.c | 3 ++
> > 3 files changed, 70 insertions(+), 9 deletions(-)
>
> Thanks for the patches. In principle they look good, but I haven't
> applied them yet due to one thing that looks a bit strange: both the SDP
> server record UUID (0x1000) as well as the public browse group UUID
> (0x1001) always show up in the UUIDs list. I wonder if there'd be any
> clean way to avoid getting them into the list. Marcel, do you have any
> idea about this or is it even a problem that these UUIDs are always in
> the list?
these UUIDs are always in the server, but not in the public browse group
and we skip them on purpose. The only reason why they are always present
is that the specification requires it.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Return error when modem_obj_path is NULL
From: Johan Hedberg @ 2010-03-29 8:13 UTC (permalink / raw)
To: Forrest Zhao; +Cc: linux-bluetooth, forrest.zhao
In-Reply-To: <1269896562-3408-1-git-send-email-forrest.zhao@intel.com>
Hi Forrest,
On Mon, Mar 29, 2010, Forrest Zhao wrote:
> This could prevent crash in case modem_obj_path is NULL.
> ---
> audio/telephony-ofono.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
Thanks. Pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Check modem_obj_path is not NULL
From: Zhao Forrest @ 2010-03-29 7:58 UTC (permalink / raw)
To: Forrest Zhao, linux-bluetooth, forrest.zhao
In-Reply-To: <20100329073957.GA20677@jh-x301>
>> @@ -311,6 +315,10 @@ void telephony_transmit_dtmf_req(void *telephony_device, char tone)
>>
>> debug("telephony-ofono: transmit dtmf: %c", tone);
>>
>> + if (!modem_obj_path)
>> + telephony_transmit_dtmf_rsp(telephony_device,
>> + CME_ERROR_AG_FAILURE);
>> +
>> tone_string = g_strdup_printf("%c", tone);
>> ret = send_method_call(OFONO_BUS_NAME, modem_obj_path,
>
> This doesn't look right. You report an error but still proceed in the
> functions (which will later try to access modem_obj_path). I guess you
> should return from the functions in both of these if-clauses.
>
My bad. Will send out the updated patch ASAP.
^ permalink raw reply
* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
From: Johan Hedberg @ 2010-03-29 7:45 UTC (permalink / raw)
To: Francisco Alecrim; +Cc: linux-bluetooth, marcel
In-Reply-To: <1269644076-10544-2-git-send-email-francisco.alecrim@openbossa.org>
Hi,
On Fri, Mar 26, 2010, Francisco Alecrim wrote:
> Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus message
> to inform that adapter properties changed.
> ---
> src/adapter.c | 75 ++++++++++++++++++++++++++++++++++++++++++++------
> src/adapter.h | 1 +
> src/sdpd-database.c | 3 ++
> 3 files changed, 70 insertions(+), 9 deletions(-)
Thanks for the patches. In principle they look good, but I haven't
applied them yet due to one thing that looks a bit strange: both the SDP
server record UUID (0x1000) as well as the public browse group UUID
(0x1001) always show up in the UUIDs list. I wonder if there'd be any
clean way to avoid getting them into the list. Marcel, do you have any
idea about this or is it even a problem that these UUIDs are always in
the list?
Johan
^ permalink raw reply
* Re: [PATCH] Check modem_obj_path is not NULL
From: Johan Hedberg @ 2010-03-29 7:39 UTC (permalink / raw)
To: Forrest Zhao; +Cc: linux-bluetooth, forrest.zhao
In-Reply-To: <1269894774-3193-1-git-send-email-forrest.zhao@intel.com>
Hi Forrest,
On Mon, Mar 29, 2010, Forrest Zhao wrote:
> This could prevent crash in case modem_obj_path is NULL.
> ---
> audio/telephony-ofono.c | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/audio/telephony-ofono.c b/audio/telephony-ofono.c
> index 45c3905..c145e87 100644
> --- a/audio/telephony-ofono.c
> +++ b/audio/telephony-ofono.c
> @@ -281,6 +281,10 @@ void telephony_dial_number_req(void *telephony_device, const char *number)
>
> debug("telephony-ofono: dial request to %s", number);
>
> + if (!modem_obj_path)
> + telephony_dial_number_rsp(telephony_device,
> + CME_ERROR_AG_FAILURE);
> +
> if (!strncmp(number, "*31#", 4)) {
> number += 4;
> clir = "enabled";
> @@ -311,6 +315,10 @@ void telephony_transmit_dtmf_req(void *telephony_device, char tone)
>
> debug("telephony-ofono: transmit dtmf: %c", tone);
>
> + if (!modem_obj_path)
> + telephony_transmit_dtmf_rsp(telephony_device,
> + CME_ERROR_AG_FAILURE);
> +
> tone_string = g_strdup_printf("%c", tone);
> ret = send_method_call(OFONO_BUS_NAME, modem_obj_path,
This doesn't look right. You report an error but still proceed in the
functions (which will later try to access modem_obj_path). I guess you
should return from the functions in both of these if-clauses.
Johan
^ permalink raw reply
* Sending big patches
From: José Antonio Santos Cadenas @ 2010-03-29 7:03 UTC (permalink / raw)
To: linux-bluetooth
Hi all,
Las friday Sancane and me tried to send a firts patch with MCAP and HDP, but it
seems it has been retained. The patch is about 5K lines and we sent it as an
attached file. Is there a better way to send this patch?
Regards
^ permalink raw reply
* GSOC 2010 - DUN Client
From: Andrey Sokolov @ 2010-03-28 17:47 UTC (permalink / raw)
To: linux-bluetooth
Hello!
I have been working on a Linux system during 3 years. I have contributed
to Bluetooth Stack & Drivers OpenSolaris project
(http://hub.opensolaris.org/bin/view/Project+bluetooth/ , "Special
Contributions" section). I have ported bthcid from NetBSD to OpenSolaris.
I graduated Vyatka State University (Russia) from department of
Computing Machines in 2007. Now I am a magistracy's student (AI). I had
internship at Intel Summer School 2006 in Nizhniy Novgorod (Russia). I
am really interested in open source operating systems. More than that, I
am rather experienced in bluetooth sphere. I have worked with
OpenSolaris and I am sure I won't have any problems with Linux. I guess
it will be for hobby. I will have my exams in June. I will be able to
dedicate 20 hours per week to the project.
I prefer to work on the DUN client idea, but other ideas are acceptable too.
Andrey
^ permalink raw reply
* hci0 urb xxxxxxxxx failed to resubmit (1)
From: Dick @ 2010-03-27 14:19 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Since I've updated my kernel to 2.6.32.10 I get the following errors in
dmesg:
...
btusb_bulk_complete: hci0 urb e48c1b00 failed to resubmit (1)
btusb_intr_complete: hci0 urb f201c280 failed to resubmit (1)
btusb_bulk_complete: hci0 urb f201c100 failed to resubmit (1)
btusb_bulk_complete: hci0 urb f201c180 failed to resubmit (1)
btusb_intr_complete: hci0 urb f2007580 failed to resubmit (1)
btusb_bulk_complete: hci0 urb f2007f00 failed to resubmit (1)
btusb_bulk_complete: hci0 urb f2007a00 failed to resubmit (1)
btusb_intr_complete: hci0 urb f20eb200 failed to resubmit (1)
btusb_bulk_complete: hci0 urb f20ebf00 failed to resubmit (1)
btusb_bulk_complete: hci0 urb f20eb300 failed to resubmit (1)
I've had urb / isoc errors before and I've fixed that issue with isoc=0
on the
kernel module, this parameter doesn't seem available anymore.
# modinfo btusb
filename: /lib/modules/2.6.32.10-1-
fl.smp.gcc4.1.x86.i686/kernel/drivers/bluetooth/btusb.ko
license: GPL
version: 0.6
description: Generic Bluetooth USB driver ver 0.6
author: Marcel Holtmann <marcel@holtmann.org>
srcversion: F297975F8C54B1A9EB522AC
alias: usb:v0C10p0000d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0BDBp1002d*dc*dsc*dp*ic*isc*ip*
alias: usb:v044Ep3002d*dc*dsc*dp*ic*isc*ip*
alias: usb:v044Ep3001d*dc*dsc*dp*ic*isc*ip*
alias: usb:v04BFp030Ad*dc*dsc*dp*ic*isc*ip*
alias: usb:v057Cp3800d*dc*dsc*dp*ic*isc*ip*
alias: usb:v*p*d*dcE0dsc01dp01ic*isc*ip*
depends: bluetooth
vermagic: 2.6.32.10-1-fl.smp.gcc4.1.x86.i686 SMP mod_unload 686
parm: ignore_dga:Ignore devices with id 08fd:0001 (bool)
parm: ignore_csr:Ignore devices with id 0a12:0001 (bool)
parm: ignore_sniffer:Ignore devices with id 0a12:0002 (bool)
parm: disable_scofix:Disable fixup of wrong SCO buffer size
(bool)
parm: force_scofix:Force fixup of wrong SCO buffers size
(bool)
parm: reset:Send HCI reset command on initialization (bool)
bluez=4.62-1-0.0.1
# hciconfig hci0 -a
hci0: Type: BR/EDR Bus: USB
BD Address: 00:16:41:92:xx:xx ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:441742 acl:23420 sco:0 events:2251 errors:0
TX bytes:1678 acl:28 sco:0 commands:90 errors:1
Features: 0xff 0xff 0x9f 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'latitude'
Class: 0x4a010c
Service Classes: Networking, Capturing, Telephony
Device Class: Computer, Laptop
HCI Version: 2.0 (0x3) Revision: 0x976
LMP Version: 2.0 (0x3) Subversion: 0x976
Manufacturer: Cambridge Silicon Radio (10)
# lsusb
Bus 001 Device 014: ID 413c:8103 Dell Computer Corp. Wireless 350
Bluetooth
My HID devices are laggy and sometimes freeze for a minute.
Please help :)
^ permalink raw reply
* Re: [PATCH] Fix display of last device classes in hciconfig
From: Gustavo F. Padovan @ 2010-03-27 9:20 UTC (permalink / raw)
To: Daniel Abraham; +Cc: Vinicius Gomes, linux-bluetooth
In-Reply-To: <1269678511.22795.22.camel@localhost.localdomain>
Hi Daniel,
On Sat, Mar 27, 2010 at 5:28 AM, Daniel Abraham
<daniel.shrugged@gmail.com> wrote:
>> > ---
>> > tools/hciconfig.c | 30 ++++++++++++++++++++++++++----
>> > 1 files changed, 26 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/tools/hciconfig.c b/tools/hciconfig.c
>> > index 3f687e0..c97ce44 100644
>> > --- a/tools/hciconfig.c
>> > +++ b/tools/hciconfig.c
>> > @@ -645,8 +645,26 @@ static char *get_minor_device_name(int major, int minor)
>> > return "Game";
>> > }
>> > break;
>> > - case 63: /* uncategorised */
>> > - return "";
>>
>> I think that the test for the "Uncategorised" (which seems to be
>> misspelled in many places) device class would be better staying here,
>> because the same code is used inside hcitool.c. Fixing there would be
>> nice too.
>>
>> Another thing, looks like this "case 63:" is wrong, major device
>> class is a 5 bit number, and the uncategorized device class is defined
>> as 31. Looks like a legacy from ancient times ;-)
>
> That's exactly why I changed it: the original check below whether to
> enter this function ("if ((cls[1] & 0x1f) >= ...") meant <no. of
> categories + 1> where +1 meant "Unrecognized", but this is mistaken as
> you wrote.
>
> I don't mind fixing it in "hcitool.c" as well, but see followup question
> at the bottom.
>
>> > + case 9: /* health */
>> > + switch(minor) {
>> > + case 0:
>> > + return "Undefined";
>> > + case 1:
>> > + return "Blood Pressure Monitor";
>> > + case 2:
>> > + return "Thermometer";
>> > + case 3:
>> > + return "Weighing Scale";
>> > + case 4:
>> > + return "Glucose Meter";
>> > + case 5:
>> > + return "Pulse Oximeter";
>> > + case 6:
>> > + return "Heart/Pulse Rate Monitor";
>> > + case 7:
>> > + return "Health Data Display";
>> > + }
>> > + break;
>> > }
>> > return "Unknown (reserved) minor device class";
>> > }
>> > @@ -668,7 +686,9 @@ static void cmd_class(int ctl, int hdev, char *opt)
>> > "Audio/Video",
>> > "Peripheral",
>> > "Imaging",
>> > - "Uncategorized" };
>> > + "Wearable",
>> > + "Toy",
>> > + "Health" };
>> > int s = hci_open_dev(hdev);
>> >
>> > if (s < 0) {
>> > @@ -706,7 +726,9 @@ static void cmd_class(int ctl, int hdev, char *opt)
>> > } else
>> > printf("Unspecified");
>> > printf("\n\tDevice Class: ");
>> > - if ((cls[1] & 0x1f) >= sizeof(major_devices) / sizeof(*major_devices))
>> > + if (0x1f == cls[1])
>>
>> This test is inverted, in BlueZ code we use the form: (variable
>> operator constant)
>>
>> > + printf("Uncategorized\n");
>> > + else if ((cls[1] & 0x1f) >= sizeof(major_devices) / sizeof(*major_devices))
>>
>> See above.
>
> Will fix both.
>
>> > printf("Invalid Device Class!\n");
>> > else
>> > printf("%s, %s\n", major_devices[cls[1] & 0x1f],
>> > --
>> > 1.6.6.1
>> > --
>> >
>>
>>
>> Cheers,
>
> Thanks for the comments! I'll send a fixed patch.
>
> But here's a followup question: what's the convention for submitting a
> change to a patch - another patch on top of it, or a full replacement
> patch? As a reply to this thread, or as new message?
Send a full replacement inline patch as a reply to this thread.
>
> --
> 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
>
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH] Fix display of last device classes in hciconfig
From: Daniel Abraham @ 2010-03-27 8:28 UTC (permalink / raw)
To: Vinicius Gomes; +Cc: linux-bluetooth
In-Reply-To: <2a9506371003221436s1cf1b465r907f726797b4f251@mail.gmail.com>
> > ---
> > tools/hciconfig.c | 30 ++++++++++++++++++++++++++----
> > 1 files changed, 26 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/hciconfig.c b/tools/hciconfig.c
> > index 3f687e0..c97ce44 100644
> > --- a/tools/hciconfig.c
> > +++ b/tools/hciconfig.c
> > @@ -645,8 +645,26 @@ static char *get_minor_device_name(int major, int minor)
> > return "Game";
> > }
> > break;
> > - case 63: /* uncategorised */
> > - return "";
>
> I think that the test for the "Uncategorised" (which seems to be
> misspelled in many places) device class would be better staying here,
> because the same code is used inside hcitool.c. Fixing there would be
> nice too.
>
> Another thing, looks like this "case 63:" is wrong, major device
> class is a 5 bit number, and the uncategorized device class is defined
> as 31. Looks like a legacy from ancient times ;-)
That's exactly why I changed it: the original check below whether to
enter this function ("if ((cls[1] & 0x1f) >= ...") meant <no. of
categories + 1> where +1 meant "Unrecognized", but this is mistaken as
you wrote.
I don't mind fixing it in "hcitool.c" as well, but see followup question
at the bottom.
> > + case 9: /* health */
> > + switch(minor) {
> > + case 0:
> > + return "Undefined";
> > + case 1:
> > + return "Blood Pressure Monitor";
> > + case 2:
> > + return "Thermometer";
> > + case 3:
> > + return "Weighing Scale";
> > + case 4:
> > + return "Glucose Meter";
> > + case 5:
> > + return "Pulse Oximeter";
> > + case 6:
> > + return "Heart/Pulse Rate Monitor";
> > + case 7:
> > + return "Health Data Display";
> > + }
> > + break;
> > }
> > return "Unknown (reserved) minor device class";
> > }
> > @@ -668,7 +686,9 @@ static void cmd_class(int ctl, int hdev, char *opt)
> > "Audio/Video",
> > "Peripheral",
> > "Imaging",
> > - "Uncategorized" };
> > + "Wearable",
> > + "Toy",
> > + "Health" };
> > int s = hci_open_dev(hdev);
> >
> > if (s < 0) {
> > @@ -706,7 +726,9 @@ static void cmd_class(int ctl, int hdev, char *opt)
> > } else
> > printf("Unspecified");
> > printf("\n\tDevice Class: ");
> > - if ((cls[1] & 0x1f) >= sizeof(major_devices) / sizeof(*major_devices))
> > + if (0x1f == cls[1])
>
> This test is inverted, in BlueZ code we use the form: (variable
> operator constant)
>
> > + printf("Uncategorized\n");
> > + else if ((cls[1] & 0x1f) >= sizeof(major_devices) / sizeof(*major_devices))
>
> See above.
Will fix both.
> > printf("Invalid Device Class!\n");
> > else
> > printf("%s, %s\n", major_devices[cls[1] & 0x1f],
> > --
> > 1.6.6.1
> > --
> >
>
>
> Cheers,
Thanks for the comments! I'll send a fixed patch.
But here's a followup question: what's the convention for submitting a
change to a patch - another patch on top of it, or a full replacement
patch? As a reply to this thread, or as new message?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox