Re: [PATCH 0/2] x86/fred: enable FRED by default

[H. Peter Anvin]

On 2026-03-24 12:53, Borislav Petkov wrote:
> On Tue, Mar 24, 2026 at 10:19:00AM -0700, Sohil Mehta wrote:
>> With FRED proposed to be default on, I think we should match the above
>> and only let fred=off disable it. All other inputs should be ignored.
> 
> So we have only said so far that "on" enables FRED and "off" disables it. And
> we can do that by carving out the FRED option parsing into a separate function
> and acting only on those and ignoring the rest.
> 
> All those other fred=X things should simply be ignored.
> 

Well, that's easy. I just didn't want to change existing behavior. If that is
your policy decision then I'm fine with that.

We don't even need a new function; it is actually an even smaller change to
the code than this patchset version, so I'll rev the patchset.

It WOULD be good to have a global function to parse boolean arguments in a
kernel-coherent manner, but that is out of scope for this patchset.

>> I agree. In general, we shouldn't even need special command line
>> parameters to *disable* features. clearcpuid=fred would have been
>> equivalent to fred=off if it didn't taint the kernel. I don't know the
>> exact history about why the taint is needed.
> 
> Because you should not poke at clearing CPUID features unless you know what
> you're doing and this cmdline option should not exist at all. But we have it
> so...
> 

Well, it is useful for testing code paths for legacy hardware.

	-hpa