public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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