22 Jul, 2007

1 commit

  • ACPI has a ton of macros which make a bunch of empty if's when configured
    in non-debug mode.

    [lenb: The code it complaines about is functionally correct,
    so this patch is just to make -Wextra happier]

    #define DBG()

    if(...)
    DBG();
    next_c_statement

    which turns into
    if(...) ;
    next_c_statement

    Signed-off-by: Dave Jones
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Dave Jones
     

09 May, 2007

2 commits

  • This works around a bug seen in some RTC-related ACPI table entries, and
    tweaks related diagnostics to follow the ACPI convention.

    The bug prevents misleading boot-time messages: platforms affected by this
    bug wrongly report they can support alarms up to one year in the future,
    when in fact the longest alarm is just 24 hours. That will surprise anyone
    trying to use those extended alarms.

    Signed-off-by: David Brownell
    Cc: Alessandro Zummo
    Cc: Len Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     
  • Remove /proc/acpi/alarm file when the rtc-cmos "wakealarm" file is available.
    Instead, provide hooks that rtc-cmos will use.

    Signed-off-by: David Brownell
    Cc: Alessandro Zummo
    Cc: Len Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Brownell
     

16 Feb, 2007

1 commit


09 Feb, 2007

1 commit

  • Update ACPI to export its RTC extension information through platform_data
    to the PNPACPI or platform bus device node used on the system being set up.

    This will need to be updated later to provide a firmware hook to handle
    system suspend with an alarm pending.

    Len notes that "Eventually we may bundle ACPI/PNP/PNPACPI..." but if/when
    that happens, ACPI can simplify this without my help.

    And until it does, the separate patch creating a platform_device (on all
    X86_PC systems, even without ACPI) will be needed.

    Signed-off-by: David Brownell
    Cc: Bjorn Helgaas
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    David Brownell
     

17 Jan, 2007

1 commit


16 Dec, 2006

2 commits


02 Dec, 2006

1 commit

  • Change ACPI to use dev_archdata instead of firmware_data

    This patch changes ACPI to use the new dev_archdata on i386, x86_64
    and ia64 (is there any other arch using ACPI ?) to store it's
    acpi_handle.

    It also removes the firmware_data field from struct device as this
    was the only user.

    Only build-tested on x86

    Signed-off-by: Benjamin Herrenschmidt
    Cc: Len Brown
    Signed-off-by: Greg Kroah-Hartman

    Benjamin Herrenschmidt
     

27 Oct, 2006

1 commit

  • acpi_get_pci_rootbridge_handle() walks the ACPI name space
    searching for seg, bus and the PCI_ROOT_HID_STRING --
    returning the handle as soon as if find the match.

    But the current codes always parses through the whole namespace because
    the user_function find_pci_rootbridge() returns status=AE_OK when it finds the match.

    Make the find_pci_rootbridge() return AE_CTRL_TERMINATE when it finds the match.
    This reduces the ACPI namespace walk for acpi_get_pci_rootbridge_handle().

    Signed-off-by: Justin Chen
    Signed-off-by: Len Brown

    Chen, Justin
     

14 Oct, 2006

1 commit


30 Jun, 2006

1 commit


10 Dec, 2005

1 commit

  • Completed a major overhaul of the Resource Manager code -
    specifically, optimizations in the area of the AML/internal
    resource conversion code. The code has been optimized to
    simplify and eliminate duplicated code, CPU stack use has
    been decreased by optimizing function parameters and local
    variables, and naming conventions across the manager have
    been standardized for clarity and ease of maintenance (this
    includes function, parameter, variable, and struct/typedef
    names.)

    All Resource Manager dispatch and information tables have
    been moved to a single location for clarity and ease of
    maintenance. One new file was created, named "rsinfo.c".

    The ACPI return macros (return_ACPI_STATUS, etc.) have
    been modified to guarantee that the argument is
    not evaluated twice, making them less prone to macro
    side-effects. However, since there exists the possibility
    of additional stack use if a particular compiler cannot
    optimize them (such as in the debug generation case),
    the original macros are optionally available. Note that
    some invocations of the return_VALUE macro may now cause
    size mismatch warnings; the return_UINT8 and return_UINT32
    macros are provided to eliminate these. (From Randy Dunlap)

    Implemented a new mechanism to enable debug tracing for
    individual control methods. A new external interface,
    acpi_debug_trace(), is provided to enable this mechanism. The
    intent is to allow the host OS to easily enable and disable
    tracing for problematic control methods. This interface
    can be easily exposed to a user or debugger interface if
    desired. See the file psxface.c for details.

    acpi_ut_callocate() will now return a valid pointer if a
    length of zero is specified - a length of one is used
    and a warning is issued. This matches the behavior of
    acpi_ut_allocate().

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

    Bob Moore
     

07 Dec, 2005

1 commit


11 Nov, 2005

1 commit

  • This patch further tweaks how we request control of hotplug
    controller hardware from BIOS. We first search the ACPI namespace
    corresponding to a specific hotplug controller looking for an
    _OSC or OSHP method. On failure, we successively move to the
    ACPI parent object, till we hit the highest level host bridge
    in the hierarchy. This allows for different types of BIOS's
    which place the _OSC/OSHP methods at various places in the acpi
    namespace, while still not encroaching on the namespace of
    some other root level host bridge.

    This patch also introduces a new load time option (pciehp_force)
    that allows us to bypass all _OSC/OSHP checking. Not supporting
    these methods seems to be be the most common ACPI firmware problem
    we've run into. This will still _not_ allow the pciehp driver to
    work correctly if the BIOS really doesn't support pciehp (i.e. if
    it doesn't generate a hotplug interrupt). Use this option with
    caution. Some BIOS's may deliberately not build any _OSC/OSHP
    methods to make sure it retains control the hotplug hardware.
    Using the pciehp_force parameter for such systems can lead to
    two separate entities trying to control the same hardware.

    Signed-off-by: Rajesh Shah
    Signed-off-by: Greg Kroah-Hartman

    rajesh.shah@intel.com
     

20 Oct, 2005

1 commit

  • In drivers/acpi/glue.c the address of an integer is cast to the address of
    an unsigned long. This breaks on systems where a long is larger than an
    int --- for a start the int can be misaligned; for a second the assignment
    through the pointer will overwrite part of the next variable.

    Signed-off-by: Peter Chubb
    Acked-by: "Brown, Len"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Chubb
     

22 Sep, 2005

1 commit


12 Aug, 2005

1 commit


05 Aug, 2005

1 commit


12 Jul, 2005

2 commits

  • DBG("No ACPI bus support for %s\n", dev->bus_id);
    http://bugzilla.kernel.org/show_bug.cgi?id=4277

    Signed-off-by: David Shaohua Li
    Signed-off-by: Len Brown

    David Shaohua Li
     
  • Implement the framework for binding physical devices
    with ACPI devices. A physical bus like PCI bus
    should create a 'acpi_bus_type', with:

    .find_device:
    For device which has parent such as normal PCI devices.

    .find_bridge:
    It's for special devices, such as PCI root bridge
    or IDE controller. Such devices generally haven't a
    parent or ->bus. We use the special method
    to get an ACPI handle.

    Uses new field in struct device: firmware_data

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

    Signed-off-by: David Shaohua Li
    Signed-off-by: Len Brown

    David Shaohua Li