From: Sonic Zhang <[email protected]>
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 <[email protected]>
---
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
On Wed, Aug 14, 2013 at 7:26 AM, Sonic Zhang <[email protected]> wrote:
> From: Sonic Zhang <[email protected]>
>
> 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 <[email protected]>
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
On 08/14/2013 09:54 AM, Linus Walleij wrote:
> On Wed, Aug 14, 2013 at 7:26 AM, Sonic Zhang <[email protected]> wrote:
>
>> From: Sonic Zhang <[email protected]>
>>
>> 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 <[email protected]>
>
> 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?
On Wed, Aug 14, 2013 at 6:21 PM, Stephen Warren <[email protected]> wrote:
> On 08/14/2013 09:54 AM, Linus Walleij wrote:
>> On Wed, Aug 14, 2013 at 7:26 AM, Sonic Zhang <[email protected]> wrote:
>>
>>> From: Sonic Zhang <[email protected]>
>>>
>>> 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 <[email protected]>
>>
>> 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
On 08/14/2013 10:27 AM, Linus Walleij wrote:
> On Wed, Aug 14, 2013 at 6:21 PM, Stephen Warren <[email protected]> wrote:
>> On 08/14/2013 09:54 AM, Linus Walleij wrote:
>>> On Wed, Aug 14, 2013 at 7:26 AM, Sonic Zhang <[email protected]> wrote:
>>>
>>>> From: Sonic Zhang <[email protected]>
>>>>
>>>> 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 <[email protected]>
>>>
>>> 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.