From: Greg Kroah-Hartman Date: Sun, 15 Oct 2023 19:03:31 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.15.136~29 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e12f1c36ceb3fc8ab72d7afec89512cd95b8ed98;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: ceph-fix-incorrect-revoked-caps-assert-in-ceph_fill_file_size.patch ceph-fix-type-promotion-bug-on-32bit-systems.patch cgroup-remove-duplicates-in-cgroup-v1-tasks-file.patch counter-microchip-tcb-capture-fix-the-use-of-internal-gclk-logic.patch dmaengine-stm32-mdma-abort-resume-if-no-ongoing-transfer.patch iio-pressure-bmp280-fix-null-pointer-exception.patch iio-pressure-dps310-adjust-timeout-settings.patch iio-pressure-ms5611-ms5611_prom_is_valid-false-negative-bug.patch input-goodix-ensure-int-gpio-is-in-input-for-gpio_count-1-gpio_int_idx-0-case.patch input-i8042-add-fujitsu-lifebook-e5411-to-i8042-quirk-table.patch input-powermate-fix-use-after-free-in-powermate_config_complete.patch input-psmouse-fix-fast_reconnect-function-for-ps-2-mode.patch input-xpad-add-pxn-v900-support.patch libceph-use-kernel_connect.patch mcb-remove-is_added-flag-from-mcb_device-struct.patch net-usb-dm9601-fix-uninitialized-variable-use-in-dm9601_mdio_read.patch pinctrl-avoid-unsafe-code-pattern-in-find_pinctrl.patch tee-amdtee-fix-use-after-free-vulnerability-in-amdtee_close_session.patch thunderbolt-check-that-lane-1-is-in-cl0-before-enabling-lane-bonding.patch usb-dwc3-soft-reset-phy-on-probe-for-host.patch usb-gadget-ncm-handle-decoding-of-multiple-ntb-s-in-unwrap-call.patch usb-gadget-udc-xilinx-replace-memcpy-with-memcpy_toio.patch usb-musb-get-the-musb_qh-poniter-after-musb_giveback.patch usb-musb-modify-the-hwvers-register-address.patch usb-xhci-xhci-ring-use-sysdev-for-mapping-bounce-buffer.patch x86-cpu-fix-amd-erratum-1485-on-zen4-based-cpus.patch --- diff --git a/queue-5.10/ceph-fix-incorrect-revoked-caps-assert-in-ceph_fill_file_size.patch b/queue-5.10/ceph-fix-incorrect-revoked-caps-assert-in-ceph_fill_file_size.patch new file mode 100644 index 00000000000..1aacfa34547 --- /dev/null +++ b/queue-5.10/ceph-fix-incorrect-revoked-caps-assert-in-ceph_fill_file_size.patch @@ -0,0 +1,44 @@ +From 15c0a870dc44ed14e01efbdd319d232234ee639f Mon Sep 17 00:00:00 2001 +From: Xiubo Li +Date: Wed, 6 Sep 2023 14:22:07 +0800 +Subject: ceph: fix incorrect revoked caps assert in ceph_fill_file_size() + +From: Xiubo Li + +commit 15c0a870dc44ed14e01efbdd319d232234ee639f upstream. + +When truncating the inode the MDS will acquire the xlock for the +ifile Locker, which will revoke the 'Frwsxl' caps from the clients. +But when the client just releases and flushes the 'Fw' caps to MDS, +for exmaple, and once the MDS receives the caps flushing msg it +just thought the revocation has finished. Then the MDS will continue +truncating the inode and then issued the truncate notification to +all the clients. While just before the clients receives the cap +flushing ack they receive the truncation notification, the clients +will detecte that the 'issued | dirty' is still holding the 'Fw' +caps. + +Cc: stable@vger.kernel.org +Link: https://tracker.ceph.com/issues/56693 +Fixes: b0d7c2231015 ("ceph: introduce i_truncate_mutex") +Signed-off-by: Xiubo Li +Reviewed-by: Milind Changire +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + fs/ceph/inode.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/fs/ceph/inode.c ++++ b/fs/ceph/inode.c +@@ -635,9 +635,7 @@ int ceph_fill_file_size(struct inode *in + ci->i_truncate_seq = truncate_seq; + + /* the MDS should have revoked these caps */ +- WARN_ON_ONCE(issued & (CEPH_CAP_FILE_EXCL | +- CEPH_CAP_FILE_RD | +- CEPH_CAP_FILE_WR | ++ WARN_ON_ONCE(issued & (CEPH_CAP_FILE_RD | + CEPH_CAP_FILE_LAZYIO)); + /* + * If we hold relevant caps, or in the case where we're diff --git a/queue-5.10/ceph-fix-type-promotion-bug-on-32bit-systems.patch b/queue-5.10/ceph-fix-type-promotion-bug-on-32bit-systems.patch new file mode 100644 index 00000000000..f5cf10cd584 --- /dev/null +++ b/queue-5.10/ceph-fix-type-promotion-bug-on-32bit-systems.patch @@ -0,0 +1,35 @@ +From 07bb00ef00ace88dd6f695fadbba76565756e55c Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Sat, 7 Oct 2023 11:52:39 +0300 +Subject: ceph: fix type promotion bug on 32bit systems + +From: Dan Carpenter + +commit 07bb00ef00ace88dd6f695fadbba76565756e55c upstream. + +In this code "ret" is type long and "src_objlen" is unsigned int. The +problem is that on 32bit systems, when we do the comparison signed longs +are type promoted to unsigned int. So negative error codes from +do_splice_direct() are treated as success instead of failure. + +Cc: stable@vger.kernel.org +Fixes: 1b0c3b9f91f0 ("ceph: re-org copy_file_range and fix some error paths") +Signed-off-by: Dan Carpenter +Reviewed-by: Xiubo Li +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + fs/ceph/file.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/ceph/file.c ++++ b/fs/ceph/file.c +@@ -2428,7 +2428,7 @@ static ssize_t __ceph_copy_file_range(st + ret = do_splice_direct(src_file, &src_off, dst_file, + &dst_off, src_objlen, flags); + /* Abort on short copies or on error */ +- if (ret < src_objlen) { ++ if (ret < (long)src_objlen) { + dout("Failed partial copy (%zd)\n", ret); + goto out; + } diff --git a/queue-5.10/cgroup-remove-duplicates-in-cgroup-v1-tasks-file.patch b/queue-5.10/cgroup-remove-duplicates-in-cgroup-v1-tasks-file.patch new file mode 100644 index 00000000000..b54c8294c43 --- /dev/null +++ b/queue-5.10/cgroup-remove-duplicates-in-cgroup-v1-tasks-file.patch @@ -0,0 +1,52 @@ +From 1ca0b605150501b7dc59f3016271da4eb3e96fce Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Michal=20Koutn=C3=BD?= +Date: Mon, 9 Oct 2023 15:58:11 +0200 +Subject: cgroup: Remove duplicates in cgroup v1 tasks file +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Michal Koutný + +commit 1ca0b605150501b7dc59f3016271da4eb3e96fce upstream. + +One PID may appear multiple times in a preloaded pidlist. +(Possibly due to PID recycling but we have reports of the same +task_struct appearing with different PIDs, thus possibly involving +transfer of PID via de_thread().) + +Because v1 seq_file iterator uses PIDs as position, it leads to +a message: +> seq_file: buggy .next function kernfs_seq_next did not update position index + +Conservative and quick fix consists of removing duplicates from `tasks` +file (as opposed to removing pidlists altogether). It doesn't affect +correctness (it's sufficient to show a PID once), performance impact +would be hidden by unconditional sorting of the pidlist already in place +(asymptotically). + +Link: https://lore.kernel.org/r/20230823174804.23632-1-mkoutny@suse.com/ +Suggested-by: Firo Yang +Signed-off-by: Michal Koutný +Signed-off-by: Tejun Heo +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + kernel/cgroup/cgroup-v1.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/kernel/cgroup/cgroup-v1.c ++++ b/kernel/cgroup/cgroup-v1.c +@@ -361,10 +361,9 @@ static int pidlist_array_load(struct cgr + } + css_task_iter_end(&it); + length = n; +- /* now sort & (if procs) strip out duplicates */ ++ /* now sort & strip out duplicates (tgids or recycled thread PIDs) */ + sort(array, length, sizeof(pid_t), cmppid, NULL); +- if (type == CGROUP_FILE_PROCS) +- length = pidlist_uniq(array, length); ++ length = pidlist_uniq(array, length); + + l = cgroup_pidlist_find_create(cgrp, type); + if (!l) { diff --git a/queue-5.10/counter-microchip-tcb-capture-fix-the-use-of-internal-gclk-logic.patch b/queue-5.10/counter-microchip-tcb-capture-fix-the-use-of-internal-gclk-logic.patch new file mode 100644 index 00000000000..befd02d6e5d --- /dev/null +++ b/queue-5.10/counter-microchip-tcb-capture-fix-the-use-of-internal-gclk-logic.patch @@ -0,0 +1,35 @@ +From df8fdd01c98b99d04915c04f3a5ce73f55456b7c Mon Sep 17 00:00:00 2001 +From: Dharma Balasubiramani +Date: Tue, 5 Sep 2023 15:38:35 +0530 +Subject: counter: microchip-tcb-capture: Fix the use of internal GCLK logic +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Dharma Balasubiramani + +commit df8fdd01c98b99d04915c04f3a5ce73f55456b7c upstream. + +As per the datasheet, the clock selection Bits 2:0 – TCCLKS[2:0] should +be set to 0 while using the internal GCLK (TIMER_CLOCK1). + +Fixes: 106b104137fd ("counter: Add microchip TCB capture counter") +Signed-off-by: Dharma Balasubiramani +Link: https://lore.kernel.org/r/20230905100835.315024-1-dharma.b@microchip.com +Signed-off-by: William Breathitt Gray +Signed-off-by: Greg Kroah-Hartman +--- + drivers/counter/microchip-tcb-capture.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/counter/microchip-tcb-capture.c ++++ b/drivers/counter/microchip-tcb-capture.c +@@ -111,7 +111,7 @@ static int mchp_tc_count_function_set(st + priv->qdec_mode = 0; + /* Set highest rate based on whether soc has gclk or not */ + bmr &= ~(ATMEL_TC_QDEN | ATMEL_TC_POSEN); +- if (priv->tc_cfg->has_gclk) ++ if (!priv->tc_cfg->has_gclk) + cmr |= ATMEL_TC_TIMER_CLOCK2; + else + cmr |= ATMEL_TC_TIMER_CLOCK1; diff --git a/queue-5.10/dmaengine-stm32-mdma-abort-resume-if-no-ongoing-transfer.patch b/queue-5.10/dmaengine-stm32-mdma-abort-resume-if-no-ongoing-transfer.patch new file mode 100644 index 00000000000..f6d3499ad08 --- /dev/null +++ b/queue-5.10/dmaengine-stm32-mdma-abort-resume-if-no-ongoing-transfer.patch @@ -0,0 +1,37 @@ +From 81337b9a72dc58a5fa0ae8a042e8cb59f9bdec4a Mon Sep 17 00:00:00 2001 +From: Amelie Delaunay +Date: Wed, 4 Oct 2023 18:35:28 +0200 +Subject: dmaengine: stm32-mdma: abort resume if no ongoing transfer + +From: Amelie Delaunay + +commit 81337b9a72dc58a5fa0ae8a042e8cb59f9bdec4a upstream. + +chan->desc can be null, if transfer is terminated when resume is called, +leading to a NULL pointer when retrieving the hwdesc. +To avoid this case, check that chan->desc is not null and channel is +disabled (transfer previously paused or terminated). + +Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver") +Signed-off-by: Amelie Delaunay +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20231004163531.2864160-1-amelie.delaunay@foss.st.com +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman +--- + drivers/dma/stm32-mdma.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/dma/stm32-mdma.c ++++ b/drivers/dma/stm32-mdma.c +@@ -1206,6 +1206,10 @@ static int stm32_mdma_resume(struct dma_ + unsigned long flags; + u32 status, reg; + ++ /* Transfer can be terminated */ ++ if (!chan->desc || (stm32_mdma_read(dmadev, STM32_MDMA_CCR(chan->id)) & STM32_MDMA_CCR_EN)) ++ return -EPERM; ++ + hwdesc = chan->desc->node[chan->curr_hwdesc].hwdesc; + + spin_lock_irqsave(&chan->vchan.lock, flags); diff --git a/queue-5.10/iio-pressure-bmp280-fix-null-pointer-exception.patch b/queue-5.10/iio-pressure-bmp280-fix-null-pointer-exception.patch new file mode 100644 index 00000000000..e62265af277 --- /dev/null +++ b/queue-5.10/iio-pressure-bmp280-fix-null-pointer-exception.patch @@ -0,0 +1,35 @@ +From 85dfb43bf69281adb1f345dfd9a39faf2e5a718d Mon Sep 17 00:00:00 2001 +From: Phil Elwell +Date: Fri, 11 Aug 2023 16:58:29 +0100 +Subject: iio: pressure: bmp280: Fix NULL pointer exception + +From: Phil Elwell + +commit 85dfb43bf69281adb1f345dfd9a39faf2e5a718d upstream. + +The bmp085 EOC IRQ support is optional, but the driver's common probe +function queries the IRQ properties whether or not it exists, which +can trigger a NULL pointer exception. Avoid any exception by making +the query conditional on the possession of a valid IRQ. + +Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt") +Signed-off-by: Phil Elwell +Reviewed-by: Linus Walleij +Link: https://lore.kernel.org/r/20230811155829.51208-1-phil@raspberrypi.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/pressure/bmp280-core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/pressure/bmp280-core.c ++++ b/drivers/iio/pressure/bmp280-core.c +@@ -1112,7 +1112,7 @@ int bmp280_common_probe(struct device *d + * however as it happens, the BMP085 shares the chip ID of BMP180 + * so we look for an IRQ if we have that. + */ +- if (irq > 0 || (chip_id == BMP180_CHIP_ID)) { ++ if (irq > 0 && (chip_id == BMP180_CHIP_ID)) { + ret = bmp085_fetch_eoc_irq(dev, name, irq, data); + if (ret) + return ret; diff --git a/queue-5.10/iio-pressure-dps310-adjust-timeout-settings.patch b/queue-5.10/iio-pressure-dps310-adjust-timeout-settings.patch new file mode 100644 index 00000000000..d0f100eb2f8 --- /dev/null +++ b/queue-5.10/iio-pressure-dps310-adjust-timeout-settings.patch @@ -0,0 +1,55 @@ +From 901a293fd96fb9bab843ba4cc7be3094a5aa7c94 Mon Sep 17 00:00:00 2001 +From: Lakshmi Yadlapati +Date: Tue, 29 Aug 2023 13:02:22 -0500 +Subject: iio: pressure: dps310: Adjust Timeout Settings + +From: Lakshmi Yadlapati + +commit 901a293fd96fb9bab843ba4cc7be3094a5aa7c94 upstream. + +The DPS310 sensor chip has been encountering intermittent errors while +reading the sensor device across various system designs. This issue causes +the chip to become "stuck," preventing the indication of "ready" status +for pressure and temperature measurements in the MEAS_CFG register. + +To address this issue, this commit fixes the timeout settings to improve +sensor stability: +- After sending a reset command to the chip, the timeout has been extended + from 2.5 ms to 15 ms, aligning with the DPS310 specification. +- The read timeout value of the MEAS_CFG register has been adjusted from + 20ms to 30ms to match the specification. + +Signed-off-by: Lakshmi Yadlapati +Fixes: 7b4ab4abcea4 ("iio: pressure: dps310: Reset chip after timeout") +Link: https://lore.kernel.org/r/20230829180222.3431926-2-lakshmiy@us.ibm.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/pressure/dps310.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/iio/pressure/dps310.c ++++ b/drivers/iio/pressure/dps310.c +@@ -57,8 +57,8 @@ + #define DPS310_RESET_MAGIC 0x09 + #define DPS310_COEF_BASE 0x10 + +-/* Make sure sleep time is <= 20ms for usleep_range */ +-#define DPS310_POLL_SLEEP_US(t) min(20000, (t) / 8) ++/* Make sure sleep time is <= 30ms for usleep_range */ ++#define DPS310_POLL_SLEEP_US(t) min(30000, (t) / 8) + /* Silently handle error in rate value here */ + #define DPS310_POLL_TIMEOUT_US(rc) ((rc) <= 0 ? 1000000 : 1000000 / (rc)) + +@@ -402,8 +402,8 @@ static int dps310_reset_wait(struct dps3 + if (rc) + return rc; + +- /* Wait for device chip access: 2.5ms in specification */ +- usleep_range(2500, 12000); ++ /* Wait for device chip access: 15ms in specification */ ++ usleep_range(15000, 55000); + return 0; + } + diff --git a/queue-5.10/iio-pressure-ms5611-ms5611_prom_is_valid-false-negative-bug.patch b/queue-5.10/iio-pressure-ms5611-ms5611_prom_is_valid-false-negative-bug.patch new file mode 100644 index 00000000000..30844b4801b --- /dev/null +++ b/queue-5.10/iio-pressure-ms5611-ms5611_prom_is_valid-false-negative-bug.patch @@ -0,0 +1,50 @@ +From fd39d9668f2ce9f4b05ad55e8c8d80c098073e0b Mon Sep 17 00:00:00 2001 +From: Alexander Zangerl +Date: Wed, 20 Sep 2023 10:01:10 +1000 +Subject: iio: pressure: ms5611: ms5611_prom_is_valid false negative bug + +From: Alexander Zangerl + +commit fd39d9668f2ce9f4b05ad55e8c8d80c098073e0b upstream. + +The ms5611 driver falsely rejects lots of MS5607-02BA03-50 chips +with "PROM integrity check failed" because it doesn't accept a prom crc +value of zero as legitimate. + +According to the datasheet for this chip (and the manufacturer's +application note about the PROM CRC), none of the possible values for the +CRC are excluded - but the current code in ms5611_prom_is_valid() ends with + +return crc_orig != 0x0000 && crc == crc_orig + +Discussed with the driver author (Tomasz Duszynski) and he indicated that +at that time (2015) he was dealing with some faulty chip samples which +returned blank data under some circumstances and/or followed example code +which indicated CRC zero being bad. + +As far as I can tell this exception should not be applied anymore; We've +got a few hundred custom boards here with this chip where large numbers +of the prom have a legitimate CRC value 0, and do work fine, but which the +current driver code wrongly rejects. + +Signed-off-by: Alexander Zangerl +Fixes: c0644160a8b5 ("iio: pressure: add support for MS5611 pressure and temperature sensor") +Link: https://lore.kernel.org/r/2535-1695168070.831792@Ze3y.dhYT.s3fx +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/pressure/ms5611_core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/pressure/ms5611_core.c ++++ b/drivers/iio/pressure/ms5611_core.c +@@ -76,7 +76,7 @@ static bool ms5611_prom_is_valid(u16 *pr + + crc = (crc >> 12) & 0x000F; + +- return crc_orig != 0x0000 && crc == crc_orig; ++ return crc == crc_orig; + } + + static int ms5611_read_prom(struct iio_dev *indio_dev) diff --git a/queue-5.10/input-goodix-ensure-int-gpio-is-in-input-for-gpio_count-1-gpio_int_idx-0-case.patch b/queue-5.10/input-goodix-ensure-int-gpio-is-in-input-for-gpio_count-1-gpio_int_idx-0-case.patch new file mode 100644 index 00000000000..4b823e0cc9e --- /dev/null +++ b/queue-5.10/input-goodix-ensure-int-gpio-is-in-input-for-gpio_count-1-gpio_int_idx-0-case.patch @@ -0,0 +1,87 @@ +From 423622a90abb243944d1517b9f57db53729e45c4 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Wed, 4 Oct 2023 07:18:31 -0700 +Subject: Input: goodix - ensure int GPIO is in input for gpio_count == 1 && gpio_int_idx == 0 case + +From: Hans de Goede + +commit 423622a90abb243944d1517b9f57db53729e45c4 upstream. + +Add a special case for gpio_count == 1 && gpio_int_idx == 0 to +goodix_add_acpi_gpio_mappings(). + +It seems that on newer x86/ACPI devices the reset and irq GPIOs are no +longer listed as GPIO resources instead there is only 1 GpioInt resource +and _PS0 does the whole reset sequence for us. + +This means that we must call acpi_device_fix_up_power() on these devices +to ensure that the chip is reset before we try to use it. + +This part was already fixed in commit 3de93e6ed2df ("Input: goodix - call +acpi_device_fix_up_power() in some cases") by adding a call to +acpi_device_fix_up_power() to the generic "Unexpected ACPI resources" +catch all. + +But it turns out that this case on some hw needs some more special +handling. Specifically the firmware may bootup with the IRQ pin in +output mode. The reset sequence from ACPI _PS0 (executed by +acpi_device_fix_up_power()) should put the pin in input mode, +but the GPIO subsystem has cached the direction at bootup, causing +request_irq() to fail due to gpiochip_lock_as_irq() failure: + +[ 9.119864] Goodix-TS i2c-GDIX1002:00: Unexpected ACPI resources: gpio_count 1, gpio_int_idx 0 +[ 9.317443] Goodix-TS i2c-GDIX1002:00: ID 911, version: 1060 +[ 9.321902] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-5/i2c-GDIX1002:00/input/input8 +[ 9.327840] gpio gpiochip0: (INT3453:00): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ +[ 9.327856] gpio gpiochip0: (INT3453:00): unable to lock HW IRQ 26 for IRQ +[ 9.327861] genirq: Failed to request resources for GDIX1002:00 (irq 131) on irqchip intel-gpio +[ 9.327912] Goodix-TS i2c-GDIX1002:00: request IRQ failed: -5 + +Fix this by adding a special case for gpio_count == 1 && gpio_int_idx == 0 +which adds an ACPI GPIO lookup table for the int GPIO even though we cannot +use it for reset purposes (as there is no reset GPIO). + +Adding the lookup will make the gpiod_int = gpiod_get(..., GPIOD_IN) call +succeed, which will explicitly set the direction to input fixing the issue. + +Note this re-uses the acpi_goodix_int_first_gpios[] lookup table, since +there is only 1 GPIO in the ACPI resources the reset entry in that +lookup table will amount to a no-op. + +Reported-and-tested-by: Michael Smith <1973.mjsmith@gmail.com> +Signed-off-by: Hans de Goede +Link: https://lore.kernel.org/r/20231003215144.69527-1-hdegoede@redhat.com +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/touchscreen/goodix.c | 19 +++++++++++++++++++ + 1 file changed, 19 insertions(+) + +--- a/drivers/input/touchscreen/goodix.c ++++ b/drivers/input/touchscreen/goodix.c +@@ -820,6 +820,25 @@ static int goodix_add_acpi_gpio_mappings + dev_info(dev, "No ACPI GpioInt resource, assuming that the GPIO order is reset, int\n"); + ts->irq_pin_access_method = IRQ_PIN_ACCESS_ACPI_GPIO; + gpio_mapping = acpi_goodix_int_last_gpios; ++ } else if (ts->gpio_count == 1 && ts->gpio_int_idx == 0) { ++ /* ++ * On newer devices there is only 1 GpioInt resource and _PS0 ++ * does the whole reset sequence for us. ++ */ ++ acpi_device_fix_up_power(ACPI_COMPANION(dev)); ++ ++ /* ++ * Before the _PS0 call the int GPIO may have been in output ++ * mode and the call should have put the int GPIO in input mode, ++ * but the GPIO subsys cached state may still think it is ++ * in output mode, causing gpiochip_lock_as_irq() failure. ++ * ++ * Add a mapping for the int GPIO to make the ++ * gpiod_int = gpiod_get(..., GPIOD_IN) call succeed, ++ * which will explicitly set the direction to input. ++ */ ++ ts->irq_pin_access_method = IRQ_PIN_ACCESS_NONE; ++ gpio_mapping = acpi_goodix_int_first_gpios; + } else { + dev_warn(dev, "Unexpected ACPI resources: gpio_count %d, gpio_int_idx %d\n", + ts->gpio_count, ts->gpio_int_idx); diff --git a/queue-5.10/input-i8042-add-fujitsu-lifebook-e5411-to-i8042-quirk-table.patch b/queue-5.10/input-i8042-add-fujitsu-lifebook-e5411-to-i8042-quirk-table.patch new file mode 100644 index 00000000000..ff13d9703e5 --- /dev/null +++ b/queue-5.10/input-i8042-add-fujitsu-lifebook-e5411-to-i8042-quirk-table.patch @@ -0,0 +1,47 @@ +From 80f39e1c27ba9e5a1ea7e68e21c569c9d8e46062 Mon Sep 17 00:00:00 2001 +From: Szilard Fabian +Date: Wed, 4 Oct 2023 05:47:01 -0700 +Subject: Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table + +From: Szilard Fabian + +commit 80f39e1c27ba9e5a1ea7e68e21c569c9d8e46062 upstream. + +In the initial boot stage the integrated keyboard of Fujitsu Lifebook E5411 +refuses to work and it's not possible to type for example a dm-crypt +passphrase without the help of an external keyboard. + +i8042.nomux kernel parameter resolves this issue but using that a PS/2 +mouse is detected. This input device is unused even when the i2c-hid-acpi +kernel module is blacklisted making the integrated ELAN touchpad +(04F3:308A) not working at all. + +Since the integrated touchpad is managed by the i2c_designware input +driver in the Linux kernel and you can't find a PS/2 mouse port on the +computer I think it's safe to not use the PS/2 mouse port at all. + +Signed-off-by: Szilard Fabian +Link: https://lore.kernel.org/r/20231004011749.101789-1-szfabian@bluemarch.art +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/serio/i8042-acpipnpio.h | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/input/serio/i8042-acpipnpio.h ++++ b/drivers/input/serio/i8042-acpipnpio.h +@@ -610,6 +610,14 @@ static const struct dmi_system_id i8042_ + .driver_data = (void *)(SERIO_QUIRK_NOMUX) + }, + { ++ /* Fujitsu Lifebook E5411 */ ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU CLIENT COMPUTING LIMITED"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E5411"), ++ }, ++ .driver_data = (void *)(SERIO_QUIRK_NOAUX) ++ }, ++ { + /* Gigabyte M912 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"), diff --git a/queue-5.10/input-powermate-fix-use-after-free-in-powermate_config_complete.patch b/queue-5.10/input-powermate-fix-use-after-free-in-powermate_config_complete.patch new file mode 100644 index 00000000000..71610951b72 --- /dev/null +++ b/queue-5.10/input-powermate-fix-use-after-free-in-powermate_config_complete.patch @@ -0,0 +1,39 @@ +From 5c15c60e7be615f05a45cd905093a54b11f461bc Mon Sep 17 00:00:00 2001 +From: Javier Carrasco +Date: Fri, 13 Oct 2023 20:11:33 -0700 +Subject: Input: powermate - fix use-after-free in powermate_config_complete + +From: Javier Carrasco + +commit 5c15c60e7be615f05a45cd905093a54b11f461bc upstream. + +syzbot has found a use-after-free bug [1] in the powermate driver. This +happens when the device is disconnected, which leads to a memory free from +the powermate_device struct. When an asynchronous control message +completes after the kfree and its callback is invoked, the lock does not +exist anymore and hence the bug. + +Use usb_kill_urb() on pm->config to cancel any in-progress requests upon +device disconnection. + +[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e + +Signed-off-by: Javier Carrasco +Reported-by: syzbot+0434ac83f907a1dbdd1e@syzkaller.appspotmail.com +Link: https://lore.kernel.org/r/20230916-topic-powermate_use_after_free-v3-1-64412b81a7a2@gmail.com +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/misc/powermate.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/input/misc/powermate.c ++++ b/drivers/input/misc/powermate.c +@@ -425,6 +425,7 @@ static void powermate_disconnect(struct + pm->requires_update = 0; + usb_kill_urb(pm->irq); + input_unregister_device(pm->input); ++ usb_kill_urb(pm->config); + usb_free_urb(pm->irq); + usb_free_urb(pm->config); + powermate_free_buffers(interface_to_usbdev(intf), pm); diff --git a/queue-5.10/input-psmouse-fix-fast_reconnect-function-for-ps-2-mode.patch b/queue-5.10/input-psmouse-fix-fast_reconnect-function-for-ps-2-mode.patch new file mode 100644 index 00000000000..e0e474f6748 --- /dev/null +++ b/queue-5.10/input-psmouse-fix-fast_reconnect-function-for-ps-2-mode.patch @@ -0,0 +1,58 @@ +From e2cb5cc822b6c9ee72c56ce1d81671b22c05406a Mon Sep 17 00:00:00 2001 +From: Jeffery Miller +Date: Fri, 13 Oct 2023 15:23:49 -0700 +Subject: Input: psmouse - fix fast_reconnect function for PS/2 mode + +From: Jeffery Miller + +commit e2cb5cc822b6c9ee72c56ce1d81671b22c05406a upstream. + +When the SMBus connection is attempted psmouse_smbus_init() sets +the fast_reconnect pointer to psmouse_smbus_reconnecti(). If SMBus +initialization fails, elantech_setup_ps2() and synaptics_init_ps2() will +fallback to PS/2 mode, replacing the psmouse private data. This can cause +issues on resume, since psmouse_smbus_reconnect() expects to find an +instance of struct psmouse_smbus_dev in psmouse->private. + +The issue was uncovered when in 92e24e0e57f7 ("Input: psmouse - add +delay when deactivating for SMBus mode") psmouse_smbus_reconnect() +started attempting to use more of the data structure. The commit was +since reverted, not because it was at fault, but because there was found +a better way of doing what it was attempting to do. + +Fix the problem by resetting the fast_reconnect pointer in psmouse +structure in elantech_setup_ps2() and synaptics_init_ps2() when the PS/2 +mode is used. + +Reported-by: Thorsten Leemhuis +Tested-by: Thorsten Leemhuis +Signed-off-by: Jeffery Miller +Fixes: bf232e460a35 ("Input: psmouse-smbus - allow to control psmouse_deactivate") +Link: https://lore.kernel.org/r/20231005002249.554877-1-jefferymiller@google.com +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/mouse/elantech.c | 1 + + drivers/input/mouse/synaptics.c | 1 + + 2 files changed, 2 insertions(+) + +--- a/drivers/input/mouse/elantech.c ++++ b/drivers/input/mouse/elantech.c +@@ -2112,6 +2112,7 @@ static int elantech_setup_ps2(struct psm + psmouse->protocol_handler = elantech_process_byte; + psmouse->disconnect = elantech_disconnect; + psmouse->reconnect = elantech_reconnect; ++ psmouse->fast_reconnect = NULL; + psmouse->pktsize = info->hw_version > 1 ? 6 : 4; + + return 0; +--- a/drivers/input/mouse/synaptics.c ++++ b/drivers/input/mouse/synaptics.c +@@ -1619,6 +1619,7 @@ static int synaptics_init_ps2(struct psm + psmouse->set_rate = synaptics_set_rate; + psmouse->disconnect = synaptics_disconnect; + psmouse->reconnect = synaptics_reconnect; ++ psmouse->fast_reconnect = NULL; + psmouse->cleanup = synaptics_reset; + /* Synaptics can usually stay in sync without extra help */ + psmouse->resync_time = 0; diff --git a/queue-5.10/input-xpad-add-pxn-v900-support.patch b/queue-5.10/input-xpad-add-pxn-v900-support.patch new file mode 100644 index 00000000000..666525dca77 --- /dev/null +++ b/queue-5.10/input-xpad-add-pxn-v900-support.patch @@ -0,0 +1,38 @@ +From a65cd7ef5a864bdbbe037267c327786b7759d4c6 Mon Sep 17 00:00:00 2001 +From: Matthias Berndt +Date: Fri, 13 Oct 2023 15:04:36 -0700 +Subject: Input: xpad - add PXN V900 support + +From: Matthias Berndt + +commit a65cd7ef5a864bdbbe037267c327786b7759d4c6 upstream. + +Add VID and PID to the xpad_device table to allow driver to use the PXN +V900 steering wheel, which is XTYPE_XBOX360 compatible in xinput mode. + +Signed-off-by: Matthias Berndt +Link: https://lore.kernel.org/r/4932699.31r3eYUQgx@fedora +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/joystick/xpad.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/input/joystick/xpad.c ++++ b/drivers/input/joystick/xpad.c +@@ -252,6 +252,7 @@ static const struct xpad_device { + { 0x1038, 0x1430, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 }, + { 0x1038, 0x1431, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 }, + { 0x11c9, 0x55f0, "Nacon GC-100XF", 0, XTYPE_XBOX360 }, ++ { 0x11ff, 0x0511, "PXN V900", 0, XTYPE_XBOX360 }, + { 0x1209, 0x2882, "Ardwiino Controller", 0, XTYPE_XBOX360 }, + { 0x12ab, 0x0004, "Honey Bee Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 }, + { 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 }, +@@ -446,6 +447,7 @@ static const struct usb_device_id xpad_t + XPAD_XBOXONE_VENDOR(0x0f0d), /* Hori Controllers */ + XPAD_XBOX360_VENDOR(0x1038), /* SteelSeries Controllers */ + XPAD_XBOX360_VENDOR(0x11c9), /* Nacon GC100XF */ ++ XPAD_XBOX360_VENDOR(0x11ff), /* PXN V900 */ + XPAD_XBOX360_VENDOR(0x1209), /* Ardwiino Controllers */ + XPAD_XBOX360_VENDOR(0x12ab), /* X-Box 360 dance pads */ + XPAD_XBOX360_VENDOR(0x1430), /* RedOctane X-Box 360 controllers */ diff --git a/queue-5.10/libceph-use-kernel_connect.patch b/queue-5.10/libceph-use-kernel_connect.patch new file mode 100644 index 00000000000..e561dac5b12 --- /dev/null +++ b/queue-5.10/libceph-use-kernel_connect.patch @@ -0,0 +1,46 @@ +From 7563cf17dce0a875ba3d872acdc63a78ea344019 Mon Sep 17 00:00:00 2001 +From: Jordan Rife +Date: Wed, 4 Oct 2023 18:38:27 -0500 +Subject: libceph: use kernel_connect() + +From: Jordan Rife + +commit 7563cf17dce0a875ba3d872acdc63a78ea344019 upstream. + +Direct calls to ops->connect() can overwrite the address parameter when +used in conjunction with BPF SOCK_ADDR hooks. Recent changes to +kernel_connect() ensure that callers are insulated from such side +effects. This patch wraps the direct call to ops->connect() with +kernel_connect() to prevent unexpected changes to the address passed to +ceph_tcp_connect(). + +This change was originally part of a larger patch targeting the net tree +addressing all instances of unprotected calls to ops->connect() +throughout the kernel, but this change was split up into several patches +targeting various trees. + +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/netdev/20230821100007.559638-1-jrife@google.com/ +Link: https://lore.kernel.org/netdev/9944248dba1bce861375fcce9de663934d933ba9.camel@redhat.com/ +Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect") +Signed-off-by: Jordan Rife +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + net/ceph/messenger.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/net/ceph/messenger.c ++++ b/net/ceph/messenger.c +@@ -477,8 +477,8 @@ static int ceph_tcp_connect(struct ceph_ + dout("connect %s\n", ceph_pr_addr(&con->peer_addr)); + + con_sock_state_connecting(con); +- ret = sock->ops->connect(sock, (struct sockaddr *)&ss, sizeof(ss), +- O_NONBLOCK); ++ ret = kernel_connect(sock, (struct sockaddr *)&ss, sizeof(ss), ++ O_NONBLOCK); + if (ret == -EINPROGRESS) { + dout("connect %s EINPROGRESS sk_state = %u\n", + ceph_pr_addr(&con->peer_addr), diff --git a/queue-5.10/mcb-remove-is_added-flag-from-mcb_device-struct.patch b/queue-5.10/mcb-remove-is_added-flag-from-mcb_device-struct.patch new file mode 100644 index 00000000000..21229eb743a --- /dev/null +++ b/queue-5.10/mcb-remove-is_added-flag-from-mcb_device-struct.patch @@ -0,0 +1,79 @@ +From 0f28ada1fbf0054557cddcdb93ad17f767105208 Mon Sep 17 00:00:00 2001 +From: Jorge Sanjuan Garcia +Date: Wed, 6 Sep 2023 11:49:26 +0000 +Subject: mcb: remove is_added flag from mcb_device struct + +From: Jorge Sanjuan Garcia + +commit 0f28ada1fbf0054557cddcdb93ad17f767105208 upstream. + +When calling mcb_bus_add_devices(), both mcb devices and the mcb +bus will attempt to attach a device to a driver because they share +the same bus_type. This causes an issue when trying to cast the +container of the device to mcb_device struct using to_mcb_device(), +leading to a wrong cast when the mcb_bus is added. A crash occurs +when freing the ida resources as the bus numbering of mcb_bus gets +confused with the is_added flag on the mcb_device struct. + +The only reason for this cast was to keep an is_added flag on the +mcb_device struct that does not seem necessary. The function +device_attach() handles already bound devices and the mcb subsystem +does nothing special with this is_added flag so remove it completely. + +Fixes: 18d288198099 ("mcb: Correctly initialize the bus's device") +Cc: stable +Signed-off-by: Jorge Sanjuan Garcia +Co-developed-by: Jose Javier Rodriguez Barbarin +Signed-off-by: Jose Javier Rodriguez Barbarin +Link: https://lore.kernel.org/r/20230906114901.63174-2-JoseJavier.Rodriguez@duagon.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mcb/mcb-core.c | 10 +++------- + drivers/mcb/mcb-parse.c | 2 -- + include/linux/mcb.h | 1 - + 3 files changed, 3 insertions(+), 10 deletions(-) + +--- a/drivers/mcb/mcb-core.c ++++ b/drivers/mcb/mcb-core.c +@@ -389,17 +389,13 @@ EXPORT_SYMBOL_NS_GPL(mcb_free_dev, MCB); + + static int __mcb_bus_add_devices(struct device *dev, void *data) + { +- struct mcb_device *mdev = to_mcb_device(dev); + int retval; + +- if (mdev->is_added) +- return 0; +- + retval = device_attach(dev); +- if (retval < 0) ++ if (retval < 0) { + dev_err(dev, "Error adding device (%d)\n", retval); +- +- mdev->is_added = true; ++ return retval; ++ } + + return 0; + } +--- a/drivers/mcb/mcb-parse.c ++++ b/drivers/mcb/mcb-parse.c +@@ -99,8 +99,6 @@ static int chameleon_parse_gdd(struct mc + mdev->mem.end = mdev->mem.start + size - 1; + mdev->mem.flags = IORESOURCE_MEM; + +- mdev->is_added = false; +- + ret = mcb_device_register(bus, mdev); + if (ret < 0) + goto err; +--- a/include/linux/mcb.h ++++ b/include/linux/mcb.h +@@ -63,7 +63,6 @@ static inline struct mcb_bus *to_mcb_bus + struct mcb_device { + struct device dev; + struct mcb_bus *bus; +- bool is_added; + struct mcb_driver *driver; + u16 id; + int inst; diff --git a/queue-5.10/net-usb-dm9601-fix-uninitialized-variable-use-in-dm9601_mdio_read.patch b/queue-5.10/net-usb-dm9601-fix-uninitialized-variable-use-in-dm9601_mdio_read.patch new file mode 100644 index 00000000000..69d064c6683 --- /dev/null +++ b/queue-5.10/net-usb-dm9601-fix-uninitialized-variable-use-in-dm9601_mdio_read.patch @@ -0,0 +1,54 @@ +From 8f8abb863fa5a4cc18955c6a0e17af0ded3e4a76 Mon Sep 17 00:00:00 2001 +From: Javier Carrasco +Date: Tue, 10 Oct 2023 00:26:14 +0200 +Subject: net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read + +From: Javier Carrasco + +commit 8f8abb863fa5a4cc18955c6a0e17af0ded3e4a76 upstream. + +syzbot has found an uninit-value bug triggered by the dm9601 driver [1]. + +This error happens because the variable res is not updated if the call +to dm_read_shared_word returns an error. In this particular case -EPROTO +was returned and res stayed uninitialized. + +This can be avoided by checking the return value of dm_read_shared_word +and propagating the error if the read operation failed. + +[1] https://syzkaller.appspot.com/bug?extid=1f53a30781af65d2c955 + +Cc: stable@vger.kernel.org +Signed-off-by: Javier Carrasco +Reported-and-tested-by: syzbot+1f53a30781af65d2c955@syzkaller.appspotmail.com +Acked-by: Peter Korsgaard +Fixes: d0374f4f9c35cdfbee0 ("USB: Davicom DM9601 usbnet driver") +Link: https://lore.kernel.org/r/20231009-topic-dm9601_uninit_mdio_read-v2-1-f2fe39739b6c@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/usb/dm9601.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/net/usb/dm9601.c ++++ b/drivers/net/usb/dm9601.c +@@ -221,13 +221,18 @@ static int dm9601_mdio_read(struct net_d + struct usbnet *dev = netdev_priv(netdev); + + __le16 res; ++ int err; + + if (phy_id) { + netdev_dbg(dev->net, "Only internal phy supported\n"); + return 0; + } + +- dm_read_shared_word(dev, 1, loc, &res); ++ err = dm_read_shared_word(dev, 1, loc, &res); ++ if (err < 0) { ++ netdev_err(dev->net, "MDIO read error: %d\n", err); ++ return err; ++ } + + netdev_dbg(dev->net, + "dm9601_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x\n", diff --git a/queue-5.10/pinctrl-avoid-unsafe-code-pattern-in-find_pinctrl.patch b/queue-5.10/pinctrl-avoid-unsafe-code-pattern-in-find_pinctrl.patch new file mode 100644 index 00000000000..24f73f2c740 --- /dev/null +++ b/queue-5.10/pinctrl-avoid-unsafe-code-pattern-in-find_pinctrl.patch @@ -0,0 +1,63 @@ +From c153a4edff6ab01370fcac8e46f9c89cca1060c2 Mon Sep 17 00:00:00 2001 +From: Dmitry Torokhov +Date: Wed, 20 Sep 2023 11:09:10 -0700 +Subject: pinctrl: avoid unsafe code pattern in find_pinctrl() + +From: Dmitry Torokhov + +commit c153a4edff6ab01370fcac8e46f9c89cca1060c2 upstream. + +The code in find_pinctrl() takes a mutex and traverses a list of pinctrl +structures. Later the caller bumps up reference count on the found +structure. Such pattern is not safe as pinctrl that was found may get +deleted before the caller gets around to increasing the reference count. + +Fix this by taking the reference count in find_pinctrl(), while it still +holds the mutex. + +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Link: https://lore.kernel.org/r/ZQs1RgTKg6VJqmPs@google.com +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pinctrl/core.c | 16 +++++++++------- + 1 file changed, 9 insertions(+), 7 deletions(-) + +--- a/drivers/pinctrl/core.c ++++ b/drivers/pinctrl/core.c +@@ -1007,17 +1007,20 @@ static int add_setting(struct pinctrl *p + + static struct pinctrl *find_pinctrl(struct device *dev) + { +- struct pinctrl *p; ++ struct pinctrl *entry, *p = NULL; + + mutex_lock(&pinctrl_list_mutex); +- list_for_each_entry(p, &pinctrl_list, node) +- if (p->dev == dev) { +- mutex_unlock(&pinctrl_list_mutex); +- return p; ++ ++ list_for_each_entry(entry, &pinctrl_list, node) { ++ if (entry->dev == dev) { ++ p = entry; ++ kref_get(&p->users); ++ break; + } ++ } + + mutex_unlock(&pinctrl_list_mutex); +- return NULL; ++ return p; + } + + static void pinctrl_free(struct pinctrl *p, bool inlist); +@@ -1126,7 +1129,6 @@ struct pinctrl *pinctrl_get(struct devic + p = find_pinctrl(dev); + if (p) { + dev_dbg(dev, "obtain a copy of previously claimed pinctrl\n"); +- kref_get(&p->users); + return p; + } + diff --git a/queue-5.10/series b/queue-5.10/series index d2f0b0fa403..79a0d7f1fd7 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -33,3 +33,29 @@ net-add-sysctl-accept_ra_min_rtr_lft.patch net-change-accept_ra_min_rtr_lft-to-affect-all-ra-lifetimes.patch net-release-reference-to-inet6_dev-pointer.patch media-mtk-jpeg-fix-use-after-free-bug-due-to-uncanceled-work.patch +dmaengine-stm32-mdma-abort-resume-if-no-ongoing-transfer.patch +usb-xhci-xhci-ring-use-sysdev-for-mapping-bounce-buffer.patch +net-usb-dm9601-fix-uninitialized-variable-use-in-dm9601_mdio_read.patch +usb-dwc3-soft-reset-phy-on-probe-for-host.patch +usb-musb-get-the-musb_qh-poniter-after-musb_giveback.patch +usb-musb-modify-the-hwvers-register-address.patch +iio-pressure-bmp280-fix-null-pointer-exception.patch +iio-pressure-dps310-adjust-timeout-settings.patch +iio-pressure-ms5611-ms5611_prom_is_valid-false-negative-bug.patch +x86-cpu-fix-amd-erratum-1485-on-zen4-based-cpus.patch +mcb-remove-is_added-flag-from-mcb_device-struct.patch +thunderbolt-check-that-lane-1-is-in-cl0-before-enabling-lane-bonding.patch +libceph-use-kernel_connect.patch +ceph-fix-incorrect-revoked-caps-assert-in-ceph_fill_file_size.patch +ceph-fix-type-promotion-bug-on-32bit-systems.patch +input-powermate-fix-use-after-free-in-powermate_config_complete.patch +input-psmouse-fix-fast_reconnect-function-for-ps-2-mode.patch +input-xpad-add-pxn-v900-support.patch +input-i8042-add-fujitsu-lifebook-e5411-to-i8042-quirk-table.patch +input-goodix-ensure-int-gpio-is-in-input-for-gpio_count-1-gpio_int_idx-0-case.patch +tee-amdtee-fix-use-after-free-vulnerability-in-amdtee_close_session.patch +cgroup-remove-duplicates-in-cgroup-v1-tasks-file.patch +pinctrl-avoid-unsafe-code-pattern-in-find_pinctrl.patch +counter-microchip-tcb-capture-fix-the-use-of-internal-gclk-logic.patch +usb-gadget-udc-xilinx-replace-memcpy-with-memcpy_toio.patch +usb-gadget-ncm-handle-decoding-of-multiple-ntb-s-in-unwrap-call.patch diff --git a/queue-5.10/tee-amdtee-fix-use-after-free-vulnerability-in-amdtee_close_session.patch b/queue-5.10/tee-amdtee-fix-use-after-free-vulnerability-in-amdtee_close_session.patch new file mode 100644 index 00000000000..c395f436dfa --- /dev/null +++ b/queue-5.10/tee-amdtee-fix-use-after-free-vulnerability-in-amdtee_close_session.patch @@ -0,0 +1,81 @@ +From f4384b3e54ea813868bb81a861bf5b2406e15d8f Mon Sep 17 00:00:00 2001 +From: Rijo Thomas +Date: Fri, 29 Sep 2023 12:30:24 +0530 +Subject: tee: amdtee: fix use-after-free vulnerability in amdtee_close_session + +From: Rijo Thomas + +commit f4384b3e54ea813868bb81a861bf5b2406e15d8f upstream. + +There is a potential race condition in amdtee_close_session that may +cause use-after-free in amdtee_open_session. For instance, if a session +has refcount == 1, and one thread tries to free this session via: + + kref_put(&sess->refcount, destroy_session); + +the reference count will get decremented, and the next step would be to +call destroy_session(). However, if in another thread, +amdtee_open_session() is called before destroy_session() has completed +execution, alloc_session() may return 'sess' that will be freed up +later in destroy_session() leading to use-after-free in +amdtee_open_session. + +To fix this issue, treat decrement of sess->refcount and removal of +'sess' from session list in destroy_session() as a critical section, so +that it is executed atomically. + +Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") +Cc: stable@vger.kernel.org +Signed-off-by: Rijo Thomas +Reviewed-by: Sumit Garg +Signed-off-by: Jens Wiklander +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tee/amdtee/core.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/drivers/tee/amdtee/core.c ++++ b/drivers/tee/amdtee/core.c +@@ -217,12 +217,12 @@ unlock: + return rc; + } + ++/* mutex must be held by caller */ + static void destroy_session(struct kref *ref) + { + struct amdtee_session *sess = container_of(ref, struct amdtee_session, + refcount); + +- mutex_lock(&session_list_mutex); + list_del(&sess->list_node); + mutex_unlock(&session_list_mutex); + kfree(sess); +@@ -272,7 +272,8 @@ int amdtee_open_session(struct tee_conte + if (arg->ret != TEEC_SUCCESS) { + pr_err("open_session failed %d\n", arg->ret); + handle_unload_ta(ta_handle); +- kref_put(&sess->refcount, destroy_session); ++ kref_put_mutex(&sess->refcount, destroy_session, ++ &session_list_mutex); + goto out; + } + +@@ -290,7 +291,8 @@ int amdtee_open_session(struct tee_conte + pr_err("reached maximum session count %d\n", TEE_NUM_SESSIONS); + handle_close_session(ta_handle, session_info); + handle_unload_ta(ta_handle); +- kref_put(&sess->refcount, destroy_session); ++ kref_put_mutex(&sess->refcount, destroy_session, ++ &session_list_mutex); + rc = -ENOMEM; + goto out; + } +@@ -331,7 +333,7 @@ int amdtee_close_session(struct tee_cont + handle_close_session(ta_handle, session_info); + handle_unload_ta(ta_handle); + +- kref_put(&sess->refcount, destroy_session); ++ kref_put_mutex(&sess->refcount, destroy_session, &session_list_mutex); + + return 0; + } diff --git a/queue-5.10/thunderbolt-check-that-lane-1-is-in-cl0-before-enabling-lane-bonding.patch b/queue-5.10/thunderbolt-check-that-lane-1-is-in-cl0-before-enabling-lane-bonding.patch new file mode 100644 index 00000000000..e730f55dd73 --- /dev/null +++ b/queue-5.10/thunderbolt-check-that-lane-1-is-in-cl0-before-enabling-lane-bonding.patch @@ -0,0 +1,44 @@ +From a9fdf5f933a6f2b358fad0194b1287b67f6704b1 Mon Sep 17 00:00:00 2001 +From: Mika Westerberg +Date: Tue, 22 Aug 2023 16:36:18 +0300 +Subject: thunderbolt: Check that lane 1 is in CL0 before enabling lane bonding +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Mika Westerberg + +commit a9fdf5f933a6f2b358fad0194b1287b67f6704b1 upstream. + +Marek reported that when BlackMagic UltraStudio device is connected the +kernel repeatedly tries to enable lane bonding without success making +the device non-functional. It looks like the device does not have lane 1 +connected at all so even though it is enabled we should not try to bond +the lanes. For this reason check that lane 1 is in fact CL0 (connected, +active) before attempting to bond the lanes. + +Reported-by: Marek Šanta +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217737 +Cc: stable@vger.kernel.org +Signed-off-by: Mika Westerberg +Signed-off-by: Greg Kroah-Hartman +--- + drivers/thunderbolt/switch.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/thunderbolt/switch.c ++++ b/drivers/thunderbolt/switch.c +@@ -2303,6 +2303,13 @@ int tb_switch_lane_bonding_enable(struct + !tb_port_is_width_supported(down, 2)) + return 0; + ++ /* ++ * Both lanes need to be in CL0. Here we assume lane 0 already be in ++ * CL0 and check just for lane 1. ++ */ ++ if (tb_wait_for_port(down->dual_link_port, false) <= 0) ++ return -ENOTCONN; ++ + ret = tb_port_lane_bonding_enable(up); + if (ret) { + tb_port_warn(up, "failed to enable lane bonding\n"); diff --git a/queue-5.10/usb-dwc3-soft-reset-phy-on-probe-for-host.patch b/queue-5.10/usb-dwc3-soft-reset-phy-on-probe-for-host.patch new file mode 100644 index 00000000000..a17c3333909 --- /dev/null +++ b/queue-5.10/usb-dwc3-soft-reset-phy-on-probe-for-host.patch @@ -0,0 +1,82 @@ +From 8bea147dfdf823eaa8d3baeccc7aeb041b41944b Mon Sep 17 00:00:00 2001 +From: Thinh Nguyen +Date: Wed, 13 Sep 2023 00:52:15 +0000 +Subject: usb: dwc3: Soft reset phy on probe for host + +From: Thinh Nguyen + +commit 8bea147dfdf823eaa8d3baeccc7aeb041b41944b upstream. + +When there's phy initialization, we need to initiate a soft-reset +sequence. That's done through USBCMD.HCRST in the xHCI driver and its +initialization, However, the dwc3 driver may modify core configs before +the soft-reset. This may result in some connection instability. So, +ensure the phy is ready before the controller updates the GCTL.PRTCAPDIR +or other settings by issuing phy soft-reset. + +Note that some host-mode configurations may not expose device registers +to initiate the controller soft-reset (via DCTL.CoreSftRst). So we reset +through GUSB3PIPECTL and GUSB2PHYCFG instead. + +Cc: stable@vger.kernel.org +Fixes: e835c0a4e23c ("usb: dwc3: don't reset device side if dwc3 was configured as host-only") +Reported-by: Kenta Sato +Closes: https://lore.kernel.org/linux-usb/ZPUciRLUcjDywMVS@debian.me/ +Signed-off-by: Thinh Nguyen +Tested-by: Kenta Sato +Link: https://lore.kernel.org/r/70aea513215d273669152696cc02b20ddcdb6f1a.1694564261.git.Thinh.Nguyen@synopsys.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/dwc3/core.c | 39 ++++++++++++++++++++++++++++++++++++++- + 1 file changed, 38 insertions(+), 1 deletion(-) + +--- a/drivers/usb/dwc3/core.c ++++ b/drivers/usb/dwc3/core.c +@@ -277,9 +277,46 @@ int dwc3_core_soft_reset(struct dwc3 *dw + * XHCI driver will reset the host block. If dwc3 was configured for + * host-only mode or current role is host, then we can return early. + */ +- if (dwc->dr_mode == USB_DR_MODE_HOST || dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST) ++ if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST) + return 0; + ++ /* ++ * If the dr_mode is host and the dwc->current_dr_role is not the ++ * corresponding DWC3_GCTL_PRTCAP_HOST, then the dwc3_core_init_mode ++ * isn't executed yet. Ensure the phy is ready before the controller ++ * updates the GCTL.PRTCAPDIR or other settings by soft-resetting ++ * the phy. ++ * ++ * Note: GUSB3PIPECTL[n] and GUSB2PHYCFG[n] are port settings where n ++ * is port index. If this is a multiport host, then we need to reset ++ * all active ports. ++ */ ++ if (dwc->dr_mode == USB_DR_MODE_HOST) { ++ u32 usb3_port; ++ u32 usb2_port; ++ ++ usb3_port = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)); ++ usb3_port |= DWC3_GUSB3PIPECTL_PHYSOFTRST; ++ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), usb3_port); ++ ++ usb2_port = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); ++ usb2_port |= DWC3_GUSB2PHYCFG_PHYSOFTRST; ++ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), usb2_port); ++ ++ /* Small delay for phy reset assertion */ ++ usleep_range(1000, 2000); ++ ++ usb3_port &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST; ++ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), usb3_port); ++ ++ usb2_port &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST; ++ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), usb2_port); ++ ++ /* Wait for clock synchronization */ ++ msleep(50); ++ return 0; ++ } ++ + reg = dwc3_readl(dwc->regs, DWC3_DCTL); + reg |= DWC3_DCTL_CSFTRST; + reg &= ~DWC3_DCTL_RUN_STOP; diff --git a/queue-5.10/usb-gadget-ncm-handle-decoding-of-multiple-ntb-s-in-unwrap-call.patch b/queue-5.10/usb-gadget-ncm-handle-decoding-of-multiple-ntb-s-in-unwrap-call.patch new file mode 100644 index 00000000000..a34e99e8c91 --- /dev/null +++ b/queue-5.10/usb-gadget-ncm-handle-decoding-of-multiple-ntb-s-in-unwrap-call.patch @@ -0,0 +1,106 @@ +From 427694cfaafa565a3db5c5ea71df6bc095dca92f Mon Sep 17 00:00:00 2001 +From: Krishna Kurapati +Date: Wed, 27 Sep 2023 16:28:58 +0530 +Subject: usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Krishna Kurapati + +commit 427694cfaafa565a3db5c5ea71df6bc095dca92f upstream. + +When NCM is used with hosts like Windows PC, it is observed that there are +multiple NTB's contained in one usb request giveback. Since the driver +unwraps the obtained request data assuming only one NTB is present, we +loose the subsequent NTB's present resulting in data loss. + +Fix this by checking the parsed block length with the obtained data +length in usb request and continue parsing after the last byte of current +NTB. + +Cc: stable@vger.kernel.org +Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added") +Signed-off-by: Krishna Kurapati +Reviewed-by: Maciej Żenczykowski +Link: https://lore.kernel.org/r/20230927105858.12950-1-quic_kriskura@quicinc.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/gadget/function/f_ncm.c | 26 +++++++++++++++++++------- + 1 file changed, 19 insertions(+), 7 deletions(-) + +--- a/drivers/usb/gadget/function/f_ncm.c ++++ b/drivers/usb/gadget/function/f_ncm.c +@@ -1180,7 +1180,8 @@ static int ncm_unwrap_ntb(struct gether + struct sk_buff_head *list) + { + struct f_ncm *ncm = func_to_ncm(&port->func); +- __le16 *tmp = (void *) skb->data; ++ unsigned char *ntb_ptr = skb->data; ++ __le16 *tmp; + unsigned index, index2; + int ndp_index; + unsigned dg_len, dg_len2; +@@ -1193,6 +1194,10 @@ static int ncm_unwrap_ntb(struct gether + const struct ndp_parser_opts *opts = ncm->parser_opts; + unsigned crc_len = ncm->is_crc ? sizeof(uint32_t) : 0; + int dgram_counter; ++ int to_process = skb->len; ++ ++parse_ntb: ++ tmp = (__le16 *)ntb_ptr; + + /* dwSignature */ + if (get_unaligned_le32(tmp) != opts->nth_sign) { +@@ -1239,7 +1244,7 @@ static int ncm_unwrap_ntb(struct gether + * walk through NDP + * dwSignature + */ +- tmp = (void *)(skb->data + ndp_index); ++ tmp = (__le16 *)(ntb_ptr + ndp_index); + if (get_unaligned_le32(tmp) != ncm->ndp_sign) { + INFO(port->func.config->cdev, "Wrong NDP SIGN\n"); + goto err; +@@ -1296,11 +1301,11 @@ static int ncm_unwrap_ntb(struct gether + if (ncm->is_crc) { + uint32_t crc, crc2; + +- crc = get_unaligned_le32(skb->data + ++ crc = get_unaligned_le32(ntb_ptr + + index + dg_len - + crc_len); + crc2 = ~crc32_le(~0, +- skb->data + index, ++ ntb_ptr + index, + dg_len - crc_len); + if (crc != crc2) { + INFO(port->func.config->cdev, +@@ -1327,7 +1332,7 @@ static int ncm_unwrap_ntb(struct gether + dg_len - crc_len); + if (skb2 == NULL) + goto err; +- skb_put_data(skb2, skb->data + index, ++ skb_put_data(skb2, ntb_ptr + index, + dg_len - crc_len); + + skb_queue_tail(list, skb2); +@@ -1340,10 +1345,17 @@ static int ncm_unwrap_ntb(struct gether + } while (ndp_len > 2 * (opts->dgram_item_len * 2)); + } while (ndp_index); + +- dev_consume_skb_any(skb); +- + VDBG(port->func.config->cdev, + "Parsed NTB with %d frames\n", dgram_counter); ++ ++ to_process -= block_len; ++ if (to_process != 0) { ++ ntb_ptr = (unsigned char *)(ntb_ptr + block_len); ++ goto parse_ntb; ++ } ++ ++ dev_consume_skb_any(skb); ++ + return 0; + err: + skb_queue_purge(list); diff --git a/queue-5.10/usb-gadget-udc-xilinx-replace-memcpy-with-memcpy_toio.patch b/queue-5.10/usb-gadget-udc-xilinx-replace-memcpy-with-memcpy_toio.patch new file mode 100644 index 00000000000..225ebadef50 --- /dev/null +++ b/queue-5.10/usb-gadget-udc-xilinx-replace-memcpy-with-memcpy_toio.patch @@ -0,0 +1,155 @@ +From 3061b6491f491197a35e14e49f805d661b02acd4 Mon Sep 17 00:00:00 2001 +From: Piyush Mehta +Date: Fri, 29 Sep 2023 17:45:14 +0530 +Subject: usb: gadget: udc-xilinx: replace memcpy with memcpy_toio + +From: Piyush Mehta + +commit 3061b6491f491197a35e14e49f805d661b02acd4 upstream. + +For ARM processor, unaligned access to device memory is not allowed. +Method memcpy does not take care of alignment. + +USB detection failure with the unalingned address of memory, with +below kernel crash. To fix the unalingned address kernel panic, +replace memcpy with memcpy_toio method. + +Kernel crash: +Unable to handle kernel paging request at virtual address ffff80000c05008a +Mem abort info: + ESR = 0x96000061 + EC = 0x25: DABT (current EL), IL = 32 bits + SET = 0, FnV = 0 + EA = 0, S1PTW = 0 + FSC = 0x21: alignment fault +Data abort info: + ISV = 0, ISS = 0x00000061 + CM = 0, WnR = 1 +swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000143b000 +[ffff80000c05008a] pgd=100000087ffff003, p4d=100000087ffff003, +pud=100000087fffe003, pmd=1000000800bcc003, pte=00680000a0010713 +Internal error: Oops: 96000061 [#1] SMP +Modules linked in: +CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.19-xilinx-v2022.1 #1 +Hardware name: ZynqMP ZCU102 Rev1.0 (DT) +pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) +pc : __memcpy+0x30/0x260 +lr : __xudc_ep0_queue+0xf0/0x110 +sp : ffff800008003d00 +x29: ffff800008003d00 x28: ffff800009474e80 x27: 00000000000000a0 +x26: 0000000000000100 x25: 0000000000000012 x24: ffff000800bc8080 +x23: 0000000000000001 x22: 0000000000000012 x21: ffff000800bc8080 +x20: 0000000000000012 x19: ffff000800bc8080 x18: 0000000000000000 +x17: ffff800876482000 x16: ffff800008004000 x15: 0000000000004000 +x14: 00001f09785d0400 x13: 0103020101005567 x12: 0781400000000200 +x11: 00000000c5672a10 x10: 00000000000008d0 x9 : ffff800009463cf0 +x8 : ffff8000094757b0 x7 : 0201010055670781 x6 : 4000000002000112 +x5 : ffff80000c05009a x4 : ffff000800a15012 x3 : ffff00080362ad80 +x2 : 0000000000000012 x1 : ffff000800a15000 x0 : ffff80000c050088 +Call trace: + __memcpy+0x30/0x260 + xudc_ep0_queue+0x3c/0x60 + usb_ep_queue+0x38/0x44 + composite_ep0_queue.constprop.0+0x2c/0xc0 + composite_setup+0x8d0/0x185c + configfs_composite_setup+0x74/0xb0 + xudc_irq+0x570/0xa40 + __handle_irq_event_percpu+0x58/0x170 + handle_irq_event+0x60/0x120 + handle_fasteoi_irq+0xc0/0x220 + handle_domain_irq+0x60/0x90 + gic_handle_irq+0x74/0xa0 + call_on_irq_stack+0x2c/0x60 + do_interrupt_handler+0x54/0x60 + el1_interrupt+0x30/0x50 + el1h_64_irq_handler+0x18/0x24 + el1h_64_irq+0x78/0x7c + arch_cpu_idle+0x18/0x2c + do_idle+0xdc/0x15c + cpu_startup_entry+0x28/0x60 + rest_init+0xc8/0xe0 + arch_call_rest_init+0x10/0x1c + start_kernel+0x694/0x6d4 + __primary_switched+0xa4/0xac + +Fixes: 1f7c51660034 ("usb: gadget: Add xilinx usb2 device support") +Reported-by: kernel test robot +Closes: https://lore.kernel.org/all/202209020044.CX2PfZzM-lkp@intel.com/ +Cc: stable@vger.kernel.org +Signed-off-by: Piyush Mehta +Link: https://lore.kernel.org/r/20230929121514.13475-1-piyush.mehta@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/gadget/udc/udc-xilinx.c | 20 ++++++++++++-------- + 1 file changed, 12 insertions(+), 8 deletions(-) + +--- a/drivers/usb/gadget/udc/udc-xilinx.c ++++ b/drivers/usb/gadget/udc/udc-xilinx.c +@@ -496,11 +496,13 @@ static int xudc_eptxrx(struct xusb_ep *e + /* Get the Buffer address and copy the transmit data.*/ + eprambase = (u32 __force *)(udc->addr + ep->rambase); + if (ep->is_in) { +- memcpy(eprambase, bufferptr, bytestosend); ++ memcpy_toio((void __iomem *)eprambase, bufferptr, ++ bytestosend); + udc->write_fn(udc->addr, ep->offset + + XUSB_EP_BUF0COUNT_OFFSET, bufferlen); + } else { +- memcpy(bufferptr, eprambase, bytestosend); ++ memcpy_toio((void __iomem *)bufferptr, eprambase, ++ bytestosend); + } + /* + * Enable the buffer for transmission. +@@ -514,11 +516,13 @@ static int xudc_eptxrx(struct xusb_ep *e + eprambase = (u32 __force *)(udc->addr + ep->rambase + + ep->ep_usb.maxpacket); + if (ep->is_in) { +- memcpy(eprambase, bufferptr, bytestosend); ++ memcpy_toio((void __iomem *)eprambase, bufferptr, ++ bytestosend); + udc->write_fn(udc->addr, ep->offset + + XUSB_EP_BUF1COUNT_OFFSET, bufferlen); + } else { +- memcpy(bufferptr, eprambase, bytestosend); ++ memcpy_toio((void __iomem *)bufferptr, eprambase, ++ bytestosend); + } + /* + * Enable the buffer for transmission. +@@ -1020,7 +1024,7 @@ static int __xudc_ep0_queue(struct xusb_ + udc->addr); + length = req->usb_req.actual = min_t(u32, length, + EP0_MAX_PACKET); +- memcpy(corebuf, req->usb_req.buf, length); ++ memcpy_toio((void __iomem *)corebuf, req->usb_req.buf, length); + udc->write_fn(udc->addr, XUSB_EP_BUF0COUNT_OFFSET, length); + udc->write_fn(udc->addr, XUSB_BUFFREADY_OFFSET, 1); + } else { +@@ -1746,7 +1750,7 @@ static void xudc_handle_setup(struct xus + + /* Load up the chapter 9 command buffer.*/ + ep0rambase = (u32 __force *) (udc->addr + XUSB_SETUP_PKT_ADDR_OFFSET); +- memcpy(&setup, ep0rambase, 8); ++ memcpy_toio((void __iomem *)&setup, ep0rambase, 8); + + udc->setup = setup; + udc->setup.wValue = cpu_to_le16(setup.wValue); +@@ -1833,7 +1837,7 @@ static void xudc_ep0_out(struct xusb_udc + (ep0->rambase << 2)); + buffer = req->usb_req.buf + req->usb_req.actual; + req->usb_req.actual = req->usb_req.actual + bytes_to_rx; +- memcpy(buffer, ep0rambase, bytes_to_rx); ++ memcpy_toio((void __iomem *)buffer, ep0rambase, bytes_to_rx); + + if (req->usb_req.length == req->usb_req.actual) { + /* Data transfer completed get ready for Status stage */ +@@ -1909,7 +1913,7 @@ static void xudc_ep0_in(struct xusb_udc + (ep0->rambase << 2)); + buffer = req->usb_req.buf + req->usb_req.actual; + req->usb_req.actual = req->usb_req.actual + length; +- memcpy(ep0rambase, buffer, length); ++ memcpy_toio((void __iomem *)ep0rambase, buffer, length); + } + udc->write_fn(udc->addr, XUSB_EP_BUF0COUNT_OFFSET, count); + udc->write_fn(udc->addr, XUSB_BUFFREADY_OFFSET, 1); diff --git a/queue-5.10/usb-musb-get-the-musb_qh-poniter-after-musb_giveback.patch b/queue-5.10/usb-musb-get-the-musb_qh-poniter-after-musb_giveback.patch new file mode 100644 index 00000000000..5e4161f9507 --- /dev/null +++ b/queue-5.10/usb-musb-get-the-musb_qh-poniter-after-musb_giveback.patch @@ -0,0 +1,52 @@ +From 33d7e37232155aadebe4145dcc592f00dabd7a2b Mon Sep 17 00:00:00 2001 +From: Xingxing Luo +Date: Tue, 19 Sep 2023 11:30:55 +0800 +Subject: usb: musb: Get the musb_qh poniter after musb_giveback + +From: Xingxing Luo + +commit 33d7e37232155aadebe4145dcc592f00dabd7a2b upstream. + +When multiple threads are performing USB transmission, musb->lock will be +unlocked when musb_giveback is executed. At this time, qh may be released +in the dequeue process in other threads, resulting in a wild pointer, so +it needs to be here get qh again, and judge whether qh is NULL, and when +dequeue, you need to set qh to NULL. + +Fixes: dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed") +Cc: stable@vger.kernel.org +Signed-off-by: Xingxing Luo +Link: https://lore.kernel.org/r/20230919033055.14085-1-xingxing.luo@unisoc.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/musb/musb_host.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/usb/musb/musb_host.c ++++ b/drivers/usb/musb/musb_host.c +@@ -321,10 +321,16 @@ static void musb_advance_schedule(struct + musb_giveback(musb, urb, status); + qh->is_ready = ready; + ++ /* ++ * musb->lock had been unlocked in musb_giveback, so qh may ++ * be freed, need to get it again ++ */ ++ qh = musb_ep_get_qh(hw_ep, is_in); ++ + /* reclaim resources (and bandwidth) ASAP; deschedule it, and + * invalidate qh as soon as list_empty(&hep->urb_list) + */ +- if (list_empty(&qh->hep->urb_list)) { ++ if (qh && list_empty(&qh->hep->urb_list)) { + struct list_head *head; + struct dma_controller *dma = musb->dma_controller; + +@@ -2404,6 +2410,7 @@ static int musb_urb_dequeue(struct usb_h + * and its URB list has emptied, recycle this qh. + */ + if (ready && list_empty(&qh->hep->urb_list)) { ++ musb_ep_set_qh(qh->hw_ep, is_in, NULL); + qh->hep->hcpriv = NULL; + list_del(&qh->ring); + kfree(qh); diff --git a/queue-5.10/usb-musb-modify-the-hwvers-register-address.patch b/queue-5.10/usb-musb-modify-the-hwvers-register-address.patch new file mode 100644 index 00000000000..8ad667873b2 --- /dev/null +++ b/queue-5.10/usb-musb-modify-the-hwvers-register-address.patch @@ -0,0 +1,36 @@ +From 6658a62e1ddf726483cb2d8bf45ea3f9bd533074 Mon Sep 17 00:00:00 2001 +From: Xingxing Luo +Date: Fri, 22 Sep 2023 15:59:29 +0800 +Subject: usb: musb: Modify the "HWVers" register address + +From: Xingxing Luo + +commit 6658a62e1ddf726483cb2d8bf45ea3f9bd533074 upstream. + +musb HWVers rgister address is not 0x69, if we operate the +wrong address 0x69, it will cause a kernel crash, because +there is no register corresponding to this address in the +additional control register of musb. In fact, HWVers has +been defined in musb_register.h, and the name is +"MUSB_HWVERS", so We need to use this macro instead of 0x69. + +Fixes: c2365ce5d5a0 ("usb: musb: replace hard coded registers with defines") +Cc: stable@vger.kernel.org +Signed-off-by: Xingxing Luo +Link: https://lore.kernel.org/r/20230922075929.31074-1-xingxing.luo@unisoc.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/musb/musb_debugfs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/usb/musb/musb_debugfs.c ++++ b/drivers/usb/musb/musb_debugfs.c +@@ -39,7 +39,7 @@ static const struct musb_register_map mu + { "IntrUsbE", MUSB_INTRUSBE, 8 }, + { "DevCtl", MUSB_DEVCTL, 8 }, + { "VControl", 0x68, 32 }, +- { "HWVers", 0x69, 16 }, ++ { "HWVers", MUSB_HWVERS, 16 }, + { "LinkInfo", MUSB_LINKINFO, 8 }, + { "VPLen", MUSB_VPLEN, 8 }, + { "HS_EOF1", MUSB_HS_EOF1, 8 }, diff --git a/queue-5.10/usb-xhci-xhci-ring-use-sysdev-for-mapping-bounce-buffer.patch b/queue-5.10/usb-xhci-xhci-ring-use-sysdev-for-mapping-bounce-buffer.patch new file mode 100644 index 00000000000..26aeb0c61fb --- /dev/null +++ b/queue-5.10/usb-xhci-xhci-ring-use-sysdev-for-mapping-bounce-buffer.patch @@ -0,0 +1,54 @@ +From 41a43013d2366db5b88b42bbcd8e8f040b6ccf21 Mon Sep 17 00:00:00 2001 +From: Wesley Cheng +Date: Fri, 15 Sep 2023 17:31:05 +0300 +Subject: usb: xhci: xhci-ring: Use sysdev for mapping bounce buffer + +From: Wesley Cheng + +commit 41a43013d2366db5b88b42bbcd8e8f040b6ccf21 upstream. + +As mentioned in: + commit 474ed23a6257 ("xhci: align the last trb before link if it is +easily splittable.") + +A bounce buffer is utilized for ensuring that transfers that span across +ring segments are aligned to the EP's max packet size. However, the device +that is used to map the DMA buffer to is currently using the XHCI HCD, +which does not carry any DMA operations in certain configrations. +Migration to using the sysdev entry was introduced for DWC3 based +implementations where the IOMMU operations are present. + +Replace the reference to the controller device to sysdev instead. This +allows the bounce buffer to be properly mapped to any implementations that +have an IOMMU involved. + +cc: stable@vger.kernel.org +Fixes: 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration") +Signed-off-by: Wesley Cheng +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20230915143108.1532163-2-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-ring.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/usb/host/xhci-ring.c ++++ b/drivers/usb/host/xhci-ring.c +@@ -742,7 +742,7 @@ static void xhci_giveback_urb_in_irq(str + static void xhci_unmap_td_bounce_buffer(struct xhci_hcd *xhci, + struct xhci_ring *ring, struct xhci_td *td) + { +- struct device *dev = xhci_to_hcd(xhci)->self.controller; ++ struct device *dev = xhci_to_hcd(xhci)->self.sysdev; + struct xhci_segment *seg = td->bounce_seg; + struct urb *urb = td->urb; + size_t len; +@@ -3325,7 +3325,7 @@ static u32 xhci_td_remainder(struct xhci + static int xhci_align_td(struct xhci_hcd *xhci, struct urb *urb, u32 enqd_len, + u32 *trb_buff_len, struct xhci_segment *seg) + { +- struct device *dev = xhci_to_hcd(xhci)->self.controller; ++ struct device *dev = xhci_to_hcd(xhci)->self.sysdev; + unsigned int unalign; + unsigned int max_pkt; + u32 new_buff_len; diff --git a/queue-5.10/x86-cpu-fix-amd-erratum-1485-on-zen4-based-cpus.patch b/queue-5.10/x86-cpu-fix-amd-erratum-1485-on-zen4-based-cpus.patch new file mode 100644 index 00000000000..53c0454a28c --- /dev/null +++ b/queue-5.10/x86-cpu-fix-amd-erratum-1485-on-zen4-based-cpus.patch @@ -0,0 +1,72 @@ +From f454b18e07f518bcd0c05af17a2239138bff52de Mon Sep 17 00:00:00 2001 +From: "Borislav Petkov (AMD)" +Date: Sat, 7 Oct 2023 12:57:02 +0200 +Subject: x86/cpu: Fix AMD erratum #1485 on Zen4-based CPUs +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Borislav Petkov (AMD) + +commit f454b18e07f518bcd0c05af17a2239138bff52de upstream. + +Fix erratum #1485 on Zen4 parts where running with STIBP disabled can +cause an #UD exception. The performance impact of the fix is negligible. + +Reported-by: René Rebe +Signed-off-by: Borislav Petkov (AMD) +Tested-by: René Rebe +Cc: +Link: https://lore.kernel.org/r/D99589F4-BC5D-430B-87B2-72C20370CF57@exactcode.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/msr-index.h | 9 +++++++-- + arch/x86/kernel/cpu/amd.c | 8 ++++++++ + 2 files changed, 15 insertions(+), 2 deletions(-) + +--- a/arch/x86/include/asm/msr-index.h ++++ b/arch/x86/include/asm/msr-index.h +@@ -541,12 +541,17 @@ + + #define MSR_AMD64_VIRT_SPEC_CTRL 0xc001011f + +-/* Fam 17h MSRs */ +-#define MSR_F17H_IRPERF 0xc00000e9 ++/* Zen4 */ ++#define MSR_ZEN4_BP_CFG 0xc001102e ++#define MSR_ZEN4_BP_CFG_SHARED_BTB_FIX_BIT 5 + ++/* Zen 2 */ + #define MSR_ZEN2_SPECTRAL_CHICKEN 0xc00110e3 + #define MSR_ZEN2_SPECTRAL_CHICKEN_BIT BIT_ULL(1) + ++/* Fam 17h MSRs */ ++#define MSR_F17H_IRPERF 0xc00000e9 ++ + /* Fam 16h MSRs */ + #define MSR_F16H_L2I_PERF_CTL 0xc0010230 + #define MSR_F16H_L2I_PERF_CTR 0xc0010231 +--- a/arch/x86/kernel/cpu/amd.c ++++ b/arch/x86/kernel/cpu/amd.c +@@ -81,6 +81,10 @@ static const int amd_div0[] = + AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x17, 0x00, 0x0, 0x2f, 0xf), + AMD_MODEL_RANGE(0x17, 0x50, 0x0, 0x5f, 0xf)); + ++static const int amd_erratum_1485[] = ++ AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x19, 0x10, 0x0, 0x1f, 0xf), ++ AMD_MODEL_RANGE(0x19, 0x60, 0x0, 0xaf, 0xf)); ++ + static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum) + { + int osvw_id = *erratum++; +@@ -1178,6 +1182,10 @@ static void init_amd(struct cpuinfo_x86 + pr_notice_once("AMD Zen1 DIV0 bug detected. Disable SMT for full protection.\n"); + setup_force_cpu_bug(X86_BUG_DIV0); + } ++ ++ if (!cpu_has(c, X86_FEATURE_HYPERVISOR) && ++ cpu_has_amd_erratum(c, amd_erratum_1485)) ++ msr_set_bit(MSR_ZEN4_BP_CFG, MSR_ZEN4_BP_CFG_SHARED_BTB_FIX_BIT); + } + + #ifdef CONFIG_X86_32