02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
14 Sep, 2017
1 commit
-
... and __initconst if applicable.
Based on similar work for an older kernel in the Grsecurity patch.
[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]Signed-off-by: Christoph Hellwig
Signed-off-by: Jean Delvare
08 Jul, 2017
1 commit
-
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()
...
28 Jun, 2017
1 commit
-
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
Reviewed-by: Mika Westerberg
Acked-by: Bjorn Helgaas
29 May, 2017
3 commits
-
There is no point in keeping an address in the file since it's subject
to change.Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Signed-off-by: Linus Walleij -
Simply join string literals back for better maintenance and debugging.
No functional changes intended.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Signed-off-by: Linus Walleij -
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
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
[Fixed a parenthesis coding style thing]
Signed-off-by: Linus Walleij
16 Mar, 2017
1 commit
-
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 for testing and
recommending changes for Xen support.Signed-off-by: Thomas Garnier
Cc: Alexander Potapenko
Cc: Andrew Morton
Cc: Andrey Ryabinin
Cc: Andy Lutomirski
Cc: Ard Biesheuvel
Cc: Boris Ostrovsky
Cc: Borislav Petkov
Cc: Chris Wilson
Cc: Christian Borntraeger
Cc: Dmitry Vyukov
Cc: Frederic Weisbecker
Cc: Jiri Kosina
Cc: Joerg Roedel
Cc: Jonathan Corbet
Cc: Josh Poimboeuf
Cc: Juergen Gross
Cc: Kees Cook
Cc: Len Brown
Cc: Linus Torvalds
Cc: Lorenzo Stoakes
Cc: Luis R . Rodriguez
Cc: Matt Fleming
Cc: Michal Hocko
Cc: Paolo Bonzini
Cc: Paul Gortmaker
Cc: Pavel Machek
Cc: Peter Zijlstra
Cc: Radim Krčmář
Cc: Rafael J . Wysocki
Cc: Rusty Russell
Cc: Stanislaw Gruszka
Cc: Thomas Gleixner
Cc: Tim Chen
Cc: Vitaly Kuznetsov
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
Link: http://lkml.kernel.org/r/20170314170508.100882-2-thgarnie@google.com
Signed-off-by: Ingo Molnar
19 Jan, 2017
1 commit
-
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
Cc: Thomas Sailer
Cc: "Rafael J. Wysocki"
Cc: Johan Hovold
Cc: Alex Elder
Cc: "J. Bruce Fields"
Cc: Jeff Layton
Cc: David Howells
Signed-off-by: Greg Kroah-Hartman
25 Dec, 2016
1 commit
-
This was entirely automated, using the script by Al:
PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*'
sed -i -e "s!$PATT!#include !" \
$(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
Signed-off-by: Linus Torvalds
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
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
27 Jul, 2016
1 commit
-
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
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
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
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()
...
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
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 +28That'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
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
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_uncoreLink: https://bugzilla.redhat.com/show_bug.cgi?id=1300955
Tested-by:
Signed-off-by: Josh Boyer
Signed-off-by: Rafael J. Wysocki
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 driverI 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 deviceThe 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
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 00Signed-off-by: Christophe Le Roy
Signed-off-by: Rafael J. Wysocki
15 Sep, 2015
1 commit
-
This is preparation for using kstrdup_const to initialize that member.
Signed-off-by: Rasmus Villemoes
Signed-off-by: Rafael J. Wysocki
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
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
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 -
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
06 May, 2015
2 commits
-
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
Signed-off-by: Rafael J. Wysocki -
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
Signed-off-by: Rafael J. Wysocki
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
...
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
-
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
16 Mar, 2015
1 commit
-
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
Reviewed-by: Mika Westerberg
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
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
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
... -
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
...
04 Feb, 2015
1 commit
-
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 .
Signed-off-by: Jiang Liu
Signed-off-by: Rafael J. Wysocki
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
26 Jan, 2015
1 commit
-
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.cBuild 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
