| Message ID | 20090826123647.e60d9555.akpm@linux-foundation.org (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Thu, 27 Aug 2009 05:06:47 am Andrew Morton wrote: > So in my tree I reworked it so that the new `force' arg gets passed > through appropriately. It compiles cleanly but I'd suggest that Len > simply drop "misc:work_on_cpu-acpi" and we send it back to Rusty for > some rechecking (sorry). Sure. My main motivation is to get rid of cpumasks on the stack; while there, I tried to fix this up properly. > Rusty/Len: please work out why the title for that patch went silly. git-quiltimport uses the patch names, and doesn't extract the title. I assume that's what Stephen uses. I didn't rename the patch when I rewrote it not to use work_on_cpu. > Rusty, please self-administer smackings for > > struct set_throttling_info sti > = { pr, p_throttling, t_state.target_state }; > > these things always start out simple and end up not-simple, so some poor > schmuck has to clean them up so stuff doesn't break. > > struct set_throttling_info sti = { > .pr = pr, > .p_throttling = p_throttling, > .target_state = t_state.target_state, > .force = force > }; > > is better! Meh... same concept applies to function arguments, and we rely on typechecking to catch that (though we have little choice in C). > My linux-next repair job: OK, I've dropped these from my tree entirely to avoid more problems. Can you take them? They're not really at home in my tree. arch-x86-kernel-acpi-cstatec-avoid-using-work_on_cpu.patch misc:work_on_cpu-acpi.patch misc:work_on_cpu-acpi-fix.patch misc:work_on_cpu-dcdbas.patch You can fetch them from http://ozlabs.org/~rusty/kernel/rr-latest/ (You'll want to rename the last three something sane...) Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rusty, On Thu, 27 Aug 2009 20:23:20 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote: > > > Rusty/Len: please work out why the title for that patch went silly. > > git-quiltimport uses the patch names, and doesn't extract the title. I > assume that's what Stephen uses. I didn't rename the patch when I rewrote > it not to use work_on_cpu. git quiltimport assumes "mail-like" patches, so it looks for "From:" and "Subject:" lines. I guess it could be made to use the first line of the patch if there is no subject ...
On Thu, 27 Aug 2009 20:23:20 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote: > > My linux-next repair job: > > OK, I've dropped these from my tree entirely to avoid more problems. > > Can you take them? They're not really at home in my tree. > > arch-x86-kernel-acpi-cstatec-avoid-using-work_on_cpu.patch > misc:work_on_cpu-acpi.patch > misc:work_on_cpu-acpi-fix.patch > misc:work_on_cpu-dcdbas.patch > > You can fetch them from http://ozlabs.org/~rusty/kernel/rr-latest/ > > (You'll want to rename the last three something sane...) Those patches are already in today's linux-next so I can't carry them. Please email them over in the traditional fashion once that situation has sorted itself out? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Andrew, Rusty, On Thu, 27 Aug 2009 14:36:53 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > On Thu, 27 Aug 2009 20:23:20 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > Can you take them? They're not really at home in my tree. > > > > arch-x86-kernel-acpi-cstatec-avoid-using-work_on_cpu.patch > > misc:work_on_cpu-acpi.patch > > misc:work_on_cpu-acpi-fix.patch > > misc:work_on_cpu-dcdbas.patch > > > > You can fetch them from http://ozlabs.org/~rusty/kernel/rr-latest/ > > > > (You'll want to rename the last three something sane...) > > Those patches are already in today's linux-next so I can't carry them. > > Please email them over in the traditional fashion once that situation > has sorted itself out? Those patches will not be in next-20090828.
On Thu, 27 Aug 2009 08:43:51 pm Stephen Rothwell wrote: > Hi Rusty, > > On Thu, 27 Aug 2009 20:23:20 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote: > > > > > Rusty/Len: please work out why the title for that patch went silly. > > > > git-quiltimport uses the patch names, and doesn't extract the title. I > > assume that's what Stephen uses. I didn't rename the patch when I rewrote > > it not to use work_on_cpu. > > git quiltimport assumes "mail-like" patches, so it looks for "From:" and > "Subject:" lines. I guess it could be made to use the first line of the > patch if there is no subject ... My scripts should all handle Subject: prefixes, I can just start using that. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rusty, On Fri, 28 Aug 2009 11:32:18 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote: > > On Thu, 27 Aug 2009 08:43:51 pm Stephen Rothwell wrote: > > > > git quiltimport assumes "mail-like" patches, so it looks for "From:" and > > "Subject:" lines. I guess it could be made to use the first line of the > > patch if there is no subject ... > > My scripts should all handle Subject: prefixes, I can just start using that. Thanks, that would be good.
diff -puN drivers/acpi/processor_throttling.c~linux-next-fixup drivers/acpi/processor_throttling.c --- a/drivers/acpi/processor_throttling.c~linux-next-fixup +++ a/drivers/acpi/processor_throttling.c @@ -1015,10 +1015,25 @@ static int acpi_processor_set_throttling return 0; } +struct set_throttling_info { + struct acpi_processor *pr; + struct acpi_processor_throttling *p_throttling; + int target_state; + bool force; + int ret; +}; + +static void set_throttling(void *_sti) +{ + struct set_throttling_info *s = _sti; + + s->ret = s->p_throttling->acpi_processor_set_throttling(s->pr, + s->target_state, s->force); +} + int acpi_processor_set_throttling(struct acpi_processor *pr, int state, bool force) { - cpumask_var_t saved_mask; int ret = 0; unsigned int i; struct acpi_processor *match_pr; @@ -1059,10 +1074,13 @@ int acpi_processor_set_throttling(struct * it can be called only for the cpu pointed by pr. */ if (p_throttling->shared_type == DOMAIN_COORD_TYPE_SW_ANY) { - /* FIXME: use work_on_cpu() */ - set_cpus_allowed_ptr(current, cpumask_of(pr->id)); - ret = p_throttling->acpi_processor_set_throttling(pr, - t_state.target_state, force); + struct set_throttling_info sti = { + .pr = pr, + .p_throttling = p_throttling, + .target_state = t_state.target_state, + .force = force }; + smp_call_function_single(pr->id, set_throttling, &sti, 1); + ret = sti.ret; } else { /* * When the T-state coordination is SW_ALL or HW_ALL, @@ -1093,11 +1111,12 @@ int acpi_processor_set_throttling(struct continue; } t_state.cpu = i; - /* FIXME: use work_on_cpu() */ - set_cpus_allowed_ptr(current, cpumask_of(i)); - ret = match_pr->throttling. - acpi_processor_set_throttling( - match_pr, t_state.target_state, force); + sti.pr = match_pr; + sti.p_throttling = &match_pr->throttling; + sti.target_state = t_state.target_state; + sti.force = force; + smp_call_function_single(i, set_throttling, &sti, 1); + ret = sti.ret; } } /*