Hi Guennadi-san,

2012/02/04 0:43, Guennadi Liakhovetski wrote:

The current renesas_usbhs driver triggers

BUG: scheduling while atomic: ksoftirqd/0/3/0x00000102

with enabled CONFIG_DEBUG_ATOMIC_SLEEP, by submitting DMA transfers from 
an atomic (tasklet) context, which is not supported by the shdma dmaengine 
driver. Fix it by switching to a work. Also simplify some list 
manipulations.

Signed-off-by: Guennadi Liakhovetski <redacted>
---

Shimoda-san, this is the problem, that you were observing. However, it 
exists with the present version of shdma just as well as with the new one 
- on top of the simple DMA library. I marked it an RFC because (1) I only 
lightly tested it with the gadget device on mackerel with the mass storage 
gadget, and (2) I am somewhat concerned about races. Currently the work 
function runs with no locking and there are no usual cancel_work_sync() 
points in the patch. However, it has also been like this before with the 
tasklet implementation, which is not much better, and it looks like there 
are no asynchronous operations on the same packets like timeouts. Only 
asynchronous events, that I can think about are things like unloading the 
driver or unplugging the cable, but these have been there before too. It 
would become worse on SMP, I think. Comments welcome.

Thank you for the patch and comments.
I also tested this patch using the g_mass_storage and g_ether.
About your points, I think so, too.
So, I will write such a code.

Best regards,
Yoshihiro Shimoda