Eric Lee / smarc-fsl-linux-kernel

09 Aug, 2019

1 commit

  • 2c2b005f5   ACPI / processor: don't print errors for processorIDs == 0xff ... Browse Code »

    Some platforms define their processors in this manner:
    Device (SCK0)
    {
    Name (_HID, "ACPI0004" /* Module Device */) // _HID: Hardware ID
    Name (_UID, "CPUSCK0") // _UID: Unique ID
    Processor (CP00, 0x00, 0x00000410, 0x06){}
    Processor (CP01, 0x02, 0x00000410, 0x06){}
    Processor (CP02, 0x04, 0x00000410, 0x06){}
    Processor (CP03, 0x06, 0x00000410, 0x06){}
    Processor (CP04, 0x01, 0x00000410, 0x06){}
    Processor (CP05, 0x03, 0x00000410, 0x06){}
    Processor (CP06, 0x05, 0x00000410, 0x06){}
    Processor (CP07, 0x07, 0x00000410, 0x06){}
    Processor (CP08, 0xFF, 0x00000410, 0x06){}
    Processor (CP09, 0xFF, 0x00000410, 0x06){}
    Processor (CP0A, 0xFF, 0x00000410, 0x06){}
    Processor (CP0B, 0xFF, 0x00000410, 0x06){}
    ...

    The processors marked as 0xff are invalid, there are only 8 of them in
    this case.

    So do not print an error on ids == 0xff, just print an info message.
    Actually, we could return ENODEV even on the first CPU with ID 0xff, but
    ACPI spec does not forbid the 0xff value to be a processor ID. Given
    0xff could be a correct one, we would break working systems if we
    returned ENODEV.

    Signed-off-by: Jiri Slaby
    Signed-off-by: Rafael J. Wysocki

    Jiri Slaby
     

19 Jun, 2019

1 commit

  • d2912cb15   treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 ... Browse Code »

    Based on 2 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 version 2 as
    published by the free software foundation

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation #

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 4122 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Enrico Weigelt
    Reviewed-by: Kate Stewart
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

04 Oct, 2018

1 commit

  • d0381bf4f   ACPI / processor: Fix the return value of acpi_processor_ids_walk() ... Browse Code »

    ACPI driver should make sure all the processor IDs in their ACPI Namespace
    are unique. the driver performs a depth-first walk of the namespace tree
    and calls the acpi_processor_ids_walk() to check the duplicate IDs.

    But, the acpi_processor_ids_walk() mistakes the return value. If a
    processor is checked, it returns true which causes the walk break
    immediately, and other processors will never be checked.

    Repace the value with AE_OK which is the standard acpi_status value.
    And don't abort the namespace walk even on error.

    Fixes: 8c8cb30f49b8 (acpi/processor: Implement DEVICE operator for processor enumeration)
    Signed-off-by: Dou Liyang
    Signed-off-by: Rafael J. Wysocki

    Dou Liyang
     

09 Nov, 2017

1 commit

24 Aug, 2017

1 commit

18 Apr, 2017

1 commit

  • 35b687359   ACPI / Processor: Drop setup_max_cpus check from acpi_processor_add() ... Browse Code »

    When maxcpus=X kernel argument is used, we parse the ACPI tables only
    for the first X cpus. The per-cpu ACPI data include the _PSD tables
    which gives information about related cpus.

    cppc_cpufreq and acpi-cpufreq parses the table once during init to
    deduce the related cpus. If a user brings a new cpu online after boot
    the related cpu data becomes incorrect.

    acpi_get_psd_map() in acpi_cppc.c returns error if it fails to find
    the parsed ACPI data for possible CPU resulting in cppc_cpufreq
    initialization failure.

    With this change we will probe all possible CPUs prior to cpufreq
    initialization, but will bring only setup_max_cpus online. nr_cpus
    kernel parameter can be used to restict even parsing per-cpu ACPI
    tables.

    Signed-off-by: Prashanth Prakash
    [ rjw: Subject ]
    Signed-off-by: Rafael J. Wysocki

    Prakash, Prashanth
     

11 Mar, 2017

3 commits

  • a77d6cd96   acpi/processor: Check for duplicate processor ids at hotplug time ... Browse Code »

    The check for duplicate processor ids happens at boot time based on the
    ACPI table contents, but the final sanity checks for a processor happen
    at hotplug time.

    At hotplug time, where the physical information is available, which might
    differ from the ACPI table information, a check for duplicate processor
    ids is missing.

    Add it to the hotplug checks and rename the function so it better
    reflects its purpose.

    Signed-off-by: Dou Liyang
    Tested-by: Xiaolong Ye
    Cc: rjw@rjwysocki.net
    Cc: linux-acpi@vger.kernel.org
    Cc: guzheng1@huawei.com
    Cc: izumi.taku@jp.fujitsu.com
    Cc: lenb@kernel.org
    Link: http://lkml.kernel.org/r/1488528147-2279-6-git-send-email-douly.fnst@cn.fujitsu.com
    Signed-off-by: Thomas Gleixner

    Dou Liyang
     
  • 8c8cb30f4   acpi/processor: Implement DEVICE operator for processor enumeration ... Browse Code »

    ACPI allows to declare processors either with the PROCESSOR or with the
    DEVICE operator. The current implementation handles only the PROCESSOR
    operator.

    On a system which uses the DEVICE operator for processor enumeration the
    evaluation fails.

    Check for the ACPI type of the ACPI handle and evaluate PROCESSOR and
    DEVICE types separately.

    Signed-off-by: Dou Liyang
    Tested-by: Xiaolong Ye
    Cc: rjw@rjwysocki.net
    Cc: linux-acpi@vger.kernel.org
    Cc: guzheng1@huawei.com
    Cc: izumi.taku@jp.fujitsu.com
    Cc: lenb@kernel.org
    Link: http://lkml.kernel.org/r/1488528147-2279-5-git-send-email-douly.fnst@cn.fujitsu.com
    Signed-off-by: Thomas Gleixner

    Dou Liyang
     
  • c962cff17   Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when booting" ... Browse Code »

    Revert: dc6db24d2476 ("x86/acpi: Set persistent cpuid nodeid mapping when booting")

    The mapping of "cpuid nodeid" is established at boot time via ACPI
    tables to keep associations of workqueues and other node related items
    consistent across cpu hotplug.

    But, ACPI tables are unreliable and failures with that boot time mapping
    have been reported on machines where the ACPI table and the physical
    information which is retrieved at actual hotplug is inconsistent.

    Revert the mapping implementation so it can be replaced with a less error
    prone approach.

    Signed-off-by: Dou Liyang
    Tested-by: Xiaolong Ye
    Cc: rjw@rjwysocki.net
    Cc: linux-acpi@vger.kernel.org
    Cc: guzheng1@huawei.com
    Cc: izumi.taku@jp.fujitsu.com
    Cc: lenb@kernel.org
    Link: http://lkml.kernel.org/r/1488528147-2279-2-git-send-email-douly.fnst@cn.fujitsu.com
    Signed-off-by: Thomas Gleixner

    Dou Liyang
     

07 Feb, 2017

1 commit

  • febf24074   x86/ACPI: keep x86_cpu_to_acpiid mapping valid on CPU hotplug ... Browse Code »

    We may or may not have all possible CPUs in MADT on boot but in any
    case we're overwriting x86_cpu_to_acpiid mapping with U32_MAX when
    acpi_register_lapic() is called again on the CPU hotplug path:

    acpi_processor_hotadd_init()
    -> acpi_map_cpu()
    -> acpi_register_lapic()

    As we have the required acpi_id information in acpi_processor_hotadd_init()
    propagate it to acpi_map_cpu() to always keep x86_cpu_to_acpiid
    mapping valid.

    Reported-by: Andrew Jones
    Signed-off-by: Vitaly Kuznetsov
    Signed-off-by: Rafael J. Wysocki

    Vitaly Kuznetsov
     

22 Sep, 2016

4 commits

  • fd74da217   acpi: Validate processor id when mapping the processor ... Browse Code »

    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: Dou Liyang
    Acked-by: Ingo Molnar
    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.com
    Signed-off-by: Thomas Gleixner

    Dou Liyang
     
  • 8e089eaa1   acpi: Provide mechanism to validate processors in the ACPI tables ... Browse Code »

    [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: Dou Liyang
    Acked-by: Ingo Molnar
    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.com
    Signed-off-by: Thomas Gleixner

    Dou Liyang
     
  • dc6db24d2   x86/acpi: Set persistent cpuid <-> nodeid mapping when booting ... Browse Code »

    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: Gu Zheng
    Signed-off-by: Tang Chen
    Signed-off-by: Zhu Guihua
    Signed-off-by: Dou Liyang
    Acked-by: Ingo Molnar
    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.com
    Signed-off-by: Thomas Gleixner

    Gu Zheng
     
  • 8ad893faf   x86/acpi: Enable MADT APIs to return disabled apicids ... Browse Code »

    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: Gu Zheng
    Signed-off-by: Tang Chen
    Signed-off-by: Zhu Guihua
    Signed-off-by: Dou Liyang
    Acked-by: Ingo Molnar
    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.com
    Signed-off-by: Thomas Gleixner

    Gu Zheng
     

02 Jun, 2016

1 commit

  • 86314751c   ACPI / processor: Avoid reserving IO regions too early ... Browse Code »

    Roland Dreier reports that one of his systems cannot boot because of
    the changes made by commit ac212b6980d8 (ACPI / processor: Use common
    hotplug infrastructure).

    The problematic part of it is the request_region() call in
    acpi_processor_get_info() that used to run at module init time before
    the above commit and now it runs much earlier. Unfortunately, the
    region(s) reserved by it fall into a range the PCI subsystem attempts
    to reserve for AHCI IO BARs. As a result, the PCI reservation fails
    and AHCI doesn't work, while previously the PCI reservation would
    be made before acpi_processor_get_info() and it would succeed.

    That request_region() call, however, was overlooked by commit
    ac212b6980d8, as it is not necessary for the enumeration of the
    processors. It only is needed when the ACPI processor driver
    actually attempts to handle them which doesn't happen before
    loading the ACPI processor driver module. Therefore that call
    should have been moved from acpi_processor_get_info() into that
    module.

    Address the problem by moving the request_region() call in question
    out of acpi_processor_get_info() and use the observation that the
    region reserved by it is only needed if the FADT-based CPU
    throttling method is going to be used, which means that it should
    be sufficient to invoke it from acpi_processor_get_throttling_fadt().

    Fixes: ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure)
    Reported-by: Roland Dreier
    Tested-by: Roland Dreier
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

26 Mar, 2016

1 commit

  • a21211672   ACPI / processor: Request native thermal interrupt handling via _OSC ... Browse Code »

    There are several reports of freeze on enabling HWP (Hardware PStates)
    feature on Skylake-based systems by the Intel P-states driver. The root
    cause is identified as the HWP interrupts causing BIOS code to freeze.

    HWP interrupts use the thermal LVT which can be handled by Linux
    natively, but on the affected Skylake-based systems SMM will respond
    to it by default. This is a problem for several reasons:
    - On the affected systems the SMM thermal LVT handler is broken (it
    will crash when invoked) and a BIOS update is necessary to fix it.
    - With thermal interrupt handled in SMM we lose all of the reporting
    features of the arch/x86/kernel/cpu/mcheck/therm_throt driver.
    - Some thermal drivers like x86-package-temp depend on the thermal
    threshold interrupts signaled via the thermal LVT.
    - The HWP interrupts are useful for debugging and tuning
    performance (if the kernel can handle them).
    The native handling of thermal interrupts needs to be enabled
    because of that.

    This requires some way to tell SMM that the OS can handle thermal
    interrupts. That can be done by using _OSC/_PDC in processor
    scope very early during ACPI initialization.

    The meaning of _OSC/_PDC bit 12 in processor scope is whether or
    not the OS supports native handling of interrupts for Collaborative
    Processor Performance Control (CPPC) notifications. Since on
    HWP-capable systems CPPC is a firmware interface to HWP, setting
    this bit effectively tells the firmware that the OS will handle
    thermal interrupts natively going forward.

    For details on _OSC/_PDC refer to:
    http://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html

    To implement the _OSC/_PDC handshake as described, introduce a new
    function, acpi_early_processor_osc(), that walks the ACPI
    namespace looking for ACPI processor objects and invokes _OSC for
    them with bit 12 in the capabilities buffer set and terminates the
    namespace walk on the first success.

    Also modify intel_thermal_interrupt() to clear HWP status bits in
    the HWP_STATUS MSR to acknowledge HWP interrupts (which prevents
    them from firing continuously).

    Signed-off-by: Srinivas Pandruvada
    [ rjw: Subject & changelog, function rename ]
    Signed-off-by: Rafael J. Wysocki

    Srinivas Pandruvada
     

22 Feb, 2016

1 commit

  • db62fda31   ACPI / processor : add support for ACPI0010 processor container ... Browse Code »

    ACPI 6.0 adds support for optional processor container device which may
    contain child objects that are either processor devices or other processor
    containers. This allows representing hierarchical processor topologies.

    It is declared using the _HID of ACPI0010. It is an abstract container
    used to represent CPU topology and should not be used to hotplug
    purposes.

    If no matching handler is found for a device in acpi_scan_attach_handler,
    acpi_bus_attach does a default enumeration for those devices with valid
    HID in the acpi namespace. This patch adds a scan handler for these ACPI
    processor containers to avoid default that enumeration and ensures the
    platform devices are not created for them.

    Signed-off-by: Sudeep Holla
    Signed-off-by: Rafael J. Wysocki

    Sudeep Holla
     

13 Oct, 2015

1 commit

  • 56cdc2a05   ACPI: Add weak routines for ACPI CPU Hotplug ... Browse Code »

    Add weak functions for architectures which do not support
    hot-adding and removing CPUs which aren't detected at
    bootup. (e.g. via MADT).

    This helps preserve the Kconfig dependency from:

    commit cbfc1bae55bb ("[ACPI] ACPI_HOTPLUG_CPU Kconfig dependency
    update")

    prevent:

    HOTPLUG_CPU=y
    ACPI_PROCESSOR=y
    ACPI_HOTPLUG_CPU=n

    Signed-off-by: Ashwin Chaugule
    Signed-off-by: Rafael J. Wysocki

    Ashwin Chaugule
     

21 Jul, 2015

1 commit

  • 8ce344c66   ACPI / processor: remove leftover __refdata annotations ... Browse Code »

    The processor_handler structure does not reference any __init / __exit
    code or data. Therefore the __refdata annotation is not needed. It used
    to be prior to commit fe7bf106ebc2 ("acpi: delete __cpuinit usage from
    all acpi files") due to the __cpuinit annotation of acpi_processor_add().
    But with that commit in place that requirement has gone.

    The same is true for the acpi_cpu_notifier notifier block.
    acpi_cpu_soft_notify() used to be marked __cpuinit but lost its
    annotation in the above mentioned commit as well. Therefore the __refdata
    annotation isn't needed there either.

    Just drop the unneded __refdata annotations to be able to catch future
    section mismatches.

    Signed-off-by: Mathias Krause
    Signed-off-by: Rafael J. Wysocki

    Mathias Krause
     

14 May, 2015

4 commits

26 Mar, 2015

1 commit

  • 828aef376   ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID ... Browse Code »

    CPU hardware ID (phys_id) is defined as u32 in structure acpi_processor,
    but phys_id is used as int in acpi processor driver, so it will lead to
    some inconsistence for the drivers.

    Furthermore, to cater for ACPI arch ports that implement 64 bits CPU
    ids a generic CPU physical id type is required.

    So introduce typedef u32 phys_cpuid_t in a common file, and introduce
    a macro PHYS_CPUID_INVALID as (phys_cpuid_t)(-1) if it's not defined
    by other archs, this will solve the inconsistence in acpi processor driver,
    and will prepare for the ACPI on ARM64 for the 64 bit CPU hardware ID
    in the following patch.

    CC: Rafael J Wysocki
    Suggested-by: Lorenzo Pieralisi
    Reviewed-by: Grant Likely
    Acked-by: Sudeep Holla
    Acked-by: Lorenzo Pieralisi
    Acked-by: Rafael J. Wysocki
    Signed-off-by: Catalin Marinas
    [hj: reworked cpu physid map return codes]
    Signed-off-by: Hanjun Guo
    Signed-off-by: Will Deacon

    Catalin Marinas
     

06 Jan, 2015

2 commits

  • d02dc27db   ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu() ... Browse Code »

    acpi_map_lsapic() will allocate a logical CPU number and map it to
    physical CPU id (such as APIC id) for the hot-added CPU, it will also
    do some mapping for NUMA node id and etc, acpi_unmap_lsapic() will
    do the reverse.

    We can see that the name of the function is a little bit confusing and
    arch (IA64) dependent so rename them as acpi_(un)map_cpu() to make arch
    agnostic and explicit.

    Signed-off-by: Hanjun Guo
    Signed-off-by: Rafael J. Wysocki

    Hanjun Guo
     
  • af8f3f514   ACPI / processor: Convert apic_id to phys_id to make it arch agnostic ... Browse Code »

    apic_id in MADT table is the CPU hardware id which identify
    it self in the system for x86 and ia64, OSPM will use it for
    SMP init to map APIC ID to logical cpu number in the early
    boot, when the DSDT/SSDT (ACPI namespace) is scanned later, the
    ACPI processor driver is probed and the driver will use acpi_id
    in DSDT to get the apic_id, then map to the logical cpu number
    which is needed by the processor driver.

    Before ACPI 5.0, only x86 and ia64 were supported in ACPI spec,
    so apic_id is used both in arch code and ACPI core which is
    pretty fine. Since ACPI 5.0, ARM is supported by ACPI and
    APIC is not available on ARM, this will confuse people when
    apic_id is both used by x86 and ARM in one function.

    So convert apic_id to phys_id (which is the original meaning)
    in ACPI processor dirver to make it arch agnostic, but leave the
    arch dependent code unchanged, no functional change.

    Signed-off-by: Hanjun Guo
    Signed-off-by: Rafael J. Wysocki

    Hanjun Guo
     

21 Jul, 2014

1 commit

  • b50154d53   ACPI: Don't use acpi_lapic in ACPI core code ... Browse Code »

    Now ARM64 support is being added to ACPI so architecture specific
    values can not be used in core ACPI code.

    Following on the patch "ACPI / processor: Check if LAPIC is present
    during initialization" which uses acpi_lapic in acpi_processor.c,
    on ARM64 platform, GIC is used instead of local APIC, so acpi_lapic
    is not a suitable value for ARM64.

    What is actually important at this point is if there is/are CPU
    entry/entries (Local APIC/SAPIC, GICC) in MADT, so introduce
    acpi_has_cpu_in_madt() to be arch specific and generic.

    Signed-off-by: Graeme Gregory
    Signed-off-by: Hanjun Guo
    Signed-off-by: Rafael J. Wysocki

    Graeme Gregory
     

16 May, 2014

1 commit

  • c401eb8ee   ACPI / processor: Check if LAPIC is present during initialization ... Browse Code »

    In acpi_processor_get_info(), ACPI processor info is initialized including
    ID, namely CPU index. Currently, on a UP system running an SMP kerenl with
    no LAPIC in the MADT, cpu0_initialized is checked to decide whether or not
    the CPU has been initialized.

    However, this check may not be sufficient for kdump kernels. Most of time
    only 1 CPU is supported because of known problems in kdump kernels. So say
    the multiple CPUs are present in the boot kernel and a crash happens on
    one specific CPU, say CPU2. Then it jumps into the kdump kernel with
    "nr_cpus=1" in the command line. In this situation, the kdump kernel
    will reuse the ACPI resources from the crashed kernel directly. That
    means all LAPIC instances are enabled in the MADT while only one CPU is
    in use. In the kdump kernel, x86_cpu_to_apicid contains the correct APIC
    ID and it's related to the CPU ID. If cpu0_initialized is checked only, 0
    will be used as the CPU index instead of that APIC ID, which is not
    correct.

    In addition to checking cpu0_initialized, check acpi_lapic. If acpi_lapic
    is 0, then no LAPIC is available from the MADT and the system should be
    treated as a UP one without a LAPIC (that is, assign 0 to the CPU index).
    Otherwise, use the original (valid) CPU index.

    Signed-off-by: Baoquan He
    [rjw: Subject and changelog]
    Signed-off-by: Rafael J. Wysocki

    Baoquan He
     

08 May, 2014

1 commit

  • 0b9d46dd7   ACPI / processor: do not mark present at boot but not onlined CPU as onlined ... Browse Code »

    acpi_processor_add() assumes that present at boot CPUs
    are always onlined, it is not so if a CPU failed to become
    onlined. As result acpi_processor_add() will mark such CPU
    device as onlined in sysfs and following attempts to
    online/offline it using /sys/device/system/cpu/cpuX/online
    attribute will fail.

    Do not poke into device internals in acpi_processor_add()
    and touch "struct device { .offline }" attribute, since
    for CPUs onlined at boot it's set by:
    topology_init() -> arch_register_cpu() -> register_cpu()
    before ACPI device tree is parsed, and for hotplugged
    CPUs it's set when userspace onlines CPU via sysfs.

    Signed-off-by: Igor Mammedov
    Acked-by: Toshi Kani
    Cc: 3.11+ # 3.11+
    Signed-off-by: Rafael J. Wysocki

    Igor Mammedov
     

01 May, 2014

1 commit

  • 4985c32ee   ACPI / processor: Fix failure of loading acpi-cpufreq driver ... Browse Code »

    According commit d640113fe (ACPI: processor: fix acpi_get_cpuid for UP
    processor), BIOS may not provide _MAT or MADT tables and acpi_get_apicid()
    always returns -1. For these cases, original code will pass apic_id with
    vaule of -1 to acpi_map_cpuid() and it will check the acpi_id. If acpi_id
    is equal to zero, ignores apic_id and return zero for CPU0.

    Commit b981513 (ACPI / scan: bail out early if failed to parse APIC
    ID for CPU) changed the behavior. Return ENODEV when find apic_id is
    less than zero after calling acpi_get_apicid(). This causes acpi-cpufreq
    driver fails to be loaded on some machines. This patch is to fix it.

    Fixes: b981513f806d (ACPI / scan: bail out early if failed to parse APIC ID for CPU)
    References: https://bugzilla.kernel.org/show_bug.cgi?id=73781
    Cc: 3.14+ # 3.14+
    Reported-and-tested-by: KATO Hiroshi
    Reported-and-tested-by: Stuart Foster
    Signed-off-by: Lan Tianyu
    Signed-off-by: Rafael J. Wysocki

    Lan Tianyu
     

29 Jan, 2014

1 commit

  • 82e180598   Merge branches 'acpi-processor', 'acpi-hotplug', 'acpi-init', 'acpi-pm' and 'acpica' ... Browse Code »

    * acpi-processor:
    ACPI / scan: reduce log level of "ACPI: \_PR_.CPU4: failed to get CPU APIC ID"
    ACPI / processor: Return specific error value when mapping lapic id

    * acpi-hotplug:
    ACPI / scan: Clear match_driver flag in acpi_bus_trim()

    * acpi-init:
    ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API

    * acpi-pm:
    ACPI / PM: Use ACPI_COMPANION() to get ACPI companions of devices

    * acpica:
    ACPICA: Remove bool usage from ACPICA.

    Rafael J. Wysocki
     

28 Jan, 2014

1 commit

  • f778d1218   ACPI / scan: reduce log level of "ACPI: \_PR_.CPU4: failed to get CPU APIC ID" ... Browse Code »

    Commit b981513f806d (ACPI / scan: bail out early if failed to parse
    APIC ID for CPU) emits an error message if ACPI processor driver fails
    to query APIC ID for the CPU.

    Originally it's designed to catch BIOS bugs for CPU hot-addition. But
    it accidently reveals another type of BIOS bug that:
    1) BIOS implements ACPI objects for all possible instead of present
    CPUs. (It's valid to do that per ACPI specification.)
    2) BIOS doesn't implement the _STA method for CPU objects. OSPM assumes
    that all CPU objects are present and functioning and attempts to
    use those CPU objects for CPU enumeration, which then triggers the
    error message. According to ACPI spec, BIOS should implement _STA
    for those absent CPUs at least.

    Though it's a BIOS bug in essential, there are some BIOSes in the fields
    which are implmented in this way. So reduce the log level from ERR to
    DEBUG to accommodate these existing BIOSes.

    Fixes: b981513f806d (ACPI / scan: bail out early if failed to parse APIC ID for CPU)
    Reported-and-tested-by: Jörg Otte
    Signed-off-by: Jiang Liu
    [rjw: Changelog]
    Signed-off-by: Rafael J. Wysocki

    Jiang Liu
     

13 Jan, 2014

1 commit

  • bcc7201a9   Merge branches 'acpi-gpe', 'acpi-video', 'acpi-thermal', 'acpi-processor', 'acpi-sleep' ... Browse Code »

    * acpi-gpe:
    ACPI / EC: disable GPE before removing GPE handler
    ACPI / Button: Fix enabling button GPEs twice

    * acpi-video:
    ACPI: Blacklist Win8 OSI for some HP laptop 2013 models
    ACPI / video: Fix typo in video_detect.c

    * acpi-thermal:
    ACPI / thermal: remove const from thermal_zone_device_ops declaration

    * acpi-processor:
    ACPI / scan: bail out early if failed to parse APIC ID for CPU

    * acpi-sleep:
    ACPI / sleep: remove panic in case hardware has changed after S4

    Rafael J. Wysocki
     

11 Jan, 2014

1 commit

  • b981513f8   ACPI / scan: bail out early if failed to parse APIC ID for CPU ... Browse Code »

    Enhance ACPI CPU hotplug driver to print clear error message and
    bail out early if BIOS returns wrong value in ACPI MADT table or
    _MAT method. Otherwise it will add the CPU device even if failed
    to get APIC ID and fails any operations against sysfs interface:
    /sys/devices/system/cpu/cpux/online

    Signed-off-by: Jiang Liu
    Signed-off-by: Rafael J. Wysocki

    Jiang Liu
     

07 Dec, 2013

1 commit

28 Oct, 2013

1 commit

  • 3fbc4d637   Merge branch 'acpi-processor' ... Browse Code »

    * acpi-processor:
    ACPI / processor: fixed a brace coding style issue
    ACPI / processor: Remove outdated comments
    ACPI / processor: remove unnecessary if (!pr) check
    ACPI / processor: remove some dead code in acpi_processor_get_info()
    x86 / ACPI: simplify _acpi_map_lsapic()
    ACPI / processor: use apic_id and remove duplicated _MAT evaluation
    ACPI / processor: Introduce apic_id in struct processor to save parsed APIC id

    Rafael J. Wysocki
     

24 Sep, 2013

4 commits