* Paul Cercueil <paul@xxxxxxxxxxxxxxx> [200809 12:54]: > musb_queue_resume_work() would call the provided callback if the runtime > PM status was 'active'. Otherwise, it would enqueue the request if the > hardware was still suspended (musb->is_runtime_suspended is true). > > This causes a race with the runtime PM handlers, as it is possible to be > in the case where the runtime PM status is not yet 'active', but the > hardware has been awaken (PM resume function has been called). > > When hitting the race, the resume work was not enqueued, which probably > triggered other bugs further down the stack. For instance, a telnet > connection on Ingenic SoCs would result in a 50/50 chance of a > segmentation fault somewhere in the musb code. > > Rework the code so that either we call the callback directly if > (musb->is_runtime_suspended == 0), or enqueue the query otherwise. Yes we should use is_runtime_suspended, thanks for fixing it. Things still work for me so: Reviewed-by: Tony Lindgren <tony@xxxxxxxxxxx> Tested-by: Tony Lindgren <tony@xxxxxxxxxxx>