1. 20 Nov, 2017 1 commit
    • Lv Zheng's avatar
      ACPI / EC: Fix regression related to PM ops support in ECDT device · a64a62ce
      Lv Zheng authored
      On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT
      EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an
      ACPI device. Thus the following commit actually removed post-resume
      acpi_ec_enable_event() invocation for such platforms, and triggered a
      regression on them that after being resumed, EC (actually should be ECDT)
      driver stops handling EC events:
      
       Commit: c2b46d67
       Subject: ACPI / EC: Add PM operations to improve event handling for resume process
      
      Notice that the root cause actually is "ECDT is not an ACPI device" rather
      than "the timing of acpi_ec_enable_event() invocation", this patch fixes
      this issue by enumerating ECDT EC as an ACPI device. Due to the existence
      of the noirq stage, the ability of tuning the timing of
      acpi_ec_enable_event() invocation is still meaningful.
      
      This patch is a little bit different from the posted fix by moving
      acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make
      sure that EC event handling won't be stopped as long as the ACPI EC driver
      is bound. Thus the following sequence shouldn't disable EC event handling:
      unbind,suspend,resume,bind.
      
      Fixes: c2b46d67 (ACPI / EC: Add PM operations to improve event handling for resume process)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847Reported-by: default avatarLuya Tshimbalanga <luya@fedoraproject.org>
      Tested-by: default avatarLuya Tshimbalanga <luya@fedoraproject.org>
      Cc: 4.9+ <stable@vger.kernel.org> # 4.9+
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a64a62ce
  2. 20 Oct, 2017 1 commit
  3. 11 Oct, 2017 1 commit
    • Srinivas Pandruvada's avatar
      ACPI / LPIT: Add Low Power Idle Table (LPIT) support · eeb2d80d
      Srinivas Pandruvada authored
      Add functionality to read LPIT table, which provides:
      
       - Sysfs interface to read residency counters via
         /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
         /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
      
      Here the count "low_power_idle_cpu_residency_us" shows the time spent
      by CPU package in low power state.  This is read via MSR interface,
      which points to MSR for PKG C10.
      
      Here the count "low_power_idle_system_residency_us" show the count the
      system was in low power state. This is read via MMIO interface. This
      is mapped to SLP_S0 residency on modern Intel systems. This residency
      is achieved only when CPU is in PKG C10 and all functional blocks are
      in low power state.
      
      It is possible that none of the above counters present or anyone of the
      counter present or all counters present.
      
      For example: On my Kabylake system both of the above counters present.
      After suspend to idle these counts updated and prints:
      
       6916179
       6998564
      
      This counter can be read by tools like turbostat to display. Or it can
      be used to debug, if modern systems are reaching desired low power state.
      
       - Provides an interface to read residency counter memory address
      
         This address can be used to get the base address of PMC memory
         mapped IO.  This is utilized by intel_pmc_core driver to print
         more debug information.
      
      In addition, to avoid code duplication to read iomem, removed the read of
      iomem from acpi_os_read_memory() in osl.c and made a common function
      acpi_os_read_iomem(). This new function is used for reading iomem in
      in both osl.c and acpi_lpit.c.
      
      Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdfSigned-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eeb2d80d
  4. 17 Aug, 2017 2 commits
  5. 07 Aug, 2017 2 commits
    • Lorenzo Pieralisi's avatar
      ACPI: Make acpi_dma_configure() DMA regions aware · 7ad42639
      Lorenzo Pieralisi authored
      Current ACPI DMA configuration set-up device DMA capabilities through
      kernel defaults that do not take into account platform specific DMA
      configurations reported by firmware.
      
      By leveraging the ACPI acpi_dev_get_dma_resources() API, add code
      in acpi_dma_configure() to retrieve the DMA regions to correctly
      set-up PCI devices DMA parameters.
      
      Rework the ACPI IORT kernel API to make sure they can accommodate
      the DMA set-up required by firmware. By making PCI devices DMA set-up
      ACPI IORT specific, the kernel is shielded from unwanted regressions
      that could be triggered by parsing DMA resources on arches that were
      previously ignoring them (ie x86/ia64), leaving kernel behaviour
      unchanged on those arches.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Tested-by: default avatarNate Watterson <nwatters@codeaurora.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7ad42639
    • Lorenzo Pieralisi's avatar
      ACPI: Introduce DMA ranges parsing · c04ac679
      Lorenzo Pieralisi authored
      Some devices have limited addressing capabilities and cannot
      reference the whole memory address space while carrying out DMA
      operations (eg some devices with bus address bits range smaller than
      system bus - which prevents them from using bus addresses that are
      otherwise valid for the system).
      
      The ACPI _DMA object allows bus devices to define the DMA window that is
      actually addressable by devices that sit upstream the bus, therefore
      providing a means to parse and initialize the devices DMA masks and
      addressable DMA range size.
      
      By relying on the generic ACPI kernel layer to retrieve and parse
      resources, introduce ACPI core code to parse the _DMA object.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: default avatarNate Watterson <nwatters@codeaurora.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c04ac679
  6. 03 Aug, 2017 1 commit
  7. 21 Jul, 2017 1 commit
  8. 04 Jul, 2017 1 commit
    • Lee, Chun-Yi's avatar
      ACPI / scan: Indicate to platform when hot remove returns busy · d429e5c1
      Lee, Chun-Yi authored
      In hotplug logic, it always indicates non-specific failure to
      platform through _OST when handing ACPI hot-remove event failed. Then
      platform terminates the hot-remove process but it can not identify
      the reason.
      
      Base on current hot-remove code, there have two situations that it
      returns busy:
      
       - OSPM try to offline an individual device, but the device offline
         function returns "busy".
      
       - When the ejection event is applied to an "not offlined yet"
         container.  OSPM sends a kobject change event to userspace and
         returns "busy".
      
      Both of them will returns -EBUSY to ACPI device hotplug function.
      Then, the hotplug function indicates non-specific failure to platform
      just like for any other error, e.g. -ENODEV or -EIO.
      
      The benefit to the platform for identifying the OS "busy" state is
      that it can use a different approach to handle the "busy" instead of
      simply terminating the hot-remove operation for an unknown reason.
      For example, the platform can wait for a while and then re-trigger
      hot-remove.
      Signed-off-by: default avatar"Lee, Chun-Yi" <jlee@suse.com>
      Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      [ rjw: Changelog massage ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d429e5c1
  9. 27 Jun, 2017 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / PM: Drop run_wake from struct acpi_device_wakeup_flags · a1a66393
      Rafael J. Wysocki authored
      The run_wake flag in struct acpi_device_wakeup_flags stores the
      information on whether or not the device can generate wakeup
      signals at run time, but in ACPI that really is equivalent to
      being able to generate wakeup signals at all.
      
      In fact, run_wake will always be set after successful executeion of
      acpi_setup_gpe_for_wake(), but if that fails, the device will not be
      able to use a wakeup GPE at all, so it won't be able to wake up the
      systems from sleep states too.  Hence, run_wake actually means that
      the device is capable of triggering wakeup and so it is equivalent
      to the valid flag.
      
      For this reason, drop run_wake from struct acpi_device_wakeup_flags
      and make sure that the valid flag is only set if
      acpi_setup_gpe_for_wake() has been successful.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      a1a66393
  10. 22 Jun, 2017 2 commits
  11. 21 Jun, 2017 1 commit
    • Jarkko Nikula's avatar
      ACPI / scan: Fix enumeration for special SPI and I2C devices · e4330d8b
      Jarkko Nikula authored
      Commit f406270b ("ACPI / scan: Set the visited flag for all
      enumerated devices") caused that two group of special SPI or I2C
      devices do not enumerate. SPI and I2C devices are expected to be
      enumerated by the SPI and I2C subsystems but change caused that
      acpi_bus_attach() marks those devices with acpi_device_set_enumerated().
      
      First group of devices are matched using Device Tree compatible property
      with special _HID "PRP0001". Those devices have matched scan handler,
      acpi_scan_attach_handler() retuns 1 and acpi_bus_attach() marks them
      with acpi_device_set_enumerated().
      
      Second group of devices without valid _HID such as "LNXVIDEO" have
      device->pnp.type.platform_id set to zero and change again marks them
      with acpi_device_set_enumerated().
      
      Fix this by flagging the SPI and I2C devices during struct acpi_device
      object initialization time and let the code in acpi_bus_attach() to go
      through the device_attach() and acpi_default_enumeration() path for all
      SPI and I2C devices.
      
      Fixes: f406270b (ACPI / scan: Set the visited flag for all enumerated devices)
      Signed-off-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: 4.11+ <stable@vger.kernel.org> # 4.11+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e4330d8b
  12. 30 May, 2017 1 commit
    • Sricharan R's avatar
      ACPI/IORT: Ignore all errors except EPROBE_DEFER · 058f8c3f
      Sricharan R authored
      While deferring the probe of IOMMU masters, xlate and
      add_device callbacks called from iort_iommu_configure
      can pass back error values like -ENODEV, which means
      the IOMMU cannot be connected with that master for real
      reasons. Before the IOMMU probe deferral, all such errors
      were ignored. Now all those errors are propagated back,
      killing the master's probe for such errors. Instead ignore
      all the errors except EPROBE_DEFER, which is the only one
      of concern and let the master work without IOMMU, thus
      restoring the old behavior. Also make explicit that
      acpi_dma_configure handles only -EPROBE_DEFER from
      iort_iommu_configure.
      
      Fixes: 5a1bb638 ("drivers: acpi: Handle IOMMU lookup failure with deferred probing or error")
      Signed-off-by: default avatarSricharan R <sricharan@codeaurora.org>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      058f8c3f
  13. 20 Apr, 2017 1 commit
    • Sricharan R's avatar
      drivers: acpi: Handle IOMMU lookup failure with deferred probing or error · 5a1bb638
      Sricharan R authored
      This is an equivalent to the DT's handling of the iommu master's probe
      with deferred probing when the corrsponding iommu is not probed yet.
      The lack of a registered IOMMU can be caused by the lack of a driver for
      the IOMMU, the IOMMU device probe not having been performed yet, having
      been deferred, or having failed.
      
      The first case occurs when the firmware describes the bus master and
      IOMMU topology correctly but no device driver exists for the IOMMU yet
      or the device driver has not been compiled in. Return NULL, the caller
      will configure the device without an IOMMU.
      
      The second and third cases are handled by deferring the probe of the bus
      master device which will eventually get reprobed after the IOMMU.
      
      The last case is currently handled by deferring the probe of the bus
      master device as well. A mechanism to either configure the bus master
      device without an IOMMU or to fail the bus master device probe depending
      on whether the IOMMU is optional or mandatory would be a good
      enhancement.
      Tested-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
      [Lorenzo: Added fixes for dma_coherent_mask overflow, acpi_dma_configure
                called multiple times for same device]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarSricharan R <sricharan@codeaurora.org>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      5a1bb638
  14. 19 Apr, 2017 2 commits
  15. 13 Apr, 2017 2 commits
    • Rafael J. Wysocki's avatar
      ACPI / scan: Set the visited flag for all enumerated devices · f406270b
      Rafael J. Wysocki authored
      Commit 10c7e20b (ACPI / scan: fix enumeration (visited) flags for
      bus rescans) attempted to fix a problem with ACPI-based enumerateion
      of I2C/SPI devices, but it forgot to ensure that the visited flag
      will be set for all of the other enumerated devices, so fix that.
      
      Fixes: 10c7e20b (ACPI / scan: fix enumeration (visited) flags for bus rescans)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=194885Reported-and-tested-by: default avatarKevin Locke <kevin@kevinlocke.name>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: 4.8+ <stable@vger.kernel.org> # 4.8+
      f406270b
    • Michal Hocko's avatar
      ACPI / scan: Drop support for force_remove · ffc10d82
      Michal Hocko authored
      /sys/firmware/acpi/hotplug/force_remove was presumably added to support
      auto offlining in the past. This is, however, inherently dangerous for
      some hotplugable resources like memory. The memory offlining fails when
      the memory is still in use and cannot be dropped or migrated. If we
      ignore the failure we are basically allowing for subtle memory
      corruption or a crash.
      
      We have actually noticed the later while hitting BUG() during the memory
      hotremove (remove_memory):
      	ret = walk_memory_range(PFN_DOWN(start), PFN_UP(start + size - 1), NULL,
      			check_memblock_offlined_cb);
      	if (ret)
      		BUG();
      
      it took us quite non-trivial time realize that the customer had
      force_remove enabled. Even if the BUG was removed here and we could
      propagate the error up the call chain it wouldn't help at all because
      then we would hit a crash or a memory corruption later and harder to
      debug. So force_remove is unfixable for the memory hotremove. We haven't
      checked other hotplugable resources to be prone to a similar problems.
      
      Remove the force_remove functionality because it is not fixable currently.
      Keep the sysfs file and report an error if somebody tries to enable it.
      Encourage users to report about the missing functionality and work with
      them with an alternative solution.
      Reviewed-by: default avatarLee, Chun-Yi <jlee@suse.com>
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ffc10d82
  16. 26 Dec, 2016 1 commit
  17. 06 Dec, 2016 1 commit
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Make dma masks set-up IORT specific · 18b709be
      Lorenzo Pieralisi authored
      The introduction of acpi_dma_configure() allows to configure DMA
      and related IOMMU for any device that is DMA capable. To achieve
      that goal it ensures DMA masks are set-up to sane default values
      before proceeding with IOMMU and DMA ops configuration.
      
      On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
      called for every device that has an ACPI companion, in that every device
      is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
      which has the side effect of initializing dma masks also for
      pseudo-devices (eg CPUs and memory nodes) and potentially for devices
      whose dma masks were not set-up before the acpi_dma_configure() API was
      introduced, which may have noxious side effects.
      
      Therefore, in preparation for IORT firmware specific DMA masks set-up,
      wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
      specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
      default expected behaviour on x86/ia64 systems and keeping DMA default
      masks set-up on IORT based (ie ARM) arch configurations.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Tested-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Tomasz Nowicki <tn@semihalf.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Sricharan R <sricharan@codeaurora.org>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      18b709be
  18. 29 Nov, 2016 3 commits
    • Zhang Rui's avatar
      ACPI: do not warn if _BQC does not exist · 7020bcb8
      Zhang Rui authored
      Starting from ACPI spec 3.0, it's only clarified that _BCM control
      method is required if _BCL is implemented. There is no word
      saying _BQC is required.
      
      And in ACPI spec 6.1 B.5.4, for _BQC, it is explicitly stated that
      "This optional method returns the current brightness level of a
      built-in display output device. If present, it must be set by
      the platform for initial brightness."
      
      Thus remove the obsolete warning message.
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7020bcb8
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Introduce iort_iommu_configure · 643b8e4d
      Lorenzo Pieralisi authored
      DT based systems have a generic kernel API to configure IOMMUs
      for devices (ie of_iommu_configure()).
      
      On ARM based ACPI systems, the of_iommu_configure() equivalent can
      be implemented atop ACPI IORT kernel API, with the corresponding
      functions to map device identifiers to IOMMUs and retrieve the
      corresponding IOMMU operations necessary for DMA operations set-up.
      
      By relying on the iommu_fwspec generic kernel infrastructure,
      implement the IORT based IOMMU configuration for ARM ACPI systems
      and hook it up in the ACPI kernel layer that implements DMA
      configuration for a device.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ACPI core]
      Reviewed-by: default avatarTomasz Nowicki <tn@semihalf.com>
      Tested-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Tested-by: default avatarTomasz Nowicki <tn@semihalf.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Tomasz Nowicki <tn@semihalf.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      643b8e4d
    • Lorenzo Pieralisi's avatar
      ACPI: Implement acpi_dma_configure · d760a1ba
      Lorenzo Pieralisi authored
      On DT based systems, the of_dma_configure() API implements DMA
      configuration for a given device. On ACPI systems an API equivalent to
      of_dma_configure() is missing which implies that it is currently not
      possible to set-up DMA operations for devices through the ACPI generic
      kernel layer.
      
      This patch fills the gap by introducing acpi_dma_configure/deconfigure()
      calls that for now are just wrappers around arch_setup_dma_ops() and
      arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
      the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
      
      Since acpi_dma_configure() is used to configure DMA operations, the
      function initializes the dma/coherent_dma masks to sane default values
      if the current masks are uninitialized (also to keep the default values
      consistent with DT systems) to make sure the device has a complete
      default DMA set-up.
      
      The DMA range size passed to arch_setup_dma_ops() is sized according
      to the device coherent_dma_mask (starting at address 0x0), mirroring the
      DT probing path behaviour when a dma-ranges property is not provided
      for the device being probed; this changes the current arch_setup_dma_ops()
      call parameters in the ACPI probing case, but since arch_setup_dma_ops()
      is a NOP on all architectures but ARM/ARM64 this patch does not change
      the current kernel behaviour on them.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> [pci]
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarTomasz Nowicki <tn@semihalf.com>
      Tested-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Tested-by: default avatarTomasz Nowicki <tn@semihalf.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Tomasz Nowicki <tn@semihalf.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d760a1ba
  19. 09 Nov, 2016 1 commit
  20. 24 Sep, 2016 1 commit
    • Mika Westerberg's avatar
      ACPI / watchdog: Add support for WDAT hardware watchdog · 058dfc76
      Mika Westerberg authored
      Starting from Intel Skylake the iTCO watchdog timer registers were moved to
      reside in the same register space with SMBus host controller.  Not all
      needed registers are available though and we need to unhide P2SB (Primary
      to Sideband) device briefly to be able to read status of required NO_REBOOT
      bit. The i2c-i801.c SMBus driver used to handle this and creation of the
      iTCO watchdog platform device.
      
      Windows, on the other hand, does not use the iTCO watchdog hardware
      directly even if it is available. Instead it relies on ACPI Watchdog Action
      Table (WDAT) table to describe the watchdog hardware to the OS. This table
      contains necessary information about the the hardware and also set of
      actions which are executed by a driver as needed.
      
      This patch implements a new watchdog driver that takes advantage of the
      ACPI WDAT table. We split the functionality into two parts: first part
      enumerates the WDAT table and if found, populates resources and creates
      platform device for the actual driver. The second part is the driver
      itself.
      
      The reason for the split is that this way we can make the driver itself to
      be a module and loaded automatically if the WDAT table is found. Otherwise
      the module is not loaded.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      058dfc76
  21. 10 Sep, 2016 1 commit
  22. 02 Sep, 2016 1 commit
    • Lorenzo Pieralisi's avatar
      ACPI / drivers: replace acpi_probe_lock spinlock with mutex · 5331d9ca
      Lorenzo Pieralisi authored
      Commit e647b532 ("ACPI: Add early device probing infrastructure")
      introduced code that allows inserting driver specific
      struct acpi_probe_entry probe entries into ACPI linker sections
      (one per-subsystem, eg irqchip, clocksource) that are then walked
      to retrieve the data and function hooks required to probe the
      respective kernel components.
      
      Probing for all entries in a section is triggered through
      the __acpi_probe_device_table() function, that in turn, according
      to the table ID a given probe entry reports parses the table
      with the function retrieved from the respective section structures
      (ie struct acpi_probe_entry). Owing to the current ACPI table
      parsing implementation, the __acpi_probe_device_table() function
      has to share global variables with the acpi_match_madt() function, so
      in order to guarantee mutual exclusion locking is required
      between the two functions.
      
      Current kernel code implements the locking through the acpi_probe_lock
      spinlock; this has the side effect of requiring all code called
      within the lock (ie struct acpi_probe_entry.probe_{table/subtbl} hooks)
      not to sleep.
      
      However, kernel subsystems that make use of the early probing
      infrastructure are relying on kernel APIs that may sleep (eg
      irq_domain_alloc_fwnode(), among others) in the function calls
      pointed at by struct acpi_probe_entry.{probe_table/subtbl} entries
      (eg gic_v2_acpi_init()), which is a bug.
      
      Since __acpi_probe_device_table() is called from context
      that is allowed to sleep the acpi_probe_lock spinlock can be replaced
      with a mutex; this fixes the issue whilst still guaranteeing
      mutual exclusion.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Fixes: e647b532 (ACPI: Add early device probing infrastructure)
      Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5331d9ca
  23. 08 Jul, 2016 2 commits
  24. 06 Jul, 2016 1 commit
  25. 16 Feb, 2016 1 commit
  26. 09 Dec, 2015 2 commits
  27. 30 Nov, 2015 1 commit
  28. 07 Nov, 2015 1 commit
  29. 01 Oct, 2015 1 commit
  30. 15 Sep, 2015 2 commits