commit 42f2129e08b822f0ccb9e66410f3a0d3986e105c Author: Greg Kroah-Hartman Date: Mon Dec 19 12:41:04 2022 +0100 Linux 6.0.14 Link: https://lore.kernel.org/r/20221215172908.162858817@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Bagas Sanjaya Tested-by: Allen Pais Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Fenil Jain Signed-off-by: Greg Kroah-Hartman commit 7eeab94a7a1be00234ba0aea528cad693e5ed360 Author: Rasmus Villemoes Date: Mon Dec 5 21:46:04 2022 +0100 net: fec: properly guard irq coalesce setup commit 7e6303567ce3ca506e4a2704e4baa86f1d8bde02 upstream. Prior to the Fixes: commit, the initialization code went through the same fec_enet_set_coalesce() function as used by ethtool, and that function correctly checks whether the current variant has support for irq coalescing. Now that the initialization code instead calls fec_enet_itr_coal_set() directly, that call needs to be guarded by a check for the FEC_QUIRK_HAS_COALESCE bit. Fixes: df727d4547de (net: fec: don't reset irq coalesce settings to defaults on "ip link up") Reported-by: Greg Ungerer Signed-off-by: Rasmus Villemoes Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20221205204604.869853-1-linux@rasmusvillemoes.dk Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7fd2add1e3bd22d1dda557710127e3ca3287dcce Author: Charles Keepax Date: Fri Nov 25 16:23:47 2022 +0000 ASoC: ops: Correct bounds check for second channel on SX controls commit f33bcc506050f89433a52a3052054d4ebd37b1c1 upstream. Currently the check against the max value for the control is being applied after the value has had the minimum applied and been masked. But the max value simply indicates the number of volume levels on an SX control, and as such should just be applied on the raw value. Fixes: 97eea946b939 ("ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()") Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20221125162348.1288005-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d5118a4b3cd6a5a33b8db11375cdde382f0607d0 Author: Lei Rao Date: Tue Nov 29 17:48:11 2022 +0800 nvme-pci: clear the prp2 field when not used [ Upstream commit a56ea6147facce4ac1fc38675455f9733d96232b ] If the prp2 field is not filled in nvme_setup_prp_simple(), the prp2 field is garbage data. According to nvme spec, the prp2 is reserved if the data transfer does not cross a memory page boundary, so clear it to zero if it is not used. Signed-off-by: Lei Rao Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 78e1317a174edbfd1182599bf76c092a2877672c Author: Peter Zijlstra Date: Thu Nov 24 12:49:12 2022 +0100 perf: Fix perf_pending_task() UaF [ Upstream commit 517e6a301f34613bff24a8e35b5455884f2d83d8 ] Per syzbot it is possible for perf_pending_task() to run after the event is free()'d. There are two related but distinct cases: - the task_work was already queued before destroying the event; - destroying the event itself queues the task_work. The first cannot be solved using task_work_cancel() since perf_release() itself might be called from a task_work (____fput), which means the current->task_works list is already empty and task_work_cancel() won't be able to find the perf_pending_task() entry. The simplest alternative is extending the perf_event lifetime to cover the task_work. The second is just silly, queueing a task_work while you know the event is going away makes no sense and is easily avoided by re-arranging how the event is marked STATE_DEAD and ensuring it goes through STATE_OFF on the way down. Reported-by: syzbot+9228d6098455bb209ec8@syzkaller.appspotmail.com Signed-off-by: Peter Zijlstra (Intel) Tested-by: Marco Elver Signed-off-by: Sasha Levin commit ef69bae62c89c700a0e34f86861612d4aaf26b5e Author: Charles Keepax Date: Fri Nov 25 16:23:48 2022 +0000 ASoC: cs42l51: Correct PGA Volume minimum value [ Upstream commit 3d1bb6cc1a654c8693a85b1d262e610196edec8b ] The table in the datasheet actually shows the volume values in the wrong order, with the two -3dB values being reversed. This appears to have caused the lower of the two values to be used in the driver when the higher should have been, correct this mixup. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20221125162348.1288005-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 55b49b040fbecf17499d1d6cac9e3cedac2d0a67 Author: Rasmus Villemoes Date: Wed Nov 23 14:38:52 2022 +0100 net: fec: don't reset irq coalesce settings to defaults on "ip link up" [ Upstream commit df727d4547de568302b0ed15b0d4e8a469bdb456 ] Currently, when a FEC device is brought up, the irq coalesce settings are reset to their default values (1000us, 200 frames). That's unexpected, and breaks for example use of an appropriate .link file to make systemd-udev apply the desired settings (https://www.freedesktop.org/software/systemd/man/systemd.link.html), or any other method that would do a one-time setup during early boot. Refactor the code so that fec_restart() instead uses fec_enet_itr_coal_set(), which simply applies the settings that are stored in the private data, and initialize that private data with the default values. Signed-off-by: Rasmus Villemoes Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9938f79cbc29c75ce54eded215fb0a226db9c26d Author: Yasushi SHOJI Date: Fri Nov 25 00:25:03 2022 +0900 can: mcba_usb: Fix termination command argument [ Upstream commit 1a8e3bd25f1e789c8154e11ea24dc3ec5a4c1da0 ] Microchip USB Analyzer can activate the internal termination resistors by setting the "termination" option ON, or OFF to to deactivate them. As I've observed, both with my oscilloscope and captured USB packets below, you must send "0" to turn it ON, and "1" to turn it OFF. From the schematics in the user's guide, I can confirm that you must drive the CAN_RES signal LOW "0" to activate the resistors. Reverse the argument value of usb_msg.termination to fix this. These are the two commands sequence, ON then OFF. > No. Time Source Destination Protocol Length Info > 1 0.000000 host 1.3.1 USB 46 URB_BULK out > > Frame 1: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) > USB URB > Leftover Capture Data: a80000000000000000000000000000000000a8 > > No. Time Source Destination Protocol Length Info > 2 4.372547 host 1.3.1 USB 46 URB_BULK out > > Frame 2: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) > USB URB > Leftover Capture Data: a80100000000000000000000000000000000a9 Signed-off-by: Yasushi SHOJI Link: https://lore.kernel.org/all/20221124152504.125994-1-yashi@spacecubics.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit e0668c0a6361076e037ef9c4820baf00de2ad8ce Author: Heiko Schocher Date: Wed Nov 23 08:16:36 2022 +0100 can: sja1000: fix size of OCR_MODE_MASK define [ Upstream commit 26e8f6a75248247982458e8237b98c9fb2ffcf9d ] bitfield mode in ocr register has only 2 bits not 3, so correct the OCR_MODE_MASK define. Signed-off-by: Heiko Schocher Link: https://lore.kernel.org/all/20221123071636.2407823-1-hs@denx.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit c24dfee7d1593651e9a644fe970dda9f9832ac07 Author: Ricardo Ribalda Date: Tue Nov 22 00:38:55 2022 +0100 pinctrl: meditatek: Startup with the IRQs disabled [ Upstream commit 11780e37565db4dd064d3243ca68f755c13f65b4 ] If the system is restarted via kexec(), the peripherals do not start with a known state. If the previous system had enabled an IRQs we will receive unexected IRQs that can lock the system. [ 28.109251] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:0] [ 28.109263] Modules linked in: [ 28.109273] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.79-14458-g4b9edf7b1ac6 #1 9f2e76613148af94acccd64c609a552fb4b4354b [ 28.109284] Hardware name: Google Elm (DT) [ 28.109290] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.109298] pc : __do_softirq+0xa0/0x388 [ 28.109309] lr : __do_softirq+0x70/0x388 [ 28.109316] sp : ffffffc008003ee0 [ 28.109321] x29: ffffffc008003f00 x28: 000000000000000a x27: 0000000000000080 [ 28.109334] x26: 0000000000000001 x25: ffffffefa7b350c0 x24: ffffffefa7b47480 [ 28.109346] x23: ffffffefa7b3d000 x22: 0000000000000000 x21: ffffffefa7b0fa40 [ 28.109358] x20: ffffffefa7b005b0 x19: ffffffefa7b47480 x18: 0000000000065b6b [ 28.109370] x17: ffffffefa749c8b0 x16: 000000000000018c x15: 00000000000001b8 [ 28.109382] x14: 00000000000d3b6b x13: 0000000000000006 x12: 0000000000057e91 [ 28.109394] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffefa7b47480 [ 28.109406] x8 : 00000000000000e0 x7 : 000000000f424000 x6 : 0000000000000000 [ 28.109418] x5 : ffffffefa7dfaca0 x4 : ffffffefa7dfadf0 x3 : 000000000000000f [ 28.109429] x2 : 0000000000000000 x1 : 0000000000000100 x0 : 0000000001ac65c5 [ 28.109441] Call trace: [ 28.109447] __do_softirq+0xa0/0x388 [ 28.109454] irq_exit+0xc0/0xe0 [ 28.109464] handle_domain_irq+0x68/0x90 [ 28.109473] gic_handle_irq+0xac/0xf0 [ 28.109480] call_on_irq_stack+0x28/0x50 [ 28.109488] do_interrupt_handler+0x44/0x58 [ 28.109496] el1_interrupt+0x30/0x58 [ 28.109506] el1h_64_irq_handler+0x18/0x24 [ 28.109512] el1h_64_irq+0x7c/0x80 [ 28.109519] arch_local_irq_enable+0xc/0x18 [ 28.109529] default_idle_call+0x40/0x140 [ 28.109539] do_idle+0x108/0x290 [ 28.109547] cpu_startup_entry+0x2c/0x30 [ 28.109554] rest_init+0xe8/0xf8 [ 28.109562] arch_call_rest_init+0x18/0x24 [ 28.109571] start_kernel+0x338/0x42c [ 28.109578] __primary_switched+0xbc/0xc4 [ 28.109588] Kernel panic - not syncing: softlockup: hung tasks Signed-off-by: Ricardo Ribalda Link: https://lore.kernel.org/r/20221122-mtk-pinctrl-v1-1-bedf5655a3d2@chromium.org Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 0a81076a3681f30a9c35ff4b16ac93d09a98120c Author: Hou Tao Date: Wed Nov 16 15:23:48 2022 +0800 libbpf: Use page size as max_entries when probing ring buffer map [ Upstream commit 689eb2f1ba46b4b02195ac2a71c55b96d619ebf8 ] Using page size as max_entries when probing ring buffer map, else the probe may fail on host with 64KB page size (e.g., an ARM64 host). After the fix, the output of "bpftool feature" on above host will be correct. Before : eBPF map_type ringbuf is NOT available eBPF map_type user_ringbuf is NOT available After : eBPF map_type ringbuf is available eBPF map_type user_ringbuf is available Signed-off-by: Hou Tao Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20221116072351.1168938-2-houtao@huaweicloud.com Signed-off-by: Sasha Levin commit 1798b62d642e7b3d4ea3403914c3caf4e438465d Author: Mark Brown Date: Wed May 11 14:41:37 2022 +0100 ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx() [ Upstream commit 97eea946b93961fffd29448dcda7398d0d51c4b2 ] The bounds checks in snd_soc_put_volsw_sx() are only being applied to the first channel, meaning it is possible to write out of bounds values to the second channel in stereo controls. Add appropriate checks. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220511134137.169575-2-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6aeae2eee731a68e6a69828ab3889fbff3d9d831 Author: Shengjiu Wang Date: Sat May 7 20:14:14 2022 +0800 ASoC: fsl_micfil: explicitly clear CHnF flags [ Upstream commit b776c4a4618ec1b5219d494c423dc142f23c4e8f ] There may be failure when start 1 channel recording after 8 channels recording. The reason is that the CHnF flags are not cleared successfully by software reset. This issue is triggerred by the change of clearing software reset bit. CHnF flags are write 1 clear bits. Clear them by force write. Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1651925654-32060-2-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0e770ee4fb6789cad6d074e98202ae2140590901 Author: Shengjiu Wang Date: Sat May 7 20:14:13 2022 +0800 ASoC: fsl_micfil: explicitly clear software reset bit [ Upstream commit 292709b9cf3ba470af94b62c9bb60284cc581b79 ] SRES is self-cleared bit, but REG_MICFIL_CTRL1 is defined as non volatile register, it still remain in regmap cache after set, then every update of REG_MICFIL_CTRL1, software reset happens. to avoid this, clear it explicitly. Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1651925654-32060-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d85028cb27ce1952266b9c53685db468c3075872 Author: Alexandre Belloni Date: Tue Oct 18 22:35:11 2022 +0200 rtc: cmos: fix build on non-ACPI platforms commit db4e955ae333567dea02822624106c0b96a2f84f upstream. Now that rtc_wake_setup is called outside of cmos_wake_setup, it also need to be defined on non-ACPI platforms. Reported-by: kernel test robot Link: https://lore.kernel.org/r/20221018203512.2532407-1-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit d93209a7d8ab0c84344e0a057466a0a73bdb289c Author: David Michael Date: Sun Nov 13 15:52:17 2022 -0500 libbpf: Fix uninitialized warning in btf_dump_dump_type_data commit dfd0afbf151d85411b371e841f62b81ee5d1ca54 upstream. GCC 11.3.0 fails to compile btf_dump.c due to the following error, which seems to originate in btf_dump_struct_data where the returned value would be uninitialized if btf_vlen returns zero. btf_dump.c: In function ‘btf_dump_dump_type_data’: btf_dump.c:2363:12: error: ‘err’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 2363 | if (err < 0) | ^ Fixes: 920d16af9b42 ("libbpf: BTF dumper support for typed data") Signed-off-by: David Michael Signed-off-by: Daniel Borkmann Acked-by: Stanislav Fomichev Acked-by: Alan Maguire Link: https://lore.kernel.org/bpf/87zgcu60hq.fsf@gmail.com Signed-off-by: Greg Kroah-Hartman commit 00b69f03b9ac938ceae74603afa4cf67547feaa7 Author: Nathan Chancellor Date: Tue Nov 8 17:03:07 2022 -0700 x86/vdso: Conditionally export __vdso_sgx_enter_enclave() commit 45be2ad007a9c6bea70249c4cf3e4905afe4caeb upstream. Recently, ld.lld moved from '--undefined-version' to '--no-undefined-version' as the default, which breaks building the vDSO when CONFIG_X86_SGX is not set: ld.lld: error: version script assignment of 'LINUX_2.6' to symbol '__vdso_sgx_enter_enclave' failed: symbol not defined __vdso_sgx_enter_enclave is only included in the vDSO when CONFIG_X86_SGX is set. Only export it if it will be present in the final object, which clears up the error. Fixes: 8466436952017 ("x86/vdso: Implement a vDSO for Intel SGX enclave call") Signed-off-by: Nathan Chancellor Signed-off-by: Thomas Gleixner Reviewed-by: Nick Desaulniers Link: https://github.com/ClangBuiltLinux/linux/issues/1756 Link: https://lore.kernel.org/r/20221109000306.1407357-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1582f5d1efbe3e5b00c710c768c67e16c466cba3 Author: Rafael J. Wysocki Date: Tue Oct 18 18:09:31 2022 +0200 rtc: cmos: Fix wake alarm breakage commit 0782b66ed2fbb035dda76111df0954515e417b24 upstream. Commit 4919d3eb2ec0 ("rtc: cmos: Fix event handler registration ordering issue") overlooked the fact that cmos_do_probe() depended on the preparations carried out by cmos_wake_setup() and the wake alarm stopped working after the ordering of them had been changed. Address this by partially reverting commit 4919d3eb2ec0 so that cmos_wake_setup() is called before cmos_do_probe() again and moving the rtc_wake_setup() invocation from cmos_wake_setup() directly to the callers of cmos_do_probe() where it will happen after a successful completion of the latter. Fixes: 4919d3eb2ec0 ("rtc: cmos: Fix event handler registration ordering issue") Reported-by: Zhang Rui Reported-by: Todd Brandt Signed-off-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/5887691.lOV4Wx5bFT@kreacher Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 1ba745fce13d19775100eece30b0bfb8b8b10ea6 Author: Rafael J. Wysocki Date: Wed Oct 12 20:07:01 2022 +0200 rtc: cmos: Fix event handler registration ordering issue commit 4919d3eb2ec0ee364f7e3cf2d99646c1b224fae8 upstream. Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit. Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver") Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/ Reported-by: Mel Gorman Signed-off-by: Rafael J. Wysocki Reviewed-by: Bjorn Helgaas Tested-by: Mel Gorman Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman