Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On [jeu., 28.03.2013 11:38:23], Stephen Warren wrote:
> On 03/28/2013 11:34 AM, Richard GENOUD wrote:
> > On [mer., 27.03.2013 17:55:45], Stephen Warren wrote:
> >> On 03/25/2013 08:47 AM, Richard Genoud wrote:
> >>> If a new state is applied, the groups configured in the old state but
> >>> not in the new state are disabled.
> >>> If something goes wrong and the new state can't be applied, we have to
> >>> re-enable those groups.
> >>
> >> What is the use-case for this? I wonder if it isn't better to simply
> >> undo the partial selection of the new state (as patch 3/4 attempts to
> >> do) and then leave p->state==NULL, indicating that no state is actively
> >> selected. IIRC, this would be the same as right after the initial
> >> pinctrl_select().
> >>
> >> I wonder if it's likely that attempting to re-apply the old state would
> >> actually work, given that applying something just failed.
> >>
> >> Finally, this recovery code doesn't:
> >>
> >> a) Process anything except MUX_GROUP; any pin config settings in the old
> >> state aren't restored.
> >>
> >> b) (I think) Apply any mux settings that don't involve groups that are
> >> referenced by both the old and new states; given that patch 3/4 attempts
> >> to undo everything in the failed application of the new state, I think
> >> this "re-apply the old state" code should simple run through everything
> >> in the old state any apply it unconditionally.
> >
> > So, if I understand correctly, it could be as simple as that:
> > }
> >
> > - if (old_state) {
> > - list_for_each_entry(setting, _state->settings, node) {
> > - bool found = false;
> > - if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
> > - continue;
> > - list_for_each_entry(setting2, >settings, node) {
> > - if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
> > - continue;
> > - if (setting2->data.mux.group ==
> > - setting->data.mux.group) {
> > - found = true;
> > - break;
> > - }
> > - }
> > - if (!found)
> > - pinmux_enable_setting(setting);
> > - }
> > - }
> > -
> > p->state = old_state;
>
> I think you want to remove that line too, so that p->state == NULL in
> the error case, so that if the pinctrl_select_state_locked() call below
> also fails to restore the old state, then (!old_state) will be true
> inside the recursive call, so it doesn't recurse into itself forever.
>
> > + if (old_state)
> > + pinctrl_select_state_locked(p, NULL);
>
> You want to pass old_state rather than NULL there, I think.
Hum, I'm starting to code nonsense. It's time to go home !
But yes, we clearly don't want to have p->state != NULL in the recursive
call (I've seen that, and an evil force made me wrote the contrary :))
So, just:
+ if (old_state)
+ pinctrl_select_state_locked(p, old_state);
Will do the trick.
It can't loop forever as p->state is null.
If it fails, p->state will be still null.
If it succeeds, p->state will be == old_state, and that's what we want.
Got it !(finally)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On 03/28/2013 11:34 AM, Richard GENOUD wrote:
> On [mer., 27.03.2013 17:55:45], Stephen Warren wrote:
>> On 03/25/2013 08:47 AM, Richard Genoud wrote:
>>> If a new state is applied, the groups configured in the old state but
>>> not in the new state are disabled.
>>> If something goes wrong and the new state can't be applied, we have to
>>> re-enable those groups.
>>
>> What is the use-case for this? I wonder if it isn't better to simply
>> undo the partial selection of the new state (as patch 3/4 attempts to
>> do) and then leave p->state==NULL, indicating that no state is actively
>> selected. IIRC, this would be the same as right after the initial
>> pinctrl_select().
>>
>> I wonder if it's likely that attempting to re-apply the old state would
>> actually work, given that applying something just failed.
>>
>> Finally, this recovery code doesn't:
>>
>> a) Process anything except MUX_GROUP; any pin config settings in the old
>> state aren't restored.
>>
>> b) (I think) Apply any mux settings that don't involve groups that are
>> referenced by both the old and new states; given that patch 3/4 attempts
>> to undo everything in the failed application of the new state, I think
>> this "re-apply the old state" code should simple run through everything
>> in the old state any apply it unconditionally.
>
> So, if I understand correctly, it could be as simple as that:
> }
>
> - if (old_state) {
> - list_for_each_entry(setting, _state->settings, node) {
> - bool found = false;
> - if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
> - continue;
> - list_for_each_entry(setting2, >settings, node) {
> - if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
> - continue;
> - if (setting2->data.mux.group ==
> - setting->data.mux.group) {
> - found = true;
> - break;
> - }
> - }
> - if (!found)
> - pinmux_enable_setting(setting);
> - }
> - }
> -
> p->state = old_state;
I think you want to remove that line too, so that p->state == NULL in
the error case, so that if the pinctrl_select_state_locked() call below
also fails to restore the old state, then (!old_state) will be true
inside the recursive call, so it doesn't recurse into itself forever.
> + if (old_state)
> + pinctrl_select_state_locked(p, NULL);
You want to pass old_state rather than NULL there, I think.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On [mer., 27.03.2013 17:55:45], Stephen Warren wrote:
> On 03/25/2013 08:47 AM, Richard Genoud wrote:
> > If a new state is applied, the groups configured in the old state but
> > not in the new state are disabled.
> > If something goes wrong and the new state can't be applied, we have to
> > re-enable those groups.
>
> What is the use-case for this? I wonder if it isn't better to simply
> undo the partial selection of the new state (as patch 3/4 attempts to
> do) and then leave p->state==NULL, indicating that no state is actively
> selected. IIRC, this would be the same as right after the initial
> pinctrl_select().
>
> I wonder if it's likely that attempting to re-apply the old state would
> actually work, given that applying something just failed.
>
> Finally, this recovery code doesn't:
>
> a) Process anything except MUX_GROUP; any pin config settings in the old
> state aren't restored.
>
> b) (I think) Apply any mux settings that don't involve groups that are
> referenced by both the old and new states; given that patch 3/4 attempts
> to undo everything in the failed application of the new state, I think
> this "re-apply the old state" code should simple run through everything
> in the old state any apply it unconditionally.
So, if I understand correctly, it could be as simple as that:
}
- if (old_state) {
- list_for_each_entry(setting, _state->settings, node) {
- bool found = false;
- if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- list_for_each_entry(setting2, >settings, node) {
- if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- if (setting2->data.mux.group ==
- setting->data.mux.group) {
- found = true;
- break;
- }
- }
- if (!found)
- pinmux_enable_setting(setting);
- }
- }
-
p->state = old_state;
+
+ if (old_state)
+ pinctrl_select_state_locked(p, NULL);
+
return ret;
}
>
> c) Set p->state = oldstate, so it's left at NULL, which would confuse
> any future pinctrl_select().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
2013/3/28 Stephen Warren : > On 03/25/2013 08:47 AM, Richard Genoud wrote: >> If a new state is applied, the groups configured in the old state but >> not in the new state are disabled. >> If something goes wrong and the new state can't be applied, we have to >> re-enable those groups. > > What is the use-case for this? I wonder if it isn't better to simply > undo the partial selection of the new state (as patch 3/4 attempts to > do) and then leave p->state==NULL, indicating that no state is actively > selected. IIRC, this would be the same as right after the initial > pinctrl_select(). > > I wonder if it's likely that attempting to re-apply the old state would > actually work, given that applying something just failed. > > Finally, this recovery code doesn't: > > a) Process anything except MUX_GROUP; any pin config settings in the old > state aren't restored. > > b) (I think) Apply any mux settings that don't involve groups that are > referenced by both the old and new states; given that patch 3/4 attempts > to undo everything in the failed application of the new state, I think > this "re-apply the old state" code should simple run through everything > in the old state any apply it unconditionally. Well, I'm not comfortable enough with this code to argue on that... > c) Set p->state = oldstate, so it's left at NULL, which would confuse > any future pinctrl_select(). Arrrggg ! I forgot it ! I'll send a fix on that -- for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On [mer., 27.03.2013 17:55:45], Stephen Warren wrote:
On 03/25/2013 08:47 AM, Richard Genoud wrote:
If a new state is applied, the groups configured in the old state but
not in the new state are disabled.
If something goes wrong and the new state can't be applied, we have to
re-enable those groups.
What is the use-case for this? I wonder if it isn't better to simply
undo the partial selection of the new state (as patch 3/4 attempts to
do) and then leave p-state==NULL, indicating that no state is actively
selected. IIRC, this would be the same as right after the initial
pinctrl_select().
I wonder if it's likely that attempting to re-apply the old state would
actually work, given that applying something just failed.
Finally, this recovery code doesn't:
a) Process anything except MUX_GROUP; any pin config settings in the old
state aren't restored.
b) (I think) Apply any mux settings that don't involve groups that are
referenced by both the old and new states; given that patch 3/4 attempts
to undo everything in the failed application of the new state, I think
this re-apply the old state code should simple run through everything
in the old state any apply it unconditionally.
So, if I understand correctly, it could be as simple as that:
}
- if (old_state) {
- list_for_each_entry(setting, old_state-settings, node) {
- bool found = false;
- if (setting-type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- list_for_each_entry(setting2, state-settings, node) {
- if (setting2-type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- if (setting2-data.mux.group ==
- setting-data.mux.group) {
- found = true;
- break;
- }
- }
- if (!found)
- pinmux_enable_setting(setting);
- }
- }
-
p-state = old_state;
+
+ if (old_state)
+ pinctrl_select_state_locked(p, NULL);
+
return ret;
}
c) Set p-state = oldstate, so it's left at NULL, which would confuse
any future pinctrl_select().
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On 03/28/2013 11:34 AM, Richard GENOUD wrote:
On [mer., 27.03.2013 17:55:45], Stephen Warren wrote:
On 03/25/2013 08:47 AM, Richard Genoud wrote:
If a new state is applied, the groups configured in the old state but
not in the new state are disabled.
If something goes wrong and the new state can't be applied, we have to
re-enable those groups.
What is the use-case for this? I wonder if it isn't better to simply
undo the partial selection of the new state (as patch 3/4 attempts to
do) and then leave p-state==NULL, indicating that no state is actively
selected. IIRC, this would be the same as right after the initial
pinctrl_select().
I wonder if it's likely that attempting to re-apply the old state would
actually work, given that applying something just failed.
Finally, this recovery code doesn't:
a) Process anything except MUX_GROUP; any pin config settings in the old
state aren't restored.
b) (I think) Apply any mux settings that don't involve groups that are
referenced by both the old and new states; given that patch 3/4 attempts
to undo everything in the failed application of the new state, I think
this re-apply the old state code should simple run through everything
in the old state any apply it unconditionally.
So, if I understand correctly, it could be as simple as that:
}
- if (old_state) {
- list_for_each_entry(setting, old_state-settings, node) {
- bool found = false;
- if (setting-type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- list_for_each_entry(setting2, state-settings, node) {
- if (setting2-type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- if (setting2-data.mux.group ==
- setting-data.mux.group) {
- found = true;
- break;
- }
- }
- if (!found)
- pinmux_enable_setting(setting);
- }
- }
-
p-state = old_state;
I think you want to remove that line too, so that p-state == NULL in
the error case, so that if the pinctrl_select_state_locked() call below
also fails to restore the old state, then (!old_state) will be true
inside the recursive call, so it doesn't recurse into itself forever.
+ if (old_state)
+ pinctrl_select_state_locked(p, NULL);
You want to pass old_state rather than NULL there, I think.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On [jeu., 28.03.2013 11:38:23], Stephen Warren wrote:
On 03/28/2013 11:34 AM, Richard GENOUD wrote:
On [mer., 27.03.2013 17:55:45], Stephen Warren wrote:
On 03/25/2013 08:47 AM, Richard Genoud wrote:
If a new state is applied, the groups configured in the old state but
not in the new state are disabled.
If something goes wrong and the new state can't be applied, we have to
re-enable those groups.
What is the use-case for this? I wonder if it isn't better to simply
undo the partial selection of the new state (as patch 3/4 attempts to
do) and then leave p-state==NULL, indicating that no state is actively
selected. IIRC, this would be the same as right after the initial
pinctrl_select().
I wonder if it's likely that attempting to re-apply the old state would
actually work, given that applying something just failed.
Finally, this recovery code doesn't:
a) Process anything except MUX_GROUP; any pin config settings in the old
state aren't restored.
b) (I think) Apply any mux settings that don't involve groups that are
referenced by both the old and new states; given that patch 3/4 attempts
to undo everything in the failed application of the new state, I think
this re-apply the old state code should simple run through everything
in the old state any apply it unconditionally.
So, if I understand correctly, it could be as simple as that:
}
- if (old_state) {
- list_for_each_entry(setting, old_state-settings, node) {
- bool found = false;
- if (setting-type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- list_for_each_entry(setting2, state-settings, node) {
- if (setting2-type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- if (setting2-data.mux.group ==
- setting-data.mux.group) {
- found = true;
- break;
- }
- }
- if (!found)
- pinmux_enable_setting(setting);
- }
- }
-
p-state = old_state;
I think you want to remove that line too, so that p-state == NULL in
the error case, so that if the pinctrl_select_state_locked() call below
also fails to restore the old state, then (!old_state) will be true
inside the recursive call, so it doesn't recurse into itself forever.
+ if (old_state)
+ pinctrl_select_state_locked(p, NULL);
You want to pass old_state rather than NULL there, I think.
Hum, I'm starting to code nonsense. It's time to go home !
But yes, we clearly don't want to have p-state != NULL in the recursive
call (I've seen that, and an evil force made me wrote the contrary :))
So, just:
+ if (old_state)
+ pinctrl_select_state_locked(p, old_state);
Will do the trick.
It can't loop forever as p-state is null.
If it fails, p-state will be still null.
If it succeeds, p-state will be == old_state, and that's what we want.
Got it !(finally)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
2013/3/28 Stephen Warren swar...@wwwdotorg.org: On 03/25/2013 08:47 AM, Richard Genoud wrote: If a new state is applied, the groups configured in the old state but not in the new state are disabled. If something goes wrong and the new state can't be applied, we have to re-enable those groups. What is the use-case for this? I wonder if it isn't better to simply undo the partial selection of the new state (as patch 3/4 attempts to do) and then leave p-state==NULL, indicating that no state is actively selected. IIRC, this would be the same as right after the initial pinctrl_select(). I wonder if it's likely that attempting to re-apply the old state would actually work, given that applying something just failed. Finally, this recovery code doesn't: a) Process anything except MUX_GROUP; any pin config settings in the old state aren't restored. b) (I think) Apply any mux settings that don't involve groups that are referenced by both the old and new states; given that patch 3/4 attempts to undo everything in the failed application of the new state, I think this re-apply the old state code should simple run through everything in the old state any apply it unconditionally. Well, I'm not comfortable enough with this code to argue on that... c) Set p-state = oldstate, so it's left at NULL, which would confuse any future pinctrl_select(). Arrrggg ! I forgot it ! I'll send a fix on that -- for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On 03/25/2013 08:47 AM, Richard Genoud wrote: > If a new state is applied, the groups configured in the old state but > not in the new state are disabled. > If something goes wrong and the new state can't be applied, we have to > re-enable those groups. What is the use-case for this? I wonder if it isn't better to simply undo the partial selection of the new state (as patch 3/4 attempts to do) and then leave p->state==NULL, indicating that no state is actively selected. IIRC, this would be the same as right after the initial pinctrl_select(). I wonder if it's likely that attempting to re-apply the old state would actually work, given that applying something just failed. Finally, this recovery code doesn't: a) Process anything except MUX_GROUP; any pin config settings in the old state aren't restored. b) (I think) Apply any mux settings that don't involve groups that are referenced by both the old and new states; given that patch 3/4 attempts to undo everything in the failed application of the new state, I think this "re-apply the old state" code should simple run through everything in the old state any apply it unconditionally. c) Set p->state = oldstate, so it's left at NULL, which would confuse any future pinctrl_select(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On Mon, Mar 25, 2013 at 3:47 PM, Richard Genoud wrote: > If a new state is applied, the groups configured in the old state but > not in the new state are disabled. > If something goes wrong and the new state can't be applied, we have to > re-enable those groups. > > Signed-off-by: Richard Genoud Another very tasty patch, applied! Thanks! Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On Mon, Mar 25, 2013 at 3:47 PM, Richard Genoud richard.gen...@gmail.com wrote: If a new state is applied, the groups configured in the old state but not in the new state are disabled. If something goes wrong and the new state can't be applied, we have to re-enable those groups. Signed-off-by: Richard Genoud richard.gen...@gmail.com Another very tasty patch, applied! Thanks! Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
On 03/25/2013 08:47 AM, Richard Genoud wrote: If a new state is applied, the groups configured in the old state but not in the new state are disabled. If something goes wrong and the new state can't be applied, we have to re-enable those groups. What is the use-case for this? I wonder if it isn't better to simply undo the partial selection of the new state (as patch 3/4 attempts to do) and then leave p-state==NULL, indicating that no state is actively selected. IIRC, this would be the same as right after the initial pinctrl_select(). I wonder if it's likely that attempting to re-apply the old state would actually work, given that applying something just failed. Finally, this recovery code doesn't: a) Process anything except MUX_GROUP; any pin config settings in the old state aren't restored. b) (I think) Apply any mux settings that don't involve groups that are referenced by both the old and new states; given that patch 3/4 attempts to undo everything in the failed application of the new state, I think this re-apply the old state code should simple run through everything in the old state any apply it unconditionally. c) Set p-state = oldstate, so it's left at NULL, which would confuse any future pinctrl_select(). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
If a new state is applied, the groups configured in the old state but
not in the new state are disabled.
If something goes wrong and the new state can't be applied, we have to
re-enable those groups.
Signed-off-by: Richard Genoud
---
drivers/pinctrl/core.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 350d5f8..9b505acc 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -861,6 +861,7 @@ static int pinctrl_select_state_locked(struct pinctrl *p,
struct pinctrl_state *state)
{
struct pinctrl_setting *setting, *setting2;
+ struct pinctrl_state *old_state = p->state;
int ret;
if (p->state == state)
@@ -937,7 +938,24 @@ unapply_new_state:
pinctrl_free_setting(true, setting2);
}
reapply_old_state:
- /* FIXME: re-enable old setting */
+ if (old_state) {
+ list_for_each_entry(setting, _state->settings, node) {
+ bool found = false;
+ if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
+ continue;
+ list_for_each_entry(setting2, >settings, node) {
+ if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
+ continue;
+ if (setting2->data.mux.group ==
+ setting->data.mux.group) {
+ found = true;
+ break;
+ }
+ }
+ if (!found)
+ pinmux_enable_setting(setting);
+ }
+ }
return ret;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] pinctrl: re-enable old state in case of error in pinctrl_select_state
If a new state is applied, the groups configured in the old state but
not in the new state are disabled.
If something goes wrong and the new state can't be applied, we have to
re-enable those groups.
Signed-off-by: Richard Genoud richard.gen...@gmail.com
---
drivers/pinctrl/core.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 350d5f8..9b505acc 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -861,6 +861,7 @@ static int pinctrl_select_state_locked(struct pinctrl *p,
struct pinctrl_state *state)
{
struct pinctrl_setting *setting, *setting2;
+ struct pinctrl_state *old_state = p-state;
int ret;
if (p-state == state)
@@ -937,7 +938,24 @@ unapply_new_state:
pinctrl_free_setting(true, setting2);
}
reapply_old_state:
- /* FIXME: re-enable old setting */
+ if (old_state) {
+ list_for_each_entry(setting, old_state-settings, node) {
+ bool found = false;
+ if (setting-type != PIN_MAP_TYPE_MUX_GROUP)
+ continue;
+ list_for_each_entry(setting2, state-settings, node) {
+ if (setting2-type != PIN_MAP_TYPE_MUX_GROUP)
+ continue;
+ if (setting2-data.mux.group ==
+ setting-data.mux.group) {
+ found = true;
+ break;
+ }
+ }
+ if (!found)
+ pinmux_enable_setting(setting);
+ }
+ }
return ret;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
