commit c8eef176690851911d8b70d798152e7314b0f7dc Author: Greg Kroah-Hartman Date: Sat May 25 16:30:56 2024 +0200 Linux 6.9.2 Link: https://lore.kernel.org/r/20240523130330.386580714@linuxfoundation.org Tested-by: Mark Brown Tested-by: SeongJae Park Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Florian Fainelli Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Pavel Machek (CIP) Tested-by: Pascal Ernster Signed-off-by: Greg Kroah-Hartman commit 9ee1c10611b4fc9efd65e8edc97f5c5730ce889d Author: Christoph Hellwig Date: Thu May 2 15:00:33 2024 +0200 block: add a partscan sysfs attribute for disks commit a4217c6740dc64a3eb6815868a9260825e8c68c6 upstream. Userspace had been unknowingly relying on a non-stable interface of kernel internals to determine if partition scanning is enabled for a given disk. Provide a stable interface for this purpose instead. Cc: stable@vger.kernel.org # 6.3+ Depends-on: 140ce28dd3be ("block: add a disk_has_partscan helper") Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/linux-block/ZhQJf8mzq_wipkBH@gardel-login/ Link: https://lore.kernel.org/r/20240502130033.1958492-3-hch@lst.de [axboe: add links and commit message from Keith] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 59e0727d444a93a3e6382f63a2c45346c151e27a Author: Christoph Hellwig Date: Thu May 2 15:00:32 2024 +0200 block: add a disk_has_partscan helper commit 140ce28dd3bee8e53acc27f123ae474d69ef66f0 upstream. Add a helper to check if partition scanning is enabled instead of open coding the check in a few places. This now always checks for the hidden flag even if all but one of the callers are never reachable for hidden gendisks. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20240502130033.1958492-2-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 50ef147264b708f8ab87ef07715ff7a07d5947a8 Author: SeongJae Park Date: Fri May 3 11:03:15 2024 -0700 Docs/admin-guide/mm/damon/usage: fix wrong schemes effective quota update command commit 14e70e4660d6ecaf503c461f072949ef8758e4a1 upstream. To update effective size quota of DAMOS schemes on DAMON sysfs file interface, user should write 'update_schemes_effective_quotas' to the kdamond 'state' file. But the document is mistakenly saying the input string as 'update_schemes_effective_bytes'. Fix it (s/bytes/quotas/). Link: https://lkml.kernel.org/r/20240503180318.72798-8-sj@kernel.org Fixes: a6068d6dfa2f ("Docs/admin-guide/mm/damon/usage: document effective_bytes file") Signed-off-by: SeongJae Park Cc: [6.9.x] Cc: Jonathan Corbet Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 883c84b2b3e61e82e0bb2de70f747f628b007be4 Author: SeongJae Park Date: Fri May 3 11:03:14 2024 -0700 Docs/admin-guide/mm/damon/usage: fix wrong example of DAMOS filter matching sysfs file commit da2a061888883e067e8e649d086df35c92c760a7 upstream. The example usage of DAMOS filter sysfs files, specifically the part of 'matching' file writing for memcg type filter, is wrong. The intention is to exclude pages of a memcg that already getting enough care from a given scheme, but the example is setting the filter to apply the scheme to only the pages of the memcg. Fix it. Link: https://lkml.kernel.org/r/20240503180318.72798-7-sj@kernel.org Fixes: 9b7f9322a530 ("Docs/admin-guide/mm/damon/usage: document DAMOS filters of sysfs") Closes: https://lore.kernel.org/r/20240317191358.97578-1-sj@kernel.org Signed-off-by: SeongJae Park Cc: [6.3.x] Cc: Jonathan Corbet Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 387f3d34e847eeb298f0acfc53309d1185a353de Author: Akira Yokosawa Date: Wed May 1 12:16:11 2024 +0900 docs: kernel_include.py: Cope with docutils 0.21 commit d43ddd5c91802a46354fa4c4381416ef760676e2 upstream. Running "make htmldocs" on a newly installed Sphinx 7.3.7 ends up in a build error: Sphinx parallel build error: AttributeError: module 'docutils.nodes' has no attribute 'reprunicode' docutils 0.21 has removed nodes.reprunicode, quote from release note [1]: * Removed objects: docutils.nodes.reprunicode, docutils.nodes.ensure_str() Python 2 compatibility hacks Sphinx 7.3.0 supports docutils 0.21 [2]: kernel_include.py, whose origin is misc.py of docutils, uses reprunicode. Upstream docutils removed the offending line from the corresponding file (docutils/docutils/parsers/rst/directives/misc.py) in January 2022. Quoting the changelog [3]: Deprecate `nodes.reprunicode` and `nodes.ensure_str()`. Drop uses of the deprecated constructs (not required with Python 3). Do the same for kernel_include.py. Tested against: - Sphinx 2.4.5 (docutils 0.17.1) - Sphinx 3.4.3 (docutils 0.17.1) - Sphinx 5.3.0 (docutils 0.18.1) - Sphinx 6.2.1 (docutils 0.19) - Sphinx 7.2.6 (docutils 0.20.1) - Sphinx 7.3.7 (docutils 0.21.2) Link: http://www.docutils.org/RELEASE-NOTES.html#release-0-21-2024-04-09 [1] Link: https://www.sphinx-doc.org/en/master/changes.html#release-7-3-0-released-apr-16-2024 [2] Link: https://github.com/docutils/docutils/commit/c8471ce47a24 [3] Signed-off-by: Akira Yokosawa Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/faf5fa45-2a9d-4573-9d2e-3930bdc1ed65@gmail.com Signed-off-by: Greg Kroah-Hartman commit 86b808ff187473674bb91a9d5abd0ad018b77cc4 Author: Thomas Weißschuh Date: Tue Apr 23 12:34:25 2024 +0200 admin-guide/hw-vuln/core-scheduling: fix return type of PR_SCHED_CORE_GET commit 8af2d1ab78f2342f8c4c3740ca02d86f0ebfac5a upstream. sched_core_share_pid() copies the cookie to userspace with put_user(id, (u64 __user *)uaddr), expecting 64 bits of space. The "unsigned long" datatype that is documented in core-scheduling.rst however is only 32 bits large on 32 bit architectures. Document "unsigned long long" as the correct data type that is always 64bits large. This matches what the selftest cs_prctl_test.c has been doing all along. Fixes: 0159bb020ca9 ("Documentation: Add usecases, design and interface for core scheduling") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/util-linux/df7a25a0-7923-4f8b-a527-5e6f0064074d@t-8ch.de/ Signed-off-by: Thomas Weißschuh Reviewed-by: Chris Hyser Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240423-core-scheduling-cookie-v1-1-5753a35f8dfc@weissschuh.net Signed-off-by: Greg Kroah-Hartman commit ff91cc12faf798f573dab2abc976c1d5b1862fea Author: Jarkko Sakkinen Date: Mon May 13 21:19:04 2024 +0300 KEYS: trusted: Do not use WARN when encode fails commit 050bf3c793a07f96bd1e2fd62e1447f731ed733b upstream. When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information. Cc: stable@vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 2e0ce54a9c5c7013b1257be044d99cbe7305e9f1 Author: Hans Verkuil Date: Fri May 10 09:11:46 2024 +0200 Revert "media: v4l2-ctrls: show all owned controls in log_status" commit eba63df7eb1f95df6bfb67722a35372b6994928d upstream. This reverts commit 9801b5b28c6929139d6fceeee8d739cc67bb2739. This patch introduced a potential deadlock scenario: [Wed May 8 10:02:06 2024] Possible unsafe locking scenario: [Wed May 8 10:02:06 2024] CPU0 CPU1 [Wed May 8 10:02:06 2024] ---- ---- [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock); For now just revert. Fixes: 9801b5b28c69 ("media: v4l2-ctrls: show all owned controls in log_status") Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Reviewed-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman commit 36c79eb4845551e9f6d28c663b38ce0ab03b84a9 Author: AngeloGioacchino Del Regno Date: Thu Mar 21 09:46:13 2024 +0100 remoteproc: mediatek: Make sure IPI buffer fits in L2TCM commit 331f91d86f71d0bb89a44217cc0b2a22810bbd42 upstream. The IPI buffer location is read from the firmware that we load to the System Companion Processor, and it's not granted that both the SRAM (L2TCM) size that is defined in the devicetree node is large enough for that, and while this is especially true for multi-core SCP, it's still useful to check on single-core variants as well. Failing to perform this check may make this driver perform R/W operations out of the L2TCM boundary, resulting (at best) in a kernel panic. To fix that, check that the IPI buffer fits, otherwise return a failure and refuse to boot the relevant SCP core (or the SCP at all, if this is single core). Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW") Signed-off-by: AngeloGioacchino Del Regno Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240321084614.45253-2-angelogioacchino.delregno@collabora.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 4dd04367a26a48e6b0750322c0c0423a77902858 Author: Daniel Thompson Date: Wed Apr 24 15:21:41 2024 +0100 serial: kgdboc: Fix NMI-safety problems from keyboard reset code commit b2aba15ad6f908d1a620fd97f6af5620c3639742 upstream. Currently, when kdb is compiled with keyboard support, then we will use schedule_work() to provoke reset of the keyboard status. Unfortunately schedule_work() gets called from the kgdboc post-debug-exception handler. That risks deadlock since schedule_work() is not NMI-safe and, even on platforms where the NMI is not directly used for debugging, the debug trap can have NMI-like behaviour depending on where breakpoints are placed. Fix this by using the irq work system, which is NMI-safe, to defer the call to schedule_work() to a point when it is safe to call. Reported-by: Liuye Closes: https://lore.kernel.org/all/20240228025602.3087748-1-liu.yeC@h3c.com/ Cc: stable@vger.kernel.org Reviewed-by: Douglas Anderson Acked-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20240424-kgdboc_fix_schedule_work-v2-1-50f5a490aec5@linaro.org Signed-off-by: Daniel Thompson Signed-off-by: Greg Kroah-Hartman commit d88a0e57ace5776bdff10968c9c1386c23f4d5c4 Author: Javier Carrasco Date: Mon Apr 29 15:35:58 2024 +0200 usb: typec: tipd: fix event checking for tps6598x commit 409c1cfb5a803f3cf2d17aeaf75c25c4be951b07 upstream. The current interrupt service routine of the tps6598x only reads the first 64 bits of the INT_EVENT1 and INT_EVENT2 registers, which means that any event above that range will be ignored, leaving interrupts unattended. Moreover, those events will not be cleared, and the device will keep the interrupt enabled. This issue has been observed while attempting to load patches, and the 'ReadyForPatch' field (bit 81) of INT_EVENT1 was set. Given that older versions of the tps6598x (1, 2 and 6) provide 8-byte registers, a mechanism based on the upper byte of the version register (0x0F) has been included. The manufacturer has confirmed [1] that this byte is always 0 for older versions, and either 0xF7 (DH parts) or 0xF9 (DK parts) is returned in newer versions (7 and 8). Read the complete INT_EVENT registers to handle all interrupts generated by the device and account for the hardware version to select the register size. Link: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1346521/tps65987d-register-command-to-distinguish-between-tps6591-2-6-and-tps65987-8 [1] Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Cc: stable@vger.kernel.org Signed-off-by: Javier Carrasco Link: https://lore.kernel.org/r/20240429-tps6598x_fix_event_handling-v3-2-4e8e58dce489@wolfvision.net Signed-off-by: Greg Kroah-Hartman commit 0db68ec4a2e28bbaec8e4a0445ca1ba4ac557fcb Author: Javier Carrasco Date: Mon Apr 29 15:35:57 2024 +0200 usb: typec: tipd: fix event checking for tps25750 commit d64adb0f41e62f91fcfdf0e0d9d5bfa714db0d23 upstream. In its current form, the interrupt service routine of the tps25750 checks the event flags in the lowest 64 bits of the interrupt event register (event[0]), but also in the upper part (event[1]). Given that all flags are defined as BIT() or BIT_ULL(), they are restricted to the first 64 bits of the INT_EVENT1 register. Including the upper part of the register can lead to false positives e.g. if the event 64 bits above the one being checked is set, but the one being checked is not. Restrict the flag checking to the first 64 bits of the INT_EVENT1 register. Fixes: 7e7a3c815d22 ("USB: typec: tps6598x: Add TPS25750 support") Cc: stable@vger.kernel.org Acked-by: Heikki Krogerus Signed-off-by: Javier Carrasco Link: https://lore.kernel.org/r/20240429-tps6598x_fix_event_handling-v3-1-4e8e58dce489@wolfvision.net Signed-off-by: Greg Kroah-Hartman commit b9828fd1bd2ace6fc947c2bba16f452501f761ba Author: Heikki Krogerus Date: Tue May 7 16:43:16 2024 +0300 usb: typec: ucsi: displayport: Fix potential deadlock commit b791a67f68121d69108640d4a3e591d210ffe850 upstream. The function ucsi_displayport_work() does not access the connector, so it also must not acquire the connector lock. This fixes a potential deadlock scenario: ucsi_displayport_work() -> lock(&con->lock) typec_altmode_vdm() dp_altmode_vdm() dp_altmode_work() typec_altmode_enter() ucsi_displayport_enter() -> lock(&con->lock) Reported-by: Mathias Nyman Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20240507134316.161999-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 7dc13634d93d4080b82c32d7118abe773b1874fc Author: Jose Ignacio Tornos Martinez Date: Fri May 10 11:08:28 2024 +0200 net: usb: ax88179_178a: fix link status when link is set to down/up commit ecf848eb934b03959918f5269f64c0e52bc23998 upstream. The idea was to keep only one reset at initialization stage in order to reduce the total delay, or the reset from usbnet_probe or the reset from usbnet_open. I have seen that restarting from usbnet_probe is necessary to avoid doing too complex things. But when the link is set to down/up (for example to configure a different mac address) the link is not correctly recovered unless a reset is commanded from usbnet_open. So, detect the initialization stage (first call) to not reset from usbnet_open after the reset from usbnet_probe and after this stage, always reset from usbnet_open too (when the link needs to be rechecked). Apply to all the possible devices, the behavior now is going to be the same. cc: stable@vger.kernel.org # 6.6+ Fixes: 56f78615bcb1 ("net: usb: ax88179_178a: avoid writing the mac address before first reading") Reported-by: Isaac Ganoung Reported-by: Yongqin Liu Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240510090846.328201-1-jtornosm@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1ba145f05b5c8f0b1a947a0633b5edff5dd1f1c5 Author: Prashanth K Date: Thu May 2 10:11:03 2024 +0530 usb: dwc3: Wait unconditionally after issuing EndXfer command commit 1d26ba0944d398f88aaf997bda3544646cf21945 upstream. Currently all controller IP/revisions except DWC3_usb3 >= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWC_usb3 controller revisions >= 3.10a supports GUCTL2[14: Rst_actbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed. Consider a case where an IN request was queued, and parallelly soft_disconnect was called (due to ffs_epfile_release). This eventually calls stop_active_transfer with IOC cleared, hence send_gadget_ep_cmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions >= 310a, we don't forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn't complete by this time, it leads to SMMU faults since the controller would still be accessing those requests. Fix this by ensuring ENDXFER completion by adding 1ms delay in __dwc3_stop_active_transfer() unconditionally. Cc: stable@vger.kernel.org Fixes: b353eb6dc285 ("usb: dwc3: gadget: Skip waiting for CMDACT cleared during endxfer") Signed-off-by: Prashanth K Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20240502044103.1066350-1-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman commit e55b4d9383f330a55b388e55d0f8e89afacd04d2 Author: Carlos Llamas Date: Sun Apr 21 17:37:49 2024 +0000 binder: fix max_thread type inconsistency commit 42316941335644a98335f209daafa4c122f28983 upstream. The type defined for the BINDER_SET_MAX_THREADS ioctl was changed from size_t to __u32 in order to avoid incompatibility issues between 32 and 64-bit kernels. However, the internal types used to copy from user and store the value were never updated. Use u32 to fix the inconsistency. Fixes: a9350fc859ae ("staging: android: binder: fix BINDER_SET_MAX_THREADS declaration") Reported-by: Arve Hjønnevåg Cc: stable@vger.kernel.org Signed-off-by: Carlos Llamas Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240421173750.3117808-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman commit a4ffa8b2fc0ebb86d001f1efb552387c97a2507d Author: Bard Liao Date: Tue Mar 26 11:04:19 2024 -0500 ASoC: Intel: sof_sdw: use generic rtd_init function for Realtek SDW DMICs commit bee2fe44679f1e6a5332d7f78587ccca4109919f upstream. The only thing that the rt_xxx_rtd_init() functions do is to set card->components. And we can set card->components with name_prefix as rt712_sdca_dmic_rtd_init() does. And sof_sdw_rtd_init() will always select the first dai with the given dai->name from codec_info_list[]. Unfortunately, we have different codecs with the same dai name. For example, dai name of rt715 and rt715-sdca are both "rt715-aif2". Using a generic rtd_init allow sof_sdw_rtd_init() run the rtd_init() callback from a similar codec dai. Fixes: 8266c73126b7 ("ASoC: Intel: sof_sdw: add common sdw dai link init") Reviewed-by: Chao Song Reviewed-by: Péter Ujfalusi Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Link: https://msgid.link/r/20240326160429.13560-25-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Peter Ujfalusi Signed-off-by: Greg Kroah-Hartman commit cf26a92f560eed5d6ddc3d441cc645950cbabc56 Author: Jarkko Sakkinen Date: Mon May 20 02:31:53 2024 +0300 KEYS: trusted: Fix memory leak in tpm2_key_encode() commit ffcaa2172cc1a85ddb8b783de96d38ca8855e248 upstream. 'scratch' is never freed. Fix this by calling kfree() in the success, and in the error case. Cc: stable@vger.kernel.org # +v5.13 Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit d2b2f7d3936dc5990549bc36ab7ac7ac37f22c30 Author: Sungwoo Kim Date: Sat May 4 15:23:29 2024 -0400 Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init() commit a5b862c6a221459d54e494e88965b48dcfa6cc44 upstream. l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range. Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value. divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Modules linked in: ---[ end trace 0000000000000000 ]--- Fixes: 6ed58ec520ad ("Bluetooth: Use LE buffers for LE traffic") Suggested-by: Luiz Augusto von Dentz Signed-off-by: Sungwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 7a4b16f8c68db211925ffb3e3d44708f09619cac Author: Uros Bizjak Date: Tue Apr 2 19:50:38 2024 +0200 x86/percpu: Use __force to cast from __percpu address space commit a55c1fdad5f61b4bfe42319694b23671a758cb28 upstream. Fix Sparse warning when casting from __percpu address space by using __force in the cast. x86 named address spaces are not considered to be subspaces of the generic (flat) address space, so explicit casts are required to convert pointers between these address spaces and the generic address space (the application should cast to uintptr_t and apply the segment base offset). The cast to uintptr_t removes __percpu address space tag and Sparse reports: warning: cast removes address space '__percpu' of expression Use __force to inform Sparse that the cast is intentional. Fixes: 9a462b9eafa6 ("x86/percpu: Use compiler segment prefix qualifier") Reported-by: Charlemagne Lasse Signed-off-by: Uros Bizjak Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20240402175058.52649-1-ubizjak@gmail.com Signed-off-by: Greg Kroah-Hartman Closes: https://lore.kernel.org/lkml/CAFGhKbzev7W4aHwhFPWwMZQEHenVgZUj7=aunFieVqZg3mt14A@mail.gmail.com/ commit b3687a2659f3c9056316cc8496758b6998e757e1 Author: Ronald Wahl Date: Mon May 13 16:39:22 2024 +0200 net: ks8851: Fix another TX stall caused by wrong ISR flag handling commit 317a215d493230da361028ea8a4675de334bfa1a upstream. Under some circumstances it may happen that the ks8851 Ethernet driver stops sending data. Currently the interrupt handler resets the interrupt status flags in the hardware after handling TX. With this approach we may lose interrupts in the time window between handling the TX interrupt and resetting the TX interrupt status bit. When all of the three following conditions are true then transmitting data stops: - TX queue is stopped to wait for room in the hardware TX buffer - no queued SKBs in the driver (txq) that wait for being written to hw - hardware TX buffer is empty and the last TX interrupt was lost This is because reenabling the TX queue happens when handling the TX interrupt status but if the TX status bit has already been cleared then this interrupt will never come. With this commit the interrupt status flags will be cleared before they are handled. That way we stop losing interrupts. The wrong handling of the ISR flags was there from the beginning but with commit 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun") the issue becomes apparent. Fixes: 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun") Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Simon Horman Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org # 5.10+ Signed-off-by: Ronald Wahl Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 308de6be0c9c7ba36915c0d398e771725c0ea911 Author: Jose Fernandez Date: Mon Apr 22 08:35:44 2024 -0600 drm/amd/display: Fix division by zero in setup_dsc_config commit 130afc8a886183a94cf6eab7d24f300014ff87ba upstream. When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero. The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected. kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2)) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu After applying this patch, the driver no longer crashes when the monitor is connected and the system is rebooted. I believe this is the same issue reported for 3113. Reviewed-by: Rodrigo Siqueira Signed-off-by: Jose Fernandez Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3113 Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Cc: "Limonciello, Mario" Signed-off-by: Greg Kroah-Hartman commit a1cc29c6b6dd9d7ab4f16c1dc3b4a18744010cd5 Author: Perry Yuan Date: Wed May 8 13:47:03 2024 +0800 cpufreq: amd-pstate: fix the highest frequency issue which limits performance commit bf202e654bfa57fb8cf9d93d4c6855890b70b9c4 upstream. To address the performance drop issue, an optimization has been implemented. The incorrect highest performance value previously set by the low-level power firmware for AMD CPUs with Family ID 0x19 and Model ID ranging from 0x70 to 0x7F series has been identified as the cause. To resolve this, a check has been implemented to accurately determine the CPU family and model ID. The correct highest performance value is now set and the performance drop caused by the incorrect highest performance value are eliminated. Before the fix, the highest frequency was set to 4200MHz, now it is set to 4971MHz which is correct. CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ 0 0 0 0 0:0:0:0 yes 4971.0000 400.0000 400.0000 1 0 0 0 0:0:0:0 yes 4971.0000 400.0000 400.0000 2 0 0 1 1:1:1:0 yes 4971.0000 400.0000 4865.8140 3 0 0 1 1:1:1:0 yes 4971.0000 400.0000 400.0000 Fixes: f3a052391822 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218759 Signed-off-by: Perry Yuan Co-developed-by: Mario Limonciello Signed-off-by: Mario Limonciello Tested-by: Gaha Bana Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d20013259539e2fde2deeac85354851097afdf9e Author: Ben Greear Date: Tue Apr 30 16:42:12 2024 -0700 wifi: iwlwifi: Use request_module_nowait commit 3d913719df14c28c4d3819e7e6d150760222bda4 upstream. This appears to work around a deadlock regression that came in with the LED merge in 6.9. The deadlock happens on my system with 24 iwlwifi radios, so maybe it something like all worker threads are busy and some work that needs to complete cannot complete. Link: https://lore.kernel.org/linux-kernel/20240411070718.GD6194@google.com/ Fixes: f5c31bcf604d ("Merge tag 'leds-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds") Signed-off-by: Ben Greear Link: https://msgid.link/20240430234212.2132958-1-greearb@candelatech.com [also remove unnecessary "load_module" var and now-wrong comment] Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 3be46923b8d802575a36a7be5d40e036c3a3b284 Author: Peter Tsao Date: Mon Apr 15 22:19:22 2024 +0800 Bluetooth: btusb: Fix the patch for MT7920 the affected to MT7921 commit 958cd6beab693f395ffe07814ef77d2b45e8b0fc upstream. Because both MT7920 and MT7921 use the same chip ID. We use the 8th bit of fw_flavor to distingush MT7920. The original patch made a mistake to check whole fw_flavor, that makes the condition both true (dev_id == 0x7961 && fw_flavor), and makes MT7921 flow wrong. In this patch, we correct the flow to get the 8th bit value for MT7920. And the patch is verified pass with both MT7920 and MT7921. Signed-off-by: Peter Tsao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman