Skip to content
  1. Jul 27, 2010
    • Matthew Garrett's avatar
      [CPUFREQ] pcc driver should check for pcch method before calling _OSC · 47f8bcf3
      Matthew Garrett authored
      
      
      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: default avatarMatthew Garrett <mjg@redhat.com>
      Cc: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      47f8bcf3
    • Xiaotian Feng's avatar
      [CPUFREQ] fix memory leak in cpufreq_add_dev · 6f90388a
      Xiaotian Feng authored
      
      
      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: default avatarXiaotian Feng <dfeng@redhat.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      6f90388a
    • Andrej Gelenberg's avatar
      [CPUFREQ] revert "[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)" · accd8466
      Andrej Gelenberg authored
      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=1594
      
      
      
      Signed-off-by: default avatarAndrej Gelenberg <andrej.gelenberg@udo.edu>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      accd8466
  2. Jul 26, 2010
  3. Jul 25, 2010
  4. Jul 24, 2010
  5. Jul 23, 2010
  6. Jul 22, 2010