1. 28 Mar, 2017 12 commits
  2. 24 Mar, 2017 5 commits
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Avoid transient updates of cpuinfo.max_freq · 80b120ca
      Rafael J. Wysocki authored
      Both intel_pstate_verify_policy() and intel_cpufreq_verify_policy()
      set policy->cpuinfo.max_freq depending on the turbo status, but the
      updates made by them are discarded by the core, because the policy
      object passed to them by the core is temporary and cpuinfo.max_freq
      from that object is not copied to the final policy object in
      cpufreq_set_policy().
      
      However, cpufreq_set_policy() passes the temporary policy object
      to the ->setpolicy callback of the driver, so intel_pstate_set_policy()
      actually sees the policy->cpuinfo.max_freq value updated by
      intel_pstate_verify_policy() and not the final one.  It also
      updates policy->max sometimes which basically has no effect after
      it returns, because the core discards that update.
      
      To avoid confusion, eliminate policy->cpuinfo.max_freq updates from
      intel_pstate_verify_policy() and intel_cpufreq_verify_policy()
      entirely and check the maximum frequency explicitly in
      intel_pstate_update_perf_limits() instead of relying on the
      transiently updated policy->cpuinfo.max_freq value.
      
      Moreover, move the max->policy adjustment carried out in
      intel_pstate_set_policy() to a separate function and call that
      function from the ->verify driver callbacks to ensure that it will
      actually be effective.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      80b120ca
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Active mode P-state limits rework · c5a2ee7d
      Rafael J. Wysocki authored
      The coordination of P-state limits used by intel_pstate in the active
      mode (ie. by default) is problematic, because it synchronizes all of
      the limits (ie. the global ones and the per-policy ones) so as to use
      one common pair of P-state limits (min and max) across all CPUs in
      the system.  The drawbacks of that are as follows:
      
       - If P-states are coordinated in hardware, it is not necessary
         to coordinate them in software on top of that, so in that case
         all of the above activity is in vain.
      
       - If P-states are not coordinated in hardware, then the processor
         is actually capable of setting different P-states for different
         CPUs and coordinating them at the software level simply doesn't
         allow that capability to be utilized.
      
       - The coordination works in such a way that setting a per-policy
         limit (eg. scaling_max_freq) for one CPU causes the common
         effective limit to change (and it will affect all of the other
         CPUs too), but subsequent reads from the corresponding sysfs
         attributes for the other CPUs will return stale values (which
         is confusing).
      
       - Reads from the global P-state limit attributes, min_perf_pct and
         max_perf_pct, return the effective common values and not the last
         values set through these attributes.  However, the last values
         set through these attributes become hard limits that cannot be
         exceeded by writes to scaling_min_freq and scaling_max_freq,
         respectively, and they are not exposed, so essentially users
         have to remember what they are.
      
      All of that is painful enough to warrant a change of the management
      of P-state limits in the active mode.
      
      To that end, redesign the active mode P-state limits management in
      intel_pstate in accordance with the following rules:
      
       (1) All CPUs are affected by the global limits (that is, none of
           them can be requested to run faster than the global max and
           none of them can be requested to run slower than the global
           min).
      
       (2) Each individual CPU is affected by its own per-policy limits
           (that is, it cannot be requested to run faster than its own
           per-policy max and it cannot be requested to run slower than
           its own per-policy min).
      
       (3) The global and per-policy limits can be set independently.
      
      Also, the global maximum and minimum P-state limits will be always
      expressed as percentages of the maximum supported turbo P-state.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c5a2ee7d
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Use load-based P-state selection more widely · 55395345
      Rafael J. Wysocki authored
      Extend the set of systems for which intel_pstate will use the
      "powersave" P-state selection algorithm based on CPU load in the
      active mode by systems with ACPI preferred profile set to "tablet",
      "appliance PC", "desktop", or "workstation" (ie. everything with a
      specified preferred profile that is not a "server").
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      55395345
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Support HWP processors in all operation modes · eb5139d1
      Rafael J. Wysocki authored
      Currently, some processors supporting HWP are only supported by
      intel_pstate if HWP is actually going to be used and not supported
      otherwise which is confusing.
      
      Specifically, they are not supported if "intel_pstate=no_hwp" is
      passed to the kernel in the command line or if the driver is started
      in the passive mode ("intel_pstate=passive").
      
      There is no real reason for that, because everything about those
      processor is known anyway and the driver can work with them in all
      modes, so make that happen, but use the load-based P-state selection
      algorithm for the active mode "powersave" policy with them.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eb5139d1
    • Rafael J. Wysocki's avatar
      f1a91645
  3. 21 Mar, 2017 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Fix policy data management in passive mode · 64897b20
      Rafael J. Wysocki authored
      The policy->cpuinfo.max_freq and policy->max updates in
      intel_cpufreq_turbo_update() are excessive as they are done for no
      good reason and may lead to problems in principle, so they should be
      dropped.  However, after dropping them intel_cpufreq_turbo_update()
      becomes almost entirely pointless, because the check made by it is
      made again down the road in intel_pstate_prepare_request().  The
      only thing in it that still needs to be done is the call to
      update_turbo_state(), so drop intel_cpufreq_turbo_update() altogether
      and make its callers invoke update_turbo_state() directly instead of
      it.
      
      In addition to that, fix intel_cpufreq_verify_policy() so that it
      checks global.no_turbo in addition to global.turbo_disabled when
      updating policy->cpuinfo.max_freq to make it consistent with
      intel_pstate_verify_policy().
      
      Fixes: 001c76f0 (cpufreq: intel_pstate: Generic governors support)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      64897b20
  4. 17 Mar, 2017 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: One set of global limits in active mode · 7de32556
      Rafael J. Wysocki authored
      In the active mode intel_pstate currently uses two sets of global
      limits, each associated with one of the possible scaling_governor
      settings in that mode: "powersave" or "performance".
      
      The driver switches over from one of those sets to the other
      depending on the scaling_governor setting for the last CPU whose
      per-policy cpufreq interface in sysfs was last used to change
      parameters exposed in there.  That obviously leads to no end of
      issues when the scaling_governor settings differ between CPUs.
      
      The most recent issue was introduced by commit a240c4aa (cpufreq:
      intel_pstate: Do not reinit performance limits in ->setpolicy)
      that eliminated the reinitialization of "performance" limits in
      intel_pstate_set_policy() preventing the max limit from being set
      to anything below 100, among other things.
      
      Namely, an undesirable side effect of commit a240c4aa is that
      now, after setting scaling_governor to "performance" in the active
      mode, the per-policy limits for the CPU in question go to the highest
      level and stay there even when it is switched back to "powersave"
      later.
      
      As it turns out, some distributions set scaling_governor to
      "performance" temporarily for all CPUs to speed-up system
      initialization, so that change causes them to misbehave later.
      
      To fix that, get rid of the performance/powersave global limits
      split and use just one set of global limits for everything.
      
      From the user's persepctive, after this modification, when
      scaling_governor is switched from "performance" to "powersave"
      or the other way around on one CPU, the limits settings (ie. the
      global max/min_perf_pct and per-policy scaling_max/min_freq for
      any CPUs) will not change.  Still, switching from "performance"
      to "powersave" or the other way around changes the way in which
      P-states are selected and in particular "performance" causes the
      driver to always request the highest P-state it is allowed to ask
      for for the given CPU.
      
      Fixes: a240c4aa (cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7de32556
  5. 15 Mar, 2017 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Avoid percentages in limits-related computations · e4c204ce
      Rafael J. Wysocki authored
      Currently, intel_pstate_update_perf_limits() first converts the
      policy minimum and maximum limits into percentages of the maximum
      turbo frequency (rounding up to an integer) and then converts these
      percentages to fractions (by using fixed-point arithmetic to divide
      them by 100).
      
      That introduces a rounding error unnecessarily, because the fractions
      can be obtained by carrying out fixed-point divisions directly on the
      input numbers.
      
      Rework the computations in intel_pstate_hwp_set() to use fractions
      instead of percentages (and drop redundant local variables from
      there) and modify intel_pstate_update_perf_limits() to compute the
      fractions directly and percentages out of them.
      
      While at it, introduce percent_ext_fp() for converting percentages
      to fractions (with extended number of fraction bits) and use it in
      the computations.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e4c204ce
  6. 14 Mar, 2017 1 commit
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Correct frequency setting in the HWP mode · 3f8ed54a
      Srinivas Pandruvada authored
      In the functions intel_pstate_hwp_set(), min/max range from HWP capability
      MSR along with max_perf_pct and min_perf_pct, is used to set the HWP
      request MSR. In some cases this doesn't result in the correct HWP max/min
      in HWP request.
      
      For example: In the following case:
      
      HWP capabilities from MSR 0x771
      0x70a1220
      
      Here cpufreq min/max frequencies from above MSR dump are 700MHz and 3.2GHz
      respectively.
      
      This will result in
      hwp_min = 0x07
      hwp_max = 0x20
      
      To limit max frequency to 2GHz:
      
      perf_limits->max_perf_pct = 63 (2GHz as a percent of 3.2GHz rounded up)
      
      With the current calculation:
      adj_range = max_perf_pct * range / 100;
      adj_range = 63 * (32 - 7) / 100
      adj_range = 15
      
      max = hw_min + adj_range;
      max = 7 + 15 = 22
      
      This will result in HWP request of 0x160f, which will result in a
      frequency cap of 2.2GHz not 2GHz.
      
      The problem with the above calculation is that hwp_min of 7 is treated
      as 0% in the range. But max_perf_pct is calculated with respect to minimum
      as 0 and max as 3.2GHz or hwp_max, so adding hwp_min to it will result in
      more than the desired.
      
      Since the min_perf_pct and max_perf_pct is already a percent of max
      frequency or hwp_max, this min/max HWP request value can be calculated
      directly applying these percentage to hwp_max.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3f8ed54a
  7. 13 Mar, 2017 1 commit
  8. 12 Mar, 2017 6 commits
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Drop redundant wrapper function · 5f98ced1
      Rafael J. Wysocki authored
      intel_pstate_hwp_set_policy() is a wrapper around
      intel_pstate_hwp_set(), but the only value it adds is to check
      hwp_active before calling the latter and one of its two callers
      has already checked hwp_active before that happens, so in that
      code path the additional check is redundant and using the wrapper
      is rather pointless.
      
      For this reason, drop intel_pstate_hwp_set_policy() and make its
      callers invoke intel_pstate_hwp_set() directly (after checking
      hwp_active).
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      5f98ced1
    • Linus Torvalds's avatar
      Linux 4.11-rc2 · 4495c08e
      Linus Torvalds authored
      4495c08e
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 56b24d1b
      Linus Torvalds authored
      Pull s390 fixes from Martin Schwidefsky:
      
       - four patches to get the new cputime code in shape for s390
      
       - add the new statx system call
      
       - a few bug fixes
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390: wire up statx system call
        KVM: s390: Fix guest migration for huge guests resulting in panic
        s390/ipl: always use load normal for CCW-type re-IPL
        s390/timex: micro optimization for tod_to_ns
        s390/cputime: provide archicture specific cputime_to_nsecs
        s390/cputime: reset all accounting fields on fork
        s390/cputime: remove last traces of cputime_t
        s390: fix in-kernel program checks
        s390/crypt: fix missing unlock in ctr_paes_crypt on error path
      56b24d1b
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 5a45a5a8
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
      
       - a fix for the kexec/purgatory regression which was introduced in the
         merge window via an innocent sparse fix. We could have reverted that
         commit, but on deeper inspection it turned out that the whole
         machinery is neither documented nor robust. So a proper cleanup was
         done instead
      
       - the fix for the TLB flush issue which was discovered recently
      
       - a simple typo fix for a reboot quirk
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/tlb: Fix tlb flushing when lguest clears PGE
        kexec, x86/purgatory: Unbreak it and clean it up
        x86/reboot/quirks: Fix typo in ASUS EeeBook X205TA reboot quirk
      5a45a5a8
    • Linus Torvalds's avatar
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · ecade114
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
      
       - a workaround for a GIC erratum
      
       - a missing stub function for CONFIG_IRQDOMAIN=n
      
       - fixes for a couple of type inconsistencies
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip/crossbar: Fix incorrect type of register size
        irqchip/gicv3-its: Add workaround for QDF2400 ITS erratum 0065
        irqdomain: Add empty irq_domain_check_msi_remap
        irqchip/crossbar: Fix incorrect type of local variables
      ecade114
    • Daniel Borkmann's avatar
      x86/tlb: Fix tlb flushing when lguest clears PGE · 2c4ea6e2
      Daniel Borkmann authored
      Fengguang reported random corruptions from various locations on x86-32
      after commits d2852a22 ("arch: add ARCH_HAS_SET_MEMORY config") and
      9d876e79 ("bpf: fix unlocking of jited image when module ronx not set")
      that uses the former. While x86-32 doesn't have a JIT like x86_64, the
      bpf_prog_lock_ro() and bpf_prog_unlock_ro() got enabled due to
      ARCH_HAS_SET_MEMORY, whereas Fengguang's test kernel doesn't have module
      support built in and therefore never had the DEBUG_SET_MODULE_RONX setting
      enabled.
      
      After investigating the crashes further, it turned out that using
      set_memory_ro() and set_memory_rw() didn't have the desired effect, for
      example, setting the pages as read-only on x86-32 would still let
      probe_kernel_write() succeed without error. This behavior would manifest
      itself in situations where the vmalloc'ed buffer was accessed prior to
      set_memory_*() such as in case of bpf_prog_alloc(). In cases where it
      wasn't, the page attribute changes seemed to have taken effect, leading to
      the conclusion that a TLB invalidate didn't happen. Moreover, it turned out
      that this issue reproduced with qemu in "-cpu kvm64" mode, but not for
      "-cpu host". When the issue occurs, change_page_attr_set_clr() did trigger
      a TLB flush as expected via __flush_tlb_all() through cpa_flush_range(),
      though.
      
      There are 3 variants for issuing a TLB flush: invpcid_flush_all() (depends
      on CPU feature bits X86_FEATURE_INVPCID, X86_FEATURE_PGE), cr4 based flush
      (depends on X86_FEATURE_PGE), and cr3 based flush.  For "-cpu host" case in
      my setup, the flush used invpcid_flush_all() variant, whereas for "-cpu
      kvm64", the flush was cr4 based. Switching the kvm64 case to cr3 manually
      worked fine, and further investigating the cr4 one turned out that
      X86_CR4_PGE bit was not set in cr4 register, meaning the
      __native_flush_tlb_global_irq_disabled() wrote cr4 twice with the same
      value instead of clearing X86_CR4_PGE in the first write to trigger the
      flush.
      
      It turned out that X86_CR4_PGE was cleared from cr4 during init from
      lguest_arch_host_init() via adjust_pge(). The X86_FEATURE_PGE bit is also
      cleared from there due to concerns of using PGE in guest kernel that can
      lead to hard to trace bugs (see bff672e6 ("lguest: documentation V:
      Host") in init()). The CPU feature bits are cleared in dynamic
      boot_cpu_data, but they never propagated to __flush_tlb_all() as it uses
      static_cpu_has() instead of boot_cpu_has() for testing which variant of TLB
      flushing to use, meaning they still used the old setting of the host
      kernel.
      
      Clearing via setup_clear_cpu_cap(X86_FEATURE_PGE) so this would propagate
      to static_cpu_has() checks is too late at this point as sections have been
      patched already, so for now, it seems reasonable to switch back to
      boot_cpu_has(X86_FEATURE_PGE) as it was prior to commit c109bf95
      ("x86/cpufeature: Remove cpu_has_pge"). This lets the TLB flush trigger via
      cr3 as originally intended, properly makes the new page attributes visible
      and thus fixes the crashes seen by Fengguang.
      
      Fixes: c109bf95 ("x86/cpufeature: Remove cpu_has_pge")
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: bp@suse.de
      Cc: Kees Cook <keescook@chromium.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: netdev@vger.kernel.org
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: lkp@01.org
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernrl.org/r/20170301125426.l4nf65rx4wahohyl@wfg-t540p.sh.intel.com
      Link: http://lkml.kernel.org/r/25c41ad9eca164be4db9ad84f768965b7eb19d9e.1489191673.git.daniel@iogearbox.netSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      2c4ea6e2
  9. 11 Mar, 2017 8 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 106e4da6
      Linus Torvalds authored
      Pull KVM fixes from Radim Krčmář:
       "ARM updates from Marc Zyngier:
         - vgic updates:
           - Honour disabling the ITS
           - Don't deadlock when deactivating own interrupts via MMIO
           - Correctly expose the lact of IRQ/FIQ bypass on GICv3
      
         - I/O virtualization:
           - Make KVM_CAP_NR_MEMSLOTS big enough for large guests with many
             PCIe devices
      
         - General bug fixes:
           - Gracefully handle exception generated with syndroms that the host
             doesn't understand
           - Properly invalidate TLBs on VHE systems
      
        x86:
         - improvements in emulation of VMCLEAR, VMX MSR bitmaps, and VCPU
           reset
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: nVMX: do not warn when MSR bitmap address is not backed
        KVM: arm64: Increase number of user memslots to 512
        KVM: arm/arm64: Remove KVM_PRIVATE_MEM_SLOTS definition that are unused
        KVM: arm/arm64: Enable KVM_CAP_NR_MEMSLOTS on arm/arm64
        KVM: Add documentation for KVM_CAP_NR_MEMSLOTS
        KVM: arm/arm64: VGIC: Fix command handling while ITS being disabled
        arm64: KVM: Survive unknown traps from guests
        arm: KVM: Survive unknown traps from guests
        KVM: arm/arm64: Let vcpu thread modify its own active state
        KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset
        kvm: nVMX: VMCLEAR should not cause the vCPU to shut down
        KVM: arm/arm64: vgic-v3: Don't pretend to support IRQ/FIQ bypass
        arm64: KVM: VHE: Clear HCR_TGE when invalidating guest TLBs
      106e4da6
    • Linus Torvalds's avatar
      Merge tag 'extable-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux · 4b050f22
      Linus Torvalds authored
      Pull extable.h fix from Paul Gortmaker:
       "Fixup for arch/score after extable.h introduction.
      
        It seems that Guenter is the only one on the planet doing builds for
        arch/score -- we don't have compile coverage for it in linux-next or
        in the kbuild-bot either. Guenter couldn't even recall where he got
        his toolchain, but was kind enough to share it with me so I could
        validate this change and also add arch/score to my build coverage.
      
        I sat on this a bit in case there was any other fallout in other arch
        dirs, but since this still seems to be the only one, I might as well
        send it on its way"
      
      * tag 'extable-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
        score: Fix implicit includes now failing build after extable change
      4b050f22
    • Linus Torvalds's avatar
      Merge tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random · 84c37c16
      Linus Torvalds authored
      Pull random updates from Ted Ts'o:
       "Change get_random_{int,log} to use the CRNG used by /dev/urandom and
        getrandom(2). It's faster and arguably more secure than cut-down MD5
        that we had been using.
      
        Also do some code cleanup"
      
      * tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
        random: move random_min_urandom_seed into CONFIG_SYSCTL ifdef block
        random: convert get_random_int/long into get_random_u32/u64
        random: use chacha20 for get_random_int/long
        random: fix comment for unused random_min_urandom_seed
        random: remove variable limit
        random: remove stale urandom_init_wait
        random: remove stale maybe_reseed_primary_crng
      84c37c16
    • Guenter Roeck's avatar
      score: Fix implicit includes now failing build after extable change · 0acf6119
      Guenter Roeck authored
      After changing from module.h to extable.h, score builds fail with:
      
        arch/score/kernel/traps.c: In function 'do_ri':
        arch/score/kernel/traps.c:248:4: error: implicit declaration of function 'user_disable_single_step'
        arch/score/mm/extable.c: In function 'fixup_exception':
        arch/score/mm/extable.c:32:38: error: dereferencing pointer to incomplete type
        arch/score/mm/extable.c:34:24: error: dereferencing pointer to incomplete type
      
      because extable.h doesn't drag in the same amount of headers as the
      module.h did.  Add in the headers which were implicitly expected.
      
      Fixes: 90858794 ("module.h: remove extable.h include now users have migrated")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      [PG: tweak commit log; refresh for sched header refactoring.]
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      0acf6119
    • Linus Torvalds's avatar
      Merge tag 'tty-4.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty · 434fd635
      Linus Torvalds authored
      Pull tty/serial fixes frpm Greg KH:
       "Here are two bugfixes for tty stuff for 4.11-rc2.
      
        One of them resolves the pretty bad bug in the n_hdlc code that
        Alexander Popov found and fixed and has been reported everywhere. The
        other just fixes a samsung serial driver issue when DMA fails on some
        systems.
      
        Both have been in linux-next with no reported issues"
      
      * tag 'tty-4.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
        serial: samsung: Continue to work if DMA request fails
        tty: n_hdlc: get rid of racy n_hdlc.tbuf
      434fd635
    • Linus Torvalds's avatar
      Merge tag 'staging-4.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging · 85298808
      Linus Torvalds authored
      Pull staging driver fixes from Greg KH:
       "Here are two small build warning fixes for some staging drivers that
        Arnd has found on his valiant quest to get the kernel to build
        properly with no warnings.
      
        Both of these have been in linux-next this week and resolve the
        reported issues"
      
      * tag 'staging-4.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
        staging: octeon: remove unused variable
        staging/vc04_services: add CONFIG_OF dependency
      85298808
    • Linus Torvalds's avatar
      Merge tag 'usb-4.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · 46552bf4
      Linus Torvalds authored
      Pull USB fixes from Greg KH:
       "Here is a number of different USB fixes for 4.11-rc2.
      
        Seems like there were a lot of unresolved issues that people have been
        finding for this subsystem, and a bunch of good security auditing
        happening as well from Johan Hovold. There's the usual batch of gadget
        driver fixes and xhci issues resolved as well.
      
       All of these have been in linux-next with no reported issues"
      
      * tag 'usb-4.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (35 commits)
        usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers
        usb: host: xhci-dbg: HCIVERSION should be a binary number
        usb: xhci: remove dummy extra_priv_size for size of xhci_hcd struct
        usb: xhci-mtk: check hcc_params after adding primary hcd
        USB: serial: digi_acceleport: fix OOB-event processing
        MAINTAINERS: usb251xb: remove reference inexistent file
        doc: dt-bindings: usb251xb: mark reg as required
        usb: usb251xb: dt: add unit suffix to oc-delay and power-on-time
        usb: usb251xb: remove max_{power,current}_{sp,bp} properties
        usb-storage: Add ignore-residue quirk for Initio INIC-3619
        USB: iowarrior: fix NULL-deref in write
        USB: iowarrior: fix NULL-deref at probe
        usb: phy: isp1301: Add OF device ID table
        usb: ohci-at91: Do not drop unhandled USB suspend control requests
        USB: serial: safe_serial: fix information leak in completion handler
        USB: serial: io_ti: fix information leak in completion handler
        USB: serial: omninet: drop open callback
        USB: serial: omninet: fix reference leaks at open
        USB: serial: io_ti: fix NULL-deref in interrupt callback
        usb: dwc3: gadget: make to increment req->remaining in all cases
        ...
      46552bf4
    • Linus Torvalds's avatar
      Merge tag 'pinctrl-v4.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl · cb853a82
      Linus Torvalds authored
      Pull pinctrl fixes from Linus Walleij:
       "Two smaller pin control fixes for the v4.11 series:
      
         - Add a get_direction() function to the qcom driver
      
         - Fix two pin names in the uniphier driver"
      
      * tag 'pinctrl-v4.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
        pinctrl: uniphier: change pin names of aio/xirq for LD11
        pinctrl: qcom: add get_direction function
      cb853a82
  10. 10 Mar, 2017 4 commits
    • Thomas Gleixner's avatar
      kexec, x86/purgatory: Unbreak it and clean it up · 40c50c1f
      Thomas Gleixner authored
      The purgatory code defines global variables which are referenced via a
      symbol lookup in the kexec code (core and arch).
      
      A recent commit addressing sparse warnings made these static and thereby
      broke kexec_file.
      
      Why did this happen? Simply because the whole machinery is undocumented and
      lacks any form of forward declarations. The variable names are unspecific
      and lack a prefix, so adding forward declarations creates shadow variables
      in the core code. Aside of that the code relies on magic constants and
      duplicate struct definitions with no way to ensure that these things stay
      in sync. The section placement of the purgatory variables happened by
      chance and not by design.
      
      Unbreak kexec and cleanup the mess:
      
       - Add proper forward declarations and document the usage
       - Use common struct definition
       - Use the proper common defines instead of magic constants
       - Add a purgatory_ prefix to have a proper name space
       - Use ARRAY_SIZE() instead of a homebrewn reimplementation
       - Add proper sections to the purgatory variables [ From Mike ]
      
      Fixes: 72042a8c ("x86/purgatory: Make functions and variables static")
      Reported-by: default avatarMike Galbraith <&lt;efault@gmx.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Nicholas Mc Guire <der.herr@hofr.at>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: "Tobin C. Harding" <me@tobin.cc>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1703101315140.3681@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      40c50c1f
    • Linus Torvalds's avatar
      Merge tag 'ceph-for-4.11-rc2' of git://github.com/ceph/ceph-client · 24c534bb
      Linus Torvalds authored
      Pull ceph fixes from Ilya Dryomov:
      
       - a fix for the recently discovered misdirected requests bug present in
         jewel and later on the server side and all stable kernels
      
       - a fixup for -rc1 CRUSH changes
      
       - two usability enhancements: osd_request_timeout option and
         supported_features bus attribute.
      
      * tag 'ceph-for-4.11-rc2' of git://github.com/ceph/ceph-client:
        libceph: osd_request_timeout option
        rbd: supported_features bus attribute
        libceph: don't set weight to IN when OSD is destroyed
        libceph: fix crush_decode() for older maps
      24c534bb
    • Linus Torvalds's avatar
      Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · 2baf3809
      Linus Torvalds authored
      Pull i2c fixes from Wolfram Sang:
       "Here are some driver bugfixes from I2C.
      
        Unusual this time are the two reverts. One because I accidently picked
        a patch from the list which I should have pulled from my co-maintainer
        instead ("missing of_node_put"). And one which I wrongly assumed to be
        an easy fix but it turned out already that it needs more iterations
        ("copy device properties")"
      
      * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        Revert "i2c: copy device properties when using i2c_register_board_info()"
        Revert "i2c: add missing of_node_put in i2c_mux_del_adapters"
        i2c: exynos5: Avoid transaction timeouts due TRANSFER_DONE_AUTO not set
        i2c: designware: add reset interface
        i2c: meson: fix wrong variable usage in meson_i2c_put_data
        i2c: copy device properties when using i2c_register_board_info()
        i2c: m65xx: drop superfluous quirk structure
        i2c: brcmstb: Fix START and STOP conditions
        i2c: add missing of_node_put in i2c_mux_del_adapters
        i2c: riic: fix restart condition
        i2c: add missing of_node_put in i2c_mux_del_adapters
      2baf3809
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-for-4.11-rc2' of git://people.freedesktop.org/~airlied/linux · 7c7fba98
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Intel, amd and mxsfb fixes.
      
        These are the drm fixes I've collected for rc2. Mostly i915 GVT only
        fixes, along with a single EDID fix, some mxsfb fixes and a few minor
        amd fixes"
      
      * tag 'drm-fixes-for-4.11-rc2' of git://people.freedesktop.org/~airlied/linux: (38 commits)
        drm: mxsfb: Implement drm_panel handling
        drm: mxsfb_crtc: Fix the framebuffer misplacement
        drm: mxsfb: Fix crash when provided invalid DT bindings
        drm: mxsfb: fix pixel clock polarity
        drm: mxsfb: use bus_format to determine LCD bus width
        drm/amdgpu: bump driver version for some new features
        drm/amdgpu: validate paramaters in the gem ioctl
        drm/amd/amdgpu: fix console deadlock if late init failed
        drm/i915/gvt: change some gvt_err to gvt_dbg_cmd
        drm/i915/gvt: protect RO and Rsvd bits of virtual vgpu configuration space
        drm/i915/gvt: handle workload lifecycle properly
        drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
        drm/i915/gvt: fix an error for F_RO flag
        drm/i915/gvt: use pfn_valid for better checking
        drm/i915/gvt: set SFUSE_STRAP properly for vitual monitor detection
        drm/i915/gvt: fix an error for one register
        drm/i915/gvt: add more registers into handlers list
        drm/i915/gvt: have more registers with F_CMD_ACCESS flags set
        drm/i915/gvt: add some new MMIOs to cmd_access white list
        drm/i915/gvt: fix pcode mailbox write emulation of BDW
        ...
      7c7fba98