[Intel-gfx] [PATCH 2/2] drm/i915: Swap ret and status returned from skl_pcode_request
Govindapillai, Vinod
vinod.govindapillai at intel.com
Fri Apr 8 17:41:40 UTC 2022
On Fri, 2022-04-08 at 15:52 +0300, Stanislav Lisovskiy wrote:
> If ret isn't zero, it is almost for sure ETIMEDOUT, because
> we use it in wait_for macro which does continuous retries
> until timeout is reached. If we still ran out of time and
> retries, we most likely would be interested in getting status,
> to understand what was the actual error propagated from PCode,
> rather than to find out that we had a time out, which is anyway
> quite obvious, if the function fails.
>
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy at intel.com>
> ---
> drivers/gpu/drm/i915/intel_pcode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pcode.c b/drivers/gpu/drm/i915/intel_pcode.c
> index fb6c43e8a02f..a68eaf510784 100644
> --- a/drivers/gpu/drm/i915/intel_pcode.c
> +++ b/drivers/gpu/drm/i915/intel_pcode.c
> @@ -202,7 +202,7 @@ int skl_pcode_request(struct drm_i915_private *i915, u32 mbox, u32 request,
>
> out:
> mutex_unlock(&i915->sb_lock);
> - return ret ? ret : status;
> + return ret ? status : ret;
Isnt this equivalent to "return status"
When we were discussing this, I felt this is good.
But on further check with the functions gen7_check_mailbox_status(), is there a possibility that
status = 0 but "request & reply_mask) != reply" for the "default" case handling?
In that cast _wait_for() will be timedout with ret = ETimedOut but "status" = 0
Is that real scenario?
> #undef COND
> }
>
More information about the Intel-gfx
mailing list