commit 0283cbd1473380d3ae46f653eac128aebb288423 Author: Greg Kroah-Hartman Date: Fri Jul 22 10:21:59 2022 +0200 Linux 5.18.13 Link: https://lore.kernel.org/r/20220719114714.247441733@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Jon Hunter Tested-by: Bagas Sanjaya Tested-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20220721180421.921249751@linuxfoundation.org Link: https://lore.kernel.org/r/20220721182818.743726259@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Justin M. Forbes Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit 6e3a6dddad55010a893b07e4e9f2ba30ff95b6d8 Author: Thomas Zimmermann Date: Fri Jun 17 14:10:27 2022 +0200 drm/aperture: Run fbdev removal before internal helpers commit bf43e4521ff3223a613f3a496991a22a4d78e04b upstream. Always run fbdev removal first to remove simpledrm via sysfb_disable(). This clears the internal state. The later call to drm_aperture_detach_drivers() then does nothing. Otherwise, with drm_aperture_detach_drivers() running first, the call to sysfb_disable() uses inconsistent state. Example backtrace show below: [ 11.663422] ================================================================== [ 11.663426] BUG: KASAN: use-after-free in device_del+0x79/0x5f0 [ 11.663435] Read of size 8 at addr ffff888108185050 by task systemd-udevd/311 [ 11.663440] CPU: 0 PID: 311 Comm: systemd-udevd Tainted: G E 5 .19.0-rc2-1-default+ #1689 [ 11.663445] Hardware name: HP ProLiant DL120 G7, BIOS J01 04/21/2011 [ 11.663447] Call Trace: [ 11.663449] [ 11.663451] ? device_del+0x79/0x5f0 [ 11.663456] dump_stack_lvl+0x5b/0x73 [ 11.663462] print_address_description.constprop.0+0x1f/0x1b0 [ 11.663468] ? device_del+0x79/0x5f0 [ 11.663471] ? device_del+0x79/0x5f0 [ 11.663475] print_report.cold+0x3c/0x21c [ 11.663481] ? lock_acquired+0x87/0x1e0 [ 11.663484] ? lock_acquired+0x87/0x1e0 [ 11.663489] ? device_del+0x79/0x5f0 [ 11.663492] kasan_report+0xbf/0xf0 [ 11.663498] ? device_del+0x79/0x5f0 [ 11.663503] device_del+0x79/0x5f0 [ 11.663509] ? device_remove_attrs+0x170/0x170 [ 11.663514] ? lock_is_held_type+0xe8/0x140 [ 11.663523] platform_device_del.part.0+0x19/0xe0 [ 11.663530] platform_device_unregister+0x1c/0x30 [ 11.663535] sysfb_disable+0x2d/0x70 [ 11.663540] remove_conflicting_framebuffers+0x1c/0xf0 [ 11.663546] remove_conflicting_pci_framebuffers+0x130/0x1a0 [ 11.663554] drm_aperture_remove_conflicting_pci_framebuffers+0x86/0xb0 [ 11.663561] ? mgag200_pci_remove+0x30/0x30 [mgag200] [ 11.663578] mgag200_pci_probe+0x2d/0x140 [mgag200] Reported-by: Zack Rusin Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Reviewed-by: Zack Rusin Fixes: ee7a69aa38d8 ("fbdev: Disable sysfb device registration when removing conflicting FBs") Cc: Javier Martinez Canillas Cc: Daniel Vetter Cc: Daniel Vetter Cc: Sam Ravnborg Cc: Helge Deller Cc: Thomas Zimmermann Cc: Alex Deucher Cc: Zhen Lei Cc: Changcheng Deng Link: https://patchwork.freedesktop.org/patch/msgid/20220617121027.30273-1-tzimmermann@suse.de (cherry picked from commit fb84efa28a48e30b87fa1122e8aab8016c7347cd) Signed-off-by: Thomas Zimmermann Signed-off-by: Greg Kroah-Hartman commit 7642e42a64b09177060c4712fbbcc1e1882fb98e Author: Matthew Auld Date: Tue Jul 12 18:40:50 2022 +0100 drm/i915/ttm: fix 32b build commit ced7866db39fc5c59ee05e154d4abc0977a17f6b upstream. Since segment_pages is no longer a compile time constant, it looks the DIV_ROUND_UP(node->size, segment_pages) breaks the 32b build. Simplest is just to use the ULL variant, but really we should need not need more than u32 for the page alignment (also we are limited by that due to the sg->length type), so also make it all u32. Reported-by: Ville Syrjälä Fixes: aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction") Signed-off-by: Matthew Auld Cc: Nirmoy Das Reviewed-by: Nirmoy Das Link: https://patchwork.freedesktop.org/patch/msgid/20220712174050.592550-1-matthew.auld@intel.com (cherry picked from commit 9306b2b2dfce6931241ef804783692cee526599c) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 99c8a3c41e0791c39482f34ee8ca3f7014ee2e3f Author: Juergen Gross Date: Fri Jul 8 15:14:56 2022 +0200 x86/pat: Fix x86_has_pat_wp() commit 230ec83d4299b30c51a1c133b4f2a669972cc08a upstream. x86_has_pat_wp() is using a wrong test, as it relies on the normal PAT configuration used by the kernel. In case the PAT MSR has been setup by another entity (e.g. Xen hypervisor) it might return false even if the PAT configuration is allowing WP mappings. This due to the fact that when running as Xen PV guest the PAT MSR is setup by the hypervisor and cannot be changed by the guest. This results in the WP related entry to be at a different position when running as Xen PV guest compared to the bare metal or fully virtualized case. The correct way to test for WP support is: 1. Get the PTE protection bits needed to select WP mode by reading __cachemode2pte_tbl[_PAGE_CACHE_MODE_WP] (depending on the PAT MSR setting this might return protection bits for a stronger mode, e.g. UC-) 2. Translate those bits back into the real cache mode selected by those PTE bits by reading __pte2cachemode_tbl[__pte2cm_idx(prot)] 3. Test for the cache mode to be _PAGE_CACHE_MODE_WP Fixes: f88a68facd9a ("x86/mm: Extend early_memremap() support with additional attrs") Signed-off-by: Juergen Gross Signed-off-by: Borislav Petkov Cc: # 4.14 Link: https://lore.kernel.org/r/20220503132207.17234-1-jgross@suse.com Signed-off-by: Greg Kroah-Hartman commit ec02687a33e7ef731afbf77c7e60a7561e9cb441 Author: Pali Rohár Date: Tue Jun 28 12:09:22 2022 +0200 serial: mvebu-uart: correctly report configured baudrate value commit 4f532c1e25319e42996ec18a1f473fd50c8e575d upstream. Functions tty_termios_encode_baud_rate() and uart_update_timeout() should be called with the baudrate value which was set to hardware. Linux then report exact values via ioctl(TCGETS2) to userspace. Change mvebu_uart_baud_rate_set() function to return baudrate value which was set to hardware and propagate this value to above mentioned functions. With this change userspace would see precise value in termios c_ospeed field. Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate") Cc: stable Reviewed-by: Ilpo Järvinen Signed-off-by: Pali Rohár Link: https://lore.kernel.org/r/20220628100922.10717-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5df66302f03f87ae8953785a882d78e911f00c55 Author: Ilpo Järvinen Date: Wed Jun 29 12:48:41 2022 +0300 serial: 8250: Fix PM usage_count for console handover commit f9b11229b79c0fb2100b5bb4628a101b1d37fbf6 upstream. When console is enabled, univ8250_console_setup() calls serial8250_console_setup() before .dev is set to uart_port. Therefore, it will not call pm_runtime_get_sync(). Later, when the actual driver is going to take over univ8250_console_exit() is called. As .dev is already set, serial8250_console_exit() makes pm_runtime_put_sync() call with usage count being zero triggering PM usage count warning (extra debug for univ8250_console_setup(), univ8250_console_exit(), and serial8250_register_ports()): [ 0.068987] univ8250_console_setup ttyS0 nodev [ 0.499670] printk: console [ttyS0] enabled [ 0.717955] printk: console [ttyS0] printing thread started [ 1.960163] serial8250_register_ports assigned dev for ttyS0 [ 1.976830] printk: console [ttyS0] disabled [ 1.976888] printk: console [ttyS0] printing thread stopped [ 1.977073] univ8250_console_exit ttyS0 usage:0 [ 1.977075] serial8250 serial8250: Runtime PM usage count underflow! [ 1.977429] dw-apb-uart.6: ttyS0 at MMIO 0x4010006000 (irq = 33, base_baud = 115200) is a 16550A [ 1.977812] univ8250_console_setup ttyS0 usage:2 [ 1.978167] printk: console [ttyS0] printing thread started [ 1.978203] printk: console [ttyS0] enabled To fix the issue, call pm_runtime_get_sync() in serial8250_register_ports() as soon as .dev is set for an uart_port if it has console enabled. This problem became apparent only recently because 82586a721595 ("PM: runtime: Avoid device usage count underflows") added the warning printout. I confirmed this problem also occurs with v5.18 (w/o the warning printout, obviously). Fixes: bedb404e91bb ("serial: 8250_port: Don't use power management for kernel console") Cc: stable Tested-by: Tony Lindgren Reviewed-by: Andy Shevchenko Reviewed-by: Tony Lindgren Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/b4f428e9-491f-daf2-2232-819928dc276e@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit b2f63fefefc5c1cba4e192949751a67bc166a671 Author: Ilpo Järvinen Date: Tue Jun 14 10:56:37 2022 +0300 serial: pl011: UPSTAT_AUTORTS requires .throttle/unthrottle commit 211565b100993c90b53bf40851eacaefc830cfe0 upstream. The driver must provide throttle and unthrottle in uart_ops when it sets UPSTAT_AUTORTS. Add them using existing stop_rx & enable_interrupts functions. Fixes: 2a76fa283098 (serial: pl011: Adopt generic flag to store auto RTS status) Cc: stable Cc: Lukas Wunner Reported-by: Nuno Gonçalves Tested-by: Nuno Gonçalves Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20220614075637.8558-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 484ec3ca92e47d7fb7bad005ddc66d8965485ad9 Author: Ilpo Järvinen Date: Mon Jun 27 18:07:52 2022 +0300 serial: stm32: Clear prev values before setting RTS delays commit 5c5f44e36217de5ead789ff25da71c31c2331c96 upstream. The code lacks clearing of previous DEAT/DEDT values. Thus, changing values on the fly results in garbage delays tending towards the maximum value as more and more bits are ORed together. (Leaving RS485 mode would have cleared the old values though). Fixes: 1bcda09d2910 ("serial: stm32: add support for RS485 hardware control mode") Cc: stable Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20220627150753.34510-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit a762cee5d933fe4e2e1b773d60fc74fb8248d8c4 Author: Dorian Rudolph Date: Sat May 14 17:23:40 2022 +0200 power: supply: core: Fix boundary conditions in interpolation commit 093d27bb6f2d1963f927ef59c9a2d37059175426 upstream. The functions power_supply_temp2resist_simple and power_supply_ocv2cap_simple handle boundary conditions incorrectly. The change was introduced in a4585ba2050f460f749bbaf2b67bd56c41e30283 ("power: supply: core: Use library interpolation"). There are two issues: First, the lines "high = i - 1" and "high = i" in ocv2cap have the wrong order compared to temp2resist. As a consequence, ocv2cap sets high=-1 if ocv>table[0].ocv, which causes an out-of-bounds read. Second, the logic of temp2resist is also not correct. Consider the case table[] = {{20, 100}, {10, 80}, {0, 60}}. For temp=5, we expect a resistance of 70% by interpolation. However, temp2resist sets high=low=2 and returns 60. Cc: stable@vger.kernel.org Signed-off-by: Dorian Rudolph Reviewed-by: Linus Walleij Fixes: a4585ba2050f ("power: supply: core: Use library interpolation") Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit dda20f46124a80e3c832a3aa024befd998f847e1 Author: Yi Yang Date: Tue Jun 28 16:35:15 2022 +0800 serial: 8250: fix return error code in serial8250_request_std_resource() commit 6e690d54cfa802f939cefbd2fa2c91bd0b8bd1b6 upstream. If port->mapbase = NULL in serial8250_request_std_resource() , it need return a error code instead of 0. If uart_set_info() fail to request new regions by serial8250_request_std_resource() but the return value of serial8250_request_std_resource() is 0, The system incorrectly considers that the resource application is successful and does not attempt to restore the old setting. A null pointer reference is triggered when the port resource is later invoked. Signed-off-by: Yi Yang Cc: stable Link: https://lore.kernel.org/r/20220628083515.64138-1-yiyang13@huawei.com Signed-off-by: Greg Kroah-Hartman commit 89c3c9dd7e0331d4e2529e91f273bc31e3c04f33 Author: Mario Limonciello Date: Wed Jul 13 12:53:46 2022 -0500 ACPI: CPPC: Fix enabling CPPC on AMD systems with shared memory commit fbd74d16890b9f5d08ea69b5282b123c894f8860 upstream. When commit 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") was introduced, we found collateral damage that a number of AMD systems that supported CPPC but didn't advertise support in _OSC stopped having a functional amd-pstate driver. The _OSC was only enforced on Intel systems at that time. This was fixed for the MSR based designs by commit 8b356e536e69f ("ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supported") but some shared memory based designs also support CPPC but haven't advertised support in the _OSC. Add support for those designs as well by hardcoding the list of systems. Fixes: 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") Fixes: 8b356e536e69f ("ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supported") Link: https://lore.kernel.org/all/3559249.JlDtxWtqDm@natalenko.name/ Cc: 5.18+ # 5.18+ Reported-and-tested-by: Oleksandr Natalenko Signed-off-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ceb7a7e7ab0640f6f75d7eaa7611aabed7981c35 Author: Tony Krowiak Date: Wed Jul 6 17:43:29 2022 -0400 s390/ap: fix error handling in __verify_queue_reservations() commit 2f23256c0ea20627c91ea2d468cda945f68c3395 upstream. The AP bus's __verify_queue_reservations function increments the ref count for the device driver passed in as a parameter, but fails to decrement it before returning control to the caller. This will prevents any subsequent removal of the module. Signed-off-by: Tony Krowiak Reported-by: Tony Krowiak Reviewed-by: Harald Freudenberger Fixes: 4f8206b88286 ("s390/ap: driver callback to indicate resource in use") Link: https://lore.kernel.org/r/20220706222619.602094-1-akrowiak@linux.ibm.com Cc: stable@vger.kernel.org [agordeev@linux.ibm.com fixed description, added Fixes and Link] Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman commit 14d2cc21ca622310babf373e3a8f0b40acfe8265 Author: Yangxi Xiang Date: Tue Jun 28 17:33:22 2022 +0800 vt: fix memory overlapping when deleting chars in the buffer commit 39cdb68c64d84e71a4a717000b6e5de208ee60cc upstream. A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew. Fixes: 81732c3b2fed ("tty vt: Fix line garbage in virtual console on command line edition") Cc: stable Signed-off-by: Yangxi Xiang Link: https://lore.kernel.org/r/20220628093322.5688-1-xyangxi5@gmail.com Signed-off-by: Greg Kroah-Hartman commit f6c04bde97baf7a0a62a7b4954b223db404f9757 Author: Hans de Goede Date: Wed Jul 13 23:11:01 2022 +0200 ACPI: video: Fix acpi_video_handles_brightness_key_presses() [ Upstream commit 5ad26161a371e4aa2d2553286f0cac580987a493 ] Commit 3a0cf7ab8df3 ("ACPI: video: Change how we determine if brightness key-presses are handled") made acpi_video_handles_brightness_key_presses() report false when none of the ACPI Video Devices support backlight control. But it turns out that at least on a Dell Inspiron N4010 there is no ACPI backlight control, yet brightness hotkeys are still reported through the ACPI Video Bus; and since acpi_video_handles_brightness_key_presses() now returns false, brightness keypresses are now reported twice. To fix this rename the has_backlight flag to may_report_brightness_keys and also set it the first time a brightness key press event is received. Depending on the delivery of the other ACPI (WMI) event vs the ACPI Video Bus event this means that the first brightness key press might still get reported twice, but all further keypresses will be filtered as before. Note that this relies on other drivers reporting brightness key events calling acpi_video_handles_brightness_key_presses() when delivering the events (rather then once during driver probe). This is already required and documented in include/acpi/video.h: /* * Note: The value returned by acpi_video_handles_brightness_key_presses() * may change over time and should not be cached. */ Fixes: 3a0cf7ab8df3 ("ACPI: video: Change how we determine if brightness key-presses are handled") Link: https://lore.kernel.org/regressions/CALF=6jEe5G8+r1Wo0vvz4GjNQQhdkLT5p8uCHn6ZXhg4nsOWow@mail.gmail.com/ Reported-and-tested-by: Ben Greening Signed-off-by: Hans de Goede Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20220713211101.85547-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit db738f76b03beaccfe9de35d838d9ec825226478 Author: Linus Torvalds Date: Wed Jul 6 12:20:59 2022 -0700 signal handling: don't use BUG_ON() for debugging [ Upstream commit a382f8fee42ca10c9bfce0d2352d4153f931f5dc ] These are indeed "should not happen" situations, but it turns out recent changes made the 'task_is_stopped_or_trace()' case trigger (fix for that exists, is pending more testing), and the BUG_ON() makes it unnecessarily hard to actually debug for no good reason. It's been that way for a long time, but let's make it clear: BUG_ON() is not good for debugging, and should never be used in situations where you could just say "this shouldn't happen, but we can continue". Use WARN_ON_ONCE() instead to make sure it gets logged, and then just continue running. Instead of making the system basically unusuable because you crashed the machine while potentially holding some very core locks (eg this function is commonly called while holding 'tasklist_lock' for writing). Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 700364130bfa1689baa9d4385a92a7f122093d1e Author: Jason A. Donenfeld Date: Thu Jul 7 02:31:54 2022 +0200 wireguard: selftests: always call kernel makefile [ Upstream commit 1a087eec257154e26a81a7a0a15380d7a2431765 ] These selftests are used for much more extensive changes than just the wireguard source files. So always call the kernel's build file, which will do something or nothing after checking the whole tree, per usual. Signed-off-by: Jason A. Donenfeld Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d2f02e532200add4dba5ff47d44c218bb9d214ad Author: Jason A. Donenfeld Date: Thu Jul 7 02:31:52 2022 +0200 wireguard: selftests: set fake real time in init [ Upstream commit 829be057dbc1e71383b8d7de8edb31dcf07b4aa0 ] Not all platforms have an RTC, and rather than trying to force one into each, it's much easier to just set a fixed time. This is necessary because WireGuard's latest handshakes parameter is returned in wallclock time, and if the system time isn't set, and the system is really fast, then this returns 0, which trips the test. Turning this on requires setting CONFIG_COMPAT_32BIT_TIME=y, as musl doesn't support settimeofday without it. Signed-off-by: Jason A. Donenfeld Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3d8b35387e01cab217dc4691a6f770cbb6ed852c Author: Keith Busch Date: Wed Jul 6 10:05:05 2022 -0700 nvme: use struct group for generic command dwords [ Upstream commit 5c629dc9609dc43492a7bc8060cc6120875bf096 ] This will allow the trace event to know the full size of the data intended to be copied and silence read overflow checks. Reported-by: John Garry Suggested-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 97f9cba7686e395669ffb2808c4a7b140bfdb5bb Author: Keith Busch Date: Tue Jul 5 10:21:02 2022 -0700 nvme-pci: phison e16 has bogus namespace ids [ Upstream commit 73029c9b23cf1213e5f54c2b59efce08665199e7 ] Add the quirk. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216049 Reported-by: Chris Egolf Signed-off-by: Keith Busch Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 7bd54d31155e3da12eb357f4a56d2612c942c4db Author: Egor Vorontsov Date: Mon Jun 27 13:00:35 2022 +0300 ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0) [ Upstream commit 2307a0e1ca0b5c1337b37ac6302f96e017ebac3c ] The patch applies the same quirks used for SC-01 at firmware v1.1.0 to the ones running v1.0.0, with respect to hard-coded sample rates. I got two more units and successfully tested the patch series with both firmwares. The support is now complete (not accounting ASIO). Signed-off-by: Egor Vorontsov Link: https://lore.kernel.org/r/20220627100041.2861494-2-sdoregor@sdore.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit da7fdaadc13506a902667fb98cfb584d70b10e0a Author: Egor Vorontsov Date: Mon Jun 27 13:00:34 2022 +0300 ALSA: usb-audio: Add quirk for Fiero SC-01 [ Upstream commit 4fb7c24f69c48fdc02ea7858dbd5a60ff08bf7e5 ] Fiero SC-01 is a USB sound card with two mono inputs and a single stereo output. The inputs are composed into a single stereo stream. The device uses a vendor-provided driver on Windows and does not work at all without it. The driver mostly provides ASIO functionality, but also alters the way the sound card is queried for sample rates and clocks. ALSA queries those failing with an EPIPE (same as Windows 10 does). Presumably, the vendor-provided driver does not query it at all, simply matching by VID:PID. Thus, I consider this a buggy firmware and adhere to a set of fixed endpoint quirks instead. The soundcard has an internal clock. Implicit feedback mode is required for the playback. I have updated my device to v1.1.0 from a Windows 10 VM using a vendor- provided binary prior to the development, hoping for it to just begin working. The device provides no obvious way to downgrade the firmware, and regardless, there's no binary available for v1.0.0 anyway. Thus, I will be getting another unit to extend the patch with support for that. Expected to be a simple copy-paste of the existing one, though. There were no previous reports of that device in context of Linux anywhere. Other issues have been reported though, but that's out of the scope. Signed-off-by: Egor Vorontsov Link: https://lore.kernel.org/r/20220627100041.2861494-1-sdoregor@sdore.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9b47d6dfaecb60c490a7c43d896e101e85490257 Author: John Veness Date: Fri Jun 24 15:07:57 2022 +0100 ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices [ Upstream commit 6e2c9105e0b743c92a157389d40f00b81bdd09fe ] Treat the claimed 96kHz 1ch in the descriptors as 48kHz 2ch, so that the audio stream doesn't sound mono. Also fix initial stream alignment, so that left and right channels are in the correct order. Signed-off-by: John Veness Link: https://lore.kernel.org/r/20220624140757.28758-1-john-linux@pelago.org.uk Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 449f51b5d6e10eeda2a59d1319334e5853e7cb3a Author: Srinivas Neeli Date: Thu Jun 9 13:54:32 2022 +0530 Revert "can: xilinx_can: Limit CANFD brp to 2" [ Upstream commit c6da4590fe819dfe28a4f8037a8dc1e056542fb4 ] This reverts commit 05ca14fdb6fe65614e0652d03e44b02748d25af7. On early silicon engineering samples observed bit shrinking issue when we use brp as 1. Hence updated brp_min as 2. As in production silicon this issue is fixed, so reverting the patch. Link: https://lore.kernel.org/all/20220609082433.1191060-2-srinivas.neeli@xilinx.com Signed-off-by: Srinivas Neeli Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 2764762d0d6a2fab76f3f68b5298e4ab634053b7 Author: Gabriel Fernandez Date: Fri Jun 24 11:27:13 2022 +0200 ARM: dts: stm32: use the correct clock source for CEC on stm32mp151 [ Upstream commit 78ece8cce1ba0c3f3e5a7c6c1b914b3794f04c44 ] The peripheral clock of CEC is not LSE but CEC. Signed-off-by: Gabriel Fernandez Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit bd77b8298f851916f4c9fd555dbc65298a4750b6 Author: Linus Walleij Date: Sun Jun 26 09:43:15 2022 +0200 soc: ixp4xx/npe: Fix unused match warning [ Upstream commit 620f83b8326ce9706b1118334f0257ae028ce045 ] The kernel test robot found this inconsistency: drivers/soc/ixp4xx/ixp4xx-npe.c:737:34: warning: 'ixp4xx_npe_of_match' defined but not used [-Wunused-const-variable=] 737 | static const struct of_device_id ixp4xx_npe_of_match[] = { This is because the match is enclosed in the of_match_ptr() which compiles into NULL when OF is disabled and this is unnecessary. Fix it by dropping of_match_ptr() around the match. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220626074315.61209-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 2334bdfc2da469c9807767002a2831274b82c39a Author: Juergen Gross Date: Thu Jun 30 09:14:40 2022 +0200 x86: Clear .brk area at early boot [ Upstream commit 38fa5479b41376dc9d7f57e71c83514285a25ca0 ] The .brk section has the same properties as .bss: it is an alloc-only section and should be cleared before being used. Not doing so is especially a problem for Xen PV guests, as the hypervisor will validate page tables (check for writable page tables and hypervisor private bits) before accepting them to be used. Make sure .brk is initially zero by letting clear_bss() clear the brk area, too. Signed-off-by: Juergen Gross Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220630071441.28576-3-jgross@suse.com Signed-off-by: Sasha Levin commit 4dc6fad52c5ca66ded0c5c00b2a25dc6c1e6a793 Author: Jacky Bai Date: Mon Jun 13 11:18:54 2022 +0800 pinctrl: imx: Add the zero base flag for imx93 [ Upstream commit fbc24ebc65507feb9728dc38197f90486148dda0 ] On i.MX93, the pin mux reg offset is from 0x0, so need to add the 'ZERO_OFFSET_VALID' flag to make sure the pin at mux offset 0 can be found. Signed-off-by: Jacky Bai Link: https://lore.kernel.org/r/20220613031854.1571357-1-ping.bai@nxp.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d6ef5aca6fe46c48f4d3b3c53d1fd9b5b86c07b4 Author: Stafford Horne Date: Wed Jun 15 08:54:26 2022 +0900 irqchip: or1k-pic: Undefine mask_ack for level triggered hardware [ Upstream commit 8520501346ed8d1c4a6dfa751cb57328a9c843f1 ] The mask_ack operation clears the interrupt by writing to the PICSR register. This we don't want for level triggered interrupt because it does not actually clear the interrupt on the source hardware. This was causing issues in qemu with multi core setups where interrupts would continue to fire even though they had been cleared in PICSR. Just remove the mask_ack operation. Acked-by: Marc Zyngier Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 7f97af49f6013c684192f63720d6fa81c974874f Author: Charles Keepax Date: Thu Jun 23 11:51:19 2022 +0100 ASoC: madera: Fix event generation for rate controls [ Upstream commit 980555e95f7cabdc9c80a07107622b097ba23703 ] madera_adsp_rate_put always returns zero regardless of if the control value was updated. This results in missing notifications to user-space of the control change. Update the handling to return 1 when the value is changed. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220623105120.1981154-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0303f460b85680f8d49ddfd9b7dbc5876e24f5c7 Author: Charles Keepax Date: Thu Jun 23 11:51:18 2022 +0100 ASoC: madera: Fix event generation for OUT1 demux [ Upstream commit e3cabbef3db8269207a6b8808f510137669f8deb ] madera_out1_demux_put returns the value of snd_soc_dapm_mux_update_power, which returns a 1 if a path was found for the kcontrol. This is obviously different to the expected return a 1 if the control was updated value. This results in spurious notifications to user-space. Update the handling to only return a 1 when the value is changed. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220623105120.1981154-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2308fdb5191ad292d626502a9c99ca7da8bf3b90 Author: Charles Keepax Date: Thu Jun 23 11:51:17 2022 +0100 ASoC: cs47l15: Fix event generation for low power mux control [ Upstream commit 7f103af4a10f375b9b346b4d0b730f6a66b8c451 ] cs47l15_in1_adc_put always returns zero regardless of if the control value was updated. This results in missing notifications to user-space of the control change. Update the handling to return 1 when the value is changed. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220623105120.1981154-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 14937a06ab710601906fcc71fe73fcd5f20e376c Author: Charles Keepax Date: Thu Jun 23 11:51:16 2022 +0100 ASoC: cs35l41: Add ASP TX3/4 source to register patch [ Upstream commit 46b0d050c8c7df6dfb2c376aaa149bf2cfc5ca3e ] The mixer controls for ASP TX3/4 are set to values that are not included in their enumeration control. This will cause spurious event notifications when the controls are first changed, as the register value changes whilst the actual visible enumeration value does not. Use the register patch to set them to a known value, zero, which equates to zero fill, thereby avoiding the spurious notifications. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220623105120.1981154-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ed5ddd50ffb5dbbb51ec4b525baf069991eebb4b Author: Charles Keepax Date: Thu Jun 23 11:51:15 2022 +0100 ASoC: dapm: Initialise kcontrol data for mux/demux controls [ Upstream commit 11d7a12f7f50baa5af9090b131c9b03af59503e7 ] DAPM keeps a copy of the current value of mux/demux controls, however this value is only initialised in the case of autodisable controls. This leads to false notification events when first modifying a DAPM kcontrol that has a non-zero default. Autodisable controls are left as they are, since they already initialise the value, and there would be more work required to support autodisable muxes where the first option isn't disabled and/or that isn't the default. Technically this issue could affect mixer/switch elements as well, although not on any of the devices I am currently running. There is also a little more work to do to address the issue there due to that side supporting stereo controls, so that has not been tackled in this patch. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220623105120.1981154-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7bb71133cae88d3003a3490b97864af76533072b Author: Shuming Fan Date: Tue Jun 21 17:07:19 2022 +0800 ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error [ Upstream commit 1df793d479bef546569fc2e409ff8bb3f0fb8e99 ] The initial settings will be written before the codec probe function. But, the rt711->component doesn't be assigned yet. If IO error happened during initial settings operations, it will cause the kernel panic. This patch changed component->dev to slave->dev to fix this issue. Signed-off-by: Shuming Fan Link: https://lore.kernel.org/r/20220621090719.30558-1-shumingf@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f3f5f2a9e2bbccc6f4e3a0d2e588a02703cdfd7f Author: Charles Keepax Date: Tue Jun 21 11:20:40 2022 +0100 ASoC: cs35l41: Correct some control names [ Upstream commit c6a5f22f9b4fd5f21414be690ce34046d9712f05 ] Various boolean controls on cs35l41 are missing the required "Switch" in the name, add these. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220621102041.1713504-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 83431e500b2c5d5c95712053c1cea2f462a4366e Author: Charles Keepax Date: Tue Jun 21 11:20:39 2022 +0100 ASoC: wm5110: Fix DRE control [ Upstream commit 0bc0ae9a5938d512fd5d44f11c9c04892dcf4961 ] The DRE controls on wm5110 should return a value of 1 if the DRE state is actually changed, update to fix this. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220621102041.1713504-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 89c2c0dd28250e1def6fdf37af311a02edb4d702 Author: Charles Keepax Date: Tue Jun 21 11:20:38 2022 +0100 ASoC: wm_adsp: Fix event for preloader [ Upstream commit 9896c029f0df628c6cb108253d09b1d61f1d4a88 ] The preloader controls on ADSP should return a value of 1 if the preloader value was changed, update to correct this. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20220621102041.1713504-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 03f97b638dd9a8eb8c7e63b243bcef12c99264a9 Author: Hans de Goede Date: Sun Jun 12 17:56:52 2022 +0200 ASoC: Intel: bytcr_wm5102: Fix GPIO related probe-ordering problem [ Upstream commit 4e07479eab8a044cc9542414ccb4aeb8eb033bde ] The "wlf,spkvdd-ena" GPIO needed by the bytcr_wm5102 driver is made available through a gpio-lookup table. This gpio-lookup table is registered by drivers/mfd/arizona-spi.c, which may get probed after the bytcr_wm5102 driver. If the gpio-lookup table has not registered yet then the gpiod_get() will return -ENOENT. Treat -ENOENT as -EPROBE_DEFER to still keep things working in this case. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220612155652.107310-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f3071f04cf125c1d4fb0698b524e1c030c1b0f17 Author: Mark Brown Date: Fri Jun 3 14:25:26 2022 +0200 ASoC: wcd938x: Fix event generation for some controls [ Upstream commit 10e7ff0047921e32b919ecee7be706dd33c107f8 ] Currently wcd938x_*_put() unconditionally report that the value of the control changed, resulting in spurious events being generated. Return 0 in that case instead as we should. There is still an issue in the compander control which is a bit more complex. Signed-off-by: Mark Brown Reported-by: kernel test robot Link: https://lore.kernel.org/r/20220603122526.3914942-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4d93ab0d2f6a82661d0bd9b79cc1a557f7a73353 Author: Mark Brown Date: Fri Jun 3 14:46:09 2022 +0200 ASoC: wcd9335: Fix spurious event generation [ Upstream commit a7786cbae4b2732815da98efa39df96746b5bd0d ] The slimbus mux put operation unconditionally reports a change in value which means that spurious events are generated. Fix this by exiting early in that case. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220603124609.4024666-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e58a32e25ef12810a4684ce31f5d48645fcedec5 Author: Yassine Oudjana Date: Mon Jun 6 19:22:26 2022 +0400 ASoC: wcd9335: Remove RX channel from old list before adding it to a new one [ Upstream commit be6dd72edb216f20fc80e426ece9fe9b8aabf033 ] Currently in slim_rx_mux_put, an RX channel gets added to a new list even if it is already in one. This can mess up links and make either it, the new list head, or both, get linked to the wrong entries. This can cause an entry to link to itself which in turn ends up making list_for_each_entry in other functions loop infinitely. To avoid issues, always remove the RX channel from any list it's in before adding it to a new list. Signed-off-by: Yassine Oudjana Link: https://lore.kernel.org/r/20220606152226.149164-1-y.oudjana@protonmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 79096060364c41b5627facc431c851f1367eb03e Author: Peter Ujfalusi Date: Thu Jun 9 11:59:49 2022 +0300 ASoC: SOF: Intel: hda-loader: Clarify the cl_dsp_init() flow [ Upstream commit bbfef046c6613404c01aeb9e9928bebb78dd327a ] Update the comment for the cl_dsp_init() to clarify what is done by the function and use the chip->init_core_mask instead of BIT(0) when unstalling/running the init core. Complements: 2a68ff846164 ("ASoC: SOF: Intel: hda: Revisit IMR boot sequence") Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20220609085949.29062-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 71d199d622c4c9bdf864a9b1f26218efe85613e1 Author: Peter Ujfalusi Date: Thu Jun 9 11:59:48 2022 +0300 ASoC: SOF: Intel: hda-loader: Make sure that the fw load sequence is followed [ Upstream commit c31691e0d126ec5d60d2b6b03f699c11b613b219 ] The hda_dsp_enable_core() is powering up _and_ unstall the core in one call while the first step of the firmware loading must not unstall the core. The core can be unstalled only after the set cpb_cfp and the configuration of the IPC register for the ROM_CONTROL message. Complements: 2a68ff846164 ("ASoC: SOF: Intel: hda: Revisit IMR boot sequence") Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20220609085949.29062-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d275601a18cf0d98e57acf370221566477f95eb5 Author: Peter Ujfalusi Date: Thu Jun 9 11:59:47 2022 +0300 ASoC: SOF: Intel: hda-dsp: Expose hda_dsp_core_power_up() [ Upstream commit 08f8a93198e300dff9649bbae424cd805d313326 ] The hda_dsp_core_power_up() needs to be exposed so that it can be used in hda-loader.c to correct the boot flow. The first step must not unstall the core, it should only power up the core(s). Add sanity check for the core_mask while exposing it to be safe. Complements: 2a68ff846164 ("ASoC: SOF: Intel: hda: Revisit IMR boot sequence") Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20220609085949.29062-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 11e35a6c6607216eeaf047ba85251f902f622a72 Author: Pierre-Louis Bossart Date: Mon Jun 6 15:37:51 2022 -0500 ASoC: codecs: rt700/rt711/rt711-sdca: initialize workqueues in probe [ Upstream commit ba98d7d8b60ba410aa03834f6aa48fd3b2e68478 ] The workqueues are initialized in the io_init functions, which isn't quite right. In some tests, this leads to warnings throw from __queue_delayed_work() WARN_ON_FUNCTION_MISMATCH(timer->function, delayed_work_timer_fn); Move all the initializations to the probe functions. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20220606203752.144159-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1d75b73ec6d6b705cca528b36d8315e43e8d7fa5 Author: Pierre-Louis Bossart Date: Mon Jun 6 15:37:50 2022 -0500 ASoC: rt7*-sdw: harden jack_detect_handler [ Upstream commit 0484271ab0ce50649329fa9dc23c50853c5b26a4 ] Realtek headset codec drivers typically check if the card is instantiated before proceeding with the jack detection. The rt700, rt711 and rt711-sdca are however missing a check on the card pointer, which can lead to NULL dereferences encountered in driver bind/unbind tests. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20220606203752.144159-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 517fa7405a48c702591887bdf378963b0e1e1328 Author: Pierre-Louis Bossart Date: Mon Jun 6 15:37:49 2022 -0500 ASoC: rt711: fix calibrate mutex initialization [ Upstream commit 08bb5dc6ce02374169213cea772b1c297eaf32d5 ] Follow the same flow as rt711-sdca and initialize all mutexes at probe time. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20220606203752.144159-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 09bca0ffc95c50369f1345d80ecfaca51864126f Author: Pierre-Louis Bossart Date: Mon Jun 6 15:37:48 2022 -0500 ASoC: Intel: sof_sdw: handle errors on card registration [ Upstream commit fe154c4ff376bc31041c6441958a08243df09c99 ] If the card registration fails, typically because of deferred probes, the device properties added for headset codecs are not removed, which leads to kernel oopses in driver bind/unbind tests. We already clean-up the device properties when the card is removed, this code can be moved as a helper and called upon card registration errors. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20220606203752.144159-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f85a8e86015f2074a79d30b9425eb8b66eaacf60 Author: Pierre-Louis Bossart Date: Mon Jun 6 15:37:47 2022 -0500 ASoC: rt711-sdca-sdw: fix calibrate mutex initialization [ Upstream commit ed0a7fb29c9fd4f53eeb37d1fe2354df7a038047 ] In codec driver bind/unbind test, the following warning is thrown: DEBUG_LOCKS_WARN_ON(lock->magic != lock) ... [ 699.182495] rt711_sdca_jack_init+0x1b/0x1d0 [snd_soc_rt711_sdca] [ 699.182498] rt711_sdca_set_jack_detect+0x3b/0x90 [snd_soc_rt711_sdca] [ 699.182500] snd_soc_component_set_jack+0x24/0x50 [snd_soc_core] A quick check in the code shows that the 'calibrate_mutex' used by this driver are not initialized at probe time. Moving the initialization to the probe removes the issue. BugLink: https://github.com/thesofproject/linux/issues/3644 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20220606203752.144159-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f3a2c0631302613f41fd8f7ce9882c633d66b9a5 Author: Pierre-Louis Bossart Date: Mon Jun 6 15:37:46 2022 -0500 ASoC: Realtek/Maxim SoundWire codecs: disable pm_runtime on remove [ Upstream commit ac63716da3070f8cb6baaba3a058a0c7f22aeb5b ] When binding/unbinding codec drivers, the following warnings are thrown: [ 107.266879] rt715-sdca sdw:3:025d:0714:01: Unbalanced pm_runtime_enable! [ 306.879700] rt711-sdca sdw:0:025d:0711:01: Unbalanced pm_runtime_enable! Add a remove callback for all Realtek/Maxim SoundWire codecs and remove this warning. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20220606203752.144159-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e162a24f1dd06c0dcae71f2565c9f3da2827b98e Author: Haowen Bai Date: Thu Apr 21 10:26:59 2022 +0800 pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux() [ Upstream commit 84a85d3fef2e75b1fe9fc2af6f5267122555a1ed ] pdesc could be null but still dereference pdesc->name and it will lead to a null pointer access. So we move a null check before dereference. Signed-off-by: Haowen Bai Link: https://lore.kernel.org/r/1650508019-22554-1-git-send-email-baihaowen@meizu.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 55ad380852bcb7fe9b70935af0a7d2e8c51166af Author: Mark Brown Date: Sat Jun 4 11:52:46 2022 +0100 ASoC: ops: Fix off by one in range control validation [ Upstream commit 5871321fb4558c55bf9567052b618ff0be6b975e ] We currently report that range controls accept a range of 0..(max-min) but accept writes in the range 0..(max-min+1). Remove that extra +1. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220604105246.4055214-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f22ddc8a5278d7fb6369a0aeb0d8775a0aefaaee Author: Jianglei Nie Date: Wed Jun 29 15:55:50 2022 +0800 net: sfp: fix memory leak in sfp_probe() [ Upstream commit 0a18d802d65cf662644fd1d369c86d84a5630652 ] sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When devm_add_action() fails, sfp is not freed, which leads to a memory leak. We should use devm_add_action_or_reset() instead of devm_add_action(). Signed-off-by: Jianglei Nie Reviewed-by: Russell King (Oracle) Link: https://lore.kernel.org/r/20220629075550.2152003-1-niejianglei2021@163.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a8ba4bd0f542a2bdf28751896ebe515e7117d0dc Author: Ruozhu Li Date: Thu Jun 23 14:45:39 2022 +0800 nvme: fix regression when disconnect a recovering ctrl [ Upstream commit f7f70f4aa09dc43d7455c060143e86a017c30548 ] We encountered a problem that the disconnect command hangs. After analyzing the log and stack, we found that the triggering process is as follows: CPU0 CPU1 nvme_rdma_error_recovery_work nvme_rdma_teardown_io_queues nvme_do_delete_ctrl nvme_stop_queues nvme_remove_namespaces --clear ctrl->namespaces nvme_start_queues --no ns in ctrl->namespaces nvme_ns_remove return(because ctrl is deleting) blk_freeze_queue blk_mq_freeze_queue_wait --wait for ns to unquiesce to clean infligt IO, hang forever This problem was not found in older kernels because we will flush err work in nvme_stop_ctrl before nvme_remove_namespaces.It does not seem to be modified for functional reasons, the patch can be revert to solve the problem. Revert commit 794a4cb3d2f7 ("nvme: remove the .stop_ctrl callout") Signed-off-by: Ruozhu Li Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 569d1c493070eca57425c1db1875157a37c452b7 Author: Sagi Grimberg Date: Sun Jun 26 12:24:51 2022 +0300 nvme-tcp: always fail a request when sending it failed [ Upstream commit 41d07df7de841bfbc32725ce21d933ad358f2844 ] queue stoppage and inflight requests cancellation is fully fenced from io_work and thus failing a request from this context. Hence we don't need to try to guess from the socket retcode if this failure is because the queue is about to be torn down or not. We are perfectly safe to just fail it, the request will not be cancelled later on. This solves possible very long shutdown delays when the users issues a 'nvme disconnect-all' Reported-by: Daniel Wagner Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e84a77bc836160b6b85bbc002465d5aaea307807 Author: Michael Walle Date: Mon Jun 27 19:06:43 2022 +0200 NFC: nxp-nci: don't print header length mismatch on i2c error [ Upstream commit 9577fc5fdc8b07b891709af6453545db405e24ad ] Don't print a misleading header length mismatch error if the i2c call returns an error. Instead just return the error code without any error message. Signed-off-by: Michael Walle Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3b2957fc09fe1ac7f07f40dd50dd5f93e3f3a7a2 Author: Hangyu Hua Date: Wed Jun 29 14:34:18 2022 +0800 net: tipc: fix possible refcount leak in tipc_sk_create() [ Upstream commit 00aff3590fc0a73bddd3b743863c14e76fd35c0c ] Free sk in case tipc_sk_insert() fails. Signed-off-by: Hangyu Hua Reviewed-by: Tung Nguyen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 07186778cf645cc79e6913a28dadf445cd3e2439 Author: Javier Martinez Canillas Date: Tue Jun 7 20:23:36 2022 +0200 fbdev: Disable sysfb device registration when removing conflicting FBs [ Upstream commit ee7a69aa38d87a3bbced7b8245c732c05ed0c6ec ] The platform devices registered by sysfb match with firmware-based DRM or fbdev drivers, that are used to have early graphics using a framebuffer provided by the system firmware. DRM or fbdev drivers later are probed and remove conflicting framebuffers, leading to these platform devices for generic drivers to be unregistered. But the current solution has a race, since the sysfb_init() function could be called after a DRM or fbdev driver is probed and request to unregister the devices for drivers with conflicting framebuffes. To prevent this, disable any future sysfb platform device registration by calling sysfb_disable(), if a driver requests to remove the conflicting framebuffers. Suggested-by: Daniel Vetter Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-4-javierm@redhat.com Signed-off-by: Sasha Levin commit 38e549484675b6eaf20bbae4bad1eb33452ab95e Author: Javier Martinez Canillas Date: Tue Jun 7 20:23:35 2022 +0200 firmware: sysfb: Add sysfb_disable() helper function [ Upstream commit bde376e9de3c0bc55eedc8956b0f114c05531595 ] This can be used by subsystems to unregister a platform device registered by sysfb and also to disable future platform device registration in sysfb. Suggested-by: Daniel Vetter Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-3-javierm@redhat.com Signed-off-by: Sasha Levin commit 6f36471e568f95d5440ba89412e5086f57baa1af Author: Javier Martinez Canillas Date: Tue Jun 7 20:23:34 2022 +0200 firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer [ Upstream commit 9e121040e54abef9ed5542e5fdfa87911cd96204 ] This function just returned 0 on success or an errno code on error, but it could be useful for sysfb_init() callers to have a pointer to the device. Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Vetter Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-2-javierm@redhat.com Signed-off-by: Sasha Levin commit 05b92733fd6cc44622b7869358aca46e004f0e27 Author: Kai-Heng Feng Date: Tue Jun 28 20:37:26 2022 +0800 platform/x86: hp-wmi: Ignore Sanitization Mode event [ Upstream commit 9ab762a84b8094540c18a170e5ddd6488632c456 ] After system resume the hp-wmi driver may complain: [ 702.620180] hp_wmi: Unknown event_id - 23 - 0x0 According to HP it means 'Sanitization Mode' and it's harmless to just ignore the event. Cc: Jorge Lopez Signed-off-by: Kai-Heng Feng Link: https://lore.kernel.org/r/20220628123726.250062-1-kai.heng.feng@canonical.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 2c27eb27e70f869e078d3179b3a12a527d33894f Author: Mark Pearson Date: Mon Jun 27 14:14:49 2022 -0400 platform/x86: thinkpad_acpi: do not use PSC mode on Intel platforms [ Upstream commit bce6243f767f7da88aa4674d5d678f9f156eaba9 ] PSC platform profile mode is only supported on Linux for AMD platforms. Some older Intel platforms (e.g T490) are advertising it's capability as Windows uses it - but on Linux we should only be using MMC profile for Intel systems. Add a check to prevent it being enabled incorrectly. Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20220627181449.3537-1-markpearson@lenovo.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 01453386fb9233ff274c60ff2ba0689e62cffb4a Author: Mark Pearson Date: Fri Jun 3 13:02:09 2022 -0400 platform/x86: thinkpad-acpi: profile capabilities as integer [ Upstream commit 42504af775361ca2330a2bfde496a5ebc5655c86 ] Currently the active mode (PSC/MMC) is stored in an enum and queried throughout the driver. Other driver changes will enumerate additional submodes that are relevant to be tracked, so instead track PSC/MMC in a single integer variable. Co-developed-by: Mario Limonciello Signed-off-by: Mario Limonciello Signed-off-by: Mark Pearson Link: https://lore.kernel.org/r/20220603170212.164963-1-markpearson@lenovo.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 4513018d0bd739097570d26a7760551cba3deb56 Author: Liang He Date: Sat Jun 18 10:25:45 2022 +0800 cpufreq: pmac32-cpufreq: Fix refcount leak bug [ Upstream commit ccd7567d4b6cf187fdfa55f003a9e461ee629e36 ] In pmac_cpufreq_init_MacRISC3(), we need to add corresponding of_node_put() for the three node pointers whose refcount have been incremented by of_find_node_by_name(). Signed-off-by: Liang He Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 811ebff1ed15ff5860ed753b5d5de46a458a974f Author: John Garry Date: Thu Jun 23 20:41:59 2022 +0800 scsi: hisi_sas: Limit max hw sectors for v3 HW [ Upstream commit fce54ed027577517df1e74b7d54dc2b1bd536887 ] If the controller is behind an IOMMU then the IOMMU IOVA caching range can affect performance, as discussed in [0]. Limit the max HW sectors to not exceed this limit. We need to hardcode the value until a proper DMA mapping API is available. [0] https://lore.kernel.org/linux-iommu/20210129092120.1482-1-thunder.leizhen@huawei.com/ Link: https://lore.kernel.org/r/1655988119-223714-1-git-send-email-john.garry@huawei.com Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 05dfa88e73c9fa9c495384534afbc0d2589b373e Author: Florian Westphal Date: Tue Jun 21 18:26:03 2022 +0200 netfilter: br_netfilter: do not skip all hooks with 0 priority [ Upstream commit c2577862eeb0be94f151f2f1fff662b028061b00 ] When br_netfilter module is loaded, skbs may be diverted to the ipv4/ipv6 hooks, just like as if we were routing. Unfortunately, bridge filter hooks with priority 0 may be skipped in this case. Example: 1. an nftables bridge ruleset is loaded, with a prerouting hook that has priority 0. 2. interface is added to the bridge. 3. no tcp packet is ever seen by the bridge prerouting hook. 4. flush the ruleset 5. load the bridge ruleset again. 6. tcp packets are processed as expected. After 1) the only registered hook is the bridge prerouting hook, but its not called yet because the bridge hasn't been brought up yet. After 2), hook order is: 0 br_nf_pre_routing // br_netfilter internal hook 0 chain bridge f prerouting // nftables bridge ruleset The packet is diverted to br_nf_pre_routing. If call-iptables is off, the nftables bridge ruleset is called as expected. But if its enabled, br_nf_hook_thresh() will skip it because it assumes that all 0-priority hooks had been called previously in bridge context. To avoid this, check for the br_nf_pre_routing hook itself, we need to resume directly after it, even if this hook has a priority of 0. Unfortunately, this still results in different packet flow. With this fix, the eval order after in 3) is: 1. br_nf_pre_routing 2. ip(6)tables (if enabled) 3. nftables bridge but after 5 its the much saner: 1. nftables bridge 2. br_nf_pre_routing 3. ip(6)tables (if enabled) Unfortunately I don't see a solution here: It would be possible to move br_nf_pre_routing to a higher priority so that it will be called later in the pipeline, but this also impacts ebtables evaluation order, and would still result in this very ordering problem for all nftables-bridge hooks with the same priority as the br_nf_pre_routing one. Searching back through the git history I don't think this has ever behaved in any other way, hence, no fixes-tag. Reported-by: Radim Hrazdil Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0016d5d46d7440729a3132f61a8da3bf7f84e2ba Author: Florian Westphal Date: Wed Jun 22 16:43:57 2022 +0200 netfilter: nf_tables: avoid skb access on nf_stolen [ Upstream commit e34b9ed96ce3b06c79bf884009b16961ca478f87 ] When verdict is NF_STOLEN, the skb might have been freed. When tracing is enabled, this can result in a use-after-free: 1. access to skb->nf_trace 2. access to skb->mark 3. computation of trace id 4. dump of packet payload To avoid 1, keep a cached copy of skb->nf_trace in the trace state struct. Refresh this copy whenever verdict is != STOLEN. Avoid 2 by skipping skb->mark access if verdict is STOLEN. 3 is avoided by precomputing the trace id. Only dump the packet when verdict is not "STOLEN". Reported-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 387c23776010b6f6dbdf53ca267e34c092f23c58 Author: Stephan Gerhold Date: Tue Jun 21 13:06:21 2022 +0200 virtio_mmio: Restore guest page size on resume [ Upstream commit e0c2ce8217955537dd5434baeba061f209797119 ] Virtio devices might lose their state when the VMM is restarted after a suspend to disk (hibernation) cycle. This means that the guest page size register must be restored for the virtio_mmio legacy interface, since otherwise the virtio queues are not functional. This is particularly problematic for QEMU that currently still defaults to using the legacy interface for virtio_mmio. Write the guest page size register again in virtio_mmio_restore() to make legacy virtio_mmio devices work correctly after hibernation. Signed-off-by: Stephan Gerhold Message-Id: <20220621110621.3638025-3-stephan.gerhold@kernkonzept.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 0723688d0c539d97a7a5bb1ebae907907cf0d19b Author: Stephan Gerhold Date: Tue Jun 21 13:06:20 2022 +0200 virtio_mmio: Add missing PM calls to freeze/restore [ Upstream commit ed7ac37fde33ccd84e4bd2b9363c191f925364c7 ] Most virtio drivers provide freeze/restore callbacks to finish up device usage before suspend and to reinitialize the virtio device after resume. However, these callbacks are currently only called when using virtio_pci. virtio_mmio does not have any PM ops defined. This causes problems for example after suspend to disk (hibernation), since the virtio devices might lose their state after the VMM is restarted. Calling virtio_device_freeze()/restore() ensures that the virtio devices are re-initialized correctly. Fix this by implementing the dev_pm_ops for virtio_mmio, similar to virtio_pci_common. Signed-off-by: Stephan Gerhold Message-Id: <20220621110621.3638025-2-stephan.gerhold@kernkonzept.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 03303d4d9f99139ca69b3a49e1302caaf906cd2e Author: Gayatri Kammela Date: Tue Jun 14 17:27:51 2022 -0700 platform/x86: intel/pmc: Add Alder Lake N support to PMC core driver [ Upstream commit d63eae6747eb8b3192e89712f6553c6aa162f872 ] Add Alder Lake N (ADL-N) to the list of the platforms that Intel's PMC core driver supports. Alder Lake N reuses all the TigerLake PCH IPs. Cc: Srinivas Pandruvada Cc: Andy Shevchenko Cc: David E. Box Signed-off-by: Gayatri Kammela Reviewed-by: Rajneesh Bhardwaj Link: https://lore.kernel.org/r/20220615002751.3371730-1-gayatri.kammela@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit fbfa91978c0be7d92ee39e77a71dbe0b4814ef9f Author: Parav Pandit Date: Mon Jun 13 22:52:23 2022 +0300 vduse: Tie vduse mgmtdev and its device [ Upstream commit 0e0348ac3f0a6e6606f1aa5acb1803ada913aa3d ] vduse devices are not backed by any real devices such as PCI. Hence it doesn't have any parent device linked to it. Kernel driver model in [1] suggests to avoid an empty device release callback. Hence tie the mgmtdevice object's life cycle to an allocate dummy struct device instead of static one. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/core-api/kobject.rst?h=v5.18-rc7#n284 Signed-off-by: Parav Pandit Message-Id: <20220613195223.473966-1-parav@nvidia.com> Signed-off-by: Michael S. Tsirkin Reviewed-by: Xie Yongji Acked-by: Jason Wang Signed-off-by: Sasha Levin commit 8a53aed793fb799d2c6f519c389ea84963d5c807 Author: Eli Cohen Date: Mon Jun 13 10:59:58 2022 +0300 vdpa/mlx5: Initialize CVQ vringh only once [ Upstream commit ace9252446ec615cd79a5f77d90edb25c0b9d024 ] Currently, CVQ vringh is initialized inside setup_virtqueues() which is called every time a memory update is done. This is undesirable since it resets all the context of the vring, including the available and used indices. Move the initialization to mlx5_vdpa_set_status() when VIRTIO_CONFIG_S_DRIVER_OK is set. Signed-off-by: Eli Cohen Message-Id: <20220613075958.511064-2-elic@nvidia.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Acked-by: Eugenio Pérez Signed-off-by: Sasha Levin commit 99d1c36bddd93919072b5a51a89297bbb5ad6a6f Author: Nathan Lynch Date: Thu Jun 23 13:25:09 2022 -0500 powerpc/xive/spapr: correct bitmap allocation size [ Upstream commit 19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe ] kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency. Signed-off-by: Nathan Lynch Reviewed-by: Cédric Le Goater Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220623182509.3985625-1-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit 8e2b1b8402efdf1a2fd8df71cbe6c6c07551b774 Author: Namjae Jeon Date: Thu Jun 2 10:07:38 2022 +0900 ksmbd: use SOCK_NONBLOCK type for kernel_accept() [ Upstream commit fe0fde09e1cb83effcf8fafa372533f438d93a1a ] I found that normally it is O_NONBLOCK but there are different value for some arch. /include/linux/net.h: #ifndef SOCK_NONBLOCK #define SOCK_NONBLOCK O_NONBLOCK #endif /arch/alpha/include/asm/socket.h: #define SOCK_NONBLOCK 0x40000000 Use SOCK_NONBLOCK instead of O_NONBLOCK for kernel_accept(). Suggested-by: David Howells Signed-off-by: Namjae Jeon Reviewed-by: Hyunchul Lee Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 94c8cc503bec42e3d580d45716843ef9bcfe103a Author: Israel Rukshin Date: Thu Jul 14 12:42:10 2022 +0000 nvme: fix block device naming collision [ Upstream commit 6961b5e02876b3b47f030a1f1ee8fd3e631ac270 ] The issue exists when multipath is enabled and the namespace is shared, but all the other controller checks at nvme_is_unique_nsid() are false. The reason for this issue is that nvme_is_unique_nsid() returns false when is called from nvme_mpath_alloc_disk() due to an uninitialized value of head->shared. The patch fixes it by setting head->shared before nvme_mpath_alloc_disk() is called. Fixes: 5974ea7ce0f9 ("nvme: allow duplicate NSIDs for private namespaces") Signed-off-by: Israel Rukshin Reviewed-by: Keith Busch Reviewed-by: Max Gurtovoy Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 799dcbf4d943401eb91c210e79d1f9d2e535ebfa Author: Bjorn Andersson Date: Fri Jul 8 17:00:27 2022 -0700 scsi: ufs: core: Drop loglevel of WriteBoost message [ Upstream commit 2ae57c995003a7840cb6b5ec5f0c06193695321b ] Commit '3b5f3c0d0548 ("scsi: ufs: core: Tidy up WB configuration code")' changed the log level of the write boost enable/disable notification from debug to info. This results in a lot of noise in the kernel log during normal operation. Drop it back to debug level to avoid this. Link: https://lore.kernel.org/r/20220709000027.3929970-1-bjorn.andersson@linaro.org Fixes: 3b5f3c0d0548 ("scsi: ufs: core: Tidy up WB configuration code") Reviewed-by: Alim Akhtar Acked-by: Bean Huo Signed-off-by: Bjorn Andersson Signed-off-by: Martin K. Petersen