1. 03 1月, 2013 9 次提交
    • B
      ACPI: Remove unused struct acpi_pci_root.id member · e0ebda2e
      Bjorn Helgaas 提交于
      This member is never initialized and never referenced, so remove it.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e0ebda2e
    • R
      ACPI: Drop ACPI device .bind() and .unbind() callbacks · 3eec5f7a
      Rafael J. Wysocki 提交于
      Drop the .bind() and .unbind() that have no more users from
      struct acpi_device_ops and remove all of the code referring to
      them from drivers/acpi/scan.c.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      3eec5f7a
    • R
      ACPI: Add .setup() and .cleanup() callbacks to struct acpi_bus_type · 11909ca1
      Rafael J. Wysocki 提交于
      Add two new callbacks,.setup() and .cleanup(), struct acpi_bus_type
      and modify acpi_platform_notify() to call .setup() after executing
      acpi_bind_one() successfully and acpi_platform_notify_remove() to
      call .cleanup() before running acpi_unbind_one().  This will allow
      the users of struct acpi_bus_type, PCI in particular, to specify
      operations to be executed right after the given device has been
      associated with a companion struct acpi_device and right before
      it's going to be detached from that companion, respectively.
      
      The main motivation is to be able to get rid of acpi_pci_bind()
      and acpi_pci_unbind(), which are horrible horrible stuff.  [In short,
      there are three problems with them: The way they populate the .bind()
      and .unbind() callbacks of ACPI devices is rather less than
      straightforward, they require special hotplug-specific paths to be
      present in the ACPI namespace scanning code and by the time
      acpi_pci_unbind() is called the PCI device object in question may
      not exist any more.]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      11909ca1
    • R
      ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argument · 0cd6ac52
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      0cd6ac52
    • R
      ACPI: Replace ACPI device add_type field with a match_driver flag · 209d3b17
      Rafael J. Wysocki 提交于
      After the removal of the second argument of acpi_bus_scan() there is
      no difference between the ACPI_BUS_ADD_MATCH and ACPI_BUS_ADD_START
      add types, so the add_type field in struct acpi_device may be
      replaced with a single flag.  Do that calling the flag match_driver.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      209d3b17
    • R
      ACPI: Remove the arguments of acpi_bus_add() that are not used · 636458de
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      636458de
    • R
      ACPI: Remove acpi_start_single_object() and acpi_bus_start() · 02f57c67
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      02f57c67
    • R
      ACPI: Replace struct acpi_bus_ops with enum type · a2d06a1a
      Rafael J. Wysocki 提交于
      Notice that one member of struct acpi_bus_ops, acpi_op_add, is not
      used anywhere any more and the relationship between its remaining
      members, acpi_op_match and acpi_op_start, is such that it doesn't
      make sense to set the latter without setting the former at the same
      time.  Therefore, replace struct acpi_bus_ops with new a enum type,
      enum acpi_bus_add_type, with three values, ACPI_BUS_ADD_BASIC,
      ACPI_BUS_ADD_MATCH, ACPI_BUS_ADD_START, corresponding to
      both acpi_op_match and acpi_op_start unset, acpi_op_match set and
      acpi_op_start unset, and both acpi_op_match and acpi_op_start set,
      respectively.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      a2d06a1a
    • R
      ACPI: Separate adding ACPI device objects from probing ACPI drivers · 805d410f
      Rafael J. Wysocki 提交于
      Split the ACPI namespace scanning for devices into two passes, such
      that struct acpi_device objects are registerd in the first pass
      without probing ACPI drivers and the drivers are probed against them
      directly in the second pass.
      
      There are two main reasons for doing that.
      
      First, the ACPI PCI root bridge driver's .add() routine,
      acpi_pci_root_add(), causes struct pci_dev objects to be created for
      all PCI devices under the given root bridge.  Usually, there are
      corresponding ACPI device nodes in the ACPI namespace for some of
      those devices and therefore there should be "companion" struct
      acpi_device objects to attach those struct pci_dev objects to.  These
      struct acpi_device objects should exist when the corresponding
      struct pci_dev objects are created, but that is only guaranteed
      during boot and not during hotplug.  This leads to a number of
      functional differences between the boot and the hotplug cases which
      are not strictly necessary and make the code more complicated.
      
      For example, this forces the ACPI PCI root bridge driver to defer the
      registration of the just created struct pci_dev objects and to use a
      special .start() callback routine, acpi_pci_root_start(), to make
      sure that all of the "companion" struct acpi_device objects will be
      present at PCI devices registration time during hotplug.
      
      If those differences can be eliminated, we will be able to
      consolidate the boot and hotplug code paths for the enumeration and
      registration of PCI devices and to reduce the complexity of that
      code quite a bit.
      
      The second reason is that, in general, it should be possible to
      resolve conflicts of resources assigned by the BIOS to different
      devices represented by ACPI namespace nodes before any drivers bind
      to them and before they are attached to "companion" objects
      representing physical devices (such as struct pci_dev).  However, for
      this purpose we first need to enumerate all ACPI device nodes in the
      given namespace scope.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      805d410f
  2. 22 11月, 2012 1 次提交
    • A
      ACPI / PM: Introduce os_accessible flag for power_state · 1399dfcd
      Aaron Lu 提交于
      Currently we have valid flag to represent if this ACPI device power
      state is valid. A device power state is valid does not necessarily
      mean we, as OSPM, has a mean to put the device into that power state,
      e.g. D3 cold is always a valid power state for any ACPI device, but if
      there is no _PS3 or _PRx for this device, we can't really put that
      device into D3 cold power state. The same is true for D0 power state.
      
      So here comes the os_accessible flag, which is only set if the device
      has provided us the required means to put it into that power state,
      e.g. if we have _PS3 or _PRx, we can put the device into D3 cold state
      and thus, D3 cold power state's os_accessible flag will be set in this
      case.
      
      And a new wrapper inline function is added to be used to check if
      firmware has provided us a way to power off the device during runtime.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1399dfcd
  3. 21 11月, 2012 1 次提交
  4. 16 11月, 2012 1 次提交
  5. 15 11月, 2012 9 次提交
    • M
      driver core / ACPI: Move ACPI support to core device and driver types · 06f64c8f
      Mika Westerberg 提交于
      With ACPI 5 we are starting to see devices that don't natively support
      discovery but can be enumerated with the help of the ACPI namespace.
      Typically, these devices can be represented in the Linux device driver
      model as platform devices or some serial bus devices, like SPI or I2C
      devices.
      
      Since we want to re-use existing drivers for those devices, we need a
      way for drivers to specify the ACPI IDs of supported devices, so that
      they can be matched against device nodes in the ACPI namespace.  To
      this end, it is sufficient to add a pointer to an array of supported
      ACPI device IDs, that can be provided by the driver, to struct device.
      
      Moreover, things like ACPI power management need to have access to
      the ACPI handle of each supported device, because that handle is used
      to invoke AML methods associated with the corresponding ACPI device
      node.  The ACPI handles of devices are now stored in the archdata
      member structure of struct device whose definition depends on the
      architecture and includes the ACPI handle only on x86 and ia64. Since
      the pointer to an array of supported ACPI IDs is added to struct
      device_driver in an architecture-independent way, it is logical to
      move the ACPI handle from archdata to struct device itself at the same
      time.  This also makes code more straightforward in some places and
      follows the example of Device Trees that have a poiter to struct
      device_node in there too.
      
      This changeset is based on Mika Westerberg's work.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      06f64c8f
    • T
      ACPI: Remove unused lockable in acpi_device_flags · f4fa0e01
      Toshi Kani 提交于
      Removed lockable in struct acpi_device_flags since it is no
      longer used by any code. acpi_bus_hot_remove_device() cannot
      use this flag because acpi_bus_trim() frees up its acpi_device
      object. Furthermore, the dock driver calls _LCK method without
      using this lockable flag.
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f4fa0e01
    • D
      ACPI / PM: Fix build problem related to acpi_target_system_state() · 99926a8c
      David Rientjes 提交于
      Commit b87b49cd0efd ("ACPI / PM: Move device PM functions related to sleep
      states") declared acpi_target_system_state() for CONFIG_PM_SLEEP whereas
      it is only defined for CONFIG_ACPI_SLEEP, resulting in the following link
      error:
      
      drivers/built-in.o: In function `acpi_pm_device_sleep_wake':
      drivers/acpi/device_pm.c:342: undefined reference to `acpi_target_system_state'
      drivers/built-in.o: In function `acpi_dev_suspend_late':
      drivers/acpi/device_pm.c:501: undefined reference to `acpi_target_system_state'
      drivers/built-in.o: In function `acpi_pm_device_sleep_state':
      drivers/acpi/device_pm.c:221: undefined reference to `acpi_target_system_state'
      
      Define it only for CONFIG_ACPI_SLEEP and fallback to a dummy definition
      for other configs.
      
      [rjw: The problem only occurs for exotic .configs in which
       HIBERNATE_CALLBACKS is selected by XEN_SAVE_RESTORE and neither
       SUSPEND nor HIBERNATION is set.]
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      99926a8c
    • R
      ACPI / PM: Move device PM functions related to sleep states · a6ae7594
      Rafael J. Wysocki 提交于
      Introduce helper function returning the target sleep state of the
      system and use it to move the remaining device power management
      functions from sleep.c to device_pm.c.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a6ae7594
    • R
      ACPI / PM: Provide device PM functions operating on struct acpi_device · 078eb126
      Rafael J. Wysocki 提交于
      If the caller of acpi_bus_set_power() already has a pointer to the
      struct acpi_device object corresponding to the device in question, it
      doesn't make sense for it to go through acpi_bus_get_device(), which
      may be costly, because it involves acquiring the global ACPI
      namespace mutex.
      
      For this reason, export the function operating on struct acpi_device
      objects used internally by acpi_bus_set_power(), so that it may be
      called instead of acpi_bus_set_power() in the above case, and change
      its name to acpi_device_set_power().
      
      Additionally, introduce two inline wrappers for checking ACPI PM
      capabilities of devices represented by struct acpi_device objects.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      078eb126
    • R
      ACPI / PM: Split device wakeup management routines · dee8370c
      Rafael J. Wysocki 提交于
      Two device wakeup management routines in device_pm.c and sleep.c,
      acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a
      device pointer argument and use it to obtain the ACPI handle of the
      corresponding ACPI namespace node.  That handle is then used to get
      the address of the struct acpi_device object corresponding to the
      struct device passed as the argument.
      
      Unfortunately, that last operation may be costly, because it involves
      taking the global ACPI namespace mutex, so it shouldn't be carried
      out too often.  However, the callers of those routines usually call
      them in a row with acpi_pm_device_sleep_state() which also takes that
      mutex for the same reason, so it would be more efficient if they ran
      acpi_bus_get_device() themselves to obtain a pointer to the struct
      acpi_device object in question and then passed that pointer to the
      appropriate PM routines.
      
      To make that possible, split each of the PM routines mentioned above
      in two parts, one taking a struct acpi_device pointer argument and
      the other implementing the current interface for compatibility.
      
      Additionally, change acpi_pm_device_run_wake() to actually return
      an error code if there is an error while setting up runtime remote
      wakeup for the device.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      dee8370c
    • R
      ACPI / PM: Move device power state selection routine to device_pm.c · 86b3832c
      Rafael J. Wysocki 提交于
      The ACPI function for choosing device power state is now located
      in drivers/acpi/sleep.c, but drivers/acpi/device_pm.c is a more
      logical place for it, so move it there.
      
      However, instead of moving the function entirely, move its core only
      under a different name and with a different list of arguments, so
      that it is more flexible, and leave a wrapper around it in the
      original location.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      86b3832c
    • R
      ACPI / PM: Move routines for adding/removing device wakeup notifiers · ec2cd81c
      Rafael J. Wysocki 提交于
      ACPI routines for adding and removing device wakeup notifiers are
      currently defined in a PCI-specific file, but they will be necessary
      for non-PCI devices too, so move them to a separate file under
      drivers/acpi and rename them to indicate their ACPI origins.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ec2cd81c
    • R
      ACPI / PM: Fix device PM kernedoc comments and #ifdefs · bdda27fb
      Rafael J. Wysocki 提交于
      The kerneldoc comments for acpi_pm_device_sleep_state(),
      acpi_pm_device_run_wake(), and acpi_pm_device_sleep_wake() are
      outdated or otherwise inaccurate and/or don't follow the common
      kerneldoc patterns, so fix them.
      
      Additionally, notice that acpi_pm_device_run_wake() should be under
      CONFIG_PM_RUNTIME rather than under CONFIG_PM_SLEEP, so fix that too.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bdda27fb
  6. 07 10月, 2012 1 次提交
    • L
      ACPI: Add new sysfs interface to export device description · d1efe3c3
      Lance Ortiz 提交于
      Add support to export the device description obtained from the ACPI _STR
      method, if one exists for a device, to user-space via a sysfs interface.
      This new interface provides a standard and platform neutral way for users
      to obtain the description text stored in the ACPI _STR method.  If no
      _STR method exists for the device, no sysfs 'description' file will be
      created.  The 'description' file will be located in the /sys/devices/
      directory using the device's path.
      
      /sys/device/<bus>/<bridge path>/<device path>.../firmware_node/description
      
      Example:
      
      /sys/devices/pci0000:00/0000:00.07.0/0000:0e:00.0/firmware_node/description
      
      It can also be located using the ACPI device path, for example:
      
      /sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/PNP0A08:00/device:13/device:15/description
      /sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/ACPI0004:01/ACPI0007:02/description
      
      Execute the 'cat' command on the 'description' file to obtain the
      description string for that device.
      
      This patch also includes documentation describing how the new sysfs
      interface works
      
      Changes from v1-v2 based on comments by Len Brown and Fengguang Wu
      * Removed output "No Description" and leaving a NULL attribute if the
      _STR method failed to evaluate.
      
      * In acpi_device_remove_files() removed the redundent check of
      dev->pnp.str_obj before calling free.  This check triggered a message
      from smatch.
      Signed-off-by: NLance Ortiz <lance.ortiz@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d1efe3c3
  7. 22 9月, 2012 2 次提交
    • M
      ACPI: introduce module_acpi_driver() helper macro · 0d2cf8f5
      Mika Westerberg 提交于
      Add a helper macro module_acpi_driver() which reduces the boilerplate code
      for ACPI drivers. This is similar what is done for other busses (PCI, SPI,
      I2C etc).
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      0d2cf8f5
    • L
      ACPI: Allow ACPI binding with USB-3.0 hub · 1033f904
      Lan Tianyu 提交于
      A USB port's position and connectability can't be identified on some boards
      via USB hub registers. ACPI _UPC and _PLD can help to resolve this issue
      and so it is necessary to bind USB with ACPI. This patch is to allow ACPI
      binding with USB-3.0 hub.
      
      Current ACPI only can bind one struct-device to one ACPI device node.
      This can not work with USB-3.0 hub, because the USB-3.0 hub has two logical
      devices. Each works for USB-2.0 and USB-3.0 devices. In the Linux USB subsystem,
      those two logical hubs are treated as two seperate devices that have two struct
      devices. But in the ACPI DSDT, these two logical hubs share one ACPI device
      node. So there is a requirement to bind multi struct-devices to one ACPI
      device node. This patch is to resolve such problem.
      
      Following is the ACPI device nodes' description under xhci hcd.
      
      Device (XHC)
                  Device (RHUB)
                      Device (HSP1)
                      Device (HSP2)
                      Device (HSP3)
                      Device (HSP4)
                      Device (SSP1)
                      Device (SSP2)
                      Device (SSP3)
                      Device (SSP4)
      
      Topology in the Linux
      
      	device XHC
      	   USB-2.0 logical hub    USB-3.0 logical hub
      		HSP1			SSP1
      		HSP2			SSP2
      		HSP3			SSP3
      		HSP4			SSP4
      
      This patch also modifies the output of /proc/acpi/wakeup. One ACPI node
      can be associated with multiple devices:
      
      XHC		S4	*enabled	pci:0000:00:14.0
      RHUB	S0	disabled	usb:usb1
      			disabled	usb:usb2
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      1033f904
  8. 21 9月, 2012 1 次提交
  9. 01 7月, 2012 2 次提交
  10. 24 6月, 2012 1 次提交
  11. 23 6月, 2012 1 次提交
  12. 04 6月, 2012 3 次提交
    • T
      ACPI: Add _OST support for sysfs eject · c4753e57
      Toshi Kani 提交于
      Changed acpi_bus_hot_remove_device() to support _OST. This function is
      also changed to global so that it can be called from hotplug notify
      handlers to perform hot-remove operation.
      
      Changed acpi_eject_store(), which is the sysfs eject handler. It checks
      eject_pending to see if the request was originated from ACPI eject
      notification. If not, it calls _OST(0x103,84,) per Figure 6-37 in ACPI
      5.0 spec.
      
      Added eject_pending bit to acpi_device_flags. This bit is set when the
      kernel has received an ACPI eject notification, but does not initiate
      its hot-remove operation by itself.
      
      Added struct acpi_eject_event. This structure is used to pass extended
      information to acpi_bus_hot_remove_device(), which has a single argument
      to support asynchronous call
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      c4753e57
    • T
      ACPI: Add an interface to evaluate _OST · 275c58d7
      Toshi Kani 提交于
      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: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      275c58d7
    • L
      ACPI: fix acpi_bus.h build warnings when ACPI is not enabled · 7ae30986
      Len Brown 提交于
      introduced in Linux-3.5-rc1 by
      66886d6f
      (ACPI: Add stubs for (un)register_acpi_bus_type)
      
      Fix header file warnings when CONFIG_ACPI is not enabled:
      
      include/acpi/acpi_bus.h:443:42: warning: 'struct acpi_bus_type' declared inside parameter list
      include/acpi/acpi_bus.h:443:42: warning: its scope is only this definition or declaration, which is probably not
      include/acpi/acpi_bus.h:444:44: warning: 'struct acpi_bus_type' declared inside parameter list
      Signed-off-by: NLen Brown <len.brown@intel.com>
      7ae30986
  13. 12 5月, 2012 2 次提交
  14. 30 3月, 2012 2 次提交
  15. 14 7月, 2011 1 次提交
  16. 15 3月, 2011 1 次提交
  17. 25 2月, 2011 1 次提交
    • R
      ACPI: Remove the wakeup.run_wake_count device field · 51907267
      Rafael J. Wysocki 提交于
      The wakeup.run_wake_count ACPI device field is only used by the PCI
      runtime PM code to "protect" devices from being prepared for
      generating wakeup signals more than once in a row.  However, it
      really doesn't provide any protection, because (1) all of the
      functions it is supposed to protect use their own reference counters
      effectively ensuring that the device will be set up for generating
      wakeup signals just once and (2) the PCI runtime PM code uses
      wakeup.run_wake_count in a racy way, since nothing prevents
      acpi_dev_run_wake() from being called concurrently from two different
      threads for the same device.
      
      Remove the wakeup.run_wake_count ACPI device field which is
      unnecessary, confusing and used in a wrong way.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      51907267
  18. 12 1月, 2011 1 次提交
    • R
      ACPI: Drop device flag wake_capable · d57d09a4
      Rafael J. Wysocki 提交于
      The wake_capable ACPI device flag is not necessary, because it is
      only used in scan.c for recording the information that _PRW is
      present for the given device.  That information is only used by
      acpi_add_single_object() to decide whether or not to call
      acpi_bus_get_wakeup_device_flags(), so the flag may be dropped
      if the _PRW check is moved to acpi_bus_get_wakeup_device_flags().
      Moreover, acpi_bus_get_wakeup_device_flags() always returns 0,
      so it really should be void.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d57d09a4