[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Eduardo Valentin]

Hello all,

Here is the version 5 of the change to export OMAP data to userspace
(name, revision, id code, production id and die id).

Basically, this version is still attempting to create a new file under /proc.
It is the /proc/socinfo, which should be used to export bits which are SoC specific
(not CPU related, nor machine related).

So, differences between previous version are:
- merged patch 02/04 with 03/04 to avoid compilation breakages.
- simplified the seq_file usage by using the single_open and single_release functions
- exported a function to register a seq_operation .show callback
- adapted the changes accordingly

As usual, comments are welcome.

BR,

-------------------------------------------------------------------------------
v4:

Here is the patch set to export OMAP id code, production id and die id.
The history of this change is as follows:

1. First attempt tried adding those data under sysfs node. Original patch by
Peter De Schrijver [1]. Then, it was suggested to move it to debugfs, which was
rejected as this info is actually needed in production systems.

2. Then it has been moved to /proc/cpuinfo [2]. Then, it was suggested to do
not add this kind of info there, as it is not really CPU data.

Now, I'm sending this version which will introduce first the /proc/socinfo.
Then, following patches will add OMAP data into that node. And finally,
will add OMAP id, production and die id code.

Just for reference, I'm also pasting the previous 0/4 message:

-------------------------------------------------------------------------------
v3:
I'm resending this series with minor change in the subject prefix of patch 4/4.
Removed the PM: prefix. Everything else is same. So, I kept the v3 prefix as well.

And now v3 of this series. Basically a minor change wrt string manipulation.
No need to use strlen in so many places. Previous log for reference:

-------------------------------------------------------------------------------
v2:

Here is the version 2 of this series. Now die id is protected using
same x86 protection mechanism to hide x86 product number. Besides,
a compilation Kconfig option has been added for DIE ID as well.

Here is previous PATCH 0/4 message:

-------------------------------------------------------------------------------
v1:

This series is to continue what has been discussed several weeks ago
wrt IDCODE patch. Original patch was made by Peter and discussion is here:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg17553.html

So, the conclusion was that IDCODE info is useful even in production systems,
and for that debugfs is not a good choice to export it. One suggestion was to
add it under /proc/cpuinfo. However this entry nowadays exports only ARM related
information.

So this series does the trick by extending the ARM /proc/cpuinfo to include
soc info data. There are a few ways to add a hook for soc specific data. But
I've decided to implement it via the simplest way I found. Basically it is
same thing which is done for system_rev, system_serial_low and system_serial_high.
Then, now we have system_soc_info, which is printed only if there is something
useful there.

As usual, comments are welcome.

-------------------------------------------------------------------------------
BR,

Eduardo Valentin (3):
  procfs: Introduce socinfo under /proc
  OMAP: export OMAP info under /proc/socinfo
  OMAP3: export chip IDCODE, Production ID and Die ID

 Documentation/filesystems/proc.txt  |    1 +
 Documentation/kernel-parameters.txt |    2 +
 arch/arm/Kconfig                    |    1 +
 arch/arm/mach-omap1/id.c            |   31 ++++++++++---
 arch/arm/mach-omap2/Kconfig         |   10 ++++
 arch/arm/mach-omap2/id.c            |   65 +++++++++++++++++++++++++---
 fs/proc/Kconfig                     |    7 +++
 fs/proc/Makefile                    |    1 +
 fs/proc/socinfo.c                   |   80 +++++++++++++++++++++++++++++++++++
 include/linux/socinfo.h             |   17 +++++++
 10 files changed, 202 insertions(+), 13 deletions(-)
 create mode 100644 fs/proc/socinfo.c
 create mode 100644 include/linux/socinfo.h

[PATCHv5 1/3] procfs: Introduce socinfo under /proc

[Eduardo Valentin]

From: Eduardo Valentin <eduardo.valentin@nokia.com>

This patch introduce the /proc/socinfo node. Its purpose is to
export System on Chip information and specific bits.

Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
---
 Documentation/filesystems/proc.txt |    1 +
 fs/proc/Kconfig                    |    7 +++
 fs/proc/Makefile                   |    1 +
 fs/proc/socinfo.c                  |   80 ++++++++++++++++++++++++++++++++++++
 include/linux/socinfo.h            |   17 ++++++++
 5 files changed, 106 insertions(+), 0 deletions(-)
 create mode 100644 fs/proc/socinfo.c
 create mode 100644 include/linux/socinfo.h

diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index a4f30fa..039bcb7 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -415,6 +415,7 @@ Table 1-5: Kernel info in /proc
  bus         Directory containing bus specific information     
  cmdline     Kernel command line                               
  cpuinfo     Info about the CPU                                
+ socinfo     Info about the System on Chip                     
  devices     Available devices (block and character)           
  dma         Used DMS channels                                 
  filesystems Supported filesystems                             
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 50f8f06..e683d62 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -67,3 +67,10 @@ config PROC_PAGE_MONITOR
 	  /proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
 	  /proc/kpagecount, and /proc/kpageflags. Disabling these
           interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_SOCINFO
+ 	default y
+	depends on PROC_FS
+	bool "Enable /proc/socinfo" if EMBEDDED
+ 	help
+	  Say Y here if you need to see information about the your System on Chip.
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 11a7b5c..7757d44 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -26,3 +26,4 @@ proc-$(CONFIG_PROC_VMCORE)	+= vmcore.o
 proc-$(CONFIG_PROC_DEVICETREE)	+= proc_devtree.o
 proc-$(CONFIG_PRINTK)	+= kmsg.o
 proc-$(CONFIG_PROC_PAGE_MONITOR)	+= page.o
+proc-$(CONFIG_PROC_SOCINFO)	+= socinfo.o
diff --git a/fs/proc/socinfo.c b/fs/proc/socinfo.c
new file mode 100644
index 0000000..09a889d
--- /dev/null
+++ b/fs/proc/socinfo.c
@@ -0,0 +1,80 @@
+/*
+ *  fs/proc/socinfo.c
+ *
+ *  Copyright (C) 2010 Nokia Corporation
+ *
+ *  Contact: Eduardo Valentin <eduardo.valentin@nokia.com>
+ *
+ *  proc socinfo file
+ */
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+#include <linux/socinfo.h>
+
+/*
+ * Function pointer to soc core code which knows how to grab soc info
+ */
+static int (*socinfo_show)(struct seq_file *, void *);
+static void *socinfo_data;
+static DEFINE_MUTEX(socinfo_mutex);
+
+/**
+ * register_socinfo_show() - register a call back to provide SoC information
+ * @show:	The function callback. It is expected to be in the same format
+ *		as the .show of struct seq_operations.
+ * @data:	A void * which will be passed as argument when show is called.
+ *
+ * This function will store the reference for a function and its data. The show
+ * argument will be called when filling up the seq_file of /proc/socinfo.
+ * Usually, this function should be called just once, while executing the SoC
+ * core initialization code.
+ */
+void register_socinfo_show(int (*show)(struct seq_file *, void *), void *data)
+{
+	mutex_lock(&socinfo_mutex);
+	socinfo_show = show;
+	socinfo_data = data;
+	mutex_unlock(&socinfo_mutex);
+}
+
+static int socinfo_show_local(struct seq_file *sfile, void *data)
+{
+	int r;
+
+	/* Just fall back to those who know how to grab the info */
+	mutex_lock(&socinfo_mutex);
+	if (socinfo_show)
+		r = socinfo_show(sfile, socinfo_data);
+	else
+		r = seq_printf(sfile, "No data\n");
+	mutex_unlock(&socinfo_mutex);
+
+	return r;
+}
+
+static int socinfo_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, socinfo_show_local, NULL);
+}
+
+static const struct file_operations proc_socinfo_operations = {
+	.owner		= THIS_MODULE,
+	.open		= socinfo_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= single_release,
+};
+
+static int __init proc_socinfo_init(void)
+{
+	if (!proc_create("socinfo", 0, NULL, &proc_socinfo_operations)) {
+		pr_info("Failed to create /proc/socinfo\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+module_init(proc_socinfo_init);
diff --git a/include/linux/socinfo.h b/include/linux/socinfo.h
new file mode 100644
index 0000000..aa870f1
--- /dev/null
+++ b/include/linux/socinfo.h
@@ -0,0 +1,17 @@
+/*
+ *  include/linux/socinfo.h
+ *
+ *  Copyright (C) 2010 Nokia Corporation
+ *
+ *  Contact: Eduardo Valentin <eduardo.valentin@nokia.com>
+ *
+ *  proc socinfo file
+ */
+
+#ifndef __SOCINFO_H
+#define __SOCINFO_H
+
+#include <linux/seq_file.h>
+
+void register_socinfo_show(int (*show)(struct seq_file *, void *), void *data);
+#endif
-- 
1.7.0.4.361.g8b5fe.dirty

[PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo

[Eduardo Valentin]

From: Eduardo Valentin <eduardo.valentin@nokia.com>

Export OMAP name and rev under /proc/socinfo node.

Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
---
 arch/arm/Kconfig         |    1 +
 arch/arm/mach-omap1/id.c |   31 ++++++++++++++++++++++++-------
 arch/arm/mach-omap2/id.c |   32 ++++++++++++++++++++++++++------
 3 files changed, 51 insertions(+), 13 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 92622eb..fbd3c50 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -326,6 +326,7 @@ config ARCH_EP93XX
 	select COMMON_CLKDEV
 	select ARCH_REQUIRE_GPIOLIB
 	select ARCH_HAS_HOLES_MEMORYMODEL
+	select PROC_SOC_INFO
 	help
 	  This enables support for the Cirrus EP93xx series of CPUs.
 
diff --git a/arch/arm/mach-omap1/id.c b/arch/arm/mach-omap1/id.c
index a0e3560..ef3caf1 100644
--- a/arch/arm/mach-omap1/id.c
+++ b/arch/arm/mach-omap1/id.c
@@ -15,6 +15,8 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/socinfo.h>
+#include <linux/seq_file.h>
 #include <plat/cpu.h>
 
 #define OMAP_DIE_ID_0		0xfffe1800
@@ -118,9 +120,21 @@ static u8 __init omap_get_die_rev(void)
 	return die_rev;
 }
 
+#define SOCINFO_SZ		128
+
+static int omap1_socinfo_show(struct seq_file *m, void *v)
+{
+	char *socinfo = v;
+
+	seq_printf(m, "SoC\t: %s\n", socinfo);
+
+	return 0;
+}
+
 void __init omap_check_revision(void)
 {
-	int i;
+	int i, sz;
+	char socinfo[SOCINFO_SZ];
 	u16 jtag_id;
 	u8 die_rev;
 	u32 omap_id;
@@ -194,11 +208,14 @@ void __init omap_check_revision(void)
 		printk(KERN_INFO "Unknown OMAP cpu type: 0x%02x\n", cpu_type);
 	}
 
-	printk(KERN_INFO "OMAP%04x", omap_revision >> 16);
+	sz = snprintf(socinfo, SOCINFO_SZ, "OMAP%04x", omap_revision >> 16);
 	if ((omap_revision >> 8) & 0xff)
-		printk(KERN_INFO "%x", (omap_revision >> 8) & 0xff);
-	printk(KERN_INFO " revision %i handled as %02xxx id: %08x%08x\n",
-	       die_rev, omap_revision & 0xff, system_serial_low,
-	       system_serial_high);
+		snprintf(socinfo + sz, SOCINFO_SZ - sz, "%x",
+						(omap_revision >> 8) & 0xff);
+	pr_info("%s revision %i handled as %02xxx id: %08x%08x\n",
+		socinfo, die_rev, omap_revision & 0xff, system_serial_low,
+		system_serial_high);
+
+	/* register function to show SoC info under /proc/socinfo */
+	register_socinfo_show(omap1_socinfo_show, kstrdup(socinfo, GFP_KERNEL));
 }
-
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37b8a1a..b67486b 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,8 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/socinfo.h>
+#include <linux/seq_file.h>
 
 #include <asm/cputype.h>
 
@@ -101,10 +103,12 @@ static struct omap_id omap_ids[] __initdata = {
 
 static void __iomem *tap_base;
 static u16 tap_prod_id;
+#define SOCINFO_SZ		128
+static char socinfo[SOCINFO_SZ];
 
 void __init omap24xx_check_revision(void)
 {
-	int i, j;
+	int i, j, sz;
 	u32 idcode, prod_id;
 	u16 hawkeye;
 	u8  dev_type, rev;
@@ -152,10 +156,11 @@ void __init omap24xx_check_revision(void)
 		j = i;
 	}
 
-	pr_info("OMAP%04x", omap_rev() >> 16);
+	sz = snprintf(socinfo, SOCINFO_SZ, "OMAP%04x", omap_rev() >> 16);
 	if ((omap_rev() >> 8) & 0x0f)
-		pr_info("ES%x", (omap_rev() >> 12) & 0xf);
-	pr_info("\n");
+		snprintf(socinfo + sz, SOCINFO_SZ - sz, "ES%x",
+						(omap_rev() >> 12) & 0xf);
+	pr_info("%s\n", socinfo);
 }
 
 #define OMAP3_CHECK_FEATURE(status,feat)				\
@@ -286,7 +291,9 @@ void __init omap4_check_revision(void)
 	if ((hawkeye == 0xb852) && (rev == 0x0)) {
 		omap_revision = OMAP4430_REV_ES1_0;
 		omap_chip.oc |= CHIP_IS_OMAP4430ES1;
-		pr_info("OMAP%04x %s\n", omap_rev() >> 16, rev_name);
+		snprintf(socinfo, SOCINFO_SZ, "OMAP%04x %s\n",
+				omap_rev() >> 16, rev_name);
+		pr_info("%s\n", socinfo);
 		return;
 	}
 
@@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void)
 	}
 
 	/* Print verbose information */
-	pr_info("%s ES%s (", cpu_name, cpu_rev);
+	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
+	pr_info("%s (", socinfo);
 
 	OMAP3_SHOW_FEATURE(l2cache);
 	OMAP3_SHOW_FEATURE(iva);
@@ -368,6 +376,15 @@ void __init omap3_cpuinfo(void)
 	printk(")\n");
 }
 
+static int omap_socinfo_show(struct seq_file *m, void *v)
+{
+	char *socinfop = v;
+
+	seq_printf(m, "SoC\t: %s\n", socinfop);
+
+	return 0;
+}
+
 /*
  * Try to detect the exact revision of the omap we're running on
  */
@@ -391,6 +408,9 @@ void __init omap2_check_revision(void)
 		pr_err("OMAP revision unknown, please fix!\n");
 	}
 
+	/* also register call back to report SoC data under /proc/socinfo */
+	register_socinfo_show(omap_socinfo_show, socinfo);
+
 	/*
 	 * OK, now we know the exact revision. Initialize omap_chip bits
 	 * for powerdowmain and clockdomain code.
-- 
1.7.0.4.361.g8b5fe.dirty

[PATCHv5 3/3] OMAP3: export chip IDCODE, Production ID and Die ID

[Eduardo Valentin]

From: Eduardo Valentin <eduardo.valentin@nokia.com>

This patch exports the OMAP3 IDCODE and Production ID to userspace
via /proc/socinfo.

Die ID is also exported depending on what users pass as kernel
parameter. It is same protection mechanism made for x86 product
number. So, if user passes "omap3_die_id" parameter, it will append
die id code into /proc/socinfo as well. A Kconfig option has been
added as well, so it can be configurable during compilation time.

This can be used to track down silicon specific issues. The info is
exported via /proc/socinfo because then it can be possible to include this
in corematic dumps.

This is based on Peter De Schrijver patch, which export same info via sysfs.

Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
---
 Documentation/kernel-parameters.txt |    2 ++
 arch/arm/mach-omap2/Kconfig         |   10 ++++++++++
 arch/arm/mach-omap2/id.c            |   35 ++++++++++++++++++++++++++++++++++-
 3 files changed, 46 insertions(+), 1 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 839b21b..8010cfb 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1809,6 +1809,8 @@ and is between 256 and 4096 characters. It is defined in the file
 			waiting for the ACK, so if this is set too high
 			interrupts *may* be lost!
 
+	omap3_die_id	[OMAP] Append DIE ID info under /proc/socinfo
+
 	omap_mux=	[OMAP] Override bootloader pin multiplexing.
 			Format: <mux_mode0.mode_name=value>...
 			For example, to override I2C bus2:
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2455dcc..fb8abed 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -169,3 +169,13 @@ config OMAP3_SDRC_AC_TIMING
 	  wish to say no.  Selecting yes without understanding what is
 	  going on could result in system crashes;
 
+config OMAP3_EXPORT_DIE_ID
+	bool "Export DIE ID code under /proc/socinfo"
+	depends on ARCH_OMAP3
+	default n
+	help
+	  Say Y here if you need DIE ID code to be exported via /proc/socinfo
+	  in production systems. You will need also to explicitly flag it by
+	  appending the "omap3_die_id" parameter to your boot command line.
+
+
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index b67486b..b4f5630 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -78,6 +78,10 @@ EXPORT_SYMBOL(omap_type);
 /*----------------------------------------------------------------------------*/
 
 #define OMAP_TAP_IDCODE		0x0204
+#define OMAP_TAP_PROD_ID_0      0x0208
+#define OMAP_TAP_PROD_ID_1      0x020c
+#define OMAP_TAP_PROD_ID_2      0x0210
+#define OMAP_TAP_PROD_ID_3      0x0214
 #define OMAP_TAP_DIE_ID_0	0x0218
 #define OMAP_TAP_DIE_ID_1	0x021C
 #define OMAP_TAP_DIE_ID_2	0x0220
@@ -306,6 +310,7 @@ void __init omap4_check_revision(void)
 
 void __init omap3_cpuinfo(void)
 {
+	int sz;
 	u8 rev = GET_OMAP_REVISION();
 	char cpu_name[16], cpu_rev[16];
 
@@ -363,7 +368,7 @@ void __init omap3_cpuinfo(void)
 	}
 
 	/* Print verbose information */
-	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
+	sz = snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
 	pr_info("%s (", socinfo);
 
 	OMAP3_SHOW_FEATURE(l2cache);
@@ -374,7 +379,35 @@ void __init omap3_cpuinfo(void)
 	OMAP3_SHOW_FEATURE(192mhz_clk);
 
 	printk(")\n");
+
+	/* Append OMAP3 IDCODE and Production ID to /proc/socinfo */
+	snprintf(socinfo + sz, SOCINFO_SZ - sz,
+			"\nIDCODE\t: %08x\nPr. ID\t: %08x %08x %08x %08x",
+			read_tap_reg(OMAP_TAP_IDCODE),
+			read_tap_reg(OMAP_TAP_PROD_ID_0),
+			read_tap_reg(OMAP_TAP_PROD_ID_1),
+			read_tap_reg(OMAP_TAP_PROD_ID_2),
+			read_tap_reg(OMAP_TAP_PROD_ID_3));
+
+}
+
+#ifdef CONFIG_OMAP3_EXPORT_DIE_ID
+static int __init omap3_die_id_setup(char *s)
+{
+	int sz;
+
+	sz = strlen(socinfo);
+	snprintf(socinfo + sz, SOCINFO_SZ - sz,
+			"\nDie ID\t: %08x %08x %08x %08x",
+			read_tap_reg(OMAP_TAP_DIE_ID_0),
+			read_tap_reg(OMAP_TAP_DIE_ID_1),
+			read_tap_reg(OMAP_TAP_DIE_ID_2),
+			read_tap_reg(OMAP_TAP_DIE_ID_3));
+
+	return 1;
 }
+__setup("omap3_die_id", omap3_die_id_setup);
+#endif
 
 static int omap_socinfo_show(struct seq_file *m, void *v)
 {
-- 
1.7.0.4.361.g8b5fe.dirty

[PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo

[Nishanth Menon]

Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:
> From: Eduardo Valentin <eduardo.valentin@nokia.com>
> 
> Export OMAP name and rev under /proc/socinfo node.
> 
> Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
> ---
>  arch/arm/Kconfig         |    1 +
>  arch/arm/mach-omap1/id.c |   31 ++++++++++++++++++++++++-------
>  arch/arm/mach-omap2/id.c |   32 ++++++++++++++++++++++++++------
>  3 files changed, 51 insertions(+), 13 deletions(-)
> 
[..]

> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 37b8a1a..b67486b 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
[..]

> @@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void)
>  	}
>  
>  	/* Print verbose information */
> -	pr_info("%s ES%s (", cpu_name, cpu_rev);
> +	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
> +	pr_info("%s (", socinfo);
>  
>  	OMAP3_SHOW_FEATURE(l2cache);
>  	OMAP3_SHOW_FEATURE(iva);
Just a minor comment -> is it a good idea to pushin the features to SOC 
info as well? currently this is being displayed at bootlog and not 
beyond.. might be a better approach to move it into socinfo..


[..]

-- 
Regards,
Nishanth Menon

[PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo

[Eduardo Valentin]

Hello Nishanth,

On Tue, May 11, 2010 at 04:28:15PM +0200, ext Nishanth Menon wrote:
> Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:
> > From: Eduardo Valentin <eduardo.valentin@nokia.com>
> > 
> > Export OMAP name and rev under /proc/socinfo node.
> > 
> > Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
> > ---
> >  arch/arm/Kconfig         |    1 +
> >  arch/arm/mach-omap1/id.c |   31 ++++++++++++++++++++++++-------
> >  arch/arm/mach-omap2/id.c |   32 ++++++++++++++++++++++++++------
> >  3 files changed, 51 insertions(+), 13 deletions(-)
> > 
> [..]
> 
> > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > index 37b8a1a..b67486b 100644
> > --- a/arch/arm/mach-omap2/id.c
> > +++ b/arch/arm/mach-omap2/id.c
> [..]
> 
> > @@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void)
> >  	}
> >  
> >  	/* Print verbose information */
> > -	pr_info("%s ES%s (", cpu_name, cpu_rev);
> > +	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
> > +	pr_info("%s (", socinfo);
> >  
> >  	OMAP3_SHOW_FEATURE(l2cache);
> >  	OMAP3_SHOW_FEATURE(iva);
> Just a minor comment -> is it a good idea to pushin the features to SOC 
> info as well? currently this is being displayed at bootlog and not 
> beyond.. might be a better approach to move it into socinfo..

Yeah. I would expect that someone would ask this. When I was writing this part
I also thought that would be nice to just duplicate all info which is printed
into kernel log buffer. But then I decided to proceed with only the info we are
needing from userspace. If you think that would be useful to know those as well,
then why not adding them.

> 
> 
> [..]
> 
> -- 
> Regards,
> Nishanth Menon

[PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo

[Eduardo Valentin]

Hello,

On Tue, May 11, 2010 at 06:58:46PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote:
> Hello Nishanth,
> 
> On Tue, May 11, 2010 at 04:28:15PM +0200, ext Nishanth Menon wrote:
> > Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:
> > > From: Eduardo Valentin <eduardo.valentin@nokia.com>
> > > 
> > > Export OMAP name and rev under /proc/socinfo node.
> > > 
> > > Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
> > > ---
> > >  arch/arm/Kconfig         |    1 +
> > >  arch/arm/mach-omap1/id.c |   31 ++++++++++++++++++++++++-------
> > >  arch/arm/mach-omap2/id.c |   32 ++++++++++++++++++++++++++------
> > >  3 files changed, 51 insertions(+), 13 deletions(-)
> > > 
> > [..]
> > 
> > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> > > index 37b8a1a..b67486b 100644
> > > --- a/arch/arm/mach-omap2/id.c
> > > +++ b/arch/arm/mach-omap2/id.c
> > [..]
> > 
> > > @@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void)
> > >  	}
> > >  
> > >  	/* Print verbose information */
> > > -	pr_info("%s ES%s (", cpu_name, cpu_rev);
> > > +	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
> > > +	pr_info("%s (", socinfo);
> > >  
> > >  	OMAP3_SHOW_FEATURE(l2cache);
> > >  	OMAP3_SHOW_FEATURE(iva);
> > Just a minor comment -> is it a good idea to pushin the features to SOC 
> > info as well? currently this is being displayed at bootlog and not 
> > beyond.. might be a better approach to move it into socinfo..
> 
> Yeah. I would expect that someone would ask this. When I was writing this part
> I also thought that would be nice to just duplicate all info which is printed
> into kernel log buffer. But then I decided to proceed with only the info we are
> needing from userspace. If you think that would be useful to know those as well,
> then why not adding them.

As discussed in #linux-omap IRC channel, we agreed that it would be nice and useful
to export the OMAP FEATURES under this interface. But as the code to detect omap features is
under re-work currently, for now we are going to leave it out of this patch set.

> 
> > 
> > 
> > [..]
> > 
> > -- 
> > Regards,
> > Nishanth Menon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo

[Nishanth Menon]

Eduardo Valentin had written, on 05/12/2010 07:34 AM, the following:
> Hello,
> 
> On Tue, May 11, 2010 at 06:58:46PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote:
>> Hello Nishanth,
>>
>> On Tue, May 11, 2010 at 04:28:15PM +0200, ext Nishanth Menon wrote:
>>> Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:
>>>> From: Eduardo Valentin <eduardo.valentin@nokia.com>
>>>>
>>>> Export OMAP name and rev under /proc/socinfo node.
>>>>
>>>> Signed-off-by: Eduardo Valentin <eduardo.valentin@nokia.com>
>>>> ---
>>>>  arch/arm/Kconfig         |    1 +
>>>>  arch/arm/mach-omap1/id.c |   31 ++++++++++++++++++++++++-------
>>>>  arch/arm/mach-omap2/id.c |   32 ++++++++++++++++++++++++++------
>>>>  3 files changed, 51 insertions(+), 13 deletions(-)
>>>>
>>> [..]
>>>
>>>> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
>>>> index 37b8a1a..b67486b 100644
>>>> --- a/arch/arm/mach-omap2/id.c
>>>> +++ b/arch/arm/mach-omap2/id.c
>>> [..]
>>>
>>>> @@ -356,7 +363,8 @@ void __init omap3_cpuinfo(void)
>>>>  	}
>>>>  
>>>>  	/* Print verbose information */
>>>> -	pr_info("%s ES%s (", cpu_name, cpu_rev);
>>>> +	snprintf(socinfo, SOCINFO_SZ, "%s ES%s", cpu_name, cpu_rev);
>>>> +	pr_info("%s (", socinfo);
>>>>  
>>>>  	OMAP3_SHOW_FEATURE(l2cache);
>>>>  	OMAP3_SHOW_FEATURE(iva);
>>> Just a minor comment -> is it a good idea to pushin the features to SOC 
>>> info as well? currently this is being displayed at bootlog and not 
>>> beyond.. might be a better approach to move it into socinfo..
>> Yeah. I would expect that someone would ask this. When I was writing this part
>> I also thought that would be nice to just duplicate all info which is printed
>> into kernel log buffer. But then I decided to proceed with only the info we are
>> needing from userspace. If you think that would be useful to know those as well,
>> then why not adding them.
> 
> As discussed in #linux-omap IRC channel, we agreed that it would be nice and useful
> to export the OMAP FEATURES under this interface. But as the code to detect omap features is
> under re-work currently, for now we are going to leave it out of this patch set.
> 
Agreed. other than this, I dont see an issue :) thanks for the work..

Acked-by: Nishanth Menon <nm@ti.com>

>>>
>>> [..]
>>>
>>> -- 
>>> Regards,
>>> Nishanth Menon
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/


-- 
Regards,
Nishanth Menon

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Andrew Morton]

On Tue, 11 May 2010 17:15:28 +0300
Eduardo Valentin <eduardo.valentin@nokia.com> wrote:

> Here is the version 5 of the change to export OMAP data to userspace
> (name, revision, id code, production id and die id).
> 
> Basically, this version is still attempting to create a new file under /proc.
> It is the /proc/socinfo, which should be used to export bits which are SoC specific
> (not CPU related, nor machine related).
> 
> So, differences between previous version are:
> - merged patch 02/04 with 03/04 to avoid compilation breakages.
> - simplified the seq_file usage by using the single_open and single_release functions
> - exported a function to register a seq_operation .show callback
> - adapted the changes accordingly
> 
> As usual, comments are welcome.

This changelog would be rather more useful if it was to show us some
sample output from /proc/socinfo, perhaps accompanied with an
explanation for people who aren't familar with this area of the kernel.

I'd have thought that sysfs was an appropriate place for this info. 
Perhaps under /sys/devices/platform?  Or /sys/devices/system?  Peter's
original patch didn't tell us where in the hierarchy the file was
placed, nor why it was placed there, not what its contents look like. 
But crappy changelogs are the norm :(

The objections stated in this email:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg17630.html
appear to still apply to this version of the patches?

Kevin didn't explain why he said "Please export these via debugfs". 
Tony didn't clearly explain why he said "I don't think we want to
export unique chip identifiers by default".



So apart from having certain opinions regarding communication skills
and wondering why people cc me on stuff without vaguely providing
enough info for me to understand what they're thinking, I don't know
what to make of it all :(

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Eduardo Valentin]

Hello Andrew,

On Thu, May 13, 2010 at 12:24:24AM +0200, Andrew Morton wrote:
> On Tue, 11 May 2010 17:15:28 +0300
> Eduardo Valentin <eduardo.valentin@nokia.com> wrote:
> 
> > Here is the version 5 of the change to export OMAP data to userspace
> > (name, revision, id code, production id and die id).
> > 
> > Basically, this version is still attempting to create a new file under /proc.
> > It is the /proc/socinfo, which should be used to export bits which are SoC specific
> > (not CPU related, nor machine related).
> > 
> > So, differences between previous version are:
> > - merged patch 02/04 with 03/04 to avoid compilation breakages.
> > - simplified the seq_file usage by using the single_open and single_release functions
> > - exported a function to register a seq_operation .show callback
> > - adapted the changes accordingly
> > 
> > As usual, comments are welcome.
> 
> This changelog would be rather more useful if it was to show us some
> sample output from /proc/socinfo, perhaps accompanied with an
> explanation for people who aren't familar with this area of the kernel.

Indeed. So, after applying this series, one example of output would be,
in case of OMAP3:

/ # cat /proc/socinfo
SoC     : OMAP3430 ES3.1
IDCODE  : 4b7ae02f
Pr. ID  : 00000000 00000000 000000cc cafeb7ae

These ids can be used, for instance, to track down silicon specific issues.

> 
> I'd have thought that sysfs was an appropriate place for this info. 
> Perhaps under /sys/devices/platform?  Or /sys/devices/system?  Peter's
> original patch didn't tell us where in the hierarchy the file was
> placed, nor why it was placed there, not what its contents look like. 
> But crappy changelogs are the norm :(

IIRC, originally, Peter's patch was creating /sys/power/idcode. The content
was very similar:


Nokia-N900:~# cat /sys/power/idcode 
IDCODE: 4b7ae02f
Production ID: 00000000 00000000 000000cc cafeb7ae
Die ID: 05018019 04033312 00000000 54500024


> 
> The objections stated in this email:
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg17630.html
> appear to still apply to this version of the patches?

Yeah, it is not applied on all IDs actually. At some point, the complain has changed.
More recently, Tony complained about Die ID:
http://marc.info/?l=linux-omap&m=127230649306842&w=2

And that's what is in patch 03/03 of this series. So, there are two things:
1. A separated config option to have DIE ID code in
2. User also have to explicitly pass the omap3_die_id kernel parameter.
Just like the "serialnumber" parameter for x86's.

Once the user has a kernel with CONFIG_OMAP3_EXPORT_DIE_ID and boots it with omap3_die_id parameter,
the first output I posted above would also include die id:

/ # cat /proc/socinfo 
SoC     : OMAP3430 ES3.1
IDCODE  : 4b7ae02f
Pr. ID  : 00000000 00000000 000000cc cafeb7ae
Die ID	: 05018019 04033312 00000000 54500024


> 
> Kevin didn't explain why he said "Please export these via debugfs". 
> Tony didn't clearly explain why he said "I don't think we want to
> export unique chip identifiers by default".
> 
> 
> 
> So apart from having certain opinions regarding communication skills
> and wondering why people cc me on stuff without vaguely providing
> enough info for me to understand what they're thinking, I don't know
> what to make of it all :(

Yeah, I agree here that there are some piece of info missing here and there.
Anyways, I believe the main point here is what is the best place to export these bits.

Originally was under sysfs (maybe not the correct place: /sys/power/idcode). Then I suggested
to move it to /proc/cpuinfo, which has been denied because these bits do not belong to CPU.
Then, it has been suggested to be under /proc/socinfo, which is the current version.
Now, I think your suggestion is to move back to sysfs, but under sys/devices/platform or /sys/devices/system, right ?



Thanks for your comments,

--
Eduardo Valentin

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Tony Lindgren]

* Andrew Morton <akpm@linux-foundation.org> [100512 15:19]:
> 
> I'd have thought that sysfs was an appropriate place for this info. 
> Perhaps under /sys/devices/platform?  Or /sys/devices/system?  Peter's
> original patch didn't tell us where in the hierarchy the file was
> placed, nor why it was placed there, not what its contents look like. 
> But crappy changelogs are the norm :(

To me both proc and sys work, I'm fine either way.
 
> The objections stated in this email:
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg17630.html
> appear to still apply to this version of the patches?
>
> Kevin didn't explain why he said "Please export these via debugfs". 
> Tony didn't clearly explain why he said "I don't think we want to
> export unique chip identifiers by default".
 
The issue I had was with the unique silicon ID getting exposed
by default to avoid the Pentium id number situation :)

It's now handled with a Kconfig and cmdline option, basically the
same way as the id on x86. So the issues in the email thread
above are sorted out.

Regards,

Tony 

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Linus Walleij]

2010/5/11 Eduardo Valentin <eduardo.valentin@nokia.com>:

> Here is the version 5 of the change to export OMAP data to userspace
> (name, revision, id code, production id and die id).
>
> Basically, this version is still attempting to create a new file under /proc.
> It is the /proc/socinfo, which should be used to export bits which are SoC specific
> (not CPU related, nor machine related).
>
> So, differences between previous version are:
> - merged patch 02/04 with 03/04 to avoid compilation breakages.
> - simplified the seq_file usage by using the single_open and single_release functions
> - exported a function to register a seq_operation .show callback
> - adapted the changes accordingly
>
> As usual, comments are welcome.

Eduardo, what has happened to this patchset?

Now we need something similar for arch/arm/mach-ux500 and I was sort of
hoping that this infrastructure would be in place already... wrong I was.

Do you want help in picking it up and try to polish it up?

Yours,
Linus Walleij

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Eduardo Valentin]

Hello Linus,

On Tue, Feb 15, 2011 at 01:58:00PM +0100, ext Linus Walleij wrote:
> 2010/5/11 Eduardo Valentin <eduardo.valentin@nokia.com>:
> 
> > Here is the version 5 of the change to export OMAP data to userspace
> > (name, revision, id code, production id and die id).
> >
> > Basically, this version is still attempting to create a new file under /proc.
> > It is the /proc/socinfo, which should be used to export bits which are SoC specific
> > (not CPU related, nor machine related).
> >
> > So, differences between previous version are:
> > - merged patch 02/04 with 03/04 to avoid compilation breakages.
> > - simplified the seq_file usage by using the single_open and single_release functions
> > - exported a function to register a seq_operation .show callback
> > - adapted the changes accordingly
> >
> > As usual, comments are welcome.
> 
> Eduardo, what has happened to this patchset?

Got forgotten :-(. Unfortunately I didn't pushed it hard enough.

> 
> Now we need something similar for arch/arm/mach-ux500 and I was sort of
> hoping that this infrastructure would be in place already... wrong I was.

Right.

> 
> Do you want help in picking it up and try to polish it up?

Yeah, but it would need a refactoring. IIRC, result of last discussion was that
we should not mess with /proc. So, maybe moving back to something under sysfs.
Perhaps /sys/devices/soc or so?

> 
> Yours,
> Linus Walleij

-- 
Eduardo Valentin

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Maxime Coquelin]

Hello Eduardo,

On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
> Hello Linus,
>
> On Tue, Feb 15, 2011 at 01:58:00PM +0100, ext Linus Walleij wrote:
>> 2010/5/11 Eduardo Valentin<eduardo.valentin@nokia.com>:
>>
>>> Here is the version 5 of the change to export OMAP data to userspace
>>> (name, revision, id code, production id and die id).
>>>
>>> Basically, this version is still attempting to create a new file under /proc.
>>> It is the /proc/socinfo, which should be used to export bits which are SoC specific
>>> (not CPU related, nor machine related).
>>>
>>> So, differences between previous version are:
>>> - merged patch 02/04 with 03/04 to avoid compilation breakages.
>>> - simplified the seq_file usage by using the single_open and single_release functions
>>> - exported a function to register a seq_operation .show callback
>>> - adapted the changes accordingly
>>>
>>> As usual, comments are welcome.
>> Eduardo, what has happened to this patchset?
> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
  I propose to refactor your patchset, moving from procfs to sysfs.
>> Do you want help in picking it up and try to polish it up?
> Yeah, but it would need a refactoring. IIRC, result of last discussion was that
> we should not mess with /proc. So, maybe moving back to something under sysfs.
> Perhaps /sys/devices/soc or so?
About the location of this new sysfs entry, where do you think it should be?
I propose to create a new directory named "soc" in /sys/devices/system/.

As platform vendors have several/different kind of IDs to export to 
sysfs, I propose each vendor to create file entries related to their IDs 
(eg. /sys/devices/system/soc/idcode for OMAP platforms).

However, I think we should have a common file entry to export the unique 
ID of the platforms. Indeed, user-space applications should have a 
unified way to get this kind of ID, regardless of the platform (eg. 
/sys/devices/system/soc/unique_id).

Do you agree with my proposal?

Thanks for your comments.

Regards,

Maxime Coquelin

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
> Hello Eduardo,
>
> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>> Eduardo, what has happened to this patchset?
>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
> I propose to refactor your patchset, moving from procfs to sysfs.

>>> Do you want help in picking it up and try to polish it up?
>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>> was that we should not mess with /proc. So, maybe moving back
 >> to something under sysfs. Perhaps /sys/devices/soc or so?
> About the location of this new sysfs entry, where do you think it should
> be?
> I propose to create a new directory named "soc" in /sys/devices/system/.
>
> As platform vendors have several/different kind of IDs to export to
> sysfs, I propose each vendor to create file entries related to their IDs
> (eg. /sys/devices/system/soc/idcode for OMAP platforms).

I think the path /sys/devices/system/soc/ will work for the MSM too. I 
would have ideally liked it to be /sys/devices/system/soc/msm, 
/sys/devices/system/soc/omap, etc, but we can't get to pick names for 
devices under a class. So, we can make do with /sys/devices/system/soc/.

> However, I think we should have a common file entry to export the unique
> ID of the platforms. Indeed, user-space applications should have a
> unified way to get this kind of ID, regardless of the platform (eg.
> /sys/devices/system/soc/unique_id).

I like the idea of have a common file across all implementations that 
will let user space identify what implementation is exporting the other 
files and how to interpret them.

I would like to propose an "arch" file to identify the arch the soc info 
file are for. I'm guessing within an arch, the soc files would mostly be 
the same? If there are other minor differences, we can let the arch 
specific code deal with how the files are interpreted.

Does "arch" work for everyone?

Thanks,
Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Andrei Warkentin]

On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
<skannan@codeaurora.org> wrote:
> On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
>>
>> Hello Eduardo,
>>
>> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>>>
>>>> Eduardo, what has happened to this patchset?
>>>
>>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
>>
>> I propose to refactor your patchset, moving from procfs to sysfs.
>
>>>> Do you want help in picking it up and try to polish it up?
>>>
>>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>>> was that we should not mess with /proc. So, maybe moving back
>
>>> to something under sysfs. Perhaps /sys/devices/soc or so?
>>
>> About the location of this new sysfs entry, where do you think it should
>> be?
>> I propose to create a new directory named "soc" in /sys/devices/system/.
>>
>> As platform vendors have several/different kind of IDs to export to
>> sysfs, I propose each vendor to create file entries related to their IDs
>> (eg. /sys/devices/system/soc/idcode for OMAP platforms).
>
> I think the path /sys/devices/system/soc/ will work for the MSM too. I would
> have ideally liked it to be /sys/devices/system/soc/msm,
> /sys/devices/system/soc/omap, etc, but we can't get to pick names for
> devices under a class. So, we can make do with /sys/devices/system/soc/.
>
>> However, I think we should have a common file entry to export the unique
>> ID of the platforms. Indeed, user-space applications should have a
>> unified way to get this kind of ID, regardless of the platform (eg.
>> /sys/devices/system/soc/unique_id).
>
> I like the idea of have a common file across all implementations that will
> let user space identify what implementation is exporting the other files and
> how to interpret them.
>
> I would like to propose an "arch" file to identify the arch the soc info
> file are for. I'm guessing within an arch, the soc files would mostly be the
> same? If there are other minor differences, we can let the arch specific
> code deal with how the files are interpreted.
>
> Does "arch" work for everyone?
>

Sorry to butt in, but what kind of info are you guys talking about?
Like SOC revision, serial numbers, etc...?

What would an "arch" file mean? The name of the soc platform?

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
> <skannan@codeaurora.org>  wrote:
>> On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
>>>
>>> Hello Eduardo,
>>>
>>> On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
>>>>>
>>>>> Eduardo, what has happened to this patchset?
>>>>
>>>> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
>>>
>>> I propose to refactor your patchset, moving from procfs to sysfs.
>>
>>>>> Do you want help in picking it up and try to polish it up?
>>>>
>>>> Yeah, but it would need a refactoring. IIRC, result of last discussion
>>>> was that we should not mess with /proc. So, maybe moving back
>>
>>>> to something under sysfs. Perhaps /sys/devices/soc or so?
>>>
>>> About the location of this new sysfs entry, where do you think it should
>>> be?
>>> I propose to create a new directory named "soc" in /sys/devices/system/.
>>>
>>> As platform vendors have several/different kind of IDs to export to
>>> sysfs, I propose each vendor to create file entries related to their IDs
>>> (eg. /sys/devices/system/soc/idcode for OMAP platforms).
>>
>> I think the path /sys/devices/system/soc/ will work for the MSM too. I would
>> have ideally liked it to be /sys/devices/system/soc/msm,
>> /sys/devices/system/soc/omap, etc, but we can't get to pick names for
>> devices under a class. So, we can make do with /sys/devices/system/soc/.
>>
>>> However, I think we should have a common file entry to export the unique
>>> ID of the platforms. Indeed, user-space applications should have a
>>> unified way to get this kind of ID, regardless of the platform (eg.
>>> /sys/devices/system/soc/unique_id).
>>
>> I like the idea of have a common file across all implementations that will
>> let user space identify what implementation is exporting the other files and
>> how to interpret them.
>>
>> I would like to propose an "arch" file to identify the arch the soc info
>> file are for. I'm guessing within an arch, the soc files would mostly be the
>> same? If there are other minor differences, we can let the arch specific
>> code deal with how the files are interpreted.
>>
>> Does "arch" work for everyone?
>>
>
> Sorry to butt in, but what kind of info are you guys talking about?

Please do butt in :-), that's what a community discussion is for.

> Like SOC revision, serial numbers, etc...?

Like SOC type (to identify different chipsets), revision, etc.

> What would an "arch" file mean? The name of the soc platform?

The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or 
similar paths. If that info is already available elsewhere, then that 
file is not needed. I proposed using the arch since that will remove the 
need to maintain some database of unique/reserved names/numbers for each 
implementation of socinfo (like the machinetypes list we have).

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 02:19 PM, Saravana Kannan wrote:
> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>> <skannan@codeaurora.org>  wrote:

<snip>

>> What would an "arch" file mean? The name of the soc platform?
> 
> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
> similar paths. If that info is already available elsewhere, then that
> file is not needed. I proposed using the arch since that will remove the
> need to maintain some database of unique/reserved names/numbers for each
> implementation of socinfo (like the machinetypes list we have).

/proc/cpuinfo already tells you what the CPU is, which gives more
information than just the architecture name.

Why is the arch information even required by userspace?

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 05:27 PM, Ryan Mallon wrote:
> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>> <skannan@codeaurora.org>   wrote:
>
> <snip>
>
>>> What would an "arch" file mean? The name of the soc platform?
>>
>> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
>> similar paths. If that info is already available elsewhere, then that
>> file is not needed. I proposed using the arch since that will remove the
>> need to maintain some database of unique/reserved names/numbers for each
>> implementation of socinfo (like the machinetypes list we have).
>
> /proc/cpuinfo already tells you what the CPU is, which gives more
> information than just the architecture name.
>
> Why is the arch information even required by userspace?

The socinfo exported by each soc is different. If userspace is trying to 
make decisions based on socinfo, it will need to know what type of soc 
(really what type of socinfo implementation) it is before trying to 
interpret the rest of the socinfo files. Keep in mind that cpuinfo is 
different from socinfo -- the cpu is just a small part of a soc.

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 02:39 PM, Saravana Kannan wrote:
> On 03/01/2011 05:27 PM, Ryan Mallon wrote:
>> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>>> <skannan@codeaurora.org>   wrote:
>>
>> <snip>
>>
>>>> What would an "arch" file mean? The name of the soc platform?
>>>
>>> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
>>> similar paths. If that info is already available elsewhere, then that
>>> file is not needed. I proposed using the arch since that will remove the
>>> need to maintain some database of unique/reserved names/numbers for each
>>> implementation of socinfo (like the machinetypes list we have).
>>
>> /proc/cpuinfo already tells you what the CPU is, which gives more
>> information than just the architecture name.
>>
>> Why is the arch information even required by userspace?
> 
> The socinfo exported by each soc is different. If userspace is trying to
> make decisions based on socinfo, it will need to know what type of soc
> (really what type of socinfo implementation) it is before trying to
> interpret the rest of the socinfo files. Keep in mind that cpuinfo is
> different from socinfo -- the cpu is just a small part of a soc.

I understand that having a socinfo file for obtaining information about
a particular SoC would be useful. A similar discussion came up a few
years ago when we talked about having a socinfo file for exposing the
ep93xx Maverick crunch id, but nothing ever came out of it.

What I don't understand is why you want the 'arch' file (ie the
mach-xxxx) name. /proc/cpuinfo already gives you more information than
an 'arch' file would. I also can't think of a particularly good
situation why userspace would need to know at runtime what the
architecture is.

Have a socinfo file to expose implementation details of the particular
SoC I am fine with (assuming those details are useful to userspace),
having an 'arch' file to expose the architecture I am against.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 05:51 PM, Ryan Mallon wrote:
> On 03/02/2011 02:39 PM, Saravana Kannan wrote:
>> On 03/01/2011 05:27 PM, Ryan Mallon wrote:
>>> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>>>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>>>> <skannan@codeaurora.org>    wrote:
>>>
>>> <snip>
>>>
>>>>> What would an "arch" file mean? The name of the soc platform?
>>>>
>>>> The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or
>>>> similar paths. If that info is already available elsewhere, then that
>>>> file is not needed. I proposed using the arch since that will remove the
>>>> need to maintain some database of unique/reserved names/numbers for each
>>>> implementation of socinfo (like the machinetypes list we have).
>>>
>>> /proc/cpuinfo already tells you what the CPU is, which gives more
>>> information than just the architecture name.
>>>
>>> Why is the arch information even required by userspace?
>>
>> The socinfo exported by each soc is different. If userspace is trying to
>> make decisions based on socinfo, it will need to know what type of soc
>> (really what type of socinfo implementation) it is before trying to
>> interpret the rest of the socinfo files. Keep in mind that cpuinfo is
>> different from socinfo -- the cpu is just a small part of a soc.
>
> I understand that having a socinfo file for obtaining information about
> a particular SoC would be useful. A similar discussion came up a few
> years ago when we talked about having a socinfo file for exposing the
> ep93xx Maverick crunch id, but nothing ever came out of it.
>
> What I don't understand is why you want the 'arch' file (ie the
> mach-xxxx) name. /proc/cpuinfo already gives you more information than
> an 'arch' file would. I also can't think of a particularly good
> situation why userspace would need to know at runtime what the
> architecture is.
>
> Have a socinfo file to expose implementation details of the particular
> SoC I am fine with (assuming those details are useful to userspace),
> having an 'arch' file to expose the architecture I am against.

You probably already understood this, but just to be sure, when I say 
"socinfo implementation" I mean the various ways the socinfo data should 
be interpreted by userspace. "socid" of 1 would mean a different thing 
depending on whether it's for omap, msm, kirkwood, etc.

I don't have any attachment to the "arch" file suggestion. If there is a 
better solution to identify the different implementations of socinfo 
without having to maintain some "unique id" list in the kernel, then I'm 
all for it. But cpuinfo is not it.

Which data listed in cpuinfo do you think will let you identify the 
socinfo implementation in a unique manner? The only thing that's even 
remotely possible is vendor_id, but I'm not sure what it's supposed to 
be if the CPU core is licensed from some vendor and used in a SOC by 
another vendor. What is a Samsung with an ARM11 core supposed to list 
for vendor_id? What if the another Samsung SOC has a Samsung's own CPU 
core? What about non-ARM architectures? I would rather not add implicit 
dependency on cpuinfo that's hard to maintain or guarantee and instead 
have the socinfo implementation explicitly exported.

The "arch" filename and what it's supposed to contain was just a 
suggestion. Another alternative might be to call it soc-family and the a 
general guideline to keep it as close as possible to the mach-xxxx name. 
For example, omap3 and omap4 might not care for having different socinfo 
implementations and can decide to use the socfamily name of "omap".

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 03:23 PM, Saravana Kannan wrote:
> On 03/01/2011 05:51 PM, Ryan Mallon wrote:
>> On 03/02/2011 02:39 PM, Saravana Kannan wrote:
>>> On 03/01/2011 05:27 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 02:19 PM, Saravana Kannan wrote:
>>>>> On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
>>>>>> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
>>>>>> <skannan@codeaurora.org>    wrote:
>>>>
>>>> <snip>
>>>>
>>>>>> What would an "arch" file mean? The name of the soc platform?
>>>>>
>>>>> The arch file would pretty much be the "xxxx" from
>>>>> arch/arm/mach-xxxx or
>>>>> similar paths. If that info is already available elsewhere, then that
>>>>> file is not needed. I proposed using the arch since that will
>>>>> remove the
>>>>> need to maintain some database of unique/reserved names/numbers for
>>>>> each
>>>>> implementation of socinfo (like the machinetypes list we have).
>>>>
>>>> /proc/cpuinfo already tells you what the CPU is, which gives more
>>>> information than just the architecture name.
>>>>
>>>> Why is the arch information even required by userspace?
>>>
>>> The socinfo exported by each soc is different. If userspace is trying to
>>> make decisions based on socinfo, it will need to know what type of soc
>>> (really what type of socinfo implementation) it is before trying to
>>> interpret the rest of the socinfo files. Keep in mind that cpuinfo is
>>> different from socinfo -- the cpu is just a small part of a soc.
>>
>> I understand that having a socinfo file for obtaining information about
>> a particular SoC would be useful. A similar discussion came up a few
>> years ago when we talked about having a socinfo file for exposing the
>> ep93xx Maverick crunch id, but nothing ever came out of it.
>>
>> What I don't understand is why you want the 'arch' file (ie the
>> mach-xxxx) name. /proc/cpuinfo already gives you more information than
>> an 'arch' file would. I also can't think of a particularly good
>> situation why userspace would need to know at runtime what the
>> architecture is.
>>
>> Have a socinfo file to expose implementation details of the particular
>> SoC I am fine with (assuming those details are useful to userspace),
>> having an 'arch' file to expose the architecture I am against.
> 
> You probably already understood this, but just to be sure, when I say
> "socinfo implementation" I mean the various ways the socinfo data should
> be interpreted by userspace. "socid" of 1 would mean a different thing
> depending on whether it's for omap, msm, kirkwood, etc.
> 
> I don't have any attachment to the "arch" file suggestion. If there is a
> better solution to identify the different implementations of socinfo
> without having to maintain some "unique id" list in the kernel, then I'm
> all for it. But cpuinfo is not it.

Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
file makes a bit more sense, but should probably be called 'mach' rather
than 'arch' to avoid this confusion :-).

I still think it is a solution in search of a problem though. What
userspace programs need to know what specific SoC they are on? My
feeling is that if userspace needs to know this information, then it is
probably dicking around with things that should be managed by the
kernel. Differences in available peripherals, etc can be determined by
looking at existing sysfs files.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 06:41 PM, Ryan Mallon wrote:
> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>> I don't have any attachment to the "arch" file suggestion. If there is a
>> better solution to identify the different implementations of socinfo
>> without having to maintain some "unique id" list in the kernel, then I'm
>> all for it. But cpuinfo is not it.
>
> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
> file makes a bit more sense, but should probably be called 'mach' rather
> than 'arch' to avoid this confusion :-).

Sorry for the confusion. Sure, I don't care much for the filename as 
long as we can all agree on it. I care more about the content of the 
file (using names very close to xxxx in mach-xxxx). I like "soc-family" 
better since it's generic enough to not force, say omap3 and omap4, to 
report different values.

Linus Walleij, Eduardo, Maxime, Andrei,

Would like to hear your opinion on the file name (soc-family vs. mach vs 
<somethingelse>) and the path /sys/devices/system/soc/.

If we settle on this, may be it would be easier to get this through.

> I still think it is a solution in search of a problem though. What
> userspace programs need to know what specific SoC they are on? My
> feeling is that if userspace needs to know this information, then it is
> probably dicking around with things that should be managed by the
> kernel. Differences in available peripherals, etc can be determined by
> looking at existing sysfs files.

I certainly have seen several use cases. Couple of easy examples:

* A lot of test scripts would find this very useful. For example, some 
clock (present is all/most MSMs) shouldn't be tested on some SOCs as it 
would lock up the system if you try to turn it off while the CPU is running.

* Some of the user space tools might want to report different "product 
id/type" (nothing to do with USB, etc) depending on what SOC it is 
running on.

Thank,
Saravana
P.S: Removed felipe.balbi at nokia.com <felipe.balbi@nokia.com> since I 
keep getting delivery failure emails.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 03:55 PM, Saravana Kannan wrote:
> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>> I don't have any attachment to the "arch" file suggestion. If there is a
>>> better solution to identify the different implementations of socinfo
>>> without having to maintain some "unique id" list in the kernel, then I'm
>>> all for it. But cpuinfo is not it.
>>
>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>> file makes a bit more sense, but should probably be called 'mach' rather
>> than 'arch' to avoid this confusion :-).
> 
> Sorry for the confusion. Sure, I don't care much for the filename as
> long as we can all agree on it. I care more about the content of the
> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
> better since it's generic enough to not force, say omap3 and omap4, to
> report different values.
> 
> Linus Walleij, Eduardo, Maxime, Andrei,
> 
> Would like to hear your opinion on the file name (soc-family vs. mach vs
> <somethingelse>) and the path /sys/devices/system/soc/.

'family' sounds good. I don't think we need the 'soc-' prefix on
filenames if they are already in /sys/devices/system/soc/.

> 
> If we settle on this, may be it would be easier to get this through.
> 
>> I still think it is a solution in search of a problem though. What
>> userspace programs need to know what specific SoC they are on? My
>> feeling is that if userspace needs to know this information, then it is
>> probably dicking around with things that should be managed by the
>> kernel. Differences in available peripherals, etc can be determined by
>> looking at existing sysfs files.
> 
> I certainly have seen several use cases. Couple of easy examples:
> 
> * A lot of test scripts would find this very useful. For example, some
> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
> would lock up the system if you try to turn it off while the CPU is
> running.

I don't follow here. Do you mean a struct clk clock or something else?
Why is userspace allowed to disable a clock which will effectively hang
the system? :-).

> * Some of the user space tools might want to report different "product
> id/type" (nothing to do with USB, etc) depending on what SOC it is
> running on.

This makes more sense. It would actually be useful for custom USB
devices (gadget) which can be done from user space.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 07:11 PM, Ryan Mallon wrote:
> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>> I don't have any attachment to the "arch" file suggestion. If there is a
>>>> better solution to identify the different implementations of socinfo
>>>> without having to maintain some "unique id" list in the kernel, then I'm
>>>> all for it. But cpuinfo is not it.
>>>
>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>> file makes a bit more sense, but should probably be called 'mach' rather
>>> than 'arch' to avoid this confusion :-).
>>
>> Sorry for the confusion. Sure, I don't care much for the filename as
>> long as we can all agree on it. I care more about the content of the
>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>> better since it's generic enough to not force, say omap3 and omap4, to
>> report different values.
>>
>> Linus Walleij, Eduardo, Maxime, Andrei,
>>
>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>> <somethingelse>) and the path /sys/devices/system/soc/.
>
> 'family' sounds good. I don't think we need the 'soc-' prefix on
> filenames if they are already in /sys/devices/system/soc/.

Makes sense. We can drop the soc- prefix. So the contenders left: family 
vs <somethingelse>. Would still be nice if the other folks chime in.

>> If we settle on this, may be it would be easier to get this through.
>>
>>> I still think it is a solution in search of a problem though. What
>>> userspace programs need to know what specific SoC they are on? My
>>> feeling is that if userspace needs to know this information, then it is
>>> probably dicking around with things that should be managed by the
>>> kernel. Differences in available peripherals, etc can be determined by
>>> looking at existing sysfs files.
>>
>> I certainly have seen several use cases. Couple of easy examples:
>>
>> * A lot of test scripts would find this very useful. For example, some
>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>> would lock up the system if you try to turn it off while the CPU is
>> running.
>
> I don't follow here. Do you mean a struct clk clock or something else?
> Why is userspace allowed to disable a clock which will effectively hang
> the system? :-).

Ah, sorry. Didn't give enough details. To give some context, I manage 
the clock stuff for MSM. The MSM clock driver exports clock control thru 
debugfs. We have test scripts that bang the clocks to test them. Each 
SoC has a different set of "touch me and you die" clocks that the test 
script shouldn't mess with. This socinfo would be useful for those test 
cases.

>> * Some of the user space tools might want to report different "product
>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>> running on.
>
> This makes more sense. It would actually be useful for custom USB
> devices (gadget) which can be done from user space.

Hmm... didn't know USB devices/gadgets could be handled from userspace.

Thanks,
Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 04:21 PM, Saravana Kannan wrote:
> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>>> I don't have any attachment to the "arch" file suggestion. If there
>>>>> is a
>>>>> better solution to identify the different implementations of socinfo
>>>>> without having to maintain some "unique id" list in the kernel,
>>>>> then I'm
>>>>> all for it. But cpuinfo is not it.
>>>>
>>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>>> file makes a bit more sense, but should probably be called 'mach'
>>>> rather
>>>> than 'arch' to avoid this confusion :-).
>>>
>>> Sorry for the confusion. Sure, I don't care much for the filename as
>>> long as we can all agree on it. I care more about the content of the
>>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>>> better since it's generic enough to not force, say omap3 and omap4, to
>>> report different values.
>>>
>>> Linus Walleij, Eduardo, Maxime, Andrei,
>>>
>>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>>> <somethingelse>) and the path /sys/devices/system/soc/.
>>
>> 'family' sounds good. I don't think we need the 'soc-' prefix on
>> filenames if they are already in /sys/devices/system/soc/.
> 
> Makes sense. We can drop the soc- prefix. So the contenders left: family
> vs <somethingelse>. Would still be nice if the other folks chime in.
> 
>>> If we settle on this, may be it would be easier to get this through.
>>>
>>>> I still think it is a solution in search of a problem though. What
>>>> userspace programs need to know what specific SoC they are on? My
>>>> feeling is that if userspace needs to know this information, then it is
>>>> probably dicking around with things that should be managed by the
>>>> kernel. Differences in available peripherals, etc can be determined by
>>>> looking at existing sysfs files.
>>>
>>> I certainly have seen several use cases. Couple of easy examples:
>>>
>>> * A lot of test scripts would find this very useful. For example, some
>>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>>> would lock up the system if you try to turn it off while the CPU is
>>> running.
>>
>> I don't follow here. Do you mean a struct clk clock or something else?
>> Why is userspace allowed to disable a clock which will effectively hang
>> the system? :-).
> 
> Ah, sorry. Didn't give enough details. To give some context, I manage
> the clock stuff for MSM. The MSM clock driver exports clock control thru
> debugfs. We have test scripts that bang the clocks to test them. Each
> SoC has a different set of "touch me and you die" clocks that the test
> script shouldn't mess with. This socinfo would be useful for those test
> cases.

Ah, okay. This is still within a single SoC family though since we don't
yet (AFAIK) support mutliple SoCs in a single kernel.

>>> * Some of the user space tools might want to report different "product
>>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>>> running on.
>>
>> This makes more sense. It would actually be useful for custom USB
>> devices (gadget) which can be done from user space.
> 
> Hmm... didn't know USB devices/gadgets could be handled from userspace.

The gadgetfs driver allows for writing custom usb device
implementations. The SoC info could be used to set the USB
vendor/product id. Again, I see this more useful within the SoC family
(ie at91sam9260 vs at91sam9263) rather than between families. From an
embedded perspective at least, I think it is unlikely for an application
to need to work on multiple SoC families.

The only real objection I have to adding the SoC family information is
basically to discourage it being abused by userspace. I can see it being
useful in debug situations, but I can also see stupid userspace
applications explicitly testing for some particular SoC, rather than
more correctly (IMHO) checking for presence of certain drivers etc.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/01/2011 07:35 PM, Ryan Mallon wrote:
> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>>>>> I don't have any attachment to the "arch" file suggestion. If there
>>>>>> is a
>>>>>> better solution to identify the different implementations of socinfo
>>>>>> without having to maintain some "unique id" list in the kernel,
>>>>>> then I'm
>>>>>> all for it. But cpuinfo is not it.
>>>>>
>>>>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>>>>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>>>>> file makes a bit more sense, but should probably be called 'mach'
>>>>> rather
>>>>> than 'arch' to avoid this confusion :-).
>>>>
>>>> Sorry for the confusion. Sure, I don't care much for the filename as
>>>> long as we can all agree on it. I care more about the content of the
>>>> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
>>>> better since it's generic enough to not force, say omap3 and omap4, to
>>>> report different values.
>>>>
>>>> Linus Walleij, Eduardo, Maxime, Andrei,
>>>>
>>>> Would like to hear your opinion on the file name (soc-family vs. mach vs
>>>> <somethingelse>) and the path /sys/devices/system/soc/.
>>>
>>> 'family' sounds good. I don't think we need the 'soc-' prefix on
>>> filenames if they are already in /sys/devices/system/soc/.
>>
>> Makes sense. We can drop the soc- prefix. So the contenders left: family
>> vs<somethingelse>. Would still be nice if the other folks chime in.
>>
>>>> If we settle on this, may be it would be easier to get this through.
>>>>
>>>>> I still think it is a solution in search of a problem though. What
>>>>> userspace programs need to know what specific SoC they are on? My
>>>>> feeling is that if userspace needs to know this information, then it is
>>>>> probably dicking around with things that should be managed by the
>>>>> kernel. Differences in available peripherals, etc can be determined by
>>>>> looking at existing sysfs files.
>>>>
>>>> I certainly have seen several use cases. Couple of easy examples:
>>>>
>>>> * A lot of test scripts would find this very useful. For example, some
>>>> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
>>>> would lock up the system if you try to turn it off while the CPU is
>>>> running.
>>>
>>> I don't follow here. Do you mean a struct clk clock or something else?
>>> Why is userspace allowed to disable a clock which will effectively hang
>>> the system? :-).
>>
>> Ah, sorry. Didn't give enough details. To give some context, I manage
>> the clock stuff for MSM. The MSM clock driver exports clock control thru
>> debugfs. We have test scripts that bang the clocks to test them. Each
>> SoC has a different set of "touch me and you die" clocks that the test
>> script shouldn't mess with. This socinfo would be useful for those test
>> cases.
>
> Ah, okay. This is still within a single SoC family though since we don't
> yet (AFAIK) support mutliple SoCs in a single kernel.

Yes, my example was within a single SoC family. But since this is user 
space example, it doesn't matter if a single kernel can support multiple 
SoCs/SoC families. We could still have one userspace code that might 
want to support multiple SoC families.

Anyway, I think we are in agreement here. So, will stop discussing this 
point.

>>>> * Some of the user space tools might want to report different "product
>>>> id/type" (nothing to do with USB, etc) depending on what SOC it is
>>>> running on.
>>>
>>> This makes more sense. It would actually be useful for custom USB
>>> devices (gadget) which can be done from user space.
>>
>> Hmm... didn't know USB devices/gadgets could be handled from userspace.
>
> The gadgetfs driver allows for writing custom usb device
> implementations. The SoC info could be used to set the USB
> vendor/product id. Again, I see this more useful within the SoC family
> (ie at91sam9260 vs at91sam9263) rather than between families. From an
> embedded perspective at least, I think it is unlikely for an application
> to need to work on multiple SoC families.
>
> The only real objection I have to adding the SoC family information is
> basically to discourage it being abused by userspace. I can see it being
> useful in debug situations, but I can also see stupid userspace
> applications explicitly testing for some particular SoC, rather than
> more correctly (IMHO) checking for presence of certain drivers etc.

True, but so many other things could be misused by stupid userspace 
programs. When there are legitimate usecases, I think we shouldn't 
prevent them just because we think a stupid userspace program could 
misuse it.

Again, although you might not be gung-ho about this, I think I have at 
least made you indifferent/mildly supportive to adding socinfo. If you 
don't mind, I would like to wait for others to chime in before 
continuing this discussion.

-Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 04:46 PM, Saravana Kannan wrote:
> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>> On 03/02/2011 04:21 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:11 PM, Ryan Mallon wrote:
>>>> On 03/02/2011 03:55 PM, Saravana Kannan wrote:
>>>>> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>>>>>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:

<snip>

>> The only real objection I have to adding the SoC family information is
>> basically to discourage it being abused by userspace. I can see it being
>> useful in debug situations, but I can also see stupid userspace
>> applications explicitly testing for some particular SoC, rather than
>> more correctly (IMHO) checking for presence of certain drivers etc.
> 
> True, but so many other things could be misused by stupid userspace
> programs. When there are legitimate usecases, I think we shouldn't
> prevent them just because we think a stupid userspace program could
> misuse it.
> 
> Again, although you might not be gung-ho about this, I think I have at
> least made you indifferent/mildly supportive to adding socinfo. If you
> don't mind, I would like to wait for others to chime in before
> continuing this discussion.

Agreed.

In general I am in support of having the SoC information exposed
somewhere. I think we just want to be careful that it doesn't become a
dumping ground for anything and everything SoC related whether the
information is useful or not. I think each piece of exposed information
should have a genuine use case, not just "because we can".

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Maxime Coquelin]

On 03/02/2011 03:55 AM, Saravana Kannan wrote:
> On 03/01/2011 06:41 PM, Ryan Mallon wrote:
>> On 03/02/2011 03:23 PM, Saravana Kannan wrote:
>>> I don't have any attachment to the "arch" file suggestion. If there is a
>>> better solution to identify the different implementations of socinfo
>>> without having to maintain some "unique id" list in the kernel, then I'm
>>> all for it. But cpuinfo is not it.
>> Sorry I am confusing the 'arch' and 'mach' bits here. I definitely have
>> an objection to having an 'arch' file (i.e. ARM). A 'mach' (i.e. omap)
>> file makes a bit more sense, but should probably be called 'mach' rather
>> than 'arch' to avoid this confusion :-).
> Sorry for the confusion. Sure, I don't care much for the filename as
> long as we can all agree on it. I care more about the content of the
> file (using names very close to xxxx in mach-xxxx). I like "soc-family"
> better since it's generic enough to not force, say omap3 and omap4, to
> report different values.
>
> Linus Walleij, Eduardo, Maxime, Andrei,
>
> Would like to hear your opinion on the file name (soc-family vs. mach vs
> <somethingelse>) and the path /sys/devices/system/soc/.
>
> If we settle on this, may be it would be easier to get this through.
>

I think we should have a tree like this :

/sys/devices/system/soc/
/sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
/sys/devices/system/soc/mach/
/sys/devices/system/soc/mach/name<- Name of the mach
/sys/devices/system/soc/mach/foo_id
/sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs to export (IDCODE for OMAP, Production ID...)

Linus, do you agree?

>> I still think it is a solution in search of a problem though. What
>> userspace programs need to know what specific SoC they are on? My
>> feeling is that if userspace needs to know this information, then it is
>> probably dicking around with things that should be managed by the
>> kernel. Differences in available peripherals, etc can be determined by
>> looking at existing sysfs files.
> I certainly have seen several use cases. Couple of easy examples:
>
> * A lot of test scripts would find this very useful. For example, some
> clock (present is all/most MSMs) shouldn't be tested on some SOCs as it
> would lock up the system if you try to turn it off while the CPU is running.
>
> * Some of the user space tools might want to report different "product
> id/type" (nothing to do with USB, etc) depending on what SOC it is
> running on.
>

For example, we have some user-space tools which need to have serial 
number to write it in logs.

> Thank,
> Saravana
> P.S: Removed felipe.balbi at nokia.com<felipe.balbi@nokia.com>  since I
> keep getting delivery failure emails.
>

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Maxime Coquelin]

On 03/02/2011 04:54 AM, Ryan Mallon wrote:
> On 03/02/2011 04:46 PM, Saravana Kannan wrote:
>> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>>> The only real objection I have to adding the SoC family information is
>>> basically to discourage it being abused by userspace. I can see it being
>>> useful in debug situations, but I can also see stupid userspace
>>> applications explicitly testing for some particular SoC, rather than
>>> more correctly (IMHO) checking for presence of certain drivers etc.
>> True, but so many other things could be misused by stupid userspace
>> programs. When there are legitimate usecases, I think we shouldn't
>> prevent them just because we think a stupid userspace program could
>> misuse it.
>>
>> Again, although you might not be gung-ho about this, I think I have at
>> least made you indifferent/mildly supportive to adding socinfo. If you
>> don't mind, I would like to wait for others to chime in before
>> continuing this discussion.
> Agreed.
>
> In general I am in support of having the SoC information exposed
> somewhere. I think we just want to be careful that it doesn't become a
> dumping ground for anything and everything SoC related whether the
> information is useful or not. I think each piece of exposed information
> should have a genuine use case, not just "because we can".
I definitely agree we should not export every SoC-related information 
just because we can do it.
The first goal of this interface was to export some SoCs IDs, as we need 
this kind of information for some user-space tools.
Does someone need to export other information than the mach name and 
some IDs?

As proposed in my previous mail, do you agree to have a unified file for 
all vendors, which exports the unique silicon ID of the chip?

Regards,
Maxime

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Linus Walleij]

On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
<maxime.coquelin-nonst@stericsson.com> wrote:

> I think we should have a tree like this :
>
> /sys/devices/system/soc/
> /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs

Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
etc.

Should we say it's a hex string of 64 bits?

> /sys/devices/system/soc/mach/
> /sys/devices/system/soc/mach/name<- Name of the mach
> /sys/devices/system/soc/mach/foo_id
> /sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs
> to export (IDCODE for OMAP, Production ID...)

For Ux500 we can export the stuff we print today in mach-ux500/id.c,
put in place earlier by Rabin, I'd prefer if you hook in the new ID stuff
there as well, since it's so little platform code, and a logical place to
have it in.

> Linus, do you agree?

Yeah, sounds good.

Yours,
Linus Walleij

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Maxime Coquelin]

On 03/02/2011 11:36 AM, Linus Walleij wrote:
> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
> <maxime.coquelin-nonst@stericsson.com>  wrote:
>
>> I think we should have a tree like this :
>>
>> /sys/devices/system/soc/
>> /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
> etc.

Yes, here is the difficulty. For example, in our case, the SoC unique ID 
is 160 bits long.
Maybe it would be a better solution to get rid of this unified file, and 
keep only mach specific entries? I mean :

/sys/devices/system/soc/
/sys/devices/system/soc/mach_name
/sys/devices/system/soc/foo_id
/sys/devices/system/soc/bar_id


> Should we say it's a hex string of 64 bits?
>
>> /sys/devices/system/soc/mach/
>> /sys/devices/system/soc/mach/name<- Name of the mach
>> /sys/devices/system/soc/mach/foo_id
>> /sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs
>> to export (IDCODE for OMAP, Production ID...)
> For Ux500 we can export the stuff we print today in mach-ux500/id.c,
> put in place earlier by Rabin, I'd prefer if you hook in the new ID stuff
> there as well, since it's so little platform code, and a logical place to
> have it in.

I agree.

Regards,
Maxime

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Jamie Iles]

On Wed, Mar 02, 2011 at 11:36:38AM +0100, Linus Walleij wrote:
> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
> <maxime.coquelin-nonst@stericsson.com> wrote:
> 
> > I think we should have a tree like this :
> >
> > /sys/devices/system/soc/
> > /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
> 
> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
> etc.
> 
> Should we say it's a hex string of 64 bits?

Could we provide hooks for the platform that takes the buffer and length 
and let the platform do the snprintf()?  Our devices have a 128-bit 
serial number and I'm sure there must be others.

> > /sys/devices/system/soc/mach/
> > /sys/devices/system/soc/mach/name<- Name of the mach
> > /sys/devices/system/soc/mach/foo_id
> > /sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs
> > to export (IDCODE for OMAP, Production ID...)

Do we need a way to allow platforms to specify additional attributes to 
co into the socinfo?  For our devices we can boot in different modes and 
how we boot determines how the firmware is upgraded.  In the case above 
the platform could specify that it needs foo_id and bar_id and the 
callbacks to fill them in.

Jamie

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Maxime Coquelin]

On 03/02/2011 12:38 PM, Jamie Iles wrote:
> On Wed, Mar 02, 2011 at 11:36:38AM +0100, Linus Walleij wrote:
>> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
>> <maxime.coquelin-nonst@stericsson.com>  wrote:
>>
>>> I think we should have a tree like this :
>>>
>>> /sys/devices/system/soc/
>>> /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
>> etc.
>>
>> Should we say it's a hex string of 64 bits?
> Could we provide hooks for the platform that takes the buffer and length
> and let the platform do the snprintf()?  Our devices have a 128-bit
> serial number and I'm sure there must be others.

This is one possibility, another one is to let the platform specify how 
it exports this serial, as you proposed bellow.

>>> /sys/devices/system/soc/mach/
>>> /sys/devices/system/soc/mach/name<- Name of the mach
>>> /sys/devices/system/soc/mach/foo_id
>>> /sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs
>>> to export (IDCODE for OMAP, Production ID...)
> Do we need a way to allow platforms to specify additional attributes to
> co into the socinfo?  For our devices we can boot in different modes and
> how we boot determines how the firmware is upgraded.  In the case above
> the platform could specify that it needs foo_id and bar_id and the
> callbacks to fill them in.

Yes it was what I thought with the foo and bar IDs exports.

Maxime

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Linus Walleij]

2011/3/2 Jamie Iles <jamie@jamieiles.com>:

>> > /sys/devices/system/soc/
>> > /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
>>
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
>> etc.
>>
>> Should we say it's a hex string of 64 bits?
>
> Could we provide hooks for the platform that takes the buffer and length
> and let the platform do the snprintf()? ?Our devices have a 128-bit
> serial number and I'm sure there must be others.

Isn't it better to just make it 64-bit so that apps can always parse it,
and then you can have your high-res numbers under mach?

If there is no solid ABI for this there is no point to make it
generic under /soc/unique_id at all.

/soc/name is another useful thing to have I think.

Apart from this we are now en route to the same color of
bikeshed discussion this patchset saw earlier, Maxime please
just implement something that works for you/us so others
can patch in whatever they need on top later.

Yours,
Linus Walleij

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Jamie Iles]

On Wed, Mar 02, 2011 at 03:42:33PM +0100, Linus Walleij wrote:
> 2011/3/2 Jamie Iles <jamie@jamieiles.com>:
> 
> >> > /sys/devices/system/soc/
> >> > /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
> >>
> >> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
> >> etc.
> >>
> >> Should we say it's a hex string of 64 bits?
> >
> > Could we provide hooks for the platform that takes the buffer and length
> > and let the platform do the snprintf()? ?Our devices have a 128-bit
> > serial number and I'm sure there must be others.
> 
> Isn't it better to just make it 64-bit so that apps can always parse it,
> and then you can have your high-res numbers under mach?
> 
> If there is no solid ABI for this there is no point to make it
> generic under /soc/unique_id at all.

I guess I'd argue that a arbitrary length hex string could be considered 
as a solid ABI but you're right that it's probably more important to get 
something out there and I'm probably being too picky, so apologies!

Jamie

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Ryan Mallon]

On 03/02/2011 09:50 PM, Maxime Coquelin wrote:
> On 03/02/2011 04:54 AM, Ryan Mallon wrote:
>> On 03/02/2011 04:46 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>>>> The only real objection I have to adding the SoC family information is
>>>> basically to discourage it being abused by userspace. I can see it
>>>> being
>>>> useful in debug situations, but I can also see stupid userspace
>>>> applications explicitly testing for some particular SoC, rather than
>>>> more correctly (IMHO) checking for presence of certain drivers etc.
>>> True, but so many other things could be misused by stupid userspace
>>> programs. When there are legitimate usecases, I think we shouldn't
>>> prevent them just because we think a stupid userspace program could
>>> misuse it.
>>>
>>> Again, although you might not be gung-ho about this, I think I have at
>>> least made you indifferent/mildly supportive to adding socinfo. If you
>>> don't mind, I would like to wait for others to chime in before
>>> continuing this discussion.
>> Agreed.
>>
>> In general I am in support of having the SoC information exposed
>> somewhere. I think we just want to be careful that it doesn't become a
>> dumping ground for anything and everything SoC related whether the
>> information is useful or not. I think each piece of exposed information
>> should have a genuine use case, not just "because we can".
> I definitely agree we should not export every SoC-related information
> just because we can do it.
> The first goal of this interface was to export some SoCs IDs, as we need
> this kind of information for some user-space tools.
> Does someone need to export other information than the mach name and
> some IDs?
> 
> As proposed in my previous mail, do you agree to have a unified file for
> all vendors, which exports the unique silicon ID of the chip?

As mentioned earlier, on ep93xx we would like to export the Maverick
Crunch ID, which is a unique identifier for the chip.

I think the ABI should specify a minimum set of values which are
guaranteed to be provided on all SoCs, but allow individual SoCs to
provide additional information as necessary.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[Saravana Kannan]

On 03/02/2011 02:53 AM, Maxime Coquelin wrote:
> On 03/02/2011 11:36 AM, Linus Walleij wrote:
>> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
>> <maxime.coquelin-nonst@stericsson.com> wrote:
>>
>>> I think we should have a tree like this :
>>>
>>> /sys/devices/system/soc/
>>> /sys/devices/system/soc/unique_id<- Unified way to export an ID for
>>> all machs
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have
>> 32-bit
>> etc.
>
> Yes, here is the difficulty. For example, in our case, the SoC unique ID
> is 160 bits long.
> Maybe it would be a better solution to get rid of this unified file, and
> keep only mach specific entries? I mean :
>
> /sys/devices/system/soc/
> /sys/devices/system/soc/mach_name
> /sys/devices/system/soc/foo_id
> /sys/devices/system/soc/bar_id

Sorry for the late reply guys. Got wrapped up is some other stuff.

I'm with Maxime on getting rid of the unique id file. It's not as if 
it's unique across all machs and archs. Any user space caring to look at 
the id will anyway have to check the mach/family first. So, there is no 
point in having this unique id file. It just adds more weirdness and 
complexity to deal with the different formats or ways each family wants 
to export the id. Actually, in the case of MSM, we don't have any need 
to export unique id. We just want to export what type of soc it is 
within the MSM family.

As for the path, it's not clear we have settled on the final path. I see 
us ping-pong between /sys/devices/system/soc/ and 
/sys/devices/system/soc/mach/. Can we drop the "mach" subdir? Seems 
pointless.

The mandatory file, I would like to call it "family", since "mach" is 
too specific (omap3 and omap4 is my usual example -- they can have one 
implementation of socinfo and report the family as "omap"). We don't 
want people to misunderstand "mach" to be an accurate representation of 
the xxxx in mach-xxxx.

The patch that adds this should probably allow each socinfo 
implementation to specify the family name and an array of attributes 
(struct attribute *) that can be used to expose whatever else they want 
to export.

Thanks,
Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.