From: jamie@jamieiles.com (Jamie Iles)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] Framework for exporting System-on-Chip information via sysfs
Date: Wed, 10 Aug 2011 14:29:56 +0100 [thread overview]
Message-ID: <20110810132956.GG2680@pulham.picochip.com> (raw)
In-Reply-To: <1312981422-13294-1-git-send-email-lee.jones@linaro.org>
Hi Lee,
A few minor comments inline.
Jamie
On Wed, Aug 10, 2011 at 02:03:39PM +0100, Lee Jones wrote:
> This patch introduces a new driver to drivers/base. The
> driver provides a means to export vital SoC data out to
> userspace via sysfs. Standard information applicable to all
> SoCs are exported to:
>
> /sys/devices/soc/[1|2|3|...]/[family|machine|revision|soc_id].
>
> It is possible to create SoC specific items via the
> soc_parent, which is returned post-registration, although
> this should be discouraged.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/base/Kconfig | 3 +
> drivers/base/Makefile | 1 +
> drivers/base/soc.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/sys_soc.h | 41 ++++++++++++++++++
> 4 files changed, 149 insertions(+), 0 deletions(-)
> create mode 100644 drivers/base/soc.c
> create mode 100644 include/linux/sys_soc.h
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index d57e8d0..372ef3a 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -168,4 +168,7 @@ config SYS_HYPERVISOR
> bool
> default n
>
> +config SYS_SOC
> + bool
> +
> endmenu
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index 4c5701c..a0d246d 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -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
>
> diff --git a/drivers/base/soc.c b/drivers/base/soc.c
> new file mode 100644
> index 0000000..05944ef
> --- /dev/null
> +++ b/drivers/base/soc.c
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (C) ST-Ericsson SA 2011
> + *
> + * Author: Lee Jones <lee.jones@linaro.org> 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>
> +
> +static DEFINE_SPINLOCK(register_lock);
> +static int soc_count = 0;
> +
> +static struct device soc_grandparent = {
> + .init_name = "soc",
> +};
> +
> +static ssize_t soc_info_get(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct soc_device *soc_dev = dev->platform_data;
> +
> + if (!strncmp(attr->attr.name, "machine", 7))
> + return sprintf(buf, "%s\n", soc_dev->machine);
> + if (!strncmp(attr->attr.name, "family", 6))
> + return sprintf(buf, "%s\n", soc_dev->family);
> + if (!strncmp(attr->attr.name, "soc_id", 6))
> + return sprintf(buf, "%s\n", soc_dev->soc_id);
> + if (!strncmp(attr->attr.name, "revision", 8))
> + return sprintf(buf, "%s\n", soc_dev->revision);
I think strcmp() would be better here rather than strncmp() otherwise
there could be problems if someone adds an attribute that has a previous
one as a starting sub-string.
> +
> + return sprintf(buf, "Unknown attribute name - %s\n", attr->attr.name);
Just return -EINVAL or similar here to propogate the error to the user.
> +}
> +
> +struct device_attribute soc_attrs[] = {
> + __ATTR(machine, S_IRUGO, soc_info_get, NULL),
> + __ATTR(family, S_IRUGO, soc_info_get, NULL),
> + __ATTR(soc_id, S_IRUGO, soc_info_get, NULL),
> + __ATTR(revision, S_IRUGO, soc_info_get, NULL),
> + __ATTR_NULL,
> +};
> +
> +static void __exit soc_device_remove_files(struct device *soc)
> +{
> + int i = 0;
> +
> + while (soc_attrs[i++].attr.name != NULL)
> + device_remove_file(soc, &soc_attrs[i]);
> +}
> +
> +static int __init soc_device_create_files(struct device *soc)
> +{
> + int ret = 0;
> + int i = 0;
> +
> + while (soc_attrs[i].attr.name != NULL) {
> + ret = device_create_file(soc, &soc_attrs[i++]);
> + if (ret)
> + goto out;
> + }
> + return ret;
> +
> +out:
> + soc_device_remove_files(soc);
This should count back from i and unregister the attributes as
soc_device_remove_files may try and remove files that didn't get
registered.
> + return ret;
> +}
> +
> +int __init soc_device_register(struct device *soc_parent,
> + struct soc_device *soc_dev)
> +{
> + int ret;
> +
> + spin_lock_irq(®ister_lock);
> +
> + if (!soc_count) {
> + /* Register top-level SoC device '/sys/devices/soc' */
> + ret = device_register(&soc_grandparent);
> + if (ret)
> + {
> + spin_unlock_irq(®ister_lock);
> + return ret;
> + }
> + }
> +
> + soc_count++;
> + soc_parent->parent = &soc_grandparent;
> + dev_set_name(soc_parent, "%i", soc_count);
> + soc_parent->platform_data = soc_dev;
I don't think platform_data is the right place for this. It's not clear
what soc_parent and soc_dev do here as soc_dev never gets registered.
Should this be:
soc_dev->parent = &soc_grandparent;
dev_set_name(soc_dev, "%i", soc_count);
device_register(soc_dev);
and drop soc_parent and add the files to soc_device? In soc_info_get(),
you could then do:
struct soc_device *soc = container_of(dev, struct soc_device, dev);
> + spin_unlock_irq(®ister_lock);
> +
> + ret = device_register(soc_parent);
> + if (ret)
> + return ret;
> +
> + soc_device_create_files(soc_parent);
> +
> + return ret;
> +}
> diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
> new file mode 100644
> index 0000000..3de6405
> --- /dev/null
> +++ b/include/linux/sys_soc.h
> @@ -0,0 +1,41 @@
> +/*
> + * Copyright (C) ST-Ericsson SA 2011
> + * Author: Lee Jones <lee.jones@linaro.org> for ST-Ericsson.
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +#ifndef __SYS_SOC_H
> +#define __SYS_SOC_H
> +
> +#include <linux/kobject.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +
> +#define MAX_SOCS 8
> +#define MACHINE 0
> +#define FAMILY 1
> +#define SOCID 2
> +#define REVISION 3
These defines don't appear to be used anywhere afaict.
> +
> +struct soc_device {
> + struct device dev;
> + const char *machine;
> + const char *family;
> + const char *soc_id;
> + const char *revision;
> +};
> +
> +/**
> + * soc_device_register - register SoC as a device
> + * @soc_parent: Parent node '/sys/devices/soc/X'
> + * @soc_dev: SoC device specific information
> + */
> +int soc_device_register(struct device *soc_parent,
> + struct soc_device *soc_dev);
> +
> +/**
> + * soc_device_unregister - unregister SoC as a device
> + * @soc_parent: Parent node '/sys/devices/soc/X'
> + */
> +void soc_device_unregister(struct device *soc_parent);
This doesn't appear to exist, and probably doesn't need to.
next prev parent reply other threads:[~2011-08-10 13:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-10 13:03 [PATCH 1/4] Framework for exporting System-on-Chip information via sysfs Lee Jones
2011-08-10 13:03 ` [PATCH 2/4] Add documenation for new sysfs devices/soc functionallity Lee Jones
2011-08-10 15:02 ` Greg KH
2011-08-10 13:03 ` [PATCH 3/4] mach-ux500: export System-on-Chip information ux500 via sysfs Lee Jones
2011-08-10 13:34 ` Jamie Iles
2011-08-10 15:03 ` Greg KH
2011-09-01 6:58 ` Lee Jones
2011-09-01 14:24 ` Greg KH
2011-08-24 16:10 ` Arnd Bergmann
2011-08-25 9:20 ` Lee Jones
2011-08-25 14:56 ` Arnd Bergmann
2011-08-25 15:16 ` Lee Jones
2011-08-10 13:03 ` [PATCH 4/4] Move top level platform devices in sysfs to /sys/devices/soc/X Lee Jones
2011-08-10 15:02 ` Greg KH
2011-08-11 11:57 ` Linus Walleij
2011-08-11 15:22 ` Greg KH
2011-08-11 18:24 ` Linus Walleij
2011-08-24 15:21 ` Arnd Bergmann
2011-08-24 15:25 ` Arnd Bergmann
2011-08-10 13:29 ` Jamie Iles [this message]
2011-08-24 14:08 ` [PATCH 1/4] Framework for exporting System-on-Chip information via sysfs Lee Jones
2011-08-24 14:19 ` Jamie Iles
2011-08-24 14:22 ` Jamie Iles
2011-08-10 15:02 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110810132956.GG2680@pulham.picochip.com \
--to=jamie@jamieiles.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).