]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
5.15-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 18 Feb 2024 19:01:37 +0000 (20:01 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 18 Feb 2024 19:01:37 +0000 (20:01 +0100)
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

15 files changed:
queue-5.15/alsa-hda-realtek-enable-mute-led-on-hp-laptop-14-fq0xxx.patch [new file with mode: 0644]
queue-5.15/alsa-hda-realtek-fix-the-external-mic-not-being-recognised-for-acer-swift-1-sf114-32.patch [new file with mode: 0644]
queue-5.15/hid-i2c-hid-of-fix-null-deref-on-failed-power-up.patch [new file with mode: 0644]
queue-5.15/hid-wacom-do-not-register-input-devices-until-after-hid_hw_start.patch [new file with mode: 0644]
queue-5.15/hid-wacom-generic-avoid-reporting-a-serial-of-0-to-userspace.patch [new file with mode: 0644]
queue-5.15/iio-hid-sensor-als-return-0-for-hid_usage_sensor_time_timestamp.patch [new file with mode: 0644]
queue-5.15/mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch [new file with mode: 0644]
queue-5.15/scs-add-config_mmu-dependency-for-vfree_atomic.patch [new file with mode: 0644]
queue-5.15/scsi-storvsc-fix-ring-buffer-size-calculation.patch [new file with mode: 0644]
queue-5.15/series
queue-5.15/tracing-trigger-fix-to-return-error-if-failed-to-alloc-snapshot.patch [new file with mode: 0644]
queue-5.15/usb-dwc3-gadget-fix-null-pointer-dereference-in-dwc3_gadget_suspend.patch [new file with mode: 0644]
queue-5.15/usb-f_mass_storage-forbid-async-queue-when-shutdown-happen.patch [new file with mode: 0644]
queue-5.15/usb-hub-check-for-alternate-port-before-enabling-a_alt_hnp_support.patch [new file with mode: 0644]
queue-5.15/usb-ucsi_acpi-fix-command-completion-handling.patch [new file with mode: 0644]

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 (file)
index 0000000..bfd5581
--- /dev/null
@@ -0,0 +1,31 @@
+From f0d78972f27dc1d1d51fbace2713ad3cdc60a877 Mon Sep 17 00:00:00 2001
+From: Luka Guzenko <l.guzenko@web.de>
+Date: Sun, 28 Jan 2024 16:57:04 +0100
+Subject: ALSA: hda/realtek: Enable Mute LED on HP Laptop 14-fq0xxx
+
+From: Luka Guzenko <l.guzenko@web.de>
+
+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 <l.guzenko@web.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20240128155704.2333812-1-l.guzenko@web.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..8a370a6
--- /dev/null
@@ -0,0 +1,33 @@
+From efb56d84dd9c3de3c99fc396abb57c6d330038b5 Mon Sep 17 00:00:00 2001
+From: David Senoner <seda18@rolmail.net>
+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 <seda18@rolmail.net>
+
+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 <seda18@rolmail.net>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20240126155626.2304465-1-seda18@rolmail.net
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..a82476e
--- /dev/null
@@ -0,0 +1,34 @@
+From 00aab7dcb2267f2aef59447602f34501efe1a07f Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan+linaro@kernel.org>
+Date: Fri, 26 Jan 2024 18:09:01 +0100
+Subject: HID: i2c-hid-of: fix NULL-deref on failed power up
+
+From: Johan Hovold <johan+linaro@kernel.org>
+
+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 <dianders@chromium.org>
+Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..fcad385
--- /dev/null
@@ -0,0 +1,147 @@
+From c1d6708bf0d3dd976460d435373cf5abf21ce258 Mon Sep 17 00:00:00 2001
+From: Jason Gerecke <killertofu@gmail.com>
+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 <killertofu@gmail.com>
+
+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 <dmitry.torokhov@gmail.com>
+Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
+Tested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..16c98bb
--- /dev/null
@@ -0,0 +1,50 @@
+From ab41a31dd5e2681803642b6d08590b61867840ec Mon Sep 17 00:00:00 2001
+From: Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com>
+Date: Thu, 1 Feb 2024 13:40:55 +0900
+Subject: HID: wacom: generic: Avoid reporting a serial of '0' to userspace
+
+From: Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com>
+
+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 <jason.gerecke@wacom.com>
+Signed-off-by: Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com>
+Fixes: f85c9dc678a5 ("HID: wacom: generic: Support tool ID and additional tool types")
+CC: stable@vger.kernel.org # v4.10
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..49d5a6d
--- /dev/null
@@ -0,0 +1,34 @@
+From 621c6257128149e45b36ffb973a01c3f3461b893 Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+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 <srinivas.pandruvada@linux.intel.com>
+
+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 <srinivas.pandruvada@linux.intel.com>
+Link: https://lore.kernel.org/r/20240204125617.2635574-1-srinivas.pandruvada@linux.intel.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/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 (file)
index 0000000..2635e6e
--- /dev/null
@@ -0,0 +1,46 @@
+From 9319b647902cbd5cc884ac08a8a6d54ce111fc78 Mon Sep 17 00:00:00 2001
+From: Zach O'Keefe <zokeefe@google.com>
+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 <zokeefe@google.com>
+
+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 <zokeefe@google.com>
+Cc: Maxim Patlasov <MPatlasov@parallels.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..38a4cd5
--- /dev/null
@@ -0,0 +1,37 @@
+From 6f9dc684cae638dda0570154509884ee78d0f75c Mon Sep 17 00:00:00 2001
+From: Samuel Holland <samuel.holland@sifive.com>
+Date: Mon, 22 Jan 2024 09:52:01 -0800
+Subject: scs: add CONFIG_MMU dependency for vfree_atomic()
+
+From: Samuel Holland <samuel.holland@sifive.com>
+
+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 <samuel.holland@sifive.com>
+Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
+Cc: Will Deacon <will@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..2b991cf
--- /dev/null
@@ -0,0 +1,83 @@
+From f4469f3858352ad1197434557150b1f7086762a0 Mon Sep 17 00:00:00 2001
+From: Michael Kelley <mhklinux@outlook.com>
+Date: Mon, 22 Jan 2024 09:09:56 -0800
+Subject: scsi: storvsc: Fix ring buffer size calculation
+
+From: Michael Kelley <mhklinux@outlook.com>
+
+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 <mhklinux@outlook.com>
+Link: https://lore.kernel.org/r/20240122170956.496436-1-mhklinux@outlook.com
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)));
index cee963e7b8b4f8fdcb5b56c7db976f64448537be..96948b4be89b13db768c8dc091769bde4f20bd01 100644 (file)
@@ -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 (file)
index 0000000..d780f72
--- /dev/null
@@ -0,0 +1,40 @@
+From 0958b33ef5a04ed91f61cef4760ac412080c4e08 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+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) <mhiramat@kernel.org>
+
+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 <vdonnefort@google.com>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..2cb7094
--- /dev/null
@@ -0,0 +1,58 @@
+From 61a348857e869432e6a920ad8ea9132e8d44c316 Mon Sep 17 00:00:00 2001
+From: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
+Date: Fri, 19 Jan 2024 15:18:25 +0530
+Subject: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend
+
+From: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
+
+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 <Thinh.Nguyen@synopsys.com>
+Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
+Link: https://lore.kernel.org/r/20240119094825.26530-1-quic_uaggarwa@quicinc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..7654e56
--- /dev/null
@@ -0,0 +1,71 @@
+From b2d2d7ea0dd09802cf5a0545bf54d8ad8987d20c Mon Sep 17 00:00:00 2001
+From: yuan linyu <yuanlinyu@hihonor.com>
+Date: Tue, 23 Jan 2024 11:48:29 +0800
+Subject: usb: f_mass_storage: forbid async queue when shutdown happen
+
+From: yuan linyu <yuanlinyu@hihonor.com>
+
+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 <stable@kernel.org>
+Signed-off-by: yuan linyu <yuanlinyu@hihonor.com>
+Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/20240123034829.3848409-1-yuanlinyu@hihonor.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..7bb0820
--- /dev/null
@@ -0,0 +1,79 @@
+From f17c34ffc792bbb520e4b61baa16b6cfc7d44b13 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+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 <oneukum@suse.com>
+
+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 <oneukum@suse.com>
+Cc: stable <stable@kernel.org>
+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 <gregkh@linuxfoundation.org>
+---
+ 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 (file)
index 0000000..eac096f
--- /dev/null
@@ -0,0 +1,75 @@
+From 2840143e393a4ddc1caab4372969ea337371168c Mon Sep 17 00:00:00 2001
+From: "Christian A. Ehrhardt" <lk@c--e.de>
+Date: Sun, 21 Jan 2024 21:41:22 +0100
+Subject: usb: ucsi_acpi: Fix command completion handling
+
+From: Christian A. Ehrhardt <lk@c--e.de>
+
+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" <lk@c--e.de>
+Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20240121204123.275441-3-lk@c--e.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }