1. 19 4月, 2016 1 次提交
    • L
      ACPI / tables: Move table override mechanisms to tables.c · 5ae74f2c
      Lv Zheng 提交于
      This patch moves acpi_os_table_override() and
      acpi_os_physical_table_override() to tables.c.
      
      Along with the mechanisms, acpi_initrd_initialize_tables() is also moved to
      tables.c to form a static function. The following functions are renamed
      according to this change:
       1. acpi_initrd_override() -> renamed to early_acpi_table_init(), which
          invokes acpi_table_initrd_init()
       2. acpi_os_physical_table_override() -> which invokes
          acpi_table_initrd_override()
       3. acpi_initialize_initrd_tables() -> renamed to acpi_table_initrd_scan()
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5ae74f2c
  2. 01 1月, 2016 1 次提交
  3. 15 12月, 2015 1 次提交
  4. 02 12月, 2015 1 次提交
  5. 07 11月, 2015 2 次提交
  6. 26 10月, 2015 1 次提交
  7. 25 10月, 2015 1 次提交
  8. 15 10月, 2015 1 次提交
  9. 14 10月, 2015 1 次提交
  10. 01 10月, 2015 1 次提交
  11. 26 9月, 2015 1 次提交
  12. 15 9月, 2015 2 次提交
    • R
      ACPI / property: Extend device_get_next_child_node() to data-only nodes · 504a3374
      Rafael J. Wysocki 提交于
      Make device_get_next_child_node() work with ACPI data-only subnodes
      introduced previously.
      
      Namely, replace acpi_get_next_child() with acpi_get_next_subnode()
      that can handle (and return) child device objects as well as child
      data-only subnodes of the given device and modify the ACPI part
      of the GPIO subsystem to handle data-only subnodes returned by it.
      
      To that end, introduce acpi_node_get_gpiod() taking a struct
      fwnode_handle pointer as the first argument.  That argument may
      point to an ACPI device object as well as to a data-only subnode
      and the function should do the right thing (ie. look for the matching
      GPIO descriptor correctly) in either case.
      
      Next, modify fwnode_get_named_gpiod() to use acpi_node_get_gpiod()
      instead of acpi_get_gpiod_by_index() which automatically causes
      devm_get_gpiod_from_child() to work with ACPI data-only subnodes
      that may be returned by device_get_next_child_node() which in turn
      is required by the users of that function (the gpio_keys_polled
      and gpio-leds drivers).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      504a3374
    • R
      ACPI / property: Extend fwnode_property_* to data-only subnodes · 3a7a2ab8
      Rafael J. Wysocki 提交于
      Modify is_acpi_node() to return "true" for ACPI data-only subnodes as
      well as for ACPI device objects and change the name of to_acpi_node()
      to to_acpi_device_node() so it is clear that it covers ACPI device
      objects only.  Accordingly, introduce to_acpi_data_node() to cover
      data-only subnodes in an analogous way.
      
      With that, make the fwnode_property_* family of functions work with
      ACPI data-only subnodes introduced previously.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      3a7a2ab8
  13. 27 8月, 2015 1 次提交
    • J
      ACPI, PCI: Penalize legacy IRQ used by ACPI SCI · 5d0ddfeb
      Jiang Liu 提交于
      Nick Meier reported a regression with HyperV that "
        After rebooting the VM, the following messages are logged in syslog
        when trying to load the tulip driver:
          tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007)
          tulip: 0000:00:0a.0: PCI INT A: failed to register GSI
          tulip: Cannot enable tulip board #0, aborting
          tulip: probe of 0000:00:0a.0 failed with error -16
        Errors occur in 3.19.0 kernel
        Works in 3.17 kernel.
      "
      
      According to the ACPI dump file posted by Nick at
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072
      
      The ACPI MADT table includes an interrupt source overridden entry for
      ACPI SCI:
      [236h 0566  1]                Subtable Type : 02 <Interrupt Source Override>
      [237h 0567  1]                       Length : 0A
      [238h 0568  1]                          Bus : 00
      [239h 0569  1]                       Source : 09
      [23Ah 0570  4]                    Interrupt : 00000009
      [23Eh 0574  2]        Flags (decoded below) : 000D
                                         Polarity : 1
                                     Trigger Mode : 3
      
      And in DSDT table, we have _PRT method to define PCI interrupts, which
      eventually goes to:
              Name (PRSA, ResourceTemplate ()
              {
                  IRQ (Level, ActiveLow, Shared, )
                      {3,4,5,7,9,10,11,12,14,15}
              })
              Name (PRSB, ResourceTemplate ()
              {
                  IRQ (Level, ActiveLow, Shared, )
                      {3,4,5,7,9,10,11,12,14,15}
              })
              Name (PRSC, ResourceTemplate ()
              {
                  IRQ (Level, ActiveLow, Shared, )
                      {3,4,5,7,9,10,11,12,14,15}
              })
              Name (PRSD, ResourceTemplate ()
              {
                  IRQ (Level, ActiveLow, Shared, )
                      {3,4,5,7,9,10,11,12,14,15}
              })
      
      According to the MADT and DSDT tables, IRQ 9 may be used for:
       1) ACPI SCI in level, high mode
       2) PCI legacy IRQ in level, low mode
      So there's a conflict in polarity setting for IRQ 9.
      
      Prior to commit cd68f6bd ("x86, irq, acpi: Get rid of special
      handling of GSI for ACPI SCI"), ACPI SCI is handled specially and
      there's no check for conflicts between ACPI SCI and PCI legagy IRQ.
      And it seems that the HyperV hypervisor doesn't make use of the
      polarity configuration in IOAPIC entry, so it just works.
      
      Commit cd68f6bd gets rid of the specially handling of ACPI SCI,
      and then the pin attribute checking code discloses the conflicts
      between ACPI SCI and PCI legacy IRQ on HyperV virtual machine,
      and rejects the request to assign IRQ9 to PCI devices.
      
      So penalize legacy IRQ used by ACPI SCI and mark it unusable if ACPI
      SCI attributes conflict with PCI IRQ attributes.
      
      Please refer to following links for more information:
      https://bugzilla.kernel.org/show_bug.cgi?id=101301
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072
      
      Fixes: cd68f6bd ("x86, irq, acpi: Get rid of special handling of GSI for ACPI SCI")
      Reported-and-tested-by: NNick Meier <nmeier@microsoft.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: 3.19+ <stable@vger.kernel.org> # 3.19+
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5d0ddfeb
  14. 08 7月, 2015 1 次提交
  15. 07 7月, 2015 2 次提交
    • S
      ACPI / scan: Add support for ACPI _CLS device matching · 26095a01
      Suthikulpanit, Suravee 提交于
      Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
      acpi_match_table to match devices. However, for generic drivers, we do not
      want to list _HID for all supported devices. Also, certain classes of devices
      do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
      which specifies PCI-defined class code (i.e. base-class, subclass and
      programming interface). This patch adds support for matching ACPI devices using
      the _CLS method.
      
      To support loadable module, current design uses _HID or _CID to match device's
      modalias. With the new way of matching with _CLS this would requires modification
      to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
      class-code to the existing ACPI modalias as following.
      
          acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
      E.g:
          # cat /sys/devices/platform/AMDI0600:00/modalias
          acpi:AMDI0600:010601:
      
      where bb is th base-class code, ss is te sub-class code, and pp is the
      programming interface code
      
      Since there would not be _HID/_CID in the ACPI matching table of the driver,
      this patch adds a field to acpi_device_id to specify the matching _CLS.
      
          static const struct acpi_device_id ahci_acpi_match[] = {
              { ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
              {},
          };
      
      In this case, the corresponded entry in modules.alias file would be:
      
          alias acpi*:010601:* ahci_platform
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      26095a01
    • R
      ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage · 0294112e
      Rafael J. Wysocki 提交于
      This effectively reverts the following three commits:
      
       7bc10388 ACPI / resources: free memory on error in add_region_before()
       0f1b414d ACPI / PNP: Avoid conflicting resource reservations
       b9a5e5e1 ACPI / init: Fix the ordering of acpi_reserve_resources()
      
      (commit b9a5e5e1 introduced regressions some of which, but not
      all, were addressed by commit 0f1b414d and commit 7bc10388
      was a fixup on top of the latter) and causes ACPI fixed hardware
      resources to be reserved at the fs_initcall_sync stage of system
      initialization.
      
      The story is as follows.  First, a boot regression was reported due
      to an apparent resource reservation ordering change after a commit
      that shouldn't lead to such changes.  Investigation led to the
      conclusion that the problem happened because acpi_reserve_resources()
      was executed at the device_initcall() stage of system initialization
      which wasn't strictly ordered with respect to driver initialization
      (and with respect to the initialization of the pcieport driver in
      particular), so a random change causing the device initcalls to be
      run in a different order might break things.
      
      The response to that was to attempt to run acpi_reserve_resources()
      as soon as we knew that ACPI would be in use (commit b9a5e5e1).
      However, that turned out to be too early, because it caused resource
      reservations made by the PNP system driver to fail on at least one
      system and that failure was addressed by commit 0f1b414d.
      
      That fix still turned out to be insufficient, though, because
      calling acpi_reserve_resources() before the fs_initcall stage of
      system initialization caused a boot regression to happen on the
      eCAFE EC-800-H20G/S netbook.  That meant that we only could call
      acpi_reserve_resources() at the fs_initcall initialization stage
      or later, but then we might just as well call it after the PNP
      initalization in which case commit 0f1b414d wouldn't be
      necessary any more.
      
      For this reason, the changes made by commit 0f1b414d are reverted
      (along with a memory leak fixup on top of that commit), the changes
      made by commit b9a5e5e1 that went too far are reverted too and
      acpi_reserve_resources() is changed into fs_initcall_sync, which
      will cause it to be executed after the PNP subsystem initialization
      (which is an fs_initcall) and before device initcalls (including
      the pcieport driver initialization) which should avoid the initial
      issue.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=100581
      Link: http://marc.info/?t=143092384600002&r=1&w=2
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
      Link: http://marc.info/?t=143389402600001&r=1&w=2
      Fixes: b9a5e5e1 "ACPI / init: Fix the ordering of acpi_reserve_resources()"
      Reported-by: NRoland Dreier <roland@purestorage.com>
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0294112e
  16. 26 6月, 2015 1 次提交
    • T
      acpi: Add acpi_map_pxm_to_online_node() · 99759869
      Toshi Kani 提交于
      The kernel initializes CPU & memory's NUMA topology from ACPI
      SRAT table.  Some other ACPI tables, such as NFIT and DMAR, also
      contain proximity IDs for their device's NUMA topology.  This
      information can be used to improve performance of these devices.
      
      This patch introduces acpi_map_pxm_to_online_node(), which is
      similar to acpi_map_pxm_to_node(), but always returns an online
      node.  When the mapped node from a given proximity ID is offline,
      it looks up the node distance table and returns the nearest
      online node.
      
      ACPI device drivers, which are called after the NUMA initialization
      has completed in the kernel, can call this interface to obtain their
      device NUMA topology from ACPI tables.  Such drivers do not have to
      deal with offline nodes.  A node may be offline when a device
      proximity ID is unique, SRAT memory entry does not exist, or NUMA is
      disabled, ex. "numa=off" on x86.
      
      This patch also moves the pxm range check from acpi_get_node() to
      acpi_map_pxm_to_node().
      Signed-off-by: NToshi Kani <toshi.kani@hp.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com&gt;>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      99759869
  17. 25 6月, 2015 1 次提交
  18. 19 6月, 2015 7 次提交
  19. 15 6月, 2015 1 次提交
  20. 11 6月, 2015 1 次提交
    • R
      ACPI / init: Switch over platform to the ACPI mode later · b064a8fa
      Rafael J. Wysocki 提交于
      Commit 73f7d1ca "ACPI / init: Run acpi_early_init() before
      timekeeping_init()" moved the ACPI subsystem initialization,
      including the ACPI mode enabling, to an earlier point in the
      initialization sequence, to allow the timekeeping subsystem
      use ACPI early.  Unfortunately, that resulted in boot regressions
      on some systems and the early ACPI initialization was moved toward
      its original position in the kernel initialization code by commit
      c4e1acbb "ACPI / init: Invoke early ACPI initialization later".
      
      However, that turns out to be insufficient, as boot is still broken
      on the Tyan S8812 mainboard.
      
      To fix that issue, split the ACPI early initialization code into
      two pieces so the majority of it still located in acpi_early_init()
      and the part switching over the platform into the ACPI mode goes into
      a new function, acpi_subsystem_init(), executed at the original early
      ACPI initialization spot.
      
      That fixes the Tyan S8812 boot problem, but still allows ACPI
      tables to be loaded earlier which is useful to the EFI code in
      efi_enter_virtual_mode().
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
      Fixes: 73f7d1ca "ACPI / init: Run acpi_early_init() before timekeeping_init()"
      Reported-and-tested-by: NMarius Tolzmann <tolzmann@molgen.mpg.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
      Reviewed-by: NLee, Chun-Yi <jlee@suse.com>
      b064a8fa
  21. 14 5月, 2015 2 次提交
  22. 11 5月, 2015 1 次提交
    • M
      gpio / ACPI: Add support for retrieving GpioInt resources from a device · c884fbd4
      Mika Westerberg 提交于
      ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
      is used to describe that a given device interrupt line is connected to a
      specific GPIO pin. Typical ACPI _CRS entry for such device looks like
      below:
      
          Name (_CRS, ResourceTemplate ()
          {
              I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
                            AddressingMode7Bit, "\\_SB.PCI0.I2C6",
                            0x00, ResourceConsumer)
              GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
                      IoRestrictionOutputOnly, "\\_SB.GPO0",
                      0x00, ResourceConsumer)
              {
                  0x004B
              }
              GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
                       "\\_SB.GPO0", 0x00, ResourceConsumer)
              {
                  0x004C
              }
          })
      
      Currently drivers need to request a GPIO corresponding to the right GpioInt
      and then translate that to Linux IRQ number. This adds unnecessary lines of
      boiler-plate code.
      
      We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
      of_irq_get(). This function translates given GpioInt resource under the
      device in question to the suitable Linux IRQ number.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      c884fbd4
  23. 04 4月, 2015 1 次提交
    • R
      device property: Make it possible to use secondary firmware nodes · 97badf87
      Rafael J. Wysocki 提交于
      Add a secondary pointer to struct fwnode_handle so as to make it
      possible for a device to have two firmware nodes associated with
      it at the same time, for example, an ACPI node and a node with
      a set of properties provided by platform initialization code.
      
      In the future that will allow device property lookup to fall back
      from the primary firmware node to the secondary one if the given
      property is not present there to make it easier to provide defaults
      for device properties used by device drivers.
      
      Introduce two helper routines, set_primary_fwnode() and
      set_secondary_fwnode() allowing callers to add a primary/secondary
      firmware node to the given device in such a way that
      
       (1) If there's only one firmware node for that device, it will be
           pointed to by the device's firmware node pointer.
       (2) If both the primary and secondary firmware nodes are present,
           the primary one will be pointed to by the device's firmware
           node pointer, while the secondary one will be pointed to by the
           primary node's secondary pointer.
       (3) If one of these nodes is removed (by calling one of the new
           nelpers with NULL as the second argument), the other one will
           be preserved.
      
      Make ACPI use set_primary_fwnode() for attaching its firmware nodes
      to devices.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97badf87
  24. 26 3月, 2015 2 次提交
  25. 17 3月, 2015 2 次提交
  26. 05 2月, 2015 2 次提交
  27. 04 2月, 2015 1 次提交