17 Aug, 2016

1 commit

  • The Makefile currently controlling compilation of this code is:

    obj-y += pnp.o
    pnp-y := core.o compat.o

    ...meaning that it currently is not being built as a module by anyone.

    Lets remove the couple traces of modular infrastructure use, so that
    when reading the driver there is no doubt it is builtin-only.

    Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

    We also delete the MODULE_LICENSE tag etc. since all that information
    is already contained at the top of the file in the comments.

    We don't replace module.h with init.h since the file already has that.
    But we do add moduleparam.h since the file does use module_param().

    Signed-off-by: Paul Gortmaker
    Acked-by: Jaroslav Kysela
    Signed-off-by: Rafael J. Wysocki

    Paul Gortmaker
     

28 Jul, 2016

1 commit

  • Fix build errors due to missing header file:

    ../drivers/pnp/pnpbios/core.c: In function 'pnp_dock_event':
    ../drivers/pnp/pnpbios/core.c:141:2: error: implicit declaration of function 'call_usermodehelper' [-Werror=implicit-function-declaration]
    value = call_usermodehelper(argv [0], argv, envp, UMH_WAIT_EXEC);
    ^
    ../drivers/pnp/pnpbios/core.c:141:52: error: 'UMH_WAIT_EXEC' undeclared (first use in this function)
    value = call_usermodehelper(argv [0], argv, envp, UMH_WAIT_EXEC);
    ^
    Signed-off-by: Randy Dunlap
    Signed-off-by: Rafael J. Wysocki

    Randy Dunlap
     

27 Jul, 2016

1 commit


15 Jul, 2016

1 commit

  • struct thread_info is a legacy mess. To prepare for its partial removal,
    move thread_info::addr_limit out.

    As an added benefit, this way is simpler.

    Signed-off-by: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/15bee834d09402b47ac86f2feccdf6529f9bc5b0.1468527351.git.luto@kernel.org
    Signed-off-by: Ingo Molnar

    Andy Lutomirski
     

06 Jul, 2016

1 commit

  • The Kconfig currently controlling compilation of this code is:

    config PNPBIOS
    bool "Plug and Play BIOS support"

    ...meaning that it currently is not being built as a module by anyone.

    Lets remove the couple traces of modularity, so that when reading the
    driver there is no doubt it is builtin-only.

    Since module_init translates to device_initcall in the non-modular
    case, the init ordering remains unchanged with this commit.

    Signed-off-by: Paul Gortmaker
    Signed-off-by: Rafael J. Wysocki

    Paul Gortmaker
     

21 May, 2016

1 commit

  • Pull driver core updates from Greg KH:
    "Here's the "big" driver core update for 4.7-rc1.

    Mostly just debugfs changes, the long-known and messy races with
    removing debugfs files should be fixed thanks to the great work of
    Nicolai Stange. We also have some isa updates in here (the x86
    maintainers told me to take it through this tree), a new warning when
    we run out of dynamic char major numbers, and a few other assorted
    changes, details in the shortlog.

    All have been in linux-next for some time with no reported issues"

    * tag 'driver-core-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (32 commits)
    Revert "base: dd: don't remove driver_data in -EPROBE_DEFER case"
    gpio: ws16c48: Utilize the ISA bus driver
    gpio: 104-idio-16: Utilize the ISA bus driver
    gpio: 104-idi-48: Utilize the ISA bus driver
    gpio: 104-dio-48e: Utilize the ISA bus driver
    watchdog: ebc-c384_wdt: Utilize the ISA bus driver
    iio: stx104: Utilize the module_isa_driver and max_num_isa_dev macros
    iio: stx104: Add X86 dependency to STX104 Kconfig option
    Documentation: Add ISA bus driver documentation
    isa: Implement the max_num_isa_dev macro
    isa: Implement the module_isa_driver macro
    pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS
    isa: Decouple X86_32 dependency from the ISA Kconfig option
    driver-core: use 'dev' argument in dev_dbg_ratelimited stub
    base: dd: don't remove driver_data in -EPROBE_DEFER case
    kernfs: Move faulting copy_user operations outside of the mutex
    devcoredump: add scatterlist support
    debugfs: unproxify files created through debugfs_create_u32_array()
    debugfs: unproxify files created through debugfs_create_blob()
    debugfs: unproxify files created through debugfs_create_bool()
    ...

    Linus Torvalds
     

02 May, 2016

1 commit

  • The PNPBIOS driver requires preprocessor defines (located in
    include/asm/segment.h) only declared if the architecture is set to
    X86_32. If the architecture is set to X86_64, the PNPBIOS driver will
    not build properly. The X86 dependecy for the PNPBIOS configuration
    option is changed to an explicit X86_32 dependency in order to prevent
    an attempt to build for an unsupported architecture.

    Acked-by: Rafael J. Wysocki
    Signed-off-by: William Breathitt Gray
    Signed-off-by: Greg Kroah-Hartman

    William Breathitt Gray
     

22 Apr, 2016

1 commit

  • Since we are removing paravirt_enabled() replace it with a
    logical equivalent. Even though PNPBIOS is x86 specific we
    add an arch-specific type call, which can be implemented by
    any architecture to show how other legacy attribute devices
    can later be also checked for with other ACPI legacy attribute
    flags.

    This implicates the first ACPI 5.2.9.3 IA-PC Boot Architecture
    ACPI_FADT_LEGACY_DEVICES flag device, and shows how to add more.

    The reason pnpbios gets a defined structure and as such uses
    a different approach than the RTC legacy quirk is that ACPI
    has a respective RTC flag, while pnpbios does not. We fold
    the pnpbios quirk under ACPI_FADT_LEGACY_DEVICES ACPI flag
    use case, and use a struct of possible devices to enable
    future extensions of this.

    As per 0-day, this bumps the vmlinux size using i386-tinyconfig as
    follows:

    TOTAL TEXT init.text x86_early_init_platform_quirks()
    +32 +28 +28 +28

    That's 4 byte overhead total, the rest is cleared out on init
    as its all __init text.

    v2: split out subarch handlng on switch to make it easier
    later to add other subarchs. The 'fall-through' switch
    handling can be confusing and we'll remove it later
    when we add handling for X86_SUBARCH_CE4100.
    v3: document vmlinux size impact as per 0-day, and also
    explain why pnpbios is treated differently than the
    RTC legacy feature.

    Signed-off-by: Luis R. Rodriguez
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: Greg Kroah-Hartman
    Cc: H. Peter Anvin
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: andrew.cooper3@citrix.com
    Cc: andriy.shevchenko@linux.intel.com
    Cc: bigeasy@linutronix.de
    Cc: boris.ostrovsky@oracle.com
    Cc: david.vrabel@citrix.com
    Cc: ffainelli@freebox.fr
    Cc: george.dunlap@citrix.com
    Cc: glin@suse.com
    Cc: jgross@suse.com
    Cc: jlee@suse.com
    Cc: josh@joshtriplett.org
    Cc: julien.grall@linaro.org
    Cc: konrad.wilk@oracle.com
    Cc: kozerkov@parallels.com
    Cc: lenb@kernel.org
    Cc: lguest@lists.ozlabs.org
    Cc: linux-acpi@vger.kernel.org
    Cc: lv.zheng@intel.com
    Cc: matt@codeblueprint.co.uk
    Cc: mbizon@freebox.fr
    Cc: rjw@rjwysocki.net
    Cc: robert.moore@intel.com
    Cc: rusty@rustcorp.com.au
    Cc: tiwai@suse.de
    Cc: toshi.kani@hp.com
    Cc: xen-devel@lists.xensource.com
    Link: http://lkml.kernel.org/r/1460592286-300-12-git-send-email-mcgrof@kernel.org
    Signed-off-by: Ingo Molnar

    Luis R. Rodriguez
     

10 Mar, 2016

1 commit

  • An error message is printed for resources of type 19, which is a valid
    supported resource type. The Firmware Test Suite tool (fwts) reports
    this as a test failure. This change fixes the false test failures
    for ASL that use type 19 (ACPI_RESOURCE_TYPE_SERIAL_BUS) resources.

    Signed-off-by: Harb Abdulhamid
    Signed-off-by: Timur Tabi
    Signed-off-by: Rafael J. Wysocki

    Harb Abdulhamid
     

03 Feb, 2016

1 commit

  • Add device ID 0x0a04 for Haswell-ULT to the list of devices with MCH
    problems.

    From a Lenovo ThinkPad T440S:
    [ 0.188604] pnp: PnP ACPI init
    [ 0.189044] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
    [ 0.189048] system 00:00: [mem 0x000c0000-0x000c3fff] could not be reserved
    [ 0.189050] system 00:00: [mem 0x000c4000-0x000c7fff] could not be reserved
    [ 0.189052] system 00:00: [mem 0x000c8000-0x000cbfff] could not be reserved
    [ 0.189054] system 00:00: [mem 0x000cc000-0x000cffff] could not be reserved
    [ 0.189056] system 00:00: [mem 0x000d0000-0x000d3fff] has been reserved
    [ 0.189058] system 00:00: [mem 0x000d4000-0x000d7fff] has been reserved
    [ 0.189060] system 00:00: [mem 0x000d8000-0x000dbfff] has been reserved
    [ 0.189061] system 00:00: [mem 0x000dc000-0x000dffff] has been reserved
    [ 0.189063] system 00:00: [mem 0x000e0000-0x000e3fff] could not be reserved
    [ 0.189065] system 00:00: [mem 0x000e4000-0x000e7fff] could not be reserved
    [ 0.189067] system 00:00: [mem 0x000e8000-0x000ebfff] could not be reserved
    [ 0.189069] system 00:00: [mem 0x000ec000-0x000effff] could not be reserved
    [ 0.189071] system 00:00: [mem 0x000f0000-0x000fffff] could not be reserved
    [ 0.189073] system 00:00: [mem 0x00100000-0xdf9fffff] could not be reserved
    [ 0.189075] system 00:00: [mem 0xfec00000-0xfed3ffff] could not be reserved
    [ 0.189078] system 00:00: [mem 0xfed4c000-0xffffffff] could not be reserved
    [ 0.189082] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active)
    [ 0.189216] system 00:01: [io 0x1800-0x189f] could not be reserved
    [ 0.189220] system 00:01: [io 0x0800-0x087f] has been reserved
    [ 0.189222] system 00:01: [io 0x0880-0x08ff] has been reserved
    [ 0.189224] system 00:01: [io 0x0900-0x097f] has been reserved
    [ 0.189226] system 00:01: [io 0x0980-0x09ff] has been reserved
    [ 0.189229] system 00:01: [io 0x0a00-0x0a7f] has been reserved
    [ 0.189231] system 00:01: [io 0x0a80-0x0aff] has been reserved
    [ 0.189233] system 00:01: [io 0x0b00-0x0b7f] has been reserved
    [ 0.189235] system 00:01: [io 0x0b80-0x0bff] has been reserved
    [ 0.189238] system 00:01: [io 0x15e0-0x15ef] has been reserved
    [ 0.189240] system 00:01: [io 0x1600-0x167f] has been reserved
    [ 0.189242] system 00:01: [io 0x1640-0x165f] has been reserved
    [ 0.189246] system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
    [ 0.189249] system 00:01: [mem 0x00000000-0x00000fff] could not be reserved
    [ 0.189251] system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved
    [ 0.189254] system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
    [ 0.189256] system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
    [ 0.189258] system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
    [ 0.189261] system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved
    [ 0.189264] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
    [....]
    [ 0.583653] resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than pnp 00:01 [mem 0xfed10000-0xfed13fff]
    [ 0.583654] ------------[ cut here ]------------
    [ 0.583660] WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:198 __ioremap_caller+0x2c5/0x380()
    [ 0.583661] Info: mapping multiple BARs. Your kernel is fine.
    [ 0.583662] Modules linked in:

    [ 0.583666] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.3-303.fc23.x86_64 #1
    [ 0.583668] Hardware name: LENOVO 20AR001GXS/20AR001GXS, BIOS GJET86WW (2.36 ) 12/04/2015
    [ 0.583670] 0000000000000000 0000000014cf7e59 ffff880214a1baf8 ffffffff813a625f
    [ 0.583673] ffff880214a1bb40 ffff880214a1bb30 ffffffff810a07c2 00000000fed10000
    [ 0.583675] ffffc90000cb8000 0000000000006000 0000000000000000 ffff8800d6381040
    [ 0.583678] Call Trace:
    [ 0.583683] [] dump_stack+0x44/0x55
    [ 0.583686] [] warn_slowpath_common+0x82/0xc0
    [ 0.583688] [] warn_slowpath_fmt+0x5c/0x80
    [ 0.583692] [] ? iomem_map_sanity_check+0xba/0xd0
    [ 0.583695] [] __ioremap_caller+0x2c5/0x380
    [ 0.583698] [] ioremap_nocache+0x17/0x20
    [ 0.583701] [] snb_uncore_imc_init_box+0x79/0xb0
    [ 0.583705] [] uncore_pci_probe+0xd0/0x1b0
    [ 0.583707] [] local_pci_probe+0x45/0xa0
    [ 0.583710] [] pci_device_probe+0xfd/0x140
    [ 0.583713] [] driver_probe_device+0x222/0x480
    [ 0.583715] [] __driver_attach+0x84/0x90
    [ 0.583717] [] ? driver_probe_device+0x480/0x480
    [ 0.583720] [] bus_for_each_dev+0x6c/0xc0
    [ 0.583722] [] driver_attach+0x1e/0x20
    [ 0.583724] [] bus_add_driver+0x1eb/0x280
    [ 0.583727] [] ? uncore_cpu_setup+0x12/0x12
    [ 0.583729] [] driver_register+0x60/0xe0
    [ 0.583733] [] __pci_register_driver+0x4c/0x50
    [ 0.583736] [] intel_uncore_init+0xe2/0x2e6
    [ 0.583738] [] ? uncore_cpu_setup+0x12/0x12
    [ 0.583741] [] do_one_initcall+0xb3/0x200
    [ 0.583745] [] ? parse_args+0x1a0/0x4a0
    [ 0.583749] [] kernel_init_freeable+0x189/0x223
    [ 0.583752] [] ? rest_init+0x80/0x80
    [ 0.583754] [] kernel_init+0xe/0xe0
    [ 0.583758] [] ret_from_fork+0x3f/0x70
    [ 0.583760] [] ? rest_init+0x80/0x80
    [ 0.583765] ---[ end trace 077c426a39e018aa ]---

    00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 0b)
    Subsystem: Lenovo Device [17aa:220c]
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
    Kernel driver in use: hsw_uncore

    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1300955
    Tested-by:
    Signed-off-by: Josh Boyer
    Signed-off-by: Rafael J. Wysocki

    Josh Boyer
     

05 Jan, 2016

1 commit

  • I have a device (Nuvoton 6779D Super-IO IR RC with nuvoton-cir driver)
    which works after initial boot but not any longer if I unload and
    re-load the driver module.

    Digging into the issue I found that unloading the driver calls
    pnp_disable_dev although the driver has flag PNP_DRIVER_RES_DO_NOT_CHANGE
    set. IMHO this is not right.

    Let's have a look at the call chain when probing a device:
    pnp_device_probe
    1. attaches the device
    2. if it's not active and PNP_DRIVER_RES_DO_NOT_CHANGE is not set
    it gets activated
    3. probes driver

    I think pnp_device_remove should do it in reverse order and also
    respect PNP_DRIVER_RES_DO_NOT_CHANGE. Therefore:
    1. call drivers remove callback
    2. if device is active and PNP_DRIVER_RES_DO_NOT_CHANGE is not set
    disable it
    3. detach device

    The change works for me and sounds logical to me.
    However I don't know the pnp driver in detail so I might be wrong.

    Signed-off-by: Heiner Kallweit
    Signed-off-by: Rafael J. Wysocki

    Heiner Kallweit
     

03 Jan, 2016

1 commit

  • Add device ID 0x1604 for Broadwell to commit cb171f7abb9a ("PNP:
    Work around BIOS defects in Intel MCH area reporting").

    >From a Lenovo ThinkPad T550:

    system 00:01: [io 0x1800-0x189f] could not be reserved
    system 00:01: [io 0x0800-0x087f] has been reserved
    system 00:01: [io 0x0880-0x08ff] has been reserved
    system 00:01: [io 0x0900-0x097f] has been reserved
    system 00:01: [io 0x0980-0x09ff] has been reserved
    system 00:01: [io 0x0a00-0x0a7f] has been reserved
    system 00:01: [io 0x0a80-0x0aff] has been reserved
    system 00:01: [io 0x0b00-0x0b7f] has been reserved
    system 00:01: [io 0x0b80-0x0bff] has been reserved
    system 00:01: [io 0x15e0-0x15ef] has been reserved
    system 00:01: [io 0x1600-0x167f] has been reserved
    system 00:01: [io 0x1640-0x165f] has been reserved
    system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
    system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved
    system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
    system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
    system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
    system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved
    system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
    [...]
    resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than pnp 00:01 [mem 0xfed10000-0xfed13fff]
    ------------[ cut here ]------------
    WARNING: CPU: 2 PID: 1 at /build/linux-CrHvZ_/linux-4.2.6/arch/x86/mm/ioremap.c:198 __ioremap_caller+0x2ee/0x360()
    Info: mapping multiple BARs. Your kernel is fine.
    Modules linked in:
    CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.2.0-1-amd64 #1 Debian 4.2.6-1
    Hardware name: LENOVO 20CKCTO1WW/20CKCTO1WW, BIOS N11ET34W (1.10 ) 08/20/2015
    0000000000000000 ffffffff817e6868 ffffffff8154e2f6 ffff8802241efbf8
    ffffffff8106e5b1 ffffc90000e98000 0000000000006000 ffffc90000e98000
    0000000000006000 0000000000000000 ffffffff8106e62a ffffffff817e68c8
    Call Trace:
    [] ? dump_stack+0x40/0x50
    [] ? warn_slowpath_common+0x81/0xb0
    [] ? warn_slowpath_fmt+0x4a/0x50
    [] ? iomem_map_sanity_check+0xb3/0xc0
    [] ? __ioremap_caller+0x2ee/0x360
    [] ? snb_uncore_imc_init_box+0x66/0x90
    [] ? uncore_pci_probe+0xc8/0x1a0
    [] ? local_pci_probe+0x3f/0xa0
    [] ? pci_device_probe+0xc4/0x110
    [] ? driver_probe_device+0x1ee/0x450
    [] ? __driver_attach+0x7b/0x80
    [] ? driver_probe_device+0x450/0x450
    [] ? bus_for_each_dev+0x5a/0x90
    [] ? bus_add_driver+0x1f1/0x290
    [] ? uncore_cpu_setup+0xc/0xc
    [] ? driver_register+0x5f/0xe0
    [] ? intel_uncore_init+0xcc/0x2b0
    [] ? uncore_cpu_setup+0xc/0xc
    [] ? do_one_initcall+0xce/0x200
    [] ? parse_args+0x140/0x4e0
    [] ? kernel_init_freeable+0x162/0x1e8
    [] ? rest_init+0x80/0x80
    [] ? kernel_init+0xe/0xf0
    [] ? ret_from_fork+0x3f/0x70
    [] ? rest_init+0x80/0x80
    ---[ end trace 472e7959536abf12 ]---

    00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
    Subsystem: Lenovo Device 2223
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
    Kernel driver in use: bdw_uncore
    00: 86 80 04 16 06 00 90 20 09 00 00 06 00 00 00 00
    10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 23 22
    30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00

    Signed-off-by: Christophe Le Roy
    Signed-off-by: Rafael J. Wysocki

    Christophe Le Roy
     

15 Sep, 2015

1 commit


11 Aug, 2015

1 commit

  • Quoting Arnd:
    I was thinking the opposite approach and basically removing all uses
    of IORESOURCE_CACHEABLE from the kernel. There are only a handful of
    them.and we can probably replace them all with hardcoded
    ioremap_cached() calls in the cases they are actually useful.

    All existing usages of IORESOURCE_CACHEABLE call ioremap() instead of
    ioremap_nocache() if the resource is cacheable, however ioremap() is
    uncached by default. Clearly none of the existing usages care about the
    cacheability. Particularly devm_ioremap_resource() never worked as
    advertised since it always fell back to plain ioremap().

    Clean this up as the new direction we want is to convert
    ioremap_() usages to memremap(..., flags).

    Suggested-by: Arnd Bergmann
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Dan Williams

    Dan Williams
     

07 Jul, 2015

1 commit

  • 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
     

19 Jun, 2015

2 commits

  • * pnp:
    PNP / ACPI: use unsigned int in pnpacpi_encode_resources()
    PNP / ACPI: use u8 instead of int in acpi_resource_extended_irq context

    * pm-tools:
    cpupower: mperf monitor: fix output in MAX_FREQ_SYSFS mode

    Rafael J. Wysocki
     
  • 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
     

06 May, 2015

2 commits


15 Apr, 2015

1 commit

  • Pull power management and ACPI updates from Rafael Wysocki:
    "These are mostly fixes and cleanups all over, although there are a few
    items that sort of fall into the new feature category.

    First off, we have new callbacks for PM domains that should help us to
    handle some issues related to device initialization in a better way.

    There also is some consolidation in the unified device properties API
    area allowing us to use that inferface for accessing data coming from
    platform initialization code in addition to firmware-provided data.

    We have some new device/CPU IDs in a few drivers, support for new
    chips and a new cpufreq driver too.

    Specifics:

    - Generic PM domains support update including new PM domain callbacks
    to handle device initialization better (Russell King, Rafael J
    Wysocki, Kevin Hilman)

    - Unified device properties API update including a new mechanism for
    accessing data provided by platform initialization code (Rafael J
    Wysocki, Adrian Hunter)

    - ARM cpuidle update including ARM32/ARM64 handling consolidation
    (Daniel Lezcano)

    - intel_idle update including support for the Silvermont Core in the
    Baytrail SOC and for the Airmont Core in the Cherrytrail and
    Braswell SOCs (Len Brown, Mathias Krause)

    - New cpufreq driver for Hisilicon ACPU (Leo Yan)

    - intel_pstate update including support for the Knights Landing chip
    (Dasaratharaman Chandramouli, Kristen Carlson Accardi)

    - QorIQ cpufreq driver update (Tang Yuantian, Arnd Bergmann)

    - powernv cpufreq driver update (Shilpasri G Bhat)

    - devfreq update including Tegra support changes (Tomeu Vizoso,
    MyungJoo Ham, Chanwoo Choi)

    - powercap RAPL (Running-Average Power Limit) driver update including
    support for Intel Broadwell server chips (Jacob Pan, Mathias Krause)

    - ACPI device enumeration update related to the handling of the
    special PRP0001 device ID allowing DT-style 'compatible' property
    to be used for ACPI device identification (Rafael J Wysocki)

    - ACPI EC driver update including limited _DEP support (Lan Tianyu,
    Lv Zheng)

    - ACPI backlight driver update including a new mechanism to allow
    native backlight handling to be forced on non-Windows 8 systems and
    a new quirk for Lenovo Ideapad Z570 (Aaron Lu, Hans de Goede)

    - New Windows Vista compatibility quirk for Sony VGN-SR19XN (Chen Yu)

    - Assorted ACPI fixes and cleanups (Aaron Lu, Martin Kepplinger,
    Masanari Iida, Mika Westerberg, Nan Li, Rafael J Wysocki)

    - Fixes related to suspend-to-idle for the iTCO watchdog driver and
    the ACPI core system suspend/resume code (Rafael J Wysocki, Chen Yu)

    - PM tracing support for the suspend phase of system suspend/resume
    transitions (Zhonghui Fu)

    - Configurable delay for the system suspend/resume testing facility
    (Brian Norris)

    - PNP subsystem cleanups (Peter Huewe, Rafael J Wysocki)"

    * tag 'pm+acpi-4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (74 commits)
    ACPI / scan: Fix NULL pointer dereference in acpi_companion_match()
    ACPI / scan: Rework modalias creation when "compatible" is present
    intel_idle: mark cpu id array as __initconst
    powercap / RAPL: mark rapl_ids array as __initconst
    powercap / RAPL: add ID for Broadwell server
    intel_pstate: Knights Landing support
    intel_pstate: remove MSR test
    cpufreq: fix qoriq uniprocessor build
    ACPI / scan: Take the PRP0001 position in the list of IDs into account
    ACPI / scan: Simplify acpi_match_device()
    ACPI / scan: Generalize of_compatible matching
    device property: Introduce firmware node type for platform data
    device property: Make it possible to use secondary firmware nodes
    PM / watchdog: iTCO: stop watchdog during system suspend
    cpufreq: hisilicon: add acpu driver
    ACPI / EC: Call acpi_walk_dep_device_list() after installing EC opregion handler
    cpufreq: powernv: Report cpu frequency throttling
    intel_idle: Add support for the Airmont Core in the Cherrytrail and Braswell SOCs
    intel_idle: Update support for Silvermont Core in Baytrail SOC
    PM / devfreq: tegra: Register governor on module init
    ...

    Linus Torvalds
     

19 Mar, 2015

2 commits

  • pnp_register_protocol() and __pnp_add_device() both have a problem
    that if device_register() fails, the objects they create will be left
    in the lists they have been put one beforehand. Unfortunately, that
    is not handled by the callers of those routines either, so in case
    of a device registration errors the PNP bus type's data structures
    will end up in an inconsistent state.

    Make pnp_register_protocol() and __pnp_add_device() remove the
    objects from the lists if device registration fails.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     
  • pnp_lock is a spinlock, but it is only acquired from process context,
    so it may be a mutex just fine.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

16 Mar, 2015

1 commit


13 Mar, 2015

1 commit

  • After 0509ad5e1a7d ("PNP: disable PNP motherboard resources that overlap
    PCI BARs"), we disable and warn about PNP resources that overlap PCI BARs.
    But we assume that all PCI BARs are valid, which is incorrect, because a
    BAR may not have any space assigned to it. In that case, we will not
    enable the BAR, so no other resource can conflict with it.

    Ignore PCI BARs that are unassigned, as indicated by IORESOURCE_UNSET.

    Firmware often leaves PCI BARs unassigned, containing zero. Zero is a
    valid BAR value, so we can't just check for that, but the PCI core can set
    IORESOURCE_UNSET when it detects an unassigned BAR by other means. This
    should get rid of many of the annoying messages like this:

    pnp 00:00: disabling [io 0x0061] because it overlaps 0001:05:00.0 BAR 0 [io 0x0000-0x00ff]

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

    Bjorn Helgaas
     

21 Feb, 2015

1 commit

  • * pnp:
    PNP: Switch from __check_region() to __request_region()

    * pm-cpuidle:
    cpuidle: powernv: Avoid endianness conversions while parsing DT
    cpuidle: powernv: Read target_residency value of idle states from DT if available

    * pm-cpufreq:
    cpufreq: s3c: remove last use of resume_clocks callback
    cpufreq: s3c: remove incorrect __init annotations

    Rafael J. Wysocki
     

16 Feb, 2015

2 commits

  • Pull tty/serial driver patches from Greg KH:
    "Here's the big tty/serial driver update for 3.20-rc1. Nothing huge
    here, just lots of driver updates and some core tty layer fixes as
    well. All have been in linux-next with no reported issues"

    * tag 'tty-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (119 commits)
    serial: 8250: Fix UART_BUG_TXEN workaround
    serial: driver for ETRAX FS UART
    tty: remove unused variable sprop
    serial: of-serial: fetch line number from DT
    serial: samsung: earlycon support depends on CONFIG_SERIAL_SAMSUNG_CONSOLE
    tty/serial: serial8250_set_divisor() can be static
    tty/serial: Add Spreadtrum sc9836-uart driver support
    Documentation: DT: Add bindings for Spreadtrum SoC Platform
    serial: samsung: remove redundant interrupt enabling
    tty: Remove external interface for tty_set_termios()
    serial: omap: Fix RTS handling
    serial: 8250_omap: Use UPSTAT_AUTORTS for RTS handling
    serial: core: Rework hw-assisted flow control support
    tty/serial: 8250_early: Add support for PXA UARTs
    tty/serial: of_serial: add support for PXA/MMP uarts
    tty/serial: of_serial: add DT alias ID handling
    serial: 8250: Prevent concurrent updates to shadow registers
    serial: 8250: Use canary to restart console after suspend
    serial: 8250: Refactor XR17V35X divisor calculation
    serial: 8250: Refactor divisor programming
    ...

    Linus Torvalds
     
  • Pull char / misc patches from Greg KH:
    "Here's the big char/misc driver update for 3.20-rc1.

    Lots of little things in here, all described in the changelog.
    Nothing major or unusual, except maybe the binder selinux stuff, which
    was all acked by the proper selinux people and they thought it best to
    come through this tree.

    All of this has been in linux-next with no reported issues for a while"

    * tag 'char-misc-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (90 commits)
    coresight: fix function etm_writel_cp14() parameter order
    coresight-etm: remove check for unknown Kconfig macro
    coresight: fixing CPU hwid lookup in device tree
    coresight: remove the unnecessary function coresight_is_bit_set()
    coresight: fix the debug AMBA bus name
    coresight: remove the extra spaces
    coresight: fix the link between orphan connection and newly added device
    coresight: remove the unnecessary replicator property
    coresight: fix the replicator subtype value
    pdfdocs: Fix 'make pdfdocs' failure for 'uio-howto.tmpl'
    mcb: Fix error path of mcb_pci_probe
    virtio/console: verify device has config space
    ti-st: clean up data types (fix harmless memory corruption)
    mei: me: release hw from reset only during the reset flow
    mei: mask interrupt set bit on clean reset bit
    extcon: max77693: Constify struct regmap_config
    extcon: adc-jack: Release IIO channel on driver remove
    extcon: Remove duplicated include from extcon-class.c
    Drivers: hv: vmbus: hv_process_timer_expiration() can be static
    Drivers: hv: vmbus: serialize Offer and Rescind offer
    ...

    Linus Torvalds
     

04 Feb, 2015

1 commit


03 Feb, 2015

1 commit

  • If the serial console is an ACPI PNP device, the PNP bus always powers
    down the device at system suspend, even though the no_console_suspend
    command line parameter is specified (eg., when debugging suspend/resume).

    Add PNP_CONSOLE capability, which when set, prevents calling both the
    ->disable() and ->suspend() PNP protocol methods if console suspend
    is disabled.

    Signed-off-by: Peter Hurley
    Signed-off-by: Greg Kroah-Hartman

    Peter Hurley
     

26 Jan, 2015

2 commits

  • struct acpi_resource_address and struct acpi_resource_extended_address64 share substracts
    just at different offsets. To unify the parsing functions, OSPMs like Linux
    need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can
    extract the shared data.

    This patch also synchronizes the structure changes to the Linux kernel.
    The usages are searched by matching the following keywords:
    1. acpi_resource_address
    2. acpi_resource_extended_address
    3. ACPI_RESOURCE_TYPE_ADDRESS
    4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS
    And we found and fixed the usages in the following files:
    arch/ia64/kernel/acpi-ext.c
    arch/ia64/pci/pci.c
    arch/x86/pci/acpi.c
    arch/x86/pci/mmconfig-shared.c
    drivers/xen/xen-acpi-memhotplug.c
    drivers/acpi/acpi_memhotplug.c
    drivers/acpi/pci_root.c
    drivers/acpi/resource.c
    drivers/char/hpet.c
    drivers/pnp/pnpacpi/rsparser.c
    drivers/hv/vmbus_drv.c

    Build tests are passed with defconfig/allnoconfig/allyesconfig and
    defconfig+CONFIG_ACPI=n.

    Original-by: Thomas Gleixner
    Original-by: Jiang Liu
    Signed-off-by: Lv Zheng
    Signed-off-by: Rafael J. Wysocki

    Lv Zheng
     
  • A small number of systems respond to PnP dock queries with bogus values.
    This causes us to keep logging an error every 2 seconds. Instead of trying
    again just assume the BIOS is crapware and doesn't actually have dock
    functionality.

    Signed-off-by: Alan Cox
    Signed-off-by: Greg Kroah-Hartman

    Alan Cox
     

22 Jan, 2015

1 commit

  • PNP core is the last user of the __check_region() which has been
    deprecated for almost 12 years (since v2.5.54). Replace it with a combo
    of __request_region() followed by __release_region().

    pnp_check_port() and pnp_check_mem() remain racy after this change.

    Signed-off-by: Jakub Sitnicki
    Signed-off-by: Rafael J. Wysocki

    Jakub Sitnicki
     

14 Oct, 2014

1 commit

  • The kernel used to contain two functions for length-delimited,
    case-insensitive string comparison, strnicmp with correct semantics and
    a slightly buggy strncasecmp. The latter is the POSIX name, so strnicmp
    was renamed to strncasecmp, and strnicmp made into a wrapper for the new
    strncasecmp to avoid breaking existing users.

    To allow the compat wrapper strnicmp to be removed at some point in the
    future, and to avoid the extra indirection cost, do
    s/strnicmp/strncasecmp/g.

    Signed-off-by: Rasmus Villemoes
    Cc: "Rafael J. Wysocki"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rasmus Villemoes
     

23 Jul, 2014

1 commit

  • The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to
    return the handle of the device's ACPI companion, so it is much
    more straightforward and efficient to use ACPI_COMPANION()
    directly to obtain the device's ACPI companion object instead of
    using ACPI_HANDLE() and acpi_bus_get_device() on the returned
    handle for the same thing.

    Do that in several places in the ACPI PNP core code.

    Also use acpi_device_set_power() and acpi_device_power_manageable()
    instead of acpi_bus_set_power() and acpi_bus_power_manageable(),
    respectively, because the former two are more efficient if the
    ACPI device object is already available.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

07 Jul, 2014

1 commit

  • PNPACPI uses acpi_bus_type to do ACPI binding for the PNPACPI devices.

    This is overkill because PNPACPI code already knows which ACPI
    device object to bind during PNPACPI device enumeration.

    This patch removes acpi_pnp_bus and does the binding by invoking
    acpi_bind_one() directly after device enumerated.

    This also fixes a bug in the previous code that some PNPACPI devices failed
    to be bound because
    1. the ACPI device _HID is not pnpid, e.g. "MSFT0001", but its _CID is,
    e.g. "PNP0303", thus ACPI _CID is used as the pnp device device id.
    2. device is bound only if the pnp device id matches the ACPI device _HID.

    Tested-by: Prigent Christophe
    Signed-off-by: Zhang Rui
    Signed-off-by: Rafael J. Wysocki

    Zhang Rui
     

04 Jun, 2014

1 commit

  • * pnp:
    MAINTAINERS: Remove Bjorn Helgaas as PNP maintainer
    PNP / resources: remove positive test on unsigned values

    * powercap:
    powercap / RAPL: add new CPU IDs
    powercap / RAPL: further relax energy counter checks

    * pm-runtime:
    PM / runtime: Update documentation to reflect the current code flow

    * pm-opp:
    PM / OPP: discard duplicate OPPs
    PM / OPP: Make OPP invisible to users in Kconfig
    PM / OPP: fix incorrect OPP count handling in of_init_opp_table

    Rafael J. Wysocki
     

30 May, 2014

1 commit

  • ACPI can be used to enumerate PNP devices, but the code does not
    handle this in the right way currently. Namely, if an ACPI device
    object
    1. Has a _CRS method,
    2. Has an identification of
    "three capital characters followed by four hex digits",
    3. Is not in the excluded IDs list,
    it will be enumerated to PNP bus (that is, a PNP device object will
    be create for it). This means that, actually, the PNP bus type is
    used as the default bus type for enumerating _HID devices in ACPI.

    However, more and more _HID devices need to be enumerated to the
    platform bus instead (that is, platform device objects need to be
    created for them). As a result, the device ID list in acpi_platform.c
    is used to enforce creating platform device objects rather than PNP
    device objects for matching devices. That list has been continuously
    growing recently, unfortunately, and it is pretty much guaranteed to
    grow even more in the future.

    To address that problem it is better to enumerate _HID devices
    as platform devices by default. To this end, change the way of
    enumerating PNP devices by adding a PNP ACPI scan handler that
    will use a device ID list to create PNP devices for the ACPI
    device objects whose device IDs are present in that list.

    The initial device ID list in the PNP ACPI scan handler contains
    all of the pnp_device_id strings from all the existing PNP drivers,
    so this change should be transparent to the PNP core and all of the
    PNP drivers. Still, in the future it should be possible to reduce
    its size by converting PNP drivers that need not be PNP for any
    technical reasons into platform drivers.

    Signed-off-by: Zhang Rui
    [rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
    Signed-off-by: Rafael J. Wysocki
    Reviewed-by: Mika Westerberg

    Zhang Rui
     

10 May, 2014

1 commit


06 May, 2014

1 commit


01 May, 2014

1 commit

  • The ACPI PNP subsystem returns errors from pnpacpi_set_resources()
    and pnpacpi_disable_resources() if the _SRS or _DIS methods are not
    present, respectively, but it should not do that, because those
    methods are optional. For this reason, modify pnpacpi_set_resources()
    and pnpacpi_disable_resources(), respectively, to ignore missing _SRS
    or _DIS.

    This problem has been uncovered by commit 202317a573b2 (ACPI / scan:
    Add acpi_device objects for all device nodes in the namespace) and
    manifested itself by causing serial port suspend to fail on some
    systems.

    Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
    References: https://bugzilla.kernel.org/show_bug.cgi?id=74371
    Reported-by: wxg4net
    Reported-and-tested-by:
    Cc: 3.14+ # 3.14+
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki