[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <537E848C.5010204@wwwdotorg.org>
Date: Thu, 22 May 2014 17:13:16 -0600
From: Stephen Warren <swarren@...dotorg.org>
To: fwu@...vell.com, linus.walleij@...aro.org, tony@...mide.com
CC: linux-kernel@...r.kernel.org, swarren@...dia.com,
cxie4@...vell.com, ylmao@...vell.com, njiang1@...vell.com,
tianxf@...vell.com, fswu@...vell.com
Subject: Re: [PATCH v2] pinctrl: add params in disable_setting for different
usage
On 05/21/2014 09:10 PM, fwu@...vell.com wrote:
> From: Fan Wu <fwu@...vell.com>
>
> What the patch did:
> 1.To call pinmux_disable_setting ahead of pinmux_enable_setting in each time of
> calling pinctrl_select_state
> 2.Remove the HW disable operation in in pinmux_disable_setting function.
>
...
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> index c0fe609..c97491a 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -993,25 +993,13 @@ int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
> * may not be identical to the set of groups with a mux setting
> * in the new state. While this might be unusual, it's entirely
> * possible for the "user"-supplied mapping table to be written
> - * that way. For each group that was configured in the old state
> - * but not in the new state, this code puts that group into a
> - * safe/disabled state.
> + * that way. This code is used for each group that was
> + * configured in the old state but not in the new state
Looking at the code, it's run for every group in the state, not "each
group that was configured in the old state but not in the new state"
> @@ -515,9 +514,6 @@ void pinmux_disable_setting(struct pinctrl_setting const *setting)
> pins[i], desc->name, gname);
> }
> }
> -
> - if (ops->disable)
> - ops->disable(pctldev, setting->data.mux.func, setting->data.mux.group);
> }
Should that op be removed from the header file and all drivers too?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists