[Intel-gfx] [PATCH] drm/i915/huc: Fix error reported by I915_PARAM_HUC_STATUS

[Ye, Tony]

On 1/23/2020 7:38 AM, Michal Wajdeczko wrote:
> On Thu, 23 Jan 2020 16:02:17 +0100, Chris Wilson 
> <chris at chris-wilson.co.uk> wrote:
> 
>> Quoting Daniele Ceraolo Spurio (2020-01-22 23:52:33)
>>>
>>>
>>> On 1/22/20 11:48 AM, Michal Wajdeczko wrote:
>>> >  From commit 84b1ca2f0e68 ("drm/i915/uc: prefer intel_gt over i915
>>> > in GuC/HuC paths") we stopped using HUC_STATUS error -ENODEV only
>>> > to indicate lack of HuC hardware and we started to use this error
>>> > also for all other cases when HuC was not in use or supported.
>>> >
>>> > Fix that by relying again on HAS_GT_UC macro, since currently
>>> > used function intel_huc_is_supported() is based on HuC firmware
>>> > support which could be unsupported also due to force disabled
>>> > GuC firmware.
>>> >
>>> > Signed-off-by: Michal Wajdeczko <michal.wajdeczko at intel.com>
>>> > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
>>> > Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
>>> > Cc: Tony Ye <tony.ye at intel.com>
>>>
>>> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
>>
>> Once upon a time did you (Michal) not argue we should indicate the lack
>> of firmware in the error code? Something like
>>
>> if (!HAS_GT_UC(gt->i915))
>>     return -ENODEV;
>>
>> if (!intel_huc_is_supported(huc))
>>     return -ENOEXEC;
> 
> Yes, we discussed this here [1] together with [2] but we didn't
> conclude our discussion due to different opinions on how represent
> some states, in particular "manually disabled" state.
> 
> In this patch I just wanted to restore old notation.
> 
> But we can start new discussion, here is summary:
> 
> ------------------+----------+----------+----------
>   HuC state        | today*   | option A | option B
> ------------------+----------+----------+----------
> no HuC hardware   | -ENODEV  | -ENODEV  | -ENODEV
> GuC fw disabled   |   0      |     0    | -EOPNOTSUPP
> HuC fw disabled   |   0      |     0    | -EOPNOTSUPP
> HuC fw missing    |   0      | -ENOPKG  | -ENOEXEC
> HuC fw error      |   0      | -ENOEXEC | -ENOEXEC
> HuC fw fail       |   0      | -EACCES  |    0
> HuC authenticated |   1      |     1    |    1
> ------------------+----------+----------+----------
> 
> Note that all above should be compatible with media driver,
> which explicitly looks for no error and value 1

 From user space perspective, e.g. the new igt huc_copy, option B looks 
like this:

    pg.param = I915_PARAM_HUC_STATUS;
    pg.value = &val;
    ret = ioctl(fd, DRM_IOCTL_I915_GETPARAM, &pg);

------------------+----------+----------+------------+----------
   HuC state       | ret      | pg.value |  errno     | huc_copy
------------------+----------+----------+------------+----------
no HuC hardware   |  -1      |     0    | -ENODEV    | SKIP
GuC fw disabled   |  -1      |     0    | -EOPNOTSUPP| SKIP
HuC fw disabled   |  -1      |     0    | -EOPNOTSUPP| SKIP
HuC fw missing    |  -1      |     0    | -ENOEXEC   | FAIL
HuC fw error      |  -1      |     0    | -ENOEXEC   | FAIL
HuC fw fail       |   0      |     0    |    0       | FAIL
HuC authenticated |   0      |     1    |    0       | continue
------------------+----------+----------+------------+----------

It can distinguish the SKIP and FAIL conditions. But looks not elegant 
enough.
The pg.value is wasted as it is not pushed back to user space when 
intel_huc_check_status() < 0.

	case I915_PARAM_HUC_STATUS:
		value = intel_huc_check_status(&i915->gt.uc.huc);
		if (value < 0)
			return value;
		break;

Regards,
Tony
> 
> Michal
> 
> [1] https://patchwork.freedesktop.org/patch/306419/?series=61001&rev=1
> [2] https://patchwork.freedesktop.org/series/60800/#rev1