pull request: bluetooth-2.6 2010-11-22

Hi John,

Following batch is intended to 2.6.37, it includes a very trivial return
err fix from myself and an remote name request fix from Johan Hedberg.
This fix move the remote name request (during the connection creation
process) to the kernelspace. In addition we have removed this operation
from BlueZ in userspace. Quoting part of Johan's patch which already
explain the change:

   "So far userspace has been responsible for this extra name request but
    tighter control is needed in order not to flood Bluetooth controllers
    with two many commands during connection creation. It has been shown
    that some controllers simply fail to function correctly if they get too
    many (almost) simultaneous commands during connection creation. The
    simplest way to acheive better control of these commands is to move
    their sending completely to the kernel side."

As side effect, we have a clean up patch in preparation to this fix.

Please pull, or let me know any problems you find here. Thanks.


The following changes since commit 3bf30b56c4f0a1c4fae34050b7db4527c92891e8:

  ath9k_htc: Avoid setting QoS control for non-QoS frames (2010-11-18 13:17:47 -0500)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master

Gustavo F. Padovan (1):
      Bluetooth: Fix not returning proper error in SCO

Johan Hedberg (3):
      Bluetooth: Simplify remote features callback function logic
      Bluetooth: Create a unified authentication request function
      Bluetooth: Automate remote name requests

 net/bluetooth/hci_event.c |  153 ++++++++++++++++++++++++++++++++-------------
 net/bluetooth/sco.c       |    6 +-
 2 files changed, 112 insertions(+), 47 deletions(-)

-- 
Gustavo F. Padovan
http://profusion.mobi

On Mon, Nov 22, 2010 at 04:14:11PM -0200, Gustavo F. Padovan wrote:

Hi John,

Following batch is intended to 2.6.37, it includes a very trivial return
err fix from myself and an remote name request fix from Johan Hedberg.
This fix move the remote name request (during the connection creation
process) to the kernelspace. In addition we have removed this operation
from BlueZ in userspace. Quoting part of Johan's patch which already
explain the change:

   "So far userspace has been responsible for this extra name request but
    tighter control is needed in order not to flood Bluetooth controllers
    with two many commands during connection creation. It has been shown
    that some controllers simply fail to function correctly if they get too
    many (almost) simultaneous commands during connection creation. The
    simplest way to acheive better control of these commands is to move
    their sending completely to the kernel side."

As side effect, we have a clean up patch in preparation to this fix.

Please pull, or let me know any problems you find here. Thanks.

The return code fix seems reasonable -- small and obvious, etc.

The other fixes are larger than I would like to see.  What is the
effect of the bug?  Does the Bluetooth controller stop completely?
Does it cause a crash?

Is this a newly-introduced bug?  Or one that has been around for
a while?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

* John W. Linville [off-list ref] [2010-11-22 14:30:30 -0500]:

On Mon, Nov 22, 2010 at 04:14:11PM -0200, Gustavo F. Padovan wrote:

quoted

Hi John,

Following batch is intended to 2.6.37, it includes a very trivial return
err fix from myself and an remote name request fix from Johan Hedberg.
This fix move the remote name request (during the connection creation
process) to the kernelspace. In addition we have removed this operation
from BlueZ in userspace. Quoting part of Johan's patch which already
explain the change:

   "So far userspace has been responsible for this extra name request but
    tighter control is needed in order not to flood Bluetooth controllers
    with two many commands during connection creation. It has been shown
    that some controllers simply fail to function correctly if they get too
    many (almost) simultaneous commands during connection creation. The
    simplest way to acheive better control of these commands is to move
    their sending completely to the kernel side."

As side effect, we have a clean up patch in preparation to this fix.

Please pull, or let me know any problems you find here. Thanks.

The return code fix seems reasonable -- small and obvious, etc.

The other fixes are larger than I would like to see.  What is the
effect of the bug?  Does the Bluetooth controller stop completely?
Does it cause a crash?

Is this a newly-introduced bug?  Or one that has been around for
a while?

No, it is not serious like that. By not having this patch we won't have
the remote name request command during connection setup, The remote name
request was done by bluetoothd, but we already removed it from
userspace. It is not a really big problem once we also cache the remote
devices names in bluetoothd.
So I'm seeing no way to convince you tou pull this patch (actually I'm
now also covinced to queue this to bluetooth-next).  I'll sent a new
pull request soon, after wait some time for new patches.

-- 
Gustavo F. Padovan
http://profusion.mobi

Hi,

On Mon, Nov 22, 2010, Gustavo F. Padovan wrote:

quoted

The other fixes are larger than I would like to see.  What is the
effect of the bug?  Does the Bluetooth controller stop completely?
Does it cause a crash?

Is this a newly-introduced bug?  Or one that has been around for
a while?

No, it is not serious like that. By not having this patch we won't have
the remote name request command during connection setup, The remote name
request was done by bluetoothd, but we already removed it from
userspace. It is not a really big problem once we also cache the remote
devices names in bluetoothd.
So I'm seeing no way to convince you tou pull this patch (actually I'm
now also covinced to queue this to bluetooth-next).  I'll sent a new
pull request soon, after wait some time for new patches.

IIRC the symptom that prompted the initial investigation was the failure
to properly connect to one specific Bluetooth headset. After discussions
with Marcel the conculsion was to move more control of these commands to
the kernel side. OTOH, this is certainly not the first time a BT
controller chokes up when receiving too many commands at the same time
(I've seen this several times during the last 8 years or so that I've
been involved with Bluetooth). Anyway, I agree that this might be better
suited for bluetooth-next.

Johan