--- /dev/null
+From 47fe1c3064c6bc1bfa3c032ff78e603e5dd6e5bc Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Mon, 29 May 2023 16:32:37 +0900
+Subject: block: fix revalidate performance regression
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit 47fe1c3064c6bc1bfa3c032ff78e603e5dd6e5bc upstream.
+
+The scsi driver function sd_read_block_characteristics() always calls
+disk_set_zoned() to a disk zoned model correctly, in case the device
+model changed. This is done even for regular disks to set the zoned
+model to BLK_ZONED_NONE and free any zone related resources if the drive
+previously was zoned.
+
+This behavior significantly impact the time it takes to revalidate disks
+on a large system as the call to disk_clear_zone_settings() done from
+disk_set_zoned() for the BLK_ZONED_NONE case results in the device
+request queued to be frozen, even if there are no zone resources to
+free.
+
+Avoid this overhead for non-zoned devices by not calling
+disk_clear_zone_settings() in disk_set_zoned() if the device model
+was already set to BLK_ZONED_NONE, which is always the case for regular
+devices.
+
+Reported by: Brian Bunker <brian@purestorage.com>
+
+Fixes: 508aebb80527 ("block: introduce blk_queue_clear_zone_settings()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Ming Lei <ming.lei@redhat.com>
+Link: https://lore.kernel.org/r/20230529073237.1339862-1-dlemoal@kernel.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/blk-settings.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/block/blk-settings.c
++++ b/block/blk-settings.c
+@@ -909,6 +909,7 @@ static bool disk_has_partitions(struct g
+ void disk_set_zoned(struct gendisk *disk, enum blk_zoned_model model)
+ {
+ struct request_queue *q = disk->queue;
++ unsigned int old_model = q->limits.zoned;
+
+ switch (model) {
+ case BLK_ZONED_HM:
+@@ -946,7 +947,7 @@ void disk_set_zoned(struct gendisk *disk
+ */
+ blk_queue_zone_write_granularity(q,
+ queue_logical_block_size(q));
+- } else {
++ } else if (old_model != BLK_ZONED_NONE) {
+ disk_clear_zone_settings(disk);
+ }
+ }
--- /dev/null
+From 5ad9b4719fc9bc4715c7e19875a962095b0577e7 Mon Sep 17 00:00:00 2001
+From: pengfuyuan <pengfuyuan@kylinos.cn>
+Date: Tue, 23 May 2023 15:09:55 +0800
+Subject: btrfs: fix csum_tree_block page iteration to avoid tripping on -Werror=array-bounds
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: pengfuyuan <pengfuyuan@kylinos.cn>
+
+commit 5ad9b4719fc9bc4715c7e19875a962095b0577e7 upstream.
+
+When compiling on a MIPS 64-bit machine we get these warnings:
+
+ In file included from ./arch/mips/include/asm/cacheflush.h:13,
+ from ./include/linux/cacheflush.h:5,
+ from ./include/linux/highmem.h:8,
+ from ./include/linux/bvec.h:10,
+ from ./include/linux/blk_types.h:10,
+ from ./include/linux/blkdev.h:9,
+ from fs/btrfs/disk-io.c:7:
+ fs/btrfs/disk-io.c: In function ‘csum_tree_block’:
+ fs/btrfs/disk-io.c:100:34: error: array subscript 1 is above array bounds of ‘struct page *[1]’ [-Werror=array-bounds]
+ 100 | kaddr = page_address(buf->pages[i]);
+ | ~~~~~~~~~~^~~
+ ./include/linux/mm.h:2135:48: note: in definition of macro ‘page_address’
+ 2135 | #define page_address(page) lowmem_page_address(page)
+ | ^~~~
+ cc1: all warnings being treated as errors
+
+We can check if i overflows to solve the problem. However, this doesn't make
+much sense, since i == 1 and num_pages == 1 doesn't execute the body of the loop.
+In addition, i < num_pages can also ensure that buf->pages[i] will not cross
+the boundary. Unfortunately, this doesn't help with the problem observed here:
+gcc still complains.
+
+To fix this add a compile-time condition for the extent buffer page
+array size limit, which would eventually lead to eliminating the whole
+for loop.
+
+CC: stable@vger.kernel.org # 5.10+
+Signed-off-by: pengfuyuan <pengfuyuan@kylinos.cn>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/disk-io.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/disk-io.c
++++ b/fs/btrfs/disk-io.c
+@@ -104,7 +104,7 @@ static void csum_tree_block(struct exten
+ crypto_shash_update(shash, kaddr + BTRFS_CSUM_SIZE,
+ first_page_part - BTRFS_CSUM_SIZE);
+
+- for (i = 1; i < num_pages; i++) {
++ for (i = 1; i < num_pages && INLINE_EXTENT_BUFFER_PAGES > 1; i++) {
+ kaddr = page_address(buf->pages[i]);
+ crypto_shash_update(shash, kaddr, PAGE_SIZE);
+ }
--- /dev/null
+From 2212fc2acf3f6ee690ea36506fb882a19d1bfcab Mon Sep 17 00:00:00 2001
+From: Jon Pan-Doh <pandoh@google.com>
+Date: Wed, 26 Apr 2023 13:32:56 -0700
+Subject: iommu/amd: Fix domain flush size when syncing iotlb
+
+From: Jon Pan-Doh <pandoh@google.com>
+
+commit 2212fc2acf3f6ee690ea36506fb882a19d1bfcab upstream.
+
+When running on an AMD vIOMMU, we observed multiple invalidations (of
+decreasing power of 2 aligned sizes) when unmapping a single page.
+
+Domain flush takes gather bounds (end-start) as size param. However,
+gather->end is defined as the last inclusive address (start + size - 1).
+This leads to an off by 1 error.
+
+With this patch, verified that 1 invalidation occurs when unmapping a
+single page.
+
+Fixes: a270be1b3fdf ("iommu/amd: Use only natural aligned flushes in a VM")
+Cc: stable@vger.kernel.org # >= 5.15
+Signed-off-by: Jon Pan-Doh <pandoh@google.com>
+Tested-by: Sudheer Dantuluri <dantuluris@google.com>
+Suggested-by: Gary Zibrat <gzibrat@google.com>
+Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
+Acked-by: Nadav Amit <namit@vmware.com>
+Link: https://lore.kernel.org/r/20230426203256.237116-1-pandoh@google.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/amd/iommu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iommu/amd/iommu.c
++++ b/drivers/iommu/amd/iommu.c
+@@ -2396,7 +2396,7 @@ static void amd_iommu_iotlb_sync(struct
+ unsigned long flags;
+
+ spin_lock_irqsave(&dom->lock, flags);
+- domain_flush_pages(dom, gather->start, gather->end - gather->start, 1);
++ domain_flush_pages(dom, gather->start, gather->end - gather->start + 1, 1);
+ amd_iommu_domain_flush_complete(dom);
+ spin_unlock_irqrestore(&dom->lock, flags);
+ }
--- /dev/null
+From 11c439a19466e7feaccdbce148a75372fddaf4e9 Mon Sep 17 00:00:00 2001
+From: Vasant Hegde <vasant.hegde@amd.com>
+Date: Thu, 18 May 2023 05:43:51 +0000
+Subject: iommu/amd/pgtbl_v2: Fix domain max address
+
+From: Vasant Hegde <vasant.hegde@amd.com>
+
+commit 11c439a19466e7feaccdbce148a75372fddaf4e9 upstream.
+
+IOMMU v2 page table supports 4 level (47 bit) or 5 level (56 bit) virtual
+address space. Current code assumes it can support 64bit IOVA address
+space. If IOVA allocator allocates virtual address > 47/56 bit (depending
+on page table level) then it will do wrong mapping and cause invalid
+translation.
+
+Hence adjust aperture size to use max address supported by the page table.
+
+Reported-by: Jerry Snitselaar <jsnitsel@redhat.com>
+Fixes: aaac38f61487 ("iommu/amd: Initial support for AMD IOMMU v2 page table")
+Cc: <Stable@vger.kernel.org> # v6.0+
+Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
+Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
+Link: https://lore.kernel.org/r/20230518054351.9626-1-vasant.hegde@amd.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/amd/iommu.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/drivers/iommu/amd/iommu.c
++++ b/drivers/iommu/amd/iommu.c
+@@ -2101,6 +2101,15 @@ out_err:
+ return NULL;
+ }
+
++static inline u64 dma_max_address(void)
++{
++ if (amd_iommu_pgtable == AMD_IOMMU_V1)
++ return ~0ULL;
++
++ /* V2 with 4/5 level page table */
++ return ((1ULL << PM_LEVEL_SHIFT(amd_iommu_gpt_level)) - 1);
++}
++
+ static struct iommu_domain *amd_iommu_domain_alloc(unsigned type)
+ {
+ struct protection_domain *domain;
+@@ -2117,7 +2126,7 @@ static struct iommu_domain *amd_iommu_do
+ return NULL;
+
+ domain->domain.geometry.aperture_start = 0;
+- domain->domain.geometry.aperture_end = ~0ULL;
++ domain->domain.geometry.aperture_end = dma_max_address();
+ domain->domain.geometry.force_aperture = true;
+
+ return &domain->domain;
--- /dev/null
+From 0b5d5c436a5c572a45f976cfd34a6741e143e5d9 Mon Sep 17 00:00:00 2001
+From: Marek Vasut <marex@denx.de>
+Date: Sat, 13 May 2023 21:23:52 +0200
+Subject: mmc: pwrseq: sd8787: Fix WILC CHIP_EN and RESETN toggling order
+
+From: Marek Vasut <marex@denx.de>
+
+commit 0b5d5c436a5c572a45f976cfd34a6741e143e5d9 upstream.
+
+Chapter "5.3 Power-Up/Down Sequence" of WILC1000 [1] and WILC3000 [2]
+states that CHIP_EN must be pulled HIGH first, RESETN second. Fix the
+order of these signals in the driver.
+
+Use the mmc_pwrseq_ops as driver data as the delay between signals is
+specific to SDIO card type anyway.
+
+[1] https://ww1.microchip.com/downloads/aemDocuments/documents/WSG/ProductDocuments/DataSheets/ATWILC1000-MR110XB-IEEE-802.11-b-g-n-Link-Controller-Module-DS70005326E.pdf
+[2] https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/IEEE-802.11-b-g-n-Link-Controller-Module-with-Integrated-Bluetooth-5.0-DS70005327B.pdf
+
+Fixes: b2832b96fcf5 ("mmc: pwrseq: sd8787: add support for wilc1000")
+Signed-off-by: Marek Vasut <marex@denx.de>
+Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230513192352.479627-1-marex@denx.de
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/core/pwrseq_sd8787.c | 34 ++++++++++++++++++++++++++--------
+ 1 file changed, 26 insertions(+), 8 deletions(-)
+
+--- a/drivers/mmc/core/pwrseq_sd8787.c
++++ b/drivers/mmc/core/pwrseq_sd8787.c
+@@ -28,7 +28,6 @@ struct mmc_pwrseq_sd8787 {
+ struct mmc_pwrseq pwrseq;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *pwrdn_gpio;
+- u32 reset_pwrdwn_delay_ms;
+ };
+
+ #define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+@@ -39,7 +38,7 @@ static void mmc_pwrseq_sd8787_pre_power_
+
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+- msleep(pwrseq->reset_pwrdwn_delay_ms);
++ msleep(300);
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+ }
+
+@@ -51,17 +50,37 @@ static void mmc_pwrseq_sd8787_power_off(
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+ }
+
++static void mmc_pwrseq_wilc1000_pre_power_on(struct mmc_host *host)
++{
++ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
++
++ /* The pwrdn_gpio is really CHIP_EN, reset_gpio is RESETN */
++ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
++ msleep(5);
++ gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
++}
++
++static void mmc_pwrseq_wilc1000_power_off(struct mmc_host *host)
++{
++ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
++
++ gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
++ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
++}
++
+ static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+ .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+ .power_off = mmc_pwrseq_sd8787_power_off,
+ };
+
+-static const u32 sd8787_delay_ms = 300;
+-static const u32 wilc1000_delay_ms = 5;
++static const struct mmc_pwrseq_ops mmc_pwrseq_wilc1000_ops = {
++ .pre_power_on = mmc_pwrseq_wilc1000_pre_power_on,
++ .power_off = mmc_pwrseq_wilc1000_power_off,
++};
+
+ static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+- { .compatible = "mmc-pwrseq-sd8787", .data = &sd8787_delay_ms },
+- { .compatible = "mmc-pwrseq-wilc1000", .data = &wilc1000_delay_ms },
++ { .compatible = "mmc-pwrseq-sd8787", .data = &mmc_pwrseq_sd8787_ops },
++ { .compatible = "mmc-pwrseq-wilc1000", .data = &mmc_pwrseq_wilc1000_ops },
+ {/* sentinel */},
+ };
+ MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+@@ -77,7 +96,6 @@ static int mmc_pwrseq_sd8787_probe(struc
+ return -ENOMEM;
+
+ match = of_match_node(mmc_pwrseq_sd8787_of_match, pdev->dev.of_node);
+- pwrseq->reset_pwrdwn_delay_ms = *(u32 *)match->data;
+
+ pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->pwrdn_gpio))
+@@ -88,7 +106,7 @@ static int mmc_pwrseq_sd8787_probe(struc
+ return PTR_ERR(pwrseq->reset_gpio);
+
+ pwrseq->pwrseq.dev = dev;
+- pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
++ pwrseq->pwrseq.ops = match->data;
+ pwrseq->pwrseq.owner = THIS_MODULE;
+ platform_set_drvdata(pdev, pwrseq);
+
--- /dev/null
+From a99d21cefd351c8aaa20b83a3c942340e5789d45 Mon Sep 17 00:00:00 2001
+From: Deren Wu <deren.wu@mediatek.com>
+Date: Sat, 13 May 2023 22:48:15 +0800
+Subject: mmc: vub300: fix invalid response handling
+
+From: Deren Wu <deren.wu@mediatek.com>
+
+commit a99d21cefd351c8aaa20b83a3c942340e5789d45 upstream.
+
+We may get an empty response with zero length at the beginning of
+the driver start and get following UBSAN error. Since there is no
+content(SDRT_NONE) for the response, just return and skip the response
+handling to avoid this problem.
+
+Test pass : SDIO wifi throughput test with this patch
+
+[ 126.980684] UBSAN: array-index-out-of-bounds in drivers/mmc/host/vub300.c:1719:12
+[ 126.980709] index -1 is out of range for type 'u32 [4]'
+[ 126.980729] CPU: 4 PID: 9 Comm: kworker/u16:0 Tainted: G E 6.3.0-rc4-mtk-local-202304272142 #1
+[ 126.980754] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020
+[ 126.980770] Workqueue: kvub300c vub300_cmndwork_thread [vub300]
+[ 126.980833] Call Trace:
+[ 126.980845] <TASK>
+[ 126.980860] dump_stack_lvl+0x48/0x70
+[ 126.980895] dump_stack+0x10/0x20
+[ 126.980916] ubsan_epilogue+0x9/0x40
+[ 126.980944] __ubsan_handle_out_of_bounds+0x70/0x90
+[ 126.980979] vub300_cmndwork_thread+0x58e7/0x5e10 [vub300]
+[ 126.981018] ? _raw_spin_unlock+0x18/0x40
+[ 126.981042] ? finish_task_switch+0x175/0x6f0
+[ 126.981070] ? __switch_to+0x42e/0xda0
+[ 126.981089] ? __switch_to_asm+0x3a/0x80
+[ 126.981129] ? __pfx_vub300_cmndwork_thread+0x10/0x10 [vub300]
+[ 126.981174] ? __kasan_check_read+0x11/0x20
+[ 126.981204] process_one_work+0x7ee/0x13d0
+[ 126.981246] worker_thread+0x53c/0x1240
+[ 126.981291] kthread+0x2b8/0x370
+[ 126.981312] ? __pfx_worker_thread+0x10/0x10
+[ 126.981336] ? __pfx_kthread+0x10/0x10
+[ 126.981359] ret_from_fork+0x29/0x50
+[ 126.981400] </TASK>
+
+Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
+Signed-off-by: Deren Wu <deren.wu@mediatek.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/048cd6972c50c33c2e8f81d5228fed928519918b.1683987673.git.deren.wu@mediatek.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/vub300.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/mmc/host/vub300.c
++++ b/drivers/mmc/host/vub300.c
+@@ -1715,6 +1715,9 @@ static void construct_request_response(s
+ int bytes = 3 & less_cmd;
+ int words = less_cmd >> 2;
+ u8 *r = vub300->resp.response.command_response;
++
++ if (!resp_len)
++ return;
+ if (bytes == 3) {
+ cmd->resp[words] = (r[1 + (words << 2)] << 24)
+ | (r[2 + (words << 2)] << 16)
--- /dev/null
+From 9bf03a0cbd80a256bc1e1c4bcc80bc2b06b8b2b9 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan+linaro@kernel.org>
+Date: Tue, 2 May 2023 12:38:09 +0200
+Subject: phy: qcom-qmp-combo: fix init-count imbalance
+
+From: Johan Hovold <johan+linaro@kernel.org>
+
+commit 9bf03a0cbd80a256bc1e1c4bcc80bc2b06b8b2b9 upstream.
+
+The init counter is not decremented on initialisation errors, which
+prevents retrying initialisation and can lead to the runtime suspend
+callback attempting to disable resources that have never been enabled.
+
+Add the missing decrement on initialisation errors so that the counter
+reflects the state of the device.
+
+Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")
+Cc: stable@vger.kernel.org # 4.12
+Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
+Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Link: https://lore.kernel.org/r/20230502103810.12061-2-johan+linaro@kernel.org
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
++++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+@@ -1993,7 +1993,7 @@ static int qmp_combo_com_init(struct qmp
+ ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
+ if (ret) {
+ dev_err(qmp->dev, "failed to enable regulators, err=%d\n", ret);
+- goto err_unlock;
++ goto err_decrement_count;
+ }
+
+ ret = reset_control_bulk_assert(cfg->num_resets, qmp->resets);
+@@ -2048,7 +2048,8 @@ err_assert_reset:
+ reset_control_bulk_assert(cfg->num_resets, qmp->resets);
+ err_disable_regulators:
+ regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
+-err_unlock:
++err_decrement_count:
++ qmp->init_count--;
+ mutex_unlock(&qmp->phy_mutex);
+
+ return ret;
--- /dev/null
+From e42f110700ed7293700c26145e1ed07ea05ac3f6 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan+linaro@kernel.org>
+Date: Tue, 2 May 2023 12:38:10 +0200
+Subject: phy: qcom-qmp-pcie-msm8996: fix init-count imbalance
+
+From: Johan Hovold <johan+linaro@kernel.org>
+
+commit e42f110700ed7293700c26145e1ed07ea05ac3f6 upstream.
+
+The init counter is not decremented on initialisation errors, which
+prevents retrying initialisation.
+
+Add the missing decrement on initialisation errors so that the counter
+reflects the state of the device.
+
+Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")
+Cc: stable@vger.kernel.org # 4.12
+Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
+Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Link: https://lore.kernel.org/r/20230502103810.12061-3-johan+linaro@kernel.org
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c
++++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie-msm8996.c
+@@ -425,7 +425,7 @@ static int qmp_pcie_msm8996_com_init(str
+ ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
+ if (ret) {
+ dev_err(qmp->dev, "failed to enable regulators, err=%d\n", ret);
+- goto err_unlock;
++ goto err_decrement_count;
+ }
+
+ ret = reset_control_bulk_assert(cfg->num_resets, qmp->resets);
+@@ -455,7 +455,8 @@ err_assert_reset:
+ reset_control_bulk_assert(cfg->num_resets, qmp->resets);
+ err_disable_regulators:
+ regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
+-err_unlock:
++err_decrement_count:
++ qmp->init_count--;
+ mutex_unlock(&qmp->phy_mutex);
+
+ return ret;
--- /dev/null
+From 9d2ccf00bddc268045e3d65a8108d61ada0e4b4e Mon Sep 17 00:00:00 2001
+From: Gaurav Batra <gbatra@linux.vnet.ibm.com>
+Date: Thu, 25 May 2023 09:34:54 -0500
+Subject: powerpc/iommu: Limit number of TCEs to 512 for H_STUFF_TCE hcall
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Gaurav Batra <gbatra@linux.vnet.ibm.com>
+
+commit 9d2ccf00bddc268045e3d65a8108d61ada0e4b4e upstream.
+
+Currently in tce_freemulti_pSeriesLP() there is no limit on how many
+TCEs are passed to the H_STUFF_TCE hcall. This has not caused an issue
+until now, but newer firmware releases have started enforcing a limit of
+512 TCEs per call.
+
+The limit is correct per the specification (PAPR v2.12 § 14.5.4.2.3).
+
+The code has been in it's current form since it was initially merged.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Gaurav Batra <gbatra@linux.vnet.ibm.com>
+Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
+[mpe: Tweak change log wording & add PAPR reference]
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://msgid.link/20230525143454.56878-1-gbatra@linux.vnet.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/pseries/iommu.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/platforms/pseries/iommu.c
++++ b/arch/powerpc/platforms/pseries/iommu.c
+@@ -311,13 +311,22 @@ static void tce_free_pSeriesLP(unsigned
+ static void tce_freemulti_pSeriesLP(struct iommu_table *tbl, long tcenum, long npages)
+ {
+ u64 rc;
++ long rpages = npages;
++ unsigned long limit;
+
+ if (!firmware_has_feature(FW_FEATURE_STUFF_TCE))
+ return tce_free_pSeriesLP(tbl->it_index, tcenum,
+ tbl->it_page_shift, npages);
+
+- rc = plpar_tce_stuff((u64)tbl->it_index,
+- (u64)tcenum << tbl->it_page_shift, 0, npages);
++ do {
++ limit = min_t(unsigned long, rpages, 512);
++
++ rc = plpar_tce_stuff((u64)tbl->it_index,
++ (u64)tcenum << tbl->it_page_shift, 0, limit);
++
++ rpages -= limit;
++ tcenum += limit;
++ } while (rpages > 0 && !rc);
+
+ if (rc && printk_ratelimit()) {
+ printk("tce_freemulti_pSeriesLP: plpar_tce_stuff failed\n");
drm-amd-pm-reverse-mclk-clocks-levels-for-smu-v13.0.5.patch
drm-amd-pm-reverse-mclk-and-fclk-clocks-levels-for-yellow-carp.patch
drm-amd-pm-reverse-mclk-and-fclk-clocks-levels-for-renoir.patch
+x86-mtrr-revert-90b926e68f50-x86-pat-fix-pat_x_mtrr_type-for-mtrr-disabled-case.patch
+mmc-vub300-fix-invalid-response-handling.patch
+mmc-pwrseq-sd8787-fix-wilc-chip_en-and-resetn-toggling-order.patch
+tty-serial-fsl_lpuart-use-uartctrl_txinv-to-send-break-instead-of-uartctrl_sbk.patch
+btrfs-fix-csum_tree_block-page-iteration-to-avoid-tripping-on-werror-array-bounds.patch
+phy-qcom-qmp-combo-fix-init-count-imbalance.patch
+phy-qcom-qmp-pcie-msm8996-fix-init-count-imbalance.patch
+block-fix-revalidate-performance-regression.patch
+powerpc-iommu-limit-number-of-tces-to-512-for-h_stuff_tce-hcall.patch
+iommu-amd-fix-domain-flush-size-when-syncing-iotlb.patch
+iommu-amd-pgtbl_v2-fix-domain-max-address.patch
+tpm-tpm_tis-correct-tpm_tis_flags-enumeration-values.patch
--- /dev/null
+From 4ecd704a4c51fd95973fcc3a60444e0e24eb9439 Mon Sep 17 00:00:00 2001
+From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
+Date: Tue, 30 May 2023 18:41:16 +0200
+Subject: tpm, tpm_tis: correct tpm_tis_flags enumeration values
+
+From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
+
+commit 4ecd704a4c51fd95973fcc3a60444e0e24eb9439 upstream.
+
+With commit 858e8b792d06 ("tpm, tpm_tis: Avoid cache incoherency in test
+for interrupts") bit accessor functions are used to access flags in
+tpm_tis_data->flags.
+
+However these functions expect bit numbers, while the flags are defined
+as bit masks in enum tpm_tis_flag.
+
+Fix this inconsistency by using numbers instead of masks also for the
+flags in the enum.
+
+Reported-by: Pavel Machek <pavel@denx.de>
+Fixes: 858e8b792d06 ("tpm, tpm_tis: Avoid cache incoherency in test for interrupts")
+Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Pavel Machek <pavel@denx.de>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/tpm/tpm_tis_core.h | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
+index e978f457fd4d..610bfadb6acf 100644
+--- a/drivers/char/tpm/tpm_tis_core.h
++++ b/drivers/char/tpm/tpm_tis_core.h
+@@ -84,10 +84,10 @@ enum tis_defaults {
+ #define ILB_REMAP_SIZE 0x100
+
+ enum tpm_tis_flags {
+- TPM_TIS_ITPM_WORKAROUND = BIT(0),
+- TPM_TIS_INVALID_STATUS = BIT(1),
+- TPM_TIS_DEFAULT_CANCELLATION = BIT(2),
+- TPM_TIS_IRQ_TESTED = BIT(3),
++ TPM_TIS_ITPM_WORKAROUND = 0,
++ TPM_TIS_INVALID_STATUS = 1,
++ TPM_TIS_DEFAULT_CANCELLATION = 2,
++ TPM_TIS_IRQ_TESTED = 3,
+ };
+
+ struct tpm_tis_data {
+--
+2.41.0
+
--- /dev/null
+From 2474e05467c00f7d51af3039b664de6886325257 Mon Sep 17 00:00:00 2001
+From: Sherry Sun <sherry.sun@nxp.com>
+Date: Fri, 19 May 2023 17:47:51 +0800
+Subject: tty: serial: fsl_lpuart: use UARTCTRL_TXINV to send break instead of UARTCTRL_SBK
+
+From: Sherry Sun <sherry.sun@nxp.com>
+
+commit 2474e05467c00f7d51af3039b664de6886325257 upstream.
+
+LPUART IP now has two known bugs, one is that CTS has higher priority
+than the break signal, which causes the break signal sending through
+UARTCTRL_SBK may impacted by the CTS input if the HW flow control is
+enabled. It exists on all platforms we support in this driver.
+So we add a workaround patch for this issue: commit c4c81db5cf8b
+("tty: serial: fsl_lpuart: disable the CTS when send break signal").
+
+Another IP bug is i.MX8QM LPUART may have an additional break character
+being sent after SBK was cleared. It may need to add some delay between
+clearing SBK and re-enabling CTS to ensure that the SBK latch are
+completely cleared.
+
+But we found that during the delay period before CTS is enabled, there
+is still a risk that Bluetooth data in TX FIFO may be sent out during
+this period because of break off and CTS disabled(even if BT sets CTS
+line deasserted, data is still sent to BT).
+
+Due to this risk, we have to drop the CTS-disabling workaround for SBK
+bugs, use TXINV seems to be a better way to replace SBK feature and
+avoid above risk. Also need to disable the transmitter to prevent any
+data from being sent out during break, then invert the TX line to send
+break. Then disable the TXINV when turn off break and re-enable
+transmitter.
+
+Fixes: c4c81db5cf8b ("tty: serial: fsl_lpuart: disable the CTS when send break signal")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
+Link: https://lore.kernel.org/r/20230519094751.28948-1-sherry.sun@nxp.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/fsl_lpuart.c | 44 ++++++++++++++++++++--------------------
+ 1 file changed, 23 insertions(+), 21 deletions(-)
+
+--- a/drivers/tty/serial/fsl_lpuart.c
++++ b/drivers/tty/serial/fsl_lpuart.c
+@@ -1475,34 +1475,36 @@ static void lpuart_break_ctl(struct uart
+
+ static void lpuart32_break_ctl(struct uart_port *port, int break_state)
+ {
+- unsigned long temp, modem;
+- struct tty_struct *tty;
+- unsigned int cflag = 0;
++ unsigned long temp;
+
+- tty = tty_port_tty_get(&port->state->port);
+- if (tty) {
+- cflag = tty->termios.c_cflag;
+- tty_kref_put(tty);
+- }
+-
+- temp = lpuart32_read(port, UARTCTRL) & ~UARTCTRL_SBK;
+- modem = lpuart32_read(port, UARTMODIR);
++ temp = lpuart32_read(port, UARTCTRL);
+
++ /*
++ * LPUART IP now has two known bugs, one is CTS has higher priority than the
++ * break signal, which causes the break signal sending through UARTCTRL_SBK
++ * may impacted by the CTS input if the HW flow control is enabled. It
++ * exists on all platforms we support in this driver.
++ * Another bug is i.MX8QM LPUART may have an additional break character
++ * being sent after SBK was cleared.
++ * To avoid above two bugs, we use Transmit Data Inversion function to send
++ * the break signal instead of UARTCTRL_SBK.
++ */
+ if (break_state != 0) {
+- temp |= UARTCTRL_SBK;
+ /*
+- * LPUART CTS has higher priority than SBK, need to disable CTS before
+- * asserting SBK to avoid any interference if flow control is enabled.
++ * Disable the transmitter to prevent any data from being sent out
++ * during break, then invert the TX line to send break.
+ */
+- if (cflag & CRTSCTS && modem & UARTMODIR_TXCTSE)
+- lpuart32_write(port, modem & ~UARTMODIR_TXCTSE, UARTMODIR);
++ temp &= ~UARTCTRL_TE;
++ lpuart32_write(port, temp, UARTCTRL);
++ temp |= UARTCTRL_TXINV;
++ lpuart32_write(port, temp, UARTCTRL);
+ } else {
+- /* Re-enable the CTS when break off. */
+- if (cflag & CRTSCTS && !(modem & UARTMODIR_TXCTSE))
+- lpuart32_write(port, modem | UARTMODIR_TXCTSE, UARTMODIR);
++ /* Disable the TXINV to turn off break and re-enable transmitter. */
++ temp &= ~UARTCTRL_TXINV;
++ lpuart32_write(port, temp, UARTCTRL);
++ temp |= UARTCTRL_TE;
++ lpuart32_write(port, temp, UARTCTRL);
+ }
+-
+- lpuart32_write(port, temp, UARTCTRL);
+ }
+
+ static void lpuart_setup_watermark(struct lpuart_port *sport)
--- /dev/null
+From f9f57da2c2d119dbf109e3f6e1ceab7659294046 Mon Sep 17 00:00:00 2001
+From: Juergen Gross <jgross@suse.com>
+Date: Thu, 9 Feb 2023 08:22:17 +0100
+Subject: x86/mtrr: Revert 90b926e68f50 ("x86/pat: Fix pat_x_mtrr_type() for MTRR disabled case")
+
+From: Juergen Gross <jgross@suse.com>
+
+commit f9f57da2c2d119dbf109e3f6e1ceab7659294046 upstream.
+
+Commit
+
+ 90b926e68f50 ("x86/pat: Fix pat_x_mtrr_type() for MTRR disabled case")
+
+broke the use case of running Xen dom0 kernels on machines with an
+external disk enclosure attached via USB, see Link tag.
+
+What this commit was originally fixing - SEV-SNP guests on Hyper-V - is
+a more specialized situation which has other issues at the moment anyway
+so reverting this now and addressing the issue properly later is the
+prudent thing to do.
+
+So revert it in time for the 6.2 proper release.
+
+ [ bp: Rewrite commit message. ]
+
+Reported-by: Christian Kujau <lists@nerdbynature.de>
+Tested-by: Christian Kujau <lists@nerdbynature.de>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Link: https://lore.kernel.org/r/4fe9541e-4d4c-2b2a-f8c8-2d34a7284930@nerdbynature.de
+Cc: Jason Andryuk <jandryuk@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/mm/pat/memtype.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/arch/x86/mm/pat/memtype.c
++++ b/arch/x86/mm/pat/memtype.c
+@@ -434,8 +434,7 @@ static unsigned long pat_x_mtrr_type(u64
+ u8 mtrr_type, uniform;
+
+ mtrr_type = mtrr_type_lookup(start, end, &uniform);
+- if (mtrr_type != MTRR_TYPE_WRBACK &&
+- mtrr_type != MTRR_TYPE_INVALID)
++ if (mtrr_type != MTRR_TYPE_WRBACK)
+ return _PAGE_CACHE_MODE_UC_MINUS;
+
+ return _PAGE_CACHE_MODE_WB;
projects / thirdparty / kernel / stable-queue.git / commitdiff
