summaryrefslogtreecommitdiff
path: root/drivers/clk/eswin/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorMichael Kelley <mhklinux@outlook.com>2026-02-17 10:23:34 -0800
committerWei Liu <wei.liu@kernel.org>2026-05-13 22:29:32 +0000
commitc5c3ef8d49e15d2fc1cec4ad7c91d81b99977440 (patch)
treefa1ace008c48099bdbb1b4bc4f4efe81e16a5e0c /drivers/clk/eswin/git@git.tavy.me:linux.git
parent6e55a8d9f21bcb238596bdd8092c92e74c698a3d (diff)
Drivers: hv: vmbus: Provide option to skip VMBus unload on panic
Currently, VMBus code initiates a VMBus unload in the panic path so that if a kdump kernel is loaded, it can start fresh in setting up its own VMBus connection. However, a driver for the VMBus virtual frame buffer may need to flush dirty portions of the frame buffer back to the Hyper-V host so that panic information is visible in the graphics console. To support such flushing, provide exported functions for the frame buffer driver to specify that the VMBus unload should not be done by the VMBus driver, and to initiate the VMBus unload itself. Together these allow a frame buffer driver to delay the VMBus unload until after it has completed the flush. Ideally, the VMBus driver could use its own panic-path callback to do the unload after all frame buffer drivers have finished. But DRM frame buffer drivers use the kmsg dump callback, and there are no callbacks after that in the panic path. Hence this somewhat messy approach to properly sequencing the frame buffer flush and the VMBus unload. Fixes: 3671f3777758 ("drm/hyperv: Add support for drm_panic") Signed-off-by: Michael Kelley <mhklinux@outlook.com> Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Wei Liu <wei.liu@kernel.org>
Diffstat (limited to 'drivers/clk/eswin/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions