[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8dfb5256-8ac8-98f0-ad16-6a891065d204@monom.org>
Date: Thu, 8 Sep 2016 11:45:56 +0200
From: Daniel Wagner <wagi@...om.org>
To: Daniel Wagner <daniel.wagner@...-carit.de>,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
Takashi Iwai <tiwai@...e.de>
Cc: linux-kernel@...r.kernel.org, Ming Lei <ming.lei@...onical.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v4 2/4] firmware: encapsulate firmware loading status
On 09/08/2016 10:05 AM, Daniel Wagner wrote:
> This while loop was originally a goto loop:
>
> 1f2b79599ee8 ("firmware loader: always let firmware_buf own the pages
> buffer")
>
> I don't think the code doesn't do what it was indented to do. The reason
> is that calling complete_all() the wait_for_completion() will not block
> again until it has 'eaten up' the done counter. That is around UMAX/2
> loops. So there is an reinit_completion() missing in this case.
Ah, I think I got it. It looks like kind of optimization. Instead doing
wait_for_completion()
if (done)
do_this()
if (abort)
do_that()
we have
check_again:
if (done) {
do_this()
goto out
}
if (abort) {
do_that()
goto out
}
wait_for_completion()
goto check_again
out:
> Before the above commit, the completion was used to wait inside
> _request_firmware_load() till the UML had done its job. The answer for
> your question is probably in 1f2b79599ee8 ("firmware loader: always let
> firmware_buf own the pages buffer").
So it still does the same job after this change. Check if we have the
firmware loaded already in buf if not kick off the umh loader and wait
for the result.
Powered by blists - more mailing lists