All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 22 Jun, 2013 1 commit
  2. 10 Jun, 2013 1 commit
  3. 07 Jun, 2013 1 commit
  4. 05 Jun, 2013 1 commit
    • Aaron Lu's avatar
      ACPI / scan: do not match drivers against objects having scan handlers · 9f29ab11
      Aaron Lu authored
      With the introduction of ACPI scan handlers, an ACPI device object
      with an ACPI scan handler attached to it must not be bound to an ACPI
      driver any more.  Therefore it doesn't make sense to match those
      ACPI device objects against a newly registered ACPI driver in
      acpi_bus_match(), so make that function return 0 if the device
      object passed to it has an ACPI scan handler attached.
      
      This also addresses a regression related to a broken ACPI table in
      the BIOS, where it has defined a _ROM method under the PCI root
      bridge object.  This causes the video module to treat that object
      as a display controller device (since only display devices are
      supposed to have a _ROM method defined according to the ACPI spec).
      As a result, the ACPI video driver binds to the PCI root bridge
      object and overwrites the previously assigned driver_data field of
      it, causing subsequent calls to acpi_get_pci_dev() to fail.
      
      [rjw: Subject and changelog]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=58091Reported-by: default avatarJason Cassell <bluesloth600@gmail.com>
      Reported-and-bisected-by: default avatarDmitry S. Demin <dmitryy.demin@gmail.com>
      Cc: 3.9+ <stable@kernel.org>
      Signed-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9f29ab11
  5. 15 May, 2013 1 commit
  6. 13 May, 2013 1 commit
  7. 12 Apr, 2013 1 commit
  8. 24 Mar, 2013 5 commits
    • Toshi Kani's avatar
      ACPI: Verify device status after eject · 882fd12e
      Toshi Kani authored
      ACPI spec states that the OS evaluates _STA after calling _EJ0
      in order to verify if eject was successful.  Added a check to
      verify if the enabled bit of the status value is cleared after
      _EJ0.
      
      Note, the present bit is not checked since some FW implementations
      do not clear the present bit until the hardware is physically
      removed.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      882fd12e
    • Toshi Kani's avatar
      ACPI: Update _OST handling for notify · 2cbb14fb
      Toshi Kani authored
      When the kernel calls _OSC with OSC_SB_HOTPLUG_OST_SUPPORT bit
      set at boot-time, the OS is responsible for calling _OST for
      ACPI hotplug events.  However, when hotplug.enabled attribute
      is unset for ACPI scan drivers, their notify handlers are removed
      and _OST is not called for ACPI hotplug events as a result.
      
      This patch keeps the notify handler of ACPI scan drivers,
      acpi_hotplug_notify_cb(), installed regardless of the state of
      hotplug.enabled.  The notify handler then checks if hotplug.enabled
      is set for the associated scan handler.  If unset, the notify
      handler calls _OST with a proper error code.  The patch also
      eliminates ACPI namespace walk when hotplug.enabled is changed
      via sysfs.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2cbb14fb
    • Toshi Kani's avatar
      ACPI: Update PNPID match handling for notify · 6b772e8f
      Toshi Kani authored
      When installing/removing a notify handler to/from an ACPI device
      object, ACPI core tries to match its associated scan handler to
      see if it supports hotplug.  However, the matching logic of the
      notify handler is different from the matching logic of attaching
      a scan handler to an ACPI device object.  This patch updates the
      matching logic of the notify handlers to be consistent with the
      attach handling.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6b772e8f
    • Toshi Kani's avatar
      ACPI: Update PNPID set/free interfaces · c0af4175
      Toshi Kani authored
      This patch introduces acpi_set_pnp_ids() and acpi_free_pnp_ids(),
      which are updated from acpi_device_set_id() and acpi_free_ids(),
      to setup and free acpi_device_pnp for a given acpi_handle.  They
      can be called without acpi_device.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c0af4175
    • Toshi Kani's avatar
      ACPI: Remove acpi_device dependency in acpi_device_set_id() · d4e1a692
      Toshi Kani authored
      This patch updates the internal operations of acpi_device_set_id()
      to setup acpi_device_pnp without using acpi_device.  There is no
      functional change to acpi_device_set_id() in this patch.
      
      acpi_pnp_type is added to acpi_device_pnp, so that PNPID type is
      self-contained within acpi_device_pnp.  acpi_add_id(), acpi_bay_match(),
      acpi_dock_match(), acpi_ibm_smbus_match() and acpi_is_video_device()
      are changed to take acpi_handle as an argument, instead of acpi_device.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d4e1a692
  9. 21 Mar, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices · f58b082a
      Rafael J. Wysocki authored
      Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some
      common features that aren't shared with any other platform devices,
      including the clock and LTR (Latency Tolerance Reporting) registers.
      It is better to handle those features in common code than to bother
      device drivers with doing that (I/O functionality-wise the LPSS
      devices are generally compatible with other devices that don't
      have those special registers and may be handled by the same drivers).
      
      The clock registers of the LPSS devices are now taken care of by
      the special clk-x86-lpss driver, but the MMIO mappings used for
      accessing those registers can also be used for accessing the LTR
      registers on those devices (LTR support for the Lynxpoint LPSS is
      going to be added by a subsequent patch).  Thus it is convenient
      to add a special ACPI scan handler for the Lynxpoint LPSS devices
      that will create the MMIO mappings for accessing the clock (and
      LTR in the future) registers and will register the LPSS devices'
      clocks, so the clk-x86-lpss driver will only need to take care of
      the main Lynxpoint LPSS clock.
      
      Introduce a special ACPI scan handler for Intel Lynxpoint LPSS
      devices as described above.  This also reduces overhead related to
      browsing the ACPI namespace in search of the LPSS devices before the
      registration of their clocks, removes some LPSS-specific (and
      somewhat ugly) code from acpi_platform.c and shrinks the overall code
      size slightly.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarMike Turquette <mturquette@linaro.org>
      f58b082a
  10. 04 Mar, 2013 5 commits
  11. 23 Feb, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PM: Take unusual configurations of power resources into account · b5d667eb
      Rafael J. Wysocki authored
      Commit d2e5f0c1 (ACPI / PCI: Rework the setup and cleanup of device
      wakeup) moved the initial disabling of system wakeup for PCI devices
      into a place where it can actually work and that exposed a hidden old
      issue with crap^Wunusual system designs where the same power
      resources are used for both wakeup power and device power control at
      run time.
      
      Namely, say there is one power resource such that the ACPI power
      state D0 of a PCI device depends on that power resource (i.e. the
      device is in D0 when that power resource is "on") and it is used
      as a wakeup power resource for the same device.  Then, calling
      acpi_pci_sleep_wake(pci_dev, false) for the device in question will
      cause the reference counter of that power resource to drop to 0,
      which in turn will cause it to be turned off.  As a result, the
      device will go into D3cold at that point, although it should have
      stayed in D0.
      
      As it turns out, that happens to USB controllers on some laptops
      and USB becomes unusable on those machines as a result, which is
      a major regression from v3.8.
      
      To fix this problem, (1) increment the reference counters of wakup
      power resources during their initialization if they are "on"
      initially, (2) prevent acpi_disable_wakeup_device_power() from
      decrementing the reference counters of wakeup power resources that
      were not enabled for wakeup power previously, and (3) prevent
      acpi_enable_wakeup_device_power() from incrementing the reference
      counters of wakeup power resources that already are enabled for
      wakeup power.
      
      In addition to that, if it is impossible to determine the initial
      states of wakeup power resources, avoid enabling wakeup for devices
      whose wakeup power depends on those power resources.
      Reported-by: default avatarDave Jones <davej@redhat.com>
      Reported-by: default avatarFabio Baltieri <fabio.baltieri@linaro.org>
      Tested-by: default avatarFabio Baltieri <fabio.baltieri@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b5d667eb
  12. 15 Feb, 2013 1 commit
  13. 13 Feb, 2013 8 commits
    • Rafael J. Wysocki's avatar
      ACPI / hotplug: Fix concurrency issues and memory leaks · 3757b948
      Rafael J. Wysocki authored
      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: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      3757b948
    • Rafael J. Wysocki's avatar
      ACPI / scan: Full transition to D3cold in acpi_device_unregister() · 0aa120a0
      Rafael J. Wysocki authored
      In order to drop reference counts of all power resources used by an
      ACPI device node being removed, acpi_device_unregister() calls
      acpi_power_transition(device, ACPI_STATE_D3_COLD), which effectively
      transitions the device node into D3cold if it uses any power
      resources.  However, for some device nodes it may not be appropriate
      to remove power from them entirely before putting them into D3hot
      before.  On the other hand, executing _PS3 for devices that don't
      use power resources before removing them shouldn't really hurt.
      In fact, that is done by acpi_bus_hot_remove_device(), but this is
      not the right place to do it, because the bus trimming may have
      caused power to be removed from the device node in question already
      before.
      
      For these reasons, make acpi_device_unregister() carry out full
      power-off transition for all device nodes supporting that and remove
      the direct evaluation of _PS3 from acpi_bus_hot_remove_device().
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0aa120a0
    • Rafael J. Wysocki's avatar
      ACPI / scan: Make acpi_bus_hot_remove_device() acquire the scan lock · f058cdf4
      Rafael J. Wysocki authored
      The ACPI scan lock has been introduced to prevent acpi_bus_scan()
      and acpi_bus_trim() from running in parallel with each other for
      overlapping ACPI namespace scopes.  However, it is not sufficient
      to do that, because if acpi_bus_scan() is run (for an overlapping
      namespace scope) right after the acpi_bus_trim() in
      acpi_bus_hot_remove_device(), the subsequent eject will remove
      devices without removing the corresponding struct acpi_device
      objects (and possibly companion "physical" device objects).
      Therefore acpi_bus_hot_remove_device() has to acquire the scan
      lock before carrying out the bus trimming and hold it through
      the evaluation of _EJ0, so make that happen.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarToshi Kani <toshi.kani@hp.com>
      f058cdf4
    • Rafael J. Wysocki's avatar
      ACPI / scan: Make container driver use struct acpi_scan_handler · 737f1a9f
      Rafael J. Wysocki authored
      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: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Tested-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Reviewed-by: default avatarToshi Kani <toshi.kani@hp.com>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      737f1a9f
    • Rafael J. Wysocki's avatar
      ACPI / scan: Remove useless #ifndef from acpi_eject_store() · 38475b3b
      Rafael J. Wysocki authored
      Since the FORCE_EJECT symbol is never defined, the
      #ifndef FORCE_EJECT in acpi_eject_store() is always true, so drop it.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Tested-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Reviewed-by: default avatarToshi Kani <toshi.kani@hp.com>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      38475b3b
    • Toshi Kani's avatar
      ACPI: Unbind ACPI drv when probe failed · 5f27ee8e
      Toshi Kani authored
      When acpi_device_install_notify_handler() failed in acpi_device_probe(),
      it calls acpi_drv->ops.remove() and fails the probe.  However, the ACPI
      driver is left bound to the acpi_device.  Fix it by clearing the driver
      and driver_data fields.
      Signed-off-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5f27ee8e
    • Toshi Kani's avatar
      ACPI: sysfs eject support for ACPI scan handlers · ce7685ad
      Toshi Kani authored
      Changed sysfs eject, acpi_eject_store(), so that it doesn't return
      error codes for devices nodes with ACPI scan handlers attached and
      no ACPI drivers.
      
      [rjw: Changelog]
      Signed-off-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ce7685ad
    • Rafael J. Wysocki's avatar
      ACPI / scan: Follow priorities of IDs when matching scan handlers · 87b85b3c
      Rafael J. Wysocki authored
      The IDs of ACPI device nodes stored in their pnp.ids member arrays
      are sorted by decreasing priority (i.e. the highest-priority ID is
      the first entry).  This means that when matching scan handlers to
      device nodes, the namespace scanning code should walk the list of
      scan handlers for each device node ID instead of walking the list
      of device node IDs for each handler (the latter causes the first
      handler matching any of the device node IDs to be chosen, although
      there may be another handler matching an ID of a higher priority
      which should be preferred).  Make the code follow this observation.
      
      This change has been suggested and justified by Toshi Kani.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarToshi Kani <toshi.kani@hp.com>
      87b85b3c
  14. 01 Feb, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PM: Do not power manage devices in unknown initial states · b3785492
      Rafael J. Wysocki authored
      In general, for ACPI device power management to work, the initial
      power states of devices must be known (otherwise, we wouldn't be able
      to keep track of power resources, for example).  Hence, if it is
      impossible to determine the initial ACPI power states of some
      devices, they can't be regarded as power-manageable using ACPI.
      
      For this reason, modify acpi_bus_get_power_flags() to clear the
      power_manageable flag if acpi_bus_init_power() fails and add some
      extra fallback code to acpi_bus_init_power() to cover broken
      BIOSes that provide _PS0/_PS3 without _PSC for some devices.
      
      Verified to work on my HP nx6325 that has this problem.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarPeter Wu <lekensteyn@gmail.com>
      b3785492
  15. 31 Jan, 2013 2 commits
  16. 30 Jan, 2013 3 commits
  17. 29 Jan, 2013 1 commit
  18. 27 Jan, 2013 1 commit
  19. 25 Jan, 2013 3 commits
  20. 24 Jan, 2013 1 commit