On Fri, 18 Sep 2009 15:59:53 -0400
Dave Jones <davej@xxxxxxxxxx> wrote:
> On Fri, Sep 18, 2009 at 12:41:05PM -0700, Andrew Morton wrote:
>
> > diff -puN arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c~arch-x86-kernel-cpu-cpufreq-acpi-cpufreqc-avoid-cross-cpu-interrupts-by-using-smp_call_function_any arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
> > --- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c~arch-x86-kernel-cpu-cpufreq-acpi-cpufreqc-avoid-cross-cpu-interrupts-by-using-smp_call_function_any
> > +++ a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
> > @@ -192,9 +192,11 @@ static void do_drv_write(void *_cmd)
> >
> > static void drv_read(struct drv_cmd *cmd)
> > {
> > + int err;
> > cmd->val = 0;
> >
> > - smp_call_function_single(cpumask_any(cmd->mask), do_drv_read, cmd, 1);
> > + err = smp_call_function_any(cmd->mask, do_drv_read, cmd, 1);
> > + WARN_ON_ONCE(err); /* smp_call_function_any() was buggy? */
> > }
> >
> > static void drv_write(struct drv_cmd *cmd)
>
> I'm ok with this going in, but I still wonder if we could have done it
> all a lot easier, by making cpumask_any pick the current cpu if it was
> in the mask instead of introducing yet another variant to an already
> enormous api.
>
Yeah, I wondered about that. But iirc Rusty had a good-sounding reason
for adding a new function but that reason didn't get into the changelog so
it's lost.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
