1. 02 9月, 2009 10 次提交
    • M
      [CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site) · 395913d0
      Mathieu Desnoyers 提交于
      remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)
      
      commit	42a06f21
      
      Missed a call site for CPUFREQ_GOV_STOP to remove the rwlock taken around the
      teardown. To make a long story short, the rwlock write-lock causes a circular
      dependency with cancel_delayed_work_sync(), because the timer handler takes the
      read lock.
      
      Note that all callers to __cpufreq_set_policy are taking the rwsem. All sysfs
      callers (writers) hold the write rwsem at the earliest sysfs calling stage.
      
      However, the rwlock write-lock is not needed upon governor stop.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      CC: rjw@sisk.pl
      CC: mingo@elte.hu
      CC: Shaohua Li <shaohua.li@intel.com>
      CC: Pekka Enberg <penberg@cs.helsinki.fi>
      CC: Dave Young <hidave.darkstar@gmail.com>
      CC: "Rafael J. Wysocki" <rjw@sisk.pl>
      CC: Rusty Russell <rusty@rustcorp.com.au>
      CC: trenn@suse.de
      CC: sven.wegener@stealer.net
      CC: cpufreq@vger.kernel.org
      Signed-off-by: NDave Jones <davej@redhat.com>
      395913d0
    • T
      [CPUFREQ] ondemand - Use global sysfs dir for tuning settings · 0e625ac1
      Thomas Renninger 提交于
      Ondemand has only global variables for userspace tunings via sysfs.
      But they were exposed per CPU which wrongly implies to the user that
      his settings are applied per cpu. Also locking sysfs against concurrent
      access won't be necessary anymore after deprecation time.
      
      This means the ondemand config dir is moved:
      /sys/devices/system/cpu/cpu*/cpufreq/ondemand ->
           /sys/devices/system/cpu/cpufreq/ondemand
      
      The old files will still exist, but reading or writing to them will
      result in one (printk_once) deprecation msg to syslog per file.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      0e625ac1
    • T
      [CPUFREQ] Introduce global, not per core: /sys/devices/system/cpu/cpufreq · 8aa84ad8
      Thomas Renninger 提交于
      Currently everything in the cpufreq layer is per core based.
      This does not reflect reality, for example ondemand on conservative
      governors have global sysfs variables.
      
      Introduce a global cpufreq directory and add the kobject to the governor
      struct, so that governors can easily access it.
      The directory is initialized in the cpufreq_core_init initcall and thus will
      always be created if cpufreq is compiled in, even if no cpufreq driver is
      active later.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      8aa84ad8
    • T
      [CPUFREQ] Bail out of cpufreq_add_dev if the link for a managed CPU got created · 4bfa042c
      Thomas Renninger 提交于
      Doing:
      echo 0 >cpu1/online
      echo 1 >cpu1/online
      
      on a managed CPU will result in:
      Jul 22 15:15:37 linux kernel: [   80.013864] WARNING: at fs/sysfs/dir.c:487 sysfs_add_one+0xcf/0xe6()
      Jul 22 15:15:37 linux kernel: [   80.013866] Hardware name: To Be Filled By O.E.M.
      Jul 22 15:15:37 linux kernel: [   80.013868] sysfs: cannot create duplicate filename '/devices/system/cpu/cpu1/cpufreq'
      Jul 22 15:15:37 linux kernel: [   80.013870] Modules linked in: powernow_k8
      Jul 22 15:15:37 linux kernel: [   80.013874] Pid: 5750, comm: bash Not tainted 2.6.31-rc2 #40
      Jul 22 15:15:37 linux kernel: [   80.013876] Call Trace:
      Jul 22 15:15:37 linux kernel: [   80.013879]  [<ffffffff8112ebda>] ? sysfs_add_one+0xcf/0xe6
      Jul 22 15:15:37 linux kernel: [   80.013884]  [<ffffffff81041926>] warn_slowpath_common+0x77/0xa4
      Jul 22 15:15:37 linux kernel: [   80.013888]  [<ffffffff810419a0>] warn_slowpath_fmt+0x3c/0x3e
      Jul 22 15:15:37 linux kernel: [   80.013891]  [<ffffffff8112ebda>] sysfs_add_one+0xcf/0xe6
      Jul 22 15:15:37 linux kernel: [   80.013894]  [<ffffffff8112f213>] create_dir+0x58/0x87
      Jul 22 15:15:37 linux kernel: [   80.013898]  [<ffffffff8112f27a>] sysfs_create_dir+0x38/0x4f
      Jul 22 15:15:37 linux kernel: [   80.013902]  [<ffffffff811ffb8a>] kobject_add_internal+0x11f/0x1de
      Jul 22 15:15:37 linux kernel: [   80.013905]  [<ffffffff811ffd21>] kobject_add_varg+0x41/0x4e
      Jul 22 15:15:37 linux kernel: [   80.013908]  [<ffffffff811ffd7a>] kobject_init_and_add+0x4c/0x57
      Jul 22 15:15:37 linux kernel: [   80.013913]  [<ffffffff810667bc>] ? mark_lock+0x22/0x228
      Jul 22 15:15:37 linux kernel: [   80.013918]  [<ffffffff813e8a3b>] cpufreq_add_dev_interface+0x40/0x1e4
      ...
      
      This bug slipped in by git commit:
      150b06f7f223cfd0f808737a5243cceca8ea47fa
      
      When splitting up cpufreq_add_dev, the whole cpufreq_add_dev function
      is not left anymore, only cpufreq_add_dev_policy.
      This patch should reconstruct the identical functionality again as it
      was before the split.
      
      CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      4bfa042c
    • D
      ecf7e461
    • D
      909a694e
    • D
      19d6f7ec
    • D
      059019a3
    • D
      54e6fe16
    • D
      [CPUFREQ] Re-enable cpufreq suspend and resume code · ce6c3997
      Dominik Brodowski 提交于
      Commit 4bc5d341 is broken and causes regressions:
      
      (1) cpufreq_driver->resume() and ->suspend() were only called on
      __powerpc__, but you could set them on all architectures. In fact,
      ->resume() was defined and used before the PPC-related commit
      42d4dc3f complained about in 4bc5d341.
      
      (2) Therfore, the resume functions in acpi_cpufreq and speedstep-smi
      would never be called.
      
      (3) This means speedstep-smi would be unusuable after suspend or resume.
      
      The _real_ problem was calling cpufreq_driver->get() with interrupts
      off, but it re-enabling interrupts on some platforms. Why is ->get()
      necessary?
      
      Some systems like to change the CPU frequency behind our
      back, especially during BIOS-intensive operations like suspend or
      resume. If such systems also use a CPU frequency-dependant timing loop,
      delays might be off by large factors. Therefore, we need to ascertain
      as soon as possible that the CPU frequency is indeed at the speed we
      think it is. You can do this two ways: either setting it anew, or trying
      to get it. The latter is what was done, the former also has the same IRQ
      issue.
      
      So, let's try something different: defer the checking to after interrupts
      are re-enabled, by calling cpufreq_update_policy() (via schedule_work()).
      Timings may be off until this later stage, so let's watch out for
      resume regressions caused by the deferred handling of frequency changes
      behind the kernel's back.
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: NDave Jones <davej@redhat.com>
      ce6c3997
  2. 05 8月, 2009 4 次提交
    • D
      [CPUFREQ] Make cpufreq suspend code conditional on powerpc. · 4bc5d341
      Dave Jones 提交于
      The suspend code runs with interrupts disabled, and the powerpc workaround we
      do in the cpufreq suspend hook calls the drivers ->get method.
      
      powernow-k8's ->get does an smp_call_function_single
      which needs interrupts enabled
      
      cpufreq's suspend/resume code was added in 42d4dc3f to work around
      a hardware problem on ppc powerbooks.  If we make all this code
      conditional on powerpc, we avoid the issue above.
      Signed-off-by: NDave Jones <davej@redhat.com>
      4bc5d341
    • T
      [CPUFREQ] Fix a kobject reference bug related to managed CPUs · d5194dec
      Thomas Renninger 提交于
      The first offline/online cycle is successful, the second not.
      Doing:
      echo 0 >cpu1/online
      echo 1 >cpu1/online
      echo 0 >cpu1/online
      
      The last command will trigger:
      Jul 22 14:39:50 linux kernel: [  593.210125] ------------[ cut here ]------------
      Jul 22 14:39:50 linux kernel: [  593.210139] WARNING: at lib/kref.c:43 kref_get+0x23/0x2b()
      Jul 22 14:39:50 linux kernel: [  593.210144] Hardware name: To Be Filled By O.E.M.
      Jul 22 14:39:50 linux kernel: [  593.210148] Modules linked in: powernow_k8
      Jul 22 14:39:50 linux kernel: [  593.210158] Pid: 378, comm: kondemand/2 Tainted: G        W  2.6.31-rc2 #38
      Jul 22 14:39:50 linux kernel: [  593.210163] Call Trace:
      Jul 22 14:39:50 linux kernel: [  593.210171]  [<ffffffff812008e8>] ? kref_get+0x23/0x2b
      Jul 22 14:39:50 linux kernel: [  593.210181]  [<ffffffff81041926>] warn_slowpath_common+0x77/0xa4
      Jul 22 14:39:50 linux kernel: [  593.210190]  [<ffffffff81041962>] warn_slowpath_null+0xf/0x11
      Jul 22 14:39:50 linux kernel: [  593.210198]  [<ffffffff812008e8>] kref_get+0x23/0x2b
      Jul 22 14:39:50 linux kernel: [  593.210206]  [<ffffffff811ffa19>] kobject_get+0x1a/0x22
      Jul 22 14:39:50 linux kernel: [  593.210214]  [<ffffffff813e815d>] cpufreq_cpu_get+0x8a/0xcb
      Jul 22 14:39:50 linux kernel: [  593.210222]  [<ffffffff813e87d1>] __cpufreq_driver_getavg+0x1d/0x67
      Jul 22 14:39:50 linux kernel: [  593.210231]  [<ffffffff813ea18f>] do_dbs_timer+0x158/0x27f
      Jul 22 14:39:50 linux kernel: [  593.210240]  [<ffffffff810529ea>] worker_thread+0x200/0x313
      ...
      
      The output continues on every do_dbs_timer ondemand freq checking poll.
      This regression was introduced by git commit:
      3f4a782b
      
      The policy is released when the cpufreq device is removed in:
      __cpufreq_remove_dev():
      	/* if this isn't the CPU which is the parent of the kobj, we
      	 * only need to unlink, put and exit
      	 */
      
      Not creating the symlink is not sever at all.
      As long as:
      sysfs_remove_link(&sys_dev->kobj, "cpufreq");
      handles it gracefully that the symlink did not exist.
      Possibly no error should be returned at all, because ondemand
      governor would still provide the same functionality.
      Userspace in userspace gov case might be confused if the link
      is missing.
      
      Resolves http://bugzilla.kernel.org/show_bug.cgi?id=13903
      
      CC: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      d5194dec
    • P
      [CPUFREQ] Do not set policy for offline cpus · 42c74b84
      Prarit Bhargava 提交于
      Suspend/Resume fails on multi socket, multi core systems because the cpufreq
      code erroneously sets the per_cpu policy_cpu value when a logical cpu is
      offline.
      
      This most notably results in missing sysfs files that are used to set the
      cpu frequencies of the various cpus.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      42c74b84
    • P
      [CPUFREQ] Fix NULL pointer dereference regression in conservative governor · 26d204af
      Pallipadi, Venkatesh 提交于
      Commit ee88415c
      introduced this regression when it removed enable bit in cpu_dbs_info_s.
      That added a possibility of dbs_cpufreq_notifier getting called for a
      CPU that is not yet managed by conservative governor. That will happen
      as the transition notifier is set as soon as one CPU switches to
      conservative governor and other CPUs can get a NULL pointer dereference
      without the enable bit check. Add the enable bit back again.
      Reported-by: NLermytte Christophe <Christophe.Lermytte@thomson.net>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      26d204af
  3. 09 7月, 2009 1 次提交
  4. 07 7月, 2009 4 次提交
  5. 24 6月, 2009 1 次提交
    • T
      percpu: clean up percpu variable definitions · 245b2e70
      Tejun Heo 提交于
      Percpu variable definition is about to be updated such that all percpu
      symbols including the static ones must be unique.  Update percpu
      variable definitions accordingly.
      
      * as,cfq: rename ioc_count uniquely
      
      * cpufreq: rename cpu_dbs_info uniquely
      
      * xen: move nesting_count out of xen_evtchn_do_upcall() and rename it
      
      * mm: move ratelimits out of balance_dirty_pages_ratelimited_nr() and
        rename it
      
      * ipv4,6: rename cookie_scratch uniquely
      
      * x86 perf_counter: rename prev_left to pmc_prev_left, irq_entry to
        pmc_irq_entry and nmi_entry to pmc_nmi_entry
      
      * perf_counter: rename disable_count to perf_disable_count
      
      * ftrace: rename test_event_disable to ftrace_test_event_disable
      
      * kmemleak: rename test_pointer to kmemleak_test_pointer
      
      * mce: rename next_interval to mce_next_interval
      
      [ Impact: percpu usage cleanups, no duplicate static percpu var names ]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: linux-mm <linux-mm@kvack.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <srostedt@redhat.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      245b2e70
  6. 15 6月, 2009 2 次提交
  7. 09 6月, 2009 1 次提交
  8. 27 5月, 2009 3 次提交
    • M
      [CPUFREQ] fix timer teardown in ondemand governor · b14893a6
      Mathieu Desnoyers 提交于
      * Rafael J. Wysocki (rjw@sisk.pl) wrote:
      > This message has been generated automatically as a part of a report
      > of regressions introduced between 2.6.28 and 2.6.29.
      >
      > The following bug entry is on the current list of known regressions
      > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
      > be listed and let me know (either way).
      >
      >
      > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
      > Subject		: cpufreq timer teardown problem
      > Submitter	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      > Date		: 2009-04-23 14:00 (24 days old)
      > References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
      > Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      > Patch		: http://patchwork.kernel.org/patch/19754/
      > 		  http://patchwork.kernel.org/patch/19753/
      >
      
      (updated changelog)
      
      cpufreq fix timer teardown in ondemand governor
      
      The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
      use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
      workqueue handler to exit.
      
      The ondemand governor does not seem to be affected because the
      "if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
      immediately without rescheduling the work. The conservative governor in
      2.6.30-rc has the same check as the ondemand governor, which makes things
      usually run smoothly. However, if the governor is quickly stopped and then
      started, this could lead to the following race :
      
      dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
      This is why a synchronized teardown is required.
      
      The following patch applies to, at least, 2.6.28.x, 2.6.29.1, 2.6.30-rc2.
      
      Depends on patch
      cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: gregkh@suse.de
      CC: stable@kernel.org
      CC: cpufreq@vger.kernel.org
      CC: Ingo Molnar <mingo@elte.hu>
      CC: rjw@sisk.pl
      CC: Ben Slusky <sluskyb@paranoiacs.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      b14893a6
    • M
      [CPUFREQ] fix timer teardown in conservative governor · b253d2b2
      Mathieu Desnoyers 提交于
      * Rafael J. Wysocki (rjw@sisk.pl) wrote:
      > This message has been generated automatically as a part of a report
      > of regressions introduced between 2.6.28 and 2.6.29.
      >
      > The following bug entry is on the current list of known regressions
      > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
      > be listed and let me know (either way).
      >
      >
      > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
      > Subject		: cpufreq timer teardown problem
      > Submitter	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      > Date		: 2009-04-23 14:00 (24 days old)
      > References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
      > Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      > Patch		: http://patchwork.kernel.org/patch/19754/
      > 		  http://patchwork.kernel.org/patch/19753/
      >
      
      (re-send with updated changelog)
      
      cpufreq fix timer teardown in conservative governor
      
      The problem is that dbs_timer_exit() uses cancel_delayed_work() when it should
      use cancel_delayed_work_sync(). cancel_delayed_work() does not wait for the
      workqueue handler to exit.
      
      The ondemand governor does not seem to be affected because the
      "if (!dbs_info->enable)" check at the beginning of the workqueue handler returns
      immediately without rescheduling the work. The conservative governor in
      2.6.30-rc has the same check as the ondemand governor, which makes things
      usually run smoothly. However, if the governor is quickly stopped and then
      started, this could lead to the following race :
      
      dbs_enable could be reenabled and multiple do_dbs_timer handlers would run.
      This is why a synchronized teardown is required.
      
      Depends on patch
      cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
      
      The following patch applies to 2.6.30-rc2. Stable kernels have a similar
      issue which should also be fixed, but the code changed between 2.6.29
      and 2.6.30, so this patch only applies to 2.6.30-rc.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: gregkh@suse.de
      CC: stable@kernel.org
      CC: cpufreq@vger.kernel.org
      CC: Ingo Molnar <mingo@elte.hu>
      CC: rjw@sisk.pl
      CC: Ben Slusky <sluskyb@paranoiacs.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      b253d2b2
    • M
      [CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call · 42a06f21
      Mathieu Desnoyers 提交于
      * Rafael J. Wysocki (rjw@sisk.pl) wrote:
      > This message has been generated automatically as a part of a report
      > of regressions introduced between 2.6.28 and 2.6.29.
      >
      > The following bug entry is on the current list of known regressions
      > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
      > be listed and let me know (either way).
      >
      >
      > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
      > Subject		: cpufreq timer teardown problem
      > Submitter	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      > Date		: 2009-04-23 14:00 (24 days old)
      > References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
      > Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      > Patch		: http://patchwork.kernel.org/patch/19754/
      > 		  http://patchwork.kernel.org/patch/19753/
      
      The patches linked above depend on the following patch to remove
      circular locking dependency :
      
      cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
      
      (the following issue was faced when using cancel_delayed_work_sync() in the
      timer teardown (which fixes a race).
      
      * KOSAKI Motohiro (kosaki.motohiro@jp.fujitsu.com) wrote:
      > Hi
      >
      > my box output following warnings.
      > it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
      >
      > A: work -> do_dbs_timer()  -> cpu_policy_rwsem
      > B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
      >
      >
      
      Hrm, I think it must be due to my attempt to fix the timer teardown race
      in ondemand governor mixed with new locking behavior in 2.6.30-rc.
      
      The rwlock seems to be taken around the whole call to
      cpufreq_governor_dbs(), when it should be only taken around accesses to
      the locked data, and especially *not* around the call to
      dbs_timer_exit().
      
      Reverting my fix attempt would put the teardown race back in place
      (replacing the cancel_delayed_work_sync by cancel_delayed_work).
      Instead, a proper fix would imply modifying this critical section :
      
      cpufreq.c: __cpufreq_remove_dev()
      ...
              if (cpufreq_driver->target)
                      __cpufreq_governor(data, CPUFREQ_GOV_STOP);
      
              unlock_policy_rwsem_write(cpu);
      
      To make sure the __cpufreq_governor() callback is not called with rwsem
      held. This would allow execution of cancel_delayed_work_sync() without
      being nested within the rwsem.
      
      Applies on top of the 2.6.30-rc5 tree.
      
      Required to remove circular dep in teardown of both conservative and
      ondemande governors so they can use cancel_delayed_work_sync().
      CPUFREQ_GOV_STOP does not modify the policy, therefore this locking seemed
      unneeded.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Greg KH <greg@kroah.com>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: "Rafael J. Wysocki" <rjw@sisk.pl>
      CC: Ben Slusky <sluskyb@paranoiacs.org>
      CC: Chris Wright <chrisw@sous-sol.org>
      CC: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      42a06f21
  9. 10 3月, 2009 1 次提交
    • D
      Revert "[CPUFREQ] Disable sysfs ui for p4-clockmod." · 129f8ae9
      Dave Jones 提交于
      This reverts commit e088e4c9.
      
      Removing the sysfs interface for p4-clockmod was flagged as a
      regression in bug 12826.
      
      Course of action:
       - Find out the remaining causes of overheating, and fix them
         if possible. ACPI should be doing the right thing automatically.
         If it isn't, we need to fix that.
       - mark p4-clockmod ui as deprecated
       - try again with the removal in six months.
      
      It's not really feasible to printk about the deprecation, because
      it needs to happen at all the sysfs entry points, which means adding
      a lot of strcmp("p4-clockmod".. calls to the core, which.. bleuch.
      Signed-off-by: NDave Jones <davej@redhat.com>
      129f8ae9
  10. 25 2月, 2009 13 次提交
新手
引导
客服 返回
顶部