Eric Lee / smarc-fsl-linux-kernel

30 Oct, 2013

1 commit

11 Oct, 2013

1 commit

  • e83dda062   ACPI: improve acpi_extract_package() utility ... Browse Code »

    The current version requires one to know the size of the package
    a priori; this is almost impossible if the package is composed of
    strings of variable length. This change allows the utility to
    allocate a buffer of the proper size if asked.

    Signed-off-by: Al Stone
    Signed-off-by: Rafael J. Wysocki

    Al Stone
     

15 Jul, 2013

3 commits

22 Nov, 2012

1 commit

  • fbfddae69   ACPI: Add acpi_handle_<level>() interfaces ... Browse Code »

    This patch introduces acpi_handle_(), where is
    a kernel message level such as err/warn/info, to support improved
    logging messages for ACPI, esp. hot-plug operations.
    acpi_handle_() appends "ACPI" prefix and ACPI object path
    to the messages. This improves diagnosis of hotplug operations
    since an error message in a log file identifies an object that
    caused an issue. This interface acquires the global namespace
    mutex to obtain an object path. In interrupt context, it shows
    the object path as .

    acpi_handle_() takes acpi_handle as an argument, which is
    passed to ACPI hotplug notify handlers from the ACPICA. Therefore,
    it is always available unlike other kernel objects, such as device.

    For example:
    acpi_handle_err(handle, "Device don't exist, dropping EJECT\n");
    logs an error message like this at KERN_ERR.
    ACPI: \_SB_.SCK4.CPU4: Device don't exist, dropping EJECT

    ACPI hot-plug drivers can use acpi_handle_() when they need
    to identify a target ACPI object path in their messages, such as
    error cases. The usage model is similar to dev_().
    acpi_handle_() can be used when a device is not created or
    is invalid during hot-plug operations. ACPI object path is also
    consistent on the platform, unlike device name that gets incremented
    over hotplug operations.

    ACPI drivers should use dev_() when a device object is valid.
    Device name provides more user friendly information, and avoids
    acquiring the global ACPI namespace mutex. ACPI drivers also
    continue to use pr_() when they do not need to specify device
    information, such as boot-up messages.

    Note: ACPI_[WARNING|INFO|ERROR]() are intended for the ACPICA and
    are not associated with the kernel message level.

    Signed-off-by: Toshi Kani
    Tested-by: Vijay Mohan Pandarathil
    Signed-off-by: Rafael J. Wysocki

    Toshi Kani
     

21 Sep, 2012

1 commit

  • 8ede06aba   ACPI: Use ACPICA native way to decode the PLD buffer ... Browse Code »

    This patch is on top of the ACPICA 20120816 release, which implemented
    a native way to decode PLD buffer, so use it instead of leting upper
    level users do the decoding.

    v2: Modify the check for PLD buffer length to reject buffers whose
    length < 16

    Signed-off-by: Feng Tang
    Signed-off-by: Bob Moore
    Signed-off-by: Len Brown

    Feng Tang
     

04 Jun, 2012

1 commit

  • 275c58d77   ACPI: Add an interface to evaluate _OST ... Browse Code »

    Added acpi_evaluate_hotplug_opt(). All ACPI hotplug handlers must call
    this function when evaluating _OST for hotplug operations. If the
    platform does not support _OST, this function returns AE_NOT_FOUND and
    has no effect on the platform.

    ACPI_HOTPLUG_OST is defined when all relevant ACPI hotplug operations,
    such as CPU, memory and container hotplug, are enabled. This assures
    consistent behavior among the hotplug operations with regarding the
    _OST support. When ACPI_HOTPLUG_OST is not defined, this function is
    a no-op.

    ACPI PCI hotplug is not enhanced to support _OST at this time since it
    is a legacy method being replaced by PCIe native hotplug. _OST support
    for ACPI PCI hotplug may be added in future if necessary.

    Some platforms may require the OS to support _OST in order to support
    ACPI hotplug operations. For example, if a platform has the management
    console where user can request a hotplug operation from, this _OST
    support would be required for the management console to show the result
    of the hotplug request to user.

    Added macro definitions of _OST source events and status codes.
    Also renamed OSC_SB_CPUHP_OST_SUPPORT to OSC_SB_HOTPLUG_OST_SUPPORT
    since this _OSC bit is not specific to CPU hotplug. This bit is
    defined in Table 6-147 of ACPI 5.0 as follows.

    Bits: 3
    Field Name: Insertion / Ejection _OST Processing Support
    Definition: This bit is set if OSPM will evaluate the _OST
    object defined under a device when processing
    insertion and ejection source event codes.

    Signed-off-by: Toshi Kani
    Signed-off-by: Len Brown

    Toshi Kani
     

12 May, 2012

1 commit

  • 38ac0f1b9   ACPI: Add _PLD support ... Browse Code »

    Add a simple helper function to allow drivers to obtain the physical
    device location data.

    Acked-by: Len Brown
    Signed-off-by: Matthew Garrett
    Signed-off-by: Lan Tianyu
    Signed-off-by: Greg Kroah-Hartman

    Matthew Garrett
     

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …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
     

15 Mar, 2010

1 commit

16 Feb, 2010

1 commit

28 Jan, 2010

1 commit

29 Aug, 2009

1 commit

  • a192a9580   ACPI: Move definition of PREFIX from acpi_bus.h to internal..h ... Browse Code »

    Linux/ACPI core files using internal.h all PREFIX "ACPI: ",
    however, not all ACPI drivers use/want it -- and they
    should not have to #undef PREFIX to define their own.

    Add GPL commment to internal.h while we are there.

    This does not change any actual console output,
    asside from a whitespace fix.

    Signed-off-by: Len Brown

    Len Brown
     

27 Nov, 2008

1 commit

  • 40599072d   ACPI: scheduling in atomic via acpi_evaluate_integer () ... Browse Code »

    Now I know why I had strange "scheduling in atomic" problems:
    acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC
    : GFP_KERNEL)... which is (of course) broken.

    There's no way to reliably tell if we need GFP_ATOMIC or not from
    code, this one for example fails to detect spinlocks held.

    Fortunately, allocation seems small enough to be done on stack.

    Signed-off-by: Pavel Machek
    Acked-by: Bob Moore
    Signed-off-by: Len Brown

    Pavel Machek
     

11 Oct, 2008

1 commit

  • 27663c585   ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit kernels ... Browse Code »

    As of version 2.0, ACPI can return 64-bit integers. The current
    acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
    Change the argument to take a pointer to an acpi_integer so we support
    64-bit integers on all platforms.

    lenb: replaced use of "acpi_integer" with "unsigned long long"
    lenb: fixed bug in acpi_thermal_trips_update()

    Signed-off-by: Matthew Wilcox
    Signed-off-by: Len Brown

    Matthew Wilcox
     

23 Apr, 2008

1 commit

  • cd0b22482   ACPICA: Fixes for external Reference Objects ... Browse Code »

    All Reference Objects returned via the AcpiEvaluteObject interface
    are now marked as type "REFERENCE" instead of "ANY". The type ANY
    is now reservered for NULL objects - either NULL package elements
    or unresolved named references.

    Signed-off-by: Bob Moore
    Signed-off-by: Alexey Starikovskiy
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Bob Moore
     

12 Mar, 2008

1 commit

16 Feb, 2008

1 commit

  • 4fd7f5188   ACPI: sparse fix, replace macro with static function ... Browse Code »

    replace acpi_util_eval_error macro with static function.

    Avoid these sparse warnings due to using buffer within the macro.
    drivers/acpi/utils.c:273:3: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:259:21: originally declared here
    drivers/acpi/utils.c:279:3: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:259:21: originally declared here
    drivers/acpi/utils.c:368:3: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:348:21: originally declared here
    drivers/acpi/utils.c:375:3: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:348:21: originally declared here
    drivers/acpi/utils.c:382:3: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:348:21: originally declared here
    drivers/acpi/utils.c:402:4: warning: symbol 'buffer' shadows an earlier one
    drivers/acpi/utils.c:348:21: originally declared here

    Signed-off-by: Harvey Harrison
    Signed-off-by: Len Brown

    Harvey Harrison
     

13 Feb, 2007

1 commit

21 Dec, 2006

1 commit

14 Oct, 2006

1 commit

17 Aug, 2006

1 commit

  • d68909f4c   ACPI: avoid irqrouter_resume might_sleep oops on resume from S4 ... Browse Code »

    __might_sleep+0x8e/0x93
    acpi_os_wait_semaphore+0x50/0xa3
    acpi_ut_acquire_mutex+0x28/0x6a
    acpi_ns_get_node+0x46/0x88
    acpi_ns_evaluate+0x2d/0xfc
    acpi_rs_set_srs_method_data+0xc5/0xe1
    acpi_set_current_resources+0x31/0x3f
    acpi_pci_link_set+0xfc/0x1a5
    irqrouter_resume+0x48/0x5f

    and

    __might_sleep+0x8e/0x93
    kmem_cache_alloc+0x2a/0x8f
    acpi_evaluate_integer+0x32/0x96
    acpi_bus_get_status+0x30/0x84
    acpi_pci_link_set+0x12a/0x1a5
    irqrouter_resume+0x48/0x5f

    http://bugzilla.kernel.org/show_bug.cgi?id=6810

    Signed-off-by: Len Brown

    Len Brown
     

30 Jun, 2006

1 commit

27 Jun, 2006

4 commits

14 May, 2006

1 commit

05 Aug, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds