summaryrefslogtreecommitdiffstats
path: root/drivers/pnp (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'gpio-v4.13-1' of ↵Linus Torvalds2017-07-071-13/+25
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.13 series. Some administrativa: I have a slew of 8250 serial patches and the new IOT2040 serial+GPIO driver coming in through this tree, along with a whole bunch of Exar 8250 fixes. These are ACKed by Greg and also hit drivers/platform/* where they are ACKed by Andy Shevchenko. Speaking about drivers/platform/* there is also a bunch of ACPI stuff coming through that route, again ACKed by Andy. The MCP23S08 changes are coming in here as well. You already have the commits in your tree, so this is just a result of sharing an immutable branch between pin control and GPIO. Core: - Export add/remove for lookup tables so that modules can export GPIO descriptor tables. - Handle GPIO sleep states: it is now possible to flag that a GPIO line may loose its state during suspend/resume of the system to save power. This is used in the Wolfson Micro Arizona driver. - ACPI-based GPIO was tightened up a lot around the edges. - Use bitmap_fill() to speed up a loop. New drivers: - Exar XRA1403 SPI-based GPIO. - MVEBU driver now supports Armada 7K and 8K. - LP87565 PMIC GPIO. - Renesas R-CAR R8A7743 (RZ/G1M). - The new IOT2040 8250 serial/GPIO also comes in through this changeset. Substantial driver changes: - Seriously fix the Exar 8250 GPIO portions to work. - The MCP23S08 was moved out to a pin control driver. - Convert MEVEBU to use regmap for register access. - Drop Vulcan support from the Broadcom driver. - Serious cleanup and improvement of the mockup driver, giving us a better test coverage. Misc: - Lots of janitorial clean up. - A bunch of documentation fixes" * tag 'gpio-v4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (70 commits) serial: exar: Add support for IOT2040 device gpio-exar/8250-exar: Make set of exported GPIOs configurable platform: Accept const properties serial: exar: Factor out platform hooks gpio-exar/8250-exar: Rearrange gpiochip parenthood gpio: exar: Fix iomap request gpio-exar/8250-exar: Do not even instantiate a GPIO device for Commtech cards serial: uapi: Add support for bus termination gpio: rcar: Add R8A7743 (RZ/G1M) support gpio: gpio-wcove: Fix GPIO control register offset calculation gpio: lp87565: Add support for GPIO gpio: dwapb: fix missing first irq for edgeboth irq type MAINTAINERS: Take maintainership for GPIO ACPI support gpio: exar: Fix reading of directions and values gpio: exar: Allocate resources on behalf of the platform device gpio-exar/8250-exar: Fix passing in of parent PCI device gpio: mockup: use devm_kcalloc() where applicable gpio: mockup: add myself as author gpio: mockup: improve the error message gpio: mockup: don't return magic numbers from probe() ...
| * PNP / ACPI: remove FSF addressAndy Shevchenko2017-05-291-4/+0
| | | | | | | | | | | | | | | | | | There is no point in keeping an address in the file since it's subject to change. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * PNP / ACPI: join strings back for better maintenanceAndy Shevchenko2017-05-291-9/+9
| | | | | | | | | | | | | | | | | | | | Simply join string literals back for better maintenance and debugging. No functional changes intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
| * PNP / ACPI: add support for GpioInt resource typeJagadish Krishnamoorthy2017-05-291-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PNP ACPI driver parses ACPI interrupt resource but not GpioInt resource. When the firmware passes GpioInt resource for IRQ the PNP ACPI driver ignores it and hence the interrupt for the particular driver will not work. One such example is 8042 keyboard which uses PNP driver for obtaining the interrupt resource. On Intel Braswell project GpioInt is used instead of interrupt resource and the keyboard driver fails to register interrupt. Fix the issue by parsing GpioInt resource type. Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> [Fixed a parenthesis coding style thing] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | ACPI / PM: Consolidate device wakeup settings codeRafael J. Wysocki2017-06-281-3/+3
|/ | | | | | | | | | | | | | | | | | | | | | | Currently, there are two separate ways of handling device wakeup settings in the ACPI core, depending on whether this is runtime wakeup or system wakeup (from sleep states). However, after the previous commit eliminating the run_wake ACPI device wakeup flag, there is no difference between the two any more at the ACPI level, so they can be combined. For this reason, introduce acpi_pm_set_device_wakeup() to replace both acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake() and make it check the ACPI device object's wakeup.valid flag to determine whether or not the device can be set up to generate wakeup signals. Also notice that zpodd_enable/disable_run_wake() only call device_set_run_wake() because acpi_pm_device_run_wake() called device_run_wake(), which is not done by acpi_pm_set_device_wakeup(), so drop the now redundant device_set_run_wake() calls from there. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
* x86: Remap GDT tables in the fixmap sectionThomas Garnier2017-03-161-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section (PAGE_OFFSET). This patch relocates the GDT table for each processor inside the fixmap section. The space is reserved based on number of supported processors. For consistency, the remapping is done by default on 32 and 64-bit. Each processor switches to its remapped GDT at the end of initialization. For hibernation, the main processor returns with the original GDT and switches back to the remapping at completion. This patch was tested on both architectures. Hibernation and KVM were both tested specially for their usage of the GDT. Thanks to Boris Ostrovsky <boris.ostrovsky@oracle.com> for testing and recommending changes for Xen support. Signed-off-by: Thomas Garnier <thgarnie@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Borislav Petkov <bp@suse.de> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Joerg Roedel <joro@8bytes.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Kees Cook <keescook@chromium.org> Cc: Len Brown <len.brown@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Lorenzo Stoakes <lstoakes@gmail.com> Cc: Luis R . Rodriguez <mcgrof@kernel.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Michal Hocko <mhocko@suse.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rafael J . Wysocki <rjw@rjwysocki.net> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Stanislaw Gruszka <sgruszka@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: kasan-dev@googlegroups.com Cc: kernel-hardening@lists.openwall.com Cc: kvm@vger.kernel.org Cc: lguest@lists.ozlabs.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Cc: linux-pm@vger.kernel.org Cc: xen-devel@lists.xenproject.org Cc: zijun_hu <zijun_hu@htc.com> Link: http://lkml.kernel.org/r/20170314170508.100882-2-thgarnie@google.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
* Make static usermode helper binaries constantGreg Kroah-Hartman2017-01-191-2/+3
| | | | | | | | | | | | | | | | There are a number of usermode helper binaries that are "hard coded" in the kernel today, so mark them as "const" to make it harder for someone to change where the variables point to. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Thomas Sailer <t.sailer@alumni.ethz.ch> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: "J. Bruce Fields" <bfields@fieldses.org> Cc: Jeff Layton <jlayton@poochiereds.net> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Replace <asm/uaccess.h> with <linux/uaccess.h> globallyLinus Torvalds2016-12-242-2/+2
| | | | | | | | | | | | | This was entirely automated, using the script by Al: PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>' sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h) to do the replacement at the end of the merge window. Requested-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* PNP: isapnp: make core more explicitly non-modularPaul Gortmaker2016-08-161-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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 <paul.gortmaker@windriver.com> Acked-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* PNP: pnpbios: add header file to fix build errorsRandy Dunlap2016-07-271-0/+1
| | | | | | | | | | | | | | 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 <rdunlap@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'pnp-4.8-rc1' of ↵Linus Torvalds2016-07-271-2/+1
|\ | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull PNP update from Rafael Wysocki: "One simple change to make the PNP core use device_initcall() instead of module_init() to run pnpbios_thread_init() (Paul Gortmaker)" * tag 'pnp-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PNP: make pnpbios core explicitly non-modular
| * PNP: make pnpbios core explicitly non-modularPaul Gortmaker2016-07-051-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <paul.gortmaker@windriver.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | x86/uaccess: Move thread_info::addr_limit to thread_structAndy Lutomirski2016-07-151-1/+1
|/ | | | | | | | | | | | | | | | | | | 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 <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/15bee834d09402b47ac86f2feccdf6529f9bc5b0.1468527351.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
* Merge tag 'driver-core-4.7-rc1' of ↵Linus Torvalds2016-05-211-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core 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() ...
| * pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOSWilliam Breathitt Gray2016-05-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <rafael.j.wysocki@intel.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | x86, drivers/pnpbios: Replace paravirt_enabled() check with legacy device checkLuis R. Rodriguez2016-04-221-1/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mcgrof@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> 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 <mingo@kernel.org>
* PNP / ACPI: add ACPI_RESOURCE_TYPE_SERIAL_BUS as a valid typeHarb Abdulhamid2016-03-091-0/+4
| | | | | | | | | | | 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 <harba@codeaurora.org> Signed-off-by: Timur Tabi <timur@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* PNP: Add Haswell-ULT to Intel MCH size workaroundJosh Boyer2016-02-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] [<ffffffff813a625f>] dump_stack+0x44/0x55 [ 0.583686] [<ffffffff810a07c2>] warn_slowpath_common+0x82/0xc0 [ 0.583688] [<ffffffff810a085c>] warn_slowpath_fmt+0x5c/0x80 [ 0.583692] [<ffffffff810a6fba>] ? iomem_map_sanity_check+0xba/0xd0 [ 0.583695] [<ffffffff81065835>] __ioremap_caller+0x2c5/0x380 [ 0.583698] [<ffffffff81065907>] ioremap_nocache+0x17/0x20 [ 0.583701] [<ffffffff8103a119>] snb_uncore_imc_init_box+0x79/0xb0 [ 0.583705] [<ffffffff81038900>] uncore_pci_probe+0xd0/0x1b0 [ 0.583707] [<ffffffff813efda5>] local_pci_probe+0x45/0xa0 [ 0.583710] [<ffffffff813f118d>] pci_device_probe+0xfd/0x140 [ 0.583713] [<ffffffff814d9b52>] driver_probe_device+0x222/0x480 [ 0.583715] [<ffffffff814d9e34>] __driver_attach+0x84/0x90 [ 0.583717] [<ffffffff814d9db0>] ? driver_probe_device+0x480/0x480 [ 0.583720] [<ffffffff814d762c>] bus_for_each_dev+0x6c/0xc0 [ 0.583722] [<ffffffff814d930e>] driver_attach+0x1e/0x20 [ 0.583724] [<ffffffff814d8e4b>] bus_add_driver+0x1eb/0x280 [ 0.583727] [<ffffffff81d6af1a>] ? uncore_cpu_setup+0x12/0x12 [ 0.583729] [<ffffffff814da680>] driver_register+0x60/0xe0 [ 0.583733] [<ffffffff813ef78c>] __pci_register_driver+0x4c/0x50 [ 0.583736] [<ffffffff81d6affc>] intel_uncore_init+0xe2/0x2e6 [ 0.583738] [<ffffffff81d6af1a>] ? uncore_cpu_setup+0x12/0x12 [ 0.583741] [<ffffffff81002123>] do_one_initcall+0xb3/0x200 [ 0.583745] [<ffffffff810be500>] ? parse_args+0x1a0/0x4a0 [ 0.583749] [<ffffffff81d5c1c8>] kernel_init_freeable+0x189/0x223 [ 0.583752] [<ffffffff81775c40>] ? rest_init+0x80/0x80 [ 0.583754] [<ffffffff81775c4e>] kernel_init+0xe/0xe0 [ 0.583758] [<ffffffff81781adf>] ret_from_fork+0x3f/0x70 [ 0.583760] [<ffffffff81775c40>] ? 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- <TAbort- <MAbort+ >SERR- <PERR- INTx- Latency: 0 Capabilities: <access denied> Kernel driver in use: hsw_uncore Link: https://bugzilla.redhat.com/show_bug.cgi?id=1300955 Tested-by: <robo@tcp.sk> Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* PNP: respect PNP_DRIVER_RES_DO_NOT_CHANGE when detachingHeiner Kallweit2016-01-041-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <hkallweit1@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* PNP: Add Broadwell to Intel MCH size workaroundChristophe Le Roy2016-01-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: [<ffffffff8154e2f6>] ? dump_stack+0x40/0x50 [<ffffffff8106e5b1>] ? warn_slowpath_common+0x81/0xb0 [<ffffffff8106e62a>] ? warn_slowpath_fmt+0x4a/0x50 [<ffffffff810742a3>] ? iomem_map_sanity_check+0xb3/0xc0 [<ffffffff8105dade>] ? __ioremap_caller+0x2ee/0x360 [<ffffffff81036ae6>] ? snb_uncore_imc_init_box+0x66/0x90 [<ffffffff810351a8>] ? uncore_pci_probe+0xc8/0x1a0 [<ffffffff81302d7f>] ? local_pci_probe+0x3f/0xa0 [<ffffffff81303ea4>] ? pci_device_probe+0xc4/0x110 [<ffffffff813d9b1e>] ? driver_probe_device+0x1ee/0x450 [<ffffffff813d9dfb>] ? __driver_attach+0x7b/0x80 [<ffffffff813d9d80>] ? driver_probe_device+0x450/0x450 [<ffffffff813d796a>] ? bus_for_each_dev+0x5a/0x90 [<ffffffff813d9091>] ? bus_add_driver+0x1f1/0x290 [<ffffffff81b37fa8>] ? uncore_cpu_setup+0xc/0xc [<ffffffff813da73f>] ? driver_register+0x5f/0xe0 [<ffffffff81b38074>] ? intel_uncore_init+0xcc/0x2b0 [<ffffffff81b37fa8>] ? uncore_cpu_setup+0xc/0xc [<ffffffff8100213e>] ? do_one_initcall+0xce/0x200 [<ffffffff8108a100>] ? parse_args+0x140/0x4e0 [<ffffffff81b2b0cb>] ? kernel_init_freeable+0x162/0x1e8 [<ffffffff815443f0>] ? rest_init+0x80/0x80 [<ffffffff815443fe>] ? kernel_init+0xe/0xf0 [<ffffffff81553e5f>] ? ret_from_fork+0x3f/0x70 [<ffffffff815443f0>] ? 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- <TAbort- <MAbort+ >SERR- <PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c <?> 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 <christophe.fish@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / scan: constify struct acpi_hardware_id::idRasmus Villemoes2015-09-151-2/+2
| | | | | | | This is preparation for using kstrdup_const to initialize that member. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cleanup IORESOURCE_CACHEABLE vs ioremap()Dan Williams2015-08-111-2/+0
| | | | | | | | | | | | | | | | | | | | | 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_<type>() usages to memremap(..., flags). Suggested-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
* ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stageRafael J. Wysocki2015-07-061-26/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <roland@purestorage.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
*-. Merge branches 'pnp' and 'pm-tools'Rafael J. Wysocki2015-06-191-5/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | PNP / ACPI: use unsigned int in pnpacpi_encode_resources()Fabian Frederick2015-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | use unsigned int for port, irq, dma and mem used for pnp_get_resource() This fixes gcc warnings of type "conversion to unsigned int from int may change the sign of the result" Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | PNP / ACPI: use u8 instead of int in acpi_resource_extended_irq contextFabian Frederick2015-05-051-4/+4
| |/ | | | | | | | | | | | | | | | | | | acpi_resource_extented_irq variables are all u8. Use that type for triggering, polarity and shareable. This fixes gcc warnings of type "conversion to u8 from int may alter its value" Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* / ACPI / PNP: Avoid conflicting resource reservationsRafael J. Wysocki2015-06-181-9/+26
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <roland@purestorage.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'pm+acpi-4.1-rc1' of ↵Linus Torvalds2015-04-155-39/+67
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm 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 ...
| * PNP: Avoid leaving unregistered device objects in listsRafael J. Wysocki2015-03-181-13/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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@intel.com>
| * PNP: Convert pnp_lock into a mutexRafael J. Wysocki2015-03-184-27/+29
| | | | | | | | | | | | | | 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@intel.com>
| * PNP / ACPI: Use ACPI_COMPANION_SET() during initializationRafael J. Wysocki2015-03-161-3/+2
| | | | | | | | | | | | | | | | | | | | pnpacpi_add_device() calls acpi_bind_one() on an already registered device, which is a mistake, but it can initialize the ACPI companion field of the struct device to be registered using ACPI_COMPANION_SET() instead, so make it do that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | PNP: Don't check for overlaps with unassigned PCI BARsBjorn Helgaas2015-03-121-3/+6
|/ | | | | | | | | | | | | | | | | | | 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 <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
*---. Merge branches 'pnp', 'pm-cpuidle' and 'pm-cpufreq'Rafael J. Wysocki2015-02-211-2/+4
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | | PNP: Switch from __check_region() to __request_region()Jakub Sitnicki2015-01-221-2/+4
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <jsitnicki@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | Merge tag 'tty-3.20-rc1' of ↵Linus Torvalds2015-02-151-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty 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 ...
| * | | PNP: Allow console to override ACPI device sleepPeter Hurley2015-02-021-1/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | | Merge tag 'char-misc-3.20-rc1' of ↵Linus Torvalds2015-02-151-1/+2
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc 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 ...
| * | pnpbios: bail out on strange errorsAlan Cox2015-01-251-1/+2
| |/ | | | | | | | | | | | | | | | | | | 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 <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | ACPI: Return translation offset when parsing ACPI address space resourcesJiang Liu2015-02-031-14/+15
| | | | | | | | | | | | | | | | | | | | | | Change function acpi_dev_resource_address_space() and acpi_dev_resource_ext_address_space() to return address space translation offset. It's based on a patch from Yinghai Lu <yinghai@kernel.org>. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPICA: Resources: Provide common part for struct acpi_resource_address ↵Lv Zheng2015-01-261-8/+8
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | structures. 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 <tglx@linutronix.de> Original-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* PNP: replace strnicmp with strncasecmpRasmus Villemoes2014-10-141-12/+12
| | | | | | | | | | | | | | | | | 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 <linux@rasmusvillemoes.dk> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ACPI / PNP: Use ACPI_COMPANION() instead of ACPI_HANDLE()Rafael J. Wysocki2014-07-231-28/+23
| | | | | | | | | | | | | | | | | | 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@intel.com>
* ACPI / PNP: do ACPI binding directlyZhang Rui2014-07-071-38/+3
| | | | | | | | | | | | | | | | | | | | 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 <christophe.prigent@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
*---. Merge branches 'pnp', 'powercap', 'pm-runtime' and 'pm-opp'Rafael J. Wysocki2014-06-031-2/+2
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | | PNP / resources: remove positive test on unsigned valuesFabian Frederick2014-05-101-2/+2
| | |/ | |/| | | | | | | | | | | | | | | | irq and dma are both resource_size_t (derived from phys_addr_t <-> unsigned) Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* / | ACPI / PNP: use device ID list for PNPACPI device enumerationZhang Rui2014-05-301-24/+4
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <rui.zhang@intel.com> [rjw: Rewrote the changelog, modified the PNP ACPI scan handler code] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | asmlinkage: Add explicit __visible to drivers/*, lib/*, kernel/*Andi Kleen2014-05-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | As requested by Linus add explicit __visible to the asmlinkage users. This marks functions visible to assembler. Tree sweep for rest of tree. Signed-off-by: Andi Kleen <ak@linux.intel.com> Link: http://lkml.kernel.org/r/1398984278-29319-4-git-send-email-andi@firstfloor.org Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
* | PNP / ACPI: Do not return errors if _DIS or _SRS are not presentRafael J. Wysocki2014-04-301-18/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <wxg4net@gmail.com> Reported-and-tested-by: <nonproffessional@gmail.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | PNP: Fix compile error in quirks.cBjorn Helgaas2014-04-291-2/+2
|/ | | | | | | | | | | | | | | | Fix the compile error: drivers/pnp/quirks.c:393:2: error: implicit declaration of function 'pcibios_bus_to_resource' that occurs when building with CONFIG_PCI unset. The quirk is only relevent to Intel devices, so we could use "#if defined(CONFIG_X86) && defined(CONFIG_PCI)" instead, but testing CONFIG_X86 is not strictly necessary. Fixes: cb171f7abb9a (PNP: Work around BIOS defects in Intel MCH area reporting) Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* PNP: Work around BIOS defects in Intel MCH area reportingBjorn Helgaas2014-04-241-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Work around BIOSes that don't report the entire Intel MCH area. MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a PNP0C02 resource. The MCH space was once 16KB, but is 32KB in newer parts. Some BIOSes still report a PNP0C02 resource that is only 16KB, which means the rest of the MCH space is consumed but unreported. This can cause resource map sanity check warnings or (theoretically) a device conflict if we assigned the unreported space to another device. The Intel perf event uncore driver tripped over this when it claimed the MCH region: resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01 Info: mapping multiple BARs. Your kernel is fine. To prevent this, if we find a PNP0C02 resource that covers part of the MCH space, extend it to cover the entire space. References: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic Reported-and-tested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Stephane Eranian <eranian@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 08:33:47 +0100