linux-toradex.git/drivers/cpufreq, branch v2.6.26.3

cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already

2008-08-01T19:43:12+00:00

commit a1531acd43310a7e4571d52e8846640667f4c74b upstream

Ingo Molnar provided a fix to not call _PPC at processor driver
initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
commit e4233dec749a3519069d9390561b5636a75c7579)

But it can still happen that _PPC is called at processor driver
initialization time.

This patch should make sure that this is not possible anymore.

Signed-off-by: Thomas Renninger 
Cc: Andi Kleen 
Cc: Len Brown 
Cc: Dave Jones 
Cc: Ingo Molnar 
Cc: Venkatesh Pallipadi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq

2008-06-09T18:27:55+00:00

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
  [CPUFREQ] Fix format string bug.

[CPUFREQ] Fix format string bug.

2008-06-09T17:24:55+00:00

Format string bug.  Not exploitable, as this is only writable by root,
but worth fixing all the same.

Spotted-by: Ilja van Sprundel 
Signed-off-by: Dave Jones

cpufreq: fix null object access on Transmeta CPU

2008-06-06T18:29:11+00:00

If cpu specific cpufreq driver(i.e.  longrun) has "setpolicy" function,
governor object isn't set into cpufreq_policy object at "__cpufreq_set_policy"
function in driver/cpufreq/cpufreq.c .

This causes a null object access at "store_scaling_setspeed" and
"show_scaling_setspeed" function in driver/cpufreq/cpufreq.c when reading or
writing through /sys interface (ex.  cat
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed)

Addresses:
	http://bugzilla.kernel.org/show_bug.cgi?id=10654
	https://bugzilla.redhat.com/show_bug.cgi?id=443354

Signed-off-by: CHIKAMA Masaki 
Cc: Dave Jones 
Cc: Chuck Ebbert 
Acked-by: Dominik Brodowski 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[CPUFREQ] fix double unlock of cpu_policy_rwsem in drivers/cpufreq/cpufreq.c

2008-05-29T16:10:12+00:00

In drivers/cpufreq/cpufreq.c the function cpufreq_add_dev() takes the
error exit 'err_out_unregister' from different places once with the
'cpu_policy_rwsem' lock held, once with the lock released:
|		if (ret)
|			goto err_out_unregister;
|	}
|
|	policy->governor = NULL; /* to assure that the starting sequence is
|				  * run in cpufreq_set_policy */
|
|	/* set default policy */
|	ret = __cpufreq_set_policy(policy, &new_policy);
|	policy->user_policy.policy = policy->policy;
|	policy->user_policy.governor = policy->governor;
|
|	unlock_policy_rwsem_write(cpu);
|
|	if (ret) {
|		dprintk("setting policy failed\n");
|		goto err_out_unregister;
|	}

This leads to the following error message in case of a failing
__cpufreq_set_policy() call:
=====================================
[ BUG: bad unlock balance detected! ]
-------------------------------------
swapper/1 is trying to release lock (&per_cpu(cpu_policy_rwsem, cpu)) at:
[] unlock_policy_rwsem_write+0x30/0x40
but there are no more locks to release!

other info that might help us debug this:
1 lock held by swapper/1:
 #0:  (sysdev_drivers_lock){--..}, at: [] sysdev_driver_register+0x74/0x130

stack backtrace:
[] (dump_stack+0x0/0x14) from [] (print_unlock_inbalance_bug+0xc8/0x104)
[] (print_unlock_inbalance_bug+0x0/0x104) from [] (lock_release_non_nested+0xc4/0x19c)
 r6:00000028 r5:c3c1ab80 r4:c01b4564
[] (lock_release_non_nested+0x0/0x19c) from [] (lock_release+0x15c/0x18c)
 r8:60000013 r7:00000001 r6:c01b4564 r5:c0541bb4 r4:c3c1ab80
[] (lock_release+0x0/0x18c) from [] (up_write+0x24/0x30)
 r8:c0541b80 r7:00000000 r6:ffffffea r5:c3c34828 r4:c0541b8c
[] (up_write+0x0/0x30) from [] (unlock_policy_rwsem_write+0x30/0x40)
 r4:c3c34884
[] (unlock_policy_rwsem_write+0x0/0x40) from [] (cpufreq_add_dev+0x324/0x398)
[] (cpufreq_add_dev+0x0/0x398) from [] (sysdev_driver_register+0xc0/0x130)
[] (sysdev_driver_register+0x0/0x130) from [] (cpufreq_register_driver+0xbc/0x174)

Signed-off-by: Lothar Waßmann 
Signed-off-by: Dave Jones

[CPUFREQ] clarify license of freq_table.c

2008-05-22T20:38:03+00:00

Signed-off-by: Dominik Brodowski 
Signed-off-by: Dave Jones

[CPUFREQ] state info wrong after resume

2008-04-28T20:27:08+00:00

Sometimes old_index != stat->last_index, see cpufreq_update_policy, bios can
change cpu setting in resume.  In my test, after resume cpu is in lowest
speed, but the stat info shows cpu is in full speed.  This patch makes the
stat info correct after a resume.

Signed-off-by: Shaohua Li 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Jones

[CPUFREQ] allow use of the powersave governor as the default one

2008-04-28T20:27:08+00:00

Allow use of the powersave cpufreq governor as the default one for EMBEDDED
configs.

Signed-off-by: Alessandro Guido 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Jones

[CPUFREQ] expose cpufreq coordination requirements regardless of coordination mechanism

2008-04-28T20:27:08+00:00

Currently, affected_cpus shows which CPUs need to have their frequency
coordinated in software.  When hardware coordination is in use, the contents
of this file appear the same as when no coordination is required.  This can
lead to some confusion among user-space programs, for example, that do not
know that extra coordination is required to force a CPU core to a particular
speed to control power consumption.

To fix this, create a "related_cpus" attribute that always displays the
coordination map regardless of whatever coordination strategy the cpufreq
driver uses (sw or hw).  If the cpufreq driver does not provide a value, fall
back to policy->cpus.

Signed-off-by: Darrick J. Wong 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Jones

[CPUFREQ] fix show_trans_table

2008-04-28T19:05:44+00:00

Fix show_trans_table when it overflows PAGE_SIZE.

* Not all snprintf calls were protected against being passed a negative
length.
* When show_trans_table overflows, len might be > PAGE_SIZE. In that case,
returns PAGE_SIZE.

Signed-off-by: Cesar Eduardo Barros 
Signed-off-by: Dave Jones