[PATCH 1/2] drm/amd/pm: correct the baco state setting for ArmD3 scenario
The check for baco support relies on the correct baco state. Signed-off-by: Evan Quan Change-Id: I9dd15958c213eb83abdb8b7d858eff0d2d364b4e --- .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 21 +++ 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c index f4927ada5c07..1984b01514bd 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c @@ -2217,10 +2217,23 @@ int smu_v13_0_gfx_ulv_control(struct smu_context *smu, int smu_v13_0_baco_set_armd3_sequence(struct smu_context *smu, enum smu_baco_seq baco_seq) { - return smu_cmn_send_smc_msg_with_param(smu, - SMU_MSG_ArmD3, - baco_seq, - NULL); + struct smu_baco_context *smu_baco = >smu_baco; + int ret; + + ret = smu_cmn_send_smc_msg_with_param(smu, + SMU_MSG_ArmD3, + baco_seq, + NULL); + if (ret) + return ret; + + if ((baco_seq == BACO_SEQ_BAMACO) || + (baco_seq == BACO_SEQ_BACO)) + smu_baco->state = SMU_BACO_STATE_ENTER; + else + smu_baco->state = SMU_BACO_STATE_EXIT; + + return 0; } bool smu_v13_0_baco_is_support(struct smu_context *smu) -- 2.34.1
[PATCH 2/2] drm/amd/pm: no pptable resetup on runpm exiting
It is assumed the pptable used before runpm is same as the one used afterwards. Thus, we can reuse the stored copy and do not need to resetup the pptable again. Signed-off-by: Evan Quan Change-Id: Ib6d61f8e8cb58df45d9e24725b0672239b3ff653 --- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c index ff806a2e804f..bb25f14f0733 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c @@ -1220,10 +1220,17 @@ static int smu_smc_hw_setup(struct smu_context *smu) return ret; } - ret = smu_setup_pptable(smu); - if (ret) { - dev_err(adev->dev, "Failed to setup pptable!\n"); - return ret; + /* +* It is assumed the pptable used before runpm is same as +* the one used afterwards. Thus, we can reuse the stored +* copy and do not need to resetup the pptable again. +*/ + if (!adev->in_runpm) { + ret = smu_setup_pptable(smu); + if (ret) { + dev_err(adev->dev, "Failed to setup pptable!\n"); + return ret; + } } /* smu_dump_pptable(smu); */ -- 2.34.1
[PATCH] drm/amd/pm: downgrade log level upon SMU IF version mismatch
SMU IF version mismatch as a warning message exists widely after asic production, however, due to this log level setting, such mismatch warning will be caught by automation test like IGT and reported as a fake error after checking. As such mismatch does not break anything, to reduce confusion, downgrade it from dev_warn to dev_info. Signed-off-by: Guchun Chen --- drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 4 ++-- drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c | 4 ++-- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c index 6492d69e2e60..e1ef88ee1ed3 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c @@ -256,7 +256,7 @@ int smu_v11_0_check_fw_version(struct smu_context *smu) * to be backward compatible. * 2. New fw usually brings some optimizations. But that's visible * only on the paired driver. -* Considering above, we just leave user a warning message instead +* Considering above, we just leave user a verbal message instead * of halt driver loading. */ if (if_version != smu->smc_driver_if_version) { @@ -264,7 +264,7 @@ int smu_v11_0_check_fw_version(struct smu_context *smu) "smu fw program = %d, version = 0x%08x (%d.%d.%d)\n", smu->smc_driver_if_version, if_version, smu_program, smu_version, smu_major, smu_minor, smu_debug); - dev_warn(smu->adev->dev, "SMU driver if version not matched\n"); + dev_info(smu->adev->dev, "SMU driver if version not matched\n"); } return ret; diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c b/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c index 56a02bc60cee..c788aa7a99a9 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c @@ -93,7 +93,7 @@ int smu_v12_0_check_fw_version(struct smu_context *smu) * to be backward compatible. * 2. New fw usually brings some optimizations. But that's visible * only on the paired driver. -* Considering above, we just leave user a warning message instead +* Considering above, we just leave user a verbal message instead * of halt driver loading. */ if (if_version != smu->smc_driver_if_version) { @@ -101,7 +101,7 @@ int smu_v12_0_check_fw_version(struct smu_context *smu) "smu fw program = %d, smu fw version = 0x%08x (%d.%d.%d)\n", smu->smc_driver_if_version, if_version, smu_program, smu_version, smu_major, smu_minor, smu_debug); - dev_warn(smu->adev->dev, "SMU driver if version not matched\n"); + dev_info(smu->adev->dev, "SMU driver if version not matched\n"); } return ret; diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c index 78945e79dbee..25f336829840 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c @@ -311,7 +311,7 @@ int smu_v13_0_check_fw_version(struct smu_context *smu) * to be backward compatible. * 2. New fw usually brings some optimizations. But that's visible * only on the paired driver. -* Considering above, we just leave user a warning message instead +* Considering above, we just leave user a verbal message instead * of halt driver loading. */ if (if_version != smu->smc_driver_if_version) { @@ -319,7 +319,7 @@ int smu_v13_0_check_fw_version(struct smu_context *smu) "smu fw program = %d, smu fw version = 0x%08x (%d.%d.%d)\n", smu->smc_driver_if_version, if_version, smu_program, smu_version, smu_major, smu_minor, smu_debug); - dev_warn(adev->dev, "SMU driver if version not matched\n"); + dev_info(adev->dev, "SMU driver if version not matched\n"); } return ret; -- 2.25.1
[PATCH 1/3] drm/amd: Allow dGPUs that support BACO to use smart suspend
If a dGPU is already runtime suspended using BACO, there is no point to waking it up to run regular suspend callbacks. Cc: Peter Kopec Signed-off-by: Mario Limonciello --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 1f6d93dc3d72..c3d3a042946d 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -2187,8 +2187,9 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, /* only need to skip on ATPX */ if (amdgpu_device_supports_px(ddev)) dev_pm_set_driver_flags(ddev->dev, DPM_FLAG_NO_DIRECT_COMPLETE); - /* we want direct complete for BOCO */ - if (amdgpu_device_supports_boco(ddev)) + /* we want direct complete for BOCO and for BACO */ + if (amdgpu_device_supports_boco(ddev) || + amdgpu_device_supports_baco(ddev)) dev_pm_set_driver_flags(ddev->dev, DPM_FLAG_SMART_PREPARE | DPM_FLAG_SMART_SUSPEND | DPM_FLAG_MAY_SKIP_RESUME); @@ -2389,7 +2390,8 @@ static int amdgpu_pmops_prepare(struct device *dev) /* Return a positive number here so * DPM_FLAG_SMART_SUSPEND works properly */ - if (amdgpu_device_supports_boco(drm_dev)) + if (amdgpu_device_supports_boco(drm_dev) || + amdgpu_device_supports_baco(drm_dev)) return pm_runtime_suspended(dev); /* if we will not support s3 or s2i for the device -- 2.34.1
[PATCH 3/3] drm/amd: Don't always set s3 for dGPUs in all sleep modes
dGPUs that will be using BACO or BOCO shouldn't be put into S3 when the system is being put into s2idle. Cc: Peter Kopec Signed-off-by: Mario Limonciello --- drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c index 25e902077caf..5c69116bc883 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c @@ -1038,8 +1038,13 @@ void amdgpu_acpi_detect(void) */ bool amdgpu_acpi_is_s3_active(struct amdgpu_device *adev) { - return !(adev->flags & AMD_IS_APU) || - (pm_suspend_target_state == PM_SUSPEND_MEM); + if (pm_suspend_target_state == PM_SUSPEND_MEM) + return true; + if (adev->flags & AMD_IS_APU) + return false; + return !amdgpu_device_supports_baco(>ddev) && + !amdgpu_device_supports_boco(>ddev); + } /** -- 2.34.1
[RFC 0/3] Adjust suspend flow for dGPUs
Currently when a dGPU supports BOCO and is runtime suspended when running the prepare() callback, the rest of the suspend and resume will be skipped. This skipping is due to "Smart prepare", "Smart suspend" and "Smart resume" flags. dGPUs that support BACO are normally suspended via PMFW and lack of video or audio, but this policy doesn't apply to them. Furthermore even if a dGPU is runtime suspended the system wide suspend callbacks always wake them even if the power rails won't be cut. This series adjust the flow around runtime suspend handling for dGPUs. Mario Limonciello (3): drm/amd: Don't always set s3 for dGPUs in all sleep modes drm/amd: Allow dGPUs that support BACO to use smart suspend drm/amd: Use runtime suspend in lieu regular suspend on supported dGPUs drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 9 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 - 2 files changed, 19 insertions(+), 7 deletions(-) -- 2.34.1
[PATCH 2/3] drm/amd: Use runtime suspend in lieu regular suspend on supported dGPUs
The PMFW on dGPUs that support BACO will transition them in and out of BACO when video/audio move in out of D3/D0. On the Linux side users can configure what sleep mode to use in `/sys/power/mem_sleep`, but if the host hardware doesn't cut the power rails during this state then calling suspend from Linux may cause a mismatch of behavior. To avoid this, only run the runtime suspend and resume callbacks when the dGPU supports BACO or BOCO and the smart flags didn't return to skip these stages (because already runtime suspended). Cc: Peter Kopec Signed-off-by: Mario Limonciello --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index c3d3a042946d..fdc1cbf8ad10 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -2418,8 +2418,11 @@ static int amdgpu_pmops_suspend(struct device *dev) adev->in_s0ix = true; else if (amdgpu_acpi_is_s3_active(adev)) adev->in_s3 = true; - if (!adev->in_s0ix && !adev->in_s3) + if (!adev->in_s0ix && !adev->in_s3) { + pm_runtime_mark_last_busy(dev); + pm_runtime_autosuspend(dev); return 0; + } return amdgpu_device_suspend(drm_dev, true); } @@ -2440,8 +2443,10 @@ static int amdgpu_pmops_resume(struct device *dev) struct amdgpu_device *adev = drm_to_adev(drm_dev); int r; - if (!adev->in_s0ix && !adev->in_s3) + if (!adev->in_s0ix && !adev->in_s3) { + pm_runtime_resume(dev); return 0; + } /* Avoids registers access if device is physically gone */ if (!pci_device_is_present(adev->pdev)) -- 2.34.1
[linux-next:master] BUILD REGRESSION d2af0fa4bfa4ec29d03b449ccd43fee39501112d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: d2af0fa4bfa4ec29d03b449ccd43fee39501112d Add linux-next specific files for 20230220 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202302062224.byzetxh1-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302092211.54eydhyh-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302111601.jty4lkra-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302170355.ljqlzucu-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302210017.xt59wvsm-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302210350.lynwcl4t-...@intel.com Error/Warning: (recently discovered and may have been fixed) Documentation/sphinx/templates/kernel-toc.html: 1:36 Invalid token: #} ERROR: modpost: "__umoddi3" [fs/btrfs/btrfs.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! FAILED: load BTF from vmlinux: No data available drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: warning: no previous prototype for 'optc3_wait_drr_doublebuffer_pending_clear' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_resource_helpers.c:62:18: warning: variable 'cursor_bpp' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_detection.c:1199: warning: expecting prototype for dc_link_detect_connection_type(). Prototype was for link_detect_connection_type() instead drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1292:32: warning: variable 'result_write_min_hblank' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c:1586:38: warning: variable 'result' set but not used [-Wunused-but-set-variable] drivers/net/ethernet/sfc/ef100_nic.c:1197:9: warning: variable 'rc' is uninitialized when used here [-Wuninitialized] drivers/net/ethernet/sfc/efx_devlink.c:326:58: error: expected ')' before 'build_id' drivers/net/ethernet/sfc/efx_devlink.c:338:55: error: expected ';' before '}' token drivers/of/unittest.c:3042:41: error: 'struct device_node' has no member named 'kobj' drivers/pwm/pwm-dwc.c:314:1: error: type defaults to 'int' in declaration of 'module_pci_driver' [-Werror=implicit-int] include/asm-generic/div64.h:238:36: error: passing argument 1 of '__div64_32' from incompatible pointer type [-Werror=incompatible-pointer-types] Unverified Error/Warning (likely false positive, please contact us if interested): drivers/infiniband/hw/hfi1/verbs.c:1661 hfi1_alloc_hw_device_stats() error: we previously assumed 'dev_cntr_descs' could be null (see line 1650) drivers/net/phy/phy-c45.c:712 genphy_c45_write_eee_adv() error: uninitialized symbol 'changed'. drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c:1678 rtl8188e_handle_ra_tx_report2() warn: ignoring unreachable code. drivers/usb/gadget/composite.c:2082:33: sparse: sparse: restricted __le16 degrades to integer drivers/virtio/virtio_ring.c:1585 virtqueue_add_packed_vring() error: uninitialized symbol 'prev'. drivers/virtio/virtio_ring.c:1593 virtqueue_add_packed_vring() error: uninitialized symbol 'head_flags'. drivers/virtio/virtio_ring.c:697 virtqueue_add_split_vring() error: uninitialized symbol 'prev'. pahole: .tmp_vmlinux.btf: No such file or directory Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_detection.c:warning:expecting-prototype-for-dc_link_detect_connection_type().-Prototype-was-for-link_detect_connection_type()-instead | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-result_write_min_hblank-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_training.c:warning:variable-result-set-but-not-used |-- alpha-buildonly-randconfig-r006-20230219 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_detection.c:warning:expecting-prototype-for-dc_link_detect_connection_type().-Prototype-was-for-link_detect_connection_type()-instead | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-result_write_min_hblank-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_training.c:warning:variable-result-set-but-not-used |-- arc-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_detection.c:warning:expecting-prototype-for-dc_link_detect_connection_type().-Prototype-was-for-link_detect_connection_type()-instead | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-result_write_min_hblank-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_trai
Re: [PATCH] drm/amd: Fix initialization for nbio 7.5.1
[AMD Official Use Only - General] Acked-by: Alex Deucher From: amd-gfx on behalf of Mario Limonciello Sent: Monday, February 20, 2023 1:10 PM To: amd-gfx@lists.freedesktop.org Cc: Gong, Richard ; Limonciello, Mario Subject: [PATCH] drm/amd: Fix initialization for nbio 7.5.1 A mistake has been made in the BIOS for some ASICs with NBIO 7.5.1 where some NBIO registers aren't properly setup. Ensure that they're set during initialization. Tested-by: Richard Gong Signed-off-by: Mario Limonciello --- drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c b/drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c index 31776b12e4c45..4b0d563c6522c 100644 --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c @@ -382,6 +382,11 @@ static void nbio_v7_2_init_registers(struct amdgpu_device *adev) if (def != data) WREG32_PCIE_PORT(SOC15_REG_OFFSET(NBIO, 0, regBIF1_PCIE_MST_CTRL_3), data); break; + case IP_VERSION(7, 5, 1): + data = RREG32_SOC15(NBIO, 0, regRCC_DEV2_EPF0_STRAP2); + data &= ~RCC_DEV2_EPF0_STRAP2__STRAP_NO_SOFT_RESET_DEV2_F0_MASK; + WREG32_SOC15(NBIO, 0, regRCC_DEV2_EPF0_STRAP2, data); + fallthrough; default: def = data = RREG32_PCIE_PORT(SOC15_REG_OFFSET(NBIO, 0, regPCIE_CONFIG_CNTL)); data = REG_SET_FIELD(data, PCIE_CONFIG_CNTL, -- 2.25.1
[PATCH] drm/amd: Fix initialization for nbio 7.5.1
A mistake has been made in the BIOS for some ASICs with NBIO 7.5.1 where some NBIO registers aren't properly setup. Ensure that they're set during initialization. Tested-by: Richard Gong Signed-off-by: Mario Limonciello --- drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c b/drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c index 31776b12e4c45..4b0d563c6522c 100644 --- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c +++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_2.c @@ -382,6 +382,11 @@ static void nbio_v7_2_init_registers(struct amdgpu_device *adev) if (def != data) WREG32_PCIE_PORT(SOC15_REG_OFFSET(NBIO, 0, regBIF1_PCIE_MST_CTRL_3), data); break; + case IP_VERSION(7, 5, 1): + data = RREG32_SOC15(NBIO, 0, regRCC_DEV2_EPF0_STRAP2); + data &= ~RCC_DEV2_EPF0_STRAP2__STRAP_NO_SOFT_RESET_DEV2_F0_MASK; + WREG32_SOC15(NBIO, 0, regRCC_DEV2_EPF0_STRAP2, data); + fallthrough; default: def = data = RREG32_PCIE_PORT(SOC15_REG_OFFSET(NBIO, 0, regPCIE_CONFIG_CNTL)); data = REG_SET_FIELD(data, PCIE_CONFIG_CNTL, -- 2.25.1
RE: [PATCH v2] drm/amd: Don't allow s0ix on APUs older than Raven
[AMD Official Use Only - General] > -Original Message- > From: Alex Deucher > Sent: Monday, February 20, 2023 11:10 > To: Limonciello, Mario > Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander > > Subject: Re: [PATCH v2] drm/amd: Don't allow s0ix on APUs older than Raven > > On Mon, Feb 20, 2023 at 11:56 AM Limonciello, Mario > wrote: > > > > [Public] > > > > > > > > > -Original Message- > > > From: Limonciello, Mario > > > Sent: Monday, February 13, 2023 15:11 > > > To: amd-gfx@lists.freedesktop.org > > > Cc: Limonciello, Mario ; Deucher, > Alexander > > > > > > Subject: [PATCH v2] drm/amd: Don't allow s0ix on APUs older than Raven > > > > > > APUs before Raven didn't support s0ix. As we just relieved some > > > of the safety checks for s0ix to improve power consumption on > > > APUs that support it but that are missing BIOS support a new > > > blind spot was introduced that a user could "try" to run s0ix. > > > > > > Plug this hole so that if users try to run s0ix on anything older > > > than Raven it will just skip suspend of the GPU. > > > > > > Fixes: cf488dcd0ab7 ("drm/amd: Allow s0ix without BIOS support") > > > Suggested-by: Alexander Deucher > > > Signed-off-by: Mario Limonciello > > > --- > > > v1->v2: > > > * Don't run any suspend code or resume code in this case > > > > Any feedback for this patch? > > Reviewed-by: Alex Deucher > Thanks. > I think for S0ix and dGPUs, we probably need some additional work as > well. If the user tries s2idle and the platform doesn't actually > support s0ix (i.e., doesn't actually turn off the power rails), we > should be using the runtime suspend routines for BACO/BOCO rather than > the S3 suspend routines. OK - I'll review the framework code for that case and see what makes sense. > > Alex > > > > > > > --- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 +++ > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 7 ++- > > > 2 files changed, 9 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > > > index fa7375b97fd47..25e902077caf6 100644 > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > > > @@ -1073,6 +1073,9 @@ bool amdgpu_acpi_is_s0ix_active(struct > > > amdgpu_device *adev) > > > (pm_suspend_target_state != PM_SUSPEND_TO_IDLE)) > > > return false; > > > > > > + if (adev->asic_type < CHIP_RAVEN) > > > + return false; > > > + > > > /* > > >* If ACPI_FADT_LOW_POWER_S0 is not set in the FADT, it is > > > generally > > >* risky to do any special firmware-related preparations for > > > entering > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > index 6c2fe50b528e0..1f6d93dc3d72b 100644 > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > > @@ -2414,8 +2414,10 @@ static int amdgpu_pmops_suspend(struct > device > > > *dev) > > > > > > if (amdgpu_acpi_is_s0ix_active(adev)) > > > adev->in_s0ix = true; > > > - else > > > + else if (amdgpu_acpi_is_s3_active(adev)) > > > adev->in_s3 = true; > > > + if (!adev->in_s0ix && !adev->in_s3) > > > + return 0; > > > return amdgpu_device_suspend(drm_dev, true); > > > } > > > > > > @@ -2436,6 +2438,9 @@ static int amdgpu_pmops_resume(struct device > > > *dev) > > > struct amdgpu_device *adev = drm_to_adev(drm_dev); > > > int r; > > > > > > + if (!adev->in_s0ix && !adev->in_s3) > > > + return 0; > > > + > > > /* Avoids registers access if device is physically gone */ > > > if (!pci_device_is_present(adev->pdev)) > > > adev->no_hw_access = true; > > > -- > > > 2.25.1
Re: [PATCH v2] drm/amd: Don't allow s0ix on APUs older than Raven
On Mon, Feb 20, 2023 at 11:56 AM Limonciello, Mario wrote: > > [Public] > > > > > -Original Message- > > From: Limonciello, Mario > > Sent: Monday, February 13, 2023 15:11 > > To: amd-gfx@lists.freedesktop.org > > Cc: Limonciello, Mario ; Deucher, Alexander > > > > Subject: [PATCH v2] drm/amd: Don't allow s0ix on APUs older than Raven > > > > APUs before Raven didn't support s0ix. As we just relieved some > > of the safety checks for s0ix to improve power consumption on > > APUs that support it but that are missing BIOS support a new > > blind spot was introduced that a user could "try" to run s0ix. > > > > Plug this hole so that if users try to run s0ix on anything older > > than Raven it will just skip suspend of the GPU. > > > > Fixes: cf488dcd0ab7 ("drm/amd: Allow s0ix without BIOS support") > > Suggested-by: Alexander Deucher > > Signed-off-by: Mario Limonciello > > --- > > v1->v2: > > * Don't run any suspend code or resume code in this case > > Any feedback for this patch? Reviewed-by: Alex Deucher I think for S0ix and dGPUs, we probably need some additional work as well. If the user tries s2idle and the platform doesn't actually support s0ix (i.e., doesn't actually turn off the power rails), we should be using the runtime suspend routines for BACO/BOCO rather than the S3 suspend routines. Alex > > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 +++ > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 7 ++- > > 2 files changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > > index fa7375b97fd47..25e902077caf6 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > > @@ -1073,6 +1073,9 @@ bool amdgpu_acpi_is_s0ix_active(struct > > amdgpu_device *adev) > > (pm_suspend_target_state != PM_SUSPEND_TO_IDLE)) > > return false; > > > > + if (adev->asic_type < CHIP_RAVEN) > > + return false; > > + > > /* > >* If ACPI_FADT_LOW_POWER_S0 is not set in the FADT, it is > > generally > >* risky to do any special firmware-related preparations for entering > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > index 6c2fe50b528e0..1f6d93dc3d72b 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > > @@ -2414,8 +2414,10 @@ static int amdgpu_pmops_suspend(struct device > > *dev) > > > > if (amdgpu_acpi_is_s0ix_active(adev)) > > adev->in_s0ix = true; > > - else > > + else if (amdgpu_acpi_is_s3_active(adev)) > > adev->in_s3 = true; > > + if (!adev->in_s0ix && !adev->in_s3) > > + return 0; > > return amdgpu_device_suspend(drm_dev, true); > > } > > > > @@ -2436,6 +2438,9 @@ static int amdgpu_pmops_resume(struct device > > *dev) > > struct amdgpu_device *adev = drm_to_adev(drm_dev); > > int r; > > > > + if (!adev->in_s0ix && !adev->in_s3) > > + return 0; > > + > > /* Avoids registers access if device is physically gone */ > > if (!pci_device_is_present(adev->pdev)) > > adev->no_hw_access = true; > > -- > > 2.25.1
RE: [PATCH v2] drm/amd: Don't allow s0ix on APUs older than Raven
[Public] > -Original Message- > From: Limonciello, Mario > Sent: Monday, February 13, 2023 15:11 > To: amd-gfx@lists.freedesktop.org > Cc: Limonciello, Mario ; Deucher, Alexander > > Subject: [PATCH v2] drm/amd: Don't allow s0ix on APUs older than Raven > > APUs before Raven didn't support s0ix. As we just relieved some > of the safety checks for s0ix to improve power consumption on > APUs that support it but that are missing BIOS support a new > blind spot was introduced that a user could "try" to run s0ix. > > Plug this hole so that if users try to run s0ix on anything older > than Raven it will just skip suspend of the GPU. > > Fixes: cf488dcd0ab7 ("drm/amd: Allow s0ix without BIOS support") > Suggested-by: Alexander Deucher > Signed-off-by: Mario Limonciello > --- > v1->v2: > * Don't run any suspend code or resume code in this case Any feedback for this patch? > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 +++ > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 7 ++- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > index fa7375b97fd47..25e902077caf6 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c > @@ -1073,6 +1073,9 @@ bool amdgpu_acpi_is_s0ix_active(struct > amdgpu_device *adev) > (pm_suspend_target_state != PM_SUSPEND_TO_IDLE)) > return false; > > + if (adev->asic_type < CHIP_RAVEN) > + return false; > + > /* >* If ACPI_FADT_LOW_POWER_S0 is not set in the FADT, it is > generally >* risky to do any special firmware-related preparations for entering > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index 6c2fe50b528e0..1f6d93dc3d72b 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -2414,8 +2414,10 @@ static int amdgpu_pmops_suspend(struct device > *dev) > > if (amdgpu_acpi_is_s0ix_active(adev)) > adev->in_s0ix = true; > - else > + else if (amdgpu_acpi_is_s3_active(adev)) > adev->in_s3 = true; > + if (!adev->in_s0ix && !adev->in_s3) > + return 0; > return amdgpu_device_suspend(drm_dev, true); > } > > @@ -2436,6 +2438,9 @@ static int amdgpu_pmops_resume(struct device > *dev) > struct amdgpu_device *adev = drm_to_adev(drm_dev); > int r; > > + if (!adev->in_s0ix && !adev->in_s3) > + return 0; > + > /* Avoids registers access if device is physically gone */ > if (!pci_device_is_present(adev->pdev)) > adev->no_hw_access = true; > -- > 2.25.1
Re: [PATCH] drm/gem: Expose the buffer object handle to userspace last
On 20/02/2023 10:01, Christian König wrote: Am 20.02.23 um 10:55 schrieb Tvrtko Ursulin: Hi, On 14/02/2023 13:59, Christian König wrote: Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin: From: Tvrtko Ursulin Currently drm_gem_handle_create_tail exposes the handle to userspace before the buffer object constructions is complete. This allowing of working against a partially constructed object, which may also be in the process of having its creation fail, can have a range of negative outcomes. A lot of those will depend on what the individual drivers are doing in their obj->funcs->open() callbacks, and also with a common failure mode being -ENOMEM from drm_vma_node_allow. We can make sure none of this can happen by allocating a handle last, although with a downside that more of the function now runs under the dev->object_name_lock. Looking into the individual drivers open() hooks, we have amdgpu_gem_object_open which seems like it could have a potential security issue without this change. A couple drivers like qxl_gem_object_open and vmw_gem_object_open implement no-op hooks so no impact for them. A bunch of other require a deeper look by individual owners to asses for impact. Those are lima_gem_object_open, nouveau_gem_object_open, panfrost_gem_open, radeon_gem_object_open and virtio_gpu_gem_object_open. Putting aside the risk assesment of the above, some common scenarios to think about are along these lines: 1) Userspace closes a handle by speculatively "guessing" it from a second thread. This results in an unreachable buffer object so, a memory leak. 2) Same as 1), but object is in the process of getting closed (failed creation). The second thread is then able to re-cycle the handle and idr_remove would in the first thread would then remove the handle it does not own from the idr. 3) Going back to the earlier per driver problem space - individual impact assesment of allowing a second thread to access and operate on a partially constructed handle / object. (Can something crash? Leak information?) In terms of identifying when the problem started I will tag some patches as references, but not all, if even any, of them actually point to a broken state. I am just identifying points at which more opportunity for issues to arise was added. Yes I've looked into this once as well, but couldn't completely solve it for some reason. Give me a day or two to get this tested and all the logic swapped back into my head again. Managed to recollect what the problem with earlier attempts was? Nope, that's way to long ago. I can only assume that I ran into problems with the object_name_lock. Probably best to double check if that doesn't result in a lock inversion when somebody grabs the reservation lock in their ->load() callback. Hmm I don't immediately follow the connection. But I have only found radeon_driver_load_kms as using the load callback. Is there any lockdep enabled CI for that driver which could tell us if there is a problem there? Regards, Tvrtko Regards, Christian. Regards, Tvrtko Christian. References: 304eda32920b ("drm/gem: add hooks to notify driver when object handle is created/destroyed") References: ca481c9b2a3a ("drm/gem: implement vma access management") References: b39b5394fabc ("drm/gem: Add drm_gem_object_funcs") Cc: dri-de...@lists.freedesktop.org Cc: Rob Clark Cc: Ben Skeggs Cc: David Herrmann Cc: Noralf Trønnes Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: l...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: Steven Price Cc: virtualizat...@lists.linux-foundation.org Cc: spice-de...@lists.freedesktop.org Cc: Zack Rusin --- drivers/gpu/drm/drm_gem.c | 48 +++ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index aa15c52ae182..e3d897bca0f2 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -356,52 +356,52 @@ drm_gem_handle_create_tail(struct drm_file *file_priv, u32 *handlep) { struct drm_device *dev = obj->dev; - u32 handle; int ret; WARN_ON(!mutex_is_locked(>object_name_lock)); if (obj->handle_count++ == 0) drm_gem_object_get(obj); + ret = drm_vma_node_allow(>vma_node, file_priv); + if (ret) + goto err_put; + + if (obj->funcs->open) { + ret = obj->funcs->open(obj, file_priv); + if (ret) + goto err_revoke; + } + /* - * Get the user-visible handle using idr. Preload and perform - * allocation under our spinlock. + * Get the user-visible handle using idr as the _last_ step. + * Preload and perform allocation under our spinlock. */ idr_preload(GFP_KERNEL); spin_lock(_priv->table_lock); - ret = idr_alloc(_priv->object_idr, obj, 1, 0, GFP_NOWAIT); - spin_unlock(_priv->table_lock); idr_preload_end(); -
Re: [PATCH] drm/gem: Expose the buffer object handle to userspace last
Am 20.02.23 um 10:55 schrieb Tvrtko Ursulin: Hi, On 14/02/2023 13:59, Christian König wrote: Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin: From: Tvrtko Ursulin Currently drm_gem_handle_create_tail exposes the handle to userspace before the buffer object constructions is complete. This allowing of working against a partially constructed object, which may also be in the process of having its creation fail, can have a range of negative outcomes. A lot of those will depend on what the individual drivers are doing in their obj->funcs->open() callbacks, and also with a common failure mode being -ENOMEM from drm_vma_node_allow. We can make sure none of this can happen by allocating a handle last, although with a downside that more of the function now runs under the dev->object_name_lock. Looking into the individual drivers open() hooks, we have amdgpu_gem_object_open which seems like it could have a potential security issue without this change. A couple drivers like qxl_gem_object_open and vmw_gem_object_open implement no-op hooks so no impact for them. A bunch of other require a deeper look by individual owners to asses for impact. Those are lima_gem_object_open, nouveau_gem_object_open, panfrost_gem_open, radeon_gem_object_open and virtio_gpu_gem_object_open. Putting aside the risk assesment of the above, some common scenarios to think about are along these lines: 1) Userspace closes a handle by speculatively "guessing" it from a second thread. This results in an unreachable buffer object so, a memory leak. 2) Same as 1), but object is in the process of getting closed (failed creation). The second thread is then able to re-cycle the handle and idr_remove would in the first thread would then remove the handle it does not own from the idr. 3) Going back to the earlier per driver problem space - individual impact assesment of allowing a second thread to access and operate on a partially constructed handle / object. (Can something crash? Leak information?) In terms of identifying when the problem started I will tag some patches as references, but not all, if even any, of them actually point to a broken state. I am just identifying points at which more opportunity for issues to arise was added. Yes I've looked into this once as well, but couldn't completely solve it for some reason. Give me a day or two to get this tested and all the logic swapped back into my head again. Managed to recollect what the problem with earlier attempts was? Nope, that's way to long ago. I can only assume that I ran into problems with the object_name_lock. Probably best to double check if that doesn't result in a lock inversion when somebody grabs the reservation lock in their ->load() callback. Regards, Christian. Regards, Tvrtko Christian. References: 304eda32920b ("drm/gem: add hooks to notify driver when object handle is created/destroyed") References: ca481c9b2a3a ("drm/gem: implement vma access management") References: b39b5394fabc ("drm/gem: Add drm_gem_object_funcs") Cc: dri-de...@lists.freedesktop.org Cc: Rob Clark Cc: Ben Skeggs Cc: David Herrmann Cc: Noralf Trønnes Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: l...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: Steven Price Cc: virtualizat...@lists.linux-foundation.org Cc: spice-de...@lists.freedesktop.org Cc: Zack Rusin --- drivers/gpu/drm/drm_gem.c | 48 +++ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index aa15c52ae182..e3d897bca0f2 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -356,52 +356,52 @@ drm_gem_handle_create_tail(struct drm_file *file_priv, u32 *handlep) { struct drm_device *dev = obj->dev; - u32 handle; int ret; WARN_ON(!mutex_is_locked(>object_name_lock)); if (obj->handle_count++ == 0) drm_gem_object_get(obj); + ret = drm_vma_node_allow(>vma_node, file_priv); + if (ret) + goto err_put; + + if (obj->funcs->open) { + ret = obj->funcs->open(obj, file_priv); + if (ret) + goto err_revoke; + } + /* - * Get the user-visible handle using idr. Preload and perform - * allocation under our spinlock. + * Get the user-visible handle using idr as the _last_ step. + * Preload and perform allocation under our spinlock. */ idr_preload(GFP_KERNEL); spin_lock(_priv->table_lock); - ret = idr_alloc(_priv->object_idr, obj, 1, 0, GFP_NOWAIT); - spin_unlock(_priv->table_lock); idr_preload_end(); - mutex_unlock(>object_name_lock); if (ret < 0) - goto err_unref; - - handle = ret; + goto err_close; - ret = drm_vma_node_allow(>vma_node, file_priv); - if (ret) - goto err_remove; + mutex_unlock(>object_name_lock); - if (obj->funcs->open) { -
Re: [PATCH] drm/gem: Expose the buffer object handle to userspace last
Hi, On 14/02/2023 13:59, Christian König wrote: Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin: From: Tvrtko Ursulin Currently drm_gem_handle_create_tail exposes the handle to userspace before the buffer object constructions is complete. This allowing of working against a partially constructed object, which may also be in the process of having its creation fail, can have a range of negative outcomes. A lot of those will depend on what the individual drivers are doing in their obj->funcs->open() callbacks, and also with a common failure mode being -ENOMEM from drm_vma_node_allow. We can make sure none of this can happen by allocating a handle last, although with a downside that more of the function now runs under the dev->object_name_lock. Looking into the individual drivers open() hooks, we have amdgpu_gem_object_open which seems like it could have a potential security issue without this change. A couple drivers like qxl_gem_object_open and vmw_gem_object_open implement no-op hooks so no impact for them. A bunch of other require a deeper look by individual owners to asses for impact. Those are lima_gem_object_open, nouveau_gem_object_open, panfrost_gem_open, radeon_gem_object_open and virtio_gpu_gem_object_open. Putting aside the risk assesment of the above, some common scenarios to think about are along these lines: 1) Userspace closes a handle by speculatively "guessing" it from a second thread. This results in an unreachable buffer object so, a memory leak. 2) Same as 1), but object is in the process of getting closed (failed creation). The second thread is then able to re-cycle the handle and idr_remove would in the first thread would then remove the handle it does not own from the idr. 3) Going back to the earlier per driver problem space - individual impact assesment of allowing a second thread to access and operate on a partially constructed handle / object. (Can something crash? Leak information?) In terms of identifying when the problem started I will tag some patches as references, but not all, if even any, of them actually point to a broken state. I am just identifying points at which more opportunity for issues to arise was added. Yes I've looked into this once as well, but couldn't completely solve it for some reason. Give me a day or two to get this tested and all the logic swapped back into my head again. Managed to recollect what the problem with earlier attempts was? Regards, Tvrtko Christian. References: 304eda32920b ("drm/gem: add hooks to notify driver when object handle is created/destroyed") References: ca481c9b2a3a ("drm/gem: implement vma access management") References: b39b5394fabc ("drm/gem: Add drm_gem_object_funcs") Cc: dri-de...@lists.freedesktop.org Cc: Rob Clark Cc: Ben Skeggs Cc: David Herrmann Cc: Noralf Trønnes Cc: David Airlie Cc: Daniel Vetter Cc: amd-gfx@lists.freedesktop.org Cc: l...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: Steven Price Cc: virtualizat...@lists.linux-foundation.org Cc: spice-de...@lists.freedesktop.org Cc: Zack Rusin --- drivers/gpu/drm/drm_gem.c | 48 +++ 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index aa15c52ae182..e3d897bca0f2 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -356,52 +356,52 @@ drm_gem_handle_create_tail(struct drm_file *file_priv, u32 *handlep) { struct drm_device *dev = obj->dev; - u32 handle; int ret; WARN_ON(!mutex_is_locked(>object_name_lock)); if (obj->handle_count++ == 0) drm_gem_object_get(obj); + ret = drm_vma_node_allow(>vma_node, file_priv); + if (ret) + goto err_put; + + if (obj->funcs->open) { + ret = obj->funcs->open(obj, file_priv); + if (ret) + goto err_revoke; + } + /* - * Get the user-visible handle using idr. Preload and perform - * allocation under our spinlock. + * Get the user-visible handle using idr as the _last_ step. + * Preload and perform allocation under our spinlock. */ idr_preload(GFP_KERNEL); spin_lock(_priv->table_lock); - ret = idr_alloc(_priv->object_idr, obj, 1, 0, GFP_NOWAIT); - spin_unlock(_priv->table_lock); idr_preload_end(); - mutex_unlock(>object_name_lock); if (ret < 0) - goto err_unref; - - handle = ret; + goto err_close; - ret = drm_vma_node_allow(>vma_node, file_priv); - if (ret) - goto err_remove; + mutex_unlock(>object_name_lock); - if (obj->funcs->open) { - ret = obj->funcs->open(obj, file_priv); - if (ret) - goto err_revoke; - } + *handlep = ret; - *handlep = handle; return 0; +err_close: + if (obj->funcs->close) + obj->funcs->close(obj, file_priv); err_revoke: drm_vma_node_revoke(>vma_node, file_priv); -err_remove: -
Re: [PATCH v2 0/3] Resolve warnings from AMDGPU
Acked-by: Christian König for the whole series. Am 17.02.23 um 19:14 schrieb Arthur Grillo: Hi, This series resolve some of the warnings that appear when compiling AMDGPU with W=1. Each patch is focused in a specific warning. This is my First Patch for the GSoC Project Idea about increasing code coverage of the DRM code[1]. Thanks for reviewing! Best regards, Arthur Grillo [1]: https://www.x.org/wiki/DRMcoverage2023/#firstpatch --- v1 -> v2: https://lore.kernel.org/all/20230213204923.111948-1-arthurgri...@riseup.net/ - Use dm_odm_combine_mode_disabled dm_odm_combine_mode_2to1 instead of an enum casting - Maintain register read --- Arthur Grillo (3): drm/amd/display: Fix implicit enum conversion drm/amd/display: Remove unused local variables drm/amd/display: Remove unused local variables and function .../amd/display/dc/dcn10/dcn10_link_encoder.c | 3 +- .../drm/amd/display/dc/dcn201/dcn201_dpp.c| 7 .../drm/amd/display/dc/dcn201/dcn201_hwseq.c | 2 - .../gpu/drm/amd/display/dc/dcn30/dcn30_afmt.c | 2 - .../gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c | 4 -- .../drm/amd/display/dc/dcn30/dcn30_hwseq.c| 3 -- .../gpu/drm/amd/display/dc/dcn31/dcn31_apg.c | 41 --- .../drm/amd/display/dc/dcn32/dcn32_resource.c | 5 +-- .../display/dc/dcn32/dcn32_resource_helpers.c | 4 -- .../dc/dml/dcn20/display_mode_vba_20.c| 9 ++-- .../dc/dml/dcn20/display_mode_vba_20v2.c | 11 ++--- .../dc/dml/dcn21/display_mode_vba_21.c| 12 +++--- .../dc/dml/dcn31/display_rq_dlg_calc_31.c | 2 - .../dc/link/protocols/link_dp_capability.c| 4 -- 14 files changed, 19 insertions(+), 90 deletions(-)