--- /dev/null
+From 1e9683c9b6ca88cc9340cdca85edd6134c8cffe3 Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Date: Tue, 27 Aug 2024 15:01:34 -0400
+Subject: Bluetooth: MGMT: Ignore keys being loaded with invalid type
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+commit 1e9683c9b6ca88cc9340cdca85edd6134c8cffe3 upstream.
+
+Due to 59b047bc98084f8af2c41483e4d68a5adf2fa7f7 there could be keys stored
+with the wrong address type so this attempt to detect it and ignore them
+instead of just failing to load all keys.
+
+Cc: stable@vger.kernel.org
+Link: https://github.com/bluez/bluez/issues/875
+Fixes: 59b047bc9808 ("Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE")
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/mgmt.c | 37 +++++++++++++++++++------------------
+ 1 file changed, 19 insertions(+), 18 deletions(-)
+
+--- a/net/bluetooth/mgmt.c
++++ b/net/bluetooth/mgmt.c
+@@ -2370,15 +2370,6 @@ static int load_link_keys(struct sock *s
+ bt_dev_dbg(hdev, "debug_keys %u key_count %u", cp->debug_keys,
+ key_count);
+
+- for (i = 0; i < key_count; i++) {
+- struct mgmt_link_key_info *key = &cp->keys[i];
+-
+- if (key->addr.type != BDADDR_BREDR || key->type > 0x08)
+- return mgmt_cmd_status(sk, hdev->id,
+- MGMT_OP_LOAD_LINK_KEYS,
+- MGMT_STATUS_INVALID_PARAMS);
+- }
+-
+ hci_dev_lock(hdev);
+
+ hci_link_keys_clear(hdev);
+@@ -2403,6 +2394,19 @@ static int load_link_keys(struct sock *s
+ continue;
+ }
+
++ if (key->addr.type != BDADDR_BREDR) {
++ bt_dev_warn(hdev,
++ "Invalid link address type %u for %pMR",
++ key->addr.type, &key->addr.bdaddr);
++ continue;
++ }
++
++ if (key->type > 0x08) {
++ bt_dev_warn(hdev, "Invalid link key type %u for %pMR",
++ key->type, &key->addr.bdaddr);
++ continue;
++ }
++
+ /* Always ignore debug keys and require a new pairing if
+ * the user wants to use them.
+ */
+@@ -5993,15 +5997,6 @@ static int load_long_term_keys(struct so
+
+ bt_dev_dbg(hdev, "key_count %u", key_count);
+
+- for (i = 0; i < key_count; i++) {
+- struct mgmt_ltk_info *key = &cp->keys[i];
+-
+- if (!ltk_is_valid(key))
+- return mgmt_cmd_status(sk, hdev->id,
+- MGMT_OP_LOAD_LONG_TERM_KEYS,
+- MGMT_STATUS_INVALID_PARAMS);
+- }
+-
+ hci_dev_lock(hdev);
+
+ hci_smp_ltks_clear(hdev);
+@@ -6017,6 +6012,12 @@ static int load_long_term_keys(struct so
+ &key->addr.bdaddr);
+ continue;
+ }
++
++ if (!ltk_is_valid(key)) {
++ bt_dev_warn(hdev, "Invalid LTK for %pMR",
++ &key->addr.bdaddr);
++ continue;
++ }
+
+ switch (key->type) {
+ case MGMT_LTK_UNAUTHENTICATED:
--- /dev/null
+From f7790d67785302b3116bbbfda62a5a44524601a3 Mon Sep 17 00:00:00 2001
+From: Joanne Koong <joannelkoong@gmail.com>
+Date: Mon, 26 Aug 2024 14:19:04 -0700
+Subject: fuse: update stats for pages in dropped aux writeback list
+
+From: Joanne Koong <joannelkoong@gmail.com>
+
+commit f7790d67785302b3116bbbfda62a5a44524601a3 upstream.
+
+In the case where the aux writeback list is dropped (e.g. the pages
+have been truncated or the connection is broken), the stats for
+its pages and backing device info need to be updated as well.
+
+Fixes: e2653bd53a98 ("fuse: fix leaked aux requests")
+Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Cc: <stable@vger.kernel.org> # v5.1
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fuse/file.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/fs/fuse/file.c
++++ b/fs/fuse/file.c
+@@ -1692,10 +1692,16 @@ __acquires(fi->lock)
+ fuse_writepage_finish(fm, wpa);
+ spin_unlock(&fi->lock);
+
+- /* After fuse_writepage_finish() aux request list is private */
++ /* After rb_erase() aux request list is private */
+ for (aux = wpa->next; aux; aux = next) {
++ struct backing_dev_info *bdi = inode_to_bdi(aux->inode);
++
+ next = aux->next;
+ aux->next = NULL;
++
++ dec_wb_stat(&bdi->wb, WB_WRITEBACK);
++ dec_node_page_state(aux->ia.ap.pages[0], NR_WRITEBACK_TEMP);
++ wb_writeout_inc(&bdi->wb);
+ fuse_writepage_free(aux);
+ }
+
--- /dev/null
+From b18915248a15eae7d901262f108d6ff0ffb4ffc1 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Mon, 19 Aug 2024 19:52:30 +0200
+Subject: fuse: use unsigned type for getxattr/listxattr size truncation
+
+From: Jann Horn <jannh@google.com>
+
+commit b18915248a15eae7d901262f108d6ff0ffb4ffc1 upstream.
+
+The existing code uses min_t(ssize_t, outarg.size, XATTR_LIST_MAX) when
+parsing the FUSE daemon's response to a zero-length getxattr/listxattr
+request.
+On 32-bit kernels, where ssize_t and outarg.size are the same size, this is
+wrong: The min_t() will pass through any size values that are negative when
+interpreted as signed.
+fuse_listxattr() will then return this userspace-supplied negative value,
+which callers will treat as an error value.
+
+This kind of bug pattern can lead to fairly bad security bugs because of
+how error codes are used in the Linux kernel. If a caller were to convert
+the numeric error into an error pointer, like so:
+
+ struct foo *func(...) {
+ int len = fuse_getxattr(..., NULL, 0);
+ if (len < 0)
+ return ERR_PTR(len);
+ ...
+ }
+
+then it would end up returning this userspace-supplied negative value cast
+to a pointer - but the caller of this function wouldn't recognize it as an
+error pointer (IS_ERR_VALUE() only detects values in the narrow range in
+which legitimate errno values are), and so it would just be treated as a
+kernel pointer.
+
+I think there is at least one theoretical codepath where this could happen,
+but that path would involve virtio-fs with submounts plus some weird
+SELinux configuration, so I think it's probably not a concern in practice.
+
+Cc: stable@vger.kernel.org # v4.9
+Fixes: 63401ccdb2ca ("fuse: limit xattr returned size")
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fuse/xattr.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/fuse/xattr.c
++++ b/fs/fuse/xattr.c
+@@ -79,7 +79,7 @@ ssize_t fuse_getxattr(struct inode *inod
+ }
+ ret = fuse_simple_request(fm, &args);
+ if (!ret && !size)
+- ret = min_t(ssize_t, outarg.size, XATTR_SIZE_MAX);
++ ret = min_t(size_t, outarg.size, XATTR_SIZE_MAX);
+ if (ret == -ENOSYS) {
+ fm->fc->no_getxattr = 1;
+ ret = -EOPNOTSUPP;
+@@ -141,7 +141,7 @@ ssize_t fuse_listxattr(struct dentry *en
+ }
+ ret = fuse_simple_request(fm, &args);
+ if (!ret && !size)
+- ret = min_t(ssize_t, outarg.size, XATTR_LIST_MAX);
++ ret = min_t(size_t, outarg.size, XATTR_LIST_MAX);
+ if (ret > 0 && size)
+ ret = fuse_verify_xattr_list(list, ret);
+ if (ret == -ENOSYS) {
--- /dev/null
+From 8396c793ffdf28bb8aee7cfe0891080f8cab7890 Mon Sep 17 00:00:00 2001
+From: Sam Protsenko <semen.protsenko@linaro.org>
+Date: Wed, 6 Mar 2024 17:20:52 -0600
+Subject: mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K
+
+From: Sam Protsenko <semen.protsenko@linaro.org>
+
+commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890 upstream.
+
+Commit 616f87661792 ("mmc: pass queue_limits to blk_mq_alloc_disk") [1]
+revealed the long living issue in dw_mmc.c driver, existing since the
+time when it was first introduced in commit f95f3850f7a9 ("mmc: dw_mmc:
+Add Synopsys DesignWare mmc host driver."), also making kernel boot
+broken on platforms using dw_mmc driver with 16K or 64K pages enabled,
+with this message in dmesg:
+
+ mmcblk: probe of mmc0:0001 failed with error -22
+
+That's happening because mmc_blk_probe() fails when it calls
+blk_validate_limits() consequently, which returns the error due to
+failed max_segment_size check in this code:
+
+ /*
+ * The maximum segment size has an odd historic 64k default that
+ * drivers probably should override. Just like the I/O size we
+ * require drivers to at least handle a full page per segment.
+ */
+ ...
+ if (WARN_ON_ONCE(lim->max_segment_size < PAGE_SIZE))
+ return -EINVAL;
+
+In case when IDMAC (Internal DMA Controller) is used, dw_mmc.c always
+sets .max_seg_size to 4 KiB:
+
+ mmc->max_seg_size = 0x1000;
+
+The comment in the code above explains why it's incorrect. Arnd
+suggested setting .max_seg_size to .max_req_size to fix it, which is
+also what some other drivers are doing:
+
+ $ grep -rl 'max_seg_size.*=.*max_req_size' drivers/mmc/host/ | \
+ wc -l
+ 18
+
+This change is not only fixing the boot with 16K/64K pages, but also
+leads to a better MMC performance. The linear write performance was
+tested on E850-96 board (eMMC only), before commit [1] (where it's
+possible to boot with 16K/64K pages without this fix, to be able to do
+a comparison). It was tested with this command:
+
+ # dd if=/dev/zero of=somefile bs=1M count=500 oflag=sync
+
+Test results are as follows:
+
+ - 4K pages, .max_seg_size = 4 KiB: 94.2 MB/s
+ - 4K pages, .max_seg_size = .max_req_size = 512 KiB: 96.9 MB/s
+ - 16K pages, .max_seg_size = 4 KiB: 126 MB/s
+ - 16K pages, .max_seg_size = .max_req_size = 2 MiB: 128 MB/s
+ - 64K pages, .max_seg_size = 4 KiB: 138 MB/s
+ - 64K pages, .max_seg_size = .max_req_size = 8 MiB: 138 MB/s
+
+Unfortunately, SD card controller is not enabled in E850-96 yet, so it
+wasn't possible for me to run the test on some cheap SD cards to check
+this patch's impact on those. But it's possible that this change might
+also reduce the writes count, thus improving SD/eMMC longevity.
+
+All credit for the analysis and the suggested solution goes to Arnd.
+
+[1] https://lore.kernel.org/all/20240215070300.2200308-18-hch@lst.de/
+
+Fixes: f95f3850f7a9 ("mmc: dw_mmc: Add Synopsys DesignWare mmc host driver.")
+Suggested-by: Arnd Bergmann <arnd@arndb.de>
+Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
+Closes: https://lore.kernel.org/all/CA+G9fYtddf2Fd3be+YShHP6CmSDNcn0ptW8qg+stUKW+Cn0rjQ@mail.gmail.com/
+Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240306232052.21317-1-semen.protsenko@linaro.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/dw_mmc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/dw_mmc.c
++++ b/drivers/mmc/host/dw_mmc.c
+@@ -2826,8 +2826,8 @@ static int dw_mci_init_slot(struct dw_mc
+ if (host->use_dma == TRANS_MODE_IDMAC) {
+ mmc->max_segs = host->ring_size;
+ mmc->max_blk_size = 65535;
+- mmc->max_seg_size = 0x1000;
+- mmc->max_req_size = mmc->max_seg_size * host->ring_size;
++ mmc->max_req_size = DW_MCI_DESC_DATA_LENGTH * host->ring_size;
++ mmc->max_seg_size = mmc->max_req_size;
+ mmc->max_blk_count = mmc->max_req_size / 512;
+ } else if (host->use_dma == TRANS_MODE_EDMAC) {
+ mmc->max_segs = 64;
--- /dev/null
+From 6e540da4c1db7b840e347c4dfe48359b18b7e376 Mon Sep 17 00:00:00 2001
+From: Liao Chen <liaochen4@huawei.com>
+Date: Mon, 26 Aug 2024 12:48:51 +0000
+Subject: mmc: sdhci-of-aspeed: fix module autoloading
+
+From: Liao Chen <liaochen4@huawei.com>
+
+commit 6e540da4c1db7b840e347c4dfe48359b18b7e376 upstream.
+
+Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
+based on the alias from of_device_id table.
+
+Signed-off-by: Liao Chen <liaochen4@huawei.com>
+Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au>
+Fixes: bb7b8ec62dfb ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240826124851.379759-1-liaochen4@huawei.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-of-aspeed.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mmc/host/sdhci-of-aspeed.c
++++ b/drivers/mmc/host/sdhci-of-aspeed.c
+@@ -236,6 +236,7 @@ static const struct of_device_id aspeed_
+ { .compatible = "aspeed,ast2600-sdhci", },
+ { }
+ };
++MODULE_DEVICE_TABLE(of, aspeed_sdhci_of_match);
+
+ static struct platform_driver aspeed_sdhci_driver = {
+ .driver = {
--- /dev/null
+From 532f8bcd1c2c4e8112f62e1922fd1703bc0ffce0 Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Date: Tue, 27 Aug 2024 14:37:22 -0400
+Subject: Revert "Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE"
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+commit 532f8bcd1c2c4e8112f62e1922fd1703bc0ffce0 upstream.
+
+This reverts commit 59b047bc98084f8af2c41483e4d68a5adf2fa7f7 which
+breaks compatibility with commands like:
+
+bluetoothd[46328]: @ MGMT Command: Load.. (0x0013) plen 74 {0x0001} [hci0]
+ Keys: 2
+ BR/EDR Address: C0:DC:DA:A5:E5:47 (Samsung Electronics Co.,Ltd)
+ Key type: Authenticated key from P-256 (0x03)
+ Central: 0x00
+ Encryption size: 16
+ Diversifier[2]: 0000
+ Randomizer[8]: 0000000000000000
+ Key[16]: 6ed96089bd9765be2f2c971b0b95f624
+ LE Address: D7:2A:DE:1E:73:A2 (Static)
+ Key type: Unauthenticated key from P-256 (0x02)
+ Central: 0x00
+ Encryption size: 16
+ Diversifier[2]: 0000
+ Randomizer[8]: 0000000000000000
+ Key[16]: 87dd2546ededda380ffcdc0a8faa4597
+@ MGMT Event: Command Status (0x0002) plen 3 {0x0001} [hci0]
+ Load Long Term Keys (0x0013)
+ Status: Invalid Parameters (0x0d)
+
+Cc: stable@vger.kernel.org
+Link: https://github.com/bluez/bluez/issues/875
+Fixes: 59b047bc9808 ("Bluetooth: MGMT/SMP: Fix address type when using SMP over BREDR/LE")
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/bluetooth/hci_core.h | 5 -----
+ net/bluetooth/mgmt.c | 25 +++++++------------------
+ net/bluetooth/smp.c | 7 -------
+ 3 files changed, 7 insertions(+), 30 deletions(-)
+
+--- a/include/net/bluetooth/hci_core.h
++++ b/include/net/bluetooth/hci_core.h
+@@ -174,7 +174,6 @@ struct blocked_key {
+ struct smp_csrk {
+ bdaddr_t bdaddr;
+ u8 bdaddr_type;
+- u8 link_type;
+ u8 type;
+ u8 val[16];
+ };
+@@ -184,7 +183,6 @@ struct smp_ltk {
+ struct rcu_head rcu;
+ bdaddr_t bdaddr;
+ u8 bdaddr_type;
+- u8 link_type;
+ u8 authenticated;
+ u8 type;
+ u8 enc_size;
+@@ -199,7 +197,6 @@ struct smp_irk {
+ bdaddr_t rpa;
+ bdaddr_t bdaddr;
+ u8 addr_type;
+- u8 link_type;
+ u8 val[16];
+ };
+
+@@ -207,8 +204,6 @@ struct link_key {
+ struct list_head list;
+ struct rcu_head rcu;
+ bdaddr_t bdaddr;
+- u8 bdaddr_type;
+- u8 link_type;
+ u8 type;
+ u8 val[HCI_LINK_KEY_SIZE];
+ u8 pin_len;
+--- a/net/bluetooth/mgmt.c
++++ b/net/bluetooth/mgmt.c
+@@ -2373,8 +2373,7 @@ static int load_link_keys(struct sock *s
+ for (i = 0; i < key_count; i++) {
+ struct mgmt_link_key_info *key = &cp->keys[i];
+
+- /* Considering SMP over BREDR/LE, there is no need to check addr_type */
+- if (key->type > 0x08)
++ if (key->addr.type != BDADDR_BREDR || key->type > 0x08)
+ return mgmt_cmd_status(sk, hdev->id,
+ MGMT_OP_LOAD_LINK_KEYS,
+ MGMT_STATUS_INVALID_PARAMS);
+@@ -5919,7 +5918,6 @@ static int load_irks(struct sock *sk, st
+
+ for (i = 0; i < irk_count; i++) {
+ struct mgmt_irk_info *irk = &cp->irks[i];
+- u8 addr_type = le_addr_type(irk->addr.type);
+
+ if (hci_is_blocked_key(hdev,
+ HCI_BLOCKED_KEY_TYPE_IRK,
+@@ -5929,12 +5927,8 @@ static int load_irks(struct sock *sk, st
+ continue;
+ }
+
+- /* When using SMP over BR/EDR, the addr type should be set to BREDR */
+- if (irk->addr.type == BDADDR_BREDR)
+- addr_type = BDADDR_BREDR;
+-
+ hci_add_irk(hdev, &irk->addr.bdaddr,
+- addr_type, irk->val,
++ le_addr_type(irk->addr.type), irk->val,
+ BDADDR_ANY);
+ }
+
+@@ -6015,7 +6009,6 @@ static int load_long_term_keys(struct so
+ for (i = 0; i < key_count; i++) {
+ struct mgmt_ltk_info *key = &cp->keys[i];
+ u8 type, authenticated;
+- u8 addr_type = le_addr_type(key->addr.type);
+
+ if (hci_is_blocked_key(hdev,
+ HCI_BLOCKED_KEY_TYPE_LTK,
+@@ -6050,12 +6043,8 @@ static int load_long_term_keys(struct so
+ continue;
+ }
+
+- /* When using SMP over BR/EDR, the addr type should be set to BREDR */
+- if (key->addr.type == BDADDR_BREDR)
+- addr_type = BDADDR_BREDR;
+-
+ hci_add_ltk(hdev, &key->addr.bdaddr,
+- addr_type, type, authenticated,
++ le_addr_type(key->addr.type), type, authenticated,
+ key->val, key->enc_size, key->ediv, key->rand);
+ }
+
+@@ -8058,7 +8047,7 @@ void mgmt_new_link_key(struct hci_dev *h
+
+ ev.store_hint = persistent;
+ bacpy(&ev.key.addr.bdaddr, &key->bdaddr);
+- ev.key.addr.type = link_to_bdaddr(key->link_type, key->bdaddr_type);
++ ev.key.addr.type = BDADDR_BREDR;
+ ev.key.type = key->type;
+ memcpy(ev.key.val, key->val, HCI_LINK_KEY_SIZE);
+ ev.key.pin_len = key->pin_len;
+@@ -8109,7 +8098,7 @@ void mgmt_new_ltk(struct hci_dev *hdev,
+ ev.store_hint = persistent;
+
+ bacpy(&ev.key.addr.bdaddr, &key->bdaddr);
+- ev.key.addr.type = link_to_bdaddr(key->link_type, key->bdaddr_type);
++ ev.key.addr.type = link_to_bdaddr(LE_LINK, key->bdaddr_type);
+ ev.key.type = mgmt_ltk_type(key);
+ ev.key.enc_size = key->enc_size;
+ ev.key.ediv = key->ediv;
+@@ -8138,7 +8127,7 @@ void mgmt_new_irk(struct hci_dev *hdev,
+
+ bacpy(&ev.rpa, &irk->rpa);
+ bacpy(&ev.irk.addr.bdaddr, &irk->bdaddr);
+- ev.irk.addr.type = link_to_bdaddr(irk->link_type, irk->addr_type);
++ ev.irk.addr.type = link_to_bdaddr(LE_LINK, irk->addr_type);
+ memcpy(ev.irk.val, irk->val, sizeof(irk->val));
+
+ mgmt_event(MGMT_EV_NEW_IRK, hdev, &ev, sizeof(ev), NULL);
+@@ -8167,7 +8156,7 @@ void mgmt_new_csrk(struct hci_dev *hdev,
+ ev.store_hint = persistent;
+
+ bacpy(&ev.key.addr.bdaddr, &csrk->bdaddr);
+- ev.key.addr.type = link_to_bdaddr(csrk->link_type, csrk->bdaddr_type);
++ ev.key.addr.type = link_to_bdaddr(LE_LINK, csrk->bdaddr_type);
+ ev.key.type = csrk->type;
+ memcpy(ev.key.val, csrk->val, sizeof(csrk->val));
+
+--- a/net/bluetooth/smp.c
++++ b/net/bluetooth/smp.c
+@@ -1060,7 +1060,6 @@ static void smp_notify_keys(struct l2cap
+ }
+
+ if (smp->remote_irk) {
+- smp->remote_irk->link_type = hcon->type;
+ mgmt_new_irk(hdev, smp->remote_irk, persistent);
+
+ /* Now that user space can be considered to know the
+@@ -1075,28 +1074,24 @@ static void smp_notify_keys(struct l2cap
+ }
+
+ if (smp->csrk) {
+- smp->csrk->link_type = hcon->type;
+ smp->csrk->bdaddr_type = hcon->dst_type;
+ bacpy(&smp->csrk->bdaddr, &hcon->dst);
+ mgmt_new_csrk(hdev, smp->csrk, persistent);
+ }
+
+ if (smp->responder_csrk) {
+- smp->responder_csrk->link_type = hcon->type;
+ smp->responder_csrk->bdaddr_type = hcon->dst_type;
+ bacpy(&smp->responder_csrk->bdaddr, &hcon->dst);
+ mgmt_new_csrk(hdev, smp->responder_csrk, persistent);
+ }
+
+ if (smp->ltk) {
+- smp->ltk->link_type = hcon->type;
+ smp->ltk->bdaddr_type = hcon->dst_type;
+ bacpy(&smp->ltk->bdaddr, &hcon->dst);
+ mgmt_new_ltk(hdev, smp->ltk, persistent);
+ }
+
+ if (smp->responder_ltk) {
+- smp->responder_ltk->link_type = hcon->type;
+ smp->responder_ltk->bdaddr_type = hcon->dst_type;
+ bacpy(&smp->responder_ltk->bdaddr, &hcon->dst);
+ mgmt_new_ltk(hdev, smp->responder_ltk, persistent);
+@@ -1116,8 +1111,6 @@ static void smp_notify_keys(struct l2cap
+ key = hci_add_link_key(hdev, smp->conn->hcon, &hcon->dst,
+ smp->link_key, type, 0, &persistent);
+ if (key) {
+- key->link_type = hcon->type;
+- key->bdaddr_type = hcon->dst_type;
+ mgmt_new_link_key(hdev, key, persistent);
+
+ /* Don't keep debug keys around if the relevant
alsa-hda-realtek-support-mute-led-on-hp-laptop-14-dq2xxx.patch
ata-libata-fix-memory-leak-for-error-path-in-ata_host_alloc.patch
irqchip-gic-v2m-fix-refcount-leak-in-gicv2m_of_init.patch
+revert-bluetooth-mgmt-smp-fix-address-type-when-using-smp-over-bredr-le.patch
+bluetooth-mgmt-ignore-keys-being-loaded-with-invalid-type.patch
+mmc-dw_mmc-fix-idmac-operation-with-pages-bigger-than-4k.patch
+mmc-sdhci-of-aspeed-fix-module-autoloading.patch
+fuse-update-stats-for-pages-in-dropped-aux-writeback-list.patch
+fuse-use-unsigned-type-for-getxattr-listxattr-size-truncation.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
