commit 8bbe7c640d76724e9cfd8aa130b8d36ad6db77a9 Author: Greg Kroah-Hartman Date: Thu Oct 19 23:11:09 2023 +0200 Linux 6.5.8 Link: https://lore.kernel.org/r/20231016084015.400031271@linuxfoundation.org Tested-by: Ricardo B. Marliere Tested-by: SeongJae Park Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Ron Economos Link: https://lore.kernel.org/r/20231016185002.371937173@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Ronald Warsow Tested-by: SeongJae Park Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman commit 46fd4e1547f9e09c9d58335cb487c3f19f102e39 Author: Kailang Yang Date: Tue Sep 12 15:31:49 2023 +0800 ALSA: hda/realtek - Fixed two speaker platform commit fb6254df09bba303db2a1002085f6c0b90a456ed upstream. If system has two speakers and one connect to 0x14 pin, use this function will disable it. Fixes: e43252db7e20 ("ALSA: hda/realtek - ALC287 I2S speaker platform support") Signed-off-by: Kailang Yang Link: https://lore.kernel.org/r/e3f2aac3fe6a47079d728a6443358cc2@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ae0c44ce454d639823e26721c62041a9b343bb11 Author: Amir Goldstein Date: Wed Oct 11 17:07:03 2023 +0300 ovl: fix regression in showing lowerdir mount option [ Upstream commit 32db510708507f6133f496ff385cbd841d8f9098 ] Before commit b36a5780cb44 ("ovl: modify layer parameter parsing"), spaces and commas in lowerdir mount option value used to be escaped using seq_show_option(). In current upstream, when lowerdir value has a space, it is not escaped in /proc/mounts, e.g.: none /mnt overlay rw,relatime,lowerdir=l l,upperdir=u,workdir=w 0 0 which results in broken output of the mount utility: none on /mnt type overlay (rw,relatime,lowerdir=l) Store the original lowerdir mount options before unescaping and show them using the same escaping used for seq_show_option() in addition to escaping the colon separator character. Fixes: b36a5780cb44 ("ovl: modify layer parameter parsing") Signed-off-by: Amir Goldstein Signed-off-by: Sasha Levin commit a8187a9ca2530372da49e5001bcfe2fc83b5dd95 Author: Amir Goldstein Date: Mon Oct 2 14:21:49 2023 +0300 ovl: make use of ->layers safe in rcu pathwalk [ Upstream commit a535116d80339dbfe50b9b81b2f808c69eefbbc3 ] ovl_permission() accesses ->layers[...].mnt; we can't have ->layers freed without an RCU delay on fs shutdown. Fortunately, kern_unmount_array() that is used to drop those mounts does include an RCU delay, so freeing is delayed; unfortunately, the array passed to kern_unmount_array() is formed by mangling ->layers contents and that happens without any delays. The ->layers[...].name string entries are used to store the strings to display in "lowerdir=..." by ovl_show_options(). Those entries are not accessed in RCU walk. Move the name strings into a separate array ofs->config.lowerdirs and reuse the ofs->config.lowerdirs array as the temporary mount array to pass to kern_unmount_array(). Reported-by: Al Viro Link: https://lore.kernel.org/r/20231002023711.GP3389589@ZenIV/ Acked-by: Miklos Szeredi Signed-off-by: Amir Goldstein Stable-dep-of: 32db51070850 ("ovl: fix regression in showing lowerdir mount option") Signed-off-by: Sasha Levin commit 58240ade86f2e4bdfdb4ccbe3b73777934f63df5 Author: Amir Goldstein Date: Thu Oct 12 16:08:28 2023 +0300 ovl: fix regression in parsing of mount options with escaped comma [ Upstream commit c34706acf40b43dd31f67c92c5a95d39666a1eb3 ] Ever since commit 91c77947133f ("ovl: allow filenames with comma"), the following example was legit overlayfs mount options: mount -t overlay overlay -o 'lowerdir=/tmp/a\,b/lower' /mnt The conversion to new mount api moved to using the common helper generic_parse_monolithic() and discarded the specialized ovl_next_opt() option separator. Bring back ovl_next_opt() and use vfs_parse_monolithic_sep() to fix the regression. Reported-by: Ryan Hendrickson Closes: https://lore.kernel.org/r/8da307fb-9318-cf78-8a27-ba5c5a0aef6d@alum.mit.edu/ Fixes: 1784fbc2ed9c ("ovl: port to new mount api") Signed-off-by: Amir Goldstein Signed-off-by: Sasha Levin commit cd86498418ede1e57961955eb2a1308d1d038d79 Author: Amir Goldstein Date: Thu Oct 12 15:24:17 2023 +0300 fs: factor out vfs_parse_monolithic_sep() helper [ Upstream commit e001d1447cd4585d7f23a44ff668ba2bc624badb ] Factor out vfs_parse_monolithic_sep() from generic_parse_monolithic(), so filesystems could use it with a custom option separator callback. Acked-by: Christian Brauner Signed-off-by: Amir Goldstein Stable-dep-of: c34706acf40b ("ovl: fix regression in parsing of mount options with escaped comma") Signed-off-by: Sasha Levin commit 87be623442a855c8c202058ea03528452132db13 Author: Matthew Wilcox (Oracle) Date: Fri Aug 18 21:08:24 2023 +0100 fs: Fix kernel-doc warnings [ Upstream commit 35931eb3945b8d38c31f8e956aee3cf31c52121b ] These have a variety of causes and a corresponding variety of solutions. Signed-off-by: "Matthew Wilcox (Oracle)" Message-Id: <20230818200824.2720007-1-willy@infradead.org> Signed-off-by: Christian Brauner Stable-dep-of: c34706acf40b ("ovl: fix regression in parsing of mount options with escaped comma") Signed-off-by: Sasha Levin commit 9baee1becd642fda751f5b2d43792af2143b3e41 Author: Christophe Leroy Date: Mon Sep 25 20:31:16 2023 +0200 powerpc/64e: Fix wrong test in __ptep_test_and_clear_young() [ Upstream commit 5ea0bbaa32e8f54e9a57cfee4a3b8769b80be0d2 ] Commit 45201c879469 ("powerpc/nohash: Remove hash related code from nohash headers.") replaced: if ((pte_val(*ptep) & (_PAGE_ACCESSED | _PAGE_HASHPTE)) == 0) return 0; By: if (pte_young(*ptep)) return 0; But it should be: if (!pte_young(*ptep)) return 0; Fix it. Fixes: 45201c879469 ("powerpc/nohash: Remove hash related code from nohash headers.") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://msgid.link/8bb7f06494e21adada724ede47a4c3d97e879d40.1695659959.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 909c0bfa08d565a9319de77a82710cc638e0a2c6 Author: Christophe Leroy Date: Mon Sep 25 20:31:15 2023 +0200 powerpc/8xx: Fix pte_access_permitted() for PAGE_NONE [ Upstream commit 5d9cea8a552ee122e21fbd5a3c5d4eb85f648e06 ] On 8xx, PAGE_NONE is handled by setting _PAGE_NA instead of clearing _PAGE_USER. But then pte_user() returns 1 also for PAGE_NONE. As _PAGE_NA prevent reads, add a specific version of pte_read() that returns 0 when _PAGE_NA is set instead of always returning 1. Fixes: 351750331fc1 ("powerpc/mm: Introduce _PAGE_NA") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://msgid.link/57bcfbe578e43123f9ed73e040229b80f1ad56ec.1695659959.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 7b126f4402c2b18bd6a1a047895b138b320563a8 Author: Duoming Zhou Date: Sun Aug 6 11:25:11 2023 +0800 dmaengine: mediatek: Fix deadlock caused by synchronize_irq() [ Upstream commit 01f1ae2733e2bb4de92fefcea5fda847d92aede1 ] The synchronize_irq(c->irq) will not return until the IRQ handler mtk_uart_apdma_irq_handler() is completed. If the synchronize_irq() holds a spin_lock and waits the IRQ handler to complete, but the IRQ handler also needs the same spin_lock. The deadlock will happen. The process is shown below: cpu0 cpu1 mtk_uart_apdma_device_pause() | mtk_uart_apdma_irq_handler() spin_lock_irqsave() | | spin_lock_irqsave() //hold the lock to wait | synchronize_irq() | This patch reorders the synchronize_irq(c->irq) outside the spin_lock in order to mitigate the bug. Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support") Signed-off-by: Duoming Zhou Reviewed-by: Eugen Hristev Link: https://lore.kernel.org/r/20230806032511.45263-1-duoming@zju.edu.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c6695a0ad6fb9750f3d62facf955e8c9a4cd7f78 Author: Rex Zhang Date: Sat Sep 16 14:06:19 2023 +0800 dmaengine: idxd: use spin_lock_irqsave before wait_event_lock_irq [ Upstream commit c0409dd3d151f661e7e57b901a81a02565df163c ] In idxd_cmd_exec(), wait_event_lock_irq() explicitly calls spin_unlock_irq()/spin_lock_irq(). If the interrupt is on before entering wait_event_lock_irq(), it will become off status after wait_event_lock_irq() is called. Later, wait_for_completion() may go to sleep but irq is disabled. The scenario is warned in might_sleep(). Fix it by using spin_lock_irqsave() instead of the primitive spin_lock() to save the irq status before entering wait_event_lock_irq() and using spin_unlock_irqrestore() instead of the primitive spin_unlock() to restore the irq status before entering wait_for_completion(). Before the change: idxd_cmd_exec() { interrupt is on spin_lock() // interrupt is on wait_event_lock_irq() spin_unlock_irq() // interrupt is enabled ... spin_lock_irq() // interrupt is disabled spin_unlock() // interrupt is still disabled wait_for_completion() // report "BUG: sleeping function // called from invalid context... // in_atomic() irqs_disabled()" } After applying spin_lock_irqsave(): idxd_cmd_exec() { interrupt is on spin_lock_irqsave() // save the on state // interrupt is disabled wait_event_lock_irq() spin_unlock_irq() // interrupt is enabled ... spin_lock_irq() // interrupt is disabled spin_unlock_irqrestore() // interrupt is restored to on wait_for_completion() // No Call trace } Fixes: f9f4082dbc56 ("dmaengine: idxd: remove interrupt disable for cmd_lock") Signed-off-by: Rex Zhang Signed-off-by: Lijun Pan Reviewed-by: Dave Jiang Reviewed-by: Fenghua Yu Link: https://lore.kernel.org/r/20230916060619.3744220-1-rex.zhang@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 0c1773bf8f386a8e34ce1da6d2c2923aa06299e1 Author: Linus Torvalds Date: Sun Oct 15 12:02:02 2023 -0700 Revert "x86/smp: Put CPUs into INIT on shutdown if possible" commit fbe1bf1e5ff1e3b298420d7a8434983ef8d72bd1 upstream. This reverts commit 45e34c8af58f23db4474e2bfe79183efec09a18b, and the two subsequent fixes to it: 3f874c9b2aae ("x86/smp: Don't send INIT to non-present and non-booted CPUs") b1472a60a584 ("x86/smp: Don't send INIT to boot CPU") because it seems to result in hung machines at shutdown. Particularly some Dell machines, but Thomas says "The rest seems to be Lenovo and Sony with Alderlake/Raptorlake CPUs - at least that's what I could figure out from the various bug reports. I don't know which CPUs the DELL machines have, so I can't say it's a pattern. I agree with the revert for now" Ashok Raj chimes in: "There was a report (probably this same one), and it turns out it was a bug in the BIOS SMI handler. The client BIOS's were waiting for the lowest APICID to be the SMI rendevous master. If this is MeteorLake, the BSP wasn't the one with the lowest APIC and it triped here. The BIOS change is also being pushed to others for assimilation :) Server BIOS's had this correctly for a while now" and it does look likely to be some bad interaction between SMI and the non-BSP cores having put into INIT (and thus unresponsive until reset). Link: https://bbs.archlinux.org/viewtopic.php?pid=2124429 Link: https://www.reddit.com/r/openSUSE/comments/16qq99b/tumbleweed_shutdown_did_not_finish_completely/ Link: https://forum.artixlinux.org/index.php/topic,5997.0.html Link: https://bugzilla.redhat.com/show_bug.cgi?id=2241279 Acked-by: Thomas Gleixner Cc: Ashok Raj Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a9b0e9e651068aa31235322d361848ccfc5844a1 Author: Javier Carrasco Date: Mon Sep 11 10:22:38 2023 +0200 usb: misc: onboard_hub: add support for Microchip USB2412 USB 2.0 hub commit e59e38158c61162f2e8beb4620df21a1585117df upstream. The USB2412 is a 2-Port USB 2.0 hub controller that provides a reset pin and a single 3v3 powre source, which makes it suitable to be controlled by the onboard_hub driver. This hub has the same reset timings as USB2514/2517 and the same onboard hub specific-data can be reused for USB2412. Signed-off-by: Javier Carrasco Cc: stable Acked-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20230911-topic-2412_onboard_hub-v1-1-7704181ddfff@wolfvision.net Signed-off-by: Greg Kroah-Hartman commit 91a9aaad5d8c25ab81df72aaaae308a7461cba6d Author: Hui Liu Date: Thu Aug 31 18:19:45 2023 +0800 usb: typec: qcom: Update the logic of regulator enable and disable commit 76750f1dcad3e1af2295cdf2f9434e06e3178ef3 upstream. Removed the call logic of disable and enable regulator in reset function. Enable the regulator in qcom_pmic_typec_start function and disable it in qcom_pmic_typec_stop function to avoid unbalanced regulator disable warnings. Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver") Cc: stable Reviewed-by: Bryan O'Donoghue Acked-by: Bryan O'Donoghue Tested-by: Bryan O'Donoghue # rb5 Signed-off-by: Hui Liu Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20230831-qcom-tcpc-v5-1-5e2661dc6c1d@quicinc.com Signed-off-by: Greg Kroah-Hartman commit f0c0314aac42189c750307784799560600ce2dfe Author: Pawel Laszczak Date: Thu Jul 13 04:14:29 2023 -0400 usb: cdnsp: Fixes issue with dequeuing not queued requests commit 34f08eb0ba6e4869bbfb682bf3d7d0494ffd2f87 upstream. Gadget ACM while unloading module try to dequeue not queued usb request which causes the kernel to crash. Patch adds extra condition to check whether usb request is processed by CDNSP driver. cc: stable@vger.kernel.org Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Signed-off-by: Pawel Laszczak Acked-by: Peter Chen Link: https://lore.kernel.org/r/20230713081429.326660-1-pawell@cadence.com Signed-off-by: Greg Kroah-Hartman commit 4bf1a9d20c65b9e80ca4b171267103f8d4f2c61f Author: Krishna Kurapati Date: Wed Sep 27 16:28:58 2023 +0530 usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call 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 commit 098bc05652503d4358f90a5d8ffc17086b0feb58 Author: Piyush Mehta Date: Fri Sep 29 17:45:14 2023 +0530 usb: gadget: udc-xilinx: replace memcpy with memcpy_toio 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 commit 3039b7d5ebb7eaab9da10264c7d718e70a39ce3c Author: Prashanth K Date: Mon Sep 11 14:34:15 2023 +0530 usb: typec: ucsi: Clear EVENT_PENDING bit if ucsi_send_command fails commit a00e197daec52bcd955e118f5f57d706da5bfe50 upstream. Currently if ucsi_send_command() fails, then we bail out without clearing EVENT_PENDING flag. So when the next connector change event comes, ucsi_connector_change() won't queue the con->work, because of which none of the new events will be processed. Fix this by clearing EVENT_PENDING flag if ucsi_send_command() fails. Cc: stable@vger.kernel.org # 5.16 Fixes: 512df95b9432 ("usb: typec: ucsi: Better fix for missing unplug events issue") Signed-off-by: Prashanth K Acked-by: Heikki Krogerus Link: https://lore.kernel.org/r/1694423055-8440-1-git-send-email-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman commit 522b7d736575a2237b3ea31b9e01bb9c44db5914 Author: RD Babiera Date: Mon Oct 9 21:00:58 2023 +0000 usb: typec: altmodes/displayport: Signal hpd low when exiting mode commit 89434b069e460967624903b049e5cf5c9e6b99b9 upstream. Upon receiving an ACK for a sent EXIT_MODE message, the DisplayPort driver currently resets the status and configuration of the port partner. The hpd signal is not updated despite being part of the status, so the Display stack can still transmit video despite typec_altmode_exit placing the lanes in a Safe State. Set hpd to low when a sent EXIT_MODE message is ACK'ed. Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode") Cc: stable@vger.kernel.org Signed-off-by: RD Babiera Acked-by: Heikki Krogerus Link: https://lore.kernel.org/r/20231009210057.3773877-2-rdbabiera@google.com Signed-off-by: Greg Kroah-Hartman commit d386632939e006365a28043939b210811f098b98 Author: Heikki Krogerus Date: Tue Oct 10 17:17:49 2023 +0300 usb: typec: ucsi: Fix missing link removal commit dddb91cde52b4a57fa06a332b230fca3b11b885f upstream. The link between the partner device and its USB Power Delivery instance was never removed which prevented the device from being released. Removing the link always when the partner is unregistered. Fixes: b04e1747fbcc ("usb: typec: ucsi: Register USB Power Delivery Capabilities") Cc: stable Reported-by: Douglas Gilbert Closes: https://lore.kernel.org/linux-usb/ZSUMXdw9nanHtnw2@kuha.fi.intel.com/ Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20231010141749.3912016-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit d68c74f3b2db08ae4e8067a919e21f958a1fa1d6 Author: Jiexun Wang Date: Wed Sep 13 13:29:40 2023 +0800 RISC-V: Fix wrong use of CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK commit 07a27665754bf649b5de8e55c655e4d6837406be upstream. If configuration options SOFTIRQ_ON_OWN_STACK and PREEMPT_RT are enabled simultaneously under RISC-V architecture, it will result in a compilation failure: arch/riscv/kernel/irq.c:64:6: error: redefinition of 'do_softirq_own_stack' 64 | void do_softirq_own_stack(void) | ^~~~~~~~~~~~~~~~~~~~ In file included from ./arch/riscv/include/generated/asm/softirq_stack.h:1, from arch/riscv/kernel/irq.c:15: ./include/asm-generic/softirq_stack.h:8:20: note: previous definition of 'do_softirq_own_stack' was here 8 | static inline void do_softirq_own_stack(void) | ^~~~~~~~~~~~~~~~~~~~ After changing CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK to CONFIG_SOFTIRQ_ON_OWN_STACK, compilation can be successful. Fixes: dd69d07a5a6c ("riscv: stack: Support HAVE_SOFTIRQ_ON_OWN_STACK") Reviewed-by: Guo Ren Signed-off-by: Jiexun Wang Reviewed-by: Samuel Holland Link: https://lore.kernel.org/r/20230913052940.374686-1-wangjiexun@tinylab.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 3431cfe773aca11b9ec4a7b508ec695d14e5408e Author: Song Shuai Date: Thu Sep 14 17:13:34 2023 +0800 riscv: Remove duplicate objcopy flag commit 505b02957e74f0c5c4655647ccb04bdc945d18f6 upstream. There are two duplicate `-O binary` flags when objcopying from vmlinux to Image/xipImage. RISC-V set `-O binary` flag in both OBJCOPYFLAGS in the top-level riscv Makefile and OBJCOPYFLAGS_* in the boot/Makefile, and the objcopy cmd in Kbuild would join them together. The `-O binary` flag is only needed for objcopying Image, so remove the OBJCOPYFLAGS in the top-level riscv Makefile. Fixes: c0fbcd991860 ("RISC-V: Build flat and compressed kernel images") Signed-off-by: Song Shuai Reviewed-by: Palmer Dabbelt Link: https://lore.kernel.org/r/20230914091334.1458542-1-songshuaishuai@tinylab.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit fdd3ceb0001da6768bede9779a0190a42e65c404 Author: Linu Cherian Date: Wed Aug 23 09:59:48 2023 +0530 coresight: Fix run time warnings while reusing ETR buffer commit bd2767ec3df2775bc336f441f9068a989ccb919d upstream. Fix the below warning by avoding calls to tmc_etr_enable_hw, if we are reusing the ETR buffer for multiple sources in sysfs mode. echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink echo 1 > /sys/bus/coresight/devices/ete1/enable_source echo 1 > /sys/bus/coresight/devices/ete2/enable_source [ 166.918290] ------------[ cut here ]------------ [ 166.922905] WARNING: CPU: 4 PID: 2288 at drivers/hwtracing/coresight/coresight-tmc-etr.c:1037 tmc_etr_enable_hw+0xb0/0xc8 [ 166.933862] Modules linked in: [ 166.936911] CPU: 4 PID: 2288 Comm: bash Not tainted 6.5.0-rc7 #132 [ 166.943084] Hardware name: Marvell CN106XX board (DT) [ 166.948127] pstate: 834000c9 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) [ 166.955083] pc : tmc_etr_enable_hw+0xb0/0xc8 [ 166.959345] lr : tmc_enable_etr_sink+0x134/0x210 snip.. 167.038545] Call trace: [ 167.040982] tmc_etr_enable_hw+0xb0/0xc8 [ 167.044897] tmc_enable_etr_sink+0x134/0x210 [ 167.049160] coresight_enable_path+0x160/0x278 [ 167.053596] coresight_enable+0xd4/0x298 [ 167.057510] enable_source_store+0x54/0xa0 [ 167.061598] dev_attr_store+0x20/0x40 [ 167.065254] sysfs_kf_write+0x4c/0x68 [ 167.068909] kernfs_fop_write_iter+0x128/0x200 [ 167.073345] vfs_write+0x1ac/0x2f8 [ 167.076739] ksys_write+0x74/0x110 [ 167.080132] __arm64_sys_write+0x24/0x38 [ 167.084045] invoke_syscall.constprop.0+0x58/0xf8 [ 167.088744] do_el0_svc+0x60/0x160 [ 167.092137] el0_svc+0x40/0x170 [ 167.095273] el0t_64_sync_handler+0x100/0x130 [ 167.099621] el0t_64_sync+0x190/0x198 [ 167.103277] ---[ end trace 0000000000000000 ]--- -bash: echo: write error: Device or resource busy Fixes: 296b01fd106e ("coresight: Refactor out buffer allocation function for ETR") Signed-off-by: Linu Cherian Reviewed-by: James Clark Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20230823042948.12879-1-lcherian@marvell.com Signed-off-by: Greg Kroah-Hartman commit 8c4f6d1a8e4da38b0f72694750c42524ea9ea4df Author: Dharma Balasubiramani Date: Tue Sep 5 15:38:35 2023 +0530 counter: microchip-tcb-capture: Fix the use of internal GCLK logic 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 commit 837b24646cfda86cfb8fb0965bc0d42d0d7160d2 Author: Fabrice Gasnier Date: Tue Aug 29 15:40:22 2023 +0200 counter: chrdev: fix getting array extensions commit 3170256d7bc1ef81587caf4b83573eb1f5bb4fb6 upstream. When trying to watch a component array extension, and the array isn't the first extended element, it fails as the type comparison is always done on the 1st element. Fix it by indexing the 'ext' array. Example on a dummy struct counter_comp: static struct counter_comp dummy[] = { COUNTER_COMP_DIRECTION(..), ..., COUNTER_COMP_ARRAY_CAPTURE(...), }; static struct counter_count dummy_cnt = { ... .ext = dummy, .num_ext = ARRAY_SIZE(dummy), } Currently, counter_get_ext() returns -EINVAL when trying to add a watch event on one of the capture array element in such example. Fixes: d2011be1e22f ("counter: Introduce the COUNTER_COMP_ARRAY component type") Signed-off-by: Fabrice Gasnier Link: https://lore.kernel.org/r/20230829134029.2402868-2-fabrice.gasnier@foss.st.com Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman commit 6a4a432e616f865bff2ead22d5045f47fbe59f53 Author: Björn Töpel Date: Tue Sep 12 08:56:19 2023 +0200 riscv: Only consider swbp/ss handlers for correct privileged mode commit 9f564b92cf6d0ecb398f9348600a7d8a7f8ea804 upstream. RISC-V software breakpoint trap handlers are used for {k,u}probes. When trapping from kernelmode, only the kernelmode handlers should be considered. Vice versa, only usermode handlers for usermode traps. This is not the case on RISC-V, which can trigger a bug if a userspace process uses uprobes, and a WARN() is triggered from kernelmode (which is implemented via {c.,}ebreak). The kernel will trap on the kernelmode {c.,}ebreak, look for uprobes handlers, realize incorrectly that uprobes need to be handled, and exit the trap handler early. The trap returns to re-executing the {c.,}ebreak, and enter an infinite trap-loop. The issue was found running the BPF selftest [1]. Fix this issue by only considering the swbp/ss handlers for kernel/usermode respectively. Also, move CONFIG ifdeffery from traps.c to the asm/{k,u}probes.h headers. Note that linux/uprobes.h only include asm/uprobes.h if CONFIG_UPROBES is defined, which is why asm/uprobes.h needs to be unconditionally included in traps.c Link: https://lore.kernel.org/linux-riscv/87v8d19aun.fsf@all.your.base.are.belong.to.us/ # [1] Fixes: 74784081aac8 ("riscv: Add uprobes supported") Reviewed-by: Guo Ren Reviewed-by: Nam Cao Tested-by: Puranjay Mohan Signed-off-by: Björn Töpel Link: https://lore.kernel.org/r/20230912065619.62020-1-bjorn@kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 27f69c85f445ccebdf290e29a89e17e8dfa99349 Author: Peter Wang Date: Tue Oct 3 10:20:02 2023 +0800 scsi: ufs: core: Correct clear TM error log commit a20c4350c6a12405b7f732b3ee6801ffe2cc45ce upstream. The clear TM function error log status was inverted. Fixes: 4693fad7d6d4 ("scsi: ufs: core: Log error handler activity") Signed-off-by: Peter Wang Link: https://lore.kernel.org/r/20231003022002.25578-1-peter.wang@mediatek.com Reviewed-by: Bart Van Assche Reviewed-by: Stanley Chu Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d2180b58a8a180afbb5344d9876b8ec8e029996b Author: Dmitry Torokhov Date: Wed Sep 20 11:09:10 2023 -0700 pinctrl: avoid unsafe code pattern in find_pinctrl() 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 commit a473943294f102f31d77b70adce9423e82b022c4 Author: Christian König Date: Fri Sep 8 10:27:23 2023 +0200 dma-buf: add dma_fence_timestamp helper commit b83ce9cb4a465b8f9a3fa45561b721a9551f60e3 upstream. When a fence signals there is a very small race window where the timestamp isn't updated yet. sync_file solves this by busy waiting for the timestamp to appear, but on other ocassions didn't handled this correctly. Provide a dma_fence_timestamp() helper function for this and use it in all appropriate cases. Another alternative would be to grab the spinlock when that happens. v2 by teddy: add a wait parameter to wait for the timestamp to show up, in case the accurate timestamp is needed and/or the timestamp is not based on ktime (e.g. hw timestamp) v3 chk: drop the parameter again for unified handling Signed-off-by: Yunxiang Li Signed-off-by: Christian König Fixes: 1774baa64f93 ("drm/scheduler: Change scheduled fence track v2") Reviewed-by: Alex Deucher CC: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20230929104725.2358-1-christian.koenig@amd.com Signed-off-by: Greg Kroah-Hartman commit da9de0b714d5c46583276fdb3e3d475b7bfecc0e Author: Michal Koutný Date: Mon Oct 9 15:58:11 2023 +0200 cgroup: Remove duplicates in cgroup v1 tasks file 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 commit c3239301ef7a34e9734328d0d6573b18c66fb1ff Author: Mario Limonciello Date: Mon Oct 9 13:46:43 2023 -0500 usb: typec: ucsi: Use GET_CAPABILITY attributes data to set power supply scope commit c9ca8de2eb15f9da24113e652980c61f95a47530 upstream. On some OEM systems, adding a W7900 dGPU triggers RAS errors and hangs at a black screen on startup. This issue occurs only if `ucsi_acpi` has loaded before `amdgpu` has loaded. The reason for this failure is that `amdgpu` uses power_supply_is_system_supplied() to determine if running on AC or DC power at startup. If this value is reported incorrectly the dGPU will also be programmed incorrectly and trigger errors. power_supply_is_system_supplied() reports the wrong value because UCSI power supplies provided as part of the system don't properly report the scope as "DEVICE" scope (not powering the system). In order to fix this issue check the capabilities reported from the UCSI power supply to ensure that it supports charging a battery and that it can be powered by AC. Mark the scope accordingly. Cc: stable@vger.kernel.org Fixes: a7fbfd44c020 ("usb: typec: ucsi: Mark dGPUs as DEVICE scope") Link: https://www.intel.com/content/www/us/en/products/docs/io/universal-serial-bus/usb-type-c-ucsi-spec.html p28 Reviewed-by: Sebastian Reichel Signed-off-by: Mario Limonciello Acked-by: Heikki Krogerus Link: https://lore.kernel.org/r/20231009184643.129986-1-mario.limonciello@amd.com Signed-off-by: Greg Kroah-Hartman commit 92437349c0f015b9e74ba0b3414180785a796900 Author: Johan Hovold Date: Fri Sep 29 12:16:49 2023 +0200 power: supply: qcom_battmgr: fix enable request endianness commit 8894b432548851f705f72ff135d3dcbd442a18d1 upstream. Add the missing endianness conversion when sending the enable request so that the driver will work also on a hypothetical big-endian machine. This issue was reported by sparse. Fixes: 29e8142b5623 ("power: supply: Introduce Qualcomm PMIC GLINK power supply") Cc: stable@vger.kernel.org # 6.3 Cc: Bjorn Andersson Signed-off-by: Johan Hovold Reviewed-by: Andrew Halaney Link: https://lore.kernel.org/r/20230929101649.20206-1-johan+linaro@kernel.org Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit fbda26ff92e0efcbb1b9172bc469782ecf4c8463 Author: Sebastian Reichel Date: Tue Sep 19 14:42:22 2023 +0200 power: supply: qcom_battmgr: fix battery_id type commit 383eba9f9a7f4cd639d367ea5daa6df2be392c54 upstream. qcom_battmgr_update_request.battery_id is written to using cpu_to_le32() and should be of type __le32, just like all other 32bit integer requests for qcom_battmgr. Cc: stable@vger.kernel.org # 6.3 Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202309162149.4owm9iXc-lkp@intel.com/ Fixes: 29e8142b5623 ("power: supply: Introduce Qualcomm PMIC GLINK power supply") Reviewed-by: Johan Hovold Link: https://lore.kernel.org/r/20230919124222.1155894-1-sebastian.reichel@collabora.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 704e0e2a0c60683702be51678651829bb9d2775a Author: Miquel Raynal Date: Mon Oct 2 18:02:06 2023 +0200 can: sja1000: Always restart the Tx queue after an overrun commit b5efb4e6fbb06da928526eca746f3de243c12ab2 upstream. Upstream commit 717c6ec241b5 ("can: sja1000: Prevent overrun stalls with a soft reset on Renesas SoCs") fixes an issue with Renesas own SJA1000 CAN controller reception: the Rx buffer is only 5 messages long, so when the bus loaded (eg. a message every 50us), overrun may easily happen. Upon an overrun situation, due to a possible internal crosstalk situation, the controller enters a frozen state which only can be unlocked with a soft reset (experimentally). The solution was to offload a call to sja1000_start() in a threaded handler. This needs to happen in process context as this operation requires to sleep. sja1000_start() basically enters "reset mode", performs a proper software reset and returns back into "normal mode". Since this fix was introduced, we no longer observe any stalls in reception. However it was sporadically observed that the transmit path would now freeze. Further investigation blamed the fix mentioned above, and especially the reset operation. Reproducing the reset in a loop helped identifying what could possibly go wrong. The sja1000 is a single Tx queue device, which leverages the netdev helpers to process one Tx message at a time. The logic is: the queue is stopped, the message sent to the transceiver, once properly transmitted the controller sets a status bit which triggers an interrupt, in the interrupt handler the transmission status is checked and the queue woken up. Unfortunately, if an overrun happens, we might perform the soft reset precisely between the transmission of the buffer to the transceiver and the advent of the transmission status bit. We would then stop the transmission operation without re-enabling the queue, leading to all further transmissions to be ignored. The reset interrupt can only happen while the device is "open", and after a reset we anyway want to resume normal operations, no matter if a packet to transmit got dropped in the process, so we shall wake up the queue. Restarting the device and waking-up the queue is exactly what sja1000_set_mode(CAN_MODE_START) does. In order to be consistent about the queue state, we must acquire a lock both in the reset handler and in the transmit path to ensure serialization of both operations. It turns out, a lock is already held when entering the transmit path, so we can just acquire/release it as well with the regular net helpers inside the threaded interrupt handler and this way we should be safe. As the reset handler might still be called after the transmission of a frame to the transceiver but before it actually gets transmitted, we must ensure we don't leak the skb, so we free it (the behavior is consistent, no matter if there was an skb on the stack or not). Fixes: 717c6ec241b5 ("can: sja1000: Prevent overrun stalls with a soft reset on Renesas SoCs") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/all/20231002160206.190953-1-miquel.raynal@bootlin.com [mkl: fixed call to can_free_echo_skb()] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit fc9ea80fa4e9f28561f9e58a8cc83c5fcb1113ee Author: Yanguo Li Date: Mon Oct 9 13:21:55 2023 +0200 nfp: flower: avoid rmmod nfp crash issues commit 14690995c14109852c7ba6e316045c02e4254272 upstream. When there are CT table entries, and you rmmod nfp, the following events can happen: task1： nfp_net_pci_remove ↓ nfp_flower_stop->(asynchronous)tcf_ct_flow_table_cleanup_work(3) ↓ nfp_zone_table_entry_destroy(1) task2： nfp_fl_ct_handle_nft_flow(2) When the execution order is (1)->(2)->(3), it will crash. Therefore, in the function nfp_fl_ct_del_flow, nf_flow_table_offload_del_cb needs to be executed synchronously. At the same time, in order to solve the deadlock problem and the problem of rtnl_lock sometimes failing, replace rtnl_lock with the private nfp_fl_lock. Fixes: 7cc93d888df7 ("nfp: flower-ct: remove callback delete deadlock") Cc: stable@vger.kernel.org Signed-off-by: Yanguo Li Signed-off-by: Louis Peens Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f7c949fa298fa6489e8eb6e9c9e6d8ba835c3b12 Author: Sarthak Kukreti Date: Wed Oct 11 13:12:30 2023 -0700 block: Don't invalidate pagecache for invalid falloc modes commit 1364a3c391aedfeb32aa025303ead3d7c91cdf9d upstream. Only call truncate_bdev_range() if the fallocate mode is supported. This fixes a bug where data in the pagecache could be invalidated if the fallocate() was called on the block device with an invalid mode. Fixes: 25f4c41415e5 ("block: implement (some of) fallocate for block devices") Cc: stable@vger.kernel.org Reported-by: "Darrick J. Wong" Signed-off-by: Sarthak Kukreti Reviewed-by: Christoph Hellwig Reviewed-by: "Darrick J. Wong" Signed-off-by: Mike Snitzer Fixes: line? I've never seen those wrapped. Link: https://lore.kernel.org/r/20231011201230.750105-1-sarthakkukreti@chromium.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2405f64a95a7a094eb24cba9bcfaffd1ea264de4 Author: Jeremy Kerr Date: Mon Oct 9 15:56:45 2023 +0800 mctp: perform route lookups under a RCU read-side lock commit 5093bbfc10ab6636b32728e35813cbd79feb063c upstream. Our current route lookups (mctp_route_lookup and mctp_route_lookup_null) traverse the net's route list without the RCU read lock held. This means the route lookup is subject to preemption, resulting in an potential grace period expiry, and so an eventual kfree() while we still have the route pointer. Add the proper read-side critical section locks around the route lookups, preventing premption and a possible parallel kfree. The remaining net->mctp.routes accesses are already under a rcu_read_lock, or protected by the RTNL for updates. Based on an analysis from Sili Luo , where introducing a delay in the route lookup could cause a UAF on simultaneous sendmsg() and route deletion. Reported-by: Sili Luo Fixes: 889b7da23abf ("mctp: Add initial routing framework") Cc: stable@vger.kernel.org Signed-off-by: Jeremy Kerr Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/29c4b0e67dc1bf3571df3982de87df90cae9b631.1696837310.git.jk@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1c95574350cd63bc3c5c2fa06658010768f2a0ce Author: Rijo Thomas Date: Fri Sep 29 12:30:24 2023 +0530 tee: amdtee: fix use-after-free vulnerability in amdtee_close_session 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 commit b8f18fa39cecda62b1064208bf757e4de6f652ac Author: Hans de Goede Date: Wed Oct 4 07:18:31 2023 -0700 Input: goodix - ensure int GPIO is in input for gpio_count == 1 && gpio_int_idx == 0 case 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 commit eb2b6503a6ff6200c267352f1a6c23cb285d82ba Author: Max Nguyen Date: Sun Sep 17 22:21:53 2023 -0700 Input: xpad - add HyperX Clutch Gladiate Support commit e28a0974d749e5105d77233c0a84d35c37da047e upstream. Add HyperX controller support to xpad_device and xpad_table. Suggested-by: Chris Toledanes Reviewed-by: Carl Ng Signed-off-by: Max Nguyen Reviewed-by: Rahul Rameshbabu Link: https://lore.kernel.org/r/20230906231514.4291-1-hphyperxdev@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8a2c1970a17822d209f13addbae9854901ef596c Author: Szilard Fabian Date: Wed Oct 4 05:47:01 2023 -0700 Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table 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 commit 9832f2274abe3a3b3e3aea1c8699bcf00ac84f87 Author: Matthias Berndt Date: Fri Oct 13 15:04:36 2023 -0700 Input: xpad - add PXN V900 support 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 commit eb12a7d348edeb2a8aabecb4342a997cb0251285 Author: Jeffery Miller Date: Fri Oct 13 15:23:49 2023 -0700 Input: psmouse - fix fast_reconnect function for PS/2 mode 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 commit e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8 Author: Javier Carrasco Date: Fri Oct 13 20:11:33 2023 -0700 Input: powermate - fix use-after-free in powermate_config_complete 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 commit 093f82c2b56b95ac7838d05380a45d66e09b5965 Author: Dan Carpenter Date: Sat Oct 7 11:52:39 2023 +0300 ceph: fix type promotion bug on 32bit systems 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 commit afe8dcef4b7a79b11b6497cddf5cab390b8ad9a8 Author: Xiubo Li Date: Wed Sep 6 14:22:07 2023 +0800 ceph: fix incorrect revoked caps assert in ceph_fill_file_size() 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 commit 707ee65259871926ddf14d5c8bdf62fc7a34615a Author: Jordan Rife Date: Wed Oct 4 18:38:27 2023 -0500 libceph: use kernel_connect() 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 commit 70f6756ad96dd70177dddcfac2fe4bd4bb320746 Author: Michael Ellerman Date: Tue Oct 10 22:47:50 2023 +1100 powerpc/47x: Fix 47x syscall return crash commit f0eee815babed70a749d2496a7678be5b45b4c14 upstream. Eddie reported that newer kernels were crashing during boot on his 476 FSP2 system: kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0) BUG: Unable to handle kernel instruction fetch Faulting instruction address: 0xb7ee2000 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K FSP-2 Modules linked in: CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1 Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2 NIP:  b7ee2000 LR: 8c008000 CTR: 00000000 REGS: bffebd83 TRAP: 0400   Not tainted (6.1.55-d23900f.ppcnf-fs p2) MSR:  00000030   CR: 00001000  XER: 20000000 GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000 GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000 GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0 GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0 NIP [b7ee2000] 0xb7ee2000 LR [8c008000] 0x8c008000 Call Trace: Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 0000000000000000 ]--- The problem is in ret_from_syscall where the check for icache_44x_need_flush is done. When the flush is needed the code jumps out-of-line to do the flush, and then intends to jump back to continue the syscall return. However the branch back to label 1b doesn't return to the correct location, instead branching back just prior to the return to userspace, causing bogus register values to be used by the rfi. The breakage was introduced by commit 6f76a01173cc ("powerpc/syscall: implement system call entry/exit logic in C for PPC32") which inadvertently removed the "1" label and reused it elsewhere. Fix it by adding named local labels in the correct locations. Note that the return label needs to be outside the ifdef so that CONFIG_PPC_47x=n compiles. Fixes: 6f76a01173cc ("powerpc/syscall: implement system call entry/exit logic in C for PPC32") Cc: stable@vger.kernel.org # v5.12+ Reported-by: Eddie James Tested-by: Eddie James Link: https://lore.kernel.org/linuxppc-dev/fdaadc46-7476-9237-e104-1d2168526e72@linux.ibm.com/ Signed-off-by: Michael Ellerman Reviewed-by: Christophe Leroy Link: https://msgid.link/20231010114750.847794-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit e28ca99f2f9cfe44bf252ea2809d22280c966464 Author: Athira Rajeev Date: Fri Sep 29 22:53:36 2023 +0530 powerpc/pseries: Fix STK_PARAM access in the hcall tracing code commit 3b678768c0458e6d8d45fadf61423e44effed4cb upstream. In powerpc pseries system, below behaviour is observed while enabling tracing on hcall: # cd /sys/kernel/debug/tracing/ # cat events/powerpc/hcall_exit/enable 0 # echo 1 > events/powerpc/hcall_exit/enable # ls -bash: fork: Bad address Above is from power9 lpar with latest kernel. Past this, softlockup is observed. Initially while attempting via perf_event_open to use "PERF_TYPE_TRACEPOINT", kernel panic was observed. perf config used: ================ memset(&pe[1],0,sizeof(struct perf_event_attr)); pe[1].type=PERF_TYPE_TRACEPOINT; pe[1].size=96; pe[1].config=0x26ULL; /* 38 raw_syscalls/sys_exit */ pe[1].sample_type=0; /* 0 */ pe[1].read_format=PERF_FORMAT_TOTAL_TIME_ENABLED|PERF_FORMAT_TOTAL_TIME_RUNNING|PERF_FORMAT_ID|PERF_FORMAT_GROUP|0x10ULL; /* 1f */ pe[1].inherit=1; pe[1].precise_ip=0; /* arbitrary skid */ pe[1].wakeup_events=0; pe[1].bp_type=HW_BREAKPOINT_EMPTY; pe[1].config1=0x1ULL; Kernel panic logs: ================== Kernel attempted to read user page (8) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000008 Faulting instruction address: 0xc0000000004c2814 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: nfnetlink bonding tls rfkill sunrpc dm_service_time dm_multipath pseries_rng xts vmx_crypto xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ibmvfc scsi_transport_fc ibmveth dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 0 PID: 1431 Comm: login Not tainted 6.4.0+ #1 Hardware name: IBM,8375-42A POWER9 (raw) 0x4e0202 0xf000005 of:IBM,FW950.30 (VL950_892) hv:phyp pSeries NIP page_remove_rmap+0x44/0x320 LR wp_page_copy+0x384/0xec0 Call Trace: 0xc00000001416e400 (unreliable) wp_page_copy+0x384/0xec0 __handle_mm_fault+0x9d4/0xfb0 handle_mm_fault+0xf0/0x350 ___do_page_fault+0x48c/0xc90 hash__do_page_fault+0x30/0x70 do_hash_fault+0x1a4/0x330 data_access_common_virt+0x198/0x1f0 --- interrupt: 300 at 0x7fffae971abc git bisect tracked this down to below commit: 'commit baa49d81a94b ("powerpc/pseries: hvcall stack frame overhead")' This commit changed STACK_FRAME_OVERHEAD (112 ) to STACK_FRAME_MIN_SIZE (32 ) since 32 bytes is the minimum size for ELFv2 stack. With the latest kernel, when running on ELFv2, STACK_FRAME_MIN_SIZE is used to allocate stack size. During plpar_hcall_trace, first call is made to HCALL_INST_PRECALL which saves the registers and allocates new stack frame. In the plpar_hcall_trace code, STK_PARAM is accessed at two places. 1. To save r4: std r4,STK_PARAM(R4)(r1) 2. To access r4 back: ld r12,STK_PARAM(R4)(r1) HCALL_INST_PRECALL precall allocates a new stack frame. So all the stack parameter access after the precall, needs to be accessed with +STACK_FRAME_MIN_SIZE. So the store instruction should be: std r4,STACK_FRAME_MIN_SIZE+STK_PARAM(R4)(r1) If the "std" is not updated with STACK_FRAME_MIN_SIZE, we will end up with overwriting stack contents and cause corruption. But instead of updating 'std', we can instead remove it since HCALL_INST_PRECALL already saves it to the correct location. similarly load instruction should be: ld r12,STACK_FRAME_MIN_SIZE+STK_PARAM(R4)(r1) Fix the load instruction to correctly access the stack parameter with +STACK_FRAME_MIN_SIZE and remove the store of r4 since the precall saves it correctly. Cc: stable@vger.kernel.org # v6.2+ Fixes: baa49d81a94b ("powerpc/pseries: hvcall stack frame overhead") Co-developed-by: Naveen N Rao Signed-off-by: Naveen N Rao Signed-off-by: Athira Rajeev Signed-off-by: Michael Ellerman Link: https://msgid.link/20230929172337.7906-1-atrajeev@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman commit b6ab7f19a44f8d1c41638de9dc1979bd37488bd7 Author: Mika Westerberg Date: Thu Sep 7 16:02:30 2023 +0300 thunderbolt: Restart XDomain discovery handshake after failure commit 308092d080852f8997126e5b3507536162416f4a upstream. Alex reported that after rebooting the other host the peer-to-peer link does not come up anymore. The reason for this is that the host that was not rebooted tries to send the UUID request only 10 times according to the USB4 Inter-Domain spec and gives up if it does not get reply. Then when the other side is actually ready it cannot get the link established anymore. The USB4 Inter-Domain spec requires that the discovery protocol is restarted in that case so implement this now. Reported-by: Alex Balcanquall Fixes: 8e1de7042596 ("thunderbolt: Add support for XDomain lane bonding") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 9828a7fa65a6767128832c0b94780361d9446baf Author: Mika Westerberg Date: Thu Aug 31 14:10:46 2023 +0300 thunderbolt: Correct TMU mode initialization from hardware commit e19f714ea63f861d95d3d92d45d5fd5ca2e05c8c upstream. David reported that cppcheck found following possible copy & paste error from tmu_mode_init(): tmu.c:385:50: style: Expression is always false because 'else if' condition matches previous condition at line 383. [multiCondition] And indeed this is a bug. Fix it to use correct index (TB_SWITCH_TMU_MODE_HIFI_UNI). Reported-by: David Binderman Fixes: d49b4f043d63 ("thunderbolt: Add support for enhanced uni-directional TMU mode") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 7525edf6aca5fd0ab7e1ccafc1c38017fb3ef4ae Author: Mika Westerberg Date: Tue Aug 22 16:36:18 2023 +0300 thunderbolt: Check that lane 1 is in CL0 before enabling lane bonding 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 commit 5e9e8b6448f4f925da4dfa748c8ca74fb984f768 Author: Mika Westerberg Date: Fri Aug 18 15:27:46 2023 +0300 thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge commit 582620d9f6b352552bc9a3316fe2b1c3acd8742d upstream. On some systems the IOMMU blocks the first couple of driver ready messages to the connection manager firmware as can be seen in below excerpts: thunderbolt 0000:06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbb0e3400 flags=0x0020] or DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Write] Request device [04:00.0] PASID ffffffff fault addr 69974000 [fault reason 05] PTE Write access is not set The reason is unknown and hard to debug because we were not able to reproduce this locally. This only happens on certain systems with Intel Maple Ridge Thunderbolt controller. If there is a device connected when the driver is loaded the issue does not happen either. Only when there is nothing connected (so typically when the system is booted up). We can work this around by sending the driver ready several times. After a couple of retries the message goes through and the controller works just fine. For this reason make the number of retries a parameter for icm_request() and then for Maple Ridge (and Titan Ridge as they us the same function but this should not matter) increase number of retries while shortening the timeout accordingly. Reported-by: Werner Sembach Reported-by: Konrad J Hambrick Reported-by: Calvin Walton Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214259 Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit 3953f7ca6521534375868dd9de3bef8cb85b73af Author: Jorge Sanjuan Garcia Date: Wed Sep 6 11:49:26 2023 +0000 mcb: remove is_added flag from mcb_device struct 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 commit cd287cc208dfe6bd6da98e7f88e723209242c9b4 Author: Kirill A. Shutemov Date: Thu Oct 12 13:04:24 2023 +0300 x86/alternatives: Disable KASAN in apply_alternatives() commit d35652a5fc9944784f6f50a5c979518ff8dacf61 upstream. Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine: BUG: KASAN: out-of-bounds in rcu_is_watching() Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0 ... __asan_load4() rcu_is_watching() trace_hardirqs_on() text_poke_early() apply_alternatives() ... On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57) gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled(). KASAN gets confused when apply_alternatives() patches the KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue. Fix it for real by disabling KASAN while the kernel is patching alternatives. [ mingo: updated the changelog ] Fixes: 6657fca06e3f ("x86/mm: Allow to boot without LA57 if CONFIG_X86_5LEVEL=y") Reported-by: Fei Yang Signed-off-by: Kirill A. Shutemov Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231012100424.1456-1-kirill.shutemov@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 12f8e4d71d996daddaebb93ea874871c02f21e49 Author: Borislav Petkov (AMD) Date: Sat Oct 7 12:57:02 2023 +0200 x86/cpu: Fix AMD erratum #1485 on Zen4-based CPUs 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 commit f71edacbd4f99c0e12fe4a4007ab4d687d0688db Author: JP Kobryn Date: Fri Oct 6 11:57:26 2023 -0700 perf/x86/lbr: Filter vsyscall addresses commit e53899771a02f798d436655efbd9d4b46c0f9265 upstream. We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region. Suggested-by: Alexei Starovoitov Signed-off-by: JP Kobryn Signed-off-by: Ingo Molnar Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f40723f20839c188421aa9e95bdb550b2981273c Author: Namjae Jeon Date: Fri Oct 6 10:41:36 2023 +0900 ksmbd: not allow to open file if delelete on close bit is set commit f43328357defc0dc9d28dbd06dc3361fd2b22e28 upstream. Cthon test fail with the following error. check for proper open/unlink operation nfsjunk files before unlink: -rwxr-xr-x 1 root root 0 9월 25 11:03 ./nfs2y8Jm9 ./nfs2y8Jm9 open; unlink ret = 0 nfsjunk files after unlink: -rwxr-xr-x 1 root root 0 9월 25 11:03 ./nfs2y8Jm9 data compare ok nfsjunk files after close: ls: cannot access './nfs2y8Jm9': No such file or directory special tests failed Cthon expect to second unlink failure when file is already unlinked. ksmbd can not allow to open file if flags of ksmbd inode is set with S_DEL_ON_CLS flags. Cc: stable@vger.kernel.org Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 77d616b2b4ed7474ea3952d6bd898e64f09f30d2 Author: Carlos Llamas Date: Fri Sep 22 17:51:37 2023 +0000 binder: fix memory leaks of spam and pending work commit 1aa3aaf8953c84bad398adf6c3cabc9d6685bf7d upstream. A transaction complete work is allocated and queued for each transaction. Under certain conditions the work->type might be marked as BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT to notify userspace about potential spamming threads or as BINDER_WORK_TRANSACTION_PENDING when the target is currently frozen. However, these work types are not being handled in binder_release_work() so they will leak during a cleanup. This was reported by syzkaller with the following kmemleak dump: BUG: memory leak unreferenced object 0xffff88810e2d6de0 (size 32): comm "syz-executor338", pid 5046, jiffies 4294968230 (age 13.590s) hex dump (first 32 bytes): e0 6d 2d 0e 81 88 ff ff e0 6d 2d 0e 81 88 ff ff .m-......m-..... 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x25/0x90 mm/slab_common.c:1114 [] kmalloc include/linux/slab.h:599 [inline] [] kzalloc include/linux/slab.h:720 [inline] [] binder_transaction+0x573/0x4050 drivers/android/binder.c:3152 [] binder_thread_write+0x6b5/0x1860 drivers/android/binder.c:4010 [] binder_ioctl_write_read drivers/android/binder.c:5066 [inline] [] binder_ioctl+0x1b2c/0x3cf0 drivers/android/binder.c:5352 [] vfs_ioctl fs/ioctl.c:51 [inline] [] __do_sys_ioctl fs/ioctl.c:871 [inline] [] __se_sys_ioctl fs/ioctl.c:857 [inline] [] __x64_sys_ioctl+0xf2/0x140 fs/ioctl.c:857 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fix the leaks by kfreeing these work types in binder_release_work() and handle them as a BINDER_WORK_TRANSACTION_COMPLETE cleanup. Cc: stable@vger.kernel.org Fixes: 0567461a7a6e ("binder: return pending info for frozen async txns") Fixes: a7dc1e6f99df ("binder: tell userspace to dump current backtrace when detected oneway spamming") Reported-by: syzbot+7f10c1653e35933c0f1e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7f10c1653e35933c0f1e Suggested-by: Alice Ryhl Signed-off-by: Carlos Llamas Reviewed-by: Alice Ryhl Acked-by: Todd Kjos Link: https://lore.kernel.org/r/20230922175138.230331-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman commit 8459746f889d72794c164d18423344686267a451 Author: Tony Lindgren Date: Thu Oct 5 10:56:42 2023 +0300 serial: core: Fix checks for tx runtime PM state commit 81a61051e0ce5fd7e09225c0d5985da08c7954a7 upstream. Maximilian reported that surface_serial_hub serdev tx does not work during system suspend. During system suspend, runtime PM gets disabled in __device_suspend_late(), and tx is unable to wake-up the serial core port device that we use to check if tx is safe to start. Johan summarized the regression noting that serdev tx no longer always works as earlier when the serdev device is runtime PM active. The serdev device and the serial core controller devices are siblings of the serial port hardware device. The runtime PM usage count from serdev device does not propagate to the serial core device siblings, it only propagates to the parent. In addition to the tx issue for suspend, testing for the serial core port device can cause an unnecessary delay in enabling tx while waiting for the serial core port device to wake-up. The serial core port device wake-up is only needed to flush pending tx when the serial port hardware device was in runtime PM suspended state. To fix the regression, we need to check the runtime PM state of the parent serial port hardware device for tx instead of the serial core port device. As the serial port device drivers may or may not implement runtime PM, we need to also add a check for pm_runtime_enabled(). Reported-by: Maximilian Luz Cc: stable Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") Signed-off-by: Tony Lindgren Tested-by: Maximilian Luz Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20231005075644.25936-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman commit 02c7efd75c61e804d02512a22a84be6a539c4b21 Author: Tony Lindgren Date: Tue Sep 26 09:13:17 2023 +0300 serial: 8250_omap: Fix errors with no_console_suspend commit 560706eff7c8e5621b0d63afe0866e0e1906e87e upstream. We now get errors on system suspend if no_console_suspend is set as reported by Thomas. The errors started with commit 20a41a62618d ("serial: 8250_omap: Use force_suspend and resume for system suspend"). Let's fix the issue by checking for console_suspend_enabled in the system suspend and resume path. Note that with this fix the checks for console_suspend_enabled in omap8250_runtime_suspend() become useless. We now keep runtime PM usage count for an attached kernel console starting with commit bedb404e91bb ("serial: 8250_port: Don't use power management for kernel console"). Fixes: 20a41a62618d ("serial: 8250_omap: Use force_suspend and resume for system suspend") Cc: stable Cc: Udit Kumar Reported-by: Thomas Richard Signed-off-by: Tony Lindgren Tested-by: Thomas Richard Reviewed-by: Dhruva Gole Link: https://lore.kernel.org/r/20230926061319.15140-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman commit 031ddb94d4ef3db2b2cacdb03cb94b0cf422b856 Author: Lukas Wunner Date: Thu Sep 21 16:52:33 2023 +0200 serial: Reduce spinlocked portion of uart_rs485_config() commit 8679328eb859d06a1984ab48d90ac35d11bbcaf1 upstream. Commit 44b27aec9d96 ("serial: core, 8250: set RS485 termination GPIO in serial core") enabled support for RS485 termination GPIOs behind i2c expanders by setting the GPIO outside of the critical section protected by the port spinlock. Access to the i2c expander may sleep, which caused a splat with the port spinlock held. Commit 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way") erroneously regressed that by spinlocking the GPIO manipulation again. Fix by moving uart_rs485_config() (the function manipulating the GPIO) outside of the spinlocked section and acquiring the spinlock inside of uart_rs485_config() for the invocation of ->rs485_config() only. This gets us one step closer to pushing the spinlock down into the ->rs485_config() callbacks which actually need it. (Some callbacks do not want to be spinlocked because they perform sleepable register accesses, see e.g. sc16is7xx_config_rs485().) Stack trace for posterity: Voluntary context switch within RCU read-side critical section! WARNING: CPU: 0 PID: 56 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch Call trace: rcu_note_context_switch __schedule schedule schedule_timeout wait_for_completion_timeout bcm2835_i2c_xfer __i2c_transfer i2c_transfer i2c_transfer_buffer_flags regmap_i2c_write _regmap_raw_write_impl _regmap_bus_raw_write _regmap_write _regmap_update_bits regmap_update_bits_base pca953x_gpio_set_value gpiod_set_raw_value_commit gpiod_set_value_nocheck gpiod_set_value_cansleep uart_rs485_config uart_add_one_port pl011_register_port pl011_probe Fixes: 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way") Suggested-by: Lino Sanfilippo Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v6.1+ Link: https://lore.kernel.org/r/f3a35967c28b32f3c6432d0aa5936e6a9908282d.1695307688.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit a20d0faed2f4ef388521f92b7b8b1dd4494b4d0f Author: Hans de Goede Date: Wed Sep 20 15:05:06 2023 +0200 ACPI: EC: Add quirk for the HP Pavilion Gaming 15-dk1xxx commit cd4aece493f99f95d41edcce32927d70a5dde923 upstream. Added GPE quirk entry for the HP Pavilion Gaming 15-dk1xxx. There is a quirk entry for 2 15-c..... laptops, this is for a new version which has 15-dk1xxx as identifier. This fixes the LID switch and rfkill and brightness hotkeys not working. Closes: https://github.com/systemd/systemd/issues/28942 Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 351a16dff55b1dfb04347a498d5328e5888c84df Author: Hans de Goede Date: Mon Oct 9 14:11:01 2023 +0200 ACPI: resource: Add TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q to irq1_edge_low_force_override[] commit f9b3ea02555e67e2e7bf95219953b88d122bd275 upstream. The TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q are 3 GPU variants of a TongFang barebone design which is sold under various brand names. The ACPI IRQ override for the keyboard IRQ must be used on these AMD Zen laptops in order for the IRQ to work. Adjust the pcspecialist_laptop[] DMI match table for this: 1. Drop the sys-vendor match from the existing PCSpecialist Elimina Pro 16 entry for the GM6BGEQ (RTX3050 GPU) model so that it will also match the laptop when sold by other vendors such as hyperbook.pl. 2. Add board-name matches for the GM6BG5Q (RTX4050) and GM6B0Q (RTX4060) models. Note the .ident values of the dmi_system_id structs are left unset since these are not used. Suggested-by: August Wikerfors Reported-by: Francesco Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217394 Link: https://laptopparts4less.frl/index.php?route=product/search&filter_name=GM6BG Link: https://hyperbook.pl/en/content/14-hyperbook-drivers Link: https://linux-hardware.org/?probe=bfa70344e3 Link: https://bbs.archlinuxcn.org/viewtopic.php?id=13313 Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e7a8ce872214a6abe184ea99811097306fd3d6e5 Author: Hans de Goede Date: Tue Sep 12 12:08:27 2023 +0200 ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA commit c1ed72171ed580fbf159e703b77685aa4b0d0df5 upstream. Like various other ASUS ExpertBook-s, the ASUS ExpertBook B1402CBA has an ACPI DSDT table that describes IRQ 1 as ActiveLow while the kernel overrides it to EdgeHigh. This prevents the keyboard from working. To fix this issue, add this laptop to the skip_override_table so that the kernel does not override IRQ 1. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217901 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 1474b39f961703d0bb33833a6d6b112826839781 Author: Zack Rusin Date: Thu Sep 28 00:13:55 2023 -0400 drm/vmwgfx: Keep a gem reference to user bos in surfaces commit 91398b413d03660fd5828f7b4abc64e884b98069 upstream. Surfaces can be backed (i.e. stored in) memory objects (mob's) which are created and managed by the userspace as GEM buffers. Surfaces grab only a ttm reference which means that the gem object can be deleted underneath us, especially in cases where prime buffer export is used. Make sure that all userspace surfaces which are backed by gem objects hold a gem reference to make sure they're not deleted before vmw surfaces are done with them, which fixes: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 2632 at lib/refcount.c:28 refcount_warn_saturate+0xfb/0x150 Modules linked in: overlay vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock snd_ens1371 snd_ac97_codec ac97_bus snd_pcm gameport> CPU: 2 PID: 2632 Comm: vmw_ref_count Not tainted 6.5.0-rc2-vmwgfx #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:refcount_warn_saturate+0xfb/0x150 Code: eb 9e 0f b6 1d 8b 5b a6 01 80 fb 01 0f 87 ba e4 80 00 83 e3 01 75 89 48 c7 c7 c0 3c f9 a3 c6 05 6f 5b a6 01 01 e8 15 81 98 ff <0f> 0b e9 6f ff ff ff 0f b> RSP: 0018:ffffbdc34344bba0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027 RDX: ffff960475ea1548 RSI: 0000000000000001 RDI: ffff960475ea1540 RBP: ffffbdc34344bba8 R08: 0000000000000003 R09: 65646e75203a745f R10: ffffffffa5b32b20 R11: 72657466612d6573 R12: ffff96037d6a6400 R13: ffff9603484805b0 R14: 000000000000000b R15: ffff9603bed06060 FS: 00007f5fd8520c40(0000) GS:ffff960475e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5fda755000 CR3: 000000010d012005 CR4: 00000000003706e0 Call Trace: ? show_regs+0x6e/0x80 ? refcount_warn_saturate+0xfb/0x150 ? __warn+0x91/0x150 ? refcount_warn_saturate+0xfb/0x150 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xfb/0x150 drm_gem_object_handle_put_unlocked+0xba/0x110 [drm] drm_gem_object_release_handle+0x6e/0x80 [drm] drm_gem_handle_delete+0x6a/0xc0 [drm] ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx] vmw_bo_unref_ioctl+0x33/0x40 [vmwgfx] drm_ioctl_kernel+0xbc/0x160 [drm] drm_ioctl+0x2d2/0x580 [drm] ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx] ? do_vmi_munmap+0xee/0x180 vmw_generic_ioctl+0xbd/0x180 [vmwgfx] vmw_unlocked_ioctl+0x19/0x20 [vmwgfx] __x64_sys_ioctl+0x99/0xd0 do_syscall_64+0x5d/0x90 ? syscall_exit_to_user_mode+0x2a/0x50 ? do_syscall_64+0x6d/0x90 ? handle_mm_fault+0x16e/0x2f0 ? exit_to_user_mode_prepare+0x34/0x170 ? irqentry_exit_to_user_mode+0xd/0x20 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x8e/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f5fda51aaff Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 7> RSP: 002b:00007ffd536a4d30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd536a4de0 RCX: 00007f5fda51aaff RDX: 00007ffd536a4de0 RSI: 0000000040086442 RDI: 0000000000000003 RBP: 0000000040086442 R08: 000055fa603ada50 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffd536a51b8 R13: 0000000000000003 R14: 000055fa5ebb4c80 R15: 00007f5fda90f040 ---[ end trace 0000000000000000 ]--- A lot of the analyis on the bug was done by Murray McAllister and Ian Forbes. Reported-by: Murray McAllister Cc: Ian Forbes Signed-off-by: Zack Rusin Fixes: a950b989ea29 ("drm/vmwgfx: Do not drop the reference to the handle too soon") Cc: # v6.2+ Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20230928041355.737635-1-zack@kde.org Signed-off-by: Greg Kroah-Hartman commit 65059dc00a79efb3cbc5b89689cc86ffb9ad7e87 Author: Daniel Miess Date: Fri Sep 29 13:04:33 2023 -0400 drm/amd/display: Don't set dpms_off for seamless boot commit 23645bca98304a2772f0de96f97370dd567d0ae6 upstream. [Why] eDPs fail to light up with seamless boot enabled [How] When seamless boot is enabled don't configure dpms_off in disable_vbios_mode_if_required. Reviewed-by: Charlene Liu Cc: Mario Limonciello Cc: Alex Deucher Cc: stable@vger.kernel.org Acked-by: Tom Chung Signed-off-by: Daniel Miess Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit ea7596e54ba9edc0f1574c8f5f81ff23360d643b Author: Christian König Date: Fri Oct 6 14:04:04 2023 +0200 drm/amdgpu: add missing NULL check commit ff89f064dca38e2203790bf876cc7756b8ab2961 upstream. bo->tbo.resource can easily be NULL here. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2902 Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d8bb7861a764b31d3f990324f92da7f4a6c0729a Author: Simon Ser Date: Thu Oct 5 13:16:32 2023 +0000 drm/atomic-helper: relax unregistered connector check commit 2b7947bd32e243c52870d54141d3b4ea6775e63d upstream. The driver might pull connectors which weren't submitted by user-space into the atomic state. For instance, intel_dp_mst_atomic_master_trans_check() pulls in connectors sharing the same DP-MST stream. However, if the connector is unregistered, this later fails with: [ 559.425658] i915 0000:00:02.0: [drm:drm_atomic_helper_check_modeset] [CONNECTOR:378:DP-7] is not registered Skip the unregistered connector check to allow user-space to turn off connectors one-by-one. See this wlroots issue: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3407 Previous discussion: https://lore.kernel.org/intel-gfx/Y6GX7z17WmDSKwta@ideak-desk.fi.intel.com/ Signed-off-by: Simon Ser Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä Reviewed-by: Lyude Paul Cc: Jani Nikula Cc: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20231005131623.114379-1-contact@emersion.fr Signed-off-by: Greg Kroah-Hartman commit 7e34cec74ee1ddab991580ee21ebbcfcc558c736 Author: Joey Gouly Date: Tue Oct 10 18:46:52 2023 +0100 drm/tiny: correctly print `struct resource *` on error commit c1165df2be2fffe3adeeaa68f4ee4325108c5e4e upstream. The `res` variable is already a `struct resource *`, don't take the address of it. Fixes incorrect output: simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not acquire memory range [??? 0xffff4be88a387d00-0xfffffefffde0a240 flags 0x0]: -16 To be correct: simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not acquire memory range [mem 0x9e20dc000-0x9e307bfff flags 0x200]: -16 Signed-off-by: Joey Gouly Fixes: 9a10c7e6519b ("drm/simpledrm: Add support for system memory framebuffers") Cc: Thomas Zimmermann Cc: Thierry Reding Cc: Javier Martinez Canillas Cc: dri-devel@lists.freedesktop.org Cc: # v6.3+ Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20231010174652.2439513-1-joey.gouly@arm.com Signed-off-by: Greg Kroah-Hartman commit 8abd2793db0fbba17097ce717e93eb1881b7567a Author: Matthew Wilcox (Oracle) Date: Thu Oct 5 14:56:47 2023 +0100 drm: Do not overrun array in drm_gem_get_pages() commit b7fd68ab1538e3adb665670414bea440f399fda9 upstream. If the shared memory object is larger than the DRM object that it backs, we can overrun the page array. Limit the number of pages we install from each folio to prevent this. Signed-off-by: "Matthew Wilcox (Oracle)" Reported-by: Oleksandr Natalenko Tested-by: Oleksandr Natalenko Link: https://lore.kernel.org/lkml/13360591.uLZWGnKmhe@natalenko.name/ Fixes: 3291e09a4638 ("drm: convert drm_gem_put_pages() to use a folio_batch") Cc: stable@vger.kernel.org # 6.5.x Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20231005135648.2317298-1-willy@infradead.org Signed-off-by: Greg Kroah-Hartman commit 5ecce079d8ef9345f4801ee1355060c0c042c2b0 Author: Macpaul Lin Date: Tue Oct 3 13:13:45 2023 +0200 arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regions commit 6cd2a30b96a4b2d270bc1ef1611429dc3fa63327 upstream. The dts file of the MediaTek MT8195 demo board has been updated to include new reserved memory regions. These reserved memory regions are: - SCP - VPU, - Sound DMA - APU. These regions are defined with the "shared-dma-pool" compatible property. In addition, the existing reserved memory regions have been reordered by their addresses to improve readability and maintainability of the DTS file. Cc: stable@vger.kernel.org # 6.1, 6.4, 6.5 Fixes: e4a417520101 ("arm64: dts: mediatek: mt8195-demo: fix the memory size of node secmon") Signed-off-by: Macpaul Lin Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20230905034511.11232-2-macpaul.lin@mediatek.com Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-3-dad7cd62a8ff@collabora.com Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit b2b2706b149d1b02c85cb5373793c1ad5f8ac23c Author: Macpaul Lin Date: Tue Oct 3 13:13:44 2023 +0200 arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB commit 25389c03c21c9587dd21c768d1cbfa514a3ca211 upstream. The onboard dram of mt8195-demo board is 8GB. Cc: stable@vger.kernel.org # 6.1, 6.4, 6.5 Fixes: 6147314aeedc ("arm64: dts: mediatek: Add device-tree for MT8195 Demo board") Signed-off-by: Macpaul Lin Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20230905034511.11232-1-macpaul.lin@mediatek.com Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-2-dad7cd62a8ff@collabora.com Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit a4442f43569cb57642e2d5ecba64e5e58ffc42dd Author: Hans de Goede Date: Tue Oct 10 12:24:58 2023 +0200 media: subdev: Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled commit 4800021c630210ea0b19434a1fb56ab16385f2b3 upstream. Since the stream API is still experimental it is currently locked away behind the internal, default disabled, v4l2_subdev_enable_streams_api flag. Advertising V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled confuses userspace. E.g. it causes the following libcamera error: ERROR SimplePipeline simple.cpp:1497 Failed to reset routes for /dev/v4l-subdev1: Inappropriate ioctl for device Don't report V4L2_SUBDEV_CAP_STREAMS when the streams API is disabled to avoid problems like this. Reported-by: Dennis Bonke Fixes: 9a6b5bf4c1bb ("media: add V4L2_SUBDEV_CAP_STREAMS") Cc: stable@vger.kernel.org # for >= 6.3 Signed-off-by: Hans de Goede Acked-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit bcf670d1f6b39174c4caf5b6927106bdefed045f Author: Antoniu Miclaus Date: Tue Sep 12 11:54:21 2023 +0300 iio: addac: Kconfig: update ad74413r selections commit b120dd3a15582fb7a959cecb05e4d9814fcba386 upstream. Building ad74413r without selecting IIO_BUFFER and IIO_TRIGGERED_BUFFER generates error with respect to the iio trigger functions that are used within the driver. Update the Kconfig accordingly. Fixes: fea251b6a5db ("iio: addac: add AD74413R driver") Signed-off-by: Antoniu Miclaus Link: https://lore.kernel.org/r/20230912085421.51102-1-antoniu.miclaus@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5ad7badddf527ed110c56fd880edab761a2f5a70 Author: Alisa-Dariana Roman Date: Sun Sep 24 18:21:48 2023 +0300 iio: adc: ad7192: Correct reference voltage commit 7e7dcab620cd6d34939f615cac63fc0ef7e81c72 upstream. The avdd and the reference voltage are two different sources but the reference voltage was assigned according to the avdd supply. Add vref regulator structure and set the reference voltage according to the vref supply from the devicetree. In case vref supply is missing, reference voltage is set according to the avdd supply for compatibility with old devicetrees. Fixes: b581f748cce0 ("staging: iio: adc: ad7192: move out of staging") Signed-off-by: Alisa-Dariana Roman Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230924152149.41884-1-alisadariana@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 96e1752330df38eb1bde2fca1d80279a6f3ff69e Author: Alexander Zangerl Date: Wed Sep 20 10:01:10 2023 +1000 iio: pressure: ms5611: ms5611_prom_is_valid false negative bug 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 commit a934a1a2b5acb145045c2e2bb99587effe302716 Author: Lakshmi Yadlapati Date: Tue Aug 29 13:02:22 2023 -0500 iio: pressure: dps310: Adjust Timeout Settings 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 commit 727115b7c668be1d9db6eb8a72c729b563d0d779 Author: Antoniu Miclaus Date: Mon Aug 7 17:38:05 2023 +0300 iio: admv1013: add mixer_vgate corner cases commit 287d998af24326b009ae0956820a3188501b34a0 upstream. Include the corner cases in the computation of the MIXER_VGATE register value. According to the datasheet: The MIXER_VGATE values follows the VCM such as, that for a 0V to 1.8V VCM, MIXER_VGATE = 23.89 VCM + 81, and for a > 1.8V to 2.6V VCM, MIXER_VGATE = 23.75 VCM + 1.25. Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013") Signed-off-by: Antoniu Miclaus Reviewed-by: Nuno Sa Link: https://lore.kernel.org/r/20230807143806.6954-1-antoniu.miclaus@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 197f50f9699dedf193aaa2326802cc18a2457891 Author: Marcelo Schmitt Date: Thu Aug 3 16:56:23 2023 -0300 iio: dac: ad3552r: Correct device IDs commit 9a85653ed3b9a9b7b31d95a34b64b990c3d33ca1 upstream. Device IDs for AD3542R and AD3552R were swapped leading to unintended collection of DAC output ranges being used for each design. Change device ID values so they are correct for each DAC chip. Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support") Signed-off-by: Marcelo Schmitt Reported-by: Chandrakant Minajigi Link: https://lore.kernel.org/r/011f480220799fbfabdd53896f8a2f251ad995ad.1691091324.git.marcelo.schmitt1@gmail.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7488449fce1b2982987b634ae6b50cccce1df6fb Author: Philipp Rossak Date: Tue Sep 5 00:02:04 2023 +0200 iio: adc: imx8qxp: Fix address for command buffer registers commit 850101b3598277794f92a9e363a60a66e0d42890 upstream. The ADC Command Buffer Register high and low are currently pointing to the wrong address and makes it impossible to perform correct ADC measurements over all channels. According to the datasheet of the imx8qxp the ADC_CMDL register starts at address 0x100 and the ADC_CMDH register starts at address 0x104. This bug seems to be in the kernel since the introduction of this driver. This can be observed by checking all raw voltages of the adc and they are all nearly identical: cat /sys/bus/iio/devices/iio\:device0/in_voltage*_raw 3498 3494 3491 3491 3489 3490 3490 3490 Fixes: 1e23dcaa1a9fa ("iio: imx8qxp-adc: Add driver support for NXP IMX8QXP ADC") Signed-off-by: Philipp Rossak Acked-by: Haibo Chen Link: https://lore.kernel.org/r/20230904220204.23841-1-embed3d@gmail.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 83342393005076d58410d30c8b4d56fd512afb31 Author: Tzung-Bi Shih Date: Tue Aug 29 11:06:22 2023 +0800 iio: cros_ec: fix an use-after-free in cros_ec_sensors_push_data() commit 7771c8c80d62ad065637ef74ed2962983f6c5f6d upstream. cros_ec_sensors_push_data() reads `indio_dev->active_scan_mask` and calls iio_push_to_buffers_with_timestamp() without making sure the `indio_dev` stays in buffer mode. There is a race if `indio_dev` exits buffer mode right before cros_ec_sensors_push_data() accesses them. An use-after-free on `indio_dev->active_scan_mask` was observed. The call trace: [...] _find_next_bit cros_ec_sensors_push_data cros_ec_sensorhub_event blocking_notifier_call_chain cros_ec_irq_thread It was caused by a race condition: one thread just freed `active_scan_mask` at [1]; while another thread tried to access the memory at [2]. Fix it by calling iio_device_claim_buffer_mode() to ensure the `indio_dev` can't exit buffer mode during cros_ec_sensors_push_data(). [1]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/industrialio-buffer.c#L1189 [2]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c#L198 Cc: stable@vger.kernel.org Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO") Signed-off-by: Tzung-Bi Shih Reviewed-by: Guenter Roeck Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20230829030622.1571852-1-tzungbi@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8a80ebbdc4902012229dcf62b828b671ef3728bd Author: Jonathan Cameron Date: Sun Sep 3 12:30:52 2023 +0100 iio: imu: bno055: Fix missing Kconfig dependencies commit c9b9cfe7d342683f624a89c3b617be18aff879e8 upstream. This driver uses IIO triggered buffers so it needs to select them in Kconfig. on riscv-32bit: /opt/crosstool/gcc-13.2.0-nolibc/riscv32-linux/bin/riscv32-linux-ld: drivers/iio/imu/bno055/bno055.o: in function `.L367': bno055.c:(.text+0x2c96): undefined reference to `devm_iio_triggered_buffer_setup_ext' Reported-by: Randy Dunlap Closes: https://lore.kernel.org/linux-next/40566b4b-3950-81fe-ff14-871d8c447627@infradead.org/ Fixes: 4aefe1c2bd0c ("iio: imu: add Bosch Sensortec BNO055 core driver") Cc: Andrea Merello Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://lore.kernel.org/r/20230903113052.846298-1-jic23@kernel.org Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a130c5dacfe4fadbd2d7098502883214a91d6971 Author: Phil Elwell Date: Fri Aug 11 16:58:29 2023 +0100 iio: pressure: bmp280: Fix NULL pointer exception 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 commit 4c7f9ce4e1edbec0666647d6d20fa5776468e97a Author: Xingxing Luo Date: Fri Sep 22 15:59:29 2023 +0800 usb: musb: Modify the "HWVers" register address 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 commit 9f13422e080b8a814f7d922ea745abd75389c63f Author: Xingxing Luo Date: Tue Sep 19 11:30:55 2023 +0800 usb: musb: Get the musb_qh poniter after musb_giveback 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 commit 136f69a04e71ba3458d137aec3bb2ce1232c0289 Author: Ricardo Cañuelo Date: Wed Aug 30 12:04:18 2023 +0200 usb: hub: Guard against accesses to uninitialized BOS descriptors commit f74a7afc224acd5e922c7a2e52244d891bbe44ee upstream. Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Signed-off-by: Ricardo Cañuelo Cc: stable Link: https://lore.kernel.org/r/20230830100418.1952143-1-ricardo.canuelo@collabora.com Signed-off-by: Greg Kroah-Hartman commit d33756339fe29056bf384ec2f528e9e191481027 Author: Xiaolei Wang Date: Tue Sep 26 15:53:33 2023 +0800 usb: cdns3: Modify the return value of cdns_set_active () to void when CONFIG_PM_SLEEP is disabled commit 9f35d612da5592f1bf1cae44ec1e023df37bea12 upstream. The return type of cdns_set_active () is inconsistent depending on whether CONFIG_PM_SLEEP is enabled, so the return value is modified to void type. Reported-by: Pavel Machek Closes: https://lore.kernel.org/all/ZP7lIKUzD68XA91j@duo.ucw.cz/ Fixes: 2319b9c87fe2 ("usb: cdns3: Put the cdns set active part outside the spin lock") Cc: stable@vger.kernel.org Signed-off-by: Xiaolei Wang Reviewed-by: Pavel Machek Reviewed-by: Roger Quadros Acked-by: Peter Chen Link: https://lore.kernel.org/r/20230926075333.1791011-1-xiaolei.wang@windriver.com Signed-off-by: Greg Kroah-Hartman commit c39cb50e1b8a6c6e3f75262540ac99cc74049acb Author: Thinh Nguyen Date: Wed Sep 13 00:52:15 2023 +0000 usb: dwc3: Soft reset phy on probe for host 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 commit 92d68868386d470ed4a1609ec4ed68b5643f7f33 Author: Javier Carrasco Date: Tue Oct 10 00:26:14 2023 +0200 net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read 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 commit 41d00825cbff0fcd01b100e9060c18bf046067ad Author: Lukas Wunner Date: Fri Sep 15 17:31:08 2023 +0300 xhci: Preserve RsvdP bits in ERSTBA register correctly commit cf97c5e0f7dda2edc15ecd96775fe6c355823784 upstream. xhci_add_interrupter() erroneously preserves only the lowest 4 bits when writing the ERSTBA register, not the lowest 6 bits. Fix it. Migrate the ERST_BASE_RSVDP macro to the modern GENMASK_ULL() syntax to avoid a u64 cast. This was previously fixed by commit 8c1cbec9db1a ("xhci: fix event ring segment table related masks and variables in header"), but immediately undone by commit b17a57f89f69 ("xhci: Refactor interrupter code for initial multi interrupter support."). Fixes: b17a57f89f69 ("xhci: Refactor interrupter code for initial multi interrupter support.") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v6.3+ Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20230915143108.1532163-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit c247dfde7e401cff134f32063d591a4487faa785 Author: Lukas Wunner Date: Fri Sep 15 17:31:07 2023 +0300 xhci: Clear EHB bit only at end of interrupt handler commit 15f3ef070933817fac2bcbdb9c85bff9e54e9f80 upstream. The Event Handler Busy bit shall be cleared by software when the Event Ring is empty. The xHC is thereby informed that it may raise another interrupt once it has enqueued new events (sec 4.17.2). However since commit dc0ffbea5729 ("usb: host: xhci: update event ring dequeue pointer on purpose"), the EHB bit is already cleared after half a segment has been processed. As a result, spurious interrupts may occur: - xhci_irq() processes half a segment, clears EHB, continues processing remaining events. - xHC enqueues new events. Because EHB has been cleared, xHC sets Interrupt Pending bit. Interrupt moderation countdown begins. - Meanwhile xhci_irq() continues processing events. Interrupt moderation countdown reaches zero, so an MSI interrupt is signaled. - xhci_irq() empties the Event Ring, clears EHB again and is done. - Because an MSI interrupt has been signaled, xhci_irq() is run again. It discovers there's nothing to do and returns IRQ_NONE. Avoid by clearing the EHB bit only at the end of xhci_irq(). Fixes: dc0ffbea5729 ("usb: host: xhci: update event ring dequeue pointer on purpose") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v5.5+ Cc: Peter Chen Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20230915143108.1532163-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit c4ea3c85a64a9de54a42e0a778b5e67cad95b1e2 Author: Mathias Nyman Date: Fri Sep 15 17:31:06 2023 +0300 xhci: track port suspend state correctly in unsuccessful resume cases commit d7cdfc319b2bcf6899ab0a05eec0958bc802a9a1 upstream. xhci-hub.c tracks suspended ports in a suspended_port bitfield. This is checked when responding to a Get_Status(PORT) request to see if a port in running U0 state was recently resumed, and adds the required USB_PORT_STAT_C_SUSPEND change bit in those cases. The suspended_port bit was left uncleared if a device is disconnected during suspend. The bit remained set even when a new device was connected and enumerated. The set bit resulted in a incorrect Get_Status(PORT) response with a bogus USB_PORT_STAT_C_SUSPEND change bit set once the new device reached U0 link state. USB_PORT_STAT_C_SUSPEND change bit is only used for USB2 ports, but xhci-hub keeps track of both USB2 and USB3 suspended ports. Cc: stable@vger.kernel.org Reported-by: Wesley Cheng Closes: https://lore.kernel.org/linux-usb/d68aa806-b26a-0e43-42fb-b8067325e967@quicinc.com/ Fixes: 1d5810b6923c ("xhci: Rework port suspend structures for limited ports.") Tested-by: Wesley Cheng Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20230915143108.1532163-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit acf5731ea0dee166ed04f5b7ef8765cf5c91df27 Author: Wesley Cheng Date: Fri Sep 15 17:31:05 2023 +0300 usb: xhci: xhci-ring: Use sysdev for mapping bounce buffer 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 commit 86b3ba53b81d05a6f4daf95c0617f1fbf4bbb82c Author: Amelie Delaunay Date: Wed Oct 4 18:35:30 2023 +0200 dmaengine: stm32-mdma: set in_flight_bytes in case CRQA flag is set commit 584970421725b7805db84714b857851fdf7203a9 upstream. CRQA flag is set by hardware when the channel request become active and the channel is enabled. It is cleared by hardware, when the channel request is completed. So when it is set, it means MDMA is transferring bytes. This information is useful in case of STM32 DMA and MDMA chaining, especially when the user pauses DMA before stopping it, to trig one last MDMA transfer to get the latest bytes of the SRAM buffer to the destination buffer. STM32 DCMI driver can then use this to know if the last MDMA transfer in case of chaining is done. Fixes: 696874322771 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA") Signed-off-by: Amelie Delaunay Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231004163531.2864160-3-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 70641b112b5bf889ec863bc81b05c9d84d0b43f5 Author: Amelie Delaunay Date: Wed Oct 4 18:35:29 2023 +0200 dmaengine: stm32-mdma: use Link Address Register to compute residue commit a4b306eb83579c07b63dc65cd5bae53b7b4019d0 upstream. Current implementation relies on curr_hwdesc index. But to keep this index up to date, Block Transfer interrupt (BTIE) has to be enabled. If it is not, curr_hwdesc is not updated, and then residue is not reliable. Rely on Link Address Register instead. And disable BTIE interrupt in stm32_mdma_setup_xfer() because it is no more needed in case of _prep_slave_sg() to maintain curr_hwdesc up to date. It avoids extra interrupts and also ensures a reliable residue. These improvements are required for STM32 DCMI camera capture use case, which need STM32 DMA and MDMA chaining for good performance. Fixes: 696874322771 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA") Signed-off-by: Amelie Delaunay Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231004163531.2864160-2-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 02544433d143a1de0f623c3fbab69b55cc4883f7 Author: Amelie Delaunay Date: Wed Oct 4 17:50:24 2023 +0200 dmaengine: stm32-dma: fix residue in case of MDMA chaining commit 67e13e89742c3b21ce177f612bf9ef32caae6047 upstream. In case of MDMA chaining, DMA is configured in Double-Buffer Mode (DBM) with two periods, but if transfer has been prepared with _prep_slave_sg(), the transfer is not marked cyclic (=!chan->desc->cyclic). However, as DBM is activated for MDMA chaining, residue computation must take into account cyclic constraints. With only two periods in MDMA chaining, and no update due to Transfer Complete interrupt masked, n_sg is always 0. If DMA current memory address (depending on SxCR.CT and SxM0AR/SxM1AR) does not correspond, it means n_sg should be increased. Then, the residue of the current period is the one read from SxNDTR and should not be overwritten with the full period length. Fixes: 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA") Signed-off-by: Amelie Delaunay Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231004155024.2609531-2-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit fa03b3920caafe562ab4dae3e33277637d1884ca Author: Amelie Delaunay Date: Wed Oct 4 17:50:23 2023 +0200 dmaengine: stm32-dma: fix stm32_dma_prep_slave_sg in case of MDMA chaining commit 2df467e908ce463cff1431ca1b00f650f7a514b4 upstream. Current Target (CT) have to be reset when starting an MDMA chaining use case, as Double Buffer mode is activated. It ensures the DMA will start processing the first memory target (pointed with SxM0AR). Fixes: 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA") Signed-off-by: Amelie Delaunay Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231004155024.2609531-1-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit f862dcfa849fe02d06a13c8278c89b43a0810bf9 Author: Amelie Delaunay Date: Wed Oct 4 18:35:28 2023 +0200 dmaengine: stm32-mdma: abort resume if no ongoing transfer 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 commit 56f16bda27aabc5be062e80d20fe78c2417f392a Author: Amir Goldstein Date: Sat Oct 14 22:30:04 2023 +0300 ovl: temporarily disable appending lowedirs commit beae836e9c61ee039e367a94b14f7fea08f0ad4c upstream. Kernel v6.5 converted overlayfs to new mount api. As an added bonus, it also added a feature to allow appending lowerdirs using lowerdir=:/lower2,lowerdir=::/data3 syntax. This new syntax has raised some concerns regarding escaping of colons. We decided to try and disable this syntax, which hasn't been in the wild for so long and introduce it again in 6.7 using explicit mount options lowerdir+=/lower2,datadir+=/data3. Suggested-by: Miklos Szeredi Link: https://lore.kernel.org/r/CAJfpegsr3A4YgF2YBevWa6n3=AcP7hNndG6EPMu3ncvV-AM71A@mail.gmail.com/ Fixes: b36a5780cb44 ("ovl: modify layer parameter parsing") Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 8eaa7650056d48538a8e8cdeb7e580815b6a17cb Author: Andy Chiu Date: Tue Aug 22 16:49:03 2023 +0000 riscv: signal: fix sigaltstack frame size checking commit 14a270bfab7ab1c4b605c01eeca5557447ad5a2b upstream. The alternative stack checking in get_sigframe introduced by the Vector support is not needed and has a problem. It is not needed as we have already validate it at the beginning of the function if we are already on an altstack. If not, the size of an altstack is always validated at its allocation stage with sigaltstack_size_valid(). Besides, we must only regard the size of an altstack if the handler of a signal is registered with SA_ONSTACK. So, blindly checking overflow of an altstack if sas_ss_size not equals to zero will check against wrong signal handlers if only a subset of signals are registered with SA_ONSTACK. Fixes: 8ee0b41898fa ("riscv: signal: Add sigcontext save/restore for vector") Reported-by: Prashanth Swaminathan Signed-off-by: Andy Chiu Link: https://lore.kernel.org/r/20230822164904.21660-1-andy.chiu@sifive.com Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit c24f3b78692ded30031ced36c47501d3dd515703 Author: Waiman Long Date: Tue Oct 10 22:48:42 2023 -0400 workqueue: Override implicit ordered attribute in workqueue_apply_unbound_cpumask() [ Upstream commit ca10d851b9ad0338c19e8e3089e24d565ebfffd7 ] Commit 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered") enabled implicit ordered attribute to be added to WQ_UNBOUND workqueues with max_active of 1. This prevented the changing of attributes to these workqueues leading to fix commit 0a94efb5acbb ("workqueue: implicit ordered attribute should be overridable"). However, workqueue_apply_unbound_cpumask() was not updated at that time. So sysfs changes to wq_unbound_cpumask has no effect on WQ_UNBOUND workqueues with implicit ordered attribute. Since not all WQ_UNBOUND workqueues are visible on sysfs, we are not able to make all the necessary cpumask changes even if we iterates all the workqueue cpumasks in sysfs and changing them one by one. Fix this problem by applying the corresponding change made to apply_workqueue_attrs_locked() in the fix commit to workqueue_apply_unbound_cpumask(). Fixes: 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 63ca6c516fe6d5c0d589cab87a199a06d852d40c Author: Yoshihiro Shimoda Date: Tue Oct 10 21:48:58 2023 +0900 rswitch: Fix imbalance phy_power_off() calling [ Upstream commit 053f13f67be6d02781730c9ac71abde6e9140610 ] The phy_power_off() should not be called if phy_power_on() failed. So, add a condition .power_count before calls phy_power_off(). Fixes: 5cb630925b49 ("net: renesas: rswitch: Add phy_power_{on,off}() calling") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8911d3485cec9d90c1cf0451f425f085d63e6595 Author: Yoshihiro Shimoda Date: Tue Oct 10 21:48:57 2023 +0900 rswitch: Fix renesas_eth_sw_remove() implementation [ Upstream commit 510b18cf23b9bd8a982ef7f1fb19f3968a2bf787 ] Fix functions calling order and a condition in renesas_eth_sw_remove(). Otherwise, kernel NULL pointer dereference happens from phy_stop() if a net device opens. Fixes: 3590918b5d07 ("net: ethernet: renesas: Add support for "Ethernet Switch"") Signed-off-by: Yoshihiro Shimoda Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7164d177bd165f92c13de91807c3e6b8a6dbb21c Author: Ratheesh Kannoth Date: Tue Oct 10 09:18:42 2023 +0530 octeontx2-pf: Fix page pool frag allocation warning [ Upstream commit 50e492143374c17ad89c865a1a44837b3f5c8226 ] Since page pool param's "order" is set to 0, will result in below warn message if interface is configured with higher rx buffer size. Steps to reproduce the issue. 1. devlink dev param set pci/0002:04:00.0 name receive_buffer_size \ value 8196 cmode runtime 2. ifconfig eth0 up [ 19.901356] ------------[ cut here ]------------ [ 19.901361] WARNING: CPU: 11 PID: 12331 at net/core/page_pool.c:567 page_pool_alloc_frag+0x3c/0x230 [ 19.901449] pstate: 82401009 (Nzcv daif +PAN -UAO +TCO -DIT +SSBS BTYPE=--) [ 19.901451] pc : page_pool_alloc_frag+0x3c/0x230 [ 19.901453] lr : __otx2_alloc_rbuf+0x60/0xbc [rvu_nicpf] [ 19.901460] sp : ffff80000f66b970 [ 19.901461] x29: ffff80000f66b970 x28: 0000000000000000 x27: 0000000000000000 [ 19.901464] x26: ffff800000d15b68 x25: ffff000195b5c080 x24: ffff0002a5a32dc0 [ 19.901467] x23: ffff0001063c0878 x22: 0000000000000100 x21: 0000000000000000 [ 19.901469] x20: 0000000000000000 x19: ffff00016f781000 x18: 0000000000000000 [ 19.901472] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 19.901474] x14: 0000000000000000 x13: ffff0005ffdc9c80 x12: 0000000000000000 [ 19.901477] x11: ffff800009119a38 x10: 4c6ef2e3ba300519 x9 : ffff800000d13844 [ 19.901479] x8 : ffff0002a5a33cc8 x7 : 0000000000000030 x6 : 0000000000000030 [ 19.901482] x5 : 0000000000000005 x4 : 0000000000000000 x3 : 0000000000000a20 [ 19.901484] x2 : 0000000000001080 x1 : ffff80000f66b9d4 x0 : 0000000000001000 [ 19.901487] Call trace: [ 19.901488] page_pool_alloc_frag+0x3c/0x230 [ 19.901490] __otx2_alloc_rbuf+0x60/0xbc [rvu_nicpf] [ 19.901494] otx2_rq_aura_pool_init+0x1c4/0x240 [rvu_nicpf] [ 19.901498] otx2_open+0x228/0xa70 [rvu_nicpf] [ 19.901501] otx2vf_open+0x20/0xd0 [rvu_nicvf] [ 19.901504] __dev_open+0x114/0x1d0 [ 19.901507] __dev_change_flags+0x194/0x210 [ 19.901510] dev_change_flags+0x2c/0x70 [ 19.901512] devinet_ioctl+0x3a4/0x6c4 [ 19.901515] inet_ioctl+0x228/0x240 [ 19.901518] sock_ioctl+0x2ac/0x480 [ 19.901522] __arm64_sys_ioctl+0x564/0xe50 [ 19.901525] invoke_syscall.constprop.0+0x58/0xf0 [ 19.901529] do_el0_svc+0x58/0x150 [ 19.901531] el0_svc+0x30/0x140 [ 19.901533] el0t_64_sync_handler+0xe8/0x114 [ 19.901535] el0t_64_sync+0x1a0/0x1a4 [ 19.901537] ---[ end trace 678c0bf660ad8116 ]--- Fixes: b2e3406a38f0 ("octeontx2-pf: Add support for page pool") Signed-off-by: Ratheesh Kannoth Reviewed-by: Yunsheng Lin Link: https://lore.kernel.org/r/20231010034842.3807816-1-rkannoth@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6584eba7688dcf999542778b07f63828c21521da Author: Jeremy Cline Date: Mon Oct 9 16:00:54 2023 -0400 nfc: nci: assert requested protocol is valid [ Upstream commit 354a6e707e29cb0c007176ee5b8db8be7bd2dee0 ] The protocol is used in a bit mask to determine if the protocol is supported. Assert the provided protocol is less than the maximum defined so it doesn't potentially perform a shift-out-of-bounds and provide a clearer error for undefined protocols vs unsupported ones. Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Reported-and-tested-by: syzbot+0839b78e119aae1fec78@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0839b78e119aae1fec78 Signed-off-by: Jeremy Cline Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20231009200054.82557-1-jeremy@jcline.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 843e69515b049bf1827125018e674e23c51bd500 Author: Kuniyuki Iwashima Date: Mon Oct 9 08:31:52 2023 -0700 af_packet: Fix fortified memcpy() without flex array. [ Upstream commit e2bca4870fdaf855651ee80b083d892599c5d982 ] Sergei Trofimovich reported a regression [0] caused by commit a0ade8404c3b ("af_packet: Fix warning of fortified memcpy() in packet_getname()."). It introduced a flex array sll_addr_flex in struct sockaddr_ll as a union-ed member with sll_addr to work around the fortified memcpy() check. However, a userspace program uses a struct that has struct sockaddr_ll in the middle, where a flex array is illegal to exist. include/linux/if_packet.h:24:17: error: flexible array member 'sockaddr_ll::::::sll_addr_flex' not at end of 'struct packet_info_t' 24 | __DECLARE_FLEX_ARRAY(unsigned char, sll_addr_flex); | ^~~~~~~~~~~~~~~~~~~~ To fix the regression, let's go back to the first attempt [1] telling memcpy() the actual size of the array. Reported-by: Sergei Trofimovich Closes: https://github.com/NixOS/nixpkgs/pull/252587#issuecomment-1741733002 [0] Link: https://lore.kernel.org/netdev/20230720004410.87588-3-kuniyu@amazon.com/ [1] Fixes: a0ade8404c3b ("af_packet: Fix warning of fortified memcpy() in packet_getname().") Signed-off-by: Kuniyuki Iwashima Link: https://lore.kernel.org/r/20231009153151.75688-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 84a6f89acb77c59b8f471ba2a6262cb71d71f0c9 Author: Ralph Siemsen Date: Wed Oct 4 16:00:08 2023 -0400 pinctrl: renesas: rzn1: Enable missing PINMUX [ Upstream commit f055ff23c331f28aa4ace4b72dc56f63b9a726c8 ] Enable pin muxing (eg. programmable function), so that the RZ/N1 GPIO pins will be configured as specified by the pinmux in the DTS. This used to be enabled implicitly via CONFIG_GENERIC_PINMUX_FUNCTIONS, however that was removed, since the RZ/N1 driver does not call any of the generic pinmux functions. Fixes: 1308fb4e4eae14e6 ("pinctrl: rzn1: Do not select GENERIC_PIN{CTRL_GROUPS,MUX_FUNCTIONS}") Signed-off-by: Ralph Siemsen Reviewed-by: Miquel Raynal Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20231004200008.1306798-1-ralph.siemsen@linaro.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit e8dc72cb8312c1175a832b2e69239a23e8f7d570 Author: Jakub Kicinski Date: Tue Oct 10 10:36:51 2023 -0700 net: tcp: fix crashes trying to free half-baked MTU probes [ Upstream commit 71c299c711d1f44f0bf04f1fea66baad565240f1 ] tcp_stream_alloc_skb() initializes the skb to use tcp_tsorted_anchor which is a union with the destructor. We need to clean that TCP-iness up before freeing. Fixes: 736013292e3c ("tcp: let tcp_mtu_probe() build headless packets") Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20231010173651.3990234-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 806f8e051903a28993990089d2dcdbc0482b39e4 Author: Nils Hoppmann Date: Mon Oct 9 16:40:48 2023 +0200 net/smc: Fix pos miscalculation in statistics [ Upstream commit a950a5921db450c74212327f69950ff03419483a ] SMC_STAT_PAYLOAD_SUB(_smc_stats, _tech, key, _len, _rc) will calculate wrong bucket positions for payloads of exactly 4096 bytes and (1 << (m + 12)) bytes, with m == SMC_BUF_MAX - 1. Intended bucket distribution: Assume l == size of payload, m == SMC_BUF_MAX - 1. Bucket 0 : 0 < l <= 2^13 Bucket n, 1 <= n <= m-1 : 2^(n+12) < l <= 2^(n+13) Bucket m : l > 2^(m+12) Current solution: _pos = fls64((l) >> 13) [...] _pos = (_pos < m) ? ((l == 1 << (_pos + 12)) ? _pos - 1 : _pos) : m For l == 4096, _pos == -1, but should be _pos == 0. For l == (1 << (m + 12)), _pos == m, but should be _pos == m - 1. In order to avoid special treatment of these corner cases, the calculation is adjusted. The new solution first subtracts the length by one, and then calculates the correct bucket by shifting accordingly, i.e. _pos = fls64((l - 1) >> 13), l > 0. This not only fixes the issues named above, but also makes the whole bucket assignment easier to follow. Same is done for SMC_STAT_RMB_SIZE_SUB(_smc_stats, _tech, k, _len), where the calculation of the bucket position is similar to the one named above. Fixes: e0e4b8fa5338 ("net/smc: Add SMC statistics support") Suggested-by: Halil Pasic Signed-off-by: Nils Hoppmann Reviewed-by: Halil Pasic Reviewed-by: Wenjia Zhang Reviewed-by: Dust Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d1af8a39cf839d93c8967fdd858f6bbdc3e4a15c Author: Eric Dumazet Date: Mon Oct 9 12:31:10 2023 +0000 net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn() [ Upstream commit 31c07dffafce914c1d1543c135382a11ff058d93 ] Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF. Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock. nfc_llcp_sock_get_sn() has a similar problem. Finally nfc_llcp_recv_snl() needs to make sure the socket found by nfc_llcp_sock_from_sn() does not disappear. Fixes: 8f50020ed9b8 ("NFC: LLCP late binding") Reported-by: Sili Luo Signed-off-by: Eric Dumazet Cc: Willy Tarreau Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20231009123110.3735515-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cf5b41a81fee2f40863cfd42bc043551785741eb Author: Ilya Leoshkevich Date: Tue Oct 10 22:20:10 2023 +0200 s390/bpf: Fix unwinding past the trampoline [ Upstream commit 5356ba1ff4f2417e1aebcf99aab35c1ea94dd6d7 ] When functions called by the trampoline panic, the backtrace that is printed stops at the trampoline, because the trampoline does not store its caller's frame address (backchain) on stack; it also stores the return address at a wrong location. Store both the same way as is already done for the regular eBPF programs. Fixes: 528eb2cb87bc ("s390/bpf: Implement arch_prepare_bpf_trampoline()") Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20231010203512.385819-3-iii@linux.ibm.com Signed-off-by: Sasha Levin commit beb59c1a329691f399f854f20533cba29c5efc92 Author: Ilya Leoshkevich Date: Tue Oct 10 22:20:09 2023 +0200 s390/bpf: Fix clobbering the caller's backchain in the trampoline [ Upstream commit ce10fc0604bc6a0d626ed8e5d69088057edc71ab ] One of the first things that s390x kernel functions do is storing the the caller's frame address (backchain) on stack. This makes unwinding possible. The backchain is always stored at frame offset 152, which is inside the 160-byte stack area, that the functions allocate for their callees. The callees must preserve the backchain; the remaining 152 bytes they may use as they please. Currently the trampoline uses all 160 bytes, clobbering the backchain. This causes kernel panics when using __builtin_return_address() in functions called by the trampoline. Fix by reducing the usage of the caller-reserved stack area by 8 bytes in the trampoline. Fixes: 528eb2cb87bc ("s390/bpf: Implement arch_prepare_bpf_trampoline()") Reported-by: Song Liu Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20231010203512.385819-2-iii@linux.ibm.com Signed-off-by: Sasha Levin commit 96217b5df8ae3aeeb3e466d707dc22c3a22fd162 Author: Will Mortensen Date: Thu Oct 5 22:37:06 2023 -0700 net/mlx5e: Again mutually exclude RX-FCS and RX-port-timestamp [ Upstream commit da6192ca72d5ad913d109d43dc896290ad05d98f ] Commit 1e66220948df8 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change") seems to have accidentally inverted the logic added in commit 0bc73ad46a76 ("net/mlx5e: Mutually exclude RX-FCS and RX-port-timestamp"). The impact of this is a little unclear since it seems the FCS scattered with RX-FCS is (usually?) correct regardless. Fixes: 1e66220948df8 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change") Tested-by: Charlotte Tan Reviewed-by: Charlotte Tan Cc: Adham Faris Cc: Aya Levin Cc: Tariq Toukan Cc: Moshe Shemesh Cc: Saeed Mahameed Signed-off-by: Will Mortensen Reviewed-by: Tariq Toukan Link: https://lore.kernel.org/r/20231006053706.514618-1-will@extrahop.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 915a812423ed7698097bd800c074025f6af1fa71 Author: Gerd Bayer Date: Fri Oct 6 14:58:47 2023 +0200 net/smc: Fix dependency of SMC on ISM [ Upstream commit a72178cfe855c283224f393d94a1332b90d1483e ] When the SMC protocol is built into the kernel proper while ISM is configured to be built as module, linking the kernel fails due to unresolved dependencies out of net/smc/smc_ism.o to ism_get_smcd_ops, ism_register_client, and ism_unregister_client as reported via the linux-next test automation (see link). This however is a bug introduced a while ago. Correct the dependency list in ISM's and SMC's Kconfig to reflect the dependencies that are actually inverted. With this you cannot build a kernel with CONFIG_SMC=y and CONFIG_ISM=m. Either ISM needs to be 'y', too - or a 'n'. That way, SMC can still be configured on non-s390 architectures that do not have (nor need) an ISM driver. Fixes: 89e7d2ba61b7 ("net/ism: Add new API for client registration") Reported-by: Randy Dunlap Closes: https://lore.kernel.org/linux-next/d53b5b50-d894-4df8-8969-fd39e63440ae@infradead.org/ Co-developed-by: Wenjia Zhang Signed-off-by: Wenjia Zhang Signed-off-by: Gerd Bayer Reviewed-by: Simon Horman Tested-by: Simon Horman # build-tested Acked-by: Randy Dunlap Tested-by: Randy Dunlap # build-tested Link: https://lore.kernel.org/r/20231006125847.1517840-1-gbayer@linux.ibm.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9c22611716b186b51bc62d4d2a399ac576ca3018 Author: Dan Carpenter Date: Fri Oct 6 15:53:09 2023 +0300 ixgbe: fix crash with empty VF macvlan list [ Upstream commit 7b5add9af567c44e12196107f0fe106e194034fd ] The adapter->vf_mvs.l list needs to be initialized even if the list is empty. Otherwise it will lead to crashes. Fixes: a1cbb15c1397 ("ixgbe: Add macvlan support for VF") Signed-off-by: Dan Carpenter Reviewed-by: Simon Horman Reviewed-by: Jesse Brandeburg Link: https://lore.kernel.org/r/ZSADNdIw8zFx1xw2@kadam Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 78004df64a7615400a0b68c4dd4fb1210d4cb9f8 Author: Ruihai Zhou Date: Sat Oct 7 14:49:49 2023 +0800 drm/panel: boe-tv101wum-nl6: Completely pull GPW to VGL before TP term [ Upstream commit 258dd5e6e65995ee85a941eed9a06708a36b1bfe ] The sta_himax83102 panel sometimes shows abnormally flickering horizontal lines. The front gate output will precharge the X point of the next pole circuit before TP(TouchPanel Enable) term starts, and wait until the end of the TP term to resume the CLK. For this reason, the X point must be maintained during the TP term. In abnormal case, we measured a slight leakage at point X. This because during the TP term, the GPW does not fully pull the VGL low, causing the TFT to not be closed tightly. To fix this, we completely pull GPW to VGL before entering the TP term. This will ensure that the TFT is closed tightly and prevent the abnormal display. Fixes: 1bc2ef065f13 ("drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel") Signed-off-by: Ruihai Zhou Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20231007064949.22668-1-zhouruihai@huaqin.corp-partner.google.com Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20231007064949.22668-1-zhouruihai@huaqin.corp-partner.google.com Signed-off-by: Sasha Levin commit 946b595277a7be1995a17f8cc6f0f2987be21ecd Author: Radu Pirea (NXP OSS) Date: Thu Oct 5 21:06:36 2023 +0300 net/mlx5e: macsec: use update_pn flag instead of PN comparation [ Upstream commit fde2f2d7f23d39f2fc699ba6d91ac3f4a2e637ca ] When updating the SA, use the new update_pn flags instead of comparing the new PN with the initial one. Comparing the initial PN value with the new value will allow the user to update the SA using the initial PN value as a parameter like this: $ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \ ead3664f508eb06c40ac7104cdae4ce5 $ ip macsec set macsec0 tx sa 0 pn 1 off Fixes: 8ff0ac5be144 ("net/mlx5: Add MACsec offload Tx command support") Fixes: aae3454e4d4c ("net/mlx5e: Add MACsec offload Rx command support") Signed-off-by: Radu Pirea (NXP OSS) Reviewed-by: Sabrina Dubroca Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5bf8bd49315ac1d57cb4a3dc639bd53fd12f4025 Author: Radu Pirea (NXP OSS) Date: Thu Oct 5 21:06:35 2023 +0300 net: phy: mscc: macsec: reject PN update requests [ Upstream commit e0a8c918daa58700609ebd45e3fcd49965be8bbc ] Updating the PN is not supported. Return -EINVAL if update_pn is true. The following command succeeded, but it should fail because the driver does not update the PN: ip macsec set macsec0 tx sa 0 pn 232 on Fixes: 28c5107aa904 ("net: phy: mscc: macsec support") Signed-off-by: Radu Pirea (NXP OSS) Reviewed-by: Sabrina Dubroca Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f74aa471ee761b20232a1909b54e9c2124a0ac5a Author: Radu Pirea (NXP OSS) Date: Thu Oct 5 21:06:33 2023 +0300 net: macsec: indicate next pn update when offloading [ Upstream commit 0412cc846a1ef38697c3f321f9b174da91ecd3b5 ] Indicate next PN update using update_pn flag in macsec_context. Offloaded MACsec implementations does not know whether or not the MACSEC_SA_ATTR_PN attribute was passed for an SA update and assume that next PN should always updated, but this is not always true. The PN can be reset to its initial value using the following command: $ ip macsec set macsec0 tx sa 0 off #octeontx2-pf case Or, the update PN command will succeed even if the driver does not support PN updates. $ ip macsec set macsec0 tx sa 0 pn 1 on #mscc phy driver case Comparing the initial PN with the new PN value is not a solution. When the user updates the PN using its initial value the command will succeed, even if the driver does not support it. Like this: $ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \ ead3664f508eb06c40ac7104cdae4ce5 $ ip macsec set macsec0 tx sa 0 pn 1 on #mlx5 case Signed-off-by: Radu Pirea (NXP OSS) Reviewed-by: Sabrina Dubroca Signed-off-by: Paolo Abeni Stable-dep-of: e0a8c918daa5 ("net: phy: mscc: macsec: reject PN update requests") Signed-off-by: Sasha Levin commit e0a9630ad1d5acaea0f16eb4b62d843e081f08da Author: Radu Pirea (NXP OSS) Date: Thu Oct 5 21:06:34 2023 +0300 octeontx2-pf: mcs: update PN only when update_pn is true [ Upstream commit 4dcf38ae3ca16b8872f151d46ba5ac28dd580b60 ] When updating SA, update the PN only when the update_pn flag is true. Otherwise, the PN will be reset to its previous value using the following command and this should not happen: $ ip macsec set macsec0 tx sa 0 on Fixes: c54ffc73601c ("octeontx2-pf: mcs: Introduce MACSEC hardware offloading") Signed-off-by: Radu Pirea (NXP OSS) Reviewed-by: Sabrina Dubroca Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 90baaf9ced76d70aa0e435d71ec2957fc950dce2 Author: Eric Dumazet Date: Fri Oct 6 17:33:54 2023 +0000 net: refine debug info in skb_checksum_help() [ Upstream commit 26c29961b142444cd99361644c30fa1e9b3da6be ] syzbot uses panic_on_warn. This means that the skb_dump() I added in the blamed commit are not even called. Rewrite this so that we get the needed skb dump before syzbot crashes. Fixes: eeee4b77dc52 ("net: add more debug info in skb_checksum_help()") Signed-off-by: Eric Dumazet Reported-by: Willem de Bruijn Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/r/20231006173355.2254983-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7067ebaf98a2c13aa4fbb48d769dcb147094cc27 Author: David Vernet Date: Mon Oct 9 11:14:13 2023 -0500 bpf: Fix verifier log for async callback return values [ Upstream commit 829955981c557c7fc7416581c4cd68a8a0c28620 ] The verifier, as part of check_return_code(), verifies that async callbacks such as from e.g. timers, will return 0. It does this by correctly checking that R0->var_off is in tnum_const(0), which effectively checks that it's in a range of 0. If this condition fails, however, it prints an error message which says that the value should have been in (0x0; 0x1). This results in possibly confusing output such as the following in which an async callback returns 1: At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x1) The fix is easy -- we should just pass the tnum_const(0) as the correct range to verbose_invalid_scalar(), which will then print the following: At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x0) Fixes: bfc6bb74e4f1 ("bpf: Implement verifier support for validation of async callbacks.") Signed-off-by: David Vernet Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20231009161414.235829-1-void@manifault.com Signed-off-by: Sasha Levin commit 67394149d7c444bdc4771fa4567ffbd769a0cfe3 Author: Konstantin Meskhidze Date: Tue Sep 5 18:02:03 2023 +0800 drm/vmwgfx: fix typo of sizeof argument [ Upstream commit 39465cac283702a7d4a507a558db81898029c6d3 ] Since size of 'header' pointer and '*header' structure is equal on 64-bit machines issue probably didn't cause any wrong behavior. But anyway, fixing typo is required. Fixes: 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.") Co-developed-by: Ivanov Mikhail Signed-off-by: Konstantin Meskhidze Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20230905100203.1716731-1-konstantin.meskhidze@huawei.com Signed-off-by: Sasha Levin commit 50c28a3bfe6e1abcb20fdb5f80b11fa4ac576048 Author: Andrew Kanner Date: Sat Oct 7 10:51:49 2023 +0300 xdp: Fix zero-size allocation warning in xskq_create() [ Upstream commit a12bbb3cccf03b12847de0f7a6772127f90936ac ] Syzkaller reported the following issue: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2807 at mm/vmalloc.c:3247 __vmalloc_node_range (mm/vmalloc.c:3361) Modules linked in: CPU: 0 PID: 2807 Comm: repro Not tainted 6.6.0-rc2+ #12 Hardware name: Generic DT based system unwind_backtrace from show_stack (arch/arm/kernel/traps.c:258) show_stack from dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) dump_stack_lvl from __warn (kernel/panic.c:633 kernel/panic.c:680) __warn from warn_slowpath_fmt (./include/linux/context_tracking.h:153 kernel/panic.c:700) warn_slowpath_fmt from __vmalloc_node_range (mm/vmalloc.c:3361 (discriminator 3)) __vmalloc_node_range from vmalloc_user (mm/vmalloc.c:3478) vmalloc_user from xskq_create (net/xdp/xsk_queue.c:40) xskq_create from xsk_setsockopt (net/xdp/xsk.c:953 net/xdp/xsk.c:1286) xsk_setsockopt from __sys_setsockopt (net/socket.c:2308) __sys_setsockopt from ret_fast_syscall (arch/arm/kernel/entry-common.S:68) xskq_get_ring_size() uses struct_size() macro to safely calculate the size of struct xsk_queue and q->nentries of desc members. But the syzkaller repro was able to set q->nentries with the value initially taken from copy_from_sockptr() high enough to return SIZE_MAX by struct_size(). The next PAGE_ALIGN(size) is such case will overflow the size_t value and set it to 0. This will trigger WARN_ON_ONCE in vmalloc_user() -> __vmalloc_node_range(). The issue is reproducible on 32-bit arm kernel. Fixes: 9f78bf330a66 ("xsk: support use vaddr as ring") Reported-by: syzbot+fae676d3cf469331fc89@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000c84b4705fb31741e@google.com/T/ Reported-by: syzbot+b132693e925cbbd89e26@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000e20df20606ebab4f@google.com/T/ Signed-off-by: Andrew Kanner Signed-off-by: Daniel Borkmann Tested-by: syzbot+fae676d3cf469331fc89@syzkaller.appspotmail.com Acked-by: Magnus Karlsson Link: https://syzkaller.appspot.com/bug?extid=fae676d3cf469331fc89 Link: https://lore.kernel.org/bpf/20231007075148.1759-1-andrew.kanner@gmail.com Signed-off-by: Sasha Levin commit 5b01f4c71a03c5c9b39f8c08bfac7277eff9746d Author: Björn Töpel Date: Wed Oct 4 14:07:06 2023 +0200 riscv, bpf: Track both a0 (RISC-V ABI) and a5 (BPF) return values [ Upstream commit 7112cd26e606c7ba51f9cc5c1905f06039f6f379 ] The RISC-V BPF uses a5 for BPF return values, which are zero-extended, whereas the RISC-V ABI uses a0 which is sign-extended. In other words, a5 and a0 can differ, and are used in different context. The BPF trampoline are used for both BPF programs, and regular kernel functions. Make sure that the RISC-V BPF trampoline saves, and restores both a0 and a5. Fixes: 49b5e77ae3e2 ("riscv, bpf: Add bpf trampoline support for RV64") Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20231004120706.52848-3-bjorn@kernel.org Signed-off-by: Sasha Levin commit 7f6ef07f8ab5d2a1c98382cbd78d1ada70758c03 Author: Björn Töpel Date: Wed Oct 4 14:07:05 2023 +0200 riscv, bpf: Sign-extend return values [ Upstream commit 2f1b0d3d733169eb11680bfa97c266ae5e757148 ] The RISC-V architecture does not expose sub-registers, and hold all 32-bit values in a sign-extended format [1] [2]: | The compiler and calling convention maintain an invariant that all | 32-bit values are held in a sign-extended format in 64-bit | registers. Even 32-bit unsigned integers extend bit 31 into bits | 63 through 32. Consequently, conversion between unsigned and | signed 32-bit integers is a no-op, as is conversion from a signed | 32-bit integer to a signed 64-bit integer. While BPF, on the other hand, exposes sub-registers, and use zero-extension (similar to arm64/x86). This has led to some subtle bugs, where a BPF JITted program has not sign-extended the a0 register (return value in RISC-V land), passed the return value up the kernel, e.g.: | int from_bpf(void); | | long foo(void) | { | return from_bpf(); | } Here, a0 would be 0xffff_ffff, instead of the expected 0xffff_ffff_ffff_ffff. Internally, the RISC-V JIT uses a5 as a dedicated register for BPF return values. Keep a5 zero-extended, but explicitly sign-extend a0 (which is used outside BPF land). Now that a0 (RISC-V ABI) and a5 (BPF ABI) differs, a0 is only moved to a5 for non-BPF native calls (BPF_PSEUDO_CALL). Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf # [2] Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/draft-20230929-e5c800e661a53efe3c2678d71a306323b60eb13b/riscv-abi.pdf # [2] Link: https://lore.kernel.org/bpf/20231004120706.52848-2-bjorn@kernel.org Signed-off-by: Sasha Levin commit 82d52f300e48afab5749cc278bc445119f6fe76c Author: Roger Pau Monne Date: Thu Oct 5 16:08:31 2023 +0200 xen-netback: use default TX queue size for vifs [ Upstream commit 66cf7435a26917c0c4d6245ad9137e7606e84fdf ] Do not set netback interfaces (vifs) default TX queue size to the ring size. The TX queue size is not related to the ring size, and using the ring size (32) as the queue size can lead to packet drops. Note the TX side of the vif interface in the netback domain is the one receiving packets to be injected to the guest. Do not explicitly set the TX queue length to any value when creating the interface, and instead use the system default. Note that the queue length can also be adjusted at runtime. Fixes: f942dc2552b8 ('xen network backend driver') Signed-off-by: Roger Pau Monné Reviewed-by: Ross Lagerwall Acked-by: Wei Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a0cde56933f2d4c163f4cbdb571eba26a44dec68 Author: Dan Carpenter Date: Thu Oct 5 17:00:12 2023 +0300 mlxsw: fix mlxsw_sp2_nve_vxlan_learning_set() return type [ Upstream commit 1e0b72a2a6432c0ef67ee5ce8d9172a7c20bba25 ] The mlxsw_sp2_nve_vxlan_learning_set() function is supposed to return zero on success or negative error codes. So it needs to be type int instead of bool. Fixes: 4ee70efab68d ("mlxsw: spectrum_nve: Add support for VXLAN on Spectrum-2") Signed-off-by: Dan Carpenter Reviewed-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit becf5c147198f4345243c5df0c4f035415491640 Author: Dinghao Liu Date: Sat Oct 7 11:30:49 2023 +0800 ieee802154: ca8210: Fix a potential UAF in ca8210_probe [ Upstream commit f990874b1c98fe8e57ee9385669f501822979258 ] If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister(). Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock(). Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Signed-off-by: Dinghao Liu Message-ID: <20231007033049.22353-1-dinghao.liu@zju.edu.cn> Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 105abd68ad8f781985113aee2e92e0702b133705 Author: Yoshihiro Shimoda Date: Thu Oct 5 10:12:01 2023 +0900 ravb: Fix use-after-free issue in ravb_tx_timeout_work() [ Upstream commit 3971442870713de527684398416970cf025b4f89 ] The ravb_stop() should call cancel_work_sync(). Otherwise, ravb_tx_timeout_work() is possible to use the freed priv after ravb_remove() was called like below: CPU0 CPU1 ravb_tx_timeout() ravb_remove() unregister_netdev() free_netdev(ndev) // free priv ravb_tx_timeout_work() // use priv unregister_netdev() will call .ndo_stop() so that ravb_stop() is called. And, after phy_stop() is called, netif_carrier_off() is also called. So that .ndo_tx_timeout() will not be called after phy_stop(). Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Reported-by: Zheng Wang Closes: https://lore.kernel.org/netdev/20230725030026.1664873-1-zyytlz.wz@163.com/ Signed-off-by: Yoshihiro Shimoda Reviewed-by: Sergey Shtylyov Link: https://lore.kernel.org/r/20231005011201.14368-3-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3b8f0ea74cfc2e6b5e9527b5119566fadf4643f Author: Yoshihiro Shimoda Date: Thu Oct 5 10:12:00 2023 +0900 ravb: Fix up dma_free_coherent() call in ravb_remove() [ Upstream commit e6864af61493113558c502b5cd0d754c19b93277 ] In ravb_remove(), dma_free_coherent() should be call after unregister_netdev(). Otherwise, this controller is possible to use the freed buffer. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Signed-off-by: Yoshihiro Shimoda Reviewed-by: Sergey Shtylyov Link: https://lore.kernel.org/r/20231005011201.14368-2-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f776656844b147575b93b82e0bd55cd9f11755fc Author: Moshe Shemesh Date: Thu Oct 5 15:50:16 2023 +0300 devlink: Hold devlink lock on health reporter dump get [ Upstream commit aba0e909dc20eceb1de985474af459f82e7b0b82 ] Devlink health dump get callback should take devlink lock as any other devlink callback. Otherwise, since devlink_mutex was removed, this callback is not protected from a race of the reporter being destroyed while handling the callback. Add devlink lock to the callback and to any call for devlink_health_do_dump(). This should be safe as non of the drivers dump callback implementation takes devlink lock. As devlink lock is added to any callback of dump, the reporter dump_lock is now redundant and can be removed. Fixes: d3efc2a6a6d8 ("net: devlink: remove devlink_mutex") Signed-off-by: Moshe Shemesh Reviewed-by: Jiri Pirko Reviewed-by: Przemek Kitszel Link: https://lore.kernel.org/r/1696510216-189379-1-git-send-email-moshe@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6dd5b1a37a73b9edb0818917c05bd5775a9df665 Author: Nícolas F. R. A. Prado Date: Tue Oct 3 13:13:47 2023 +0200 arm64: dts: mediatek: mt8195: Set DSU PMU status to fail [ Upstream commit d192615c307ec9f74cd0582880ece698533eb99b ] The DSU PMU allows monitoring performance events in the DSU cluster, which is done by configuring and reading back values from the DSU PMU system registers. However, for write-access to be allowed by ELs lower than EL3, the EL3 firmware needs to update the setting on the ACTLR3_EL3 register, as it is disallowed by default. That configuration is not done on the firmware used by the MT8195 SoC, as a consequence, booting a MT8195-based machine like mt8195-cherry-tomato-r2 with CONFIG_ARM_DSU_PMU enabled hangs the kernel just as it writes to the CLUSTERPMOVSCLR_EL1 register, since the instruction faults to EL3, and BL31 apparently just re-runs the instruction over and over. Mark the DSU PMU node in the Devicetree with status "fail", as the machine doesn't have a suitable firmware to make use of it from the kernel, and allowing its driver to probe would hang the kernel. Fixes: 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20230720200753.322133-1-nfraprado@collabora.com Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-5-dad7cd62a8ff@collabora.com Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 340e23477773c82342acb0345c7873e099da176c Author: Eugen Hristev Date: Tue Oct 3 13:13:46 2023 +0200 arm64: dts: mediatek: fix t-phy unit name [ Upstream commit 963c3b0c47ec29b4c49c9f45965cd066f419d17f ] dtbs_check throws a warning at t-phy nodes: Warning (unit_address_vs_reg): /t-phy@1a243000: node has a unit name, but no reg or ranges property Warning (unit_address_vs_reg): /soc/t-phy@11c00000: node has a unit name, but no reg or ranges property The ranges is empty thus removing the `@1a243000`, `@11c00000` from the node name. Fixes: 6029cae696c8 ("arm64: dts: mediatek: mt7622: harmonize node names and compatibles") Fixes: 918aed7abd2d ("arm64: dts: mt7986: add pcie related device nodes") Signed-off-by: Eugen Hristev Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20230814093931.9298-2-eugen.hristev@collabora.com Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-4-dad7cd62a8ff@collabora.com Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 2463f7061ce6972f662c22a0183dc5ed6b878ef3 Author: John Watts Date: Wed Sep 6 09:13:43 2023 +1000 can: sun4i_can: Only show Kconfig if ARCH_SUNXI is set [ Upstream commit 1f223208ebdef84f21c15e9958c005a93c871aa2 ] When adding the RISCV option I didn't gate it behind ARCH_SUNXI. As a result this option shows up with Allwinner support isn't enabled. Fix that by requiring ARCH_SUNXI to be set if RISCV is set. Fixes: 8abb95250ae6 ("can: sun4i_can: Add support for the Allwinner D1") Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/linux-sunxi/CAMuHMdV2m54UAH0X2dG7stEg=grFihrdsz4+o7=_DpBMhjTbkw@mail.gmail.com/ Signed-off-by: John Watts Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/all/20230905231342.2042759-2-contact@jookia.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit ed545e8ccc85c9b1fbdb5a4acd9498401a3acfcd Author: Lukas Magel Date: Sun Aug 27 09:22:05 2023 +0000 can: isotp: isotp_sendmsg(): fix TX state detection and wait behavior [ Upstream commit d9c2ba65e651467de739324d978b04ed8729f483 ] With patch [1], isotp_poll was updated to also queue the poller in the so->wait queue, which is used for send state changes. Since the queue now also contains polling tasks that are not interested in sending, the queue fill state can no longer be used as an indication of send readiness. As a consequence, nonblocking writes can lead to a race and lock-up of the socket if there is a second task polling the socket in parallel. With this patch, isotp_sendmsg does not consult wq_has_sleepers but instead tries to atomically set so->tx.state and waits on so->wait if it is unable to do so. This behavior is in alignment with isotp_poll, which also checks so->tx.state to determine send readiness. V2: - Revert direct exit to goto err_event_drop [1] https://lore.kernel.org/all/20230331125511.372783-1-michal.sojka@cvut.cz Reported-by: Maxime Jayat Closes: https://lore.kernel.org/linux-can/11328958-453f-447f-9af8-3b5824dfb041@munic.io/ Signed-off-by: Lukas Magel Reviewed-by: Oliver Hartkopp Fixes: 79e19fa79cb5 ("can: isotp: isotp_ops: fix poll() to not report false EPOLLOUT events") Link: https://github.com/pylessard/python-udsoncan/issues/178#issuecomment-1743786590 Link: https://lore.kernel.org/all/20230827092205.7908-1-lukas.magel@posteo.net Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 96c8f114105510c0f26706428fd113962811845e Author: Marek Behún Date: Wed Oct 4 11:19:04 2023 +0200 net: dsa: qca8k: fix potential MDIO bus conflict when accessing internal PHYs via management frames [ Upstream commit 526c8ee04bdbd4d8d19a583b1f3b06700229a815 ] Besides the QCA8337 switch the Turris 1.x device has on it's MDIO bus also Micron ethernet PHY (dedicated to the WAN port). We've been experiencing a strange behavior of the WAN ethernet interface, wherein the WAN PHY started timing out the MDIO accesses, for example when the interface was brought down and then back up. Bisecting led to commit 2cd548566384 ("net: dsa: qca8k: add support for phy read/write with mgmt Ethernet"), which added support to access the QCA8337 switch's internal PHYs via management ethernet frames. Connecting the MDIO bus pins onto an oscilloscope, I was able to see that the MDIO bus was active whenever a request to read/write an internal PHY register was done via an management ethernet frame. My theory is that when the switch core always communicates with the internal PHYs via the MDIO bus, even when externally we request the access via ethernet. This MDIO bus is the same one via which the switch and internal PHYs are accessible to the board, and the board may have other devices connected on this bus. An ASCII illustration may give more insight: +---------+ +----| | | | WAN PHY | | +--| | | | +---------+ | | | | +----------------------------------+ | | | QCA8337 | MDC | | | +-------+ | ------o-+--|--------o------------o--| | | MDIO | | | | | PHY 1 |-|--to RJ45 --------o--|---o----+---------o--+--| | | | | | | | +-------+ | | +-------------+ | o--| | | | | MDIO MDC | | | | PHY 2 |-|--to RJ45 eth1 | | | o--+--| | | -----------|-|port0 | | | +-------+ | | | | | o--| | | | | switch core | | | | PHY 3 |-|--to RJ45 | +-------------+ o--+--| | | | | | +-------+ | | | o--| ... | | +----------------------------------+ When we send a request to read an internal PHY register via an ethernet management frame via eth1, the switch core receives the ethernet frame on port 0 and then communicates with the internal PHY via MDIO. At this time, other potential devices, such as the WAN PHY on Turris 1.x, cannot use the MDIO bus, since it may cause a bus conflict. Fix this issue by locking the MDIO bus even when we are accessing the PHY registers via ethernet management frames. Fixes: 2cd548566384 ("net: dsa: qca8k: add support for phy read/write with mgmt Ethernet") Signed-off-by: Marek Behún Reviewed-by: Christian Marangi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9515695b6a9d74b523aa4b280cdc7d83e3cc0351 Author: Marek Behún Date: Wed Oct 4 11:19:03 2023 +0200 net: dsa: qca8k: fix regmap bulk read/write methods on big endian systems [ Upstream commit 5652d1741574eb89cc02576e50ee3e348bd6dd77 ] Commit c766e077d927 ("net: dsa: qca8k: convert to regmap read/write API") introduced bulk read/write methods to qca8k's regmap. The regmap bulk read/write methods get the register address in a buffer passed as a void pointer parameter (the same buffer contains also the read/written values). The register address occupies only as many bytes as it requires at the beginning of this buffer. For example if the .reg_bits member in regmap_config is 16 (as is the case for this driver), the register address occupies only the first 2 bytes in this buffer, so it can be cast to u16. But the original commit implementing these bulk read/write methods cast the buffer to u32: u32 reg = *(u32 *)reg_buf & U16_MAX; taking the first 4 bytes. This works on little endian systems where the first 2 bytes of the buffer correspond to the low 16-bits, but it obviously cannot work on big endian systems. Fix this by casting the beginning of the buffer to u16 as u32 reg = *(u16 *)reg_buf; Fixes: c766e077d927 ("net: dsa: qca8k: convert to regmap read/write API") Signed-off-by: Marek Behún Tested-by: Christian Marangi Reviewed-by: Christian Marangi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c2d7c79898b427d263c64a4841987eec131f2d4e Author: Vladimir Oltean Date: Wed Oct 4 14:17:08 2023 +0300 phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers [ Upstream commit 139ad1143151a07be93bf741d4ea7c89e59f89ce ] The protocol converter configuration registers PCC8, PCCC, PCCD (implemented by the driver), as well as others, control protocol converters from multiple lanes (each represented as a different struct phy). So, if there are simultaneous calls to phy_set_mode_ext() to lanes sharing the same PCC register (either for the "old" or for the "new" protocol), corruption of the values programmed to hardware is possible, because lynx_28g_rmw() has no locking. Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take the global spinlock from the phy_ops :: set_mode() implementation. There are no other callers which modify PCC registers. Fixes: 8f73b37cf3fb ("phy: add support for the Layerscape SerDes 28G") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1c68986b6950846168b1470fef794e8c64810561 Author: Vladimir Oltean Date: Wed Oct 4 14:17:07 2023 +0300 phy: lynx-28g: lock PHY while performing CDR lock workaround [ Upstream commit 0ac87fe54a171d18c5fb5345e3ee8d14e1b06f4b ] lynx_28g_cdr_lock_check() runs once per second in a workqueue to reset the lane receiver if the CDR has not locked onto bit transitions in the RX stream. But the PHY consumer may do stuff with the PHY simultaneously, and that isn't okay. Block concurrent generic PHY calls by holding the PHY mutex from this workqueue. Fixes: 8f73b37cf3fb ("phy: add support for the Layerscape SerDes 28G") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3dea2f73f1719d0be9cd2f9c6f39f5d4e234ab29 Author: Ioana Ciornei Date: Wed Oct 4 14:17:06 2023 +0300 phy: lynx-28g: cancel the CDR check work item on the remove path [ Upstream commit f200bab3756fe81493a1b280180dafa1d9ccdcf7 ] The blamed commit added the CDR check work item but didn't cancel it on the remove path. Fix this by adding a remove function which takes care of it. Fixes: 8f73b37cf3fb ("phy: add support for the Layerscape SerDes 28G") Signed-off-by: Ioana Ciornei Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ca98df1efda08783ad51338a36139cf9104c3612 Author: Abhinav Kumar Date: Mon Sep 11 15:16:26 2023 -0700 drm/msm/dpu: fail dpu_plane_atomic_check() based on mdp clk limits [ Upstream commit 10f20628c9b8e924b8046e63b36b2cea4d2c85e4 ] Currently, dpu_plane_atomic_check() does not check whether the plane can process the image without exceeding the per chipset limits for MDP clock. This leads to underflow issues because the SSPP is not able to complete the processing for the data rate of the display. Fail the dpu_plane_atomic_check() if the SSPP cannot process the image without exceeding the MDP clock limits. changes in v2: - use crtc_state's adjusted_mode instead of mode Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/556819/ Link: https://lore.kernel.org/r/20230911221627.9569-1-quic_abhinavk@quicinc.com Signed-off-by: Sasha Levin commit 91f31c14f299836635eb973e58aa8a5d41b1ac89 Author: Stephen Boyd Date: Fri Aug 25 16:01:08 2023 -0700 drm/msm/dp: Add newlines to debug printks [ Upstream commit eba8c99a0fc45da1c8d5b5f5bd1dc2e79229a767 ] These debug printks are missing newlines, causing drm debug logs to be hard to read. Add newlines so that the messages are on their own line. Cc: Kuogee Hsieh Cc: Vinod Polimera Signed-off-by: Stephen Boyd Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease of debugging") Fixes: cd779808cccd ("drm/msm/dp: Add basic PSR support for eDP") Reviewed-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/554533/ Link: https://lore.kernel.org/r/20230825230109.2264345-1-swboyd@chromium.org Signed-off-by: Abhinav Kumar Signed-off-by: Sasha Levin commit 4c90ae0ef321c9d2ce3b131c44a8de860404ce21 Author: Abhinav Kumar Date: Thu Sep 7 18:26:16 2023 -0700 drm/msm/dpu: change _dpu_plane_calc_bw() to use u64 to avoid overflow [ Upstream commit 95e681ca3b65e4ce3d2537b47672d787b7d30375 ] _dpu_plane_calc_bw() uses integer variables to calculate the bandwidth used during plane bandwidth calculations. However for high resolution displays this overflows easily and leads to below errors [dpu error]crtc83 failed performance check -7 Promote the intermediate variables to u64 to avoid overflow. changes in v2: - change to u64 where actually needed in the math Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display") Reviewed-by: Dmitry Baryshkov Reported-by: Nia Espera Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/32 Tested-by: Nia Espera Patchwork: https://patchwork.freedesktop.org/patch/556288/ Link: https://lore.kernel.org/r/20230908012616.20654-1-quic_abhinavk@quicinc.com Signed-off-by: Abhinav Kumar Signed-off-by: Sasha Levin commit 06b722ee314152f9c0da2f9ed03b2985d0229846 Author: Dan Carpenter Date: Fri Sep 15 15:59:40 2023 +0300 drm/msm/dsi: fix irq_of_parse_and_map() error checking [ Upstream commit 6a1d4c7976dd1ee7c9f80bc8e62801ec7b1f2f58 ] The irq_of_parse_and_map() function returns zero on error. It never returns negative error codes. Fix the check. Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support") Signed-off-by: Dan Carpenter Reviewed-by: Konrad Dybcio Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/557715/ Link: https://lore.kernel.org/r/4f3c5c98-04f7-43f7-900f-5d7482c83eef@moroto.mountain Signed-off-by: Abhinav Kumar Signed-off-by: Sasha Levin commit 66b54db0e8a43725c9eda42c555e8461d1988e6f Author: Abhinav Kumar Date: Fri Sep 15 13:44:25 2023 -0700 drm/msm/dsi: skip the wait for video mode done if not applicable [ Upstream commit ab483e3adcc178254eb1ce0fbdfbea65f86f1006 ] dsi_wait4video_done() API waits for the DSI video mode engine to become idle so that we can transmit the DCS commands in the beginning of BLLP. However, with the current sequence, the MDP timing engine is turned on after the panel's pre_enable() callback which can send out the DCS commands needed to power up the panel. During those cases, this API will always timeout and print out the error spam leading to long bootup times and log flooding. Fix this by checking if the DSI video engine was actually busy before waiting for it to become idle otherwise this is a redundant wait. changes in v2: - move the reg read below the video mode check - minor fixes in commit text Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/34 Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support") Signed-off-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/557853/ Link: https://lore.kernel.org/r/20230915204426.19011-1-quic_abhinavk@quicinc.com Signed-off-by: Sasha Levin commit b945326b569f4e0bd33415d2ef71198d5a38975a Author: Kuogee Hsieh Date: Tue Aug 8 15:19:50 2023 -0700 drm/msm/dp: do not reinitialize phy unless retry during link training [ Upstream commit 0c1a2e69bcb506f48ebf94bd199bab0b93f66da2 ] DP PHY re-initialization done using dp_ctrl_reinitialize_mainlink() will cause PLL unlocked initially and then PLL gets locked at the end of initialization. PLL_UNLOCKED interrupt will fire during this time if the interrupt mask is enabled. However currently DP driver link training implementation incorrectly re-initializes PHY unconditionally during link training as the PHY was already configured in dp_ctrl_enable_mainlink_clocks(). Fix this by re-initializing the PHY only if the previous link training failed. [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/30 Signed-off-by: Kuogee Hsieh Tested-by: Abhinav Kumar # sc7280 Reviewed-by: Abhinav Kumar Reviewed-by: Stephen Boyd Reviewed-by: Dmitry Baryshkov Tested-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/551847/ Link: https://lore.kernel.org/r/1691533190-19335-1-git-send-email-quic_khsieh@quicinc.com [quic_abhinavk@quicinc.com: added line break in commit text] Signed-off-by: Abhinav Kumar Signed-off-by: Sasha Levin commit 098c06b6903cccd89a2a4c8ff1936b95790c7455 Author: Hal Feng Date: Tue Sep 5 20:21:04 2023 +0800 pinctrl: starfive: jh7110: Fix failure to set irq after CONFIG_PM is enabled [ Upstream commit 8406d6b5916663b4edc604b3effbf4935b61c2da ] The issue was found when we enabled CONFIG_PM and tested edge events using libgpiod. > # gpiomon -r gpiochip0 55 > gpiomon: error waiting for events: Permission denied `gpiomon` will call irq_chip_pm_get() and then call pm_runtime_resume_and_get() if (IS_ENABLED(CONFIG_PM) && sfp->gc.irq.domain->pm_dev). pm_runtime_resume_and_get() will fail if the runtime pm of pinctrl device is disabled. As we expect the pinctrl driver can be always working and never suspend during runtime, unset sfp->gc.irq.domain->pm_dev to make sure pm_runtime_resume_and_get() won't be called when setting irq. Fixes: 447976ab62c5 ("pinctrl: starfive: Add StarFive JH7110 sys controller driver") Signed-off-by: Hal Feng Link: https://lore.kernel.org/r/20230905122105.117000-2-hal.feng@starfivetech.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c9d7cac0fd27c74dd368e80dc4b5d0f9f2e13cf8 Author: Mikhail Kobuk Date: Fri Aug 25 13:15:28 2023 +0300 pinctrl: nuvoton: wpcm450: fix out of bounds write [ Upstream commit 87d315a34133edcb29c4cadbf196ec6c30dfd47b ] Write into 'pctrl->gpio_bank' happens before the check for GPIO index validity, so out of bounds write may happen. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a1d1e0e3d80a ("pinctrl: nuvoton: Add driver for WPCM450") Signed-off-by: Mikhail Kobuk Reviewed-by: Alexey Khoroshilov Reviewed-by: Jonathan Neuschäfer Link: https://lore.kernel.org/r/20230825101532.6624-1-m.kobuk@ispras.ru Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 44ec7bd0bd83578b8bc481e7da18f26cbfff41ac Author: Kailang Yang Date: Thu Sep 21 15:20:41 2023 +0800 ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP [ Upstream commit d93eeca627db512a56145285dc94feac5b88a1d4 ] This is merge model ALC287_FIXUP_THINKPAD_I2S_SPK and ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI. Signed-off-by: Kailang Yang Fixes: f7b069cf0881 ("ALSA: hda/realtek: Fix generic fixup definition for cs35l41 amp") Link: https://lore.kernel.org/r/82a45234327c4c50b4988a27e9f64c37@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 4654dd54a0fa8b1691ad45f83bc5f711fb4f5222 Author: Kailang Yang Date: Wed Sep 6 16:50:41 2023 +0800 ALSA: hda/realtek - ALC287 I2S speaker platform support [ Upstream commit e43252db7e207a2e194e6a4883a43a31a776a968 ] 0x17 was only speaker pin, DAC assigned will be 0x03. Headphone assigned to 0x02. Playback via headphone will get EQ filter processing. So,it needs to swap DAC. Tested-by: Mark Pearson Signed-off-by: Kailang Yang Link: https://lore.kernel.org/r/4e4cfa1b3b4c46838aecafc6e8b6f876@realtek.com Signed-off-by: Takashi Iwai Stable-dep-of: d93eeca627db ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP") Signed-off-by: Sasha Levin commit 92e54a0648dd2667fdf10df019cd83082fd22f4e Author: Fabian Vogt Date: Thu Aug 24 20:39:48 2023 +0200 ALSA: hda/realtek: Add quirk for mute LEDs on HP ENVY x360 15-eu0xxx [ Upstream commit c99c26b16c1544534ebd6a5f27a034f3e44d2597 ] The LED for the mic mute button is controlled by GPIO2. The mute button LED is slightly more complex, it's controlled by two bits in coeff 0x0b. Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/2693091.mvXUDI8C0e@fabians-envy Signed-off-by: Takashi Iwai Stable-dep-of: d93eeca627db ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP") Signed-off-by: Sasha Levin commit b94e563ae542585c81bf49f3e86a5825fa42201a Author: SungHwan Jung Date: Wed Aug 23 20:40:51 2023 +0900 ALSA: hda/realtek: Add quirk for HP Victus 16-d1xxx to enable mute LED [ Upstream commit 93dc18e11b1ab2d485b69f91c973e6b83e47ebd0 ] This quirk enables mute LED on HP Victus 16-d1xxx (8A25) laptops, which use ALC245 codec. Signed-off-by: SungHwan Jung Link: https://lore.kernel.org/r/20230823114051.3921-1-onenowy@gmail.com Signed-off-by: Takashi Iwai Stable-dep-of: d93eeca627db ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP") Signed-off-by: Sasha Levin commit 8cdbfcefbb37bd8355081e0210662ec84445c3e1 Author: Balamurugan C Date: Tue Sep 19 17:11:35 2023 +0800 ASoC: Intel: soc-acpi: Add entry for sof_es8336 in MTL match table. commit 381ddcd5875e496f2eae06bb65853271b7150fee upstream. Adding support for ES83x6 codec in MTL match table. Signed-off-by: Balamurugan C Reviewed-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20230919091136.1922253-2-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a2511b24670a3dc0746ebff2692da77a15b834d3 Author: Pierre-Louis Bossart Date: Tue Sep 19 17:21:25 2023 +0800 ASoC: Intel: sof_sdw: add support for SKU 0B14 commit fb0b8d299781be8d46b3612aa96cef28da0d93f4 upstream. One more missing SKU in the list. Closes: https://github.com/thesofproject/linux/issues/4543 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Chao Song Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20230919092125.1922468-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3aa5bd4b8a2ead6f904e10505c82af274763ac39 Author: Shengjiu Wang Date: Tue Sep 19 17:42:13 2023 +0800 ASoC: fsl_sai: Don't disable bitclock for i.MX8MP commit 197c53c8ecb34f2cd5922f4bdcffa8f701a134eb upstream. On i.MX8MP, the BCE and TERE bit are binding with mclk enablement, if BCE and TERE are cleared the MCLK also be disabled on output pin, that cause the external codec (wm8960) in wrong state. Codec (wm8960) is using the mclk to generate PLL clock, if mclk is disabled before disabling PLL, the codec (wm8960) won't generate bclk and frameclk when sysclk switch to MCLK source in next test case. The test case: $aplay -r44100 test1.wav (PLL source) $aplay -r48000 test2.wav (MCLK source) aplay: pcm_write:2127: write error: Input/output error Fixes: 269f399dc19f ("ASoC: fsl_sai: Disable bit clock with transmitter") Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1695116533-23287-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0cee8c73ea35f09399489a0be08f507c6bafb361 Author: Balamurugan C Date: Tue Sep 19 17:11:36 2023 +0800 ASoC: Intel: soc-acpi: Add entry for HDMI_In capture support in MTL match table commit d1f67278d4b2de3bf544ea9bcd9f64d03584df87 upstream. Adding HDMI-In capture via I2S feature support in MTL platform. Signed-off-by: Balamurugan C Reviewed-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20230919091136.1922253-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 934c889a945bf6b90ffa97bb1ba8546728d4701f Author: Pierre-Louis Bossart Date: Tue Sep 19 16:36:06 2023 +0800 ASoC: Intel: soc-acpi: fix Dell SKU 0B34 commit b399f9706a1cbae42731cc420a46cfb9c3c6b10f upstream. The rule for the SoundWire tables is that the platforms with more devices need to be added first. We broke that rule with the Dell SKU 0B34, and caused the second amplifier for SKU 0AF3 to be ignored. The fix is simple, we need to move the single-amplifier entry after the two-amplifier one. Fixes: b62a1a839b48 ("ASoC: Intel: soc-acpi: add tables for Dell SKU 0B34") Closes: https://github.com/thesofproject/linux/issues/4559 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Chao Song Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20230919083606.1920202-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 838cf77c7449748e74f4e1649202ec9ff626bb0e Author: Kuninori Morimoto Date: Tue Sep 19 01:22:57 2023 +0000 ASoC: simple-card-utils: fixup simple_util_startup() error handling commit 69cf63b6560205a390a736b88d112374655adb28 upstream. It should use "goto" instead of "return" Fixes: 5ca2ab459817 ("ASoC: simple-card-utils: Add new system-clock-fixed flag") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/202309141205.ITZeDJxV-lkp@intel.com/ Closes: https://lore.kernel.org/all/202309151840.au9Aa2W4-lkp@intel.com/ Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87v8c76jnz.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ba1e7575a0bbb87a79982184e3dfd84726a72f74 Author: Vijendar Mukunda Date: Wed Sep 27 12:44:10 2023 +0530 ASoC: SOF: amd: fix for firmware reload failure after playback commit 7e1fe5d9e7eae67e218f878195d1d348d01f9af7 upstream. Setting ACP ACLK as clock source when ACP enters D0 state causing firmware load failure as mentioned in below scenario. - Load snd_sof_amd_rembrandt - Play or Record audio - Stop audio - Unload snd_sof_amd_rembrandt - Reload snd_sof_amd_rembrandt If acp_clkmux_sel register field is set, then clock source will be set to ACP ACLK when ACP enters D0 state. During stream stop, if there is no active stream is running then acp firmware will set the ACP ACLK value to zero. When driver is reloaded and clock source is selected as ACP ACLK, as ACP ACLK is programmed to zero, firmware loading will fail. For RMB platform, remove the clock mux selection field so that ACP will use internal clock source when ACP enters D0 state. Fixes: 41cb85bc4b52 ("ASoC: SOF: amd: Add support for Rembrandt plaform.") Reported-by: coolstar Closes: https://github.com/thesofproject/sof/issues/8137 Signed-off-by: Vijendar Mukunda Link: https://lore.kernel.org/r/20230927071412.2416250-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8380e411ab734edb277df55b1693d272cfbb0e13 Author: Kailang Yang Date: Fri Oct 6 14:47:37 2023 +0800 ALSA: hda/realtek: Change model for Intel RVP board commit ccbd88be057a38531f835e8a04948ebf80cb0c5d upstream. Intel RVP board (0x12cc) has Headset Mic issue for reboot. If system plugged headset when system reboot the headset Mic was gone. Fixes: 1a93f10c5b12 ("ALSA: hda/realtek: Add "Intel Reference board" and "NUC 13" SSID in the ALC256") Signed-off-by: Kailang Yang Link: https://lore.kernel.org/r/28112f54c0c6496f97ac845645bc0256@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9da0985b9f572b5aec639f67eeab88df86cae281 Author: Stefan Binding Date: Tue Oct 3 15:21:38 2023 +0100 ALSA: hda: cs35l41: Cleanup and fix double free in firmware request commit 5d542b850d40cb08a38ad4bb2a944dbf1b7b0683 upstream. There is an unlikely but possible double free when loading firmware, and a missing free calls if a firmware is successfully requested but the coefficient file request fails, leading to the fallback firmware request occurring without clearing the previously loaded firmware. Fixes: cd40dad2ca91 ("ALSA: hda: cs35l41: Ensure firmware/tuning pairs are always loaded") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202309291331.0JUUQnPT-lkp@intel.com/ Signed-off-by: Stefan Binding Link: https://lore.kernel.org/r/20231003142138.180108-1-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 235805a7a78898ba3906de680f5024a77f2f6ba7 Author: Christos Skevis Date: Fri Oct 6 17:53:30 2023 +0200 ALSA: usb-audio: Fix microphone sound on Nexigo webcam. commit 4a63e68a295187ae3c1cb3fa0c583c96a959714f upstream. I own an external usb Webcam, model NexiGo N930AF, which had low mic volume and inconsistent sound quality. Video works as expected. (snip) [ +0.047857] usb 5-1: new high-speed USB device number 2 using xhci_hcd [ +0.003406] usb 5-1: New USB device found, idVendor=1bcf, idProduct=2283, bcdDevice=12.17 [ +0.000007] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000004] usb 5-1: Product: NexiGo N930AF FHD Webcam [ +0.000003] usb 5-1: Manufacturer: SHENZHEN AONI ELECTRONIC CO., LTD [ +0.000004] usb 5-1: SerialNumber: 20201217011 [ +0.003900] usb 5-1: Found UVC 1.00 device NexiGo N930AF FHD Webcam (1bcf:2283) [ +0.025726] usb 5-1: 3:1: cannot get usb sound sample rate freq at ep 0x86 [ +0.071482] usb 5-1: 3:2: cannot get usb sound sample rate freq at ep 0x86 [ +0.004679] usb 5-1: 3:3: cannot get usb sound sample rate freq at ep 0x86 [ +0.051607] usb 5-1: Warning! Unlikely big volume range (=4096), cval->res is probably wrong. [ +0.000005] usb 5-1: [7] FU [Mic Capture Volume] ch = 1, val = 0/4096/1 Set up quirk cval->res to 16 for 256 levels, Set GET_SAMPLE_RATE quirk flag to stop trying to get the sample rate. Confirmed that happened anyway later due to the backoff mechanism, after 3 failures All audio stream on device interfaces share the same values, apart from wMaxPacketSize and tSamFreq : (snip) Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 8 bDelay 1 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 1 bSubframeSize 2 bBitResolution 16 bSamFreqType 1 Discrete tSamFreq[ 0] 44100 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x005c 1x 92 bytes bInterval 4 bRefresh 0 bSynchAddress 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0x0000 (snip) Based on the usb data about manufacturer, SPCA2281B3 is the most likely controller IC Manufacturer does not provide link for datasheet nor detailed specs. No way to confirm if the firmware supports any other way of getting the sample rate. Testing patch provides consistent good sound recording quality and volume range. (snip) [ +0.045764] usb 5-1: new high-speed USB device number 2 using xhci_hcd [ +0.106290] usb 5-1: New USB device found, idVendor=1bcf, idProduct=2283, bcdDevice=12.17 [ +0.000006] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000004] usb 5-1: Product: NexiGo N930AF FHD Webcam [ +0.000003] usb 5-1: Manufacturer: SHENZHEN AONI ELECTRONIC CO., LTD [ +0.000004] usb 5-1: SerialNumber: 20201217011 [ +0.043700] usb 5-1: set resolution quirk: cval->res = 16 [ +0.002585] usb 5-1: Found UVC 1.00 device NexiGo N930AF FHD Webcam (1bcf:2283) Signed-off-by: Christos Skevis Link: https://lore.kernel.org/r/20231006155330.399393-1-xristos.thes@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f64401dec39ce4d9ccbf3cff17dd03d03c3af7ac Author: WhaleChang Date: Fri Oct 6 12:48:49 2023 +0800 ALSA: usb-audio: Fix microphone sound on Opencomm2 Headset commit 6a83d6f3bb3c329a73e3483651fb77b78bac1878 upstream. When a Opencomm2 Headset is connected to a Bluetooth USB dongle, the audio playback functions properly, but the microphone does not work. In the dmesg logs, there are messages indicating that the init_pitch function fails when the capture process begins. The microphone only functions when the ep pitch control is not set. Toggling the pitch control off bypasses the init_piatch function and allows the microphone to work. Signed-off-by: WhaleChang Link: https://lore.kernel.org/r/20231006044852.4181022-1-whalechang@google.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8a8ca58b89d523b304cf789d590fb0468997d590 Author: Sumit Garg Date: Fri Oct 6 10:48:01 2023 +0530 KEYS: trusted: Remove redundant static calls usage commit 01bbafc63b65689cb179ca537971286bc27f3b74 upstream. Static calls invocations aren't well supported from module __init and __exit functions. Especially the static call from cleanup_trusted() led to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y. However, the usage of static call invocations for trusted_key_init() and trusted_key_exit() don't add any value from either a performance or security perspective. Hence switch to use indirect function calls instead. Note here that although it will fix the current crash report, ultimately the static call infrastructure should be fixed to either support its future usage from module __init and __exit functions or not. Reported-and-tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Signed-off-by: Sumit Garg Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b50b1d7e76aa21635f958c142a4ab6685097131d Author: Biju Das Date: Mon Sep 18 13:24:09 2023 +0100 irqchip: renesas-rzg2l: Fix logic to clear TINT interrupt source commit 9b8df572ba3f4e544366196820a719a40774433e upstream. The logic to clear the TINT interrupt source in rzg2l_irqc_irq_disable() is wrong as the mask is correct only for LSB on the TSSR register. This issue is found when testing with two TINT interrupt sources. So fix the logic for all TINTs by using the macro TSSEL_SHIFT() to multiply tssr_offset with 8. Fixes: 3fed09559cd8 ("irqchip: Add RZ/G2L IA55 Interrupt Controller driver") Signed-off-by: Biju Das Tested-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Reviewed-by: Claudiu Beznea Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20230918122411.237635-2-biju.das.jz@bp.renesas.com Signed-off-by: Greg Kroah-Hartman commit 380aa2dfb4191b866890df2d5223b38f6b711099 Author: Lad Prabhakar Date: Fri Jul 22 16:11:54 2022 +0100 dt-bindings: interrupt-controller: renesas,rzg2l-irqc: Update description for '#interrupt-cells' property commit cfa1f9db6d6088118ef311c0927c66072665b47e upstream. Update description for '#interrupt-cells' property to utilize the RZG2L_{NMI,IRQX} for the first cell defined in the include/dt-bindings/interrupt-controller/irqc-rzg2l.h file. Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Fixes: 96fed779d3d4cb3c ("dt-bindings: interrupt-controller: Add Renesas RZ/G2L Interrupt Controller") Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20220722151155.21100-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman commit 862e2b015bbddbd1b6b3075c487205d4dc4472f4 Author: Dmitry Baryshkov Date: Tue Sep 5 15:19:26 2023 +0200 arm64: dts: qcom: sm8150: extend the size of the PDC resource commit cf5716acbfc6190b3f97f4614affdf5991aed7b2 upstream. Follow the example of other platforms and extend the PDC resource region to 0x30000, so that the PDC driver can read the PDC_VERSION register. Fixes: 397ad94668c1 ("arm64: dts: qcom: sm8150: Add pdc interrupt controller node") Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20230905-topic-sm8x50-upstream-pdc-ver-v4-2-fc633c7df84b@linaro.org Signed-off-by: Greg Kroah-Hartman commit 2f89f1515e13cd0e9d54ad0fedab2a344594f232 Author: Jordan Rife Date: Thu Sep 21 18:46:42 2023 -0500 net: prevent address rewrite in kernel_bind() commit c889a99a21bf124c3db08d09df919f0eccc5ea4c upstream. Similar to the change in commit 0bdf399342c5("net: Avoid address overwrite in kernel_connect"), BPF hooks run on bind may rewrite the address passed to kernel_bind(). This change 1) Makes a copy of the bind address in kernel_bind() to insulate callers. 2) Replaces direct calls to sock->ops->bind() in net with kernel_bind() Link: https://lore.kernel.org/netdev/20230912013332.2048422-1-jrife@google.com/ Fixes: 4fbac77d2d09 ("bpf: Hooks for sys_bind") Cc: stable@vger.kernel.org Reviewed-by: Willem de Bruijn Signed-off-by: Jordan Rife Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bbbf096ea227607cbb348155eeda7af71af1a35b Author: Damien Le Moal Date: Sat Aug 26 09:43:39 2023 +0900 ata: libata-scsi: Disable scsi device manage_system_start_stop commit aa3998dbeb3abce63653b7f6d4542e7dcd022590 upstream. The introduction of a device link to create a consumer/supplier relationship between the scsi device of an ATA device and the ATA port of that ATA device fixes the ordering of system suspend and resume operations. For suspend, the scsi device is suspended first and the ata port after it. This is fine as this allows the synchronize cache and START STOP UNIT commands issued by the scsi disk driver to be executed before the ata port is disabled. For resume operations, the ata port is resumed first, followed by the scsi device. This allows having the request queue of the scsi device to be unfrozen after the ata port resume is scheduled in EH, thus avoiding to see new requests prematurely issued to the ATA device. Since libata sets manage_system_start_stop to 1, the scsi disk resume operation also results in issuing a START STOP UNIT command to the device being resumed so that the device exits standby power mode. However, restoring the ATA device to the active power mode must be synchronized with libata EH processing of the port resume operation to avoid either 1) seeing the start stop unit command being received too early when the port is not yet resumed and ready to accept commands, or after the port resume process issues commands such as IDENTIFY to revalidate the device. In this last case, the risk is that the device revalidation fails with timeout errors as the drive is still spun down. Commit 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume") disabled issuing the START STOP UNIT command to avoid issues with it. But this is incorrect as transitioning a device to the active power mode from the standby power mode set on suspend requires a media access command. The IDENTIFY, READ LOG and SET FEATURES commands executed in libata EH context triggered by the ata port resume operation may thus fail. Fix these synchronization issues is by handling a device power mode transitions for system suspend and resume directly in libata EH context, without relying on the scsi disk driver management triggered with the manage_system_start_stop flag. To do this, the following libata helper functions are introduced: 1) ata_dev_power_set_standby(): This function issues a STANDBY IMMEDIATE command to transitiom a device to the standby power mode. For HDDs, this spins down the disks. This function applies only to ATA and ZAC devices and does nothing otherwise. This function also does nothing for devices that have the ATA_FLAG_NO_POWEROFF_SPINDOWN or ATA_FLAG_NO_HIBERNATE_SPINDOWN flag set. For suspend, call ata_dev_power_set_standby() in ata_eh_handle_port_suspend() before the port is disabled and frozen. ata_eh_unload() is also modified to transition all enabled devices to the standby power mode when the system is shutdown or devices removed. 2) ata_dev_power_set_active() and This function applies to ATA or ZAC devices and issues a VERIFY command for 1 sector at LBA 0 to transition the device to the active power mode. For HDDs, since this function will complete only once the disk spin up. Its execution uses the same timeouts as for reset, to give the drive enough time to complete spinup without triggering a command timeout. For resume, call ata_dev_power_set_active() in ata_eh_revalidate_and_attach() after the port has been enabled and before any other command is issued to the device. With these changes, the manage_system_start_stop and no_start_on_resume scsi device flags do not need to be set in ata_scsi_dev_config(). The flag manage_runtime_start_stop is still set to allow the sd driver to spinup/spindown a disk through the sd runtime operations. Fixes: 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Hannes Reinecke Tested-by: Geert Uytterhoeven Reviewed-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 567558b4350e854843dedc7075c7ca35cbda464f Author: Matthias Reichl Date: Fri Sep 29 21:50:28 2023 +0200 ASoC: hdmi-codec: Fix broken channel map reporting commit b84b53149476b22cc3b8677b771fb4cf06d1d455 upstream. Commit 4e0871333661 ("ASoC: hdmi-codec: fix channel info for compressed formats") accidentally changed hcp->chmap_idx from ca_id, the CEA channel allocation ID, to idx, the index to the table of channel mappings ordered by preference. This resulted in wrong channel maps being reported to userspace, eg for 5.1 "FL,FR,LFE,FC" was reported instead of the expected "FL,FR,LFE,FC,RL,RR": ~ # speaker-test -c 6 -t sine ... 0 - Front Left 3 - Front Center 1 - Front Right 2 - LFE 4 - Unknown 5 - Unknown ~ # amixer cget iface=PCM,name='Playback Channel Map' | grep ': values' : values=3,4,8,7,0,0,0,0 Switch this back to ca_id in case of PCM audio so the correct channel map is reported again and set it to HDMI_CODEC_CHMAP_IDX_UNKNOWN in case of non-PCM audio so the PCM channel map control returns "Unknown" channels (value 0). Fixes: 4e0871333661 ("ASoC: hdmi-codec: fix channel info for compressed formats") Cc: stable@vger.kernel.org Signed-off-by: Matthias Reichl Link: https://lore.kernel.org/r/20230929195027.97136-1-hias@horus.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a70aec77d89b82d106ffda99721a26ecb2808e0e Author: Sven Frotscher Date: Thu Sep 28 00:36:07 2023 +0200 ASoC: amd: yc: Fix non-functional mic on Lenovo 82YM commit 1948fa64727685ac3f6584755212e2e738b6b051 upstream. Like the Lenovo 82TL, 82V2, 82QF and 82UG, the 82YM (Yoga 7 14ARP8) requires an entry in the quirk list to enable the internal microphone. The latter two received similar fixes in commit 1263cc0f414d ("ASoC: amd: yc: Fix non-functional mic on Lenovo 82QF and 82UG"). Fixes: c008323fe361 ("ASoC: amd: yc: Fix a non-functional mic on Lenovo 82SJ") Cc: stable@vger.kernel.org Signed-off-by: Sven Frotscher Link: https://lore.kernel.org/r/20230927223758.18870-1-sven.frotscher@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 59073dfbc666aaaa6a0422a61bdce7995c94d1c8 Author: Herbert Xu Date: Fri Oct 6 09:41:55 2023 +0800 dm crypt: Fix reqsize in crypt_iv_eboiv_gen commit 152d0bcdf1efcb54a4fa20f694e9c7bbb6d06cbf upstream. A skcipher_request object is made up of struct skcipher_request followed by a variable-sized trailer. The allocation of the skcipher_request and IV in crypt_iv_eboiv_gen is missing the memory for struct skcipher_request. Fix it by adding it to reqsize. Fixes: e3023094dffb ("dm crypt: Avoid using MAX_CIPHER_BLOCKSIZE") Cc: #6.5+ Reported-by: Tatu Heikkilä Reviewed-by: Mike Snitzer Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 2a1ddddba6541143c8f73962f3021f1789114284 Author: Jan Kara Date: Wed Oct 4 15:32:01 2023 +0200 quota: Fix slow quotaoff commit 869b6ea1609f655a43251bf41757aa44e5350a8f upstream. Eric has reported that commit dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide") heavily increases runtime of generic/270 xfstest for ext4 in nojournal mode. The reason for this is that ext4 in nojournal mode leaves dquots dirty until the last dqput() and thus the cleanup done in quota_release_workfn() has to write them all. Due to the way quota_release_workfn() is written this results in synchronize_srcu() call for each dirty dquot which makes the dquot cleanup when turning quotas off extremely slow. To be able to avoid synchronize_srcu() for each dirty dquot we need to rework how we track dquots to be cleaned up. Instead of keeping the last dquot reference while it is on releasing_dquots list, we drop it right away and mark the dquot with new DQ_RELEASING_B bit instead. This way we can we can remove dquot from releasing_dquots list when new reference to it is acquired and thus there's no need to call synchronize_srcu() each time we drop dq_list_lock. References: https://lore.kernel.org/all/ZRytn6CxFK2oECUt@debian-BULLSEYE-live-builder-AMD64 Reported-by: Eric Whitney Fixes: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit f7b2c7d9831af99369fe8ad9b2a68d78942f414e Author: Hans de Goede Date: Thu Oct 5 20:26:38 2023 +0200 HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect commit dac501397b9d81e4782232c39f94f4307b137452 upstream. hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: power_supply_unregister+0x8e/0xa0 Sep 22 20:01:35 eric kernel: release_nodes+0x3d/0xb0 Sep 22 20:01:35 eric kernel: devres_release_group+0xfc/0x130 Sep 22 20:01:35 eric kernel: hid_device_remove+0x56/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: logi_dj_remove+0x9a/0x100 [hid_logitech_dj 5c91534a0ead2b65e04dd799a0437e3b99b21bc4] Sep 22 20:01:35 eric kernel: hid_device_remove+0x44/0xa0 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? __queue_work+0x1df/0x440 Sep 22 20:01:35 eric kernel: hid_destroy_device+0x4b/0x60 Sep 22 20:01:35 eric kernel: usbhid_disconnect+0x47/0x60 [usbhid 727dcc1c0b94e6b4418727a468398ac3bca492f3] Sep 22 20:01:35 eric kernel: usb_unbind_interface+0x90/0x270 Sep 22 20:01:35 eric kernel: device_release_driver_internal+0x19f/0x200 Sep 22 20:01:35 eric kernel: bus_remove_device+0xc6/0x130 Sep 22 20:01:35 eric kernel: device_del+0x15c/0x3f0 Sep 22 20:01:35 eric kernel: ? kobject_put+0xa0/0x1d0 Sep 22 20:01:35 eric kernel: usb_disable_device+0xcd/0x1e0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xde/0x2c0 Sep 22 20:01:35 eric kernel: usb_disconnect+0xc3/0x2c0 Sep 22 20:01:35 eric kernel: hub_event+0xe80/0x1c10 There have been quite a few bug reports (see Link tags) about this crash. Fix all the TOCTOU issues, including the really bad power-supply related system crash on USB disconnect, by making probe() use the workqueue for running hidpp_connect_event() too, so that it can never run more then once. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227221 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2227968 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2242189 Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412#c58 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20231005182638.3776-1-hdegoede@redhat.com Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 705c1eb72b74f8587af910707780445e2242d0ce Author: Ondrej Zary Date: Thu Oct 5 22:55:57 2023 +0200 ata: pata_parport: implement set_devctl commit d2302427c12277929c9f390adeda19fbf403c0bb upstream. Add missing ops->sff_set_devctl implementation. Fixes: 246a1c4c6b7f ("ata: pata_parport: add driver (PARIDE replacement)") Cc: stable@vger.kernel.org Signed-off-by: Ondrej Zary Reviewed-by: Sergey Shtylyov Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit cbb170a68ca40949000082eac9c383f836998424 Author: Ondrej Zary Date: Thu Oct 5 22:55:56 2023 +0200 ata: pata_parport: fix pata_parport_devchk commit b555aa66760f17df4a0a5e4b440816e390311a38 upstream. There's a 'x' missing in 0x55 in pata_parport_devchk(), causing the detection to always fail. Fix it. Fixes: 246a1c4c6b7f ("ata: pata_parport: add driver (PARIDE replacement)") Cc: stable@vger.kernel.org Signed-off-by: Ondrej Zary Reviewed-by: Sergey Shtylyov Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit e958cc0212625b73256cb571684c9a0a83d76021 Author: Damien Le Moal Date: Wed Oct 4 17:50:49 2023 +0900 scsi: Do not rescan devices with a suspended queue commit 626b13f015e080e434b1dee9a0c116ddbf4fb695 upstream. Commit ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices") modified scsi_rescan_device() to avoid attempting rescanning a suspended device. However, the modification added a check to verify that a SCSI device is in the running state without checking if the device request queue (in the case of block device) is also running, thus allowing the exectuion of internal requests. Without checking the device request queue, commit ff48b37802e5 fix is incomplete and deadlocks on resume can still happen. Use blk_queue_pm_only() to check if the device request queue allows executing commands in addition to checking the SCSI device state. Reported-by: Petr Tesarik Fixes: ff48b37802e5 ("scsi: Do not attempt to rescan suspended devices") Cc: stable@vger.kernel.org Tested-by: Petr Tesarik Reviewed-by: Martin K. Petersen Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 4e76d4585daf2dce69e41a1c298b5ab40e992427 Author: Samson Tam Date: Mon Sep 18 18:43:13 2023 -0400 drm/amd/display: apply edge-case DISPCLK WDIVIDER changes to master OTG pipes only commit b206011bf05069797df1f4c5ce639398728978e2 upstream. [Why] The edge-case DISPCLK WDIVIDER changes call stream_enc functions. But with MPC pipes, downstream pipes have null stream_enc and will cause crash. [How] Only call stream_enc functions for pipes that are OTG master. Reviewed-by: Alvin Lee Cc: Mario Limonciello Cc: Alex Deucher Cc: stable@vger.kernel.org Acked-by: Aurabindo Pillai Signed-off-by: Samson Tam Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman commit f4b4b7448ccc37f2860d6cf8bd65930869c98b0e Author: Wenjing Liu Date: Fri Jul 28 13:42:37 2023 -0400 drm/amd/display: implement pipe type definition and adding accessors commit 53f3288079460ec7c86a39871af5c8b2a5d48685 upstream. [why] There is a lack of encapsulation of pipe connection representation in pipe context. This has caused many challenging bugs and coding errors with repeated logic to identify the same pipe type. [how] Formally define pipe types and provide getters to identify a pipe type and find a pipe based on specific requirements. Update existing logic in non dcn specific files and dcn32 and future versions to use the new accessors. Reviewed-by: Jun Lei Acked-by: Stylon Wang Signed-off-by: Wenjing Liu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher [ Reduced to only introduce resource_is_pipe_type() to make candidate for stable 6.5.y. ] Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman commit 50f84c0b1e2c15486e36da84e3dd772eacd48f81 Author: Fabio Estevam Date: Wed Oct 4 17:11:05 2023 -0300 media: dt-bindings: imx7-csi: Make power-domains not required for imx8mq [ Upstream commit d7614a2733f5e354c075be178b068a241d5d8b11 ] On i.MX8MQ the MIPI CSI block does have an associated power-domain, but the CSI bridge does not. Remove the power-domains requirement from the i.MX8MQ CSI bridge to fix the following schema warning: imx8mq-librem5-r4.dtb: csi@30a90000: 'power-domains' is a required property from schema $id: http://devicetree.org/schemas/media/nxp,imx7-csi.yaml# Fixes: de655386845a ("media: dt-bindings: media: imx7-csi: Document i.MX8M power-domains property") Signed-off-by: Fabio Estevam Acked-by: Conor Dooley Reviewed-by: Marek Vasut Link: https://lore.kernel.org/r/20231004201105.2323758-1-festevam@gmail.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit fe76d3e58a8103df404a772ae3c0fbc2627a1c5b Author: Uwe Kleine-König Date: Wed Oct 4 13:16:24 2023 +0200 platform/x86: hp-wmi:: Mark driver struct with __refdata to prevent section mismatch warning [ Upstream commit 5b44abbc39ca15df80d0da4756078c98c831090f ] As described in the added code comment, a reference to .exit.text is ok for drivers registered via module_platform_driver_probe(). Make this explicit to prevent a section mismatch warning: WARNING: modpost: drivers/platform/x86/hp/hp-wmi: section mismatch in reference: hp_wmi_driver+0x8 (section: .data) -> hp_wmi_bios_remove (section: .exit.text) Fixes: c165b80cfecc ("hp-wmi: fix handling of platform device") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20231004111624.2667753-1-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit c8647e25346ea1fb8340dfbedadea9c76c8f1811 Author: Luben Tuikov Date: Fri Sep 22 17:21:21 2023 -0400 drm/amdgpu: Fix a memory leak [ Upstream commit 5d061675b7538e25d060d13310880c01160207c4 ] Fix a memory leak in amdgpu_fru_get_product_info(). Cc: Alex Deucher Reported-by: Yang Wang Fixes: 0dbf2c562625 ("drm/amdgpu: Interpret IPMI data for product information (v2)") Signed-off-by: Luben Tuikov Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fdae43a5b6ce60a9bb23b35801da1876350fcb39 Author: Oza Pawandeep Date: Tue Oct 3 10:33:33 2023 -0700 cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer [ Upstream commit 4785aa8028536c2be656d22c74ec1995b97056f3 ] Arm® Functional Fixed Hardware Specification defines LPI states, which provide an architectural context loss flags field that can be used to describe the context that might be lost when an LPI state is entered. - Core context Lost - General purpose registers. - Floating point and SIMD registers. - System registers, include the System register based - generic timer for the core. - Debug register in the core power domain. - PMU registers in the core power domain. - Trace register in the core power domain. - Trace context loss - GICR - GICD Qualcomm's custom CPUs preserves the architectural state, including keeping the power domain for local timers active. when core is power gated, the local timers are sufficient to wake the core up without needing broadcast timer. The patch fixes the evaluation of cpuidle arch_flags, and moves only to broadcast timer if core context lost is defined in ACPI LPI. Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power Idle(LPI) states") Reviewed-by: Sudeep Holla Acked-by: Rafael J. Wysocki Signed-off-by: Oza Pawandeep Link: https://lore.kernel.org/r/20231003173333.2865323-1-quic_poza@quicinc.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1d61ce0a321f24890bb2c3d68457736769450753 Author: Mathias Krause Date: Thu Sep 28 20:20:18 2023 +0200 drm/i915: Register engines early to avoid type confusion [ Upstream commit 6007265ad70a87aa9b4eea79b5e5828da452cfd8 ] Commit 1ec23ed7126e ("drm/i915: Use uabi engines for the default engine map") switched from using for_each_engine() to for_each_uabi_engine() to iterate over the user engines. While this seems to be a sensible change, it's only safe to do when the engines are actually chained using the rb-tree structure which is not the case during early driver initialization where it can be either a lock-less list or regular double-linked list. In fact, the modesetting initialization code may end up calling default_engines() through the fb helper code while the engines list is still llist_node-based: i915_driver_probe() -> intel_display_driver_probe() -> intel_fbdev_init() -> drm_fb_helper_init() -> drm_client_init() -> drm_client_open() -> drm_file_alloc() -> i915_driver_open() -> i915_gem_open() -> i915_gem_context_open() -> i915_gem_create_context() -> default_engines() Using for_each_uabi_engine() in default_engines() is therefore wrong, as it would try to interpret the llist as rb-tree, making it find no engine at all, as the rb_left and rb_right members will still be NULL, as they haven't been initialized yet. To fix this type confusion register the engines earlier and at the same time reduce the amount of code that has to deal with the intermediate llist state. Reported-by: sanity checks in grsecurity Suggested-by: Tvrtko Ursulin Fixes: 1ec23ed7126e ("drm/i915: Use uabi engines for the default engine map") Signed-off-by: Mathias Krause Cc: Jonathan Cavitt Cc: Tvrtko Ursulin Reviewed-by: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20230928182019.10256-2-minipli@grsecurity.net [tursulin: fixed commit tag typo] (cherry picked from commit 2b562f032fc2594fb3fac22b7a2eb3c1969a7ba3) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit c6e3023579de8d33256771ac0745239029e81106 Author: Armin Wolf Date: Mon Sep 25 16:28:18 2023 +0200 platform/x86: think-lmi: Fix reference leak [ Upstream commit 528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81 ] If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a separate function to allow for this change without having to duplicate the cleanup code for this setting. As a side note, a very similar bug was fixed in commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"), so it seems that the bug was copied from that driver. Compile-tested only. Fixes: 1bcad8e510b2 ("platform/x86: think-lmi: Fix issues with duplicate attributes") Reviewed-by: Mark Pearson Reviewed-by: Ilpo Järvinen Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20230925142819.74525-2-W_Armin@gmx.de Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 1cd61412f98df5e73e8c6101b5d62988041c41ac Author: Jing Zhang Date: Mon Sep 25 11:22:32 2023 +0800 perf/arm-cmn: Fix the unhandled overflow status of counter 4 to 7 [ Upstream commit 7f949f6f54ff593123ab95b6247bfa4542a65580 ] The register por_dt_pmovsr Bits[7:0] indicates overflow from counters 7 to 0. But in arm_cmn_handle_irq(), only handled the overflow status of Bits[3:0] which results in unhandled overflow status of counters 4 to 7. So let the overflow status of DTC counters 4 to 7 to be handled. Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Signed-off-by: Jing Zhang Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/1695612152-123633-1-git-send-email-renyu.zj@linux.alibaba.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 7e879676635c338d8d7e525fdd49cb6a0cc5b4a2 Author: Artem Chernyshev Date: Tue Sep 5 15:40:48 2023 +0300 RDMA/cxgb4: Check skb value for failure to allocate [ Upstream commit 8fb8a82086f5bda6893ea6557c5a458e4549c6d7 ] get_skb() can fail to allocate skb, so check it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5be78ee924ae ("RDMA/cxgb4: Fix LE hash collision bug for active open connection") Signed-off-by: Artem Chernyshev Link: https://lore.kernel.org/r/20230905124048.284165-1-artem.chernyshev@red-soft.ru Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9dcc8f4dbe147af93fcf1fd1f4233b669e293213 Author: Remi Pommarel Date: Wed Oct 4 16:33:56 2023 +0200 net: stmmac: remove unneeded stmmac_poll_controller [ Upstream commit 3eef8555891026628aa1cc6dbc01db86df88aa26 ] Using netconsole netpoll_poll_dev could be called from interrupt context, thus using disable_irq() would cause the following kernel warning with CONFIG_DEBUG_ATOMIC_SLEEP enabled: BUG: sleeping function called from invalid context at kernel/irq/manage.c:137 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 10, name: ksoftirqd/0 CPU: 0 PID: 10 Comm: ksoftirqd/0 Tainted: G W 5.15.42-00075-g816b502b2298-dirty #117 Hardware name: aml (r1) (DT) Call trace: dump_backtrace+0x0/0x270 show_stack+0x14/0x20 dump_stack_lvl+0x8c/0xac dump_stack+0x18/0x30 ___might_sleep+0x150/0x194 __might_sleep+0x64/0xbc synchronize_irq+0x8c/0x150 disable_irq+0x2c/0x40 stmmac_poll_controller+0x140/0x1a0 netpoll_poll_dev+0x6c/0x220 netpoll_send_skb+0x308/0x390 netpoll_send_udp+0x418/0x760 write_msg+0x118/0x140 [netconsole] console_unlock+0x404/0x500 vprintk_emit+0x118/0x250 dev_vprintk_emit+0x19c/0x1cc dev_printk_emit+0x90/0xa8 __dev_printk+0x78/0x9c _dev_warn+0xa4/0xbc ath10k_warn+0xe8/0xf0 [ath10k_core] ath10k_htt_txrx_compl_task+0x790/0x7fc [ath10k_core] ath10k_pci_napi_poll+0x98/0x1f4 [ath10k_pci] __napi_poll+0x58/0x1f4 net_rx_action+0x504/0x590 _stext+0x1b8/0x418 run_ksoftirqd+0x74/0xa4 smpboot_thread_fn+0x210/0x3c0 kthread+0x1fc/0x210 ret_from_fork+0x10/0x20 Since [0] .ndo_poll_controller is only needed if driver doesn't or partially use NAPI. Because stmmac does so, stmmac_poll_controller can be removed fixing the above warning. [0] commit ac3d9dd034e5 ("netpoll: make ndo_poll_controller() optional") Cc: # 5.15.x Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers") Signed-off-by: Remi Pommarel Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/1c156a6d8c9170bd6a17825f2277115525b4d50f.1696429960.git.repk@triplefau.lt Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin