From: Javier Pello <javier.pello@urjc.es>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
linux-kernel@vger.kernel.org, GregKH <greg@kroah.com>
Subject: Re: [PATCH] request_firmware: skip timeout if userspace was not notified
Date: Thu, 09 Aug 2007 11:36:05 +0200 [thread overview]
Message-ID: <46BAE005.4000906@urjc.es> (raw)
In-Reply-To: <20070807162618.3814ff78@gondolin.boeblingen.de.ibm.com>
On Tue, 07 Aug 2007, Cornelia Huck wrote:
> So it is indeed that this driver wants to fail its probe if it
> cannot get the firmware.
That's right. The driver unbinds itself from the device if it doesn't
get the firmware.
> A possibilty to achieve a similar effect would be to use
> request_firmware_nowait() and to call device_release_driver() from
> the callback if no firmware is loaded. (This would imply a split of
> that driver's probe function into two stages.)
The comments in the source code say that request_firmware_nowait()
is an "asynchronous version of request_firmware() for contexts where
it is not possible to sleep". So a driver's decision to call one of
them is not based on whether it wants to wait or not, but whether it
_can_ wait.
Of course, it can be decided that we never want to wait, but then
the best course of action would be to make request_firmware itself
behave as request_firmware_nowait (no need to change drivers).
Anyway, my point is that it is useless to have the kernel block for
a minute at boot waiting for something that cannot happen, and that
it should be avoided (even if my proposed solution is not the way
to go).
Javier
next prev parent reply other threads:[~2007-08-09 9:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-03 19:07 [PATCH] request_firmware: skip timeout if userspace was not notified Javier Pello
2007-08-04 5:21 ` david
2007-08-04 8:50 ` Javier Pello
2007-08-04 17:09 ` david
2007-08-04 21:20 ` Javier Pello
2007-08-06 12:24 ` Cornelia Huck
2007-08-06 20:23 ` Javier Pello
[not found] ` <20070807125844.4d756b04@gondo lin.boeblingen.de.ibm.com>
2007-08-07 10:58 ` Cornelia Huck
2007-08-07 11:46 ` Kay Sievers
2007-08-07 12:10 ` Cornelia Huck
2007-08-07 12:31 ` Kay Sievers
2007-08-07 12:48 ` Cornelia Huck
2007-08-07 12:47 ` Javier Pello
2007-08-07 12:57 ` Kay Sievers
2007-08-07 13:15 ` Cornelia Huck
2007-08-07 13:59 ` Javier Pello
2007-08-07 14:08 ` Kay Sievers
2007-08-07 14:38 ` Cornelia Huck
2007-08-09 9:13 ` Javier Pello
2007-08-09 9:21 ` Kay Sievers
2007-08-09 9:26 ` Cornelia Huck
2007-08-07 14:26 ` Cornelia Huck
2007-08-09 9:36 ` Javier Pello [this message]
2007-08-09 11:58 ` Kay Sievers
2007-08-10 21:24 ` Javier Pello
2007-08-11 13:26 ` Kay Sievers
2007-08-07 20:05 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46BAE005.4000906@urjc.es \
--to=javier.pello@urjc.es \
--cc=cornelia.huck@de.ibm.com \
--cc=greg@kroah.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox