1. 03 Nov, 2016 1 commit
  2. 27 Oct, 2016 1 commit
    • Jonathan Corbet's avatar
      docs: Clean up and organize the admin guide a bit · 7358bb2f
      Jonathan Corbet authored
      
      
      The admin guide is a good start, but it's time to turn it into something
      better than an unordered blob of files.  This is a first step in that
      direction.  The TOC has been split up and annotated, the guides have been
      reordered, and minor tweaks have been applied to a few of them.
      
      One consequence of splitting up the TOC is that we don't really want to use
      :numbered: anymore, since the count resets every time and there doesn't
      seem to be a way to change that.  Eventually we probably want to group the
      documents into sub-books, at which point we can go back to a single TOC,
      but it's probably early to do that.
      Reviewed-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      7358bb2f
  3. 24 Oct, 2016 3 commits
  4. 11 Oct, 2016 2 commits
    • Marcos Paulo de Souza's avatar
      Input: i8042 - skip selftest on ASUS laptops · 930e1924
      Marcos Paulo de Souza authored
      On suspend/resume cycle, selftest is executed to reset i8042 controller.
      But when this is done in Asus devices, subsequent calls to detect/init
      functions to elantech driver fails. Skipping selftest fixes this problem.
      
      An easier step to reproduce this problem is adding i8042.reset=1 as a
      kernel parameter. On Asus laptops, it'll make the system to start with the
      touchpad already stuck, since psmouse_probe forcibly calls the selftest
      function.
      
      This patch was inspired by John Hiesey's change[1], but, since this problem
      affects a lot of models of Asus, let's avoid running selftests on them.
      
      All models affected by this problem:
      A455LD
      K401LB
      K501LB
      K501LX
      R409L
      V502LX
      X302LA
      X450LCP
      X450LD
      X455LAB
      X455LDB
      X455LF
      Z450LA
      
      [1]: https://marc.info/?l=linux-input&m=144312209020616&w=2
      
      Fixes: "ETPS/2 Elantech Touchpad dies after resume from suspend"
      (https://bugzilla.kernel.org/show_bug.cgi?id=107971
      
      )
      Signed-off-by: default avatarMarcos Paulo de Souza <marcos.souza.org@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      930e1924
    • Noam Camus's avatar
      lib/bitmap.c: enhance bitmap syntax · 2d13e6ca
      Noam Camus authored
      Today there are platforms with many CPUs (up to 4K).  Trying to boot only
      part of the CPUs may result in too long string.
      
      For example lets take NPS platform that is part of arch/arc.  This
      platform have SMP system with 256 cores each with 16 HW threads (SMT
      machine) where HW thread appears as CPU to the kernel.  In this example
      there is total of 4K CPUs.  When one tries to boot only part of the HW
      threads from each core the string representing the map may be long...  For
      example if for sake of performance we decided to boot only first half of
      HW threads of each core the map will look like:
      0-7,16-23,32-39,...,4080-4087
      
      This patch introduce new syntax to accommodate with such use case.  I
      added an optional postfix to a range of CPUs which will choose according
      to given modulo the desired range of reminders i.e.:
      
          <cpus range>:sed_size/group_size
      
      For example, above map can be described in new syntax like this:
      0-4095:8/16
      
      Note that this patch is backward compatible with current syntax.
      
      [akpm@linux-foundation.org: rework documentation]
      Link: http://lkml.kernel.org/r/1473579629-4283-1-git-send-email-noamca@mellanox.com
      
      Signed-off-by: default avatarNoam Camus <noamca@mellanox.com>
      Cc: David Decotigny <decot@googlers.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Pan Xinhui <xinhui@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2d13e6ca
  5. 27 Sep, 2016 1 commit
  6. 26 Sep, 2016 1 commit
  7. 23 Sep, 2016 1 commit
    • Scott Wood's avatar
      arm64: arch_timer: Work around QorIQ Erratum A-008585 · f6dc1576
      Scott Wood authored
      
      
      Erratum A-008585 says that the ARM generic timer counter "has the
      potential to contain an erroneous value for a small number of core
      clock cycles every time the timer value changes".  Accesses to TVAL
      (both read and write) are also affected due to the implicit counter
      read.  Accesses to CVAL are not affected.
      
      The workaround is to reread TVAL and count registers until successive
      reads return the same value.  Writes to TVAL are replaced with an
      equivalent write to CVAL.
      
      The workaround is to reread TVAL and count registers until successive reads
      return the same value, and when writing TVAL to retry until counter
      reads before and after the write return the same value.
      
      The workaround is enabled if the fsl,erratum-a008585 property is found in
      the timer node in the device tree.  This can be overridden with the
      clocksource.arm_arch_timer.fsl-a008585 boot parameter, which allows KVM
      users to enable the workaround until a mechanism is implemented to
      automatically communicate this information.
      
      This erratum can be found on LS1043A and LS2080A.
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarScott Wood <oss@buserror.net>
      [will: renamed read macro to reflect that it's not usually unstable]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      f6dc1576
  8. 19 Sep, 2016 1 commit
  9. 13 Sep, 2016 1 commit
  10. 09 Sep, 2016 1 commit
    • Dave Hansen's avatar
      x86/pkeys: Default to a restrictive init PKRU · acd547b2
      Dave Hansen authored
      
      
      PKRU is the register that lets you disallow writes or all access to a given
      protection key.
      
      The XSAVE hardware defines an "init state" of 0 for PKRU: its most
      permissive state, allowing access/writes to everything.  Since we start off
      all new processes with the init state, we start all processes off with the
      most permissive possible PKRU.
      
      This is unfortunate.  If a thread is clone()'d [1] before a program has
      time to set PKRU to a restrictive value, that thread will be able to write
      to all data, no matter what pkey is set on it.  This weakens any integrity
      guarantees that we want pkeys to provide.
      
      To fix this, we define a very restrictive PKRU to override the
      XSAVE-provided value when we create a new FPU context.  We choose a value
      that only allows access to pkey 0, which is as restrictive as we can
      practically make it.
      
      This does not cause any practical problems with applications using
      protection keys because we require them to specify initial permissions for
      each key when it is allocated, which override the restrictive default.
      
      In the end, this ensures that threads which do not know how to manage their
      own pkey rights can not do damage to data which is pkey-protected.
      
      I would have thought this was a pretty contrived scenario, except that I
      heard a bug report from an MPX user who was creating threads in some very
      early code before main().  It may be crazy, but folks evidently _do_ it.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: linux-arch@vger.kernel.org
      Cc: Dave Hansen <dave@sr71.net>
      Cc: mgorman@techsingularity.net
      Cc: arnd@arndb.de
      Cc: linux-api@vger.kernel.org
      Cc: linux-mm@kvack.org
      Cc: luto@kernel.org
      Cc: akpm@linux-foundation.org
      Cc: torvalds@linux-foundation.org
      Link: http://lkml.kernel.org/r/20160729163021.F3C25D4A@viggo.jf.intel.com
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      acd547b2
  11. 06 Sep, 2016 1 commit
  12. 05 Sep, 2016 1 commit
  13. 31 Aug, 2016 1 commit
  14. 25 Aug, 2016 1 commit
  15. 18 Aug, 2016 1 commit
    • baolex.ni's avatar
      Update the maximum depth of C-state from 6 to 9 · 22c6bbe4
      baolex.ni authored
      
      
      Hi Jon,
      
      This patch is an old one, we have corrected some minor issues on the newer one.
      Please only review the newest version from my last mail with this subject
      "[PATCH] ACPI: Update the maximum depth of C-state from 6 to 9".
      And I also attached it to this mail.
      
      Thanks,
      Baole
      
      On 7/11/2016 6:37 AM, Jonathan Corbet wrote:
      > On Mon, 4 Jul 2016 09:55:10 +0800
      > "baolex.ni" <baolex.ni@intel.com> wrote:
      >
      >> Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
      >> and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of C-state.
      >> This change is reflected in one place of the kernel-param file,
      >> but not in the other place where I suggest changing.
      >>
      >> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
      >> Signed-off-by: Baole Ni <baolex.ni@intel.com>
      >
      > So why are there two signoffs on a single-line patch?  Which one of you
      > is the actual author?
      >
      > Thanks,
      >
      > jon
      >
      
      From cf5f8aa6885874f6490b11507d3c0c86fa0a11f4 Mon Sep 17 00:00:00 2001
      From: Chuansheng Liu <chuansheng.liu@intel.com>
      Date: Mon, 4 Jul 2016 08:52:51 +0800
      Subject: [PATCH] Update the maximum depth of C-state from 6 to 9
      MIME-Version: 1.0
      Content-Type: text/plain; charset=UTF-8
      Content-Transfer-Encoding: 8bit
      
      Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
      and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of C-state.
      This change is reflected in one place of the kernel-param file,
      but not in the other place where I suggest changing.
      Signed-off-by: default avatarChuansheng Liu <chuansheng.liu@intel.com>
      Signed-off-by: default avatarBaole Ni <baolex.ni@intel.com>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      22c6bbe4
  16. 09 Aug, 2016 1 commit
    • Mathias Koehrer's avatar
      PCI: Update "pci=resource_alignment" documentation · 8b078c60
      Mathias Koehrer authored
      
      
      Some uio based PCI drivers, e.g., uio_cif, do not work if the assigned PCI
      memory resources are not page aligned.  By using the kernel option
      "pci=resource_alignment=<align>@<bus>:<slot>.<func>" it is possible to
      request page alignment for memory resources of devices.
      
      However, this is cumbersome when using several devices, and the
      bus/slot/func addresses may change if devices are added to or removed from
      the system.
      
      Extend the "pci=resource_alignment" option so we can specify the relevant
      devices via PCI vendor, device, subvendor, and subdevice IDs.  The
      specification of the devices via IDs is indicated by a leading string
      "pci:" as argument to "pci=resource_alignment".
      
      The format of the specification is
        pci:<vendor>:<device>[:<subvendor>:<subdevice>]
      
      Examples:
        pci=resource_alignment=4096@pci:8086:9c22:103c:198f
        pci=resource_alignment=pci:8086:9c22       # defaults to PAGE_SIZE align
      
      [bhelgaas: changelog, use actual vendor/device IDs in examples]
      Signed-off-by: default avatarMathias Koehrer <mathias.koehrer@etas.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      8b078c60
  17. 04 Aug, 2016 1 commit
    • Prarit Bhargava's avatar
      modules: Add kernel parameter to blacklist modules · be7de5f9
      Prarit Bhargava authored
      
      
      Blacklisting a module in linux has long been a problem.  The current
      procedure is to use rd.blacklist=module_name, however, that doesn't
      cover the case after the initramfs and before a boot prompt (where one
      is supposed to use /etc/modprobe.d/blacklist.conf to blacklist
      runtime loading). Using rd.shell to get an early prompt is hit-or-miss,
      and doesn't cover all situations AFAICT.
      
      This patch adds this functionality of permanently blacklisting a module
      by its name via the kernel parameter module_blacklist=module_name.
      
      [v2]: Rusty, use core_param() instead of __setup() which simplifies
      things.
      
      [v3]: Rusty, undo wreckage from strsep()
      
      [v4]: Rusty, simpler version of blacklisted()
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: linux-doc@vger.kernel.org
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      be7de5f9
  18. 03 Aug, 2016 1 commit
  19. 02 Aug, 2016 1 commit
    • Borislav Petkov's avatar
      printk: add kernel parameter to control writes to /dev/kmsg · 750afe7b
      Borislav Petkov authored
      Add a "printk.devkmsg" kernel command line parameter which controls how
      userspace writes into /dev/kmsg.  It has three options:
      
       * ratelimit - ratelimit logging from userspace.
       * on  - unlimited logging from userspace
       * off - logging from userspace gets ignored
      
      The default setting is to ratelimit the messages written to it.
      
      This changes the kernel default setting of "on" to "ratelimit" and we do
      that because we want to keep userspace spamming /dev/kmsg to sane
      levels.  This is especially moot when a small kernel log buffer wraps
      around and messages get lost.  So the ratelimiting setting should be a
      sane setting where kernel messages should have a bit higher chance of
      survival from all the spamming.
      
      It additionally does not limit logging to /dev/kmsg while the system is
      booting if we haven't disabled it on the command line.
      
      Furthermore, we can control the logging from a lower priority sysctl
      interface - kernel.printk_devkmsg.
      
      That interface will succeed only if printk.devkmsg *hasn't* been
      supplied on the command line.  If it has, then printk.devkmsg is a
      one-time setting which remains for the duration of the system lifetime.
      This "locking" of the setting is to prevent userspace from changing the
      logging on us through sysctl(2).
      
      This patch is based on previous patches from Linus and Steven.
      
      [bp@suse.de: fixes]
        Link: http://lkml.kernel.org/r/20160719072344.GC25563@nazgul.tnic
      Link: http://lkml.kernel.org/r/20160716061745.15795-3-bp@alien8.de
      
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Franck Bui <fbui@suse.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      750afe7b
  20. 25 Jul, 2016 1 commit
  21. 17 Jul, 2016 1 commit
  22. 13 Jul, 2016 1 commit
  23. 10 Jul, 2016 1 commit
    • Rafael J. Wysocki's avatar
      PM / hibernate: Image data protection during restoration · 4c0b6c10
      Rafael J. Wysocki authored
      
      
      Make it possible to protect all pages holding image data during
      hibernate image restoration by setting them read-only (so as to
      catch attempts to write to those pages after image data have been
      stored in them).
      
      This adds overhead to image restoration code (it may cause large
      page mappings to be split as a result of page flags changes) and
      the errors it protects against should never happen in theory, so
      the feature is only active after passing hibernate=protect_image
      to the command line of the restore kernel.
      
      Also it only is built if CONFIG_DEBUG_RODATA is set.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4c0b6c10
  24. 08 Jul, 2016 1 commit
  25. 05 Jul, 2016 1 commit
  26. 29 Jun, 2016 1 commit
    • Huang Ying's avatar
      ACPI / APEI: Add Boot Error Record Table (BERT) support · a3e2acc5
      Huang Ying authored
      ACPI/APEI is designed to verifiy/report H/W errors, like Corrected
      Error(CE) and Uncorrected Error(UC). It contains four tables: HEST,
      ERST, EINJ and BERT. The first three tables have been merged for
      a long time, but because of lacking BIOS support for BERT, the
      support for BERT is pending until now. Recently on ARM 64 platform
      it is has been supported. So here we come.
      
      Under normal circumstances, when a hardware error occurs, kernel will
      be notified via NMI, MCE or some other method, then kernel will
      process the error condition, report it, and recover it if possible.
      But sometime, the situation is so bad, so that firmware may choose to
      reset directly without notifying Linux kernel.
      
      Linux kernel can use the Boot Error Record Table (BERT) to get the
      un-notified hardware errors that occurred in a previous boot. In this
      patch, the error information is reported via printk.
      
      For more information about BERT, please refer to ACPI Specification
      version 6.0, section 18.3.1:
        http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
      
      
      
      The following log is a BERT record after system reboot because of hitting
      a fatal memory error:
      BERT: Error records from previous boot:
      [Hardware Error]: It has been corrected by h/w and requires no further action
      [Hardware Error]: event severity: corrected
      [Hardware Error]:  Error 0, type: recoverable
      [Hardware Error]:   section_type: memory error
      [Hardware Error]:   error_status: 0x0000000000000400
      [Hardware Error]:   physical_address: 0xffffffffffffffff
      [Hardware Error]:   card: 1 module: 2 bank: 3 row: 1 column: 2 bit_position: 5
      [Hardware Error]:   error_type: 2, single-bit ECC
      
      [Tomasz Nowicki: Clear error status at the end of error handling]
      [Tony: Applied some cleanups suggested by Fu Wei]
      [Fu Wei: delete EXPORT_SYMBOL_GPL(bert_disable), improve the code]
      Signed-off-by: default avatarHuang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarTomasz Nowicki <tomasz.nowicki@linaro.org>
      Signed-off-by: default avatarChen, Gong <gong.chen@linux.intel.com>
      Tested-by: default avatarJonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
      Signed-off-by: default avatarFu Wei <fu.wei@linaro.org>
      Tested-by: default avatarTyler Baicar <tbaicar@codeaurora.org>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a3e2acc5
  27. 28 Jun, 2016 2 commits
  28. 26 Jun, 2016 1 commit
    • Kees Cook's avatar
      x86/KASLR, x86/power: Remove x86 hibernation restrictions · 65fe935d
      Kees Cook authored
      
      
      With the following fix:
      
        70595b479ce1 ("x86/power/64: Fix crash whan the hibernation code passes control to the image kernel")
      
      ... there is no longer a problem with hibernation resuming a
      KASLR-booted kernel image, so remove the restriction.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      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: Jonathan Corbet <corbet@lwn.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Linux PM list <linux-pm@vger.kernel.org>
      Cc: Logan Gunthorpe <logang@deltatee.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-doc@vger.kernel.org
      Link: http://lkml.kernel.org/r/20160613221002.GA29719@www.outflux.net
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      65fe935d
  29. 21 Jun, 2016 1 commit
    • Koehrer Mathias (ETAS/ESW5)'s avatar
      PCI: Extending pci=resource_alignment to specify device/vendor IDs · 644a544f
      Koehrer Mathias (ETAS/ESW5) authored
      
      
      Some uio-based PCI drivers, e.g., uio_cif do not work if the assigned PCI
      memory resources are not page aligned.
      
      By using the kernel option "pci=resource_alignment" it is possible to force
      single PCI boards to use page alignment for their memory resources.
      However, this is fairly cumbersome if several of these boards are in use
      as the specification of the cards has to be done via PCI bus/slot/function
      number which might change, e.g., by adding another board.
      
      Extend the kernel option "pci=resource_alignment" to allow specification of
      relevant devices via PCI device/vendor (and subdevice/subvendor) IDs.  The
      specification of the devices via device/vendor is indicated by a leading
      string "pci:" as argument to "pci=resource_alignment".  The format of the
      specification is pci:<vendor>:<device>[:<subvendor>:<subdevice>]
      Signed-off-by: default avatarMathias Koehrer <mathias.koehrer@etas.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      644a544f
  30. 13 Jun, 2016 1 commit
    • Mika Westerberg's avatar
      PCI: Put PCIe ports into D3 during suspend · 9d26d3a8
      Mika Westerberg authored
      
      
      Currently the Linux PCI core does not touch power state of PCI bridges and
      PCIe ports when system suspend is entered.  Leaving them in D0 consumes
      power unnecessarily and may prevent the CPU from entering deeper C-states.
      
      With recent PCIe hardware we can power down the ports to save power given
      that we take into account few restrictions:
      
        - The PCIe port hardware is recent enough, starting from 2015.
      
        - Devices connected to PCIe ports are effectively in D3cold once the port
          is transitioned to D3 (the config space is not accessible anymore and
          the link may be powered down).
      
        - Devices behind the PCIe port need to be allowed to transition to D3cold
          and back.  There is a way both drivers and userspace can forbid this.
      
        - If the device behind the PCIe port is capable of waking the system it
          needs to be able to do so from D3cold.
      
      This patch adds a new flag to struct pci_device called 'bridge_d3'.  This
      flag is set and cleared by the PCI core whenever there is a change in power
      management state of any of the devices behind the PCIe port.  When system
      later on is suspended we only need to check this flag and if it is true
      transition the port to D3 otherwise we leave it in D0.
      
      Also provide override mechanism via command line parameter
      "pcie_port_pm=[off|force]" that can be used to disable or enable the
      feature regardless of the BIOS manufacturing date.
      Tested-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9d26d3a8
  31. 03 Jun, 2016 1 commit
  32. 20 May, 2016 1 commit
  33. 05 May, 2016 1 commit
  34. 04 May, 2016 1 commit
  35. 30 Apr, 2016 1 commit
  36. 27 Apr, 2016 1 commit