Export SoC info through sysfs
Subsystems (5)
v2 cover Export SoC info through sysfs
Here is the second version of the proposal to export SoC related information to user-space through sysFS interface.
The first patch introduces the common part, which provides an interface to the platform to export platform-defined IDs to user-space. The IDs strings can be provided in two ways: either with a pointer to the string, or by a callback fullfilling the sysfs's "show" callback buffer.
The second patch is given as example for the ux500 architecture. It registers the socinfo interface, and exports 5 values (Family name, machine name, silicon process, silicon revision, and serial number).
Here is the output for DB8500:
root at ME:/sys/socinfo ls -l
-r--r--r-- 1 root root 4096 Jan 2 03:35 family -r--r--r-- 1 root root 4096 Jan 2 03:35 machine -r--r--r-- 1 root root 4096 Jan 2 03:35 process -r--r--r-- 1 root root 4096 Jan 2 03:35 revision -r--r--r-- 1 root root 4096 Jan 2 03:35 soc_id
root at ME:/sys/socinfo cat machine
DB8500
root at ME:/sys/socinfo cat family
Ux500
root at ME:/sys/socinfo cat process
Standard
root at ME:/sys/socinfo cat revision
2.0
root at ME:/sys/socinfo cat soc_id2ba07ce9e5835d6185321e9577462ef2ea2129cf
-------------------------------------------------------------------------------
v1:
Conclusion about first version :
* /sys/devices/system is not right place for this interface.
* "mach_name" should be declared as other attributes to simplify code.
* The get_info callback should use directly the "show" callback buffer.
* Documentation was missing (ABI description required)
* Errors were not reported at registration time.
* Macros should be used to create attributes.
* Some kernel coding rules not followed.
-------------------------------------------------------------------------------
Any comments are welcome.
Note that I will be off from 13th to 21th of March.
Regards,
Maxime
-------------------------------------------------------------------------------
Maxime Coquelin (2):
Export SoC info through sysfs
ux500: Export U8500 SoC info through sysfs
Documentation/ABI/testing/sysfs-socinfo | 16 ++++++ arch/arm/mach-ux500/Kconfig | 1 + arch/arm/mach-ux500/id.c | 70 +++++++++++++++++++++++++++ drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++ include/linux/sys_soc.h | 50 +++++++++++++++++++ 7 files changed, 220 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-socinfo create mode 100644 drivers/base/soc.c create mode 100644 include/linux/sys_soc.h
RFC PATCH v2 1/2 Export SoC info through sysfs
Common base to export System-on-Chip related informations through sysfs.
Creation of a "socinfo" directory under /sys/.
Creation of SoC information entries.
--- Documentation/ABI/testing/sysfs-socinfo | 16 ++++++ drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++ include/linux/sys_soc.h | 50 +++++++++++++++++++ 5 files changed, 149 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-socinfo create mode 100644 drivers/base/soc.c create mode 100644 include/linux/sys_soc.h
Documentation/ABI/testing/sysfs-socinfo new file +16 -0
@@ -0,0 +1,16 @@ +What: /sys/socinfo +Date: March 2011 +contact: Maxime Coquelin <[email protected]> +Description: + The /sys/socinfo directory contains information about the + System-on-Chip. It is only available if platform implements it. + This directory contains two kind of attributes : + - common attributes: + * machine: the name of the machine. + * family: the family name of the SoC + - SoC-specific attributes: The SoC vendor can declare attributes + to export some strings to user-space, like the serial-number for + example. + +Users: + User-space applications which needs these kind of attributes.
drivers/base/Kconfig +3 -0
@@ -168,4 +168,7 @@ config SYS_HYPERVISOR bool default n +config SYS_SOC + bool + endmenu
drivers/base/Makefile +1 -0
@@ -18,6 +18,7 @@ ifeq ($(CONFIG_SYSFS),y) obj-$(CONFIG_MODULES) += module.o endif obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o +obj-$(CONFIG_SYS_SOC) += soc.o ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
drivers/base/soc.c new file +79 -0
79 lines not on this page · raw message
include/linux/sys_soc.h new file +50 -0
50 lines not on this page · raw message
Signature · 1 line
1.7.1
RFC PATCH v2 1/2 Export SoC info through sysfs
Hello,
Quoted 111 lines · ext Maxime Coquelin
Common base to export System-on-Chip related informations through sysfs.
Creation of a "socinfo" directory under
/sys/.
Creation of SoC information entries.Signed-off-by Maxime COQUELIN <[email protected]>--- Documentation/ABI/testing/sysfs-socinfo | 16 ++++++ drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++ include/linux/sys_soc.h | 50 +++++++++++++++++++ 5 files changed, 149 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-socinfo create mode 100644 drivers/base/soc.c create mode 100644 include/linux/sys_soc.hDocumentation/ABI/testing/sysfs-socinfo new file +16
-0@@ -0,0 +1,16 @@ +What: /sys/socinfo +Date: March 2011 +contact: Maxime Coquelin <[email protected]> +Description: + The /sys/socinfo directory contains information about the + System-on-Chip. It is only available if platform implements it. + This directory contains two kind of attributes : + - common attributes: + * machine: the name of the machine. + * family: the family name of the SoC + - SoC-specific attributes: The SoC vendor can declare attributes + to export some strings to user-space, like the serial-number for + example. + +Users: + User-space applications which needs these kind of attributes.drivers/base/Kconfig +3
-0@@ -168,4 +168,7 @@ config SYS_HYPERVISOR bool default n +config SYS_SOC + bool + endmenudrivers/base/Makefile +1
-0@@ -18,6 +18,7 @@ ifeq ($(CONFIG_SYSFS),y) obj-$(CONFIG_MODULES) += module.o endif obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o +obj-$(CONFIG_SYS_SOC) += soc.o ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUGdrivers/base/soc.c new file +42
-0@@ -0,0 +1,79 @@ +/* +* Copyright (C) ST-Ericsson SA 2011 +* Author: Maxime Coquelin <[email protected]> for ST-Ericsson. +* License terms: GNU General Public License (GPL), version 2 +*/ + +#include <linux/sysfs.h> +#include <linux/module.h> +#include <linux/init.h> +#include <linux/stat.h> +#include <linux/slab.h> +#include <linux/sys_soc.h> + +struct kobject *soc_object; + +ssize_t show_soc_info (struct kobject *kobj, +struct kobj_attribute *attr,char *buf) +{ +struct sysfs_soc_info *si =container_of (attr, + struct sysfs_soc_info, attr); + +if (si->info) +return sprintf (buf,"%s\n" , si->info); + +return si->get_info (buf, si); +} + +int __init register_sysfs_soc_info (struct sysfs_soc_info *info,int nb_info) +{ +int i, ret; + +for (i =0 ; i < nb_info; i++) { + ret =sysfs_create_file (soc_object, &info[i].attr.attr); +if (ret) { +for (i -=1 ; i >=0 ; i--) +sysfs_remove_file (soc_object, &info[i].attr.attr); +break ; + } + } + +return ret; +}
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 25 lines
Quoted 9 lines
drivers/base/soc.c new file +6
-0+ +int __init register_sysfs_soc_info (struct sysfs_soc_info *info,int nb_info) +{ +int i, ret; + +for (i =0 ; i< nb_info; i++) {drivers/base/soc.c line 42
Quoted 10 lines
drivers/base/soc.c new file +10
-0+ ret =sysfs_create_file (soc_object,&info[i].attr.attr); +if (ret) { +for (i -=1 ; i>=0 ; i--) +sysfs_remove_file (soc_object,&info[i].attr.attr); +break ; + } + } + +return ret; +}From functional perspective, this looks like a
sysfs_create_group.
Now it makes me wonder if this thing would make sense. Maybe it's better to create a node under platform and then add attributes to it, as suggested in V1 thread. I don't know, this could still be done by the socinfo code. I mean, location is still an issue it seams :-)
Quoted 3 lines
Another thing, what could be done is, instead of creating new data structures to hold the attributes, a struct
attribute_groupcould be pass instead during registration time. What do you think??
It would be cleaner indeed.
Quoted 10 lines
drivers/base/soc.c line 50
Quoted 8 lines
drivers/base/soc.c new file +8
-0+ +static struct attribute *soc_attrs[] = { +NULL , +}; + +static struct attribute_group soc_attr_group = { + .attrs = soc_attrs, +};What is the point of the above two ?
sysfs_create_group() requires attributes.
Quoted 22 lines
Quoted 4 lines
drivers/base/soc.c new file +4
-0+ +int __init register_sysfs_soc (struct sysfs_soc_info *info,size_t num) +{ +int ret;drivers/base/soc.c line 64
Quoted 10 lines
drivers/base/soc.c new file +10
-0+ + soc_object =kobject_create_and_add ("socinfo" ,NULL ); +if (!soc_object) { + ret = -ENOMEM ; + goto exit; + } + + ret =sysfs_create_group (soc_object,&soc_attr_group); +if (ret) + goto kset_exit;You add an empty group here.
drivers/base/soc.c line 68
Quoted 4 lines
drivers/base/soc.c new file +4
-0+ + ret =register_sysfs_soc_info (info, num); +if (ret) + goto group_exit;But the real thing happens here.
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 42 lines · ext Maxime Coquelin
Quoted 25 lines
Quoted 9 lines
drivers/base/soc.c new file +6
-0+ +int __init register_sysfs_soc_info (struct sysfs_soc_info *info,int nb_info) +{ +int i, ret; + +for (i =0 ; i< nb_info; i++) {drivers/base/soc.c line 42
Quoted 10 lines
drivers/base/soc.c new file +10
-0+ ret =sysfs_create_file (soc_object,&info[i].attr.attr); +if (ret) { +for (i -=1 ; i>=0 ; i--) +sysfs_remove_file (soc_object,&info[i].attr.attr); +break ; + } + } + +return ret; +}From functional perspective, this looks like a
sysfs_create_group. Now it makes me wonder if this thing would make sense. Maybe it's better to create a node under platform and then add attributes to it, as suggested in V1 thread. I don't know, this could still be done by the socinfo code. I mean, location is still an issue it seams :-)Quoted 3 lines
Another thing, what could be done is, instead of creating new data structures to hold the attributes, a struct
attribute_groupcould be pass instead during registration time. What do you think??It would be cleaner indeed.
Quoted 10 lines
drivers/base/soc.c line 50
Quoted 8 lines
drivers/base/soc.c new file +8
-0+ +static struct attribute *soc_attrs[] = { +NULL , +}; + +static struct attribute_group soc_attr_group = { + .attrs = soc_attrs, +};What is the point of the above two ?
Quoted 1 line
sysfs_create_group()requires attributes.
Indeed, it does. but you call it with an empty set of attributes. So, what's the point?
Quoted 24 lines
Quoted 23 lines
Quoted 5 lines
drivers/base/soc.c new file +4
-0+ +int __init register_sysfs_soc (struct sysfs_soc_info *info,size_t num) +{ +int ret;drivers/base/soc.c line 64
Quoted 10 lines
drivers/base/soc.c new file +10
-0+ + soc_object =kobject_create_and_add ("socinfo" ,NULL ); +if (!soc_object) { + ret = -ENOMEM ; + goto exit; + } + + ret =sysfs_create_group (soc_object,&soc_attr_group); +if (ret) + goto kset_exit;You add an empty group here.
drivers/base/soc.c line 68
Quoted 4 lines
drivers/base/soc.c new file +4
-0+ + ret =register_sysfs_soc_info (info, num); +if (ret) + goto group_exit;But the real thing happens here.
Signature · 1 line
Eduardo Valentin
RFC PATCH v2 1/2 Export SoC info through sysfs
In reply to Maxime CoquelinQuoted 6 lines · Maxime Coquelin
Common base to export System-on-Chip related informations through sysfs.
Creation of a "socinfo" directory under
/sys/.
Creation of SoC information entries.Signed-off-by Maxime COQUELIN <[email protected]>
I think it's better than the previous patch to create an artificial device in /sys/devices/system/socinfo, but I'd still prefer the information to be attached to a real device that represents the SOC, as I explained in the discussion with Linus Walleij.
You should definitely add Greg on Cc, as he's maintaining sysfs and certainly has an opininion here.
Arnd
Quoted 79 lines
--- Documentation/ABI/testing/sysfs-socinfo | 16 ++++++ drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++ include/linux/sys_soc.h | 50 +++++++++++++++++++ 5 files changed, 149 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-socinfo create mode 100644 drivers/base/soc.c create mode 100644 include/linux/sys_soc.hDocumentation/ABI/testing/sysfs-socinfo new file +16
-0@@ -0,0 +1,16 @@ +What: /sys/socinfo +Date: March 2011 +contact: Maxime Coquelin <[email protected]> +Description: + The /sys/socinfo directory contains information about the + System-on-Chip. It is only available if platform implements it. + This directory contains two kind of attributes : + - common attributes: + * machine: the name of the machine. + * family: the family name of the SoC + - SoC-specific attributes: The SoC vendor can declare attributes + to export some strings to user-space, like the serial-number for + example. + +Users: + User-space applications which needs these kind of attributes.drivers/base/Kconfig +3
-0@@ -168,4 +168,7 @@ config SYS_HYPERVISOR bool default n +config SYS_SOC + bool + endmenudrivers/base/Makefile +1
-0@@ -18,6 +18,7 @@ ifeq ($(CONFIG_SYSFS),y) obj-$(CONFIG_MODULES) += module.o endif obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o +obj-$(CONFIG_SYS_SOC) += soc.o ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUGdrivers/base/soc.c new file +16
-0@@ -0,0 +1,79 @@ +/* +* Copyright (C) ST-Ericsson SA 2011 +* Author: Maxime Coquelin <[email protected]> for ST-Ericsson. +* License terms: GNU General Public License (GPL), version 2 +*/ + +#include <linux/sysfs.h> +#include <linux/module.h> +#include <linux/init.h> +#include <linux/stat.h> +#include <linux/slab.h> +#include <linux/sys_soc.h> + +struct kobject *soc_object; + +ssize_t show_soc_info(struct kobject *kobj,
drivers/base/soc.c line 26
Quoted 10 lines
drivers/base/soc.c new file +10
-0+ struct kobj_attribute *attr, char *buf) +{ + struct sysfs_soc_info *si = container_of(attr, + struct sysfs_soc_info, attr); + +if (si->info) +return sprintf (buf,"%s\n" , si->info); + +return si->get_info (buf, si); +}
I think this can be simplified by just letting the soc register its own show method instead of the get_info function.
Quoted 109 lines
drivers/base/soc.c new file +52
-0+int __init register_sysfs_soc_info (struct sysfs_soc_info *info,int nb_info) +{ +int i, ret; + +for (i =0 ; i < nb_info; i++) { + ret =sysfs_create_file (soc_object, &info[i].attr.attr); +if (ret) { +for (i -=1 ; i >=0 ; i--) +sysfs_remove_file (soc_object, &info[i].attr.attr); +break ; + } + } + +return ret; +} + +static struct attribute *soc_attrs[] = { +NULL , +}; + +static struct attribute_group soc_attr_group = { + .attrs = soc_attrs, +}; + +int __init register_sysfs_soc (struct sysfs_soc_info *info,size_t num) +{ +int ret; + + soc_object =kobject_create_and_add ("socinfo" ,NULL ); +if (!soc_object) { + ret = -ENOMEM ; + goto exit; + } + + ret =sysfs_create_group (soc_object, &soc_attr_group); +if (ret) + goto kset_exit; + + ret =register_sysfs_soc_info (info, num); +if (ret) + goto group_exit; + +return 0 ; + +group_exit: +sysfs_remove_group (soc_object, &soc_attr_group); +kset_exit: +kobject_put (soc_object); +exit: +return ret; +} +include/linux/sys_soc.h new file +50
-0@@ -0,0 +1,50 @@ +/* +* Copyright (C) ST-Ericsson SA 2011 +* Author: Maxime Coquelin <[email protected]> for ST-Ericsson. +* License terms: GNU General Public License (GPL), version 2 +*/ +#ifndef __SYS_SOC_H +#define __SYS_SOC_H + +#include <linux/kobject.h> + +/** +* struct sys_soc_info - SoC exports related informations +* @name: name of the export +* @info: pointer on the key to export +* @get_info: callback to retrieve key if info field is NULL +* @attr: export's sysdev class attribute +*/ +struct sysfs_soc_info { +const char *info; +ssize_t (*get_info)(char *buf,struct sysfs_soc_info *); +struct kobj_attribute attr; +}; + +ssize_t show_soc_info (struct kobject *,struct kobj_attribute *,char *); + +#define SYSFS_SOC_ATTR_VALUE (_name, _value) { \ + .attr.attr.name = _name, \ + .attr.attr.mode = S_IRUGO, \ + .attr.show = show_soc_info, \ + .info = _value, \ +} + +#define SYSFS_SOC_ATTR_CALLBACK (_name, _callback) { \ + .attr.attr.name = _name, \ + .attr.attr.mode = S_IRUGO, \ + .attr.show = show_soc_info, \ + .get_info = _callback, \ +} + +/** +* register_sys_soc - register the soc information +* @name: name of the machine +* @info: pointer on the info table to export +* @num: number of info to export +* +* NOTE: This function must only be called once +*/ +int register_sysfs_soc (struct sysfs_soc_info *info,size_t num); + +#endif /* __SYS_SOC_H */
RFC PATCH v2 1/2 Export SoC info through sysfs
Hello,
Quoted 6 lines · ext Arnd Bergmann
Quoted 5 lines · Maxime Coquelin
Common base to export System-on-Chip related informations through sysfs.
Creation of a "socinfo" directory under
/sys/.
Creation of SoC information entries.
Quoted 7 lines
Quoted 1 line
Signed-off-by Maxime COQUELIN <[email protected]>I think it's better than the previous patch to create an artificial device in
/sys/devices/system/socinfo, but I'd still prefer the information to be attached to a real device that represents the SOC, as I explained in the discussion with Linus Walleij.
True.
Quoted 90 lines
You should definitely add Greg on Cc, as he's maintaining sysfs and certainly has an opininion here.
Arnd
Quoted 84 lines
--- Documentation/ABI/testing/sysfs-socinfo | 16 ++++++ drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++ include/linux/sys_soc.h | 50 +++++++++++++++++++ 5 files changed, 149 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-socinfo create mode 100644 drivers/base/soc.c create mode 100644 include/linux/sys_soc.hDocumentation/ABI/testing/sysfs-socinfo new file +16
-0@@ -0,0 +1,16 @@ +What: /sys/socinfo +Date: March 2011 +contact: Maxime Coquelin <[email protected]> +Description: + The /sys/socinfo directory contains information about the + System-on-Chip. It is only available if platform implements it. + This directory contains two kind of attributes : + - common attributes: + * machine: the name of the machine. + * family: the family name of the SoC + - SoC-specific attributes: The SoC vendor can declare attributes + to export some strings to user-space, like the serial-number for + example. + +Users: + User-space applications which needs these kind of attributes.drivers/base/Kconfig +3
-0@@ -168,4 +168,7 @@ config SYS_HYPERVISOR bool default n +config SYS_SOC + bool + endmenudrivers/base/Makefile +1
-0@@ -18,6 +18,7 @@ ifeq ($(CONFIG_SYSFS),y) obj-$(CONFIG_MODULES) += module.o endif obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o +obj-$(CONFIG_SYS_SOC) += soc.o ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUGdrivers/base/soc.c new file +21
-0@@ -0,0 +1,79 @@ +/* +* Copyright (C) ST-Ericsson SA 2011 +* Author: Maxime Coquelin <[email protected]> for ST-Ericsson. +* License terms: GNU General Public License (GPL), version 2 +*/ + +#include <linux/sysfs.h> +#include <linux/module.h> +#include <linux/init.h> +#include <linux/stat.h> +#include <linux/slab.h> +#include <linux/sys_soc.h> + +struct kobject *soc_object; + +ssize_t show_soc_info (struct kobject *kobj, +struct kobj_attribute *attr,char *buf) +{ +struct sysfs_soc_info *si =container_of (attr, + struct sysfs_soc_info, attr); +
Quoted 8 lines
drivers/base/soc.c line 26
Quoted 5 lines
drivers/base/soc.c new file +5
-0+if (si->info) +return sprintf (buf,"%s\n" , si->info); + +return si->get_info (buf, si); +}I think this can be simplified by just letting the soc register its own show method instead of the
get_infofunction.
Indeed. One way to do it is to use attribute_group, as I mentioned on other email.
Quoted 110 lines
Quoted 110 lines
drivers/base/soc.c new file +52
-0+int __init register_sysfs_soc_info (struct sysfs_soc_info *info,int nb_info) +{ +int i, ret; + +for (i =0 ; i < nb_info; i++) { + ret =sysfs_create_file (soc_object, &info[i].attr.attr); +if (ret) { +for (i -=1 ; i >=0 ; i--) +sysfs_remove_file (soc_object, &info[i].attr.attr); +break ; + } + } + +return ret; +} + +static struct attribute *soc_attrs[] = { +NULL , +}; + +static struct attribute_group soc_attr_group = { + .attrs = soc_attrs, +}; + +int __init register_sysfs_soc (struct sysfs_soc_info *info,size_t num) +{ +int ret; + + soc_object =kobject_create_and_add ("socinfo" ,NULL ); +if (!soc_object) { + ret = -ENOMEM ; + goto exit; + } + + ret =sysfs_create_group (soc_object, &soc_attr_group); +if (ret) + goto kset_exit; + + ret =register_sysfs_soc_info (info, num); +if (ret) + goto group_exit; + +return 0 ; + +group_exit: +sysfs_remove_group (soc_object, &soc_attr_group); +kset_exit: +kobject_put (soc_object); +exit: +return ret; +} +include/linux/sys_soc.h new file +50
-0@@ -0,0 +1,50 @@ +/* +* Copyright (C) ST-Ericsson SA 2011 +* Author: Maxime Coquelin <[email protected]> for ST-Ericsson. +* License terms: GNU General Public License (GPL), version 2 +*/ +#ifndef __SYS_SOC_H +#define __SYS_SOC_H + +#include <linux/kobject.h> + +/** +* struct sys_soc_info - SoC exports related informations +* @name: name of the export +* @info: pointer on the key to export +* @get_info: callback to retrieve key if info field is NULL +* @attr: export's sysdev class attribute +*/ +struct sysfs_soc_info { +const char *info; +ssize_t (*get_info)(char *buf,struct sysfs_soc_info *); +struct kobj_attribute attr; +}; + +ssize_t show_soc_info (struct kobject *,struct kobj_attribute *,char *); + +#define SYSFS_SOC_ATTR_VALUE (_name, _value) { \ + .attr.attr.name = _name, \ + .attr.attr.mode = S_IRUGO, \ + .attr.show = show_soc_info, \ + .info = _value, \ +} + +#define SYSFS_SOC_ATTR_CALLBACK (_name, _callback) { \ + .attr.attr.name = _name, \ + .attr.attr.mode = S_IRUGO, \ + .attr.show = show_soc_info, \ + .get_info = _callback, \ +} + +/** +* register_sys_soc - register the soc information +* @name: name of the machine +* @info: pointer on the info table to export +* @num: number of info to export +* +* NOTE: This function must only be called once +*/ +int register_sysfs_soc (struct sysfs_soc_info *info,size_t num); + +#endif /* __SYS_SOC_H */
Signature · 1 line
Eduardo Valentin
RFC PATCH v2 1/2 Export SoC info through sysfs
In reply to Arnd BergmannQuoted 6 lines · Arnd Bergmann
Quoted 5 lines · Maxime Coquelin
Common base to export System-on-Chip related informations through sysfs.
Creation of a "socinfo" directory under
/sys/.
Creation of SoC information entries.
Quoted 7 lines
Quoted 1 line
Signed-off-by Maxime COQUELIN <[email protected]>I think it's better than the previous patch to create an artificial device in
/sys/devices/system/socinfo, but I'd still prefer the information to be attached to a real device that represents the SOC, as I explained in the discussion with Linus Walleij.
Why not create it under the cpu directory?
Quoted 212 lines
You should definitely add Greg on Cc, as he's maintaining sysfs and certainly has an opininion here.
Arnd
Quoted 79 lines
--- Documentation/ABI/testing/sysfs-socinfo | 16 ++++++ drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++ include/linux/sys_soc.h | 50 +++++++++++++++++++ 5 files changed, 149 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-socinfo create mode 100644 drivers/base/soc.c create mode 100644 include/linux/sys_soc.hDocumentation/ABI/testing/sysfs-socinfo new file +16
-0@@ -0,0 +1,16 @@ +What: /sys/socinfo +Date: March 2011 +contact: Maxime Coquelin <[email protected]> +Description: + The /sys/socinfo directory contains information about the + System-on-Chip. It is only available if platform implements it. + This directory contains two kind of attributes : + - common attributes: + * machine: the name of the machine. + * family: the family name of the SoC + - SoC-specific attributes: The SoC vendor can declare attributes + to export some strings to user-space, like the serial-number for + example. + +Users: + User-space applications which needs these kind of attributes.drivers/base/Kconfig +3
-0@@ -168,4 +168,7 @@ config SYS_HYPERVISOR bool default n +config SYS_SOC + bool + endmenudrivers/base/Makefile +1
-0@@ -18,6 +18,7 @@ ifeq ($(CONFIG_SYSFS),y) obj-$(CONFIG_MODULES) += module.o endif obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o +obj-$(CONFIG_SYS_SOC) += soc.o ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUGdrivers/base/soc.c new file +16
-0@@ -0,0 +1,79 @@ +/* +* Copyright (C) ST-Ericsson SA 2011 +* Author: Maxime Coquelin <[email protected]> for ST-Ericsson. +* License terms: GNU General Public License (GPL), version 2 +*/ + +#include <linux/sysfs.h> +#include <linux/module.h> +#include <linux/init.h> +#include <linux/stat.h> +#include <linux/slab.h> +#include <linux/sys_soc.h> + +struct kobject *soc_object; + +ssize_t show_soc_info(struct kobject *kobj,drivers/base/soc.c line 26
Quoted 10 lines
drivers/base/soc.c new file +10
-0+ struct kobj_attribute *attr, char *buf) +{ + struct sysfs_soc_info *si = container_of(attr, + struct sysfs_soc_info, attr); + +if (si->info) +return sprintf (buf,"%s\n" , si->info); + +return si->get_info (buf, si); +}I think this can be simplified by just letting the soc register its own show method instead of the
get_infofunction.Quoted 99 lines
drivers/base/soc.c new file +52
-0+int __init register_sysfs_soc_info (struct sysfs_soc_info *info,int nb_info) +{ +int i, ret; + +for (i =0 ; i < nb_info; i++) { + ret =sysfs_create_file (soc_object, &info[i].attr.attr); +if (ret) { +for (i -=1 ; i >=0 ; i--) +sysfs_remove_file (soc_object, &info[i].attr.attr); +break ; + } + } + +return ret; +} + +static struct attribute *soc_attrs[] = { +NULL , +}; + +static struct attribute_group soc_attr_group = { + .attrs = soc_attrs, +}; + +int __init register_sysfs_soc (struct sysfs_soc_info *info,size_t num) +{ +int ret; + + soc_object =kobject_create_and_add ("socinfo" ,NULL ); +if (!soc_object) { + ret = -ENOMEM ; + goto exit; + } + + ret =sysfs_create_group (soc_object, &soc_attr_group); +if (ret) + goto kset_exit; + + ret =register_sysfs_soc_info (info, num); +if (ret) + goto group_exit; + +return 0 ; + +group_exit: +sysfs_remove_group (soc_object, &soc_attr_group); +kset_exit: +kobject_put (soc_object); +exit: +return ret; +} +include/linux/sys_soc.h new file +40
-0@@ -0,0 +1,50 @@ +/* +* Copyright (C) ST-Ericsson SA 2011 +* Author: Maxime Coquelin <[email protected]> for ST-Ericsson. +* License terms: GNU General Public License (GPL), version 2 +*/ +#ifndef __SYS_SOC_H +#define __SYS_SOC_H + +#include <linux/kobject.h> + +/** +* struct sys_soc_info - SoC exports related informations +* @name: name of the export +* @info: pointer on the key to export +* @get_info: callback to retrieve key if info field is NULL +* @attr: export's sysdev class attribute +*/ +struct sysfs_soc_info { +const char *info; +ssize_t (*get_info)(char *buf,struct sysfs_soc_info *); +struct kobj_attribute attr; +}; + +ssize_t show_soc_info (struct kobject *,struct kobj_attribute *,char *); + +#define SYSFS_SOC_ATTR_VALUE (_name, _value) { \ + .attr.attr.name = _name, \ + .attr.attr.mode = S_IRUGO, \ + .attr.show = show_soc_info, \ + .info = _value, \ +} + +#define SYSFS_SOC_ATTR_CALLBACK (_name, _callback) { \ + .attr.attr.name = _name, \ + .attr.attr.mode = S_IRUGO, \ + .attr.show = show_soc_info, \ + .get_info = _callback, \ +} + +/** include/linux/sys_soc.h line 50
Quoted 10 lines
include/linux/sys_soc.h new file +10
-0+* register_sys_soc - register the soc information +* @name: name of the machine +* @info: pointer on the info table to export +* @num: number of info to export +* +* NOTE: This function must only be called once +*/ +int register_sysfs_soc (struct sysfs_soc_info *info,size_t num); + +#endif /* __SYS_SOC_H */ _______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 3 lines
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear.
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 9 lines · ext Ben Dooks
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · Maxime Coquelin
Common base to export System-on-Chip related informations through sysfs.
Creation of a "socinfo" directory under
/sys/.
Creation of SoC information entries.Signed-off-by Maxime COQUELIN <[email protected]>
Quoted 7 lines
Quoted 5 lines
I think it's better than the previous patch to create an artificial device in
/sys/devices/system/socinfo, but I'd still prefer the information to be attached to a real device that represents the SOC, as I explained in the discussion with Linus Walleij.Why not create it under the cpu directory?
I think it is mainly because people have strong opinion against merging/confusing soc data with cpu data.
Quoted 218 lines
Quoted 213 lines
You should definitely add Greg on Cc, as he's maintaining sysfs and certainly has an opininion here.
Arnd
Quoted 79 lines
--- Documentation/ABI/testing/sysfs-socinfo | 16 ++++++ drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++ include/linux/sys_soc.h | 50 +++++++++++++++++++ 5 files changed, 149 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-socinfo create mode 100644 drivers/base/soc.c create mode 100644 include/linux/sys_soc.hDocumentation/ABI/testing/sysfs-socinfo new file +16
-0@@ -0,0 +1,16 @@ +What: /sys/socinfo +Date: March 2011 +contact: Maxime Coquelin <[email protected]> +Description: + The /sys/socinfo directory contains information about the + System-on-Chip. It is only available if platform implements it. + This directory contains two kind of attributes : + - common attributes: + * machine: the name of the machine. + * family: the family name of the SoC + - SoC-specific attributes: The SoC vendor can declare attributes + to export some strings to user-space, like the serial-number for + example. + +Users: + User-space applications which needs these kind of attributes.drivers/base/Kconfig +3
-0@@ -168,4 +168,7 @@ config SYS_HYPERVISOR bool default n +config SYS_SOC + bool + endmenudrivers/base/Makefile +1
-0@@ -18,6 +18,7 @@ ifeq ($(CONFIG_SYSFS),y) obj-$(CONFIG_MODULES) += module.o endif obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o +obj-$(CONFIG_SYS_SOC) += soc.o ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUGdrivers/base/soc.c new file +16
-0@@ -0,0 +1,79 @@ +/* +* Copyright (C) ST-Ericsson SA 2011 +* Author: Maxime Coquelin <[email protected]> for ST-Ericsson. +* License terms: GNU General Public License (GPL), version 2 +*/ + +#include <linux/sysfs.h> +#include <linux/module.h> +#include <linux/init.h> +#include <linux/stat.h> +#include <linux/slab.h> +#include <linux/sys_soc.h> + +struct kobject *soc_object; + +ssize_t show_soc_info(struct kobject *kobj,drivers/base/soc.c line 26
Quoted 10 lines
drivers/base/soc.c new file +10
-0+ struct kobj_attribute *attr, char *buf) +{ + struct sysfs_soc_info *si = container_of(attr, + struct sysfs_soc_info, attr); + +if (si->info) +return sprintf (buf,"%s\n" , si->info); + +return si->get_info (buf, si); +}I think this can be simplified by just letting the soc register its own show method instead of the
get_infofunction.Quoted 99 lines
drivers/base/soc.c new file +52
-0+int __init register_sysfs_soc_info (struct sysfs_soc_info *info,int nb_info) +{ +int i, ret; + +for (i =0 ; i < nb_info; i++) { + ret =sysfs_create_file (soc_object, &info[i].attr.attr); +if (ret) { +for (i -=1 ; i >=0 ; i--) +sysfs_remove_file (soc_object, &info[i].attr.attr); +break ; + } + } + +return ret; +} + +static struct attribute *soc_attrs[] = { +NULL , +}; + +static struct attribute_group soc_attr_group = { + .attrs = soc_attrs, +}; + +int __init register_sysfs_soc (struct sysfs_soc_info *info,size_t num) +{ +int ret; + + soc_object =kobject_create_and_add ("socinfo" ,NULL ); +if (!soc_object) { + ret = -ENOMEM ; + goto exit; + } + + ret =sysfs_create_group (soc_object, &soc_attr_group); +if (ret) + goto kset_exit; + + ret =register_sysfs_soc_info (info, num); +if (ret) + goto group_exit; + +return 0 ; + +group_exit: +sysfs_remove_group (soc_object, &soc_attr_group); +kset_exit: +kobject_put (soc_object); +exit: +return ret; +} +include/linux/sys_soc.h new file +40
-0@@ -0,0 +1,50 @@ +/* +* Copyright (C) ST-Ericsson SA 2011 +* Author: Maxime Coquelin <[email protected]> for ST-Ericsson. +* License terms: GNU General Public License (GPL), version 2 +*/ +#ifndef __SYS_SOC_H +#define __SYS_SOC_H + +#include <linux/kobject.h> + +/** +* struct sys_soc_info - SoC exports related informations +* @name: name of the export +* @info: pointer on the key to export +* @get_info: callback to retrieve key if info field is NULL +* @attr: export's sysdev class attribute +*/ +struct sysfs_soc_info { +const char *info; +ssize_t (*get_info)(char *buf,struct sysfs_soc_info *); +struct kobj_attribute attr; +}; + +ssize_t show_soc_info (struct kobject *,struct kobj_attribute *,char *); + +#define SYSFS_SOC_ATTR_VALUE (_name, _value) { \ + .attr.attr.name = _name, \ + .attr.attr.mode = S_IRUGO, \ + .attr.show = show_soc_info, \ + .info = _value, \ +} + +#define SYSFS_SOC_ATTR_CALLBACK (_name, _callback) { \ + .attr.attr.name = _name, \ + .attr.attr.mode = S_IRUGO, \ + .attr.show = show_soc_info, \ + .get_info = _callback, \ +} + +/** include/linux/sys_soc.h line 50
Quoted 10 lines
include/linux/sys_soc.h new file +10
-0+* register_sys_soc - register the soc information +* @name: name of the machine +* @info: pointer on the info table to export +* @num: number of info to export +* +* NOTE: This function must only be called once +*/ +int register_sysfs_soc (struct sysfs_soc_info *info,size_t num); + +#endif /* __SYS_SOC_H */ _______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernelSignature · 3 lines
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear.
Signature · 1 line
Eduardo Valentin
RFC PATCH v2 1/2 Export SoC info through sysfs
In reply to Arnd BergmannQuoted 44 lines · Arnd Bergmann
Quoted 6 lines · Maxime Coquelin
Common base to export System-on-Chip related informations through sysfs.
Creation of a "socinfo" directory under
/sys/.
Creation of SoC information entries.Signed-off-by Maxime COQUELIN <[email protected]>I think it's better than the previous patch to create an artificial device in
/sys/devices/system/socinfo, but I'd still prefer the information to be attached to a real device that represents the SOC, as I explained in the discussion with Linus Walleij.You should definitely add Greg on Cc, as he's maintaining sysfs and certainly has an opininion here.
Arnd
Quoted 25 lines
--- Documentation/ABI/testing/sysfs-socinfo | 16 ++++++ drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++ include/linux/sys_soc.h | 50 +++++++++++++++++++ 5 files changed, 149 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-socinfo create mode 100644 drivers/base/soc.c create mode 100644 include/linux/sys_soc.hDocumentation/ABI/testing/sysfs-socinfo new file +8
-0@@ -0,0 +1,16 @@ +What: /sys/socinfo +Date: March 2011 +contact: Maxime Coquelin <[email protected]> +Description: + The /sys/socinfo directory contains information about the + System-on-Chip. It is only available if platform implements it. + This directory contains two kind of attributes : + - common attributes:
Quoted 8 lines
Documentation/ABI/testing/sysfs-socinfo line 16
Quoted 8 lines
Documentation/ABI/testing/sysfs-socinfo new file +8
-0+ * machine: the name of the machine. + * family: the family name of the SoC + - SoC-specific attributes: The SoC vendor can declare attributes + to export some strings to user-space, like the serial-number for + example. + +Users: + User-space applications which needs these kind of attributes.
I thought I rejected this the last time it came around?
I still fail to understand why this is needed, please provide more information about why you feel this is something that the kernel needs.
thanks,
greg k-h
RFC PATCH v2 1/2 Export SoC info through sysfs
Hello,
Quoted 47 lines · ext Greg KH
Quoted 46 lines · Arnd Bergmann
Quoted 6 lines · Maxime Coquelin
Common base to export System-on-Chip related informations through sysfs.
Creation of a "socinfo" directory under
/sys/.
Creation of SoC information entries.Signed-off-by Maxime COQUELIN <[email protected]>I think it's better than the previous patch to create an artificial device in
/sys/devices/system/socinfo, but I'd still prefer the information to be attached to a real device that represents the SOC, as I explained in the discussion with Linus Walleij.You should definitely add Greg on Cc, as he's maintaining sysfs and certainly has an opininion here.
Arnd
Quoted 27 lines
--- Documentation/ABI/testing/sysfs-socinfo | 16 ++++++ drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++ include/linux/sys_soc.h | 50 +++++++++++++++++++ 5 files changed, 149 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-socinfo create mode 100644 drivers/base/soc.c create mode 100644 include/linux/sys_soc.hDocumentation/ABI/testing/sysfs-socinfo new file +10
-0@@ -0,0 +1,16 @@ +What: /sys/socinfo +Date: March 2011 +contact: Maxime Coquelin <[email protected]> +Description: + The /sys/socinfo directory contains information about the + System-on-Chip. It is only available if platform implements it. + This directory contains two kind of attributes : + - common attributes: + * machine: the name of the machine. + * family: the family name of the SoC
Quoted 9 lines
Quoted 6 lines
Documentation/ABI/testing/sysfs-socinfo line 16
Quoted 6 lines
Documentation/ABI/testing/sysfs-socinfo new file +6
-0+ - SoC-specific attributes: The SoC vendor can declare attributes + to export some strings to user-space, like the serial-number for + example. + +Users: + User-space applications which needs these kind of attributes.I thought I rejected this the last time it came around?
Greg,
Do you mind sharing the link of the thread where you have reject this?
Quoted 2 lines
I still fail to understand why this is needed, please provide more information about why you feel this is something that the kernel needs.
In case of OMAP, there are few ids that we would expose to user space, like serial, revision and die id to quote some from top of my mind. I must emphasize that these are not data from CPU at all, they belong to SoC itself.
This info can be useful to track buggy silicon misbehaving on products which are already on the market. For instance, one possible usage would be to collect from products which arrives on customer care centers.
That's obviously the view I have from OMAP perspective.
But looks like if we had some common way to expose this data, not only OMAP socs would benefit of it, as you can see interest from other soc vendors in this thread (also on V1 of this patch set or on my original patch set over /proc)
Quoted 4 lines
thanks,
greg k-h
Signature · 1 line
Eduardo Valentin
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 60 lines · Eduardo Valentin
Hello,
Quoted 47 lines · ext Greg KH
Quoted 46 lines · Arnd Bergmann
Quoted 6 lines · Maxime Coquelin
Common base to export System-on-Chip related informations through sysfs.
Creation of a "socinfo" directory under
/sys/.
Creation of SoC information entries.Signed-off-by Maxime COQUELIN <[email protected]>I think it's better than the previous patch to create an artificial device in
/sys/devices/system/socinfo, but I'd still prefer the information to be attached to a real device that represents the SOC, as I explained in the discussion with Linus Walleij.You should definitely add Greg on Cc, as he's maintaining sysfs and certainly has an opininion here.
Arnd
Quoted 27 lines
--- Documentation/ABI/testing/sysfs-socinfo | 16 ++++++ drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/soc.c | 79 +++++++++++++++++++++++++++++++ include/linux/sys_soc.h | 50 +++++++++++++++++++ 5 files changed, 149 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-socinfo create mode 100644 drivers/base/soc.c create mode 100644 include/linux/sys_soc.hDocumentation/ABI/testing/sysfs-socinfo new file +10
-0@@ -0,0 +1,16 @@ +What: /sys/socinfo +Date: March 2011 +contact: Maxime Coquelin <[email protected]> +Description: + The /sys/socinfo directory contains information about the + System-on-Chip. It is only available if platform implements it. + This directory contains two kind of attributes : + - common attributes: + * machine: the name of the machine. + * family: the family name of the SoCQuoted 9 lines
Quoted 6 lines
Documentation/ABI/testing/sysfs-socinfo line 16
Quoted 6 lines
Documentation/ABI/testing/sysfs-socinfo new file +6
-0+ - SoC-specific attributes: The SoC vendor can declare attributes + to export some strings to user-space, like the serial-number for + example. + +Users: + User-space applications which needs these kind of attributes.I thought I rejected this the last time it came around?
Quoted 3 lines
Greg,
Do you mind sharing the link of the thread where you have reject this?
I don't remember it, you can search as well as I can :)
Quoted 7 lines
Quoted 2 lines
I still fail to understand why this is needed, please provide more information about why you feel this is something that the kernel needs.
In case of OMAP, there are few ids that we would expose to user space, like serial, revision and die id to quote some from top of my mind. I must emphasize that these are not data from CPU at all, they belong to SoC itself.
I understand, but note that there could be multiple SoC devices, right? How will this code support that?
Make this a "real" device not /sys/socinfo please. It can be a platform device that export the needed information, that way you can have multiple ones.
thanks,
greg k-h
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 3 lines · On Friday 11 March 2011 20:33:30 Greg KH wrote:
Make this a "real" device not
/sys/socinfoplease. It can be a platform device that export the needed information, that way you can have multiple ones.
Note that the version 1 of this patch had a device, and I argued against that patch on the basis that anything under /sys/devices/ should reflect an actual part of the hardware, which socinfo by itself does not.
I believe the best way to represent this really is to have a device (platform or other, I don't care) that:
* represents the SOC in its entirety
* has the subdevices that are part of the SOC as direct or indirect children
* can be identified easily as a SOC (through one of its name, its place in the hierarchy or its bus_type)
* has the standard device attributes proposed in Maxime's patch.
Arnd
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 9 lines · Arnd Bergmann
Quoted 3 lines · On Friday 11 March 2011 20:33:30 Greg KH wrote:
Make this a "real" device not
/sys/socinfoplease. It can be a platform device that export the needed information, that way you can have multiple ones.Note that the version 1 of this patch had a device, and I argued against that patch on the basis that anything under
/sys/devices/should reflect an actual part of the hardware, which socinfo by itself does not.
Why is the overall SoC not a device? cpus are (well, they will be in a few kernel versions in the future), so what makes the other bits somehow "special"?
Quoted 10 lines
I believe the best way to represent this really is to have a device (platform or other, I don't care) that:
* represents the SOC in its entirety
* has the subdevices that are part of the SOC as direct or indirect children
* can be identified easily as a SOC (through one of its name, its place in the hierarchy or itsbus_type)
* has the standard device attributes proposed in Maxime's patch.
That's fine, as it would be a real "struct device" :)
thanks,
greg k-h
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 6 lines · On Friday 11 March 2011 23:03:33 Greg KH wrote:
Quoted 5 lines · Arnd Bergmann
Quoted 3 lines · On Friday 11 March 2011 20:33:30 Greg KH wrote:
Make this a "real" device not
/sys/socinfoplease. It can be a platform device that export the needed information, that way you can have multiple ones.
Quoted 8 lines
Quoted 4 lines
Note that the version 1 of this patch had a device, and I argued against that patch on the basis that anything under
/sys/devices/should reflect an actual part of the hardware, which socinfo by itself does not.Why is the overall SoC not a device? cpus are (well, they will be in a few kernel versions in the future), so what makes the other bits somehow "special"?
The suggestion was to have a single disconnected device stuck in /sys/devices/system/socinfo, and only have it there to contain device attributes that can be collected from random places in the system, such hardcoded board specific data, or read from registers that belong to another device.
A real device IMHO would be one that has specific hardware properties, such as its own set of device registers or other devices that are attached to it and that are represented as children of this device.
Arnd
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 22 lines · Arnd Bergmann
Quoted 6 lines · On Friday 11 March 2011 23:03:33 Greg KH wrote:
Quoted 5 lines · Arnd Bergmann
Quoted 3 lines · On Friday 11 March 2011 20:33:30 Greg KH wrote:
Make this a "real" device not
/sys/socinfoplease. It can be a platform device that export the needed information, that way you can have multiple ones.Quoted 8 lines
Quoted 4 lines
Note that the version 1 of this patch had a device, and I argued against that patch on the basis that anything under
/sys/devices/should reflect an actual part of the hardware, which socinfo by itself does not.Why is the overall SoC not a device? cpus are (well, they will be in a few kernel versions in the future), so what makes the other bits somehow "special"?
The suggestion was to have a single disconnected device stuck in
/sys/devices/system/socinfo, and only have it there to contain device attributes that can be collected from random places in the system, such hardcoded board specific data, or read from registers that belong to another device.
Quoted 4 lines
A real device IMHO would be one that has specific hardware properties, such as its own set of device registers or other devices that are attached to it and that are represented as children of this device.
Unfortunately, Maxime is extremely busy at the moment, so I have taken over to finally get this thing upstream. Just for clarification what's the _final_ verdict on the location of this entry? Something that we can all agree on.
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 28 lines · Lee Jones
Quoted 22 lines · Arnd Bergmann
Quoted 6 lines · On Friday 11 March 2011 23:03:33 Greg KH wrote:
Quoted 5 lines · Arnd Bergmann
Quoted 3 lines · On Friday 11 March 2011 20:33:30 Greg KH wrote:
Make this a "real" device not
/sys/socinfoplease. It can be a platform device that export the needed information, that way you can have multiple ones.Quoted 8 lines
Quoted 4 lines
Note that the version 1 of this patch had a device, and I argued against that patch on the basis that anything under
/sys/devices/should reflect an actual part of the hardware, which socinfo by itself does not.Why is the overall SoC not a device? cpus are (well, they will be in a few kernel versions in the future), so what makes the other bits somehow "special"?
The suggestion was to have a single disconnected device stuck in
/sys/devices/system/socinfo, and only have it there to contain device attributes that can be collected from random places in the system, such hardcoded board specific data, or read from registers that belong to another device.Quoted 4 lines
A real device IMHO would be one that has specific hardware properties, such as its own set of device registers or other devices that are attached to it and that are represented as children of this device.
Quoted 4 lines
Unfortunately, Maxime is extremely busy at the moment, so I have taken over to finally get this thing upstream. Just for clarification what's the final verdict on the location of this entry? Something that we can all agree on.
I'll try to capture the opinions from the other people as well, hopefully this represents a consensus. Please correct me otherwise.
I believe the uncontroversial parts are:
* Make it not an entry but a device with certain properties.
* Make the naming so that you can have more than one of them.
* Put all devices on an SoC that uses this scheme underneath that device by setting their parents to the SoC device.
For the location of the device, I have not seen a clear consensus yet, but I'm fine with eihter of these:
/sys/devices/soc/${NAME}//sys/devices/platform/soc${NUMBER}/
For the implementation, I'd suggest adding an soc_device_register() function that gets passed the necessary data and returns the struct device that can then be used as the parent in all platform_device_register calls.
Arnd
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 44 lines · Arnd Bergmann
Quoted 28 lines · Lee Jones
Quoted 22 lines · Arnd Bergmann
Quoted 6 lines · On Friday 11 March 2011 23:03:33 Greg KH wrote:
Quoted 5 lines · Arnd Bergmann
Quoted 3 lines · On Friday 11 March 2011 20:33:30 Greg KH wrote:
Make this a "real" device not
/sys/socinfoplease. It can be a platform device that export the needed information, that way you can have multiple ones.Quoted 8 lines
Quoted 4 lines
Note that the version 1 of this patch had a device, and I argued against that patch on the basis that anything under
/sys/devices/should reflect an actual part of the hardware, which socinfo by itself does not.Why is the overall SoC not a device? cpus are (well, they will be in a few kernel versions in the future), so what makes the other bits somehow "special"?
The suggestion was to have a single disconnected device stuck in
/sys/devices/system/socinfo, and only have it there to contain device attributes that can be collected from random places in the system, such hardcoded board specific data, or read from registers that belong to another device.Quoted 4 lines
A real device IMHO would be one that has specific hardware properties, such as its own set of device registers or other devices that are attached to it and that are represented as children of this device.
Quoted 4 lines
Unfortunately, Maxime is extremely busy at the moment, so I have taken over to finally get this thing upstream. Just for clarification what's the final verdict on the location of this entry? Something that we can all agree on.
I'll try to capture the opinions from the other people as well, hopefully this represents a consensus. Please correct me otherwise.
I believe the uncontroversial parts are:
* Make it not an entry but a device with certain properties.
* Make the naming so that you can have more than one of them.
* Put all devices on an SoC that uses this scheme underneath that device by setting their parents to the SoC device.
Quoted 5 lines
For the location of the device, I have not seen a clear consensus yet, but I'm fine with eihter of these:
/sys/devices/soc/${NAME}//sys/devices/platform/soc${NUMBER}/
I prefer the second format here since the path is always the same which makes it easier to write parsing tools. The name should be an entry in the directory rather than the name of the directory itself.
Probably SoC number should match CPU number for SMP machines right? Possibly the SoC directory should even contain a symlink to the relevant CPU sysfs directory? If CPU's are set to become devices under sysfs then the SoC should also probably be the parent of the CPU?
Quoted 3 lines
For the implementation, I'd suggest adding an
soc_device_register()function that gets passed the necessary data and returns the struct device that can then be used as the parent in allplatform_device_registercalls.
Agreed.
~Ryan
Signature · 7 lines
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
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 14 lines · Ryan Mallon
Quoted 13 lines · Arnd Bergmann
I'll try to capture the opinions from the other people as well, hopefully this represents a consensus. Please correct me otherwise.
I believe the uncontroversial parts are:
* Make it not an entry but a device with certain properties.
* Make the naming so that you can have more than one of them.
* Put all devices on an SoC that uses this scheme underneath that device by setting their parents to the SoC device.For the location of the device, I have not seen a clear consensus yet, but I'm fine with eihter of these:
Quoted 8 lines
Quoted 2 lines
/sys/devices/soc/${NAME}//sys/devices/platform/soc${NUMBER}/I prefer the second format here since the path is always the same which makes it easier to write parsing tools. The name should be an entry in the directory rather than the name of the directory itself.
Probably SoC number should match CPU number for SMP machines right?
Not really. SOC means System On Chip. you usually have only one SOC on a board, and within that SOC you may have one or more CPUs. SMP machines are still likely to have only one SOC.
Nicolas
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 23 lines · Nicolas Pitre
Quoted 21 lines · Ryan Mallon
Quoted 10 lines · Arnd Bergmann
I'll try to capture the opinions from the other people as well, hopefully this represents a consensus. Please correct me otherwise.
I believe the uncontroversial parts are:
* Make it not an entry but a device with certain properties.
* Make the naming so that you can have more than one of them.
* Put all devices on an SoC that uses this scheme underneath that device by setting their parents to the SoC device.Quoted 5 lines
For the location of the device, I have not seen a clear consensus yet, but I'm fine with eihter of these:
/sys/devices/soc/${NAME}//sys/devices/platform/soc${NUMBER}/I prefer the second format here since the path is always the same which makes it easier to write parsing tools. The name should be an entry in the directory rather than the name of the directory itself.
Quoted 5 lines
Quoted 1 line
Probably SoC number should match CPU number for SMP machines right?
Not really. SOC means System On Chip. you usually have only one SOC on a board, and within that SOC you may have one or more CPUs. SMP machines are still likely to have only one SOC.
Ok. What is the situation where we have more than one SoC?
~Ryan
Signature · 7 lines
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
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 24 lines · Ryan Mallon
Quoted 23 lines · Nicolas Pitre
Quoted 21 lines · Ryan Mallon
Quoted 10 lines · Arnd Bergmann
I'll try to capture the opinions from the other people as well, hopefully this represents a consensus. Please correct me otherwise.
I believe the uncontroversial parts are:
* Make it not an entry but a device with certain properties.
* Make the naming so that you can have more than one of them.
* Put all devices on an SoC that uses this scheme underneath that device by setting their parents to the SoC device.Quoted 5 lines
For the location of the device, I have not seen a clear consensus yet, but I'm fine with eihter of these:
/sys/devices/soc/${NAME}//sys/devices/platform/soc${NUMBER}/I prefer the second format here since the path is always the same which makes it easier to write parsing tools. The name should be an entry in the directory rather than the name of the directory itself.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Probably SoC number should match CPU number for SMP machines right?
Not really. SOC means System On Chip. you usually have only one SOC on a board, and within that SOC you may have one or more CPUs. SMP machines are still likely to have only one SOC.
Ok. What is the situation where we have more than one SoC?
That would mean two separate instances of Linux, just like two systems. SMP across multiple SOCs doesn't make much sense, and I don't think they are likely to be designed for that ability either.
Nicolas
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 32 lines · Nicolas Pitre
Quoted 30 lines · Ryan Mallon
Quoted 28 lines · Nicolas Pitre
Quoted 14 lines · Ryan Mallon
Quoted 13 lines · Arnd Bergmann
I'll try to capture the opinions from the other people as well, hopefully this represents a consensus. Please correct me otherwise.
I believe the uncontroversial parts are:
* Make it not an entry but a device with certain properties.
* Make the naming so that you can have more than one of them.
* Put all devices on an SoC that uses this scheme underneath that device by setting their parents to the SoC device.For the location of the device, I have not seen a clear consensus yet, but I'm fine with eihter of these:
Quoted 8 lines
Quoted 2 lines
/sys/devices/soc/${NAME}//sys/devices/platform/soc${NUMBER}/I prefer the second format here since the path is always the same which makes it easier to write parsing tools. The name should be an entry in the directory rather than the name of the directory itself.
Probably SoC number should match CPU number for SMP machines right?
Not really. SOC means System On Chip. you usually have only one SOC on a board, and within that SOC you may have one or more CPUs. SMP machines are still likely to have only one SOC.
Quoted 5 lines
Quoted 1 line
Ok. What is the situation where we have more than one SoC?
That would mean two separate instances of Linux, just like two systems. SMP across multiple SOCs doesn't make much sense, and I don't think they are likely to be designed for that ability either.
So we probably don't need the ability to have multiple SoC directories under sysfs then?
For the other part of the question, do you think it makes sense for the CPU's to be child devices of the SoC (and for the CPU devices to be potentially symlinked from the SoC directory)?
~Ryan
Signature · 7 lines
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
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 6 lines · Ryan Mallon
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
/sys/devices/soc/${NAME}//sys/devices/platform/soc${NUMBER}/I prefer the second format here since the path is always the same which makes it easier to write parsing tools. The name should be an entry in the directory rather than the name of the directory itself.
In the first case, we would ensure that every directory under /sys/devices/soc is an SOC device, so you would not need to parse the name at all, which is even simpler. I'm open to other arguments either way, but I think this one is not particularly important.
Quoted 6 lines
Quoted 3 lines
That would mean two separate instances of Linux, just like two systems. SMP across multiple SOCs doesn't make much sense, and I don't think they are likely to be designed for that ability either.
So we probably don't need the ability to have multiple SoC directories under sysfs then?
There are systems that have multiple ones, they are just not as common.
Quoted 3 lines
For the other part of the question, do you think it makes sense for the CPU's to be child devices of the SoC (and for the CPU devices to be potentially symlinked from the SoC directory)?
No, the CPUs are children of /sys/devices/system, and we should not change that. Symlinks sound like a good idea though.
Arnd
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 4 lines · Arnd Bergmann
Quoted 3 lines · Ryan Mallon
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
/sys/devices/soc/${NAME}//sys/devices/platform/soc${NUMBER}/
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
I prefer the second format here since the path is always the same which makes it easier to write parsing tools. The name should be an entry in the directory rather than the name of the directory itself.
In the first case, we would ensure that every directory under
/sys/devices/socis an SOC device, so you would not need to parse the name at all, which is even simpler. I'm open to other arguments either way, but I think this one is not particularly important.
I think your proposal is best.
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
That would mean two separate instances of Linux, just like two systems. SMP across multiple SOCs doesn't make much sense, and I don't think they are likely to be designed for that ability either.
So we probably don't need the ability to have multiple SoC directories under sysfs then?
Quoted 8 lines
There are systems that have multiple ones, they are just not as common.
Quoted 3 lines
For the other part of the question, do you think it makes sense for the CPU's to be child devices of the SoC (and for the CPU devices to be potentially symlinked from the SoC directory)?
No, the CPUs are children of
/sys/devices/system, and we should not change that. Symlinks sound like a good idea though.
Symlinks are a requirement as multiple cpus can be attached to a single SoC.
What about multiple cpus that are attached to multiple SoCs? Why even try to describe this relationship, what would userspace get out of this information?
thanks,
greg k-h
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 6 lines · Greg KH
Symlinks are a requirement as multiple cpus can be attached to a single SoC.
What about multiple cpus that are attached to multiple SoCs? Why even try to describe this relationship, what would userspace get out of this information?
The only one I can think of is node affinity. I've worked with a system (IBM QS2x Cell blade) that had two SoCs with multiple CPUs each. There was a significant performance penalty when talking to devices on the remote SoC. In that case, we used the NUMA node information in /sys/ to deal with it, but we might not want to use the NUMA infrastructure on systems that only have RAM on one node.
Arnd
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · Greg KH
Symlinks are a requirement as multiple cpus can be attached to a single SoC.
What about multiple cpus that are attached to multiple SoCs? Why even try to describe this relationship, what would userspace get out of this information?
Quoted 6 lines
The only one I can think of is node affinity. I've worked with a system (IBM QS2x Cell blade) that had two SoCs with multiple CPUs each. There was a significant performance penalty when talking to devices on the remote SoC. In that case, we used the NUMA node information in
/sys/to deal with it, but we might not want to use the NUMA infrastructure on systems that only have RAM on one node.
I'm struggling to see a scenario where we'd have multiple SoCs on a single device and only one filesystem. ux500 sub-arch code is yet to facilitate SoC counting functionality. If were are to implement per-SoC directories would this need to be added?
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 16 lines · Lee Jones
Quoted 8 lines · Arnd Bergmann
Quoted 6 lines · Greg KH
Symlinks are a requirement as multiple cpus can be attached to a single SoC.
What about multiple cpus that are attached to multiple SoCs? Why even try to describe this relationship, what would userspace get out of this information?
Quoted 6 lines
The only one I can think of is node affinity. I've worked with a system (IBM QS2x Cell blade) that had two SoCs with multiple CPUs each. There was a significant performance penalty when talking to devices on the remote SoC. In that case, we used the NUMA node information in sys to deal with it, but we might not want to use the NUMA infrastructure on systems that only have RAM on one node.
Quoted 4 lines
I'm struggling to see a scenario where we'd have multiple SoCs on a single device and only one filesystem. ux500 sub-arch code is yet to facilitate SoC counting functionality. If were are to implement per-SoC directories would this need to be added?
How can you say we won't need it when I've just given you a specific example of a widely shipping machine?
It's not important that the kernel internal code supports multiple SoCs as long as there is no in-tree user for this. It can always be added at a later point.
What is important is that the user interface accomodates for it. If you name the device simply /sys/devices/soc/, any user program looking at that will have to be modified when we have more than one. We cannot allow that to happen.
Arnd
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 17 lines · Arnd Bergmann
Quoted 16 lines · Lee Jones
Quoted 14 lines · Arnd Bergmann
Quoted 6 lines · Greg KH
Symlinks are a requirement as multiple cpus can be attached to a single SoC.
What about multiple cpus that are attached to multiple SoCs? Why even try to describe this relationship, what would userspace get out of this information?
The only one I can think of is node affinity. I've worked with a system (IBM QS2x Cell blade) that had two SoCs with multiple CPUs each. There was a significant performance penalty when talking to devices on the remote SoC. In that case, we used the NUMA node information in sys to deal with it, but we might not want to use the NUMA infrastructure on systems that only have RAM on one node.
Quoted 7 lines
Quoted 4 lines
I'm struggling to see a scenario where we'd have multiple SoCs on a single device and only one filesystem. ux500 sub-arch code is yet to facilitate SoC counting functionality. If were are to implement per-SoC directories would this need to be added?
How can you say we won't need it when I've just given you a specific example of a widely shipping machine?
I didn't say we won't need it. I'm just finding it difficult to picture how it would work. I'm more than happy to implement it, but there are more things to take into consideration, such as naming conventions for multiple SoCs. Even if they start at '1' and increase sequentially, there are still questions that need to be answered, such as; How will the SoCs be ordered? First come first served? Priority order? Or we could name them by soc_id?
Quoted 8 lines
It's not important that the kernel internal code supports multiple SoCs as long as there is no in-tree user for this. It can always be added at a later point.
What is important is that the user interface accomodates for it. If you name the device simply
/sys/devices/soc/, any user program looking at that will have to be modified when we have more than one. We cannot allow that to happen.
No problem. I can insure it's complete on first submission.
RFC PATCH v2 1/2 Export SoC info through sysfs
Quoted 7 lines · Lee Jones
I didn't say we won't need it. I'm just finding it difficult to picture how it would work. I'm more than happy to implement it, but there are more things to take into consideration, such as naming conventions for multiple SoCs. Even if they start at '1' and increase sequentially, there are still questions that need to be answered, such as; How will the SoCs be ordered? First come first served? Priority order? Or we could name them by
soc_id?
Any of these would be fine IMHO. In most cases, the order is fixed, either through a board file or through the order in the device tree, so I would just use a sequential number.
Arnd
RFC PATCH v2 2/2 ux500: Export U8500 SoC info through sysfs
In reply to Maxime CoquelinST-Ericsson's U8500 implementation.
Register sysfs SoC interface, and exports:
- Machine name
- Family name
- SoC ID
- Silicon process
- Silicon revision number.
socinfo : ux500 part 2
--- arch/arm/mach-ux500/Kconfig | 1 + arch/arm/mach-ux500/id.c | 70 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+), 0 deletions(-)
arch/arm/mach-ux500/Kconfig +1 -0
@@ -23,6 +23,7 @@ config MACH_U8500 bool "U8500 Development platform" depends on UX500_SOC_DB8500 select TPS6105X + select SYS_SOC help Include support for the mop500 development platform.
arch/arm/mach-ux500/id.c +70 -0
79 lines not on this page · raw message
Signature · 1 line
1.7.1
RFC PATCH v2 2/2 ux500: Export U8500 SoC info through sysfs
Quoted 7 lines · Maxime Coquelin
ST-Ericsson's U8500 implementation.
Register sysfs SoC interface, and exports:
- Machine name
- Family name
- SoC ID
- Silicon process
- Silicon revision number.
I propose some weeks ago exactly the same kind of patch
and Greg point that we need to create a bus
Best Regards,
J.
RFC PATCH v2 2/2 ux500: Export U8500 SoC info through sysfs
Quoted 9 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 7 lines · Maxime Coquelin
ST-Ericsson's U8500 implementation.
Register sysfs SoC interface, and exports:
? ? ? - Machine name
? ? ? - Family name
? ? ? - SoC ID
? ? ? - Silicon process
? ? ? - Silicon revision number.I propose some weeks ago exactly the same kind of patch
Could you tell which Subject: and mailing list so I can find it? If it was private can you forward it to the list?
Yours,
Linus Walleij
RFC PATCH v2 2/2 ux500: Export U8500 SoC info through sysfs
Quoted 10 lines · Linus Walleij
Quoted 8 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 7 lines · Maxime Coquelin
ST-Ericsson's U8500 implementation.
Register sysfs SoC interface, and exports:
? ? ? - Machine name
? ? ? - Family name
? ? ? - SoC ID
? ? ? - Silicon process
? ? ? - Silicon revision number.
Quoted 4 lines
Quoted 1 line
I propose some weeks ago exactly the same kind of patch
Could you tell which Subject: and mailing list so I can find it? If it was private can you forward it to the list?
892 F Dec14 To linux-kernel [PATCH] base: add sysfs socs info
Best Regards,
J.