Re: [PATCH] firmware_class: improve suspend handling

[Daniel Drake]

On Mon, May 21, 2012 at 4:06 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> If I remember correctly, we used to have an equivalent of this, but it
> didn't work.  The reason is that there are situations in which
> request_firmware_nowait() shouldn't be aborted even if system suspend is
> in progress (or more generally user space is frozen).

OK, maybe this is not the right approach. But we still need a
solution. Do you have any ideas, or am I not managing to communicate
the problem well enough?

> By definition, request_firmware_nowait() should not interfere with the
> suspend process, because it is asynchronous with respect to it, but
> if the driver actually waits for it to complete, it should simply use
> request_firmware() instead.

In this case we need to load firmware from probe. udev no longer lets
us use request_firmware() here, as per
http://www.spinics.net/lists/linux-wireless/msg85541.html

This is why we must move to request_firmware_nowait() and (I think) is
why several drivers have recently moved to the async version.

So, after probe returns the device may still be initialising. If the
device gets disconnected, the remove handler gets called. The remove
handler will want to wait for any ongoing firmware loads to complete
before tearing down the device, otherwise later the firmware callback
will execute on a device that has been freed.

What happens if the device gets removed while the system is suspending
(or if the suspend causes the device disconnection)? We hit this
issue.

I guess what is really needed here is a way to immediately cancel the
async firmware load without waiting for it to complete, without
requiring any communication with userspace. This would require
changing the API a little, to return some kind of handle that can be
cancelled. The suspend handlers could then cancel the firmware load if
they need.

What do you think?

Thanks
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/