Jarkko Sakkinen [Tue, 9 Jun 2015 12:07:59 +0000 (15:07 +0300)]
tpm, tpm_crb: fix le64_to_cpu conversions in crb_acpi_add()
commit
49afd7289bd937401c5f7faa193054bc3c41dad6 upstream.
le64_to_cpu() was applied twice to the physical addresses read from the
control area. This hasn't shown any visible regressions because CRB
driver has been tested only on the little endian platofrms so far.
Reported-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Fixes:
30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Fries [Sat, 9 May 2015 00:51:50 +0000 (19:51 -0500)]
w1_therm reference count family data
commit
f7134eea05b2fb4a2c0935f8a540539fff01f3eb upstream.
A temperature conversion can take 750 ms and when possible the
w1_therm slave driver drops the bus_mutex to allow other bus
operations, but that includes operations such as a periodic slave
search, which can remove this slave when it is no longer detected.
If that happens the sl->family_data will be freed and set to NULL
causing w1_slave_show to crash when it wakes up.
Signed-off-by: David Fries <David@Fries.net>
Reported-By: Thorsten Bschorr <thorsten@bschorr.de>
Tested-by: Thorsten Bschorr <thorsten@bschorr.de>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Foster [Mon, 22 Jun 2015 22:47:20 +0000 (08:47 +1000)]
xfs: don't truncate attribute extents if no extents exist
commit
f66bf042693b620133d39af8d2f13615f03eadfc upstream.
The xfs_attr3_root_inactive() call from xfs_attr_inactive() assumes that
attribute blocks exist to invalidate. It is possible to have an
attribute fork without extents, however. Consider the case where the
attribute fork is created towards the beginning of xfs_attr_set() but
some part of the subsequent attribute set fails.
If an inode in such a state hits xfs_attr_inactive(), it eventually
calls xfs_dabuf_map() and possibly xfs_bmapi_read(). The former emits a
filesystem corruption warning, returns an error that bubbles back up to
xfs_attr_inactive(), and leads to destruction of the in-core attribute
fork without an on-disk reset. If the inode happens to make it back
through xfs_inactive() in this state (e.g., via a concurrent bulkstat
that cycles the inode from the reclaim state and releases it), i_afp
might not exist when xfs_bmapi_read() is called and causes a NULL
dereference panic.
A '-p 2' fsstress run to ENOSPC on a relatively small fs (1GB)
reproduces these problems. The behavior is a regression caused by:
6dfe5a0 xfs: xfs_attr_inactive leaves inconsistent attr fork state behind
... which removed logic that avoided the attribute extent truncate when
no extents exist. Restore this logic to ensure the attribute fork is
destroyed and reset correctly if it exists without any allocated
extents.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Sandeen [Sun, 21 Jun 2015 23:42:48 +0000 (09:42 +1000)]
xfs: fix remote symlinks on V5/CRC filesystems
commit
2ac56d3d4bd625450a54d4c3f9292d58f6b88232 upstream.
If we create a CRC filesystem, mount it, and create a symlink with
a path long enough that it can't live in the inode, we get a very
strange result upon remount:
# ls -l mnt
total 4
lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM
XSLM is the V5 symlink block header magic (which happens to be
followed by a NUL, so the string looks terminated).
xfs_readlink_bmap() advanced cur_chunk by the size of the header
for CRC filesystems, but never actually used that pointer; it
kept reading from bp->b_addr, which is the start of the block,
rather than the start of the symlink data after the header.
Looks like this problem goes back to v3.10.
Fixing this gets us reading the proper link target, again.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin K. Petersen [Tue, 19 May 2015 23:44:17 +0000 (19:44 -0400)]
libata: Fix regression when the NCQ Send and Receive log page is absent
commit
eab6ee1ce3c4678224d70338134f7a02005768cb upstream.
Commit
5d3abf8ff67f ("libata: Fall back to unqueued READ LOG EXT if
the DMA variant fails") allowed us to fall back to the unqueued READ
LOG variant if the queued version failed. However, if the device did
not support the page at all we would end up looping due to a merge
snafu.
Ensure we only take the fallback path once.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Thu, 16 Jul 2015 14:47:50 +0000 (16:47 +0200)]
drm: Stop resetting connector state to unknown
commit
5677d67ae3949f09f57357241b88222d49b8c782 upstream.
It's causing piles of issues since we've stopped forcing full detect
cycles in the sysfs interfaces with
commit
c484f02d0f02fbbfc6decc945a69aae011041a27
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Mar 6 12:36:42 2015 +0000
drm: Lighten sysfs connector 'status'
The original justification for this was that the hpd handlers could
use the unknown state as a hint to force a full detection. But current
i915 code isn't doing that any more, and no one else really uses reset
on resume. So instead just keep the old state around.
References: http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100641
Cc: Rui Matos <tiagomatos@gmail.com>
Cc: Julien Wajsberg <felash@gmail.com>
Cc: kuddel.mail@gmx.de
Cc: Lennart Poettering <mzxreary@0pointer.de>
Acked-by: Rob Clark <robdclark@gmail.com>
Tested-by: Rui Tiago Cação Matos <tiagomatos@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tvrtko Ursulin [Tue, 14 Jul 2015 10:13:08 +0000 (11:13 +0100)]
drm: Provide compat ioctl for addfb2.1
commit
c631d5f90e7ee246536c72f80ade86e9ef4d2f13 upstream.
Frame buffer modifiers extensions provided in;
commit
e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark <robdclark@gmail.com>
Date: Thu Feb 5 14:41:52 2015 +0000
drm: add support for tiled/compressed/etc modifier in addfb2
Missed the structure packing/alignment problem where 64-bit
members were added after the odd number of 32-bit ones. This
makes the compiler produce structures of different sizes under
32- and 64-bit x86 targets and makes the ioctl need explicit
compat handling.
v2: Removed the typedef. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: Rob Clark <robdclark@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
[danvet: Squash in compile fix from Mika.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhao Junwang [Tue, 7 Jul 2015 09:08:35 +0000 (17:08 +0800)]
drm: add a check for x/y in drm_mode_setcrtc
commit
01447e9f04ba1c49a9534ae6a5a6f26c2bb05226 upstream.
legacy setcrtc ioctl does take a 32 bit value which might indeed
overflow
the checks of crtc_req->x > INT_MAX and crtc_req->y > INT_MAX aren't
needed any more with this
v2: -polish the annotation according to Daniel's comment
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Zhao Junwang <zhjwpku@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Kurtz [Tue, 7 Jul 2015 09:03:36 +0000 (17:03 +0800)]
drm/rockchip: use drm_gem_mmap helpers
commit
41315b793e13f884cda79389f0d5d44d027e57d1 upstream.
Rather than (incompletely [0]) re-implementing drm_gem_mmap() and
drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap
routines.
Once the core functions return successfully, the rockchip mmap routines
can still use dma_mmap_attrs() to simply mmap the entire buffer.
[0] Previously, we were performing the mmap() without first taking a
reference on the underlying gem buffer. This could leak ptes if the gem
object is destroyed while userspace is still holding the mapping.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Thu, 16 Jul 2015 14:17:09 +0000 (10:17 -0400)]
drm/radeon/ci: silence a harmless PCC warning
commit
bda5e3e97ffe80c5a793383df5681d3581d46ac8 upstream.
This has been a source of confusion. Make it debug only.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Tue, 14 Jul 2015 13:58:30 +0000 (15:58 +0200)]
drm/radeon: fix user ptr race condition
commit
12f1384da650bdb835fff63e66fe815ea882fc0e upstream.
Port of amdgpu patch
9298e52f8b51d1e4acd68f502832f3a97f8cf892.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 10 Jul 2015 01:08:17 +0000 (21:08 -0400)]
drm/radeon: add a dpm quirk for Sapphire Radeon R9 270X 2GB GDDR5
commit
5dfc71bc44d91d1620505c064fa22b0b3db58a9d 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>
Michel Dänzer [Fri, 3 Jul 2015 01:02:27 +0000 (10:02 +0900)]
drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL
commit
233709d2cd6bbaaeda0aeb8d11f6ca7f98563b39 upstream.
This can be the case when the GPU is powered off, e.g. via vgaswitcheroo
or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin
flushes the TLB after setting rdev->gart.ptr to non-NULL.
Fixes panic on powering off R7xx GPUs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Grigori Goronzy [Tue, 7 Jul 2015 07:27:29 +0000 (16:27 +0900)]
drm/radeon: unpin cursor BOs on suspend and pin them again on resume (v2)
commit
f3cbb17bcf676a2fc6aedebe9fbebd59e550c51a upstream.
Everything is evicted from VRAM before suspend, so we need to make
sure all BOs are unpinned and re-pinned after resume. Fixes broken
mouse cursor after resume introduced by commit
b9729b17.
[Michel Dänzer: Add pinning BOs on resume]
v2:
[Alex Deucher: merge cursor unpin into fb unpin loop]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Signed-off-by: Grigori Goronzy <greg@chown.ath.cx>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michel Dänzer [Tue, 7 Jul 2015 07:27:28 +0000 (16:27 +0900)]
drm/radeon: Clean up reference counting and pinning of the cursor BOs
commit
cd404af0c930104462aa91344f07d002cf8248ed upstream.
Take a GEM reference for and pin the new cursor BO, unpin and drop the
GEM reference for the old cursor BO in radeon_crtc_cursor_set2, and use
radeon_crtc->cursor_addr in radeon_set_cursor.
This fixes radeon_cursor_reset accidentally incrementing the cursor BO
pin count, and cleans up the code a little.
Reviewed-by: Grigori Goronzy <greg@chown.ath.cx>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mario Kleiner [Fri, 3 Jul 2015 04:03:06 +0000 (06:03 +0200)]
drm/radeon: Handle irqs only based on irq ring, not irq status regs.
commit
07f18f0bb8d8d65badd8b4988b40d329fc0cc6dc upstream.
Trying to resolve issues with missed vblanks and impossible
values inside delivered kms pageflip completion events showed
that radeon's irq handling sometimes doesn't handle valid irqs,
but silently skips them. This was observed for vblank interrupts.
Although those irqs have corresponding events queued in the gpu's
irq ring at time of interrupt, and therefore the corresponding
handling code gets triggered by these events, the handling code
sometimes silently skipped processing the irq. The reason for those
skips is that the handling code double-checks for each irq event if
the corresponding irq status bits in the irq status registers
are set. Sometimes those bits are not set at time of check
for valid irqs, maybe due to some hardware race on some setups?
The problem only seems to happen on some machine + card combos
sometimes, e.g., never happened during my testing of different PC
cards of the DCE-2/3/4 generation a year ago, but happens consistently
now on two different Apple Mac cards (RV730, DCE-3, Apple iMac and
Evergreen JUNIPER, DCE-4 in a Apple MacPro). It also doesn't happen
at each interrupt but only occassionally every couple of
hundred or thousand vblank interrupts.
This results in XOrg warning messages like
"[ 7084.472] (WW) RADEON(0): radeon_dri2_flip_event_handler:
Pageflip completion event has impossible msc 420120 < target_msc 420121"
as well as skipped frames and problems for applications that
use kms pageflip events or vblank events, e.g., users of DRI2 and
DRI3/Present, Waylands Weston compositor, etc. See also
https://bugs.freedesktop.org/show_bug.cgi?id=85203
After some talking to Alex and Michel, we decided to fix this
by turning the double-check for asserted irq status bits into a
warning. Whenever a irq event is queued in the IH ring, always
execute the corresponding interrupt handler. Still check the irq
status bits, but only to log a DRM_DEBUG message on a mismatch.
This fixed the problems reliably on both previously failing
cards, RV-730 dual-head tested on both crtcs (pipes D1 and D2)
and a triple-output Juniper HD-5770 card tested on all three
available crtcs (D1/D2/D3). The r600 and evergreen irq handling
is therefore tested, but the cik an si handling is only compile
tested due to lack of hw.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
CC: Michel Dänzer <michel.daenzer@amd.com>
CC: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Grigori Goronzy [Thu, 2 Jul 2015 23:54:11 +0000 (01:54 +0200)]
drm/radeon: fix HDP flushing
commit
54e03986133468e02cb01b76215e4d53a9cf6380 upstream.
This was regressed by commit
39e7f6f8, although I don't know of any
actual issues caused by it.
The storage domain is read without TTM locking now, but the lock
never helped to prevent any races.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Grigori Goronzy <greg@chown.ath.cx>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 30 Jun 2015 13:30:01 +0000 (09:30 -0400)]
drm/radeon: only check the sink type on DP connectors
commit
479e9a95120aaae0bf0d3e0b5b26b36ac4a347b6 upstream.
Avoids a crash on pre-DP asics that support HDMI.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 29 Jun 2015 15:09:11 +0000 (11:09 -0400)]
Revert "drm/radeon: dont switch vt on suspend"
commit
ac9134906b3f5c2b45dc80dab0fee792bd516d52 upstream.
This reverts commit
b9729b17a414f99c61f4db9ac9f9ed987fa0cbfe.
This seems to break the cursor on resume for lots of systems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jérôme Glisse [Fri, 19 Jun 2015 14:32:16 +0000 (10:32 -0400)]
drm/radeon: SDMA fix hibernation (CI GPU family).
commit
2ba8d1bb8f6b589037f7db1f01144fc80750e8f7 upstream.
In order for hibernation to reliably work we need to properly turn
off the SDMA block, sadly after numerous attemps i haven't not found
proper sequence for clean and full shutdown. So simply reset both
SDMA block, this makes hibernation works reliably on sea island GPU
family (CI)
Hibernation and suspend to ram were tested (several times) on :
Bonaire
Hawaii
Mullins
Kaveri
Kabini
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jérôme Glisse [Fri, 19 Jun 2015 14:32:15 +0000 (10:32 -0400)]
drm/radeon: compute ring fix hibernation (CI GPU family) v2.
commit
161569deaa03cf3c00ed63352006193f250b0648 upstream.
In order for hibernation to reliably work we need to cleanup more
thoroughly the compute ring. Hibernation is different from suspend
resume as when we resume from hibernation the hardware is first
fully initialize by regular kernel then freeze callback happens
(which correspond to a suspend inside the radeon kernel driver)
and turn off each of the block. It turns out we were not cleanly
shutting down the compute ring. This patch fix that.
Hibernation and suspend to ram were tested (several times) on :
Bonaire
Hawaii
Mullins
Kaveri
Kabini
Changed since v1:
- Factor the ring stop logic into a function taking ring as arg.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Thu, 16 Jul 2015 11:37:56 +0000 (12:37 +0100)]
drm/i915: Use two 32bit reads for select 64bit REG_READ ioctls
commit
648a9bc5308d952f2c80772301b339f73026f013 upstream.
Since the hardware sometimes mysteriously totally flummoxes the 64bit
read of a 64bit register when read using a single instruction, split the
read into two instructions. Since the read here is of automatically
incrementing timestamp counters, we also have to be very careful in
order to make sure that it does not increment between the two
instructions.
However, since userspace tried to workaround this issue and so enshrined
this ABI for a broken hardware read and in the process neglected that
the read only fails in some environments, we have to introduce a new
uABI flag for userspace to request the 2x32 bit accurate read of the
timestamp.
v2: Fix alignment check and include details of the workaround for
userspace.
Reported-by: Karol Herbst <freedesktop@karolherbst.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91317
Testcase: igt/gem_reg_read
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Tested-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Tue, 14 Jul 2015 10:29:27 +0000 (12:29 +0200)]
Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations"
commit
d82c0ba6e306f079407f07003e53c262d683397b upstream.
This reverts commit
19ee835cdb0b5a8eb11a68f25a51b8039d564488.
It breaks existing old userspace which doesn't handle UNKNOWN
swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably
still is on some other platforms, but it still pretty clearly broke
the testers machine. If we want this we need to extend the ioctl with
new paramters that only new userspace looks at.
Cc: Harald Arnesen <harald@skogtun.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Harald Arnesen <harald@skogtun.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tvrtko Ursulin [Mon, 13 Jul 2015 15:51:39 +0000 (16:51 +0100)]
drm/i915: Forward all core DRM ioctls to core compat handling
commit
ac7e7ab1c3243b10b41653cc8d8536088d83b152 upstream.
Previously only core DRM ioctls under the DRM_COMMAND_BASE were being
forwarded, but the drm.h header suggests (and reality confirms) ones
after (and including) DRM_COMMAND_END should be forwarded as well.
We need this to correctly forward the compat ioctl for the botched-up
addfb2.1 extension.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
[danvet: Explain why this is suddenly needed and add cc: stable.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomas Elf [Thu, 9 Jul 2015 14:30:57 +0000 (15:30 +0100)]
drm/i915: Snapshot seqno of most recently submitted request.
commit
94f7bbe1509731bdef651d7fb235b2c31fb23be8 upstream.
The hang checker needs to inspect whether or not the ring request list is empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the struct_mutex, which is required in order to safely inspect requests since
requests might be deallocated during inspection. In the past we've had kernel
panics due to this very unsynchronized access in the hang checker.
One solution to this problem is to not inspect the requests directly since
we're only interested in the seqno of the most recently submitted request - not
the request itself. Instead the seqno of the most recently submitted request is
stored separately, which the hang checker then inspects, circumventing the
issue of synchronization from the hang checker entirely.
This fixes a regression introduced in
commit
44cdd6d219bc64f6810b8ed0023a4d4db9e0fe68
Author: John Harrison <John.C.Harrison@Intel.com>
Date: Mon Nov 24 18:49:40 2014 +0000
drm/i915: Convert 'ring_idle()' to use requests not seqnos
v2 (Chris Wilson):
- Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() rather
than compute it over again.
- Remove extra whitespace.
Issue: VIZ-5998
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regressing commit citation provided by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Mon, 29 Jun 2015 13:01:19 +0000 (14:01 +0100)]
drm/i915: Declare the swizzling unknown for L-shaped configurations
commit
19ee835cdb0b5a8eb11a68f25a51b8039d564488 upstream.
The old style of memory interleaving swizzled upto the end of the
first even bank of memory, and then used the remainder as unswizzled on
the unpaired bank - i.e. swizzling is not constant for all memory. This
causes problems when we try to migrate memory and so the kernel prevents
migration at all when we detect L-shaped inconsistent swizzling.
However, this issue also extends to userspace who try to manually detile
into memory as the swizzling for an individual page is unknown (it
depends on its physical address only known to the kernel), userspace
cannot correctly swizzle objects.
v2: Mark the global swizzling as unknown rather than adjust the value
reported to userspace.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91105
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jani Nikula [Fri, 26 Jun 2015 11:18:56 +0000 (14:18 +0300)]
drm/i915: fix backlight after resume on 855gm
commit
2059ac3b1304cb6a82f9d90762dea9f556831627 upstream.
Some 855gm models (at least ThinkPad X40) regressed because of
commit
b0cd324faed23d10d66ba6ade66579c681feef6f
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Nov 12 16:25:43 2014 +0200
drm/i915: don't save/restore backlight hist ctl registers
which tried to make our driver more robust by not blindly saving and
restoring registers, but it failed to take into account
commit
0eb96d6ed38430b72897adde58f5477a6b71757a
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Wed Oct 14 12:33:41 2009 -0700
drm/i915: save/restore BLC histogram control reg across suspend/resume
Fix the regression by enabling hist ctl on gen2.
v2: Improved the comment.
v3: Improved the comment, again.
Reported-and-tested-by: Philipp Gesang <phg@phi-gamma.net>
References: http://mid.gmane.org/
20150623222648.GD12335@acheron
Fixes:
b0cd324faed2 ("drm/i915: don't save/restore backlight hist ctl registers")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rodrigo Vivi [Thu, 28 May 2015 18:07:11 +0000 (11:07 -0700)]
drm/i915: Fix IPS related flicker
commit
ac88cd738425e04dbed3706621cf613a00708834 upstream.
We cannot let IPS enabled with no plane on the pipe:
BSpec: "IPS cannot be enabled until after at least one plane has
been enabled for at least one vertical blank." and "IPS must be
disabled while there is still at least one plane enabled on the
same pipe as IPS." This restriction apply to HSW and BDW.
However a shortcut path on update primary plane function
to make primary plane invisible by setting DSPCTRL to 0
was leting IPS enabled while there was no
other plane enabled on the pipe causing flickerings that we were
believing that it was caused by that other restriction where
ips cannot be used when pixel rate is greater than 95% of cdclok.
v2: Don't mess with Atomic path as pointed out by Ville.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85583
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michel Thierry [Thu, 25 Jun 2015 11:59:38 +0000 (12:59 +0100)]
drm/i915/ppgtt: Break loop in gen8_ppgtt_clear_range failure path
commit
00245266b4be4fbe989ee073663f56716da6c1f3 upstream.
If for some reason [1], the page directory/table does not exist, clear_range
would end up in an infinite while loop.
Introduced by commit
06fda602dbca ("drm/i915: Create page table allocators").
[1] This is already being addressed in one of Mika's patches:
http://mid.gmane.org/
1432314314-23530-17-git-send-email-mika.kuoppala@intel.com
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reported-by: John Harrison <john.c.harrison@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 18 May 2015 15:11:48 +0000 (11:11 -0400)]
drm/radeon: clean up radeon_audio_enable
commit
010621936103fcfc15375ccdc92c0f583923d489 upstream.
- make it static
- fix mask/bool handling for last param
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 15 May 2015 15:48:52 +0000 (11:48 -0400)]
drm/radeon: take the mode_config mutex when dealing with hpds (v2)
commit
39fa10f7e21574a70cecf1fed0f9b36535aa68a0 upstream.
Since we are messing with state in the worker.
v2: drop the changes in the mst worker
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrey Ryabinin [Mon, 25 May 2015 10:29:44 +0000 (13:29 +0300)]
drm/atomic: fix out of bounds read in for_each_*_in_state helpers
commit
60f207a5b6d8f23c2e8388b415e8d5c7311cc79d upstream.
for_each_*_in_state validate array index after
access to array elements, thus perform out of bounds read.
Fix this by validating index in the first place and read
array element iff validation was successful.
Fixes:
df63b9994eaf ("drm/atomic: Add for_each_{connector,crtc,plane}_in_state helper macros")
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Tue, 5 May 2015 16:32:17 +0000 (18:32 +0200)]
drm/bridge: ptn3460: Include linux/gpio/consumer.h
commit
dad3c3503462f59c6bec7edfa19dbde1857962c0 upstream.
If GPIOLIB=n and asm-generic/gpio.h is not used:
drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_pre_enable’:
drivers/gpu/drm/bridge/ptn3460.c:135: error: implicit declaration of function ‘gpiod_set_value’
drivers/gpu/drm/bridge/ptn3460.c: In function ‘ptn3460_probe’:
drivers/gpu/drm/bridge/ptn3460.c:333: error: implicit declaration of function ‘devm_gpiod_get’
drivers/gpu/drm/bridge/ptn3460.c:333: warning: assignment makes pointer from integer without a cast
drivers/gpu/drm/bridge/ptn3460.c:340: error: implicit declaration of function ‘gpiod_direction_output’
drivers/gpu/drm/bridge/ptn3460.c:346: warning: assignment makes pointer from integer without a cast
Add the missing #include <linux/gpio/consumer.h> to fix this.
Fixes:
af478d8823 ("drm/bridge: ptn3460: use gpiod interface")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frediano Ziglio [Wed, 3 Jun 2015 11:09:10 +0000 (12:09 +0100)]
drm/qxl: Do not leak memory if qxl_release_list_add fails
commit
8451cc964c1d193b989c41a44e5e77109cc696f8 upstream.
If the function fails reference counter to the object is not decremented
causing leaks.
This is hard to spot as it happens only on very low memory situations.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frediano Ziglio [Wed, 3 Jun 2015 11:09:09 +0000 (12:09 +0100)]
drm/qxl: Do not cause spice-server to clean our objects
commit
2fa19535ca6abcbfd1ccc9ef694db52f49f77747 upstream.
If objects are moved back from system memory to VRAM (and spice id
created again) memory is already initialized so we need to set flag
to not clear memory.
If you don't do it after a while using desktop many images turns to
black or transparents.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thierry Reding [Thu, 11 Jun 2015 16:33:48 +0000 (18:33 +0200)]
drm/tegra: dpaux: Fix transfers larger than 4 bytes
commit
3c1dae0a07c651526f8e878d223a88f82caa5a50 upstream.
The DPAUX read/write FIFO registers aren't sequential in the register
space, causing transfers larger than 4 bytes to cause accesses to non-
existing FIFO registers.
Fixes:
6b6b604215c6 ("drm/tegra: Add eDP support")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Mon, 22 Jun 2015 07:31:59 +0000 (17:31 +1000)]
drm/dp/mst: make sure mst_primary mstb is valid in work function
commit
9254ec496a1dbdddeab50021a8138dc627a8166a upstream.
This validates the mst_primary under the lock, and then calls
into the check and send function. This makes the code a lot
easier to understand the locking rules in.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Airlie [Mon, 22 Jun 2015 04:40:44 +0000 (14:40 +1000)]
drm/dp/mst: take lock around looking up the branch device on hpd irq
commit
9eb1e57f564d4e6e10991402726cc83fe0b9172f upstream.
If we are doing an MST transaction and we've gotten HPD and we
lookup the device from the incoming msg, we should take the mgr
lock around it, so that mst_primary and mstb->ports are valid.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Airlie [Mon, 15 Jun 2015 00:34:28 +0000 (10:34 +1000)]
drm/dp/mst: close deadlock in connector destruction.
commit
6b8eeca65b18ae77e175cc2b6571731f0ee413bf upstream.
I've only seen this once, and I failed to capture the
lockdep backtrace, but I did some investigations.
If we are calling into the MST layer from EDID probing,
we have the mode_config mutex held, if during that EDID
probing, the MST hub goes away, then we can get a deadlock
where the connector destruction function in the driver
tries to retake the mode config mutex.
This offloads connector destruction to a workqueue,
and avoid the subsequenct lock ordering issue.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Tue, 23 Jun 2015 14:35:06 +0000 (16:35 +0200)]
drm/vgem: Set unique to "vgem"
commit
fa2f97dd33c2c32a06a5ea7f6e87af06a2e26baa upstream.
Since there's only one global instance ever we don't need to have
anything fancy. Stops a WARNING in the get_unique ioctl that the
unique name isn't set.
Reportedy-and-tested-by: Fabio Coatti <fabio.coatti@gmail.com>
Cc: Fabio Coatti <fabio.coatti@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pawel Moll [Thu, 2 Apr 2015 17:50:32 +0000 (18:50 +0100)]
bus: arm-ccn: Fix node->XP config conversion
commit
a18f8e97fe69195823d7fb5c68a8d6565f39db4b upstream.
Events defined as watchpoints on nodes must have their config values
converted so that they apply to the respective node's XP. The
function setting new values was using wrong mask for the "port" field,
resulting in corrupted value. Fixed now.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Boris Brezillon [Wed, 17 Jun 2015 08:59:05 +0000 (10:59 +0200)]
ARM: at91/dt: update udc compatible strings
commit
6540165cf41655810ee67b78f01537af022a636a upstream.
at91sam9g45, at91sam9x5 and sama5 SoCs should not use
"atmel,at91sam9rl-udc" for their USB device compatible property since
this compatible is attached to a specific hardware bug fix.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Tested-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Ferre [Wed, 17 Jun 2015 08:59:04 +0000 (10:59 +0200)]
ARM: at91/dt: trivial: fix USB udc compatible string
commit
50f0a44991516b5b9744ecb2c080c2ec6ad21b25 upstream.
To please checkpatch and the tiresome reader, add the "atmel," prefix to the
USB udc compatible string.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Ferre [Mon, 11 May 2015 11:00:31 +0000 (13:00 +0200)]
tty/serial: at91: RS485 mode: 0 is valid for delay_rts_after_send
commit
8687634b7908c42eb700e0469e110e02833611d1 upstream.
In RS485 mode, we may want to set the delay_rts_after_send value to 0.
In the datasheet, the 0 value is said to "disable" the Transmitter Timeguard but
this is exactly the expected behavior if we want no delay...
Moreover, if the value was set to non-zero value by device-tree or earlier
ioctl command, it was impossible to change it back to zero.
Reported-by: Sami Pietikäinen <Sami.Pietikainen@wapice.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ludovic.desroches@atmel.com [Mon, 8 Jun 2015 13:55:48 +0000 (15:55 +0200)]
ARM: at91/dt: sama5d4: fix dma conf for aes, sha and tdes nodes
commit
aabbe8f1a561dd8318e693830d9ae377c9a04d2b upstream.
The xdmac channel configuration is done in one cell not two. This error
prevents from probing devices correctly.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Fixes:
83906783b766 ("ARM: at91/dt: sama5d4: add aes, sha and tdes nodes")
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ludovic Desroches [Thu, 28 May 2015 09:55:16 +0000 (11:55 +0200)]
ARM: at91/dt: sama5d4ek: mci0 uses slot 0
commit
ea25525ce0d195724fead07fe6562fe478a3bf6f upstream.
Mci0 uses slot 0 not 1.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Fixes:
7a4752677c44 ("ARM: at91: dt: add device tree file for SAMA5D4ek board")
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin K. Petersen [Wed, 22 Jul 2015 11:57:12 +0000 (07:57 -0400)]
block: Do a full clone when splitting discard bios
commit
f3f5da624e0a891c34d8cd513c57f1d9b0c7dadc upstream.
This fixes a data corruption bug when using discard on top of MD linear,
raid0 and raid10 personalities.
Commit
20d0189b1012 "block: Introduce new bio_split()" permits sharing
the bio_vec between the two resulting bios. That is fine for read/write
requests where the bio_vec is immutable. For discards, however, we need
to be able to attach a payload and update the bio_vec so the page can
get mapped to a scatterlist entry. Therefore the bio_vec can not be
shared when splitting discards and we must do a full clone.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reported-by: Seunguk Shin <seunguk.shin@samsung.com>
Tested-by: Seunguk Shin <seunguk.shin@samsung.com>
Cc: Seunguk Shin <seunguk.shin@samsung.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Tue, 5 May 2015 11:49:55 +0000 (19:49 +0800)]
block: loop: avoiding too many pending per work I/O
commit
4d4e41aef9429872ea3b105e83426941f7185ab6 upstream.
If there are too many pending per work I/O, too many
high priority work thread can be generated so that
system performance can be effected.
This patch limits the max_active parameter of workqueue as 16.
This patch fixes Fedora 22 live booting performance
regression when it is booted from squashfs over dm
based on loop, and looks the following reasons are
related with the problem:
- not like other filesyststems(such as ext4), squashfs
is a bit special, and I observed that increasing I/O jobs
to access file in squashfs only improve I/O performance a
little, but it can make big difference for ext4
- nested loop: both squashfs.img and ext3fs.img are mounted
as loop block, and ext3fs.img is inside the squashfs
- during booting, lots of tasks may run concurrently
Fixes:
b5dd2f6047ca108001328aac0e8588edd15f1778
Cc: Justin M. Forbes <jforbes@fedoraproject.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Tue, 5 May 2015 11:49:54 +0000 (19:49 +0800)]
block: loop: convert to per-device workqueue
commit
f4aa4c7bbac6c4afdd4adccf90898c1a3685396d upstream.
Documentation/workqueue.txt:
If there is dependency among multiple work items used
during memory reclaim, they should be queued to separate
wq each with WQ_MEM_RECLAIM.
Loop devices can be stacked, so we have to convert to per-device
workqueue. One example is Fedora live CD.
Fixes:
b5dd2f6047ca108001328aac0e8588edd15f1778
Cc: Justin M. Forbes <jforbes@fedoraproject.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomas Winkler [Thu, 16 Jul 2015 13:50:45 +0000 (15:50 +0200)]
mmc: block: Add missing mmc_blk_put() in power_ro_lock_show()
commit
9098f84cced870f54d8c410dd2444cfa61467fa0 upstream.
Enclosing mmc_blk_put() is missing in power_ro_lock_show() sysfs handler,
let's add it.
Fixes:
add710eaa886 ("mmc: boot partition ro lock support")
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Thornber [Fri, 3 Jul 2015 13:51:32 +0000 (14:51 +0100)]
dm btree: silence lockdep lock inversion in dm_btree_del()
commit
1c7518794a3647eb345d59ee52844e8a40405198 upstream.
Allocate memory using GFP_NOIO when deleting a btree. dm_btree_del()
can be called via an ioctl and we don't want to recurse into the FS or
block layer.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Thornber [Fri, 3 Jul 2015 09:22:42 +0000 (10:22 +0100)]
dm thin: allocate the cell_sort_array dynamically
commit
a822c83e47d97cdef38c4352e1ef62d9f46cfe98 upstream.
Given the pool's cell_sort_array holds 8192 pointers it triggers an
order 5 allocation via kmalloc. This order 5 allocation is prone to
failure as system memory gets more fragmented over time.
Fix this by allocating the cell_sort_array using vmalloc.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dennis Yang [Fri, 26 Jun 2015 14:25:48 +0000 (15:25 +0100)]
dm btree remove: fix bug in redistribute3
commit
4c7e309340ff85072e96f529582d159002c36734 upstream.
redistribute3() shares entries out across 3 nodes. Some entries were
being moved the wrong way, breaking the ordering. This manifested as a
BUG() in dm-btree-remove.c:shift() when entries were removed from the
btree.
For additional context see:
https://www.redhat.com/archives/dm-devel/2015-May/msg00113.html
Signed-off-by: Dennis Yang <shinrairis@gmail.com>
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Thornber [Wed, 17 Jun 2015 12:35:19 +0000 (13:35 +0100)]
dm space map metadata: fix occasional leak of a metadata block on resize
commit
6096d91af0b65a3967139b32d5adbb3647858a26 upstream.
The metadata space map has a simplified 'bootstrap' mode that is
operational when extending the space maps. Whilst in this mode it's
possible for some refcount decrement operations to become queued (eg, as
a result of shadowing one of the bitmap indexes). These decrements were
not being applied when switching out of bootstrap mode.
The effect of this bug was the leaking of a 4k metadata block. This is
detected by the latest version of thin_check as a non fatal error.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Fri, 5 Jun 2015 13:50:42 +0000 (09:50 -0400)]
dm stats: fix divide by zero if 'number_of_areas' arg is zero
commit
dd4c1b7d0c95be1c9245118a3accc41a16f1db67 upstream.
If the number_of_areas argument was zero the kernel would crash on
div-by-zero. Add better input validation.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Thornber [Wed, 20 May 2015 09:30:32 +0000 (10:30 +0100)]
dm cache: fix race when issuing a POLICY_REPLACE operation
commit
fb4100ae7f312c3d614b37621c2b17b3b7cf65f8 upstream.
There is a race between a policy deciding to replace a cache entry,
the core target writing back any dirty data from this block, and other
IO threads doing IO to the same block.
This sort of problem is avoided most of the time by the core target
grabbing a bio prison cell before making the request to the policy.
But for a demotion the core target doesn't know which block will be
demoted, so can't do this in advance.
Fix this demotion race by introducing a callback to the policy interface
that allows the policy to grab the cell on behalf of the core target.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AMAN DEEP [Tue, 21 Jul 2015 14:20:27 +0000 (17:20 +0300)]
usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function
commit
3496810663922617d4b706ef2780c279252ddd6a upstream.
virt_dev->num_cached_rings counts on freed ring and is not updated
correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring
is added into cache and then num_rings_cache is incremented as below:
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
virt_dev->num_rings_cached++;
here, free ring pointer is added to a current index and then
index is incremented.
So current index always points to empty location in the ring cache.
For getting available free ring, current index should be decremented
first and then corresponding ring buffer value should be taken from ring
cache.
But In function xhci_endpoint_init(), the num_rings_cached index is
accessed before decrement.
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
virt_dev->num_rings_cached--;
This is bug in manipulating the index of ring cache.
And it should be as below:
virt_dev->num_rings_cached--;
virt_dev->eps[ep_index].new_ring =
virt_dev->ring_cache[virt_dev->num_rings_cached];
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
Signed-off-by: Aman Deep <aman.deep@samsung.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lu Baolu [Tue, 16 Jun 2015 01:08:26 +0000 (09:08 +0800)]
usb: core: lpm: set lpm_capable for root hub device
commit
2d2a316765d956bc5cb6bb367b2ec52ca59ab8e9 upstream.
Commit
25cd2882e2fc ("usb/xhci: Change how we indicate a host supports
Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
internal field, a.k.a. lpm_capable, and let usb core to set it by
checking U1 and U2 exit latency values in the descriptor.
Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately,
root hub is a special usb device as it has no parent. Hub_port_init()
will never be called for a root hub device. That means lpm_capable will
by no means be set for the root hub. As the result, lpm isn't functional
at all in Linux kernel.
This patch add the code to check and set lpm_capable when registering a
root hub device. It could be back-ported to kernels as old as v3.15,
that contains the Commit
25cd2882e2fc ("usb/xhci: Change how we indicate
a host supports Link PM.").
Reported-by: Kevin Strasser <kevin.strasser@linux.intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Tue, 30 Jun 2015 15:25:54 +0000 (11:25 -0400)]
USB: OHCI: Fix race between ED unlink and URB submission
commit
7d8021c967648accd1b78e5e1ddaad655cd2c61f upstream.
This patch fixes a bug introduced by commit
977dcfdc6031 ("USB: OHCI:
don't lose track of EDs when a controller dies"). The commit changed
ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
been called. The user-visible consequence is that the driver
occasionally crashes or locks up when an URB is submitted while
another URB for the same endpoint is being unlinked.
This patch moves the ED state change later, to the right place. The
drawback is that now we may unnecessarily execute some instructions
multiple times when a controller dies. Since controllers dying is an
exceptional occurrence, a little wasted time won't matter.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Heiko Przybyl <lil_tux@web.de>
Tested-by: Heiko Przybyl <lil_tux@web.de>
Fixes:
977dcfdc60311e7aa571cabf6f39c36dde13339e
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Thumshirn [Wed, 8 Jul 2015 15:26:37 +0000 (17:26 +0200)]
USB: serial: Destroy serial_minors IDR on module exit
commit
d23f47d4927fd2f61b3a754d83c7bcec215b5cfe upstream.
Destroy serial_minors IDR on module exit, reclaiming the allocated memory.
This was detected by the following semantic patch (written by Luis
Rodriguez <mcgrof@suse.com>)
<SmPL>
@ defines_module_init @
declarer name module_init, module_exit;
declarer name DEFINE_IDR;
identifier init;
@@
module_init(init);
@ defines_module_exit @
identifier exit;
@@
module_exit(exit);
@ declares_idr depends on defines_module_init && defines_module_exit @
identifier idr;
@@
DEFINE_IDR(idr);
@ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
identifier declares_idr.idr, defines_module_exit.exit;
@@
exit(void)
{
...
idr_destroy(&idr);
...
}
@ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
identifier declares_idr.idr, defines_module_exit.exit;
@@
exit(void)
{
...
+idr_destroy(&idr);
}
</SmPL>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Claudio Cappelli [Wed, 10 Jun 2015 18:38:30 +0000 (20:38 +0200)]
USB: option: add 2020:4000 ID
commit
f6d7fb37f92622479ef6da604f27561f5045ba1e upstream.
Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000.
T: Bus=01 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2020 ProdID=4000 Rev=03.00
S: Manufacturer=Network Connect
S: Product=MT6225
C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
Signed-off-by: Claudio Cappelli <claudio.cappelli.linux@gmail.com>
Suggested-by: Lars Melin <larsm17@gmail.com>
[johan: amend commit message with devices info ]
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Sanford [Fri, 26 Jun 2015 00:40:05 +0000 (17:40 -0700)]
USB: cp210x: add ID for Aruba Networks controllers
commit
f98a7aa81eeeadcad25665c3501c236d531d4382 upstream.
Add the USB serial console device ID for Aruba Networks 7xxx series
controllers which have a USB port for their serial console.
Signed-off-by: Peter Sanford <peter@sanford.io>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe Balbi [Tue, 2 Jun 2015 18:03:36 +0000 (13:03 -0500)]
usb: musb: host: rely on port_mode to call musb_start()
commit
be9d39881fc4fa39a64b6eed6bab5d9ee5125344 upstream.
Currently, we're calling musb_start() twice for DRD ports
in some situations. This has been observed to cause enumeration
issues after suspend/resume cycles with AM335x.
In order to fix the problem, we just have to fix the check
on musb_has_gadget() so that it only returns true if
current mode is Host and ignore the fact that we have or
not a gadget driver loaded.
Fixes:
ae44df2e21b5 (usb: musb: call musb_start() only once in OTG mode)
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michal Nazarewicz [Fri, 19 Jun 2015 21:56:34 +0000 (23:56 +0200)]
usb: f_mass_storage: limit number of reported LUNs
commit
8515bac01a983d277148e4fcc5f235bf603de577 upstream.
Mass storage function created via configfs always reports eight LUNs
to the hosts even if only one LUN has been configured. Adjust the
number when the USB function is allocated based on LUNs that user
has created.
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Khoroshilov [Sun, 19 Jul 2015 16:13:28 +0000 (23:13 +0700)]
usb: gadget: mv_udc_core: fix phy_regs I/O memory leak
commit
53e20f2eb161fbe9eea28b54dccc870cec94eca2 upstream.
There was an omission in transition to devm_xxx resource handling.
iounmap(udc->phy_regs) were removed, but ioremap() was left
without devm_.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Fixes:
3517c31a8ece6 ("usb: gadget: mv_udc: use devm_xxx for probe")
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rui Miguel Silva [Mon, 18 May 2015 15:02:07 +0000 (16:02 +0100)]
usb: gadget: f_fs: do not set cancel function on synchronous {read,write}
commit
4088acf1e845aba35f30fb91dee10649edbd0e84 upstream.
do not try to set cancel function in synchronous operations in
ffs_epfile_{read,write}_iter.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kishon Vijay Abraham I [Thu, 11 Jun 2015 16:42:11 +0000 (22:12 +0530)]
usb: gadget: composite: Fix NULL pointer dereference
commit
b4c21f0bdd2c0cd5d5be1bb56f0a28dae5041eed upstream.
commit
f563d230903210acc ("usb: gadget: composite: add req_match method
to usb_function") accesses cdev->config even before set config
is invoked causing a NULL pointer dereferencing error while running
Lecroy Mass Storage Compliance test.
Fix it here by accessing cdev->config only if it is non NULL.
Fixes: commit
f563d230903210acc ("usb: gadget: composite: add req_match
method to usb_function").
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hebb [Thu, 2 Jul 2015 05:04:18 +0000 (01:04 -0400)]
phy: berlin-usb: fix divider for BG2CD
commit
96696a9df935d15fd2e89603454c20a692ec232a upstream.
The marvell,berlin2cd-usb-phy compatible incorrectly sets the PLL
divider to BG2's value instead of BG2CD/BG2Q's. Change it to the right
value.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Wahren [Mon, 15 Jun 2015 04:37:00 +0000 (04:37 +0000)]
usb: phy: mxs: suspend to RAM causes NULL pointer dereference
commit
543aa4867d4a2dff5fc11e1b688197ee3bad7f89 upstream.
Triggering suspend to RAM via sysfs on a i.MX28 causes a NULL pointer
dereference. This patch avoids the oops in mxs_phy_get_vbus_status()
by aborting since there is no syscon available.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Fixes:
efdbd3a5d6e ("usb: phy: mxs: do not set PWD.RXPWD1PT1 for low speed connection")
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Thu, 16 Apr 2015 08:03:04 +0000 (18:03 +1000)]
phy: twl4030-usb: remove incorrect pm_runtime_get_sync() in probe function.
commit
4724e27114c4a7eceeee07db227a17fcab6f165c upstream.
The USB phy should initialize with power-off, and will be powered on
by the USB system when a cable connection is detected.
Having this pm_runtime_get_sync() during probe causes the phy to
*always* be powered on.
Removing it returns to sensible power management.
Fixes:
96be39ab34b77c6f6f5cd6ae03aac6c6449ee5c4
Signed-off-by: NeilBrown <neil@brown.name>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Mon, 18 May 2015 12:29:51 +0000 (15:29 +0300)]
USB: devio: fix a condition in async_completed()
commit
83ed07c5db71bc02bd646d6eb60b48908235cdf9 upstream.
Static checkers complain that the current condition is never true. It
seems pretty likely that it's a typo and "URB" was intended instead of
"USB".
Fixes:
3d97ff63f899 ('usbdevfs: Use scatter-gather lists for large bulk transfers')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robert Schlabbach [Mon, 25 May 2015 22:27:30 +0000 (00:27 +0200)]
usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset
commit
fb6d1f7df5d25299fd7b3e84b72b8851d3634764 upstream.
Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.
Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().
Verbose Problem Description:
USB 3.0 devices may be "lost for good" during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.
The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following "warm" reset.
However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the "preliminary" status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of
USB_STATE_NOTATTACHED state.
Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.
Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Youn [Mon, 17 Sep 2001 07:00:00 +0000 (00:00 -0700)]
usb: dwc3: Reset the transfer resource index on SET_INTERFACE
commit
aebda618718157a69c0dc0adb978d69bc2b8723c upstream.
This fixes an issue introduced in commit
b23c843992b6 (usb: dwc3:
gadget: fix DEPSTARTCFG for non-EP0 EPs) that made sure we would
only use DEPSTARTCFG once per SetConfig.
The trick is that we should use one DEPSTARTCFG per SetConfig *OR*
SetInterface. SetInterface was completely missed from the original
patch.
This problem became aparent after commit
76e838c9f776 (usb: dwc3:
gadget: return error if command sent to DEPCMD register fails)
added checking of the return status of device endpoint commands.
'Set Endpoint Transfer Resource' command was caught failing
occasionally. This is because the Transfer Resource
Index was not getting reset during a SET_INTERFACE request.
Finally, to fix the issue, was we have to do is make sure that
our start_config_issued flag gets reset whenever we receive a
SetInterface request.
To verify the problem (and its fix), all we have to do is run
test 9 from testusb with 'testusb -t 9 -s 2048 -a -c 5000'.
Tested-by: Huang Rui <ray.huang@amd.com>
Tested-by: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Fixes:
b23c843992b6 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs)
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe Balbi [Fri, 29 May 2015 15:06:38 +0000 (10:06 -0500)]
usb: dwc3: gadget: don't clear EP_BUSY too early
commit
e18b7975c885bc3a938b9a76daf32957ea0235fa upstream.
In case of non-Isochronous transfers, we don't
want to clear DWC3_EP_BUSY flag until XferComplete
event. That's because XferInProgress was only enabled
so we can recycle TRBs and usb_requests quicker, but
there are still other pending requests being transferred.
In order to make sure we don't allow for another StartTransfer
command while the HW is still processing other transfers,
we must keep DWC3_EP_BUSY flag set and this what this patch
does.
Fixes:
f3af36511e60 (usb: dwc3: gadget: always enable IOC on
bulk/interrupt transfers)
Reported-by: sundeep subbaraya <sundeep.lkml@gmail.com>
Tested-by: sundeep subbaraya <sundeep.lkml@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subbaraya Sundeep Bhatta [Thu, 21 May 2015 10:16:48 +0000 (15:46 +0530)]
usb: dwc3: gadget: return error if command sent to DEPCMD register fails
commit
76e838c9f7765f9a6205b4d558d75a66104bc60d upstream.
We need to return error to caller if command is not sent to
controller succesfully.
Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
Fixes:
72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver)
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subbaraya Sundeep Bhatta [Thu, 21 May 2015 10:16:47 +0000 (15:46 +0530)]
usb: dwc3: gadget: return error if command sent to DGCMD register fails
commit
891b1dc022955d36cf4c0f42d383226a930db7ed upstream.
We need to return error to caller if command is not sent to
controller succesfully.
Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
Fixes:
b09bb64239c8 (usb: dwc3: gadget: implement Global Command support)
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arne Fitzenreiter [Wed, 15 Jul 2015 11:54:37 +0000 (13:54 +0200)]
libata: force disable trim for SuperSSpeed S238
commit
cda57b1b05cf7b8b99ab4b732bea0b05b6c015cc upstream.
This device loses blocks, often the partition table area, on trim.
Disable TRIM.
http://pcengines.ch/msata16a.htm
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin K. Petersen [Thu, 16 Jul 2015 01:03:23 +0000 (21:03 -0400)]
libata: Do not blacklist M510DC
commit
9051bd393cf25e76dfb45409792719a854661500 upstream.
A new Micron drive was just announced, once again recycling the first
part of the model string. Add an underscore to the M510/M550 pattern to
avoid picking up the new DC drive.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Milburn [Mon, 13 Jul 2015 16:48:23 +0000 (11:48 -0500)]
libata: add ATA_HORKAGE_MAX_SEC_1024 to revert back to previous max_sectors limit
commit
af34d637637eabaf49406eb35c948cd51ba262a6 upstream.
Since no longer limiting max_sectors to BLK_DEF_MAX_SECTORS (commit
34b48db66e08),
data corruption may occur on ST380013AS drive configured on 82801JI (ICH10 Family)
SATA controller. This patch will allow the driver to limit max_sectors as before
# cat /sys/block/sdb/queue/max_sectors_kb
512
I was able to double the max_sectors_kb value up to 16384 on linux-4.2.0-rc2
before seeing corruption, but seems safer to use previous limit. Without this
patch max_sectors_kb will be 32767.
tj: Minor comment update.
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: David Milburn <dmilburn@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes:
34b48db66e08 ("block: remove artifical max_hw_sectors cap")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arne Fitzenreiter [Wed, 15 Jul 2015 11:54:36 +0000 (13:54 +0200)]
libata: add ATA_HORKAGE_NOTRIM
commit
71d126fd28de2d4d9b7b2088dbccd7ca62fad6e0 upstream.
Some devices lose data on TRIM whether queued or not. This patch adds
a horkage to disable TRIM.
tj: Collapsed unnecessary if() nesting.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin K. Petersen [Tue, 5 May 2015 01:54:19 +0000 (21:54 -0400)]
libata: Expose TRIM capability in sysfs
commit
f303074160d3401970ccae082014e1ee5a9a52c5 upstream.
Create a sysfs "trim" attribute for each ata_device that displays
whether DSM TRIM is "unsupported", "unqueued", "forced_unqueued"
(blacklisted) or "queued".
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin K. Petersen [Tue, 5 May 2015 01:54:21 +0000 (21:54 -0400)]
libata: Fall back to unqueued READ LOG EXT if the DMA variant fails
commit
5d3abf8ff67f49271a42c0f7fa4f20f9e046bf0e upstream.
Some devices advertise support for the READ/WRITE LOG DMA EXT commands
but fail when we try to issue them. This can lead to queued TRIM being
unintentionally disabled since the relevant feature flag is located in a
general purpose log page.
Fall back to unqueued READ LOG EXT if the DMA variant fails while
reading a log page.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Wed, 8 Jul 2015 17:06:12 +0000 (13:06 -0400)]
libata: increase the timeout when setting transfer mode
commit
d531be2ca2f27cca5f041b6a140504999144a617 upstream.
I have a ST4000DM000 disk. If Linux is booted while the disk is spun down,
the command that sets transfer mode causes the disk to spin up. The
spin-up takes longer than the default 5s timeout, so the command fails and
timeout is reported.
Fix this by increasing the timeout to 15s, which is enough for the disk to
spin up.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aleksei Mamlin [Wed, 1 Jul 2015 10:48:30 +0000 (13:48 +0300)]
libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk VB0250EAVER
commit
08c85d2a599d967ede38a847f5594447b6100642 upstream.
Enabling AA on HP 250GB SATA disk VB0250EAVER causes errors:
[ 3.788362] ata3.00: failed to enable AA (error_mask=0x1)
[ 3.789243] ata3.00: failed to enable AA (error_mask=0x1)
Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk.
tj: Collected FPDMA_AA entries and updated comment.
Signed-off-by: Aleksei Mamlin <mamlinav@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin K. Petersen [Thu, 18 Jun 2015 18:50:18 +0000 (14:50 -0400)]
libata: Do not blacklist Micron M500DC
commit
243918be6393f643e513a26e7882e6ae06ff7717 upstream.
Queued TRIM got disabled on Micron M500DC drives thanks to the
"Micron_M500*" pattern we had in place to accommodate the previous
generation of this drive family. Tweak the blacklist entry slightly so
we only disable queued TRIM for the non-DC variants of M500 drives.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Ujfalusi [Thu, 4 Jun 2015 13:04:15 +0000 (16:04 +0300)]
ASoC: tas2552: Fix kernel crash caused by wrong kcontrol entry
commit
1cf0f44811b754b64283b11ef0e60cb0de07b29c upstream.
SOC_DAPM_SINGLE("Playback AMP", ..) should not be under kcontrols. It
causes kernel crash (NULL pointer) when the mixers are listed.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Ujfalusi [Thu, 4 Jun 2015 13:04:14 +0000 (16:04 +0300)]
ASoC: tas2552: Fix kernel crash when the codec is loaded but not part of a card
commit
80ba2669ec8c3e6517aa935001f6cb8809bf3df4 upstream.
If the card is not part of any card the tas_data->codec is NULL since it is
set only during snd_soc_codec_driver.probe, which is not yet called.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zidan Wang [Thu, 11 Jun 2015 11:14:36 +0000 (19:14 +0800)]
ASoC: wm8960: the enum of "DAC Polarity" should be wm8960_enum[1]
commit
a077e81ec61e07a7f86997d045109f06719fbffe upstream.
the enum of "DAC Polarity" should be wm8960_enum[1].
Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Axel Lin [Mon, 11 May 2015 01:04:06 +0000 (09:04 +0800)]
ASoC: wm8903: Fix define for WM8903_VMID_RES_250K
commit
ebb6ad73e645b8f2d098dd3c41d2ff0da4146a02 upstream.
VMID Control 0 BIT[2:1] is VMID Divider Enable and Select
00 = VMID disabled (for OFF mode)
01 = 2 x 50kΩ divider (for normal operation)
10 = 2 x 250kΩ divider (for low power standby)
11 = 2 x 5kΩ divider (for fast start-up)
So WM8903_VMID_RES_250K should be 2 << 1, which is 4.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Axel Lin [Fri, 15 May 2015 01:15:16 +0000 (09:15 +0800)]
ASoC: wm8955: Fix setting wrong register for WM8955_K_8_0_MASK bits
commit
12c350050538c7dc779c083b7342bfd20f74949c upstream.
WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than
WM8955_PLL_CONTROL_2.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Axel Lin [Sun, 10 May 2015 03:35:06 +0000 (11:35 +0800)]
ASoC: wm8737: Fixup setting VMID Impedance control register
commit
14ba3ec1de043260cecd9e828ea2e3a0ad302893 upstream.
According to the datasheet:
R10 (0Ah) VMID Impedance Control
BIT 3:2 VMIDSEL DEFAULT 00
DESCRIPTION: VMID impedance selection control
00: 75kΩ output
01: 300kΩ output
10: 2.5kΩ output
WM8737_VMIDSEL_MASK is 0xC (VMIDSEL - [3:2]),
so it needs to left shift WM8737_VMIDSEL_SHIFT bits for setting these bits.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Tue, 19 May 2015 12:47:32 +0000 (14:47 +0200)]
ASoC: omap: fix up SND_OMAP_SOC_OMAP_ABE_TWL6040 dependency, again
commit
0574eab363ace70ef275d4caad6eadc458d33728 upstream.
I tried to fix this before and submitted a working patch, but after
some discussion we came up with what seemed to be a nicer solution,
resulting in commit
3d4cf65e2d ("ASoC: omap: fix up
SND_OMAP_SOC_OMAP_ABE_TWL6040 dependency"). Unfortunately, that
version was incomplete, and we still get this build error:
drivers/clk/clk-palmas.c:46:16: error: field 'hw' has incomplete type
drivers/clk/clk-palmas.c: In function 'to_palmas_clks_info':
drivers/clk/clk-palmas.c:54:74: warning: initialization from incompatible pointer type [-Winc
This happens only in randconfig builds that turn on MFD_PALMAS
on a platform other than OMAP2+ when COMPILE_TEST is set
but COMMON_CLK is not.
The new approach is only 'select COMMON_CLK_PALMAS' if we know
that we are on an OMAP5 platform and MFD_PALMAS is already set.
This patch has survived thousands of randconfig builds and I
don't see a remaining hole in the logic.
Fixes:
3d4cf65e2d ("ASoC: omap: fix up SND_OMAP_SOC_OMAP_ABE_TWL6040 dependency")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 10 Jun 2015 15:37:23 +0000 (18:37 +0300)]
ASoC: imx-wm8962: Add a missing error check
commit
474ff0ae23b834e9fc18374d14bb5f3e7b3828b4 upstream.
My static checker complains that:
sound/soc/fsl/imx-wm8962.c:196 imx_wm8962_probe() warn:
we tested 'ret' before and it was 'false'
The intent was that we use "ret" to check imx_audmux_v2_configure_port().
Fixes:
8de2ae2a7f1f ('ASoC: fsl: add imx-wm8962 machine driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Otherwise, Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Thu, 21 May 2015 09:07:08 +0000 (11:07 +0200)]
ASoC: qcom: remove incorrect dependencies
commit
a7310c496f376b945e7e61f64d69c9c0a93ee1ee upstream.
Compile-tests show a warning for the newly added SND_SOC_STORM
symbol:
warning: (SND_SOC_STORM) selects SND_SOC_LPASS_CPU which has unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC && SND_SOC_QCOM)
The problem is that it can be selected for COMPILE_TEST on non-QCOM
builds, but the symbols it selects have a dependency.
Dropping the dependencies makes it work without warnings and no
other side-effects, because these are not user-visible.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes:
f380dd3f3cd ("ASoC: qcom: Add ability to build QCOM drivers")
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Axel Lin [Tue, 26 May 2015 12:35:08 +0000 (20:35 +0800)]
ASoC: max98925: Fix mask for setting DAI invert mode
commit
0b51601d4504f46f585eed823485101390f0b588 upstream.
The M98925_DAI_WCI_MASK bit is not updated with current code.
To properly set the DAI invert mode, the mask should be
M98925_DAI_BCI_MASK | M98925_DAI_WCI_MASK.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Boichat [Fri, 5 Jun 2015 10:42:12 +0000 (18:42 +0800)]
ASoC: rt5645: Init jack_detect_work before registering irq
commit
7ea3470a7277380248135a592a849e1c27960b2f upstream.
Prevents frequent panic on boot, if the irq handler rt5645_irq
gets called before the workqueue rt5645_jack_detect_work is
initialized.
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Fitzgerald [Thu, 28 May 2015 13:28:12 +0000 (14:28 +0100)]
ASoC: arizona: Fix noise generator gain TLV
commit
15575ed544910464715df5c45a44b9732e415b93 upstream.
The Arizona codec drivers had an incorrect dB scaling for the
noise generator gain that started at 0dB and went upwards.
Actually the highest setting is 0dB.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Tue, 28 Apr 2015 21:51:17 +0000 (18:51 -0300)]
cx24116: fix a buffer overflow when checking userspace params
commit
1fa2337a315a2448c5434f41e00d56b01a22283c upstream.
The maximum size for a DiSEqC command is 6, according to the
userspace API. However, the code allows to write up much more values:
drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Tue, 28 Apr 2015 21:34:40 +0000 (18:34 -0300)]
s5h1420: fix a buffer overflow when checking userspace params
commit
12f4543f5d6811f864e6c4952eb27253c7466c02 upstream.
The maximum size for a DiSEqC command is 6, according to the
userspace API. However, the code allows to write up to 7 values:
drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd() error: buffer overflow 'cmd->msg' 6 <= 7
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans Verkuil [Fri, 27 Mar 2015 18:17:56 +0000 (15:17 -0300)]
saa7164: fix querycap warning
commit
534bc3e2ee93835badca753bedce8073c67caa92 upstream.
Fix the VIDIOC_QUERYCAP warning due to the missing device_caps. Don't fill
in the version field, the V4L2 core will do that for you.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>