diff options
Diffstat (limited to 'SOURCES/zen.patch')
| -rw-r--r-- | SOURCES/zen.patch | 109 |
1 files changed, 0 insertions, 109 deletions
diff --git a/SOURCES/zen.patch b/SOURCES/zen.patch index 8507e36..9c7003c 100644 --- a/SOURCES/zen.patch +++ b/SOURCES/zen.patch @@ -591,112 +591,3 @@ index ef15ec4..3a0d083 100644 if (!strcmp(str, "hwp_only")) -- 2.28.0 - -From: Sathish Narasimman <nsathish41@gmail.com> -Subject: [PATCH] Bluetooth: Fix: LL PRivacy BLE device fails to connect -Date: Thu, 22 Oct 2020 13:53:04 +0530 - -When adding device to white list the device is added to resolving list -also it has to be added only when HCI_ENABLE_LL_PRIVACY flag is set. -HCI_ENABLE_LL_PRIVACY flag has to be tested before adding/deleting devices -to resolving list. use_ll_privacy macro is used only to check if controller -supports LL_Privacy. - -https://bugzilla.kernel.org/show_bug.cgi?id=209745 - -Signed-off-by: Sathish Narasimman <sathish.narasimman@intel.com> ---- - net/bluetooth/hci_request.c | 12 ++++++++---- - 1 file changed, 8 insertions(+), 4 deletions(-) - -diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c -index e026919..f30bc18 100644 ---- a/net/bluetooth/hci_request.c -+++ b/net/bluetooth/hci_request.c -@@ -698,7 +698,8 @@ static void del_from_white_list(struct hci_request *req, bdaddr_t *bdaddr, - cp.bdaddr_type); - hci_req_add(req, HCI_OP_LE_DEL_FROM_WHITE_LIST, sizeof(cp), &cp); - -- if (use_ll_privacy(req->hdev)) { -+ if (use_ll_privacy(req->hdev) && -+ hci_dev_test_flag(req->hdev, HCI_ENABLE_LL_PRIVACY)) { - struct smp_irk *irk; - - irk = hci_find_irk_by_addr(req->hdev, bdaddr, bdaddr_type); -@@ -732,7 +733,8 @@ static int add_to_white_list(struct hci_request *req, - return -1; - - /* White list can not be used with RPAs */ -- if (!allow_rpa && !use_ll_privacy(hdev) && -+ if (!allow_rpa && -+ !hci_dev_test_flag(hdev, HCI_ENABLE_LL_PRIVACY) && - hci_find_irk_by_addr(hdev, ¶ms->addr, params->addr_type)) { - return -1; - } -@@ -750,7 +752,8 @@ static int add_to_white_list(struct hci_request *req, - cp.bdaddr_type); - hci_req_add(req, HCI_OP_LE_ADD_TO_WHITE_LIST, sizeof(cp), &cp); - -- if (use_ll_privacy(hdev)) { -+ if (use_ll_privacy(hdev) && -+ hci_dev_test_flag(hdev, HCI_ENABLE_LL_PRIVACY)) { - struct smp_irk *irk; - - irk = hci_find_irk_by_addr(hdev, ¶ms->addr, -@@ -812,7 +815,8 @@ static u8 update_white_list(struct hci_request *req) - } - - /* White list can not be used with RPAs */ -- if (!allow_rpa && !use_ll_privacy(hdev) && -+ if (!allow_rpa && -+ !hci_dev_test_flag(hdev, HCI_ENABLE_LL_PRIVACY) && - hci_find_irk_by_addr(hdev, &b->bdaddr, b->bdaddr_type)) { - return 0x00; - } - -From: Rajat Jain <rajatja@google.com> -Subject: [PATCH] PCI: Always call pci_enable_acs() regardless of pdev->acs_cap -Date: Wed, 28 Oct 2020 16:15:45 -0700 - -Some devices may have have anomalies with the ACS cpability structure, -and they may be using quirks to support ACS functionality via other -registers. For such devices, it is important we always call -pci_enable_acs() to give the quirks a chance to enable ACS in other ways. - -For Eg: -There seems a class of Intel devices quirked with *_intel_pch_acs_* -functions, that do not expose the standard ACS capability structure. But -these quirks help support ACS on these devices using other registers: -pci_quirk_enable_intel_pch_acs() -> doesn't use acs_cap to enable ACS - -This has already been taken care of in the quirks, in the other direction -i.e. when checking if the ACS is enabled or not. So no need to do -anything there. - -Reported-by: Boris V <borisvk@bstnet.org> -Fixes: 52fbf5bdeeef ("PCI: Cache ACS capability offset in device") -Signed-off-by: Rajat Jain <rajatja@google.com> ---- - drivers/pci/pci.c | 9 +++++++-- - 1 file changed, 7 insertions(+), 2 deletions(-) - -diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c -index e39c549..2e721e7 100644 ---- a/drivers/pci/pci.c -+++ b/drivers/pci/pci.c -@@ -3503,8 +3503,13 @@ void pci_acs_init(struct pci_dev *dev) - { - dev->acs_cap = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ACS); - -- if (dev->acs_cap) -- pci_enable_acs(dev); -+ /* -+ * Attempt to enable ACS regardless of capability because some rootports -+ * (e.g. the ones quirked with *_intel_pch_acs_*) may not expose -+ * standard rootport capability structure, but still may support ACS via -+ * those quirks. -+ */ -+ pci_enable_acs(dev); - } - - /** |