linux-toradex.git/drivers, branch v3.14.20

clk: qcom: mdp_lut_clk is a child of mdp_src

2014-10-05T21:52:24+00:00

commit f87dfcabc6f173cc811d185d33327f50a8c88399 upstream.

The mdp_lut_clk isn't a child of the mdp_clk. Instead it's the
child of the mdp_src clock. Fix it.

Fixes: 6d00b56fe "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)"
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: qcom: Fix MN frequency tables, parent map, and jpegd

2014-10-05T21:52:24+00:00

commit ff20783f7b9f35b29e768d8ecc7076c1ca1a60ca upstream.

Clocks that don't have a pre-divider don't list any pre-divider
in their frequency tables, but their tables are initialized using
aggregate initializers. Use tagged initializers so we properly
assign the m and n values for each frequency. Furthermore, the
mmcc_pxo_pll8_pll2_pll3 array improperly mapped the second
element to pll2 instead of pll8, causing the clock driver to
recalculate the wrong rate for any clocks using this array along
with a rate that uses pll2. Plus the .num_parents field is 3
instead of 4 so you can't even switch the parent to pll3. Finally
I noticed that the jpegd clock improperly indicates that the
pre-divider width is only 2, when it's actually 4 bits wide.

Fixes: 6d00b56fe "clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC)"
Tested-by: Rob Clark 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

staging/lustre: disable virtual block device for 64K pages

2014-10-05T21:52:24+00:00

commit 0bf22be0da8ea74bc7ccc5b07d7855830be16eca upstream.

The lustre virtual block device cannot handle 64K pages and fails at compile
time. To avoid running into this error, let's disable the Kconfig option
for this driver in cases it doesn't support.

Reported-by: Dann Frazier 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

clk: prevent erronous parsing of children during rate change

2014-10-05T21:52:24+00:00

commit 067bb1741c27c8d3b74ac98c0b8fc12b31e67005 upstream.

In some cases, clocks can switch their parent with clk_set_rate, for
example clk_mux can do this in some cases. Current implementation of
clk_change_rate uses un-safe list iteration on the clock children, which
will cause wrong clocks to be parsed in case any of the clock children
change their parents during the change rate operation. Fixed by using
the safe list iterator instead.

The problem was detected due to some divide by zero errors generated
by clock init on dra7-evm board, see discussion under
http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details.

Fixes: 71472c0c06cf ("clk: add support for clock reparent on set_rate")
Signed-off-by: Tero Kristo 
Reported-by: Nishanth Menon 
Signed-off-by: Mike Turquette 
Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: don't perform DMA when dmaengine_submit is called

2014-10-05T21:52:24+00:00

commit dd8ecfcac66b4485416b2d1df0ec4798b198d7d6 upstream.

Accordingly to discussion [1] and followed up documentation the DMA controller
driver shouldn't start any DMA operations when dmaengine_submit() is called.

This patch fixes the workflow in dw_dmac driver to follow the documentation.

[1] http://www.spinics.net/lists/arm-kernel/msg125987.html

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Cc: "Petallo, MauriceX R" 
Signed-off-by: Greg Kroah-Hartman

dmaengine: dw: introduce dwc_dostart_first_queued() helper

2014-10-05T21:52:24+00:00

commit e7637c6c0382485f4d2e20715d058dae6f2b6a7c upstream.

We have a duplicate code which starts first descriptor in the queue. Let's make
this as a separate helper that can be used in future as well.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Vinod Koul 
Cc: "Petallo, MauriceX R" 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dma: check the result of TX buffer mapping

2014-10-05T21:52:24+00:00

commit d4089a332883ad969700aac5dd4dd5f1c4fee825 upstream.

Using dma_mapping_error() to make sure the mapping did not
fail.

Signed-off-by: Heikki Krogerus 
Cc: "Petallo, MauriceX R" 
Signed-off-by: Greg Kroah-Hartman

md/raid1: intialise start_next_window for READ case to avoid hang

2014-10-05T21:52:23+00:00

commit f0cc9a057151892b885be21a1d19b0185568281d upstream.

r1_bio->start_next_window is not initialised in the READ
case, so allow_barrier may incorrectly decrement
   conf->current_window_requests
which can cause raise_barrier() to block forever.

Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Reported-by: Brassow Jonathan 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid1: fix_read_error should act on all non-faulty devices.

2014-10-05T21:52:23+00:00

commit b8cb6b4c121e1bf1963c16ed69e7adcb1bc301cd upstream.

If a devices is being recovered it is not InSync and is not Faulty.

If a read error is experienced on that device, fix_read_error()
will be called, but it ignores non-InSync devices.  So it will
neither fix the error nor fail the device.

It is incorrect that fix_read_error() ignores non-InSync devices.
It should only ignore Faulty devices.  So fix it.

This became a bug when we allowed reading from a device that was being
recovered.  It is suitable for any subsequent -stable kernel.

Fixes: da8840a747c0dbf49506ec906757a6b87b9741e9
Reported-by: Alexander Lyakas 
Tested-by: Alexander Lyakas 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid1: count resync requests in nr_pending.

2014-10-05T21:52:23+00:00

commit 34e97f170149bfa14979581c4c748bc9b4b79d5b upstream.

Both normal IO and resync IO can be retried with reschedule_retry()
and so be counted into ->nr_queued, but only normal IO gets counted in
->nr_pending.

Before the recent improvement to RAID1 resync there could only
possibly have been one or the other on the queue.  When handling a
read failure it could only be normal IO.  So when handle_read_error()
called freeze_array() the fact that freeze_array only compares
->nr_queued against ->nr_pending was safe.

But now that these two types can interleave, we can have both normal
and resync IO requests queued, so we need to count them both in
nr_pending.

This error can lead to freeze_array() hanging if there is a read
error, so it is suitable for -stable.

Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Reported-by: Brassow Jonathan 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman