--- /dev/null
+From ab9fd06cb8f0db0854291833fc40c789e43a361f Mon Sep 17 00:00:00 2001
+From: Vamshi Gajjela <vamshigajjela@google.com>
+Date: Wed, 24 Jul 2024 19:21:26 +0530
+Subject: scsi: ufs: core: Fix hba->last_dme_cmd_tstamp timestamp updating logic
+
+From: Vamshi Gajjela <vamshigajjela@google.com>
+
+commit ab9fd06cb8f0db0854291833fc40c789e43a361f upstream.
+
+The ufshcd_add_delay_before_dme_cmd() always introduces a delay of
+MIN_DELAY_BEFORE_DME_CMDS_US between DME commands even when it's not
+required. The delay is added when the UFS host controller supplies the
+quirk UFSHCD_QUIRK_DELAY_BEFORE_DME_CMDS.
+
+Fix the logic to update hba->last_dme_cmd_tstamp to ensure subsequent DME
+commands have the correct delay in the range of 0 to
+MIN_DELAY_BEFORE_DME_CMDS_US.
+
+Update the timestamp at the end of the function to ensure it captures the
+latest time after any necessary delay has been applied.
+
+Signed-off-by: Vamshi Gajjela <vamshigajjela@google.com>
+Link: https://lore.kernel.org/r/20240724135126.1786126-1-vamshigajjela@google.com
+Fixes: cad2e03d8607 ("ufs: add support to allow non standard behaviours (quirks)")
+Cc: stable@vger.kernel.org
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/ufs/ufshcd.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/scsi/ufs/ufshcd.c
++++ b/drivers/scsi/ufs/ufshcd.c
+@@ -3592,11 +3592,16 @@ static inline void ufshcd_add_delay_befo
+ min_sleep_time_us =
+ MIN_DELAY_BEFORE_DME_CMDS_US - delta;
+ else
+- return; /* no more delay required */
++ min_sleep_time_us = 0; /* no more delay required */
+ }
+
+- /* allow sleep for extra 50us if needed */
+- usleep_range(min_sleep_time_us, min_sleep_time_us + 50);
++ if (min_sleep_time_us > 0) {
++ /* allow sleep for extra 50us if needed */
++ usleep_range(min_sleep_time_us, min_sleep_time_us + 50);
++ }
++
++ /* update the last_dme_cmd_tstamp */
++ hba->last_dme_cmd_tstamp = ktime_get();
+ }
+
+ /**
spi-spi-fsl-lpspi-fix-scldiv-calculation.patch
alsa-line6-fix-racy-access-to-midibuf.patch
usb-vhci-hcd-do-not-drop-references-before-new-references-are-gained.patch
+usb-serial-debug-do-not-echo-input-by-default.patch
+usb-gadget-core-check-for-unset-descriptor.patch
+scsi-ufs-core-fix-hba-last_dme_cmd_tstamp-timestamp-updating-logic.patch
+tick-broadcast-move-per-cpu-pointer-access-into-the-atomic-section.patch
--- /dev/null
+From 6881e75237a84093d0986f56223db3724619f26e Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Wed, 31 Jul 2024 12:23:51 +0200
+Subject: tick/broadcast: Move per CPU pointer access into the atomic section
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 6881e75237a84093d0986f56223db3724619f26e upstream.
+
+The recent fix for making the take over of the broadcast timer more
+reliable retrieves a per CPU pointer in preemptible context.
+
+This went unnoticed as compilers hoist the access into the non-preemptible
+region where the pointer is actually used. But of course it's valid that
+the compiler keeps it at the place where the code puts it which rightfully
+triggers:
+
+ BUG: using smp_processor_id() in preemptible [00000000] code:
+ caller is hotplug_cpu__broadcast_tick_pull+0x1c/0xc0
+
+Move it to the actual usage site which is in a non-preemptible region.
+
+Fixes: f7d43dd206e7 ("tick/broadcast: Make takeover of broadcast hrtimer reliable")
+Reported-by: David Wang <00107082@163.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Yu Liao <liaoyu15@huawei.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/all/87ttg56ers.ffs@tglx
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/time/tick-broadcast.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/time/tick-broadcast.c
++++ b/kernel/time/tick-broadcast.c
+@@ -941,7 +941,6 @@ void tick_broadcast_switch_to_oneshot(vo
+ #ifdef CONFIG_HOTPLUG_CPU
+ void hotplug_cpu__broadcast_tick_pull(int deadcpu)
+ {
+- struct tick_device *td = this_cpu_ptr(&tick_cpu_device);
+ struct clock_event_device *bc;
+ unsigned long flags;
+
+@@ -967,6 +966,8 @@ void hotplug_cpu__broadcast_tick_pull(in
+ * device to avoid the starvation.
+ */
+ if (tick_check_broadcast_expired()) {
++ struct tick_device *td = this_cpu_ptr(&tick_cpu_device);
++
+ cpumask_clear_cpu(smp_processor_id(), tick_broadcast_force_mask);
+ tick_program_event(td->evtdev->next_event, 1);
+ }
--- /dev/null
+From 973a57891608a98e894db2887f278777f564de18 Mon Sep 17 00:00:00 2001
+From: Chris Wulff <crwulff@gmail.com>
+Date: Wed, 24 Jul 2024 21:04:20 -0400
+Subject: usb: gadget: core: Check for unset descriptor
+
+From: Chris Wulff <crwulff@gmail.com>
+
+commit 973a57891608a98e894db2887f278777f564de18 upstream.
+
+Make sure the descriptor has been set before looking at maxpacket.
+This fixes a null pointer panic in this case.
+
+This may happen if the gadget doesn't properly set up the endpoint
+for the current speed, or the gadget descriptors are malformed and
+the descriptor for the speed/endpoint are not found.
+
+No current gadget driver is known to have this problem, but this
+may cause a hard-to-find bug during development of new gadgets.
+
+Fixes: 54f83b8c8ea9 ("USB: gadget: Reject endpoints with 0 maxpacket value")
+Cc: stable@vger.kernel.org
+Signed-off-by: Chris Wulff <crwulff@gmail.com>
+Link: https://lore.kernel.org/r/20240725010419.314430-2-crwulff@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/udc/core.c | 10 ++++------
+ 1 file changed, 4 insertions(+), 6 deletions(-)
+
+--- a/drivers/usb/gadget/udc/core.c
++++ b/drivers/usb/gadget/udc/core.c
+@@ -99,12 +99,10 @@ int usb_ep_enable(struct usb_ep *ep)
+ goto out;
+
+ /* UDC drivers can't handle endpoints with maxpacket size 0 */
+- if (usb_endpoint_maxp(ep->desc) == 0) {
+- /*
+- * We should log an error message here, but we can't call
+- * dev_err() because there's no way to find the gadget
+- * given only ep.
+- */
++ if (!ep->desc || usb_endpoint_maxp(ep->desc) == 0) {
++ WARN_ONCE(1, "%s: ep%d (%s) has %s\n", __func__, ep->address, ep->name,
++ (!ep->desc) ? "NULL descriptor" : "maxpacket 0");
++
+ ret = -EINVAL;
+ goto out;
+ }
--- /dev/null
+From 00af4f3dda1461ec90d892edc10bec6d3c50c554 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
+ <marmarek@invisiblethingslab.com>
+Date: Mon, 15 Jul 2024 12:44:53 +0200
+Subject: USB: serial: debug: do not echo input by default
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
+
+commit 00af4f3dda1461ec90d892edc10bec6d3c50c554 upstream.
+
+This driver is intended as a "client" end of the console connection.
+When connected to a host it's supposed to receive debug logs, and
+possibly allow to interact with whatever debug console is available
+there. Feeding messages back, depending on a configuration may cause log
+messages be executed as shell commands (which can be really bad if one
+is unlucky, imagine a log message like "prevented running `rm -rf
+/home`"). In case of Xen, it exposes sysrq-like debug interface, and
+feeding it its own logs will pretty quickly hit 'R' for "instant
+reboot".
+
+Contrary to a classic serial console, the USB one cannot be configured
+ahead of time, as the device shows up only when target OS is up. And at
+the time device is opened to execute relevant ioctl, it's already too
+late, especially when logs start flowing shortly after device is
+initialized.
+Avoid the issue by changing default to no echo for this type of devices.
+
+Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
+[ johan: amend summary; disable also ECHONL ]
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/serial/usb_debug.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/usb/serial/usb_debug.c
++++ b/drivers/usb/serial/usb_debug.c
+@@ -69,6 +69,11 @@ static void usb_debug_process_read_urb(s
+ usb_serial_generic_process_read_urb(urb);
+ }
+
++static void usb_debug_init_termios(struct tty_struct *tty)
++{
++ tty->termios.c_lflag &= ~(ECHO | ECHONL);
++}
++
+ static struct usb_serial_driver debug_device = {
+ .driver = {
+ .owner = THIS_MODULE,
+@@ -78,6 +83,7 @@ static struct usb_serial_driver debug_de
+ .num_ports = 1,
+ .bulk_out_size = USB_DEBUG_MAX_PACKET_SIZE,
+ .break_ctl = usb_debug_break_ctl,
++ .init_termios = usb_debug_init_termios,
+ .process_read_urb = usb_debug_process_read_urb,
+ };
+
+@@ -89,6 +95,7 @@ static struct usb_serial_driver dbc_devi
+ .id_table = dbc_id_table,
+ .num_ports = 1,
+ .break_ctl = usb_debug_break_ctl,
++ .init_termios = usb_debug_init_termios,
+ .process_read_urb = usb_debug_process_read_urb,
+ };
+