From 42ac01728773b5da61cc740caf10609d7eb0db6f Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 18 Feb 2024 20:01:37 +0100 Subject: [PATCH] 5.15-stable patches added patches: alsa-hda-realtek-enable-mute-led-on-hp-laptop-14-fq0xxx.patch alsa-hda-realtek-fix-the-external-mic-not-being-recognised-for-acer-swift-1-sf114-32.patch hid-i2c-hid-of-fix-null-deref-on-failed-power-up.patch hid-wacom-do-not-register-input-devices-until-after-hid_hw_start.patch hid-wacom-generic-avoid-reporting-a-serial-of-0-to-userspace.patch iio-hid-sensor-als-return-0-for-hid_usage_sensor_time_timestamp.patch mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch scs-add-config_mmu-dependency-for-vfree_atomic.patch scsi-storvsc-fix-ring-buffer-size-calculation.patch tracing-trigger-fix-to-return-error-if-failed-to-alloc-snapshot.patch usb-dwc3-gadget-fix-null-pointer-dereference-in-dwc3_gadget_suspend.patch usb-f_mass_storage-forbid-async-queue-when-shutdown-happen.patch usb-hub-check-for-alternate-port-before-enabling-a_alt_hnp_support.patch usb-ucsi_acpi-fix-command-completion-handling.patch --- ...able-mute-led-on-hp-laptop-14-fq0xxx.patch | 31 ++++ ...recognised-for-acer-swift-1-sf114-32.patch | 33 ++++ ...of-fix-null-deref-on-failed-power-up.patch | 34 ++++ ...put-devices-until-after-hid_hw_start.patch | 147 ++++++++++++++++++ ...reporting-a-serial-of-0-to-userspace.patch | 50 ++++++ ...-for-hid_usage_sensor_time_timestamp.patch | 34 ++++ ...ide-by-zero-in-wb_dirty_limits-again.patch | 46 ++++++ ...nfig_mmu-dependency-for-vfree_atomic.patch | 37 +++++ ...vsc-fix-ring-buffer-size-calculation.patch | 83 ++++++++++ queue-5.15/series | 14 ++ ...rn-error-if-failed-to-alloc-snapshot.patch | 40 +++++ ...r-dereference-in-dwc3_gadget_suspend.patch | 58 +++++++ ...bid-async-queue-when-shutdown-happen.patch | 71 +++++++++ ...rt-before-enabling-a_alt_hnp_support.patch | 79 ++++++++++ ...acpi-fix-command-completion-handling.patch | 75 +++++++++ 15 files changed, 832 insertions(+) create mode 100644 queue-5.15/alsa-hda-realtek-enable-mute-led-on-hp-laptop-14-fq0xxx.patch create mode 100644 queue-5.15/alsa-hda-realtek-fix-the-external-mic-not-being-recognised-for-acer-swift-1-sf114-32.patch create mode 100644 queue-5.15/hid-i2c-hid-of-fix-null-deref-on-failed-power-up.patch create mode 100644 queue-5.15/hid-wacom-do-not-register-input-devices-until-after-hid_hw_start.patch create mode 100644 queue-5.15/hid-wacom-generic-avoid-reporting-a-serial-of-0-to-userspace.patch create mode 100644 queue-5.15/iio-hid-sensor-als-return-0-for-hid_usage_sensor_time_timestamp.patch create mode 100644 queue-5.15/mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch create mode 100644 queue-5.15/scs-add-config_mmu-dependency-for-vfree_atomic.patch create mode 100644 queue-5.15/scsi-storvsc-fix-ring-buffer-size-calculation.patch create mode 100644 queue-5.15/tracing-trigger-fix-to-return-error-if-failed-to-alloc-snapshot.patch create mode 100644 queue-5.15/usb-dwc3-gadget-fix-null-pointer-dereference-in-dwc3_gadget_suspend.patch create mode 100644 queue-5.15/usb-f_mass_storage-forbid-async-queue-when-shutdown-happen.patch create mode 100644 queue-5.15/usb-hub-check-for-alternate-port-before-enabling-a_alt_hnp_support.patch create mode 100644 queue-5.15/usb-ucsi_acpi-fix-command-completion-handling.patch diff --git a/queue-5.15/alsa-hda-realtek-enable-mute-led-on-hp-laptop-14-fq0xxx.patch b/queue-5.15/alsa-hda-realtek-enable-mute-led-on-hp-laptop-14-fq0xxx.patch new file mode 100644 index 00000000000..bfd5581b6d3 --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-enable-mute-led-on-hp-laptop-14-fq0xxx.patch @@ -0,0 +1,31 @@ +From f0d78972f27dc1d1d51fbace2713ad3cdc60a877 Mon Sep 17 00:00:00 2001 +From: Luka Guzenko +Date: Sun, 28 Jan 2024 16:57:04 +0100 +Subject: ALSA: hda/realtek: Enable Mute LED on HP Laptop 14-fq0xxx + +From: Luka Guzenko + +commit f0d78972f27dc1d1d51fbace2713ad3cdc60a877 upstream. + +This HP Laptop uses ALC236 codec with COEF 0x07 controlling the +mute LED. Enable existing quirk for this device. + +Signed-off-by: Luka Guzenko +Cc: +Link: https://lore.kernel.org/r/20240128155704.2333812-1-l.guzenko@web.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -9090,6 +9090,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x103c, 0x8786, "HP OMEN 15", ALC285_FIXUP_HP_MUTE_LED), + SND_PCI_QUIRK(0x103c, 0x8787, "HP OMEN 15", ALC285_FIXUP_HP_MUTE_LED), + SND_PCI_QUIRK(0x103c, 0x8788, "HP OMEN 15", ALC285_FIXUP_HP_MUTE_LED), ++ SND_PCI_QUIRK(0x103c, 0x87b7, "HP Laptop 14-fq0xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2), + SND_PCI_QUIRK(0x103c, 0x87c8, "HP", ALC287_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x87e5, "HP ProBook 440 G8 Notebook PC", ALC236_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x87e7, "HP ProBook 450 G8 Notebook PC", ALC236_FIXUP_HP_GPIO_LED), diff --git a/queue-5.15/alsa-hda-realtek-fix-the-external-mic-not-being-recognised-for-acer-swift-1-sf114-32.patch b/queue-5.15/alsa-hda-realtek-fix-the-external-mic-not-being-recognised-for-acer-swift-1-sf114-32.patch new file mode 100644 index 00000000000..8a370a6289b --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-fix-the-external-mic-not-being-recognised-for-acer-swift-1-sf114-32.patch @@ -0,0 +1,33 @@ +From efb56d84dd9c3de3c99fc396abb57c6d330038b5 Mon Sep 17 00:00:00 2001 +From: David Senoner +Date: Fri, 26 Jan 2024 16:56:26 +0100 +Subject: ALSA: hda/realtek: Fix the external mic not being recognised for Acer Swift 1 SF114-32 + +From: David Senoner + +commit efb56d84dd9c3de3c99fc396abb57c6d330038b5 upstream. + +If you connect an external headset/microphone to the 3.5mm jack on the +Acer Swift 1 SF114-32 it does not recognize the microphone. This fixes +that and gives the user the ability to choose between internal and +headset mic. + +Signed-off-by: David Senoner +Cc: +Link: https://lore.kernel.org/r/20240126155626.2304465-1-seda18@rolmail.net +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -8905,6 +8905,7 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox", ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS), + SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G", ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1025, 0x1269, "Acer SWIFT SF314-54", ALC256_FIXUP_ACER_HEADSET_MIC), ++ SND_PCI_QUIRK(0x1025, 0x126a, "Acer Swift SF114-32", ALC256_FIXUP_ACER_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G", ALC286_FIXUP_ACER_AIO_HEADSET_MIC), + SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G", ALC286_FIXUP_ACER_AIO_HEADSET_MIC), + SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G", ALC286_FIXUP_ACER_AIO_HEADSET_MIC), diff --git a/queue-5.15/hid-i2c-hid-of-fix-null-deref-on-failed-power-up.patch b/queue-5.15/hid-i2c-hid-of-fix-null-deref-on-failed-power-up.patch new file mode 100644 index 00000000000..a82476e4ca0 --- /dev/null +++ b/queue-5.15/hid-i2c-hid-of-fix-null-deref-on-failed-power-up.patch @@ -0,0 +1,34 @@ +From 00aab7dcb2267f2aef59447602f34501efe1a07f Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 26 Jan 2024 18:09:01 +0100 +Subject: HID: i2c-hid-of: fix NULL-deref on failed power up + +From: Johan Hovold + +commit 00aab7dcb2267f2aef59447602f34501efe1a07f upstream. + +A while back the I2C HID implementation was split in an ACPI and OF +part, but the new OF driver never initialises the client pointer which +is dereferenced on power-up failures. + +Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules") +Cc: stable@vger.kernel.org # 5.12 +Cc: Douglas Anderson +Signed-off-by: Johan Hovold +Reviewed-by: Douglas Anderson +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/i2c-hid/i2c-hid-of.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/hid/i2c-hid/i2c-hid-of.c ++++ b/drivers/hid/i2c-hid/i2c-hid-of.c +@@ -80,6 +80,7 @@ static int i2c_hid_of_probe(struct i2c_c + if (!ihid_of) + return -ENOMEM; + ++ ihid_of->client = client; + ihid_of->ops.power_up = i2c_hid_of_power_up; + ihid_of->ops.power_down = i2c_hid_of_power_down; + diff --git a/queue-5.15/hid-wacom-do-not-register-input-devices-until-after-hid_hw_start.patch b/queue-5.15/hid-wacom-do-not-register-input-devices-until-after-hid_hw_start.patch new file mode 100644 index 00000000000..fcad385375c --- /dev/null +++ b/queue-5.15/hid-wacom-do-not-register-input-devices-until-after-hid_hw_start.patch @@ -0,0 +1,147 @@ +From c1d6708bf0d3dd976460d435373cf5abf21ce258 Mon Sep 17 00:00:00 2001 +From: Jason Gerecke +Date: Mon, 29 Jan 2024 14:35:45 -0800 +Subject: HID: wacom: Do not register input devices until after hid_hw_start + +From: Jason Gerecke + +commit c1d6708bf0d3dd976460d435373cf5abf21ce258 upstream. + +If a input device is opened before hid_hw_start is called, events may +not be received from the hardware. In the case of USB-backed devices, +for example, the hid_hw_start function is responsible for filling in +the URB which is submitted when the input device is opened. If a device +is opened prematurely, polling will never start because the device will +not have been in the correct state to send the URB. + +Because the wacom driver registers its input devices before calling +hid_hw_start, there is a window of time where a device can be opened +and end up in an inoperable state. Some ARM-based Chromebooks in particular +reliably trigger this bug. + +This commit splits the wacom_register_inputs function into two pieces. +One which is responsible for setting up the allocated inputs (and runs +prior to hid_hw_start so that devices are ready for any input events +they may end up receiving) and another which only registers the devices +(and runs after hid_hw_start to ensure devices can be immediately opened +without issue). Note that the functions to initialize the LEDs and remotes +are also moved after hid_hw_start to maintain their own dependency chains. + +Fixes: 7704ac937345 ("HID: wacom: implement generic HID handling for pen generic devices") +Cc: stable@vger.kernel.org # v3.18+ +Suggested-by: Dmitry Torokhov +Signed-off-by: Jason Gerecke +Tested-by: Dmitry Torokhov +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/wacom_sys.c | 63 ++++++++++++++++++++++++++++++++---------------- + 1 file changed, 43 insertions(+), 20 deletions(-) + +--- a/drivers/hid/wacom_sys.c ++++ b/drivers/hid/wacom_sys.c +@@ -2088,7 +2088,7 @@ static int wacom_allocate_inputs(struct + return 0; + } + +-static int wacom_register_inputs(struct wacom *wacom) ++static int wacom_setup_inputs(struct wacom *wacom) + { + struct input_dev *pen_input_dev, *touch_input_dev, *pad_input_dev; + struct wacom_wac *wacom_wac = &(wacom->wacom_wac); +@@ -2107,10 +2107,6 @@ static int wacom_register_inputs(struct + input_free_device(pen_input_dev); + wacom_wac->pen_input = NULL; + pen_input_dev = NULL; +- } else { +- error = input_register_device(pen_input_dev); +- if (error) +- goto fail; + } + + error = wacom_setup_touch_input_capabilities(touch_input_dev, wacom_wac); +@@ -2119,10 +2115,6 @@ static int wacom_register_inputs(struct + input_free_device(touch_input_dev); + wacom_wac->touch_input = NULL; + touch_input_dev = NULL; +- } else { +- error = input_register_device(touch_input_dev); +- if (error) +- goto fail; + } + + error = wacom_setup_pad_input_capabilities(pad_input_dev, wacom_wac); +@@ -2131,7 +2123,34 @@ static int wacom_register_inputs(struct + input_free_device(pad_input_dev); + wacom_wac->pad_input = NULL; + pad_input_dev = NULL; +- } else { ++ } ++ ++ return 0; ++} ++ ++static int wacom_register_inputs(struct wacom *wacom) ++{ ++ struct input_dev *pen_input_dev, *touch_input_dev, *pad_input_dev; ++ struct wacom_wac *wacom_wac = &(wacom->wacom_wac); ++ int error = 0; ++ ++ pen_input_dev = wacom_wac->pen_input; ++ touch_input_dev = wacom_wac->touch_input; ++ pad_input_dev = wacom_wac->pad_input; ++ ++ if (pen_input_dev) { ++ error = input_register_device(pen_input_dev); ++ if (error) ++ goto fail; ++ } ++ ++ if (touch_input_dev) { ++ error = input_register_device(touch_input_dev); ++ if (error) ++ goto fail; ++ } ++ ++ if (pad_input_dev) { + error = input_register_device(pad_input_dev); + if (error) + goto fail; +@@ -2387,6 +2406,20 @@ static int wacom_parse_and_register(stru + goto fail; + } + ++ error = wacom_setup_inputs(wacom); ++ if (error) ++ goto fail; ++ ++ if (features->type == HID_GENERIC) ++ connect_mask |= HID_CONNECT_DRIVER; ++ ++ /* Regular HID work starts now */ ++ error = hid_hw_start(hdev, connect_mask); ++ if (error) { ++ hid_err(hdev, "hw start failed\n"); ++ goto fail; ++ } ++ + error = wacom_register_inputs(wacom); + if (error) + goto fail; +@@ -2401,16 +2434,6 @@ static int wacom_parse_and_register(stru + goto fail; + } + +- if (features->type == HID_GENERIC) +- connect_mask |= HID_CONNECT_DRIVER; +- +- /* Regular HID work starts now */ +- error = hid_hw_start(hdev, connect_mask); +- if (error) { +- hid_err(hdev, "hw start failed\n"); +- goto fail; +- } +- + if (!wireless) { + /* Note that if query fails it is not a hard failure */ + wacom_query_tablet_data(wacom); diff --git a/queue-5.15/hid-wacom-generic-avoid-reporting-a-serial-of-0-to-userspace.patch b/queue-5.15/hid-wacom-generic-avoid-reporting-a-serial-of-0-to-userspace.patch new file mode 100644 index 00000000000..16c98bb79c9 --- /dev/null +++ b/queue-5.15/hid-wacom-generic-avoid-reporting-a-serial-of-0-to-userspace.patch @@ -0,0 +1,50 @@ +From ab41a31dd5e2681803642b6d08590b61867840ec Mon Sep 17 00:00:00 2001 +From: Tatsunosuke Tobita +Date: Thu, 1 Feb 2024 13:40:55 +0900 +Subject: HID: wacom: generic: Avoid reporting a serial of '0' to userspace + +From: Tatsunosuke Tobita + +commit ab41a31dd5e2681803642b6d08590b61867840ec upstream. + +The xf86-input-wacom driver does not treat '0' as a valid serial +number and will drop any input report which contains an +MSC_SERIAL = 0 event. The kernel driver already takes care to +avoid sending any MSC_SERIAL event if the value of serial[0] == 0 +(which is the case for devices that don't actually report a +serial number), but this is not quite sufficient. +Only the lower 32 bits of the serial get reported to userspace, +so if this portion of the serial is zero then there can still +be problems. + +This commit allows the driver to report either the lower 32 bits +if they are non-zero or the upper 32 bits otherwise. + +Signed-off-by: Jason Gerecke +Signed-off-by: Tatsunosuke Tobita +Fixes: f85c9dc678a5 ("HID: wacom: generic: Support tool ID and additional tool types") +CC: stable@vger.kernel.org # v4.10 +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/wacom_wac.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/hid/wacom_wac.c ++++ b/drivers/hid/wacom_wac.c +@@ -2551,7 +2551,14 @@ static void wacom_wac_pen_report(struct + wacom_wac->hid_data.tipswitch); + input_report_key(input, wacom_wac->tool[0], sense); + if (wacom_wac->serial[0]) { +- input_event(input, EV_MSC, MSC_SERIAL, wacom_wac->serial[0]); ++ /* ++ * xf86-input-wacom does not accept a serial number ++ * of '0'. Report the low 32 bits if possible, but ++ * if they are zero, report the upper ones instead. ++ */ ++ __u32 serial_lo = wacom_wac->serial[0] & 0xFFFFFFFFu; ++ __u32 serial_hi = wacom_wac->serial[0] >> 32; ++ input_event(input, EV_MSC, MSC_SERIAL, (int)(serial_lo ? serial_lo : serial_hi)); + input_report_abs(input, ABS_MISC, sense ? id : 0); + } + diff --git a/queue-5.15/iio-hid-sensor-als-return-0-for-hid_usage_sensor_time_timestamp.patch b/queue-5.15/iio-hid-sensor-als-return-0-for-hid_usage_sensor_time_timestamp.patch new file mode 100644 index 00000000000..49d5a6d0b2b --- /dev/null +++ b/queue-5.15/iio-hid-sensor-als-return-0-for-hid_usage_sensor_time_timestamp.patch @@ -0,0 +1,34 @@ +From 621c6257128149e45b36ffb973a01c3f3461b893 Mon Sep 17 00:00:00 2001 +From: Srinivas Pandruvada +Date: Sun, 4 Feb 2024 04:56:17 -0800 +Subject: iio: hid-sensor-als: Return 0 for HID_USAGE_SENSOR_TIME_TIMESTAMP + +From: Srinivas Pandruvada + +commit 621c6257128149e45b36ffb973a01c3f3461b893 upstream. + +When als_capture_sample() is called with usage ID +HID_USAGE_SENSOR_TIME_TIMESTAMP, return 0. The HID sensor core ignores +the return value for capture_sample() callback, so return value doesn't +make difference. But correct the return value to return success instead +of -EINVAL. + +Signed-off-by: Srinivas Pandruvada +Link: https://lore.kernel.org/r/20240204125617.2635574-1-srinivas.pandruvada@linux.intel.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/light/hid-sensor-als.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/iio/light/hid-sensor-als.c ++++ b/drivers/iio/light/hid-sensor-als.c +@@ -228,6 +228,7 @@ static int als_capture_sample(struct hid + case HID_USAGE_SENSOR_TIME_TIMESTAMP: + als_state->timestamp = hid_sensor_convert_timestamp(&als_state->common_attributes, + *(s64 *)raw_data); ++ ret = 0; + break; + default: + break; diff --git a/queue-5.15/mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch b/queue-5.15/mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch new file mode 100644 index 00000000000..2635e6ee8c0 --- /dev/null +++ b/queue-5.15/mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch @@ -0,0 +1,46 @@ +From 9319b647902cbd5cc884ac08a8a6d54ce111fc78 Mon Sep 17 00:00:00 2001 +From: Zach O'Keefe +Date: Thu, 18 Jan 2024 10:19:53 -0800 +Subject: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again + +From: Zach O'Keefe + +commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78 upstream. + +(struct dirty_throttle_control *)->thresh is an unsigned long, but is +passed as the u32 divisor argument to div_u64(). On architectures where +unsigned long is 64 bytes, the argument will be implicitly truncated. + +Use div64_u64() instead of div_u64() so that the value used in the "is +this a safe division" check is the same as the divisor. + +Also, remove redundant cast of the numerator to u64, as that should happen +implicitly. + +This would be difficult to exploit in memcg domain, given the ratio-based +arithmetic domain_drity_limits() uses, but is much easier in global +writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. +vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32) + +Link: https://lkml.kernel.org/r/20240118181954.1415197-1-zokeefe@google.com +Fixes: f6789593d5ce ("mm/page-writeback.c: fix divide by zero in bdi_dirty_limits()") +Signed-off-by: Zach O'Keefe +Cc: Maxim Patlasov +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/page-writeback.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/page-writeback.c ++++ b/mm/page-writeback.c +@@ -1529,7 +1529,7 @@ static inline void wb_dirty_limits(struc + */ + dtc->wb_thresh = __wb_calc_thresh(dtc); + dtc->wb_bg_thresh = dtc->thresh ? +- div_u64((u64)dtc->wb_thresh * dtc->bg_thresh, dtc->thresh) : 0; ++ div64_u64(dtc->wb_thresh * dtc->bg_thresh, dtc->thresh) : 0; + + /* + * In order to avoid the stacked BDI deadlock we need diff --git a/queue-5.15/scs-add-config_mmu-dependency-for-vfree_atomic.patch b/queue-5.15/scs-add-config_mmu-dependency-for-vfree_atomic.patch new file mode 100644 index 00000000000..38a4cd500a0 --- /dev/null +++ b/queue-5.15/scs-add-config_mmu-dependency-for-vfree_atomic.patch @@ -0,0 +1,37 @@ +From 6f9dc684cae638dda0570154509884ee78d0f75c Mon Sep 17 00:00:00 2001 +From: Samuel Holland +Date: Mon, 22 Jan 2024 09:52:01 -0800 +Subject: scs: add CONFIG_MMU dependency for vfree_atomic() + +From: Samuel Holland + +commit 6f9dc684cae638dda0570154509884ee78d0f75c upstream. + +The shadow call stack implementation fails to build without CONFIG_MMU: + + ld.lld: error: undefined symbol: vfree_atomic + >>> referenced by scs.c + >>> kernel/scs.o:(scs_free) in archive vmlinux.a + +Link: https://lkml.kernel.org/r/20240122175204.2371009-1-samuel.holland@sifive.com +Fixes: a2abe7cbd8fe ("scs: switch to vmapped shadow stacks") +Signed-off-by: Samuel Holland +Reviewed-by: Sami Tolvanen +Cc: Will Deacon +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + arch/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/Kconfig ++++ b/arch/Kconfig +@@ -605,6 +605,7 @@ config SHADOW_CALL_STACK + bool "Clang Shadow Call Stack" + depends on CC_IS_CLANG && ARCH_SUPPORTS_SHADOW_CALL_STACK + depends on DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER ++ depends on MMU + help + This option enables Clang's Shadow Call Stack, which uses a + shadow stack to protect function return addresses from being diff --git a/queue-5.15/scsi-storvsc-fix-ring-buffer-size-calculation.patch b/queue-5.15/scsi-storvsc-fix-ring-buffer-size-calculation.patch new file mode 100644 index 00000000000..2b991cf86b5 --- /dev/null +++ b/queue-5.15/scsi-storvsc-fix-ring-buffer-size-calculation.patch @@ -0,0 +1,83 @@ +From f4469f3858352ad1197434557150b1f7086762a0 Mon Sep 17 00:00:00 2001 +From: Michael Kelley +Date: Mon, 22 Jan 2024 09:09:56 -0800 +Subject: scsi: storvsc: Fix ring buffer size calculation + +From: Michael Kelley + +commit f4469f3858352ad1197434557150b1f7086762a0 upstream. + +Current code uses the specified ring buffer size (either the default of 128 +Kbytes or a module parameter specified value) to encompass the one page +ring buffer header plus the actual ring itself. When the page size is 4K, +carving off one page for the header isn't significant. But when the page +size is 64K on ARM64, only half of the default 128 Kbytes is left for the +actual ring. While this doesn't break anything, the smaller ring size +could be a performance bottleneck. + +Fix this by applying the VMBUS_RING_SIZE macro to the specified ring buffer +size. This macro adds a page for the header, and rounds up the size to a +page boundary, using the page size for which the kernel is built. Use this +new size for subsequent ring buffer calculations. For example, on ARM64 +with 64K page size and the default ring size, this results in the actual +ring being 128 Kbytes, which is intended. + +Cc: stable@vger.kernel.org # 5.15.x +Signed-off-by: Michael Kelley +Link: https://lore.kernel.org/r/20240122170956.496436-1-mhklinux@outlook.com +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/storvsc_drv.c | 12 +++++++----- + 1 file changed, 7 insertions(+), 5 deletions(-) + +--- a/drivers/scsi/storvsc_drv.c ++++ b/drivers/scsi/storvsc_drv.c +@@ -367,6 +367,7 @@ enum storvsc_request_type { + */ + + static int storvsc_ringbuffer_size = (128 * 1024); ++static int aligned_ringbuffer_size; + static u32 max_outstanding_req_per_channel; + static int storvsc_change_queue_depth(struct scsi_device *sdev, int queue_depth); + +@@ -737,8 +738,8 @@ static void handle_sc_creation(struct vm + new_sc->next_request_id_callback = storvsc_next_request_id; + + ret = vmbus_open(new_sc, +- storvsc_ringbuffer_size, +- storvsc_ringbuffer_size, ++ aligned_ringbuffer_size, ++ aligned_ringbuffer_size, + (void *)&props, + sizeof(struct vmstorage_channel_properties), + storvsc_on_channel_callback, new_sc); +@@ -2033,7 +2034,7 @@ static int storvsc_probe(struct hv_devic + hv_set_drvdata(device, stor_device); + + stor_device->port_number = host->host_no; +- ret = storvsc_connect_to_vsp(device, storvsc_ringbuffer_size, is_fc); ++ ret = storvsc_connect_to_vsp(device, aligned_ringbuffer_size, is_fc); + if (ret) + goto err_out1; + +@@ -2226,7 +2227,7 @@ static int storvsc_resume(struct hv_devi + { + int ret; + +- ret = storvsc_connect_to_vsp(hv_dev, storvsc_ringbuffer_size, ++ ret = storvsc_connect_to_vsp(hv_dev, aligned_ringbuffer_size, + hv_dev_is_fc(hv_dev)); + return ret; + } +@@ -2264,8 +2265,9 @@ static int __init storvsc_drv_init(void) + * for Win7 and older hosts because it does not take into account + * the vmscsi_size_delta correction to the max request size. + */ ++ aligned_ringbuffer_size = VMBUS_RING_SIZE(storvsc_ringbuffer_size); + max_outstanding_req_per_channel = +- ((storvsc_ringbuffer_size - PAGE_SIZE) / ++ ((aligned_ringbuffer_size - PAGE_SIZE) / + ALIGN(MAX_MULTIPAGE_BUFFER_PACKET + + sizeof(struct vstor_packet) + sizeof(u64), + sizeof(u64))); diff --git a/queue-5.15/series b/queue-5.15/series index cee963e7b8b..96948b4be89 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -362,3 +362,17 @@ asoc-rt5645-fix-deadlock-in-rt5645_jack_detect_work.patch net-sysfs-fix-sys-class-net-iface-path-for-statistic.patch mips-add-memory-clobber-to-csum_ipv6_magic-inline-as.patch i40e-fix-waiting-for-queues-of-all-vsis-to-be-disabl.patch +scs-add-config_mmu-dependency-for-vfree_atomic.patch +tracing-trigger-fix-to-return-error-if-failed-to-alloc-snapshot.patch +mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch +scsi-storvsc-fix-ring-buffer-size-calculation.patch +alsa-hda-realtek-fix-the-external-mic-not-being-recognised-for-acer-swift-1-sf114-32.patch +alsa-hda-realtek-enable-mute-led-on-hp-laptop-14-fq0xxx.patch +hid-i2c-hid-of-fix-null-deref-on-failed-power-up.patch +hid-wacom-generic-avoid-reporting-a-serial-of-0-to-userspace.patch +hid-wacom-do-not-register-input-devices-until-after-hid_hw_start.patch +iio-hid-sensor-als-return-0-for-hid_usage_sensor_time_timestamp.patch +usb-ucsi_acpi-fix-command-completion-handling.patch +usb-hub-check-for-alternate-port-before-enabling-a_alt_hnp_support.patch +usb-f_mass_storage-forbid-async-queue-when-shutdown-happen.patch +usb-dwc3-gadget-fix-null-pointer-dereference-in-dwc3_gadget_suspend.patch diff --git a/queue-5.15/tracing-trigger-fix-to-return-error-if-failed-to-alloc-snapshot.patch b/queue-5.15/tracing-trigger-fix-to-return-error-if-failed-to-alloc-snapshot.patch new file mode 100644 index 00000000000..d780f72e9d5 --- /dev/null +++ b/queue-5.15/tracing-trigger-fix-to-return-error-if-failed-to-alloc-snapshot.patch @@ -0,0 +1,40 @@ +From 0958b33ef5a04ed91f61cef4760ac412080c4e08 Mon Sep 17 00:00:00 2001 +From: "Masami Hiramatsu (Google)" +Date: Fri, 26 Jan 2024 09:42:58 +0900 +Subject: tracing/trigger: Fix to return error if failed to alloc snapshot + +From: Masami Hiramatsu (Google) + +commit 0958b33ef5a04ed91f61cef4760ac412080c4e08 upstream. + +Fix register_snapshot_trigger() to return error code if it failed to +allocate a snapshot instead of 0 (success). Unless that, it will register +snapshot trigger without an error. + +Link: https://lore.kernel.org/linux-trace-kernel/170622977792.270660.2789298642759362200.stgit@devnote2 + +Fixes: 0bbe7f719985 ("tracing: Fix the race between registering 'snapshot' event trigger and triggering 'snapshot' operation") +Cc: stable@vger.kernel.org +Cc: Vincent Donnefort +Signed-off-by: Masami Hiramatsu (Google) +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace_events_trigger.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/kernel/trace/trace_events_trigger.c ++++ b/kernel/trace/trace_events_trigger.c +@@ -1161,8 +1161,10 @@ register_snapshot_trigger(char *glob, st + struct event_trigger_data *data, + struct trace_event_file *file) + { +- if (tracing_alloc_snapshot_instance(file->tr) != 0) +- return 0; ++ int ret = tracing_alloc_snapshot_instance(file->tr); ++ ++ if (ret < 0) ++ return ret; + + return register_trigger(glob, ops, data, file); + } diff --git a/queue-5.15/usb-dwc3-gadget-fix-null-pointer-dereference-in-dwc3_gadget_suspend.patch b/queue-5.15/usb-dwc3-gadget-fix-null-pointer-dereference-in-dwc3_gadget_suspend.patch new file mode 100644 index 00000000000..2cb7094c952 --- /dev/null +++ b/queue-5.15/usb-dwc3-gadget-fix-null-pointer-dereference-in-dwc3_gadget_suspend.patch @@ -0,0 +1,58 @@ +From 61a348857e869432e6a920ad8ea9132e8d44c316 Mon Sep 17 00:00:00 2001 +From: Uttkarsh Aggarwal +Date: Fri, 19 Jan 2024 15:18:25 +0530 +Subject: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend + +From: Uttkarsh Aggarwal + +commit 61a348857e869432e6a920ad8ea9132e8d44c316 upstream. + +In current scenario if Plug-out and Plug-In performed continuously +there could be a chance while checking for dwc->gadget_driver in +dwc3_gadget_suspend, a NULL pointer dereference may occur. + +Call Stack: + + CPU1: CPU2: + gadget_unbind_driver dwc3_suspend_common + dwc3_gadget_stop dwc3_gadget_suspend + dwc3_disconnect_gadget + +CPU1 basically clears the variable and CPU2 checks the variable. +Consider CPU1 is running and right before gadget_driver is cleared +and in parallel CPU2 executes dwc3_gadget_suspend where it finds +dwc->gadget_driver which is not NULL and resumes execution and then +CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where +it checks dwc->gadget_driver is already NULL because of which the +NULL pointer deference occur. + +Cc: stable@vger.kernel.org +Fixes: 9772b47a4c29 ("usb: dwc3: gadget: Fix suspend/resume during device mode") +Acked-by: Thinh Nguyen +Signed-off-by: Uttkarsh Aggarwal +Link: https://lore.kernel.org/r/20240119094825.26530-1-quic_uaggarwa@quicinc.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/dwc3/gadget.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +--- a/drivers/usb/dwc3/gadget.c ++++ b/drivers/usb/dwc3/gadget.c +@@ -4412,15 +4412,13 @@ int dwc3_gadget_suspend(struct dwc3 *dwc + unsigned long flags; + int ret; + +- if (!dwc->gadget_driver) +- return 0; +- + ret = dwc3_gadget_soft_disconnect(dwc); + if (ret) + goto err; + + spin_lock_irqsave(&dwc->lock, flags); +- dwc3_disconnect_gadget(dwc); ++ if (dwc->gadget_driver) ++ dwc3_disconnect_gadget(dwc); + spin_unlock_irqrestore(&dwc->lock, flags); + + return 0; diff --git a/queue-5.15/usb-f_mass_storage-forbid-async-queue-when-shutdown-happen.patch b/queue-5.15/usb-f_mass_storage-forbid-async-queue-when-shutdown-happen.patch new file mode 100644 index 00000000000..7654e560472 --- /dev/null +++ b/queue-5.15/usb-f_mass_storage-forbid-async-queue-when-shutdown-happen.patch @@ -0,0 +1,71 @@ +From b2d2d7ea0dd09802cf5a0545bf54d8ad8987d20c Mon Sep 17 00:00:00 2001 +From: yuan linyu +Date: Tue, 23 Jan 2024 11:48:29 +0800 +Subject: usb: f_mass_storage: forbid async queue when shutdown happen + +From: yuan linyu + +commit b2d2d7ea0dd09802cf5a0545bf54d8ad8987d20c upstream. + +When write UDC to empty and unbind gadget driver from gadget device, it is +possible that there are many queue failures for mass storage function. + +The root cause is mass storage main thread alaways try to queue request to +receive a command from host if running flag is on, on platform like dwc3, +if pull down called, it will not queue request again and return +-ESHUTDOWN, but it not affect running flag of mass storage function. + +Check return code from mass storage function and clear running flag if it +is -ESHUTDOWN, also indicate start in/out transfer failure to break loops. + +Cc: stable +Signed-off-by: yuan linyu +Reviewed-by: Alan Stern +Link: https://lore.kernel.org/r/20240123034829.3848409-1-yuanlinyu@hihonor.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/gadget/function/f_mass_storage.c | 20 ++++++++++++++++++-- + 1 file changed, 18 insertions(+), 2 deletions(-) + +--- a/drivers/usb/gadget/function/f_mass_storage.c ++++ b/drivers/usb/gadget/function/f_mass_storage.c +@@ -543,21 +543,37 @@ static int start_transfer(struct fsg_dev + + static bool start_in_transfer(struct fsg_common *common, struct fsg_buffhd *bh) + { ++ int rc; ++ + if (!fsg_is_set(common)) + return false; + bh->state = BUF_STATE_SENDING; +- if (start_transfer(common->fsg, common->fsg->bulk_in, bh->inreq)) ++ rc = start_transfer(common->fsg, common->fsg->bulk_in, bh->inreq); ++ if (rc) { + bh->state = BUF_STATE_EMPTY; ++ if (rc == -ESHUTDOWN) { ++ common->running = 0; ++ return false; ++ } ++ } + return true; + } + + static bool start_out_transfer(struct fsg_common *common, struct fsg_buffhd *bh) + { ++ int rc; ++ + if (!fsg_is_set(common)) + return false; + bh->state = BUF_STATE_RECEIVING; +- if (start_transfer(common->fsg, common->fsg->bulk_out, bh->outreq)) ++ rc = start_transfer(common->fsg, common->fsg->bulk_out, bh->outreq); ++ if (rc) { + bh->state = BUF_STATE_FULL; ++ if (rc == -ESHUTDOWN) { ++ common->running = 0; ++ return false; ++ } ++ } + return true; + } + diff --git a/queue-5.15/usb-hub-check-for-alternate-port-before-enabling-a_alt_hnp_support.patch b/queue-5.15/usb-hub-check-for-alternate-port-before-enabling-a_alt_hnp_support.patch new file mode 100644 index 00000000000..7bb08204236 --- /dev/null +++ b/queue-5.15/usb-hub-check-for-alternate-port-before-enabling-a_alt_hnp_support.patch @@ -0,0 +1,79 @@ +From f17c34ffc792bbb520e4b61baa16b6cfc7d44b13 Mon Sep 17 00:00:00 2001 +From: Oliver Neukum +Date: Mon, 22 Jan 2024 16:35:32 +0100 +Subject: USB: hub: check for alternate port before enabling A_ALT_HNP_SUPPORT +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Oliver Neukum + +commit f17c34ffc792bbb520e4b61baa16b6cfc7d44b13 upstream. + +The OTG 1.3 spec has the feature A_ALT_HNP_SUPPORT, which tells +a device that it is connected to the wrong port. Some devices +refuse to operate if you enable that feature, because it indicates +to them that they ought to request to be connected to another port. + +According to the spec this feature may be used based only the following +three conditions: + +6.5.3 a_alt_hnp_support +Setting this feature indicates to the B-device that it is connected to +an A-device port that is not capable of HNP, but that the A-device does +have an alternate port that is capable of HNP. +The A-device is required to set this feature under the following conditions: +• the A-device has multiple receptacles +• the A-device port that connects to the B-device does not support HNP +• the A-device has another port that does support HNP + +A check for the third and first condition is missing. Add it. + +Signed-off-by: Oliver Neukum +Cc: stable +Fixes: 7d2d641c44269 ("usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device") +Link: https://lore.kernel.org/r/20240122153545.12284-1-oneukum@suse.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/core/hub.c | 30 +++++++++++++++++++----------- + 1 file changed, 19 insertions(+), 11 deletions(-) + +--- a/drivers/usb/core/hub.c ++++ b/drivers/usb/core/hub.c +@@ -2368,17 +2368,25 @@ static int usb_enumerate_device_otg(stru + } + } else if (desc->bLength == sizeof + (struct usb_otg_descriptor)) { +- /* Set a_alt_hnp_support for legacy otg device */ +- err = usb_control_msg(udev, +- usb_sndctrlpipe(udev, 0), +- USB_REQ_SET_FEATURE, 0, +- USB_DEVICE_A_ALT_HNP_SUPPORT, +- 0, NULL, 0, +- USB_CTRL_SET_TIMEOUT); +- if (err < 0) +- dev_err(&udev->dev, +- "set a_alt_hnp_support failed: %d\n", +- err); ++ /* ++ * We are operating on a legacy OTP device ++ * These should be told that they are operating ++ * on the wrong port if we have another port that does ++ * support HNP ++ */ ++ if (bus->otg_port != 0) { ++ /* Set a_alt_hnp_support for legacy otg device */ ++ err = usb_control_msg(udev, ++ usb_sndctrlpipe(udev, 0), ++ USB_REQ_SET_FEATURE, 0, ++ USB_DEVICE_A_ALT_HNP_SUPPORT, ++ 0, NULL, 0, ++ USB_CTRL_SET_TIMEOUT); ++ if (err < 0) ++ dev_err(&udev->dev, ++ "set a_alt_hnp_support failed: %d\n", ++ err); ++ } + } + } + #endif diff --git a/queue-5.15/usb-ucsi_acpi-fix-command-completion-handling.patch b/queue-5.15/usb-ucsi_acpi-fix-command-completion-handling.patch new file mode 100644 index 00000000000..eac096f8730 --- /dev/null +++ b/queue-5.15/usb-ucsi_acpi-fix-command-completion-handling.patch @@ -0,0 +1,75 @@ +From 2840143e393a4ddc1caab4372969ea337371168c Mon Sep 17 00:00:00 2001 +From: "Christian A. Ehrhardt" +Date: Sun, 21 Jan 2024 21:41:22 +0100 +Subject: usb: ucsi_acpi: Fix command completion handling + +From: Christian A. Ehrhardt + +commit 2840143e393a4ddc1caab4372969ea337371168c upstream. + +In case of a spurious or otherwise delayed notification it is +possible that CCI still reports the previous completion. The +UCSI spec is aware of this and provides two completion bits in +CCI, one for normal commands and one for acks. As acks and commands +alternate the notification handler can determine if the completion +bit is from the current command. + +The initial UCSI code correctly handled this but the distinction +between the two completion bits was lost with the introduction of +the new API. + +To fix this revive the ACK_PENDING bit for ucsi_acpi and only complete +commands if the completion bit matches. + +Fixes: f56de278e8ec ("usb: typec: ucsi: acpi: Move to the new API") +Cc: stable@vger.kernel.org +Signed-off-by: "Christian A. Ehrhardt" +Acked-by: Heikki Krogerus +Link: https://lore.kernel.org/r/20240121204123.275441-3-lk@c--e.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/typec/ucsi/ucsi_acpi.c | 17 +++++++++++++---- + 1 file changed, 13 insertions(+), 4 deletions(-) + +--- a/drivers/usb/typec/ucsi/ucsi_acpi.c ++++ b/drivers/usb/typec/ucsi/ucsi_acpi.c +@@ -70,9 +70,13 @@ static int ucsi_acpi_sync_write(struct u + const void *val, size_t val_len) + { + struct ucsi_acpi *ua = ucsi_get_drvdata(ucsi); ++ bool ack = UCSI_COMMAND(*(u64 *)val) == UCSI_ACK_CC_CI; + int ret; + +- set_bit(COMMAND_PENDING, &ua->flags); ++ if (ack) ++ set_bit(ACK_PENDING, &ua->flags); ++ else ++ set_bit(COMMAND_PENDING, &ua->flags); + + ret = ucsi_acpi_async_write(ucsi, offset, val, val_len); + if (ret) +@@ -82,7 +86,10 @@ static int ucsi_acpi_sync_write(struct u + ret = -ETIMEDOUT; + + out_clear_bit: +- clear_bit(COMMAND_PENDING, &ua->flags); ++ if (ack) ++ clear_bit(ACK_PENDING, &ua->flags); ++ else ++ clear_bit(COMMAND_PENDING, &ua->flags); + + return ret; + } +@@ -106,8 +113,10 @@ static void ucsi_acpi_notify(acpi_handle + if (UCSI_CCI_CONNECTOR(cci)) + ucsi_connector_change(ua->ucsi, UCSI_CCI_CONNECTOR(cci)); + +- if (test_bit(COMMAND_PENDING, &ua->flags) && +- cci & (UCSI_CCI_ACK_COMPLETE | UCSI_CCI_COMMAND_COMPLETE)) ++ if (cci & UCSI_CCI_ACK_COMPLETE && test_bit(ACK_PENDING, &ua->flags)) ++ complete(&ua->complete); ++ if (cci & UCSI_CCI_COMMAND_COMPLETE && ++ test_bit(COMMAND_PENDING, &ua->flags)) + complete(&ua->complete); + } + -- 2.47.3