All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] Framework for exporting System-on-Chip information via sysfs
Date: Fri, 15 Jul 2011 16:02:05 +0200	[thread overview]
Message-ID: <201107151602.06282.arnd@arndb.de> (raw)
In-Reply-To: <1310476090-9807-1-git-send-email-lee.jones@linaro.org>

On Tuesday 12 July 2011, Lee Jones wrote:
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  drivers/base/Kconfig    |   10 +++++
>  drivers/base/Makefile   |    1 +
>  drivers/base/soc.c      |   98 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/sys_soc.h |   45 +++++++++++++++++++++

After looking at the patch again, I do have some important comments
after all. I had only looked at the documentation you posted, not
at the actual patch.

> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index d57e8d0..2feab2b 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -168,4 +168,14 @@ config SYS_HYPERVISOR
>  	bool
>  	default n
>  
> +config ARCH_NO_SYSDEV_OPS
> +	bool
> +	---help---
> +	  To be selected by architectures that don't use sysdev class or
> +	  sysdev driver power management (suspend/resume) and shutdown
> +	  operations.

You don't seem to be using this anywhere. What is this for?

> diff --git a/drivers/base/soc.c b/drivers/base/soc.c
> new file mode 100644
> index 0000000..30659f4
> --- /dev/null
> +++ b/drivers/base/soc.c
> @@ -0,0 +1,98 @@
> +/*
> + * 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>
> +
> +struct device_attribute soc_attrs[] = {
> +	__ATTR(machine,  S_IRUGO, NULL, NULL),
> +	__ATTR(family,   S_IRUGO, NULL, NULL),
> +	__ATTR(soc_id,   S_IRUGO, NULL, NULL),
> +	__ATTR(revision, S_IRUGO, NULL, NULL),
> +	__ATTR_NULL,
> +};

This method does not work. You only set the function pointers
when you call soc_device_register, but they will end up overwriting
the existing function pointers when you have multiple callers of that
function.

It would be better to define a 'struct soc_device' derived from 'struct 
device' that holds a pointer to the actual strings (or operations, if
you insist) and provide a single soc_info_get() function that is used
for all the attributes.

> +const char *soc_names[] = { "1", "2", "3", "4", "5", "6", "7", "8" };
> +static int soc_count = 0;

This is a bit silly and artificially limits the number of SoC devices.
It's much simpler to just use dev_set_name().

> +static struct device soc_grandparent = {
> +	.init_name = "soc",
> +};
>
> +static int soc_device_create_files(struct device *soc);
> +static void soc_device_remove_files(struct device *soc);

No forward declarations for static functions please.

> +int __init soc_device_register(struct device *soc_parent,
> +			struct soc_callback_functions *soc_callbacks)
> +{
> +	int ret;
> +
> +	soc_attrs[MACHINE].show = soc_callbacks->get_machine_fn;
> +	soc_attrs[FAMILY].show = soc_callbacks->get_family_fn;
> +	soc_attrs[SOCID].show = soc_callbacks->get_soc_id_fn;
> +	soc_attrs[REVISION].show = soc_callbacks->get_revision_fn;

It's better to allocate the device here, so you don't have to
do it in each caller.

> +	soc_parent->init_name = soc_names[soc_count];
> +	soc_parent->parent = &soc_grandparent;
> +
> +	ret = device_register(soc_parent);
> +	if (ret)
> +		return ret;
> +
> +	soc_device_create_files(soc_parent);
> +
> +	soc_count++;

This needs some locking to ensure that you don't try to register
two devices with the same number.

> +
> +void __exit soc_device_unregister(struct device *soc_parent)
> +{
> +	/* Unregister and free SoC from sysfs */
> +	soc_device_remove_files(soc_parent);
> +	device_unregister(soc_parent);
> +
> +	if (--soc_count == 0)
> +		/* Unregister top-level SoC device '/sys/devices/soc' */
> +	device_unregister(&soc_grandparent);
> +}

The exit function does not make any sense if you cannot build the soc
support itself as a module, which in turn makes no sense at all.

> +
> +#define MAX_SOCS 8
> +#define MACHINE  0
> +#define FAMILY   1
> +#define SOCID    2
> +#define REVISION 3
> +

I think these defines are used nowhere by the individual drivers, so they
need not be in the header file. More importantly, the names are not put
in a proper namespace, so they can easily collide with other macros
or enums.

	Arnd

  parent reply	other threads:[~2011-07-15 14:02 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-12 13:08 [PATCH 1/3] Framework for exporting System-on-Chip information via sysfs Lee Jones
2011-07-12 13:08 ` [PATCH 2/3] mach-ux500: export " Lee Jones
2011-07-12 16:29   ` Saravana Kannan
2011-07-13  7:55     ` Lee Jones
2011-07-13 16:40       ` Saravana Kannan
2011-07-13 20:32         ` Greg KH
2011-07-13 20:51           ` Arnd Bergmann
2011-07-14  6:42             ` Lee Jones
2011-07-14 12:58               ` Arnd Bergmann
2011-07-14 13:04                 ` Lee Jones
2011-07-14 17:25             ` Saravana Kannan
2011-07-15  6:27               ` Lee Jones
2011-07-12 16:47   ` Arnd Bergmann
2011-07-13  8:10     ` Lee Jones
2011-07-13 13:42       ` Arnd Bergmann
2011-07-13 14:31         ` Lee Jones
2011-07-13 16:20           ` Arnd Bergmann
2011-07-12 13:08 ` [PATCH 3/3] Add documenation for new sysfs devices/soc functionallity Lee Jones
2011-07-12 14:13 ` [PATCH 1/3] Framework for exporting System-on-Chip information via sysfs Baruch Siach
2011-07-12 16:08   ` Greg KH
2011-07-13  7:16     ` Lee Jones
2011-07-13  7:53       ` Greg KH
2011-07-13  8:27         ` Lee Jones
2011-07-15 14:02 ` Arnd Bergmann [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-04-14 14:49 [PATCH 0/3] Export valuable System-on-Chip information to user-space " Lee Jones
2011-04-14 14:49 ` [PATCH 1/3] Framework for exporting System-on-Chip information " Lee Jones
2011-04-17 18:36   ` Arnd Bergmann
2011-04-21  9:44     ` Lee Jones
2011-04-21 11:03       ` Arnd Bergmann
2011-04-21 11:56         ` Lee Jones
2011-04-27 20:48           ` Russell King - ARM Linux
2011-04-28  6:46             ` Lee Jones
2011-04-11 18:01 Lee Jones
2011-04-12 12:46 ` Jamie Iles
2011-04-13  7:43   ` Lee Jones

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=201107151602.06282.arnd@arndb.de \
    --to=arnd@arndb.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.