rpms/kernel
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Linux v4.13.6

Browse Source
This commit is contained in:
Justin M. Forbes 2017-10-12 10:40:29 -05:00
parent f43f87d5aa
commit 4ae8c94a38
5 changed files with 247 additions and 157 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch
View File

@ -1,74 +0,0 @@
From patchwork Sun Jul 23 01:15:09 2017
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: HID: rmi: Make sure the HID device is opened on resume
From: Lyude <lyude@redhat.com>
X-Patchwork-Id: 9858267
Message-Id: <20170723011509.23651-1-lyude@redhat.com>
To: linux-input@vger.kernel.org
Cc: Lyude <lyude@redhat.com>, Andrew Duggan <aduggan@synaptics.com>,
stable@vger.kernel.org, Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
linux-kernel@vger.kernel.org
Date: Sat, 22 Jul 2017 21:15:09 -0400
So it looks like that suspend/resume has actually always been broken on
hid-rmi. The fact it worked was a rather silly coincidence that was
relying on the HID device to already be opened upon resume. This means
that so long as anything was reading the /dev/input/eventX node for for
an RMI device, it would suspend and resume correctly. As well, if
nothing happened to be keeping the HID device away it would shut off,
then the RMI driver would get confused on resume when it stopped
responding and explode.
So, call hid_hw_open() in rmi_post_resume() so we make sure that the
device is alive before we try talking to it.
This fixes RMI device suspend/resume over HID.
Signed-off-by: Lyude <lyude@redhat.com>
Cc: Andrew Duggan <aduggan@synaptics.com>
Cc: stable@vger.kernel.org
---
drivers/hid/hid-rmi.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 5b40c2614599..e7d124f9a27f 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -431,22 +431,29 @@ static int rmi_post_resume(struct hid_device *hdev)
{
struct rmi_data *data = hid_get_drvdata(hdev);
struct rmi_device *rmi_dev = data->xport.rmi_dev;
- int ret;
+ int ret = 0;
if (!(data->device_flags & RMI_DEVICE))
return 0;
- ret = rmi_reset_attn_mode(hdev);
+ /* Make sure the HID device is ready to receive events */
+ ret = hid_hw_open(hdev);
if (ret)
return ret;
+ ret = rmi_reset_attn_mode(hdev);
+ if (ret)
+ goto out;
+
ret = rmi_driver_resume(rmi_dev, false);
if (ret) {
hid_warn(hdev, "Failed to resume device: %d\n", ret);
- return ret;
+ goto out;
}
- return 0;
+out:
+ hid_hw_close(hdev);
+ return ret;
}
#endif /* CONFIG_PM */

79
arm64-ensure-ready-for-userspace.patch
View File

@ -1,79 +0,0 @@
From c0d8832e78cbfd4a64b7112e34920af4b0b0e60e Mon Sep 17 00:00:00 2001
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Date: Fri, 6 Oct 2017 14:16:52 +0100
Subject: arm64: Ensure the instruction emulation is ready for userspace
We trap and emulate some instructions (e.g, mrs, deprecated instructions)
for the userspace. However the handlers for these are registered as
late_initcalls and the userspace could be up and running from the initramfs
by that time (with populate_rootfs, which is a rootfs_initcall()). This
could cause problems for the early applications ending up in failure
like :
[ 11.152061] modprobe[93]: undefined instruction: pc=0000ffff8ca48ff4
This patch promotes the specific calls to core_initcalls, which are
guaranteed to be completed before we hit userspace.
Cc: stable@vger.kernel.org
Cc: Dave Martin <dave.martin@arm.com>
Cc: Matthias Brugger <mbrugger@suse.com>
Cc: James Morse <james.morse@arm.com>
Reported-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/armv8_deprecated.c | 2 +-
arch/arm64/kernel/cpufeature.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index f0e6d71..d06fbe4 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -649,4 +649,4 @@ static int __init armv8_deprecated_init(void)
return 0;
}
-late_initcall(armv8_deprecated_init);
+core_initcall(armv8_deprecated_init);
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index cd52d36..21e2c95 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1307,4 +1307,4 @@ static int __init enable_mrs_emulation(void)
return 0;
}
-late_initcall(enable_mrs_emulation);
+core_initcall(enable_mrs_emulation);
From ae2e972dae3cea795e9f8f94eb1601213c2d49f0 Mon Sep 17 00:00:00 2001
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Date: Fri, 6 Oct 2017 14:16:53 +0100
Subject: arm64: Ensure fpsimd support is ready before userspace is active
We register the pm/hotplug callbacks for FPSIMD as late_initcall,
which happens after the userspace is active (from initramfs via
populate_rootfs, a rootfs_initcall). Make sure we are ready even
before the userspace could potentially use it, by promoting to
a core_initcall.
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/fpsimd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index f444f37..5d547de 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -444,4 +444,4 @@ static int __init fpsimd_init(void)
return 0;
}
-late_initcall(fpsimd_init);
+core_initcall(fpsimd_init);

238
drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch Normal file
View File

@ -0,0 +1,238 @@
From 333e2a813cdfb86ff286ece6f13bec371aa03d7b Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu, 17 Aug 2017 13:37:06 +0100
Subject: [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If we miss the current vblank because the gpu was busy, that may cause a
jitter as the frame rate temporarily drops. We try to limit the impact
of this by then boosting the GPU clock to deliver the frame as quickly
as possible. Originally done in commit 6ad790c0f5ac ("drm/i915: Boost GPU
frequency if we detect outstanding pageflips") but was never forward
ported to atomic and finally dropped in commit fd3a40242e87 ("drm/i915:
Rip out legacy page_flip completion/irq handling").
One of the most typical use-cases for this is a mostly idle desktop.
Rendering one frame of the desktop's frontbuffer can easily be
accomplished by the GPU running at low frequency, but often exceeds
the time budget of the desktop compositor. The result is that animations
such as opening the menu, doing a fullscreen switch, or even just trying
to move a window around are slow and jerky. We need to respond within a
frame to give the best impression of a smooth UX, as a compromise we
instead respond if that first frame misses its goal. The result should
be a near-imperceivable initial delay and a smooth animation even
starting from idle. The cost, as ever, is that we spend more power than
is strictly necessary as we overestimate the required GPU frequency and
then try to ramp down.
This of course is reactionary, too little, too late; nevertheless it is
surprisingly effective.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102199
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817123706.6777-1-chris@chris-wilson.co.uk
Tested-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
---
drivers/gpu/drm/i915/i915_gem.c | 10 +++---
drivers/gpu/drm/i915/intel_display.c | 63 ++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_pm.c | 14 ++++----
3 files changed, 77 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 969bac8404f1..7d409b29d75a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -355,6 +355,7 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
long timeout,
struct intel_rps_client *rps)
{
+ unsigned long irq_flags;
struct drm_i915_gem_request *rq;
BUILD_BUG_ON(I915_WAIT_INTERRUPTIBLE != 0x1);
@@ -410,9 +411,9 @@ i915_gem_object_wait_fence(struct dma_fence *fence,
* Compensate by giving the synchronous client credit for
* a waitboost next time.
*/
- spin_lock(&rq->i915->rps.client_lock);
+ spin_lock_irqsave(&rq->i915->rps.client_lock, irq_flags);
list_del_init(&rps->link);
- spin_unlock(&rq->i915->rps.client_lock);
+ spin_unlock_irqrestore(&rq->i915->rps.client_lock, irq_flags);
}
return timeout;
@@ -5029,6 +5030,7 @@ void i915_gem_release(struct drm_device *dev, struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
struct drm_i915_gem_request *request;
+ unsigned long flags;
/* Clean up our request list when the client is going away, so that
* later retire_requests won't dereference our soon-to-be-gone
@@ -5040,9 +5042,9 @@ void i915_gem_release(struct drm_device *dev, struct drm_file *file)
spin_unlock(&file_priv->mm.lock);
if (!list_empty(&file_priv->rps.link)) {
- spin_lock(&to_i915(dev)->rps.client_lock);
+ spin_lock_irqsave(&to_i915(dev)->rps.client_lock, flags);
list_del(&file_priv->rps.link);
- spin_unlock(&to_i915(dev)->rps.client_lock);
+ spin_unlock_irqrestore(&to_i915(dev)->rps.client_lock, flags);
}
}
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 022125082649..875eb7aec2f1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13301,6 +13301,58 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.set_crc_source = intel_crtc_set_crc_source,
};
+struct wait_rps_boost {
+ struct wait_queue_entry wait;
+
+ struct drm_crtc *crtc;
+ struct drm_i915_gem_request *request;
+};
+
+static int do_rps_boost(struct wait_queue_entry *_wait,
+ unsigned mode, int sync, void *key)
+{
+ struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), wait);
+ struct drm_i915_gem_request *rq = wait->request;
+
+ gen6_rps_boost(rq->i915, NULL, rq->emitted_jiffies);
+ i915_gem_request_put(rq);
+
+ drm_crtc_vblank_put(wait->crtc);
+
+ list_del(&wait->wait.entry);
+ kfree(wait);
+ return 1;
+}
+
+static void add_rps_boost_after_vblank(struct drm_crtc *crtc,
+ struct dma_fence *fence)
+{
+ struct wait_rps_boost *wait;
+
+ if (!dma_fence_is_i915(fence))
+ return;
+
+ if (INTEL_GEN(to_i915(crtc->dev)) < 6)
+ return;
+
+ if (drm_crtc_vblank_get(crtc))
+ return;
+
+ wait = kmalloc(sizeof(*wait), GFP_KERNEL);
+ if (!wait) {
+ drm_crtc_vblank_put(crtc);
+ return;
+ }
+
+ wait->request = to_request(dma_fence_get(fence));
+ wait->crtc = crtc;
+
+ wait->wait.func = do_rps_boost;
+ wait->wait.flags = 0;
+
+ add_wait_queue(drm_crtc_vblank_waitqueue(crtc), &wait->wait);
+}
+
/**
* intel_prepare_plane_fb - Prepare fb for usage on plane
* @plane: drm plane to prepare for
@@ -13392,6 +13444,8 @@ intel_prepare_plane_fb(struct drm_plane *plane,
return 0;
if (!new_state->fence) { /* implicit fencing */
+ struct dma_fence *fence;
+
ret = i915_sw_fence_await_reservation(&intel_state->commit_ready,
obj->resv, NULL,
false, I915_FENCE_TIMEOUT,
@@ -13399,7 +13453,16 @@ intel_prepare_plane_fb(struct drm_plane *plane,
if (ret < 0)
return ret;
+ fence = reservation_object_get_excl_rcu(obj->resv);
+ if (fence) {
+ add_rps_boost_after_vblank(new_state->crtc, fence);
+ dma_fence_put(fence);
+ }
+
i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
+
+ } else {
+ add_rps_boost_after_vblank(new_state->crtc, new_state->fence);
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 40b224b44d1b..b0ee9c4d33f4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6108,6 +6108,7 @@ void gen6_rps_busy(struct drm_i915_private *dev_priv)
void gen6_rps_idle(struct drm_i915_private *dev_priv)
{
+ unsigned long flags;
/* Flush our bottom-half so that it does not race with us
* setting the idle frequency and so that it is bounded by
* our rpm wakeref. And then disable the interrupts to stop any
@@ -6127,16 +6128,17 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
}
mutex_unlock(&dev_priv->rps.hw_lock);
- spin_lock(&dev_priv->rps.client_lock);
+ spin_lock_irqsave(&dev_priv->rps.client_lock, flags);
while (!list_empty(&dev_priv->rps.clients))
list_del_init(dev_priv->rps.clients.next);
- spin_unlock(&dev_priv->rps.client_lock);
+ spin_unlock_irqrestore(&dev_priv->rps.client_lock, flags);
}
void gen6_rps_boost(struct drm_i915_private *dev_priv,
struct intel_rps_client *rps,
unsigned long submitted)
{
+ unsigned long flags;
/* This is intentionally racy! We peek at the state here, then
* validate inside the RPS worker.
*/
@@ -6151,14 +6153,14 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
if (rps && time_after(jiffies, submitted + DRM_I915_THROTTLE_JIFFIES))
rps = NULL;
- spin_lock(&dev_priv->rps.client_lock);
+ spin_lock_irqsave(&dev_priv->rps.client_lock, flags);
if (rps == NULL || list_empty(&rps->link)) {
- spin_lock_irq(&dev_priv->irq_lock);
+ spin_lock(&dev_priv->irq_lock);
if (dev_priv->rps.interrupts_enabled) {
dev_priv->rps.client_boost = true;
schedule_work(&dev_priv->rps.work);
}
- spin_unlock_irq(&dev_priv->irq_lock);
+ spin_unlock(&dev_priv->irq_lock);
if (rps != NULL) {
list_add(&rps->link, &dev_priv->rps.clients);
@@ -6166,7 +6168,7 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
} else
dev_priv->rps.boosts++;
}
- spin_unlock(&dev_priv->rps.client_lock);
+ spin_unlock_irqrestore(&dev_priv->rps.client_lock, flags);
}
int intel_set_rps(struct drm_i915_private *dev_priv, u8 val)

11
kernel.spec
View File

@ -54,7 +54,7 @@ Summary: The Linux kernel
%if 0%{?released_kernel}
# Do we have a -stable update to apply?
%define stable_update 5
%define stable_update 6
# Set rpm version accordingly
%if 0%{?stable_update}
%define stablerev %{stable_update}
@ -655,7 +655,6 @@ Patch335: arm64-cavium-fixes.patch
# https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0d8832e78cbfd4a64b7112e34920af4b0b0e60e
# https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae2e972dae3cea795e9f8f94eb1601213c2d49f0
Patch350: arm64-ensure-ready-for-userspace.patch
# 400 - IBM (ppc/s390x) patches
@ -690,7 +689,6 @@ Patch619: pci-mark-amd-stoney-gpu-ats-as-broken.patch
Patch622: qxl-fixes.patch
# rhbz 1431375
Patch623: HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch
Patch624: input-rmi4-remove-the-need-for-artifical-IRQ.patch
# rhbz 1432684
@ -704,6 +702,9 @@ Patch629: 0001-platform-x86-peaq-wmi-Add-DMI-check-before-binding-t.patch
# rhbz 1482648
Patch630: Input-synaptics---Disable-kernel-tracking-on-SMBus-devices.patch
# Headed upstream
Patch631: drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch
# END OF PATCH DEFINITIONS
%endif
@ -2258,6 +2259,10 @@ fi
#
#
%changelog
* Thu Oct 12 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.13.6-300
- Linux v4.13.6
- Fixes CVE-2017-1000255 (rhbz 1498067 1500335)
* Thu Oct 12 2017 Peter Robinson <pbrobinson@fedoraproject.org>
- Fixes for Cavium ThunderX plaforms

2
sources
View File

@ -1,3 +1,3 @@
SHA512 (linux-4.13.tar.xz) = a557c2f0303ae618910b7106ff63d9978afddf470f03cb72aa748213e099a0ecd5f3119aea6cbd7b61df30ca6ef3ec57044d524b7babbaabddf8b08b8bafa7d2
SHA512 (perf-man-4.13.tar.gz) = 9bcc2cd8e56ec583ed2d8e0b0c88e7a94035a1915e40b3177bb02d6c0f10ddd4df9b097b1f5af59efc624226b613e240ddba8ddc2156f3682f992d5455fc5c03
SHA512 (patch-4.13.5.xz) = de55b07e52e88e3bc5af54c619933a81f535393f20712f38000bffa77ded22c7a16e70e43c28daf576bcc6cd3ad39387b8e1f430e3d22222f572113d2345df48
SHA512 (patch-4.13.6.xz) = 40e111f3969b622f982bfb75f8c35aa59d9989a627a4511d8e0090b0c7bbcafcc90567434f5166ef2d17831f0beddb52762107e523414523e1877f67f66ca3f7