1. 03 Mar, 2021 1 commit
  2. 12 Feb, 2021 2 commits
  3. 04 Feb, 2021 1 commit
    • Mika Westerberg's avatar
      ACPI: Add support for native USB4 control _OSC · 5a6a2c0f
      Mika Westerberg authored
      
      ACPI 6.4 introduced a new _OSC capability that is used negotiate native
      connection manager support. Connection manager is the entity that is
      responsible for tunneling over the USB4 fabric. If the platform rejects
      the native access then firmware based connection manager is used.
      
      The new _OSC also includes a set of bits that can be used to disable
      certain tunnel types such as PCIe for security reasons for instance.
      
      This implements the new USB4 _OSC so that we try to negotiate native
      USB4 support if the Thunderbolt/USB4 (CONFIG_USB4) driver is enabled.
      Drivers can determine what was negotiated by checking two new variables
      exposed in this patch.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5a6a2c0f
  4. 27 Jan, 2021 1 commit
  5. 07 Jan, 2021 1 commit
  6. 12 Dec, 2020 1 commit
  7. 25 Oct, 2020 1 commit
  8. 14 Oct, 2020 1 commit
    • Dan Williams's avatar
      x86/numa: add 'nohmat' option · 3b0d3101
      Dan Williams authored
      Disable parsing of the HMAT for debug, to workaround broken platform
      instances, or cases where it is otherwise not wanted.
      
      [rdunlap@infradead.org: fix build when CONFIG_ACPI is not set]
        Link: https://lkml.kernel.org/r/70e5ee34-9809-a997-7b49-499e4be61307@infradead.org
      
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Ard Biesheuvel <ardb@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Brice Goglin <Brice.Goglin@inria.fr>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ira Weiny <ira.weiny@intel.com>
      Cc: Jason Gunthorpe <jgg@mellanox.com>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Jia He <justin.he@arm.com>
      Cc: Joao Martins <joao.m.martins@oracle.com>
      Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Mike Rapoport <rppt@linux.ibm.com>
      Cc: Paul Mackerras <paulus@ozlabs.org>
      Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Vishal Verma <vishal.l.verma@intel.com>
      Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Hulk Robot <hulkci@huawei.com>
      Cc: Jason Yan <yanaijie@huawei.com>
      Cc: "Jérôme Glisse" <jglisse@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: kernel test robot <lkp@intel.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Stefano Stabellini <sstabellini@kernel.org>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Link: https://lkml.kernel.org/r/159643095540.4062302.732962081968036212.stgit@dwillia2-desk3.amr.corp.intel.com
      
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3b0d3101
  9. 02 Oct, 2020 2 commits
  10. 30 Sep, 2020 1 commit
  11. 25 Sep, 2020 1 commit
  12. 24 Sep, 2020 2 commits
  13. 28 Jul, 2020 1 commit
    • Lorenzo Pieralisi's avatar
      ACPI/IORT: Add an input ID to acpi_dma_configure() · b8e069a2
      Lorenzo Pieralisi authored
      
      Some HW devices are created as child devices of proprietary busses,
      that have a bus specific policy defining how the child devices
      wires representing the devices ID are translated into IOMMU and
      IRQ controllers device IDs.
      
      Current IORT code provides translations for:
      
      - PCI devices, where the device ID is well identified at bus level
        as the requester ID (RID)
      - Platform devices that are endpoint devices where the device ID is
        retrieved from the ACPI object IORT mappings (Named components single
        mappings). A platform device is represented in IORT as a named
        component node
      
      For devices that are child devices of proprietary busses the IORT
      firmware represents the bus node as a named component node in IORT
      and it is up to that named component node to define in/out bus
      specific ID translations for the bus child devices that are
      allocated and created in a bus specific manner.
      
      In order to make IORT ID translations available for proprietary
      bus child devices, the current ACPI (and IORT) code must be
      augmented to provide an additional ID parameter to acpi_dma_configure()
      representing the child devices input ID. This ID is bus specific
      and it is retrieved in bus specific code.
      
      By adding an ID parameter to acpi_dma_configure(), the IORT
      code can map the child device ID to an IOMMU stream ID through
      the IORT named component representing the bus in/out ID mappings.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Link: https://lore.kernel.org/r/20200619082013.13661-6-lorenzo.pieralisi@arm.com
      
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      b8e069a2
  14. 27 Jun, 2020 2 commits
  15. 04 Apr, 2020 1 commit
    • Hans de Goede's avatar
      ACPI: PM: Add acpi_[un]register_wakeup_handler() · ddfd9dcf
      Hans de Goede authored
      Since commit fdde0ff8 ("ACPI: PM: s2idle: Prevent spurious SCIs from
      waking up the system") the SCI triggering without there being a wakeup
      cause recognized by the ACPI sleep code will no longer wakeup the system.
      
      This works as intended, but this is a problem for devices where the SCI
      is shared with another device which is also a wakeup source.
      
      In the past these, from the pov of the ACPI sleep code, spurious SCIs
      would still cause a wakeup so the wakeup from the device sharing the
      interrupt would actually wakeup the system. This now no longer works.
      
      This is a problem on e.g. Bay Trail-T and Cherry Trail devices where
      some peripherals (typically the XHCI controller) can signal a
      Power Management Event (PME) to the Power Management Controller (PMC)
      to wakeup the system, this uses the same interrupt as the SCI.
      These wakeups are handled through a special INT0002 ACPI device which
      checks for events in the GPE0a_STS for this and takes care of acking
      the PME so that the shared interrupt stops triggering.
      
      The change to the ACPI sleep code to ignore the spurious SCI, causes
      the system to no longer wakeup on these PME events. To make things
      worse this means that the INT0002 device driver interrupt handler will
      no longer run, causing the PME to not get cleared and resulting in the
      system hanging. Trying to wakeup the system after such a PME through e.g.
      the power button no longer works.
      
      Add an acpi_register_wakeup_handler() function which registers
      a handler to be called from acpi_s2idle_wake() and when the handler
      returns true, return true from acpi_s2idle_wake().
      
      The INT0002 driver will use this mechanism to check the GPE0a_STS
      register from acpi_s2idle_wake() and to tell the system to wakeup
      if a PME is signaled in the register.
      
      Fixes: fdde0ff8
      
       ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system")
      Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ddfd9dcf
  16. 28 Mar, 2020 1 commit
    • Kuppuswamy Sathyanarayanan's avatar
      PCI/DPC: Add Error Disconnect Recover (EDR) support · ac1c8e35
      Kuppuswamy Sathyanarayanan authored
      Error Disconnect Recover (EDR) is a feature that allows ACPI firmware to
      notify OSPM that a device has been disconnected due to an error condition
      (ACPI v6.3, sec 5.6.6).  OSPM advertises its support for EDR on PCI devices
      via _OSC (see [1], sec 4.5.1, table 4-4).  The OSPM EDR notify handler
      should invalidate software state associated with disconnected devices and
      may attempt to recover them.  OSPM communicates the status of recovery to
      the firmware via _OST (sec 6.3.5.2).
      
      For PCIe, firmware may use Downstream Port Containment (DPC) to support
      EDR.  Per [1], sec 4.5.1, table 4-6, even if firmware has retained control
      of DPC, OSPM may read/write DPC control and status registers during the EDR
      notification processing window, i.e., from the time it receives an EDR
      notification until it clears the DPC Trigger Status.
      
      Note that per [1], sec 4.5.1 and 4.5.2.4,
      
        1. If the OS supports EDR, it should advertise that to firmware by
           setting OSC_PCI_EDR_SUPPORT in _OSC Support.
      
        2. If the OS sets OSC_PCI_EXPRESS_DPC_CONTROL in _OSC Control to request
           control of the DPC capability, it must also set OSC_PCI_EDR_SUPPORT in
           _OSC Support.
      
      Add an EDR notify handler to attempt recovery.
      
      [1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019,
          affecting PCI Firmware Specification, Rev. 3.2
          https://members.pcisig.com/wg/PCI-SIG/document/12888
      
      [bhelgaas: squash add/enable patches into one]
      Link: https://lore.kernel.org/r/90f91fe6d25c13f9d2255d2ce97ca15be307e1bb.1585000084.git.sathyanarayanan.kuppuswamy@linux.intel.com
      
      Signed-off-by: default avatarKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Len Brown <lenb@kernel.org>
      ac1c8e35
  17. 17 Feb, 2020 1 commit
  18. 27 Dec, 2019 1 commit
  19. 16 Dec, 2019 1 commit
    • Rafael J. Wysocki's avatar
      ACPI: processor: Export function to claim _CST control · bc946388
      Rafael J. Wysocki authored
      
      The intel_idle driver will be modified to use ACPI _CST subsequently
      and it will need to notify the platform firmware of that if
      acpi_gbl_FADT.cst_control is set, so add a routine for this purpose,
      acpi_processor_claim_cst_control(), to acpi_processor.c (so that it
      is always present which is required by intel_idle) and export it
      to allow the ACPI processor driver (which is modular) to call it.
      
      No intentional functional impact.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bc946388
  20. 15 Oct, 2019 1 commit
  21. 20 Aug, 2019 1 commit
    • Josh Boyer's avatar
      acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down · 41fa1ee9
      Josh Boyer authored
      
      This option allows userspace to pass the RSDP address to the kernel, which
      makes it possible for a user to modify the workings of hardware. Reject
      the option when the kernel is locked down. This requires some reworking
      of the existing RSDP command line logic, since the early boot code also
      makes use of a command-line passed RSDP when locating the SRAT table
      before the lockdown code has been initialised. This is achieved by
      separating the command line RSDP path in the early boot code from the
      generic RSDP path, and then copying the command line RSDP into boot
      params in the kernel proper if lockdown is not enabled. If lockdown is
      enabled and an RSDP is provided on the command line, this will only be
      used when parsing SRAT (which shouldn't permit kernel code execution)
      and will be ignored in the rest of the kernel.
      
      (Modified by Matthew Garrett in order to handle the early boot RSDP
      environment)
      Signed-off-by: default avatarJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarMatthew Garrett <mjg59@google.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      cc: Dave Young <dyoung@redhat.com>
      cc: linux-acpi@vger.kernel.org
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      41fa1ee9
  22. 12 Aug, 2019 1 commit
  23. 30 Jul, 2019 2 commits
    • Andy Shevchenko's avatar
      gpiolib-acpi: Move acpi_dev_add_driver_gpios() et al to consumer.h · 2838bf94
      Andy Shevchenko authored
      
      The API, which belongs to GPIO library, is foreign to ACPI headers. Earlier
      we moved out I²C out of the latter, and now it's time for
      acpi_dev_add_driver_gpios() et al.
      
      For time being the acpi_gpio_get_irq_resource() and acpi_dev_gpio_irq_get()
      are left untouched as they need more thought about.
      
      Note, it requires uninline acpi_dev_remove_driver_gpios() to keep purity of
      consumer.h.
      
      Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com>
      Cc: Jie Yang <yang.jie@linux.intel.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: alsa-devel@alsa-project.org (moderated list:INTEL ASoC DRIVERS)
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Link: https://lore.kernel.org/r/20190730104337.21235-3-andriy.shevchenko@linux.intel.com
      
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      2838bf94
    • Rafael J. Wysocki's avatar
      ACPI: PM: Set up EC GPE for system wakeup from drivers that need it · 10a08fd6
      Rafael J. Wysocki authored
      
      The EC GPE needs to be set up for system wakeup only if there is a
      driver depending on it, either intel-hid or intel-vbtn, bound to a
      button device that is expected to wake up the system from sleep (such
      as the power button on some Dell systems, like the XPS13 9360).  It
      doesn't need to be set up for waking up the system from sleep in any
      other cases and whether or not it is expected to wake up the system
      from sleep doesn't depend on whether or not the LPS0 device is
      present in the ACPI namespace.
      
      For this reason, rearrange the ACPI suspend-to-idle code to make the
      drivers depending on the EC GPE wakeup take care of setting it up and
      decouple that from the LPS0 device handling.
      
      While at it, make intel-hid and intel-vbtn prepare for system wakeup
      only if they are allowed to wake up the system from sleep by user
      space (via sysfs).
      
      [Note that acpi_ec_mark_gpe_for_wake() and acpi_ec_set_gpe_wake_mask()
       are there to prevent the EC GPE from being disabled by the
       acpi_enable_all_wakeup_gpes() call in acpi_s2idle_prepare(), so on
       systems with either intel-hid or intel-vbtn this change doesn't
       affect any interactions with the hardware or platform firmware.]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      10a08fd6
  24. 15 Jul, 2019 1 commit
    • Arnd Bergmann's avatar
      ACPI: fix false-positive -Wuninitialized warning · dfd6f9ad
      Arnd Bergmann authored
      
      clang gets confused by an uninitialized variable in what looks
      to it like a never executed code path:
      
      arch/x86/kernel/acpi/boot.c:618:13: error: variable 'polarity' is uninitialized when used here [-Werror,-Wuninitialized]
              polarity = polarity ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
                         ^~~~~~~~
      arch/x86/kernel/acpi/boot.c:606:32: note: initialize the variable 'polarity' to silence this warning
              int rc, irq, trigger, polarity;
                                            ^
                                             = 0
      arch/x86/kernel/acpi/boot.c:617:12: error: variable 'trigger' is uninitialized when used here [-Werror,-Wuninitialized]
              trigger = trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
                        ^~~~~~~
      arch/x86/kernel/acpi/boot.c:606:22: note: initialize the variable 'trigger' to silence this warning
              int rc, irq, trigger, polarity;
                                  ^
                                   = 0
      
      This is unfortunately a design decision in clang and won't be fixed.
      
      Changing the acpi_get_override_irq() macro to an inline function
      reliably avoids the issue.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      dfd6f9ad
  25. 02 Jul, 2019 3 commits
  26. 27 Jun, 2019 1 commit
  27. 17 Jun, 2019 1 commit
    • Yurii Pavlovskyi's avatar
      platform/x86: wmi: Add function to get _UID of WMI device · e7488e58
      Yurii Pavlovskyi authored
      Add a new function to acpi.h / wmi.c that returns _UID of the ACPI WMI
      device. For example, it returns "ATK" for the following declaration in
      DSDT:
      Device (ATKD)
      {
          Name (_HID, "PNP0C14" /* Windows Management Instrumentation Device */)
            // _HID: Hardware ID
          Name (_UID, "ATK")  // _UID: Unique ID
          ..
      
      Generally, it is possible that multiple PNP0C14 ACPI devices are present in
      the system as mentioned in the commit message of commit bff431e4
      
      
      ("ACPI: WMI: Add ACPI-WMI mapping driver").
      
      Therefore the _UID is returned for a specific ACPI device that declares the
      given GUID, to which it is also mapped by other methods of wmi module.
      Signed-off-by: default avatarYurii Pavlovskyi <yurii.pavlovskyi@gmail.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      e7488e58
  28. 30 May, 2019 1 commit
    • Thomas Gleixner's avatar
      treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157 · c942fddf
      Thomas Gleixner authored
      
      Based on 3 normalized pattern(s):
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version this program is distributed in the
        hope that it will be useful but without any warranty without even
        the implied warranty of merchantability or fitness for a particular
        purpose see the gnu general public license for more details
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version [author] [kishon] [vijay] [abraham]
        [i] [kishon]@[ti] [com] this program is distributed in the hope that
        it will be useful but without any warranty without even the implied
        warranty of merchantability or fitness for a particular purpose see
        the gnu general public license for more details
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version [author] [graeme] [gregory]
        [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
        [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
        [hk] [hemahk]@[ti] [com] this program is distributed in the hope
        that it will be useful but without any warranty without even the
        implied warranty of merchantability or fitness for a particular
        purpose see the gnu general public license for more details
      
      extracted by the scancode license scanner the SPDX license identifier
      
        GPL-2.0-or-later
      
      has been chosen to replace the boilerplate/reference in 1105 file(s).
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarAllison Randal <allison@lohutok.net>
      Reviewed-by: default avatarRichard Fontana <rfontana@redhat.com>
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Cc: linux-spdx@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c942fddf
  29. 28 May, 2019 1 commit
    • Ard Biesheuvel's avatar
      acpi/irq: Implement helper to create hierachical domains · 621dc2fd
      Ard Biesheuvel authored
      
      ACPI permits arbitrary producer->consumer interrupt links to be
      described in AML, which means a topology such as the following
      is perfectly legal:
      
        Device (EXIU) {
          Name (_HID, "SCX0008")
          Name (_UID, Zero)
          Name (_CRS, ResourceTemplate () {
            ...
          })
        }
      
        Device (GPIO) {
          Name (_HID, "SCX0007")
          Name (_UID, Zero)
          Name (_CRS, ResourceTemplate () {
            Memory32Fixed (ReadWrite, SYNQUACER_GPIO_BASE, SYNQUACER_GPIO_SIZE)
            Interrupt (ResourceConsumer, Edge, ActiveHigh, ExclusiveAndWake, 0, "\\_SB.EXIU") {
              7,
            }
          })
          ...
        }
      
      The EXIU in this example is the external interrupt unit as can be found
      on Socionext SynQuacer based platforms, which converts a block of 32 SPIs
      from arbitrary polarity/trigger into level-high, with a separate set
      of config/mask/unmask/clear controls.
      
      The existing DT based driver in drivers/irqchip/irq-sni-exiu.c models
      this as a hierarchical domain stacked on top of the GIC's irqdomain.
      Since the GIC is modeled as a DT node as well, obtaining a reference
      to this irqdomain is easily done by going through the parent link.
      
      On ACPI systems, however, the GIC is not modeled as an object in the
      namespace, and so device objects cannot refer to it directly. So in
      order to obtain the irqdomain reference when driving the EXIU in ACPI
      mode, we need a helper that implicitly grabs the default domain as the
      parent of the hierarchy for interrupts allocated out of the global GSI
      pool.
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      621dc2fd
  30. 23 Apr, 2019 2 commits
  31. 04 Apr, 2019 2 commits