This symbol was removed in early 2025 but 2 dangling references to it
were missed. Delete them now.

Fixes: f388f60ca904 ("x86/cpu: Drop configuration options for early 64-bit CPUs")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org

 arch/x86/Kconfig.cpufeatures |    2 +-
 arch/x86/Makefile_32.cpu     |    6 ------
 2 files changed, 1 insertion(+), 7 deletions(-)

--- linux-next-20251219.orig/arch/x86/Kconfig.cpufeatures
+++ linux-next-20251219/arch/x86/Kconfig.cpufeatures
@@ -38,7 +38,7 @@ config X86_REQUIRED_FEATURE_ALWAYS
 
 config X86_REQUIRED_FEATURE_NOPL
 	def_bool y
-	depends on X86_64 || X86_P6_NOP
+	depends on X86_64
 
 config X86_REQUIRED_FEATURE_CX8
 	def_bool y
--- linux-next-20251219.orig/arch/x86/Makefile_32.cpu
+++ linux-next-20251219/arch/x86/Makefile_32.cpu
@@ -42,9 +42,3 @@ cflags-$(CONFIG_MGEODE_LX)	+= $(call cc-
 # add at the end to overwrite eventual tuning options from earlier
 # cpu entries
 cflags-$(CONFIG_X86_GENERIC) 	+= $(call tune,generic,$(call tune,i686))
-
-# Bug fix for binutils: this option is required in order to keep
-# binutils from generating NOPL instructions against our will.
-ifneq ($(CONFIG_X86_P6_NOP),y)
-cflags-y			+= $(call cc-option,-Wa$(comma)-mtune=generic32,)
-endif

On 12/28/25 15:27, Randy Dunlap wrote:
> -# Bug fix for binutils: this option is required in order to keep
> -# binutils from generating NOPL instructions against our will.
> -ifneq ($(CONFIG_X86_P6_NOP),y)
> -cflags-y			+= $(call cc-option,-Wa$(comma)-mtune=generic32,)
> -endif

Isn't this adding the cflags when CONFIG_X86_P6_NOP is _not_ =y? Isn't
this the case now that X86_P6_NOP has been zapped from the tree? Doesn't
that make the straightforward "fix" to just remove the reference to
CONFIG_X86_P6_NOP, but leave the cflags-y like this?

-ifneq ($(CONFIG_X86_P6_NOP),y)
 cflags-y	+= $(call cc-option,-Wa$(comma)-mtune=generic32,)
-endif

It's either that or I'm reading the Makefile logic backwards (wouldn't
be the first time :).

On 1/5/26 13:02, Dave Hansen wrote:
> It's either that or I'm reading the Makefile logic backwards (wouldn't
> be the first time 🙂.

Oh, and I'd also randomly guess that this binutils "bug" has long since
been fixed or become irrelevant. So this might be a bit silly to even
discuss.

But, let's at least make sure to document in the changelog what we
_might_ be breaking and not pretend that this has zero consequences.

On Mon, Jan 5, 2026, at 22:05, Dave Hansen wrote:
> On 1/5/26 13:02, Dave Hansen wrote:
>> It's either that or I'm reading the Makefile logic backwards (wouldn't
>> be the first time 🙂.

I saws the same thing, saw your email before I sent my reply

> Oh, and I'd also randomly guess that this binutils "bug" has long since
> been fixed or become irrelevant. So this might be a bit silly to even
> discuss.
>
> But, let's at least make sure to document in the changelog what we
> _might_ be breaking and not pretend that this has zero consequences.

In all binutils versions I can find (2.36.1+), calling 'as --32'
uses the portable NOP instructions for a 16 byte nop:

   0:	90                   	nop
   1:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi
   8:	8d b4 26 00 00 00 00 	lea    0x0(%esi,%eiz,1),%esi
   f:	90                   	nop

while passing either --64 or -mtune=generic64 makes it use nopl,
same for -mtime=pentium4 or others:

   0:	90                   	nop
   1:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%eax,%eax,1)
   8:	00 00 00 00 
   c:	0f 1f 40 00          	nopl   0x0(%eax)

According to the description of 28f7e66fc1da ("x86: prevent
binutils from being "smart" and generating NOPLs for us"),
gcc-4.3 and later no longer cause the problem, as they don't
pass down -mtune=. I confirmed this with gcc-8 and gcc-15.

      Arnd

On 29.12.25 г. 1:27 ч., Randy Dunlap wrote:
> This symbol was removed in early 2025 but 2 dangling references to it
> were missed. Delete them now.
> 
> Fixes: f388f60ca904 ("x86/cpu: Drop configuration options for early 64-bit CPUs")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>