From: Jean Delvare <khali@linux-fr.org>
To: "Fenghua Yu" <fenghua.yu@intel.com>
Cc: "Ingo Molnar" <mingo@elte.hu>, "H Peter Anvin" <hpa@zytor.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Guenter Roeck" <guenter.roeck@ericsson.com>,
"Jin Dongming" <jin.dongming@np.css.fujitsu.com>,
"Hidetoshi Seto" <seto.hidetoshi@jp.fujitsu.com>,
"linux-kernel" <linux-kernel@vger.kernel.org>,
"lm-sensors" <lm-sensors@lm-sensors.org>
Subject: Re: [PATCH v2] x86/therm_throt.c: Fix error handling in thermal_throttle_add_dev
Date: Fri, 10 Sep 2010 10:19:37 +0200 [thread overview]
Message-ID: <20100910101937.373d8a16@hyperion.delvare> (raw)
In-Reply-To: <1283905550-18571-1-git-send-email-fenghua.yu@intel.com>
On Tue, 7 Sep 2010 17:25:50 -0700, Fenghua Yu wrote:
> From: Fenghua Yu <fenghua.yu@intel.com>
>
> When sysfs_add_file_to_group fails, thermal_throttle_add_dev removes the
> created group and returns with the error code and the driver cleans up and
> returns with the error code. Thus the driver either installs all devices
> successfully or doesn't install any device at all.
I don't think this makes any sense. While I generally agree with the
idea that a given device (actually, CPU feature) should either be fully
available or not available at all, I don't get the point of preventing
the driver from loading because one device couldn't be initialized for
whatever reason. I don't know of any other driver behaving this way.
What's the rationale? I think Ingo's wording was inaccurate and when he
wrote "we should either initialize a driver fully - or not intialize it
at all" he really meant "device" not "driver. Ingo?
>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> ---
> arch/x86/kernel/cpu/mcheck/therm_throt.c | 36 ++++++++++++++++++++++++++---
> 1 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> index c2a8b26..5099e90 100644
> --- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
> +++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> @@ -211,19 +211,33 @@ static __cpuinit int thermal_throttle_add_dev(struct sys_device *sys_dev)
> if (err)
> return err;
>
> - if (cpu_has(c, X86_FEATURE_PLN))
> + if (cpu_has(c, X86_FEATURE_PLN)) {
> err = sysfs_add_file_to_group(&sys_dev->kobj,
> &attr_core_power_limit_count.attr,
> thermal_attr_group.name);
> - if (cpu_has(c, X86_FEATURE_PTS))
> + if (err)
> + goto error;
> + }
> +
> + if (cpu_has(c, X86_FEATURE_PTS)) {
> err = sysfs_add_file_to_group(&sys_dev->kobj,
> &attr_package_throttle_count.attr,
> thermal_attr_group.name);
> - if (cpu_has(c, X86_FEATURE_PLN))
> + if (err)
> + goto error;
> +
> + if (cpu_has(c, X86_FEATURE_PLN)) {
> err = sysfs_add_file_to_group(&sys_dev->kobj,
> &attr_package_power_limit_count.attr,
> thermal_attr_group.name);
> + if (err)
> + goto error;
> + }
> + }
>
> + return 0;
> +error:
> + sysfs_remove_group(&sys_dev->kobj, &thermal_attr_group);
> return err;
> }
>
I'm fine with the above...
> @@ -275,6 +289,7 @@ static struct notifier_block thermal_throttle_cpu_notifier __cpuinitdata =
> static __init int thermal_throttle_init_device(void)
> {
> unsigned int cpu = 0;
> + int i;
> int err;
>
> if (!atomic_read(&therm_throt_en))
> @@ -288,13 +303,26 @@ static __init int thermal_throttle_init_device(void)
> /* connect live CPUs to sysfs */
> for_each_online_cpu(cpu) {
> err = thermal_throttle_add_dev(get_cpu_sysdev(cpu));
> - WARN_ON(err);
> + if (err)
> + goto error;
> }
> #ifdef CONFIG_HOTPLUG_CPU
> mutex_unlock(&therm_cpu_lock);
> #endif
>
> return 0;
> +error:
> + WARN_ON(err);
> +
> + /* cleanup. */
> + for (i = 0; i < cpu; i++)
> + thermal_throttle_remove_dev(get_cpu_sysdev(i));
> +#ifdef CONFIG_HOTPLUG_CPU
> + mutex_unlock(&therm_cpu_lock);
> +#endif
> + unregister_hotcpu_notifier(&thermal_throttle_cpu_notifier);
> +
> + return err;
> }
> device_initcall(thermal_throttle_init_device);
>
... but not with this!
--
Jean Delvare
next prev parent reply other threads:[~2010-09-10 8:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-08 0:25 [PATCH v2] x86/therm_throt.c: Fix error handling in thermal_throttle_add_dev Fenghua Yu
2010-09-10 8:19 ` Jean Delvare [this message]
2010-09-10 13:56 ` Guenter Roeck
2010-09-13 7:55 ` Jean Delvare
2010-10-08 8:10 ` Jean Delvare
2010-10-08 8:26 ` Ingo Molnar
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=20100910101937.373d8a16@hyperion.delvare \
--to=khali@linux-fr.org \
--cc=fenghua.yu@intel.com \
--cc=guenter.roeck@ericsson.com \
--cc=hpa@zytor.com \
--cc=jin.dongming@np.css.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
--cc=mingo@elte.hu \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=tglx@linutronix.de \
/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