"Michael Kelley (LINUX)" <mikelley@xxxxxxxxxxxxx> writes: > From: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> Sent: Thursday, August 18, 2022 7:25 AM >> >> When drm_aperture_remove_conflicting_pci_framebuffers() fails, 'pdev' >> needs to be released with pci_dev_put(). >> >> Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") >> Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> >> --- >> drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c >> b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c >> index 46f6c454b820..ca4e517b95ca 100644 >> --- a/drivers/gpu/drm/hyperv/hyperv_drm_drv.c >> +++ b/drivers/gpu/drm/hyperv/hyperv_drm_drv.c >> @@ -82,7 +82,7 @@ static int hyperv_setup_gen1(struct hyperv_drm_device *hv) >> ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, >> &hyperv_driver); >> if (ret) { >> drm_err(dev, "Not able to remove boot fb\n"); >> - return ret; >> + goto error; >> } >> >> if (pci_request_region(pdev, 0, DRIVER_NAME) != 0) >> -- >> 2.37.1 > > This patch appears to be obsoleted by commit a0ab5abced55 > that was merged into 6.0-rc1. Of course, it does beg the question of > why the original function hyperv_setup_gen2(), which is now renamed > to hyperv_setup_vram(), doesn't check the return value from > drm_aperture_remove_conflicting_framebuffers(). AFAICT this commit (which I've obviously missed) also solves the worst issue I'm trying to address with this series: conflict between framebuffer and SR-IOV VF config space. It would probably still make sense to reserve the whole FB region on Gen1 first thing and use it as-is for DRM/FB later (Patches 3-4). -- Vitaly