| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
commit 10ff4c5239a137abfc896ec73ef3d15a0f86a16a upstream.
The exynos5 I2C controller driver always prepares and enables a clock
before using it and then disables unprepares it when the clock is not
used anymore.
But this can cause a possible ABBA deadlock in some scenarios since a
driver that uses regmap to access its I2C registers, will first grab
the regmap lock and then the I2C xfer function will grab the prepare
lock when preparing the I2C clock. But since the clock driver also
uses regmap for I2C accesses, preparing a clock will first grab the
prepare lock and then the regmap lock when using the regmap API.
An example of this happens on the Exynos5422 Odroid XU4 board where a
s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
share the same I2C regmap.
The possible deadlock is reported by the kernel lockdep:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sec_core:428:(regmap)->lock);
lock(prepare_lock);
lock(sec_core:428:(regmap)->lock);
lock(prepare_lock);
*** DEADLOCK ***
Fix it by leaving the code prepared on probe and use {en,dis}able in
the I2C transfer function.
This patch is similar to commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA
deadlock by keeping clock prepared") that fixes the same bug in other
driver for an I2C controller found in Samsung SoCs.
Reported-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 609d5a1b2b35bb62b4b3750396e55453160c2a17 upstream.
Since commit ea8daa7b9784 ("kbuild: Add option to turn incompatible
pointer check into error"), assignments from an incompatible pointer
types have become a hard error, eg:
drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of
'dma_alloc_coherent' from incompatible pointer type
Fix the build break by converting txdma & rxdma to dma_addr_t.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: ea8daa7b9784
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 31318a922395ec9e78d6e2ddf70779355afc7594 upstream.
HSW still has the wake FIFO, so let's check it.
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Deepak S <deepak.s@linux.intel.com>
Fixes: 05a2fb157e44 ("drm/i915: Consolidate forcewake code")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1460633942-24013-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
(cherry picked from commit 3d7d0c85e41afb5a05e98b3a8a72c38357f02594)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d43f3ebf12f59c57782ec652da65ef61c2662b40 upstream.
Currently for the case where there is enough space at the end of Ring
buffer for accommodating only the base request, the wrapround is done
immediately and as a result the base request gets added at the start
of Ring buffer. But there may not be enough free space at the beginning
to accommodate the base request, as before the wraparound, the wait was
effectively done for the reserved_size free space from the start of
Ring buffer. In such a case there is a potential of Ring buffer overflow,
the instructions at the head of Ring (ACTHD) can get overwritten.
Since the base request can fit in the remaining space, there is no need
to wraparound immediately. The wraparound will anyway happen later when
the reserved part starts getting used.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1457688402-10411-1-git-send-email-akash.goel@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 782f6bc0aba037436d6a04d19b23f8b61020a576)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 93fce954427effee89e44a976299b15dd75b4bbc upstream.
At the end of the function we expect "status" to be zero, but it's
either -EINVAL or uninitialized.
Fixes: 788bf83db301 ('drm/amdkfd: Add wave control operation to debugger')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fa5a7970d372c9c9beb3a0ce79ee1d0c23387d0a upstream.
Pass BIT(DRM_ROTATE_0) instead of DRM_ROTATE_0 to skl_update_scaler().
The former is a mask, the latter just the bit number.
Fortunately the only thing skl_update_scaler() does with the rotation
is check if it's 90/270 degrees or not, and so in this case it would
still do the right thing.
Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444917718-28495-1-git-send-email-ville.syrjala@linux.intel.com
Fixes: 6156a45602f9 ("drm/i915: skylake primary plane scaling using shared scalers")
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7d3fdfff23852fe458a0d0979a3555fe60f1e563 upstream.
Restore the lost phys status page cleanup.
Fixes the following splat with DMA_API_DEBUG=y:
WARNING: CPU: 0 PID: 21615 at ../lib/dma-debug.c:974 dma_debug_device_change+0x190/0x1f0()
pci 0000:00:02.0: DMA-API: device driver has pending DMA allocations while released from device [count=1]
One of leaked entries details: [device address=0x0000000023163000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]
Modules linked in: i915(-) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm sha256_generic hmac drbg ctr ccm sch_fq_codel binfmt_misc joydev mousedev arc4 ath5k iTCO_wdt mac80211 smsc_ircc2 ath snd_intel8x0m snd_intel8x0 snd_ac97_codec ac97_bus psmouse snd_pcm input_leds i2c_i801 pcspkr snd_timer cfg80211 snd soundcore i2c_core ehci_pci firewire_ohci ehci_hcd firewire_core lpc_ich 8139too rfkill crc_itu_t mfd_core mii usbcore rng_core intel_agp intel_gtt usb_common agpgart irda crc_ccitt fujitsu_laptop led_class parport_pc video parport evdev backlight
CPU: 0 PID: 21615 Comm: rmmod Tainted: G U 4.4.0-rc4-mgm-ovl+ #4
Hardware name: FUJITSU SIEMENS LIFEBOOK S6120/FJNB16C, BIOS Version 1.26 05/10/2004
e31a3de0 e31a3de0 e31a3d9c c128d4bd e31a3dd0 c1045a0c c15e00c4 e31a3dfc
0000546f c15dfad2 000003ce c12b3740 000003ce c12b3740 00000000 00000001
f61fb8a0 e31a3de8 c1045a83 00000009 e31a3de0 c15e00c4 e31a3dfc e31a3e4c
Call Trace:
[<c128d4bd>] dump_stack+0x16/0x19
[<c1045a0c>] warn_slowpath_common+0x8c/0xd0
[<c12b3740>] ? dma_debug_device_change+0x190/0x1f0
[<c12b3740>] ? dma_debug_device_change+0x190/0x1f0
[<c1045a83>] warn_slowpath_fmt+0x33/0x40
[<c12b3740>] dma_debug_device_change+0x190/0x1f0
[<c1065499>] notifier_call_chain+0x59/0x70
[<c10655af>] __blocking_notifier_call_chain+0x3f/0x80
[<c106560f>] blocking_notifier_call_chain+0x1f/0x30
[<c134cfb3>] __device_release_driver+0xc3/0xf0
[<c134d0d7>] driver_detach+0x97/0xa0
[<c134c440>] bus_remove_driver+0x40/0x90
[<c134db18>] driver_unregister+0x28/0x60
[<c1079e8c>] ? trace_hardirqs_on_caller+0x12c/0x1d0
[<c12c0618>] pci_unregister_driver+0x18/0x80
[<f83e96e7>] drm_pci_exit+0x87/0xb0 [drm]
[<f8b3be2d>] i915_exit+0x1b/0x1ee [i915]
[<c10b999c>] SyS_delete_module+0x14c/0x210
[<c1079e8c>] ? trace_hardirqs_on_caller+0x12c/0x1d0
[<c115a9bd>] ? ____fput+0xd/0x10
[<c1002014>] do_fast_syscall_32+0xa4/0x450
[<c149f6fa>] sysenter_past_esp+0x3b/0x5d
---[ end trace c2ecbc77760f10a0 ]---
Mapped at:
[<c12b3183>] debug_dma_alloc_coherent+0x33/0x90
[<f83e989c>] drm_pci_alloc+0x18c/0x1e0 [drm]
[<f8acd59f>] intel_init_ring_buffer+0x2af/0x490 [i915]
[<f8acd8b0>] intel_init_render_ring_buffer+0x130/0x750 [i915]
[<f8aaea4e>] i915_gem_init_rings+0x1e/0x110 [i915]
v2: s/BUG_ON/WARN_ON/ since dim doens't like the former anymore
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 5c6c600 ("drm/i915: Remove DRI1 ring accessors and API")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1452538112-5331-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c5857e3f94ab2719dfac649a146cb5dd6f21fcf3 upstream.
The change fixes potential oops while accessing iomem on invalid address
if devm_ioremap_resource() fails due to some reason.
The devm_ioremap_resource() function returns ERR_PTR() and never returns
NULL, which makes useless a following check for NULL.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Fixes: 3a9f5957020f ("pwm: Add Broadcom BCM7038 PWM controller support")
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 263efde31f97c498e1ebad30e4d2906609d7ad6b upstream.
We can thank KASAN for finding this, otherwise I probably would have spent
hours on it. This fixes a somewhat harder to trigger kernel panic, occuring
while enabling MST where the port we were currently updating the payload on
would have all of it's refs dropped before we finished what we were doing:
==================================================================
BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018
Read of size 4 by task Xorg/973
=============================================================================
BUG kmalloc-2048 (Tainted: G B W ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175
___slab_alloc+0x472/0x490
__slab_alloc+0x20/0x40
kmem_cache_alloc_trace+0x151/0x190
drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper]
drm_dp_send_link_address+0x526/0x960 [drm_kms_helper]
drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper]
drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper]
process_one_work+0x562/0x1350
worker_thread+0xd9/0x1390
kthread+0x1c5/0x260
ret_from_fork+0x22/0x40
INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175
__slab_free+0x17f/0x2d0
kfree+0x169/0x180
drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper]
drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper]
process_one_work+0x562/0x1350
worker_thread+0xd9/0x1390
kthread+0x1c5/0x260
ret_from_fork+0x22/0x40
which on this T460s, would eventually lead to kernel panics in somewhat
random places later in intel_mst_enable_dp() if we got lucky enough.
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9dc0487d96a0396367a1451b31873482080b527f upstream.
Some hubs are forgetful, and end up forgetting whatever GUID we set
previously after we do a suspend/resume cycle. This can lead to
hotplugging breaking (along with probably other things) since the hub
will start sending connection notifications with the wrong GUID. As
such, we need to check on resume whether or not the GUID the hub is
giving us is valid.
Signed-off-by: Lyude <cpaul@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit deba0a2af9592b2022a0bce7b085a318b53ce1db upstream.
With the joys of things running concurrently, there's always a chance
that the port we get passed in drm_dp_payload_send_msg() isn't actually
valid anymore. Because of this, we need to make sure we validate the
reference to the port before we use it otherwise we risk running into
various race conditions. For instance, on the Dell MST monitor I have
here for testing, hotplugging it enough times causes us to kernel panic:
[drm:intel_mst_enable_dp] 1
[drm:drm_dp_update_payload_part2] payload 0 1
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x10101011, pins 0x00000020
[drm:intel_hpd_irq_handler] digital hpd port B - short
[drm:intel_dp_hpd_pulse] got hpd irq on port B - short
[drm:intel_dp_check_mst_status] got esi 00 10 00
[drm:drm_dp_update_payload_part2] payload 1 1
general protection fault: 0000 [#1] SMP
…
Call Trace:
[<ffffffffa012b632>] drm_dp_update_payload_part2+0xc2/0x130 [drm_kms_helper]
[<ffffffffa032ef08>] intel_mst_enable_dp+0xf8/0x180 [i915]
[<ffffffffa0310dbd>] haswell_crtc_enable+0x3ed/0x8c0 [i915]
[<ffffffffa030c84d>] intel_atomic_commit+0x5ad/0x1590 [i915]
[<ffffffffa01db877>] ? drm_atomic_set_crtc_for_connector+0x57/0xe0 [drm]
[<ffffffffa01dc4e7>] drm_atomic_commit+0x37/0x60 [drm]
[<ffffffffa0130a3a>] drm_atomic_helper_set_config+0x7a/0xb0 [drm_kms_helper]
[<ffffffffa01cc482>] drm_mode_set_config_internal+0x62/0x100 [drm]
[<ffffffffa01d02ad>] drm_mode_setcrtc+0x3cd/0x4e0 [drm]
[<ffffffffa01c18e3>] drm_ioctl+0x143/0x510 [drm]
[<ffffffffa01cfee0>] ? drm_mode_setplane+0x1b0/0x1b0 [drm]
[<ffffffff810f79a7>] ? hrtimer_start_range_ns+0x1b7/0x3a0
[<ffffffff81212962>] do_vfs_ioctl+0x92/0x570
[<ffffffff81590852>] ? __sys_recvmsg+0x42/0x80
[<ffffffff81212eb9>] SyS_ioctl+0x79/0x90
[<ffffffff816b4e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
RIP [<ffffffffa012b026>] drm_dp_payload_send_msg+0x146/0x1f0 [drm_kms_helper]
Which occurs because of the hotplug event shown in the log, which ends
up causing DRM's dp helpers to drop the port we're updating the payload
on and panic.
Signed-off-by: Lyude <cpaul@redhat.com>
Reviewed-by: David Airlie <airlied@linux.ie>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 28dca90533750c7e31e8641c3df426bad9c12941 upstream.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5d5b7803c49bbb01bdf4c6e95e8314d0515b9484 upstream.
When crtc/timing is disabled on boot the dig block
should be stopped in order ignore timing from crtc,
reset the steering fifo otherwise we get display
corruption or hung in dp sst mode.
v2: agd: fix coding style
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b5dcec693f87cb8475f2291c0075b2422addd3d6 upstream.
Allowing userptr bo which are basicly a list of page from some vma
(so either anonymous page or file backed page) would lead to serious
corruption of kernel structures and counters (because we overwrite
the page->mapping field when mapping buffer).
This will already block if the buffer was populated before anyone does
try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the
ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm
vm fault handler.
So to be safe just add a check to verify_access() callback.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7403c515c49c033fec33df0814fffdc977e6acdc upstream.
This got lost somewhere along the way. This fixes
audio not working until set_property was called.
Noticed-by: Hyungwon Hwang <hyungwon.hwang7@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bcb31eba4a4ea356fd61cbd5dec5511c3883f57e upstream.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This fix was written against drm-next, but when it was
backported to 4.5 as a stable fix, the driver internal
structure change was missed. Fix that up here to avoid
a hang due to waiting for the wrong sequence number.
v2: agd: fix up commit message
Signed-off-by: Grigori Goronzy <greg@chown.ath.cx>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
commit 562e2689baebaa2ac25b7ec934385480ed1cb7d6 upstream.
Was previously always hardcoded to 0.
Signed-off-by: Sonny Jiang <sonny.jiang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 83c5cda2ccf40a7a7e4bb674321509b346e23d5a upstream.
Fixes array overflow on these chips.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3ea25f858fd5aeee888059952bbb8e910541eebb upstream.
Prerequiste for the next patch which ups the limits.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 85cc88f02eb0ecf44493c1b2ebb6f206cd5fc321 upstream.
fix the issue that when resume back, uvd/vce
dpm was disabled and uvd/vce's performace
dropped.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 07b48ac4bbe527e68cfc555f2b2b206908437141 upstream.
With the change to stashing just the IOVA-page-aligned remainder of the
CPU-page offset rather than the whole thing, the failure path in
__invalidate_sg() also needs tweaking to account for that in the case of
differing page sizes where the two offsets may not be equivalent.
Similarly in __finalise_sg(), lest the architecture-specific wrappers
later get the wrong address for cache maintenance on sync or unmap.
Fixes: 164afb1d85b8 ("iommu/dma: Use correct offset in map_sg")
Reported-by: Magnus Damm <damm+renesas@opensource.se>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e3156048346c28c695f5cf9db67a8cf88c90f947 upstream.
Commit 61289cb ('iommu/amd: Remove old alias handling code')
removed the old alias handling code from the AMD IOMMU
driver because this is now handled by the IOMMU core code.
But this also removed the handling of PCI aliases, which is
not handled by the core code. This caused issues with PCI
devices that have hidden PCIe-to-PCI bridges that rewrite
the request-id.
Fix this bug by re-introducing some of the removed functions
from commit 61289cbaf6c8 and add a alias field
'struct iommu_dev_data'. This field carrys the return value
of the get_alias() function and uses that instead of the
amd_iommu_alias_table[] array in the code.
Fixes: 61289cbaf6c8 ('iommu/amd: Remove old alias handling code')
Tested-by: Tomasz Golinski <tomaszg@math.uwb.edu.pl>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 56b367c0cd67d4c3006738e7dc9dda9273fd2bfe upstream.
pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices
ranging from 1 to MAX. This leads to a corner case where we try to request
the pin number = MAX and fails.
bit_pos value is being calculted using ffs. pin_num_from_lsb uses
bit_pos value. pins array is populated with:
pin + pin_num_from_lsb.
The above is 1 more than usual bit indices as bit_pos uses ffs to compute
first set bit. Hence the last of the pins array is populated with the MAX
value and not MAX - 1 which causes error when we call pin_request.
mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1))
Consequently val_pos and submask are correct.
Hence use __ffs which gives (ffs(x) - 1) as the first bit set.
fixes: 4e7e8017a8 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules")
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5fedbb923936174ab4d1d5cc92bca1cf6b2e0ca2 upstream.
The debounce time unit for gpio_chip.set_debounce is us but
mtk_gpio_set_debounce regard it as ms.
Fix this by correct debounce time array dbnc_arr so it can find correct
debounce setting. Debounce time for first debounce setting is 500us,
correct this as well.
While I'm at it, also change the debounce time array name to
"debounce_time" for readability.
Signed-off-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 13aa38e291bdd4e4018f40dd2f75e464814dcbf3 upstream.
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: David Vrabel <david.vrabel@citrix.com>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit eda5ecc0a6b865561997e177c393f0b0136fe3b7 upstream.
The trigger delay algorithm that converts from microseconds to
the register value looks incorrect. According to most of the PMIC
documentation, the equation is
delay (Seconds) = (1 / 1024) * 2 ^ (x + 4)
except for one case where the documentation looks to have a
formatting issue and the equation looks like
delay (Seconds) = (1 / 1024) * 2 x + 4
Most likely this driver was written with the improper
documentation to begin with. According to the downstream sources
the valid delays are from 2 seconds to 1/64 second, and the
latter equation just doesn't make sense for that. Let's fix the
algorithm and the range check to match the documentation and the
downstream sources.
Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes: 92d57a73e410 ("input: Add support for Qualcomm PMIC8XXX power key")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 162f98dea487206d9ab79fc12ed64700667a894d upstream.
The gtco driver expects at least one valid endpoint. If given malicious
descriptors that specify 0 for the number of endpoints, it will crash in
the probe function. Ensure there is at least one endpoint on the interface
before using it.
Also let's fix a minor coding style issue.
The full correct report of this issue can be found in the public
Red Hat Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1283385
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 340ff60ae93a5db2b2be6f38868df9a1293b6007 upstream.
After conversion to new AEAD interface, tcrypt tests fail as follows:
[...]
[ 1.145414] alg: aead: Test 1 failed on encryption for authenc-hmac-sha1-cbc-aes-talitos
[ 1.153564] 00000000: 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
[ 1.160041] 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 1.166509] 00000020: 00 00 00 00
[...]
Fix them by providing the correct cipher in & cipher out pointers,
i.e. must skip over associated data in src and dst S/G.
While here, fix a problem with the HW S/G table index usage:
tbl_off must be updated after the pointer to the table entries is set.
Fixes: aeb4c132f33d ("crypto: talitos - Convert to new AEAD interface")
Reported-by: Jonas Eymann <J.Eymann@gmx.net>
Signed-off-by: Horia Geant? <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 89d124cb61b39900959e2839ac06b6339b6a54cb upstream.
Conversion of talitos driver to the new AEAD interface
hasn't been properly tested.
AEAD algorithms crash in talitos_cra_init as follows:
[...]
[ 1.141095] talitos ffe30000.crypto: hwrng
[ 1.145381] Unable to handle kernel paging request for data at address 0x00000058
[ 1.152913] Faulting instruction address: 0xc02accc0
[ 1.157910] Oops: Kernel access of bad area, sig: 11 [#1]
[ 1.163315] SMP NR_CPUS=2 P1020 RDB
[ 1.166810] Modules linked in:
[ 1.169875] CPU: 0 PID: 1007 Comm: cryptomgr_test Not tainted 4.4.6 #1
[ 1.176415] task: db5ec200 ti: db4d6000 task.ti: db4d6000
[ 1.181821] NIP: c02accc0 LR: c02acd18 CTR: c02acd04
[ 1.186793] REGS: db4d7d30 TRAP: 0300 Not tainted (4.4.6)
[ 1.192457] MSR: 00029000 <CE,EE,ME> CR: 95009359 XER: e0000000
[ 1.198585] DEAR: 00000058 ESR: 00000000
GPR00: c017bdc0 db4d7de0 db5ec200 df424b48 00000000 00000000 df424bfc db75a600
GPR08: df424b48 00000000 db75a628 db4d6000 00000149 00000000 c0044cac db5acda0
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000400 df424940
GPR24: df424900 00003083 00000400 c0180000 db75a640 c03e9f84 df424b40 df424b48
[ 1.230978] NIP [c02accc0] talitos_cra_init+0x28/0x6c
[ 1.236039] LR [c02acd18] talitos_cra_init_aead+0x14/0x28
[ 1.241443] Call Trace:
[ 1.243894] [db4d7de0] [c03e9f84] 0xc03e9f84 (unreliable)
[ 1.249322] [db4d7df0] [c017bdc0] crypto_create_tfm+0x5c/0xf0
[ 1.255083] [db4d7e10] [c017beec] crypto_alloc_tfm+0x98/0xf8
[ 1.260769] [db4d7e40] [c0186a20] alg_test_aead+0x28/0xc8
[ 1.266181] [db4d7e60] [c0186718] alg_test+0x260/0x2e0
[ 1.271333] [db4d7ee0] [c0183860] cryptomgr_test+0x30/0x54
[ 1.276843] [db4d7ef0] [c0044d80] kthread+0xd4/0xd8
[ 1.281741] [db4d7f40] [c000e4a4] ret_from_kernel_thread+0x5c/0x64
[ 1.287930] Instruction dump:
[ 1.290902] 38600000 4e800020 81230028 7c681b78 81490010 38e9ffc0 3929ffe8 554a073e
[ 1.298691] 2b8a000a 7d474f9e 812a0008 91230030 <80e90058> 39270060 7c0004ac 7cc04828
Fixes: aeb4c132f33d ("crypto: talitos - Convert to new AEAD interface")
Signed-off-by: Jonas Eymann <J.Eymann@gmx.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix typo - replaced parameter of __crypto_ahash_alg(): s/tfm/alg
Remove checkpatch warnings.
Add commit message.
Signed-off-by: Horia Geant? <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
commit f709b45ec461b548c41a00044dba1f1b572783bf upstream.
Prevent information from leaking to userspace by doing a memset to 0 of
the export state structure before setting the structure values and copying
it. This prevents un-initialized padding areas from being copied into the
export area.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7fdf9663261cc77a516396fec82cee8a8ea07e76 upstream.
Currently paging download buffer is freed during the
the unloading of the opmode which happens when the driver
is unloaded.
This causes a memory leak since the paging download
buffer is allocated every time we enable the
interface, so the download buffer can be allocated many
times, but only be freed once.
Free paging download buffer during disabling of the
interface.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9fc515bc9e735c10cd327f05c20f5ef69474188d upstream.
IWL_INFO is not an error but still printed by default.
"can't access the RSA semaphore it is write protected" seems
worrisome but it is not really a problem.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1becf03545a0859ceaaf9e8c2d9861882a71cb01 upstream.
When the config TDP level is not nominal (level = 0), the MSR values for
reading level 1 and level 2 ratios contain power in low 14 bits and actual
ratio bits are at bits [23:16]. The current processing for level 1 and
level 2 is wrong as there is no shift done to get actual ratio.
Fixes: 6a35fc2d6c22 (cpufreq: intel_pstate: get P1 from TAR when available)
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e9bef455af8eb0e837e179aab8988ae2649fd8d3 upstream.
This reverts commit bedf2a65c1aa8fb29ba8527fd00c0f68ec1f55f1.
See the radeon revert for an extended description.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bfaddd9fc8ac048b99475f000dbef6f08297417f upstream.
This reverts commit e64c952efb8e0c15ae82cec8e455ab4910690ef1.
ATPX is the ACPI method for controlling AMD PowerXpress laptops.
There are flags to indicate which methods are supported. If
the dGPU power down flag is not supported, the driver needs to
implement the dGPU power down manually. We had previously
always forced the driver to assume the ATPX dGPU power down
was present, but this causes problems on boards where it is
not, leading to GPU hangs when attempting to power down the
dGPU. Manual dGPU power down is not currently supported in
the Linux driver. Some laptops indicate that the ATPX
dGPU power down method is not present, but it actually
apparently is. I'm not sure if this is a bios bug and it should
be set or if there is a reason it was unset and the method should
not be used. This is not an issue on other OSes since both the
ATPX and the manual driver power down methods are supported.
This is apparently fairly widespread, so just revert for now.
bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=115321
https://bugzilla.kernel.org/show_bug.cgi?id=116581
https://bugzilla.kernel.org/show_bug.cgi?id=116251
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9e60290dbafdf577766e5fc5f2fdb3be450cf9a6 upstream.
After unplugging a DP MST display from the system, we have to go through
and destroy all of the DRM connectors associated with it since none of
them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
doesn't do a good enough job of ensuring that throughout the destruction
process that no modesettings can be done with the connectors. As it is
right now, intel_dp_destroy_mst_connector() works like this:
* Take all modeset locks
* Clear the configuration of the crtc on the connector, if there is one
* Drop all modeset locks, this is required because of circular
dependency issues that arise with trying to remove the connector from
sysfs with modeset locks held
* Unregister the connector
* Take all modeset locks, again
* Do the rest of the required cleaning for destroying the connector
* Finally drop all modeset locks for good
This only works sometimes. During the destruction process, it's very
possible that a userspace application will attempt to do a modesetting
using the connector. When we drop the modeset locks, an ioctl handler
such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
locks from us. When this happens, one thing leads to another and
eventually we end up committing a mode with the non-existent connector:
[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
And in some cases, such as with the T460s using an MST dock, this
results in breaking modesetting and/or panicking the system.
To work around this, we now unregister the connector at the very
beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
locks, and then hold them until we finish the rest of the function.
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Rob Clark <rclark@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458155884-13877-1-git-send-email-cpaul@redhat.com
(cherry picked from commit 1f7717552ef1306be3b7ed28c66c6eff550e3a23)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d59a1f71ff1aeda4b4630df92d3ad4e3b1dfc885 upstream.
The SPICE protocol considers the position of a cursor to be the location
of its active pixel on the display, so the cursor is drawn with its
top-left corner at "(x - hot_spot_x, y - hot_spot_y)" but the DRM cursor
position gives the location where the top-left corner should be drawn,
with the hotspot being a hint for drivers that need it.
This fixes the location of the window resize cursors when using Fluxbox
with the QXL DRM driver and both the QXL and modesetting X drivers.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1447845445-2116-1-git-send-email-john@metanate.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 78a121d82da8aff3aca2a6a1c40f5061081760f0 upstream.
Most calls to nvkm_ramht_new use 0x8000 as the size. This results in a
fairly sizeable chunk of memory to be allocated, which may not be
available with kzalloc. Since this is done fairly rarely (once per
channel), use vzalloc instead.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: Sven Joachim <svenjoac@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ff15e95c82768d589957dbb17d7eb7dba7904659 upstream.
In commit:
eb1af3b71f9d ("Fix computation of channel address")
I switched the "sck_way" variable from holding the log2 value read
from the h/w to instead be the actual number. Unfortunately it
is needed in log2 form when used to shift the address.
Tested-by: Patrick Geary <patrickg@supermicro.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Aristeu Rozanski <arozansk@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-edac@vger.kernel.org
Fixes: eb1af3b71f9d ("Fix computation of channel address")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6bab1c6afdca0371cfa957079b36b78d12dd2cf5 upstream.
The current number of requestor lines is limited to 31. This was an
error of a previous commit, as this number is platform dependent, and is
actually :
- for pxa25x: 40 requestor lines
- for pxa27x: 75 requestor lines
- for pxa3xx: 100 requestor lines
The previous testing did not reveal the faulty constant as on pxa[23]xx
platforms, only camera, MSL and USB are above requestor 32, and in these
only the camera has a driver using dma.
Fixes: e87ffbdf0697 ("dmaengine: pxa_dma: fix the no-requestor case")
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4f4bc0abff79dc9d7ccbd3143adbf8ad1f4fe6ab upstream.
There is a typo in documentation regarding to descriptor empty bit (DESCE)
which is set to 1 when descriptor is empty. Thus, status register at the end of
a transfer usually returns all DESCE bits set and thus it will never be zero.
Moreover, there are 2 bits (CDESC) that encode current descriptor, on which
interrupt has been asserted. In case when we have few descriptors programmed we
might have non-zero value.
Remove DESCE and CDESC bits from DMA channel status register (HSU_CH_SR) when
reading it.
Fixes: 2b49e0c56741 ("dmaengine: append hsu DMA driver")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3fe6409c23e2bee4b2b1b6d671d2da8daa15271c upstream.
The commit 895005202987 ("dmaengine: dw: apply both HS interfaces and remove
slave_id usage") cleaned up the code to avoid usage of depricated slave_id
member of generic slave configuration.
Meanwhile it broke the master selection by removing important call to
dwc_set_masters() in ->device_alloc_chan_resources() which copied masters from
custom slave configuration to the internal channel structure.
Everything works until now since there is no customized connection of
DesignWare DMA IP to the bus, i.e. one bus and one or more masters are in use.
The configurations where 2 masters are connected to the different masters are
not working anymore. We are expecting one user of such configuration and need
to select masters properly. Besides that it is obviously a performance
regression since only one master is in use in multi-master configuration.
Select masters in accordance with what user asked for. Keep this patch in a form
more suitable for back porting.
We are safe to take necessary data in ->device_alloc_chan_resources() because
we don't support generic slave configuration embedded into custom one, and thus
the only way to provide such is to use the parameter to a filter function which
is called exactly before channel resource allocation.
While here, replase BUG_ON to less noisy dev_warn() and prevent channel
allocation in case of error.
Fixes: 895005202987 ("dmaengine: dw: apply both HS interfaces and remove slave_id usage")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6545b60baaf880b0cd29a5e89dbe745a06027e89 upstream.
Commit 9567366fefdd ("dm cache metadata: fix READ_LOCK macros and
cleanup WRITE_LOCK macros") uses down_write() instead of down_read() in
cmd_read_lock(), yet up_read() is used to release the lock in
READ_UNLOCK(). Fix it.
Fixes: 9567366fefdd ("dm cache metadata: fix READ_LOCK macros and cleanup WRITE_LOCK macros")
Signed-off-by: Ahmed Samy <f.fallen45@gmail.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9567366fefddeaea4ed1d713270535d93a3b3c76 upstream.
The READ_LOCK macro was incorrectly returning -EINVAL if
dm_bm_is_read_only() was true -- it will always be true once the cache
metadata transitions to read-only by dm_cache_metadata_set_read_only().
Wrap READ_LOCK and WRITE_LOCK multi-statement macros in do {} while(0).
Also, all accesses of the 'cmd' argument passed to these related macros
are now encapsulated in parenthesis.
A follow-up patch can be developed to eliminate the use of macros in
favor of pure C code. Avoiding that now given that this needs to apply
to stable@.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Fixes: d14fcf3dd79 ("dm cache: make sure every metadata function checks fail_io")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 38740a5b87d53ceb89eb2c970150f6e94e00373a upstream.
When using asynchronous read or write operations on the USB endpoints the
issuer of the IO request is notified by calling the ki_complete() callback
of the submitted kiocb when the URB has been completed.
Calling this ki_complete() callback will free kiocb. Make sure that the
structure is no longer accessed beyond that point, otherwise undefined
behaviour might occur.
Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e86103a75705c7c530768f4ffaba74cf382910f2 upstream.
On BXT platform Host Controller and Device Controller figure as
same PCI device but with different device function. HCD should
not pass data to Device Controller but only to Host Controllers.
Checking if companion device is Host Controller, otherwise skip.
Signed-off-by: Robert Dobrowolski <robert.dobrowolski@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 98d74f9ceaefc2b6c4a6440050163a83be0abede upstream.
PCI hotpluggable xhci controllers such as some Alpine Ridge solutions will
remove the xhci controller from the PCI bus when the last USB device is
disconnected.
Add a flag to indicate that the host is being removed to avoid queueing
configure_endpoint commands for the dropped endpoints.
For PCI hotplugged controllers this will prevent 5 second command timeouts
For static xhci controllers the configure_endpoint command is not needed
in the removal case as everything will be returned, freed, and the
controller is reset.
For now the flag is only set for PCI connected host controllers.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 71504062a7c34838c3fccd92c447f399d3cb5797 upstream.
This patch fixes some wild pointers produced by xhci_mem_cleanup.
These wild pointers will cause system crash if xhci_mem_cleanup()
is called twice.
Reported-and-tested-by: Pengcheng Li <lpc.li@hisilicon.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 671ffdff5b13314b1fc65d62cf7604b873fb5dc4 upstream.
Give USB3 devices a better chance to enumerate at USB 3 speeds if
they are connected to a suspended host.
Solves an issue with NEC uPD720200 host hanging when partially
enumerating a USB3 device as USB2 after host controller runtime resume.
Tested-by: Mike Murdoch <main.haarp@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
