All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Bryan Wu <bryan.wu@canonical.com>
Cc: tony@atomide.com, linux@arm.linux.org.uk, rpurdie@rpsys.net,
	manuel.lauss@gmail.com, cjb@laptop.org, cbou@mail.ru,
	dwmw2@infradead.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linus.walleij@linaro.org
Subject: Re: [PATCH 01/18] led-triggers: create a trigger for CPU activity
Date: Fri, 6 Apr 2012 15:15:05 -0700	[thread overview]
Message-ID: <20120406151505.4eeb01ba.akpm@linux-foundation.org> (raw)
In-Reply-To: <1333108713-12707-2-git-send-email-bryan.wu@canonical.com>

On Fri, 30 Mar 2012 19:58:16 +0800
Bryan Wu <bryan.wu@canonical.com> wrote:

> Attempting to consolidate the ARM LED code, this removes the
> custom RealView LED trigger code to turn LEDs on and off in
> response to CPU activity and replace it with a standard trigger.
> 
> (bryan.wu@canonical.com:
> It moves arch/arm/kernel/leds.c syscore stubs into this trigger.
> It also provides ledtrig_cpu trigger event stub in <linux/leds.h>.
> Although it was inspired by ARM work, it can be used in other arch.)
> 
>
> ...
>
> +#include <linux/percpu.h>
> +#include <linux/syscore_ops.h>
> +#include "leds.h"
> +
> +#define MAX_NAME_LEN	8

The kernel already has at least eight different definitions of
MAX_NAME_LEN.  I guess a ninth won't hurt ;)

>
> ...
>
> +static void __init ledtrig_cpu_register(void)
> +{
> +	int cpuid = smp_processor_id();
> +	struct led_trigger *trig;
> +	char *name = __get_cpu_var(trig_name);
> +
> +	snprintf(name, MAX_NAME_LEN, "cpu%d", cpuid);
> +	led_trigger_register_simple(name, &trig);
> +
> +	pr_info("LED trigger %s indicate activity on CPU %d\n",
> +		trig->name, cpuid);
> +
> +	__get_cpu_var(cpu_trig) = trig;
> +}
> +
> +static void __exit ledtrig_cpu_unregister(void)
> +{
> +	struct led_trigger *trig = __get_cpu_var(cpu_trig);
> +	char *name = __get_cpu_var(trig_name);
> +
> +	led_trigger_unregister_simple(trig);
> +	__get_cpu_var(cpu_trig) = NULL;
> +	memset(name, 0, MAX_NAME_LEN);
> +}
> +
> +static int __init ledtrig_cpu_init(void)
> +{
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu)
> +		ledtrig_cpu_register();
> +
> +	register_syscore_ops(&ledtrig_cpu_syscore_ops);
> +
> +	return 0;
> +}
> +module_init(ledtrig_cpu_init);

This all looks horridly broken.  We call ledtrig_cpu_register() once
for each CPU, but we call it on the same CPU each time, and it uses
smp_processor_id() which a) is wrong and b) will emit a runtime
preemption-is-enabled warning.

I'm assuming this wasn't tested on SMP.  It needs to be, please.

Also, the code uses for_each_possible_cpu, ignoring CPU hotplug. 
That's probably justifiable for this small storage size and not-hotpath
code, but the decision should be given prominence and justified in the
changelog or, better, in code comments please.

>
> ...
>

The patchset is basically an ARM thing.  Is there some ARM tree via
which we can get it merged?

WARNING: multiple messages have this Message-ID (diff)
From: akpm@linux-foundation.org (Andrew Morton)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/18] led-triggers: create a trigger for CPU activity
Date: Fri, 6 Apr 2012 15:15:05 -0700	[thread overview]
Message-ID: <20120406151505.4eeb01ba.akpm@linux-foundation.org> (raw)
In-Reply-To: <1333108713-12707-2-git-send-email-bryan.wu@canonical.com>

On Fri, 30 Mar 2012 19:58:16 +0800
Bryan Wu <bryan.wu@canonical.com> wrote:

> Attempting to consolidate the ARM LED code, this removes the
> custom RealView LED trigger code to turn LEDs on and off in
> response to CPU activity and replace it with a standard trigger.
> 
> (bryan.wu at canonical.com:
> It moves arch/arm/kernel/leds.c syscore stubs into this trigger.
> It also provides ledtrig_cpu trigger event stub in <linux/leds.h>.
> Although it was inspired by ARM work, it can be used in other arch.)
> 
>
> ...
>
> +#include <linux/percpu.h>
> +#include <linux/syscore_ops.h>
> +#include "leds.h"
> +
> +#define MAX_NAME_LEN	8

The kernel already has at least eight different definitions of
MAX_NAME_LEN.  I guess a ninth won't hurt ;)

>
> ...
>
> +static void __init ledtrig_cpu_register(void)
> +{
> +	int cpuid = smp_processor_id();
> +	struct led_trigger *trig;
> +	char *name = __get_cpu_var(trig_name);
> +
> +	snprintf(name, MAX_NAME_LEN, "cpu%d", cpuid);
> +	led_trigger_register_simple(name, &trig);
> +
> +	pr_info("LED trigger %s indicate activity on CPU %d\n",
> +		trig->name, cpuid);
> +
> +	__get_cpu_var(cpu_trig) = trig;
> +}
> +
> +static void __exit ledtrig_cpu_unregister(void)
> +{
> +	struct led_trigger *trig = __get_cpu_var(cpu_trig);
> +	char *name = __get_cpu_var(trig_name);
> +
> +	led_trigger_unregister_simple(trig);
> +	__get_cpu_var(cpu_trig) = NULL;
> +	memset(name, 0, MAX_NAME_LEN);
> +}
> +
> +static int __init ledtrig_cpu_init(void)
> +{
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu)
> +		ledtrig_cpu_register();
> +
> +	register_syscore_ops(&ledtrig_cpu_syscore_ops);
> +
> +	return 0;
> +}
> +module_init(ledtrig_cpu_init);

This all looks horridly broken.  We call ledtrig_cpu_register() once
for each CPU, but we call it on the same CPU each time, and it uses
smp_processor_id() which a) is wrong and b) will emit a runtime
preemption-is-enabled warning.

I'm assuming this wasn't tested on SMP.  It needs to be, please.

Also, the code uses for_each_possible_cpu, ignoring CPU hotplug. 
That's probably justifiable for this small storage size and not-hotpath
code, but the decision should be given prominence and justified in the
changelog or, better, in code comments please.

>
> ...
>

The patchset is basically an ARM thing.  Is there some ARM tree via
which we can get it merged?

  reply	other threads:[~2012-04-06 22:15 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-30 11:58 [PATCH v5 00/18] Introduce a led trigger for CPU activity and consolidate LED driver in ARM Bryan Wu
2012-03-30 11:58 ` Bryan Wu
2012-03-30 11:58 ` [PATCH 01/18] led-triggers: create a trigger for CPU activity Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-04-06 22:15   ` Andrew Morton [this message]
2012-04-06 22:15     ` Andrew Morton
2012-04-13 11:29     ` Bryan Wu
2012-04-13 11:29       ` Bryan Wu
2012-03-30 11:58 ` [PATCH 02/18] ARM: at91: convert old leds drivers to gpio_led and led_trigger drivers Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 03/18] ARM: mach-realview and mach-versatile: retire custom LED code Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 04/18] ARM: mach-ks8695: remove leds driver, since nobody use it Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 05/18] ARM: mach-shark: retire custom LED code Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 06/18] ARM: mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 07/18] ARM: mach-integrator: move CM_CTRL to header file for accessing by other functions Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 08/18] ARM: mach-integrator: retire custom LED code Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 09/18] ARM: mach-clps711x: retire custom LED code of P720T machine Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 10/18] ARM: mach-ebsa110: retire custom LED code Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 11/18] ARM: mach-footbridge: " Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 12/18] char: nwflash: remove old led event code Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 13/18] ARM: mach-pxa: retire custom LED code Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 14/18] ARM: plat-samsung: remove including old leds event API header file Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 15/18] ARM: mach-pnx4008: " Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 16/18] ARM: mach-omap1: retire custom LED code Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 17/18] ARM: mach-sa1100: " Bryan Wu
2012-03-30 11:58   ` Bryan Wu
2012-03-30 11:58 ` [PATCH 18/18] ARM: use new LEDS CPU trigger stub to replace old one Bryan Wu
2012-03-30 11:58   ` Bryan Wu
  -- strict thread matches above, loose matches on Subject: below --
2012-04-13 11:25 [PATCH v6 00/18] Introduce a led trigger for CPU activity and consolidate LED driver in ARM Bryan Wu
2012-04-13 11:26 ` [PATCH 01/18] led-triggers: create a trigger for CPU activity Bryan Wu
2012-04-13 11:26   ` Bryan Wu
2012-04-13 14:56   ` Tim Gardner
2012-04-13 14:56     ` Tim Gardner
2012-04-16  9:51     ` Bryan Wu
2012-04-16  9:51       ` Bryan Wu
2012-04-16 18:09       ` Tim Gardner
2012-04-16 18:09         ` Tim Gardner
2012-04-17 10:53 [PATCH v7 00/18] Introduce a led trigger for CPU activity and consolidate LED driver in ARM Bryan Wu
2012-04-17 10:53 ` [PATCH 01/18] led-triggers: create a trigger for CPU activity Bryan Wu
2012-04-17 10:53   ` Bryan Wu
2012-04-17 22:52   ` Andrew Morton
2012-04-17 22:52     ` Andrew Morton
2012-04-17 23:07     ` Richard Purdie
2012-04-17 23:07       ` Richard Purdie
2012-04-30  5:14       ` Bryan Wu
2012-04-30  5:14         ` Bryan Wu
2012-04-19  2:44     ` Bryan Wu
2012-04-19  2:44       ` Bryan Wu
2012-04-20  6:59   ` Stephen Boyd
2012-04-20  6:59     ` Stephen Boyd
2012-04-20  7:26     ` Bryan Wu
2012-04-20  7:26       ` Bryan Wu
2012-08-13  5:51 [PATCH v10 00/18] Introduce a led trigger for CPU activity and consolidate LED driver in ARM Bryan Wu
2012-08-13  5:51 ` [PATCH 01/18] led-triggers: create a trigger for CPU activity Bryan Wu
2012-08-13  5:51   ` Bryan Wu

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=20120406151505.4eeb01ba.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=bryan.wu@canonical.com \
    --cc=cbou@mail.ru \
    --cc=cjb@laptop.org \
    --cc=dwmw2@infradead.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=manuel.lauss@gmail.com \
    --cc=rpurdie@rpsys.net \
    --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.