* Re: Possible regression with skb_clone() in 2.6.36
From: Gustavo F. Padovan @ 2010-09-16 0:10 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, netdev, linux-kernel, marcel, davem
In-Reply-To: <20100910194509.GC19693@vigoh>
* Gustavo F. Padovan <padovan@profusion.mobi> [2010-09-10 16:45:09 -0300]:
> Hi Mat,
>
> * Mat Martineau <mathewm@codeaurora.org> [2010-09-10 09:53:31 -0700]:
>
> >
> > Gustavo -
> >
> > I'm not sure why the streaming code used to work, but this does not
> > look like an skb_clone() problem. Your patch to remove the
> > skb_clone() call in l2cap_streaming_send() addresses the root cause of
> > this crash.
> >
> > On Wed, 8 Sep 2010, Gustavo F. Padovan wrote:
> >
> > > I've been experiencing some problems when running the L2CAP Streaming mode in
> > > 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> > > wasn't happening before, so I think we may have a regression here (I didn't
> > > find where yet). The crash log is below.
> > >
> > > The following patch does not fix the regression, but shows that removing the
> > > skb_clone() call from l2cap_streaming_send() we workaround the problem. The
> > > patch is good anyway because it saves memory and time.
> > >
> > > By now I have no idea on how to fix this.
> > >
> > > <snip>
> >
> > This has to do with the sk->sk_wmem_alloc accounting that controls the
> > amount of write buffer space used on the socket.
> >
> > When the L2CAP streaming mode socket segments its data, it allocates
> > memory using sock_alloc_send_skb() (via bt_skb_send_alloc()). Before
> > that allocation call returns, skb_set_owner_w() is called on the new
> > skb. This adds to sk->sk_wmem_alloc and sets skb->destructor so that
> > sk->sk_wmem_alloc is correctly updated when the skb is freed.
> >
> > When that skb is cloned, the clone is not "owned" by the write buffer.
> > The clone's destructor is set to NULL in __skb_clone(). The version
> > of l2cap_streaming_send() that runs out of memory is passing the
> > non-owned skb clone down to the HCI layer. The original skb (the one
> > that's "owned by w") is immediately freed, which adjusts
> > sk->sk_wmem_alloc back down - the socket thinks it has unlimited write
> > buffer space. As a result, bt_skb_send_alloc() never blocks waiting
> > for buffer space (or returns EAGAIN for nonblocking writes) and the
> > HCI send queue keeps growing.
>
> If the problem is what you are saying, add a skb_set_owner_w(skb, sk) on
> the cloned skb should solve the problem, but it doesn't. That's exactly
> what tcp_transmit_skb() does. Also that just appeared in 2.6.36, is was
> working fine before, i.e, we have a regression here.
>
> >
> > This isn't a problem for the ERTM sends, because the original skbs are
> > kept in the ERTM tx queue until they are acked. Once they're acked,
> > the write buffer space is freed and additional skbs can be allocated.
>
> It affects ERTM as well, but in that case the kernel doesn't crash
> because ERTM block on sending trying to allocate memory. Then we are not
> able to receive any ack (everything stays queued in sk_backlog_queue as
> the sk is owned by the user) and ERTM stalls.
By reverting
commit 218bb9dfd21472128f86b38ad2eab123205c2991
Author: Gustavo F. Padovan <padovan@profusion.mobi>
Date: Mon Jun 21 18:53:22 2010 -0300
Bluetooth: Add backlog queue to ERTM code
backlog queue is the canonical mechanism to avoid race conditions due
interrupts in bottom half context. After the socket lock is released the
net core take care of push all skb in its backlog queue.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
we can workaround the bug. It's not the real cause of the bug because the
backlog queue was working before 2.6.36, but removing the backlog queue scheme
make L2CAP works again and also give us more time to find the real cause of the
problem.
Before implement the backlog queue L2CAP had his own lock scheme to avoid race
conditions. The point is that the backlog queue adds too much serialization to
L2CAP, that was the cause of the ERTM bug. The old scheme (the one we are going
to use after revert this commit) just serialize access to some places.
By not using the backlog queue, we can receive the acknowledgement frames more
quickly and then free the acked frames quickly. In fact the old scheme is
looks better than backlog queue.
I think we should proceed with the revert with this commit in mainline, and at the
same time try to find the root cause of the problem.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: CSP implementation for MCAP
From: Elvis Pfützenreuter @ 2010-09-15 22:45 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <4A11989E-5448-43B7-887F-217C54977E22@epx.com.br>
On 02/09/2010, at 15:58, Elvis Pfützenreuter wrote:
> This is the repository for the CSP implementation, rebased over the recently accepted MCAP, for your appreciation:
>
> git://gitorious.org/bluez-epx/bluez-epx.git csp
>
> or
>
> http://www.gitorious.org/bluez-epx/bluez-epx/commits/csp--
And I am happy to announce that this CSP implementation passed on PTS :) Fixes are on topmost patch of the repository.
^ permalink raw reply
* Re: Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900
From: Pavan Savoy @ 2010-09-15 20:57 UTC (permalink / raw)
To: pghatwork; +Cc: Alan Cox, linus.walleij, linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTi=CNdDYVGNmx17miVBXfPgnWY0X59Ao1pRQDN=S@mail.gmail.com>
Hi,
On Wed, Sep 15, 2010 at 5:14 AM, Par-Gunnar Hjalmdahl
<par-gunnar.p.hjalmdahl@stericsson.com> wrote:
> Hi Pavan,
>
> Thanks for your comments and sorry for me taking time to answer your mail.
> See below for answers.
>
>>
>> ok bit more of information ....
>> We don;t use the hciattach, instead we have our own daemon which opens
>> up the UART and installs the line discipline (not N_HCI, but similar
>> one called N_SHARED) when the hciconfig hci0 up happens or even when
>> /dev/radio0 (FM V4L2 device) happens or when generic GPS character
>> device (/dev/tigps) happens...
>
> :-) We also have our own user space application for opening the UART
> and setting the line disc since we don't want to depend completely on
> hciattach, which contains more than we need, and also misses stuff
> that we want to do towards our specific controller. I just used it as
> an example since that is the common BlueZ way to open the Bluetooth
> transport.
Ok, yes currently we communicate with user-space daemon over rfkill,
we can probably use UDEV events to communicate opening/installation of
ldisc or closing of UART.
>>
>> There is non-mailine driver which gets modified to get into mainline @
>> http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=drivers/misc/ti-
>> st;h=028ff4a739d7b59b94d0c613b5ef510ff338b65d;hb=refs/heads/p-android-
>> omap-2.6.32
>>
>> feel free to have a look at it...
>> Yes our solution too works with BlueZ and non-exactly a MFD driver but
>> it is a simple platform device driver .. by looks of things the driver
>> can run as is for your chip too .. (except for the firmware search and
>> download part .. may be...).
>
> Your code is in a lot of ways similar to ours (which is not so strange
> since you address the same market with your chip as we do with ours),
> but there are several differences that would at least for now make it
> impossible for us to use your driver. When we post our first patches
> (which will hopefully be in a few days) you can see for yourself. But
> I don't think there is a simple way for us to re-use your driver.
Humn, I kind of thought may be we can have a same driver for 2
different types of chips.
>>
>> and note when we would want to support SPI transport for the same, we
>> plan a SPI-TTY driver ('ala usb-serial) where-in we can install this
>> N_TI_WL line discipline on that /dev/ttySPI0 device, and the SPI
>> related stuff to be handled by the spi-tty.c which registers itself as
>> a tty_device and a tty_driver ....
>
> Our SPI usage will be a bit different, where we don't use TTY for our
> driver. We will use the SPI directly instead.
>
Ok, I was intending towards the SPI usage of our driver when we move to SPI.
>> regards,
>> Pavan
>>
>> On Fri, Sep 10, 2010 at 2:07 PM, Pavan Savoy <pavan_savoy@sify.com>
>> wrote:
>> > Can you directly make use of the ti-st driver which is currently
>> staged?
>> > It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising
>> !!!
>
> :-) As I said earlier this is quite natural since both TI and
> ST-Ericsson address the same market segments.
yes...
> /P-G
>
^ permalink raw reply
* Re: [RFC] D-Bus API for out of band association model
From: jaikumar Ganesh @ 2010-09-15 19:13 UTC (permalink / raw)
To: jaikumar Ganesh, Claudio Takahasi, Andrzej Kaczmarek,
linux-bluetooth, par-gunnar.p.hjalmdahl
In-Reply-To: <20100915185340.GA2804@jh-x301>
Hi Johan:
On Wed, Sep 15, 2010 at 11:53 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Jaikumar,
>
> On Wed, Sep 15, 2010, jaikumar Ganesh wrote:
>> We started to work on this API too last week. Not complete yet to post
>> to the mailing list.
>> The approach we took was this:
>>
>> a) Since OOB authentication is just another means of authentication
>> compared to Passkey, Pin entry,
>> we added an agent API (similar to the lines of other
>> authentication mechanisms) that will ask for the Out Of Band data.
>> b) We added an API to the adapter to get the local Out of Band Data
>> c) Currently, RegisterAgent is called to register with the
>> capabilities. Since OOB is part of the capabilities data structure, we
>> added OOB to agent structure which already has the capabilities.
>> d) We added an API variant of createPairedDevice which will be used
>> for OutOfBand Pairing. When the device agent is created, the OOB field
>> in agent is updated.
>> e) When a capability request comes from the remote side the agent OOB
>> field is checked. It will be set if the pairing is initiated locally
>> through d).
>> For incoming pairing requests if the Agent has OOB field set but
>> there is no device specific agent, we need to make an Agent API call
>> asking if
>> there is OOB data for this remote device.
>>
>> We left it to the users of the API - regarding the OOB channel to use.
>> It can be NFC or any other trusted channel.
>>
>> Comments ?
>
> I'm still not convinced that the Agent is the right place for this. The
> agent is typically representing the UI whereas in most cases (like NFC)
> the OOB data will be coming from below bluetoothd in the software stack
> and not from above it (which is where the agent resides). Also, the
> presence of OOB data isn't really agent specific. It's something that
> can come and go during the lifetime of an agent.
Consider a case where there is a third party app residing on the device.
This wants to initiate pairing and has OOB data. (here OOB data comes
from above bluetoothd)
When the remote request OOB data comes, bluetoothd asks the app for
the OOB data.
Depending on the implementation either the app can show a UI to the user
asking permission to pair when the OOB data Agent API is called. This is again
similar to what we have for the passkey mechanism.
This need of the UI and the fact that OOB data can come from above
bluetoothd (similar to pin entry)
is what made us go with the agent approach.
The device agent is removed when the device is unpaired. So next time
when pairing
happens depending upon the API used we can again have OOB pairing or
non OOB pairing.
Yes OOB data can come and go during the life of an agent. Hence we put
this burden on the users
of bluetoothd to supply bluetoothd if the OOB data. We not storing any
OOB data of the remote device
in bluetoothd
> My idea has been to add a a plugin interface through which a hardware
> specific plugin could notify the core daemon about the existence of OOB
> data. bluetoothd would then take care of setting the right flag when it
> gets a IO capability request. This doesn't of course rule out the
> possibility of having part of the work done in another process since the
> plugin could simply export a service over D-Bus or talk to another D-Bus
> service.
If I understand correctly, hardware specific plugin works well for
things like NFC.
What about cases where the trusted channel is say something like an
app running on
both the computer and the device. That channel is trusted using some
other authentication mechanism
The apps communicate to exchange OOB data.
For example, you can use the browser to device messaging mechanism
(Cloud to device messaging using Chrome).
>
> Johan
>
^ permalink raw reply
* Re: [RFC] D-Bus API for out of band association model
From: Johan Hedberg @ 2010-09-15 18:53 UTC (permalink / raw)
To: jaikumar Ganesh
Cc: Claudio Takahasi, Andrzej Kaczmarek, linux-bluetooth,
par-gunnar.p.hjalmdahl
In-Reply-To: <AANLkTikryj2AeaCWpVKQhkMznfAF-d15QpJF6=BgyGsY@mail.gmail.com>
Hi Jaikumar,
On Wed, Sep 15, 2010, jaikumar Ganesh wrote:
> We started to work on this API too last week. Not complete yet to post
> to the mailing list.
> The approach we took was this:
>
> a) Since OOB authentication is just another means of authentication
> compared to Passkey, Pin entry,
> we added an agent API (similar to the lines of other
> authentication mechanisms) that will ask for the Out Of Band data.
> b) We added an API to the adapter to get the local Out of Band Data
> c) Currently, RegisterAgent is called to register with the
> capabilities. Since OOB is part of the capabilities data structure, we
> added OOB to agent structure which already has the capabilities.
> d) We added an API variant of createPairedDevice which will be used
> for OutOfBand Pairing. When the device agent is created, the OOB field
> in agent is updated.
> e) When a capability request comes from the remote side the agent OOB
> field is checked. It will be set if the pairing is initiated locally
> through d).
> For incoming pairing requests if the Agent has OOB field set but
> there is no device specific agent, we need to make an Agent API call
> asking if
> there is OOB data for this remote device.
>
> We left it to the users of the API - regarding the OOB channel to use.
> It can be NFC or any other trusted channel.
>
> Comments ?
I'm still not convinced that the Agent is the right place for this. The
agent is typically representing the UI whereas in most cases (like NFC)
the OOB data will be coming from below bluetoothd in the software stack
and not from above it (which is where the agent resides). Also, the
presence of OOB data isn't really agent specific. It's something that
can come and go during the lifetime of an agent.
My idea has been to add a a plugin interface through which a hardware
specific plugin could notify the core daemon about the existence of OOB
data. bluetoothd would then take care of setting the right flag when it
gets a IO capability request. This doesn't of course rule out the
possibility of having part of the work done in another process since the
plugin could simply export a service over D-Bus or talk to another D-Bus
service.
Johan
^ permalink raw reply
* Re: Possible regression with skb_clone() in 2.6.36
From: Gustavo F. Padovan @ 2010-09-15 18:42 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, netdev, linux-kernel, marcel, davem
In-Reply-To: <20100910194509.GC19693@vigoh>
Hi Mat,
* Gustavo F. Padovan <padovan@profusion.mobi> [2010-09-10 16:45:09 -0300]:
> Hi Mat,
>
> * Mat Martineau <mathewm@codeaurora.org> [2010-09-10 09:53:31 -0700]:
>
> >
> > Gustavo -
> >
> > I'm not sure why the streaming code used to work, but this does not
> > look like an skb_clone() problem. Your patch to remove the
> > skb_clone() call in l2cap_streaming_send() addresses the root cause of
> > this crash.
> >
> > On Wed, 8 Sep 2010, Gustavo F. Padovan wrote:
> >
> > > I've been experiencing some problems when running the L2CAP Streaming mode in
> > > 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> > > wasn't happening before, so I think we may have a regression here (I didn't
> > > find where yet). The crash log is below.
> > >
> > > The following patch does not fix the regression, but shows that removing the
> > > skb_clone() call from l2cap_streaming_send() we workaround the problem. The
> > > patch is good anyway because it saves memory and time.
> > >
> > > By now I have no idea on how to fix this.
> > >
> > > <snip>
> >
> > This has to do with the sk->sk_wmem_alloc accounting that controls the
> > amount of write buffer space used on the socket.
> >
> > When the L2CAP streaming mode socket segments its data, it allocates
> > memory using sock_alloc_send_skb() (via bt_skb_send_alloc()). Before
> > that allocation call returns, skb_set_owner_w() is called on the new
> > skb. This adds to sk->sk_wmem_alloc and sets skb->destructor so that
> > sk->sk_wmem_alloc is correctly updated when the skb is freed.
> >
> > When that skb is cloned, the clone is not "owned" by the write buffer.
> > The clone's destructor is set to NULL in __skb_clone(). The version
> > of l2cap_streaming_send() that runs out of memory is passing the
> > non-owned skb clone down to the HCI layer. The original skb (the one
> > that's "owned by w") is immediately freed, which adjusts
> > sk->sk_wmem_alloc back down - the socket thinks it has unlimited write
> > buffer space. As a result, bt_skb_send_alloc() never blocks waiting
> > for buffer space (or returns EAGAIN for nonblocking writes) and the
> > HCI send queue keeps growing.
>
> If the problem is what you are saying, add a skb_set_owner_w(skb, sk) on
> the cloned skb should solve the problem, but it doesn't. That's exactly
> what tcp_transmit_skb() does. Also that just appeared in 2.6.36, is was
> working fine before, i.e, we have a regression here.
I've run some other tests and what you said also fixes the problem for
Streaming Mode. If I use skb_set_owner_w() on the cloned skb, everything
works fine. But we still have the problem for ERTM as I described.
send() blocks wainting for memory. The regression is there yet.
:(
>
> >
> > This isn't a problem for the ERTM sends, because the original skbs are
> > kept in the ERTM tx queue until they are acked. Once they're acked,
> > the write buffer space is freed and additional skbs can be allocated.
>
> It affects ERTM as well, but in that case the kernel doesn't crash
> because ERTM block on sending trying to allocate memory. Then we are not
> able to receive any ack (everything stays queued in sk_backlog_queue as
> the sk is owned by the user) and ERTM stalls.
>
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [RFC] D-Bus API for out of band association model
From: jaikumar Ganesh @ 2010-09-15 17:13 UTC (permalink / raw)
To: Claudio Takahasi
Cc: Andrzej Kaczmarek, linux-bluetooth, par-gunnar.p.hjalmdahl
In-Reply-To: <AANLkTimm++uSFQmkKHF+vHzp=Kc0tYpzb+xqq=eG6jnW@mail.gmail.com>
Hi,
On Wed, Sep 15, 2010 at 6:30 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> On Wed, Sep 15, 2010 at 5:10 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> Hi Andrzej,
>>
>> On Wed, Sep 15, 2010, Andrzej Kaczmarek wrote:
>>> On behalf of ST-Ericsson SA, below is our proposal of API for out of band
>>> association model. To give you a bit more overview how this will be integrated
>>> into BlueZ:
>>>
>>> .RequestRemoteOobData should be called from hcid_dbus_request_io_cap to
>>> check if any data was exchange/retrieved from remote device. Returned data
>>> will be stored (if any) and used to reply with proper IO capabilities as well
>>> as to to return retrieved data. This will involve some changes in flow from
>>> io_capa_request onwards.
>>>
>>> Please let me know if you have any comments. Implementation will follow.
>>
>> I'd prefer to do this completely internally in bluetoothd through a
>> plugin. Do you see any reasons why not to do it that way? We still need
>> some UI to call CreatePairedDevice but a plugin that knows about local
>> platform specific OOB mechanisms (e.g. NFC) could provide the core
>> daemon with enough info to set the IO capabilities correctly and provide
>> the necessary OOB values.
>>
>> Johan
>> --
>
> Hi Andrzej,
>
> I did some testing with OOB last year.
> See my branch git://git.infradead.org/users/cktakahasi/bluez.git
> oob-displayyesno
>
> About the API changes. MAYBE, Hash and Randomizer could be only
> adapter properties.
> For the remote Hash and Randomizer still not clear to me what is the
> best way to allow external apps to set those values, but in my opinion
> BlueZ should not know the OOB mechanism, only the capability is
> enough.
[Resending, because the mail to linux-bluetooth bounced. Sorry if some
folks got it twice]
We started to work on this API too last week. Not complete yet to post
to the mailing list.
The approach we took was this:
a) Since OOB authentication is just another means of authentication
compared to Passkey, Pin entry,
we added an agent API (similar to the lines of other
authentication mechanisms) that will ask for the Out Of Band data.
b) We added an API to the adapter to get the local Out of Band Data
c) Currently, RegisterAgent is called to register with the
capabilities. Since OOB is part of the capabilities data structure, we
added OOB to agent structure which already has the capabilities.
d) We added an API variant of createPairedDevice which will be used
for OutOfBand Pairing. When the device agent is created, the OOB field
in agent is updated.
e) When a capability request comes from the remote side the agent OOB
field is checked. It will be set if the pairing is initiated locally
through d).
For incoming pairing requests if the Agent has OOB field set but
there is no device specific agent, we need to make an Agent API call
asking if
there is OOB data for this remote device.
We left it to the users of the API - regarding the OOB channel to use.
It can be NFC or any other trusted channel.
Comments ?
Regards,
Jaikumar
>
> Regards,
> Claudio
> --
> 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: [PATCH 00/10] Media API
From: Johan Hedberg @ 2010-09-15 13:35 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1284387337-18822-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, Sep 13, 2010, Luiz Augusto von Dentz wrote:
> Luiz Augusto von Dentz (10):
> Add media API documentation
> Add rule to enabling talking to org.bluez.MediaEndpoint
> Add option to enable/disable unix ipc via audio.conf
> Add support for media transport in gstreamer plugin
> Add simple-endpoint test script
> Add initial implementation of org.bluez.Media spec
> Introduce headset_get_inband
> Update a2dp transport delay when it changes
> Remove local cache for nrec and inband
> Add proper checks for MediaTransport.SetProperty
>
> Makefile.am | 6 +-
> audio/a2dp-codecs.h | 116 ++++++++
> audio/a2dp.c | 749 +++++++++++++++++++++++++++++++++++++++++--------
> audio/a2dp.h | 15 +
> audio/avdtp.c | 88 +++----
> audio/avdtp.h | 5 +-
> audio/gsta2dpsink.c | 33 ++-
> audio/gsta2dpsink.h | 1 +
> audio/gstavdtpsink.c | 609 +++++++++++++++++++++++++++++++++++++++-
> audio/gstavdtpsink.h | 6 +
> audio/headset.c | 10 +
> audio/headset.h | 1 +
> audio/main.c | 9 -
> audio/manager.c | 66 +++++
> audio/manager.h | 2 +
> audio/media.c | 689 +++++++++++++++++++++++++++++++++++++++++++++
> audio/media.h | 54 ++++
> audio/sink.c | 179 ++-----------
> audio/source.c | 174 ++----------
> audio/transport.c | 758 ++++++++++++++++++++++++++++++++++++++++++++++++++
> audio/transport.h | 36 +++
> audio/unix.c | 1 +
> doc/media-api.txt | 169 +++++++++++
> src/bluetooth.conf | 1 +
> test/simple-endpoint | 126 +++++++++
> 25 files changed, 3395 insertions(+), 508 deletions(-)
> create mode 100644 audio/a2dp-codecs.h
> create mode 100644 audio/media.c
> create mode 100644 audio/media.h
> create mode 100644 audio/transport.c
> create mode 100644 audio/transport.h
> create mode 100644 doc/media-api.txt
> create mode 100755 test/simple-endpoint
All patches have been pushed upstream now (with the few minor changes
that we discussed). Next step: talk to PulseAudio guys and get this
merged there too.
Johan
^ permalink raw reply
* Re: [RFC] D-Bus API for out of band association model
From: Claudio Takahasi @ 2010-09-15 13:30 UTC (permalink / raw)
To: Andrzej Kaczmarek, linux-bluetooth, par-gunnar.p.hjalmdahl
In-Reply-To: <20100915081047.GA15065@jh-x301>
On Wed, Sep 15, 2010 at 5:10 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Andrzej,
>
> On Wed, Sep 15, 2010, Andrzej Kaczmarek wrote:
>> On behalf of ST-Ericsson SA, below is our proposal of API for out of band
>> association model. To give you a bit more overview how this will be integrated
>> into BlueZ:
>>
>> .RequestRemoteOobData should be called from hcid_dbus_request_io_cap to
>> check if any data was exchange/retrieved from remote device. Returned data
>> will be stored (if any) and used to reply with proper IO capabilities as well
>> as to to return retrieved data. This will involve some changes in flow from
>> io_capa_request onwards.
>>
>> Please let me know if you have any comments. Implementation will follow.
>
> I'd prefer to do this completely internally in bluetoothd through a
> plugin. Do you see any reasons why not to do it that way? We still need
> some UI to call CreatePairedDevice but a plugin that knows about local
> platform specific OOB mechanisms (e.g. NFC) could provide the core
> daemon with enough info to set the IO capabilities correctly and provide
> the necessary OOB values.
>
> Johan
> --
Hi Andrzej,
I did some testing with OOB last year.
See my branch git://git.infradead.org/users/cktakahasi/bluez.git
oob-displayyesno
About the API changes. MAYBE, Hash and Randomizer could be only
adapter properties.
For the remote Hash and Randomizer still not clear to me what is the
best way to allow external apps to set those values, but in my opinion
BlueZ should not know the OOB mechanism, only the capability is
enough.
Regards,
Claudio
^ permalink raw reply
* Re: [PATCH] Add handling of TITLE contact's field in vCard
From: Johan Hedberg @ 2010-09-15 12:49 UTC (permalink / raw)
To: Rafał Michalski; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikjKRY_ZBjNeyJrsSObb4qVNfNgdpdUzghmYrD8@mail.gmail.com>
Hi Rafal,
On Wed, Sep 15, 2010, Rafał Michalski wrote:
> From: Rafal Michalski <michalski.raf@gmail.com>
> Date: Wed, 15 Sep 2010 09:16:11 +0200
> Subject: [PATCH] Add handling of TITLE contact's field in vCard
>
> After pulling contacts this field wasn't presented in downloaded vCard
> structure in spite of that it existed (not empty). Now it shows downloaded
> TITLE field (using database query).
> ---
> plugins/phonebook-tracker.c | 23 ++++++++++++-----------
> plugins/vcard.c | 4 ++++
> plugins/vcard.h | 1 +
> 3 files changed, 17 insertions(+), 11 deletions(-)
Thanks for the patch. It's now upstream.
Johan
^ permalink raw reply
* [PATCHv4 3/3] Bluetooth: check L2CAP length in first ACL fragment
From: Emeltchenko Andrei @ 2010-09-15 11:28 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284550124-31201-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Current Bluetooth code assembles fragments of big L2CAP packets
in l2cap_recv_acldata and then checks allowed L2CAP size in
assemled L2CAP packet (pi->imtu < skb->len).
The patch moves allowed L2CAP size check to the early stage when
we receive the first fragment of L2CAP packet. We do not need to
reserve and keep L2CAP fragments for bad packets.
Updated version after comments from Mat Martineau <mathewm@codeaurora.org>
and Gustavo Padovan <padovan@profusion.mobi>.
Trace below is received when using stress tools sending big
fragmented L2CAP packets.
...
[ 1712.798492] swapper: page allocation failure. order:4, mode:0x4020
[ 1712.804809] [<c0031870>] (unwind_backtrace+0x0/0xdc) from [<c00a1f70>]
(__alloc_pages_nodemask+0x4)
[ 1712.814666] [<c00a1f70>] (__alloc_pages_nodemask+0x47c/0x4d4) from
[<c00a1fd8>] (__get_free_pages+)
[ 1712.824645] [<c00a1fd8>] (__get_free_pages+0x10/0x3c) from [<c026eb5c>]
(__alloc_skb+0x4c/0xfc)
[ 1712.833465] [<c026eb5c>] (__alloc_skb+0x4c/0xfc) from [<bf28c738>]
(l2cap_recv_acldata+0xf0/0x1f8 )
[ 1712.843322] [<bf28c738>] (l2cap_recv_acldata+0xf0/0x1f8 [l2cap]) from
[<bf0094ac>] (hci_rx_task+0x)
...
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index ce8f5e4..3aa2e9c 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4654,6 +4654,8 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
if (flags & ACL_START) {
struct l2cap_hdr *hdr;
+ struct sock *sk;
+ u16 cid;
int len;
if (conn->rx_len) {
@@ -4673,6 +4675,7 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
hdr = (struct l2cap_hdr *) skb->data;
len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
+ cid = __le16_to_cpu(hdr->cid);
if (len == skb->len) {
/* Complete frame received */
@@ -4689,6 +4692,19 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
goto drop;
}
+ sk = l2cap_get_chan_by_scid(&conn->chan_list, cid);
+
+ if (sk && l2cap_pi(sk)->imtu < len - L2CAP_HDR_SIZE) {
+ BT_ERR("Frame exceeding recv MTU (len %d, MTU %d)",
+ len, l2cap_pi(sk)->imtu);
+ bh_unlock_sock(sk);
+ l2cap_conn_unreliable(conn, ECOMM);
+ goto drop;
+ }
+
+ if (sk)
+ bh_unlock_sock(sk);
+
/* Allocate skb for the complete frame (with header) */
conn->rx_skb = bt_skb_alloc(len, GFP_ATOMIC);
if (!conn->rx_skb)
--
1.7.0.4
^ permalink raw reply related
* [PATCHv4 2/3] Bluetooth: check for l2cap header in start fragment
From: Emeltchenko Andrei @ 2010-09-15 11:28 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284550124-31201-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] page 36 mentioned
"Note: Start Fragments always begin with the Basic L2CAP header
of a PDU."
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 9fad312..ce8f5e4 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4664,7 +4664,8 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
l2cap_conn_unreliable(conn, ECOMM);
}
- if (skb->len < 2) {
+ /* Start fragment always begin with Basic L2CAP header */
+ if (skb->len < L2CAP_HDR_SIZE) {
BT_ERR("Frame is too short (len %d)", skb->len);
l2cap_conn_unreliable(conn, ECOMM);
goto drop;
--
1.7.0.4
^ permalink raw reply related
* [PATCHv4 1/3] Bluetooth: fix MTU L2CAP configuration parameter
From: Emeltchenko Andrei @ 2010-09-15 11:28 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284550124-31201-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
When receiving L2CAP negative configuration response with respect
to MTU parameter we modify wrong field. MTU here means proposed
value of MTU that the remote device intends to transmit. So for local
L2CAP socket it is pi->imtu.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/l2cap.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index c784703..9fad312 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2771,10 +2771,10 @@ static int l2cap_parse_conf_rsp(struct sock *sk, void *rsp, int len, void *data,
case L2CAP_CONF_MTU:
if (val < L2CAP_DEFAULT_MIN_MTU) {
*result = L2CAP_CONF_UNACCEPT;
- pi->omtu = L2CAP_DEFAULT_MIN_MTU;
+ pi->imtu = L2CAP_DEFAULT_MIN_MTU;
} else
- pi->omtu = val;
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->omtu);
+ pi->imtu = val;
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->imtu);
break;
case L2CAP_CONF_FLUSH_TO:
--
1.7.0.4
^ permalink raw reply related
* [PATCHv4 0/3] Bluetooth: L2CAP robustness fixes
From: Emeltchenko Andrei @ 2010-09-15 11:28 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Fixes increase L2CAP robustness to DOS attacks to BT stack.
Updated version after comments from Mat Martineau <mathewm@codeaurora.org>
and Gustavo Padovan <padovan@profusion.mobi>.
Andrei Emeltchenko (3):
Bluetooth: fix MTU L2CAP configuration parameter
Bluetooth: check for l2cap header in start fragment
Bluetooth: check L2CAP length in first ACL fragment
net/bluetooth/l2cap.c | 25 +++++++++++++++++++++----
1 files changed, 21 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCHv3 3/3] Bluetooth: check L2CAP length in first ACL fragment
From: Andrei Emeltchenko @ 2010-09-15 11:17 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20100914182147.GB5398@vigoh>
Hi Gustavo,
On Tue, Sep 14, 2010 at 9:21 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Andrei,
>
> * Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-09-09 10:43:01 +0300]:
>
>> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>>
>> Current Bluetooth code assembles fragments of big L2CAP packets
>> in l2cap_recv_acldata and then checks allowed L2CAP size in
>> assemled L2CAP packet (pi->imtu < skb->len).
>>
>> The patch moves allowed L2CAP size check to the early stage when
>> we receive the first fragment of L2CAP packet. We do not need to
>> reserve and keep L2CAP fragments for bad packets.
>>
>> Updated version after comments from Mat Martineau <mathewm@codeaurora.org>
>>
>> Trace below is received when using stress tools sending big
>> fragmented L2CAP packets.
>> ...
>> [ 1712.798492] swapper: page allocation failure. order:4, mode:0x4020
>> [ 1712.804809] [<c0031870>] (unwind_backtrace+0x0/0xdc) from [<c00a1f70>]
>> (__alloc_pages_nodemask+0x4)
>> [ 1712.814666] [<c00a1f70>] (__alloc_pages_nodemask+0x47c/0x4d4) from
>> [<c00a1fd8>] (__get_free_pages+)
>> [ 1712.824645] [<c00a1fd8>] (__get_free_pages+0x10/0x3c) from [<c026eb5c>]
>> (__alloc_skb+0x4c/0xfc)
>> [ 1712.833465] [<c026eb5c>] (__alloc_skb+0x4c/0xfc) from [<bf28c738>]
>> (l2cap_recv_acldata+0xf0/0x1f8 )
>> [ 1712.843322] [<bf28c738>] (l2cap_recv_acldata+0xf0/0x1f8 [l2cap]) from
>> [<bf0094ac>] (hci_rx_task+0x)
>> ...
>>
>> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>> ---
>> net/bluetooth/l2cap.c | 17 +++++++++++++++++
>> 1 files changed, 17 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index ce8f5e4..c95fbd8 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -4654,6 +4654,8 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
>>
>> if (flags & ACL_START) {
>> struct l2cap_hdr *hdr;
>> + struct sock *sk;
>> + u16 cid;
>> int len;
>>
>> if (conn->rx_len) {
>> @@ -4673,6 +4675,7 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
>>
>> hdr = (struct l2cap_hdr *) skb->data;
>> len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
>> + cid = __le16_to_cpu(hdr->cid);
>>
>> if (len == skb->len) {
>> /* Complete frame received */
>> @@ -4689,6 +4692,20 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
>> goto drop;
>> }
>>
>> + sk = l2cap_get_chan_by_scid(&conn->chan_list, cid);
>> +
>> + if (sk && l2cap_pi(sk)->imtu < len) {
>> + BT_ERR("Frame exceeding recv MTU (len %d, MTU %d)",
>> + len, l2cap_pi(sk)->imtu);
>
> I think you have to check if the imtu is less than (len -
> L2CAP_HDR_SIZE) because we don't count the header in the MTU.
>
>> + conn->rx_len = 0; /* needed? */
>
> It's not needed. rx_len is always zero here.
>
Thanks, I will fix those issues.
Regards,
Andrei
^ permalink raw reply
* Re: [PATCH] Bluetooth: remove extra newline from debug output
From: Ville Tervo @ 2010-09-15 10:29 UTC (permalink / raw)
To: ext Emeltchenko Andrei; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1283952413-22791-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Wed, Sep 08, 2010 at 03:26:53PM +0200, ext Emeltchenko Andrei wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/rfcomm/core.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index 16b79f3..a7e4f2d 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -1698,7 +1698,7 @@ static int rfcomm_recv_frame(struct rfcomm_session *s, struct sk_buff *skb)
> break;
>
> default:
> - BT_ERR("Unknown packet type 0x%02x\n", type);
> + BT_ERR("Unknown packet type 0x%02x", type);
> break;
> }
> kfree_skb(skb);
--
Ville
^ permalink raw reply
* [PATCH] Add handling of TITLE contact's field in vCard
From: Rafał Michalski @ 2010-09-15 10:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Add-handling-of-TITLE-contact-s-field-in-vCard.patch --]
[-- Type: text/x-patch, Size: 5142 bytes --]
From fffde75fb874b9db4afbb51dc0d8d7a72ed04ef0 Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Wed, 15 Sep 2010 09:16:11 +0200
Subject: [PATCH] Add handling of TITLE contact's field in vCard
After pulling contacts this field wasn't presented in downloaded vCard
structure in spite of that it existed (not empty). Now it shows downloaded
TITLE field (using database query).
---
| 23 ++++++++++++-----------
| 4 ++++
| 1 +
3 files changed, 17 insertions(+), 11 deletions(-)
--git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 43c2e28..3161927 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -43,16 +43,16 @@
#define TRACKER_RESOURCES_INTERFACE "org.freedesktop.Tracker1.Resources"
#define TRACKER_DEFAULT_CONTACT_ME "http://www.semanticdesktop.org/ontologies/2007/03/22/nco#default-contact-me"
-#define CONTACTS_ID_COL 36
-#define PULL_QUERY_COL_AMOUNT 37
+#define CONTACTS_ID_COL 37
+#define PULL_QUERY_COL_AMOUNT 38
#define COL_HOME_NUMBER 0
#define COL_HOME_EMAIL 7
#define COL_WORK_NUMBER 8
#define COL_FAX_NUMBER 16
#define COL_WORK_EMAIL 17
-#define COL_DATE 33
-#define COL_SENT 34
-#define COL_ANSWERED 35
+#define COL_DATE 34
+#define COL_SENT 35
+#define COL_ANSWERED 36
#define ADDR_FIELD_AMOUNT 7
#define CONTACTS_QUERY_ALL \
@@ -68,7 +68,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "\"NOTACALL\" \"false\" \"false\" ?c " \
+ "nco:title(?a) \"NOTACALL\" \"false\" \"false\" ?c " \
"WHERE { " \
"?c a nco:PersonContact . " \
"OPTIONAL { ?c nco:hasPhoneNumber ?h . \
@@ -119,7 +119,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nmo:receivedDate(?call) " \
+ "nco:title(?a) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
"?call a nmo:Call ; " \
@@ -171,7 +171,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nmo:receivedDate(?call) " \
+ "nco:title(?a) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
"?call a nmo:Call ; " \
@@ -223,7 +223,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nmo:receivedDate(?call) " \
+ "nco:title(?a) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
"?call a nmo:Call ; " \
@@ -273,7 +273,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nmo:receivedDate(?call) " \
+ "nco:title(?a) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
"{ " \
@@ -349,7 +349,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(<%s>) " \
- "\"NOTACALL\" \"false\" \"false\" <%s> " \
+ "nco:title(?a) \"NOTACALL\" \"false\" \"false\" <%s> " \
"WHERE { " \
"<%s> a nco:Contact . " \
"OPTIONAL { <%s> nco:hasPhoneNumber ?h . \
@@ -865,6 +865,7 @@ add_entry:
contact->department = g_strdup(reply[23]);
contact->role = g_strdup(reply[24]);
contact->uid = g_strdup(reply[32]);
+ contact->title = g_strdup(reply[33]);
set_call_type(contact, reply[COL_DATE], reply[COL_SENT],
reply[COL_ANSWERED]);
--git a/plugins/vcard.c b/plugins/vcard.c
index e277ced..bc22177 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -539,6 +539,9 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
if (filter & FILTER_ROLE)
vcard_printf_tag(vcards, format, "ROLE", NULL, contact->role);
+ if (filter & FILTER_TITLE)
+ vcard_printf_tag(vcards, format, "TITLE", NULL, contact->title);
+
if (filter & FILTER_X_IRMC_CALL_DATETIME)
vcard_printf_datetime(vcards, contact);
@@ -597,6 +600,7 @@ void phonebook_contact_free(struct phonebook_contact *contact)
g_free(contact->company);
g_free(contact->department);
g_free(contact->role);
+ g_free(contact->title);
g_free(contact->datetime);
g_free(contact);
}
--git a/plugins/vcard.h b/plugins/vcard.h
index 0ed51b9..d1c225e 100644
--- a/plugins/vcard.h
+++ b/plugins/vcard.h
@@ -79,6 +79,7 @@ struct phonebook_contact {
char *company;
char *department;
char *role;
+ char *title;
char *datetime;
int calltype;
};
--
1.6.3.3
^ permalink raw reply related
* Re: Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900
From: Par-Gunnar Hjalmdahl @ 2010-09-15 10:14 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Alan Cox, linus.walleij, linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTinctyN3d4o8vq-8pAH67FaoAXOiX3=kobWkNTms@mail.gmail.com>
Hi Pavan,
Thanks for your comments and sorry for me taking time to answer your mail.
See below for answers.
>
> ok bit more of information ....
> We don;t use the hciattach, instead we have our own daemon which opens
> up the UART and installs the line discipline (not N_HCI, but similar
> one called N_SHARED) when the hciconfig hci0 up happens or even when
> /dev/radio0 (FM V4L2 device) happens or when generic GPS character
> device (/dev/tigps) happens...
:-) We also have our own user space application for opening the UART
and setting the line disc since we don't want to depend completely on
hciattach, which contains more than we need, and also misses stuff
that we want to do towards our specific controller. I just used it as
an example since that is the common BlueZ way to open the Bluetooth
transport.
>
> There is non-mailine driver which gets modified to get into mainline @
> http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=drivers/misc/ti-
> st;h=028ff4a739d7b59b94d0c613b5ef510ff338b65d;hb=refs/heads/p-android-
> omap-2.6.32
>
> feel free to have a look at it...
> Yes our solution too works with BlueZ and non-exactly a MFD driver but
> it is a simple platform device driver .. by looks of things the driver
> can run as is for your chip too .. (except for the firmware search and
> download part .. may be...).
Your code is in a lot of ways similar to ours (which is not so strange
since you address the same market with your chip as we do with ours),
but there are several differences that would at least for now make it
impossible for us to use your driver. When we post our first patches
(which will hopefully be in a few days) you can see for yourself. But
I don't think there is a simple way for us to re-use your driver.
>
> and note when we would want to support SPI transport for the same, we
> plan a SPI-TTY driver ('ala usb-serial) where-in we can install this
> N_TI_WL line discipline on that /dev/ttySPI0 device, and the SPI
> related stuff to be handled by the spi-tty.c which registers itself as
> a tty_device and a tty_driver ....
Our SPI usage will be a bit different, where we don't use TTY for our
driver. We will use the SPI directly instead.
>
> regards,
> Pavan
>
> On Fri, Sep 10, 2010 at 2:07 PM, Pavan Savoy <pavan_savoy@sify.com>
> wrote:
> > Can you directly make use of the ti-st driver which is currently
> staged?
> > It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising
> !!!
:-) As I said earlier this is quite natural since both TI and
ST-Ericsson address the same market segments.
/P-G
^ permalink raw reply
* Re: [PATCH] Bluetooth: Don't clear the blacklist when closing the HCI device
From: Ville Tervo @ 2010-09-15 9:49 UTC (permalink / raw)
To: ext johan.hedberg@gmail.com
Cc: linux-bluetooth@vger.kernel.org,
Hedberg Johan (Nokia-MS/Helsinki)
In-Reply-To: <1284017559-13510-1-git-send-email-johan.hedberg@gmail.com>
On Thu, Sep 09, 2010 at 09:32:39AM +0200, ext johan.hedberg@gmail.com wrote:
> From: Johan Hedberg <johan.hedberg@nokia.com>
>
> Clearing the blacklist in hci_dev_do_close() would mean that user space
> needs to do extra work to re-block devices after a DEVDOWN-DEVUP cycle.
> This patch removes the clearing of the blacklist in this case and
> thereby saves user space from the extra work.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/hci_core.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index c52f091..bc2a052 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -562,7 +562,6 @@ static int hci_dev_do_close(struct hci_dev *hdev)
> hci_dev_lock_bh(hdev);
> inquiry_cache_flush(hdev);
> hci_conn_hash_flush(hdev);
> - hci_blacklist_clear(hdev);
> hci_dev_unlock_bh(hdev);
>
> hci_notify(hdev, HCI_DEV_DOWN);
> --
> 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: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Waldemar.Rymarkiewicz @ 2010-09-15 9:18 UTC (permalink / raw)
To: marcel, suraj; +Cc: Suraj.Sumangala, linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1284522264.2405.89.camel@localhost.localdomain>
Hi Marcel,=20
>if we talk about the SAP server role found in a mobile phone,=20
>then that support clearly needs to interact with the telephony=20
>stack. Since when SAP is active the telephony stack needs to=20
>be suspended and all SIM transaction being forwarded.
I agree, but a telephony stack needs to care about its state when SAP is ac=
tive. Not all linux based mobile platforms use ofono.
>Currently I would be thinking that the SAP implementation=20
>should be done inside oFono actually. Since then you have=20
>direct access to the hardware. The D-Bus approach just doesn't=20
>sound correct to me. I could be of course wrong, but I can't=20
>wrap my mind around on how you can make this work.
I assume that ofono should handle sap transactions (as it's kind of hardwar=
e abstraction for bluez) and expose SAP APDU interfaces as i.e Nokia did fo=
r sap transactions in spec (http://www.wirelessmodemapi.com/), and not impl=
ement sap profile itself. Again, not all use ofono as telephony stack.
Sorry, I don't know ofono well. What's the interface between ofono and blue=
z?=20
>Even with file descriptor passing this doesn't look like the=20
>right approach. If we need a hardware abstraction than we=20
>either use oFono or we have to create some SAP hardware access=20
>abstraction.
I agree with this too. I prefere to have a sap implementation as bluez plug=
in, but we need to define api for sim operations which could be implemented=
in ofono or other proprietary stacks. I guess dbus was intended to be kind=
of hw abstraction api.
Some time ago Claudio sent proposal implementation of sap server where he d=
efined api for a driver to sim.
Regards,
/Waldek=
^ permalink raw reply
* RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Nicolas GUILBAUD @ 2010-09-15 8:56 UTC (permalink / raw)
To: Suraj Sumangala
Cc: Suraj Sumangala, Marcel Holtmann, linux-bluetooth,
Jothikumar Mothilal
In-Reply-To: <4C9082C8.9030502@Atheros.com>
>-----Message d'origine-----
>De=A0: linux-bluetooth-owner@vger.kernel.org =
[mailto:linux-bluetooth->owner@vger.kernel.org] De la part de Suraj =
Sumangala
>Envoy=E9=A0: mercredi 15 septembre 2010 10:25
>=C0=A0: Nicolas GUILBAUD
>Cc=A0: Suraj Sumangala; Marcel Holtmann; =
linux-bluetooth@vger.kernel.org; >Jothikumar Mothilal
>Objet=A0: Re: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description
>
>Hi Nicolas,
>
>On 9/15/2010 1:02 PM, Nicolas GUILBAUD wrote:
>> Hello Marcel and Suraj,
>>
>> I agree with Marcel, because in standard Mobile phone implementation, =
the >SIM card is directly connected to the Modem. To access the SIM =
card, AT >command (or proprietary commands) are needed, oFono implements =
both of them >to access SIM card in Modem side, but in my understanding =
there is no >possibilities to disconnect modem (in oFono) due to SIM =
SAP.
>>
>> In the case where SIM card is connected to the Application processor =
>(Linux side), it's missing the SIM stack (APDU server...). I don't find =
any >SIM implementation in Linux, may be we have to specify it.
>>
>Other than transferring APDUs, SAP profile also specifies operations on =
>the SIM cards like SIM Reset, SIM power on/off, Getting Card reader=20
>status etc.
>
>How do we do these operations case of mobile phones?
There are specific interfaces, you can find example of interface in =
Nokia Wireless Open API (uicc_fp.pdf) in =
http://www.wirelessmodemapi.com/, register is free.
SIM reset is an OFF command following by ON command (ATR comes with ON), =
card status is a local information...=20
Best Regards,
Nicolas.
^ permalink raw reply
* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Suraj Sumangala @ 2010-09-15 8:24 UTC (permalink / raw)
To: Nicolas GUILBAUD
Cc: Suraj Sumangala, Marcel Holtmann, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <A9AC1023FCA4654D92AC24C2A8F6A09201A2B923@renesas4bis.renesas-rdf.local>
Hi Nicolas,
On 9/15/2010 1:02 PM, Nicolas GUILBAUD wrote:
> Hello Marcel and Suraj,
>
> I agree with Marcel, because in standard Mobile phone implementation, the SIM card is directly connected to the Modem. To access the SIM card, AT command (or proprietary commands) are needed, oFono implements both of them to access SIM card in Modem side, but in my understanding there is no possibilities to disconnect modem (in oFono) due to SIM SAP.
>
> In the case where SIM card is connected to the Application processor (Linux side), it's missing the SIM stack (APDU server...). I don't find any SIM implementation in Linux, may be we have to specify it.
>
Other than transferring APDUs, SAP profile also specifies operations on
the SIM cards like SIM Reset, SIM power on/off, Getting Card reader
status etc.
How do we do these operations case of mobile phones?
>
> Best Regards,
>
> Nicolas.
Regards
Suraj
^ permalink raw reply
* Re: [RFC] D-Bus API for out of band association model
From: Johan Hedberg @ 2010-09-15 8:10 UTC (permalink / raw)
To: Andrzej Kaczmarek; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl
In-Reply-To: <1284537527-22783-1-git-send-email-andrzej.kaczmarek@tieto.com>
Hi Andrzej,
On Wed, Sep 15, 2010, Andrzej Kaczmarek wrote:
> On behalf of ST-Ericsson SA, below is our proposal of API for out of band
> association model. To give you a bit more overview how this will be integrated
> into BlueZ:
>
> .RequestRemoteOobData should be called from hcid_dbus_request_io_cap to
> check if any data was exchange/retrieved from remote device. Returned data
> will be stored (if any) and used to reply with proper IO capabilities as well
> as to to return retrieved data. This will involve some changes in flow from
> io_capa_request onwards.
>
> Please let me know if you have any comments. Implementation will follow.
I'd prefer to do this completely internally in bluetoothd through a
plugin. Do you see any reasons why not to do it that way? We still need
some UI to call CreatePairedDevice but a plugin that knows about local
platform specific OOB mechanisms (e.g. NFC) could provide the core
daemon with enough info to set the IO capabilities correctly and provide
the necessary OOB values.
Johan
^ permalink raw reply
* [RFC] D-Bus API for out of band association model
From: Andrzej Kaczmarek @ 2010-09-15 7:58 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, Andrzej Kaczmarek
Hi,
On behalf of ST-Ericsson SA, below is our proposal of API for out of band
association model. To give you a bit more overview how this will be integrated
into BlueZ:
.RequestRemoteOobData should be called from hcid_dbus_request_io_cap to
check if any data was exchange/retrieved from remote device. Returned data
will be stored (if any) and used to reply with proper IO capabilities as well
as to to return retrieved data. This will involve some changes in flow from
io_capa_request onwards.
Please let me know if you have any comments. Implementation will follow.
BR,
Andrzej
---
doc/adapter-api.txt | 14 ++++++++++++++
doc/agent-api.txt | 14 ++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
index 6098c76..0dd628e 100644
--- a/doc/adapter-api.txt
+++ b/doc/adapter-api.txt
@@ -5,6 +5,7 @@ Copyright (C) 2004-2010 Marcel Holtmann <marcel@holtmann.org>
Copyright (C) 2005-2006 Johan Hedberg <johan.hedberg@nokia.com>
Copyright (C) 2005-2006 Claudio Takahasi <claudio.takahasi@indt.org.br>
Copyright (C) 2006-2007 Luiz von Dentz <luiz.dentz@indt.org.br>
+Copyright (C) 2010 ST-Ericsson SA <andrzej.kaczmarek@tieto.com>
Adapter hierarchy
@@ -173,6 +174,19 @@ Methods dict GetProperties()
Possible errors: org.bluez.Error.DoesNotExist
+ struct{
+ array{byte}, array{byte}
+ } GetLocalOobData()
+
+ Retrieves current C and R values used for out-of-band
+ bonding association model.
+
+ The return value is struct containing two arrays of
+ bytes, C and R values retrieved from local device.
+
+ Possible errors: org.bluez.Error.InProgress
+ org.bluez.Error.Failed
+
Signals PropertyChanged(string name, variant value)
This signal indicates a changed value of the given
diff --git a/doc/agent-api.txt b/doc/agent-api.txt
index d8d35c0..323ccf1 100644
--- a/doc/agent-api.txt
+++ b/doc/agent-api.txt
@@ -3,6 +3,7 @@ BlueZ D-Bus Agent API description
Copyright (C) 2004-2010 Marcel Holtmann <marcel@holtmann.org>
Copyright (C) 2005-2006 Johan Hedberg <johan.hedberg@nokia.com>
+Copyright (C) 2010 ST-Ericsson SA <andrzej.kaczmarek@tieto.com>
Agent hierarchy
@@ -68,6 +69,19 @@ Methods void Release()
Possible errors: org.bluez.Error.Rejected
org.bluez.Error.Canceled
+ struct{
+ array{byte}, array{byte}
+ } RequestRemoteOobData(object device)
+
+ This method gets called when the service daemon
+ needs out-of-band data for an authentication.
+
+ The return value should be struct containing two
+ arrays of bytes, C and R values retrieved from
+ remote device.
+
+ Possible errors: org.bluez.Error.NoData
+
void Authorize(object device, string uuid)
This method gets called when the service daemon
--
1.7.0.4
^ permalink raw reply related
* RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Nicolas GUILBAUD @ 2010-09-15 7:32 UTC (permalink / raw)
To: Suraj Sumangala, Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth, Jothikumar Mothilal
In-Reply-To: <4C906430.90900@Atheros.com>
Hello Marcel and Suraj,
-----Message d'origine-----
De=A0: linux-bluetooth-owner@vger.kernel.org =
[mailto:linux-bluetooth-owner@vger.kernel.org] De la part de Suraj =
Sumangala
Envoy=E9=A0: mercredi 15 septembre 2010 08:14
=C0=A0: Marcel Holtmann
Cc=A0: Suraj Sumangala; linux-bluetooth@vger.kernel.org; Jothikumar =
Mothilal
Objet=A0: Re: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description
>Hi Marcel,
>
>On 9/15/2010 9:14 AM, Marcel Holtmann wrote:
>> Hi Suraj,
>>
>>>
>>> I would really appreciate if you can give me any idea about working
>>> around the above mentioned issues.
>>
>> if we talk about the SAP server role found in a mobile phone, then =
that
>> support clearly needs to interact with the telephony stack. Since =
when
>> SAP is active the telephony stack needs to be suspended and all SIM
>> transaction being forwarded.
>>
>> Currently I would be thinking that the SAP implementation should be =
done
>> inside oFono actually. Since then you have direct access to the
>> hardware. The D-Bus approach just doesn't sound correct to me. I =
could
>> be of course wrong, but I can't wrap my mind around on how you can =
make
>> this work.
>>
>> Even with file descriptor passing this doesn't look like the right
>> approach. If we need a hardware abstraction than we either use oFono =
or
>> we have to create some SAP hardware access abstraction.
>
>The advantage I thought d-bus has would be the generic interface it=20
>could provide. But, if we have a system with direct access to the Sim=20
>access hardware, D-bus could possibly become a bottleneck.
>
>I would really appreciate if others who have worked with Sim Access and =
>OFono can give their comments.
>
>Also, please share some information on regarding the SIM reader=20
>implementation in linux based systems.
>
>>
>> The SAP client role found a carkit is obviously a different story.
>>
>> Regards
>>
>> Marcel
>>
>>
>Regards
>Suraj
I agree with Marcel, because in standard Mobile phone implementation, =
the SIM card is directly connected to the Modem. To access the SIM card, =
AT command (or proprietary commands) are needed, oFono implements both =
of them to access SIM card in Modem side, but in my understanding there =
is no possibilities to disconnect modem (in oFono) due to SIM SAP.
In the case where SIM card is connected to the Application processor =
(Linux side), it's missing the SIM stack (APDU server...). I don't find =
any SIM implementation in Linux, may be we have to specify it.=20
Best Regards,
Nicolas.
^ 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