From: Greg Kroah-Hartman Date: Fri, 6 Dec 2024 12:27:15 +0000 (+0100) Subject: 6.6-stable patches X-Git-Tag: v6.6.64~20 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=578d23a6b4c5124b5b9a3578e6c2d9709c9f6761;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: fs-proc-kcore.c-clear-ret-value-in-read_kcore_iter-after-successful-iov_iter_zero.patch i3c-master-fix-miss-free-init_dyn_addr-at-i3c_master_put_i3c_addrs.patch i3c-master-svc-fix-pm_runtime_set_suspended-with-runtime-pm-enabled.patch leds-flash-mt6360-fix-device_for_each_child_node-refcounting-in-error-paths.patch ovl-properly-handle-large-files-in-ovl_security_fileattr.patch pci-endpoint-clear-secondary-not-primary-epc-in-pci_epc_remove_epf.patch pci-keystone-add-link-up-check-to-ks_pcie_other_map_bus.patch pci-keystone-set-mode-as-root-complex-for-ti-keystone-pcie-compatible.patch scsi-ufs-exynos-fix-hibern8-notify-callbacks.patch thermal-int3400-fix-reading-of-current_uuid-for-active-policy.patch util_macros.h-fix-rework-find_closest-macros.patch --- diff --git a/queue-6.6/fs-proc-kcore.c-clear-ret-value-in-read_kcore_iter-after-successful-iov_iter_zero.patch b/queue-6.6/fs-proc-kcore.c-clear-ret-value-in-read_kcore_iter-after-successful-iov_iter_zero.patch new file mode 100644 index 00000000000..2074309a311 --- /dev/null +++ b/queue-6.6/fs-proc-kcore.c-clear-ret-value-in-read_kcore_iter-after-successful-iov_iter_zero.patch @@ -0,0 +1,37 @@ +From 088f294609d8f8816dc316681aef2eb61982e0da Mon Sep 17 00:00:00 2001 +From: Jiri Olsa +Date: Fri, 22 Nov 2024 00:11:18 +0100 +Subject: fs/proc/kcore.c: Clear ret value in read_kcore_iter after successful iov_iter_zero + +From: Jiri Olsa + +commit 088f294609d8f8816dc316681aef2eb61982e0da upstream. + +If iov_iter_zero succeeds after failed copy_from_kernel_nofault, +we need to reset the ret value to zero otherwise it will be returned +as final return value of read_kcore_iter. + +This fixes objdump -d dump over /proc/kcore for me. + +Cc: stable@vger.kernel.org +Cc: Alexander Gordeev +Fixes: 3d5854d75e31 ("fs/proc/kcore.c: allow translation of physical memory addresses") +Signed-off-by: Jiri Olsa +Link: https://lore.kernel.org/r/20241121231118.3212000-1-jolsa@kernel.org +Acked-by: Alexander Gordeev +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman +--- + fs/proc/kcore.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/proc/kcore.c ++++ b/fs/proc/kcore.c +@@ -599,6 +599,7 @@ static ssize_t read_kcore_iter(struct ki + ret = -EFAULT; + goto out; + } ++ ret = 0; + /* + * We know the bounce buffer is safe to copy from, so + * use _copy_to_iter() directly. diff --git a/queue-6.6/i3c-master-fix-miss-free-init_dyn_addr-at-i3c_master_put_i3c_addrs.patch b/queue-6.6/i3c-master-fix-miss-free-init_dyn_addr-at-i3c_master_put_i3c_addrs.patch new file mode 100644 index 00000000000..1f5cbab827c --- /dev/null +++ b/queue-6.6/i3c-master-fix-miss-free-init_dyn_addr-at-i3c_master_put_i3c_addrs.patch @@ -0,0 +1,38 @@ +From 3082990592f7c6d7510a9133afa46e31bbe26533 Mon Sep 17 00:00:00 2001 +From: Frank Li +Date: Tue, 1 Oct 2024 12:26:08 -0400 +Subject: i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs() + +From: Frank Li + +commit 3082990592f7c6d7510a9133afa46e31bbe26533 upstream. + +if (dev->boardinfo && dev->boardinfo->init_dyn_addr) + ^^^ here check "init_dyn_addr" + i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) + ^^^^ + free "dyn_addr" +Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr". + +Cc: stable@kernel.org +Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") +Reviewed-by: Miquel Raynal +Signed-off-by: Frank Li +Link: https://lore.kernel.org/r/20241001162608.224039-1-Frank.Li@nxp.com +Signed-off-by: Alexandre Belloni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i3c/master.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/i3c/master.c ++++ b/drivers/i3c/master.c +@@ -1293,7 +1293,7 @@ static void i3c_master_put_i3c_addrs(str + I3C_ADDR_SLOT_FREE); + + if (dev->boardinfo && dev->boardinfo->init_dyn_addr) +- i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ++ i3c_bus_set_addr_slot_status(&master->bus, dev->boardinfo->init_dyn_addr, + I3C_ADDR_SLOT_FREE); + } + diff --git a/queue-6.6/i3c-master-svc-fix-pm_runtime_set_suspended-with-runtime-pm-enabled.patch b/queue-6.6/i3c-master-svc-fix-pm_runtime_set_suspended-with-runtime-pm-enabled.patch new file mode 100644 index 00000000000..f5d1da1afbf --- /dev/null +++ b/queue-6.6/i3c-master-svc-fix-pm_runtime_set_suspended-with-runtime-pm-enabled.patch @@ -0,0 +1,37 @@ +From 18599e93e4e814ce146186026c6abf83c14d5798 Mon Sep 17 00:00:00 2001 +From: Jinjie Ruan +Date: Mon, 30 Sep 2024 17:19:13 +0800 +Subject: i3c: master: svc: Fix pm_runtime_set_suspended() with runtime pm enabled + +From: Jinjie Ruan + +commit 18599e93e4e814ce146186026c6abf83c14d5798 upstream. + +It is not valid to call pm_runtime_set_suspended() for devices +with runtime PM enabled because it returns -EAGAIN if it is enabled +already and working. So, call pm_runtime_disable() before to fix it. + +Cc: stable@vger.kernel.org # v5.17 +Fixes: 05be23ef78f7 ("i3c: master: svc: add runtime pm support") +Reviewed-by: Frank Li +Reviewed-by: Miquel Raynal +Signed-off-by: Jinjie Ruan +Link: https://lore.kernel.org/r/20240930091913.2545510-1-ruanjinjie@huawei.com +Signed-off-by: Alexandre Belloni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i3c/master/svc-i3c-master.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/i3c/master/svc-i3c-master.c ++++ b/drivers/i3c/master/svc-i3c-master.c +@@ -1684,8 +1684,8 @@ static int svc_i3c_master_probe(struct p + rpm_disable: + pm_runtime_dont_use_autosuspend(&pdev->dev); + pm_runtime_put_noidle(&pdev->dev); +- pm_runtime_set_suspended(&pdev->dev); + pm_runtime_disable(&pdev->dev); ++ pm_runtime_set_suspended(&pdev->dev); + + err_disable_clks: + svc_i3c_master_unprepare_clks(master); diff --git a/queue-6.6/leds-flash-mt6360-fix-device_for_each_child_node-refcounting-in-error-paths.patch b/queue-6.6/leds-flash-mt6360-fix-device_for_each_child_node-refcounting-in-error-paths.patch new file mode 100644 index 00000000000..a560686b3bd --- /dev/null +++ b/queue-6.6/leds-flash-mt6360-fix-device_for_each_child_node-refcounting-in-error-paths.patch @@ -0,0 +1,50 @@ +From 73b03b27736e440e3009fe1319cbc82d2cd1290c Mon Sep 17 00:00:00 2001 +From: Javier Carrasco +Date: Fri, 27 Sep 2024 01:20:52 +0200 +Subject: leds: flash: mt6360: Fix device_for_each_child_node() refcounting in error paths + +From: Javier Carrasco + +commit 73b03b27736e440e3009fe1319cbc82d2cd1290c upstream. + +The device_for_each_child_node() macro requires explicit calls to +fwnode_handle_put() upon early exits to avoid memory leaks, and in +this case the error paths are handled after jumping to +'out_flash_realease', which misses that required call to +to decrement the refcount of the child node. + +A more elegant and robust solution is using the scoped variant of the +loop, which automatically handles such early exits. + +Fix the child node refcounting in the error paths by using +device_for_each_child_node_scoped(). + +Cc: stable@vger.kernel.org +Fixes: 679f8652064b ("leds: Add mt6360 driver") +Signed-off-by: Javier Carrasco +Link: https://lore.kernel.org/r/20240927-leds_device_for_each_child_node_scoped-v1-1-95c0614b38c8@gmail.com +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/leds/flash/leds-mt6360.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/leds/flash/leds-mt6360.c ++++ b/drivers/leds/flash/leds-mt6360.c +@@ -774,7 +774,6 @@ static void mt6360_v4l2_flash_release(st + static int mt6360_led_probe(struct platform_device *pdev) + { + struct mt6360_priv *priv; +- struct fwnode_handle *child; + size_t count; + int i = 0, ret; + +@@ -801,7 +800,7 @@ static int mt6360_led_probe(struct platf + return -ENODEV; + } + +- device_for_each_child_node(&pdev->dev, child) { ++ device_for_each_child_node_scoped(&pdev->dev, child) { + struct mt6360_led *led = priv->leds + i; + struct led_init_data init_data = { .fwnode = child, }; + u32 reg, led_color; diff --git a/queue-6.6/ovl-properly-handle-large-files-in-ovl_security_fileattr.patch b/queue-6.6/ovl-properly-handle-large-files-in-ovl_security_fileattr.patch new file mode 100644 index 00000000000..7c4c1ded5b9 --- /dev/null +++ b/queue-6.6/ovl-properly-handle-large-files-in-ovl_security_fileattr.patch @@ -0,0 +1,54 @@ +From 3b6b99ef15ea37635604992ede9ebcccef38a239 Mon Sep 17 00:00:00 2001 +From: Oleksandr Tymoshenko +Date: Wed, 30 Oct 2024 00:28:55 +0000 +Subject: ovl: properly handle large files in ovl_security_fileattr + +From: Oleksandr Tymoshenko + +commit 3b6b99ef15ea37635604992ede9ebcccef38a239 upstream. + +dentry_open in ovl_security_fileattr fails for any file +larger than 2GB if open method of the underlying filesystem +calls generic_file_open (e.g. fusefs). + +The issue can be reproduce using the following script: +(passthrough_ll is an example app from libfuse). + + $ D=/opt/test/mnt + $ mkdir -p ${D}/{source,base,top/uppr,top/work,ovlfs} + $ dd if=/dev/zero of=${D}/source/zero.bin bs=1G count=2 + $ passthrough_ll -o source=${D}/source ${D}/base + $ mount -t overlay overlay \ + -olowerdir=${D}/base,upperdir=${D}/top/uppr,workdir=${D}/top/work \ + ${D}/ovlfs + $ chmod 0777 ${D}/mnt/ovlfs/zero.bin + +Running this script results in "Value too large for defined data type" +error message from chmod. + +Signed-off-by: Oleksandr Tymoshenko +Fixes: 72db82115d2b ("ovl: copy up sync/noatime fileattr flags") +Cc: stable@vger.kernel.org # v5.15+ +Signed-off-by: Amir Goldstein +Signed-off-by: Greg Kroah-Hartman +--- + fs/overlayfs/inode.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/fs/overlayfs/inode.c ++++ b/fs/overlayfs/inode.c +@@ -741,8 +741,13 @@ static int ovl_security_fileattr(const s + struct file *file; + unsigned int cmd; + int err; ++ unsigned int flags; + +- file = dentry_open(realpath, O_RDONLY, current_cred()); ++ flags = O_RDONLY; ++ if (force_o_largefile()) ++ flags |= O_LARGEFILE; ++ ++ file = dentry_open(realpath, flags, current_cred()); + if (IS_ERR(file)) + return PTR_ERR(file); + diff --git a/queue-6.6/pci-endpoint-clear-secondary-not-primary-epc-in-pci_epc_remove_epf.patch b/queue-6.6/pci-endpoint-clear-secondary-not-primary-epc-in-pci_epc_remove_epf.patch new file mode 100644 index 00000000000..9a462281541 --- /dev/null +++ b/queue-6.6/pci-endpoint-clear-secondary-not-primary-epc-in-pci_epc_remove_epf.patch @@ -0,0 +1,61 @@ +From 688d2eb4c6fcfdcdaed0592f9df9196573ff5ce2 Mon Sep 17 00:00:00 2001 +From: Zijun Hu +Date: Thu, 7 Nov 2024 08:53:09 +0800 +Subject: PCI: endpoint: Clear secondary (not primary) EPC in pci_epc_remove_epf() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Zijun Hu + +commit 688d2eb4c6fcfdcdaed0592f9df9196573ff5ce2 upstream. + +In addition to a primary endpoint controller, an endpoint function may be +associated with a secondary endpoint controller, epf->sec_epc, to provide +NTB (non-transparent bridge) functionality. + +Previously, pci_epc_remove_epf() incorrectly cleared epf->epc instead of +epf->sec_epc when removing from the secondary endpoint controller. + +Extend the epc->list_lock coverage and clear either epf->epc or +epf->sec_epc as indicated. + +Link: https://lore.kernel.org/r/20241107-epc_rfc-v2-2-da5b6a99a66f@quicinc.com +Fixes: 63840ff53223 ("PCI: endpoint: Add support to associate secondary EPC with EPF") +Signed-off-by: Zijun Hu +Reviewed-by: Manivannan Sadhasivam +[mani: reworded subject and description] +Signed-off-by: Manivannan Sadhasivam +[bhelgaas: commit log] +Signed-off-by: Bjorn Helgaas +Signed-off-by: Krzysztof Wilczyński +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/endpoint/pci-epc-core.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/pci/endpoint/pci-epc-core.c ++++ b/drivers/pci/endpoint/pci-epc-core.c +@@ -663,18 +663,18 @@ void pci_epc_remove_epf(struct pci_epc * + if (!epc || IS_ERR(epc) || !epf) + return; + ++ mutex_lock(&epc->list_lock); + if (type == PRIMARY_INTERFACE) { + func_no = epf->func_no; + list = &epf->list; ++ epf->epc = NULL; + } else { + func_no = epf->sec_epc_func_no; + list = &epf->sec_epc_list; ++ epf->sec_epc = NULL; + } +- +- mutex_lock(&epc->list_lock); + clear_bit(func_no, &epc->function_num_map); + list_del(list); +- epf->epc = NULL; + mutex_unlock(&epc->list_lock); + } + EXPORT_SYMBOL_GPL(pci_epc_remove_epf); diff --git a/queue-6.6/pci-keystone-add-link-up-check-to-ks_pcie_other_map_bus.patch b/queue-6.6/pci-keystone-add-link-up-check-to-ks_pcie_other_map_bus.patch new file mode 100644 index 00000000000..f93d4d79384 --- /dev/null +++ b/queue-6.6/pci-keystone-add-link-up-check-to-ks_pcie_other_map_bus.patch @@ -0,0 +1,52 @@ +From 9e9ec8d8692a6f64d81ef67d4fb6255af6be684b Mon Sep 17 00:00:00 2001 +From: Kishon Vijay Abraham I +Date: Fri, 24 May 2024 16:27:14 +0530 +Subject: PCI: keystone: Add link up check to ks_pcie_other_map_bus() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Kishon Vijay Abraham I + +commit 9e9ec8d8692a6f64d81ef67d4fb6255af6be684b upstream. + +K2G forwards the error triggered by a link-down state (e.g., no connected +endpoint device) on the system bus for PCI configuration transactions; +these errors are reported as an SError at system level, which is fatal and +hangs the system. + +So, apply fix similar to how it was done in the DesignWare Core driver +commit 15b23906347c ("PCI: dwc: Add link up check in dw_child_pcie_ops.map_bus()"). + +Fixes: 10a797c6e54a ("PCI: dwc: keystone: Use pci_ops for config space accessors") +Link: https://lore.kernel.org/r/20240524105714.191642-3-s-vadapalli@ti.com +Signed-off-by: Kishon Vijay Abraham I +Signed-off-by: Siddharth Vadapalli +[kwilczynski: commit log, added tag for stable releases] +Signed-off-by: Krzysztof Wilczyński +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/dwc/pci-keystone.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/drivers/pci/controller/dwc/pci-keystone.c ++++ b/drivers/pci/controller/dwc/pci-keystone.c +@@ -464,6 +464,17 @@ static void __iomem *ks_pcie_other_map_b + struct keystone_pcie *ks_pcie = to_keystone_pcie(pci); + u32 reg; + ++ /* ++ * Checking whether the link is up here is a last line of defense ++ * against platforms that forward errors on the system bus as ++ * SError upon PCI configuration transactions issued when the link ++ * is down. This check is racy by definition and does not stop ++ * the system from triggering an SError if the link goes down ++ * after this check is performed. ++ */ ++ if (!dw_pcie_link_up(pci)) ++ return NULL; ++ + reg = CFG_BUS(bus->number) | CFG_DEVICE(PCI_SLOT(devfn)) | + CFG_FUNC(PCI_FUNC(devfn)); + if (!pci_is_root_bus(bus->parent)) diff --git a/queue-6.6/pci-keystone-set-mode-as-root-complex-for-ti-keystone-pcie-compatible.patch b/queue-6.6/pci-keystone-set-mode-as-root-complex-for-ti-keystone-pcie-compatible.patch new file mode 100644 index 00000000000..9e82371c22f --- /dev/null +++ b/queue-6.6/pci-keystone-set-mode-as-root-complex-for-ti-keystone-pcie-compatible.patch @@ -0,0 +1,50 @@ +From 5a938ed9481b0c06cb97aec45e722a80568256fd Mon Sep 17 00:00:00 2001 +From: Kishon Vijay Abraham I +Date: Fri, 24 May 2024 16:27:13 +0530 +Subject: PCI: keystone: Set mode as Root Complex for "ti,keystone-pcie" compatible +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Kishon Vijay Abraham I + +commit 5a938ed9481b0c06cb97aec45e722a80568256fd upstream. + +commit 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x +Platforms") introduced configuring "enum dw_pcie_device_mode" as part of +device data ("struct ks_pcie_of_data"). However it failed to set the +mode for "ti,keystone-pcie" compatible. + +Since the mode defaults to "DW_PCIE_UNKNOWN_TYPE", the following error +message is displayed for the v3.65a controller: + + "INVALID device type 0" + +Despite the driver probing successfully, the controller may not be +functional in the Root Complex mode of operation. + +So, set the mode as Root Complex for "ti,keystone-pcie" compatible to +fix this. + +Fixes: 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") +Link: https://lore.kernel.org/r/20240524105714.191642-2-s-vadapalli@ti.com +Signed-off-by: Kishon Vijay Abraham I +Signed-off-by: Siddharth Vadapalli +[kwilczynski: commit log, added tag for stable releases] +Signed-off-by: Krzysztof Wilczyński +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/dwc/pci-keystone.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/pci/controller/dwc/pci-keystone.c ++++ b/drivers/pci/controller/dwc/pci-keystone.c +@@ -1104,6 +1104,7 @@ static int ks_pcie_am654_set_mode(struct + + static const struct ks_pcie_of_data ks_pcie_rc_of_data = { + .host_ops = &ks_pcie_host_ops, ++ .mode = DW_PCIE_RC_TYPE, + .version = DW_PCIE_VER_365A, + }; + diff --git a/queue-6.6/scsi-ufs-exynos-fix-hibern8-notify-callbacks.patch b/queue-6.6/scsi-ufs-exynos-fix-hibern8-notify-callbacks.patch new file mode 100644 index 00000000000..23f6e5d0d54 --- /dev/null +++ b/queue-6.6/scsi-ufs-exynos-fix-hibern8-notify-callbacks.patch @@ -0,0 +1,87 @@ +From ceef938bbf8b93ba3a218b4adc244cde94b582aa Mon Sep 17 00:00:00 2001 +From: Peter Griffin +Date: Thu, 31 Oct 2024 15:00:31 +0000 +Subject: scsi: ufs: exynos: Fix hibern8 notify callbacks + +From: Peter Griffin + +commit ceef938bbf8b93ba3a218b4adc244cde94b582aa upstream. + +v1 of the patch which introduced the ufshcd_vops_hibern8_notify() +callback used a bool instead of an enum. In v2 this was updated to an +enum based on the review feedback in [1]. + +ufs-exynos hibernate calls have always been broken upstream as it +follows the v1 bool implementation. + +Link: https://patchwork.kernel.org/project/linux-scsi/patch/001f01d23994$719997c0$54ccc740$@samsung.com/ [1] +Fixes: 55f4b1f73631 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") +Signed-off-by: Peter Griffin +Link: https://lore.kernel.org/r/20241031150033.3440894-13-peter.griffin@linaro.org +Cc: stable@vger.kernel.org +Reviewed-by: Tudor Ambarus +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ufs/host/ufs-exynos.c | 16 ++++++++-------- + 1 file changed, 8 insertions(+), 8 deletions(-) + +--- a/drivers/ufs/host/ufs-exynos.c ++++ b/drivers/ufs/host/ufs-exynos.c +@@ -1228,12 +1228,12 @@ static void exynos_ufs_dev_hw_reset(stru + hci_writel(ufs, 1 << 0, HCI_GPIO_OUT); + } + +-static void exynos_ufs_pre_hibern8(struct ufs_hba *hba, u8 enter) ++static void exynos_ufs_pre_hibern8(struct ufs_hba *hba, enum uic_cmd_dme cmd) + { + struct exynos_ufs *ufs = ufshcd_get_variant(hba); + struct exynos_ufs_uic_attr *attr = ufs->drv_data->uic_attr; + +- if (!enter) { ++ if (cmd == UIC_CMD_DME_HIBER_EXIT) { + if (ufs->opts & EXYNOS_UFS_OPT_BROKEN_AUTO_CLK_CTRL) + exynos_ufs_disable_auto_ctrl_hcc(ufs); + exynos_ufs_ungate_clks(ufs); +@@ -1261,11 +1261,11 @@ static void exynos_ufs_pre_hibern8(struc + } + } + +-static void exynos_ufs_post_hibern8(struct ufs_hba *hba, u8 enter) ++static void exynos_ufs_post_hibern8(struct ufs_hba *hba, enum uic_cmd_dme cmd) + { + struct exynos_ufs *ufs = ufshcd_get_variant(hba); + +- if (!enter) { ++ if (cmd == UIC_CMD_DME_HIBER_EXIT) { + u32 cur_mode = 0; + u32 pwrmode; + +@@ -1284,7 +1284,7 @@ static void exynos_ufs_post_hibern8(stru + + if (!(ufs->opts & EXYNOS_UFS_OPT_SKIP_CONNECTION_ESTAB)) + exynos_ufs_establish_connt(ufs); +- } else { ++ } else if (cmd == UIC_CMD_DME_HIBER_ENTER) { + ufs->entry_hibern8_t = ktime_get(); + exynos_ufs_gate_clks(ufs); + if (ufs->opts & EXYNOS_UFS_OPT_BROKEN_AUTO_CLK_CTRL) +@@ -1371,15 +1371,15 @@ static int exynos_ufs_pwr_change_notify( + } + + static void exynos_ufs_hibern8_notify(struct ufs_hba *hba, +- enum uic_cmd_dme enter, ++ enum uic_cmd_dme cmd, + enum ufs_notify_change_status notify) + { + switch ((u8)notify) { + case PRE_CHANGE: +- exynos_ufs_pre_hibern8(hba, enter); ++ exynos_ufs_pre_hibern8(hba, cmd); + break; + case POST_CHANGE: +- exynos_ufs_post_hibern8(hba, enter); ++ exynos_ufs_post_hibern8(hba, cmd); + break; + } + } diff --git a/queue-6.6/series b/queue-6.6/series index 4dee899df3d..2a211fab4b4 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -641,3 +641,14 @@ arm-9430-1-entry-do-a-dummy-read-from-vmap-shadow.patch arm-9431-1-mm-pair-atomic_set_release-with-_read_acquire.patch mm-slub-avoid-list-corruption-when-removing-a-slab-from-the-full-list.patch ceph-extract-entity-name-from-device-id.patch +util_macros.h-fix-rework-find_closest-macros.patch +scsi-ufs-exynos-fix-hibern8-notify-callbacks.patch +i3c-master-svc-fix-pm_runtime_set_suspended-with-runtime-pm-enabled.patch +i3c-master-fix-miss-free-init_dyn_addr-at-i3c_master_put_i3c_addrs.patch +pci-keystone-set-mode-as-root-complex-for-ti-keystone-pcie-compatible.patch +pci-keystone-add-link-up-check-to-ks_pcie_other_map_bus.patch +pci-endpoint-clear-secondary-not-primary-epc-in-pci_epc_remove_epf.patch +fs-proc-kcore.c-clear-ret-value-in-read_kcore_iter-after-successful-iov_iter_zero.patch +thermal-int3400-fix-reading-of-current_uuid-for-active-policy.patch +leds-flash-mt6360-fix-device_for_each_child_node-refcounting-in-error-paths.patch +ovl-properly-handle-large-files-in-ovl_security_fileattr.patch diff --git a/queue-6.6/thermal-int3400-fix-reading-of-current_uuid-for-active-policy.patch b/queue-6.6/thermal-int3400-fix-reading-of-current_uuid-for-active-policy.patch new file mode 100644 index 00000000000..0598cbd14ca --- /dev/null +++ b/queue-6.6/thermal-int3400-fix-reading-of-current_uuid-for-active-policy.patch @@ -0,0 +1,47 @@ +From 7082503622986537f57bdb5ef23e69e70cfad881 Mon Sep 17 00:00:00 2001 +From: Srinivas Pandruvada +Date: Thu, 14 Nov 2024 12:02:13 -0800 +Subject: thermal: int3400: Fix reading of current_uuid for active policy + +From: Srinivas Pandruvada + +commit 7082503622986537f57bdb5ef23e69e70cfad881 upstream. + +When the current_uuid attribute is set to the active policy UUID, +reading back the same attribute is returning "INVALID" instead of +the active policy UUID on some platforms before Ice Lake. + +In platforms before Ice Lake, firmware provides a list of supported +thermal policies. In this case, user space can select any of the +supported thermal policies via a write to attribute "current_uuid". + +In commit c7ff29763989 ("thermal: int340x: Update OS policy capability +handshake")', the OS policy handshake was updated to support Ice Lake +and later platforms and it treated priv->current_uuid_index=0 as +invalid. However, priv->current_uuid_index=0 is for the active policy, +only priv->current_uuid_index=-1 is invalid. + +Fix this issue by updating the priv->current_uuid_index check. + +Fixes: c7ff29763989 ("thermal: int340x: Update OS policy capability handshake") +Signed-off-by: Srinivas Pandruvada +Cc: 5.18+ # 5.18+ +Link: https://patch.msgid.link/20241114200213.422303-1-srinivas.pandruvada@linux.intel.com +[ rjw: Subject and changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c ++++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c +@@ -144,7 +144,7 @@ static ssize_t current_uuid_show(struct + struct int3400_thermal_priv *priv = dev_get_drvdata(dev); + int i, length = 0; + +- if (priv->current_uuid_index > 0) ++ if (priv->current_uuid_index >= 0) + return sprintf(buf, "%s\n", + int3400_thermal_uuids[priv->current_uuid_index]); + diff --git a/queue-6.6/util_macros.h-fix-rework-find_closest-macros.patch b/queue-6.6/util_macros.h-fix-rework-find_closest-macros.patch new file mode 100644 index 00000000000..9d26f679861 --- /dev/null +++ b/queue-6.6/util_macros.h-fix-rework-find_closest-macros.patch @@ -0,0 +1,188 @@ +From bc73b4186736341ab5cd2c199da82db6e1134e13 Mon Sep 17 00:00:00 2001 +From: Alexandru Ardelean +Date: Tue, 5 Nov 2024 16:54:05 +0200 +Subject: util_macros.h: fix/rework find_closest() macros + +From: Alexandru Ardelean + +commit bc73b4186736341ab5cd2c199da82db6e1134e13 upstream. + +A bug was found in the find_closest() (find_closest_descending() is also +affected after some testing), where for certain values with small +progressions, the rounding (done by averaging 2 values) causes an +incorrect index to be returned. The rounding issues occur for +progressions of 1, 2 and 3. It goes away when the progression/interval +between two values is 4 or larger. + +It's particularly bad for progressions of 1. For example if there's an +array of 'a = { 1, 2, 3 }', using 'find_closest(2, a ...)' would return 0 +(the index of '1'), rather than returning 1 (the index of '2'). This +means that for exact values (with a progression of 1), find_closest() will +misbehave and return the index of the value smaller than the one we're +searching for. + +For progressions of 2 and 3, the exact values are obtained correctly; but +values aren't approximated correctly (as one would expect). Starting with +progressions of 4, all seems to be good (one gets what one would expect). + +While one could argue that 'find_closest()' should not be used for arrays +with progressions of 1 (i.e. '{1, 2, 3, ...}', the macro should still +behave correctly. + +The bug was found while testing the 'drivers/iio/adc/ad7606.c', +specifically the oversampling feature. +For reference, the oversampling values are listed as: + static const unsigned int ad7606_oversampling_avail[7] = { + 1, 2, 4, 8, 16, 32, 64, + }; + +When doing: + 1. $ echo 1 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio + $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio + 1 # this is fine + 2. $ echo 2 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio + $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio + 1 # this is wrong; 2 should be returned here + 3. $ echo 3 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio + $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio + 2 # this is fine + 4. $ echo 4 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio + $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio + 4 # this is fine +And from here-on, the values are as correct (one gets what one would +expect.) + +While writing a kunit test for this bug, a peculiar issue was found for the +array in the 'drivers/hwmon/ina2xx.c' & 'drivers/iio/adc/ina2xx-adc.c' +drivers. While running the kunit test (for 'ina226_avg_tab' from these +drivers): + * idx = find_closest([-1 to 2], ina226_avg_tab, ARRAY_SIZE(ina226_avg_tab)); + This returns idx == 0, so value. + * idx = find_closest(3, ina226_avg_tab, ARRAY_SIZE(ina226_avg_tab)); + This returns idx == 0, value 1; and now one could argue whether 3 is + closer to 4 or to 1. This quirk only appears for value '3' in this + array, but it seems to be a another rounding issue. + * And from 4 onwards the 'find_closest'() works fine (one gets what one + would expect). + +This change reworks the find_closest() macros to also check the difference +between the left and right elements when 'x'. If the distance to the right +is smaller (than the distance to the left), the index is incremented by 1. +This also makes redundant the need for using the DIV_ROUND_CLOSEST() macro. + +In order to accommodate for any mix of negative + positive values, the +internal variables '__fc_x', '__fc_mid_x', '__fc_left' & '__fc_right' are +forced to 'long' type. This also addresses any potential bugs/issues with +'x' being of an unsigned type. In those situations any comparison between +signed & unsigned would be promoted to a comparison between 2 unsigned +numbers; this is especially annoying when '__fc_left' & '__fc_right' +underflow. + +The find_closest_descending() macro was also reworked and duplicated from +the find_closest(), and it is being iterated in reverse. The main reason +for this is to get the same indices as 'find_closest()' (but in reverse). +The comparison for '__fc_right < __fc_left' favors going the array in +ascending order. +For example for array '{ 1024, 512, 256, 128, 64, 16, 4, 1 }' and x = 3, we +get: + __fc_mid_x = 2 + __fc_left = -1 + __fc_right = -2 + Then '__fc_right < __fc_left' evaluates to true and '__fc_i++' becomes 7 + which is not quite incorrect, but 3 is closer to 4 than to 1. + +This change has been validated with the kunit from the next patch. + +Link: https://lkml.kernel.org/r/20241105145406.554365-1-aardelean@baylibre.com +Fixes: 95d119528b0b ("util_macros.h: add find_closest() macro") +Signed-off-by: Alexandru Ardelean +Cc: Bartosz Golaszewski +Cc: Greg Kroah-Hartman +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/util_macros.h | 56 +++++++++++++++++++++++++++++++------------- + 1 file changed, 40 insertions(+), 16 deletions(-) + +--- a/include/linux/util_macros.h ++++ b/include/linux/util_macros.h +@@ -4,19 +4,6 @@ + + #include + +-#define __find_closest(x, a, as, op) \ +-({ \ +- typeof(as) __fc_i, __fc_as = (as) - 1; \ +- typeof(x) __fc_x = (x); \ +- typeof(*a) const *__fc_a = (a); \ +- for (__fc_i = 0; __fc_i < __fc_as; __fc_i++) { \ +- if (__fc_x op DIV_ROUND_CLOSEST(__fc_a[__fc_i] + \ +- __fc_a[__fc_i + 1], 2)) \ +- break; \ +- } \ +- (__fc_i); \ +-}) +- + /** + * find_closest - locate the closest element in a sorted array + * @x: The reference value. +@@ -25,8 +12,27 @@ + * @as: Size of 'a'. + * + * Returns the index of the element closest to 'x'. ++ * Note: If using an array of negative numbers (or mixed positive numbers), ++ * then be sure that 'x' is of a signed-type to get good results. + */ +-#define find_closest(x, a, as) __find_closest(x, a, as, <=) ++#define find_closest(x, a, as) \ ++({ \ ++ typeof(as) __fc_i, __fc_as = (as) - 1; \ ++ long __fc_mid_x, __fc_x = (x); \ ++ long __fc_left, __fc_right; \ ++ typeof(*a) const *__fc_a = (a); \ ++ for (__fc_i = 0; __fc_i < __fc_as; __fc_i++) { \ ++ __fc_mid_x = (__fc_a[__fc_i] + __fc_a[__fc_i + 1]) / 2; \ ++ if (__fc_x <= __fc_mid_x) { \ ++ __fc_left = __fc_x - __fc_a[__fc_i]; \ ++ __fc_right = __fc_a[__fc_i + 1] - __fc_x; \ ++ if (__fc_right < __fc_left) \ ++ __fc_i++; \ ++ break; \ ++ } \ ++ } \ ++ (__fc_i); \ ++}) + + /** + * find_closest_descending - locate the closest element in a sorted array +@@ -36,9 +42,27 @@ + * @as: Size of 'a'. + * + * Similar to find_closest() but 'a' is expected to be sorted in descending +- * order. ++ * order. The iteration is done in reverse order, so that the comparison ++ * of '__fc_right' & '__fc_left' also works for unsigned numbers. + */ +-#define find_closest_descending(x, a, as) __find_closest(x, a, as, >=) ++#define find_closest_descending(x, a, as) \ ++({ \ ++ typeof(as) __fc_i, __fc_as = (as) - 1; \ ++ long __fc_mid_x, __fc_x = (x); \ ++ long __fc_left, __fc_right; \ ++ typeof(*a) const *__fc_a = (a); \ ++ for (__fc_i = __fc_as; __fc_i >= 1; __fc_i--) { \ ++ __fc_mid_x = (__fc_a[__fc_i] + __fc_a[__fc_i - 1]) / 2; \ ++ if (__fc_x <= __fc_mid_x) { \ ++ __fc_left = __fc_x - __fc_a[__fc_i]; \ ++ __fc_right = __fc_a[__fc_i - 1] - __fc_x; \ ++ if (__fc_right < __fc_left) \ ++ __fc_i--; \ ++ break; \ ++ } \ ++ } \ ++ (__fc_i); \ ++}) + + /** + * is_insidevar - check if the @ptr points inside the @var memory range.