On Thu, 2023-05-25 at 09:56 -0700, Ceraolo Spurio, Daniele wrote:
> On 5/24/2023 10:14 PM, Teres Alexis, Alan Previn wrote:
> > On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote:
alan:snip
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> > > @@ -17,6 +17,9 @@ struct intel_gsc_uc {
> > > struct intel_uc_fw fw;
> > >
> > > /* GSC-specific additions */
> > > + struct intel_uc_fw_ver release;
> > > + u32 security_version;
> > alan: for consistency and less redundancy, can't we add "security_version"
> > into 'struct intel_uc_fw_ver' (which is zero for firmware that doesn't
> > have it). That way, intel_gsc_uc can re-use intel_uc_fw.file_selected
> > just like huc?
>
> I'm not sure what you mean by re-using intel_uc_fw.file_selected. Is
> that for the call from intel_uc_fw_version_from_meu_manifest? I'm
> purposely not doing that. Note that the GSC has 3 versions:
>
> Release version (incremented with each build and encoded in the header)
> Security version (also encoded in the header)
> Compatibility version (queried via message to the GSC)
>
> The one we care about for communicating with the GSC is the last one, so
> that's the one I stored in intel_uc_fw.file_selected (in the next
> patch). The other 2 versions are not strictly required to use the GSC
> and we only fetch them for debug purposes, so if something goes wrong we
> know exactly what we've loaded.
>
> Daniele
alan: okay thanks - seeing that now in the next patch... (and i also forgot that
the GSC release version doesnt reflect interface versioning in anyway like GuC does).
In that case, above additional versions are fine. Would definitely love to see
additional comments under "GSC-specific-additions" that explain those 3 versioning
items and what we care about as how you have explained here.
