On Fri, 24 May 2019 15:29:22 +0200, Michal Wajdeczko
<michal.wajdeczko@xxxxxxxxx> wrote:
On Fri, 24 May 2019 15:10:58 +0200, Joonas Lahtinen
<joonas.lahtinen@xxxxxxxxxxxxxxx> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
