stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Jan-Benedict Glaw <jbglaw@lug-owl.de>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH] DEC: Limit PMAX memory probing to R3k systems
Date: Fri, 4 Mar 2022 20:16:23 +0000 (GMT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2203041838380.47558@angie.orcam.me.uk> (raw)

Recent tightening of the opcode table in binutils so as to consistently 
disallow the assembly or disassembly of CP0 instructions not supported 
by the processor architecture chosen has caused a regression like below:

arch/mips/dec/prom/locore.S: Assembler messages:
arch/mips/dec/prom/locore.S:29: Error: opcode not supported on this processor: r4600 (mips3) `rfe'

in a piece of code used to probe for memory with PMAX DECstation models, 
which have non-REX firmware.  Those computers always have an R2000 CPU 
and consequently the exception handler used in memory probing uses the 
RFE instruction, which those processors use.

While adding 64-bit support this code was correctly excluded for 64-bit 
configurations, however it should have also been excluded for irrelevant 
32-bit configurations.  Do this now then, and only enable PMAX memory 
probing for R3k systems.

Reported-by: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org # v2.6.12+
---
Hi,

 I'm assuming this won't go back beyond commit 2a11c8ea20bf ("kconfig: 
Introduce IS_ENABLED(), IS_BUILTIN() and IS_MODULE()") or any backport 
will have to be rewritten to avoid IS_ENABLED.

 The original actual change named to fix ought to be commit dd82ef87e4c9 
("PROM interface rework to support a 64-bit kernel.") from the LMO repo: 
<https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git/commit/?id=dd82ef87e4c9>, 
which introduced the `prom_is_rex' macro, which guards this code.  Said 
commit predates the history of our main repository though.

 This change has actually been verified at runtime with a PMIN system 
(effectively a PMAX, but with a slower R2000 CPU) and a 4MAX+ system (an 
R4400SC-based machine), and naturally throughout the three possible build 
configurations: R3k, R4k/32-bit, R4k/64-bit.

 It took longer than expected, but oh well...  Sorry for the inconvenience 
caused.

 Please apply,

  Maciej
---
 arch/mips/dec/prom/Makefile      |    2 +-
 arch/mips/include/asm/dec/prom.h |   15 +++++----------
 2 files changed, 6 insertions(+), 11 deletions(-)

linux-dec-locore-r3000.diff
Index: linux-macro/arch/mips/dec/prom/Makefile
===================================================================
--- linux-macro.orig/arch/mips/dec/prom/Makefile
+++ linux-macro/arch/mips/dec/prom/Makefile
@@ -6,4 +6,4 @@
 
 lib-y			+= init.o memory.o cmdline.o identify.o console.o
 
-lib-$(CONFIG_32BIT)	+= locore.o
+lib-$(CONFIG_CPU_R3000)	+= locore.o
Index: linux-macro/arch/mips/include/asm/dec/prom.h
===================================================================
--- linux-macro.orig/arch/mips/include/asm/dec/prom.h
+++ linux-macro/arch/mips/include/asm/dec/prom.h
@@ -43,16 +43,11 @@
  */
 #define REX_PROM_MAGIC		0x30464354
 
-#ifdef CONFIG_64BIT
-
-#define prom_is_rex(magic)	1	/* KN04 and KN05 are REX PROMs.  */
-
-#else /* !CONFIG_64BIT */
-
-#define prom_is_rex(magic)	((magic) == REX_PROM_MAGIC)
-
-#endif /* !CONFIG_64BIT */
-
+/* KN04 and KN05 are REX PROMs, so only do the check for R3k systems.  */
+static inline bool prom_is_rex(u32 magic)
+{
+	return !IS_ENABLED(CONFIG_CPU_R3000) || magic == REX_PROM_MAGIC;
+}
 
 /*
  * 3MIN/MAXINE PROM entry points for DS5000/1xx's, DS5000/xx's and

             reply	other threads:[~2022-03-04 20:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 20:16 Maciej W. Rozycki [this message]
2022-03-07 12:21 ` [PATCH] DEC: Limit PMAX memory probing to R3k systems Thomas Bogendoerfer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2203041838380.47558@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=jbglaw@lug-owl.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=ralf@linux-mips.org \
    --cc=stable@vger.kernel.org \
    --cc=sudipm.mukherjee@gmail.com \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).