--- /dev/null
+From e0cec363197e41af870613e8e17b30bf0e3d41b5 Mon Sep 17 00:00:00 2001
+From: Carlos Song <carlos.song@nxp.com>
+Date: Wed, 18 Dec 2024 12:42:38 +0800
+Subject: i2c: imx: add imx7d compatible string for applying erratum ERR007805
+
+From: Carlos Song <carlos.song@nxp.com>
+
+commit e0cec363197e41af870613e8e17b30bf0e3d41b5 upstream.
+
+Compatible string "fsl,imx7d-i2c" is not exited at i2c-imx driver
+compatible string table, at the result, "fsl,imx21-i2c" will be
+matched, but it will cause erratum ERR007805 not be applied in fact.
+
+So Add "fsl,imx7d-i2c" compatible string in i2c-imx driver to apply
+the erratum ERR007805(https://www.nxp.com/docs/en/errata/IMX7DS_3N09P.pdf).
+
+"
+ERR007805 I2C: When the I2C clock speed is configured for 400 kHz,
+the SCL low period violates the I2C spec of 1.3 uS min
+
+Description: When the I2C module is programmed to operate at the
+maximum clock speed of 400 kHz (as defined by the I2C spec), the SCL
+clock low period violates the I2C spec of 1.3 uS min. The user must
+reduce the clock speed to obtain the SCL low time to meet the 1.3us
+I2C minimum required. This behavior means the SoC is not compliant
+to the I2C spec at 400kHz.
+
+Workaround: To meet the clock low period requirement in fast speed
+mode, SCL must be configured to 384KHz or less.
+"
+
+"fsl,imx7d-i2c" already is documented in binding doc. This erratum
+fix has been included in imx6_i2c_hwdata and it is the same in all
+I.MX6/7/8, so just reuse it.
+
+Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit")
+Cc: stable@vger.kernel.org # v5.18+
+Signed-off-by: Carlos Song <carlos.song@nxp.com>
+Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
+Reviewed-by: Frank Li <Frank.Li@nxp.com>
+Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit")
+Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Link: https://lore.kernel.org/r/20241218044238.143414-1-carlos.song@nxp.com
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-imx.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/i2c/busses/i2c-imx.c
++++ b/drivers/i2c/busses/i2c-imx.c
+@@ -286,6 +286,7 @@ static const struct of_device_id i2c_imx
+ { .compatible = "fsl,imx6sll-i2c", .data = &imx6_i2c_hwdata, },
+ { .compatible = "fsl,imx6sx-i2c", .data = &imx6_i2c_hwdata, },
+ { .compatible = "fsl,imx6ul-i2c", .data = &imx6_i2c_hwdata, },
++ { .compatible = "fsl,imx7d-i2c", .data = &imx6_i2c_hwdata, },
+ { .compatible = "fsl,imx7s-i2c", .data = &imx6_i2c_hwdata, },
+ { .compatible = "fsl,imx8mm-i2c", .data = &imx6_i2c_hwdata, },
+ { .compatible = "fsl,imx8mn-i2c", .data = &imx6_i2c_hwdata, },
--- /dev/null
+From 9a8f9320d67b27ddd7f1ee88d91820197a0e908f Mon Sep 17 00:00:00 2001
+From: Conor Dooley <conor.dooley@microchip.com>
+Date: Wed, 18 Dec 2024 12:07:40 +0000
+Subject: i2c: microchip-core: actually use repeated sends
+
+From: Conor Dooley <conor.dooley@microchip.com>
+
+commit 9a8f9320d67b27ddd7f1ee88d91820197a0e908f upstream.
+
+At present, where repeated sends are intended to be used, the
+i2c-microchip-core driver sends a stop followed by a start. Lots of i2c
+devices must not malfunction in the face of this behaviour, because the
+driver has operated like this for years! Try to keep track of whether or
+not a repeated send is required, and suppress sending a stop in these
+cases.
+
+CC: stable@vger.kernel.org
+Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers")
+Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
+Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
+Link: https://lore.kernel.org/r/20241218-football-composure-e56df2461461@spud
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-microchip-corei2c.c | 120 ++++++++++++++++++++++-------
+ 1 file changed, 94 insertions(+), 26 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-microchip-corei2c.c
++++ b/drivers/i2c/busses/i2c-microchip-corei2c.c
+@@ -93,27 +93,35 @@
+ * @base: pointer to register struct
+ * @dev: device reference
+ * @i2c_clk: clock reference for i2c input clock
++ * @msg_queue: pointer to the messages requiring sending
+ * @buf: pointer to msg buffer for easier use
+ * @msg_complete: xfer completion object
+ * @adapter: core i2c abstraction
+ * @msg_err: error code for completed message
+ * @bus_clk_rate: current i2c bus clock rate
+ * @isr_status: cached copy of local ISR status
++ * @total_num: total number of messages to be sent/received
++ * @current_num: index of the current message being sent/received
+ * @msg_len: number of bytes transferred in msg
+ * @addr: address of the current slave
++ * @restart_needed: whether or not a repeated start is required after current message
+ */
+ struct mchp_corei2c_dev {
+ void __iomem *base;
+ struct device *dev;
+ struct clk *i2c_clk;
++ struct i2c_msg *msg_queue;
+ u8 *buf;
+ struct completion msg_complete;
+ struct i2c_adapter adapter;
+ int msg_err;
++ int total_num;
++ int current_num;
+ u32 bus_clk_rate;
+ u32 isr_status;
+ u16 msg_len;
+ u8 addr;
++ bool restart_needed;
+ };
+
+ static void mchp_corei2c_core_disable(struct mchp_corei2c_dev *idev)
+@@ -222,6 +230,47 @@ static int mchp_corei2c_fill_tx(struct m
+ return 0;
+ }
+
++static void mchp_corei2c_next_msg(struct mchp_corei2c_dev *idev)
++{
++ struct i2c_msg *this_msg;
++ u8 ctrl;
++
++ if (idev->current_num >= idev->total_num) {
++ complete(&idev->msg_complete);
++ return;
++ }
++
++ /*
++ * If there's been an error, the isr needs to return control
++ * to the "main" part of the driver, so as not to keep sending
++ * messages once it completes and clears the SI bit.
++ */
++ if (idev->msg_err) {
++ complete(&idev->msg_complete);
++ return;
++ }
++
++ this_msg = idev->msg_queue++;
++
++ if (idev->current_num < (idev->total_num - 1)) {
++ struct i2c_msg *next_msg = idev->msg_queue;
++
++ idev->restart_needed = next_msg->flags & I2C_M_RD;
++ } else {
++ idev->restart_needed = false;
++ }
++
++ idev->addr = i2c_8bit_addr_from_msg(this_msg);
++ idev->msg_len = this_msg->len;
++ idev->buf = this_msg->buf;
++
++ ctrl = readb(idev->base + CORE_I2C_CTRL);
++ ctrl |= CTRL_STA;
++ writeb(ctrl, idev->base + CORE_I2C_CTRL);
++
++ idev->current_num++;
++}
++
+ static irqreturn_t mchp_corei2c_handle_isr(struct mchp_corei2c_dev *idev)
+ {
+ u32 status = idev->isr_status;
+@@ -247,10 +296,14 @@ static irqreturn_t mchp_corei2c_handle_i
+ break;
+ case STATUS_M_SLAW_ACK:
+ case STATUS_M_TX_DATA_ACK:
+- if (idev->msg_len > 0)
++ if (idev->msg_len > 0) {
+ mchp_corei2c_fill_tx(idev);
+- else
+- last_byte = true;
++ } else {
++ if (idev->restart_needed)
++ finished = true;
++ else
++ last_byte = true;
++ }
+ break;
+ case STATUS_M_TX_DATA_NACK:
+ case STATUS_M_SLAR_NACK:
+@@ -287,7 +340,7 @@ static irqreturn_t mchp_corei2c_handle_i
+ mchp_corei2c_stop(idev);
+
+ if (last_byte || finished)
+- complete(&idev->msg_complete);
++ mchp_corei2c_next_msg(idev);
+
+ return IRQ_HANDLED;
+ }
+@@ -311,21 +364,48 @@ static irqreturn_t mchp_corei2c_isr(int
+ return ret;
+ }
+
+-static int mchp_corei2c_xfer_msg(struct mchp_corei2c_dev *idev,
+- struct i2c_msg *msg)
++static int mchp_corei2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
++ int num)
+ {
+- u8 ctrl;
++ struct mchp_corei2c_dev *idev = i2c_get_adapdata(adap);
++ struct i2c_msg *this_msg = msgs;
+ unsigned long time_left;
++ u8 ctrl;
+
+- idev->addr = i2c_8bit_addr_from_msg(msg);
+- idev->msg_len = msg->len;
+- idev->buf = msg->buf;
++ mchp_corei2c_core_enable(idev);
++
++ /*
++ * The isr controls the flow of a transfer, this info needs to be saved
++ * to a location that it can access the queue information from.
++ */
++ idev->restart_needed = false;
++ idev->msg_queue = msgs;
++ idev->total_num = num;
++ idev->current_num = 0;
++
++ /*
++ * But the first entry to the isr is triggered by the start in this
++ * function, so the first message needs to be "dequeued".
++ */
++ idev->addr = i2c_8bit_addr_from_msg(this_msg);
++ idev->msg_len = this_msg->len;
++ idev->buf = this_msg->buf;
+ idev->msg_err = 0;
+
+- reinit_completion(&idev->msg_complete);
++ if (idev->total_num > 1) {
++ struct i2c_msg *next_msg = msgs + 1;
+
+- mchp_corei2c_core_enable(idev);
++ idev->restart_needed = next_msg->flags & I2C_M_RD;
++ }
+
++ idev->current_num++;
++ idev->msg_queue++;
++
++ reinit_completion(&idev->msg_complete);
++
++ /*
++ * Send the first start to pass control to the isr
++ */
+ ctrl = readb(idev->base + CORE_I2C_CTRL);
+ ctrl |= CTRL_STA;
+ writeb(ctrl, idev->base + CORE_I2C_CTRL);
+@@ -335,20 +415,8 @@ static int mchp_corei2c_xfer_msg(struct
+ if (!time_left)
+ return -ETIMEDOUT;
+
+- return idev->msg_err;
+-}
+-
+-static int mchp_corei2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
+- int num)
+-{
+- struct mchp_corei2c_dev *idev = i2c_get_adapdata(adap);
+- int i, ret;
+-
+- for (i = 0; i < num; i++) {
+- ret = mchp_corei2c_xfer_msg(idev, msgs++);
+- if (ret)
+- return ret;
+- }
++ if (idev->msg_err)
++ return idev->msg_err;
+
+ return num;
+ }
--- /dev/null
+From 49e1f0fd0d4cb03a16b8526c4e683e1958f71490 Mon Sep 17 00:00:00 2001
+From: Conor Dooley <conor.dooley@microchip.com>
+Date: Wed, 18 Dec 2024 12:07:42 +0000
+Subject: i2c: microchip-core: fix "ghost" detections
+
+From: Conor Dooley <conor.dooley@microchip.com>
+
+commit 49e1f0fd0d4cb03a16b8526c4e683e1958f71490 upstream.
+
+Running i2c-detect currently produces an output akin to:
+ 0 1 2 3 4 5 6 7 8 9 a b c d e f
+00: 08 -- 0a -- 0c -- 0e --
+10: 10 -- 12 -- 14 -- 16 -- UU 19 -- 1b -- 1d -- 1f
+20: -- 21 -- 23 -- 25 -- 27 -- 29 -- 2b -- 2d -- 2f
+30: -- -- -- -- -- -- -- -- 38 -- 3a -- 3c -- 3e --
+40: 40 -- 42 -- 44 -- 46 -- 48 -- 4a -- 4c -- 4e --
+50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
+60: 60 -- 62 -- 64 -- 66 -- 68 -- 6a -- 6c -- 6e --
+70: 70 -- 72 -- 74 -- 76 --
+
+This happens because for an i2c_msg with a len of 0 the driver will
+mark the transmission of the message as a success once the START has
+been sent, without waiting for the devices on the bus to respond with an
+ACK/NAK. Since i2cdetect seems to run in a tight loop over all addresses
+the NAK is treated as part of the next test for the next address.
+
+Delete the fast path that marks a message as complete when idev->msg_len
+is zero after sending a START/RESTART since this isn't a valid scenario.
+
+CC: stable@vger.kernel.org
+Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers")
+Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
+Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
+Link: https://lore.kernel.org/r/20241218-outbid-encounter-b2e78b1cc707@spud
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-microchip-corei2c.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-microchip-corei2c.c
++++ b/drivers/i2c/busses/i2c-microchip-corei2c.c
+@@ -287,8 +287,6 @@ static irqreturn_t mchp_corei2c_handle_i
+ ctrl &= ~CTRL_STA;
+ writeb(idev->addr, idev->base + CORE_I2C_DATA);
+ writeb(ctrl, idev->base + CORE_I2C_CTRL);
+- if (idev->msg_len == 0)
+- finished = true;
+ break;
+ case STATUS_M_ARB_LOST:
+ idev->msg_err = -EAGAIN;
--- /dev/null
+From e33ac68e5e21ec1292490dfe061e75c0dbdd3bd4 Mon Sep 17 00:00:00 2001
+From: Pavel Begunkov <asml.silence@gmail.com>
+Date: Thu, 26 Dec 2024 16:49:23 +0000
+Subject: io_uring/sqpoll: fix sqpoll error handling races
+
+From: Pavel Begunkov <asml.silence@gmail.com>
+
+commit e33ac68e5e21ec1292490dfe061e75c0dbdd3bd4 upstream.
+
+BUG: KASAN: slab-use-after-free in __lock_acquire+0x370b/0x4a10 kernel/locking/lockdep.c:5089
+Call Trace:
+<TASK>
+...
+_raw_spin_lock_irqsave+0x3d/0x60 kernel/locking/spinlock.c:162
+class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]
+try_to_wake_up+0xb5/0x23c0 kernel/sched/core.c:4205
+io_sq_thread_park+0xac/0xe0 io_uring/sqpoll.c:55
+io_sq_thread_finish+0x6b/0x310 io_uring/sqpoll.c:96
+io_sq_offload_create+0x162/0x11d0 io_uring/sqpoll.c:497
+io_uring_create io_uring/io_uring.c:3724 [inline]
+io_uring_setup+0x1728/0x3230 io_uring/io_uring.c:3806
+...
+
+Kun Hu reports that the SQPOLL creating error path has UAF, which
+happens if io_uring_alloc_task_context() fails and then io_sq_thread()
+manages to run and complete before the rest of error handling code,
+which means io_sq_thread_finish() is looking at already killed task.
+
+Note that this is mostly theoretical, requiring fault injection on
+the allocation side to trigger in practice.
+
+Cc: stable@vger.kernel.org
+Reported-by: Kun Hu <huk23@m.fudan.edu.cn>
+Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
+Link: https://lore.kernel.org/r/0f2f1aa5729332612bd01fe0f2f385fd1f06ce7c.1735231717.git.asml.silence@gmail.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/sqpoll.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/io_uring/sqpoll.c
++++ b/io_uring/sqpoll.c
+@@ -352,6 +352,7 @@ void io_sqpoll_wait_sq(struct io_ring_ct
+ __cold int io_sq_offload_create(struct io_ring_ctx *ctx,
+ struct io_uring_params *p)
+ {
++ struct task_struct *task_to_put = NULL;
+ int ret;
+
+ /* Retain compatibility with failing for an invalid attach attempt */
+@@ -432,6 +433,7 @@ __cold int io_sq_offload_create(struct i
+ }
+
+ sqd->thread = tsk;
++ task_to_put = get_task_struct(tsk);
+ ret = io_uring_alloc_task_context(tsk, ctx);
+ wake_up_new_task(tsk);
+ if (ret)
+@@ -442,11 +444,15 @@ __cold int io_sq_offload_create(struct i
+ goto err;
+ }
+
++ if (task_to_put)
++ put_task_struct(task_to_put);
+ return 0;
+ err_sqpoll:
+ complete(&ctx->sq_data->exited);
+ err:
+ io_sq_thread_finish(ctx);
++ if (task_to_put)
++ put_task_struct(task_to_put);
+ return ret;
+ }
+
--- /dev/null
+From a60b990798eb17433d0283788280422b1bd94b18 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Sat, 14 Dec 2024 12:50:18 +0100
+Subject: PCI/MSI: Handle lack of irqdomain gracefully
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit a60b990798eb17433d0283788280422b1bd94b18 upstream.
+
+Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a
+RISCV platform which does not provide PCI/MSI support:
+
+ WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32
+ __pci_enable_msix_range+0x30c/0x596
+ pci_msi_setup_msi_irqs+0x2c/0x32
+ pci_alloc_irq_vectors_affinity+0xb8/0xe2
+
+RISCV uses hierarchical interrupt domains and correctly does not implement
+the legacy fallback. The warning triggers from the legacy fallback stub.
+
+That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent
+domain is associated with the device or not. There is a check for MSI-X,
+which has a legacy assumption. But that legacy fallback assumption is only
+valid when legacy support is enabled, but otherwise the check should simply
+return -ENOTSUPP.
+
+Loongarch tripped over the same problem and blindly enabled legacy support
+without implementing the legacy fallbacks. There are weak implementations
+which return an error, so the problem was papered over.
+
+Correct pci_msi_domain_supports() to evaluate the legacy mode and add
+the missing supported check into the MSI enable path to complete it.
+
+Fixes: d2a463b29741 ("PCI/MSI: Reject multi-MSI early")
+Reported-by: Alexandre Ghiti <alexghiti@rivosinc.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/all/87ed2a8ow5.ffs@tglx
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/msi/irqdomain.c | 7 +++++--
+ drivers/pci/msi/msi.c | 4 ++++
+ 2 files changed, 9 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/msi/irqdomain.c
++++ b/drivers/pci/msi/irqdomain.c
+@@ -330,8 +330,11 @@ bool pci_msi_domain_supports(struct pci_
+
+ domain = dev_get_msi_domain(&pdev->dev);
+
+- if (!domain || !irq_domain_is_hierarchy(domain))
+- return mode == ALLOW_LEGACY;
++ if (!domain || !irq_domain_is_hierarchy(domain)) {
++ if (IS_ENABLED(CONFIG_PCI_MSI_ARCH_FALLBACKS))
++ return mode == ALLOW_LEGACY;
++ return false;
++ }
+
+ if (!irq_domain_is_msi_parent(domain)) {
+ /*
+--- a/drivers/pci/msi/msi.c
++++ b/drivers/pci/msi/msi.c
+@@ -429,6 +429,10 @@ int __pci_enable_msi_range(struct pci_de
+ if (WARN_ON_ONCE(dev->msi_enabled))
+ return -EINVAL;
+
++ /* Test for the availability of MSI support */
++ if (!pci_msi_domain_supports(dev, 0, ALLOW_LEGACY))
++ return -ENOTSUPP;
++
+ nvec = pci_msi_vec_count(dev);
+ if (nvec < 0)
+ return nvec;
--- /dev/null
+From afc6e39e824ad0e44b2af50a97885caec8d213d1 Mon Sep 17 00:00:00 2001
+From: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
+Date: Mon, 9 Dec 2024 11:46:15 +0100
+Subject: power: supply: gpio-charger: Fix set charge current limits
+
+From: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
+
+commit afc6e39e824ad0e44b2af50a97885caec8d213d1 upstream.
+
+Fix set charge current limits for devices which allow to set the lowest
+charge current limit to be greater zero. If requested charge current limit
+is below lowest limit, the index equals current_limit_map_size which leads
+to accessing memory beyond allocated memory.
+
+Fixes: be2919d8355e ("power: supply: gpio-charger: add charge-current-limit feature")
+Cc: stable@vger.kernel.org
+Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
+Link: https://lore.kernel.org/r/20241209-fix-charge-current-limit-v1-1-760d9b8f2af3@liebherr.com
+Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/power/supply/gpio-charger.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/power/supply/gpio-charger.c
++++ b/drivers/power/supply/gpio-charger.c
+@@ -67,6 +67,14 @@ static int set_charge_current_limit(stru
+ if (gpio_charger->current_limit_map[i].limit_ua <= val)
+ break;
+ }
++
++ /*
++ * If a valid charge current limit isn't found, default to smallest
++ * current limitation for safety reasons.
++ */
++ if (i >= gpio_charger->current_limit_map_size)
++ i = gpio_charger->current_limit_map_size - 1;
++
+ mapping = gpio_charger->current_limit_map[i];
+
+ for (i = 0; i < ndescs; i++) {
drm-amdkfd-use-device-based-logging-for-errors.patch
drm-amdkfd-pause-autosuspend-when-creating-pdd.patch
freezer-sched-report-frozen-tasks-as-d-instead-of-r.patch
+tracing-constify-string-literal-data-member-in-struct-trace_event_call.patch
+tracing-prevent-bad-count-for-tracing_cpumask_write.patch
+io_uring-sqpoll-fix-sqpoll-error-handling-races.patch
+i2c-microchip-core-actually-use-repeated-sends.patch
+x86-fred-clear-wfe-in-missing-endbranch-cps.patch
+pci-msi-handle-lack-of-irqdomain-gracefully.patch
+i2c-imx-add-imx7d-compatible-string-for-applying-erratum-err007805.patch
+i2c-microchip-core-fix-ghost-detections.patch
+power-supply-gpio-charger-fix-set-charge-current-limits.patch
--- /dev/null
+From 452f4b31e3f70a52b97890888eeb9eaa9a87139a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20G=C3=B6ttsche?= <cgzones@googlemail.com>
+Date: Mon, 25 Nov 2024 11:50:25 +0100
+Subject: tracing: Constify string literal data member in struct trace_event_call
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Christian Göttsche <cgzones@googlemail.com>
+
+commit 452f4b31e3f70a52b97890888eeb9eaa9a87139a upstream.
+
+The name member of the struct trace_event_call is assigned with
+generated string literals; declare them pointer to read-only.
+
+Reported by clang:
+
+ security/landlock/syscalls.c:179:1: warning: initializing 'char *' with an expression of type 'const char[34]' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
+ 179 | SYSCALL_DEFINE3(landlock_create_ruleset,
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 180 | const struct landlock_ruleset_attr __user *const, attr,
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 181 | const size_t, size, const __u32, flags)
+ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ ./include/linux/syscalls.h:226:36: note: expanded from macro 'SYSCALL_DEFINE3'
+ 226 | #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ ./include/linux/syscalls.h:234:2: note: expanded from macro 'SYSCALL_DEFINEx'
+ 234 | SYSCALL_METADATA(sname, x, __VA_ARGS__) \
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ ./include/linux/syscalls.h:184:2: note: expanded from macro 'SYSCALL_METADATA'
+ 184 | SYSCALL_TRACE_ENTER_EVENT(sname); \
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ ./include/linux/syscalls.h:151:30: note: expanded from macro 'SYSCALL_TRACE_ENTER_EVENT'
+ 151 | .name = "sys_enter"#sname, \
+ | ^~~~~~~~~~~~~~~~~
+
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Cc: Mickaël Salaün <mic@digikod.net>
+Cc: Günther Noack <gnoack@google.com>
+Cc: Nathan Chancellor <nathan@kernel.org>
+Cc: Nick Desaulniers <ndesaulniers@google.com>
+Cc: Bill Wendling <morbo@google.com>
+Cc: Justin Stitt <justinstitt@google.com>
+Link: https://lore.kernel.org/20241125105028.42807-1-cgoettsche@seltendoof.de
+Fixes: b77e38aa240c3 ("tracing: add event trace infrastructure")
+Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/trace_events.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/trace_events.h
++++ b/include/linux/trace_events.h
+@@ -369,7 +369,7 @@ struct trace_event_call {
+ struct list_head list;
+ struct trace_event_class *class;
+ union {
+- char *name;
++ const char *name;
+ /* Set TRACE_EVENT_FL_TRACEPOINT flag when using "tp" */
+ struct tracepoint *tp;
+ };
--- /dev/null
+From 98feccbf32cfdde8c722bc4587aaa60ee5ac33f0 Mon Sep 17 00:00:00 2001
+From: Lizhi Xu <lizhi.xu@windriver.com>
+Date: Mon, 16 Dec 2024 15:32:38 +0800
+Subject: tracing: Prevent bad count for tracing_cpumask_write
+
+From: Lizhi Xu <lizhi.xu@windriver.com>
+
+commit 98feccbf32cfdde8c722bc4587aaa60ee5ac33f0 upstream.
+
+If a large count is provided, it will trigger a warning in bitmap_parse_user.
+Also check zero for it.
+
+Cc: stable@vger.kernel.org
+Fixes: 9e01c1b74c953 ("cpumask: convert kernel trace functions")
+Link: https://lore.kernel.org/20241216073238.2573704-1-lizhi.xu@windriver.com
+Reported-by: syzbot+0aecfd34fb878546f3fd@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=0aecfd34fb878546f3fd
+Tested-by: syzbot+0aecfd34fb878546f3fd@syzkaller.appspotmail.com
+Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -5331,6 +5331,9 @@ tracing_cpumask_write(struct file *filp,
+ cpumask_var_t tracing_cpumask_new;
+ int err;
+
++ if (count == 0 || count > KMALLOC_MAX_SIZE)
++ return -EINVAL;
++
+ if (!zalloc_cpumask_var(&tracing_cpumask_new, GFP_KERNEL))
+ return -ENOMEM;
+
--- /dev/null
+From dc81e556f2a017d681251ace21bf06c126d5a192 Mon Sep 17 00:00:00 2001
+From: "Xin Li (Intel)" <xin@zytor.com>
+Date: Wed, 13 Nov 2024 09:59:34 -0800
+Subject: x86/fred: Clear WFE in missing-ENDBRANCH #CPs
+
+From: Xin Li (Intel) <xin@zytor.com>
+
+commit dc81e556f2a017d681251ace21bf06c126d5a192 upstream.
+
+An indirect branch instruction sets the CPU indirect branch tracker
+(IBT) into WAIT_FOR_ENDBRANCH (WFE) state and WFE stays asserted
+across the instruction boundary. When the decoder finds an
+inappropriate instruction while WFE is set ENDBR, the CPU raises a #CP
+fault.
+
+For the "kernel IBT no ENDBR" selftest where #CPs are deliberately
+triggered, the WFE state of the interrupted context needs to be
+cleared to let execution continue. Otherwise when the CPU resumes
+from the instruction that just caused the previous #CP, another
+missing-ENDBRANCH #CP is raised and the CPU enters a dead loop.
+
+This is not a problem with IDT because it doesn't preserve WFE and
+IRET doesn't set WFE. But FRED provides space on the entry stack
+(in an expanded CS area) to save and restore the WFE state, thus the
+WFE state is no longer clobbered, so software must clear it.
+
+Clear WFE to avoid dead looping in ibt_clear_fred_wfe() and the
+!ibt_fatal code path when execution is allowed to continue.
+
+Clobbering WFE in any other circumstance is a security-relevant bug.
+
+[ dhansen: changelog rewording ]
+
+Fixes: a5f6c2ace997 ("x86/shstk: Add user control-protection fault handler")
+Signed-off-by: Xin Li (Intel) <xin@zytor.com>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/all/20241113175934.3897541-1-xin%40zytor.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cet.c | 30 ++++++++++++++++++++++++++++++
+ 1 file changed, 30 insertions(+)
+
+diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c
+index d2c732a34e5d..303bf74d175b 100644
+--- a/arch/x86/kernel/cet.c
++++ b/arch/x86/kernel/cet.c
+@@ -81,6 +81,34 @@ static void do_user_cp_fault(struct pt_regs *regs, unsigned long error_code)
+
+ static __ro_after_init bool ibt_fatal = true;
+
++/*
++ * By definition, all missing-ENDBRANCH #CPs are a result of WFE && !ENDBR.
++ *
++ * For the kernel IBT no ENDBR selftest where #CPs are deliberately triggered,
++ * the WFE state of the interrupted context needs to be cleared to let execution
++ * continue. Otherwise when the CPU resumes from the instruction that just
++ * caused the previous #CP, another missing-ENDBRANCH #CP is raised and the CPU
++ * enters a dead loop.
++ *
++ * This is not a problem with IDT because it doesn't preserve WFE and IRET doesn't
++ * set WFE. But FRED provides space on the entry stack (in an expanded CS area)
++ * to save and restore the WFE state, thus the WFE state is no longer clobbered,
++ * so software must clear it.
++ */
++static void ibt_clear_fred_wfe(struct pt_regs *regs)
++{
++ /*
++ * No need to do any FRED checks.
++ *
++ * For IDT event delivery, the high-order 48 bits of CS are pushed
++ * as 0s into the stack, and later IRET ignores these bits.
++ *
++ * For FRED, a test to check if fred_cs.wfe is set would be dropped
++ * by compilers.
++ */
++ regs->fred_cs.wfe = 0;
++}
++
+ static void do_kernel_cp_fault(struct pt_regs *regs, unsigned long error_code)
+ {
+ if ((error_code & CP_EC) != CP_ENDBR) {
+@@ -90,6 +118,7 @@ static void do_kernel_cp_fault(struct pt_regs *regs, unsigned long error_code)
+
+ if (unlikely(regs->ip == (unsigned long)&ibt_selftest_noendbr)) {
+ regs->ax = 0;
++ ibt_clear_fred_wfe(regs);
+ return;
+ }
+
+@@ -97,6 +126,7 @@ static void do_kernel_cp_fault(struct pt_regs *regs, unsigned long error_code)
+ if (!ibt_fatal) {
+ printk(KERN_DEFAULT CUT_HERE);
+ __warn(__FILE__, __LINE__, (void *)regs->ip, TAINT_WARN, regs, NULL);
++ ibt_clear_fred_wfe(regs);
+ return;
+ }
+ BUG();
+--
+2.47.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
