[Intel-gfx] [PATCH v2] drm/i915/huc: Don't try to check HuC status if it's not loaded

[Michal Wajdeczko]

On Fri, 24 May 2019 15:10:58 +0200, Joonas Lahtinen  
<joonas.lahtinen at linux.intel.com> wrote:

> Quoting Ye, Tony (2019-05-22 14:32:41)
>>  From UMD perspective, when HuC is not working as expected, usually we
>> look into the kernel log and i915_huc_load_status debugfs to find out
>> why it's not working. It will be helpful to know the reason of the
>> failure from the error code. The typically failures we encountered are
>> "HuC FW not loaded (FW not built into initramfs)" and "HuC FW
>> authentication failed".
>>
>> And it looks clearer to me if we can define 0 as "disabled by user" to
>> distinguish it from other errors like ENODEV, ENOPKG and "not
>> authenticated".
>
> Suggestion by Chris for 0/1 for huc_status makes sense to me to reflect  
> if
> HuC authentication was succesful or not. Mostly because the name of the
> debugfs and func is huc_status. It also nicely maps to a register.

But this entry is not limited to "huc authentication status", as then
we should even not try to introduce new errors, but return 0 to match
register.

On other hand, under normal conditions, we expect HuC to be authenticated
and running or explicitly disabled by the user. Other cases are unexpected
error conditions. I would expect from the ABI that these error conditions
will be reported as errors. For me ABI is something more than reg value.

>
> One could have huc_enabled which would then collapse to easy 0/1, but  
> that'd
> be bit redundant.

that's why we wanted to provide more details in new error codes for
existing GETPARAM, without breaking current usages.

Michal

>
> Regards, Joonas