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

[Michal Wajdeczko]

On 28.02.2020 12:33, Joonas Lahtinen wrote:
>>>>>>> ------------------+----------
>>>>>>>    HuC state       | option B
>>>>>>> ------------------+----------
>>>>>>> no HuC hardware   | -ENODEV
>>>>>>> GuC fw disabled   | -EOPNOTSUPP -> user decision, why error?
>>>>>>> HuC fw disabled   | -EOPNOTSUPP -> user decision, why error?
>>>>>>> HuC fw missing    | -ENOEXEC
>>>>>>> HuC fw error      | -ENOEXEC
>>>>>>> HuC fw fail       |    0        -> unlikely, but still fw/hw error
>>>>>>> HuC authenticated |    1
>>>>>>> ------------------+----------
>>>>>>>
>>>>>>> On other hand, option A treats all error conditions as errors, leaving
>>>>>>> status codes only for normal operations: disabled(0)/authenticated(1):
>>>>>>>
>>>>>>> ------------------+----------
>>>>>>>    HuC state       | option A
>>>>>>> ------------------+----------
>>>>>>> no HuC hardware   | -ENODEV  -> you shouldn't ask
>>>>>>> GuC fw disabled   |     0    -> user decision, not an error
>>>>>>> HuC fw disabled   |     0    -> user decision, not an error
>>>>>>> HuC fw missing    | -ENOPKG  -> fw not installed correctly
>>>>>>> HuC fw error      | -ENOEXEC -> bad/wrong fw
>>>>>>> HuC fw fail       | -EACCES  -> fw/hw error
>>>>>>> HuC authenticated |     1
>>>>>>> ------------------+----------
> 
> Let's go with Option B here.

Tony was ok with option A...

> 
> It correctly reports anything as error if it precedes
> the actual action of authentication and prevents it from
> happening.

Option A do the same, including correctly reporting corrupted/wrong
firmware as error (as this is the most likely reason that prevents
successful HuC authentication on given platform).

The main difference here is user decision to disable HuC, that is now
treated as the only one non-error reason that HuC is not available for use.

> 
> So the result one gets is 0/1 is for the authentication
> status which is the original intent here. 

I'm not sure that from user POV original intent was to explicitly check
HuC authentication status but rather if HuC is available for use.

Our redundant [1] check of fw authentication status during this ioctl is
just internal detail, not necessary something user was interested from
this action.

Michal

[1] as we are already checking this register during HuC fw load