Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

At Tue, 19 May 2015 19:42:55 +0200,
Oliver Neukum wrote:

On Tue, 2015-05-19 at 19:13 +0200, Takashi Iwai wrote:

quoted

At Tue, 19 May 2015 10:26:46 -0400 (EDT),
Alan Stern wrote:

quoted

quoted

quoted

quoted

 Of just have request_firmware()
actually sleep until userspace is ready. Seriously, why is
request_firmware not just sleeping for us.

It won't work.  The request_firmware call is part of the probe 
sequence, which in turn is part of the resume sequence.  Userspace 
doesn't start running again until the resume sequence is finished.  If 
request_firmware waited for userspace, it would hang.

Note that the recent request_firmware() doesn't need the user-space
invocation (unless the fallback is explicitly enabled) but loads the

That is a dangerous approach. You cannot be sure you can do file IO.
It depends on the exact shape of the device tree.

 
It's the reason why firmware loader still takes UMH lock (thus we're
seeing this very problem).

quoted

file directly.  And, request_firmware() for the cached data is valid
to be called in the resume path.

Well, yes, if your data is cached in RAM, all is well. But that leads
to the same problem one step further. What must be cached?

The data is cached in RAM.  More specifically, the former loaded
firmware files are reloaded and saved at suspend for each device
object.  See fw_pm_notify() in firmware_class.c.

The question is then why the cached data isn't used.  I have no
concrete answer to it for now, need more investigation, but my wild
guess is that it's because the device itself is being renewed.
Or, something wrong in firmware_class.c.


Takashi