Skip to contentSkip to conversation

use sparc64 version of prom/printf.c

PATCH Applied Robert Reif 3 participants 6 messages Dec 7, 2008 – Dec 8, 2008 SPARC + UltraSPARC (sparc/sparc64)

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 use sparc64 version of prom/printf.c

Use sparc64 version of prom/printf.c.

The only differences for sparc32 is that prom_printf is no longer exported for modules which should be OK.

 arch/sparc/include/asm/oplib_32.h |    2 +-
 arch/sparc/prom/Makefile          |    2 +-
 arch/sparc/prom/printf.c          |   47 ++++++++++++++++++++++++++++++++++++
 arch/sparc/prom/printf_32.c       |   48 -------------------------------------
 arch/sparc/prom/printf_64.c       |   47 ------------------------------------
 5 files changed, 49 insertions(+), 97 deletions(-)
 create mode 100644 arch/sparc/prom/printf.c
 delete mode 100644 arch/sparc/prom/printf_32.c
 delete mode 100644 arch/sparc/prom/printf_64.c
arch/sparc/include/asm/oplib_32.h +1 -1
index 3bdf56f..73d4552 100644
@@ -136,7 +136,7 @@ extern char prom_getchar(void);
 extern void prom_putchar(char character);
 
 /* Prom's internal routines, don't use in kernel/boot code. */
-extern void prom_printf(char *fmt, ...);
+extern void prom_printf(const char *fmt, ...);
 extern void prom_write(const char *buf, unsigned int len);
 
 /* Multiprocessor operations... */
arch/sparc/prom/Makefile +1 -1
index f8e0278..1b8c073 100644
@@ -15,7 +15,7 @@ lib-$(CONFIG_SPARC32) += palloc.o
 lib-$(CONFIG_SPARC32) += ranges.o
 lib-$(CONFIG_SPARC32) += segment.o
 lib-y                 += console_$(BITS).o
-lib-y                 += printf_$(BITS).o
+lib-y                 += printf.o
 lib-y                 += tree_$(BITS).o
 lib-$(CONFIG_SPARC64) += p1275.o
 lib-$(CONFIG_SPARC64) += cif.o
arch/sparc/prom/printf.c new file +47 -0

47 lines not on this page · raw message

arch/sparc/prom/printf_32.c deleted +0 -48

48 lines not on this page · raw message

arch/sparc/prom/printf_64.c deleted +0 -47

47 lines not on this page · raw message

#1 lore raw

Hi Robert.

Quoted 4 lines · Robert Reif

Use sparc64 version of prom/printf.c.

The only differences for sparc32 is that prom_printf is no longer exported for modules which should be OK.

cyber200fb uses prom_prinf and can be built as a module. From Kconfig:

config FB_CYBER2000

        tristate "CyberPro 2000/2010/5000 support"
        depends on FB && PCI && (BROKEN || !SPARC64)

So it looks to me we should keep the EXPORT.

Sam

#2 lore raw
In reply to Robert Reif
Quoted 8 lines · Sam Ravnborg

Hi Robert.

Quoted 4 lines · Robert Reif

Use sparc64 version of prom/printf.c.

The only differences for sparc32 is that prom_printf is no longer exported for modules which should be OK.

Quoted 8 lines

cyber200fb uses prom_prinf and can be built as a module.

Quoted 1 line

From Kconfig:

config FB_CYBER2000

        tristate "CyberPro 2000/2010/5000 support"
        depends on FB && PCI && (BROKEN || !SPARC64)

So it looks to me we should keep the EXPORT.

And a test bult with your patch confirmed this:
MODPOST 5 modules
ERROR: "prom_printf" [drivers/video/cyber2000fb.ko] undefined! make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2

Please redo your patch with the EXPORT kept.
I cannot see that it hurts sparc64 so no need to do it conditionally.

Sam

#3 lore raw
In reply to Robert Reif
Quoted 13 lines · Sam Ravnborg

Hi Robert.

Quoted 5 lines · Robert Reif

Use sparc64 version of prom/printf.c.

The only differences for sparc32 is that prom_printf is no longer exported for modules which should be OK.

cyber200fb uses prom_prinf and can be built as a module.

Quoted 1 line

From Kconfig:

Quoted 9 lines

config FB_CYBER2000

        tristate "CyberPro 2000/2010/5000 support"
        depends on FB && PCI && (BROKEN || !SPARC64)

So it looks to me we should keep the EXPORT.

Sam

Since this is the only driver that can use prom_printf in a module and it appears that the only sparc system that uses it is an unreleased version of the java station, wouldn't it be better to change the prom_printf to a printk in this driver?

I didn't see this problem because I don't compile with pci support because it's one of the things I have to disable to get a kernel small enough to actually load.

maintainer
#4 lore raw
In reply to Robert Reif

From: Robert Reif <[email protected]>
Date: Sun, 07 Dec 2008 20:53:40 -0500

Quoted 19 lines
Quoted 18 lines · Sam Ravnborg

Hi Robert.

Quoted 4 lines · Robert Reif

Use sparc64 version of prom/printf.c.

The only differences for sparc32 is that prom_printf is no longer exported for modules which should be OK.

cyber200fb uses prom_prinf and can be built as a module.

Quoted 1 line

From Kconfig:

config FB_CYBER2000

        tristate "CyberPro 2000/2010/5000 support"
        depends on FB && PCI && (BROKEN || !SPARC64)

So it looks to me we should keep the EXPORT.

Quoted 7 lines
Quoted 3 lines

Sam

Since this is the only driver that can use prom_printf in a module and it appears that the only sparc system that uses it is an unreleased version of the java station, wouldn't it be better to change the prom_printf to a printk in this driver?

That's a reasonable way to handle this problem.

The reason that prom_printf() tends to be widespread is that long ago we didn't have a "-p" kernel boot command line option which is useful for debugging console driver failures.

Otherwise you don't get the message so have no idea what has gone wrong :)

I'll sort this out, thanks guys.