--- /dev/null
+From 6061806a863e8b65b109eb06a280041cc7525442 Mon Sep 17 00:00:00 2001
+From: Christoph Niedermaier <cniedermaier@dh-electronics.com>
+Date: Tue, 1 Feb 2022 12:36:43 +0100
+Subject: drm/imx: parallel-display: Remove bus flags check in imx_pd_bridge_atomic_check()
+
+From: Christoph Niedermaier <cniedermaier@dh-electronics.com>
+
+commit 6061806a863e8b65b109eb06a280041cc7525442 upstream.
+
+If display timings were read from the devicetree using
+of_get_display_timing() and pixelclk-active is defined
+there, the flag DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE is
+automatically generated. Through the function
+drm_bus_flags_from_videomode() e.g. called in the
+panel-simple driver this flag got into the bus flags,
+but then in imx_pd_bridge_atomic_check() the bus flag
+check failed and will not initialize the display. The
+original commit fe141cedc433 does not explain why this
+check was introduced. So remove the bus flags check,
+because it stops the initialization of the display with
+valid bus flags.
+
+Fixes: fe141cedc433 ("drm/imx: pd: Use bus format/flags provided by the bridge when available")
+Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
+Cc: Marek Vasut <marex@denx.de>
+Cc: Boris Brezillon <boris.brezillon@collabora.com>
+Cc: Philipp Zabel <p.zabel@pengutronix.de>
+Cc: David Airlie <airlied@linux.ie>
+Cc: Daniel Vetter <daniel@ffwll.ch>
+Cc: Shawn Guo <shawnguo@kernel.org>
+Cc: Sascha Hauer <s.hauer@pengutronix.de>
+Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
+Cc: Fabio Estevam <festevam@gmail.com>
+Cc: NXP Linux Team <linux-imx@nxp.com>
+Cc: linux-arm-kernel@lists.infradead.org
+To: dri-devel@lists.freedesktop.org
+Tested-by: Max Krummenacher <max.krummenacher@toradex.com>
+Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
+Signed-off-by: Marek Vasut <marex@denx.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220201113643.4638-1-cniedermaier@dh-electronics.com
+Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/imx/parallel-display.c | 8 --------
+ 1 file changed, 8 deletions(-)
+
+--- a/drivers/gpu/drm/imx/parallel-display.c
++++ b/drivers/gpu/drm/imx/parallel-display.c
+@@ -235,14 +235,6 @@ static int imx_pd_bridge_atomic_check(st
+ if (!imx_pd_format_supported(bus_fmt))
+ return -EINVAL;
+
+- if (bus_flags &
+- ~(DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_DE_HIGH |
+- DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
+- DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)) {
+- dev_warn(imxpd->dev, "invalid bus_flags (%x)\n", bus_flags);
+- return -EINVAL;
+- }
+-
+ bridge_state->output_bus_cfg.flags = bus_flags;
+ bridge_state->input_bus_cfg.flags = bus_flags;
+ imx_crtc_state->bus_flags = bus_flags;
usb-dwc2-gadget-lpm-flow-fix.patch
usb-udc-remove-warning-when-queue-disabled-ep.patch
scsi-qla2xxx-fix-command-flush-on-cable-pull.patch
+x86-cpu-enable-stibp-on-amd-if-automatic-ibrs-is-enabled.patch
+timers-move-clearing-of-base-timer_running-under-base-lock.patch
+drm-imx-parallel-display-remove-bus-flags-check-in-imx_pd_bridge_atomic_check.patch
--- /dev/null
+From bb7262b295472eb6858b5c49893954794027cd84 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Sun, 6 Dec 2020 22:40:07 +0100
+Subject: timers: Move clearing of base::timer_running under base:: Lock
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit bb7262b295472eb6858b5c49893954794027cd84 upstream.
+
+syzbot reported KCSAN data races vs. timer_base::timer_running being set to
+NULL without holding base::lock in expire_timers().
+
+This looks innocent and most reads are clearly not problematic, but
+Frederic identified an issue which is:
+
+ int data = 0;
+
+ void timer_func(struct timer_list *t)
+ {
+ data = 1;
+ }
+
+ CPU 0 CPU 1
+ ------------------------------ --------------------------
+ base = lock_timer_base(timer, &flags); raw_spin_unlock(&base->lock);
+ if (base->running_timer != timer) call_timer_fn(timer, fn, baseclk);
+ ret = detach_if_pending(timer, base, true); base->running_timer = NULL;
+ raw_spin_unlock_irqrestore(&base->lock, flags); raw_spin_lock(&base->lock);
+
+ x = data;
+
+If the timer has previously executed on CPU 1 and then CPU 0 can observe
+base->running_timer == NULL and returns, assuming the timer has completed,
+but it's not guaranteed on all architectures. The comment for
+del_timer_sync() makes that guarantee. Moving the assignment under
+base->lock prevents this.
+
+For non-RT kernel it's performance wise completely irrelevant whether the
+store happens before or after taking the lock. For an RT kernel moving the
+store under the lock requires an extra unlock/lock pair in the case that
+there is a waiter for the timer, but that's not the end of the world.
+
+Reported-by: syzbot+aa7c2385d46c5eba0b89@syzkaller.appspotmail.com
+Reported-by: syzbot+abea4558531bae1ba9fe@syzkaller.appspotmail.com
+Fixes: 030dcdd197d7 ("timers: Prepare support for PREEMPT_RT")
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Link: https://lore.kernel.org/r/87lfea7gw8.fsf@nanos.tec.linutronix.de
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/time/timer.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/kernel/time/timer.c
++++ b/kernel/time/timer.c
+@@ -1304,8 +1304,10 @@ static inline void timer_base_unlock_exp
+ static void timer_sync_wait_running(struct timer_base *base)
+ {
+ if (atomic_read(&base->timer_waiters)) {
++ raw_spin_unlock_irq(&base->lock);
+ spin_unlock(&base->expiry_lock);
+ spin_lock(&base->expiry_lock);
++ raw_spin_lock_irq(&base->lock);
+ }
+ }
+
+@@ -1490,14 +1492,14 @@ static void expire_timers(struct timer_b
+ if (timer->flags & TIMER_IRQSAFE) {
+ raw_spin_unlock(&base->lock);
+ call_timer_fn(timer, fn, baseclk);
+- base->running_timer = NULL;
+ raw_spin_lock(&base->lock);
++ base->running_timer = NULL;
+ } else {
+ raw_spin_unlock_irq(&base->lock);
+ call_timer_fn(timer, fn, baseclk);
++ raw_spin_lock_irq(&base->lock);
+ base->running_timer = NULL;
+ timer_sync_wait_running(base);
+- raw_spin_lock_irq(&base->lock);
+ }
+ }
+ }
--- /dev/null
+From fd470a8beed88440b160d690344fbae05a0b9b1b Mon Sep 17 00:00:00 2001
+From: Kim Phillips <kim.phillips@amd.com>
+Date: Thu, 20 Jul 2023 14:47:27 -0500
+Subject: x86/cpu: Enable STIBP on AMD if Automatic IBRS is enabled
+
+From: Kim Phillips <kim.phillips@amd.com>
+
+commit fd470a8beed88440b160d690344fbae05a0b9b1b upstream.
+
+Unlike Intel's Enhanced IBRS feature, AMD's Automatic IBRS does not
+provide protection to processes running at CPL3/user mode, see section
+"Extended Feature Enable Register (EFER)" in the APM v2 at
+https://bugzilla.kernel.org/attachment.cgi?id=304652
+
+Explicitly enable STIBP to protect against cross-thread CPL3
+branch target injections on systems with Automatic IBRS enabled.
+
+Also update the relevant documentation.
+
+Fixes: e7862eda309e ("x86/cpu: Support AMD Automatic IBRS")
+Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Kim Phillips <kim.phillips@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230720194727.67022-1-kim.phillips@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/admin-guide/hw-vuln/spectre.rst | 11 +++++++----
+ arch/x86/kernel/cpu/bugs.c | 15 +++++++++------
+ 2 files changed, 16 insertions(+), 10 deletions(-)
+
+--- a/Documentation/admin-guide/hw-vuln/spectre.rst
++++ b/Documentation/admin-guide/hw-vuln/spectre.rst
+@@ -484,11 +484,14 @@ Spectre variant 2
+
+ Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at
+ boot, by setting the IBRS bit, and they're automatically protected against
+- Spectre v2 variant attacks, including cross-thread branch target injections
+- on SMT systems (STIBP). In other words, eIBRS enables STIBP too.
++ Spectre v2 variant attacks.
+
+- Legacy IBRS systems clear the IBRS bit on exit to userspace and
+- therefore explicitly enable STIBP for that
++ On Intel's enhanced IBRS systems, this includes cross-thread branch target
++ injections on SMT systems (STIBP). In other words, Intel eIBRS enables
++ STIBP, too.
++
++ AMD Automatic IBRS does not protect userspace, and Legacy IBRS systems clear
++ the IBRS bit on exit to userspace, therefore both explicitly enable STIBP.
+
+ The retpoline mitigation is turned on by default on vulnerable
+ CPUs. It can be forced on or off by the administrator
+--- a/arch/x86/kernel/cpu/bugs.c
++++ b/arch/x86/kernel/cpu/bugs.c
+@@ -1153,19 +1153,21 @@ spectre_v2_user_select_mitigation(void)
+ }
+
+ /*
+- * If no STIBP, enhanced IBRS is enabled, or SMT impossible, STIBP
++ * If no STIBP, Intel enhanced IBRS is enabled, or SMT impossible, STIBP
+ * is not required.
+ *
+- * Enhanced IBRS also protects against cross-thread branch target
++ * Intel's Enhanced IBRS also protects against cross-thread branch target
+ * injection in user-mode as the IBRS bit remains always set which
+ * implicitly enables cross-thread protections. However, in legacy IBRS
+ * mode, the IBRS bit is set only on kernel entry and cleared on return
+- * to userspace. This disables the implicit cross-thread protection,
+- * so allow for STIBP to be selected in that case.
++ * to userspace. AMD Automatic IBRS also does not protect userspace.
++ * These modes therefore disable the implicit cross-thread protection,
++ * so allow for STIBP to be selected in those cases.
+ */
+ if (!boot_cpu_has(X86_FEATURE_STIBP) ||
+ !smt_possible ||
+- spectre_v2_in_eibrs_mode(spectre_v2_enabled))
++ (spectre_v2_in_eibrs_mode(spectre_v2_enabled) &&
++ !boot_cpu_has(X86_FEATURE_AUTOIBRS)))
+ return;
+
+ /*
+@@ -2221,7 +2223,8 @@ static ssize_t mmio_stale_data_show_stat
+
+ static char *stibp_state(void)
+ {
+- if (spectre_v2_in_eibrs_mode(spectre_v2_enabled))
++ if (spectre_v2_in_eibrs_mode(spectre_v2_enabled) &&
++ !boot_cpu_has(X86_FEATURE_AUTOIBRS))
+ return "";
+
+ switch (spectre_v2_user_stibp) {
projects / thirdparty / kernel / stable-queue.git / commitdiff
