From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
"Fosha, Robert M" <robert.m.fosha@intel.com>,
"Ye, Tony" <tony.ye@intel.com>,
Chris Wilson <chris@chris-wilson.co.uk>,
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/huc: Fix error reported by I915_PARAM_HUC_STATUS
Date: Fri, 28 Feb 2020 14:44:40 +0100 [thread overview]
Message-ID: <a30d703c-a9c6-7b19-f636-b8a8def73e8d@intel.com> (raw)
In-Reply-To: <158288959705.8183.10803900434216996205@jlahtine-desk.ger.corp.intel.com>
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-02-28 13:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-22 19:48 [Intel-gfx] [PATCH] drm/i915/huc: Fix error reported by I915_PARAM_HUC_STATUS Michal Wajdeczko
2020-01-22 23:52 ` Daniele Ceraolo Spurio
2020-01-23 15:02 ` Chris Wilson
2020-01-23 15:38 ` Michal Wajdeczko
2020-01-23 15:51 ` Chris Wilson
2020-01-26 17:41 ` Michal Wajdeczko
2020-02-05 0:43 ` Ye, Tony
2020-02-11 17:53 ` Fosha, Robert M
2020-02-11 19:57 ` Michal Wajdeczko
2020-02-11 21:54 ` Fosha, Robert M
2020-02-21 3:56 ` Ye, Tony
2020-02-28 11:33 ` Joonas Lahtinen
2020-02-28 13:44 ` Michal Wajdeczko [this message]
2020-01-23 18:26 ` Ye, Tony
2020-01-23 18:43 ` Michal Wajdeczko
2020-01-23 19:50 ` Ye, Tony
2020-01-23 2:43 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
2020-01-23 14:57 ` Michal Wajdeczko
2020-01-23 18:12 ` [Intel-gfx] [PATCH] " Ye, Tony
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a30d703c-a9c6-7b19-f636-b8a8def73e8d@intel.com \
--to=michal.wajdeczko@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniele.ceraolospurio@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=robert.m.fosha@intel.com \
--cc=tony.ye@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox