<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/dma, branch v5.4.50</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.50</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.50'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-05-27T15:46:43+00:00</updated>
<entry>
<title>dmaengine: owl: Use correct lock in owl_dma_get_pchan()</title>
<updated>2020-05-27T15:46:43+00:00</updated>
<author>
<name>Cristian Ciocaltea</name>
<email>cristian.ciocaltea@gmail.com</email>
</author>
<published>2020-05-02T17:15:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4b1b34621998c4f99d91830175a53ac9a57c07a7'/>
<id>urn:sha1:4b1b34621998c4f99d91830175a53ac9a57c07a7</id>
<content type='text'>
commit f8f482deb078389b42768b2193e050a81aae137d upstream.

When the kernel is built with lockdep support and the owl-dma driver is
used, the following message is shown:

[    2.496939] INFO: trying to register non-static key.
[    2.501889] the code is fine but needs lockdep annotation.
[    2.507357] turning off the locking correctness validator.
[    2.512834] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.3+ #15
[    2.519084] Hardware name: Generic DT based system
[    2.523878] Workqueue: events_freezable mmc_rescan
[    2.528681] [&lt;801127f0&gt;] (unwind_backtrace) from [&lt;8010da58&gt;] (show_stack+0x10/0x14)
[    2.536420] [&lt;8010da58&gt;] (show_stack) from [&lt;8080fbe8&gt;] (dump_stack+0xb4/0xe0)
[    2.543645] [&lt;8080fbe8&gt;] (dump_stack) from [&lt;8017efa4&gt;] (register_lock_class+0x6f0/0x718)
[    2.551816] [&lt;8017efa4&gt;] (register_lock_class) from [&lt;8017b7d0&gt;] (__lock_acquire+0x78/0x25f0)
[    2.560330] [&lt;8017b7d0&gt;] (__lock_acquire) from [&lt;8017e5e4&gt;] (lock_acquire+0xd8/0x1f4)
[    2.568159] [&lt;8017e5e4&gt;] (lock_acquire) from [&lt;80831fb0&gt;] (_raw_spin_lock_irqsave+0x3c/0x50)
[    2.576589] [&lt;80831fb0&gt;] (_raw_spin_lock_irqsave) from [&lt;8051b5fc&gt;] (owl_dma_issue_pending+0xbc/0x120)
[    2.585884] [&lt;8051b5fc&gt;] (owl_dma_issue_pending) from [&lt;80668cbc&gt;] (owl_mmc_request+0x1b0/0x390)
[    2.594655] [&lt;80668cbc&gt;] (owl_mmc_request) from [&lt;80650ce0&gt;] (mmc_start_request+0x94/0xbc)
[    2.602906] [&lt;80650ce0&gt;] (mmc_start_request) from [&lt;80650ec0&gt;] (mmc_wait_for_req+0x64/0xd0)
[    2.611245] [&lt;80650ec0&gt;] (mmc_wait_for_req) from [&lt;8065aa10&gt;] (mmc_app_send_scr+0x10c/0x144)
[    2.619669] [&lt;8065aa10&gt;] (mmc_app_send_scr) from [&lt;80659b3c&gt;] (mmc_sd_setup_card+0x4c/0x318)
[    2.628092] [&lt;80659b3c&gt;] (mmc_sd_setup_card) from [&lt;80659f0c&gt;] (mmc_sd_init_card+0x104/0x430)
[    2.636601] [&lt;80659f0c&gt;] (mmc_sd_init_card) from [&lt;8065a3e0&gt;] (mmc_attach_sd+0xcc/0x16c)
[    2.644678] [&lt;8065a3e0&gt;] (mmc_attach_sd) from [&lt;8065301c&gt;] (mmc_rescan+0x3ac/0x40c)
[    2.652332] [&lt;8065301c&gt;] (mmc_rescan) from [&lt;80143244&gt;] (process_one_work+0x2d8/0x780)
[    2.660239] [&lt;80143244&gt;] (process_one_work) from [&lt;80143730&gt;] (worker_thread+0x44/0x598)
[    2.668323] [&lt;80143730&gt;] (worker_thread) from [&lt;8014b5f8&gt;] (kthread+0x148/0x150)
[    2.675708] [&lt;8014b5f8&gt;] (kthread) from [&lt;801010b4&gt;] (ret_from_fork+0x14/0x20)
[    2.682912] Exception stack(0xee8fdfb0 to 0xee8fdff8)
[    2.687954] dfa0:                                     00000000 00000000 00000000 00000000
[    2.696118] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.704277] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000

The obvious fix would be to use 'spin_lock_init()' on 'pchan-&gt;lock'
before attempting to call 'spin_lock_irqsave()' in 'owl_dma_get_pchan()'.

However, according to Manivannan Sadhasivam, 'pchan-&gt;lock' was supposed
to only protect 'pchan-&gt;vchan' while 'od-&gt;lock' does a similar job in
'owl_dma_terminate_pchan()'.

Therefore, this patch substitutes 'pchan-&gt;lock' with 'od-&gt;lock' and
removes the 'lock' attribute in 'owl_dma_pchan' struct.

Fixes: 47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA driver")
Signed-off-by: Cristian Ciocaltea &lt;cristian.ciocaltea@gmail.com&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Acked-by: Andreas Färber &lt;afaerber@suse.de&gt;
Link: https://lore.kernel.org/r/c6e6cdaca252b5364bd294093673951036488cf0.1588439073.git.cristian.ciocaltea@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dmaengine: dmatest: Restore default for channel</title>
<updated>2020-05-27T15:46:42+00:00</updated>
<author>
<name>Vladimir Murzin</name>
<email>vladimir.murzin@arm.com</email>
</author>
<published>2020-04-29T07:15:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0fcbe108b01a82806fd7907490b09709eef4bbac'/>
<id>urn:sha1:0fcbe108b01a82806fd7907490b09709eef4bbac</id>
<content type='text'>
commit 6b41030fdc79086db5d673c5ed7169f3ee8c13b9 upstream.

In case of dmatest is built-in and no channel was configured test
doesn't run with:

dmatest: Could not start test, no channels configured

Even though description to "channel" parameter claims that default is
any.

Add default channel back as it used to be rather than reject test with
no channel configuration.

Fixes: d53513d5dc285d9a95a534fc41c5c08af6b60eac ("dmaengine: dmatest: Add support for multi channel testing)
Reported-by: Dijil Mohan &lt;Dijil.Mohan@arm.com&gt;
Signed-off-by: Vladimir Murzin &lt;vladimir.murzin@arm.com&gt;
Link: https://lore.kernel.org/r/20200429071522.58148-1-vladimir.murzin@arm.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dmaengine: tegra210-adma: Fix an error handling path in 'tegra_adma_probe()'</title>
<updated>2020-05-27T15:46:42+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2020-05-16T21:42:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=432b103596bd8dd1ca3d4b5b98eb35f45d66c82b'/>
<id>urn:sha1:432b103596bd8dd1ca3d4b5b98eb35f45d66c82b</id>
<content type='text'>
commit 3a5fd0dbd87853f8bd2ea275a5b3b41d6686e761 upstream.

Commit b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe")
has moved some code in the probe function and reordered the error handling
path accordingly.
However, a goto has been missed.

Fix it and goto the right label if 'dma_async_device_register()' fails, so
that all resources are released.

Fixes: b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Reviewed-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Link: https://lore.kernel.org/r/20200516214205.276266-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dmaengine: mmp_tdma: Reset channel error on release</title>
<updated>2020-05-20T06:20:14+00:00</updated>
<author>
<name>Lubomir Rintel</name>
<email>lkundrak@v3.sk</email>
</author>
<published>2020-04-19T16:49:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b313699e7a9a968f0d644254175875890d85680'/>
<id>urn:sha1:2b313699e7a9a968f0d644254175875890d85680</id>
<content type='text'>
[ Upstream commit 0c89446379218698189a47871336cb30286a7197 ]

When a channel configuration fails, the status of the channel is set to
DEV_ERROR so that an attempt to submit it fails. However, this status
sticks until the heat end of the universe, making it impossible to
recover from the error.

Let's reset it when the channel is released so that further use of the
channel with correct configuration is not impacted.

Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Link: https://lore.kernel.org/r/20200419164912.670973-5-lkundrak@v3.sk
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: mmp_tdma: Do not ignore slave config validation errors</title>
<updated>2020-05-20T06:20:14+00:00</updated>
<author>
<name>Lubomir Rintel</name>
<email>lkundrak@v3.sk</email>
</author>
<published>2020-04-19T16:49:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6c414ddee7f040bb81d4e01eac4350e82b1809ec'/>
<id>urn:sha1:6c414ddee7f040bb81d4e01eac4350e82b1809ec</id>
<content type='text'>
[ Upstream commit 363c32701c7fdc8265a84b21a6a4f45d1202b9ca ]

With an invalid dma_slave_config set previously,
mmp_tdma_prep_dma_cyclic() would detect an error whilst configuring the
channel, but proceed happily on:

  [  120.756530] mmp-tdma d42a0800.adma: mmp_tdma: unknown burst size.

Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
Link: https://lore.kernel.org/r/20200419164912.670973-2-lkundrak@v3.sk
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: pch_dma.c: Avoid data race between probe and irq handler</title>
<updated>2020-05-20T06:20:13+00:00</updated>
<author>
<name>Madhuparna Bhowmik</name>
<email>madhuparnabhowmik10@gmail.com</email>
</author>
<published>2020-04-16T06:23:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=de76c0d4a03c2a7121919dd799fe9d83c8f33164'/>
<id>urn:sha1:de76c0d4a03c2a7121919dd799fe9d83c8f33164</id>
<content type='text'>
[ Upstream commit 2e45676a4d33af47259fa186ea039122ce263ba9 ]

pd-&gt;dma.dev is read in irq handler pd_irq().
However, it is set to pdev-&gt;dev after request_irq().
Therefore, set pd-&gt;dma.dev to pdev-&gt;dev before request_irq() to
avoid data race between pch_dma_probe() and pd_irq().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Madhuparna Bhowmik &lt;madhuparnabhowmik10@gmail.com&gt;
Link: https://lore.kernel.org/r/20200416062335.29223-1-madhuparnabhowmik10@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: dmatest: Fix process hang when reading 'wait' parameter</title>
<updated>2020-05-06T06:15:16+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2020-04-28T11:35:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=73162ca8156f0d90f17995b82ca8ff7bb1d2cd5e'/>
<id>urn:sha1:73162ca8156f0d90f17995b82ca8ff7bb1d2cd5e</id>
<content type='text'>
commit aa72f1d20ee973d68f26d46fce5e1cf6f9b7e1ca upstream.

If we do

  % echo 1 &gt; /sys/module/dmatest/parameters/run
  [  115.851124] dmatest: Could not start test, no channels configured

  % echo dma8chan7 &gt; /sys/module/dmatest/parameters/channel
  [  127.563872] dmatest: Added 1 threads using dma8chan7

  % cat /sys/module/dmatest/parameters/wait
  ... !!! HANG !!! ...

The culprit is the commit 6138f967bccc

  ("dmaengine: dmatest: Use fixed point div to calculate iops")

which makes threads not to run, but pending and being kicked off by writing
to the 'run' node. However, it forgot to consider 'wait' routine to avoid
above mentioned case.

In order to fix this, check for really running threads, i.e. with pending
and done flags unset.

It's pity the culprit commit hadn't updated documentation and tested all
possible scenarios.

Fixes: 6138f967bccc ("dmaengine: dmatest: Use fixed point div to calculate iops")
Cc: Seraj Alijan &lt;seraj.alijan@sondrel.com&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20200428113518.70620-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dmaengine: dmatest: Fix iteration non-stop logic</title>
<updated>2020-05-06T06:15:16+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2020-04-24T16:11:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c753a12c88e8c98a86a5dec752ddcaf66d0fa7ba'/>
<id>urn:sha1:c753a12c88e8c98a86a5dec752ddcaf66d0fa7ba</id>
<content type='text'>
commit b9f960201249f20deea586b4ec814669b4c6b1c0 upstream.

Under some circumstances, i.e. when test is still running and about to
time out and user runs, for example,

	grep -H . /sys/module/dmatest/parameters/*

the iterations parameter is not respected and test is going on and on until
user gives

	echo 0 &gt; /sys/module/dmatest/parameters/run

This is not what expected.

The history of this bug is interesting. I though that the commit
  2d88ce76eb98 ("dmatest: add a 'wait' parameter")
is a culprit, but looking closer to the code I think it simple revealed the
broken logic from the day one, i.e. in the commit
  0a2ff57d6fba ("dmaengine: dmatest: add a maximum number of test iterations")
which adds iterations parameter.

So, to the point, the conditional of checking the thread to be stopped being
first part of conjunction logic prevents to check iterations. Thus, we have to
always check both conditions to be able to stop after given iterations.

Since it wasn't visible before second commit appeared, I add a respective
Fixes tag.

Fixes: 2d88ce76eb98 ("dmatest: add a 'wait' parameter")
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Nicolas Ferre &lt;nicolas.ferre@microchip.com&gt;
Link: https://lore.kernel.org/r/20200424161147.16895-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dmaengine: coh901318: Fix a double lock bug in dma_tc_handle()</title>
<updated>2020-03-12T12:00:30+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2020-02-17T14:40:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5293e17978c4335674f1956da05c84ec68fa5be0'/>
<id>urn:sha1:5293e17978c4335674f1956da05c84ec68fa5be0</id>
<content type='text'>
commit 36d5d22090d13fd3a7a8c9663a711cbe6970aac8 upstream.

The caller is already holding the lock so this will deadlock.

Fixes: 0b58828c923e ("DMAENGINE: COH 901 318 remove irq counting")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Link: https://lore.kernel.org/r/20200217144050.3i4ymbytogod4ijn@kili.mountain
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dmaengine: tegra-apb: Prevent race conditions of tasklet vs free list</title>
<updated>2020-03-12T12:00:23+00:00</updated>
<author>
<name>Dmitry Osipenko</name>
<email>digetx@gmail.com</email>
</author>
<published>2020-02-09T16:33:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac5e2d2d5fc6d3e2ecc56af9e3aff77942c1d48f'/>
<id>urn:sha1:ac5e2d2d5fc6d3e2ecc56af9e3aff77942c1d48f</id>
<content type='text'>
commit c33ee1301c393a241d6424e36eff1071811b1064 upstream.

The interrupt handler puts a half-completed DMA descriptor on a free list
and then schedules tasklet to process bottom half of the descriptor that
executes client's callback, this creates possibility to pick up the busy
descriptor from the free list. Thus, let's disallow descriptor's re-use
until it is fully processed.

Signed-off-by: Dmitry Osipenko &lt;digetx@gmail.com&gt;
Acked-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20200209163356.6439-3-digetx@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
