[PATCH 10/14] ps3: get firmware version

Output the PS3 firmware version to dmesg and /proc/cpuinfo.

Signed-off-by: Geoff Levand <redacted>

---
 arch/powerpc/platforms/ps3/setup.c |   30 +++++++++++++++++++++++++++++-
 include/asm-powerpc/ps3.h          |    9 +++++++++
 2 files changed, 38 insertions(+), 1 deletion(-)

--- ps3-linux-dev.orig/arch/powerpc/platforms/ps3/setup.c
+++ ps3-linux-dev/arch/powerpc/platforms/ps3/setup.c

@@ -32,6 +32,7 @@
 #include <asm/udbg.h>
 #include <asm/prom.h>
 #include <asm/lv1call.h>
+#include <asm/ps3.h>
 
 #include "platform.h"
 

@@ -41,9 +42,29 @@
 #define DBG(fmt...) do{if(0)printk(fmt);}while(0)
 #endif
 
+int ps3_get_firmware_version(struct ps3_firmware_version *v)
+{
+	int result = lv1_get_version_info(&v->raw);
+
+	if(result) {
+		memset(v, 0, sizeof(struct ps3_firmware_version));
+		return -1;
+	}
+
+	v->rev = v->raw & 0xffff;
+	v->minor = (v->raw >> 16) & 0xffff;
+	v->major = (v->raw >> 32) & 0xffff;
+
+	return result;
+}
+EXPORT_SYMBOL_GPL(ps3_get_firmware_version);
+
 static void ps3_show_cpuinfo(struct seq_file *m)
 {
-	seq_printf(m, "machine\t\t: %s\n", ppc_md.name);
+	struct ps3_firmware_version v;
+
+	ps3_get_firmware_version(&v);
+	seq_printf(m, "firmware\t: %u.%u.%u\n", v.major, v.minor, v.rev);
 }
 
 static void ps3_power_save(void)

@@ -74,8 +95,14 @@ static void ps3_panic(char *str)
 
 static void __init ps3_setup_arch(void)
 {
+	struct ps3_firmware_version v;
+
 	DBG(" -> %s:%d\n", __func__, __LINE__);
 
+	ps3_get_firmware_version(&v);
+	printk(KERN_INFO "PS3 firmware version %u.%u.%u\n", v.major, v.minor,
+		v.rev);
+
 	ps3_spu_set_platform();
 	ps3_map_htab();
 

@@ -89,6 +116,7 @@ static void __init ps3_setup_arch(void)
 
 	ppc_md.power_save = ps3_power_save;
 
+
 	DBG(" <- %s:%d\n", __func__, __LINE__);
 }
 
--- ps3-linux-dev.orig/include/asm-powerpc/ps3.h
+++ ps3-linux-dev/include/asm-powerpc/ps3.h

@@ -27,6 +27,15 @@
 #include <linux/device.h>
 #include <scsi/scsi.h>
 
+struct ps3_firmware_version {
+	u64 raw;
+	unsigned int major;
+	unsigned int minor;
+	unsigned int rev;
+};
+
+int ps3_get_firmware_version(struct ps3_firmware_version *v);
+
 /**
  * struct ps3_device_id - HV bus device identifier from the system repository
  * @bus_id: HV bus id, {1..} (zero invalid)

On Wed, 2007-01-24 at 18:40 -0800, Geoff Levand wrote:

+struct ps3_firmware_version {
+	u64 raw;
+	unsigned int major;
+	unsigned int minor;
+	unsigned int rev;
+};

Wouldn't it be better to have a union here ?

Ben

On Thursday 25 January 2007 03:40, Geoff Levand wrote:

Output the PS3 firmware version to dmesg and /proc/cpuinfo.

Signed-off-by: Geoff Levand <redacted>

Acked-by: Arnd Bergmann <redacted>

I agree with benh that you should avoid the copy of individual fields
inside of the struct ps3_firmware_version, since you can directly
read into a 

struct ps3_firmware_version {
	u16 pad;
	u16 major;
	u16 minor;
	u16 rev;
};

On Wed, Jan 24, 2007 at 06:40:17PM -0800, Geoff Levand wrote:

Output the PS3 firmware version to dmesg and /proc/cpuinfo.

Do we really need to bloat /proc/cpuinfo with more information that's
totally platform-specific?  The file is enough of a mess already..

Christoph Hellwig wrote:

On Wed, Jan 24, 2007 at 06:40:17PM -0800, Geoff Levand wrote:

quoted

Output the PS3 firmware version to dmesg and /proc/cpuinfo.

Do we really need to bloat /proc/cpuinfo with more information that's
totally platform-specific?  The file is enough of a mess already..

I wanted to make the firmware version available to user space utilities, so
for example, I plan to make a utility to write the kernel to flash.  If the
utility can query the firmware version, it can prompt the user that a firmware
update would allow the kernel to take advantage of some new or updated feature.
Without this, the only way to notify the user is with a message to the system
log when the new kernel is running.

Anyway, that is the need, the question is where to make it available.  I thought
/proc/cpuinfo already has the platform type (coming from the generic powerpc
code), so it would be convenient for utilities to have the firmware version
there too.  I don't think parsing the dmsg is an option for minimal
configs like bootloaders and distro installers, as they may not keep the boot
messages around, and in general doesn't seem a reliable way.  If you can make
a suggestion, I'd like to hear it.

-Geoff

Anyway, that is the need, the question is where to make it available.  I thought
/proc/cpuinfo already has the platform type (coming from the generic powerpc
code), so it would be convenient for utilities to have the firmware version
there too.  I don't think parsing the dmsg is an option for minimal
configs like bootloaders and distro installers, as they may not keep the boot
messages around, and in general doesn't seem a reliable way.  If you can make
a suggestion, I'd like to hear it.

Yeah, /proc/cpuinfo is actually a fairly convenient place for that...

Ben.

Benjamin Herrenschmidt wrote:

quoted

Anyway, that is the need, the question is where to make it
available.  I thought /proc/cpuinfo already has the platform type
(coming from the generic powerpc code), so it would be convenient
for utilities to have the firmware version there too.  I don't
think parsing the dmsg is an option for minimal configs like
bootloaders and distro installers, as they may not keep the boot
messages around, and in general doesn't seem a reliable way.  If
you can make a suggestion, I'd like to hear it.

Yeah, /proc/cpuinfo is actually a fairly convenient place for that...

Other firmwares provide a property in the device tree with version
information, for example on Power5:

$ lsprop /proc/device-tree/openprom/ibm,fw-vernum_encoded
/proc/device-tree/openprom/ibm,fw-vernum_encoded "SF225_096"

Nathan Lynch wrote:

Benjamin Herrenschmidt wrote:

quoted

quoted

Anyway, that is the need, the question is where to make it
available.  I thought /proc/cpuinfo already has the platform type
(coming from the generic powerpc code), so it would be convenient
for utilities to have the firmware version there too.  I don't
think parsing the dmsg is an option for minimal configs like
bootloaders and distro installers, as they may not keep the boot
messages around, and in general doesn't seem a reliable way.  If
you can make a suggestion, I'd like to hear it.

Yeah, /proc/cpuinfo is actually a fairly convenient place for that...

Other firmwares provide a property in the device tree with version
information, for example on Power5:

But this firmware does not.  The kernel must do it sometime after
startup.  I don't see any reason why the kernel should try to
emulate the behavior of firmware on some other platform.

-Geoff

Geoff Levand wrote:

Nathan Lynch wrote:

quoted

Benjamin Herrenschmidt wrote:

quoted

quoted

Anyway, that is the need, the question is where to make it
available.  I thought /proc/cpuinfo already has the platform type
(coming from the generic powerpc code), so it would be convenient
for utilities to have the firmware version there too.  I don't
think parsing the dmsg is an option for minimal configs like
bootloaders and distro installers, as they may not keep the boot
messages around, and in general doesn't seem a reliable way.  If
you can make a suggestion, I'd like to hear it.

Yeah, /proc/cpuinfo is actually a fairly convenient place for that...

Other firmwares provide a property in the device tree with version
information, for example on Power5:

But this firmware does not.  The kernel must do it sometime after
startup.  I don't see any reason why the kernel should try to
emulate the behavior of firmware on some other platform.

Actually, now that I think about it, your suggestion seems like the best
way to do it :-) 

Since /proc/device-tree/model gives the model, and I can arrange for
/proc/device-tree/firmware to give a firmware version.  I'll just need to
add a property to the tree after bootup.

-Geoff

Actually, now that I think about it, your suggestion seems like the best
way to do it :-) 

Since /proc/device-tree/model gives the model, and I can arrange for
/proc/device-tree/firmware to give a firmware version.  I'll just need to
add a property to the tree after bootup.

In fact, the most logical place to do that is in the kboot wrapper, when
the tree is created initially. That way, it will be naturally passed
from kernel to kernel via kexec.

The zImage is built with a library to hack at the device-tree so it
should be trivial to do it there.

Ben.