linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Gardner <tim.gardner@canonical.com>
To: Bryan Wu <bryan.wu@canonical.com>
Cc: linux@arm.linux.org.uk, rpurdie@rpsys.net,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linus.walleij@linaro.org,
	akpm@linux-foundation.org, arnd.bergmann@linaro.org,
	nicolas.pitre@linaro.org
Subject: Re: [PATCH 01/18] led-triggers: create a trigger for CPU activity
Date: Mon, 16 Apr 2012 12:09:15 -0600	[thread overview]
Message-ID: <4F8C604B.70700@canonical.com> (raw)
In-Reply-To: <CAK5ve-K=KUO+uNK7bJw_RFJ55oid=q36tFHmqLJmeGdRxkt=wg@mail.gmail.com>

On 04/16/2012 03:51 AM, Bryan Wu wrote:
>>> +
>>> +#define MAX_NAME_LEN 8
>>> +
>>
>> This length accommodates up to 10000 CPUs. How long will that suffice ?
>>
> 
> How about this:
> #define MAX_NAME_LEN    (4 + DIV_ROUND_UP(NR_CPUS, 255))
> 

That doesn't really work either. How about just leave MAX_NAME_LEN at 8
and add a 'BUILD_BUG_ON(CONFIG_NR_CPUS > 9999)' somewhere ?

> 
>>> +static DEFINE_PER_CPU(struct led_trigger *, cpu_trig);
>>> +static DEFINE_PER_CPU(char [MAX_NAME_LEN], trig_name);
>>> +
>>> +void ledtrig_cpu(enum cpu_led_event ledevt)
>>> +{
>>> +     struct led_trigger *trig = __get_cpu_var(cpu_trig);
>>> +
>>> +     if (!trig)
>>> +             return;
>>
>> I don't think __get_cpu_var(cpu_trig) _should_ ever return NULL. See
>> discussion about exclusion below in ledtrig_cpu_init().
>>
>>> +
>>> +     /* Locate the correct CPU LED */
>>> +     switch (ledevt) {
>>> +     case CPU_LED_IDLE_END:
>>> +     case CPU_LED_START:
>>> +             /* Will turn the LED on, max brightness */
>>> +             led_trigger_event(trig, LED_FULL);
>>> +             break;
>>> +
>>> +     case CPU_LED_IDLE_START:
>>> +     case CPU_LED_STOP:
>>> +     case CPU_LED_HALTED:
>>> +             /* Will turn the LED off */
>>> +             led_trigger_event(trig, LED_OFF);
>>> +             break;
>>> +
>>> +     default:
>>> +             /* Will leave the LED as it is */
>>> +             break;
>>> +     }
>>> +}
>>> +EXPORT_SYMBOL(ledtrig_cpu);
>>> +
>>> +static int ledtrig_cpu_syscore_suspend(void)
>>> +{
>>> +     ledtrig_cpu(CPU_LED_STOP);
>>> +     return 0;
>>> +}
>>> +
>>> +static void ledtrig_cpu_syscore_resume(void)
>>> +{
>>> +     ledtrig_cpu(CPU_LED_START);
>>> +}
>>> +
>>> +static void ledtrig_cpu_syscore_shutdown(void)
>>> +{
>>> +     ledtrig_cpu(CPU_LED_HALTED);
>>> +}
>>> +
>>> +static struct syscore_ops ledtrig_cpu_syscore_ops = {
>>> +     .shutdown       = ledtrig_cpu_syscore_shutdown,
>>> +     .suspend        = ledtrig_cpu_syscore_suspend,
>>> +     .resume         = ledtrig_cpu_syscore_resume,
>>> +};
>>> +
>>> +static int __init ledtrig_cpu_init(void)
>>> +{
>>> +     int cpu;
>>> +
>>> +     /*
>>> +      * Registering CPU led trigger for each CPU cores here
>>> +      * ignores CPU hotplug, but after this CPU hotplug works
>>> +      * fine with this trigger.
>>> +      */
>>> +     for_each_possible_cpu(cpu) {
>>> +             struct led_trigger *trig;
>>> +             char *name = per_cpu(trig_name, cpu);
>>> +
>>> +             snprintf(name, MAX_NAME_LEN, "cpu%d", cpu);
>>> +             led_trigger_register_simple(name, &trig);
>>
>> Check for trig == NULL. led_trigger_register_simple() does a
>> kzalloc(GFP_KERNEL). You'll also have to unwind any successful
>> registrations. Perhaps carve the guts out of ledtrig_cpu_exit() into a
>> function that can be called from either place.
>>
> 
> Actually, led_trigger_register_simple() will take care of kzalloc()
> failure. And if so trig will be NULL. I think it's unnecessary to
> check trig == NULL here and unwind any passed registrations, since
> those registration failure on for one CPU has no relationship with
> other successful registrations.
> 
> So it is necessary for us to check trig==NULL in ledtrig_cpu().
> 

I guess that means you're OK with partial registrations? That doesn't
seem orthogonal to me, but probably won't cause an OOPS. I'll look again
when you send out v2 of this patch set.

rtg
-- 
Tim Gardner tim.gardner@canonical.com

  reply	other threads:[~2012-04-16 18:10 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 14:56   ` Tim Gardner
2012-04-16  9:51     ` Bryan Wu
2012-04-16 18:09       ` Tim Gardner [this message]
2012-04-13 11:26 ` [PATCH 02/18] ARM: at91: convert old leds drivers to gpio_led and led_trigger drivers Bryan Wu
2012-04-13 11:26 ` [PATCH 03/18] ARM: mach-realview and mach-versatile: retire custom LED code Bryan Wu
2012-04-13 11:26 ` [PATCH 04/18] ARM: mach-ks8695: remove leds driver, since nobody use it Bryan Wu
2012-04-13 11:26 ` [PATCH 05/18] ARM: mach-shark: retire custom LED code Bryan Wu
2012-04-13 11:26 ` [PATCH 06/18] ARM: mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger Bryan Wu
2012-04-13 11:26 ` [PATCH 07/18] ARM: mach-integrator: move CM_CTRL to header file for accessing by other functions Bryan Wu
2012-04-13 11:26 ` [PATCH 08/18] ARM: mach-integrator: retire custom LED code Bryan Wu
2012-04-13 11:26 ` [PATCH 09/18] ARM: mach-clps711x: retire custom LED code of P720T machine Bryan Wu
2012-04-13 11:26 ` [PATCH 10/18] ARM: mach-ebsa110: retire custom LED code Bryan Wu
2012-04-13 11:26 ` [PATCH 11/18] ARM: mach-footbridge: " Bryan Wu
2012-04-13 11:26 ` [PATCH 12/18] char: nwflash: remove old led event code Bryan Wu
2012-04-13 11:26 ` [PATCH 13/18] ARM: mach-pxa: retire custom LED code Bryan Wu
2012-04-13 11:26 ` [PATCH 14/18] ARM: plat-samsung: remove including old leds event API header file Bryan Wu
2012-04-13 11:26 ` [PATCH 15/18] ARM: mach-pnx4008: " Bryan Wu
2012-04-13 11:26 ` [PATCH 16/18] ARM: mach-omap1: retire custom LED code Bryan Wu
2012-04-13 11:26 ` [PATCH 17/18] ARM: mach-sa1100: " Bryan Wu
2012-04-13 11:26 ` [PATCH 18/18] ARM: use new LEDS CPU trigger stub to replace old one Bryan Wu
  -- strict thread matches above, loose matches on Subject: below --
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-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 22:52   ` Andrew Morton
2012-04-17 23:07     ` Richard Purdie
2012-04-30  5:14       ` Bryan Wu
2012-04-19  2:44     ` Bryan Wu
2012-04-20  6:59   ` Stephen Boyd
2012-04-20  7:26     ` Bryan Wu
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 ` [PATCH 01/18] led-triggers: create a trigger for CPU activity Bryan Wu
2012-04-06 22:15   ` Andrew Morton
2012-04-13 11:29     ` 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=4F8C604B.70700@canonical.com \
    --to=tim.gardner@canonical.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd.bergmann@linaro.org \
    --cc=bryan.wu@canonical.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nicolas.pitre@linaro.org \
    --cc=rpurdie@rpsys.net \
    /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).