All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin-nonst@stericsson.com>
To: Jamie Iles <jamie@jamieiles.com>
Cc: ext Nishanth Menon <nm@ti.com>,
	ext Tony Lindgren <tony@atomide.com>,
	Peter De-Schrijver <Peter.De-Schrijver@nokia.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Ambresh <a0393775@ti.com>,
	Saravana Kannan <skannan@codeaurora.org>,
	Andrei Warkentin <andreiw@motorola.com>,
	Lee Jones <Lee.Jones@linaro.org>,
	Rabin VINCENT <rabin.vincent@stericsson.com>,
	Russell King <linux@arm.linux.org.uk>,
	Jonas ABERG <jonas.aberg@stericsson.com>,
	ext Kevin Hilman <khilman@deeprootsystems.com>,
	David Brown <davidb@codeaurora.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	Loic PALLARDY <loic.pallardy@stericsson.com>,
	"eduardo.valentin@nokia.com" <eduardo.valentin@nokia.com>,
	"maxime_coquelin@yahoo.fr" <maxime_coquelin@yahoo.fr>,
	Ryan Mallon <ryan@bluewatersys.com>,
	Linux-OMAP <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@>
Subject: Re: [RFC PATCHv1 1/2] Export SoC info through sysfs
Date: Thu, 10 Mar 2011 10:45:12 +0100	[thread overview]
Message-ID: <4D789DA8.7080703@stericsson.com> (raw)
In-Reply-To: <20110309173902.GD2737@pulham.picochip.com>

On 03/09/2011 06:39 PM, Jamie Iles wrote:
> Hi Maxime,
>
> Thanks for doing this, it looks very nice!  A couple of nitpicks, but
> I've given it a quick spin on my platform and it provides us with all of
> the hooks to export all of the information we need.
>
> Jamie

Hi Jamie,
Thanks for your review. Fine it works for you.

> +
> +static struct sysdev_class_attribute *soc_default_attrs[];
> +
> +struct sys_soc {
> +	char *mach_name;
> Can this be made const?

Yes, you're right.

>> +
>> +	if (si->info)
>> +		return sprintf(buf, "%s\n", si->info);
>> +	else if (si->get_info)
>> +		return sprintf(buf, "%s\n", si->get_info(si));
>> +	else
>> +		return sprintf(buf, "No data\n");
> Isn't this a platform error if we don't have a way to get the required
> info?  If in register_sys_soc_info() we check that one of si->info or
> si->get_info is non-NULL then we don't need this check.  If we have
> something like:
>
> static bool sys_soc_info_is_valid(struct sys_soc_info *info)
> {
> 	if ((!info->info&&  !info->get_info) ||
> 	    info->info&&  info->get_info)
> 	    return false;
>
> 	return true;
> }

Yes it is a platform error, it should be tested at registration time.

> then we can do this at registration.  Is there a valid use case where
> someone could set the static info and the dynamic get_info callback?
>

At registration, no. But in the get_info callback, we can set the info 
field in order to call the callback once if the value will never change.
However, I will remove this possibility as it is not clear.

>
> Make name const?  Also, should num be a size_t?

Fixed

> soc.mach_name = kstrdup(name, GFP_KERNEL) instead of the allocate and
> sprintf?
>

Fixed.

>> +struct sys_soc_info {
>> +	char *name;
>> +	char *info;
>> +	char *(*get_info)(struct sys_soc_info *);
> Could this return a const char* ?
>

Fixed.

>> +	struct sysdev_class_attribute attr;
>> +};
>> +
>> +/**
>> + * void register_sys_soc(char *name, struct sys_soc_info *, int num)
> I think this should be "register_sys_soc - register the soc information"
> for valid kerneldoc notation..

Fixed.

Regards,
Maxime

WARNING: multiple messages have this Message-ID (diff)
From: maxime.coquelin-nonst@stericsson.com (Maxime Coquelin)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCHv1 1/2] Export SoC info through sysfs
Date: Thu, 10 Mar 2011 10:45:12 +0100	[thread overview]
Message-ID: <4D789DA8.7080703@stericsson.com> (raw)
In-Reply-To: <20110309173902.GD2737@pulham.picochip.com>

On 03/09/2011 06:39 PM, Jamie Iles wrote:
> Hi Maxime,
>
> Thanks for doing this, it looks very nice!  A couple of nitpicks, but
> I've given it a quick spin on my platform and it provides us with all of
> the hooks to export all of the information we need.
>
> Jamie

Hi Jamie,
Thanks for your review. Fine it works for you.

> +
> +static struct sysdev_class_attribute *soc_default_attrs[];
> +
> +struct sys_soc {
> +	char *mach_name;
> Can this be made const?

Yes, you're right.

>> +
>> +	if (si->info)
>> +		return sprintf(buf, "%s\n", si->info);
>> +	else if (si->get_info)
>> +		return sprintf(buf, "%s\n", si->get_info(si));
>> +	else
>> +		return sprintf(buf, "No data\n");
> Isn't this a platform error if we don't have a way to get the required
> info?  If in register_sys_soc_info() we check that one of si->info or
> si->get_info is non-NULL then we don't need this check.  If we have
> something like:
>
> static bool sys_soc_info_is_valid(struct sys_soc_info *info)
> {
> 	if ((!info->info&&  !info->get_info) ||
> 	    info->info&&  info->get_info)
> 	    return false;
>
> 	return true;
> }

Yes it is a platform error, it should be tested at registration time.

> then we can do this at registration.  Is there a valid use case where
> someone could set the static info and the dynamic get_info callback?
>

At registration, no. But in the get_info callback, we can set the info 
field in order to call the callback once if the value will never change.
However, I will remove this possibility as it is not clear.

>
> Make name const?  Also, should num be a size_t?

Fixed

> soc.mach_name = kstrdup(name, GFP_KERNEL) instead of the allocate and
> sprintf?
>

Fixed.

>> +struct sys_soc_info {
>> +	char *name;
>> +	char *info;
>> +	char *(*get_info)(struct sys_soc_info *);
> Could this return a const char* ?
>

Fixed.

>> +	struct sysdev_class_attribute attr;
>> +};
>> +
>> +/**
>> + * void register_sys_soc(char *name, struct sys_soc_info *, int num)
> I think this should be "register_sys_soc - register the soc information"
> for valid kerneldoc notation..

Fixed.

Regards,
Maxime

  reply	other threads:[~2011-03-10  9:45 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-09 16:59 [RFC PATCHv1 0/2] Export SoC info through sysfs Maxime Coquelin
2011-03-09 16:59 ` Maxime Coquelin
2011-03-09 16:59 ` Maxime Coquelin
2011-03-09 16:59 ` [RFC PATCHv1 1/2] " Maxime Coquelin
2011-03-09 16:59   ` Maxime Coquelin
2011-03-09 16:59   ` Maxime Coquelin
2011-03-09 17:39   ` Jamie Iles
2011-03-09 17:39     ` Jamie Iles
2011-03-10  9:45     ` Maxime Coquelin [this message]
2011-03-10  9:45       ` Maxime Coquelin
2011-03-09 17:47   ` Mark Brown
2011-03-09 17:47     ` Mark Brown
2011-03-10  9:58     ` Maxime Coquelin
2011-03-10  9:58       ` Maxime Coquelin
2011-03-10 13:18       ` Mark Brown
2011-03-10 13:18         ` Mark Brown
2011-03-10 13:16         ` Maxime Coquelin
2011-03-10 13:16           ` Maxime Coquelin
2011-03-09 19:58   ` Arnd Bergmann
2011-03-09 19:58     ` Arnd Bergmann
2011-03-10 12:56     ` Maxime Coquelin
2011-03-10 12:56       ` Maxime Coquelin
2011-03-10 13:25     ` Linus Walleij
2011-03-10 13:25       ` Linus Walleij
2011-03-10 14:08       ` Mark Brown
2011-03-10 14:08         ` Mark Brown
2011-03-10 14:29         ` Arnd Bergmann
2011-03-10 14:29           ` Arnd Bergmann
2011-03-10 14:44           ` Mark Brown
2011-03-10 14:44             ` Mark Brown
2011-03-10 15:02             ` Arnd Bergmann
2011-03-10 15:02               ` Arnd Bergmann
2011-03-10 15:10               ` Russell King - ARM Linux
2011-03-10 15:10                 ` Russell King - ARM Linux
2011-03-10 15:17                 ` Linus Walleij
2011-03-10 15:17                   ` Linus Walleij
2011-03-10 15:21                 ` Helmut Raiger
2011-03-10 15:20               ` Mark Brown
2011-03-10 15:20                 ` Mark Brown
2011-03-10 16:11                 ` Arnd Bergmann
2011-03-10 16:11                   ` Arnd Bergmann
2011-03-10 16:19                   ` Mark Brown
2011-03-10 16:19                     ` Mark Brown
2011-03-10 16:54                     ` Arnd Bergmann
2011-03-10 16:54                       ` Arnd Bergmann
2011-03-10 14:23       ` Arnd Bergmann
2011-03-10 14:23         ` Arnd Bergmann
2011-03-10 16:05         ` Linus Walleij
2011-03-10 16:05           ` Linus Walleij
2011-03-10 16:32           ` Arnd Bergmann
2011-03-10 16:32             ` Arnd Bergmann
2011-03-10 17:08             ` Linus Walleij
2011-03-10 17:08               ` Linus Walleij
2011-03-11 16:14               ` Arnd Bergmann
2011-03-11 16:14                 ` Arnd Bergmann
2011-03-09 20:38   ` Ryan Mallon
2011-03-09 20:38     ` Ryan Mallon
2011-03-09 16:59 ` [RFC PATCHv1 2/2] ux500: Export U8500 " Maxime Coquelin
2011-03-09 16:59   ` Maxime Coquelin
2011-03-09 16:59   ` Maxime Coquelin
2011-03-09 20:02   ` Arnd Bergmann
2011-03-09 20:02     ` Arnd Bergmann
2011-03-10 13:05 ` [RFC PATCHv1 0/2] Export " Eduardo Valentin
2011-03-10 13:05   ` Eduardo Valentin
2011-03-10 13:36   ` Maxime Coquelin
2011-03-10 13:36     ` Maxime Coquelin

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=4D789DA8.7080703@stericsson.com \
    --to=maxime.coquelin-nonst@stericsson.com \
    --cc=Lee.Jones@linaro.org \
    --cc=Peter.De-Schrijver@nokia.com \
    --cc=a0393775@ti.com \
    --cc=andreiw@motorola.com \
    --cc=davidb@codeaurora.org \
    --cc=eduardo.valentin@nokia.com \
    --cc=jamie@jamieiles.com \
    --cc=jonas.aberg@stericsson.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=loic.pallardy@stericsson.com \
    --cc=maxime_coquelin@yahoo.fr \
    --cc=nm@ti.com \
    --cc=rabin.vincent@stericsson.com \
    --cc=ryan@bluewatersys.com \
    --cc=skannan@codeaurora.org \
    --cc=tony@atomide.com \
    /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.