| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Since commit fe115628d567 ("drm/i915: Implement pwrite without
struct-mutex") the lowlevel pwrite calls are now called without the
protection of struct_mutex, but pwrite_phys was still asserting that it
held the struct_mutex and later tried to drop and relock it.
Fixes: fe115628d567 ("drm/i915: Implement pwrite without struct-mutex")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
(cherry picked from commit 10466d2a59b23aa6d5ecd5310296c8cdb6458dac)
Signed-off-by: Jani Nikula <[email protected]>
|
|
Missed when rebasing patches, I failed to set ret to zero before
starting the unbind loop (which depends upon ret being zero).
Reported-by: Matthew Auld <[email protected]>
Fixes: 9332f3b1b99a ("drm/i915: Combine loops within i915_gem_evict_something")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Matthew Auld <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matthew Auld <[email protected]>
Cc: <[email protected]> # v4.9+
(cherry picked from commit 121dfbb2a2ef1c5f49e15c38ccc47ff0beb59446)
Signed-off-by: Jani Nikula <[email protected]>
|
|
Commit bbe097f092b0 ("usb: gadget: udc: atmel: fix endpoint name")
introduced a memory leak when unbinding the driver. The endpoint names
would not be freed. Solve that by including the name as a string in struct
usba_ep so it is freed when the endpoint is.
Signed-off-by: Alexandre Belloni <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Axius clock error path returns without disabling clock and suspend clock.
Fix it to disable them before returning error.
Reviewed-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
I've found when booting HiKey with the usb gadget cable attached
if I then try to connect via adb, I get an infinite spew of:
dwc2 f72c0000.usb: dwc2_hsotg_ep_sethalt(ep ffffffc0790ecb18 ep1out, 0)
dwc2 f72c0000.usb: dwc2_hsotg_ep_sethalt(ep ffffffc0790eca18 ep1in, 0)
It seems that the usb autosuspend is suspending the bus shortly
after bootup when the gadget cable is attached. So when adbd
then tries to use the device, it doesn't work and it then tries
to restart it over and over via the ep_sethalt calls (via
FUNCTIONFS_CLEAR_HALT ioctl).
Chen Yu suggested this patch to avoid suspending if we're
in device mode, and it avoids the problem.
Cc: Wei Xu <[email protected]>
Cc: Guodong Xu <[email protected]>
Cc: Amit Pundir <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: John Youn <[email protected]>
Cc: Douglas Anderson <[email protected]>
Cc: Chen Yu <[email protected]>
Cc: Kishon Vijay Abraham I <[email protected]>
Cc: Felipe Balbi <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: [email protected]
Suggested-by: Chen Yu <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: John Youn <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Commit 05ee799f2021 ("usb: dwc2: Move gadget settings into core_params")
changes to type u16 for DT binding "g-rx-fifo-size" and
"g-np-tx-fifo-size" but use type u32 for "g-tx-fifo-size". Finally the
the first two parameters cannot be passed successfully with wrong data
format. This is found the data transferring broken on 96boards Hikey.
This patch is to change all parameters to u32 type, and verified on
Hikey board the DT parameters can pass successfully.
[johnyoun: minor rebase]
Signed-off-by: Leo Yan <[email protected]>
Signed-off-by: John Youn <[email protected]>
Tested-by: John Stultz <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
When zero endpoints are declared for a function, there is no endpoint
to disable, enable or free, so replace do...while loops with while loops.
Change pre-decrement to post-decrement to iterate the same number of times
when there are endpoints to process.
Signed-off-by: Vincent Pelletier <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Remove DMA memory free from EP disable flow by replacing
dma_alloc_coherent with dmam_alloc_coherent.
Tested-by: John Stultz <[email protected]>
Signed-off-by: Vardan Mikayelyan <[email protected]>
Signed-off-by: John Youn <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
'cdev->os_desc_req' has been allocated with 'usb_ep_alloc_request()' so
'usb_ep_free_request()' should be used to free it.
Signed-off-by: Christophe JAILLET <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
|
|
Allows usage of the new page_flip_target hook for drivers implementing
the atomic path.
Provides default atomic helper for the new hook.
v2:
Update code sharing logic between exsiting and the new flip hooks.
Improve kerneldoc.
Signed-off-by: Andrey Grodzovsky <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Trivial fix to spelling mistake, rename kfd_ioctl_dbg_unrgesiter
to kfd_ioctl_dbg_unregister
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Oded Gabbay <[email protected]>
|
|
The vma->exec_list is still the only means we have for both reserving an
object in execbuf, and for constructing the eviction list. So during the
construction of the eviction list, we must treat anything already on the
exec_list as being pinned.
Yes, this sharing of two semantically different lists will be fixed! But
in the meantime, we have the issue that this is tripping up CI since we
started using i915_gem_gtt_reserve_node() + i915_gem_evict_for_node()
from the regular execbuf reservation path in commit 606fec956c0e
("drm/i915: Prefer random replacement before eviction search"):
[ 108.424063] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:254!
[ 108.424072] invalid opcode: 0000 [#1] PREEMPT SMP
[ 108.424079] Modules linked in: snd_hda_intel i915 intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core mei_me snd_pcm lpc_ich mei sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915]
[ 108.424132] CPU: 1 PID: 6865 Comm: gem_cs_tlb Tainted: G U 4.10.0-rc3-CI-CI_DRM_2049+ #1
[ 108.424143] Hardware name: Hewlett-Packard HP EliteBook 8440p/172A, BIOS 68CCU Ver. F.24 09/13/2013
[ 108.424154] task: ffff88012ae22600 task.stack: ffffc90000a14000
[ 108.424220] RIP: 0010:i915_gem_evict_for_node+0x237/0x410 [i915]
[ 108.424229] RSP: 0018:ffffc90000a17a58 EFLAGS: 00010202
[ 108.424237] RAX: 0000000000005871 RBX: ffff88012d1ad778 RCX: 0000000000000000
[ 108.424246] RDX: 000000007ffff000 RSI: ffffc90000a17a68 RDI: ffff880127e694d8
[ 108.424255] RBP: ffffc90000a17aa0 R08: ffffc90000a17a68 R09: 0000000000000000
[ 108.424264] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000080000000
[ 108.424273] R13: ffffc90000a17a68 R14: ffff880127e694d8 R15: ffffffffa0387330
[ 108.424283] FS: 00007f8236e3d8c0(0000) GS:ffff880137c40000(0000) knlGS:0000000000000000
[ 108.424293] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 108.424305] CR2: 00007f82347a2000 CR3: 000000012c866000 CR4: 00000000000006e0
[ 108.424317] Call Trace:
[ 108.424368] i915_gem_gtt_reserve+0x67/0x80 [i915]
[ 108.424424] __i915_vma_do_pin+0x248/0x620 [i915]
[ 108.424487] ? __i915_vma_do_pin+0x162/0x620 [i915]
[ 108.424540] i915_gem_execbuffer_reserve_vma.isra.8+0x153/0x1f0 [i915]
[ 108.424591] i915_gem_execbuffer_reserve.isra.9+0x40e/0x440 [i915]
[ 108.424643] i915_gem_do_execbuffer.isra.15+0x6d9/0x1b20 [i915]
[ 108.424696] i915_gem_execbuffer2+0xc0/0x250 [i915]
[ 108.424712] drm_ioctl+0x200/0x450
[ 108.424760] ? i915_gem_execbuffer+0x330/0x330 [i915]
[ 108.424776] do_vfs_ioctl+0x90/0x6e0
[ 108.424789] ? up_read+0x1a/0x40
[ 108.424800] ? trace_hardirqs_on_caller+0x122/0x1b0
[ 108.424813] SyS_ioctl+0x3c/0x70
[ 108.424828] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 108.424839] RIP: 0033:0x7f8235867357
[ 108.424848] RSP: 002b:00007ffdc14504c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 108.424866] RAX: ffffffffffffffda RBX: 00007ffdc1450600 RCX: 00007f8235867357
[ 108.424878] RDX: 00007ffdc14505a0 RSI: 0000000040406469 RDI: 0000000000000003
[ 108.424890] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000022
[ 108.424903] R10: 0000000000000007 R11: 0000000000000246 R12: 0000000000000002
[ 108.424915] R13: 0000000000419101 R14: 00007ffdc1450600 R15: 00007ffdc14505f0
[ 108.424928] Code: 45 b8 8b 4d c0 4c 89 f2 48 89 de ff d0 49 8b 07 4c 8b 45 b8 48 85 c0 75 dd 65 ff 0d d4 a1 c8 5f 0f 84 47 01 00 00 e9 0d fe ff ff <0f> 0b 45 31 f6 4c 8b 65 c8 49 8b 04 24 4d 39 ec 49 8d 9c 24 28
[ 108.425055] RIP: i915_gem_evict_for_node+0x237/0x410 [i915] RSP: ffffc90000a17a58
Fixes: 172ae5b4c8c1 ("drm/i915: Fix i915_gem_evict_for_vma (soft-pinning)")
Fixes: 606fec956c0e ("drm/i915: Prefer random replacement before eviction search")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Joonas Lahtinen <[email protected]>
|
|
Since gpio_dev->hwbank_num is now a variable, the compiler cannot
figure out if pin_num is initialized at all:
drivers/pinctrl/pinctrl-amd.c: In function 'amd_gpio_dbg_show':
drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num' may be used uninitialized in this function [-Wmaybe-uninitialized]
for (; i < pin_num; i++) {
^~~
drivers/pinctrl/pinctrl-amd.c:172:21: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
This adds a 'default' statement to make that case well-defined.
Fixes: 3bfd44306c65 ("pinctrl: amd: Add support for additional GPIO")
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
When DIRECT_IRQ_EN is set, the pin is routed directly to the IO-APIC bypassing
the GPIO driver completely. However, the mask register is still used to
determine if the pin is supposed to generate IRQ or not.
So with commit 3ae02c14d964 the IRQ core masks all IRQs (because of
handle_bad_irq()) the pin connected to the touchscreen gets masked as well and
hence no interrupts.
To make this all work as expected we do not add those GPIOs to the IRQ domain
that can actually propagate interrupts.
Fixes: 3ae02c14d964 ("pinctrl: intel: set default handler to be handle_bad_irq()")
Reported-by: Robert R. Howell <[email protected]>
Suggested-by: Mika Westerberg <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Set variables initialized in lpfc_sli4_alloc_resource_identifiers() to
NULL if an error occurred. Otherwise, lpfc_sli4_driver_resource_unset()
attempts to free the memory again.
Signed-off-by: Roberto Sassu <[email protected]>
Signed-off-by: Johannes Thumshirn <[email protected]>
Acked-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Now that qla2xxx uses the IRQ layer affinity assignment, affinity won't
change over the life time of a device and the notifiers are useless.
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Himanshu Madhani <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The first two or three vectors in qla2xxx adapter are global and not
associated with a specific queue. They should not have IRQ affinity
assigned.
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Himanshu Madhani <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The receive callback (in tasklet context) is using RCU to get reference
to associated VF network device but this is not safe. RCU read lock
needs to be held. Found by running with full lockdep debugging
enabled.
Fixes: f207c10d9823 ("hv_netvsc: use RCU to protect vf_netdev")
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Otherwise, a xfrm policy with sport/dport being set cannot be matched.
Signed-off-by: Martynas Pumputis <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Fix the hw rx checksum is always enabled, and the user couldn't switch
it to sw rx checksum.
Note that the RTL_VER_01 only support sw rx checksum only. Besides,
the hw rx checksum for RTL_VER_02 is disabled after
commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.
Signed-off-by: Hayes Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.
Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.
As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.
See https://github.com/vlasenko/hid-asus-dkms/issues/24 for further
details.
Signed-off-by: Brendan McGrath <[email protected]>
Reviewed-by: Benjamin Tissoires <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
|
|
Merge fixes from Andrew Morton:
"27 fixes.
There are three patches that aren't actually fixes. They're simple
function renamings which are nice-to-have in mainline as ongoing net
development depends on them."
* akpm: (27 commits)
timerfd: export defines to userspace
mm/hugetlb.c: fix reservation race when freeing surplus pages
mm/slab.c: fix SLAB freelist randomization duplicate entries
zram: support BDI_CAP_STABLE_WRITES
zram: revalidate disk under init_lock
mm: support anonymous stable page
mm: add documentation for page fragment APIs
mm: rename __page_frag functions to __page_frag_cache, drop order from drain
mm: rename __alloc_page_frag to page_frag_alloc and __free_page_frag to page_frag_free
mm, memcg: fix the active list aging for lowmem requests when memcg is enabled
mm: don't dereference struct page fields of invalid pages
mailmap: add codeaurora.org names for nameless email commits
signal: protect SIGNAL_UNKILLABLE from unintentional clearing.
mm: pmd dirty emulation in page fault handler
ipc/sem.c: fix incorrect sem_lock pairing
lib/Kconfig.debug: fix frv build failure
mm: get rid of __GFP_OTHER_NODE
mm: fix remote numa hits statistics
mm: fix devm_memremap_pages crash, use mem_hotplug_{begin, done}
ocfs2: fix crash caused by stale lvb with fsdlm plugin
...
|
|
Pull networking fixes from David Miller:
1) Fix rtlwifi crash, from Larry Finger.
2) Memory disclosure in appletalk ipddp routing code, from Vlad
Tsyrklevich.
3) r8152 can erroneously split an RX packet into multiple URBs if the
Rx FIFO is not empty when we suspend. Fix this by waiting for the
FIFO to empty before suspending. From Hayes Wang.
4) Two GRO fixes (enter slow path when not enough SKB tail room exists,
disable frag0 optimizations when there are IPV6 extension headers)
from Eric Dumazet and Herbert Xu.
5) A series of mlx5e bug fixes (do source udp port offloading for
tunnels properly, Ip fragment matching fixes, handling firmware
errors properly when installing TC rules, etc.) from Saeed Mahameed,
Or Gerlitz, Roi Dayan, Hadar Hen Zion, Gil Rockah, and Daniel
Jurgens.
6) Two VRF fixes from David Ahern (don't skip multipath selection for
VRF paths, disallow VRF to be configured with table ID 0).
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (35 commits)
net: vrf: do not allow table id 0
net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
sctp: Fix spelling mistake: "Atempt" -> "Attempt"
net: ipv4: Fix multipath selection with vrf
cgroup: move CONFIG_SOCK_CGROUP_DATA to init/Kconfig
gro: use min_t() in skb_gro_reset_offset()
net/mlx5: Only cancel recovery work when cleaning up device
net/mlx5e: Remove WARN_ONCE from adaptive moderation code
net/mlx5e: Un-register uplink representor on nic_disable
net/mlx5e: Properly handle FW errors while adding TC rules
net/mlx5e: Fix kbuild warnings for uninitialized parameters
net/mlx5e: Set inline mode requirements for matching on IP fragments
net/mlx5e: Properly get address type of encapsulation IP headers
net/mlx5e: TC ipv4 tunnel encap offload error flow fixes
net/mlx5e: Warn when rejecting offload attempts of IP tunnels
net/mlx5e: Properly handle offloading of source udp port for IP tunnels
gro: Disable frag0 optimization on IPv6 ext headers
gro: Enter slow-path if there is no tailroom
mlx4: Return EOPNOTSUPP instead of ENOTSUPP
net/af_iucv: don't use paged skbs for TX on HiperSockets
...
|
|
I noticed that the VT switch doesn't work any longer with a Dell
laptop with 1366x768 eDP when the machine is connected with a DP
monitor. It behaves as if VT were switched, but the graphics remain
frozen. Actually the keyboard works, so I could switch back to VT7
again.
I tried to track down the problem, and encountered a long story until
we reach to this error:
- The machine is booted with video=1366x768 option (the distro
installer seems to add it as default).
- Recently, drm_helper_probe_single_connector_modes() deals with
cmdline modes, and it tries to create a new mode when no
matching mode is found.
- The drm_mode_create_from_cmdline_mode() creates a mode based on
either CVT of GFT according to the given cmdline mode; in our case,
it's 1366x768.
- Since both CVT and GFT can't express the width 1366 due to
alignment, the resultant mode becomes 1368x768, slightly larger than
the given size.
- Later on, the atomic commit is performed, and in
drm_atomic_check_only(), the size of each plane is checked.
- The size check of 1366x768 fails due to the above, and eventually
the whole VT switch fails.
Back in the history, we've had a manual fix-up of 1368x768 in various
places via c09dedb7a50e ("drm/edid: Add a workaround for 1366x768 HD
panel"), but they have been all in drm_edid.c at probing the modes
from EDID. For addressing the problem above, we need a similar hack
to the mode newly created from cmdline, manually adjusting the width
when the expected size is 1366 while we get 1368 instead.
Fixes: eaf99c749d43 ("drm: Perform cmdline mode parsing during...")
Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
|
|
Many DRM drivers only work with an MMU, and after the patch to enable
core DRM support without MMU, we already had one fixup for many of them.
The etnaviv, armada and msm drivers were missed and have the same problem:
warning: (DRM_ETNAVIV) selects IOMMU_SUPPORT which has unmet direct dependencies (MMU)
warning: (DRM_I915 && DRM_MSM && DRM_ETNAVIV) selects SHMEM which has unmet direct dependencies (MMU)
drivers/gpu/drm/armada/armada_gem.o: In function `armada_gem_vm_fault':
armada_gem.c:(.text.armada_gem_vm_fault+0x14): undefined reference to `vm_insert_pfn'
arch/arm/mm/dma-mapping.c: In function '__iommu_alloc_remap':
arch/arm/mm/dma-mapping.c:1390:4: error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function)
arch/arm/mm/dma-mapping.c:1456:31: error: 'atomic_pool' undeclared (first use in this function); did you mean 'atomic_xor'?
Fixes: 011cda589938 ("drm: fix compilations issues introduced by "drm: allow to use mmuless SoC"")
Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC")
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Lucas Stach <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Commit 54adc01055b7 ("nvme/quirk: Add a delay before checking for adapter
readiness") introduced a quirk to adapters that cannot read the bit
NVME_CSTS_RDY right after register NVME_REG_CC is set; these adapters
need a delay or else the action of reading the bit NVME_CSTS_RDY could
somehow corrupt adapter's registers state and it never recovers.
When this quirk was added, we checked ctrl->tagset in order to avoid
quirking in probe time, supposing we would never require such delay
during probe. Well, it was too optimistic; we in fact need this quirk
at probe time in some cases, like after a kexec.
In some experiments, after abnormal shutdown of machine (aka power cord
unplug), we booted into our bootloader in Power, which is a Linux kernel,
and kexec'ed into another distro. If this kexec is too quick, we end up
reaching the probe of NVMe adapter in that distro when adapter is in
bad state (not fully initialized on our bootloader). What happens next
is that nvme_wait_ready() is unable to complete, except if the quirk is
enabled.
So, this patch removes the original ctrl->tagset verification in order
to enable the quirk even on probe time.
Fixes: 54adc01055b7 ("nvme/quirk: Add a delay before checking for adapter readiness")
Reported-by: Andrew Byrne <[email protected]>
Reported-by: Jaime A. H. Gomez <[email protected]>
Reported-by: Zachary D. Myers <[email protected]>
Signed-off-by: Guilherme G. Piccoli <[email protected]>
Acked-by: Jeffrey Lien <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
Now that we don't abuse the cmd field in struct request for nvme command
passthrough this function needs to be converted to the proper accessor
as well.
Fixes: d49187e97e ("nvme: introduce struct nvme_request")
Signed-off-by: Christoph Hellwig <[email protected]>
Reviewed-by: Max Gurtovoy <[email protected]>
|
|
If a URB is killed while the host is removed we can end up in a situation
where the hub thread takes the roothub device lock, and waits for
the URB to be given back by xhci-hcd, blocking the host remove code.
xhci-hcd tries to stop the endpoint and give back the urb, but can't
as the host is removed from PCI bus at the same time, preventing the normal
way of giving back urb.
Instead we need to rely on the stop command timeout function to give back
the urb. This xhci_stop_endpoint_command_watchdog() timeout function
used a XHCI_STATE_DYING flag to indicate if the timeout function is already
running, but later this flag has been taking into use in other places to
mark that xhci is dying.
Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still
checking that reading from pci state does not return 0xffffffff or that
host is not halted before trying to stop the endpoint.
This whole area of stopping endpoints, giving back URBs, and the wathdog
timeout need rework, this fix focuses on solving a specific deadlock
issue that we can then send to stable before any major rework.
Cc: <[email protected]>
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary
interface and a PCI Express secondary interface. The PCIe interface is a
Downstream Port that originates a Link. See the "PCI Express to PCI/PCI-X
Bridge Specification", rev 1.0, sections 1.2 and A.6.
The bug report below involves a PCI-to-PCIe bridge and a PCIe switch below
the bridge:
00:1e.0 Intel 82801 PCI Bridge to [bus 01-0a]
01:00.0 Pericom PI7C9X111SL PCIe-to-PCI Reversible Bridge to [bus 02-0a]
02:00.0 Pericom Device 8608 [PCIe Upstream Port] to [bus 03-0a]
03:01.0 Pericom Device 8608 [PCIe Downstream Port] to [bus 0a]
01:00.0 is configured as a PCI-to-PCIe bridge (despite the name printed by
lspci). As we traverse a PCIe hierarchy, device connections alternate
between PCIe Links and internal Switch logic. Previously we did not
recognize that 01:00.0 had a secondary link, so we thought the 02:00.0
Upstream Port *did* have a secondary link. In fact, it's the other way
around: 01:00.0 has a secondary link, and 02:00.0 has internal Switch logic
on its secondary side.
When we thought 02:00.0 had a secondary link, the pci_scan_slot() ->
only_one_child() path assumed 02:00.0 could have only one child, so 03:00.0
was the only possible downstream device. But 03:00.0 doesn't exist, so we
didn't look for any other devices on bus 03.
Booting with "pci=pcie_scan_all" is a workaround, but we don't want users
to have to do that.
Recognize that PCI-to-PCIe bridges originate links on their secondary
interfaces.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=189361
Fixes: d0751b98dfa3 ("PCI: Add dev->has_secondary_link to track downstream PCIe links")
Tested-by: Blake Moore <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: [email protected] # v4.2+
|
|
Frank reported that vrf devices can be created with a table id of 0.
This breaks many of the run time table id checks and should not be
allowed. Detect this condition at create time and fail with EINVAL.
Fixes: 193125dbd8eb ("net: Introduce VRF device driver")
Reported-by: Frank Kellermann <[email protected]>
Signed-off-by: David Ahern <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When an Marvell 88E1512 PHY is connected to a nic in SGMII mode, the
fiber page is used for the SGMII host-side connection. The PHY driver
notices that SUPPORTED_FIBRE is set, so it tries reading the fiber page
for the link status, and ends up reading the MAC-side status instead of
the outgoing (copper) link. This leads to incorrect results reported
via ethtool.
If the PHY is connected via SGMII to the host, ignore the fiber page.
However, continue to allow the existing power management code to
suspend and resume the fiber page.
Fixes: 6cfb3bcc0641 ("Marvell phy: check link status in case of fiber link.")
Signed-off-by: Russell King <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
fib_select_path does not call fib_select_multipath if oif is set in the
flow struct. For VRF use cases oif is always set, so multipath route
selection is bypassed. Use the FLOWI_FLAG_SKIP_NH_OIF to skip the oif
check similar to what is done in fib_table_lookup.
Add saddr and proto to the flow struct for the fib lookup done by the
VRF driver to better match hash computation for a flow.
Fixes: 613d09b30f8b ("net: Use VRF device index for lookups on TX")
Signed-off-by: David Ahern <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
It is an error to start a new request on the same timeline (ringbuffer)
as the current one before the current is submitted. If there are two
requests emitting to the ringbuffer at the same time, the operation is
undefined. We can catch this by checking for the timeline having a later
seqno than ours when we come to submit our request.
Currently we have this check at the end of __i915_add_request, but
having an early check as well isolates a failure in the caller versus a
failure in sealing the request (i.e. from inside __i915_add_request
itself). For example, CI is currently tripping over this late assertion
on ctg/ilk:
[ 100.329399] [IGT] gem_cs_tlb: starting subtest basic-default
[ 100.336333] ------------[ cut here ]------------
[ 100.336341] kernel BUG at drivers/gpu/drm/i915/i915_gem_request.c:908!
[ 100.336347] invalid opcode: 0000 [#1] PREEMPT SMP
[ 100.336351] Modules linked in: snd_hda_intel i915 snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm coretemp mei_me lpc_ich mei e1000e ptp pps_core [last unloaded: i915]
[ 100.336373] CPU: 0 PID: 6308 Comm: gem_cs_tlb Tainted: G U 4.10.0-rc3-CI-CI_DRM_2045+ #1
[ 100.336380] Hardware name: LENOVO 7465CTO/7465CTO, BIOS 6DET44WW (2.08 ) 04/22/2009
[ 100.336386] task: ffff88012b738040 task.stack: ffffc90000560000
[ 100.336441] RIP: 0010:__i915_add_request+0x4aa/0x510 [i915]
[ 100.336445] RSP: 0018:ffffc90000563ac0 EFLAGS: 00010212
[ 100.336451] RAX: 0000000000005d52 RBX: ffff880133bb84c0 RCX: 0000000000000001
[ 100.336456] RDX: 0000000080000001 RSI: ffff88012b738860 RDI: 00000000ffffffff
[ 100.336461] RBP: ffffc90000563b00 R08: ffff880133bb8780 R09: 0000000000000000
[ 100.336466] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88012f53d950
[ 100.336472] R13: ffff88012a2b0af8 R14: ffff88012a5b0008 R15: ffff88012f53d960
[ 100.336477] FS: 00007f0d19da38c0(0000) GS:ffff88013bc00000(0000) knlGS:0000000000000000
[ 100.336483] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 100.336488] CR2: 00007f0d17706000 CR3: 000000012aa3e000 CR4: 00000000000406f0
[ 100.336496] Call Trace:
[ 100.336527] i915_gem_switch_to_kernel_context+0x131/0x1b0 [i915]
[ 100.336559] i915_gem_evict_vm+0x202/0x2b0 [i915]
[ 100.336590] i915_gem_execbuffer_reserve.isra.9+0x3ae/0x440 [i915]
[ 100.336623] i915_gem_do_execbuffer.isra.15+0x6d9/0x1b20 [i915]
[ 100.336656] i915_gem_execbuffer2+0xc0/0x250 [i915]
[ 100.336666] drm_ioctl+0x200/0x450
[ 100.336697] ? i915_gem_execbuffer+0x330/0x330 [i915]
[ 100.336708] do_vfs_ioctl+0x90/0x6e0
[ 100.336716] ? up_read+0x1a/0x40
[ 100.336723] ? trace_hardirqs_on_caller+0x122/0x1b0
[ 100.336730] SyS_ioctl+0x3c/0x70
[ 100.336738] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 100.336745] RIP: 0033:0x7f0d187cb357
[ 100.336750] RSP: 002b:00007ffe0b2f7c28 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 100.336761] RAX: ffffffffffffffda RBX: 00007ffe0b2f7d60 RCX: 00007f0d187cb357
[ 100.336768] RDX: 00007ffe0b2f7d00 RSI: 0000000040406469 RDI: 0000000000000003
[ 100.336775] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000022
[ 100.336782] R10: 0000000000000007 R11: 0000000000000246 R12: 0000000000000002
[ 100.336789] R13: 0000000000419101 R14: 00007ffe0b2f7d60 R15: 00007ffe0b2f7d50
[ 100.336797] Code: 5f 74 1e e9 d4 fb ff ff e8 bc 1e 9c e0 e9 ae fb ff ff 4c 89 e7 e8 77 22 fd ff e9 88 fd ff ff 0f 0b e8 a3 1e 9c e0 e9 b1 fb ff ff <0f> 0b 0f 0b e8 fd af ab e0 85 c0 75 c2 48 c7 c2 80 2c 71 a0 be
[ 100.336877] RIP: __i915_add_request+0x4aa/0x510 [i915] RSP: ffffc90000563ac0
[ 100.336886] ---[ end trace 22b36545479e5eb7 ]---
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Joonas Lahtinen <[email protected]>
|
|
The commit 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
implements debounce for Baytrail pin control, but seems wasn't tested properly.
The register which keeps debounce value is separated from the configuration
one. Writing wrong values to the latter will guarantee wrong behaviour of the
driver and even might break something physically.
Besides above there is missed case how to disable it, which is actually done
through the bit in configuration register.
Rectify implementation here by using proper register for debounce value.
Fixes: 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
Cc: Cristina Ciocan <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
There are two bits in the PADCFG0 register to configure direction, one per
TX/RX buffers.
For now we wrongly assume that the GPIO is always requested before it is being
used, which is not true when the GPIO is used through irqchip. In this case the
GPIO is never requested and we never enable RX buffer for it.
Fix this by setting both bits accordingly.
Reported-by: Jarkko Nikula <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
PADCFGLOCK (and PADCFGLOCK_TX) offset in Broxton actually starts at 0x060
and not 0x090 as used in the driver. Fix it to use the correct offset.
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Performing an eviction search can be very, very slow especially for a
range restricted replacement. For example, a workload like
gem_concurrent_blit will populate the entire GTT and then cause aperture
thrashing. Since the GTT is a mix of active and inactive tiny objects,
we have to search through almost 400k objects before finding anything
inside the mappable region, and as this search is required before every
operation performance falls off a cliff.
Instead of performing the full search, we do a trial replacement of the
node at a random location fitting the specified restrictions. We lose
the strict LRU property of the GTT in exchange for avoiding the slow
search (several orders of runtime improvement for gem_concurrent_blit
4KiB-global-gtt, e.g. from 5000s to 20s). The loss of LRU replacement is
(later) mitigated firstly by only doing replacement if we find no
freespace and secondly by execbuf doing a PIN_NONBLOCK search first before
it starts thrashing (i.e. the random replacement will only occur from the
already inactive set of objects).
v2: Ascii-art, and check preconditionst
v3: Rephrase final sentence in comment to explain why we don't bother
with if (i915_is_ggtt(vm)) for preferring random replacement.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Extract drm_mm_reserve_node + calling i915_gem_evict_for_node into its
own routine so that it can be shared rather than duplicated.
v2: Kerneldoc
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: [email protected]
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
When we evict from the GTT to make room for an object, the hole we
create is put onto the MRU stack inside the drm_mm range manager. On the
next search pass, we can speed up a PIN_HIGH allocation by referencing
that stack for the new hole.
v2: Pull together the 3 identical implements (ahem, a couple were
outdated) into a common routine for allocating a node and evicting as
necessary.
v3: Detect invalid calls to i915_gem_gtt_insert()
v4: kerneldoc
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
A short control transfer would currently fail to be detected, something
which could lead to stale buffer data being used as valid input.
Check for short transfers, and make sure to log any transfer errors.
Note that this also avoids leaking heap data to user space (TIOCMGET)
and the remote device (break control).
Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor")
Cc: stable <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
|
|
In ca91cx42_slave_get function, the value pointed by vme_base pointer is
set through:
*vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]);
So it must be dereferenced to be used in calculation of pci_base:
*pci_base = (dma_addr_t)*vme_base + pci_offset;
This bug was caught thanks to the following gcc warning:
drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’:
drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
*pci_base = (dma_addr_t)vme_base + pci_offset;
Signed-off-by: Augusto Mecking Caringi <[email protected]>
Acked-By: Martyn Welch <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
After rollover of the IOVA space, we want to get a low IOVA address,
otherwise the the games we play by remembering the last IOVA are
pointless. When we search for a free hole with DRM_MM_SEARCH_DEFAULT,
drm_mm will pop the next entry from the free holes stack, which will
likely be a high IOVA. By using DRM_MM_SEARCH_BELOW we can trick
drm_mm into reversing the search and provide us with a low IOVA.
Signed-off-by: Lucas Stach <[email protected]>
Reviewed-by: Wladimir van der Laan <[email protected]>
|
|
Fix build errors caused by selecting incorrect kconfig symbols.
drivers/built-in.o:(.data+0x19cec): undefined reference to `sys_fillrect'
drivers/built-in.o:(.data+0x19cf0): undefined reference to `sys_copyarea'
drivers/built-in.o:(.data+0x19cf4): undefined reference to `sys_imageblit'
Fixes: 31114fa95bdb (auxdisplay: ht16k33: select framebuffer helper modules)
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Miguel Ojeda Sandonis <[email protected]>
Reported-by: kbuild test robot <[email protected]>
Acked-by: Robin van der Gracht <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
The sysrq input handler should be attached to the input device which has
a left alt key.
On 32-bit kernels, some input devices which has a left alt key cannot
attach sysrq handler. Because the keybit bitmap in struct input_device_id
for sysrq is not correctly initialized. KEY_LEFTALT is 56 which is
greater than BITS_PER_LONG on 32-bit kernels.
I found this problem when using a matrix keypad device which defines
a KEY_LEFTALT (56) but doesn't have a KEY_O (24 == 56%32).
Cc: Jiri Slaby <[email protected]>
Signed-off-by: Akinobu Mita <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
A previous fix of a memory leak now prints the string 'name'
that was previously free'd. Fix this by free'ing the string
at the end of the function and adding an error exit path for
the error conditions.
CoverityScan CID#1384523 ("Use after free")
Fixes: 2bd362d5f45c1 ("ppdev: fix memory leak")
Signed-off-by: Colin Ian King <[email protected]>
Acked-by: Sudip Mukherjee <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Function get_zeroed_page() returns a NULL pointer if there is no enough
memory. In function extcon_sync(), it returns 0 if the call to
get_zeroed_page() fails. The return value 0 indicates success in the
context, which is incosistent with the execution status. This patch
fixes the bug by returning -ENOMEM.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188611
Signed-off-by: Pan Bian <[email protected]>
Fixes: a580982f0836e
Cc: stable <[email protected]>
Acked-by: Chanwoo Choi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
drivers/gpu/drm/selftests/test-drm_mm.c:1277 evict_everything()
warn: calling list_del() inside list_for_each
The list_del() inside the error handling in the eviction loop is
overkill. We have to undo the eviction scan to return the drm_mm back to
a recoverable state, so have to iterate over the full list, but we only
want to report the error once and once we have an error we can return
early.
Reported-by: Dan Carpenter <[email protected]>
Fixes: 560b32842912 ("drm: kselftest for drm_mm and eviction")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Daniel Vetter <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This commit needs to be reverted because it prevents people from
using the serial console as a secondary console with input being
directed to tty0.
IOW, if you boot with console=ttyS0 console=tty0 then all kernels
prior to this commit will produce output on both ttyS0 and tty0
but input will only be taken from tty0. With this patch the serial
console will always be the primary console instead of tty0,
potentially preventing people from getting into their machines in
emergency situations.
Fixes: d03516df8375 ("tty: serial: 8250: add CON_CONSDEV to flags")
Signed-off-by: Herbert Xu <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
When in RS485 emulation mode, __do_stop_tx_rs485() calls
serial8250_clear_fifos(). This not only clears the FIFOs, but also sets
all bits in their control register (UART_FCR) to 0.
One of the effects of this is the disabling of the FIFOs, which turns
them into single-byte holding registers. The rest of the driver doesn't
know this, which results in the lions share of characters passed into a
write call to be dropped.
(I can supply logic analyzer screenshots if necessary)
This fix replaces the serial8250_clear_fifos() call to
serial8250_clear_and_reinit_fifos() - this prevents the "dropped
characters" issue from manifesting again while retaining the requirement
of clearing the RX FIFO after transmission if the SER_RS485_RX_DURING_TX
flag is disabled.
Signed-off-by: Daniel Jedrychowski <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Commit f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during
PCI error recovery") introduces a potential use-after-free in case the
pciserial_init_ports call in serial8250_io_resume fails, which may
happen if a memory allocation fails or if the .init quirk failed for
whatever reason). If this happen, further pci_get_drvdata will return a
pointer to freed memory.
This patch reworks the PCI recovery resume hook to restore the old priv
structure in this case, which should be ok, since the ports were already
detached. Such error during recovery causes us to give up on the
recovery.
Fixes: f209fa03fc9d ("serial: 8250_pci: Detach low-level driver during
PCI error recovery")
Reported-by: Michal Suchanek <[email protected]>
Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
Signed-off-by: Guilherme G. Piccoli <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|