summaryrefslogtreecommitdiff
path: root/lib/locking-selftest-rlock-hardirq.h
diff options
context:
space:
mode:
authorMarcel Holtmann <marcel@holtmann.org>2008-07-14 18:13:45 (GMT)
committerMarcel Holtmann <marcel@holtmann.org>2008-07-14 18:13:45 (GMT)
commitae29319649b80ed9d28d7b4f164e3f5f75020fc8 (patch)
tree71026720bc10d9e4c9f1b971a531e175aa9d2e16 /lib/locking-selftest-rlock-hardirq.h
parent9719f8afce34d3d04e884873a8a5e3483e30974c (diff)
downloadlinux-fsl-qoriq-ae29319649b80ed9d28d7b4f164e3f5f75020fc8.tar.xz
[Bluetooth] Update authentication status after successful encryption
The authentication status is not communicated to both parties. This is actually a flaw in the Bluetooth specification. Only the requesting side really knows if the authentication was successful or not. This piece of information is however needed on the other side to know if it has to trigger the authentication procedure or not. Worst case is that both sides will request authentication at different times, but this should be avoided since it costs extra time when setting up a new connection. For Bluetooth encryption it is required to authenticate the link first and the encryption status is communicated to both sides. So when a link is switched to encryption it is possible to update the authentication status since it implies an authenticated link. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'lib/locking-selftest-rlock-hardirq.h')
0 files changed, 0 insertions, 0 deletions