[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y4qqmcM8iijFaemO@a4bf019067fa.jf.intel.com>
Date: Fri, 2 Dec 2022 17:47:05 -0800
From: Ashok Raj <ashok.raj@...el.com>
To: Sohil Mehta <sohil.mehta@...el.com>
CC: Borislav Petkov <bp@...en8.de>, X86-kernel <x86@...nel.org>,
"LKML Mailing List" <linux-kernel@...r.kernel.org>,
Dave Hansen <dave.hansen@...el.com>,
Tony Luck <tony.luck@...el.com>, <alison.schofield@...el.com>,
<reinette.chatre@...el.com>, Ashok Raj <ashok.raj@...el.com>
Subject: Re: [Patch V1 2/7] x86/microcode/intel: Remove retries on early
microcode load
On Fri, Dec 02, 2022 at 03:53:52PM -0800, Mehta, Sohil wrote:
> On 11/29/2022 1:08 PM, Ashok Raj wrote:
> > -
> > - if (apply_microcode_early(&uci, true)) {
> > - /* Mixed-silicon system? Try to refetch the proper patch: */
> > - *iup = NULL;
> > -
> > - goto reget;
> > - }
> > + apply_microcode_early(&uci, true);
>
> After this change, none of the callers of apply_microcode_early() check the
> return code.
>
> In future, do we expect callers to care about the return code? The rest
> patches in this series don't seem to suggest so. Also, the expected error
> printing happens in the function itself.
>
> Should the return type for apply_microcode_early() be changed to void (in a
> follow-up patch)?
Good idea.. But I think its early, the return code could be used for
something useful. I have some additional cleanup patches that I need to
fixup and we could use this for real.
For e.g. early loading failures are now reported by each vendor, if we can
consolidate this, we could do it more at a core level, but I'm worried it
might be too much change right now, and this can wait its turn.
Cheers,
Ashok
Powered by blists - more mailing lists