summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-07-27drm/msm/dp: Initialize the INTF_CONFIG registerBjorn Andersson
Some bootloaders set the widebus enable bit in the INTF_CONFIG register, but configuration of widebus isn't yet supported ensure that the register has a known value, with widebus disabled. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210722024434.3313167-1-bjorn.andersson@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm/dp: use dp_ctrl_off_link_stream during PHY compliance test runKuogee Hsieh
DP cable should always connect to DPU during the entire PHY compliance testing run. Since DP PHY compliance test is executed at irq_hpd event context, dp_ctrl_off_link_stream() should be used instead of dp_ctrl_off(). dp_ctrl_off() is used for unplug event which is triggered when DP cable is dis connected. Changes in V2: -- add fixes statement Fixes: f21c8a276c2d ("drm/msm/dp: handle irq_hpd with sink_count = 0 correctly") Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1626191647-13901-2-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm: Fix display fault handlingRob Clark
It turns out that when the display is enabled by the bootloader, we can get some transient iommu faults from the display. Which doesn't go over too well when we install a fault handler that is gpu specific. To avoid this, defer installing the fault handler until we get around to setting up per-process pgtables (which is adreno_smmu specific). The arm-smmu fallback error reporting is sufficient for reporting display related faults (and in fact was all we had prior to f8f934c180f629bb927a04fd90d) Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reported-by: Yassine Oudjana <y.oudjana@protonmail.com> Fixes: 2a574cc05d38 ("drm/msm: Improve the a6xx page fault handler") Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Yassine Oudjana <y.oudjana@protonmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210707180113.840741-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27drm/msm/dpu: Fix sm8250_mdp register lengthRobert Foss
The downstream dts lists this value as 0x494, and not 0x45c. Fixes: af776a3e1c30 ("drm/msm/dpu: add SM8250 to hw catalog") Signed-off-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Link: https://lore.kernel.org/r/20210628085033.9905-1-robert.foss@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-07-27virt: acrn: Do hcall_destroy_vm() before resource releaseShuo Liu
The ACRN hypervisor has scenarios which could run a real-time guest VM. The real-time guest VM occupies dedicated CPU cores, be assigned with dedicated PCI devices. It can run without the Service VM after boot up. hcall_destroy_vm() returns failure when a real-time guest VM refuses. The clearing of flag ACRN_VM_FLAG_DESTROYED causes some kernel resource double-freed in a later acrn_vm_destroy(). Do hcall_destroy_vm() before resource release to drop this chance to destroy the VM if hypercall fails. Fixes: 9c5137aedd11 ("virt: acrn: Introduce VM management interfaces") Cc: stable <stable@vger.kernel.org> Signed-off-by: Shuo Liu <shuo.a.liu@intel.com> Signed-off-by: Fei Li <fei1.li@intel.com> Link: https://lore.kernel.org/r/20210722062736.15050-1-fei1.li@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: otg-fsm: Fix hrtimer list corruptionDmitry Osipenko
The HNP work can be re-scheduled while it's still in-fly. This results in re-initialization of the busy work, resetting the hrtimer's list node of the work and crashing kernel with null dereference within kernel/timer once work's timer is expired. It's very easy to trigger this problem by re-plugging USB cable quickly. Initialize HNP work only once to fix this trouble. Unable to handle kernel NULL pointer dereference at virtual address 00000126) ... PC is at __run_timers.part.0+0x150/0x228 LR is at __next_timer_interrupt+0x51/0x9c ... (__run_timers.part.0) from [<c0187a2b>] (run_timer_softirq+0x2f/0x50) (run_timer_softirq) from [<c01013ad>] (__do_softirq+0xd5/0x2f0) (__do_softirq) from [<c012589b>] (irq_exit+0xab/0xb8) (irq_exit) from [<c0170341>] (handle_domain_irq+0x45/0x60) (handle_domain_irq) from [<c04c4a43>] (gic_handle_irq+0x6b/0x7c) (gic_handle_irq) from [<c0100b65>] (__irq_svc+0x65/0xac) Cc: stable@vger.kernel.org Acked-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210717182134.30262-6-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: host: ohci-at91: suspend/resume ports after/before OHCI accessesClaudiu Beznea
On SAMA7G5 suspending ports will cut the access to OHCI registers and any subsequent access to them will lead to CPU being blocked trying to access that memory. Same thing happens on resume: if OHCI memory is accessed before resuming ports the CPU will block on that access. The OCHI memory is accessed on suspend/resume though ohci_suspend()/ohci_resume(). Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210721132905.1970713-1-claudiu.beznea@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: musb: Fix suspend and resume issues for PHYs on I2C and SPITony Lindgren
As the USB PHYs typically are on I2C or SPI bus for the 2430 glue layer, we need configure the PHYs early for suspend. The musb glue layer we need to suspend only after musb_suspend() in suspend_late. Fixes: 62d472d8ad88 ("usb: musb: Add missing PM suspend and resume functions for 2430 glue") Reported-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20210727104134.52800-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: gadget: f_hid: added GET_IDLE and SET_IDLE handlersMaxim Devaev
The USB HID standard declares mandatory support for GET_IDLE and SET_IDLE requests for Boot Keyboard. Most hosts can handle their absence, but others like some old/strange UEFIs and BIOSes consider this a critical error and refuse to work with f_hid. This primitive implementation of saving and returning idle is sufficient to meet the requirements of the standard and these devices. Acked-by: Felipe Balbi <balbi@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Maxim Devaev <mdevaev@gmail.com> Link: https://lore.kernel.org/r/20210721180351.129450-1-mdevaev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: gadget: f_hid: fixed NULL pointer dereferencePhil Elwell
Disconnecting and reconnecting the USB cable can lead to crashes and a variety of kernel log spam. The problem was found and reproduced on the Raspberry Pi [1] and the original fix was created in Raspberry's own fork [2]. Link: https://github.com/raspberrypi/linux/issues/3870 [1] Link: https://github.com/raspberrypi/linux/commit/a6e47d5f4efbd2ea6a0b6565cd2f9b7bb217ded5 [2] Signed-off-by: Maxim Devaev <mdevaev@gmail.com> Signed-off-by: Phil Elwell <phil@raspberrypi.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210723155928.210019-1-mdevaev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27usb: gadget: remove leaked entry from udc driver listZhang Qilong
The usb_add_gadget_udc will add a new gadget to the udc class driver list. Not calling usb_del_gadget_udc in error branch will result in residual gadget entry in the udc driver list. We fix it by calling usb_del_gadget_udc to clean it when error return. Fixes: 48ba02b2e2b1 ("usb: gadget: add udc driver for max3420") Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20210727073142.84666-1-zhangqilong3@huawei.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27USB: usbtmc: Fix RCU stall warningQiang.zhang
rcu: INFO: rcu_preempt self-detected stall on CPU rcu: 1-...!: (2 ticks this GP) idle=d92/1/0x4000000000000000 softirq=25390/25392 fqs=3 (t=12164 jiffies g=31645 q=43226) rcu: rcu_preempt kthread starved for 12162 jiffies! g31645 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0 rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. rcu: RCU grace-period kthread stack dump: task:rcu_preempt state:R running task ........... usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: unknown status received: -71 usbtmc 3-1:0.0: usb_submit_urb failed: -19 The function usbtmc_interrupt() resubmits urbs when the error status of an urb is -EPROTO. In systems using the dummy_hcd usb controller this can result in endless interrupt loops when the usbtmc device is disconnected from the host system. Since host controller drivers already try to recover from transmission errors, there is no need to resubmit the urb or try other solutions to repair the error situation. In case of errors the INT pipe just stops to wait for further packets. Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation") Cc: stable@vger.kernel.org Reported-by: syzbot+e2eae5639e7203360018@syzkaller.appspotmail.com Signed-off-by: Qiang.zhang <qiang.zhang@windriver.com> Acked-by: Guido Kiener <guido.kiener@rohde-schwarz.com> Link: https://lore.kernel.org/r/20210723004334.458930-1-qiang.zhang@windriver.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27staging: mt7621-pci: avoid to re-disable clock for those pcies not in useSergio Paracuellos
Clock driver for this SoC is using some gates to properly enabling and disabling the access to peripherals. Those gates that are not in use are properly being automatically disabled by the kernel. Pcie driver is explicitly doing a 'clk_disable_unprepare' call for gates of those pcies that are not used. Since kernel has already disabled them, the following warnings appear: WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:952 clk_core_disable+0xe4/0x100 pcie2 already disabled Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0 #0 Stack : 81661680 80082d00 807c0000 00000004 00000000 80a20000 80860000 80792380 814503d4 80862e83 00000000 1431b70 81454360 00000000 00000000 80792380 81431a08 ffffefff fffffea 00000000 81431a14 0000007b 80868820 ffffffff 80792380 1431c70 803d7a24 00000009 807f3a74 00000001 815df810 00000018 0000000 80a20000 ... Call Trace: [<80007ed8>] show_stack+0x28/0xf0 [<80381e40>] dump_stack_lvl+0x60/0x80 [<8002cf90>] __warn+0xcc/0x140 [<8002d090>] warn_slowpath_fmt+0x8c/0xac [<803d7a24>] clk_core_disable+0xe4/0x100 [<803da468>] clk_disable+0x38/0x58 [<804cb730>] mt7621_pci_probe+0x980/0xa50 [<8041e624>] platform_probe+0x50/0xbc [<8041bfe4>] really_probe.part.0+0xa8/0x340 [<8041c3dc>] driver_probe_device+0x4c/0x154 [<8041cb88>] __driver_attach+0xb4/0x1b4 [<80419a38>] bus_for_each_dev+0x68/0xa4 [<8041b1e8>] bus_add_driver+0x134/0x214 [<8041d3bc>] driver_register+0x98/0x154 [<80001648>] do_one_initcall+0x50/0x1a8 [<808ea1fc>] kernel_init_freeable+0x270/0x30c [<806dd9dc>] kernel_init+0x20/0x110 [<80002d98>] ret_from_kernel_thread+0x14/0x1c WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:810 clk_core_unprepare+0xf4/0x194 pcie2 already unprepared Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 5.14.0 #0 Stack : 81661680 80082d00 807c0000 00000004 00000000 00000000 81431bc4 80a20000 80860000 80792380 814503d4 80862e83 00000000 00000001 81431b70 81454360 00000000 00000000 80792380 81431a08 ffffefff 00000000 ffffffea 00000000 81431a14 0000009b 80868820 ffffffff 80792380 00000001 81431c70 803d7764 00000009 807f3a74 00000001 815df810 00000018 8040b36c 00000000 80a20000 ... Call Trace: [<80007ed8>] show_stack+0x28/0xf0 [<80381e40>] dump_stack_lvl+0x60/0x80 [<8002cf90>] __warn+0xcc/0x140 [<8002d090>] warn_slowpath_fmt+0x8c/0xac [<803d7764>] clk_core_unprepare+0xf4/0x194 [<803d97c4>] clk_unprepare+0x30/0x48 [<804cb738>] mt7621_pci_probe+0x988/0xa50 [<8041e624>] platform_probe+0x50/0xbc [<8041bfe4>] really_probe.part.0+0xa8/0x340 [<8041c3dc>] driver_probe_device+0x4c/0x154 [<8041cb88>] __driver_attach+0xb4/0x1b4 [<80419a38>] bus_for_each_dev+0x68/0xa4 [<8041b1e8>] bus_add_driver+0x134/0x214 [<8041d3bc>] driver_register+0x98/0x154 [<80001648>] do_one_initcall+0x50/0x1a8 [<808ea1fc>] kernel_init_freeable+0x270/0x30c [<806dd9dc>] kernel_init+0x20/0x110 [<80002d98>] ret_from_kernel_thread+0x14/0x1c Avoid to explicitly disable already disabled pcie gates fixes the problem. Fixes: cc4e864a5ce4 ("staging: mt7621-pci: make use of kernel clock apis") Reported-by: DENG Qingfang <dqfext@gmail.com> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://lore.kernel.org/r/20210727054058.10612-1-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27staging: rtl8712: error handling refactoringPavel Skripkin
There was strange error handling logic in case of fw load failure. For some reason fw loader callback was doing clean up stuff when fw is not available. I don't see any reason behind doing this. Since this driver doesn't have EEPROM firmware let's just disconnect it in case of fw load failure. Doing clean up stuff in 2 different place which can run concurently is not good idea and syzbot found 2 bugs related to this strange approach. So, in this pacth I deleted all clean up code from fw callback and made a call to device_release_driver() under device_lock(parent) in case of fw load failure. This approach is more generic and it defend driver from UAF bugs, since all clean up code is moved to one place. Fixes: e02a3b945816 ("staging: rtl8712: fix memory leak in rtl871x_load_fw_cb") Fixes: 8c213fa59199 ("staging: r8712u: Use asynchronous firmware loading") Cc: stable <stable@vger.kernel.org> Reported-and-tested-by: syzbot+5872a520e0ce0a7c7230@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+cc699626e48a6ebaf295@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/d49ecc56e97c4df181d7bd4d240b031f315eacc3.1626895918.git.paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27staging: rtl8712: get rid of flush_scheduled_workPavel Skripkin
This patch is preparation for following patch for error handling refactoring. flush_scheduled_work() takes (wq_completion)events lock and it can lead to deadlock when r871xu_dev_remove() is called from workqueue. To avoid deadlock sutiation we can change flush_scheduled_work() call to flush_work() call for all possibly scheduled works in this driver, since next patch adds device_release_driver() in case of fw load failure. Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/6e028b4c457eeb7156c76c6ea3cdb3cb0207c7e1.1626895918.git.paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27nfc: s3fwrn5: fix undefined parameter values in dev_err()Tang Bin
In the function s3fwrn5_fw_download(), the 'ret' is not assigned, so the correct value should be given in dev_err function. Fixes: a0302ff5906a ("nfc: s3fwrn5: remove unnecessary label") Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-27dmaengine: uniphier-xdmac: Use readl_poll_timeout_atomic() in atomic stateKunihiko Hayashi
The function uniphier_xdmac_chan_stop() is only called in atomic state. Should use readl_poll_timeout_atomic() there instead of readl_poll_timeout(). Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 667b9251440b ("dmaengine: uniphier-xdmac: Add UniPhier external DMA controller driver") Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1627364852-28432-1-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2021-07-27drivers core: Fix oops when driver probe failsFilip Schauer
dma_range_map is freed to early, which might cause an oops when a driver probe fails. Call trace: is_free_buddy_page+0xe4/0x1d4 __free_pages+0x2c/0x88 dma_free_contiguous+0x64/0x80 dma_direct_free+0x38/0xb4 dma_free_attrs+0x88/0xa0 dmam_release+0x28/0x34 release_nodes+0x78/0x8c devres_release_all+0xa8/0x110 really_probe+0x118/0x2d0 __driver_probe_device+0xc8/0xe0 driver_probe_device+0x54/0xec __driver_attach+0xe0/0xf0 bus_for_each_dev+0x7c/0xc8 driver_attach+0x30/0x3c bus_add_driver+0x17c/0x1c4 driver_register+0xc0/0xf8 __platform_driver_register+0x34/0x40 ... This issue is introduced by commit d0243bbd5dd3 ("drivers core: Free dma_range_map when driver probe failed"). It frees dma_range_map before the call to devres_release_all, which is too early. The solution is to free dma_range_map only after devres_release_all. Fixes: d0243bbd5dd3 ("drivers core: Free dma_range_map when driver probe failed") Cc: stable <stable@vger.kernel.org> Signed-off-by: Filip Schauer <filip@mg6.at> Link: https://lore.kernel.org/r/20210727112311.GA7645@DESKTOP-E8BN1B0.localdomain Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-27ASoC: SOF: Intel: hda: enforce exclusion between HDaudio and SoundWirePierre-Louis Bossart
On some platforms with an external HDaudio codec, the DSDT reports the presence of SoundWire devices. Pin-mux restrictions and board reworks usually prevent coexistence between the two types of links, let's prevent unnecessary operations from starting. In the case of a single iDISP codec being detected, we still start the links even if no SoundWire machine configuration was detected, so that we can double-check what the hardware is and add the missing configuration if applicable. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <bard.liao@intel.com> Link: https://lore.kernel.org/r/20210726182855.179943-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-27ASoC: topology: Select SND_DYNAMIC_MINORSPeter Ujfalusi
The indexes of the devices are described within the topology file, it is a possibility that the topology encodes invalid indexes when DYNAMIC_MINORS is not enabled in kernel: #define SNDRV_MINOR_COMPRESS 2 /* 2 - 3 */ #define SNDRV_MINOR_HWDEP 4 /* 4 - 7 */ #define SNDRV_MINOR_RAWMIDI 8 /* 8 - 15 */ #define SNDRV_MINOR_PCM_PLAYBACK 16 /* 16 - 23 */ #define SNDRV_MINOR_PCM_CAPTURE 24 /* 24 - 31 */ If the topology assigns an index greater than 7 for PLAYBACK/CAPTURE PCM then there will be minor number collision. As an example: card0 creates a capture PCM with index 10 -> minor = 34 card1 creates compress device with index 0 -> minor = 34 Card1 will fail to instantiate because the minor for the compress stream is already taken. To avoid seemingly mysterious issues with card creation, select the DYNAMIC_MINORS when the topology is enabled. The other option would be to try to do out of bound index checks in case of DYNAMIC_MINOR is not enabled and do not even attempt to create the device with failing the topology load. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210726182142.179604-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-27Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann
Backmerging to get tree to v5.14-rc3, as requested by Daniel. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2021-07-27net: llc: fix skb_over_panicPavel Skripkin
Syzbot reported skb_over_panic() in llc_pdu_init_as_xid_cmd(). The problem was in wrong LCC header manipulations. Syzbot's reproducer tries to send XID packet. llc_ui_sendmsg() is doing following steps: 1. skb allocation with size = len + header size len is passed from userpace and header size is 3 since addr->sllc_xid is set. 2. skb_reserve() for header_len = 3 3. filling all other space with memcpy_from_msg() Ok, at this moment we have fully loaded skb, only headers needs to be filled. Then code comes to llc_sap_action_send_xid_c(). This function pushes 3 bytes for LLC PDU header and initializes it. Then comes llc_pdu_init_as_xid_cmd(). It initalizes next 3 bytes *AFTER* LLC PDU header and call skb_push(skb, 3). This looks wrong for 2 reasons: 1. Bytes rigth after LLC header are user data, so this function was overwriting payload. 2. skb_push(skb, 3) call can cause skb_over_panic() since all free space was filled in llc_ui_sendmsg(). (This can happen is user passed 686 len: 686 + 14 (eth header) + 3 (LLC header) = 703. SKB_DATA_ALIGN(703) = 704) So, in this patch I added 2 new private constansts: LLC_PDU_TYPE_U_XID and LLC_PDU_LEN_U_XID. LLC_PDU_LEN_U_XID is used to correctly reserve header size to handle LLC + XID case. LLC_PDU_TYPE_U_XID is used by llc_pdu_header_init() function to push 6 bytes instead of 3. And finally I removed skb_push() call from llc_pdu_init_as_xid_cmd(). This changes should not affect other parts of LLC, since after all steps we just transmit buffer. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: syzbot+5e5a981ad7cc54c4b2b4@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-27octeontx2-af: Do NIX_RX_SW_SYNC twiceSunil Goutham
NIX_RX_SW_SYNC ensures all existing transactions are finished and pkts are written to LLC/DRAM, queues should be teared down after successful SW_SYNC. Due to a HW errata, in some rare scenarios an existing transaction might end after SW_SYNC operation. To ensure operation is fully done, do the SW_SYNC twice. Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-27ALSA: usb-audio: Add registration quirk for JBL Quantum 600Alexander Tsoy
Apparently JBL Quantum 600 has multiple hardware revisions. Apply registration quirk to another device id as well. Signed-off-by: Alexander Tsoy <alexander@tsoy.me> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210727093326.1153366-1-alexander@tsoy.me Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-07-27HID: ft260: fix format type warning in ft260_word_show()Michael Zaidman
Fixes: 6a82582d9fa4 ("HID: ft260: add usb hid to i2c host bridge driver") Fix warning reported by static analysis when built with W=1 for arm64 by clang version 13.0.0 >> drivers/hid/hid-ft260.c:794:44: warning: format specifies type 'short' but the argument has type 'int' [-Wformat] return scnprintf(buf, PAGE_SIZE, "%hi\n", le16_to_cpu(*field)); ~~~ ^~~~~~~~~~~~~~~~~~~ %i include/linux/byteorder/generic.h:91:21: note: expanded from macro 'le16_to_cpu' #define le16_to_cpu __le16_to_cpu ^ include/uapi/linux/byteorder/big_endian.h:36:26: note: expanded from macro '__le16_to_cpu' #define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/uapi/linux/swab.h:105:2: note: expanded from macro '__swab16' (__builtin_constant_p((__u16)(x)) ? \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Any sprintf style use of %h or %hi for a sub-int sized value isn't useful since integer promotion is done on the value anyway. So, use %d instead. https://lore.kernel.org/lkml/CAHk-=wgoxnmsj8GEVFJSvTwdnWm8wVJthefNk2n6+4TC=20e0Q@mail.gmail.com/ Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com> Suggested-by: Joe Perches <joe@perches.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-07-27Merge branch 'fixes-v5.14' into fixesTony Lindgren
2021-07-27omap5-board-common: remove not physically existing vdds_1v8_main fixed-regulatorH. Nikolaus Schaller
This device tree include file describes a fixed-regulator connecting smps7_reg output (1.8V) to some 1.8V rail and consumers (vdds_1v8_main). This regulator does not physically exist. I assume it was introduced as a wrapper around smps7_reg to provide a speaking signal name "vdds_1v8_main" as label. This fixed-regulator without real function was not an issue in driver code until Commit 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators") introduced a new check for regulator initialization which makes Palmas regulator registration fail: [ 5.407712] ldo1: supplied by vsys_cobra [ 5.412748] ldo2: supplied by vsys_cobra [ 5.417603] palmas-pmic 48070000.i2c:palmas@48:palmas_pmic: failed to register 48070000.i2c:palmas@48:palmas_pmic regulator The reason is that the supply-chain of regulators is too long and goes from ldo3 through the virtual vdds_1v8_main regulator and then back to smps7. This adds a cross-dependency of probing Palmas regulators and the fixed-regulator which leads to probe deferral by the new check and is no longer resolved. Since we do not control what device tree files including this one reference (either &vdds_1v8_main or &smps7_reg or both) we keep both labels for smps7 for compatibility. Fixes: 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-07-27ARM: dts: am437x-l4: fix typo in can@0 nodeDario Binacchi
Replace clock-name with clock-names. Fixes: 2a4117df9b43 ("ARM: dts: Fix dcan driver probe failed on am437x platform") Signed-off-by: Dario Binacchi <dariobin@libero.it> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-07-27ARM: dts: am43x-epos-evm: Reduce i2c0 bus speed for tps65218Dave Gerlach
Based on the latest timing specifications for the TPS65218 from the data sheet, http://www.ti.com/lit/ds/symlink/tps65218.pdf, document SLDS206 from November 2014, we must change the i2c bus speed to better fit within the minimum high SCL time required for proper i2c transfer. When running at 400khz, measurements show that SCL spends 0.8125 uS/1.666 uS high/low which violates the requirement for minimum high period of SCL provided in datasheet Table 7.6 which is 1 uS. Switching to 100khz gives us 5 uS/5 uS high/low which both fall above the minimum given values for 100 khz, 4.0 uS/4.7 uS high/low. Without this patch occasionally a voltage set operation from the kernel will appear to have worked but the actual voltage reflected on the PMIC will not have updated, causing problems especially with cpufreq that may update to a higher OPP without actually raising the voltage on DCDC2, leading to a hang. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-07-27bus: ti-sysc: AM3: RNG is GP onlyKevin Hilman
Make the RNG on AM3 GP only. Based on this patch from TI v5.4 tree which is based on hwmod data which are now removed: | ARM: AM43xx: hwmod: Move RNG to a GP only links table | | On non-GP devices the RNG is controlled by the secure-side software, | like in DRA7xx hwmod we should not control this IP when we are not | a GP device. | | Signed-off-by: Andrew F. Davis <afd@ti.com> Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-07-27ARM: omap2+: hwmod: fix potential NULL pointer accessTero Kristo
omap_hwmod_get_pwrdm() may access a NULL clk_hw pointer in some failure cases. Add a check for the case and bail out gracely if this happens. Reported-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-07-27ALSA: hda/realtek: Fix headset mic for Acer SWIFT SF314-56 (ALC256)Nikos Liolios
The issue on Acer SWIFT SF314-56 is that headset microphone doesn't work. The following quirk fixed headset microphone issue. The fixup was found by trial and error. Note that the fixup of SF314-54/55 (ALC256_FIXUP_ACER_HEADSET_MIC) was not successful on my SF314-56. Signed-off-by: Nikos Liolios <liolios.nk@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210727030510.36292-1-liolios.nk@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-07-26smb3: rc uninitialized in one fallocate pathSteve French
Clang detected a problem with rc possibly being unitialized (when length is zero) in a recently added fallocate code path. Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-07-26SMB3: fix readpage for large swap cacheSteve French
readpage was calculating the offset of the page incorrectly for the case of large swapcaches. loff_t offset = (loff_t)page->index << PAGE_SHIFT; As pointed out by Matthew Wilcox, this needs to use page_file_offset() to calculate the offset instead. Pages coming from the swap cache have page->index set to their index within the swapcache, not within the backing file. For a sufficiently large swapcache, we could have overlapping values of page->index within the same backing file. Suggested by: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: <stable@vger.kernel.org> # v5.7+ Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-07-26clk: hisilicon: hi3559a: select RESET_HISIRandy Dunlap
The clk-hi3559a driver uses functions from reset.c so it should select RESET_HISI to avoid build errors. Fixes these build errors: aarch64-linux-ld: drivers/clk/hisilicon/clk-hi3559a.o: in function `hi3559av100_crg_remove': clk-hi3559a.c:(.text+0x158): undefined reference to `hisi_reset_exit' aarch64-linux-ld: drivers/clk/hisilicon/clk-hi3559a.o: in function `hi3559av100_crg_probe': clk-hi3559a.c:(.text+0x1f4): undefined reference to `hisi_reset_init' aarch64-linux-ld: clk-hi3559a.c:(.text+0x238): undefined reference to `hisi_reset_exit' Fixes: 6c81966107dc ("clk: hisilicon: Add clock driver for hi3559A SoC") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Dongjiu Geng <gengdongjiu@huawei.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: stable@vger.kernel.org Cc: linux-clk@vger.kernel.org Cc: Michael Turquette <mturquette@baylibre.com> Link: https://lore.kernel.org/r/20210717043159.12566-1-rdunlap@infradead.org Reviewed-by: Dongjiu Geng <gengdongjiu1@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2021-07-26clk: stm32f4: fix post divisor setup for I2S/SAI PLLsDario Binacchi
Enabling the framebuffer leads to a system hang. Running, as a debug hack, the store_pan() function in drivers/video/fbdev/core/fbsysfs.c without taking the console_lock, allows to see the crash backtrace on the serial line. ~ # echo 0 0 > /sys/class/graphics/fb0/pan [ 9.719414] Unhandled exception: IPSR = 00000005 LR = fffffff1 [ 9.726937] CPU: 0 PID: 49 Comm: sh Not tainted 5.13.0-rc5 #9 [ 9.733008] Hardware name: STM32 (Device Tree Support) [ 9.738296] PC is at clk_gate_is_enabled+0x0/0x28 [ 9.743426] LR is at stm32f4_pll_div_set_rate+0xf/0x38 [ 9.748857] pc : [<0011e4be>] lr : [<0011f9e3>] psr: 0100000b [ 9.755373] sp : 00bc7be0 ip : 00000000 fp : 001f3ac4 [ 9.760812] r10: 002610d0 r9 : 01efe920 r8 : 00540560 [ 9.766269] r7 : 02e7ddb0 r6 : 0173eed8 r5 : 00000000 r4 : 004027c0 [ 9.773081] r3 : 0011e4bf r2 : 02e7ddb0 r1 : 0173eed8 r0 : 1d3267b8 [ 9.779911] xPSR: 0100000b [ 9.782719] CPU: 0 PID: 49 Comm: sh Not tainted 5.13.0-rc5 #9 [ 9.788791] Hardware name: STM32 (Device Tree Support) [ 9.794120] [<0000afa1>] (unwind_backtrace) from [<0000a33f>] (show_stack+0xb/0xc) [ 9.802421] [<0000a33f>] (show_stack) from [<0000a8df>] (__invalid_entry+0x4b/0x4c) The `pll_num' field in the post_div_data configuration contained a wrong value which also referenced an uninitialized hardware clock when clk_register_pll_div() was called. Fixes: 517633ef630e ("clk: stm32f4: Add post divisor for I2S & SAI PLLs") Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Gabriel Fernandez <gabriel.fernandez@st.com> Link: https://lore.kernel.org/r/20210725160725.10788-1-dariobin@libero.it Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2021-07-26bnxt_en: Fix static checker warning in bnxt_fw_reset_task()Somnath Kotur
Now that we return when bnxt_open() fails in bnxt_fw_reset_task(), there is no need to check for 'rc' value again before invoking bnxt_reenable_sriov(). Fixes: 3958b1da725a ("bnxt_en: fix error path of FW reset") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-26spi: imx: mx51-ecspi: Fix low-speed CONFIGREG delay calculationMarek Vasut
The spi_imx->spi_bus_clk may be uninitialized and thus also zero in mx51_ecspi_prepare_message(), which would lead to division by zero in kernel. Since bitbang .setup_transfer callback which initializes the spi_imx->spi_bus_clk is called after bitbang prepare_message callback, iterate over all the transfers in spi_message, find the one with lowest bus frequency, and use that bus frequency for the delay calculation. Note that it is not possible to move this CONFIGREG delay back into the .setup_transfer callback, because that is invoked too late, after the GPIO chipselects were already configured. Fixes: 135cbd378eab ("spi: imx: mx51-ecspi: Reinstate low-speed CONFIGREG delay") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210726100102.5188-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-26ASoC: Intel: sof_da7219_mx98360a: fail to initialize soundcardBrent Lu
The default codec for speaker amp's DAI Link is max98373 and will be overwritten in probe function if the board id is sof_da7219_mx98360a. However, the probe function does not do it because the board id is changed in earlier commit. Fixes: 1cc04d195dc2 ("ASoC: Intel: sof_da7219_max98373: shrink platform_id below 20 characters") Signed-off-by: Brent Lu <brent.lu@intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210726094525.5748-1-brent.lu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-26ALSA: usb-audio: Fix superfluous autosuspend recoveryTakashi Iwai
The change to restore the autosuspend from the disabled state uses a wrong check: namely, it should have been the exact comparison of the quirk_type instead of the bitwise and (&). Otherwise it matches wrongly with the other quirk types. Although re-enabling the autosuspend for the already enabled device shouldn't matter much, it's better to fix the unbalanced call. Fixes: 9799110825db ("ALSA: usb-audio: Disable USB autosuspend properly in setup_disable_autosuspend()") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/s5hr1flh9ov.wl-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-07-26drm/amdgpu: Avoid printing of stack contents on firmware load errorJiri Kosina
In case when psp_init_asd_microcode() fails to load ASD microcode file, psp_v12_0_init_microcode() tries to print the firmware filename that failed to load before bailing out. This is wrong because: - the firmware filename it would want it print is an incorrect one as psp_init_asd_microcode() and psp_v12_0_init_microcode() are loading different filenames - it tries to print fw_name, but that's not yet been initialized by that time, so it prints random stack contents, e.g. amdgpu 0000:04:00.0: Direct firmware load for amdgpu/renoir_asd.bin failed with error -2 amdgpu 0000:04:00.0: amdgpu: fail to initialize asd microcode amdgpu 0000:04:00.0: amdgpu: psp v12.0: Failed to load firmware "\xfeTO\x8e\xff\xff" Fix that by bailing out immediately, instead of priting the bogus error message. Reported-by: Vojtech Pavlik <vojtech@ucw.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-07-26io_uring: fix race in unified task_work runningJens Axboe
We use a bit to manage if we need to add the shared task_work, but a list + lock for the pending work. Before aborting a current run of the task_work we check if the list is empty, but we do so without grabbing the lock that protects it. This can lead to races where we think we have nothing left to run, where in practice we could be racing with a task adding new work to the list. If we do hit that race condition, we could be left with work items that need processing, but the shared task_work is not active. Ensure that we grab the lock before checking if the list is empty, so we know if it's safe to exit the run or not. Link: https://lore.kernel.org/io-uring/c6bd5987-e9ae-cd02-49d0-1b3ac1ef65b1@tnonline.net/ Cc: stable@vger.kernel.org # 5.11+ Reported-by: Forza <forza@tnonline.net> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-07-26drm/amdgpu: Fix resource leak on probe error pathJiri Kosina
This reverts commit 4192f7b5768912ceda82be2f83c87ea7181f9980. It is not true (as stated in the reverted commit changelog) that we never unmap the BAR on failure; it actually does happen properly on amdgpu_driver_load_kms() -> amdgpu_driver_unload_kms() -> amdgpu_device_fini() error path. What's worse, this commit actually completely breaks resource freeing on probe failure (like e.g. failure to load microcode), as amdgpu_driver_unload_kms() notices adev->rmmio being NULL and bails too early, leaving all the resources that'd normally be freed in amdgpu_acpi_fini() and amdgpu_device_fini() still hanging around, leading to all sorts of oopses when someone tries to, for example, access the sysfs and procfs resources which are still around while the driver is gone. Fixes: 4192f7b57689 ("drm/amdgpu: unmap register bar on device init failure") Reported-by: Vojtech Pavlik <vojtech@ucw.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-07-26io_uring: fix io_prep_async_link lockingPavel Begunkov
io_prep_async_link() may be called after arming a linked timeout, automatically making it unsafe to traverse the linked list. Guard with completion_lock if there was a linked timeout. Cc: stable@vger.kernel.org # 5.9+ Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/93f7c617e2b4f012a2a175b3dab6bc2f27cebc48.1627304436.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-07-26net/qla3xxx: fix schedule while atomic in ql_wait_for_drvr_lock and ↵Letu Ren
ql_adapter_reset When calling the 'ql_wait_for_drvr_lock' and 'ql_adapter_reset', the driver has already acquired the spin lock, so the driver should not call 'ssleep' in atomic context. This bug can be fixed by using 'mdelay' instead of 'ssleep'. Reported-by: Letu Ren <fantasquex@gmail.com> Signed-off-by: Letu Ren <fantasquex@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-26iommu/dma: Fix leak in non-contiguous APIEzequiel Garcia
Currently, iommu_dma_alloc_noncontiguous() allocates a struct dma_sgt_handle object to hold some state needed for iommu_dma_free_noncontiguous(). However, the handle is neither freed nor returned explicitly by the ->alloc_noncontiguous method, and therefore seems leaked. This was found by code inspection, so please review carefully and test. As a side note, it appears the struct dma_sgt_handle type is exposed to users of the DMA-API by linux/dma-map-ops.h, but is has no users or functions returning the type explicitly. This may indicate it's a good idea to move the struct dma_sgt_handle type to drivers/iommu/dma-iommu.c. The decision is left to maintainers :-) Cc: stable@vger.kernel.org Fixes: e817ee5f2f95c ("dma-iommu: implement ->alloc_noncontiguous") Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20210723010552.50969-1-ezequiel@collabora.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-07-26KVM: x86: Check the right feature bit for MSR_KVM_ASYNC_PF_ACK accessVitaly Kuznetsov
MSR_KVM_ASYNC_PF_ACK MSR is part of interrupt based asynchronous page fault interface and not the original (deprecated) KVM_FEATURE_ASYNC_PF. This is stated in Documentation/virt/kvm/msr.rst. Fixes: 66570e966dd9 ("kvm: x86: only provide PV features if enabled in guest's CPUID") Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Oliver Upton <oupton@google.com> Message-Id: <20210722123018.260035-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-26docs: virt: kvm: api.rst: replace some charactersMauro Carvalho Chehab
The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+00a0 (' '): NO-BREAK SPACE as it can cause lines being truncated on PDF output Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Message-Id: <ff70cb42d63f3a1da66af1b21b8d038418ed5189.1626947264.git.mchehab+huawei@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-26KVM: Documentation: Fix KVM_CAP_ENFORCE_PV_FEATURE_CPUID nameVitaly Kuznetsov
'KVM_CAP_ENFORCE_PV_CPUID' doesn't match the define in include/uapi/linux/kvm.h. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210722092628.236474-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-07-26KVM: nSVM: Swap the parameter order for ↵Vitaly Kuznetsov
svm_copy_vmrun_state()/svm_copy_vmloadsave_state() Make svm_copy_vmrun_state()/svm_copy_vmloadsave_state() interface match 'memcpy(dest, src)' to avoid any confusion. No functional change intended. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210719090322.625277-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit (git 2.34.1) at 2025-09-14 23:24:26 +0000