07 Nov, 2011

1 commit

  • Recently the ACPI ops structs were constified but the inline version
    of register_hotplug_dock_device() was overlooked (see also commit
    9c8b04b, June 25 2011). Update the inline function
    register_hotplug_dock_device() that is enabled with
    CONFIG_ACPI_DOCK=n too. This patch fixes at least the following
    compiler warnings:

    drivers/ata/libata-acpi.c: In function .ata_acpi_associate.:
    drivers/ata/libata-acpi.c:266:11: warning: passing argument 2 of .register_hotplug_dock_device. discards qualifiers from pointer target type
    include/acpi/acpi_drivers.h:146:19: note: expected .struct acpi_dock_ops *. but argument is of type .const struct acpi_dock_ops *.
    drivers/ata/libata-acpi.c:275:11: warning: passing argument 2 of .register_hotplug_dock_device. discards qualifiers from pointer target type
    include/acpi/acpi_drivers.h:146:19: note: expected .struct acpi_dock_ops *. but argument is of type .const struct acpi_dock_ops *.

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

    Bart Van Assche
     

17 Jul, 2011

1 commit

  • Structs battery_file, acpi_dock_ops, file_operations,
    thermal_cooling_device_ops, thermal_zone_device_ops, kernel_param_ops
    are not changed in runtime. It is safe to make them const.
    register_hotplug_dock_device() was altered to take const "ops" argument
    to respect acpi_dock_ops' const notion.

    Signed-off-by: Vasiliy Kulikov
    Acked-by: Jeff Garzik
    Signed-off-by: Len Brown

    Vasiliy Kulikov
     

20 Oct, 2010

1 commit


04 Apr, 2010

1 commit

  • The acpi_pci_root structure contains all the individual items (acpi_device,
    domain, bus number) we pass to pci_acpi_scan_root(), so just pass the
    single acpi_pci_root pointer directly.

    This will make it easier to add _CBA support later. For _CBA, we need the
    entire downstream bus range, not just the base bus number. We have that in
    the acpi_pci_root structure, so passing the pointer makes it available to
    the arch-specific code.

    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Kenji Kaneshige
    Signed-off-by: Len Brown

    Bjorn Helgaas
     

24 Mar, 2010

1 commit

  • On some old IBM workstations and desktop computers, the BIOS presents in the
    DSDT an SMBus object that is missing the HID identifier that the i2c-scmi
    driver looks for. Modify the ACPI device scan code to insert the missing HID
    if it finds an IBM system with such an object.

    Affected machines: IntelliStation Z20/Z30. Note that the i2c-i801 driver no
    longer works on these machines because of ACPI resource conflicts.

    Signed-off-by: Darrick J. Wong
    Signed-off-by: Jean Delvare

    Darrick J. Wong
     

24 Feb, 2010

1 commit

  • The main benefit of using ACPI host bridge window information is that
    we can do better resource allocation in systems with multiple host bridges,
    e.g., http://bugzilla.kernel.org/show_bug.cgi?id=14183

    Sometimes we need _CRS information even if we only have one host bridge,
    e.g., https://bugs.launchpad.net/ubuntu/+source/linux/+bug/341681

    Most of these systems are relatively new, so this patch turns on
    "pci=use_crs" only on machines with a BIOS date of 2008 or newer.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     

24 Jun, 2009

1 commit


18 Jun, 2009

6 commits

  • acpi_get_pci_dev() is better, and all callers have been converted, so
    eliminate acpi_get_pci_id().

    Signed-off-by: Alex Chiang
    Acked-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Alexander Chiang
     
  • There is no need to pass a segment/bus tuple to this API, as the callsite
    always has a struct pci_bus. We can derive segment/bus from the
    struct pci_bus, so let's take this opportunit to simplify the API and
    make life easier for the callers.

    Signed-off-by: Alex Chiang
    Acked-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Alexander Chiang
     
  • A PCI domain cannot change as you descend down subordinate buses, which
    makes the 'segment' argument to acpi_pci_irq_add_prt() useless.

    Change the interface to take a struct pci_bus *, from whence we can derive
    the bus number and segment. Reducing the number of arguments makes life
    simpler for callers.

    Signed-off-by: Alex Chiang
    Acked-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Alexander Chiang
     
  • Now that we can dynamically convert an ACPI CA handle to a
    struct pci_dev at runtime, there's no need to statically bind
    them during boot.

    acpi_pci_bind/unbind are vastly simplified, and are only used
    to evaluate _PRT methods on P2P bridges and non-bridge children.

    This patch also changes the time-space tradeoff ever so slightly.

    Looking up the ACPI-PCI binding is never in the performance path, and by
    eliminating this caching, we save 24 bytes for each _ADR device in the
    ACPI namespace.

    This patch lays further groundwork to eventually eliminate
    the acpi_driver_ops.bind callback.

    Signed-off-by: Alex Chiang
    Acked-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Alexander Chiang
     
  • Convert an ACPI CA handle to a struct pci_dev.

    Performing this lookup dynamically allows us to get rid of the
    ACPI-PCI binding code, which:

    - eliminates struct acpi_device vs struct pci_dev lifetime issues
    - lays more groundwork for eliminating .start from acpi_device_ops
    and thus simplifying ACPI drivers
    - whacks out a lot of code

    This change lays the groundwork for eliminating much of pci_bind.c.

    Although pci_root.c may not be the most logical place for this
    change, putting it here saves us from having to export acpi_pci_find_root.

    Signed-off-by: Alex Chiang
    Acked-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Alexander Chiang
     
  • acpi_pci_root_add() explicitly assigns device->ops.bind, and later
    calls acpi_pci_bind_root(), which also does the same thing.

    We don't need to repeat ourselves; removing the explicit assignment
    allows us to make acpi_pci_bind() static.

    Signed-off-by: Alex Chiang
    Acked-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Alexander Chiang
     

28 May, 2009

2 commits

  • The ACPI0007 _HID used for processor "Device" objects in the namespace
    is not needed outside the processor driver, so move it there. Also, the
    #define is only used once, so just remove it and hard-code "ACPI0007".

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Bjorn Helgaas
     
  • ACPI_PROCESSOR_OBJECT_HID is a synthetic _HID that Linux generates
    for "Processor" definitions. Unlike "Device" definitions, "Processor"
    definitions do not have a _HID in the namespace, so we generate a
    fake _HID. By convention, all these fake _HIDs begin with "LNX".

    This does change the user-visible _HID for "Processor" objects --
    previously, we used "ACPI_CPU" and this changes that to "LNXCPU",
    which starts with "LNX" as do all the other made-up _HIDs. This
    change is visible in processor filenames and "hid" files under
    /sys/devices/LNXSYSTM:00/.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Bjorn Helgaas
     

05 Apr, 2009

1 commit

  • This patch adds support for ACPI device driver .notify() methods. If
    such a method is present, Linux/ACPI installs a handler for device
    notifications (but not for system notifications such as Bus Check,
    Device Check, etc). When a device notification occurs, Linux/ACPI
    passes it on to the driver's .notify() method.

    In most cases, this removes the need for drivers to install their own
    handlers for device-specific notifications.

    For fixed hardware devices like some power and sleep buttons, there's
    no notification value because there's no control method to execute a
    Notify opcode. When a fixed hardware device generates an event, we
    handle it the same as a regular device notification, except we send
    a ACPI_FIXED_HARDWARE_EVENT value. This is outside the normal 0x0-0xff
    range used by Notify opcodes.

    Several drivers install their own handlers for system Bus Check and
    Device Check notifications so they can support hot-plug. This patch
    doesn't affect that usage.

    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Alex Chiang
    Signed-off-by: Len Brown

    Bjorn Helgaas
     

17 Mar, 2009

1 commit

  • A number of things that shouldn't be exposed outside the ACPI core
    were declared in include/acpi/acpi_drivers.h, where anybody can
    see them. This patch moves those declarations to a new "internal.h"
    inside drivers/acpi.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Bjorn Helgaas
     

12 Nov, 2008

1 commit


08 Nov, 2008

3 commits


07 Nov, 2008

3 commits

  • Declaring processors in ACPI namespace can be done using either a
    "Processor" definition or a "Device" definition (see section 8.4 -
    Declaring Processors; "Advanced Configuration and Power Interface
    Specification", Revision 3.0b). Currently the two processor
    declaration types are conflated.

    This patch disambiguates the processor declaration's definition type
    enabling subsequent code to behave uniquely based explicitly on the
    declaration's type.

    Signed-off-by: Myron Stowe
    Signed-off-by: Len Brown

    Myron Stowe
     
  • Remove CONFIG_ACPI_EC. It was always set the same as CONFIG_ACPI,
    and it had no menu label, so there was no way to set it to anything
    other than "y".

    Per section 6.5.4 of the ACPI 3.0b specification,

    OSPM must make Embedded Controller operation regions, accessed
    via the Embedded Controllers described in ECDT, available before
    executing any control method.

    The ECDT table is optional, but if it is present, the above text
    means that the EC it describes is a required part of the ACPI
    subsystem, so CONFIG_ACPI_EC=n wouldn't make sense.

    Signed-off-by: Bjorn Helgaas
    Acked-by: Alexey Starikovskiy
    Signed-off-by: Len Brown

    Bjorn Helgaas
     
  • Remove CONFIG_ACPI_POWER. It was always set the same as CONFIG_ACPI,
    and it had no menu label, so there was no way to set it to anything
    other than "y".

    The interfaces under CONFIG_ACPI_POWER (acpi_device_sleep_wake(),
    acpi_power_transition(), etc) are called unconditionally from the
    ACPI core, so we already depend on it always being present.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Bjorn Helgaas
     

23 Oct, 2008

3 commits

  • Len Brown
     
  • Conflicts:
    drivers/acpi/osl.c

    Signed-off-by: Len Brown

    Len Brown
     
  • Maybe the incorrect power state is returned on the bogus bios, which
    is different with the real power state. For example: the bios returns D0
    state and the real power state is D3. OS expects to set the device to D0
    state. In such case if OS uses the power state returned by the BIOS and
    checks the device power state very strictly in power transition, the device
    can't be transited to the correct power state.

    So the boot option of "acpi.power_nocheck=1" is added to avoid checking
    the device power in the course of device power transition.

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

    Signed-off-by: Zhao Yakui
    Signed-off-by: Zhang Rui
    Signed-off-by: Li Shaohua
    Signed-off-by: Andi Kleen
    Signed-off-by: Len Brown

    Zhao Yakui
     

11 Oct, 2008

1 commit

  • when there is no ECDT table and no _INI object for EC device, it will be
    enabled before scanning ACPI device. But it is too late after the following
    the commit is merged.
    >commit 7752d5cfe3d11ca0bb9c673ec38bd78ba6578f8e
    > Author: Robert Hancock
    > Date: Fri Feb 15 01:27:20 2008 -0800
    >x86: validate against acpi motherboard resources

    After the above commit is merged, OS will check whether MCFG area is
    reserved in ACPI motherboard resources by calling the function of
    acpi_get_devices when there exists MCFG table. In the acpi_get_devices the _STA
    object will be evaluated to check the status of the ACPI device. On some broken
    BIOS the MYEC object of EC device is initialized as one, which indicates that
    EC operation region is already accessible before enabling EC device.So on these
    broken BIOS the EC operation region will be accessed in course of evaluating
    the _STA object before enabling EC device, which causes that OS will print the
    following warning messages:
    >ACPI Error (evregion-0315): No handler for Region [EC__] (ffff88007f8145e8)
    [EmbeddedControl] [20080609]
    >ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20080321]
    >ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.
    EC__.BAT1._STA] (Node ffff81013fc17a00), AE_NOT_EXIST
    >ACPI Error (uteval-0233): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1.
    _STA] (Node ffff81013fc17a00), AE_NOT_EXIST

    Although the above warning message is harmless, it looks confusing.
    So it is necessary to enable EC device as early as possible.Maybe it is
    appropriate to enable it immediately after ACPI full initialization.

    http://bugzilla.kernel.org/show_bug.cgi?id=11255
    http://bugzilla.kernel.org/show_bug.cgi?id=11374
    http://bugzilla.kernel.org/show_bug.cgi?id=11660

    Signed-off-by: Zhao Yakui
    Acked-by: Alexey Starikovskiy
    Signed-off-by: Len Brown

    Zhao Yakui
     

24 Sep, 2008

1 commit

  • dock's uevent reported itself, not ata. It might be difficult to find an
    ata device just according to a dock. This patch introduces docking ops
    for each device in a dock. when docking, dock driver can send device
    specific uevent. This should help dock station too (not just bay)

    Signed-off-by: Shaohua Li
    Acked-by: Tejun Heo
    Signed-off-by: Len Brown

    Shaohua Li
     

08 Jul, 2008

1 commit

  • The currect ACPI code attempts to execute _PSW at three different
    places and in one of them only it tries to execute _DSW before _PSW,
    which is inconsistent with the other two cases.

    Move the execution of _DSW and _PSW into a separate function called
    acpi_device_sleep_wake() and call it wherever appropriate instead of
    executing _DSW and/or _PSW directly.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek
    Signed-off-by: Jesse Barnes

    Rafael J. Wysocki
     

07 Feb, 2008

2 commits

  • Conflicts:

    drivers/acpi/scan.c
    include/linux/acpi.h

    Signed-off-by: Len Brown

    Len Brown
     
  • This patch contains the following possible cleanups:
    - make the following needlessly global code static:
    - drivers/acpi/bay.c:dev_attr_eject
    - drivers/acpi/bay.c:dev_attr_present
    - drivers/acpi/dock.c:dev_attr_docked
    - drivers/acpi/dock.c:dev_attr_flags
    - drivers/acpi/dock.c:dev_attr_uid
    - drivers/acpi/dock.c:dev_attr_undock
    - drivers/acpi/pci_bind.c:acpi_pci_unbind()
    - drivers/acpi/pci_link.c:acpi_link_lock
    - drivers/acpi/sbs.c:acpi_sbs_callback()
    - drivers/acpi/sbshc.c:acpi_smbus_transaction()
    - drivers/acpi/sleep/main.c:acpi_sleep_prepare()
    - #if 0 the following unused global functions:
    - drivers/acpi/numa.c:acpi_unmap_pxm_to_node()
    - remove the following unused EXPORT_SYMBOL's:
    - acpi_register_gsi
    - acpi_unregister_gsi
    - acpi_strict
    - acpi_bus_receive_event
    - register_acpi_bus_type
    - unregister_acpi_bus_type
    - acpi_os_printf
    - acpi_os_sleep
    - acpi_os_stall
    - acpi_os_read_pci_configuration
    - acpi_os_create_semaphore
    - acpi_os_delete_semaphore
    - acpi_os_wait_semaphore
    - acpi_os_signal_semaphore
    - acpi_os_signal
    - acpi_pci_irq_enable
    - acpi_get_pxm

    Signed-off-by: Adrian Bunk
    Acked-by: Alexey Starikovskiy
    Signed-off-by: Len Brown

    Adrian Bunk
     

08 Dec, 2007

1 commit


26 Sep, 2007

1 commit


30 Jul, 2007

2 commits

  • Restore the 2.6.22 CONFIG_ACPI_SLEEP build option, but now shadowing the
    new CONFIG_PM_SLEEP option.

    Signed-off-by: Len Brown
    [ Modified to work with the PM config setup changes. ]
    Signed-off-by: Linus Torvalds

    Len Brown
     
  • Introduce CONFIG_SUSPEND representing the ability to enter system sleep
    states, such as the ACPI S3 state, and allow the user to choose SUSPEND
    and HIBERNATION independently of each other.

    Make HOTPLUG_CPU be selected automatically if SUSPEND or HIBERNATION has
    been chosen and the kernel is intended for SMP systems.

    Also, introduce CONFIG_PM_SLEEP which is automatically selected if
    CONFIG_SUSPEND or CONFIG_HIBERNATION is set and use it to select the
    code needed for both suspend and hibernation.

    The top-level power management headers and the ACPI code related to
    suspend and hibernation are modified to use the new definitions (the
    changes in drivers/acpi/sleep/main.c are, mostly, moving code to reduce
    the number of ifdefs).

    There are many other files in which CONFIG_PM can be replaced with
    CONFIG_PM_SLEEP or even with CONFIG_SUSPEND, but they can be updated in
    the future.

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Linus Torvalds

    Rafael J. Wysocki
     

25 Jul, 2007

2 commits


24 Jul, 2007

1 commit


10 May, 2007

1 commit