All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: gregkh@linuxfoundation.org,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Daniel Wagner <daniel.wagner@bmw-carit.de>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	Ming Lei <ming.lei@canonical.com>,
	linux-kernel@vger.kernel.org, oss-drivers@netronome.com
Subject: Re: [PATCH driver-core/master] firmware: Correct handling of fw_state_wait_timeout() return value
Date: Mon, 16 Jan 2017 19:29:12 +0100	[thread overview]
Message-ID: <20170116182912.GA13946@wotan.suse.de> (raw)
In-Reply-To: <20170116145706.19198-1-jakub.kicinski@netronome.com>

On Mon, Jan 16, 2017 at 02:57:06PM +0000, Jakub Kicinski wrote:
> Commit 5d47ec02c37e ("firmware: Correct handling of fw_state_wait()
> return value") made the assumption that any error returned from
> fw_state_wait_timeout() means FW load has to be aborted.  This is
> incorrect FW load only has to be aborted when load timed out or

You want a comma before FW -- but also:

> has been interrupted,

__fw_state_wait_common() returns -ENOENT when:

if (ret != 0 && fw_st->status == FW_STATUS_ABORTED)
	return -ENOENT;

Why not for when -ENOENT is returned ?

> otherwise the waking thread had already
> cleaned up for us.

What code in what waking thread would have done precisely what cleanup?
And why can't fw_load_abort() handle being called twice and why not just
instead allow for that?

> Fixes: 5d47ec02c37e ("firmware: Correct handling of fw_state_wait() return value")

What does this fix exactly? A fix should describe the impact, what
issues are in place without the fix. What also happens after the fix
and why. In this commit log none of this is clear.

> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
>  drivers/base/firmware_class.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 4497d263209f..ce142e6b2c72 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -1020,7 +1020,7 @@ static int _request_firmware_load(struct firmware_priv *fw_priv,
>  	}
>  
>  	retval = fw_state_wait_timeout(&buf->fw_st, timeout);
> -	if (retval < 0) {
> +	if (retval == -ETIMEDOUT || retval == -ERESTARTSYS) {

Also, if your change is correct I will also note fw_state_wait_timeout()
is just a wrapper for __fw_state_wait_common(), but we also have
another wrapper for __fw_state_wait_common() now:

#define fw_state_wait(fw_st)                                    \               
        __fw_state_wait_common(fw_st, MAX_SCHEDULE_TIMEOUT) 

Do we need to fix anything for fw_state_wait() ?

Clarifying all this would help review your proposed changes. If you
consider them a fix please be very clear as to the exact issue and
what is fixed with your patch.

  Luis

  reply	other threads:[~2017-01-16 18:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16 14:57 [PATCH driver-core/master] firmware: Correct handling of fw_state_wait_timeout() return value Jakub Kicinski
2017-01-16 18:29 ` Luis R. Rodriguez [this message]
2017-01-16 19:13   ` Jakub Kicinski

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=20170116182912.GA13946@wotan.suse.de \
    --to=mcgrof@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel.wagner@bmw-carit.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jakub.kicinski@netronome.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=oss-drivers@netronome.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.