From: jamie@jamieiles.com (Jamie Iles)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/17] leds: create a trigger for CPU activity
Date: Wed, 3 Aug 2011 16:30:35 +0100 [thread overview]
Message-ID: <20110803153035.GL2607@pulham.picochip.com> (raw)
In-Reply-To: <CACRpkdZRh=gcedJQh6V3aUCfi2arn2V_P67MgZE2mB_hYZ-OnQ@mail.gmail.com>
Hi Linus,
On Wed, Aug 03, 2011 at 05:22:02PM +0200, Linus Walleij wrote:
> 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.
OK, I'm fine with that.
>
> > 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.
Yes, but can't ledtrig_cpu() potentially still be called after
deactivation, then the:
if (!trigdata)
return;
would be incorrect? My main point though was that it looks like
led->trigger_data is the processor id and kfree() is being called on
that.
> > 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;
I understand that bit, but I can't see anything that actually assigns
led->trigger_data in the first place.
Jamie
next prev parent reply other threads:[~2011-08-03 15:30 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
2011-08-03 15:30 ` Jamie Iles [this message]
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=20110803153035.GL2607@pulham.picochip.com \
--to=jamie@jamieiles.com \
--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).