• Marcel Holtmann's avatar
    Bluetooth: Ask upper layers for HCI disconnect reason · 2950f21a
    Marcel Holtmann authored
    Some of the qualification tests demand that in case of failures in L2CAP
    the HCI disconnect should indicate a reason why L2CAP fails. This is a
    bluntly layer violation since multiple L2CAP connections could be using
    the same ACL and thus forcing a disconnect reason is not a good idea.
    
    To comply with the Bluetooth test specification, the disconnect reason
    is now stored in the L2CAP connection structure and every time a new
    L2CAP channel is added it will set back to its default. So only in the
    case where the L2CAP channel with the disconnect reason is really the
    last one, it will propagated to the HCI layer.
    
    The HCI layer has been extended with a disconnect indication that allows
    it to ask upper layers for a disconnect reason. The upper layer must not
    support this callback and in that case it will nicely default to the
    existing behavior. If an upper layer like L2CAP can provide a disconnect
    reason that one will be used to disconnect the ACL or SCO link.
    
    No modification to the ACL disconnect timeout have been made. So in case
    of Linux to Linux connection the initiator will disconnect the ACL link
    before the acceptor side can signal the specific disconnect reason. That
    is perfectly fine since Linux doesn't make use of this value anyway. The
    L2CAP layer has a perfect valid error code for rejecting connection due
    to a security violation. It is unclear why the Bluetooth specification
    insists on having specific HCI disconnect reason.
    Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
    2950f21a
hci_core.h 17.6 KB