--- /dev/null
+From c40ca9ef7c5c9bbb0d2f7774c87417cc4f1713bf Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Wed, 22 Jan 2025 10:02:03 +0100
+Subject: drm: select DRM_KMS_HELPER from DRM_GEM_SHMEM_HELPER
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit c40ca9ef7c5c9bbb0d2f7774c87417cc4f1713bf upstream.
+
+In the combination of DRM_KMS_HELPER=m, DRM_GEM_SHMEM_HELPER=y, DRM_FBDEV_EMULATION=y,
+The shmem code fails to link against the KMS helpers:
+
+x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_driver_fbdev_probe':
+(.text+0xeec601): undefined reference to `drm_fb_helper_alloc_info'
+x86_64-linux-ld: (.text+0xeec633): undefined reference to `drm_fb_helper_fill_info'
+x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_get_page':
+drm_fbdev_shmem.c:(.text+0xeec7d2): undefined reference to `drm_gem_fb_get_obj'
+x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_fb_mmap':
+drm_fbdev_shmem.c:(.text+0xeec9f6): undefined reference to `drm_gem_fb_get_obj'
+x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_defio_imageblit':
+(.rodata+0x5b2288): undefined reference to `drm_fb_helper_check_var'
+x86_64-linux-ld: (.rodata+0x5b2290): undefined reference to `drm_fb_helper_set_par'
+
+This can happen for a number of device drivers that select DRM_GEM_SHMEM_HELPER
+without also selecting DRM_KMS_HELPER. To work around this, add another select
+that forces DRM_KMS_HELPER to be built-in rather than a loadable module, but
+only if FBDEV emulation is also enabled. DRM_TTM_HELPER and DRM_GEM_DMA_HELPER
+look like they have the same problem in theory even if there is no possible
+configuration that shows it. For consistency, do the same change to those.
+
+Closes: https://lore.kernel.org/all/20250121-greedy-flounder-of-abundance-4d2ee8-mkl@pengutronix.de
+Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20250122090211.3161186-1-arnd@kernel.org
+Cc: NoisyCoil <noisycoil@disroot.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/Kconfig | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/Kconfig
++++ b/drivers/gpu/drm/Kconfig
+@@ -359,6 +359,7 @@ config DRM_TTM_HELPER
+ tristate
+ depends on DRM
+ select DRM_TTM
++ select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
+ select FB_CORE if DRM_FBDEV_EMULATION
+ select FB_SYSMEM_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
+ help
+@@ -367,6 +368,7 @@ config DRM_TTM_HELPER
+ config DRM_GEM_DMA_HELPER
+ tristate
+ depends on DRM
++ select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
+ select FB_CORE if DRM_FBDEV_EMULATION
+ select FB_DMAMEM_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
+ help
+@@ -375,6 +377,7 @@ config DRM_GEM_DMA_HELPER
+ config DRM_GEM_SHMEM_HELPER
+ tristate
+ depends on DRM && MMU
++ select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
+ select FB_CORE if DRM_FBDEV_EMULATION
+ select FB_SYSMEM_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
+ help
--- /dev/null
+From 488fb6effe03e20f38d34da7425de77bbd3e2665 Mon Sep 17 00:00:00 2001
+From: Kory Maincent <kory.maincent@bootlin.com>
+Date: Wed, 12 Feb 2025 16:17:51 +0100
+Subject: net: pse-pd: Fix deadlock in current limit functions
+
+From: Kory Maincent <kory.maincent@bootlin.com>
+
+commit 488fb6effe03e20f38d34da7425de77bbd3e2665 upstream.
+
+Fix a deadlock in pse_pi_get_current_limit and pse_pi_set_current_limit
+caused by consecutive mutex_lock calls. One in the function itself and
+another in pse_pi_get_voltage.
+
+Resolve the issue by using the unlocked version of pse_pi_get_voltage
+instead.
+
+Fixes: e0a5e2bba38a ("net: pse-pd: Use power limit at driver side instead of current limit")
+Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
+Link: https://patch.msgid.link/20250212151751.1515008-1-kory.maincent@bootlin.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/pse-pd/pse_core.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/pse-pd/pse_core.c
++++ b/drivers/net/pse-pd/pse_core.c
+@@ -309,7 +309,7 @@ static int pse_pi_get_current_limit(stru
+ goto out;
+ mW = ret;
+
+- ret = pse_pi_get_voltage(rdev);
++ ret = _pse_pi_get_voltage(rdev);
+ if (!ret) {
+ dev_err(pcdev->dev, "Voltage null\n");
+ ret = -ERANGE;
+@@ -346,7 +346,7 @@ static int pse_pi_set_current_limit(stru
+
+ id = rdev_get_id(rdev);
+ mutex_lock(&pcdev->lock);
+- ret = pse_pi_get_voltage(rdev);
++ ret = _pse_pi_get_voltage(rdev);
+ if (!ret) {
+ dev_err(pcdev->dev, "Voltage null\n");
+ ret = -ERANGE;
--- /dev/null
+From 22bec11a569983f39c6061cb82279e7de9e3bdfc Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Mon, 6 Jan 2025 11:11:43 -0500
+Subject: tracing: Fix using ret variable in tracing_set_tracer()
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit 22bec11a569983f39c6061cb82279e7de9e3bdfc upstream.
+
+When the function tracing_set_tracer() switched over to using the guard()
+infrastructure, it did not need to save the 'ret' variable and would just
+return the value when an error arised, instead of setting ret and jumping
+to an out label.
+
+When CONFIG_TRACER_SNAPSHOT is enabled, it had code that expected the
+"ret" variable to be initialized to zero and had set 'ret' while holding
+an arch_spin_lock() (not used by guard), and then upon releasing the lock
+it would check 'ret' and exit if set. But because ret was only set when an
+error occurred while holding the locks, 'ret' would be used uninitialized
+if there was no error. The code in the CONFIG_TRACER_SNAPSHOT block should
+be self contain. Make sure 'ret' is also set when no error occurred.
+
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Link: https://lore.kernel.org/20250106111143.2f90ff65@gandalf.local.home
+Reported-by: kernel test robot <lkp@intel.com>
+Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
+Closes: https://lore.kernel.org/r/202412271654.nJVBuwmF-lkp@intel.com/
+Fixes: d33b10c0c73ad ("tracing: Switch trace.c code over to use guard()")
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -6102,8 +6102,7 @@ int tracing_set_tracer(struct trace_arra
+ if (t->use_max_tr) {
+ local_irq_disable();
+ arch_spin_lock(&tr->max_lock);
+- if (tr->cond_snapshot)
+- ret = -EBUSY;
++ ret = tr->cond_snapshot ? -EBUSY : 0;
+ arch_spin_unlock(&tr->max_lock);
+ local_irq_enable();
+ if (ret)