linux-kernel - Re: [PATCH] Thermal: Don't resolve THERMAL_NO_LIMIT to max

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]

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/