Eric Lee / smarc-fsl-linux-kernel

08 Jul, 2015

1 commit

21 Sep, 2014

1 commit

  • 8ab17fc92   ACPI / hotplug: Generate online uevents for ACPI containers ... Browse Code »

    Commit 46394fd01 (ACPI / hotplug: Move container-specific code out of
    the core) removed the generation of "online" uevents for containers,
    because "add" uevents are now generated for them automatically when
    container system devices are registered. However, there are user
    space tools that need to be notified when the container and all of
    its children have been enumerated, which doesn't happen any more.

    For this reason, add a mechanism allowing "online" uevents to be
    generated for ACPI containers after enumerating the container along
    with all of its children.

    Fixes: 46394fd01 (ACPI / hotplug: Move container-specific code out of the core)
    Reported-and-tested-by: Yasuaki Ishimatsu
    Cc: 3.14+ # 3.14+
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

30 May, 2014

1 commit

  • a1ec65721   ACPI / scan: always register container scan handler ... Browse Code »

    Prevent platform devices from being created for ACPI containers
    if CONFIG_ACPI_CONTAINER is unset by compiling out the container
    scan handler's callbacks only in that case and still compiling
    its device ID list in and registering the scan handler in either
    case.

    This change is based on a prototype from Zhang Rui.

    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Mika Westerberg

    Rafael J. Wysocki
     

20 Mar, 2014

1 commit

19 Mar, 2014

1 commit

17 Mar, 2014

1 commit

  • 6621c5a69   Merge branch 'acpi-hotplug' ... Browse Code »

    * acpi-hotplug:
    ACPI / hotplug: Rework deferred execution of acpi_device_hotplug()
    ACPI / dock: Update copyright notice
    ACPI / dock: Drop remove_dock_dependent_devices()
    ACPI / dock: Drop struct acpi_dock_ops and all code related to it
    ACPI / ATA: Add hotplug contexts to ACPI companions of SATA devices
    ACPI / dock: Add .uevent() callback to struct acpi_hotplug_context
    ACPI / dock: Use callback pointers from devices' ACPI hotplug contexts
    ACPI / dock: Use ACPI device object pointers instead of ACPI handles
    ACPI / hotplug: Add .fixup() callback to struct acpi_hotplug_context
    ACPI / hotplug / PCI: Do not clear event callback pointer for docks
    ACPI / dock: Associate dock platform devices with ACPI device objects
    ACPI / dock: Pass ACPI device pointer to acpi_device_is_battery()
    ACPI / dock: Dispatch dock notifications from the global notify handler

    Rafael J. Wysocki
     

16 Feb, 2014

1 commit

  • 1e2380cd1   ACPI / dock: Dispatch dock notifications from the global notify handler ... Browse Code »

    The ACPI dock station code carries out an extra namespace scan
    before the main one in order to find and register all of the dock
    device objects. Then, it registers a notify handler for each of
    them for handling dock events.

    However, dock device objects need not be scanned for upfront. They
    very well can be enumerated and registered during the first phase
    of the main namespace scan, before attaching scan handlers and ACPI
    drivers to ACPI device objects. Then, the dependent devices can be
    added to the in the second phase. That makes it possible to drop
    the extra namespace scan, so do it.

    Moreover, it is not necessary to register notify handlers for all
    of the dock stations' namespace nodes, becuase notifications may
    be dispatched from the global notify handler for them. Do that and
    drop two functions used for dock notify handling, acpi_dock_deferred_cb()
    and dock_notify_handler(), that aren't necessary any more.

    Finally, some dock station objects have _HID objects matching the
    ACPI container scan handler which causes it to claim those objects
    and try to handle their hotplug, but that is not a good idea,
    because those objects have their own special hotplug handling anyway.
    For this reason, the hotplug_notify flag should not be set for ACPI
    device objects representing dock stations and the container scan
    handler should be made ignore those objects, so make that happen.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

12 Feb, 2014

1 commit

29 Dec, 2013

1 commit

  • caa73ea15   ACPI / hotplug / driver core: Handle containers in a special way ... Browse Code »

    ACPI container devices require special hotplug handling, at least
    on some systems, since generally user space needs to carry out
    system-specific cleanup before it makes sense to offline devices in
    the container. However, the current ACPI hotplug code for containers
    first attempts to offline devices in the container and only then it
    notifies user space of the container offline.

    Moreover, after commit 202317a573b2 (ACPI / scan: Add acpi_device
    objects for all device nodes in the namespace), ACPI device objects
    representing containers are present as long as the ACPI namespace
    nodes corresponding to them are present, which may be forever, even
    if the container devices are physically detached from the system (the
    return values of the corresponding _STA methods change in those
    cases, but generally the namespace nodes themselves are still there).
    Thus it is useful to introduce entities representing containers that
    will go away during container hot-unplug.

    The goal of this change is to address both the above issues.

    The idea is to create a "companion" container system device for each
    of the ACPI container device objects during the initial namespace
    scan or on a hotplug event making the container present. That system
    device will be unregistered on container removal. A new bus type
    for container devices is added for this purpose, because device
    offline and online operations need to be defined for them. The
    online operation is a trivial function that is always successful
    and the offline uses a callback pointed to by the container device's
    offline member.

    For ACPI containers that callback simply walks the list of ACPI
    device objects right below the container object (its children) and
    checks if all of their physical companion devices are offline. If
    that's not the case, it returns -EBUSY and the container system
    devivce cannot be put offline. Consequently, to put the container
    system device offline, it is necessary to put all of the physical
    devices depending on its ACPI companion object offline beforehand.

    Container system devices created for ACPI container objects are
    initially online. They are created by the container ACPI scan
    handler whose hotplug.demand_offline flag is set. That causes
    acpi_scan_hot_remove() to check if the companion container system
    device is offline before attempting to remove an ACPI container or
    any devices below it. If the check fails, a KOBJ_CHANGE uevent is
    emitted for the container system device in question and user space
    is expected to offline all devices below the container and the
    container itself in response to it. Then, user space can finalize
    the removal of the container with the help of its ACPI device
    object's eject attribute in sysfs.

    Tested-by: Yasuaki Ishimatsu
    Signed-off-by: Rafael J. Wysocki
    Acked-by: Greg Kroah-Hartman

    Rafael J. Wysocki
     

23 Nov, 2013

1 commit

  • 46394fd01   ACPI / hotplug: Move container-specific code out of the core ... Browse Code »

    Move container-specific uevents from the core hotplug code to the
    container scan handler's .attach() and .detach() callbacks.

    This way the core will not have to special-case containers and
    the uevents will be guaranteed to happen every time a container
    is either scanned or trimmed as appropriate.

    Signed-off-by: Rafael J. Wysocki
    Tested-by: Mika Westerberg

    Rafael J. Wysocki
     

28 Apr, 2013

1 commit

  • c940c8ce1   Merge branch 'acpi-assorted' ... Browse Code »

    * acpi-assorted: (21 commits)
    ACPI / thermal: do not always return THERMAL_TREND_RAISING for active trip points
    ACPI: video: correct acpi_video_bus_add error processing
    ACPI: Fix wrong parameter passed to memblock_reserve
    acpi: video: enhance the quirk detect logic of _BQC
    ACPI: update comments for acpi_event_status
    ACPI: remove "config ACPI_DEBUG_FUNC_TRACE"
    PCI / ACPI: Don't query OSC support with all possible controls
    ACPI / processor_thermal: avoid null pointer deference error
    ACPI / fan: avoid null pointer deference error
    ACPI / video: Fix applying indexed initial brightness value.
    ACPI / video: Make logic a little easier to understand.
    ACPI / video: Fix brightness control initialization for some laptops.
    ACPI: Use resource_size() in osl.c
    ACPI / acpi_pad: Used PTR_RET
    ACPI: suppress compiler warning in container.c
    ACPI: suppress compiler warning in battery.c
    ACPI: suppress compiler warnings in processor_throttling.c
    ACPI: suppress compiler warnings in button.c
    ACPI: replace kmalloc+memcpy with kmemdup
    ACPI: Remove acpi_pci_bind_root() definition
    ...

    Rafael J. Wysocki
     

25 Mar, 2013

1 commit

04 Mar, 2013

2 commits

13 Feb, 2013

3 commits

  • 3757b9480   ACPI / hotplug: Fix concurrency issues and memory leaks ... Browse Code »

    This changeset is aimed at fixing a few different but related
    problems in the ACPI hotplug infrastructure.

    First of all, since notify handlers may be run in parallel with
    acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device()
    and some of them are installed for ACPI handles that have no struct
    acpi_device objects attached (i.e. before those objects are created),
    those notify handlers have to take acpi_scan_lock to prevent races
    from taking place (e.g. a struct acpi_device is found to be present
    for the given ACPI handle, but right after that it is removed by
    acpi_bus_trim() running in parallel to the given notify handler).
    Moreover, since some of them call acpi_bus_scan() and
    acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock
    should be acquired by the callers of these two funtions rather by
    these functions themselves.

    For these reasons, make all notify handlers that can handle device
    addition and eject events take acpi_scan_lock and remove the
    acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim().
    Accordingly, update all of their users to make sure that they
    are always called under acpi_scan_lock.

    Furthermore, since eject operations are carried out asynchronously
    with respect to the notify events that trigger them, with the help
    of acpi_bus_hot_remove_device(), even if notify handlers take the
    ACPI scan lock, it still is possible that, for example,
    acpi_bus_trim() will run between acpi_bus_hot_remove_device() and
    the notify handler that scheduled its execution and that
    acpi_bus_trim() will remove the device node passed to
    acpi_bus_hot_remove_device() for ejection. In that case, the struct
    acpi_device object obtained by acpi_bus_hot_remove_device() will be
    invalid and not-so-funny things will ensue. To protect agaist that,
    make the users of acpi_bus_hot_remove_device() run get_device() on
    ACPI device node objects that are about to be passed to it and make
    acpi_bus_hot_remove_device() run put_device() on them and check if
    their ACPI handles are not NULL (make acpi_device_unregister() clear
    the device nodes' ACPI handles for that check to work).

    Finally, observe that acpi_os_hotplug_execute() actually can fail,
    in which case its caller ought to free memory allocated for the
    context object to prevent leaks from happening. It also needs to
    run put_device() on the device node that it ran get_device() on
    previously in that case. Modify the code accordingly.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Yinghai Lu

    Rafael J. Wysocki
     
  • 87d4a4da7   ACPI: Drop the container.h header file ... Browse Code »

    The include/acpi/container.h only contains a definition of a
    structure that is not used any more, so drop it entirely.

    Similar change was proposed earlier by Toshi Kani.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Toshi Kani

    Rafael J. Wysocki
     
  • 737f1a9f8   ACPI / scan: Make container driver use struct acpi_scan_handler ... Browse Code »

    Make the ACPI container driver use struct acpi_scan_handler for
    representing the object used to initialize ACPI containers and remove
    the ACPI driver structure used previously and the data structures
    created by it, since in fact they were not used for any purpose.

    This simplifies the code and reduces the kernel's memory footprint by
    avoiding the registration of a struct device_driver object with the
    driver core and creation of its sysfs directory which is unnecessary.

    In addition to that, make the namespace walk callback used for
    installing the notify handlers for ACPI containers more
    straightforward.

    This change includes fixes from Toshi Kani.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Yinghai Lu
    Acked-by: Yasuaki Ishimatsu
    Tested-by: Yasuaki Ishimatsu
    Reviewed-by: Toshi Kani
    Tested-by: Toshi Kani

    Rafael J. Wysocki
     

26 Jan, 2013

1 commit

  • 51fac8388   ACPI: Remove useless type argument of driver .remove() operation ... Browse Code »

    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
     

19 Jan, 2013

1 commit

  • b8bd759ac   ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead ... Browse Code »

    The only difference between acpi_bus_scan() and acpi_bus_add() is the
    invocation of acpi_update_all_gpes() in the latter which in fact is
    unnecessary, because acpi_update_all_gpes() has already been called
    by acpi_scan_init() and the way it is implemented guarantees the next
    invocations of it to do nothing.

    For this reason, drop acpi_bus_add() and make all its callers use
    acpi_bus_scan() directly instead of it. Additionally, rearrange the
    code in acpi_scan_init() slightly to improve the visibility of the
    acpi_update_all_gpes() call in there.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Yinghai Lu

    Rafael J. Wysocki
     

03 Jan, 2013

3 commits

  • 0cd6ac52b   ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argument ... Browse Code »

    The callers of acpi_bus_add() usually assume that if it has
    succeeded, then a struct acpi_device object has been attached to
    the handle passed as the first argument. Unfortunately, however,
    this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add()
    too as a result, may return a pointer to a different struct
    acpi_device object on success (it may be an object corresponding to
    one of the descendant ACPI nodes in the namespace scope below that
    handle).

    For this reason, the callers of acpi_bus_add() who care about
    whether or not a struct acpi_device object has been created for
    its first argument need to check that using acpi_bus_get_device()
    anyway, so the second argument of acpi_bus_add() is not really
    useful for them. The same observation applies to acpi_bus_scan()
    executed directly from acpi_scan_init().

    Therefore modify the relevant callers of acpi_bus_add() to check the
    existence of the struct acpi_device in question with the help of
    acpi_bus_get_device() and drop the no longer necessary second
    argument of acpi_bus_add(). Accordingly, modify acpi_scan_init() to
    use acpi_bus_get_device() to get acpi_root and drop the no longer
    needed second argument of acpi_bus_scan().

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

    Rafael J. Wysocki
     
  • 636458de3   ACPI: Remove the arguments of acpi_bus_add() that are not used ... Browse Code »

    Notice that acpi_bus_add() uses only 2 of its 4 arguments and
    redefine its header to match the body. Update all of its callers as
    necessary and observe that this leads to quite a number of removed
    lines of code (Linus will like that).

    Add a kerneldoc comment documenting acpi_bus_add() and wonder how
    its callers make wrong assumptions about the second argument (make
    note to self to take care of that later).

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

    Rafael J. Wysocki
     
  • 02f57c67a   ACPI: Remove acpi_start_single_object() and acpi_bus_start() ... Browse Code »

    The ACPI PCI root bridge driver was the only ACPI driver implementing
    the .start() callback, which isn't used by any ACPI drivers any more
    now.

    For this reason, acpi_start_single_object() has no purpose any more,
    so remove it and all references to it. Also remove
    acpi_bus_start_device(), whose only purpose was to call
    acpi_start_single_object().

    Moreover, since after the removal of acpi_bus_start_device() the
    only purpose of acpi_bus_start() remains to call
    acpi_update_all_gpes(), move that into acpi_bus_add() and drop
    acpi_bus_start() too, remove its header from acpi_bus.h and
    update all of its former users accordingly.

    This change was previously proposed in a different from by
    Yinghai Lu.

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

    Rafael J. Wysocki
     

22 Nov, 2012

1 commit

15 Nov, 2012

1 commit

04 Jun, 2012

1 commit

  • 0c67dc242   ACPI: Add _OST support for ACPI container hotplug ... Browse Code »

    Changed container_notify_cb() to call ACPI _OST method when ACPI
    container hotplug operation has completed. Slightly restructured
    the code with the same logic. The function sets eject_pending bit
    for an eject request since it does not initiate hot-remove operation.
    This bit is checked by the sysfs eject handler to determine if the
    request is originated from an ACPI eject notification.

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

    Toshi Kani
     

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
     

25 Nov, 2009

1 commit

  • 2263576cf   ACPICA: Add post-order callback to acpi_walk_namespace ... Browse Code »

    The existing interface only has a pre-order callback. This change
    adds an additional parameter for a post-order callback which will
    be more useful for bus scans. ACPICA BZ 779.

    Also update the external calls to acpi_walk_namespace.

    http://www.acpica.org/bugzilla/show_bug.cgi?id=779

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

    Lin Ming
     

19 Sep, 2009

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 Aug, 2009

1 commit

  • 15b8dd53f   ACPICA: Major update for acpi_get_object_info external interface ... Browse Code »

    Completed a major update for the acpi_get_object_info external interface.
    Changes include:
    - Support for variable, unlimited length HID, UID, and CID strings
    - Support Processor objects the same as Devices (HID,UID,CID,ADR,STA, etc.)
    - Call the _SxW power methods on behalf of a device object
    - Determine if a device is a PCI root bridge
    - Change the ACPI_BUFFER parameter to ACPI_DEVICE_INFO.
    These changes will require an update to all callers of this interface.
    See the ACPICA Programmer Reference for details.

    Also, update all invocations of acpi_get_object_info interface

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

    Bob Moore
     

07 Feb, 2009

1 commit

08 Nov, 2008

1 commit

23 Oct, 2008

1 commit

11 Oct, 2008

2 commits

24 Jul, 2007

1 commit

26 Apr, 2007

1 commit

13 Feb, 2007

3 commits

  • 7cda93e00   ACPI: delete extra #defines in /drivers/acpi/ drivers ... Browse Code »

    Cosmetic only.

    Except in a single case, #define ACPI_*_DRIVER_NAME
    were invoked 0 or 1 times.

    Signed-off-by: Len Brown

    Len Brown
     
  • c2b6705b7   ACPI: fix acpi_driver.name usage ... Browse Code »

    It was erroneously used as a description rather than a name.

    ie. turn this:

    lenb@se7525gp2:/sys> ls bus/acpi/drivers
    ACPI AC Adapter Driver ACPI Embedded Controller Driver ACPI Power Resource Driver
    ACPI Battery Driver ACPI Fan Driver ACPI Processor Driver
    ACPI Button Driver ACPI PCI Interrupt Link Driver ACPI Thermal Zone Driver
    ACPI container driver ACPI PCI Root Bridge Driver hpet

    into this:

    lenb@se7525gp2:~> ls /sys/bus/acpi/drivers
    ac battery button container ec fan hpet pci_link pci_root power processor thermal

    Signed-off-by: Len Brown

    Len Brown
     
  • f52fd66d2   ACPI: clean up ACPI_MODULE_NAME() use ... Browse Code »

    cosmetic only

    Make "module name" actually match the file name.
    Invoke with ';' as leaving it off confuses Lindent and gcc doesn't care.
    Fix indentation where Lindent did get confused.

    Signed-off-by: Len Brown

    Len Brown