[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:29:22 +0200, Michal Wajdeczko  
<michal.wajdeczko at intel.com> wrote:

> 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.

one more thought on debugfs: we are dumping there raw register value,
not just single bit that holds authentication status (and auth bit is 7),
so I'm not sure why do you want to link that value with getparam value?

Michal

>> 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