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

[Sonic Zhang]

Hi Stephen,

On Thu, Aug 8, 2013 at 1:09 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> On 08/07/2013 10:23 AM, Linus Walleij 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?
>
> Yes, the commit description needs to describe the problem this solves.
>
> I'm *guessing* the issue is:
>
> Something tries to enable a new mux setting on some pins. One of those
> pins is already owned by something else. So, applying the current
> setting fails. So, pinctrl core attempts to unapply the partially
> applied setting. This ends up incorrectly over-writing the conflicting
> ownership of the pins with NULL, and hence forgetting about it.
>
> I think a better change would be something more along the lines of:
>
>   for (i = 0; i < num_pins; i++)
> +       if (this_device_owns_pin(pins[i])
>                 pin_free(pctldev, pins[i], NULL);
>
> ?
>
> Where this_device_owns_pin() might be someting like:
>
>         desc->owning_setting == setting
>
> (which would be a new field that needed to be assigned during
> pinmux_enable_setting).
>
> Or perhaps the strcmp() is fine.
>

You are right. 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.

I am fine to compare owner's pinctrl_setting structure other than name string.

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/