lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1365730710.2183.26.camel@rzhang1-mobl4>
Date:	Fri, 12 Apr 2013 09:38:30 +0800
From:	Zhang Rui <rui.zhang@...el.com>
To:	Yuxuan Shui <yshuiv7@...il.com>
Cc:	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Amit Kachhap <amit.kachhap@...aro.org>,
	durga <durgadoss.r@...el.com>, eduardo <eduardo.valentin@...com>
Subject: Re: [PATCH] Thermal: Don't resolve THERMAL_NO_LIMIT to max_state.

On Tue, 2013-03-26 at 21:29 +0800, Yuxuan Shui wrote:
> max_state may change at runtime, for example, when loading/unloading
> cpufreq policy.
> 
this seems to be a problem that we have not covered yet.

when loading/unloading the cpufreq policy, the cpufreq_frequency_table
will be changed as well, right?
what if we want to use p4 for trip point 2, and then there are only two
valid entries after reloading cpufreq policy?

To me, the real thing we missed here is a mechanism for dynamic
binding. 

thanks,
rui

> Signed-off-by: Yuxuan Shui <yshuiv7@...il.com>
> ---
>  drivers/thermal/step_wise.c   | 11 ++++++++---
>  drivers/thermal/thermal_sys.c |  5 ++---
>  2 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
> index 407cde3..2edb7e9 100644
> --- a/drivers/thermal/step_wise.c
> +++ b/drivers/thermal/step_wise.c
> @@ -54,18 +54,23 @@ static unsigned long get_target_state(struct thermal_instance *instance,
>  {
>  	struct thermal_cooling_device *cdev = instance->cdev;
>  	unsigned long cur_state;
> +	unsigned long max_state;
> +	int upper;
>  
>  	cdev->ops->get_cur_state(cdev, &cur_state);
> +	cdev->ops->get_max_state(cdev, &max_state);
> +
> +	upper = instance->upper == THERMAL_NO_LIMIT ? max_state : instance->upper;
>  
>  	switch (trend) {
>  	case THERMAL_TREND_RAISING:
>  		if (throttle)
> -			cur_state = cur_state < instance->upper ?
> -				    (cur_state + 1) : instance->upper;
> +			cur_state = cur_state < upper ?
> +				    (cur_state + 1) : upper;
>  		break;
>  	case THERMAL_TREND_RAISE_FULL:
>  		if (throttle)
> -			cur_state = instance->upper;
> +			cur_state = upper;
>  		break;
>  	case THERMAL_TREND_DROPPING:
>  		if (cur_state == instance->lower) {
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 5b7863a..f02e4d4 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -1134,11 +1134,10 @@ int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz,
>  
>  	cdev->ops->get_max_state(cdev, &max_state);
>  
> -	/* lower default 0, upper default max_state */
> +	/* lower default 0 */
>  	lower = lower == THERMAL_NO_LIMIT ? 0 : lower;
> -	upper = upper == THERMAL_NO_LIMIT ? max_state : upper;
>  
> -	if (lower > upper || upper > max_state)
> +	if (lower > upper || (upper != THERMAL_NO_LIMIT && upper > max_state))
>  		return -EINVAL;
>  
>  	dev =


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ