--- /dev/null
+From 5fddf8962b429b8303c4a654291ecb6e61a7d747 Mon Sep 17 00:00:00 2001
+From: Shuah Khan <skhan@linuxfoundation.org>
+Date: Tue, 11 Oct 2022 11:14:17 -0600
+Subject: docs: update mediator contact information in CoC doc
+
+From: Shuah Khan <skhan@linuxfoundation.org>
+
+commit 5fddf8962b429b8303c4a654291ecb6e61a7d747 upstream.
+
+Update mediator contact information in CoC interpretation document.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
+Link: https://lore.kernel.org/r/20221011171417.34286-1-skhan@linuxfoundation.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/process/code-of-conduct-interpretation.rst | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/Documentation/process/code-of-conduct-interpretation.rst
++++ b/Documentation/process/code-of-conduct-interpretation.rst
+@@ -51,7 +51,7 @@ the Technical Advisory Board (TAB) or ot
+ uncertain how to handle situations that come up. It will not be
+ considered a violation report unless you want it to be. If you are
+ uncertain about approaching the TAB or any other maintainers, please
+-reach out to our conflict mediator, Joanna Lee <joanna.lee@gesmer.com>.
++reach out to our conflict mediator, Joanna Lee <jlee@linuxfoundation.org>.
+
+ In the end, "be kind to each other" is really what the end goal is for
+ everybody. We know everyone is human and we all fail at times, but the
--- /dev/null
+From 65946690ed8d972fdb91a74ee75ac0f0f0d68321 Mon Sep 17 00:00:00 2001
+From: Brian Norris <briannorris@chromium.org>
+Date: Wed, 19 Oct 2022 18:10:53 -0700
+Subject: firmware: coreboot: Register bus in module init
+
+From: Brian Norris <briannorris@chromium.org>
+
+commit 65946690ed8d972fdb91a74ee75ac0f0f0d68321 upstream.
+
+The coreboot_table driver registers a coreboot bus while probing a
+"coreboot_table" device representing the coreboot table memory region.
+Probing this device (i.e., registering the bus) is a dependency for the
+module_init() functions of any driver for this bus (e.g.,
+memconsole-coreboot.c / memconsole_driver_init()).
+
+With synchronous probe, this dependency works OK, as the link order in
+the Makefile ensures coreboot_table_driver_init() (and thus,
+coreboot_table_probe()) completes before a coreboot device driver tries
+to add itself to the bus.
+
+With asynchronous probe, however, coreboot_table_probe() may race with
+memconsole_driver_init(), and so we're liable to hit one of these two:
+
+1. coreboot_driver_register() eventually hits "[...] the bus was not
+ initialized.", and the memconsole driver fails to register; or
+2. coreboot_driver_register() gets past #1, but still races with
+ bus_register() and hits some other undefined/crashing behavior (e.g.,
+ in driver_find() [1])
+
+We can resolve this by registering the bus in our initcall, and only
+deferring "device" work (scanning the coreboot memory region and
+creating sub-devices) to probe().
+
+[1] Example failure, using 'driver_async_probe=*' kernel command line:
+
+[ 0.114217] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
+...
+[ 0.114307] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc1 #63
+[ 0.114316] Hardware name: Google Scarlet (DT)
+...
+[ 0.114488] Call trace:
+[ 0.114494] _raw_spin_lock+0x34/0x60
+[ 0.114502] kset_find_obj+0x28/0x84
+[ 0.114511] driver_find+0x30/0x50
+[ 0.114520] driver_register+0x64/0x10c
+[ 0.114528] coreboot_driver_register+0x30/0x3c
+[ 0.114540] memconsole_driver_init+0x24/0x30
+[ 0.114550] do_one_initcall+0x154/0x2e0
+[ 0.114560] do_initcall_level+0x134/0x160
+[ 0.114571] do_initcalls+0x60/0xa0
+[ 0.114579] do_basic_setup+0x28/0x34
+[ 0.114588] kernel_init_freeable+0xf8/0x150
+[ 0.114596] kernel_init+0x2c/0x12c
+[ 0.114607] ret_from_fork+0x10/0x20
+[ 0.114624] Code: 5280002b 1100054a b900092a f9800011 (885ffc01)
+[ 0.114631] ---[ end trace 0000000000000000 ]---
+
+Fixes: b81e3140e412 ("firmware: coreboot: Make bus registration symmetric")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Reviewed-by: Stephen Boyd <swboyd@chromium.org>
+Link: https://lore.kernel.org/r/20221019180934.1.If29e167d8a4771b0bf4a39c89c6946ed764817b9@changeid
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/google/coreboot_table.c | 37 ++++++++++++++++++++++++-------
+ 1 file changed, 29 insertions(+), 8 deletions(-)
+
+--- a/drivers/firmware/google/coreboot_table.c
++++ b/drivers/firmware/google/coreboot_table.c
+@@ -149,12 +149,8 @@ static int coreboot_table_probe(struct p
+ if (!ptr)
+ return -ENOMEM;
+
+- ret = bus_register(&coreboot_bus_type);
+- if (!ret) {
+- ret = coreboot_table_populate(dev, ptr);
+- if (ret)
+- bus_unregister(&coreboot_bus_type);
+- }
++ ret = coreboot_table_populate(dev, ptr);
++
+ memunmap(ptr);
+
+ return ret;
+@@ -169,7 +165,6 @@ static int __cb_dev_unregister(struct de
+ static int coreboot_table_remove(struct platform_device *pdev)
+ {
+ bus_for_each_dev(&coreboot_bus_type, NULL, NULL, __cb_dev_unregister);
+- bus_unregister(&coreboot_bus_type);
+ return 0;
+ }
+
+@@ -199,6 +194,32 @@ static struct platform_driver coreboot_t
+ .of_match_table = of_match_ptr(coreboot_of_match),
+ },
+ };
+-module_platform_driver(coreboot_table_driver);
++
++static int __init coreboot_table_driver_init(void)
++{
++ int ret;
++
++ ret = bus_register(&coreboot_bus_type);
++ if (ret)
++ return ret;
++
++ ret = platform_driver_register(&coreboot_table_driver);
++ if (ret) {
++ bus_unregister(&coreboot_bus_type);
++ return ret;
++ }
++
++ return 0;
++}
++
++static void __exit coreboot_table_driver_exit(void)
++{
++ platform_driver_unregister(&coreboot_table_driver);
++ bus_unregister(&coreboot_bus_type);
++}
++
++module_init(coreboot_table_driver_init);
++module_exit(coreboot_table_driver_exit);
++
+ MODULE_AUTHOR("Google, Inc.");
+ MODULE_LICENSE("GPL");
--- /dev/null
+From 242b0aaeabbe2efbef1b9d42a8e56627e800964c Mon Sep 17 00:00:00 2001
+From: Tina Zhang <tina.zhang@intel.com>
+Date: Wed, 16 Nov 2022 13:15:43 +0800
+Subject: iommu/vt-d: Preset Access bit for IOVA in FL non-leaf paging entries
+
+From: Tina Zhang <tina.zhang@intel.com>
+
+commit 242b0aaeabbe2efbef1b9d42a8e56627e800964c upstream.
+
+The A/D bits are preseted for IOVA over first level(FL) usage for both
+kernel DMA (i.e, domain typs is IOMMU_DOMAIN_DMA) and user space DMA
+usage (i.e., domain type is IOMMU_DOMAIN_UNMANAGED).
+
+Presetting A bit in FL requires to preset the bit in every related paging
+entries, including the non-leaf ones. Otherwise, hardware may treat this
+as an error. For example, in a case of ECAP_REG.SMPWC==0, DMA faults might
+occur with below DMAR fault messages (wrapped for line length) dumped.
+
+ DMAR: DRHD: handling fault status reg 2
+ DMAR: [DMA Read NO_PASID] Request device [aa:00.0] fault addr 0x10c3a6000
+ [fault reason 0x90]
+ SM: A/D bit update needed in first-level entry when set up in no snoop
+
+Fixes: 289b3b005cb9 ("iommu/vt-d: Preset A/D bits for user space DMA usage")
+Cc: stable@vger.kernel.org
+Signed-off-by: Tina Zhang <tina.zhang@intel.com>
+Link: https://lore.kernel.org/r/20221113010324.1094483-1-tina.zhang@intel.com
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Link: https://lore.kernel.org/r/20221116051544.26540-2-baolu.lu@linux.intel.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/iommu.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/drivers/iommu/intel/iommu.c
++++ b/drivers/iommu/intel/iommu.c
+@@ -1048,11 +1048,9 @@ static struct dma_pte *pfn_to_dma_pte(st
+
+ domain_flush_cache(domain, tmp_page, VTD_PAGE_SIZE);
+ pteval = ((uint64_t)virt_to_dma_pfn(tmp_page) << VTD_PAGE_SHIFT) | DMA_PTE_READ | DMA_PTE_WRITE;
+- if (domain_use_first_level(domain)) {
+- pteval |= DMA_FL_PTE_XD | DMA_FL_PTE_US;
+- if (iommu_is_dma_domain(&domain->domain))
+- pteval |= DMA_FL_PTE_ACCESS;
+- }
++ if (domain_use_first_level(domain))
++ pteval |= DMA_FL_PTE_XD | DMA_FL_PTE_US | DMA_FL_PTE_ACCESS;
++
+ if (cmpxchg64(&pte->val, 0ULL, pteval))
+ /* Someone else set it while we were thinking; use theirs. */
+ free_pgtable_page(tmp_page);
--- /dev/null
+From 7fc961cf7ffcb130c4e93ee9a5628134f9de700a Mon Sep 17 00:00:00 2001
+From: Tina Zhang <tina.zhang@intel.com>
+Date: Wed, 16 Nov 2022 13:15:44 +0800
+Subject: iommu/vt-d: Set SRE bit only when hardware has SRS cap
+
+From: Tina Zhang <tina.zhang@intel.com>
+
+commit 7fc961cf7ffcb130c4e93ee9a5628134f9de700a upstream.
+
+SRS cap is the hardware cap telling if the hardware IOMMU can support
+requests seeking supervisor privilege or not. SRE bit in scalable-mode
+PASID table entry is treated as Reserved(0) for implementation not
+supporting SRS cap.
+
+Checking SRS cap before setting SRE bit can avoid the non-recoverable
+fault of "Non-zero reserved field set in PASID Table Entry" caused by
+setting SRE bit while there is no SRS cap support. The fault messages
+look like below:
+
+ DMAR: DRHD: handling fault status reg 2
+ DMAR: [DMA Read NO_PASID] Request device [00:0d.0] fault addr 0x1154e1000
+ [fault reason 0x5a]
+ SM: Non-zero reserved field set in PASID Table Entry
+
+Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table interface")
+Cc: stable@vger.kernel.org
+Signed-off-by: Tina Zhang <tina.zhang@intel.com>
+Link: https://lore.kernel.org/r/20221115070346.1112273-1-tina.zhang@intel.com
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Link: https://lore.kernel.org/r/20221116051544.26540-3-baolu.lu@linux.intel.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/pasid.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/iommu/intel/pasid.c
++++ b/drivers/iommu/intel/pasid.c
+@@ -717,7 +717,7 @@ int intel_pasid_setup_second_level(struc
+ * Since it is a second level only translation setup, we should
+ * set SRE bit as well (addresses are expected to be GPAs).
+ */
+- if (pasid != PASID_RID2PASID)
++ if (pasid != PASID_RID2PASID && ecap_srs(iommu->ecap))
+ pasid_set_sre(pte);
+ pasid_set_present(pte);
+ pasid_flush_caches(iommu, pte, pasid, did);
+@@ -756,7 +756,8 @@ int intel_pasid_setup_pass_through(struc
+ * We should set SRE bit as well since the addresses are expected
+ * to be GPAs.
+ */
+- pasid_set_sre(pte);
++ if (ecap_srs(iommu->ecap))
++ pasid_set_sre(pte);
+ pasid_set_present(pte);
+ pasid_flush_caches(iommu, pte, pasid, did);
+
--- /dev/null
+From e5b0d06d9b10f5f43101bd6598b076c347f9295f Mon Sep 17 00:00:00 2001
+From: Alexander Potapenko <glider@google.com>
+Date: Fri, 4 Nov 2022 18:58:49 +0100
+Subject: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()
+
+From: Alexander Potapenko <glider@google.com>
+
+commit e5b0d06d9b10f5f43101bd6598b076c347f9295f upstream.
+
+`struct vmci_event_qp` allocated by qp_notify_peer() contains padding,
+which may carry uninitialized data to the userspace, as observed by
+KMSAN:
+
+ BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121
+ instrument_copy_to_user ./include/linux/instrumented.h:121
+ _copy_to_user+0x5f/0xb0 lib/usercopy.c:33
+ copy_to_user ./include/linux/uaccess.h:169
+ vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431
+ vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925
+ vfs_ioctl fs/ioctl.c:51
+ ...
+
+ Uninit was stored to memory at:
+ kmemdup+0x74/0xb0 mm/util.c:131
+ dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271
+ vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339
+ qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479
+ qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
+ qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750
+ vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940
+ vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488
+ vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927
+ ...
+
+ Local variable ev created at:
+ qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456
+ qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662
+ qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750
+
+ Bytes 28-31 of 48 are uninitialized
+ Memory access of size 48 starts at ffff888035155e00
+ Data copied to user address 0000000020000100
+
+Use memset() to prevent the infoleaks.
+
+Also speculatively fix qp_notify_peer_local(), which may suffer from the
+same problem.
+
+Reported-by: syzbot+39be4da489ed2493ba25@syzkaller.appspotmail.com
+Cc: stable <stable@kernel.org>
+Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.")
+Signed-off-by: Alexander Potapenko <glider@google.com>
+Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
+Link: https://lore.kernel.org/r/20221104175849.2782567-1-glider@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/vmw_vmci/vmci_queue_pair.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
++++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
+@@ -854,6 +854,7 @@ static int qp_notify_peer_local(bool att
+ u32 context_id = vmci_get_context_id();
+ struct vmci_event_qp ev;
+
++ memset(&ev, 0, sizeof(ev));
+ ev.msg.hdr.dst = vmci_make_handle(context_id, VMCI_EVENT_HANDLER);
+ ev.msg.hdr.src = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
+ VMCI_CONTEXT_RESOURCE_ID);
+@@ -1467,6 +1468,7 @@ static int qp_notify_peer(bool attach,
+ * kernel.
+ */
+
++ memset(&ev, 0, sizeof(ev));
+ ev.msg.hdr.dst = vmci_make_handle(peer_id, VMCI_EVENT_HANDLER);
+ ev.msg.hdr.src = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
+ VMCI_CONTEXT_RESOURCE_ID);
--- /dev/null
+From 39a72dbfe188291b156dd6523511e3d5761ce775 Mon Sep 17 00:00:00 2001
+From: Yann Gautier <yann.gautier@foss.st.com>
+Date: Fri, 28 Oct 2022 09:37:40 +0200
+Subject: mmc: core: properly select voltage range without power cycle
+
+From: Yann Gautier <yann.gautier@foss.st.com>
+
+commit 39a72dbfe188291b156dd6523511e3d5761ce775 upstream.
+
+In mmc_select_voltage(), if there is no full power cycle, the voltage
+range selected at the end of the function will be on a single range
+(e.g. 3.3V/3.4V). To keep a range around the selected voltage (3.2V/3.4V),
+the mask shift should be reduced by 1.
+
+This issue was triggered by using a specific SD-card (Verbatim Premium
+16GB UHS-1) on an STM32MP157C-DK2 board. This board cannot do UHS modes
+and there is no power cycle. And the card was failing to switch to
+high-speed mode. When adding the range 3.2V/3.3V for this card with the
+proposed shift change, the card can switch to high-speed mode.
+
+Fixes: ce69d37b7d8f ("mmc: core: Prevent violation of specs while initializing cards")
+Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20221028073740.7259-1-yann.gautier@foss.st.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/core/core.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/mmc/core/core.c
++++ b/drivers/mmc/core/core.c
+@@ -1132,7 +1132,13 @@ u32 mmc_select_voltage(struct mmc_host *
+ mmc_power_cycle(host, ocr);
+ } else {
+ bit = fls(ocr) - 1;
+- ocr &= 3 << bit;
++ /*
++ * The bit variable represents the highest voltage bit set in
++ * the OCR register.
++ * To keep a range of 2 values (e.g. 3.2V/3.3V and 3.3V/3.4V),
++ * we must shift the mask '3' with (bit - 1).
++ */
++ ocr &= 3 << (bit - 1);
+ if (bit != host->ios.vdd)
+ dev_warn(mmc_dev(host), "exceeding card's volts\n");
+ }
--- /dev/null
+From 222cfa0118aa68687ace74aab8fdf77ce8fbd7e6 Mon Sep 17 00:00:00 2001
+From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
+Date: Mon, 14 Nov 2022 16:31:00 +0800
+Subject: mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()
+
+From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
+
+commit 222cfa0118aa68687ace74aab8fdf77ce8fbd7e6 upstream.
+
+pci_get_device() will increase the reference count for the returned
+pci_dev. We need to use pci_dev_put() to decrease the reference count
+before amd_probe() returns. There is no problem for the 'smbus_dev ==
+NULL' branch because pci_dev_put() can also handle the NULL input
+parameter case.
+
+Fixes: 659c9bc114a8 ("mmc: sdhci-pci: Build o2micro support in the same module")
+Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20221114083100.149200-1-wangxiongfeng2@huawei.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-pci-core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-pci-core.c
++++ b/drivers/mmc/host/sdhci-pci-core.c
+@@ -1818,6 +1818,8 @@ static int amd_probe(struct sdhci_pci_ch
+ }
+ }
+
++ pci_dev_put(smbus_dev);
++
+ if (gen == AMD_CHIPSET_BEFORE_ML || gen == AMD_CHIPSET_CZ)
+ chip->quirks2 |= SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD;
+
--- /dev/null
+From 096cc0cddf58232bded309336961784f1d1c85f8 Mon Sep 17 00:00:00 2001
+From: Chevron Li <chevron.li@bayhubtech.com>
+Date: Fri, 4 Nov 2022 02:55:12 -0700
+Subject: mmc: sdhci-pci-o2micro: fix card detect fail issue caused by CD# debounce timeout
+
+From: Chevron Li <chevron.li@bayhubtech.com>
+
+commit 096cc0cddf58232bded309336961784f1d1c85f8 upstream.
+
+The SD card is recognized failed sometimes when resume from suspend.
+Because CD# debounce time too long then card present report wrong.
+Finally, card is recognized failed.
+
+Signed-off-by: Chevron Li <chevron.li@bayhubtech.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20221104095512.4068-1-chevron.li@bayhubtech.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/sdhci-pci-o2micro.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-pci-o2micro.c
++++ b/drivers/mmc/host/sdhci-pci-o2micro.c
+@@ -31,6 +31,7 @@
+ #define O2_SD_CAPS 0xE0
+ #define O2_SD_ADMA1 0xE2
+ #define O2_SD_ADMA2 0xE7
++#define O2_SD_MISC_CTRL2 0xF0
+ #define O2_SD_INF_MOD 0xF1
+ #define O2_SD_MISC_CTRL4 0xFC
+ #define O2_SD_MISC_CTRL 0x1C0
+@@ -830,6 +831,12 @@ static int sdhci_pci_o2_probe(struct sdh
+ /* Set Tuning Windows to 5 */
+ pci_write_config_byte(chip->pdev,
+ O2_SD_TUNING_CTRL, 0x55);
++ //Adjust 1st and 2nd CD debounce time
++ pci_read_config_dword(chip->pdev, O2_SD_MISC_CTRL2, &scratch_32);
++ scratch_32 &= 0xFFE7FFFF;
++ scratch_32 |= 0x00180000;
++ pci_write_config_dword(chip->pdev, O2_SD_MISC_CTRL2, scratch_32);
++ pci_write_config_dword(chip->pdev, O2_SD_DETECT_SETTING, 1);
+ /* Lock WP */
+ ret = pci_read_config_byte(chip->pdev,
+ O2_SD_LOCK_WP, &scratch);
--- /dev/null
+From ce0d998be9274dd3a3d971cbeaa6fe28fd2c3062 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Sat, 12 Nov 2022 17:15:08 +0200
+Subject: perf/x86/intel/pt: Fix sampling using single range output
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit ce0d998be9274dd3a3d971cbeaa6fe28fd2c3062 upstream.
+
+Deal with errata TGL052, ADL037 and RPL017 "Trace May Contain Incorrect
+Data When Configured With Single Range Output Larger Than 4KB" by
+disabling single range output whenever larger than 4KB.
+
+Fixes: 670638477aed ("perf/x86/intel/pt: Opportunistically use single range output mode")
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20221112151508.13768-1-adrian.hunter@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/events/intel/pt.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/arch/x86/events/intel/pt.c
++++ b/arch/x86/events/intel/pt.c
+@@ -1247,6 +1247,15 @@ static int pt_buffer_try_single(struct p
+ if (1 << order != nr_pages)
+ goto out;
+
++ /*
++ * Some processors cannot always support single range for more than
++ * 4KB - refer errata TGL052, ADL037 and RPL017. Future processors might
++ * also be affected, so for now rather than trying to keep track of
++ * which ones, just disable it for all.
++ */
++ if (nr_pages > 1)
++ goto out;
++
+ buf->single = true;
+ buf->nr_pages = nr_pages;
+ ret = 0;
maccess-fix-writing-offset-in-case-of-fault-in-strncpy_from_kernel_nofault.patch
net-phy-marvell-add-sleep-time-after-enabling-the-loopback-bit.patch
scsi-zfcp-fix-double-free-of-fsf-request-when-qdio-send-fails.patch
+iommu-vt-d-preset-access-bit-for-iova-in-fl-non-leaf-paging-entries.patch
+iommu-vt-d-set-sre-bit-only-when-hardware-has-srs-cap.patch
+firmware-coreboot-register-bus-in-module-init.patch
+mmc-core-properly-select-voltage-range-without-power-cycle.patch
+mmc-sdhci-pci-o2micro-fix-card-detect-fail-issue-caused-by-cd-debounce-timeout.patch
+mmc-sdhci-pci-fix-possible-memory-leak-caused-by-missing-pci_dev_put.patch
+docs-update-mediator-contact-information-in-coc-doc.patch
+misc-vmw_vmci-fix-an-infoleak-in-vmci_host_do_receive_datagram.patch
+perf-x86-intel-pt-fix-sampling-using-single-range-output.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
