On Sun, Sep 11, 2011 at 4:42 PM, Thomas Renninger <trenn@xxxxxxx> wrote:
> Signed-off-by: Thomas Renninger <trenn@xxxxxxx>
> CC: Len Brown <lenb@xxxxxxxxxx>
> CC: linux-acpi@xxxxxxxxxxxxxxx
> ---
> drivers/acpi/processor_driver.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index 9247e67..7bc141a 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -540,6 +540,7 @@ err_thermal_unregister:
> thermal_cooling_device_unregister(pr->cdev);
> err_power_exit:
> acpi_processor_power_exit(pr, device);
> + sysfs_remove_link(&device->dev.kobj, "sysdev");
The sysfs_remove_link("sysdev") looks right to me.
acpi_processor_power_exit() looks like it is undoing whatever
acpi_processor_power_init() did earlier. But we only called
_power_init() if we're using acpi_idle_driver, and we call
_power_exit() always. That seems wrong. It seems like you only want
to call _power_exit() if you successfully called _power_init().
Oh, and _power_init() can return failure, but we didn't check for it.
Seems like we ought to do *something*. While you're looking at it,
I'd say the "if (!pr) return -EINVAL" in _power_init() should just be
removed. It's impossible to call with pr==NULL, and even if we could,
I'd rather take the null pointer oops so we could find the problem.
I know these issues aren't your fault, but maybe you could fix them
since you're in the area?
Bjorn
> err_free_cpumask:
> free_cpumask_var(pr->throttling.shared_cpu_map);
>
> --
> 1.7.6.1
>
> --
> 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
>
--
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
