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

[Sonic Zhang]

Hi Linus,

On Thu, Aug 8, 2013 at 12:23 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> On Wed, Jul 17, 2013 at 7:31 AM, Sonic Zhang <sonic.adi@xxxxxxxxx> wrote:
>
> I'd like Stephen and Axel to have a look at this as well...
>
>> From: Sonic Zhang <sonic.zhang@xxxxxxxxxx>
>>
>> in pinmux_disable_setting after current device fails to request
>> the same pins.
>>
>> Signed-off-by: Sonic Zhang <sonic.zhang@xxxxxxxxxx>
>
> I don't quite understand the patch. Can you provide more context?
>
>> diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
>> index 88cc509..9ebcf3b 100644
>> --- a/drivers/pinctrl/pinmux.c
>> +++ b/drivers/pinctrl/pinmux.c
>> @@ -482,13 +482,14 @@ void pinmux_disable_setting(struct pinctrl_setting const *setting)
>>                                  pins[i]);
>>                         continue;
>>                 }
>> +               /* And release the pins */
>> +               if (desc->mux_usecount &&
>> +                       !strcmp(desc->mux_owner, setting->dev_name))
>> +                       pin_free(pctldev, pins[i], NULL);
>> +
>>                 desc->mux_setting = NULL;
>>         }
>>
>> -       /* And release the pins */
>> -       for (i = 0; i < num_pins; i++)
>> -               pin_free(pctldev, pins[i], NULL);
>> -
>
> For pinmux_disable_setting() to inspect desc->mux_usecount seems
> assymetric. This is something pin_free() should do, shouldn't it?
>
> Should not this codepath be kept and a change made inside pin_free()
> for the check above instead?
>

You can't move this codepath into pin_free(), because the pointer to
structure pinctrl_setting is not passed through pin_free(). But yes,
checking desc->mux_usecount is not necessary here, because pin_free()
has already handled that.

I will remove desc->mux_usecount checking in next patch.

Regards,

Sonic
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/