1. 19 Jul, 2018 1 commit
  2. 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
  3. 07 Feb, 2018 12 commits
  4. 04 Jan, 2018 3 commits
  5. 14 Dec, 2017 5 commits
  6. 09 Dec, 2017 9 commits
  7. 05 Dec, 2017 9 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: 's 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: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ville Syrjälä's avatar
      drm/i915: Prevent zero length "index" write · 88e1bb2a
      Ville Syrjälä authored
      commit 56350fb8978bbf4aafe08f21234e161dd128b417 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: 's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.syrjala@linux.intel.comReviewed-by: 's avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit bb9e0d4bca50f429152e74a459160b41f3d60fb2)
      Signed-off-by: 's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: 's 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 ae5c631e605a452a5a0e73205a92810c01ed954b 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: 's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.syrjala@linux.intel.comReviewed-by: 's avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit c4deb62d7821672265b87952bcd1c808f3bf3e8f)
      Signed-off-by: 's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: 's 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 b721b65af4eb46df6a1d9e34b14003225e403565 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: 's avatarXiong Zhang <xiong.y.zhang@intel.com>
      Signed-off-by: 's avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: 's 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 a45b30a6c5db631e2ba680304bd5edd0cd1f9643 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: 's 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: 's avatarLukas Wunner <lukas@wunner.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@chris-wilson.co.uk
      (cherry picked from commit ad88d7fc6c032ddfb32b8d496a070ab71de3a64f)
      Signed-off-by: 's avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: 's 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 294cf1af8cf2eb0d1eced377fdfb9a2d3f0e8b42 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: 's avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: 's avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: 's avatarHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
      (cherry picked from commit bedf4d79c3654921839b62246b0965ddb308b201)
      Signed-off-by: 's avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: 's 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 f4359cedfb43b934f38c50d1604db21333abe57b 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: 's avatarFKr <bugs-freedesktop@ubermail.me>
      Reviewed-by: 's avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: 's avatarHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
      (cherry picked from commit ce30560c80dead91e98a03d90fb8791e57a9b69d)
      Signed-off-by: 's avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • NeilBrown's avatar
      md: forbid a RAID5 from having both a bitmap and a journal. · a6793684
      NeilBrown authored
      commit 230b55fa8d64007339319539f8f8e68114d08529 upstream.
      Having both a bitmap and a journal is pointless.
      Attempting to do so can corrupt the bitmap if the journal
      replay happens before the bitmap is initialized.
      Rather than try to avoid this corruption, simply
      refuse to allow arrays with both a bitmap and a journal.
       - if raid5_run sees both are present, fail.
       - if adding a bitmap finds a journal is present, fail
       - if adding a journal finds a bitmap is present, fail.
      Signed-off-by: 's avatarNeilBrown <neilb@suse.com>
      Tested-by: 's avatarJoshua Kinard <kumba@gentoo.org>
      Acked-by: 's avatarJoshua Kinard <kumba@gentoo.org>
      Signed-off-by: 's avatarShaohua Li <shli@fb.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>