05 Sep, 2013

1 commit

  • Pull PTR_RET() removal patches from Rusty Russell:
    "PTR_RET() is a weird name, and led to some confusing usage. We ended
    up with PTR_ERR_OR_ZERO(), and replacing or fixing all the usages.

    This has been sitting in linux-next for a whole cycle"

    [ There are still some PTR_RET users scattered about, with some of them
    possibly being new, but most of them existing in Rusty's tree too. We
    have that

    #define PTR_RET(p) PTR_ERR_OR_ZERO(p)

    thing in , so they continue to work for now - Linus ]

    * tag 'PTR_RET-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
    GFS2: Replace PTR_RET with PTR_ERR_OR_ZERO
    Btrfs: volume: Replace PTR_RET with PTR_ERR_OR_ZERO
    drm/cma: Replace PTR_RET with PTR_ERR_OR_ZERO
    sh_veu: Replace PTR_RET with PTR_ERR_OR_ZERO
    dma-buf: Replace PTR_RET with PTR_ERR_OR_ZERO
    drivers/rtc: Replace PTR_RET with PTR_ERR_OR_ZERO
    mm/oom_kill: remove weird use of ERR_PTR()/PTR_ERR().
    staging/zcache: don't use PTR_RET().
    remoteproc: don't use PTR_RET().
    pinctrl: don't use PTR_RET().
    acpi: Replace weird use of PTR_RET.
    s390: Replace weird use of PTR_RET.
    PTR_RET is now PTR_ERR_OR_ZERO(): Replace most.
    PTR_RET is now PTR_ERR_OR_ZERO

    Linus Torvalds
     

15 Jul, 2013

2 commits

  • It is quite some time that this one has been deprecated.
    Get rid of it.

    Should some really important user be overseen, it may be reverted and
    the userspace program worked on first, but it is time to do something
    to get rid of this old stuff...

    Signed-off-by: Thomas Renninger
    Acked-by: Matthew Garrett
    Acked-by: Henrique de Moraes Holschuh
    Signed-off-by: Rafael J. Wysocki

    Thomas Renninger
     
  • This functions is really weird. It sets rc to -ENOMEM, then overrides
    it. It was converted to PTR_RET in a1458187 when it should have
    simply been rewritten.

    This version makes it more explicit, with a single IS_ERR() test.

    Cc: Alexandru Gheorghiu
    Signed-off-by: Rusty Russell
    Acked-by: Rafael J. Wysocki

    Rusty Russell
     

25 Mar, 2013

1 commit


26 Jan, 2013

1 commit

  • The second argument of ACPI driver .remove() operation is only used
    by the ACPI processor driver and the value passed to that driver
    through it is always available from the given struct acpi_device
    object's removal_type field. For this reason, the second ACPI driver
    .remove() argument is in fact useless, so drop it.

    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Jiang Liu
    Acked-by: Toshi Kani
    Acked-by: Yinghai Lu

    Rafael J. Wysocki
     

15 Nov, 2012

1 commit


26 Jul, 2012

1 commit


14 Jul, 2012

1 commit

  • In an effort to be fair to bound processes,
    acpi_pad periodically moves its forced-idle threads.

    The default interval for moving the threads is 10 seconds.
    Measurements show that reducing this to 1 second has no
    power or performance impact, so reduce default to 1 second.

    Signed-off-by: Len Brown

    Len Brown
     

30 Jun, 2012

1 commit

  • The acpi_pad driver can get stuck in destroy_power_saving_task()
    waiting for kthread_stop() to stop a power_saving thread. The problem
    is that the isolated_cpus_lock mutex is owned when
    destroy_power_saving_task() calls kthread_stop(), which waits for a
    power_saving thread to end, and the power_saving thread tries to
    acquire the isolated_cpus_lock when it calls round_robin_cpu(). This
    patch fixes the issue by making round_robin_cpu() use its own mutex.

    https://bugzilla.kernel.org/show_bug.cgi?id=42981

    Cc: stable@vger.kernel.org
    Signed-off-by: Stuart Hayes
    Signed-off-by: Len Brown

    Stuart Hayes
     

14 Jun, 2012

1 commit


23 Mar, 2011

2 commits


22 Oct, 2010

1 commit


30 Sep, 2010

1 commit


18 Sep, 2010

1 commit


27 Jul, 2010

1 commit

  • Now that all arches have been converted over to use generic time via
    clocksources or arch_gettimeoffset(), we can remove the GENERIC_TIME
    config option and simplify the generic code.

    Signed-off-by: John Stultz
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    John Stultz
     

04 Jun, 2010

1 commit


29 May, 2010

2 commits

  • * 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6:
    intel_idle: native hardware cpuidle driver for latest Intel processors
    ACPI: acpi_idle: touch TS_POLLING only in the non-MWAIT case
    acpi_pad: uses MONITOR/MWAIT, so it doesn't need to clear TS_POLLING
    sched: clarify commment for TS_POLLING
    ACPI: allow a native cpuidle driver to displace ACPI
    cpuidle: make cpuidle_curr_driver static
    cpuidle: add cpuidle_unregister_driver() error check
    cpuidle: fail to register if !CONFIG_CPU_IDLE

    Linus Torvalds
     
  • acpi pad driver kind of aggressively marks TSC as unstable at init
    time, on mwait capable and non X86_FEATURE_NONSTOP_TSC systems. This is
    irrespective of whether pad driver is ever going to be used on the
    system or deep C-states are supported/used. This will affect every user
    who just happens to compile in (or get a kernel version which
    compiles in) acpi pad driver.

    Move mark_tsc_unstable() out of init to the actual idle invocation path
    of the pad driver.

    There is also another bug/missing_feature in the code that it does not
    support 'always running apic timer' and switches to broadcast mode
    unconditionally. Shaohua, can you take a look at that please.

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Len Brown

    Venkatesh Pallipadi
     

28 May, 2010

1 commit


06 May, 2010

1 commit

  • cpi_device_class can only be 19 characters and a NULL terminator.

    With the current name we get a buffer overflow in acpi_pad_add()
    strcpy(acpi_device_class(device), ACPI_PROCESSOR_AGGREGATOR_CLASS);

    [akpm@linux-foundation.org: call it acpi_pad, per Shaohua Li]
    Signed-off-by: Dan Carpenter
    Cc: walter harms
    Acked-by: Shaohua Li
    Cc: Len Brown
    Acked-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Dan Carpenter
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

20 Jan, 2010

1 commit


31 Dec, 2009

1 commit

  • There are some fixes listed below:
    1. When met a bogus BIOS, the return value of cpu number maybe is
    a negative value so that acpi_pad_pur get an unexpected result.
    2. the return value of function acpi_pad_idle_cpus is useless.
    3. enhance the process of create_power_saving_task/destroy_power_saving_task
    4. Add more error checks when evaluating _PUR object.
    5. one typo fix

    Signed-off-by: Chen Gong
    Acked-by: Shaohua Li
    Signed-off-by: Len Brown

    Chen Gong
     

16 Dec, 2009

1 commit

  • drivers/acpi/acpi_pad.c: In function 'power_saving_thread':
    drivers/acpi/acpi_pad.c:103: warning: 'preferred_cpu' may be used uninitialized in this function

    Cc: Shaohua Li
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Andrew Morton
     

01 Aug, 2009

1 commit

  • ACPI 4.0 created the logical "processor aggregator device" as
    a mechinism for platforms to ask the OS to force otherwise busy
    processors to enter (power saving) idle.

    The intent is to lower power consumption to ride-out
    transient electrical and thermal emergencies,
    rather than powering off the server.

    On platforms that can save more power/performance via P-states,
    the platform will first exhaust P-states before forcing idle.
    However, the relative benefit of P-states vs. idle states
    is platform dependent, and thus this driver need not know
    or care about it.

    This driver does not use the kernel's CPU hot-plug mechanism
    because after the transient emergency is over, the system must
    be returned to its normal state, and hotplug would permanently
    break both cpusets and binding.

    So to force idle, the driver creates a power saving thread.
    The scheduler will migrate the thread to the preferred CPU.
    The thread has max priority and has SCHED_RR policy,
    so it can occupy one CPU. To save power, the thread will
    invoke the deep C-state entry instructions.

    To avoid starvation, the thread will sleep 5% of the time
    time for every second (current RT scheduler has threshold
    to avoid starvation, but if other CPUs are idle,
    the CPU can borrow CPU timer from other,
    which makes the mechanism not work here)

    Vaidyanathan Srinivasan has proposed scheduler enhancements
    to allow injecting idle time into the system. This driver doesn't
    depend on those enhancements, but could cut over to them
    when they are available.

    Peter Z. does not favor upstreaming this driver until
    the those scheduler enhancements are in place. However,
    we favor upstreaming this driver now because it is useful
    now, and can be enhanced over time.

    Signed-off-by: Shaohua Li
    NACKed-by: Peter Zijlstra
    Cc: Vaidyanathan Srinivasan
    Signed-off-by: Len Brown

    Shaohua Li