--- /dev/null
+From a321d163de3d8aa38a6449ab2becf4b1581aed96 Mon Sep 17 00:00:00 2001
+From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Date: Wed, 8 Jan 2025 19:09:27 +0530
+Subject: bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock
+
+From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+commit a321d163de3d8aa38a6449ab2becf4b1581aed96 upstream.
+
+There are multiple places from where the recovery work gets scheduled
+asynchronously. Also, there are multiple places where the caller waits
+synchronously for the recovery to be completed. One such place is during
+the PM shutdown() callback.
+
+If the device is not alive during recovery_work, it will try to reset the
+device using pci_reset_function(). This function internally will take the
+device_lock() first before resetting the device. By this time, if the lock
+has already been acquired, then recovery_work will get stalled while
+waiting for the lock. And if the lock was already acquired by the caller
+which waits for the recovery_work to be completed, it will lead to
+deadlock.
+
+This is what happened on the X1E80100 CRD device when the device died
+before shutdown() callback. Driver core calls the driver's shutdown()
+callback while holding the device_lock() leading to deadlock.
+
+And this deadlock scenario can occur on other paths as well, like during
+the PM suspend() callback, where the driver core would hold the
+device_lock() before calling driver's suspend() callback. And if the
+recovery_work was already started, it could lead to deadlock. This is also
+observed on the X1E80100 CRD.
+
+So to fix both issues, use pci_try_reset_function() in recovery_work. This
+function first checks for the availability of the device_lock() before
+trying to reset the device. If the lock is available, it will acquire it
+and reset the device. Otherwise, it will return -EAGAIN. If that happens,
+recovery_work will fail with the error message "Recovery failed" as not
+much could be done.
+
+Cc: stable@vger.kernel.org # 5.12
+Reported-by: Johan Hovold <johan@kernel.org>
+Closes: https://lore.kernel.org/mhi/Z1me8iaK7cwgjL92@hovoldconsulting.com
+Fixes: 7389337f0a78 ("mhi: pci_generic: Add suspend/resume/recovery procedure")
+Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
+Tested-by: Johan Hovold <johan+linaro@kernel.org>
+Analyzed-by: Johan Hovold <johan@kernel.org>
+Link: https://lore.kernel.org/mhi/Z2KKjWY2mPen6GPL@hovoldconsulting.com/
+Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
+Link: https://lore.kernel.org/r/20250108-mhi_recovery_fix-v1-1-a0a00a17da46@linaro.org
+Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/mhi/host/pci_generic.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/bus/mhi/host/pci_generic.c
++++ b/drivers/bus/mhi/host/pci_generic.c
+@@ -1040,8 +1040,9 @@ static void mhi_pci_recovery_work(struct
+ err_unprepare:
+ mhi_unprepare_after_power_down(mhi_cntrl);
+ err_try_reset:
+- if (pci_reset_function(pdev))
+- dev_err(&pdev->dev, "Recovery failed\n");
++ err = pci_try_reset_function(pdev);
++ if (err)
++ dev_err(&pdev->dev, "Recovery failed: %d\n", err);
+ }
+
+ static void health_check(struct timer_list *t)
--- /dev/null
+From 91d44c1afc61a2fec37a9c7a3485368309391e0b Mon Sep 17 00:00:00 2001
+From: Qiu-ji Chen <chenqiuji666@gmail.com>
+Date: Sat, 18 Jan 2025 15:08:33 +0800
+Subject: cdx: Fix possible UAF error in driver_override_show()
+
+From: Qiu-ji Chen <chenqiuji666@gmail.com>
+
+commit 91d44c1afc61a2fec37a9c7a3485368309391e0b upstream.
+
+Fixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c
+
+This function driver_override_show() is part of DEVICE_ATTR_RW, which
+includes both driver_override_show() and driver_override_store().
+These functions can be executed concurrently in sysfs.
+
+The driver_override_store() function uses driver_set_override() to
+update the driver_override value, and driver_set_override() internally
+locks the device (device_lock(dev)). If driver_override_show() reads
+cdx_dev->driver_override without locking, it could potentially access
+a freed pointer if driver_override_store() frees the string
+concurrently. This could lead to printing a kernel address, which is a
+security risk since DEVICE_ATTR can be read by all users.
+
+Additionally, a similar pattern is used in drivers/amba/bus.c, as well
+as many other bus drivers, where device_lock() is taken in the show
+function, and it has been working without issues.
+
+This potential bug was detected by our experimental static analysis
+tool, which analyzes locking APIs and paired functions to identify
+data races and atomicity violations.
+
+Fixes: 1f86a00c1159 ("bus/fsl-mc: add support for 'driver_override' in the mc-bus")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Qiu-ji Chen <chenqiuji666@gmail.com>
+Link: https://lore.kernel.org/r/20250118070833.27201-1-chenqiuji666@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cdx/cdx.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/cdx/cdx.c
++++ b/drivers/cdx/cdx.c
+@@ -470,8 +470,12 @@ static ssize_t driver_override_show(stru
+ struct device_attribute *attr, char *buf)
+ {
+ struct cdx_device *cdx_dev = to_cdx_device(dev);
++ ssize_t len;
+
+- return sysfs_emit(buf, "%s\n", cdx_dev->driver_override);
++ device_lock(dev);
++ len = sysfs_emit(buf, "%s\n", cdx_dev->driver_override);
++ device_unlock(dev);
++ return len;
+ }
+ static DEVICE_ATTR_RW(driver_override);
+
--- /dev/null
+From 6d991f569c5ef6eaeadf1238df2c36e3975233ad Mon Sep 17 00:00:00 2001
+From: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+Date: Thu, 23 Jan 2025 09:32:49 -0300
+Subject: char: misc: deallocate static minor in error path
+
+From: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+
+commit 6d991f569c5ef6eaeadf1238df2c36e3975233ad upstream.
+
+When creating sysfs files fail, the allocated minor must be freed such that
+it can be later reused. That is specially harmful for static minor numbers,
+since those would always fail to register later on.
+
+Fixes: 6d04d2b554b1 ("misc: misc_minor_alloc to use ida for all dynamic/misc dynamic minors")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+Link: https://lore.kernel.org/r/20250123123249.4081674-5-cascardo@igalia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/misc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/char/misc.c
++++ b/drivers/char/misc.c
+@@ -264,8 +264,8 @@ int misc_register(struct miscdevice *mis
+ device_create_with_groups(&misc_class, misc->parent, dev,
+ misc, misc->groups, "%s", misc->name);
+ if (IS_ERR(misc->this_device)) {
++ misc_minor_free(misc->minor);
+ if (is_dynamic) {
+- misc_minor_free(misc->minor);
+ misc->minor = MISC_DYNAMIC_MINOR;
+ }
+ err = PTR_ERR(misc->this_device);
--- /dev/null
+From 78eb41f518f414378643ab022241df2a9dcd008b Mon Sep 17 00:00:00 2001
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Date: Thu, 13 Feb 2025 15:05:13 +0100
+Subject: drivers: core: fix device leak in __fw_devlink_relax_cycles()
+
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+commit 78eb41f518f414378643ab022241df2a9dcd008b upstream.
+
+Commit bac3b10b78e5 ("driver core: fw_devlink: Stop trying to optimize
+cycle detection logic") introduced a new struct device *con_dev and a
+get_dev_from_fwnode() call to get it, but without adding a corresponding
+put_device().
+
+Closes: https://lore.kernel.org/all/20241204124826.2e055091@booty/
+Fixes: bac3b10b78e5 ("driver core: fw_devlink: Stop trying to optimize cycle detection logic")
+Cc: stable@vger.kernel.org
+Reviewed-by: Saravana Kannan <saravanak@google.com>
+Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Link: https://lore.kernel.org/r/20250213-fix__fw_devlink_relax_cycles_missing_device_put-v2-1-8cd3b03e6a3f@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/base/core.c
++++ b/drivers/base/core.c
+@@ -2079,6 +2079,7 @@ static bool __fw_devlink_relax_cycles(st
+ out:
+ sup_handle->flags &= ~FWNODE_FLAG_VISITED;
+ put_device(sup_dev);
++ put_device(con_dev);
+ put_device(par_dev);
+ return ret;
+ }
--- /dev/null
+From 819cec1dc47cdeac8f5dd6ba81c1dbee2a68c3bb Mon Sep 17 00:00:00 2001
+From: Haoyu Li <lihaoyu499@gmail.com>
+Date: Thu, 30 Jan 2025 19:58:11 +0800
+Subject: drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl
+
+From: Haoyu Li <lihaoyu499@gmail.com>
+
+commit 819cec1dc47cdeac8f5dd6ba81c1dbee2a68c3bb upstream.
+
+In the "pmcmd_ioctl" function, three memory objects allocated by
+kmalloc are initialized by "hcall_get_cpu_state", which are then
+copied to user space. The initializer is indeed implemented in
+"acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk of
+information leakage due to uninitialized bytes.
+
+Fixes: 3d679d5aec64 ("virt: acrn: Introduce interfaces to query C-states and P-states allowed by hypervisor")
+Signed-off-by: Haoyu Li <lihaoyu499@gmail.com>
+Cc: stable <stable@kernel.org>
+Acked-by: Fei Li <fei1.li@intel.com>
+Link: https://lore.kernel.org/r/20250130115811.92424-1-lihaoyu499@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/virt/acrn/hsm.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/virt/acrn/hsm.c
++++ b/drivers/virt/acrn/hsm.c
+@@ -49,7 +49,7 @@ static int pmcmd_ioctl(u64 cmd, void __u
+ switch (cmd & PMCMD_TYPE_MASK) {
+ case ACRN_PMCMD_GET_PX_CNT:
+ case ACRN_PMCMD_GET_CX_CNT:
+- pm_info = kmalloc(sizeof(u64), GFP_KERNEL);
++ pm_info = kzalloc(sizeof(u64), GFP_KERNEL);
+ if (!pm_info)
+ return -ENOMEM;
+
+@@ -64,7 +64,7 @@ static int pmcmd_ioctl(u64 cmd, void __u
+ kfree(pm_info);
+ break;
+ case ACRN_PMCMD_GET_PX_DATA:
+- px_data = kmalloc(sizeof(*px_data), GFP_KERNEL);
++ px_data = kzalloc(sizeof(*px_data), GFP_KERNEL);
+ if (!px_data)
+ return -ENOMEM;
+
+@@ -79,7 +79,7 @@ static int pmcmd_ioctl(u64 cmd, void __u
+ kfree(px_data);
+ break;
+ case ACRN_PMCMD_GET_CX_DATA:
+- cx_data = kmalloc(sizeof(*cx_data), GFP_KERNEL);
++ cx_data = kzalloc(sizeof(*cx_data), GFP_KERNEL);
+ if (!cx_data)
+ return -ENOMEM;
+
--- /dev/null
+From 038ef0754aae76f79b147b8867f9250e6a976872 Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Fri, 7 Feb 2025 00:03:11 +0200
+Subject: eeprom: digsy_mtc: Make GPIO lookup table match the device
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit 038ef0754aae76f79b147b8867f9250e6a976872 upstream.
+
+The dev_id value in the GPIO lookup table must match to
+the device instance name, which in this case is combined
+of name and platform device ID, i.e. "spi_gpio.1". But
+the table assumed that there was no platform device ID
+defined, which is wrong. Fix the dev_id value accordingly.
+
+Fixes: 9b00bc7b901f ("spi: spi-gpio: Rewrite to use GPIO descriptors")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Link: https://lore.kernel.org/r/20250206220311.1554075-1-andriy.shevchenko@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/eeprom/digsy_mtc_eeprom.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/misc/eeprom/digsy_mtc_eeprom.c
++++ b/drivers/misc/eeprom/digsy_mtc_eeprom.c
+@@ -50,7 +50,7 @@ static struct platform_device digsy_mtc_
+ };
+
+ static struct gpiod_lookup_table eeprom_spi_gpiod_table = {
+- .dev_id = "spi_gpio",
++ .dev_id = "spi_gpio.1",
+ .table = {
+ GPIO_LOOKUP("gpio@b00", GPIO_EEPROM_CLK,
+ "sck", GPIO_ACTIVE_HIGH),
--- /dev/null
+From 21d7241faf406e8aee3ce348451cc362d5db6a02 Mon Sep 17 00:00:00 2001
+From: Markus Burri <markus.burri@mt.com>
+Date: Fri, 24 Jan 2025 16:07:03 +0100
+Subject: iio: adc: ad7192: fix channel select
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Markus Burri <markus.burri@mt.com>
+
+commit 21d7241faf406e8aee3ce348451cc362d5db6a02 upstream.
+
+Channel configuration doesn't work as expected.
+For FIELD_PREP the bit mask is needed and not the bit number.
+
+Fixes: 874bbd1219c7 ("iio: adc: ad7192: Use bitfield access macros")
+Signed-off-by: Markus Burri <markus.burri@mt.com>
+Reviewed-by: Nuno Sá <nuno.sa@analog.com>
+Link: https://patch.msgid.link/20250124150703.97848-1-markus.burri@mt.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/ad7192.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/adc/ad7192.c
++++ b/drivers/iio/adc/ad7192.c
+@@ -1082,7 +1082,7 @@ static int ad7192_update_scan_mode(struc
+
+ conf &= ~AD7192_CONF_CHAN_MASK;
+ for_each_set_bit(i, scan_mask, 8)
+- conf |= FIELD_PREP(AD7192_CONF_CHAN_MASK, i);
++ conf |= FIELD_PREP(AD7192_CONF_CHAN_MASK, BIT(i));
+
+ ret = ad_sd_write_reg(&st->sd, AD7192_REG_CONF, 3, conf);
+ if (ret < 0)
--- /dev/null
+From aa5119c36d19639397d29ef305aa53a5ecd72b27 Mon Sep 17 00:00:00 2001
+From: Nayab Sayed <nayabbasha.sayed@microchip.com>
+Date: Wed, 15 Jan 2025 11:37:04 +0530
+Subject: iio: adc: at91-sama5d2_adc: fix sama7g5 realbits value
+
+From: Nayab Sayed <nayabbasha.sayed@microchip.com>
+
+commit aa5119c36d19639397d29ef305aa53a5ecd72b27 upstream.
+
+The number of valid bits in SAMA7G5 ADC channel data register are 16.
+Hence changing the realbits value to 16
+
+Fixes: 840bf6cb983f ("iio: adc: at91-sama5d2_adc: add support for sama7g5 device")
+Signed-off-by: Nayab Sayed <nayabbasha.sayed@microchip.com>
+Link: https://patch.msgid.link/20250115-fix-sama7g5-adc-realbits-v2-1-58a6e4087584@microchip.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/at91-sama5d2_adc.c | 68 +++++++++++++++++++++----------------
+ 1 file changed, 40 insertions(+), 28 deletions(-)
+
+--- a/drivers/iio/adc/at91-sama5d2_adc.c
++++ b/drivers/iio/adc/at91-sama5d2_adc.c
+@@ -329,7 +329,7 @@ static const struct at91_adc_reg_layout
+ #define AT91_HWFIFO_MAX_SIZE_STR "128"
+ #define AT91_HWFIFO_MAX_SIZE 128
+
+-#define AT91_SAMA5D2_CHAN_SINGLE(index, num, addr) \
++#define AT91_SAMA_CHAN_SINGLE(index, num, addr, rbits) \
+ { \
+ .type = IIO_VOLTAGE, \
+ .channel = num, \
+@@ -337,7 +337,7 @@ static const struct at91_adc_reg_layout
+ .scan_index = index, \
+ .scan_type = { \
+ .sign = 'u', \
+- .realbits = 14, \
++ .realbits = rbits, \
+ .storagebits = 16, \
+ }, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+@@ -350,7 +350,13 @@ static const struct at91_adc_reg_layout
+ .indexed = 1, \
+ }
+
+-#define AT91_SAMA5D2_CHAN_DIFF(index, num, num2, addr) \
++#define AT91_SAMA5D2_CHAN_SINGLE(index, num, addr) \
++ AT91_SAMA_CHAN_SINGLE(index, num, addr, 14)
++
++#define AT91_SAMA7G5_CHAN_SINGLE(index, num, addr) \
++ AT91_SAMA_CHAN_SINGLE(index, num, addr, 16)
++
++#define AT91_SAMA_CHAN_DIFF(index, num, num2, addr, rbits) \
+ { \
+ .type = IIO_VOLTAGE, \
+ .differential = 1, \
+@@ -360,7 +366,7 @@ static const struct at91_adc_reg_layout
+ .scan_index = index, \
+ .scan_type = { \
+ .sign = 's', \
+- .realbits = 14, \
++ .realbits = rbits, \
+ .storagebits = 16, \
+ }, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+@@ -373,6 +379,12 @@ static const struct at91_adc_reg_layout
+ .indexed = 1, \
+ }
+
++#define AT91_SAMA5D2_CHAN_DIFF(index, num, num2, addr) \
++ AT91_SAMA_CHAN_DIFF(index, num, num2, addr, 14)
++
++#define AT91_SAMA7G5_CHAN_DIFF(index, num, num2, addr) \
++ AT91_SAMA_CHAN_DIFF(index, num, num2, addr, 16)
++
+ #define AT91_SAMA5D2_CHAN_TOUCH(num, name, mod) \
+ { \
+ .type = IIO_POSITIONRELATIVE, \
+@@ -666,30 +678,30 @@ static const struct iio_chan_spec at91_s
+ };
+
+ static const struct iio_chan_spec at91_sama7g5_adc_channels[] = {
+- AT91_SAMA5D2_CHAN_SINGLE(0, 0, 0x60),
+- AT91_SAMA5D2_CHAN_SINGLE(1, 1, 0x64),
+- AT91_SAMA5D2_CHAN_SINGLE(2, 2, 0x68),
+- AT91_SAMA5D2_CHAN_SINGLE(3, 3, 0x6c),
+- AT91_SAMA5D2_CHAN_SINGLE(4, 4, 0x70),
+- AT91_SAMA5D2_CHAN_SINGLE(5, 5, 0x74),
+- AT91_SAMA5D2_CHAN_SINGLE(6, 6, 0x78),
+- AT91_SAMA5D2_CHAN_SINGLE(7, 7, 0x7c),
+- AT91_SAMA5D2_CHAN_SINGLE(8, 8, 0x80),
+- AT91_SAMA5D2_CHAN_SINGLE(9, 9, 0x84),
+- AT91_SAMA5D2_CHAN_SINGLE(10, 10, 0x88),
+- AT91_SAMA5D2_CHAN_SINGLE(11, 11, 0x8c),
+- AT91_SAMA5D2_CHAN_SINGLE(12, 12, 0x90),
+- AT91_SAMA5D2_CHAN_SINGLE(13, 13, 0x94),
+- AT91_SAMA5D2_CHAN_SINGLE(14, 14, 0x98),
+- AT91_SAMA5D2_CHAN_SINGLE(15, 15, 0x9c),
+- AT91_SAMA5D2_CHAN_DIFF(16, 0, 1, 0x60),
+- AT91_SAMA5D2_CHAN_DIFF(17, 2, 3, 0x68),
+- AT91_SAMA5D2_CHAN_DIFF(18, 4, 5, 0x70),
+- AT91_SAMA5D2_CHAN_DIFF(19, 6, 7, 0x78),
+- AT91_SAMA5D2_CHAN_DIFF(20, 8, 9, 0x80),
+- AT91_SAMA5D2_CHAN_DIFF(21, 10, 11, 0x88),
+- AT91_SAMA5D2_CHAN_DIFF(22, 12, 13, 0x90),
+- AT91_SAMA5D2_CHAN_DIFF(23, 14, 15, 0x98),
++ AT91_SAMA7G5_CHAN_SINGLE(0, 0, 0x60),
++ AT91_SAMA7G5_CHAN_SINGLE(1, 1, 0x64),
++ AT91_SAMA7G5_CHAN_SINGLE(2, 2, 0x68),
++ AT91_SAMA7G5_CHAN_SINGLE(3, 3, 0x6c),
++ AT91_SAMA7G5_CHAN_SINGLE(4, 4, 0x70),
++ AT91_SAMA7G5_CHAN_SINGLE(5, 5, 0x74),
++ AT91_SAMA7G5_CHAN_SINGLE(6, 6, 0x78),
++ AT91_SAMA7G5_CHAN_SINGLE(7, 7, 0x7c),
++ AT91_SAMA7G5_CHAN_SINGLE(8, 8, 0x80),
++ AT91_SAMA7G5_CHAN_SINGLE(9, 9, 0x84),
++ AT91_SAMA7G5_CHAN_SINGLE(10, 10, 0x88),
++ AT91_SAMA7G5_CHAN_SINGLE(11, 11, 0x8c),
++ AT91_SAMA7G5_CHAN_SINGLE(12, 12, 0x90),
++ AT91_SAMA7G5_CHAN_SINGLE(13, 13, 0x94),
++ AT91_SAMA7G5_CHAN_SINGLE(14, 14, 0x98),
++ AT91_SAMA7G5_CHAN_SINGLE(15, 15, 0x9c),
++ AT91_SAMA7G5_CHAN_DIFF(16, 0, 1, 0x60),
++ AT91_SAMA7G5_CHAN_DIFF(17, 2, 3, 0x68),
++ AT91_SAMA7G5_CHAN_DIFF(18, 4, 5, 0x70),
++ AT91_SAMA7G5_CHAN_DIFF(19, 6, 7, 0x78),
++ AT91_SAMA7G5_CHAN_DIFF(20, 8, 9, 0x80),
++ AT91_SAMA7G5_CHAN_DIFF(21, 10, 11, 0x88),
++ AT91_SAMA7G5_CHAN_DIFF(22, 12, 13, 0x90),
++ AT91_SAMA7G5_CHAN_DIFF(23, 14, 15, 0x98),
+ IIO_CHAN_SOFT_TIMESTAMP(24),
+ AT91_SAMA5D2_CHAN_TEMP(AT91_SAMA7G5_ADC_TEMP_CHANNEL, "temp", 0xdc),
+ };
--- /dev/null
+From e17b9f20da7d2bc1f48878ab2230523b2512d965 Mon Sep 17 00:00:00 2001
+From: Angelo Dureghello <adureghello@baylibre.com>
+Date: Sat, 25 Jan 2025 17:24:32 +0100
+Subject: iio: dac: ad3552r: clear reset status flag
+
+From: Angelo Dureghello <adureghello@baylibre.com>
+
+commit e17b9f20da7d2bc1f48878ab2230523b2512d965 upstream.
+
+Clear reset status flag, to keep error status register clean after reset
+(ad3552r manual, rev B table 38).
+
+Reset error flag was left to 1, so debugging registers, the "Error
+Status Register" was dirty (0x01). It is important to clear this bit, so
+if there is any reset event over normal working mode, it is possible to
+detect it.
+
+Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support")
+Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
+Link: https://patch.msgid.link/20250125-wip-bl-ad3552r-clear-reset-v2-1-aa3a27f3ff8c@baylibre.com
+Cc: <Stable@vger..kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/dac/ad3552r.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/iio/dac/ad3552r.c
++++ b/drivers/iio/dac/ad3552r.c
+@@ -410,6 +410,12 @@ static int ad3552r_reset(struct ad3552r_
+ return ret;
+ }
+
++ /* Clear reset error flag, see ad3552r manual, rev B table 38. */
++ ret = ad3552r_write_reg(dac, AD3552R_REG_ADDR_ERR_STATUS,
++ AD3552R_MASK_RESET_STATUS);
++ if (ret)
++ return ret;
++
+ return ad3552r_update_reg_field(dac,
+ AD3552R_REG_ADDR_INTERFACE_CONFIG_A,
+ AD3552R_MASK_ADDR_ASCENSION,
--- /dev/null
+From cc2c3540d9477a9931fb0fd851fcaeba524a5b35 Mon Sep 17 00:00:00 2001
+From: Sam Winchenbach <swinchenbach@arka.org>
+Date: Mon, 3 Feb 2025 13:34:34 +0000
+Subject: iio: filter: admv8818: Force initialization of SDO
+
+From: Sam Winchenbach <swinchenbach@arka.org>
+
+commit cc2c3540d9477a9931fb0fd851fcaeba524a5b35 upstream.
+
+When a weak pull-up is present on the SDO line, regmap_update_bits fails
+to write both the SOFTRESET and SDOACTIVE bits because it incorrectly
+reads them as already set.
+
+Since the soft reset disables the SDO line, performing a
+read-modify-write operation on ADI_SPI_CONFIG_A to enable the SDO line
+doesn't make sense. This change directly writes to the register instead
+of using regmap_update_bits.
+
+Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818")
+Signed-off-by: Sam Winchenbach <swinchenbach@arka.org>
+Link: https://patch.msgid.link/SA1P110MB106904C961B0F3FAFFED74C0BCF5A@SA1P110MB1069.NAMP110.PROD.OUTLOOK.COM
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/filter/admv8818.c | 14 ++++----------
+ 1 file changed, 4 insertions(+), 10 deletions(-)
+
+--- a/drivers/iio/filter/admv8818.c
++++ b/drivers/iio/filter/admv8818.c
+@@ -574,21 +574,15 @@ static int admv8818_init(struct admv8818
+ struct spi_device *spi = st->spi;
+ unsigned int chip_id;
+
+- ret = regmap_update_bits(st->regmap, ADMV8818_REG_SPI_CONFIG_A,
+- ADMV8818_SOFTRESET_N_MSK |
+- ADMV8818_SOFTRESET_MSK,
+- FIELD_PREP(ADMV8818_SOFTRESET_N_MSK, 1) |
+- FIELD_PREP(ADMV8818_SOFTRESET_MSK, 1));
++ ret = regmap_write(st->regmap, ADMV8818_REG_SPI_CONFIG_A,
++ ADMV8818_SOFTRESET_N_MSK | ADMV8818_SOFTRESET_MSK);
+ if (ret) {
+ dev_err(&spi->dev, "ADMV8818 Soft Reset failed.\n");
+ return ret;
+ }
+
+- ret = regmap_update_bits(st->regmap, ADMV8818_REG_SPI_CONFIG_A,
+- ADMV8818_SDOACTIVE_N_MSK |
+- ADMV8818_SDOACTIVE_MSK,
+- FIELD_PREP(ADMV8818_SDOACTIVE_N_MSK, 1) |
+- FIELD_PREP(ADMV8818_SDOACTIVE_MSK, 1));
++ ret = regmap_write(st->regmap, ADMV8818_REG_SPI_CONFIG_A,
++ ADMV8818_SDOACTIVE_N_MSK | ADMV8818_SDOACTIVE_MSK);
+ if (ret) {
+ dev_err(&spi->dev, "ADMV8818 SDO Enable failed.\n");
+ return ret;
--- /dev/null
+From a96d3e2beca0e51c8444d0a3b6b3ec484c4c5a8f Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Sun, 12 Jan 2025 01:08:11 +0100
+Subject: iio: light: apds9306: fix max_scale_nano values
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit a96d3e2beca0e51c8444d0a3b6b3ec484c4c5a8f upstream.
+
+The two provided max_scale_nano values must be multiplied by 100 and 10
+respectively to achieve nano units. According to the comments:
+
+Max scale for apds0306 is 16.326432 → the fractional part is 0.326432,
+which is 326432000 in NANO. The current value is 3264320.
+
+Max scale for apds0306-065 is 14.09721 → the fractional part is 0.09712,
+which is 97120000 in NANO. The current value is 9712000.
+
+Update max_scale_nano initialization to use the right NANO fractional
+parts.
+
+Cc: stable@vger.kernel.org
+Fixes: 620d1e6c7a3f ("iio: light: Add support for APDS9306 Light Sensor")
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Tested-by: subhajit.ghosh@tweaklogic.com
+Link: https://patch.msgid.link/20250112-apds9306_nano_vals-v1-1-82fb145d0b16@gmail.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/light/apds9306.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/light/apds9306.c
++++ b/drivers/iio/light/apds9306.c
+@@ -108,11 +108,11 @@ static const struct part_id_gts_multipli
+ {
+ .part_id = 0xB1,
+ .max_scale_int = 16,
+- .max_scale_nano = 3264320,
++ .max_scale_nano = 326432000,
+ }, {
+ .part_id = 0xB3,
+ .max_scale_int = 14,
+- .max_scale_nano = 9712000,
++ .max_scale_nano = 97120000,
+ },
+ };
+
--- /dev/null
+From b5edccae9f447a92d475267d94c33f4926963eec Mon Sep 17 00:00:00 2001
+From: Pawel Chmielewski <pawel.chmielewski@intel.com>
+Date: Tue, 11 Feb 2025 20:50:15 +0200
+Subject: intel_th: pci: Add Arrow Lake support
+
+From: Pawel Chmielewski <pawel.chmielewski@intel.com>
+
+commit b5edccae9f447a92d475267d94c33f4926963eec upstream.
+
+Add support for the Trace Hub in Arrow Lake.
+
+Signed-off-by: Pawel Chmielewski <pawel.chmielewski@intel.com>
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable@kernel.org
+Link: https://lore.kernel.org/r/20250211185017.1759193-4-alexander.shishkin@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hwtracing/intel_th/pci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -335,6 +335,11 @@ static const struct pci_device_id intel_
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
+ {
++ /* Arrow Lake */
++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x7724),
++ .driver_data = (kernel_ulong_t)&intel_th_2x,
++ },
++ {
+ /* Alder Lake CPU */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x466f),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
--- /dev/null
+From a70034d6c0d5f3cdee40bb00a578e17fd2ebe426 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Tue, 11 Feb 2025 20:50:16 +0200
+Subject: intel_th: pci: Add Panther Lake-H support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit a70034d6c0d5f3cdee40bb00a578e17fd2ebe426 upstream.
+
+Add support for the Trace Hub in Panther Lake-H.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable@kernel.org
+Link: https://lore.kernel.org/r/20250211185017.1759193-5-alexander.shishkin@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hwtracing/intel_th/pci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -340,6 +340,11 @@ static const struct pci_device_id intel_
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
+ {
++ /* Panther Lake-H */
++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe324),
++ .driver_data = (kernel_ulong_t)&intel_th_2x,
++ },
++ {
+ /* Alder Lake CPU */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x466f),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
--- /dev/null
+From 49114ff05770264ae233f50023fc64a719a9dcf9 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Tue, 11 Feb 2025 20:50:17 +0200
+Subject: intel_th: pci: Add Panther Lake-P/U support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 49114ff05770264ae233f50023fc64a719a9dcf9 upstream.
+
+Add support for the Trace Hub in Panther Lake-P/U.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable@kernel.org
+Link: https://lore.kernel.org/r/20250211185017.1759193-6-alexander.shishkin@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hwtracing/intel_th/pci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -345,6 +345,11 @@ static const struct pci_device_id intel_
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
+ },
+ {
++ /* Panther Lake-P/U */
++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe424),
++ .driver_data = (kernel_ulong_t)&intel_th_2x,
++ },
++ {
+ /* Alder Lake CPU */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x466f),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
--- /dev/null
+From ee89e8013383d50a27ea9bf3c8a69eed6799856f Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 27 Feb 2025 14:24:06 -0800
+Subject: KVM: SVM: Drop DEBUGCTL[5:2] from guest's effective value
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit ee89e8013383d50a27ea9bf3c8a69eed6799856f upstream.
+
+Drop bits 5:2 from the guest's effective DEBUGCTL value, as AMD changed
+the architectural behavior of the bits and broke backwards compatibility.
+On CPUs without BusLockTrap (or at least, in APMs from before ~2023),
+bits 5:2 controlled the behavior of external pins:
+
+ Performance-Monitoring/Breakpoint Pin-Control (PBi)—Bits 5:2, read/write.
+ Software uses thesebits to control the type of information reported by
+ the four external performance-monitoring/breakpoint pins on the
+ processor. When a PBi bit is cleared to 0, the corresponding external pin
+ (BPi) reports performance-monitor information. When a PBi bit is set to
+ 1, the corresponding external pin (BPi) reports breakpoint information.
+
+With the introduction of BusLockTrap, presumably to be compatible with
+Intel CPUs, AMD redefined bit 2 to be BLCKDB:
+
+ Bus Lock #DB Trap (BLCKDB)—Bit 2, read/write. Software sets this bit to
+ enable generation of a #DB trap following successful execution of a bus
+ lock when CPL is > 0.
+
+and redefined bits 5:3 (and bit 6) as "6:3 Reserved MBZ".
+
+Ideally, KVM would treat bits 5:2 as reserved. Defer that change to a
+feature cleanup to avoid breaking existing guest in LTS kernels. For now,
+drop the bits to retain backwards compatibility (of a sort).
+
+Note, dropping bits 5:2 is still a guest-visible change, e.g. if the guest
+is enabling LBRs *and* the legacy PBi bits, then the state of the PBi bits
+is visible to the guest, whereas now the guest will always see '0'.
+
+Reported-by: Ravi Bangoria <ravi.bangoria@amd.com>
+Cc: stable@vger.kernel.org
+Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
+Link: https://lore.kernel.org/r/20250227222411.3490595-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/svm.c | 12 ++++++++++++
+ arch/x86/kvm/svm/svm.h | 2 +-
+ 2 files changed, 13 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/svm/svm.c
++++ b/arch/x86/kvm/svm/svm.c
+@@ -3169,6 +3169,18 @@ static int svm_set_msr(struct kvm_vcpu *
+ kvm_pr_unimpl_wrmsr(vcpu, ecx, data);
+ break;
+ }
++
++ /*
++ * AMD changed the architectural behavior of bits 5:2. On CPUs
++ * without BusLockTrap, bits 5:2 control "external pins", but
++ * on CPUs that support BusLockDetect, bit 2 enables BusLockTrap
++ * and bits 5:3 are reserved-to-zero. Sadly, old KVM allowed
++ * the guest to set bits 5:2 despite not actually virtualizing
++ * Performance-Monitoring/Breakpoint external pins. Drop bits
++ * 5:2 for backwards compatibility.
++ */
++ data &= ~GENMASK(5, 2);
++
+ if (data & DEBUGCTL_RESERVED_BITS)
+ return 1;
+
+--- a/arch/x86/kvm/svm/svm.h
++++ b/arch/x86/kvm/svm/svm.h
+@@ -591,7 +591,7 @@ static inline bool is_vnmi_enabled(struc
+ /* svm.c */
+ #define MSR_INVALID 0xffffffffU
+
+-#define DEBUGCTL_RESERVED_BITS (~(0x3fULL))
++#define DEBUGCTL_RESERVED_BITS (~(DEBUGCTLMSR_BTF | DEBUGCTLMSR_LBR))
+
+ extern bool dump_invalid_vmcb;
+
--- /dev/null
+From 433265870ab3455b418885bff48fa5fd02f7e448 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 27 Feb 2025 14:24:09 -0800
+Subject: KVM: SVM: Manually context switch DEBUGCTL if LBR virtualization is disabled
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 433265870ab3455b418885bff48fa5fd02f7e448 upstream.
+
+Manually load the guest's DEBUGCTL prior to VMRUN (and restore the host's
+value on #VMEXIT) if it diverges from the host's value and LBR
+virtualization is disabled, as hardware only context switches DEBUGCTL if
+LBR virtualization is fully enabled. Running the guest with the host's
+value has likely been mildly problematic for quite some time, e.g. it will
+result in undesirable behavior if BTF diverges (with the caveat that KVM
+now suppresses guest BTF due to lack of support).
+
+But the bug became fatal with the introduction of Bus Lock Trap ("Detect"
+in kernel paralance) support for AMD (commit 408eb7417a92
+("x86/bus_lock: Add support for AMD")), as a bus lock in the guest will
+trigger an unexpected #DB.
+
+Note, suppressing the bus lock #DB, i.e. simply resuming the guest without
+injecting a #DB, is not an option. It wouldn't address the general issue
+with DEBUGCTL, e.g. for things like BTF, and there are other guest-visible
+side effects if BusLockTrap is left enabled.
+
+If BusLockTrap is disabled, then DR6.BLD is reserved-to-1; any attempts to
+clear it by software are ignored. But if BusLockTrap is enabled, software
+can clear DR6.BLD:
+
+ Software enables bus lock trap by setting DebugCtl MSR[BLCKDB] (bit 2)
+ to 1. When bus lock trap is enabled, ... The processor indicates that
+ this #DB was caused by a bus lock by clearing DR6[BLD] (bit 11). DR6[11]
+ previously had been defined to be always 1.
+
+and clearing DR6.BLD is "sticky" in that it's not set (i.e. lowered) by
+other #DBs:
+
+ All other #DB exceptions leave DR6[BLD] unmodified
+
+E.g. leaving BusLockTrap enable can confuse a legacy guest that writes '0'
+to reset DR6.
+
+Reported-by: rangemachine@gmail.com
+Reported-by: whanos@sergal.fun
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219787
+Closes: https://lore.kernel.org/all/bug-219787-28872@https.bugzilla.kernel.org%2F
+Cc: Ravi Bangoria <ravi.bangoria@amd.com>
+Cc: stable@vger.kernel.org
+Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
+Link: https://lore.kernel.org/r/20250227222411.3490595-5-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/svm.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/arch/x86/kvm/svm/svm.c
++++ b/arch/x86/kvm/svm/svm.c
+@@ -4277,6 +4277,16 @@ static __no_kcsan fastpath_t svm_vcpu_ru
+ clgi();
+ kvm_load_guest_xsave_state(vcpu);
+
++ /*
++ * Hardware only context switches DEBUGCTL if LBR virtualization is
++ * enabled. Manually load DEBUGCTL if necessary (and restore it after
++ * VM-Exit), as running with the host's DEBUGCTL can negatively affect
++ * guest state and can even be fatal, e.g. due to Bus Lock Detect.
++ */
++ if (!(svm->vmcb->control.virt_ext & LBR_CTL_ENABLE_MASK) &&
++ vcpu->arch.host_debugctl != svm->vmcb->save.dbgctl)
++ update_debugctlmsr(svm->vmcb->save.dbgctl);
++
+ kvm_wait_lapic_expire(vcpu);
+
+ /*
+@@ -4304,6 +4314,10 @@ static __no_kcsan fastpath_t svm_vcpu_ru
+ if (unlikely(svm->vmcb->control.exit_code == SVM_EXIT_NMI))
+ kvm_before_interrupt(vcpu, KVM_HANDLING_NMI);
+
++ if (!(svm->vmcb->control.virt_ext & LBR_CTL_ENABLE_MASK) &&
++ vcpu->arch.host_debugctl != svm->vmcb->save.dbgctl)
++ update_debugctlmsr(vcpu->arch.host_debugctl);
++
+ kvm_load_host_xsave_state(vcpu);
+ stgi();
+
--- /dev/null
+From b2653cd3b75f62f29b72df4070e20357acb52bc4 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Wed, 26 Feb 2025 17:25:32 -0800
+Subject: KVM: SVM: Save host DR masks on CPUs with DebugSwap
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit b2653cd3b75f62f29b72df4070e20357acb52bc4 upstream.
+
+When running SEV-SNP guests on a CPU that supports DebugSwap, always save
+the host's DR0..DR3 mask MSR values irrespective of whether or not
+DebugSwap is enabled, to ensure the host values aren't clobbered by the
+CPU. And for now, also save DR0..DR3, even though doing so isn't
+necessary (see below).
+
+SVM_VMGEXIT_AP_CREATE is deeply flawed in that it allows the *guest* to
+create a VMSA with guest-controlled SEV_FEATURES. A well behaved guest
+can inform the hypervisor, i.e. KVM, of its "requested" features, but on
+CPUs without ALLOWED_SEV_FEATURES support, nothing prevents the guest from
+lying about which SEV features are being enabled (or not!).
+
+If a misbehaving guest enables DebugSwap in a secondary vCPU's VMSA, the
+CPU will load the DR0..DR3 mask MSRs on #VMEXIT, i.e. will clobber the
+MSRs with '0' if KVM doesn't save its desired value.
+
+Note, DR0..DR3 themselves are "ok", as DR7 is reset on #VMEXIT, and KVM
+restores all DRs in common x86 code as needed via hw_breakpoint_restore().
+I.e. there is no risk of host DR0..DR3 being clobbered (when it matters).
+However, there is a flaw in the opposite direction; because the guest can
+lie about enabling DebugSwap, i.e. can *disable* DebugSwap without KVM's
+knowledge, KVM must not rely on the CPU to restore DRs. Defer fixing
+that wart, as it's more of a documentation issue than a bug in the code.
+
+Note, KVM added support for DebugSwap on commit d1f85fbe836e ("KVM: SEV:
+Enable data breakpoints in SEV-ES"), but that is not an appropriate Fixes,
+as the underlying flaw exists in hardware, not in KVM. I.e. all kernels
+that support SEV-SNP need to be patched, not just kernels with KVM's full
+support for DebugSwap (ignoring that DebugSwap support landed first).
+
+Opportunistically fix an incorrect statement in the comment; on CPUs
+without DebugSwap, the CPU does NOT save or load debug registers, i.e.
+
+Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event")
+Cc: stable@vger.kernel.org
+Cc: Naveen N Rao <naveen@kernel.org>
+Cc: Kim Phillips <kim.phillips@amd.com>
+Cc: Tom Lendacky <thomas.lendacky@amd.com>
+Cc: Alexey Kardashevskiy <aik@amd.com>
+Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
+Link: https://lore.kernel.org/r/20250227012541.3234589-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/sev.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kvm/svm/sev.c
++++ b/arch/x86/kvm/svm/sev.c
+@@ -4567,6 +4567,8 @@ void sev_es_vcpu_reset(struct vcpu_svm *
+
+ void sev_es_prepare_switch_to_guest(struct vcpu_svm *svm, struct sev_es_save_area *hostsa)
+ {
++ struct kvm *kvm = svm->vcpu.kvm;
++
+ /*
+ * All host state for SEV-ES guests is categorized into three swap types
+ * based on how it is handled by hardware during a world switch:
+@@ -4590,10 +4592,15 @@ void sev_es_prepare_switch_to_guest(stru
+
+ /*
+ * If DebugSwap is enabled, debug registers are loaded but NOT saved by
+- * the CPU (Type-B). If DebugSwap is disabled/unsupported, the CPU both
+- * saves and loads debug registers (Type-A).
++ * the CPU (Type-B). If DebugSwap is disabled/unsupported, the CPU does
++ * not save or load debug registers. Sadly, on CPUs without
++ * ALLOWED_SEV_FEATURES, KVM can't prevent SNP guests from enabling
++ * DebugSwap on secondary vCPUs without KVM's knowledge via "AP Create".
++ * Save all registers if DebugSwap is supported to prevent host state
++ * from being clobbered by a misbehaving guest.
+ */
+- if (sev_vcpu_has_debug_swap(svm)) {
++ if (sev_vcpu_has_debug_swap(svm) ||
++ (sev_snp_guest(kvm) && cpu_feature_enabled(X86_FEATURE_DEBUG_SWAP))) {
+ hostsa->dr0 = native_get_debugreg(0);
+ hostsa->dr1 = native_get_debugreg(1);
+ hostsa->dr2 = native_get_debugreg(2);
--- /dev/null
+From be45bc4eff33d9a7dae84a2150f242a91a617402 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Mon, 24 Feb 2025 08:54:41 -0800
+Subject: KVM: SVM: Set RFLAGS.IF=1 in C code, to get VMRUN out of the STI shadow
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit be45bc4eff33d9a7dae84a2150f242a91a617402 upstream.
+
+Enable/disable local IRQs, i.e. set/clear RFLAGS.IF, in the common
+svm_vcpu_enter_exit() just after/before guest_state_{enter,exit}_irqoff()
+so that VMRUN is not executed in an STI shadow. AMD CPUs have a quirk
+(some would say "bug"), where the STI shadow bleeds into the guest's
+intr_state field if a #VMEXIT occurs during injection of an event, i.e. if
+the VMRUN doesn't complete before the subsequent #VMEXIT.
+
+The spurious "interrupts masked" state is relatively benign, as it only
+occurs during event injection and is transient. Because KVM is already
+injecting an event, the guest can't be in HLT, and if KVM is querying IRQ
+blocking for injection, then KVM would need to force an immediate exit
+anyways since injecting multiple events is impossible.
+
+However, because KVM copies int_state verbatim from vmcb02 to vmcb12, the
+spurious STI shadow is visible to L1 when running a nested VM, which can
+trip sanity checks, e.g. in VMware's VMM.
+
+Hoist the STI+CLI all the way to C code, as the aforementioned calls to
+guest_state_{enter,exit}_irqoff() already inform lockdep that IRQs are
+enabled/disabled, and taking a fault on VMRUN with RFLAGS.IF=1 is already
+possible. I.e. if there's kernel code that is confused by running with
+RFLAGS.IF=1, then it's already a problem. In practice, since GIF=0 also
+blocks NMIs, the only change in exposure to non-KVM code (relative to
+surrounding VMRUN with STI+CLI) is exception handling code, and except for
+the kvm_rebooting=1 case, all exception in the core VM-Enter/VM-Exit path
+are fatal.
+
+Use the "raw" variants to enable/disable IRQs to avoid tracing in the
+"no instrumentation" code; the guest state helpers also take care of
+tracing IRQ state.
+
+Oppurtunstically document why KVM needs to do STI in the first place.
+
+Reported-by: Doug Covelli <doug.covelli@broadcom.com>
+Closes: https://lore.kernel.org/all/CADH9ctBs1YPmE4aCfGPNBwA10cA8RuAk2gO7542DjMZgs4uzJQ@mail.gmail.com
+Fixes: f14eec0a3203 ("KVM: SVM: move more vmentry code to assembly")
+Cc: stable@vger.kernel.org
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Link: https://lore.kernel.org/r/20250224165442.2338294-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/svm.c | 14 ++++++++++++++
+ arch/x86/kvm/svm/vmenter.S | 10 +---------
+ 2 files changed, 15 insertions(+), 9 deletions(-)
+
+--- a/arch/x86/kvm/svm/svm.c
++++ b/arch/x86/kvm/svm/svm.c
+@@ -4178,6 +4178,18 @@ static noinstr void svm_vcpu_enter_exit(
+
+ guest_state_enter_irqoff();
+
++ /*
++ * Set RFLAGS.IF prior to VMRUN, as the host's RFLAGS.IF at the time of
++ * VMRUN controls whether or not physical IRQs are masked (KVM always
++ * runs with V_INTR_MASKING_MASK). Toggle RFLAGS.IF here to avoid the
++ * temptation to do STI+VMRUN+CLI, as AMD CPUs bleed the STI shadow
++ * into guest state if delivery of an event during VMRUN triggers a
++ * #VMEXIT, and the guest_state transitions already tell lockdep that
++ * IRQs are being enabled/disabled. Note! GIF=0 for the entirety of
++ * this path, so IRQs aren't actually unmasked while running host code.
++ */
++ raw_local_irq_enable();
++
+ amd_clear_divider();
+
+ if (sev_es_guest(vcpu->kvm))
+@@ -4186,6 +4198,8 @@ static noinstr void svm_vcpu_enter_exit(
+ else
+ __svm_vcpu_run(svm, spec_ctrl_intercepted);
+
++ raw_local_irq_disable();
++
+ guest_state_exit_irqoff();
+ }
+
+--- a/arch/x86/kvm/svm/vmenter.S
++++ b/arch/x86/kvm/svm/vmenter.S
+@@ -170,12 +170,8 @@ SYM_FUNC_START(__svm_vcpu_run)
+ mov VCPU_RDI(%_ASM_DI), %_ASM_DI
+
+ /* Enter guest mode */
+- sti
+-
+ 3: vmrun %_ASM_AX
+ 4:
+- cli
+-
+ /* Pop @svm to RAX while it's the only available register. */
+ pop %_ASM_AX
+
+@@ -340,12 +336,8 @@ SYM_FUNC_START(__svm_sev_es_vcpu_run)
+ mov KVM_VMCB_pa(%rax), %rax
+
+ /* Enter guest mode */
+- sti
+-
+ 1: vmrun %rax
+-
+-2: cli
+-
++2:
+ /* IMPORTANT: Stuff the RSB immediately after VM-Exit, before RET! */
+ FILL_RETURN_BUFFER %rax, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_VMEXIT
+
--- /dev/null
+From d0eac42f5cecce009d315655bee341304fbe075e Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 27 Feb 2025 14:24:07 -0800
+Subject: KVM: SVM: Suppress DEBUGCTL.BTF on AMD
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit d0eac42f5cecce009d315655bee341304fbe075e upstream.
+
+Mark BTF as reserved in DEBUGCTL on AMD, as KVM doesn't actually support
+BTF, and fully enabling BTF virtualization is non-trivial due to
+interactions with the emulator, guest_debug, #DB interception, nested SVM,
+etc.
+
+Don't inject #GP if the guest attempts to set BTF, as there's no way to
+communicate lack of support to the guest, and instead suppress the flag
+and treat the WRMSR as (partially) unsupported.
+
+In short, make KVM behave the same on AMD and Intel (VMX already squashes
+BTF).
+
+Note, due to other bugs in KVM's handling of DEBUGCTL, the only way BTF
+has "worked" in any capacity is if the guest simultaneously enables LBRs.
+
+Reported-by: Ravi Bangoria <ravi.bangoria@amd.com>
+Cc: stable@vger.kernel.org
+Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
+Link: https://lore.kernel.org/r/20250227222411.3490595-3-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/svm.c | 9 +++++++++
+ arch/x86/kvm/svm/svm.h | 2 +-
+ 2 files changed, 10 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/svm/svm.c
++++ b/arch/x86/kvm/svm/svm.c
+@@ -3181,6 +3181,15 @@ static int svm_set_msr(struct kvm_vcpu *
+ */
+ data &= ~GENMASK(5, 2);
+
++ /*
++ * Suppress BTF as KVM doesn't virtualize BTF, but there's no
++ * way to communicate lack of support to the guest.
++ */
++ if (data & DEBUGCTLMSR_BTF) {
++ kvm_pr_unimpl_wrmsr(vcpu, MSR_IA32_DEBUGCTLMSR, data);
++ data &= ~DEBUGCTLMSR_BTF;
++ }
++
+ if (data & DEBUGCTL_RESERVED_BITS)
+ return 1;
+
+--- a/arch/x86/kvm/svm/svm.h
++++ b/arch/x86/kvm/svm/svm.h
+@@ -591,7 +591,7 @@ static inline bool is_vnmi_enabled(struc
+ /* svm.c */
+ #define MSR_INVALID 0xffffffffU
+
+-#define DEBUGCTL_RESERVED_BITS (~(DEBUGCTLMSR_BTF | DEBUGCTLMSR_LBR))
++#define DEBUGCTL_RESERVED_BITS (~DEBUGCTLMSR_LBR)
+
+ extern bool dump_invalid_vmcb;
+
--- /dev/null
+From f9dc8fb3afc968042bdaf4b6e445a9272071c9f3 Mon Sep 17 00:00:00 2001
+From: Xiaoyao Li <xiaoyao.li@intel.com>
+Date: Tue, 4 Mar 2025 03:23:14 -0500
+Subject: KVM: x86: Explicitly zero EAX and EBX when PERFMON_V2 isn't supported by KVM
+
+From: Xiaoyao Li <xiaoyao.li@intel.com>
+
+commit f9dc8fb3afc968042bdaf4b6e445a9272071c9f3 upstream.
+
+Fix a goof where KVM sets CPUID.0x80000022.EAX to CPUID.0x80000022.EBX
+instead of zeroing both when PERFMON_V2 isn't supported by KVM. In
+practice, barring a buggy CPU (or vCPU model when running nested) only the
+!enable_pmu case is affected, as KVM always supports PERFMON_V2 if it's
+available in hardware, i.e. CPUID.0x80000022.EBX will be '0' if PERFMON_V2
+is unsupported.
+
+For the !enable_pmu case, the bug is relatively benign as KVM will refuse
+to enable PMU capabilities, but a VMM that reflects KVM's supported CPUID
+into the guest could inadvertently induce #GPs in the guest due to
+advertising support for MSRs that KVM refuses to emulate.
+
+Fixes: 94cdeebd8211 ("KVM: x86/cpuid: Add AMD CPUID ExtPerfMonAndDbg leaf 0x80000022")
+Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
+Link: https://lore.kernel.org/r/20250304082314.472202-3-xiaoyao.li@intel.com
+[sean: massage shortlog and changelog, tag for stable]
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/cpuid.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/cpuid.c
++++ b/arch/x86/kvm/cpuid.c
+@@ -1393,7 +1393,7 @@ static inline int __do_cpuid_func(struct
+
+ entry->ecx = entry->edx = 0;
+ if (!enable_pmu || !kvm_cpu_cap_has(X86_FEATURE_PERFMON_V2)) {
+- entry->eax = entry->ebx;
++ entry->eax = entry->ebx = 0;
+ break;
+ }
+
--- /dev/null
+From 189ecdb3e112da703ac0699f4ec76aa78122f911 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 27 Feb 2025 14:24:10 -0800
+Subject: KVM: x86: Snapshot the host's DEBUGCTL after disabling IRQs
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 189ecdb3e112da703ac0699f4ec76aa78122f911 upstream.
+
+Snapshot the host's DEBUGCTL after disabling IRQs, as perf can toggle
+debugctl bits from IRQ context, e.g. when enabling/disabling events via
+smp_call_function_single(). Taking the snapshot (long) before IRQs are
+disabled could result in KVM effectively clobbering DEBUGCTL due to using
+a stale snapshot.
+
+Cc: stable@vger.kernel.org
+Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
+Link: https://lore.kernel.org/r/20250227222411.3490595-6-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/x86.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -4976,7 +4976,6 @@ void kvm_arch_vcpu_load(struct kvm_vcpu
+
+ /* Save host pkru register if supported */
+ vcpu->arch.host_pkru = read_pkru();
+- vcpu->arch.host_debugctl = get_debugctlmsr();
+
+ /* Apply any externally detected TSC adjustments (due to suspend) */
+ if (unlikely(vcpu->arch.tsc_offset_adjustment)) {
+@@ -10961,6 +10960,8 @@ static int vcpu_enter_guest(struct kvm_v
+ set_debugreg(0, 7);
+ }
+
++ vcpu->arch.host_debugctl = get_debugctlmsr();
++
+ guest_timing_enter_irqoff();
+
+ for (;;) {
--- /dev/null
+From fb71c795935652fa20eaf9517ca9547f5af99a76 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 27 Feb 2025 14:24:08 -0800
+Subject: KVM: x86: Snapshot the host's DEBUGCTL in common x86
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit fb71c795935652fa20eaf9517ca9547f5af99a76 upstream.
+
+Move KVM's snapshot of DEBUGCTL to kvm_vcpu_arch and take the snapshot in
+common x86, so that SVM can also use the snapshot.
+
+Opportunistically change the field to a u64. While bits 63:32 are reserved
+on AMD, not mentioned at all in Intel's SDM, and managed as an "unsigned
+long" by the kernel, DEBUGCTL is an MSR and therefore a 64-bit value.
+
+Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
+Cc: stable@vger.kernel.org
+Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
+Link: https://lore.kernel.org/r/20250227222411.3490595-4-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/kvm_host.h | 1 +
+ arch/x86/kvm/vmx/vmx.c | 8 ++------
+ arch/x86/kvm/vmx/vmx.h | 2 --
+ arch/x86/kvm/x86.c | 1 +
+ 4 files changed, 4 insertions(+), 8 deletions(-)
+
+--- a/arch/x86/include/asm/kvm_host.h
++++ b/arch/x86/include/asm/kvm_host.h
+@@ -761,6 +761,7 @@ struct kvm_vcpu_arch {
+ u32 pkru;
+ u32 hflags;
+ u64 efer;
++ u64 host_debugctl;
+ u64 apic_base;
+ struct kvm_lapic *apic; /* kernel irqchip context */
+ bool load_eoi_exitmap_pending;
+--- a/arch/x86/kvm/vmx/vmx.c
++++ b/arch/x86/kvm/vmx/vmx.c
+@@ -1514,16 +1514,12 @@ void vmx_vcpu_load_vmcs(struct kvm_vcpu
+ */
+ void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
+ {
+- struct vcpu_vmx *vmx = to_vmx(vcpu);
+-
+ if (vcpu->scheduled_out && !kvm_pause_in_guest(vcpu->kvm))
+ shrink_ple_window(vcpu);
+
+ vmx_vcpu_load_vmcs(vcpu, cpu, NULL);
+
+ vmx_vcpu_pi_load(vcpu, cpu);
+-
+- vmx->host_debugctlmsr = get_debugctlmsr();
+ }
+
+ void vmx_vcpu_put(struct kvm_vcpu *vcpu)
+@@ -7469,8 +7465,8 @@ fastpath_t vmx_vcpu_run(struct kvm_vcpu
+ }
+
+ /* MSR_IA32_DEBUGCTLMSR is zeroed on vmexit. Restore it if needed */
+- if (vmx->host_debugctlmsr)
+- update_debugctlmsr(vmx->host_debugctlmsr);
++ if (vcpu->arch.host_debugctl)
++ update_debugctlmsr(vcpu->arch.host_debugctl);
+
+ #ifndef CONFIG_X86_64
+ /*
+--- a/arch/x86/kvm/vmx/vmx.h
++++ b/arch/x86/kvm/vmx/vmx.h
+@@ -337,8 +337,6 @@ struct vcpu_vmx {
+ /* apic deadline value in host tsc */
+ u64 hv_deadline_tsc;
+
+- unsigned long host_debugctlmsr;
+-
+ /*
+ * Only bits masked by msr_ia32_feature_control_valid_bits can be set in
+ * msr_ia32_feature_control. FEAT_CTL_LOCKED is always included
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -4976,6 +4976,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu
+
+ /* Save host pkru register if supported */
+ vcpu->arch.host_pkru = read_pkru();
++ vcpu->arch.host_debugctl = get_debugctlmsr();
+
+ /* Apply any externally detected TSC adjustments (due to suspend) */
+ if (unlikely(vcpu->arch.tsc_offset_adjustment)) {
--- /dev/null
+From a8e8ffcc3afce2ee5fb70162aeaef3f03573ee1e Mon Sep 17 00:00:00 2001
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+Date: Sun, 9 Feb 2025 13:05:50 +0200
+Subject: mei: me: add panther lake P DID
+
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+
+commit a8e8ffcc3afce2ee5fb70162aeaef3f03573ee1e upstream.
+
+Add Panther Lake P device id.
+
+Cc: stable <stable@kernel.org>
+Co-developed-by: Tomas Winkler <tomasw@gmail.com>
+Signed-off-by: Tomas Winkler <tomasw@gmail.com>
+Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
+Link: https://lore.kernel.org/r/20250209110550.1582982-1-alexander.usyskin@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/mei/hw-me-regs.h | 2 ++
+ drivers/misc/mei/pci-me.c | 2 ++
+ 2 files changed, 4 insertions(+)
+
+--- a/drivers/misc/mei/hw-me-regs.h
++++ b/drivers/misc/mei/hw-me-regs.h
+@@ -117,6 +117,8 @@
+
+ #define MEI_DEV_ID_LNL_M 0xA870 /* Lunar Lake Point M */
+
++#define MEI_DEV_ID_PTL_P 0xE470 /* Panther Lake P */
++
+ /*
+ * MEI HW Section
+ */
+--- a/drivers/misc/mei/pci-me.c
++++ b/drivers/misc/mei/pci-me.c
+@@ -124,6 +124,8 @@ static const struct pci_device_id mei_me
+
+ {MEI_PCI_DEVICE(MEI_DEV_ID_LNL_M, MEI_ME_PCH15_CFG)},
+
++ {MEI_PCI_DEVICE(MEI_DEV_ID_PTL_P, MEI_ME_PCH15_CFG)},
++
+ /* required last entry */
+ {0, }
+ };
--- /dev/null
+From fdb1ada57cf8b8752cdf54f08709d76d74999544 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Fri, 14 Feb 2025 22:24:25 +0100
+Subject: mei: vsc: Use "wakeuphostint" when getting the host wakeup GPIO
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit fdb1ada57cf8b8752cdf54f08709d76d74999544 upstream.
+
+The _CRS ACPI resources table has 2 entries for the host wakeup GPIO,
+the first one being a regular GpioIo () resource while the second one
+is a GpioInt () resource for the same pin.
+
+The acpi_gpio_mapping table used by vsc-tp.c maps the first Gpio ()
+resource to "wakeuphost-gpios" where as the second GpioInt () entry
+is mapped to "wakeuphostint-gpios".
+
+Using "wakeuphost" to request the GPIO as was done until now, means
+that the gpiolib-acpi code does not know that the GPIO is active-low
+as that info is only available in the GpioInt () entry.
+
+Things were still working before due to the following happening:
+
+1. Since the 2 entries point to the same pin they share a struct gpio_desc
+2. The SPI core creates the SPI device vsc-tp.c binds to and calls
+ acpi_dev_gpio_irq_get(). This does use the second entry and sets
+ FLAG_ACTIVE_LOW in gpio_desc.flags .
+3. vsc_tp_probe() requests the "wakeuphost" GPIO and inherits the
+ active-low flag set by acpi_dev_gpio_irq_get()
+
+But there is a possible scenario where things do not work:
+
+1. - 3. happen as above
+4. After requesting the "wakeuphost" GPIO, the "resetfw" GPIO is requested
+ next, but its USB GPIO controller is not available yet, so this call
+ returns -EPROBE_DEFER.
+5. The gpio_desc for "wakeuphost" is put() and during this the active-low
+ flag is cleared from gpio_desc.flags .
+6. Later on vsc_tp_probe() requests the "wakeuphost" GPIO again, but now it
+ is not marked active-low.
+
+The difference can also be seen in /sys/kernel/debug/gpio, which contains
+the following line for this GPIO:
+
+ gpio-535 ( |wakeuphost ) in hi IRQ ACTIVE LOW
+
+If the second scenario is hit the "ACTIVE LOW" at the end disappears and
+things do not work.
+
+Fix this by requesting the GPIO through the "wakeuphostint" mapping instead
+which provides active-low info without relying on acpi_dev_gpio_irq_get()
+pre-populating this info in the gpio_desc.
+
+Link: https://bugzilla.redhat.com/show_bug.cgi?id=2316918
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
+Tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
+Cc: stable <stable@kernel.org>
+Link: https://lore.kernel.org/r/20250214212425.84021-1-hdegoede@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/mei/vsc-tp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/misc/mei/vsc-tp.c
++++ b/drivers/misc/mei/vsc-tp.c
+@@ -502,7 +502,7 @@ static int vsc_tp_probe(struct spi_devic
+ if (ret)
+ return ret;
+
+- tp->wakeuphost = devm_gpiod_get(dev, "wakeuphost", GPIOD_IN);
++ tp->wakeuphost = devm_gpiod_get(dev, "wakeuphostint", GPIOD_IN);
+ if (IS_ERR(tp->wakeuphost))
+ return PTR_ERR(tp->wakeuphost);
+
usb-gadget-check-bmattributes-only-if-configuration-is-valid.patch
kbuild-userprogs-use-correct-lld-when-linking-through-clang.patch
acpi-typec-ucsi-introduce-a-poll_cci-method.patch
+kvm-svm-set-rflags.if-1-in-c-code-to-get-vmrun-out-of-the-sti-shadow.patch
+kvm-svm-save-host-dr-masks-on-cpus-with-debugswap.patch
+kvm-svm-drop-debugctl-from-guest-s-effective-value.patch
+kvm-svm-suppress-debugctl.btf-on-amd.patch
+kvm-x86-snapshot-the-host-s-debugctl-in-common-x86.patch
+kvm-svm-manually-context-switch-debugctl-if-lbr-virtualization-is-disabled.patch
+kvm-x86-snapshot-the-host-s-debugctl-after-disabling-irqs.patch
+kvm-x86-explicitly-zero-eax-and-ebx-when-perfmon_v2-isn-t-supported-by-kvm.patch
+cdx-fix-possible-uaf-error-in-driver_override_show.patch
+mei-me-add-panther-lake-p-did.patch
+mei-vsc-use-wakeuphostint-when-getting-the-host-wakeup-gpio.patch
+intel_th-pci-add-arrow-lake-support.patch
+intel_th-pci-add-panther-lake-h-support.patch
+intel_th-pci-add-panther-lake-p-u-support.patch
+char-misc-deallocate-static-minor-in-error-path.patch
+drivers-core-fix-device-leak-in-__fw_devlink_relax_cycles.patch
+slimbus-messaging-free-transaction-id-in-delayed-interrupt-scenario.patch
+bus-mhi-host-pci_generic-use-pci_try_reset_function-to-avoid-deadlock.patch
+eeprom-digsy_mtc-make-gpio-lookup-table-match-the-device.patch
+drivers-virt-acrn-hsm-use-kzalloc-to-avoid-info-leak-in-pmcmd_ioctl.patch
+iio-filter-admv8818-force-initialization-of-sdo.patch
+iio-light-apds9306-fix-max_scale_nano-values.patch
+iio-dac-ad3552r-clear-reset-status-flag.patch
+iio-adc-ad7192-fix-channel-select.patch
+iio-adc-at91-sama5d2_adc-fix-sama7g5-realbits-value.patch
--- /dev/null
+From dcb0d43ba8eb9517e70b1a0e4b0ae0ab657a0e5a Mon Sep 17 00:00:00 2001
+From: Visweswara Tanuku <quic_vtanuku@quicinc.com>
+Date: Fri, 24 Jan 2025 04:57:40 -0800
+Subject: slimbus: messaging: Free transaction ID in delayed interrupt scenario
+
+From: Visweswara Tanuku <quic_vtanuku@quicinc.com>
+
+commit dcb0d43ba8eb9517e70b1a0e4b0ae0ab657a0e5a upstream.
+
+In case of interrupt delay for any reason, slim_do_transfer()
+returns timeout error but the transaction ID (TID) is not freed.
+This results into invalid memory access inside
+qcom_slim_ngd_rx_msgq_cb() due to invalid TID.
+
+Fix the issue by freeing the TID in slim_do_transfer() before
+returning timeout error to avoid invalid memory access.
+
+Call trace:
+__memcpy_fromio+0x20/0x190
+qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]
+vchan_complete+0x2a0/0x4a0
+tasklet_action_common+0x274/0x700
+tasklet_action+0x28/0x3c
+_stext+0x188/0x620
+run_ksoftirqd+0x34/0x74
+smpboot_thread_fn+0x1d8/0x464
+kthread+0x178/0x238
+ret_from_fork+0x10/0x20
+Code: aa0003e8 91000429 f100044a 3940002b (3800150b)
+---[ end trace 0fe00bec2b975c99 ]---
+Kernel panic - not syncing: Oops: Fatal exception in interrupt.
+
+Fixes: afbdcc7c384b ("slimbus: Add messaging APIs to slimbus framework")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Visweswara Tanuku <quic_vtanuku@quicinc.com>
+Link: https://lore.kernel.org/r/20250124125740.16897-1-quic_vtanuku@quicinc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/slimbus/messaging.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/slimbus/messaging.c
++++ b/drivers/slimbus/messaging.c
+@@ -148,8 +148,9 @@ int slim_do_transfer(struct slim_control
+ }
+
+ ret = ctrl->xfer_msg(ctrl, txn);
+-
+- if (!ret && need_tid && !txn->msg->comp) {
++ if (ret == -ETIMEDOUT) {
++ slim_free_txn_tid(ctrl, txn);
++ } else if (!ret && need_tid && !txn->msg->comp) {
+ unsigned long ms = txn->rl + HZ;
+
+ time_left = wait_for_completion_timeout(txn->comp,
projects / thirdparty / kernel / stable-queue.git / commitdiff
