15 Jul, 2019

1 commit


31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 or at your option any
    later version this program is distributed in the hope that it will
    be useful but without any warranty without even the implied warranty
    of merchantability or fitness for a particular purpose see the gnu
    general public license for more details you should have received a
    copy of the gnu general public license along with this program if
    not write to the free software foundation inc 59 temple place suite
    330 boston ma 02111 1307 usa

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

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

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

    Thomas Gleixner
     

24 May, 2019

2 commits

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 or at your option any
    later version this program is distributed in the hope that it will
    be useful but without any warranty without even the implied warranty
    of merchantability or fitness for a particular purpose see the gnu
    general public license for more details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

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

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

    Thomas Gleixner
     
  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version this program is distributed in the
    hope that it will be useful but without any warranty without even
    the implied warranty of merchantability or fitness for a particular
    purpose see the gnu general public license for more details you
    should have received a copy of the gnu general public license along
    with this program if not write to the free software foundation inc
    675 mass ave cambridge ma 02139 usa

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

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

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

    Thomas Gleixner
     

21 May, 2019

1 commit


09 Apr, 2019

1 commit

  • %pF and %pf are functionally equivalent to %pS and %ps conversion
    specifiers. The former are deprecated, therefore switch the current users
    to use the preferred variant.

    The changes have been produced by the following command:

    git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' | \
    while read i; do perl -i -pe 's/%pf/%ps/g; s/%pF/%pS/g;' $i; done

    And verifying the result.

    Link: http://lkml.kernel.org/r/20190325193229.23390-1-sakari.ailus@linux.intel.com
    Cc: Andy Shevchenko
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: sparclinux@vger.kernel.org
    Cc: linux-um@lists.infradead.org
    Cc: xen-devel@lists.xenproject.org
    Cc: linux-acpi@vger.kernel.org
    Cc: linux-pm@vger.kernel.org
    Cc: drbd-dev@lists.linbit.com
    Cc: linux-block@vger.kernel.org
    Cc: linux-mmc@vger.kernel.org
    Cc: linux-nvdimm@lists.01.org
    Cc: linux-pci@vger.kernel.org
    Cc: linux-scsi@vger.kernel.org
    Cc: linux-btrfs@vger.kernel.org
    Cc: linux-f2fs-devel@lists.sourceforge.net
    Cc: linux-mm@kvack.org
    Cc: ceph-devel@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Signed-off-by: Sakari Ailus
    Acked-by: David Sterba (for btrfs)
    Acked-by: Mike Rapoport (for mm/memblock.c)
    Acked-by: Bjorn Helgaas (for drivers/pci)
    Acked-by: Rafael J. Wysocki
    Signed-off-by: Petr Mladek

    Sakari Ailus
     

25 Feb, 2019

1 commit


04 Jan, 2019

1 commit

  • Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
    of the user address range verification function since we got rid of the
    old racy i386-only code to walk page tables by hand.

    It existed because the original 80386 would not honor the write protect
    bit when in kernel mode, so you had to do COW by hand before doing any
    user access. But we haven't supported that in a long time, and these
    days the 'type' argument is a purely historical artifact.

    A discussion about extending 'user_access_begin()' to do the range
    checking resulted this patch, because there is no way we're going to
    move the old VERIFY_xyz interface to that model. And it's best done at
    the end of the merge window when I've done most of my merges, so let's
    just get this done once and for all.

    This patch was mostly done with a sed-script, with manual fix-ups for
    the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.

    There were a couple of notable cases:

    - csky still had the old "verify_area()" name as an alias.

    - the iter_iov code had magical hardcoded knowledge of the actual
    values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
    really used it)

    - microblaze used the type argument for a debug printout

    but other than those oddities this should be a total no-op patch.

    I tried to fix up all architectures, did fairly extensive grepping for
    access_ok() uses, and the changes are trivial, but I may have missed
    something. Any missed conversion should be trivially fixable, though.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

08 Jun, 2018

1 commit

  • Pull media updates from Mauro Carvalho Chehab:

    - remove of atomisp driver from staging, as nobody would have time to
    dedicate huge efforts to fix all the problems there. Also, we have a
    feeling that the driver may not even run the way it is.

    - move Zoran driver to staging, in order to be either fixed to use VB2
    and the proper media kAPIs or to be removed

    - remove videobuf-dvb driver, with is unused for a while

    - some V4L2 documentation fixes/improvements

    - new sensor drivers: imx258 and ov7251

    - a new driver was added to allow using I2C transparent drivers

    - several improvements at the ddbridge driver

    - several improvements at the ISDB pt1 driver, making it more coherent
    with the DVB framework

    - added a new platform driver for MIPI CSI-2 RX: cadence

    - now, all media drivers can be compiled on x86 with COMPILE_TEST

    - almost all media drivers now build on non-x86 architectures with
    COMPILE_TEST

    - lots of other random stuff: cleanups, support for new board models,
    bug fixes, etc

    * tag 'media/v4.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (464 commits)
    media: omap2: fix compile-testing with FB_OMAP2=m
    media: media/radio/Kconfig: add back RADIO_ISA
    media: v4l2-ioctl.c: fix missing unlock in __video_do_ioctl()
    media: pxa_camera: ignore -ENOIOCTLCMD from v4l2_subdev_call for s_power
    media: arch: sh: migor: Fix TW9910 PDN gpio
    media: staging: tegra-vde: Reset VDE regardless of memory client resetting failure
    media: marvel-ccic: mmp: select VIDEOBUF2_VMALLOC/DMA_CONTIG
    media: marvel-ccic: allow ccic and mmp drivers to coexist
    media: uvcvideo: Prevent setting unavailable flags
    media: ddbridge: conditionally enable fast TS for stv0910-equipped bridges
    media: dvb-frontends/stv0910: make TS speed configurable
    media: ddbridge/mci: add identifiers to function definition arguments
    media: ddbridge/mci: protect against out-of-bounds array access in stop()
    media: rc: ensure input/lirc device can be opened after register
    media: rc: nuvoton: Keep device enabled during reg init
    media: rc: nuvoton: Keep track of users on CIR enable/disable
    media: rc: nuvoton: Tweak the interrupt enabling dance
    media: uvcvideo: Support realtek's UVC 1.5 device
    media: uvcvideo: Fix driver reference counting
    media: gspca_zc3xx: Enable short exposure times for OV7648
    ...

    Linus Torvalds
     

16 May, 2018

1 commit


20 Apr, 2018

1 commit


16 Dec, 2017

1 commit

  • Fix ptr_ret.cocci warnings:
    drivers/pnp/pnpbios/core.c:584:1-3: WARNING: PTR_ERR_OR_ZERO can be used

    Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

    Generated by: scripts/coccinelle/api/ptr_ret.cocci

    Signed-off-by: Vasyl Gomonovych
    Reviewed-by: Jean Delvare
    Signed-off-by: Rafael J. Wysocki

    Vasyl Gomonovych
     

13 Dec, 2017

1 commit

  • The file was converted from print_fn_descriptor_symbol()
    to %pF some time ago (2e532d68a2b3e2aa {pci,pnp} quirks.c:
    don't use deprecated print_fn_descriptor_symbol()). kallsyms
    does not seem to be needed anymore.

    Signed-off-by: Sergey Senozhatsky
    Signed-off-by: Rafael J. Wysocki

    Sergey Senozhatsky
     

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

    Greg Kroah-Hartman
     

14 Sep, 2017

1 commit


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()
    ...

    Linus Torvalds
     

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

    Rafael J. Wysocki
     

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

    Andy Shevchenko
     
  • 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

    Andy Shevchenko
     
  • 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

    Jagadish Krishnamoorthy
     

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

    Thomas Garnier
     

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

    Greg Kroah-Hartman
     

25 Dec, 2016

1 commit


17 Aug, 2016

1 commit

  • The Makefile currently controlling compilation of this code is:

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

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

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

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

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

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

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

    Paul Gortmaker
     

28 Jul, 2016

1 commit

  • Fix build errors due to missing header file:

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

    Randy Dunlap
     

27 Jul, 2016

1 commit


15 Jul, 2016

1 commit

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

    As an added benefit, this way is simpler.

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

    Andy Lutomirski
     

06 Jul, 2016

1 commit

  • The Kconfig currently controlling compilation of this code is:

    config PNPBIOS
    bool "Plug and Play BIOS support"

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

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

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

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

    Paul Gortmaker
     

21 May, 2016

1 commit

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

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

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

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

    Linus Torvalds
     

02 May, 2016

1 commit

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

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

    William Breathitt Gray
     

22 Apr, 2016

1 commit

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

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

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

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

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

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

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

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

    Luis R. Rodriguez
     

10 Mar, 2016

1 commit

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

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

    Harb Abdulhamid
     

03 Feb, 2016

1 commit

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

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

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

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

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

    Josh Boyer
     

05 Jan, 2016

1 commit

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

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

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

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

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

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

    Heiner Kallweit
     

03 Jan, 2016

1 commit

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

    >From a Lenovo ThinkPad T550:

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

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

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

    Christophe Le Roy
     

15 Sep, 2015

1 commit


11 Aug, 2015

1 commit

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

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

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

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

    Dan Williams
     

07 Jul, 2015

1 commit

  • This effectively reverts the following three commits:

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

    (commit b9a5e5e18fbf introduced regressions some of which, but not
    all, were addressed by commit 0f1b414d1907 and commit 7bc10388ccdd
    was a fixup on top of the latter) and causes ACPI fixed hardware
    resources to be reserved at the fs_initcall_sync stage of system
    initialization.

    The story is as follows. First, a boot regression was reported due
    to an apparent resource reservation ordering change after a commit
    that shouldn't lead to such changes. Investigation led to the
    conclusion that the problem happened because acpi_reserve_resources()
    was executed at the device_initcall() stage of system initialization
    which wasn't strictly ordered with respect to driver initialization
    (and with respect to the initialization of the pcieport driver in
    particular), so a random change causing the device initcalls to be
    run in a different order might break things.

    The response to that was to attempt to run acpi_reserve_resources()
    as soon as we knew that ACPI would be in use (commit b9a5e5e18fbf).
    However, that turned out to be too early, because it caused resource
    reservations made by the PNP system driver to fail on at least one
    system and that failure was addressed by commit 0f1b414d1907.

    That fix still turned out to be insufficient, though, because
    calling acpi_reserve_resources() before the fs_initcall stage of
    system initialization caused a boot regression to happen on the
    eCAFE EC-800-H20G/S netbook. That meant that we only could call
    acpi_reserve_resources() at the fs_initcall initialization stage
    or later, but then we might just as well call it after the PNP
    initalization in which case commit 0f1b414d1907 wouldn't be
    necessary any more.

    For this reason, the changes made by commit 0f1b414d1907 are reverted
    (along with a memory leak fixup on top of that commit), the changes
    made by commit b9a5e5e18fbf that went too far are reverted too and
    acpi_reserve_resources() is changed into fs_initcall_sync, which
    will cause it to be executed after the PNP subsystem initialization
    (which is an fs_initcall) and before device initcalls (including
    the pcieport driver initialization) which should avoid the initial
    issue.

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

    Rafael J. Wysocki
     

19 Jun, 2015

2 commits

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

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

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

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

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

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

    Rafael J. Wysocki