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
