summaryrefslogtreecommitdiff
path: root/include/net/bluetooth
diff options
context:
space:
mode:
authorJohan Hedberg <johan.hedberg@intel.com>2015-10-12 11:36:19 (GMT)
committerMarcel Holtmann <marcel@holtmann.org>2015-10-20 22:49:21 (GMT)
commitcad20c278085d893ebd616cd20c0747a8e9d53c7 (patch)
tree04bde6709e83fd472e0da063ab08a8d9f52cd936 /include/net/bluetooth
parent581d6fd60f37be587690655de05aee200b939e06 (diff)
downloadlinux-cad20c278085d893ebd616cd20c0747a8e9d53c7.tar.xz
Bluetooth: Don't use remote address type to decide IRK persistency
There are LE devices on the market that start off by announcing their public address and then once paired switch to using private address. To be interoperable with such devices we should simply trust the fact that we're receiving an IRK from them to indicate that they may use private addresses in the future. Instead, simply tie the persistency to the bonding/no-bonding information the same way as for LTKs and CSRKs. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'include/net/bluetooth')
-rw-r--r--include/net/bluetooth/hci_core.h2
1 files changed, 1 insertions, 1 deletions
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index f28470e..989c72a 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -1458,7 +1458,7 @@ void mgmt_remote_name(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 link_type,
void mgmt_discovering(struct hci_dev *hdev, u8 discovering);
bool mgmt_powering_down(struct hci_dev *hdev);
void mgmt_new_ltk(struct hci_dev *hdev, struct smp_ltk *key, bool persistent);
-void mgmt_new_irk(struct hci_dev *hdev, struct smp_irk *irk);
+void mgmt_new_irk(struct hci_dev *hdev, struct smp_irk *irk, bool persistent);
void mgmt_new_csrk(struct hci_dev *hdev, struct smp_csrk *csrk,
bool persistent);
void mgmt_new_conn_param(struct hci_dev *hdev, bdaddr_t *bdaddr,