--- /dev/null
+From 3cd59d8ef8df7d7a079f54d56502dae8f716b39b Mon Sep 17 00:00:00 2001
+From: Dirk Su <dirk.su@canonical.com>
+Date: Wed, 26 Jun 2024 10:14:36 +0800
+Subject: ALSA: hda/realtek: fix mute/micmute LEDs don't work for EliteBook 645/665 G11.
+
+From: Dirk Su <dirk.su@canonical.com>
+
+commit 3cd59d8ef8df7d7a079f54d56502dae8f716b39b upstream.
+
+HP EliteBook 645/665 G11 needs ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to
+make mic-mute/audio-mute working.
+
+Signed-off-by: Dirk Su <dirk.su@canonical.com>
+Cc: <stable@vger.kernel.org>
+Link: https://patch.msgid.link/20240626021437.77039-1-dirk.su@canonical.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -9963,6 +9963,9 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x103c, 0x8c7c, "HP ProBook 445 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8c7d, "HP ProBook 465 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8c7e, "HP ProBook 465 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
++ SND_PCI_QUIRK(0x103c, 0x8c7f, "HP EliteBook 645 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
++ SND_PCI_QUIRK(0x103c, 0x8c80, "HP EliteBook 645 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
++ SND_PCI_QUIRK(0x103c, 0x8c81, "HP EliteBook 665 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8c89, "HP ProBook 460 G11", ALC236_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8c8a, "HP EliteBook 630", ALC236_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8c8c, "HP EliteBook 660", ALC236_FIXUP_HP_GPIO_LED),
--- /dev/null
+From eeb25a09c5e0805d92e4ebd12c4b0ad0df1b0295 Mon Sep 17 00:00:00 2001
+From: Niklas Cassel <cassel@kernel.org>
+Date: Sat, 29 Jun 2024 14:42:14 +0200
+Subject: ata: ahci: Clean up sysfs file on error
+
+From: Niklas Cassel <cassel@kernel.org>
+
+commit eeb25a09c5e0805d92e4ebd12c4b0ad0df1b0295 upstream.
+
+.probe() (ahci_init_one()) calls sysfs_add_file_to_group(), however,
+if probe() fails after this call, we currently never call
+sysfs_remove_file_from_group().
+
+(The sysfs_remove_file_from_group() call in .remove() (ahci_remove_one())
+does not help, as .remove() is not called on .probe() error.)
+
+Thus, if probe() fails after the sysfs_add_file_to_group() call, the next
+time we insmod the module we will get:
+
+sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/remapped_nvme'
+CPU: 11 PID: 954 Comm: modprobe Not tainted 6.10.0-rc5 #43
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x5d/0x80
+ sysfs_warn_dup.cold+0x17/0x23
+ sysfs_add_file_mode_ns+0x11a/0x130
+ sysfs_add_file_to_group+0x7e/0xc0
+ ahci_init_one+0x31f/0xd40 [ahci]
+
+Fixes: 894fba7f434a ("ata: ahci: Add sysfs attribute to show remapped NVMe device count")
+Cc: stable@vger.kernel.org
+Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Link: https://lore.kernel.org/r/20240629124210.181537-10-cassel@kernel.org
+Signed-off-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/ahci.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+--- a/drivers/ata/ahci.c
++++ b/drivers/ata/ahci.c
+@@ -1890,8 +1890,10 @@ static int ahci_init_one(struct pci_dev
+ n_ports = max(ahci_nr_ports(hpriv->cap), fls(hpriv->port_map));
+
+ host = ata_host_alloc_pinfo(&pdev->dev, ppi, n_ports);
+- if (!host)
+- return -ENOMEM;
++ if (!host) {
++ rc = -ENOMEM;
++ goto err_rm_sysfs_file;
++ }
+ host->private_data = hpriv;
+
+ if (ahci_init_msi(pdev, n_ports, hpriv) < 0) {
+@@ -1944,11 +1946,11 @@ static int ahci_init_one(struct pci_dev
+ /* initialize adapter */
+ rc = ahci_configure_dma_masks(pdev, hpriv);
+ if (rc)
+- return rc;
++ goto err_rm_sysfs_file;
+
+ rc = ahci_pci_reset_controller(host);
+ if (rc)
+- return rc;
++ goto err_rm_sysfs_file;
+
+ ahci_pci_init_controller(host);
+ ahci_pci_print_info(host);
+@@ -1957,10 +1959,15 @@ static int ahci_init_one(struct pci_dev
+
+ rc = ahci_host_activate(host, &ahci_sht);
+ if (rc)
+- return rc;
++ goto err_rm_sysfs_file;
+
+ pm_runtime_put_noidle(&pdev->dev);
+ return 0;
++
++err_rm_sysfs_file:
++ sysfs_remove_file_from_group(&pdev->dev.kobj,
++ &dev_attr_remapped_nvme.attr, NULL);
++ return rc;
+ }
+
+ static void ahci_shutdown_one(struct pci_dev *pdev)
--- /dev/null
+From ab9e0c529eb7cafebdd31fe1644524e80a48b05d Mon Sep 17 00:00:00 2001
+From: Niklas Cassel <cassel@kernel.org>
+Date: Sat, 29 Jun 2024 14:42:13 +0200
+Subject: ata: libata-core: Fix double free on error
+
+From: Niklas Cassel <cassel@kernel.org>
+
+commit ab9e0c529eb7cafebdd31fe1644524e80a48b05d upstream.
+
+If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
+to the err_out label, which will call devres_release_group().
+devres_release_group() will trigger a call to ata_host_release().
+ata_host_release() calls kfree(host), so executing the kfree(host) in
+ata_host_alloc() will lead to a double free:
+
+kernel BUG at mm/slub.c:553!
+Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
+RIP: 0010:kfree+0x2cf/0x2f0
+Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
+RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
+RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
+RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
+RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
+R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
+R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
+FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
+PKRU: 55555554
+Call Trace:
+ <TASK>
+ ? __die_body.cold+0x19/0x27
+ ? die+0x2e/0x50
+ ? do_trap+0xca/0x110
+ ? do_error_trap+0x6a/0x90
+ ? kfree+0x2cf/0x2f0
+ ? exc_invalid_op+0x50/0x70
+ ? kfree+0x2cf/0x2f0
+ ? asm_exc_invalid_op+0x1a/0x20
+ ? ata_host_alloc+0xf5/0x120 [libata]
+ ? ata_host_alloc+0xf5/0x120 [libata]
+ ? kfree+0x2cf/0x2f0
+ ata_host_alloc+0xf5/0x120 [libata]
+ ata_host_alloc_pinfo+0x14/0xa0 [libata]
+ ahci_init_one+0x6c9/0xd20 [ahci]
+
+Ensure that we will not call kfree(host) twice, by performing the kfree()
+only if the devres_open_group() call failed.
+
+Fixes: dafd6c496381 ("libata: ensure host is free'd on error exit paths")
+Cc: stable@vger.kernel.org
+Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Link: https://lore.kernel.org/r/20240629124210.181537-9-cassel@kernel.org
+Signed-off-by: Niklas Cassel <cassel@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-core.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -5587,8 +5587,10 @@ struct ata_host *ata_host_alloc(struct d
+ if (!host)
+ return NULL;
+
+- if (!devres_open_group(dev, NULL, GFP_KERNEL))
+- goto err_free;
++ if (!devres_open_group(dev, NULL, GFP_KERNEL)) {
++ kfree(host);
++ return NULL;
++ }
+
+ dr = devres_alloc(ata_devres_release, 0, GFP_KERNEL);
+ if (!dr)
+@@ -5620,8 +5622,6 @@ struct ata_host *ata_host_alloc(struct d
+
+ err_out:
+ devres_release_group(dev, NULL);
+- err_free:
+- kfree(host);
+ return NULL;
+ }
+ EXPORT_SYMBOL_GPL(ata_host_alloc);
--- /dev/null
+From 537a350d14321c8cca5efbf0a33a404fec3a9f9e Mon Sep 17 00:00:00 2001
+From: Sven Eckelmann <sven@narfation.org>
+Date: Sat, 4 May 2024 21:57:30 +0200
+Subject: batman-adv: Don't accept TT entries for out-of-spec VIDs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Sven Eckelmann <sven@narfation.org>
+
+commit 537a350d14321c8cca5efbf0a33a404fec3a9f9e upstream.
+
+The internal handling of VLAN IDs in batman-adv is only specified for
+following encodings:
+
+* VLAN is used
+ - bit 15 is 1
+ - bit 11 - bit 0 is the VLAN ID (0-4095)
+ - remaining bits are 0
+* No VLAN is used
+ - bit 15 is 0
+ - remaining bits are 0
+
+batman-adv was only preparing new translation table entries (based on its
+soft interface information) using this encoding format. But the receive
+path was never checking if entries in the roam or TT TVLVs were also
+following this encoding.
+
+It was therefore possible to create more than the expected maximum of 4096
++ 1 entries in the originator VLAN list. Simply by setting the "remaining
+bits" to "random" values in corresponding TVLV.
+
+Cc: stable@vger.kernel.org
+Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
+Reported-by: Linus Lüssing <linus.luessing@c0d3.blue>
+Signed-off-by: Sven Eckelmann <sven@narfation.org>
+Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/batman-adv/originator.c | 27 +++++++++++++++++++++++++++
+ 1 file changed, 27 insertions(+)
+
+--- a/net/batman-adv/originator.c
++++ b/net/batman-adv/originator.c
+@@ -12,6 +12,7 @@
+ #include <linux/errno.h>
+ #include <linux/etherdevice.h>
+ #include <linux/gfp.h>
++#include <linux/if_vlan.h>
+ #include <linux/jiffies.h>
+ #include <linux/kref.h>
+ #include <linux/list.h>
+@@ -132,6 +133,29 @@ batadv_orig_node_vlan_get(struct batadv_
+ }
+
+ /**
++ * batadv_vlan_id_valid() - check if vlan id is in valid batman-adv encoding
++ * @vid: the VLAN identifier
++ *
++ * Return: true when either no vlan is set or if VLAN is in correct range,
++ * false otherwise
++ */
++static bool batadv_vlan_id_valid(unsigned short vid)
++{
++ unsigned short non_vlan = vid & ~(BATADV_VLAN_HAS_TAG | VLAN_VID_MASK);
++
++ if (vid == 0)
++ return true;
++
++ if (!(vid & BATADV_VLAN_HAS_TAG))
++ return false;
++
++ if (non_vlan)
++ return false;
++
++ return true;
++}
++
++/**
+ * batadv_orig_node_vlan_new() - search and possibly create an orig_node_vlan
+ * object
+ * @orig_node: the originator serving the VLAN
+@@ -149,6 +173,9 @@ batadv_orig_node_vlan_new(struct batadv_
+ {
+ struct batadv_orig_node_vlan *vlan;
+
++ if (!batadv_vlan_id_valid(vid))
++ return NULL;
++
+ spin_lock_bh(&orig_node->vlan_list_lock);
+
+ /* first look if an object for this vid already exists */
--- /dev/null
+From b9fd2affe4aa99a4ca14ee87e1f38fea22ece52a Mon Sep 17 00:00:00 2001
+From: Naohiro Aota <naohiro.aota@wdc.com>
+Date: Tue, 11 Jun 2024 17:17:30 +0900
+Subject: btrfs: zoned: fix initial free space detection
+
+From: Naohiro Aota <naohiro.aota@wdc.com>
+
+commit b9fd2affe4aa99a4ca14ee87e1f38fea22ece52a upstream.
+
+When creating a new block group, it calls btrfs_add_new_free_space() to add
+the entire block group range into the free space accounting.
+__btrfs_add_free_space_zoned() checks if size == block_group->length to
+detect the initial free space adding, and proceed that case properly.
+
+However, if the zone_capacity == zone_size and the over-write speed is fast
+enough, the entire zone can be over-written within one transaction. That
+confuses __btrfs_add_free_space_zoned() to handle it as an initial free
+space accounting. As a result, that block group becomes a strange state: 0
+used bytes, 0 zone_unusable bytes, but alloc_offset == zone_capacity (no
+allocation anymore).
+
+The initial free space accounting can properly be checked by checking
+alloc_offset too.
+
+Fixes: 98173255bddd ("btrfs: zoned: calculate free space from zone capacity")
+CC: stable@vger.kernel.org # 6.1+
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/free-space-cache.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/free-space-cache.c
++++ b/fs/btrfs/free-space-cache.c
+@@ -2695,7 +2695,7 @@ static int __btrfs_add_free_space_zoned(
+ u64 offset = bytenr - block_group->start;
+ u64 to_free, to_unusable;
+ int bg_reclaim_threshold = 0;
+- bool initial = (size == block_group->length);
++ bool initial = ((size == block_group->length) && (block_group->alloc_offset == 0));
+ u64 reclaimable_unusable;
+
+ WARN_ON(!initial && offset + size > block_group->zone_capacity);
--- /dev/null
+From d8fb63e46c884c898a38f061c2330f7729e75510 Mon Sep 17 00:00:00 2001
+From: Vitor Soares <vitor.soares@toradex.com>
+Date: Fri, 17 May 2024 14:43:55 +0100
+Subject: can: mcp251xfd: fix infinite loop when xmit fails
+
+From: Vitor Soares <vitor.soares@toradex.com>
+
+commit d8fb63e46c884c898a38f061c2330f7729e75510 upstream.
+
+When the mcp251xfd_start_xmit() function fails, the driver stops
+processing messages, and the interrupt routine does not return,
+running indefinitely even after killing the running application.
+
+Error messages:
+[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16
+[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).
+... and repeat forever.
+
+The issue can be triggered when multiple devices share the same SPI
+interface. And there is concurrent access to the bus.
+
+The problem occurs because tx_ring->head increments even if
+mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX
+package while still expecting a response in
+mcp251xfd_handle_tefif_one().
+
+Resolve the issue by starting a workqueue to write the tx obj
+synchronously if err = -EBUSY. In case of another error, decrement
+tx_ring->head, remove skb from the echo stack, and drop the message.
+
+Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN")
+Cc: stable@vger.kernel.org
+Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
+Link: https://lore.kernel.org/all/20240517134355.770777-1-ivitro@gmail.com
+[mkl: use more imperative wording in patch description]
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 14 +++++-
+ drivers/net/can/spi/mcp251xfd/mcp251xfd-tx.c | 55 +++++++++++++++++++++----
+ drivers/net/can/spi/mcp251xfd/mcp251xfd.h | 5 ++
+ 3 files changed, 65 insertions(+), 9 deletions(-)
+
+--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
++++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
+@@ -1618,11 +1618,20 @@ static int mcp251xfd_open(struct net_dev
+ clear_bit(MCP251XFD_FLAGS_DOWN, priv->flags);
+ can_rx_offload_enable(&priv->offload);
+
++ priv->wq = alloc_ordered_workqueue("%s-mcp251xfd_wq",
++ WQ_FREEZABLE | WQ_MEM_RECLAIM,
++ dev_name(&spi->dev));
++ if (!priv->wq) {
++ err = -ENOMEM;
++ goto out_can_rx_offload_disable;
++ }
++ INIT_WORK(&priv->tx_work, mcp251xfd_tx_obj_write_sync);
++
+ err = request_threaded_irq(spi->irq, NULL, mcp251xfd_irq,
+ IRQF_SHARED | IRQF_ONESHOT,
+ dev_name(&spi->dev), priv);
+ if (err)
+- goto out_can_rx_offload_disable;
++ goto out_destroy_workqueue;
+
+ err = mcp251xfd_chip_interrupts_enable(priv);
+ if (err)
+@@ -1634,6 +1643,8 @@ static int mcp251xfd_open(struct net_dev
+
+ out_free_irq:
+ free_irq(spi->irq, priv);
++ out_destroy_workqueue:
++ destroy_workqueue(priv->wq);
+ out_can_rx_offload_disable:
+ can_rx_offload_disable(&priv->offload);
+ set_bit(MCP251XFD_FLAGS_DOWN, priv->flags);
+@@ -1661,6 +1672,7 @@ static int mcp251xfd_stop(struct net_dev
+ hrtimer_cancel(&priv->tx_irq_timer);
+ mcp251xfd_chip_interrupts_disable(priv);
+ free_irq(ndev->irq, priv);
++ destroy_workqueue(priv->wq);
+ can_rx_offload_disable(&priv->offload);
+ mcp251xfd_timestamp_stop(priv);
+ mcp251xfd_chip_stop(priv, CAN_STATE_STOPPED);
+--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-tx.c
++++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-tx.c
+@@ -131,6 +131,39 @@ mcp251xfd_tx_obj_from_skb(const struct m
+ tx_obj->xfer[0].len = len;
+ }
+
++static void mcp251xfd_tx_failure_drop(const struct mcp251xfd_priv *priv,
++ struct mcp251xfd_tx_ring *tx_ring,
++ int err)
++{
++ struct net_device *ndev = priv->ndev;
++ struct net_device_stats *stats = &ndev->stats;
++ unsigned int frame_len = 0;
++ u8 tx_head;
++
++ tx_ring->head--;
++ stats->tx_dropped++;
++ tx_head = mcp251xfd_get_tx_head(tx_ring);
++ can_free_echo_skb(ndev, tx_head, &frame_len);
++ netdev_completed_queue(ndev, 1, frame_len);
++ netif_wake_queue(ndev);
++
++ if (net_ratelimit())
++ netdev_err(priv->ndev, "ERROR in %s: %d\n", __func__, err);
++}
++
++void mcp251xfd_tx_obj_write_sync(struct work_struct *work)
++{
++ struct mcp251xfd_priv *priv = container_of(work, struct mcp251xfd_priv,
++ tx_work);
++ struct mcp251xfd_tx_obj *tx_obj = priv->tx_work_obj;
++ struct mcp251xfd_tx_ring *tx_ring = priv->tx;
++ int err;
++
++ err = spi_sync(priv->spi, &tx_obj->msg);
++ if (err)
++ mcp251xfd_tx_failure_drop(priv, tx_ring, err);
++}
++
+ static int mcp251xfd_tx_obj_write(const struct mcp251xfd_priv *priv,
+ struct mcp251xfd_tx_obj *tx_obj)
+ {
+@@ -162,6 +195,11 @@ static bool mcp251xfd_tx_busy(const stru
+ return false;
+ }
+
++static bool mcp251xfd_work_busy(struct work_struct *work)
++{
++ return work_busy(work);
++}
++
+ netdev_tx_t mcp251xfd_start_xmit(struct sk_buff *skb,
+ struct net_device *ndev)
+ {
+@@ -175,7 +213,8 @@ netdev_tx_t mcp251xfd_start_xmit(struct
+ if (can_dev_dropped_skb(ndev, skb))
+ return NETDEV_TX_OK;
+
+- if (mcp251xfd_tx_busy(priv, tx_ring))
++ if (mcp251xfd_tx_busy(priv, tx_ring) ||
++ mcp251xfd_work_busy(&priv->tx_work))
+ return NETDEV_TX_BUSY;
+
+ tx_obj = mcp251xfd_get_tx_obj_next(tx_ring);
+@@ -193,13 +232,13 @@ netdev_tx_t mcp251xfd_start_xmit(struct
+ netdev_sent_queue(priv->ndev, frame_len);
+
+ err = mcp251xfd_tx_obj_write(priv, tx_obj);
+- if (err)
+- goto out_err;
+-
+- return NETDEV_TX_OK;
+-
+- out_err:
+- netdev_err(priv->ndev, "ERROR in %s: %d\n", __func__, err);
++ if (err == -EBUSY) {
++ netif_stop_queue(ndev);
++ priv->tx_work_obj = tx_obj;
++ queue_work(priv->wq, &priv->tx_work);
++ } else if (err) {
++ mcp251xfd_tx_failure_drop(priv, tx_ring, err);
++ }
+
+ return NETDEV_TX_OK;
+ }
+--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd.h
++++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd.h
+@@ -633,6 +633,10 @@ struct mcp251xfd_priv {
+ struct mcp251xfd_rx_ring *rx[MCP251XFD_FIFO_RX_NUM];
+ struct mcp251xfd_tx_ring tx[MCP251XFD_FIFO_TX_NUM];
+
++ struct workqueue_struct *wq;
++ struct work_struct tx_work;
++ struct mcp251xfd_tx_obj *tx_work_obj;
++
+ DECLARE_BITMAP(flags, __MCP251XFD_FLAGS_SIZE__);
+
+ u8 rx_ring_num;
+@@ -952,6 +956,7 @@ void mcp251xfd_skb_set_timestamp(const s
+ void mcp251xfd_timestamp_init(struct mcp251xfd_priv *priv);
+ void mcp251xfd_timestamp_stop(struct mcp251xfd_priv *priv);
+
++void mcp251xfd_tx_obj_write_sync(struct work_struct *work);
+ netdev_tx_t mcp251xfd_start_xmit(struct sk_buff *skb,
+ struct net_device *ndev);
+
--- /dev/null
+From 932d8476399f622aa0767a4a0a9e78e5341dc0e1 Mon Sep 17 00:00:00 2001
+From: Yuntao Wang <ytcoode@gmail.com>
+Date: Wed, 15 May 2024 21:45:54 +0800
+Subject: cpu/hotplug: Fix dynstate assignment in __cpuhp_setup_state_cpuslocked()
+
+From: Yuntao Wang <ytcoode@gmail.com>
+
+commit 932d8476399f622aa0767a4a0a9e78e5341dc0e1 upstream.
+
+Commit 4205e4786d0b ("cpu/hotplug: Provide dynamic range for prepare
+stage") added a dynamic range for the prepare states, but did not handle
+the assignment of the dynstate variable in __cpuhp_setup_state_cpuslocked().
+
+This causes the corresponding startup callback not to be invoked when
+calling __cpuhp_setup_state_cpuslocked() with the CPUHP_BP_PREPARE_DYN
+parameter, even though it should be.
+
+Currently, the users of __cpuhp_setup_state_cpuslocked(), for one reason or
+another, have not triggered this bug.
+
+Fixes: 4205e4786d0b ("cpu/hotplug: Provide dynamic range for prepare stage")
+Signed-off-by: Yuntao Wang <ytcoode@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240515134554.427071-1-ytcoode@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/cpu.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/kernel/cpu.c
++++ b/kernel/cpu.c
+@@ -2495,7 +2495,7 @@ EXPORT_SYMBOL_GPL(__cpuhp_state_add_inst
+ * The caller needs to hold cpus read locked while calling this function.
+ * Return:
+ * On success:
+- * Positive state number if @state is CPUHP_AP_ONLINE_DYN;
++ * Positive state number if @state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN;
+ * 0 for all other states
+ * On failure: proper (negative) error code
+ */
+@@ -2518,7 +2518,7 @@ int __cpuhp_setup_state_cpuslocked(enum
+ ret = cpuhp_store_callbacks(state, name, startup, teardown,
+ multi_instance);
+
+- dynstate = state == CPUHP_AP_ONLINE_DYN;
++ dynstate = state == CPUHP_AP_ONLINE_DYN || state == CPUHP_BP_PREPARE_DYN;
+ if (ret > 0 && dynstate) {
+ state = ret;
+ ret = 0;
+@@ -2549,8 +2549,8 @@ int __cpuhp_setup_state_cpuslocked(enum
+ out:
+ mutex_unlock(&cpuhp_state_mutex);
+ /*
+- * If the requested state is CPUHP_AP_ONLINE_DYN, return the
+- * dynamically allocated state in case of success.
++ * If the requested state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN,
++ * return the dynamically allocated state in case of success.
+ */
+ if (!ret && dynstate)
+ return state;
--- /dev/null
+From a1ff59784b277795a613beaa5d3dd9c5595c69a7 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Thu, 20 Jun 2024 18:14:53 +0200
+Subject: cpufreq: intel_pstate: Use HWP to initialize ITMT if CPPC is missing
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit a1ff59784b277795a613beaa5d3dd9c5595c69a7 upstream.
+
+It is reported that single-thread performance on some hybrid systems
+dropped significantly after commit 7feec7430edd ("ACPI: CPPC: Only probe
+for _CPC if CPPC v2 is acked") which prevented _CPC from being used if
+the support for it had not been confirmed by the platform firmware.
+
+The problem is that if the platform firmware does not confirm CPPC v2
+support, cppc_get_perf_caps() returns an error which prevents the
+intel_pstate driver from enabling ITMT. Consequently, the scheduler
+does not get any hints on CPU performance differences, so in a hybrid
+system some tasks may run on CPUs with lower capacity even though they
+should be running on high-capacity CPUs.
+
+To address this, modify intel_pstate to use the information from
+MSR_HWP_CAPABILITIES to enable ITMT if CPPC is not available (which is
+done already if the highest performance number coming from CPPC is not
+realistic).
+
+Fixes: 7feec7430edd ("ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked")
+Closes: https://lore.kernel.org/linux-acpi/d01b0a1f-bd33-47fe-ab41-43843d8a374f@kfocus.org
+Link: https://lore.kernel.org/linux-acpi/ZnD22b3Br1ng7alf@kf-XE
+Reported-by: Aaron Rainbolt <arainbolt@kfocus.org>
+Tested-by: Aaron Rainbolt <arainbolt@kfocus.org>
+Cc: 5.19+ <stable@vger.kernel.org> # 5.19+
+Link: https://patch.msgid.link/12460110.O9o76ZdvQC@rjwysocki.net
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/intel_pstate.c | 13 ++++++-------
+ 1 file changed, 6 insertions(+), 7 deletions(-)
+
+--- a/drivers/cpufreq/intel_pstate.c
++++ b/drivers/cpufreq/intel_pstate.c
+@@ -356,15 +356,14 @@ static void intel_pstate_set_itmt_prio(i
+ int ret;
+
+ ret = cppc_get_perf_caps(cpu, &cppc_perf);
+- if (ret)
+- return;
+-
+ /*
+- * On some systems with overclocking enabled, CPPC.highest_perf is hardcoded to 0xff.
+- * In this case we can't use CPPC.highest_perf to enable ITMT.
+- * In this case we can look at MSR_HWP_CAPABILITIES bits [8:0] to decide.
++ * If CPPC is not available, fall back to MSR_HWP_CAPABILITIES bits [8:0].
++ *
++ * Also, on some systems with overclocking enabled, CPPC.highest_perf is
++ * hardcoded to 0xff, so CPPC.highest_perf cannot be used to enable ITMT.
++ * Fall back to MSR_HWP_CAPABILITIES then too.
+ */
+- if (cppc_perf.highest_perf == CPPC_MAX_PERF)
++ if (ret || cppc_perf.highest_perf == CPPC_MAX_PERF)
+ cppc_perf.highest_perf = HWP_HIGHEST_PERF(READ_ONCE(all_cpu_data[cpu]->hwp_cap_cached));
+
+ /*
--- /dev/null
+From 3339b99ef6fe38dac43b534cba3a8a0e29fb2eff Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 14 Jun 2024 09:54:20 +0200
+Subject: csky, hexagon: fix broken sys_sync_file_range
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 3339b99ef6fe38dac43b534cba3a8a0e29fb2eff upstream.
+
+Both of these architectures require u64 function arguments to be
+passed in even/odd pairs of registers or stack slots, which in case of
+sync_file_range would result in a seven-argument system call that is
+not currently possible. The system call is therefore incompatible with
+all existing binaries.
+
+While it would be possible to implement support for seven arguments
+like on mips, it seems better to use a six-argument version, either
+with the normal argument order but misaligned as on most architectures
+or with the reordered sync_file_range2() calling conventions as on
+arm and powerpc.
+
+Cc: stable@vger.kernel.org
+Acked-by: Guo Ren <guoren@kernel.org>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/csky/include/uapi/asm/unistd.h | 1 +
+ arch/hexagon/include/uapi/asm/unistd.h | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/arch/csky/include/uapi/asm/unistd.h
++++ b/arch/csky/include/uapi/asm/unistd.h
+@@ -6,6 +6,7 @@
+ #define __ARCH_WANT_SYS_CLONE3
+ #define __ARCH_WANT_SET_GET_RLIMIT
+ #define __ARCH_WANT_TIME32_SYSCALLS
++#define __ARCH_WANT_SYNC_FILE_RANGE2
+ #include <asm-generic/unistd.h>
+
+ #define __NR_set_thread_area (__NR_arch_specific_syscall + 0)
+--- a/arch/hexagon/include/uapi/asm/unistd.h
++++ b/arch/hexagon/include/uapi/asm/unistd.h
+@@ -36,5 +36,6 @@
+ #define __ARCH_WANT_SYS_VFORK
+ #define __ARCH_WANT_SYS_FORK
+ #define __ARCH_WANT_TIME32_SYSCALLS
++#define __ARCH_WANT_SYNC_FILE_RANGE2
+
+ #include <asm-generic/unistd.h>
--- /dev/null
+From 2ec6c7f802332d1eff16f03e7c757f1543ee1183 Mon Sep 17 00:00:00 2001
+From: Michael Strauss <michael.strauss@amd.com>
+Date: Tue, 28 Nov 2023 10:31:12 -0500
+Subject: drm/amd/display: Send DP_TOTAL_LTTPR_CNT during detection if LTTPR is present
+
+From: Michael Strauss <michael.strauss@amd.com>
+
+commit 2ec6c7f802332d1eff16f03e7c757f1543ee1183 upstream.
+
+[WHY]
+New register field added in DP2.1 SCR, needed for auxless ALPM
+
+[HOW]
+Echo value read from 0xF0007 back to sink
+
+Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Alex Hung <alex.hung@amd.com>
+Signed-off-by: Michael Strauss <michael.strauss@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c | 10 +++++++++-
+ drivers/gpu/drm/amd/display/include/dpcd_defs.h | 5 +++++
+ 2 files changed, 14 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
++++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+@@ -1584,9 +1584,17 @@ static bool retrieve_link_cap(struct dc_
+ return false;
+ }
+
+- if (dp_is_lttpr_present(link))
++ if (dp_is_lttpr_present(link)) {
+ configure_lttpr_mode_transparent(link);
+
++ // Echo TOTAL_LTTPR_CNT back downstream
++ core_link_write_dpcd(
++ link,
++ DP_TOTAL_LTTPR_CNT,
++ &link->dpcd_caps.lttpr_caps.phy_repeater_cnt,
++ sizeof(link->dpcd_caps.lttpr_caps.phy_repeater_cnt));
++ }
++
+ /* Read DP tunneling information. */
+ status = dpcd_get_tunneling_device_data(link);
+
+--- a/drivers/gpu/drm/amd/display/include/dpcd_defs.h
++++ b/drivers/gpu/drm/amd/display/include/dpcd_defs.h
+@@ -177,4 +177,9 @@ enum dpcd_psr_sink_states {
+ #define DP_SINK_PR_PIXEL_DEVIATION_PER_LINE 0x379
+ #define DP_SINK_PR_MAX_NUMBER_OF_DEVIATION_LINE 0x37A
+
++/* Remove once drm_dp_helper.h is updated upstream */
++#ifndef DP_TOTAL_LTTPR_CNT
++#define DP_TOTAL_LTTPR_CNT 0xF000A /* 2.1 */
++#endif
++
+ #endif /* __DAL_DPCD_DEFS_H__ */
--- /dev/null
+From f6f49dda49db72e7a0b4ca32c77391d5ff5ce232 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Fri, 14 Jun 2024 13:48:26 -0400
+Subject: drm/amdgpu/atomfirmware: fix parsing of vram_info
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit f6f49dda49db72e7a0b4ca32c77391d5ff5ce232 upstream.
+
+v3.x changed the how vram width was encoded. The previous
+implementation actually worked correctly for most boards.
+Fix the implementation to work correctly everywhere.
+
+This fixes the vram width reported in the kernel log on
+some boards.
+
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
+@@ -399,7 +399,7 @@ amdgpu_atomfirmware_get_vram_info(struct
+ mem_channel_number = vram_info->v30.channel_num;
+ mem_channel_width = vram_info->v30.channel_width;
+ if (vram_width)
+- *vram_width = mem_channel_number * (1 << mem_channel_width);
++ *vram_width = mem_channel_number * 16;
+ break;
+ default:
+ return -EINVAL;
--- /dev/null
+From bcfa48ff785bd121316592b131ff6531e3e696bb Mon Sep 17 00:00:00 2001
+From: Julia Zhang <julia.zhang@amd.com>
+Date: Mon, 3 Jun 2024 19:31:09 +0800
+Subject: drm/amdgpu: avoid using null object of framebuffer
+
+From: Julia Zhang <julia.zhang@amd.com>
+
+commit bcfa48ff785bd121316592b131ff6531e3e696bb upstream.
+
+Instead of using state->fb->obj[0] directly, get object from framebuffer
+by calling drm_gem_fb_get_obj() and return error code when object is
+null to avoid using null object of framebuffer.
+
+Reported-by: Fusheng Huang <fusheng.huang@ecarxgroup.com>
+Signed-off-by: Julia Zhang <Julia.Zhang@amd.com>
+Reviewed-by: Huang Rui <ray.huang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 18 ++++++++++++++++--
+ 1 file changed, 16 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+@@ -2,6 +2,7 @@
+
+ #include <drm/drm_atomic_helper.h>
+ #include <drm/drm_simple_kms_helper.h>
++#include <drm/drm_gem_framebuffer_helper.h>
+ #include <drm/drm_vblank.h>
+
+ #include "amdgpu.h"
+@@ -313,7 +314,13 @@ static int amdgpu_vkms_prepare_fb(struct
+ return 0;
+ }
+ afb = to_amdgpu_framebuffer(new_state->fb);
+- obj = new_state->fb->obj[0];
++
++ obj = drm_gem_fb_get_obj(new_state->fb, 0);
++ if (!obj) {
++ DRM_ERROR("Failed to get obj from framebuffer\n");
++ return -EINVAL;
++ }
++
+ rbo = gem_to_amdgpu_bo(obj);
+ adev = amdgpu_ttm_adev(rbo->tbo.bdev);
+
+@@ -367,12 +374,19 @@ static void amdgpu_vkms_cleanup_fb(struc
+ struct drm_plane_state *old_state)
+ {
+ struct amdgpu_bo *rbo;
++ struct drm_gem_object *obj;
+ int r;
+
+ if (!old_state->fb)
+ return;
+
+- rbo = gem_to_amdgpu_bo(old_state->fb->obj[0]);
++ obj = drm_gem_fb_get_obj(old_state->fb, 0);
++ if (!obj) {
++ DRM_ERROR("Failed to get obj from framebuffer\n");
++ return;
++ }
++
++ rbo = gem_to_amdgpu_bo(obj);
+ r = amdgpu_bo_reserve(rbo, false);
+ if (unlikely(r)) {
+ DRM_ERROR("failed to reserve rbo before unpin\n");
--- /dev/null
+From 4f2a129b33a2054e62273edd5a051c34c08d96e9 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Thu, 27 Jun 2024 11:26:00 +1000
+Subject: drm/drm_file: Fix pid refcounting race
+
+From: Jann Horn <jannh@google.com>
+
+commit 4f2a129b33a2054e62273edd5a051c34c08d96e9 upstream.
+
+<maarten.lankhorst@linux.intel.com>, Maxime Ripard
+<mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>
+
+filp->pid is supposed to be a refcounted pointer; however, before this
+patch, drm_file_update_pid() only increments the refcount of a struct
+pid after storing a pointer to it in filp->pid and dropping the
+dev->filelist_mutex, making the following race possible:
+
+process A process B
+========= =========
+ begin drm_file_update_pid
+ mutex_lock(&dev->filelist_mutex)
+ rcu_replace_pointer(filp->pid, <pid B>, 1)
+ mutex_unlock(&dev->filelist_mutex)
+begin drm_file_update_pid
+mutex_lock(&dev->filelist_mutex)
+rcu_replace_pointer(filp->pid, <pid A>, 1)
+mutex_unlock(&dev->filelist_mutex)
+get_pid(<pid A>)
+synchronize_rcu()
+put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here ***
+ get_pid(<pid B>) *** UAF ***
+ synchronize_rcu()
+ put_pid(<pid A>)
+
+As far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y
+because it requires RCU to detect a quiescent state in code that is not
+explicitly calling into the scheduler.
+
+This race leads to use-after-free of a "struct pid".
+It is probably somewhat hard to hit because process A has to pass
+through a synchronize_rcu() operation while process B is between
+mutex_unlock() and get_pid().
+
+Fix it by ensuring that by the time a pointer to the current task's pid
+is stored in the file, an extra reference to the pid has been taken.
+
+This fix also removes the condition for synchronize_rcu(); I think
+that optimization is unnecessary complexity, since in that case we
+would usually have bailed out on the lockless check above.
+
+Fixes: 1c7a387ffef8 ("drm: Update file owner during use")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_file.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/drm_file.c
++++ b/drivers/gpu/drm/drm_file.c
+@@ -529,14 +529,12 @@ void drm_file_update_pid(struct drm_file
+
+ dev = filp->minor->dev;
+ mutex_lock(&dev->filelist_mutex);
++ get_pid(pid);
+ old = rcu_replace_pointer(filp->pid, pid, 1);
+ mutex_unlock(&dev->filelist_mutex);
+
+- if (pid != old) {
+- get_pid(pid);
+- synchronize_rcu();
+- put_pid(old);
+- }
++ synchronize_rcu();
++ put_pid(old);
+ }
+
+ /**
--- /dev/null
+From d92a7580392ad4681b1d4f9275d00b95375ebe01 Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Mon, 17 Jun 2024 17:26:37 +0200
+Subject: drm/fbdev-dma: Only set smem_start is enable per module option
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit d92a7580392ad4681b1d4f9275d00b95375ebe01 upstream.
+
+Only export struct fb_info.fix.smem_start if that is required by the
+user and the memory does not come from vmalloc().
+
+Setting struct fb_info.fix.smem_start breaks systems where DMA
+memory is backed by vmalloc address space. An example error is
+shown below.
+
+[ 3.536043] ------------[ cut here ]------------
+[ 3.540716] virt_to_phys used for non-linear address: 000000007fc4f540 (0xffff800086001000)
+[ 3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98
+[ 3.565455] Modules linked in:
+[ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 6.6.23-06226-g4986cc3e1b75-dirty #250
+[ 3.577310] Hardware name: NXP i.MX95 19X19 board (DT)
+[ 3.582452] Workqueue: events_unbound deferred_probe_work_func
+[ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+[ 3.595233] pc : __virt_to_phys+0x68/0x98
+[ 3.599246] lr : __virt_to_phys+0x68/0x98
+[ 3.603276] sp : ffff800083603990
+[ 3.677939] Call trace:
+[ 3.680393] __virt_to_phys+0x68/0x98
+[ 3.684067] drm_fbdev_dma_helper_fb_probe+0x138/0x238
+[ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0
+[ 3.695385] drm_fb_helper_initial_config+0x4c/0x68
+[ 3.700264] drm_fbdev_dma_client_hotplug+0x8c/0xe0
+[ 3.705161] drm_client_register+0x60/0xb0
+[ 3.709269] drm_fbdev_dma_setup+0x94/0x148
+
+Additionally, DMA memory is assumed to by contiguous in physical
+address space, which is not guaranteed by vmalloc().
+
+Resolve this by checking the module flag drm_leak_fbdev_smem when
+DRM allocated the instance of struct fb_info. Fbdev-dma then only
+sets smem_start only if required (via FBINFO_HIDE_SMEM_START). Also
+guarantee that the framebuffer is not located in vmalloc address
+space.
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Reported-by: Peng Fan (OSS) <peng.fan@oss.nxp.com>
+Closes: https://lore.kernel.org/dri-devel/20240604080328.4024838-1-peng.fan@oss.nxp.com/
+Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Closes: https://lore.kernel.org/dri-devel/CAMuHMdX3N0szUvt1VTbroa2zrT1Nye_VzPb5qqCZ7z5gSm7HGw@mail.gmail.com/
+Fixes: a51c7663f144 ("drm/fb-helper: Consolidate CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM")
+Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: <stable@vger.kernel.org> # v6.4+
+Link: https://patchwork.freedesktop.org/patch/msgid/20240617152843.11886-1-tzimmermann@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_fb_helper.c | 6 +++---
+ drivers/gpu/drm/drm_fbdev_dma.c | 5 ++++-
+ 2 files changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/drm_fb_helper.c
++++ b/drivers/gpu/drm/drm_fb_helper.c
+@@ -524,6 +524,9 @@ struct fb_info *drm_fb_helper_alloc_info
+ if (!info)
+ return ERR_PTR(-ENOMEM);
+
++ if (!drm_leak_fbdev_smem)
++ info->flags |= FBINFO_HIDE_SMEM_START;
++
+ ret = fb_alloc_cmap(&info->cmap, 256, 0);
+ if (ret)
+ goto err_release;
+@@ -1860,9 +1863,6 @@ __drm_fb_helper_initial_config_and_unloc
+ info = fb_helper->info;
+ info->var.pixclock = 0;
+
+- if (!drm_leak_fbdev_smem)
+- info->flags |= FBINFO_HIDE_SMEM_START;
+-
+ /* Need to drop locks to avoid recursive deadlock in
+ * register_framebuffer. This is ok because the only thing left to do is
+ * register the fbdev emulation instance in kernel_fb_helper_list. */
+--- a/drivers/gpu/drm/drm_fbdev_dma.c
++++ b/drivers/gpu/drm/drm_fbdev_dma.c
+@@ -130,7 +130,10 @@ static int drm_fbdev_dma_helper_fb_probe
+ info->flags |= FBINFO_READS_FAST; /* signal caching */
+ info->screen_size = sizes->surface_height * fb->pitches[0];
+ info->screen_buffer = map.vaddr;
+- info->fix.smem_start = page_to_phys(virt_to_page(info->screen_buffer));
++ if (!(info->flags & FBINFO_HIDE_SMEM_START)) {
++ if (!drm_WARN_ON(dev, is_vmalloc_addr(info->screen_buffer)))
++ info->fix.smem_start = page_to_phys(virt_to_page(info->screen_buffer));
++ }
+ info->fix.smem_len = info->screen_size;
+
+ return 0;
--- /dev/null
+From 996c3412a06578e9d779a16b9e79ace18125ab50 Mon Sep 17 00:00:00 2001
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Date: Mon, 3 Jun 2024 21:54:45 +0200
+Subject: drm/i915/gt: Fix potential UAF by revoke of fence registers
+
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+
+commit 996c3412a06578e9d779a16b9e79ace18125ab50 upstream.
+
+CI has been sporadically reporting the following issue triggered by
+igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
+
+<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
+...
+<6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
+<6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
+<3> [414.070354] Unable to pin Y-tiled fence; err:-4
+<3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active))
+...
+<4>[ 609.603992] ------------[ cut here ]------------
+<2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
+<4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+<4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
+<4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
+<4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]
+<4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
+...
+<4>[ 609.604271] Call Trace:
+<4>[ 609.604273] <TASK>
+...
+<4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]
+<4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]
+<4>[ 609.604977] force_unbind+0x24/0xa0 [i915]
+<4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]
+<4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
+<4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
+<4>[ 609.605440] process_scheduled_works+0x351/0x690
+...
+
+In the past, there were similar failures reported by CI from other IGT
+tests, observed on other platforms.
+
+Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity
+before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for
+idleness of vma->active via fence_update(). That commit introduced
+vma->fence->active in order for the fence_update() to be able to wait
+selectively on that one instead of vma->active since only idleness of
+fence registers was needed. But then, another commit 0d86ee35097a
+("drm/i915/gt: Make fence revocation unequivocal") replaced the call to
+fence_update() in i915_vma_revoke_fence() with only fence_write(), and
+also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front.
+No justification was provided on why we might then expect idleness of
+vma->fence->active without first waiting on it.
+
+The issue can be potentially caused by a race among revocation of fence
+registers on one side and sequential execution of signal callbacks invoked
+on completion of a request that was using them on the other, still
+processed in parallel to revocation of those fence registers. Fix it by
+waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
+
+Fixes: 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal")
+Closes: https://gitlab.freedesktop.org/drm/intel/issues/10021
+Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Cc: stable@vger.kernel.org # v5.8+
+Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
+Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240603195446.297690-2-janusz.krzysztofik@linux.intel.com
+(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
++++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+@@ -298,6 +298,7 @@ void i915_vma_revoke_fence(struct i915_v
+ return;
+
+ GEM_BUG_ON(fence->vma != vma);
++ i915_active_wait(&fence->active);
+ GEM_BUG_ON(!i915_active_is_idle(&fence->active));
+ GEM_BUG_ON(atomic_read(&fence->pin_count));
+
--- /dev/null
+From 6d411c8ccc0137a612e0044489030a194ff5c843 Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+Date: Tue, 25 Jun 2024 16:10:29 +0800
+Subject: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
+
+From: Ma Ke <make24@iscas.ac.cn>
+
+commit 6d411c8ccc0137a612e0044489030a194ff5c843 upstream.
+
+In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
+assigned to mode, which will lead to a possible NULL pointer dereference
+on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
+Add a check to avoid null pointer dereference.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ma Ke <make24@iscas.ac.cn>
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240625081029.2619437-1-make24@iscas.ac.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
++++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+@@ -260,6 +260,8 @@ static int nv17_tv_get_hd_modes(struct d
+ if (modes[i].hdisplay == output_mode->hdisplay &&
+ modes[i].vdisplay == output_mode->vdisplay) {
+ mode = drm_mode_duplicate(encoder->dev, output_mode);
++ if (!mode)
++ continue;
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
+
+ } else {
+@@ -267,6 +269,8 @@ static int nv17_tv_get_hd_modes(struct d
+ modes[i].vdisplay, 60, false,
+ (output_mode->flags &
+ DRM_MODE_FLAG_INTERLACE), false);
++ if (!mode)
++ continue;
+ }
+
+ /* CVT modes are sometimes unsuitable... */
--- /dev/null
+From 66edf3fb331b6c55439b10f9862987b0916b3726 Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+Date: Tue, 25 Jun 2024 16:18:28 +0800
+Subject: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
+
+From: Ma Ke <make24@iscas.ac.cn>
+
+commit 66edf3fb331b6c55439b10f9862987b0916b3726 upstream.
+
+In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is
+assigned to mode, which will lead to a possible NULL pointer dereference
+on failure of drm_mode_duplicate(). Add a check to avoid npd.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ma Ke <make24@iscas.ac.cn>
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240625081828.2620794-1-make24@iscas.ac.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
++++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+@@ -209,6 +209,8 @@ static int nv17_tv_get_ld_modes(struct d
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(encoder->dev, tv_mode);
++ if (!mode)
++ continue;
+
+ mode->clock = tv_norm->tv_enc_mode.vrefresh *
+ mode->htotal / 1000 *
--- /dev/null
+From 896842284c6ccba25ec9d78b7b6e62cdd507c083 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Thu, 20 Jun 2024 15:24:11 +0200
+Subject: hexagon: fix fadvise64_64 calling conventions
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 896842284c6ccba25ec9d78b7b6e62cdd507c083 upstream.
+
+fadvise64_64() has two 64-bit arguments at the wrong alignment
+for hexagon, which turns them into a 7-argument syscall that is
+not supported by Linux.
+
+The downstream musl port for hexagon actually asks for a 6-argument
+version the same way we do it on arm, csky, powerpc, so make the
+kernel do it the same way to avoid having to change both.
+
+Link: https://github.com/quic/musl/blob/hexagon/arch/hexagon/syscall_arch.h#L78
+Cc: stable@vger.kernel.org
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/hexagon/include/asm/syscalls.h | 6 ++++++
+ arch/hexagon/kernel/syscalltab.c | 7 +++++++
+ 2 files changed, 13 insertions(+)
+ create mode 100644 arch/hexagon/include/asm/syscalls.h
+
+--- /dev/null
++++ b/arch/hexagon/include/asm/syscalls.h
+@@ -0,0 +1,6 @@
++/* SPDX-License-Identifier: GPL-2.0 */
++
++#include <asm-generic/syscalls.h>
++
++asmlinkage long sys_hexagon_fadvise64_64(int fd, int advice,
++ u32 a2, u32 a3, u32 a4, u32 a5);
+--- a/arch/hexagon/kernel/syscalltab.c
++++ b/arch/hexagon/kernel/syscalltab.c
+@@ -14,6 +14,13 @@
+ #undef __SYSCALL
+ #define __SYSCALL(nr, call) [nr] = (call),
+
++SYSCALL_DEFINE6(hexagon_fadvise64_64, int, fd, int, advice,
++ SC_ARG64(offset), SC_ARG64(len))
++{
++ return ksys_fadvise64_64(fd, SC_VAL64(loff_t, offset), SC_VAL64(loff_t, len), advice);
++}
++#define sys_fadvise64_64 sys_hexagon_fadvise64_64
++
+ void *sys_call_table[__NR_syscalls] = {
+ #include <asm/unistd.h>
+ };
--- /dev/null
+From 2d64eaeeeda5659d52da1af79d237269ba3c2d2c Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Sun, 23 Jun 2024 11:41:13 +0800
+Subject: irqchip/loongson-eiointc: Use early_cpu_to_node() instead of cpu_to_node()
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit 2d64eaeeeda5659d52da1af79d237269ba3c2d2c upstream.
+
+Multi-bridge machines required that all eiointc controllers in the system
+are initialized, otherwise the system does not boot.
+
+The initialization happens on the boot CPU during early boot and relies on
+cpu_to_node() for identifying the individual nodes.
+
+That works when the number of possible CPUs is large enough, but with a
+command line limit, e.g. "nr_cpus=$N" for kdump, but fails when the CPUs
+of the secondary nodes are not covered.
+
+During early ACPI enumeration all CPU to node mappings are recorded up to
+CONFIG_NR_CPUS. These are accessible via early_cpu_to_node() even in the
+case that "nr_cpus=N" truncates the number of possible CPUs and only
+provides the possible CPUs via cpu_to_node() translation.
+
+Change the node lookup in the driver to use early_cpu_to_node() so that
+even with a limitation on the number of possible CPUs all eointc instances
+are initialized.
+
+This can't obviously cure the case where CONFIG_NR_CPUS is too small.
+
+[ tglx: Massaged changelog ]
+
+Fixes: 64cc451e45e1 ("irqchip/loongson-eiointc: Fix incorrect use of acpi_get_vec_parent")
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240623034113.1808727-1-chenhuacai@loongson.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-loongson-eiointc.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/irqchip/irq-loongson-eiointc.c
++++ b/drivers/irqchip/irq-loongson-eiointc.c
+@@ -15,6 +15,7 @@
+ #include <linux/irqchip/chained_irq.h>
+ #include <linux/kernel.h>
+ #include <linux/syscore_ops.h>
++#include <asm/numa.h>
+
+ #define EIOINTC_REG_NODEMAP 0x14a0
+ #define EIOINTC_REG_IPMAP 0x14c0
+@@ -349,7 +350,7 @@ static int __init pch_msi_parse_madt(uni
+ int node;
+
+ if (cpu_has_flatmode)
+- node = cpu_to_node(eiointc_priv[nr_pics - 1]->node * CORES_PER_EIO_NODE);
++ node = early_cpu_to_node(eiointc_priv[nr_pics - 1]->node * CORES_PER_EIO_NODE);
+ else
+ node = eiointc_priv[nr_pics - 1]->node;
+
+@@ -441,7 +442,7 @@ int __init eiointc_acpi_init(struct irq_
+ goto out_free_handle;
+
+ if (cpu_has_flatmode)
+- node = cpu_to_node(acpi_eiointc->node * CORES_PER_EIO_NODE);
++ node = early_cpu_to_node(acpi_eiointc->node * CORES_PER_EIO_NODE);
+ else
+ node = acpi_eiointc->node;
+ acpi_set_vec_parent(node, priv->eiointc_domain, pch_group);
--- /dev/null
+From a9c3ee5d0fdb069b54902300df6ac822027f3b0a Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Sat, 22 Jun 2024 12:33:38 +0800
+Subject: irqchip/loongson-liointc: Set different ISRs for different cores
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit a9c3ee5d0fdb069b54902300df6ac822027f3b0a upstream.
+
+The liointc hardware provides separate Interrupt Status Registers (ISR) for
+each core. The current code uses always the ISR of core #0, which works
+during boot because by default all interrupts are routed to core #0.
+
+When the interrupt routing changes in the firmware configuration then this
+causes interrupts to be lost because they are not configured in the
+corresponding core.
+
+Use the core index to access the correct ISR instead of a hardcoded 0.
+
+[ tglx: Massaged changelog ]
+
+Fixes: 0858ed035a85 ("irqchip/loongson-liointc: Add ACPI init support")
+Co-developed-by: Tianli Xiong <xiongtianli@loongson.cn>
+Signed-off-by: Tianli Xiong <xiongtianli@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20240622043338.1566945-1-chenhuacai@loongson.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-loongson-liointc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/irqchip/irq-loongson-liointc.c
++++ b/drivers/irqchip/irq-loongson-liointc.c
+@@ -28,7 +28,7 @@
+
+ #define LIOINTC_INTC_CHIP_START 0x20
+
+-#define LIOINTC_REG_INTC_STATUS (LIOINTC_INTC_CHIP_START + 0x20)
++#define LIOINTC_REG_INTC_STATUS(core) (LIOINTC_INTC_CHIP_START + 0x20 + (core) * 8)
+ #define LIOINTC_REG_INTC_EN_STATUS (LIOINTC_INTC_CHIP_START + 0x04)
+ #define LIOINTC_REG_INTC_ENABLE (LIOINTC_INTC_CHIP_START + 0x08)
+ #define LIOINTC_REG_INTC_DISABLE (LIOINTC_INTC_CHIP_START + 0x0c)
+@@ -217,7 +217,7 @@ static int liointc_init(phys_addr_t addr
+ goto out_free_priv;
+
+ for (i = 0; i < LIOINTC_NUM_CORES; i++)
+- priv->core_isr[i] = base + LIOINTC_REG_INTC_STATUS;
++ priv->core_isr[i] = base + LIOINTC_REG_INTC_STATUS(i);
+
+ for (i = 0; i < LIOINTC_NUM_PARENT; i++)
+ priv->handler[i].parent_int_map = parent_int_map[i];
--- /dev/null
+From 9cc5f3bf63aa98bd7cc7ce8a8599077fde13283e Mon Sep 17 00:00:00 2001
+From: Dragan Simic <dsimic@manjaro.org>
+Date: Mon, 10 Jun 2024 07:21:12 +0200
+Subject: kbuild: Install dtb files as 0644 in Makefile.dtbinst
+
+From: Dragan Simic <dsimic@manjaro.org>
+
+commit 9cc5f3bf63aa98bd7cc7ce8a8599077fde13283e upstream.
+
+The compiled dtb files aren't executable, so install them with 0644 as their
+permission mode, instead of defaulting to 0755 for the permission mode and
+installing them with the executable bits set.
+
+Some Linux distributions, including Debian, [1][2][3] already include fixes
+in their kernel package build recipes to change the dtb file permissions to
+0644 in their kernel packages. These changes, when additionally propagated
+into the long-term kernel versions, will allow such distributions to remove
+their downstream fixes.
+
+[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/642
+[2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/749
+[3] https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.8.12-1/debian/rules.real#L193
+
+Cc: Diederik de Haas <didi.debian@cknow.org>
+Cc: <stable@vger.kernel.org>
+Fixes: aefd80307a05 ("kbuild: refactor Makefile.dtbinst more")
+Signed-off-by: Dragan Simic <dsimic@manjaro.org>
+Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/Makefile.dtbinst | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/scripts/Makefile.dtbinst
++++ b/scripts/Makefile.dtbinst
+@@ -24,7 +24,7 @@ __dtbs_install: $(dtbs) $(subdirs)
+ @:
+
+ quiet_cmd_dtb_install = INSTALL $@
+- cmd_dtb_install = install -D $< $@
++ cmd_dtb_install = install -D -m 0644 $< $@
+
+ $(dst)/%.dtb: $(obj)/%.dtb
+ $(call cmd,dtb_install)
--- /dev/null
+From d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb Mon Sep 17 00:00:00 2001
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+Date: Fri, 17 Nov 2023 13:49:59 +0100
+Subject: net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
+
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+
+commit d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb upstream.
+
+This patch enhances error handling in scenarios with RTS (Request to
+Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE
+backtraces with a new error handling method. This provides clearer error
+messages and allows for the early termination of problematic sessions.
+Previously, sessions were only released at the end of j1939_xtp_rx_rts().
+
+Potentially this could be reproduced with something like:
+testj1939 -r vcan0:0x80 &
+while true; do
+ # send first RTS
+ cansend vcan0 18EC8090#1014000303002301;
+ # send second RTS
+ cansend vcan0 18EC8090#1014000303002301;
+ # send abort
+ cansend vcan0 18EC8090#ff00000000002301;
+done
+
+Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
+Reported-by: syzbot+daa36413a5cedf799ae4@syzkaller.appspotmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Link: https://lore.kernel.org/all/20231117124959.961171-1-o.rempel@pengutronix.de
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/can/j1939/transport.c | 19 +++++++++++++++++--
+ 1 file changed, 17 insertions(+), 2 deletions(-)
+
+--- a/net/can/j1939/transport.c
++++ b/net/can/j1939/transport.c
+@@ -1593,8 +1593,8 @@ j1939_session *j1939_xtp_rx_rts_session_
+ struct j1939_sk_buff_cb skcb = *j1939_skb_to_cb(skb);
+ struct j1939_session *session;
+ const u8 *dat;
++ int len, ret;
+ pgn_t pgn;
+- int len;
+
+ netdev_dbg(priv->ndev, "%s\n", __func__);
+
+@@ -1653,7 +1653,22 @@ j1939_session *j1939_xtp_rx_rts_session_
+ session->tskey = priv->rx_tskey++;
+ j1939_sk_errqueue(session, J1939_ERRQUEUE_RX_RTS);
+
+- WARN_ON_ONCE(j1939_session_activate(session));
++ ret = j1939_session_activate(session);
++ if (ret) {
++ /* Entering this scope indicates an issue with the J1939 bus.
++ * Possible scenarios include:
++ * - A time lapse occurred, and a new session was initiated
++ * due to another packet being sent correctly. This could
++ * have been caused by too long interrupt, debugger, or being
++ * out-scheduled by another task.
++ * - The bus is receiving numerous erroneous packets, either
++ * from a malfunctioning device or during a test scenario.
++ */
++ netdev_alert(priv->ndev, "%s: 0x%p: concurrent session with same addr (%02x %02x) is already active.\n",
++ __func__, session, skcb.addr.sa, skcb.addr.da);
++ j1939_session_put(session);
++ return NULL;
++ }
+
+ return session;
+ }
--- /dev/null
+From b7cdf1dd5d2a2d8200efd98d1893684db48fe134 Mon Sep 17 00:00:00 2001
+From: Shigeru Yoshida <syoshida@redhat.com>
+Date: Fri, 17 May 2024 12:59:53 +0900
+Subject: net: can: j1939: Initialize unused data in j1939_send_one()
+
+From: Shigeru Yoshida <syoshida@redhat.com>
+
+commit b7cdf1dd5d2a2d8200efd98d1893684db48fe134 upstream.
+
+syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()
+creates full frame including unused data, but it doesn't initialize
+it. This causes the kernel-infoleak issue. Fix this by initializing
+unused data.
+
+[1]
+BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
+BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
+BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
+BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
+BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
+BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
+ instrument_copy_to_user include/linux/instrumented.h:114 [inline]
+ copy_to_user_iter lib/iov_iter.c:24 [inline]
+ iterate_ubuf include/linux/iov_iter.h:29 [inline]
+ iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
+ iterate_and_advance include/linux/iov_iter.h:271 [inline]
+ _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
+ copy_to_iter include/linux/uio.h:196 [inline]
+ memcpy_to_msg include/linux/skbuff.h:4113 [inline]
+ raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008
+ sock_recvmsg_nosec net/socket.c:1046 [inline]
+ sock_recvmsg+0x2c4/0x340 net/socket.c:1068
+ ____sys_recvmsg+0x18a/0x620 net/socket.c:2803
+ ___sys_recvmsg+0x223/0x840 net/socket.c:2845
+ do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939
+ __sys_recvmmsg net/socket.c:3018 [inline]
+ __do_sys_recvmmsg net/socket.c:3041 [inline]
+ __se_sys_recvmmsg net/socket.c:3034 [inline]
+ __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034
+ x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300
+ do_syscall_x64 arch/x86/entry/common.c:52 [inline]
+ do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Uninit was created at:
+ slab_post_alloc_hook mm/slub.c:3804 [inline]
+ slab_alloc_node mm/slub.c:3845 [inline]
+ kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
+ kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
+ __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
+ alloc_skb include/linux/skbuff.h:1313 [inline]
+ alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
+ sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
+ sock_alloc_send_skb include/net/sock.h:1842 [inline]
+ j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]
+ j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]
+ j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277
+ sock_sendmsg_nosec net/socket.c:730 [inline]
+ __sock_sendmsg+0x30f/0x380 net/socket.c:745
+ ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
+ ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
+ __sys_sendmsg net/socket.c:2667 [inline]
+ __do_sys_sendmsg net/socket.c:2676 [inline]
+ __se_sys_sendmsg net/socket.c:2674 [inline]
+ __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
+ x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47
+ do_syscall_x64 arch/x86/entry/common.c:52 [inline]
+ do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Bytes 12-15 of 16 are uninitialized
+Memory access of size 16 starts at ffff888120969690
+Data copied to user address 00000000200017c0
+
+CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
+
+Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
+Reported-and-tested-by: syzbot+5681e40d297b30f5b513@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=5681e40d297b30f5b513
+Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
+Link: https://lore.kernel.org/all/20240517035953.2617090-1-syoshida@redhat.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/can/j1939/main.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/net/can/j1939/main.c
++++ b/net/can/j1939/main.c
+@@ -30,10 +30,6 @@ MODULE_ALIAS("can-proto-" __stringify(CA
+ /* CAN_HDR: #bytes before can_frame data part */
+ #define J1939_CAN_HDR (offsetof(struct can_frame, data))
+
+-/* CAN_FTR: #bytes beyond data part */
+-#define J1939_CAN_FTR (sizeof(struct can_frame) - J1939_CAN_HDR - \
+- sizeof(((struct can_frame *)0)->data))
+-
+ /* lowest layer */
+ static void j1939_can_recv(struct sk_buff *iskb, void *data)
+ {
+@@ -342,7 +338,7 @@ int j1939_send_one(struct j1939_priv *pr
+ memset(cf, 0, J1939_CAN_HDR);
+
+ /* make it a full can frame again */
+- skb_put(skb, J1939_CAN_FTR + (8 - dlc));
++ skb_put_zero(skb, 8 - dlc);
+
+ canid = CAN_EFF_FLAG |
+ (skcb->priority << 26) |
--- /dev/null
+From 9ad1da14ab3bf23087ae45fe399d84a109ddb81a Mon Sep 17 00:00:00 2001
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+Date: Tue, 28 May 2024 09:06:48 +0200
+Subject: net: can: j1939: recover socket queue on CAN bus error during BAM transmission
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+
+commit 9ad1da14ab3bf23087ae45fe399d84a109ddb81a upstream.
+
+Addresses an issue where a CAN bus error during a BAM transmission
+could stall the socket queue, preventing further transmissions even
+after the bus error is resolved. The fix activates the next queued
+session after the error recovery, allowing communication to continue.
+
+Fixes: 9d71dd0c70099 ("can: add support of SAE J1939 protocol")
+Cc: stable@vger.kernel.org
+Reported-by: Alexander Hölzl <alexander.hoelzl@gmx.net>
+Tested-by: Alexander Hölzl <alexander.hoelzl@gmx.net>
+Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Link: https://lore.kernel.org/all/20240528070648.1947203-1-o.rempel@pengutronix.de
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/can/j1939/transport.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/can/j1939/transport.c
++++ b/net/can/j1939/transport.c
+@@ -1681,6 +1681,8 @@ static int j1939_xtp_rx_rts_session_acti
+
+ j1939_session_timers_cancel(session);
+ j1939_session_cancel(session, J1939_XTP_ABORT_BUSY);
++ if (session->transmission)
++ j1939_session_deactivate_activate_next(session);
+
+ return -EBUSY;
+ }
--- /dev/null
+From 9eee5330656bf92f51cb1f09b2dc9f8cf975b3d1 Mon Sep 17 00:00:00 2001
+From: Mostafa Saleh <smostafa@google.com>
+Date: Mon, 24 Jun 2024 20:37:28 +0000
+Subject: PCI/MSI: Fix UAF in msi_capability_init
+
+From: Mostafa Saleh <smostafa@google.com>
+
+commit 9eee5330656bf92f51cb1f09b2dc9f8cf975b3d1 upstream.
+
+KFENCE reports the following UAF:
+
+ BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488
+
+ Use-after-free read at 0x0000000024629571 (in kfence-#12):
+ __pci_enable_msi_range+0x2c0/0x488
+ pci_alloc_irq_vectors_affinity+0xec/0x14c
+ pci_alloc_irq_vectors+0x18/0x28
+
+ kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128
+
+ allocated by task 81 on cpu 7 at 10.808142s:
+ __kmem_cache_alloc_node+0x1f0/0x2bc
+ kmalloc_trace+0x44/0x138
+ msi_alloc_desc+0x3c/0x9c
+ msi_domain_insert_msi_desc+0x30/0x78
+ msi_setup_msi_desc+0x13c/0x184
+ __pci_enable_msi_range+0x258/0x488
+ pci_alloc_irq_vectors_affinity+0xec/0x14c
+ pci_alloc_irq_vectors+0x18/0x28
+
+ freed by task 81 on cpu 7 at 10.811436s:
+ msi_domain_free_descs+0xd4/0x10c
+ msi_domain_free_locked.part.0+0xc0/0x1d8
+ msi_domain_alloc_irqs_all_locked+0xb4/0xbc
+ pci_msi_setup_msi_irqs+0x30/0x4c
+ __pci_enable_msi_range+0x2a8/0x488
+ pci_alloc_irq_vectors_affinity+0xec/0x14c
+ pci_alloc_irq_vectors+0x18/0x28
+
+Descriptor allocation done in:
+__pci_enable_msi_range
+ msi_capability_init
+ msi_setup_msi_desc
+ msi_insert_msi_desc
+ msi_domain_insert_msi_desc
+ msi_alloc_desc
+ ...
+
+Freed in case of failure in __msi_domain_alloc_locked()
+__pci_enable_msi_range
+ msi_capability_init
+ pci_msi_setup_msi_irqs
+ msi_domain_alloc_irqs_all_locked
+ msi_domain_alloc_locked
+ __msi_domain_alloc_locked => fails
+ msi_domain_free_locked
+ ...
+
+That failure propagates back to pci_msi_setup_msi_irqs() in
+msi_capability_init() which accesses the descriptor for unmasking in the
+error exit path.
+
+Cure it by copying the descriptor and using the copy for the error exit path
+unmask operation.
+
+[ tglx: Massaged change log ]
+
+Fixes: bf6e054e0e3f ("genirq/msi: Provide msi_device_populate/destroy_sysfs()")
+Suggested-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Mostafa Saleh <smostafa@google.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Bjorn Heelgas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240624203729.1094506-1-smostafa@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/msi/msi.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/msi/msi.c
++++ b/drivers/pci/msi/msi.c
+@@ -348,7 +348,7 @@ static int msi_capability_init(struct pc
+ struct irq_affinity *affd)
+ {
+ struct irq_affinity_desc *masks = NULL;
+- struct msi_desc *entry;
++ struct msi_desc *entry, desc;
+ int ret;
+
+ /* Reject multi-MSI early on irq domain enabled architectures */
+@@ -373,6 +373,12 @@ static int msi_capability_init(struct pc
+ /* All MSIs are unmasked by default; mask them all */
+ entry = msi_first_desc(&dev->dev, MSI_DESC_ALL);
+ pci_msi_mask(entry, msi_multi_mask(entry));
++ /*
++ * Copy the MSI descriptor for the error path because
++ * pci_msi_setup_msi_irqs() will free it for the hierarchical
++ * interrupt domain case.
++ */
++ memcpy(&desc, entry, sizeof(desc));
+
+ /* Configure MSI capability structure */
+ ret = pci_msi_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSI);
+@@ -392,7 +398,7 @@ static int msi_capability_init(struct pc
+ goto unlock;
+
+ err:
+- pci_msi_unmask(entry, msi_multi_mask(entry));
++ pci_msi_unmask(&desc, msi_multi_mask(&desc));
+ pci_free_msi_irqs(dev);
+ fail:
+ dev->msi_enabled = 0;
serial-imx-set-receiver-level-before-starting-uart.patch
serial-core-introduce-uart_port_tx_limited_flags.patch
serial-bcm63xx-uart-fix-tx-after-conversion-to-uart_port_tx_limited.patch
+alsa-hda-realtek-fix-mute-micmute-leds-don-t-work-for-elitebook-645-665-g11.patch
+tty-mcf-mcf54418-has-10-uarts.patch
+net-can-j1939-initialize-unused-data-in-j1939_send_one.patch
+net-can-j1939-recover-socket-queue-on-can-bus-error-during-bam-transmission.patch
+net-can-j1939-enhanced-error-handling-for-tightly-received-rts-messages-in-xtp_rx_rts_session_new.patch
+pci-msi-fix-uaf-in-msi_capability_init.patch
+cpufreq-intel_pstate-use-hwp-to-initialize-itmt-if-cppc-is-missing.patch
+irqchip-loongson-eiointc-use-early_cpu_to_node-instead-of-cpu_to_node.patch
+cpu-hotplug-fix-dynstate-assignment-in-__cpuhp_setup_state_cpuslocked.patch
+irqchip-loongson-liointc-set-different-isrs-for-different-cores.patch
+kbuild-install-dtb-files-as-0644-in-makefile.dtbinst.patch
+sh-rework-sync_file_range-abi.patch
+btrfs-zoned-fix-initial-free-space-detection.patch
+csky-hexagon-fix-broken-sys_sync_file_range.patch
+hexagon-fix-fadvise64_64-calling-conventions.patch
+drm-drm_file-fix-pid-refcounting-race.patch
+drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_ld_modes.patch
+drm-fbdev-dma-only-set-smem_start-is-enable-per-module-option.patch
+drm-amdgpu-avoid-using-null-object-of-framebuffer.patch
+drm-i915-gt-fix-potential-uaf-by-revoke-of-fence-registers.patch
+drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_hd_modes.patch
+drm-amd-display-send-dp_total_lttpr_cnt-during-detection-if-lttpr-is-present.patch
+drm-amdgpu-atomfirmware-fix-parsing-of-vram_info.patch
+batman-adv-don-t-accept-tt-entries-for-out-of-spec-vids.patch
+can-mcp251xfd-fix-infinite-loop-when-xmit-fails.patch
+ata-ahci-clean-up-sysfs-file-on-error.patch
+ata-libata-core-fix-double-free-on-error.patch
--- /dev/null
+From 30766f1105d6d2459c3b9fe34a3e52b637a72950 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Tue, 11 Jun 2024 22:12:43 +0200
+Subject: sh: rework sync_file_range ABI
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 30766f1105d6d2459c3b9fe34a3e52b637a72950 upstream.
+
+The unusual function calling conventions on SuperH ended up causing
+sync_file_range to have the wrong argument order, with the 'flags'
+argument getting sorted before 'nbytes' by the compiler.
+
+In userspace, I found that musl, glibc, uclibc and strace all expect the
+normal calling conventions with 'nbytes' last, so changing the kernel
+to match them should make all of those work.
+
+In order to be able to also fix libc implementations to work with existing
+kernels, they need to be able to tell which ABI is used. An easy way
+to do this is to add yet another system call using the sync_file_range2
+ABI that works the same on all architectures.
+
+Old user binaries can now work on new kernels, and new binaries can
+try the new sync_file_range2() to work with new kernels or fall back
+to the old sync_file_range() version if that doesn't exist.
+
+Cc: stable@vger.kernel.org
+Fixes: 75c92acdd5b1 ("sh: Wire up new syscalls.")
+Acked-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/sh/kernel/sys_sh32.c | 11 +++++++++++
+ arch/sh/kernel/syscalls/syscall.tbl | 3 ++-
+ 2 files changed, 13 insertions(+), 1 deletion(-)
+
+--- a/arch/sh/kernel/sys_sh32.c
++++ b/arch/sh/kernel/sys_sh32.c
+@@ -59,3 +59,14 @@ asmlinkage int sys_fadvise64_64_wrapper(
+ (u64)len0 << 32 | len1, advice);
+ #endif
+ }
++
++/*
++ * swap the arguments the way that libc wants them instead of
++ * moving flags ahead of the 64-bit nbytes argument
++ */
++SYSCALL_DEFINE6(sh_sync_file_range6, int, fd, SC_ARG64(offset),
++ SC_ARG64(nbytes), unsigned int, flags)
++{
++ return ksys_sync_file_range(fd, SC_VAL64(loff_t, offset),
++ SC_VAL64(loff_t, nbytes), flags);
++}
+--- a/arch/sh/kernel/syscalls/syscall.tbl
++++ b/arch/sh/kernel/syscalls/syscall.tbl
+@@ -321,7 +321,7 @@
+ 311 common set_robust_list sys_set_robust_list
+ 312 common get_robust_list sys_get_robust_list
+ 313 common splice sys_splice
+-314 common sync_file_range sys_sync_file_range
++314 common sync_file_range sys_sh_sync_file_range6
+ 315 common tee sys_tee
+ 316 common vmsplice sys_vmsplice
+ 317 common move_pages sys_move_pages
+@@ -395,6 +395,7 @@
+ 385 common pkey_alloc sys_pkey_alloc
+ 386 common pkey_free sys_pkey_free
+ 387 common rseq sys_rseq
++388 common sync_file_range2 sys_sync_file_range2
+ # room for arch specific syscalls
+ 393 common semget sys_semget
+ 394 common semctl sys_semctl
--- /dev/null
+From 7c92a8bd53f24d50c8cf4aba53bb75505b382fed Mon Sep 17 00:00:00 2001
+From: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
+Date: Thu, 20 Jun 2024 18:29:59 +0200
+Subject: tty: mcf: MCF54418 has 10 UARTS
+
+From: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
+
+commit 7c92a8bd53f24d50c8cf4aba53bb75505b382fed upstream.
+
+Most of the colfires have up to 5 UARTs but MCF54418 has up-to 10 !
+Change the maximum value authorized.
+
+Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
+Cc: stable <stable@kernel.org>
+Fixes: 2545cf6e94b4 ("m68knommu: allow 4 coldfire serial ports")
+Link: https://lore.kernel.org/r/20240620-upstream-uart-v1-1-a9d0d95fb19e@yoseli.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/mcf.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/mcf.c
++++ b/drivers/tty/serial/mcf.c
+@@ -462,7 +462,7 @@ static const struct uart_ops mcf_uart_op
+ .verify_port = mcf_verify_port,
+ };
+
+-static struct mcf_uart mcf_ports[4];
++static struct mcf_uart mcf_ports[10];
+
+ #define MCF_MAXPORTS ARRAY_SIZE(mcf_ports)
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
