1. 24 Jul, 2018 1 commit
  2. 19 Jul, 2018 1 commit
  3. 17 Jul, 2018 1 commit
    • Philippe Gerum's avatar
      arm64/ipipe: multiplex IPIs · e401d452
      Philippe Gerum authored
      SGI8-15 can be reserved for the exclusive use of the firmware. The
      ARM64 kernel currently uses six of them (NR_IPI), and the pipeline
      needs to define three more for conveying out-of-band events
      (i.e. reschedule, hrtimer and critical IPIs). Therefore we have to
      multiplex nine inter-processor events over eight SGIs (SGI0-7).
      This patch changes the IPI management in order to multiplex all
      regular (in-band) IPIs over SGI0, reserving SGI1-3 for out-of-band
  4. 07 Feb, 2018 12 commits
  5. 04 Jan, 2018 3 commits
  6. 14 Dec, 2017 5 commits
  7. 09 Dec, 2017 9 commits
  8. 05 Dec, 2017 8 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.4 · 51a2a68f
      Greg Kroah-Hartman authored
    • Greg Kroah-Hartman's avatar
      Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()" · e49d722f
      Greg Kroah-Hartman authored
      This reverts commit f9a64e23 which is
      commit 0d794d0d018f23fb09c50f6ae26868bd6ae343d6 upstream.
      Andy writes:
      	I think the thing to do is to revert the patch from -stable.
      	The bug it fixes is very minor, and the regression is that it
      	made a pre-existing bug in some nearly-undebuggable core resume
      	code much easier to hit.  I don't feel comfortable with a
      	backport of the latter fix until it has a good long soak in
      	Linus' tree.
      Reported-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bpetkov@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ville Syrjälä's avatar
      drm/i915: Prevent zero length "index" write · 88e1bb2a
      Ville Syrjälä authored
      commit 56350fb8 upstream.
      The hardware always writes one or two bytes in the index portion of
      an indexed transfer. Make sure the message we send as the index
      doesn't have a zero length.
      Cc: Daniel Kurtz <djkurtz@chromium.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Sean Paul <seanpaul@chromium.org>
      Fixes: 56f9eac0 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit bb9e0d4b)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ville Syrjälä's avatar
      drm/i915: Don't try indexed reads to alternate slave addresses · e522b924
      Ville Syrjälä authored
      commit ae5c631e upstream.
      We can only specify the one slave address to indexed reads/writes.
      Make sure the messages we check are destined to the same slave
      address before deciding to do an indexed transfer.
      Cc: Daniel Kurtz <djkurtz@chromium.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Sean Paul <seanpaul@chromium.org>
      Fixes: 56f9eac0 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit c4deb62d)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Xiong Zhang's avatar
      drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition · 6c0d3d1d
      Xiong Zhang authored
      commit b721b65a upstream.
      For ADDR_4K_MASK, bit[45..12] should be 1, all other bits
      should be 0. The current definition wrongly set bit[46] as 1
      also. This path fixes this.
      v2: Add commit message, fixes and cc stable.(Zhenyu)
      Fixes: 2707e444("drm/i915/gvt: vGPU graphics memory virtualization")
      Signed-off-by: default avatarXiong Zhang <xiong.y.zhang@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Chris Wilson's avatar
      drm/i915/fbdev: Serialise early hotplug events with async fbdev config · 7042c2b9
      Chris Wilson authored
      commit a45b30a6 upstream.
      As both the hotplug event and fbdev configuration run asynchronously, it
      is possible for them to run concurrently. If configuration fails, we were
      freeing the fbdev causing a use-after-free in the hotplug event.
      <7>[ 3069.935211] [drm:intel_fb_initial_config [i915]] Not using firmware configuration
      <7>[ 3069.935225] [drm:drm_setup_crtcs] looking for cmdline mode on connector 77
      <7>[ 3069.935229] [drm:drm_setup_crtcs] looking for preferred mode on connector 77 0
      <7>[ 3069.935233] [drm:drm_setup_crtcs] found mode 3200x1800
      <7>[ 3069.935236] [drm:drm_setup_crtcs] picking CRTCs for 8192x8192 config
      <7>[ 3069.935253] [drm:drm_setup_crtcs] desired mode 3200x1800 set on crtc 43 (0,0)
      <7>[ 3069.935323] [drm:intelfb_create [i915]] no BIOS fb, allocating a new one
      <4>[ 3069.967737] general protection fault: 0000 [#1] PREEMPT SMP
      <0>[ 3069.977453] ---------------------------------
      <4>[ 3069.977457] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii prime_numbers mei i2c_hid pinctrl_geminilake pinctrl_intel [last unloaded: i915]
      <4>[ 3069.977492] CPU: 1 PID: 15414 Comm: kworker/1:0 Tainted: G     U          4.14.0-CI-CI_DRM_3388+ #1
      <4>[ 3069.977497] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
      <4>[ 3069.977508] Workqueue: events output_poll_execute
      <4>[ 3069.977512] task: ffff880177734e40 task.stack: ffffc90001fe4000
      <4>[ 3069.977519] RIP: 0010:__lock_acquire+0x109/0x1b60
      <4>[ 3069.977523] RSP: 0018:ffffc90001fe7bb0 EFLAGS: 00010002
      <4>[ 3069.977526] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000282 RCX: 0000000000000000
      <4>[ 3069.977530] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880170d4efd0
      <4>[ 3069.977534] RBP: ffffc90001fe7c70 R08: 0000000000000001 R09: 0000000000000000
      <4>[ 3069.977538] R10: 0000000000000000 R11: ffffffff81899609 R12: ffff880170d4efd0
      <4>[ 3069.977542] R13: ffff880177734e40 R14: 0000000000000001 R15: 0000000000000000
      <4>[ 3069.977547] FS:  0000000000000000(0000) GS:ffff88017fc80000(0000) knlGS:0000000000000000
      <4>[ 3069.977551] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4>[ 3069.977555] CR2: 00007f7e8b7bcf04 CR3: 0000000003e0f000 CR4: 00000000003406e0
      <4>[ 3069.977559] Call Trace:
      <4>[ 3069.977565]  ? mark_held_locks+0x64/0x90
      <4>[ 3069.977571]  ? _raw_spin_unlock_irq+0x24/0x50
      <4>[ 3069.977575]  ? _raw_spin_unlock_irq+0x24/0x50
      <4>[ 3069.977579]  ? trace_hardirqs_on_caller+0xde/0x1c0
      <4>[ 3069.977583]  ? _raw_spin_unlock_irq+0x2f/0x50
      <4>[ 3069.977588]  ? finish_task_switch+0xa5/0x210
      <4>[ 3069.977592]  ? lock_acquire+0xaf/0x200
      <4>[ 3069.977596]  lock_acquire+0xaf/0x200
      <4>[ 3069.977600]  ? __mutex_lock+0x5e9/0x9b0
      <4>[ 3069.977604]  _raw_spin_lock+0x2a/0x40
      <4>[ 3069.977608]  ? __mutex_lock+0x5e9/0x9b0
      <4>[ 3069.977612]  __mutex_lock+0x5e9/0x9b0
      <4>[ 3069.977616]  ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
      <4>[ 3069.977621]  ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
      <4>[ 3069.977625]  drm_fb_helper_hotplug_event.part.19+0x16/0xa0
      <4>[ 3069.977630]  output_poll_execute+0x8d/0x180
      <4>[ 3069.977635]  process_one_work+0x22e/0x660
      <4>[ 3069.977640]  worker_thread+0x48/0x3a0
      <4>[ 3069.977644]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
      <4>[ 3069.977649]  kthread+0x102/0x140
      <4>[ 3069.977653]  ? process_one_work+0x660/0x660
      <4>[ 3069.977657]  ? kthread_create_on_node+0x40/0x40
      <4>[ 3069.977662]  ret_from_fork+0x27/0x40
      <4>[ 3069.977666] Code: 8d 62 f8 c3 49 81 3c 24 e0 fa 3c 82 41 be 00 00 00 00 45 0f 45 f0 83 fe 01 77 86 89 f0 49 8b 44 c4 08 48 85 c0 0f 84 76 ff ff ff <f0> ff 80 38 01 00 00 8b 1d 62 f9 e8 01 45 8b 85 b8 08 00 00 85
      <1>[ 3069.977707] RIP: __lock_acquire+0x109/0x1b60 RSP: ffffc90001fe7bb0
      <4>[ 3069.977712] ---[ end trace 4ad012eb3af62df7 ]---
      In order to keep the dev_priv->ifbdev alive after failure, we have to
      avoid the free and leave it empty until we unload the module (which is
      less than ideal, but a necessary evil for simplicity). Then we can use
      intel_fbdev_sync() to serialise the hotplug event with the configuration.
      The serialisation between the two was removed in commit 934458c2
      ("Revert "drm/i915: Fix races on fbdev""), but the use after free is much
      older, commit 366e39b4 ("drm/i915: Tear down fbdev if initialization
      Fixes: 366e39b4 ("drm/i915: Tear down fbdev if initialization fails")
      Fixes: 934458c2 ("Revert "drm/i915: Fix races on fbdev"")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Lukas Wunner <lukas@wunner.de>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarLukas Wunner <lukas@wunner.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@chris-wilson.co.uk
      (cherry picked from commit ad88d7fc)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hans de Goede's avatar
      drm/i915: Re-register PMIC bus access notifier on runtime resume · 569e3d1d
      Hans de Goede authored
      commit 294cf1af upstream.
      intel_uncore_suspend() unregisters the uncore code's PMIC bus access
      notifier and gets called on both normal and runtime suspend.
      intel_uncore_resume_early() re-registers the notifier, but only on
      normal resume. Add a new intel_uncore_runtime_resume() function which
      only re-registers the notifier and call that on runtime resume.
      Reported-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
      (cherry picked from commit bedf4d79)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hans de Goede's avatar
      drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 · 6613dc72
      Hans de Goede authored
      commit f4359ced upstream.
      assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
      even though it gets unregistered on (runtime) suspend, this is caused
      by a race happening under the following circumstances:
      intel_runtime_pm_put does:
      And pm_runtime_put_autosuspend calls intel_runtime_suspend from
      a workqueue, so there is ample of time between the atomic_dec() and
      intel_runtime_suspend() unregistering the notifier. If the notifier
      gets called in this windowd assert_rpm_wakelock_held falsely triggers
      (at this point we're not runtime-suspended yet).
      This commit adds disable_rpm_wakeref_asserts and
      enable_rpm_wakeref_asserts calls around the
      intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
      i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.
      Changes in v2:
      -Reword comment explaining why disabling the wakeref asserts is
       ok and necessary
      Reported-by: default avatarFKr <bugs-freedesktop@ubermail.me>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
      (cherry picked from commit ce30560c)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>