--- /dev/null
+From 0b83c86b444ab467134b0e618f45ad2216a4973c Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Tue, 26 Nov 2024 19:47:05 +0900
+Subject: block: Prevent potential deadlock in blk_revalidate_disk_zones()
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+commit 0b83c86b444ab467134b0e618f45ad2216a4973c upstream.
+
+The function blk_revalidate_disk_zones() calls the function
+disk_update_zone_resources() after freezing the device queue. In turn,
+disk_update_zone_resources() calls queue_limits_start_update() which
+takes a queue limits mutex lock, resulting in the ordering:
+q->q_usage_counter check -> q->limits_lock. However, the usual ordering
+is to always take a queue limit lock before freezing the queue to commit
+the limits updates, e.g., the code pattern:
+
+lim = queue_limits_start_update(q);
+...
+blk_mq_freeze_queue(q);
+ret = queue_limits_commit_update(q, &lim);
+blk_mq_unfreeze_queue(q);
+
+Thus, blk_revalidate_disk_zones() introduces a potential circular
+locking dependency deadlock that lockdep sometimes catches with the
+splat:
+
+[ 51.934109] ======================================================
+[ 51.935916] WARNING: possible circular locking dependency detected
+[ 51.937561] 6.12.0+ #2107 Not tainted
+[ 51.938648] ------------------------------------------------------
+[ 51.940351] kworker/u16:4/157 is trying to acquire lock:
+[ 51.941805] ffff9fff0aa0bea8 (&q->limits_lock){+.+.}-{4:4}, at: disk_update_zone_resources+0x86/0x170
+[ 51.944314]
+ but task is already holding lock:
+[ 51.945688] ffff9fff0aa0b890 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: blk_revalidate_disk_zones+0x15f/0x340
+[ 51.948527]
+ which lock already depends on the new lock.
+
+[ 51.951296]
+ the existing dependency chain (in reverse order) is:
+[ 51.953708]
+ -> #1 (&q->q_usage_counter(queue)#3){++++}-{0:0}:
+[ 51.956131] blk_queue_enter+0x1c9/0x1e0
+[ 51.957290] blk_mq_alloc_request+0x187/0x2a0
+[ 51.958365] scsi_execute_cmd+0x78/0x490 [scsi_mod]
+[ 51.959514] read_capacity_16+0x111/0x410 [sd_mod]
+[ 51.960693] sd_revalidate_disk.isra.0+0x872/0x3240 [sd_mod]
+[ 51.962004] sd_probe+0x2d7/0x520 [sd_mod]
+[ 51.962993] really_probe+0xd5/0x330
+[ 51.963898] __driver_probe_device+0x78/0x110
+[ 51.964925] driver_probe_device+0x1f/0xa0
+[ 51.965916] __driver_attach_async_helper+0x60/0xe0
+[ 51.967017] async_run_entry_fn+0x2e/0x140
+[ 51.968004] process_one_work+0x21f/0x5a0
+[ 51.968987] worker_thread+0x1dc/0x3c0
+[ 51.969868] kthread+0xe0/0x110
+[ 51.970377] ret_from_fork+0x31/0x50
+[ 51.970983] ret_from_fork_asm+0x11/0x20
+[ 51.971587]
+ -> #0 (&q->limits_lock){+.+.}-{4:4}:
+[ 51.972479] __lock_acquire+0x1337/0x2130
+[ 51.973133] lock_acquire+0xc5/0x2d0
+[ 51.973691] __mutex_lock+0xda/0xcf0
+[ 51.974300] disk_update_zone_resources+0x86/0x170
+[ 51.975032] blk_revalidate_disk_zones+0x16c/0x340
+[ 51.975740] sd_zbc_revalidate_zones+0x73/0x160 [sd_mod]
+[ 51.976524] sd_revalidate_disk.isra.0+0x465/0x3240 [sd_mod]
+[ 51.977824] sd_probe+0x2d7/0x520 [sd_mod]
+[ 51.978917] really_probe+0xd5/0x330
+[ 51.979915] __driver_probe_device+0x78/0x110
+[ 51.981047] driver_probe_device+0x1f/0xa0
+[ 51.982143] __driver_attach_async_helper+0x60/0xe0
+[ 51.983282] async_run_entry_fn+0x2e/0x140
+[ 51.984319] process_one_work+0x21f/0x5a0
+[ 51.985873] worker_thread+0x1dc/0x3c0
+[ 51.987289] kthread+0xe0/0x110
+[ 51.988546] ret_from_fork+0x31/0x50
+[ 51.989926] ret_from_fork_asm+0x11/0x20
+[ 51.991376]
+ other info that might help us debug this:
+
+[ 51.994127] Possible unsafe locking scenario:
+
+[ 51.995651] CPU0 CPU1
+[ 51.996694] ---- ----
+[ 51.997716] lock(&q->q_usage_counter(queue)#3);
+[ 51.998817] lock(&q->limits_lock);
+[ 52.000043] lock(&q->q_usage_counter(queue)#3);
+[ 52.001638] lock(&q->limits_lock);
+[ 52.002485]
+ *** DEADLOCK ***
+
+Prevent this issue by moving the calls to blk_mq_freeze_queue() and
+blk_mq_unfreeze_queue() around the call to queue_limits_commit_update()
+in disk_update_zone_resources(). In case of revalidation failure, the
+call to disk_free_zone_resources() in blk_revalidate_disk_zones()
+is still done with the queue frozen as before.
+
+Fixes: 843283e96e5a ("block: Fake max open zones limit when there is no limit")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Link: https://lore.kernel.org/r/20241126104705.183996-1-dlemoal@kernel.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/blk-zoned.c | 14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+--- a/block/blk-zoned.c
++++ b/block/blk-zoned.c
+@@ -1541,6 +1541,7 @@ static int disk_update_zone_resources(st
+ unsigned int nr_seq_zones, nr_conv_zones = 0;
+ unsigned int pool_size;
+ struct queue_limits lim;
++ int ret;
+
+ disk->nr_zones = args->nr_zones;
+ disk->zone_capacity = args->zone_capacity;
+@@ -1593,7 +1594,11 @@ static int disk_update_zone_resources(st
+ }
+
+ commit:
+- return queue_limits_commit_update(q, &lim);
++ blk_mq_freeze_queue(q);
++ ret = queue_limits_commit_update(q, &lim);
++ blk_mq_unfreeze_queue(q);
++
++ return ret;
+ }
+
+ static int blk_revalidate_conv_zone(struct blk_zone *zone, unsigned int idx,
+@@ -1814,14 +1819,15 @@ int blk_revalidate_disk_zones(struct gen
+ * Set the new disk zone parameters only once the queue is frozen and
+ * all I/Os are completed.
+ */
+- blk_mq_freeze_queue(q);
+ if (ret > 0)
+ ret = disk_update_zone_resources(disk, &args);
+ else
+ pr_warn("%s: failed to revalidate zones\n", disk->disk_name);
+- if (ret)
++ if (ret) {
++ blk_mq_freeze_queue(q);
+ disk_free_zone_resources(disk);
+- blk_mq_unfreeze_queue(q);
++ blk_mq_unfreeze_queue(q);
++ }
+
+ kfree(args.conv_zones_bitmap);
+
--- /dev/null
+From 12b3642b6c242061d3ba84e6e3050c3141ded14c Mon Sep 17 00:00:00 2001
+From: Michal Simek <michal.simek@amd.com>
+Date: Mon, 16 Sep 2024 11:53:06 +0200
+Subject: dt-bindings: serial: rs485: Fix rs485-rts-delay property
+
+From: Michal Simek <michal.simek@amd.com>
+
+commit 12b3642b6c242061d3ba84e6e3050c3141ded14c upstream.
+
+Code expects array only with 2 items which should be checked.
+But also item checking is not working as it should likely because of
+incorrect items description.
+
+Fixes: d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings to json-schema")
+Signed-off-by: Michal Simek <michal.simek@amd.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Link: https://lore.kernel.org/r/820c639b9e22fe037730ed44d1b044cdb6d28b75.1726480384.git.michal.simek@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/devicetree/bindings/serial/rs485.yaml | 19 +++++++++----------
+ 1 file changed, 9 insertions(+), 10 deletions(-)
+
+--- a/Documentation/devicetree/bindings/serial/rs485.yaml
++++ b/Documentation/devicetree/bindings/serial/rs485.yaml
+@@ -18,16 +18,15 @@ properties:
+ description: prop-encoded-array <a b>
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+- items:
+- - description: Delay between rts signal and beginning of data sent in
+- milliseconds. It corresponds to the delay before sending data.
+- default: 0
+- maximum: 100
+- - description: Delay between end of data sent and rts signal in milliseconds.
+- It corresponds to the delay after sending data and actual release
+- of the line.
+- default: 0
+- maximum: 100
++ - description: Delay between rts signal and beginning of data sent in
++ milliseconds. It corresponds to the delay before sending data.
++ default: 0
++ maximum: 100
++ - description: Delay between end of data sent and rts signal in milliseconds.
++ It corresponds to the delay after sending data and actual release
++ of the line.
++ default: 0
++ maximum: 100
+
+ rs485-rts-active-high:
+ description: drive RTS high when sending (this is the default).
--- /dev/null
+From e2fb2f89faf87b681038475d093214f4cbe12ebb Mon Sep 17 00:00:00 2001
+From: Zicheng Qu <quzicheng@huawei.com>
+Date: Thu, 31 Oct 2024 01:45:05 +0000
+Subject: iio: gts: Fix uninitialized symbol 'ret'
+
+From: Zicheng Qu <quzicheng@huawei.com>
+
+commit e2fb2f89faf87b681038475d093214f4cbe12ebb upstream.
+
+Initialize the variable ret at the time of declaration to prevent it from
+being returned without a defined value. Fixes smatch warning:
+drivers/iio/industrialio-gts-helper.c:256 gain_to_scaletables() error:
+uninitialized symbol 'ret'.
+
+Cc: stable@vger.kernel.org # v6.6+
+Fixes: 38416c28e168 ("iio: light: Add gain-time-scale helpers")
+Signed-off-by: Zicheng Qu <quzicheng@huawei.com>
+Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
+Link: https://patch.msgid.link/20241031014505.2313035-1-quzicheng@huawei.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/industrialio-gts-helper.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/industrialio-gts-helper.c
++++ b/drivers/iio/industrialio-gts-helper.c
+@@ -167,7 +167,7 @@ static int iio_gts_gain_cmp(const void *
+
+ static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales)
+ {
+- int ret, i, j, new_idx, time_idx;
++ int i, j, new_idx, time_idx, ret = 0;
+ int *all_gains;
+ size_t gain_bytes;
+
--- /dev/null
+From 12aaf67584cf19dc84615b7aba272fe642c35b8b Mon Sep 17 00:00:00 2001
+From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
+Date: Thu, 21 Nov 2024 12:48:25 +0000
+Subject: irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain
+
+From: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+
+commit 12aaf67584cf19dc84615b7aba272fe642c35b8b upstream.
+
+Commit fbdf14e90ce4 ("irqchip/irq-mvebu-sei: Switch to MSI parent")
+introduced in v6.11-rc1 broke Mavell Armada platforms (and possibly others)
+by incorrectly switching irq-mvebu-sei to MSI parent.
+
+In the above commit, msi_parent_ops is set for the sei->cp_domain, but
+rather than adding a .select method to mvebu_sei_cp_domain_ops (which is
+associated with sei->cp_domain), it was added to mvebu_sei_domain_ops which
+is associated with sei->sei_domain, which doesn't have any
+msi_parent_ops. This makes the call to msi_lib_irq_domain_select() always
+fail.
+
+This bug manifests itself with the following kernel messages on Armada 8040
+based systems:
+
+ platform f21e0000.interrupt-controller:interrupt-controller@50: deferred probe pending: (reason unknown)
+ platform f41e0000.interrupt-controller:interrupt-controller@50: deferred probe pending: (reason unknown)
+
+Move the select callback to mvebu_sei_cp_domain_ops to cure it.
+
+Fixes: fbdf14e90ce4 ("irqchip/irq-mvebu-sei: Switch to MSI parent")
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/all/E1tE6bh-004CmX-QU@rmk-PC.armlinux.org.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-mvebu-sei.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/irqchip/irq-mvebu-sei.c b/drivers/irqchip/irq-mvebu-sei.c
+index f8c70f2d100a..065166ab5dbc 100644
+--- a/drivers/irqchip/irq-mvebu-sei.c
++++ b/drivers/irqchip/irq-mvebu-sei.c
+@@ -192,7 +192,6 @@ static void mvebu_sei_domain_free(struct irq_domain *domain, unsigned int virq,
+ }
+
+ static const struct irq_domain_ops mvebu_sei_domain_ops = {
+- .select = msi_lib_irq_domain_select,
+ .alloc = mvebu_sei_domain_alloc,
+ .free = mvebu_sei_domain_free,
+ };
+@@ -306,6 +305,7 @@ static void mvebu_sei_cp_domain_free(struct irq_domain *domain,
+ }
+
+ static const struct irq_domain_ops mvebu_sei_cp_domain_ops = {
++ .select = msi_lib_irq_domain_select,
+ .alloc = mvebu_sei_cp_domain_alloc,
+ .free = mvebu_sei_cp_domain_free,
+ };
+--
+2.47.1
+
--- /dev/null
+From fe051552f5078fa02d593847529a3884305a6ffe Mon Sep 17 00:00:00 2001
+From: Kinsey Moore <kinsey.moore@oarcorp.com>
+Date: Tue, 23 Jul 2024 15:58:05 -0500
+Subject: jffs2: Prevent rtime decompress memory corruption
+
+From: Kinsey Moore <kinsey.moore@oarcorp.com>
+
+commit fe051552f5078fa02d593847529a3884305a6ffe upstream.
+
+The rtime decompression routine does not fully check bounds during the
+entirety of the decompression pass and can corrupt memory outside the
+decompression buffer if the compressed data is corrupted. This adds the
+required check to prevent this failure mode.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Kinsey Moore <kinsey.moore@oarcorp.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/jffs2/compr_rtime.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/jffs2/compr_rtime.c
++++ b/fs/jffs2/compr_rtime.c
+@@ -95,6 +95,9 @@ static int jffs2_rtime_decompress(unsign
+
+ positions[value]=outpos;
+ if (repeat) {
++ if ((outpos + repeat) >= destlen) {
++ return 1;
++ }
+ if (backoffs + repeat >= outpos) {
+ while(repeat) {
+ cpage_out[outpos++] = cpage_out[backoffs++];
--- /dev/null
+From 07593293ffabba14125c8998525adde5a832bfa3 Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Sat, 19 Oct 2024 22:27:03 +0200
+Subject: mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit 07593293ffabba14125c8998525adde5a832bfa3 upstream.
+
+The 'fw_vols' fwnode_handle initialized via
+device_get_named_child_node() requires explicit calls to
+fwnode_handle_put() when the variable is no longer required.
+
+Add the missing calls to fwnode_handle_put() before the function
+returns.
+
+Cc: stable@vger.kernel.org
+Fixes: 51932f9fc487 ("mtd: ubi: populate ubi volume fwnode")
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/ubi/vmt.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/mtd/ubi/vmt.c
++++ b/drivers/mtd/ubi/vmt.c
+@@ -143,8 +143,10 @@ static struct fwnode_handle *find_volume
+ vol->vol_id != volid)
+ continue;
+
++ fwnode_handle_put(fw_vols);
+ return fw_vol;
+ }
++ fwnode_handle_put(fw_vols);
+
+ return NULL;
+ }
--- /dev/null
+From bcc7ba668818dcadd2f1db66b39ed860a63ecf97 Mon Sep 17 00:00:00 2001
+From: Bin Liu <b-liu@ti.com>
+Date: Thu, 31 Oct 2024 12:23:15 -0500
+Subject: serial: 8250: omap: Move pm_runtime_get_sync
+
+From: Bin Liu <b-liu@ti.com>
+
+commit bcc7ba668818dcadd2f1db66b39ed860a63ecf97 upstream.
+
+Currently in omap_8250_shutdown, the dma->rx_running flag is
+set to zero in omap_8250_rx_dma_flush. Next pm_runtime_get_sync
+is called, which is a runtime resume call stack which can
+re-set the flag. When the call omap_8250_shutdown returns, the
+flag is expected to be UN-SET, but this is not the case. This
+is causing issues the next time UART is re-opened and
+omap_8250_rx_dma is called. Fix by moving pm_runtime_get_sync
+before the omap_8250_rx_dma_flush.
+
+cc: stable@vger.kernel.org
+Fixes: 0e31c8d173ab ("tty: serial: 8250_omap: add custom DMA-RX callback")
+Signed-off-by: Bin Liu <b-liu@ti.com>
+[Judith: Add commit message]
+Signed-off-by: Judith Mendez <jm@ti.com>
+Reviewed-by: Kevin Hilman <khilman@baylibre.com>
+Tested-by: Kevin Hilman <khilman@baylibre.com>
+Link: https://lore.kernel.org/r/20241031172315.453750-1-jm@ti.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_omap.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250_omap.c
++++ b/drivers/tty/serial/8250/8250_omap.c
+@@ -777,12 +777,12 @@ static void omap_8250_shutdown(struct ua
+ struct uart_8250_port *up = up_to_u8250p(port);
+ struct omap8250_priv *priv = port->private_data;
+
++ pm_runtime_get_sync(port->dev);
++
+ flush_work(&priv->qos_work);
+ if (up->dma)
+ omap_8250_rx_dma_flush(up);
+
+- pm_runtime_get_sync(port->dev);
+-
+ serial_out(up, UART_OMAP_WER, 0);
+ if (priv->habit & UART_HAS_EFR2)
+ serial_out(up, UART_OMAP_EFR2, 0x0);
--- /dev/null
+From 166105c9030a30ba08574a9998afc7b60bc72dd7 Mon Sep 17 00:00:00 2001
+From: Filip Brozovic <fbrozovic@gmail.com>
+Date: Sun, 10 Nov 2024 12:17:00 +0100
+Subject: serial: 8250_fintek: Add support for F81216E
+
+From: Filip Brozovic <fbrozovic@gmail.com>
+
+commit 166105c9030a30ba08574a9998afc7b60bc72dd7 upstream.
+
+The F81216E is a LPC/eSPI to 4 UART Super I/O and is mostly compatible with
+the F81216H, but does not support RS-485 auto-direction delays on any port.
+
+Signed-off-by: Filip Brozovic <fbrozovic@gmail.com>
+Cc: stable <stable@kernel.org>
+Link: https://lore.kernel.org/r/20241110111703.15494-1-fbrozovic@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_fintek.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/8250/8250_fintek.c
++++ b/drivers/tty/serial/8250/8250_fintek.c
+@@ -21,6 +21,7 @@
+ #define CHIP_ID_F81866 0x1010
+ #define CHIP_ID_F81966 0x0215
+ #define CHIP_ID_F81216AD 0x1602
++#define CHIP_ID_F81216E 0x1617
+ #define CHIP_ID_F81216H 0x0501
+ #define CHIP_ID_F81216 0x0802
+ #define VENDOR_ID1 0x23
+@@ -158,6 +159,7 @@ static int fintek_8250_check_id(struct f
+ case CHIP_ID_F81866:
+ case CHIP_ID_F81966:
+ case CHIP_ID_F81216AD:
++ case CHIP_ID_F81216E:
+ case CHIP_ID_F81216H:
+ case CHIP_ID_F81216:
+ break;
+@@ -181,6 +183,7 @@ static int fintek_8250_get_ldn_range(str
+ return 0;
+
+ case CHIP_ID_F81216AD:
++ case CHIP_ID_F81216E:
+ case CHIP_ID_F81216H:
+ case CHIP_ID_F81216:
+ *min = F81216_LDN_LOW;
+@@ -250,6 +253,7 @@ static void fintek_8250_set_irq_mode(str
+ break;
+
+ case CHIP_ID_F81216AD:
++ case CHIP_ID_F81216E:
+ case CHIP_ID_F81216H:
+ case CHIP_ID_F81216:
+ sio_write_mask_reg(pdata, FINTEK_IRQ_MODE, IRQ_SHARE,
+@@ -263,7 +267,8 @@ static void fintek_8250_set_irq_mode(str
+ static void fintek_8250_set_max_fifo(struct fintek_8250 *pdata)
+ {
+ switch (pdata->pid) {
+- case CHIP_ID_F81216H: /* 128Bytes FIFO */
++ case CHIP_ID_F81216E: /* 128Bytes FIFO */
++ case CHIP_ID_F81216H:
+ case CHIP_ID_F81966:
+ case CHIP_ID_F81866:
+ sio_write_mask_reg(pdata, FIFO_CTRL,
+@@ -297,6 +302,7 @@ static void fintek_8250_set_termios(stru
+ goto exit;
+
+ switch (pdata->pid) {
++ case CHIP_ID_F81216E:
+ case CHIP_ID_F81216H:
+ reg = RS485;
+ break;
+@@ -346,6 +352,7 @@ static void fintek_8250_set_termios_hand
+ struct fintek_8250 *pdata = uart->port.private_data;
+
+ switch (pdata->pid) {
++ case CHIP_ID_F81216E:
+ case CHIP_ID_F81216H:
+ case CHIP_ID_F81966:
+ case CHIP_ID_F81866:
+@@ -438,6 +445,11 @@ static void fintek_8250_set_rs485_handle
+ uart->port.rs485_supported = fintek_8250_rs485_supported;
+ break;
+
++ case CHIP_ID_F81216E: /* F81216E does not support RS485 delays */
++ uart->port.rs485_config = fintek_8250_rs485_config;
++ uart->port.rs485_supported = fintek_8250_rs485_supported;
++ break;
++
+ default: /* No RS485 Auto direction functional */
+ break;
+ }
--- /dev/null
+From b5a23a60e8ab5711f4952912424347bf3864ce8d Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 15 Nov 2024 11:59:54 +0100
+Subject: serial: amba-pl011: fix build regression
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit b5a23a60e8ab5711f4952912424347bf3864ce8d upstream.
+
+When CONFIG_DMA_ENGINE is disabled, the driver now fails to build:
+
+drivers/tty/serial/amba-pl011.c: In function 'pl011_unthrottle_rx':
+drivers/tty/serial/amba-pl011.c:1822:16: error: 'struct uart_amba_port' has no member named 'using_rx_dma'
+ 1822 | if (uap->using_rx_dma) {
+ | ^~
+drivers/tty/serial/amba-pl011.c:1823:20: error: 'struct uart_amba_port' has no member named 'dmacr'
+ 1823 | uap->dmacr |= UART011_RXDMAE;
+ | ^~
+drivers/tty/serial/amba-pl011.c:1824:32: error: 'struct uart_amba_port' has no member named 'dmacr'
+ 1824 | pl011_write(uap->dmacr, uap, REG_DMACR);
+ | ^~
+
+Add the missing #ifdef check around these field accesses, matching
+what other parts of this driver do.
+
+Fixes: 2bcacc1c87ac ("serial: amba-pl011: Fix RX stall when DMA is used")
+Cc: stable <stable@kernel.org>
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202411140617.nkjeHhsK-lkp@intel.com/
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Link: https://lore.kernel.org/r/20241115110021.744332-1-arnd@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/amba-pl011.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/tty/serial/amba-pl011.c
++++ b/drivers/tty/serial/amba-pl011.c
+@@ -1819,10 +1819,12 @@ static void pl011_unthrottle_rx(struct u
+
+ pl011_write(uap->im, uap, REG_IMSC);
+
++#ifdef CONFIG_DMA_ENGINE
+ if (uap->using_rx_dma) {
+ uap->dmacr |= UART011_RXDMAE;
+ pl011_write(uap->dmacr, uap, REG_DMACR);
+ }
++#endif
+
+ uart_port_unlock_irqrestore(&uap->port, flags);
+ }
--- /dev/null
+From 2bcacc1c87acf9a8ebc17de18cb2b3cfeca547cf Mon Sep 17 00:00:00 2001
+From: Kartik Rajput <kkartik@nvidia.com>
+Date: Wed, 13 Nov 2024 14:56:29 +0530
+Subject: serial: amba-pl011: Fix RX stall when DMA is used
+
+From: Kartik Rajput <kkartik@nvidia.com>
+
+commit 2bcacc1c87acf9a8ebc17de18cb2b3cfeca547cf upstream.
+
+Function pl011_throttle_rx() calls pl011_stop_rx() to disable RX, which
+also disables the RX DMA by clearing the RXDMAE bit of the DMACR
+register. However, to properly unthrottle RX when DMA is used, the
+function pl011_unthrottle_rx() is expected to set the RXDMAE bit of
+the DMACR register, which it currently lacks. This causes RX to stall
+after the throttle API is called.
+
+Set RXDMAE bit in the DMACR register while unthrottling RX if RX DMA is
+used.
+
+Fixes: 211565b10099 ("serial: pl011: UPSTAT_AUTORTS requires .throttle/unthrottle")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/20241113092629.60226-1-kkartik@nvidia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/amba-pl011.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/tty/serial/amba-pl011.c
++++ b/drivers/tty/serial/amba-pl011.c
+@@ -1819,6 +1819,11 @@ static void pl011_unthrottle_rx(struct u
+
+ pl011_write(uap->im, uap, REG_IMSC);
+
++ if (uap->using_rx_dma) {
++ uap->dmacr |= UART011_RXDMAE;
++ pl011_write(uap->dmacr, uap, REG_DMACR);
++ }
++
+ uart_port_unlock_irqrestore(&uap->port, flags);
+ }
+
ksmbd-fix-use-after-free-in-smb-request-handling.patch
smb-client-fix-null-ptr-deref-in-crypto_aead_setkey.patch
platform-chrome-cros_ec_typec-fix-missing-fwnode-reference-decrement.patch
+irqchip-irq-mvebu-sei-move-misplaced-select-callback-to-sei-cp-domain.patch
+x86-cpu-amd-terminate-the-erratum_1386_microcode-array.patch
+ubi-wl-put-source-peb-into-correct-list-if-trying-locking-leb-failed.patch
+um-ubd-do-not-use-drvdata-in-release.patch
+um-net-do-not-use-drvdata-in-release.patch
+dt-bindings-serial-rs485-fix-rs485-rts-delay-property.patch
+serial-8250_fintek-add-support-for-f81216e.patch
+serial-8250-omap-move-pm_runtime_get_sync.patch
+serial-amba-pl011-fix-rx-stall-when-dma-is-used.patch
+serial-amba-pl011-fix-build-regression.patch
+jffs2-prevent-rtime-decompress-memory-corruption.patch
+mtd-ubi-fix-unreleased-fwnode_handle-in-find_volume_fwnode.patch
+block-prevent-potential-deadlock-in-blk_revalidate_disk_zones.patch
+um-vector-do-not-use-drvdata-in-release.patch
+sh-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch
+iio-gts-fix-uninitialized-symbol-ret.patch
--- /dev/null
+From 3c891f7c6a4e90bb1199497552f24b26e46383bc Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Thu, 14 Jul 2022 16:41:36 +0800
+Subject: sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit 3c891f7c6a4e90bb1199497552f24b26e46383bc upstream.
+
+When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected,
+cpu_max_bits_warn() generates a runtime warning similar as below when
+showing /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)
+instead of NR_CPUS to iterate CPUs.
+
+[ 3.052463] ------------[ cut here ]------------
+[ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0
+[ 3.070072] Modules linked in: efivarfs autofs4
+[ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052
+[ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000
+[ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430
+[ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff
+[ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890
+[ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa
+[ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000
+[ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000
+[ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000
+[ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286
+[ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
+[ 3.195868] ...
+[ 3.199917] Call Trace:
+[ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c
+[ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88
+[ 3.217625] [<900000000023d268>] __warn+0xd0/0x100
+[ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc
+[ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0
+[ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4
+[ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4
+[ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0
+[ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100
+[ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94
+[ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160
+[ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/sh/kernel/cpu/proc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/sh/kernel/cpu/proc.c
++++ b/arch/sh/kernel/cpu/proc.c
+@@ -132,7 +132,7 @@ static int show_cpuinfo(struct seq_file
+
+ static void *c_start(struct seq_file *m, loff_t *pos)
+ {
+- return *pos < NR_CPUS ? cpu_data + *pos : NULL;
++ return *pos < nr_cpu_ids ? cpu_data + *pos : NULL;
+ }
+ static void *c_next(struct seq_file *m, void *v, loff_t *pos)
+ {
--- /dev/null
+From d610020f030bec819f42de327c2bd5437d2766b3 Mon Sep 17 00:00:00 2001
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+Date: Mon, 19 Aug 2024 11:26:21 +0800
+Subject: ubi: wl: Put source PEB into correct list if trying locking LEB failed
+
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+
+commit d610020f030bec819f42de327c2bd5437d2766b3 upstream.
+
+During wear-leveing work, the source PEB will be moved into scrub list
+when source LEB cannot be locked in ubi_eba_copy_leb(), which is wrong
+for non-scrub type source PEB. The problem could bring extra and
+ineffective wear-leveing jobs, which makes more or less negative effects
+for the life time of flash. Specifically, the process is divided 2 steps:
+1. wear_leveling_worker // generate false scrub type PEB
+ ubi_eba_copy_leb // MOVE_RETRY is returned
+ leb_write_trylock // trylock failed
+ scrubbing = 1;
+ e1 is put into ubi->scrub
+2. wear_leveling_worker // schedule false scrub type PEB for wl
+ scrubbing = 1
+ e1 = rb_entry(rb_first(&ubi->scrub))
+
+The problem can be reproduced easily by running fsstress on a small
+UBIFS partition(<64M, simulated by nandsim) for 5~10mins
+(CONFIG_MTD_UBI_FASTMAP=y,CONFIG_MTD_UBI_WL_THRESHOLD=50). Following
+message is shown:
+ ubi0: scrubbed PEB 66 (LEB 0:10), data moved to PEB 165
+
+Since scrub type source PEB has set variable scrubbing as '1', and
+variable scrubbing is checked before variable keep, so the problem can
+be fixed by setting keep variable as 1 directly if the source LEB cannot
+be locked.
+
+Fixes: e801e128b220 ("UBI: fix missing scrub when there is a bit-flip")
+CC: stable@vger.kernel.org
+Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/ubi/wl.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/mtd/ubi/wl.c
++++ b/drivers/mtd/ubi/wl.c
+@@ -846,7 +846,14 @@ static int wear_leveling_worker(struct u
+ goto out_not_moved;
+ }
+ if (err == MOVE_RETRY) {
+- scrubbing = 1;
++ /*
++ * For source PEB:
++ * 1. The scrubbing is set for scrub type PEB, it will
++ * be put back into ubi->scrub list.
++ * 2. Non-scrub type PEB will be put back into ubi->used
++ * list.
++ */
++ keep = 1;
+ dst_leb_clean = 1;
+ goto out_not_moved;
+ }
--- /dev/null
+From d1db692a9be3b4bd3473b64fcae996afaffe8438 Mon Sep 17 00:00:00 2001
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+Date: Tue, 5 Nov 2024 00:32:02 +0800
+Subject: um: net: Do not use drvdata in release
+
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+
+commit d1db692a9be3b4bd3473b64fcae996afaffe8438 upstream.
+
+The drvdata is not available in release. Let's just use container_of()
+to get the uml_net instance. Otherwise, removing a network device will
+result in a crash:
+
+RIP: 0033:net_device_release+0x10/0x6f
+RSP: 00000000e20c7c40 EFLAGS: 00010206
+RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0
+RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028
+RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70
+R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000
+R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6
+Kernel panic - not syncing: Segfault with no mm
+CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1
+Workqueue: events mc_work_proc
+Stack:
+ 627af028 62c7af00 e20c7c80 60276fcd
+ 62778000 603f5820 627af028 00000000
+ e20c7cb0 603a2bcd 627af000 62770010
+Call Trace:
+ [<60276fcd>] device_release+0x70/0xba
+ [<603a2bcd>] kobject_put+0xba/0xe7
+ [<60277265>] put_device+0x19/0x1c
+ [<60281266>] platform_device_put+0x26/0x29
+ [<60281e5f>] platform_device_unregister+0x2c/0x2e
+ [<6002ec9c>] net_remove+0x63/0x69
+ [<60031316>] ? mconsole_reply+0x0/0x50
+ [<600310c8>] mconsole_remove+0x160/0x1cc
+ [<60087d40>] ? __remove_hrtimer+0x38/0x74
+ [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98
+ [<6006b3cf>] ? dl_server_stop+0x3f/0x48
+ [<6006b390>] ? dl_server_stop+0x0/0x48
+ [<600672e8>] ? dequeue_entities+0x327/0x390
+ [<60038fa6>] ? um_set_signals+0x0/0x43
+ [<6003070c>] mc_work_proc+0x77/0x91
+ [<60057664>] process_scheduled_works+0x1b3/0x2dd
+ [<60055f32>] ? assign_work+0x0/0x58
+ [<60057f0a>] worker_thread+0x1e9/0x293
+ [<6005406f>] ? set_pf_worker+0x0/0x64
+ [<6005d65d>] ? arch_local_irq_save+0x0/0x2d
+ [<6005d748>] ? kthread_exit+0x0/0x3a
+ [<60057d21>] ? worker_thread+0x0/0x293
+ [<6005dbf1>] kthread+0x126/0x12b
+ [<600219c5>] new_thread_handler+0x85/0xb6
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
+Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
+Link: https://patch.msgid.link/20241104163203.435515-4-tiwei.btw@antgroup.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/um/drivers/net_kern.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/um/drivers/net_kern.c
++++ b/arch/um/drivers/net_kern.c
+@@ -336,7 +336,7 @@ static struct platform_driver uml_net_dr
+
+ static void net_device_release(struct device *dev)
+ {
+- struct uml_net *device = dev_get_drvdata(dev);
++ struct uml_net *device = container_of(dev, struct uml_net, pdev.dev);
+ struct net_device *netdev = device->dev;
+ struct uml_net_private *lp = netdev_priv(netdev);
+
--- /dev/null
+From 5bee35e5389f450a7eea7318deb9073e9414d3b1 Mon Sep 17 00:00:00 2001
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+Date: Tue, 5 Nov 2024 00:32:01 +0800
+Subject: um: ubd: Do not use drvdata in release
+
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+
+commit 5bee35e5389f450a7eea7318deb9073e9414d3b1 upstream.
+
+The drvdata is not available in release. Let's just use container_of()
+to get the ubd instance. Otherwise, removing a ubd device will result
+in a crash:
+
+RIP: 0033:blk_mq_free_tag_set+0x1f/0xba
+RSP: 00000000e2083bf0 EFLAGS: 00010246
+RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00
+RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348
+RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7
+R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000
+R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0
+Kernel panic - not syncing: Segfault with no mm
+CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1
+Workqueue: events mc_work_proc
+Stack:
+ 00000000 604f7ef0 62c5d000 62405d20
+ e2083c30 6002c776 6002c755 600e47ff
+ e2083c60 6025ffe3 04208060 603d36e0
+Call Trace:
+ [<6002c776>] ubd_device_release+0x21/0x55
+ [<6002c755>] ? ubd_device_release+0x0/0x55
+ [<600e47ff>] ? kfree+0x0/0x100
+ [<6025ffe3>] device_release+0x70/0xba
+ [<60381d6a>] kobject_put+0xb5/0xe2
+ [<6026027b>] put_device+0x19/0x1c
+ [<6026a036>] platform_device_put+0x26/0x29
+ [<6026ac5a>] platform_device_unregister+0x2c/0x2e
+ [<6002c52e>] ubd_remove+0xb8/0xd6
+ [<6002bb74>] ? mconsole_reply+0x0/0x50
+ [<6002b926>] mconsole_remove+0x160/0x1cc
+ [<6002bbbc>] ? mconsole_reply+0x48/0x50
+ [<6003379c>] ? um_set_signals+0x3b/0x43
+ [<60061c55>] ? update_min_vruntime+0x14/0x70
+ [<6006251f>] ? dequeue_task_fair+0x164/0x235
+ [<600620aa>] ? update_cfs_group+0x0/0x40
+ [<603a0e77>] ? __schedule+0x0/0x3ed
+ [<60033761>] ? um_set_signals+0x0/0x43
+ [<6002af6a>] mc_work_proc+0x77/0x91
+ [<600520b4>] process_scheduled_works+0x1af/0x2c3
+ [<6004ede3>] ? assign_work+0x0/0x58
+ [<600527a1>] worker_thread+0x2f7/0x37a
+ [<6004ee3b>] ? set_pf_worker+0x0/0x64
+ [<6005765d>] ? arch_local_irq_save+0x0/0x2d
+ [<60058e07>] ? kthread_exit+0x0/0x3a
+ [<600524aa>] ? worker_thread+0x0/0x37a
+ [<60058f9f>] kthread+0x130/0x135
+ [<6002068e>] new_thread_handler+0x85/0xb6
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
+Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
+Link: https://patch.msgid.link/20241104163203.435515-3-tiwei.btw@antgroup.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/um/drivers/ubd_kern.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/um/drivers/ubd_kern.c
++++ b/arch/um/drivers/ubd_kern.c
+@@ -779,7 +779,7 @@ static int ubd_open_dev(struct ubd *ubd_
+
+ static void ubd_device_release(struct device *dev)
+ {
+- struct ubd *ubd_dev = dev_get_drvdata(dev);
++ struct ubd *ubd_dev = container_of(dev, struct ubd, pdev.dev);
+
+ blk_mq_free_tag_set(&ubd_dev->tag_set);
+ *ubd_dev = ((struct ubd) DEFAULT_UBD);
--- /dev/null
+From 51b39d741970742a5c41136241a9c48ac607cf82 Mon Sep 17 00:00:00 2001
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+Date: Tue, 5 Nov 2024 00:32:03 +0800
+Subject: um: vector: Do not use drvdata in release
+
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+
+commit 51b39d741970742a5c41136241a9c48ac607cf82 upstream.
+
+The drvdata is not available in release. Let's just use container_of()
+to get the vector_device instance. Otherwise, removing a vector device
+will result in a crash:
+
+RIP: 0033:vector_device_release+0xf/0x50
+RSP: 00000000e187bc40 EFLAGS: 00010202
+RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0
+RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000
+RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70
+R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028
+R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6
+Kernel panic - not syncing: Segfault with no mm
+CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1
+Workqueue: events mc_work_proc
+Stack:
+ 60028f61 623ae028 e187bc80 60276fcd
+ 6220b9c0 603f5820 623ae028 00000000
+ e187bcb0 603a2bcd 623ae000 62370010
+Call Trace:
+ [<60028f61>] ? vector_device_release+0x0/0x50
+ [<60276fcd>] device_release+0x70/0xba
+ [<603a2bcd>] kobject_put+0xba/0xe7
+ [<60277265>] put_device+0x19/0x1c
+ [<60281266>] platform_device_put+0x26/0x29
+ [<60281e5f>] platform_device_unregister+0x2c/0x2e
+ [<60029422>] vector_remove+0x52/0x58
+ [<60031316>] ? mconsole_reply+0x0/0x50
+ [<600310c8>] mconsole_remove+0x160/0x1cc
+ [<603b19f4>] ? strlen+0x0/0x15
+ [<60066611>] ? __dequeue_entity+0x1a9/0x206
+ [<600666a7>] ? set_next_entity+0x39/0x63
+ [<6006666e>] ? set_next_entity+0x0/0x63
+ [<60038fa6>] ? um_set_signals+0x0/0x43
+ [<6003070c>] mc_work_proc+0x77/0x91
+ [<60057664>] process_scheduled_works+0x1b3/0x2dd
+ [<60055f32>] ? assign_work+0x0/0x58
+ [<60057f0a>] worker_thread+0x1e9/0x293
+ [<6005406f>] ? set_pf_worker+0x0/0x64
+ [<6005d65d>] ? arch_local_irq_save+0x0/0x2d
+ [<6005d748>] ? kthread_exit+0x0/0x3a
+ [<60057d21>] ? worker_thread+0x0/0x293
+ [<6005dbf1>] kthread+0x126/0x12b
+ [<600219c5>] new_thread_handler+0x85/0xb6
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com>
+Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
+Link: https://patch.msgid.link/20241104163203.435515-5-tiwei.btw@antgroup.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/um/drivers/vector_kern.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/um/drivers/vector_kern.c
++++ b/arch/um/drivers/vector_kern.c
+@@ -821,7 +821,8 @@ static struct platform_driver uml_net_dr
+
+ static void vector_device_release(struct device *dev)
+ {
+- struct vector_device *device = dev_get_drvdata(dev);
++ struct vector_device *device =
++ container_of(dev, struct vector_device, pdev.dev);
+ struct net_device *netdev = device->dev;
+
+ list_del(&device->list);
--- /dev/null
+From ff6cdc407f4179748f4673c39b0921503199a0ad Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Date: Tue, 26 Nov 2024 14:47:22 +0100
+Subject: x86/CPU/AMD: Terminate the erratum_1386_microcode array
+
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+
+commit ff6cdc407f4179748f4673c39b0921503199a0ad upstream.
+
+The erratum_1386_microcode array requires an empty entry at the end.
+Otherwise x86_match_cpu_with_stepping() will continue iterate the array after
+it ended.
+
+Add an empty entry to erratum_1386_microcode to its end.
+
+Fixes: 29ba89f189528 ("x86/CPU/AMD: Improve the erratum 1386 workaround")
+Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/20241126134722.480975-1-bigeasy@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/amd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
+index 823f44f7bc94..d8408aafeed9 100644
+--- a/arch/x86/kernel/cpu/amd.c
++++ b/arch/x86/kernel/cpu/amd.c
+@@ -798,6 +798,7 @@ static void init_amd_bd(struct cpuinfo_x86 *c)
+ static const struct x86_cpu_desc erratum_1386_microcode[] = {
+ AMD_CPU_DESC(0x17, 0x1, 0x2, 0x0800126e),
+ AMD_CPU_DESC(0x17, 0x31, 0x0, 0x08301052),
++ {},
+ };
+
+ static void fix_erratum_1386(struct cpuinfo_x86 *c)
+--
+2.47.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
