1. 27 7月, 2010 3 次提交
    • M
      [CPUFREQ] pcc driver should check for pcch method before calling _OSC · 47f8bcf3
      Matthew Garrett 提交于
      The pcc specification documents an _OSC method that's incompatible with the
      one defined as part of the ACPI spec. This shouldn't be a problem as both
      are supposed to be guarded with a UUID. Unfortunately approximately nobody
      (including HP, who wrote this spec) properly check the UUID on entry to the
      _OSC call. Right now this could result in surprising behaviour if the pcc
      driver performs an _OSC call on a machine that doesn't implement the pcc
      specification. Check whether the PCCH method exists first in order to reduce
      this probability.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Cc: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      47f8bcf3
    • X
      [CPUFREQ] fix memory leak in cpufreq_add_dev · 6f90388a
      Xiaotian Feng 提交于
      We didn't free policy->related_cpus in error path err_unlock_policy.
      This is catched by following kmemleak report:
      
      unreferenced object 0xffff88022a0b96d0 (size 512):
        comm "modprobe", pid 886, jiffies 4294689177 (age 780.694s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff8111ebe5>] create_object+0x186/0x281
          [<ffffffff814fad4f>] kmemleak_alloc+0x60/0xa7
          [<ffffffff8111127a>] kmem_cache_alloc_node_notrace+0x120/0x142
          [<ffffffff81262e4f>] alloc_cpumask_var_node+0x2c/0xd7
          [<ffffffff81262f0b>] alloc_cpumask_var+0x11/0x13
          [<ffffffff81262f1c>] zalloc_cpumask_var+0xf/0x11
          [<ffffffff8140fac0>] cpufreq_add_dev+0x11f/0x547
          [<ffffffff81334bda>] sysdev_driver_register+0xc2/0x11d
          [<ffffffff8140e334>] cpufreq_register_driver+0xcb/0x1b8
          [<ffffffffa032e040>] 0xffffffffa032e040
          [<ffffffff810021ba>] do_one_initcall+0x5e/0x15c
          [<ffffffff81087f94>] sys_init_module+0xa6/0x1e6
          [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b
          [<ffffffffffffffff>] 0xffffffffffffffff
      Signed-off-by: NXiaotian Feng <dfeng@redhat.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      6f90388a
    • A
      [CPUFREQ] revert "[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)" · accd8466
      Andrej Gelenberg 提交于
      395913d0 ("[CPUFREQ] remove rwsem lock
      from CPUFREQ_GOV_STOP call (second call site)") is not needed, because
      there is no rwsem lock in cpufreq_ondemand and cpufreq_conservative
      anymore.  Lock should not be released until the work done.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=1594Signed-off-by: NAndrej Gelenberg <andrej.gelenberg@udo.edu>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      accd8466
  2. 26 7月, 2010 4 次提交
  3. 25 7月, 2010 2 次提交
  4. 24 7月, 2010 3 次提交
  5. 23 7月, 2010 26 次提交
  6. 22 7月, 2010 2 次提交