Marcel Holtmann 98bcd08b5b [Bluetooth] Correct RFCOMM channel MTU for broken implementations ... Some Bluetooth RFCOMM implementations try to negotiate a bigger channel MTU than we can support for a particular session. The maximum MTU for a RFCOMM session is limited through the L2CAP layer. So if the other side proposes a channel MTU that is bigger than the underlying L2CAP MTU, we should reduce it to the L2CAP MTU of the session minus five bytes for the RFCOMM headers. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>		2006-07-24 12:44:25 -07:00
..
bnep
cmtp	[Bluetooth] Remaining transitions to use kzalloc()	2006-07-12 15:34:28 -07:00
hidp	[Bluetooth] Let BT_HIDP depend on INPUT	2006-07-12 15:34:33 -07:00
rfcomm	[Bluetooth] Correct RFCOMM channel MTU for broken implementations	2006-07-24 12:44:25 -07:00
af_bluetooth.c
hci_conn.c
hci_core.c	[Bluetooth] Remaining transitions to use kzalloc()	2006-07-12 15:34:28 -07:00
hci_event.c
hci_sock.c
hci_sysfs.c
Kconfig
l2cap.c	[Bluetooth] Fix deadlock in the L2CAP layer	2006-07-12 15:34:35 -07:00
lib.c
Makefile
sco.c	[Bluetooth] Remaining transitions to use kzalloc()	2006-07-12 15:34:28 -07:00