--- /dev/null
+From 088f294609d8f8816dc316681aef2eb61982e0da Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jolsa@kernel.org>
+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 <jolsa@kernel.org>
+
+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 <agordeev@linux.ibm.com>
+Fixes: 3d5854d75e31 ("fs/proc/kcore.c: allow translation of physical memory addresses")
+Signed-off-by: Jiri Olsa <jolsa@kernel.org>
+Link: https://lore.kernel.org/r/20241121231118.3212000-1-jolsa@kernel.org
+Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.
--- /dev/null
+From 3082990592f7c6d7510a9133afa46e31bbe26533 Mon Sep 17 00:00:00 2001
+From: Frank Li <Frank.Li@nxp.com>
+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 <Frank.Li@nxp.com>
+
+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 <miquel.raynal@bootlin.com>
+Signed-off-by: Frank Li <Frank.Li@nxp.com>
+Link: https://lore.kernel.org/r/20241001162608.224039-1-Frank.Li@nxp.com
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
--- /dev/null
+From 18599e93e4e814ce146186026c6abf83c14d5798 Mon Sep 17 00:00:00 2001
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+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 <ruanjinjie@huawei.com>
+
+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 <Frank.Li@nxp.com>
+Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
+Link: https://lore.kernel.org/r/20240930091913.2545510-1-ruanjinjie@huawei.com
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 73b03b27736e440e3009fe1319cbc82d2cd1290c Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+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 <javier.carrasco.cruz@gmail.com>
+
+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 <javier.carrasco.cruz@gmail.com>
+Link: https://lore.kernel.org/r/20240927-leds_device_for_each_child_node_scoped-v1-1-95c0614b38c8@gmail.com
+Signed-off-by: Lee Jones <lee@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 3b6b99ef15ea37635604992ede9ebcccef38a239 Mon Sep 17 00:00:00 2001
+From: Oleksandr Tymoshenko <ovt@google.com>
+Date: Wed, 30 Oct 2024 00:28:55 +0000
+Subject: ovl: properly handle large files in ovl_security_fileattr
+
+From: Oleksandr Tymoshenko <ovt@google.com>
+
+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 <ovt@google.com>
+Fixes: 72db82115d2b ("ovl: copy up sync/noatime fileattr flags")
+Cc: stable@vger.kernel.org # v5.15+
+Signed-off-by: Amir Goldstein <amir73il@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From 688d2eb4c6fcfdcdaed0592f9df9196573ff5ce2 Mon Sep 17 00:00:00 2001
+From: Zijun Hu <quic_zijuhu@quicinc.com>
+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 <quic_zijuhu@quicinc.com>
+
+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 <quic_zijuhu@quicinc.com>
+Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+[mani: reworded subject and description]
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+[bhelgaas: commit log]
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 9e9ec8d8692a6f64d81ef67d4fb6255af6be684b Mon Sep 17 00:00:00 2001
+From: Kishon Vijay Abraham I <kishon@ti.com>
+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 <kishon@ti.com>
+
+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 <kishon@ti.com>
+Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
+[kwilczynski: commit log, added tag for stable releases]
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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))
--- /dev/null
+From 5a938ed9481b0c06cb97aec45e722a80568256fd Mon Sep 17 00:00:00 2001
+From: Kishon Vijay Abraham I <kishon@ti.com>
+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 <kishon@ti.com>
+
+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 <kishon@ti.com>
+Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
+[kwilczynski: commit log, added tag for stable releases]
+Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
+ };
+
--- /dev/null
+From ceef938bbf8b93ba3a218b4adc244cde94b582aa Mon Sep 17 00:00:00 2001
+From: Peter Griffin <peter.griffin@linaro.org>
+Date: Thu, 31 Oct 2024 15:00:31 +0000
+Subject: scsi: ufs: exynos: Fix hibern8 notify callbacks
+
+From: Peter Griffin <peter.griffin@linaro.org>
+
+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 <peter.griffin@linaro.org>
+Link: https://lore.kernel.org/r/20241031150033.3440894-13-peter.griffin@linaro.org
+Cc: stable@vger.kernel.org
+Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+ }
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
--- /dev/null
+From 7082503622986537f57bdb5ef23e69e70cfad881 Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Date: Thu, 14 Nov 2024 12:02:13 -0800
+Subject: thermal: int3400: Fix reading of current_uuid for active policy
+
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+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 <srinivas.pandruvada@linux.intel.com>
+Cc: 5.18+ <stable@vger.kernel.org> # 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 <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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]);
+
--- /dev/null
+From bc73b4186736341ab5cd2c199da82db6e1134e13 Mon Sep 17 00:00:00 2001
+From: Alexandru Ardelean <aardelean@baylibre.com>
+Date: Tue, 5 Nov 2024 16:54:05 +0200
+Subject: util_macros.h: fix/rework find_closest() macros
+
+From: Alexandru Ardelean <aardelean@baylibre.com>
+
+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 <aardelean@baylibre.com>
+Cc: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <linux/math.h>
+
+-#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.
projects / thirdparty / kernel / stable-queue.git / commitdiff
