aboutsummaryrefslogtreecommitdiffstats
path: root/include/net/bluetooth/l2cap.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2013-10-15Bluetooth: Add chan->ops->set_shutdown()Gustavo Padovan1-0/+5
We need to remove all direct access of struct sock from L2CAP core. This change is pretty simple and just add a new L2CAP channel callback to do the work in the L2CAP socket side. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-15Bluetooth: Access sk_sndtimeo indirectly in l2cap_core.cGustavo Padovan1-0/+6
As part of the work to remove struct sock from l2cap_core.c and make it more generic we remove in this commit the direct access to sk->sk_sndtimeo member. This objective of this change is purely remove sk usage from l2cap_core.c Now we have a new l2cap ops to get the current value of sk->sndtimeo. A l2cap_chan_no_get_sndtimeo was added for users of L2CAP that doesn't need to set a timeout. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-15Bluetooth: Extend state_change() call to report errors tooGustavo Padovan1-1/+1
Instead of creating an new function pointer to report errors we are just reusing state_change for that and there is a simple reason for this, one place in the l2cap_core.c code needs, in a locked sk, set both the sk_state and sk_err. If we create two different functions for this we would need to release the lock between the two operation putting the socket in non desired state. The change is transparent to the l2cap_core.c code, user that only needs to set the state won't need any modification. This is another step of an ongoing work to make l2cap_core.c totally independent from l2cap's struct sock. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14treewide: Fix common typo in "identify"Maxime Jayat1-1/+1
Correct common misspelling of "identify" as "indentify" throughout the kernel Signed-off-by: Maxime Jayat <maxime@artisandeveloppeur.fr> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-14Bluetooth: Introduce L2CAP channel callback for resumingMarcel Holtmann1-0/+1
Clearing the BT_SK_SUSPEND socket flag from the L2CAP core is causing a dependency on the socket. So intead of doing that, use a channel callback into the socket handling to resume. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-14Bluetooth: Introduce L2CAP channel flag for defer setupMarcel Holtmann1-0/+1
The L2CAP core should not look into the socket flags to figure out the setting of defer setup. So introduce a L2CAP channel flag that mirrors the socket flag. Since the defer setup option is only set in one place this becomes a really easy thing to do. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Return the correct address type for L2CAP socketsMarcel Holtmann1-2/+3
The L2CAP sockets can use BR/EDR public, LE public and LE random addresses for various combinations of source and destination devices. So make sure that getsockname(), getpeername() and accept() return the correct address type. For this the address type of the source and destination is stored with the L2CAP channel information. The stored address type is not the one specific for the HCI protocol. It is the address type used for the L2CAP sockets and the management interface. The underlying HCI connections store the HCI address type. If needed, it gets converted to the socket address type. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Store address information in L2CAP channel structureMarcel Holtmann1-0/+2
With the effort of abstracting the L2CAP socket from the underlying L2CAP channel it is important to store the source and destination address information directly in the L2CAP channel structure. Direct access to the HCI connection address information is not possible since they might not be avaiable at L2CAP channel creation time. The address information will be updated when the underlying BR/EDR or LE connection status changes. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst pointersMarcel Holtmann1-3/+0
The l2cap_conn->src and l2cap_conn->dst pointers are no longer in use and so just remove them. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-12Bluetooth: The L2CAP fixed channel connectionless data is supportedMarcel Holtmann1-0/+1
The implementation actually supports the L2CAP connectionless data channel. So set it as supported in the fixed channels bitmask. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-12Bluetooth: Allow 3D profile to use security mode 4 level 0Marcel Holtmann1-0/+1
The PSM 0x0021 is dedicated to the 3D profile and has permission to use security mode 4 level 0 for L2CAP connectionless unicast data transfers. When establishing a L2CAP connectionless channel on PSM 0x0021, it will no longer force Secure Simple Pairing. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-02Bluetooth: Provide high speed configuration optionMarcel Holtmann1-0/+1
Hiding the Bluetooth high speed support behind a module parameter is not really useful. This can be enabled and disabled at runtime via the management interface. This also has the advantage that this can now be changed per controller and not just global. This patch removes the module parameter and exposes the high speed setting of the management interface to all controllers. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-06-23Bluetooth: Rename L2CAP_CID_LE_DATA to L2CAP_CID_ATTJohan Hedberg1-1/+1
In future Core Specification versions the ATT CID will be just one of many possible CIDs that can be used for data transfer. Therefore, it makes sense to rename the define for the ATT CID to something less ambigous. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: l2cap: add l2cap_user sub-modulesDavid Herrmann1-0/+10
Several sub-modules like HIDP, rfcomm, ... need to track l2cap connections. The l2cap_conn->hcon->dev object is used as parent for sysfs devices so the sub-modules need to be notified when the hci_conn object is removed from sysfs. As submodules normally use the l2cap layer, the l2cap_user objects are registered there instead of on the underlying hci_conn object. This avoids any direct dependency on the HCI layer and lets the l2cap core handle any specifics. This patch introduces l2cap_user objects which contain a "probe" and "remove" callback. You can register them on any l2cap_conn object and if it is active, the "probe" callback will get called. Otherwise, an error is returned. The l2cap_conn object will call your "remove" callback directly before it is removed from user-space. This allows you to remove your submodules _before_ the parent l2cap_conn and hci_conn object is removed. At any time you can asynchronously unregister your l2cap_user object if your submodule vanishes before the l2cap_conn object does. There is no way around l2cap_user. If we want wire-protocols in the kernel, we always want the hci_conn object as parent in the sysfs tree. We cannot use a channel here since we might need multiple channels for a single protocol. But the problem is, we _must_ get notified when an l2cap_conn object is removed. We cannot use reference-counting for object-removal! This is not how it works. If a hardware is removed, we should immediately remove the object from sysfs. Any other behavior would be inconsistent with the rest of the system. Also note that device_del() might sleep, but it doesn't wait for user-space or block very long. It only _unlinks_ the object from sysfs and the whole device-tree. Everything else is handled by ref-counts! This is exactly what the other sub-modules must do: unlink their devices when the "remove" l2cap_user callback is called. They should not do any cleanup or synchronous shutdowns. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: l2cap: introduce l2cap_conn ref-countingDavid Herrmann1-0/+4
If we want to use l2cap_conn outside of l2cap_core.c, we need refcounting for these objects. Otherwise, we cannot synchronize l2cap locks with outside locks and end up with deadlocks. Hence, introduce ref-counting for l2cap_conn objects. This doesn't affect l2cap internals at all, as they use a direct synchronization. We also keep a reference to the parent hci_conn for locking purposes as l2cap_conn depends on this. This doesn't affect the connection itself but only the lifetime of the (dead) object. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-05Bluetooth: hidp: verify l2cap socketsDavid Herrmann1-0/+1
We need to verify that the given sockets actually are l2cap sockets. If they aren't, we are not supposed to access bt_sk(sock) and we shouldn't start the session if the offsets turn out to be valid local BT addresses. That is, if someone passes a TCP socket to HIDCONNADD, then we access some random offset in the TCP socket (which isn't even guaranteed to be valid). Fix this by checking that the socket is an l2cap socket. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-01-09Bluetooth: remove an unused variable in a header fileRami Rosen1-1/+0
This patch removes srej_queue_next from include/net/bluetooth/l2cap.h as it is not used. Signed-off-by: Rami Rosen <ramirose@gmail.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-12-03Bluetooth: trivial: Change NO_FCS_RECV to RECV_NO_FCSAndrei Emeltchenko1-1/+1
Make code more readable by changing CONF_NO_FCS_RECV which is read as "No L2CAP FCS option received" to CONF_RECV_NO_FCS which means "Received L2CAP option NO_FCS". This flag really means that we have received L2CAP FRAME CHECK SEQUENCE (FCS) OPTION with value "No FCS". Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-11-19Bluetooth: Refactor locking in amp_physical_cfmAndrei Emeltchenko1-1/+1
Remove locking from l2cap_physical_cfm and lock chan inside amp_physical_cfm. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-11-01Bluetooth: Rename ctrl_id to remote_amp_idAndrei Emeltchenko1-2/+1
Since we have started to use local_amp_id for local AMP Controller Id it makes sense to rename ctrl_id to remote_amp_id since it represents remote AMP controller Id. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-11-01Bluetooth: AMP: Use l2cap_physical_cfm in phylink complete evtAndrei Emeltchenko1-0/+1
When receiving HCI Phylink Complete event run amp_physical_cfm which initialize BR/EDR L2CAP channel associated with High Speed link and run l2cap_physical_cfm which shall send L2CAP Create Chan Request. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-11-01Bluetooth: AMP: Process Logical Link complete evtAndrei Emeltchenko1-0/+2
After receiving HCI Logical Link Complete event finish EFS configuration by sending L2CAP Conf Response with success code. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-10-24Bluetooth: Start channel move when socket option is changedMat Martineau1-0/+1
Channel moves are triggered by changes to the BT_CHANNEL_POLICY sockopt when an ERTM or streaming-mode channel is connected. Moves are only started if enable_hs is true. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-10-24Bluetooth: Move channel responseMat Martineau1-0/+2
The move response command includes a result code indicating "pending", "success", or "failure" status. A pending result is received when the remote address is still setting up a physical link, and will be followed by success or failure. On success, logical link setup will proceed. On failure, the move is stopped. The receiver of a move channel response must always follow up by sending a move channel confirm command. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-10-23Bluetooth: Add new l2cap_chan struct members for high speed channelsMat Martineau1-0/+29
An L2CAP channel using high speed continues to be associated with a BR/EDR l2cap_conn, while also tracking an additional hci_conn (representing a physical link on a high speed controller) and hci_chan (representing a logical link). There may only be one physical link between two high speed controllers. Each physical link may contain several logical links, with each logical link representing a channel with specific quality of service. During a channel move, the destination channel id, current move state, and role (initiator vs. responder) are tracked and used by the channel move state machine. The ident value associated with a move request must also be stored in order to use it in later move responses. The active channel is stored in local_amp_id. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-10-15Bluetooth: Add chan->ops->defer()Gustavo Padovan1-0/+5
When DEFER_SETUP is set defer() will trigger an authorization request to the userspace. l2cap_chan_no_defer() is meant to be used when one does not want to support DEFER_SETUP (A2MP for example). Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-10-08Bluetooth: L2CAP: Fix using default Flush Timeout for EFSAndrei Emeltchenko1-1/+2
There are two Flush Timeouts: one is old Flush Timeot Option which is 2 octets and the second is Flush Timeout inside EFS which is 4 octets long. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-10-08Bluetooth: Adjust L2CAP Max PDU size for AMP packetsAndrei Emeltchenko1-1/+1
Maximum PDU size is defined by new BT Spec as 1492 octets. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Reviewed-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-09-27Bluetooth: AMP: Process Chan Selected eventAndrei Emeltchenko1-0/+2
Channel Selected event indicates that link information data is available. Read it with Read Local AMP Assoc command. The data shall be sent in the A2MP Create Physical Link Request. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-09-27Bluetooth: A2MP: Add fallback to normal l2cap init sequenceAndrei Emeltchenko1-0/+1
When there is no remote AMP controller found fallback to normal L2CAP sequence. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-09-27Bluetooth: Choose connection based on capabilitiesAndrei Emeltchenko1-0/+1
Choose which L2CAP connection to establish by checking support for HS and remote side supported features. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-08-21Bluetooth: Use kref for l2cap channel reference countingSyam Sidhardhan1-2/+1
This patch changes the struct l2cap_chan and associated code to use kref api for object refcounting and freeing. Suggested-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by: Syam Sidhardhan <s.syam@samsung.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-08-06Bluetooth: Free the l2cap channel list only when refcount is zeroJaganath Kanakkassery1-1/+0
Move the l2cap channel list chan->global_l under the refcnt protection and free it based on the refcnt. Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by: Syam Sidhardhan <s.syam@samsung.com> Reviewed-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-08-06Bluetooth: Move l2cap_chan_hold/put to l2cap_core.cJaganath Kanakkassery1-14/+2
Refactor the code in order to use the l2cap_chan_destroy() from l2cap_chan_put() under the refcnt protection. Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by: Syam Sidhardhan <s.syam@samsung.com> Reviewed-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-07-15Bluetooth: Use tx window from config response for ack timingMat Martineau1-0/+1
This change addresses an L2CAP ERTM throughput problem when a remote device does not fully utilize the available transmit window. The L2CAP ERTM transmit window size determines the maximum number of unacked frames that may be outstanding at any time. It is configured separately for each direction of an ERTM connection. Each side sends a configuration request with a tx_win field indicating how many unacked frames it is capable of receiving before sending an ack. The configuration response's tx_win field shows how many frames the transmitter will actually send before waiting for an ack. It's important to trace both the actual transmit window (to check for validity of incoming frames) and the number of frames that the transmitter will send before waiting (to send acks at the appropriate time). Now there are separate tx_win and ack_win values. ack_win is updated based on configuration responses, and is used to determine when acks are sent. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-07-11Bluetooth: debug: Print l2cap_chan refcountAndrei Emeltchenko1-0/+4
Improve debug output. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-06-05Bluetooth: Create empty l2cap ops functionGustavo Padovan1-0/+12
A2MP doesn't use part of the L2CAP chan ops API so we just create general empty function instead of the A2MP specific one. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2012-06-05Bluetooth: Rename L2CAP_LE_DEFAULT_MTUAndre Guedes1-1/+1
This patch renames L2CAP_LE_DEFAULT_MTU macro to L2CAP_LE_MIN_MTU since it represents the minimum MTU value, not the default MTU value for LE. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-06-05Bluetooth: A2MP: Handling fixed channelsAndrei Emeltchenko1-0/+1
A2MP fixed channel do not have sk Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-06-05Bluetooth: A2MP: Create A2MP channelAndrei Emeltchenko1-0/+6
Create and initialize fixed A2MP channel Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-06-05Bluetooth: Add l2cap_chan->ops->ready()Andrei Emeltchenko1-0/+1
This move socket specific code to l2cap_sock.c. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2012-06-05Bluetooth: Move clean up code and set of SOCK_ZAPPED to l2cap_sock.cAndrei Emeltchenko1-0/+1
This remove a bit more of socket code from l2cap core, this calls set the SOCK_ZAPPED and do some clean up depending on the socket state. Reported-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2012-06-05Bluetooth: Use chan as parameters for l2cap chan opsGustavo Padovan1-4/+6
Use chan instead of void * makes more sense here. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2012-06-05Bluetooth: Define and use PSM identifiersAndrei Emeltchenko1-0/+4
Define assigned Protocol and Service Multiplexor (PSM) identifiers and use them instead of magic numbers. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-06-05Bluetooth: Define L2CAP conf continuation flagAndrei Emeltchenko1-0/+3
Define Continuation flag which the only flag used from Flags field in L2CAP Configuration Request and Response. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2012-06-05Bluetooth: Remove unused ERTM control field macrosMat Martineau1-168/+0
Now that l2cap_ctrl is used to set up control fields, these macros are not needed. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-06-05Bluetooth: Check rules when setting retransmit or monitor timersMat Martineau1-4/+0
The ERTM specification requires the retransmit timer to be cancelled when the monitor timer is set. The retransmit timer cannot be set again while the monitor timer is pending. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-06-05Bluetooth: Remove receive code that has been supercededMat Martineau1-8/+0
This deletes the receive code that had handlers for each frame type at the top level, and then had logic to determine the receive state within each handler. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-06-05Bluetooth: Fix early return from l2cap_chan_delMat Martineau1-0/+1
This fixes a regression from commit 2ead70b8390d199ca04cd35311b51f5f3676079e that is present in all kernels starting at v3.0. When L2CAP information was moved to struct l2cap_chan, a check was added to l2cap_chan_del to avoid certain cleanup operations when ERTM or streaming mode had not yet been initialized. The logic in the check did not take in to account that chan->conf_state is set to 0 in l2cap_chan_ready, so l2cap_chan_del failed to cancel timers and leaked memory any time the ERTM queues or lists were not empty. This change makes sure that l2cap_chan_del only returns early if ERTM initialization was not performed. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2012-05-09Bluetooth: Refactor L2CAP ERTM and streaming transmit segmentationMat Martineau1-0/+1
Use more common code for ERTM and streaming mode segmentation and transmission, and begin using skb control block data for delaying extended or enhanced header generation until just before the packet is transmitted. This code is also better suited for resegmentation, which is needed when L2CAP links are reconfigured after an AMP channel move. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Reviewed-by: Ulisses Furquim <ulisses@profusion.mobi> Signed-off-by: Gustavo Padovan <gustavo@padovan.org>