On Denverton's integration of the Intel(R) Trace Hub (for a reference
and overview see Documentation/trace/intel_th.txt) the reported size of
one of its resources (RTIT_BAR) doesn't match its actual size, which
leads to overlaps with other devices' resources.
In practice, it overlaps with XHCI MMIO space, which results in the xhci
driver bailing out after seeing its registers as 0xffffffff, and perceived
disappearance of all USB devices:
> intel_th_pci 0000:00:1f.7: enabling device (0004 -> 0006)
> xhci_hcd 0000:00:15.0: xHCI host controller not responding, assume dead
> xhci_hcd 0000:00:15.0: xHC not responding in xhci_irq, assume controller is dead
> xhci_hcd 0000:00:15.0: HC died; cleaning up
> usb 1-1: USB disconnect, device number 2
...
For this reason, we need to resize the RTIT_BAR on Denverton to its
actual size, which in this case is 4MB. The corresponding erratum is
DNV36 at the link below.
Link: https://www.intel.com/content/dam/www/public/us/en/documents/specification-…
Fixes: 5118ccd34780 ("intel_th: pci: Add Denverton SOC support")
Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: stable(a)vger.kernel.org
---
arch/x86/pci/fixup.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 30a5111ae5fd..527e69b12002 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -635,6 +635,22 @@ static void quirk_no_aersid(struct pci_dev *pdev)
DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
PCI_CLASS_BRIDGE_PCI, 8, quirk_no_aersid);
+static void quirk_intel_th_dnv(struct pci_dev *dev)
+{
+ struct resource *r = &dev->resource[4];
+
+ /*
+ * Denverton reports 2k of RTIT_BAR (intel_th resource 4), which
+ * appears to be 4 MB in reality.
+ */
+ if (r->end == r->start + 0x7ff) {
+ r->start = 0;
+ r->end = 0x3fffff;
+ r->flags |= IORESOURCE_UNSET;
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x19e1, quirk_intel_th_dnv);
+
#ifdef CONFIG_PHYS_ADDR_T_64BIT
#define AMD_141b_MMIO_BASE(x) (0x80 + (x) * 0x8)
--
2.20.1
In VRR mode, keep track of the vblank count of the last
completed pageflip in amdgpu_crtc->last_flip_vblank, as
recorded in the pageflip completion handler after each
completed flip.
Use that count to prevent mmio programming a new pageflip
within the same vblank in which the last pageflip completed,
iow. to throttle pageflips to at most one flip per video
frame, while at the same time allowing to request a flip
not only before start of vblank, but also anywhere within
vblank.
The old logic did the same, and made sense for regular fixed
refresh rate flipping, but in vrr mode it prevents requesting
a flip anywhere inside the possibly huge vblank, thereby
reducing framerate in vrr mode instead of improving it, by
delaying a slightly delayed flip requests up to a maximum
vblank duration + 1 scanout duration. This would limit VRR
usefulness to only help applications with a very high GPU
demand, which can submit the flip request before start of
vblank, but then have to wait long for fences to complete.
With this method a flip can be both requested and - after
fences have completed - executed, ie. it doesn't matter if
the request (amdgpu_dm_do_flip()) gets delayed until deep
into the extended vblank due to cpu execution delays. This
also allows clients which want to regulate framerate within
the vrr range a much more fine-grained control of flip timing,
a feature that might be useful for video playback, and is
very useful for neuroscience/vision research applications.
In regular non-VRR mode, retain the old flip submission
behavior. This to keep flip scheduling for fullscreen X11/GLX
OpenGL clients intact, if they use the GLX_OML_sync_control
extensions glXSwapBufferMscOML(, ..., target_msc,...) function
with a specific target_msc target vblank count.
glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will
not flip at the proper target_msc for a non-zero target_msc
if VRR mode is active with this patch. They'd often flip one
frame too early. However, this limitation should not matter
much in VRR mode, as scheduling based on vblank counts is
pretty futile/unusable under variable refresh duration
anyway, so no real extra harm is done.
According to some testing already done with this patch by
Nicholas on top of my tests, IGT tests didn't report any
problems. If fixes stuttering and flickering when flipping
at rates below the minimum vrr refresh rate.
Fixes: bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR
properties")
Signed-off-by: Mario Kleiner <mario.kleiner.de(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com>
Cc: Harry Wentland <harry.wentland(a)amd.com>
Cc: Alex Deucher <alexander.deucher(a)amd.com>
Cc: Michel Dänzer <michel(a)daenzer.net>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 +
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 ++++++++++++++++---
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index bfa394ffd6d2..87ca5746f861 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -411,6 +411,7 @@ struct amdgpu_crtc {
struct amdgpu_flip_work *pflip_works;
enum amdgpu_flip_status pflip_status;
int deferred_flip_completion;
+ u64 last_flip_vblank;
/* pll sharing */
struct amdgpu_atom_ss ss;
bool ss_enabled;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index d59bafc84475..d4da331aa349 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -303,12 +303,11 @@ static void dm_pflip_high_irq(void *interrupt_params)
return;
}
+ /* Update to correct count(s) if racing with vblank irq */
+ amdgpu_crtc->last_flip_vblank = drm_crtc_accurate_vblank_count(&amdgpu_crtc->base);
/* wake up userspace */
if (amdgpu_crtc->event) {
- /* Update to correct count(s) if racing with vblank irq */
- drm_crtc_accurate_vblank_count(&amdgpu_crtc->base);
-
drm_crtc_send_vblank_event(&amdgpu_crtc->base, amdgpu_crtc->event);
/* page flip completed. clean up */
@@ -4736,6 +4735,8 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
struct amdgpu_bo *abo;
uint64_t tiling_flags, dcc_address;
uint32_t target, target_vblank;
+ uint64_t last_flip_vblank;
+ bool vrr_active = acrtc_state->freesync_config.state == VRR_STATE_ACTIVE_VARIABLE;
struct {
struct dc_surface_update surface_updates[MAX_SURFACES];
@@ -4889,7 +4890,31 @@ static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
* hopefully eliminating dc_*_update structs in their entirety.
*/
if (flip_count) {
- target = (uint32_t)drm_crtc_vblank_count(pcrtc) + *wait_for_vblank;
+ if (!vrr_active) {
+ /* Use old throttling in non-vrr fixed refresh rate mode
+ * to keep flip scheduling based on target vblank counts
+ * working in a backwards compatible way, e.g., for
+ * clients using the GLX_OML_sync_control extension or
+ * DRI3/Present extension with defined target_msc.
+ */
+ last_flip_vblank = drm_crtc_vblank_count(pcrtc);
+ }
+ else {
+ /* For variable refresh rate mode only:
+ * Get vblank of last completed flip to avoid > 1 vrr
+ * flips per video frame by use of throttling, but allow
+ * flip programming anywhere in the possibly large
+ * variable vrr vblank interval for fine-grained flip
+ * timing control and more opportunity to avoid stutter
+ * on late submission of flips.
+ */
+ spin_lock_irqsave(&pcrtc->dev->event_lock, flags);
+ last_flip_vblank = acrtc_attach->last_flip_vblank;
+ spin_unlock_irqrestore(&pcrtc->dev->event_lock, flags);
+ }
+
+ target = (uint32_t)last_flip_vblank + *wait_for_vblank;
+
/* Prepare wait for target vblank early - before the fence-waits */
target_vblank = target - (uint32_t)drm_crtc_vblank_count(pcrtc) +
amdgpu_get_vblank_counter_kms(pcrtc->dev, acrtc_attach->crtc_id);
--
2.17.1
From: Peter Zijlstra <peterz(a)infradead.org>
intel_pmu_cpu_prepare() allocated memory for ->shared_regs among other
members of struct cpu_hw_events. This memory is released in
intel_pmu_cpu_dying() which is wrong. The counterpart of the
intel_pmu_cpu_prepare() callback is x86_pmu_dead_cpu().
Otherwise if the CPU fails on the UP path between CPUHP_PERF_X86_PREPARE
and CPUHP_AP_PERF_X86_STARTING then it won't release the memory but
allocate new memory on the next attempt to online the CPU (leaking the
old memory).
Also, if the CPU down path fails between CPUHP_AP_PERF_X86_STARTING and
CPUHP_PERF_X86_PREPARE then the CPU will go back online but never
allocate the memory that was released in x86_pmu_dying_cpu().
Make the memory allocation/free symmetrical in regard to the CPU hotplug
notifier by moving the deallocation to intel_pmu_cpu_dead().
This started in commit:
a7e3ed1e47011 ("perf: Add support for supplementary event registers").
In principle the bug was introduced in v2.6.39 (!), but it will almost
certainly not backport cleanly across the big CPU hotplug rewrite between v4.7-v4.15...
[ bigeasy: Added patch description. ]
[ mingo: Added backporting guidance. ]
Reported-by: He Zhe <zhe.he(a)windriver.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> # With developer hat on
Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> # With maintainer hat on
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: acme(a)kernel.org
Cc: bp(a)alien8.de
Cc: hpa(a)zytor.com
Cc: jolsa(a)kernel.org
Cc: kan.liang(a)linux.intel.com
Cc: namhyung(a)kernel.org
Cc: <stable(a)vger.kernel.org>
Fixes: a7e3ed1e47011 ("perf: Add support for supplementary event registers").
Link: https://lkml.kernel.org/r/20181219165350.6s3jvyxbibpvlhtq@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
[ He Zhe: Fixes conflict caused by missing disable_counter_freeze which is
introduced since v4.20 af3bdb991a5cb. ]
Signed-off-by: He Zhe <zhe.he(a)windriver.com>
---
This backport is for v4.9. The original commit id is 602cae04c4864.
arch/x86/events/intel/core.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 4f85607..f600ab6 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3235,6 +3235,11 @@ static void free_excl_cntrs(int cpu)
static void intel_pmu_cpu_dying(int cpu)
{
+ fini_debug_store_on_cpu(cpu);
+}
+
+static void intel_pmu_cpu_dead(int cpu)
+{
struct cpu_hw_events *cpuc = &per_cpu(cpu_hw_events, cpu);
struct intel_shared_regs *pc;
@@ -3246,8 +3251,6 @@ static void intel_pmu_cpu_dying(int cpu)
}
free_excl_cntrs(cpu);
-
- fini_debug_store_on_cpu(cpu);
}
static void intel_pmu_sched_task(struct perf_event_context *ctx,
@@ -3324,6 +3327,7 @@ static __initconst const struct x86_pmu core_pmu = {
.cpu_prepare = intel_pmu_cpu_prepare,
.cpu_starting = intel_pmu_cpu_starting,
.cpu_dying = intel_pmu_cpu_dying,
+ .cpu_dead = intel_pmu_cpu_dead,
};
static __initconst const struct x86_pmu intel_pmu = {
@@ -3359,6 +3363,8 @@ static __initconst const struct x86_pmu intel_pmu = {
.cpu_prepare = intel_pmu_cpu_prepare,
.cpu_starting = intel_pmu_cpu_starting,
.cpu_dying = intel_pmu_cpu_dying,
+ .cpu_dead = intel_pmu_cpu_dead,
+
.guest_get_msrs = intel_guest_get_msrs,
.sched_task = intel_pmu_sched_task,
};
--
2.7.4
From: Peter Zijlstra <peterz(a)infradead.org>
intel_pmu_cpu_prepare() allocated memory for ->shared_regs among other
members of struct cpu_hw_events. This memory is released in
intel_pmu_cpu_dying() which is wrong. The counterpart of the
intel_pmu_cpu_prepare() callback is x86_pmu_dead_cpu().
Otherwise if the CPU fails on the UP path between CPUHP_PERF_X86_PREPARE
and CPUHP_AP_PERF_X86_STARTING then it won't release the memory but
allocate new memory on the next attempt to online the CPU (leaking the
old memory).
Also, if the CPU down path fails between CPUHP_AP_PERF_X86_STARTING and
CPUHP_PERF_X86_PREPARE then the CPU will go back online but never
allocate the memory that was released in x86_pmu_dying_cpu().
Make the memory allocation/free symmetrical in regard to the CPU hotplug
notifier by moving the deallocation to intel_pmu_cpu_dead().
This started in commit:
a7e3ed1e47011 ("perf: Add support for supplementary event registers").
In principle the bug was introduced in v2.6.39 (!), but it will almost
certainly not backport cleanly across the big CPU hotplug rewrite between v4.7-v4.15...
[ bigeasy: Added patch description. ]
[ mingo: Added backporting guidance. ]
Reported-by: He Zhe <zhe.he(a)windriver.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> # With developer hat on
Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> # With maintainer hat on
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: acme(a)kernel.org
Cc: bp(a)alien8.de
Cc: hpa(a)zytor.com
Cc: jolsa(a)kernel.org
Cc: kan.liang(a)linux.intel.com
Cc: namhyung(a)kernel.org
Cc: <stable(a)vger.kernel.org>
Fixes: a7e3ed1e47011 ("perf: Add support for supplementary event registers").
Link: https://lkml.kernel.org/r/20181219165350.6s3jvyxbibpvlhtq@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
[ He Zhe: Fixes conflict caused by missing disable_counter_freeze which is
introduced since v4.20 af3bdb991a5cb. ]
Signed-off-by: He Zhe <zhe.he(a)windriver.com>
---
This backport is for v4.19 and v4.14. The original commit id is 602cae04c4864.
arch/x86/events/intel/core.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 155fa4b..d0b1862 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3440,6 +3440,11 @@ static void free_excl_cntrs(int cpu)
static void intel_pmu_cpu_dying(int cpu)
{
+ fini_debug_store_on_cpu(cpu);
+}
+
+static void intel_pmu_cpu_dead(int cpu)
+{
struct cpu_hw_events *cpuc = &per_cpu(cpu_hw_events, cpu);
struct intel_shared_regs *pc;
@@ -3451,8 +3456,6 @@ static void intel_pmu_cpu_dying(int cpu)
}
free_excl_cntrs(cpu);
-
- fini_debug_store_on_cpu(cpu);
}
static void intel_pmu_sched_task(struct perf_event_context *ctx,
@@ -3541,6 +3544,7 @@ static __initconst const struct x86_pmu core_pmu = {
.cpu_prepare = intel_pmu_cpu_prepare,
.cpu_starting = intel_pmu_cpu_starting,
.cpu_dying = intel_pmu_cpu_dying,
+ .cpu_dead = intel_pmu_cpu_dead,
};
static struct attribute *intel_pmu_attrs[];
@@ -3581,6 +3585,8 @@ static __initconst const struct x86_pmu intel_pmu = {
.cpu_prepare = intel_pmu_cpu_prepare,
.cpu_starting = intel_pmu_cpu_starting,
.cpu_dying = intel_pmu_cpu_dying,
+ .cpu_dead = intel_pmu_cpu_dead,
+
.guest_get_msrs = intel_guest_get_msrs,
.sched_task = intel_pmu_sched_task,
};
--
2.7.4
Hello stablers,
With the following revert being backported to stable:
a9c859033f6ec Revert "usb: gadget: ffs: Fix BUG when userland exits
with submitted AIO transfers"
The original bug it fixed is back. I wonder if we should be
backporting the series that seems to quietly fix that issue:
fec9095bdef4e usb: dwc3: gadget: remove wait_end_transfer
d4f1afe5e896c usb: dwc3: gadget: move requests to cancelled_list
d5443bbf5fc8f usb: dwc3: gadget: introduce cancelled_list
7746a8dfb3f9c usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs()
c3acd59014148 usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue()
09fe1f8d7e2f4 usb: dwc3: gadget: track number of TRBs per request
1a22ec6435806 usb: dwc3: gadget: combine unaligned and zero flags
(Patch 1/8 of the original series was already backported). I know we
saw this with 4.19, I'm not sure which other versions it would go
into.
I'll re-paste the stack from the original commit that got reverted. I
can easily reproduce this by connecting a host when our device is in
gadget mode, then attempting to gracefully reboot the system:
[ 382.200896] BUG: scheduling while atomic: screen/1808/0x00000100
[ 382.207124] 4 locks held by screen/1808:
[ 382.211266] #0: (rcu_callback){....}, at: [<c10b4ff0>]
rcu_process_callbacks+0x260/0x440
[ 382.219949] #1: (rcu_read_lock_sched){....}, at: [<c1358ba0>]
percpu_ref_switch_to_atomic_rcu+0xb0/0x130
[ 382.230034] #2: (&(&ctx->ctx_lock)->rlock){....}, at:
[<c11f0c73>] free_ioctx_users+0x23/0xd0
[ 382.230096] #3: (&(&ffs->eps_lock)->rlock){....}, at:
[<f81e7710>] ffs_aio_cancel+0x20/0x60 [usb_f_fs]
[ 382.230160] Modules linked in: usb_f_fs libcomposite configfs bnep
btsdio bluetooth ecdh_generic brcmfmac brcmutil intel_powerclamp
coretemp dwc3 kvm_intel ulpi udc_core kvm irqbypass crc32_pclmul
crc32c_intel pcbc dwc3_pci aesni_intel aes_i586 crypto_simd cryptd
ehci_pci ehci_hcd gpio_keys usbcore basincove_gpadc industrialio
usb_common
[ 382.230407] CPU: 1 PID: 1808 Comm: screen Not tainted 4.14.0-edison+ #117
[ 382.230416] Hardware name: Intel Corporation Merrifield/BODEGA BAY,
BIOS 542 2015.01.21:18.19.48
[ 382.230425] Call Trace:
[ 382.230438] <SOFTIRQ>
[ 382.230466] dump_stack+0x47/0x62
[ 382.230498] __schedule_bug+0x61/0x80
[ 382.230522] __schedule+0x43/0x7a0
[ 382.230587] schedule+0x5f/0x70
[ 382.230625] dwc3_gadget_ep_dequeue+0x14c/0x270 [dwc3]
[ 382.230669] ? do_wait_intr_irq+0x70/0x70
[ 382.230724] usb_ep_dequeue+0x19/0x90 [udc_core]
[ 382.230770] ffs_aio_cancel+0x37/0x60 [usb_f_fs]
[ 382.230798] kiocb_cancel+0x31/0x40
[ 382.230822] free_ioctx_users+0x4d/0xd0
[ 382.230858] percpu_ref_switch_to_atomic_rcu+0x10a/0x130
[ 382.230881] ? percpu_ref_exit+0x40/0x40
[ 382.230904] rcu_process_callbacks+0x2b3/0x440
[ 382.230965] __do_softirq+0xf8/0x26b
[ 382.231011] ? __softirqentry_text_start+0x8/0x8
[ 382.231033] do_softirq_own_stack+0x22/0x30
[ 382.231042] </SOFTIRQ>
[ 382.231071] irq_exit+0x45/0xc0
[ 382.231089] smp_apic_timer_interrupt+0x13c/0x150
[ 382.231118] apic_timer_interrupt+0x35/0x3c
Felipe/others, any thoughts about this?
-Evan
Hi,
I hit use-after-free issues in UIO in 4.14.x, and discovered that it's
already fixed in later kernel versions:
commit a93e7b331568227500186a465fee3c2cb5dffd1f
Author: Hamish Martin <hamish.martin(a)alliedtelesis.co.nz>
Date: Mon May 14 13:32:23 2018 +1200
uio: Prevent device destruction while fds are open
Can we have this in 4.14.y?
(good idea to older LTS kernels too)
I picked and tested the following commits in 4.14.x:
# Temporarily revert "uio: Fix an Oops on load",
# to avoid merge conflict later with "uio: use
# request_threaded_irq instead"
git revert f6a6ae4e0f345aa481535bfe2046cd33f4dc37b8
# "uio: Reduce return paths from uio_write()"
git cherry-pick 81daa406c2cc97d85eef9409400404efc2a3f756
# "uio: Prevent device destruction while fds are open"
# Also amend this, change __poll_t to plain unsigned int,
# the former not found in 4.14.
git cherry-pick a93e7b331568227500186a465fee3c2cb5dffd1f
sed -i "s/__poll_t/unsigned int/" drivers/uio/uio.c
git commit --amend drivers/uio/uio.c
# "uio: use request_threaded_irq instead"
git cherry-pick 9421e45f5ff3d558cf8b75a8cc0824530caf3453
# "uio: change to use the mutex lock instead of the spin lock"
# Resolve conflict due to __poll_t in patch context.
git cherry-pick 543af5861f41af0a5d2432f6fb5976af50f9cee5
sed -i -e '/<<<<<<</,/=======/d' -e '/>>>>>>>/d' \
-e 's/__poll_t/unsigned int/' drivers/uio/uio.c
git add drivers/uio/uio.c
git cherry-pick --continue
# uio: fix crash after the device is unregistered
git cherry-pick 57c5f4df0a5a0ee83df799991251e2ee93a5e4e9
# uio: fix wrong return value from uio_mmap()
git cherry-pick e7de2590f18a272e63732b9d519250d1b522b2c4
# uio: fix possible circular locking dependency
git cherry-pick b34e9a15b37b8ddbf06a4da142b0c39c74211eb4
# Revert "uio: use request_threaded_irq instead"
git cherry-pick 3d27c4de8d4fb2d4099ff324671792aa2578c6f9
# re-apply: uio: Fix an Oops on load
git cherry-pick 432798195bbce1f8cd33d1c0284d0538835e25fb
-Tommi