linux-toradex.git/drivers, branch v4.1.21

dmaengine: at_xdmac: fix residue computation

2016-03-22T15:10:35+00:00

[ Upstream commit 25c5e9626ca4d40928dc9c44f009ce2ed0a739e7 ]

When computing the residue we need two pieces of information: the current
descriptor and the remaining data of the current descriptor. To get
that information, we need to read consecutively two registers but we
can't do it in an atomic way. For that reason, we have to check manually
that current descriptor has not changed.

Signed-off-by: Ludovic Desroches 
Suggested-by: Cyrille Pitchen 
Reported-by: David Engraf 
Tested-by: David Engraf 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: stable@vger.kernel.org #4.1 and later
Signed-off-by: Vinod Koul 

Signed-off-by: Sasha Levin

Revert "drm/radeon/pm: adjust display configuration after powerstate"

2016-03-22T15:10:33+00:00

[ Upstream commit d74e766e1916d0e09b86e4b5b9d0f819628fd546 ]

This reverts commit 39d4275058baf53e89203407bf3841ff2c74fa32.

This caused a regression on some older hardware.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=113891

Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/radeon/dp: add back special handling for NUTMEG

2016-03-22T15:10:32+00:00

[ Upstream commit c8213a638f65bf487c10593c216525952cca3690 ]

When I fixed the dp rate selection in:
092c96a8ab9d1bd60ada2ed385cc364ce084180e
drm/radeon: fix dp link rate selection (v2)
I accidently dropped the special handling for NUTMEG
DP bridge chips.  They require a fixed link rate.

Reviewed-by: Christian König 
Reviewed-by: Ken Wang 
Reviewed-by: Harry Wentland 
Tested-by: Ken Moffat 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/radeon: fix dp link rate selection (v2)

2016-03-22T15:10:32+00:00

[ Upstream commit 092c96a8ab9d1bd60ada2ed385cc364ce084180e ]

Need to properly handle the max link rate in the dpcd.
This prevents some cases where 5.4 Ghz is selected when
it shouldn't be.

v2: simplify logic, add array bounds check

Reviewed-by: Tom St Denis 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/radeon: make dpcd parameters const

2016-03-22T15:10:31+00:00

[ Upstream commit 0c3a88407ef2be8bb7c302c298d6ff58ebde4a43 ]

Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

target: Drop incorrect ABORT_TASK put for completed commands

2016-03-22T15:10:28+00:00

[ Upstream commit 7f54ab5ff52fb0b91569bc69c4a6bc5cac1b768d ]

This patch fixes a recent ABORT_TASK regression associated
with commit febe562c, where a left-over target_put_sess_cmd()
would still be called when __target_check_io_state() detected
a command has already been completed, and explicit ABORT must
be avoided.

Note commit febe562c dropped the local kref_get_unless_zero()
check in core_tmr_abort_task(), but did not drop this extra
corresponding target_put_sess_cmd() in the failure path.

So go ahead and drop this now bogus target_put_sess_cmd(),
and avoid this potential use-after-free.

Reported-by: Dan Lane 
Cc: Quinn Tran 
Cc: Himanshu Madhani 
Cc: Sagi Grimberg 
Cc: Christoph Hellwig 
Cc: Hannes Reinecke 
Cc: Andy Grover 
Cc: Mike Christie 
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Sasha Levin

can: gs_usb: fixed disconnect bug by removing erroneous use of kfree()

2016-03-18T03:14:02+00:00

[ Upstream commit e9a2d81b1761093386a0bb8a4f51642ac785ef63 ]

gs_destroy_candev() erroneously calls kfree() on a struct gs_can *, which is
allocated through alloc_candev() and should instead be freed using
free_candev() alone.

The inappropriate use of kfree() causes the kernel to hang when
gs_destroy_candev() is called.

Only the struct gs_usb * which is allocated through kzalloc() should be freed
using kfree() when the device is disconnected.

Signed-off-by: Maximilian Schneider 
Cc: linux-stable 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Sasha Levin

iwlwifi: mvm: inc pending frames counter also when txing non-sta

2016-03-18T03:13:48+00:00

[ Upstream commit fb896c44f88a75843a072cd6961b1615732f7811 ]

Until this patch, when TXing non-sta the pending_frames counter
wasn't increased, but it WAS decreased in
iwl_mvm_rx_tx_cmd_single(), what makes it negative in certain
conditions. This in turn caused much trouble when we need to
remove the station since we won't be waiting forever until
pending_frames gets 0. In certain cases, we were exhausting
the station table even in BSS mode, because we had a lot of
stale stations.

Increase the counter also in iwl_mvm_tx_skb_non_sta() after a
successful TX to avoid this outcome.

CC:  [3.18+]
Signed-off-by: Liad Kaufman 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Sasha Levin

ubi: Fix out of bounds write in volume update code

2016-03-14T16:42:31+00:00

[ Upstream commit e4f6daac20332448529b11f09388f1d55ef2084c ]

ubi_start_leb_change() allocates too few bytes.
ubi_more_leb_change_data() will write up to req->upd_bytes +
ubi->min_io_size bytes.

Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger 
Reviewed-by: Boris Brezillon 
Signed-off-by: Sasha Levin

drm/radeon/pm: update current crtc info after setting the powerstate

2016-03-09T18:15:24+00:00

[ Upstream commit 5e031d9fe8b0741f11d49667dfc3ebf5454121fd ]

On CI, we need to see if the number of crtcs changes to determine
whether or not we need to upload the mclk table again.  In practice
we don't currently upload the mclk table again after the initial load.
The only reason you would would be to add new states, e.g., for
arbitrary mclk setting which is not currently supported.

Acked-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin