[PATCH v4] pinctrl: pinmux: Don't free pins requested by other devices in pinmux_disable_setting.

[PATCH v4] pinctrl: pinmux: Don't free pins requested by other devices in pinmux_disable_setting.

[Sonic Zhang]

From: Sonic Zhang <sonic.zhang@analog.com>

One peripheral may share part of its pins with the 2nd
peripheral and the other pins with the 3rd. If it requests all pins
when part of them has already be requested and owned by the 2nd
peripheral, this request fails and pinmux_disable_setting() is called.
The pinmux_disable_setting() frees all pins of the first peripheral
without checking if the pin is owned by itself or the 2nd, which
results in the malfunction of the 2nd peripheral driver.

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
 drivers/pinctrl/pinmux.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 88cc509..5f51588 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -482,13 +482,13 @@ void pinmux_disable_setting(struct pinctrl_setting const *setting)
 				 pins[i]);
 			continue;
 		}
-		desc->mux_setting = NULL;
+		if (desc->mux_setting == &(setting->data.mux)) {
+			desc->mux_setting = NULL;
+			/* And release the pin */
+			pin_free(pctldev, pins[i], NULL);
+		}
 	}
 
-	/* And release the pins */
-	for (i = 0; i < num_pins; i++)
-		pin_free(pctldev, pins[i], NULL);
-
 	if (ops->disable)
 		ops->disable(pctldev, setting->data.mux.func, setting->data.mux.group);
 }
-- 
1.8.2.3

Re: [PATCH v4] pinctrl: pinmux: Don't free pins requested by other devices in pinmux_disable_setting.

[Linus Walleij]

On Wed, Aug 14, 2013 at 7:26 AM, Sonic Zhang <sonic.adi@gmail.com> wrote:

> From: Sonic Zhang <sonic.zhang@analog.com>
>
> One peripheral may share part of its pins with the 2nd
> peripheral and the other pins with the 3rd. If it requests all pins
> when part of them has already be requested and owned by the 2nd
> peripheral, this request fails and pinmux_disable_setting() is called.
> The pinmux_disable_setting() frees all pins of the first peripheral
> without checking if the pin is owned by itself or the 2nd, which
> results in the malfunction of the 2nd peripheral driver.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>

Hm it makes some sense so patch applied.

That said I think we currently have drivers where a pin group
mapped to a certain function in a certain setting  *usually*
don't overlap with pins in another group used with another
function, and having it so seems racy, i.e. it will be some
first-come-first-serve effect.

I will add a warning print.

Yours,
Linus Walleij

Re: [PATCH v4] pinctrl: pinmux: Don't free pins requested by other devices in pinmux_disable_setting.

[Stephen Warren]

On 08/14/2013 09:54 AM, Linus Walleij wrote:
> On Wed, Aug 14, 2013 at 7:26 AM, Sonic Zhang <sonic.adi@gmail.com> wrote:
> 
>> From: Sonic Zhang <sonic.zhang@analog.com>
>>
>> One peripheral may share part of its pins with the 2nd
>> peripheral and the other pins with the 3rd. If it requests all pins
>> when part of them has already be requested and owned by the 2nd
>> peripheral, this request fails and pinmux_disable_setting() is called.
>> The pinmux_disable_setting() frees all pins of the first peripheral
>> without checking if the pin is owned by itself or the 2nd, which
>> results in the malfunction of the 2nd peripheral driver.
>>
>> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> 
> Hm it makes some sense so patch applied.
> 
> That said I think we currently have drivers where a pin group
> mapped to a certain function in a certain setting  *usually*
> don't overlap with pins in another group used with another
> function, and having it so seems racy, i.e. it will be some
> first-come-first-serve effect.
> 
> I will add a warning print.

Surely there's a warning print already when the enable_setting() fails,
so we don't need to do any more warning prints when the free_setting()
cleans up after that?

Re: [PATCH v4] pinctrl: pinmux: Don't free pins requested by other devices in pinmux_disable_setting.

[Linus Walleij]

On Wed, Aug 14, 2013 at 6:21 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 08/14/2013 09:54 AM, Linus Walleij wrote:
>> On Wed, Aug 14, 2013 at 7:26 AM, Sonic Zhang <sonic.adi@gmail.com> wrote:
>>
>>> From: Sonic Zhang <sonic.zhang@analog.com>
>>>
>>> One peripheral may share part of its pins with the 2nd
>>> peripheral and the other pins with the 3rd. If it requests all pins
>>> when part of them has already be requested and owned by the 2nd
>>> peripheral, this request fails and pinmux_disable_setting() is called.
>>> The pinmux_disable_setting() frees all pins of the first peripheral
>>> without checking if the pin is owned by itself or the 2nd, which
>>> results in the malfunction of the 2nd peripheral driver.
>>>
>>> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
>>
>> Hm it makes some sense so patch applied.
>>
>> That said I think we currently have drivers where a pin group
>> mapped to a certain function in a certain setting  *usually*
>> don't overlap with pins in another group used with another
>> function, and having it so seems racy, i.e. it will be some
>> first-come-first-serve effect.
>>
>> I will add a warning print.
>
> Surely there's a warning print already when the enable_setting() fails,
> so we don't need to do any more warning prints when the free_setting()
> cleans up after that?

Now I'm confused ... I added debug prints to pinmux_disable_setting()
which is where the patch hits? free_setting() is just an empty function
body still.

Yours,
Linus Walleij

Re: [PATCH v4] pinctrl: pinmux: Don't free pins requested by other devices in pinmux_disable_setting.

[Stephen Warren]

On 08/14/2013 10:27 AM, Linus Walleij wrote:
> On Wed, Aug 14, 2013 at 6:21 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 08/14/2013 09:54 AM, Linus Walleij wrote:
>>> On Wed, Aug 14, 2013 at 7:26 AM, Sonic Zhang <sonic.adi@gmail.com> wrote:
>>>
>>>> From: Sonic Zhang <sonic.zhang@analog.com>
>>>>
>>>> One peripheral may share part of its pins with the 2nd
>>>> peripheral and the other pins with the 3rd. If it requests all pins
>>>> when part of them has already be requested and owned by the 2nd
>>>> peripheral, this request fails and pinmux_disable_setting() is called.
>>>> The pinmux_disable_setting() frees all pins of the first peripheral
>>>> without checking if the pin is owned by itself or the 2nd, which
>>>> results in the malfunction of the 2nd peripheral driver.
>>>>
>>>> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
>>>
>>> Hm it makes some sense so patch applied.
>>>
>>> That said I think we currently have drivers where a pin group
>>> mapped to a certain function in a certain setting  *usually*
>>> don't overlap with pins in another group used with another
>>> function, and having it so seems racy, i.e. it will be some
>>> first-come-first-serve effect.
>>>
>>> I will add a warning print.
>>
>> Surely there's a warning print already when the enable_setting() fails,
>> so we don't need to do any more warning prints when the free_setting()
>> cleans up after that?
> 
> Now I'm confused ... I added debug prints to pinmux_disable_setting()
> which is where the patch hits? free_setting() is just an empty function
> body still.

I wrote the wrong function name; s/free_setting/disable_setting/ in what
I wrote.