1. 17 3月, 2015 1 次提交
    • R
      ACPI: Introduce has_acpi_companion() · ca5b74d2
      Rafael J. Wysocki 提交于
      Now that the ACPI companions of devices are represented by pointers
      to struct fwnode_handle, it is not quite efficient to check whether
      or not an ACPI companion of a device is present by evaluating the
      ACPI_COMPANION() macro.
      
      For this reason, introduce a special static inline routine for that,
      has_acpi_companion(), and update the code to use it where applicable.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ca5b74d2
  2. 11 2月, 2014 1 次提交
    • R
      ACPI / scan: Add bind/unbind callbacks to struct acpi_scan_handler · 9cb32acf
      Rafael J. Wysocki 提交于
      In some cases it may be necessary to perform certain setup/cleanup
      operations on a device object representing a physical device after
      it has been associated with an ACPI companion by acpi_bind_one() or
      before disassociating it from that companion by acpi_unbind_one(),
      respectively.  If there is a struct acpi_bus_type object for the
      given device's bus type, the .setup()/.cleanup() callbacks from there
      are executed for these purposes.  However, an analogous mechanism will
      be necessary for devices whose bus types don't have corresponding
      struct acpi_bus_type objects and that have specific ACPI scan handlers.
      
      For those devices, add new .bind() and .unbind() callbacks to struct
      acpi_scan_handler that will be executed by acpi_platform_notify()
      right after the given device has been associated with an ACPI
      comapnion and by acpi_platform_notify_remove() right before calling
      acpi_unbind_one() for that device, respectively.
      
      To make that work for scan handlers registering new devices in their
      .attach() callbacks, modify acpi_scan_attach_handler() to set the
      ACPI device object's handler field before calling .attach() from the
      scan handler at hand.
      
      This changeset includes a fix from Mika Westerberg.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9cb32acf
  3. 07 12月, 2013 7 次提交
  4. 15 11月, 2013 2 次提交
    • R
      ACPI / bind: Use (put|get)_device() on ACPI device objects too · a104b4d4
      Rafael J. Wysocki 提交于
      When associating a "physical" device with an ACPI device object
      acpi_bind_one() only uses get_device() to increment the reference
      counter of the former, but there is no reason not to do that with
      the latter too.  Among other things, that may help to avoid
      use-after-free when an ACPI device object is freed without calling
      acpi_unbind_one() for all "physical" devices associated with it
      (that only can happen in buggy code, but then it's better if the
      kernel doesn't crash as a result of a bug).
      
      For this reason, modify acpi_bind_one() to apply get_device() to
      the ACPI device object too and update acpi_unbind_one() to drop
      that reference using put_device() as appropriate.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: NLan Tianyu <tianyu.lan@intel.com>
      a104b4d4
    • R
      ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node · 7b199811
      Rafael J. Wysocki 提交于
      Modify struct acpi_dev_node to contain a pointer to struct acpi_device
      associated with the given device object (that is, its ACPI companion
      device) instead of an ACPI handle corresponding to it.  Introduce two
      new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
      ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
      ACPI_HANDLE() macro to take the above changes into account.
      Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
      use ACPI_COMPANION_SET() instead.  For some of them who used to
      pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
      introduce a helper routine acpi_preset_companion() doing an
      equivalent thing.
      
      The main motivation for doing this is that there are things
      represented by struct acpi_device objects that don't have valid
      ACPI handles (so called fixed ACPI hardware features, such as
      power and sleep buttons) and we would like to create platform
      device objects for them and "glue" them to their ACPI companions
      in the usual way (which currently is impossible due to the
      lack of valid ACPI handles).  However, there are more reasons
      why it may be useful.
      
      First, struct acpi_device pointers allow of much better type checking
      than void pointers which are ACPI handles, so it should be more
      difficult to write buggy code using modified struct acpi_dev_node
      and the new macros.  Second, the change should help to reduce (over
      time) the number of places in which the result of ACPI_HANDLE() is
      passed to acpi_bus_get_device() in order to obtain a pointer to the
      struct acpi_device associated with the given "physical" device,
      because now that pointer is returned by ACPI_COMPANION() directly.
      Finally, the change should make it easier to write generic code that
      will build both for CONFIG_ACPI set and unset without adding explicit
      compiler directives to it.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
      7b199811
  5. 10 9月, 2013 1 次提交
  6. 09 8月, 2013 2 次提交
  7. 08 8月, 2013 7 次提交
  8. 06 8月, 2013 1 次提交
    • R
      ACPI: Drop physical_node_id_bitmap from struct acpi_device · 007ccfcf
      Rafael J. Wysocki 提交于
      The physical_node_id_bitmap in struct acpi_device is only used for
      looking up the first currently unused dependent phyiscal node ID
      by acpi_bind_one().  It is not really necessary, however, because
      acpi_bind_one() walks the entire physical_node_list of the given
      device object for sanity checking anyway and if that list is always
      sorted by node_id, it is straightforward to find the first gap
      between the currently used node IDs and use that number as the ID
      of the new list node.
      
      This also removes the artificial limit of the maximum number of
      dependent physical devices per ACPI device object, which now depends
      only on the capacity of unsigend int.  As a result, it fixes a
      regression introduced by commit e2ff3940 (ACPI / memhotplug: Bind
      removable memory blocks to ACPI device nodes) that caused
      acpi_memory_enable_device() to fail when the number of 128 MB blocks
      within one removable memory module was greater than 32.
      Reported-and-tested-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      007ccfcf
  9. 20 6月, 2013 1 次提交
    • J
      ACPI: add _STA evaluation at do_acpi_find_child() · c7d9ca90
      Jeff Wu 提交于
      Once do_acpi_find_child() has found the first matching handle, it
      makes the acpi_get_child() loop stop and return that handle.  On some
      platforms, though, there are multiple devices with the same value of
      "_ADR" in the same namespace scope, and if one of them is enabled,
      the others will be disabled.  For example:
      
       Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV0
       Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV1
       Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV2
      
      If DEV0 and DEV1 are disabled and DEV2 is enabled, the handle of DEV2
      should be returned, but actually the function always returns the
      handle of DEV0.
      
      To address that issue, make do_acpi_find_child() evaluate _STA to
      check the device status.  If a matching device object exists, but is
      disabled, acpi_get_child() will continue to walk the namespace in the
      hope of finding an enabled one.  If one is found, its handle will be
      returned, but otherwise the function will return the handle of the
      disabled object found before (in case it is enabled going forward).
      
      [rjw: Changelog]
      Signed-off-by: NJeff Wu <zlinuxkernel@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c7d9ca90
  10. 12 5月, 2013 1 次提交
    • R
      ACPI / processor: Use common hotplug infrastructure · ac212b69
      Rafael J. Wysocki 提交于
      Split the ACPI processor driver into two parts, one that is
      non-modular, resides in the ACPI core and handles the enumeration
      and hotplug of processors and one that implements the rest of the
      existing processor driver functionality.
      
      The non-modular part uses an ACPI scan handler object to enumerate
      processors on the basis of information provided by the ACPI namespace
      and to hook up with the common ACPI hotplug infrastructure.  It also
      populates the ACPI handle of each processor device having a
      corresponding object in the ACPI namespace, which allows the driver
      proper to bind to those devices, and makes the driver bind to them
      if it is readily available (i.e. loaded) when the scan handler's
      .attach() routine is running.
      
      There are a few reasons to make this change.
      
      First, switching the ACPI processor driver to using the common ACPI
      hotplug infrastructure reduces code duplication and size considerably,
      even though a new file is created along with a header comment etc.
      
      Second, since the common hotplug code attempts to offline devices
      before starting the (non-reversible) removal procedure, it will abort
      (and possibly roll back) hot-remove operations involving processors
      if cpu_down() returns an error code for one of them instead of
      continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
      is unset).  That is a more desirable behavior than what the current
      code does.
      
      Finally, the separation of the scan/hotplug part from the driver
      proper makes it possible to simplify the driver's .remove() routine,
      because it doesn't need to worry about the possible cleanup related
      to processor removal any more (the scan/hotplug part is responsible
      for that now) and can handle device removal and driver removal
      symmetricaly (i.e. as appropriate).
      
      Some user-visible changes in sysfs are made (for example, the
      'sysdev' link from the ACPI device node to the processor device's
      directory is gone and a 'physical_node' link is present instead
      and a corresponding 'firmware_node' is present in the processor
      device's directory, the processor driver is now visible under
      /sys/bus/cpu/drivers/ and bound to the processor device), but
      that shouldn't affect the functionality that users care about
      (frequency scaling, C-states and thermal management).
      
      Tested on my venerable Toshiba Portege R500.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Reviewed-by: NToshi Kani <toshi.kani@hp.com>
      ac212b69
  11. 04 3月, 2013 2 次提交
  12. 26 1月, 2013 1 次提交
    • R
      ACPI: Rework acpi_get_child() to be more efficient · 33f767d7
      Rafael J. Wysocki 提交于
      Observe that acpi_get_child() doesn't need to use the helper
      struct acpi_find_child structure and change it to work without it.
      Also, using acpi_get_object_info() to get the output of _ADR for the
      given device is overkill, because that function does much more than
      just evaluating _ADR (let alone the additional memory allocation
      done by it).
      
      Moreover, acpi_get_child() doesn't need to loop any more once it has
      found a matching handle, so make it stop in that case.  To prevent
      the results from changing, make it use do_acpi_find_child() as
      a post-order callback.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      33f767d7
  13. 12 1月, 2013 1 次提交
  14. 03 1月, 2013 2 次提交
    • J
      ACPI / glue: Update DBG macro to include KERN_DEBUG · 23415eb5
      Joe Perches 提交于
      Currently these DBG statements are emitted at KERN_DEFAULT.
      Change the macro to emit at KERN_DEBUG.
      
      This can help avoid unexpected message interleaving.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      23415eb5
    • 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
  15. 21 11月, 2012 2 次提交
    • R
      ACPI / driver core: Introduce struct acpi_dev_node and related macros · 95f8a082
      Rafael J. Wysocki 提交于
      To avoid adding an ACPI handle pointer to struct device on
      architectures that don't use ACPI, or generally when CONFIG_ACPI is
      not set, in which cases that pointer is useless, define struct
      acpi_dev_node that will contain the handle pointer if CONFIG_ACPI is
      set and will be empty otherwise and use it to represent the ACPI
      device node field in struct device.
      
      In addition to that define macros for reading and setting the ACPI
      handle of a device that don't generate code when CONFIG_ACPI is
      unset.  Modify the ACPI subsystem to use those macros instead of
      referring to the given device's ACPI handle directly.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      95f8a082
    • R
      ACPI: Allow ACPI handles of devices to be initialized in advance · f3fd0c8a
      Rafael J. Wysocki 提交于
      Currently, the ACPI handles of devices are initialized from within
      device_add(), by acpi_bind_one() called from acpi_platform_notify()
      which first uses the .find_device() routine provided by the device's
      bus type to find the matching device node in the ACPI namespace.
      This is a source of some computational overhead and, moreover, the
      correctness of the result depends on the implementation of
      .find_device() which is known to fail occasionally for some bus types
      (e.g. PCI).  In some cases, however, the corresponding ACPI device
      node is known already before calling device_add() for the given
      struct device object and the whole .find_device() dance in
      acpi_platform_notify() is then simply unnecessary.
      
      For this reason, make it possible to initialize the ACPI handles of
      devices before calling device_add() for them.  Modify
      acpi_platform_notify() to call acpi_bind_one() in advance to check
      the device's existing ACPI handle and skip the .find_device()
      search if that is successful.  Change acpi_bind_one() accordingly.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      f3fd0c8a
  16. 15 11月, 2012 1 次提交
    • 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
  17. 23 10月, 2012 1 次提交
  18. 22 9月, 2012 1 次提交
    • 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
  19. 26 7月, 2012 1 次提交
  20. 29 6月, 2012 1 次提交
  21. 12 5月, 2012 1 次提交
  22. 01 11月, 2011 1 次提交
  23. 07 1月, 2011 1 次提交