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

On Tue, 19 May 2015, Marcel Holtmann wrote:

Hi Alan,

quoted

quoted

quoted

quoted

I am not convinced. Now we are hacking the Bluetooth core layer
(which has nothing to do with the drivers suspend/resume or
probe) to do something different so that we do not see this
warning.

I can not do anything about the platform in question choosing a
unplug/replug for suspend/resume instead of having a proper USB
suspend and resume handling. That is pretty much out of our
control.

Actually one can do something about this.  I mean, one _can_ implement
proper USB suspend and resume handling in the Bluetooth driver.  At
this point the details aren't clear to me, but perhaps if the driver in
question had a reset_resume callback then it might work better.

the btusb.ko driver has suspend/resume support. Are you saying we
also need reset_resume support?

I don't know; I'm not familiar enough with how Bluetooth works.  If the 
device loses power and requires its firmware to be loaded again, then a 
reset_resume would end up doing much the same thing as probe anyway.  
So implementing reset_resume might not make much difference.

quoted

quoted

quoted

quoted

I would rather have the USB subsystem delay the probe()
callback if we tell it to.

This is possible.  I am not sure it would be the right thing to do,
though.  What happens if the probe routine gets called early on during
the boot-up procedure, before userspace is up and running?  The same
thing should happen here.

For modules this will be hard. Since you need userspace before being
able to load the modules. If built-in code, then in theory this might
be possible. Depending on the order of the init sections.

Yes, I meant built-in.

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.

Then I really have no idea on how to solve this unless we silence the
warning from request_firmware. From a driver perspective we go back
trough probe(). So the driver has to treat this as a new device.

Oliver's suggestion to keep the firmware in memory may be the only
reasonable solution.

Alan Stern