linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linus.walleij@linaro.org (Linus Walleij)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/17] leds: create a trigger for CPU activity
Date: Wed, 3 Aug 2011 17:22:02 +0200	[thread overview]
Message-ID: <CACRpkdZRh=gcedJQh6V3aUCfi2arn2V_P67MgZE2mB_hYZ-OnQ@mail.gmail.com> (raw)
In-Reply-To: <20110803102829.GC2607@pulham.picochip.com>

On Wed, Aug 3, 2011 at 12:28 PM, Jamie Iles <jamie@jamieiles.com> wrote:
> Hi Bryan,
> [...]
>> +static DEFINE_PER_CPU(struct ledtrig_cpu_data *, ledtrig_cpu_triggers);
> [...]
>> +static void ledtrig_cpu_activate_cpu(void *data)
>> +{
>> + ? ? struct ledtrig_cpu_data *cpu_data;
>> + ? ? struct led_classdev *led = data;
>> + ? ? int my_cpu = smp_processor_id();
>> + ? ? unsigned long target_cpu = (unsigned long) led->trigger_data;
>> +
>> + ? ? if (target_cpu != my_cpu)
>> + ? ? ? ? ? ? return;
>> +
>> + ? ? cpu_data = kzalloc(sizeof(*cpu_data), GFP_KERNEL);
>> + ? ? if (!cpu_data)
>> + ? ? ? ? ? ? return;
>> +
>> + ? ? dev_info(led->dev, "led %s indicate activity on CPU %d\n",
>> + ? ? ? ? ? ? ?led->name, my_cpu);
>> +
>> + ? ? cpu_data->led = led;
>> + ? ? __get_cpu_var(ledtrig_cpu_triggers) = cpu_data;
>> +}
>> +
>> +static void ledtrig_cpu_activate(struct led_classdev *led)
>> +{
>> + ? ? on_each_cpu(ledtrig_cpu_activate_cpu, led, 1);
>> +}
>> +
>> +static void ledtrig_cpu_deactivate(struct led_classdev *led)
>> +{
>> + ? ? struct ledtrig_cpu_data *cpu_data = led->trigger_data;
>> +
>> + ? ? kfree(cpu_data);
>> +}
>
> Is this deactivation correct? ?My (limited) understanding of the smp api
> is that we'll allocate the ledtrig_cpu_data for each CPU and store it in
> the ledtrig_cpu_triggers pointers.

At this point you have a handle to a specific LED and that one is tied
to a certain CPU aldready, since it is a member of
struct ledtrig_cpu_data. The LED is CPU-local by nature already since
it is looked up in the code being called from the ARM kernel,
i.e. the activate/deactivate pairs get called once per CPU.

> So shouldn't this be doing a
> __get_cpu_var(ledtrig_cpu_triggers) and a kfree() on that (and setting
> to NULL)?

You could do that but why? There is no way the pointer value
can make any harm. If activate() is called again it will be overwritten
with the new pointer.

> Also, where does led->trigger_data get assigned with the cpu id?

The activate() function is called on every core and if the CPU ID
is not equal to the assigned CPU it just exits, here:

+     int my_cpu = smp_processor_id();
+     unsigned long target_cpu = (unsigned long) led->trigger_data;
+
+     if (target_cpu != my_cpu)
+             return;

Yours,
Linus Walleij

  reply	other threads:[~2011-08-03 15:22 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-03  9:34 [PATCH v2 00/17] Introduce a led trigger for CPU activity and consolidate LED driver in ARM Bryan Wu
2011-08-03  9:34 ` [PATCH 01/17] leds: create a trigger for CPU activity Bryan Wu
2011-08-03 10:23   ` Michał Mirosław
2011-08-04  9:18     ` Bryan Wu
2011-08-03 10:28   ` Jamie Iles
2011-08-03 15:22     ` Linus Walleij [this message]
2011-08-03 15:30       ` Jamie Iles
2011-08-03 16:02         ` Jochen Friedrich
2011-08-03 16:12         ` Linus Walleij
2011-08-05  9:48           ` Bryan Wu
2011-08-03  9:34 ` [PATCH 02/17] arm: at91: convert old leds drivers to gpio_led and led_trigger drivers Bryan Wu
2011-08-03  9:34 ` [PATCH 03/17] mach-realview and mach-versatile: retire custom LED code Bryan Wu
2011-08-03 11:59   ` Russell King - ARM Linux
2011-08-17 11:06     ` Bryan Wu
2011-08-03  9:34 ` [PATCH 04/17] mach-ks8695: remove leds driver, since nobody use it Bryan Wu
2011-08-03  9:34 ` [PATCH 05/17] mach-shark: retire custom LED code Bryan Wu
2011-08-03  9:34 ` [PATCH 06/17] mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger Bryan Wu
2011-08-03  9:34 ` [PATCH 07/17] mach-integrator: introduce cm_read function helper to read CM_CTRL register Bryan Wu
2011-08-03 11:29   ` Sergei Shtylyov
2011-08-04  8:54     ` Bryan Wu
2011-08-03 11:30   ` Sergei Shtylyov
2011-08-03  9:34 ` [PATCH 08/17] mach-integrator: retire custom LED code Bryan Wu
2011-08-03  9:34 ` [PATCH 09/17] mach-clps711x: retire custom LED code of P720T machine Bryan Wu
2011-08-03  9:34 ` [PATCH 10/17] mach-ebsa110: retire custom LED code Bryan Wu
2011-08-03  9:34 ` [PATCH 11/17] mach-footbridge: " Bryan Wu
2011-08-03  9:34 ` [PATCH 12/17] mach-pxa: " Bryan Wu
2011-08-03  9:34 ` [PATCH 13/17] plat-samsung: remove including old leds event API header file Bryan Wu
2011-08-03  9:34 ` [PATCH 14/17] mach-pnx4008: " Bryan Wu
2011-08-03  9:34 ` [PATCH 15/17] mach-omap1: retire custom LED code Bryan Wu
2011-08-03  9:34 ` [PATCH 16/17] mach-sa1100: " Bryan Wu
2011-08-03  9:34 ` [PATCH 17/17] ARM: use new LEDS CPU trigger stub to replace old one Bryan Wu
  -- strict thread matches above, loose matches on Subject: below --
2011-07-06 12:34 [PATCH 00/17] Introduce a led trigger for CPU activity Bryan Wu
2011-07-06 12:34 ` [PATCH 01/17] leds: create a " Bryan Wu
2011-07-06 13:16   ` Eric Miao
2011-07-06 13:35     ` Russell King - ARM Linux
2011-07-06 14:11       ` Nicolas Pitre
2011-07-07 12:58     ` 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='CACRpkdZRh=gcedJQh6V3aUCfi2arn2V_P67MgZE2mB_hYZ-OnQ@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --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).