Introduce the /proc/socinfo and use it to export OMAP data

From: Eduardo Valentin <[email protected]>

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

Signed-off-by Eduardo Valentin <[email protected]>

---
 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(-)

arch/arm/mach-omap2/id.c +0 -0

index 37b8a1a..b67486b 100644

Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:

Quoted 11 lines

From: Eduardo Valentin <[email protected]>

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

Signed-off-by Eduardo Valentin <[email protected]>

---
 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(-)

[..]

Quoted 4 lines

arch/arm/mach-omap2/id.c +0 -0

index 37b8a1a..b67486b 100644

[..]

Quoted 8 lines

arch/arm/mach-omap2/id.c +2 -1

@@ -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);
 

arch/arm/mach-omap2/id.c void __init omap3_cpuinfo(void) · line 370

Quoted 2 lines

arch/arm/mach-omap2/id.c +0 -0

 	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..

[..]

Signature · 2 lines

Regards,
Nishanth Menon

Hello Nishanth,

Quoted 28 lines · ext Nishanth Menon

Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:

Quoted 11 lines

From: Eduardo Valentin <[email protected]>

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

Signed-off-by Eduardo Valentin <[email protected]>

---
 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(-)

[..]

Quoted 4 lines

arch/arm/mach-omap2/id.c +0 -0

index 37b8a1a..b67486b 100644

[..]

Quoted 8 lines

arch/arm/mach-omap2/id.c +2 -1

@@ -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);
 

Quoted 5 lines

arch/arm/mach-omap2/id.c void __init omap3_cpuinfo(void) · line 370

Quoted 2 lines

arch/arm/mach-omap2/id.c +0 -0

 	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.

Quoted 8 lines

[..]

Signature · 2 lines

Regards,
Nishanth Menon

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

Hello,

Quoted 36 lines · Valentin Eduardo (Nokia-D/Helsinki)

Hello Nishanth,

Quoted 28 lines · ext Nishanth Menon

Eduardo Valentin had written, on 05/11/2010 09:15 AM, the following:

Quoted 11 lines

From: Eduardo Valentin <[email protected]>

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

Signed-off-by Eduardo Valentin <[email protected]>

---
 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(-)

[..]

Quoted 4 lines

arch/arm/mach-omap2/id.c +0 -0

index 37b8a1a..b67486b 100644

[..]

Quoted 8 lines

arch/arm/mach-omap2/id.c +2 -1

@@ -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);
 

Quoted 5 lines

arch/arm/mach-omap2/id.c void __init omap3_cpuinfo(void) · line 370

Quoted 2 lines

arch/arm/mach-omap2/id.c +0 -0

 	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..

Quoted 5 lines

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.

Quoted 11 lines

Quoted 6 lines

[..]

Signature · 2 lines

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/

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.

Quoted 13 lines · On Tue, 11 May 2010 17:15:28 +0300 Eduardo Valentin…

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

Quoted 1 line

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/[email protected]/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 :(

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".

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.

2010/5/11 Eduardo Valentin <[email protected]>:

Quoted 13 lines

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

Quoted 1 line

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

Hello Linus,

Quoted 15 lines · ext Linus Walleij

2010/5/11 Eduardo Valentin<[email protected]>:

Quoted 13 lines

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

Quoted 2 lines

Quoted 1 line

As usual, comments are welcome.

Eduardo, what has happened to this patchset?

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

Quoted 1 line

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?

Hello Eduardo,

Quoted 2 lines · Eduardo Valentin

Quoted 1 line

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.

Quoted 4 lines

Quoted 1 line

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).

Quoted 18 lines · Maxime Coquelin

Hello Eduardo,

Quoted 4 lines · Eduardo Valentin

Quoted 2 lines

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.

Quoted 6 lines

Quoted 1 line

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?

Quoted 7 lines

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/.

Quoted 4 lines

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?

Quoted 46 lines · Saravana Kannan

Quoted 18 lines · Maxime Coquelin

Hello Eduardo,

Quoted 4 lines · Eduardo Valentin

Quoted 2 lines

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.

Quoted 6 lines

Quoted 1 line

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?

Quoted 7 lines

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/.

Quoted 4 lines

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.

Quoted 2 lines

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?

Quoted 2 lines · Andrei Warkentin

On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
<[email protected]> wrote:

Quoted 1 line

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).

Quoted 3 lines · Saravana Kannan

Quoted 2 lines · Andrei Warkentin

On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
<[email protected]> wrote:

<snip>

Quoted 7 lines

Quoted 1 line

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?

Quoted 18 lines · Ryan Mallon

Quoted 3 lines · Saravana Kannan

Quoted 2 lines · Andrei Warkentin

On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
<[email protected]> wrote:

<snip>

Quoted 7 lines

Quoted 1 line

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.

Quoted 1 line

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.

Quoted 19 lines · Saravana Kannan

Quoted 18 lines · Ryan Mallon

Quoted 3 lines · Saravana Kannan

Quoted 2 lines · Andrei Warkentin

On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
<[email protected]> wrote:

<snip>

Quoted 7 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 1 line

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.

Quoted 42 lines · Ryan Mallon

Quoted 22 lines · Saravana Kannan

Quoted 21 lines · Ryan Mallon

Quoted 3 lines · Saravana Kannan

Quoted 2 lines · Andrei Warkentin

On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
<[email protected]> wrote:

<snip>

Quoted 10 lines

Quoted 1 line

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.

Quoted 7 lines

Quoted 1 line

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.

Quoted 3 lines

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.

Quoted 4 lines · Saravana Kannan

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.

Quoted 10 lines · Ryan Mallon

Quoted 4 lines · Saravana Kannan

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.

Quoted 6 lines

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.

Quoted 18 lines · Saravana Kannan

Quoted 10 lines · Ryan Mallon

Quoted 4 lines · Saravana Kannan

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.

Quoted 4 lines

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/.

Quoted 11 lines

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

Quoted 6 lines

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:

Quoted 4 lines

* 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? :-).

Quoted 3 lines

* 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.

Quoted 22 lines · Ryan Mallon

Quoted 21 lines · Saravana Kannan

Quoted 8 lines · Ryan Mallon

Quoted 6 lines · Saravana Kannan

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.

Quoted 5 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 11 lines

Quoted 11 lines

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

Quoted 6 lines

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:

Quoted 8 lines

Quoted 4 lines

* 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.

Quoted 6 lines

Quoted 3 lines

* 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.

Quoted 54 lines · Saravana Kannan

Quoted 22 lines · Ryan Mallon

Quoted 21 lines · Saravana Kannan

Quoted 8 lines · Ryan Mallon

Quoted 6 lines · Saravana Kannan

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.

Quoted 5 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 11 lines

Quoted 11 lines

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

Quoted 6 lines

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:

Quoted 8 lines

Quoted 4 lines

* 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? :-).

Quoted 6 lines

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.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

* 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.

Quoted 5 lines · Ryan Mallon

Quoted 4 lines · Saravana Kannan

Quoted 3 lines · Ryan Mallon

Quoted 2 lines · Saravana Kannan

Quoted 1 line · Ryan Mallon

On 03/02/2011 03:23 PM, Saravana Kannan wrote:

Quoted 5 lines

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.

Quoted 11 lines · Saravana Kannan

Quoted 5 lines · Ryan Mallon

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.

Quoted 4 lines

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".

Quoted 17 lines · Ryan Mallon

Quoted 12 lines · Saravana Kannan

Quoted 6 lines · Ryan Mallon

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.

Quoted 4 lines

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.

Quoted 7 lines

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?

Quoted 9 lines · Ryan Mallon

Quoted 4 lines · Saravana Kannan

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.

Quoted 6 lines

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<[email protected]> since I keep getting delivery failure emails.

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?

Quoted 4 lines · Maxime Coquelin

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?

Quoted 5 lines

/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.

Quoted 11 lines · Linus Walleij

Quoted 5 lines · Maxime Coquelin

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

Quoted 2 lines · Maxime Coquelin

I think we should have a tree like this :

Quoted 2 lines

/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?

Quoted 5 lines

/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...)

Quoted 7 lines · Linus Walleij

Quoted 4 lines · Maxime Coquelin

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

Quoted 4 lines

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.

Quoted 5 lines

Quoted 5 lines

/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.

Quoted 7 lines

Quoted 2 lines

/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.

2011/3/2 Jamie Iles <[email protected]>:

Quoted 11 lines

Quoted 7 lines

Quoted 2 lines

/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.