Eric Lee / smarc-fsl-linux-kernel

30 Dec, 2020

1 commit

  • c5f7d6244   Revert "ACPI / resources: Use AE_CTRL_TERMINATE to terminate resources walks" ... Browse Code »

    commit 12fc4dad94dfac25599f31257aac181c691ca96f upstream.

    This reverts commit 8a66790b7850a6669129af078768a1d42076a0ef.

    Switching this function to AE_CTRL_TERMINATE broke the documented
    behaviour of acpi_dev_get_resources() - AE_CTRL_TERMINATE does not, in
    fact, terminate the resource walk because acpi_walk_resource_buffer()
    ignores it (specifically converting it to AE_OK), referring to that
    value as "an OK termination by the user function". This means that
    acpi_dev_get_resources() does not abort processing when the preproc
    function returns a negative value.

    Signed-off-by: Daniel Scally
    Cc: 3.10+ # 3.10+
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Greg Kroah-Hartman

    Daniel Scally
     

09 Jul, 2020

1 commit

  • 57d2dd4bd   ACPI: Use fallthrough pseudo-keyword ... Browse Code »

    Replace the existing /* fall through */ comments and its variants with
    the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
    fall-through markings when it is the case.

    Link: https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through # [1]
    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: Rafael J. Wysocki

    Gustavo A. R. Silva
     

18 Oct, 2019

1 commit

  • 933ca4e32   acpi: Use pr_warn instead of pr_warning ... Browse Code »

    As said in commit f2c2cbcc35d4 ("powerpc: Use pr_warn instead of
    pr_warning"), removing pr_warning so all logging messages use a
    consistent _warn style. Let's do it.

    Link: http://lkml.kernel.org/r/20191018031850.48498-8-wangkefeng.wang@huawei.com
    To: linux-kernel@vger.kernel.org
    Cc: "Rafael J. Wysocki"
    Cc: Len Brown
    Cc: James Morse
    Signed-off-by: Kefeng Wang
    Reviewed-by: Sergey Senozhatsky
    [pmladek@suse.com: two more indentation fixes]
    Signed-off-by: Petr Mladek

    Kefeng Wang
     

31 May, 2019

1 commit

  • 1802d0bee   treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174 ... Browse Code »

    Based on 1 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
    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-only

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

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

    Thomas Gleixner
     

25 Feb, 2019

1 commit

09 Nov, 2017

1 commit

07 Aug, 2017

1 commit

  • c04ac679c   ACPI: Introduce DMA ranges parsing ... Browse Code »

    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: Lorenzo Pieralisi
    Tested-by: Nate Watterson
    Signed-off-by: Rafael J. Wysocki

    Lorenzo Pieralisi
     

04 Aug, 2017

1 commit

  • 4f0450af5   ACPI: Make acpi_dev_get_resources() method agnostic ... Browse Code »

    The function acpi_dev_get_resources() is completely generic and
    can be used to parse resource objects that are not necessarily
    coming from the _CRS method but also from other objects eg _DMA
    that have the same _CRS resource format.

    Create an acpi_dev_get_resources() helper, internal to the ACPI
    resources parsing compilation unit, __acpi_dev_get_resources(),
    that takes a const char* parameter to detect which ACPI method should be
    called to retrieve the resources list and make acpi_dev_get_resources()
    call it with a method name _CRS leaving the API behaviour unchanged.

    Signed-off-by: Lorenzo Pieralisi
    Tested-by: Nate Watterson
    Signed-off-by: Rafael J. Wysocki

    Lorenzo Pieralisi
     

28 Feb, 2017

1 commit

03 Feb, 2017

1 commit

  • fa20b176f   ACPI: Generic GSI: Do not attempt to map non-GSI IRQs during bus scan ... Browse Code »

    ACPI extended IRQ resources may contain a Resource Source field to specify
    an alternate interrupt controller, attempting to map them as GSIs is
    incorrect, so just disable the platform resource.

    Since this field is currently ignored, we make this change conditional
    on CONFIG_ACPI_GENERIC_GSI to keep the current behavior on x86 platforms,
    in case some existing ACPI tables are using this incorrectly.

    Acked-by: Rafael J. Wysocki
    Acked-by: Lorenzo Pieralisi
    Reviewed-by: Hanjun Guo
    Tested-by: Hanjun Guo
    Signed-off-by: Agustin Vega-Frias
    Signed-off-by: Marc Zyngier

    Agustin Vega-Frias
     

02 Dec, 2016

1 commit

  • 00710984e   ACPI: Add acpi_resource_consumer() to find device that claims a resource ... Browse Code »

    Add acpi_resource_consumer(). This takes a struct resource and searches
    the ACPI namespace for a device whose current resource settings (_CRS)
    includes the resource. It returns the device if it exists, or NULL if no
    device uses the resource.

    If more than one device uses the resource (this may happen in the case of
    bridges), acpi_resource_consumer() returns the first one found by
    acpi_get_devices() in its modified depth-first walk of the namespace.

    Signed-off-by: Bjorn Helgaas
    Acked-by: Rafael J. Wysocki

    Bjorn Helgaas
     

23 Mar, 2016

1 commit

  • 4a2e7aab4   PCI: ACPI: IA64: fix IO port generic range check ... Browse Code »

    The [0 - 64k] ACPI PCI IO port resource boundary check in:

    acpi_dev_ioresource_flags()

    is currently applied blindly in the ACPI resource parsing to all
    architectures, but only x86 suffers from that IO space limitation.

    On arches (ie IA64 and ARM64) where IO space is memory mapped,
    the PCI root bridges IO resource windows are firstly initialized from
    the _CRS (in acpi_decode_space()) and contain the CPU physical address
    at which a root bridge decodes IO space in the CPU physical address
    space with the offset value representing the offset required to translate
    the PCI bus address into the CPU physical address.

    The IO resource windows are then parsed and updated in arch code
    before creating and enumerating PCI buses (eg IA64 add_io_space())
    to map in an arch specific way the obtained CPU physical address range
    to a slice of virtual address space reserved to map PCI IO space,
    ending up with PCI bridges resource windows containing IO
    resources like the following on a working IA64 configuration:

    PCI host bridge to bus 0000:00
    pci_bus 0000:00: root bus resource [io 0x1000000-0x100ffff window] (bus
    address [0x0000-0xffff])
    pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000fffff window]
    pci_bus 0000:00: root bus resource [mem 0x80000000-0x8fffffff window]
    pci_bus 0000:00: root bus resource [mem 0x80004000000-0x800ffffffff window]
    pci_bus 0000:00: root bus resource [bus 00]

    This implies that the [0 - 64K] check in acpi_dev_ioresource_flags()
    leaves platforms with memory mapped IO space (ie IA64) broken (ie kernel
    can't claim IO resources since the host bridge IO resource is disabled
    and discarded by ACPI core code, see log on IA64 with missing root bridge
    IO resource, silently filtered by current [0 - 64k] check in
    acpi_dev_ioresource_flags()):

    PCI host bridge to bus 0000:00
    pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000fffff window]
    pci_bus 0000:00: root bus resource [mem 0x80000000-0x8fffffff window]
    pci_bus 0000:00: root bus resource [mem 0x80004000000-0x800ffffffff window]
    pci_bus 0000:00: root bus resource [bus 00]

    [...]

    pci 0000:00:03.0: [1002:515e] type 00 class 0x030000
    pci 0000:00:03.0: reg 0x10: [mem 0x80000000-0x87ffffff pref]
    pci 0000:00:03.0: reg 0x14: [io 0x1000-0x10ff]
    pci 0000:00:03.0: reg 0x18: [mem 0x88020000-0x8802ffff]
    pci 0000:00:03.0: reg 0x30: [mem 0x88000000-0x8801ffff pref]
    pci 0000:00:03.0: supports D1 D2
    pci 0000:00:03.0: can't claim BAR 1 [io 0x1000-0x10ff]: no compatible
    bridge window

    For this reason, the IO port resources boundaries check in generic ACPI
    parsing code should be guarded with a CONFIG_X86 guard so that more arches
    (ie ARM64) can benefit from the generic ACPI resources parsing interface
    without incurring in unexpected resource filtering, fixing at the same
    time current breakage on IA64.

    This patch factors out IO ports boundary [0 - 64k] check in generic ACPI
    code and makes the IO space check X86 specific to make sure that IO
    space resources are usable on other arches too.

    Fixes: 3772aea7d6f3 (ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge)
    Signed-off-by: Lorenzo Pieralisi
    Cc: 4.4+ # 4.4+
    Signed-off-by: Rafael J. Wysocki

    Lorenzo Pieralisi
     

01 Jan, 2016

1 commit

17 Oct, 2015

1 commit

01 Sep, 2015

1 commit

  • 73990fc81   Merge branches 'acpi-scan', 'acpi-processor' and 'acpi-assorted' ... Browse Code »

    * acpi-scan:
    ACPI / bus: Move ACPI bus type registration
    ACPI / scan: Move bus operations and notification routines to bus.c
    ACPI / scan: Move device matching code to bus.c
    ACPI / scan: Move sysfs-related device code to a separate file

    * acpi-processor:
    PCC: Disable compilation by default
    ACPI: Decouple ACPI idle and ACPI processor drivers
    ACPI: Split out ACPI PSS from ACPI Processor driver
    PCC: Initialize PCC Mailbox earlier at boot
    ACPI / processor: remove leftover __refdata annotations

    * acpi-assorted:
    ACPI: fix acpi_debugfs_init prototype
    ACPI: Remove FSF mailing addresses

    Rafael J. Wysocki
     

17 Jul, 2015

1 commit

10 Jul, 2015

1 commit

  • 1fb01ca93   ACPI / PCI: Fix regressions caused by resource_size_t overflow with 32-bit kernel ... Browse Code »

    Zoltan Boszormenyi reported this regression:
    "There's a Realtek RTL8111/8168/8411 (PCI ID 10ec:8168, Subsystem ID
    1565:230e) network chip on the mainboard. After the r8169 driver loaded
    the IRQs in the machine went berserk. Keyboard keypressed arrived with
    considerable latency and duplicated, so no real work was possible.
    The machine responded to the power button but didn't actually power
    down. It just stuck at the powering down message. I had to press the
    power button for 4 seconds to power it down.

    The computer is a POS machine with a big battery inside. Because of this,
    either ACPI or the Realtek chip kept the bad state and after rebooting,
    the network chip didn't even show up in lspci. Not even the PXE ROM
    announced itself during boot. I had to disconnect the battery to beat
    some sense back to the computer.

    The regression happens with 4.0.5, 4.1.0-rc8 and 4.1.0-final. 3.18.16 was
    good."

    The regression is caused by commit 593669c2ac0f (x86/PCI/ACPI: Use common
    ACPI resource interfaces to simplify implementation). Since commit
    593669c2ac0f, x86 PCI ACPI host bridge driver validates ACPI resources by
    first converting an ACPI resource to a 'struct resource' structure and
    then applying checks against the converted resource structure. The 'start'
    and 'end' fields in 'struct resource' are defined to be type of
    resource_size_t, which may be 32 bits or 64 bits depending on
    CONFIG_PHYS_ADDR_T_64BIT.

    This may cause incorrect resource validation results with 32-bit kernels
    because 64-bit ACPI resource descriptors may get truncated when converting
    to 32-bit 'start' and 'end' fields in 'struct resource'. It eventually
    affects PCI resource allocation subsystem and makes some PCI devices and
    the system behave abnormally due to incorrect resource assignment.

    So enhance the ACPI resource parsing interfaces to ignore ACPI resource
    descriptors with address/offset above 4G when running in 32-bit mode.

    With the fix applied, the behavior of the machine was restored to how
    3.18.16 worked, i.e. the memory range that is over 4GB is ignored again,
    and lspci -vvxxx shows that everything is at the same memory window as
    they were with 3.18.16.

    Reported-and-tested-by: Boszormenyi Zoltan
    Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation)
    Signed-off-by: Jiang Liu
    Cc: 4.0+ # 4.0+
    Signed-off-by: Rafael J. Wysocki

    Jiang Liu
     

08 Jul, 2015

1 commit

07 Jul, 2015

1 commit

  • 0294112ee   ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage ... Browse Code »

    This effectively reverts the following three commits:

    7bc10388ccdd ACPI / resources: free memory on error in add_region_before()
    0f1b414d1907 ACPI / PNP: Avoid conflicting resource reservations
    b9a5e5e18fbf ACPI / init: Fix the ordering of acpi_reserve_resources()

    (commit b9a5e5e18fbf introduced regressions some of which, but not
    all, were addressed by commit 0f1b414d1907 and commit 7bc10388ccdd
    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 b9a5e5e18fbf).
    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 0f1b414d1907.

    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 0f1b414d1907 wouldn't be
    necessary any more.

    For this reason, the changes made by commit 0f1b414d1907 are reverted
    (along with a memory leak fixup on top of that commit), the changes
    made by commit b9a5e5e18fbf 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: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()"
    Reported-by: Roland Dreier
    Cc: All applicable
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

25 Jun, 2015

1 commit

19 Jun, 2015

1 commit

  • 0f1b414d1   ACPI / PNP: Avoid conflicting resource reservations ... Browse Code »

    Commit b9a5e5e18fbf "ACPI / init: Fix the ordering of
    acpi_reserve_resources()" overlooked the fact that the memory
    and/or I/O regions reserved by acpi_reserve_resources() may
    conflict with those reserved by the PNP "system" driver.

    If that conflict actually takes place, it causes the reservations
    made by the "system" driver to fail while before commit b9a5e5e18fbf
    all reservations made by it and by acpi_reserve_resources() would be
    successful. In turn, that allows the resources that haven't been
    reserved by the "system" driver to be used by others (e.g. PCI) which
    sometimes leads to functional problems (up to and including boot
    failures).

    To fix that issue, introduce a common resource reservation routine,
    acpi_reserve_region(), to be used by both acpi_reserve_resources()
    and the "system" driver, that will track all resources reserved by
    it and avoid making conflicting requests.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
    Link: http://marc.info/?t=143389402600001&r=1&w=2
    Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()"
    Reported-by: Roland Dreier
    Cc: All applicable
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

01 May, 2015

1 commit

  • 2c62e8492   x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff] available on PCI bus ... Browse Code »

    An IO port or MMIO resource assigned to a PCI host bridge may be
    consumed by the host bridge itself or available to its child
    bus/devices. The ACPI specification defines a bit (Producer/Consumer)
    to tell whether the resource is consumed by the host bridge itself,
    but firmware hasn't used that bit consistently, so we can't rely on it.

    Before commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource
    interfaces to simplify implementation"), arch/x86/pci/acpi.c ignored
    all IO port resources defined by acpi_resource_io and
    acpi_resource_fixed_io to filter out IO ports consumed by the host
    bridge itself.

    Commit 593669c2ac0f ("x86/PCI/ACPI: Use common ACPI resource interfaces
    to simplify implementation") started accepting all IO port and MMIO
    resources, which caused a regression that IO port resources consumed
    by the host bridge itself became available to its child devices.

    Then commit 63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
    host bridge itself") ignored resources consumed by the host bridge
    itself by checking the IORESOURCE_WINDOW flag, which accidently removed
    MMIO resources defined by acpi_resource_memory24, acpi_resource_memory32
    and acpi_resource_fixed_memory32.

    On x86 and IA64 platforms, all IO port and MMIO resources are assumed
    to be available to child bus/devices except one special case:
    IO port [0xCF8-0xCFF] is consumed by the host bridge itself
    to access PCI configuration space.

    So explicitly filter out PCI CFG IO ports[0xCF8-0xCFF]. This solution
    will also ease the way to consolidate ACPI PCI host bridge common code
    from x86, ia64 and ARM64.

    Related ACPI table are archived at:
    https://bugzilla.kernel.org/show_bug.cgi?id=94221

    Related discussions at:
    http://patchwork.ozlabs.org/patch/461633/
    https://lkml.org/lkml/2015/3/29/304

    Fixes: 63f1789ec716 (Ignore resources consumed by host bridge itself)
    Reported-by: Bernhard Thaler
    Signed-off-by: Jiang Liu
    Cc: 4.0+ # 4.0+
    Reviewed-by: Bjorn Helgaas
    Signed-off-by: Rafael J. Wysocki

    Jiang Liu
     

04 Mar, 2015

1 commit

  • aa714d286   x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around BIOS bugs ... Browse Code »

    Some BIOSes report incorrect length for ACPI address space descriptors,
    so relax the checks to avoid regressions. This issue has appeared several
    times as:
    3162b6f0c5e1 ("PNPACPI: truncate _CRS windows with _LEN > _MAX - _MIN + 1")
    d558b483d5a7 ("x86/PCI: truncate _CRS windows with _LEN > _MAX - _MIN + 1")
    f238b414a74a ("PNPACPI: compute Address Space length rather than using _LEN")
    48728e077480 ("x86/PCI: compute Address Space length rather than using _LEN")

    Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=94221
    for more details and example malformed ACPI resource descriptors.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=94221
    Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces ...)
    Signed-off-by: Jiang Liu
    Tested-by: Dave Airlie
    Tested-by: Prakash Punnoor
    Signed-off-by: Rafael J. Wysocki

    Jiang Liu
     

18 Feb, 2015

1 commit

05 Feb, 2015

1 commit

  • 90e978206   resources: Move struct resource_list_entry from ACPI into resource core ... Browse Code »

    Currently ACPI, PCI and pnp all implement the same resource list
    management with different data structure. We need to transfer from
    one data structure into another when passing resources from one
    subsystem into another subsystem. So move struct resource_list_entry
    from ACPI into resource core and rename it as resource_entry,
    then it could be reused by different subystems and avoid the data
    structure conversion.

    Introduce dedicated header file resource_ext.h instead of embedding
    it into ioport.h to avoid header file inclusion order issues.

    Signed-off-by: Jiang Liu
    Acked-by: Vinod Koul
    Signed-off-by: Rafael J. Wysocki

    Jiang Liu
     

04 Feb, 2015

15 commits