public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Richard Genoud <richard.genoud@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Stephen Warren <swarren@nvidia.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] pinctrl: disable and free setting in select_state in case of error
Date: Wed, 27 Mar 2013 17:49:46 -0600	[thread overview]
Message-ID: <5153859A.8000801@wwwdotorg.org> (raw)
In-Reply-To: <1364222843-30305-4-git-send-email-richard.genoud@gmail.com>

On 03/25/2013 08:47 AM, Richard Genoud wrote:
> If enabling a pin fails in pinctrl_select_state_locked(), all the
> previous enabled pins have to be disabled to get back to the previous
> state.

> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c

> @@ -910,13 +910,35 @@ static int pinctrl_select_state_locked(struct pinctrl *p,

>  		if (ret < 0) {
> -			/* FIXME: Difficult to return to prev state */
> -			return ret;
> +			goto unapply_new_state;
>  		}

Those { } should really be removed there, since there's only 1 line left
in the block.

> +unapply_new_state:
> +	pr_info("Error applying setting, reverse things back\n");

That should be dev_err() on the client device.

> +	/*
> +	 * If the loop stopped on the 1st entry, nothing has been enabled,
> +	 * so jump directly to the 2nd phase
> +	 */
> +	if (list_entry(&setting->node, typeof(*setting), node) ==
> +	    list_first_entry(&state->settings, typeof(*setting), node))
> +		goto reapply_old_state;

That's just an optimization, not a correctness issue isn't it?

I think it'd be simpler to just always run the list_for_each_entry()
below and let it bail out on the first loop if that's where the failure
happened. It's a lot simpler than understanding the conditional above,
which I didn't really try to do.

> +	list_for_each_entry(setting2, &state->settings, node) {
> +		if (&setting2->node == &setting->node)
> +			break;
> +		pinctrl_free_setting(true, setting2);

That's clearly wrong.

pinctrl_free_setting() is supposed to free any memory associated with
the setting; the storage that holds the representation of that setting.

It's only appropriate to do that in pinctrl_put(), when actually
destroying the whole struct pinctrl object. If pinctrl_select() fails,
we don't want to destroy/invalidate the struct pinctrl content, but
rather keep it around in case the driver uses it again even if the face
of previous errors.

In other words, what you should be doing inside this loop body is
exactly what the body of the first loop inside pinctrl_select_state()
does to "undo" any previously selected state, which is to call
pinmux_disable_setting() for each entry, or something similar to that.

> +	}
> +reapply_old_state:
> +	/* FIXME: re-enable old setting */
> +	return ret;
>  }


  parent reply	other threads:[~2013-03-27 23:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-25 14:47 [PATCH 0/4] pintrcl: restore old state when pinctrl_select_state fails Richard Genoud
2013-03-25 14:47 ` [PATCH 1/4] pinctrl: fix typo in header Richard Genoud
2013-03-27 22:13   ` Linus Walleij
2013-03-25 14:47 ` [PATCH 2/4] pinctrl: create pinctrl_free_setting function Richard Genoud
2013-03-27 22:15   ` Linus Walleij
2013-03-25 14:47 ` [PATCH 3/4] pinctrl: disable and free setting in select_state in case of error Richard Genoud
2013-03-27 22:17   ` Linus Walleij
2013-03-27 23:49   ` Stephen Warren [this message]
2013-03-28 10:55     ` Richard Genoud
2013-03-28 14:53       ` Stephen Warren
2013-03-28 15:47         ` Richard Genoud
2013-04-03 12:30           ` Linus Walleij
2013-04-03 12:36             ` Richard Genoud
2013-03-25 14:47 ` [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state Richard Genoud
2013-03-27 22:18   ` Linus Walleij
2013-03-27 23:55   ` Stephen Warren
2013-03-28 11:35     ` Richard Genoud
2013-03-28 17:34     ` Richard GENOUD
2013-03-28 17:38       ` Stephen Warren
2013-03-28 18:06         ` Richard GENOUD

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=5153859A.8000801@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.genoud@gmail.com \
    --cc=swarren@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox