1. 21 11月, 2016 1 次提交
  2. 15 11月, 2016 1 次提交
  3. 10 11月, 2016 1 次提交
  4. 29 10月, 2016 3 次提交
  5. 24 10月, 2016 4 次提交
  6. 13 10月, 2016 2 次提交
  7. 12 10月, 2016 1 次提交
    • M
      ACPI / property: Allow holes in reference properties · b60e4ea4
      Mika Westerberg 提交于
      DT allows holes or empty phandles for references. This is used for example
      in SPI subsystem where some chip selects are native and others are regular
      GPIOs. In ACPI _DSD we currently do not support this but instead the
      preceding reference consumes all following integer arguments.
      
      For example we would like to support something like the below ASL fragment
      for SPI:
      
        Package () {
            "cs-gpios",
            Package () {
                ^GPIO, 19, 0, 0, // GPIO CS0
                0,               // Native CS
                ^GPIO, 20, 0, 0, // GPIO CS1
            }
        }
      
      The zero in the middle means "no entry" or NULL reference. To support this
      we change acpi_data_get_property_reference() to take firmware node and
      num_args as argument and rename it to __acpi_node_get_property_reference().
      The function returns -ENOENT if the given index resolves to "no entry"
      reference and -ENODATA when there are no more entries in the property.
      
      We then add static inline wrapper acpi_node_get_property_reference() that
      passes MAX_ACPI_REFERENCE_ARGS as num_args to support the existing
      behaviour which some drivers have been relying on.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b60e4ea4
  8. 10 10月, 2016 2 次提交
  9. 08 10月, 2016 1 次提交
  10. 01 10月, 2016 2 次提交
  11. 28 9月, 2016 1 次提交
  12. 27 9月, 2016 1 次提交
  13. 26 9月, 2016 1 次提交
  14. 24 9月, 2016 4 次提交
  15. 22 9月, 2016 5 次提交
    • D
      acpi: Validate processor id when mapping the processor · fd74da21
      Dou Liyang 提交于
      When we want to identify whether the proc_id is unreasonable or not, we
      can call the "acpi_processor_validate_proc_id" function. It will search
      in the duplicate IDs. If we find the proc_id in the IDs, we return true
      to the call function. Conversely, the false represents available.
      
      When we establish all possible cpuid <-> nodeid mapping to handle the
      cpu hotplugs, we will use the proc_id from ACPI table.
      
      We do validation when we get the proc_id. If the result is true, we
      will stop the mapping.
      
      [ tglx: Mark the new function __init ]
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: mika.j.penttila@gmail.com
      Cc: len.brown@intel.com
      Cc: rafael@kernel.org
      Cc: rjw@rjwysocki.net
      Cc: yasu.isimatu@gmail.com
      Cc: linux-mm@kvack.org
      Cc: linux-acpi@vger.kernel.org
      Cc: isimatu.yasuaki@jp.fujitsu.com
      Cc: gongzhaogang@inspur.com
      Cc: tj@kernel.org
      Cc: izumi.taku@jp.fujitsu.com
      Cc: cl@linux.com
      Cc: chen.tang@easystack.cn
      Cc: akpm@linux-foundation.org
      Cc: kamezawa.hiroyu@jp.fujitsu.com
      Cc: lenb@kernel.org
      Link: http://lkml.kernel.org/r/1472114120-3281-8-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      fd74da21
    • D
      acpi: Provide mechanism to validate processors in the ACPI tables · 8e089eaa
      Dou Liyang 提交于
      [Problem]
      
      When we set cpuid <-> nodeid mapping to be persistent, it will use the DSDT
      As we know, the ACPI tables are just like user's input in that respect, and
      we don't crash if user's input is unreasonable.
      
      Such as, the mapping of the proc_id and pxm in some machine's ACPI table is
      like this:
      
      proc_id   |    pxm
      --------------------
      0       <->     0
      1       <->     0
      2       <->     1
      3       <->     1
      89      <->     0
      89      <->     0
      89      <->     0
      89      <->     1
      89      <->     1
      89      <->     2
      89      <->     3
      .....
      
      We can't be sure which one is correct to the proc_id 89. We may map a wrong
      node to a cpu. When pages are allocated, this may cause a kernal panic.
      
      So, we should provide mechanisms to validate the ACPI tables, just like we
      do validation to check user's input in web project.
      
      The mechanism is that the processor objects which have the duplicate IDs
      are not valid.
      
      [Solution]
      
      We add a validation function, like this:
      
      foreach Processor in DSDT
      	proc_id = get_ACPI_Processor_number(Processor)
      	if (proc_id exists )
      		mark both of them as being unreasonable;
      
      The function will record the unique or duplicate processor IDs.
      
      The duplicate processor IDs such as 89 are regarded as the unreasonable IDs
      which mean that the processor objects in question are not valid.
      
      [ tglx: Add __init[data] annotations ]
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: mika.j.penttila@gmail.com
      Cc: len.brown@intel.com
      Cc: rafael@kernel.org
      Cc: rjw@rjwysocki.net
      Cc: yasu.isimatu@gmail.com
      Cc: linux-mm@kvack.org
      Cc: linux-acpi@vger.kernel.org
      Cc: isimatu.yasuaki@jp.fujitsu.com
      Cc: gongzhaogang@inspur.com
      Cc: tj@kernel.org
      Cc: izumi.taku@jp.fujitsu.com
      Cc: cl@linux.com
      Cc: chen.tang@easystack.cn
      Cc: akpm@linux-foundation.org
      Cc: kamezawa.hiroyu@jp.fujitsu.com
      Cc: lenb@kernel.org
      Link: http://lkml.kernel.org/r/1472114120-3281-7-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      8e089eaa
    • G
      x86/acpi: Set persistent cpuid <-> nodeid mapping when booting · dc6db24d
      Gu Zheng 提交于
      The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So that,
      when node online/offline happens, cache based on cpuid <-> nodeid mapping such as
      wq_numa_possible_cpumask will not cause any problem.
      It contains 4 steps:
      1. Enable apic registeration flow to handle both enabled and disabled cpus.
      2. Introduce a new array storing all possible cpuid <-> apicid mapping.
      3. Enable _MAT and MADT relative apis to return non-present or disabled cpus' apicid.
      4. Establish all possible cpuid <-> nodeid mapping.
      
      This patch finishes step 4.
      
      This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
      processors at boot time via an additional acpi namespace walk for processors.
      
      [ tglx: Remove the unneeded exports ]
      Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Signed-off-by: NZhu Guihua <zhugh.fnst@cn.fujitsu.com>
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: mika.j.penttila@gmail.com
      Cc: len.brown@intel.com
      Cc: rafael@kernel.org
      Cc: rjw@rjwysocki.net
      Cc: yasu.isimatu@gmail.com
      Cc: linux-mm@kvack.org
      Cc: linux-acpi@vger.kernel.org
      Cc: isimatu.yasuaki@jp.fujitsu.com
      Cc: gongzhaogang@inspur.com
      Cc: tj@kernel.org
      Cc: izumi.taku@jp.fujitsu.com
      Cc: cl@linux.com
      Cc: chen.tang@easystack.cn
      Cc: akpm@linux-foundation.org
      Cc: kamezawa.hiroyu@jp.fujitsu.com
      Cc: lenb@kernel.org
      Link: http://lkml.kernel.org/r/1472114120-3281-6-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      dc6db24d
    • G
      x86/acpi: Enable MADT APIs to return disabled apicids · 8ad893fa
      Gu Zheng 提交于
      The whole patch-set aims at making cpuid <-> nodeid mapping persistent. So that,
      when node online/offline happens, cache based on cpuid <-> nodeid mapping such as
      wq_numa_possible_cpumask will not cause any problem.
      It contains 4 steps:
      1. Enable apic registeration flow to handle both enabled and disabled cpus.
      2. Introduce a new array storing all possible cpuid <-> apicid mapping.
      3. Enable _MAT and MADT relative apis to return non-present or disabled cpus' apicid.
      4. Establish all possible cpuid <-> nodeid mapping.
      
      This patch finishes step 3.
      
      There are four mappings in the kernel:
      1. nodeid (logical node id)   <->   pxm        (persistent)
      2. apicid (physical cpu id)   <->   nodeid     (persistent)
      3. cpuid (logical cpu id)     <->   apicid     (not persistent, now persistent by step 2)
      4. cpuid (logical cpu id)     <->   nodeid     (not persistent)
      
      So, in order to setup persistent cpuid <-> nodeid mapping for all possible CPUs,
      we should:
      1. Setup cpuid <-> apicid mapping for all possible CPUs, which has been done in step 1, 2.
      2. Setup cpuid <-> nodeid mapping for all possible CPUs. But before that, we should
         obtain all apicids from MADT.
      
      All processors' apicids can be obtained by _MAT method or from MADT in ACPI.
      The current code ignores disabled processors and returns -ENODEV.
      
      After this patch, a new parameter will be added to MADT APIs so that caller
      is able to control if disabled processors are ignored.
      Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Signed-off-by: NZhu Guihua <zhugh.fnst@cn.fujitsu.com>
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Cc: mika.j.penttila@gmail.com
      Cc: len.brown@intel.com
      Cc: rafael@kernel.org
      Cc: rjw@rjwysocki.net
      Cc: yasu.isimatu@gmail.com
      Cc: linux-mm@kvack.org
      Cc: linux-acpi@vger.kernel.org
      Cc: isimatu.yasuaki@jp.fujitsu.com
      Cc: gongzhaogang@inspur.com
      Cc: tj@kernel.org
      Cc: izumi.taku@jp.fujitsu.com
      Cc: cl@linux.com
      Cc: chen.tang@easystack.cn
      Cc: akpm@linux-foundation.org
      Cc: kamezawa.hiroyu@jp.fujitsu.com
      Cc: lenb@kernel.org
      Link: http://lkml.kernel.org/r/1472114120-3281-5-git-send-email-douly.fnst@cn.fujitsu.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      8ad893fa
    • D
      nfit: fail DSMs that return non-zero status by default · 11294d63
      Dan Williams 提交于
      For the DSMs where the kernel knows the format of the output buffer and
      originates those DSMs from within the kernel, return -EIO for any
      non-zero status.  If the BIOS is indicating a status that we do not know
      how to handle, fail the DSM.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      11294d63
  16. 21 9月, 2016 1 次提交
  17. 20 9月, 2016 1 次提交
  18. 17 9月, 2016 6 次提交
  19. 13 9月, 2016 2 次提交
    • J
      ACPI / APD: constify local structures · a217726a
      Julia Lawall 提交于
      For structure types defined in the same file or local header files, find
      top-level static structure declarations that have the following
      properties:
      1. Never reassigned.
      2. Address never taken
      3. Not passed to a top-level macro call
      4. No pointer or array-typed field passed to a function or stored in a
      variable.
      Declare structures having all of these properties as const.
      
      Done using Coccinelle.
      Based on a suggestion by Joe Perches <joe@perches.com>.
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a217726a
    • T
      ACPI: Add new IORT functions to support MSI domain handling · 4bf2efd2
      Tomasz Nowicki 提交于
      For ITS, MSI functionality consists on building domain stack and
      during that process we need to reference to domain stack components
      e.g. before we create new DOMAIN_BUS_PCI_MSI domain we need to specify
      its DOMAIN_BUS_NEXUS parent domain. In order to manage that process
      properly, maintain list which elements contain domain token
      (unique for MSI domain stack) and ITS ID: iort_register_domain_token()
      and iort_deregister_domain_token(). Then retrieve domain token
      any time later with ITS ID being key off: iort_find_domain_token().
      With domain token and domain type we are able to find corresponding
      IRQ domain.
      
      Since IORT is prepared to describe MSI domain on a per-device basis,
      use existing IORT helpers and implement two calls:
      1. iort_msi_map_rid() to map MSI RID for a device
      2. iort_get_device_domain() to find domain token for a device
      Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
      Acked-by: NRafael J. Wysocki <rjw@rjwysocki.net>
      Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      4bf2efd2