Skip to content
  1. Mar 30, 2015
  2. Mar 29, 2015
  3. Mar 28, 2015
  4. Mar 27, 2015
  5. Mar 26, 2015
    • Daniel Vetter's avatar
      drm/i915: Fixup legacy plane->crtc link for initial fb config · 5f407751
      Daniel Vetter authored
      This is a very similar bug in the load detect code fixed in
      
      commit 9128b040
      
      
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Tue Mar 3 17:31:21 2015 +0100
      
          drm/i915: Fix modeset state confusion in the load detect code
      
      But this time around it was the initial fb code that forgot to update
      the plane->crtc pointer. Otherwise it's the exact same bug, with the
      exact same restrains (any set_config call/ioctl that doesn't disable
      the pipe papers over the bug for free, so fairly hard to hit in normal
      testing). So if you want the full explanation just go read that one
      over there - it's rather long ...
      
      Cc: Matt Roper <matthew.d.roper@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Reported-and-tested-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      [Jani: backported to drm-intel-fixes for v4.0-rc]
      Reference: http://mid.gmane.org/CA+5PVA7ChbtJrknqws1qvZcbrg1CW2pQAFkSMURWWgyASRyGXg@mail.gmail.com
      
      
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      5f407751
    • Damien Lespiau's avatar
      drm/i915: Fix atomic state when reusing the firmware fb · 3164a803
      Damien Lespiau authored
      
      
      Right now, we get a warning when taking over the firmware fb:
      
        [drm:drm_atomic_plane_check] FB set but no CRTC
      
      with the following backtrace:
      
        [<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm]
        [<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm]
        [<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
        [<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
        [<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper]
        [<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
        [<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
        [<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915]
        [<ffffffff813ad444>] fbcon_init+0x4f4/0x580
      
      That's because we update the plane state with the fb from the firmware, but we
      never associate the plane to that CRTC.
      
      We don't quite have the full DRM take over from HW state just yet, so
      fake enough of the plane atomic state to pass the checks.
      
      v2: Fix the state on which we set the CRTC in the case we're sharing the
          initial fb with another pipe. (Matt)
      
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      [Jani: backported to drm-intel-fixes for v4.0-rc]
      Reference: http://mid.gmane.org/CA+5PVA7yXH=U757w8V=Zj2U1URG4nYNav20NpjtQ4svVueyPNw@mail.gmail.com
      Reference: http://lkml.kernel.org/r/CA+55aFweWR=nDzc2Y=rCtL_H8JfdprQiCimN5dwc+TgyD4Bjsg@mail.gmail.com
      
      
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      3164a803
    • Hui Wang's avatar
      ALSA: hda - Add one more node in the EAPD supporting candidate list · af95b414
      Hui Wang authored
      We have a HP machine which use the codec node 0x17 connecting the
      internal speaker, and from the node capability, we saw the EAPD,
      if we don't set the EAPD on for this node, the internal speaker
      can't output any sound.
      
      Cc: <stable@vger.kernel.org>
      BugLink: https://bugs.launchpad.net/bugs/1436745
      
      
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      af95b414
    • Maxime Ripard's avatar
      clocksource/drivers/sun5i: Fix cpufreq interaction with sched_clock() · 6e206020
      Maxime Ripard authored
      
      
      The sun5i timer is used as the sched-clock on certain systems, and ever
      since we started using cpufreq, the cpu clock (that is one of the
      timer's clock indirect parent) now changes as well, along with the
      actual sched_clock() rate.
      
      This is not accurate and not desirable.
      
      We can safely remove the sun5i sched-clock on those systems, since we
      have other reliable sched_clock() sources in the system.
      
      Tested-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      [ Improved the changelog. ]
      Cc: richard@nod.at
      Link: http://lkml.kernel.org/r/1427362029-6511-4-git-send-email-daniel.lezcano@linaro.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6e206020
    • Richard Weinberger's avatar
      clocksource/drivers: Fix various !CONFIG_HAS_IOMEM build errors · 11bc26fe
      Richard Weinberger authored
      
      
      Fix !CONFIG_HAS_IOMEM related build failures in three clocksource drivers.
      
      The build failures have the pattern of:
      
        drivers/clocksource/sh_cmt.c: In function ‘sh_cmt_map_memory’: drivers/clocksource/sh_cmt.c:920:2:
        error: implicit declaration of function ‘ioremap_nocache’ [-Werror=implicit-function-declaration]   cmt->mapbase = ioremap_nocache(mem->start, resource_size(mem));
      
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Acked-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: maxime.ripard@free-electrons.com
      Link: http://lkml.kernel.org/r/1427362029-6511-1-git-send-email-daniel.lezcano@linaro.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      11bc26fe
    • Chris Wilson's avatar
      drm/i915: Keep ring->active_list and ring->requests_list consistent · 832a3aad
      Chris Wilson authored
      If we retire requests last, we may use a later seqno and so clear
      the requests lists without clearing the active list, leading to
      confusion. Hence we should retire requests first for consistency with
      the early return. The order used to be important as the lifecycle for
      the object on the active list was determined by request->seqno. However,
      the requests themselves are now reference counted removing the
      constraint from the order of retirement.
      
      Fixes regression from
      
      commit 1b5a433a
      
      
      Author: John Harrison <John.C.Harrison@Intel.com>
      Date:   Mon Nov 24 18:49:42 2014 +0000
      
          drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed
      '
      
      and a
      
      	WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279 i915_gem_evict_vm+0x10c/0x140()
      	WARN_ON(!list_empty(&vm->active_list))
      
      Identified by updating WATCH_LISTS:
      
      	[drm:i915_verify_lists] *ERROR* blitter ring: active list not empty, but no requests
      	WARNING: CPU: 0 PID: 681 at drivers/gpu/drm/i915/i915_gem.c:2751 i915_gem_retire_requests_ring+0x149/0x230()
      	WARN_ON(i915_verify_lists(ring->dev))
      
      Note that this is only a problem in evict_vm where the following happens
      after a retire_request has cleaned out all requests, but not all active
      bo:
      - intel_ring_idle called from i915_gpu_idle notices that no requests are
        outstanding and immediately returns.
      - i915_gem_retire_requests_ring called from i915_gem_retire_requests also
        immediately returns when there's no request, still leaving the bo on the
        active list.
      - evict_vm hits the WARN_ON(!list_empty(&vm->active_list)) after evicting
        all active objects that there's still stuff left that shouldn't be
        there.
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: John Harrison <John.C.Harrison@Intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      832a3aad
    • Libin Yang's avatar
      ALSA: hda_intel: apply the Seperate stream_tag for Sunrise Point · db48abf4
      Libin Yang authored
      
      
      The total stream number of Sunrise Point's input and output stream
      exceeds 15, which will cause some streams do not work because
      of the overflow on SDxCTL.STRM field if using the legacy
      stream tag allocation method.
      
      This patch uses the new stream tag allocation method by add
      the flag AZX_DCAPS_SEPARATE_STREAM_TAG for Skylake platform.
      
      Signed-off-by: default avatarLibin Yang <libin.yang@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      db48abf4
    • Vineet Gupta's avatar
      ARC: signal handling robustify · e4140819
      Vineet Gupta authored
      
      
      A malicious signal handler / restorer can DOS the system by fudging the
      user regs saved on stack, causing weird things such as sigreturn returning
      to user mode PC but cpu state still being kernel mode....
      
      Ensure that in sigreturn path status32 always has U bit; any other bogosity
      (gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.
      
      Reproducer signal handler:
      
          void handle_sig(int signo, siginfo_t *info, void *context)
          {
      	ucontext_t *uc = context;
      	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);
      
      	regs->scratch.status32 = 0;
          }
      
      Before the fix, kernel would go off to weeds like below:
      
          --------->8-----------
          [ARCLinux]$ ./signal-test
          Path: /signal-test
          CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
          task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000
      
          [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
          [EFA   ]: 0x00000010
          [BLINK ]: 0x2007c1ee
          [ERET  ]: 0x10698
          [STAT32]: 0x00000000 :                                   <--------
          BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
          LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
          ...
          --------->8-----------
      
      Reported-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      e4140819
    • Vineet Gupta's avatar
      ARC: SA_SIGINFO ucontext regs off-by-one · 6914e1e3
      Vineet Gupta authored
      The regfile provided to SA_SIGINFO signal handler as ucontext was off by
      one due to pt_regs gutter cleanups in 2013.
      
      Before handling signal, user pt_regs are copied onto user_regs_struct and copied
      back later. Both structs are binary compatible. This was all fine until
      commit 2fa91904 (ARC: pt_regs update #2) which removed the empty stack slot
      at top of pt_regs (corresponding to first pad) and made the corresponding
      fixup in struct user_regs_struct (the pad in there was moved out of
      @scratch - not removed altogether as it is part of ptrace ABI)
      
       struct user_regs_struct {
      +       long pad;
              struct {
      -               long pad;
                      long bta, lp_start, lp_end,....
              } scratch;
       ...
       }
      
      This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and
      signal code needs to user_regs_struct.scratch to reflect it as pt_regs,
      which is what this commit does.
      
      This problem was hidden for 2 years, because both save/restore, despite
      using wrong location, were using the same location. Only an interim
      inspection (reproducer below) exposed the issue.
      
           void handle_segv(int signo, siginfo_t *info, void *context)
           {
       	ucontext_t *uc = context;
      	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);
      
      	printf("regs %x %x\n",               <=== prints 7 8 (vs. 8 9)
                     regs->scratch.r8, regs->scratch.r9);
           }
      
           int main()
           {
      	struct sigaction sa;
      
      	sa.sa_sigaction = handle_segv;
      	sa.sa_flags = SA_SIGINFO;
      	sigemptyset(&sa.sa_mask);
      	sigaction(SIGSEGV, &sa, NULL);
      
      	asm volatile(
      	"mov	r7, 7	\n"
      	"mov	r8, 8	\n"
      	"mov	r9, 9	\n"
      	"mov	r10, 10	\n"
      	:::"r7","r8","r9","r10");
      
      	*((unsigned int*)0x10) = 0;
           }
      
      Fixes: 2fa91904
      
       "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs"
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      6914e1e3
    • Linus Torvalds's avatar
      Merge tag 'metag-fixes-v4.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag · 4c4fe4c2
      Linus Torvalds authored
      Pull arch/metag fix from James Hogan:
       "Another metag architecture fix for v4.0
      
        This is another single fix, for an include dependency problem when
        using ioremap_wc() from asm/io.h without also including asm/pgtable.h"
      
      * tag 'metag-fixes-v4.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag:
        metag: Fix ioremap_wc/ioremap_cached build errors
      4c4fe4c2
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 9c8e30d1
      Linus Torvalds authored
      Merge misc fixes from Andrew Morton:
       "15 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        mm: numa: mark huge PTEs young when clearing NUMA hinting faults
        mm: numa: slow PTE scan rate if migration failures occur
        mm: numa: preserve PTE write permissions across a NUMA hinting fault
        mm: numa: group related processes based on VMA flags instead of page table flags
        hfsplus: fix B-tree corruption after insertion at position 0
        MAINTAINERS: add Jan as DMI/SMBIOS support maintainer
        fs/affs/file.c: unlock/release page on error
        mm/page_alloc.c: call kernel_map_pages in unset_migrateype_isolate
        mm/slub: fix lockups on PREEMPT && !SMP kernels
        mm/memory hotplug: postpone the reset of obsolete pgdat
        MAINTAINERS: correct rtc armada38x pattern entry
        mm/pagewalk.c: prevent positive return value of walk_page_test() from being passed to callers
        mm: fix anon_vma->degree underflow in anon_vma endless growing prevention
        drivers/rtc/rtc-mrst: fix suspend/resume
        aoe: update aoe maintainer information
      9c8e30d1
    • Marcelo Tosatti's avatar
      Merge tag 'signed-for-4.0' of git://github.com/agraf/linux-2.6 · 27bfc6cf
      Marcelo Tosatti authored
      Patch queue for 4.0 - 2015-03-25
      
      A few bug fixes for Book3S HV KVM:
      
        - Fix spinlock ordering
        - Fix idle guests on LE hosts
        - Fix instruction emulation
      27bfc6cf
    • Mel Gorman's avatar
      mm: numa: mark huge PTEs young when clearing NUMA hinting faults · b7b04004
      Mel Gorman authored
      
      
      Base PTEs are marked young when the NUMA hinting information is cleared
      but the same does not happen for huge pages which this patch addresses.
      
      Note that migrated pages are not marked young as the base page migration
      code does not assume that migrated pages have been referenced.  This
      could be addressed but beyond the scope of this series which is aimed at
      Dave Chinners shrink workload that is unlikely to be affected by this
      issue.
      
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b7b04004