linux/include/net/bluetooth/rfcomm.h, branch v3.0.86

Bluetooth: clean up legal text

2010-12-01T23:04:43Z

Remove extra spaces from legal text so that legal stuff looks the same for all bluetooth code. Signed-off-by: Andrei Emeltchenko Signed-off-by: Gustavo F. Padovan

Bluetooth: clean up rfcomm code

2010-12-01T23:04:43Z

Remove extra spaces, assignments in if statement, zeroing static variables, extra braces. Fix includes. Signed-off-by: Andrei Emeltchenko Signed-off-by: Gustavo F. Padovan

Bluetooth: clean up rfcomm code

2010-10-12T15:44:53Z

Remove dead code and unused rfcomm thread events Signed-off-by: Andrei Emeltchenko Acked-by: Marcel Holtmann Signed-off-by: Gustavo F. Padovan

Bluetooth: Use __packed annotation

2010-07-21T17:39:13Z

To make net/ and include/net/ code consistent use __packed instead of __attribute__ ((packed)). Bluetooth subsystem was one of the last net subsys still using __attribute__ ((packed)). Signed-off-by: Gustavo F. Padovan Signed-off-by: Marcel Holtmann

Bluetooth: Fix rejected connection not disconnecting ACL link

2009-08-22T22:05:58Z

When using DEFER_SETUP on a RFCOMM socket, a SABM frame triggers authorization which when rejected send a DM response. This is fine according to the RFCOMM spec: the responding implementation may replace the "proper" response on the Multiplexer Control channel with a DM frame, sent on the referenced DLCI to indicate that the DLCI is not open, and that the responder would not grant a request to open it later either. But some stacks doesn't seems to cope with this leaving DLCI 0 open after receiving DM frame. To fix it properly a timer was introduced to rfcomm_session which is used to set a timeout when the last active DLC of a session is unlinked, this will give the remote stack some time to reply with a proper DISC frame on DLCI 0 avoiding both sides sending DISC to each other on stacks that follow the specification and taking care of those who don't by taking down DLCI 0. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann

bluetooth: rfcomm_init bug fix

2009-08-03T20:24:39Z

rfcomm tty may be used before rfcomm_tty_driver initilized, The problem is that now socket layer init before tty layer, if userspace program do socket callback right here then oops will happen. reporting in: http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2 make 3 changes: 1. remove #ifdef in rfcomm/core.c, make it blank function when rfcomm tty not selected in rfcomm.h 2. tune the rfcomm_init error patch to ensure tty driver initilized before rfcomm socket usage. 3. remove __exit for rfcomm_cleanup_sockets because above change need call it in a __init function. Reported-by: Oliver Hartkopp Tested-by: Oliver Hartkopp Signed-off-by: Dave Young Signed-off-by: David S. Miller

Bluetooth: Pause RFCOMM TX when encryption drops

2009-02-27T05:14:33Z

A role switch with devices following the Bluetooth pre-2.1 standards or without Encryption Pause and Resume support is not possible if encryption is enabled. Most newer headsets require the role switch, but also require that the connection is encrypted. For connections with a high security mode setting, the link will be immediately dropped. When the connection uses medium security mode setting, then a grace period is introduced where the TX is halted and the remote device gets a change to re-enable encryption after the role switch. If not re-enabled the link will be dropped. Based on initial work by Ville Tervo Signed-off-by: Marcel Holtmann

Bluetooth: Replace RFCOMM link mode with security level

2009-02-27T05:14:26Z

Change the RFCOMM internals to use the new security levels and remove the link mode details. Signed-off-by: Marcel Holtmann

Bluetooth: Add support for deferring RFCOMM connection setup

2009-02-27T05:14:23Z

In order to decide if listening RFCOMM sockets should be accept()ed the BD_ADDR of the remote device needs to be known. This patch adds a socket option which defines a timeout for deferring the actual connection setup. The connection setup is done after reading from the socket for the first time. Until then writing to the socket returns ENOTCONN. Signed-off-by: Marcel Holtmann

[Bluetooth] Store remote modem status for RFCOMM TTY

2008-07-14T18:13:52Z

When switching a RFCOMM socket to a TTY, the remote modem status might be needed later. Currently it is lost since the original configuration is done via the socket interface. So store the modem status and reply it when the socket has been converted to a TTY. Signed-off-by: Denis Kenzior Signed-off-by: Marcel Holtmann