Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1181421 > unrolled thread

Re: [PATCH v1 1/3] gpio: defer probe if pinctrl cannot be found

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v1 1/3] gpio: defer probe if pinctrl cannot be found Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-07-10 11:40 +0200
    Re: [PATCH v1 1/3] gpio: defer probe if pinctrl cannot be found Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-07-10 18:30 +0200
      Re: [PATCH v1 1/3] gpio: defer probe if pinctrl cannot be found Stephen Warren <swarren@wwwdotorg.org> - 2015-07-10 19:10 +0200

#1181421 — Re: [PATCH v1 1/3] gpio: defer probe if pinctrl cannot be found

On 1 July 2015 at 19:36, Rob Herring <robherring2@gmail.com> wrote:
> On Wed, Jul 1, 2015 at 7:45 AM, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
>> When an OF node has a pin range for its GPIOs, return -EPROBE_DEFER if
>> the pin controller isn't available.
>>
>> Otherwise, the GPIO range wouldn't be set at all unless the pin
>> controller probed always before the GPIO chip.
>>
>> With this change, the probe of the GPIO chip will be deferred and will
>> be retried at a later point, hopefully once the pin controller has been
>> registered and probed already.
>
> This will break cases where the pinctrl driver does not exist, but the
> DT contains pinctrl bindings. We can have similar problems already
> with clocks though. However, IMO this problem is a bit different in
> that pinctrl is more likely entirely optional while clocks are often
> required. You may do all pin setup in bootloader/firmware on some
> boards and not others. Of course then why put pinctrl in the DT in
> that case? They could be present just due to how chip vs. board dts
> files are structured.

I see. My instinct tells me that it would be better if the gpio-ranges
property was set in the board dts, but I don't really know what each
mach does with its DTSs.

> We could address this by simply marking the pin controller node
> disabled. However, ...
>
>> @@ -361,7 +361,7 @@ static void of_gpiochip_add_pin_range(struct gpio_chip *chip)
>>
>>                 pctldev = of_pinctrl_get(pinspec.np);
>>                 if (!pctldev)
>> -                       break;
>> +                       return -EPROBE_DEFER;
>
> But you cannot distinguish that case here. I think of_pinctrl_get
> needs to set the error code appropriately.

Why not? I was thinking of just doing this before we call of_pinctrl_get():

        if (!of_device_is_available(pinspec.np))
            continue;

Thanks,

Tomeu

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

[toc] | [next] | [standalone]

#1181732

On 10 July 2015 at 17:27, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 07/10/2015 03:29 AM, Tomeu Vizoso wrote:
>>
>> On 1 July 2015 at 19:36, Rob Herring <robherring2@gmail.com> wrote:
>>>
>>> On Wed, Jul 1, 2015 at 7:45 AM, Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>> wrote:
>>>>
>>>> When an OF node has a pin range for its GPIOs, return -EPROBE_DEFER if
>>>> the pin controller isn't available.
>>>>
>>>> Otherwise, the GPIO range wouldn't be set at all unless the pin
>>>> controller probed always before the GPIO chip.
>>>>
>>>> With this change, the probe of the GPIO chip will be deferred and will
>>>> be retried at a later point, hopefully once the pin controller has been
>>>> registered and probed already.
>>>
>>>
>>> This will break cases where the pinctrl driver does not exist, but the
>>> DT contains pinctrl bindings. We can have similar problems already
>>> with clocks though. However, IMO this problem is a bit different in
>>> that pinctrl is more likely entirely optional while clocks are often
>>> required. You may do all pin setup in bootloader/firmware on some
>>> boards and not others. Of course then why put pinctrl in the DT in
>>> that case? They could be present just due to how chip vs. board dts
>>> files are structured.
>>
>>
>> I see. My instinct tells me that it would be better if the gpio-ranges
>> property was set in the board dts, but I don't really know what each
>> mach does with its DTSs.
>
>
> That doesn't make sense; the mapping between GPIO controller pins and pin
> controller pins is a property of the SoC not the board.

From what Rob said above, apparently some boards will rely on the pin
setup done by the bootloader, and some other boards with the same soc
will want to do it in the kernel. So it's not really a difference in
the hw itself, but what expectations exist about the firmware on a
specific board.

Regards,

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

[toc] | [prev] | [next] | [standalone]

#1181765

On 07/10/2015 10:21 AM, Tomeu Vizoso wrote:
> On 10 July 2015 at 17:27, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 07/10/2015 03:29 AM, Tomeu Vizoso wrote:
>>>
>>> On 1 July 2015 at 19:36, Rob Herring <robherring2@gmail.com> wrote:
>>>>
>>>> On Wed, Jul 1, 2015 at 7:45 AM, Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>>> wrote:
>>>>>
>>>>> When an OF node has a pin range for its GPIOs, return -EPROBE_DEFER if
>>>>> the pin controller isn't available.
>>>>>
>>>>> Otherwise, the GPIO range wouldn't be set at all unless the pin
>>>>> controller probed always before the GPIO chip.
>>>>>
>>>>> With this change, the probe of the GPIO chip will be deferred and will
>>>>> be retried at a later point, hopefully once the pin controller has been
>>>>> registered and probed already.
>>>>
>>>>
>>>> This will break cases where the pinctrl driver does not exist, but the
>>>> DT contains pinctrl bindings. We can have similar problems already
>>>> with clocks though. However, IMO this problem is a bit different in
>>>> that pinctrl is more likely entirely optional while clocks are often
>>>> required. You may do all pin setup in bootloader/firmware on some
>>>> boards and not others. Of course then why put pinctrl in the DT in
>>>> that case? They could be present just due to how chip vs. board dts
>>>> files are structured.
>>>
>>>
>>> I see. My instinct tells me that it would be better if the gpio-ranges
>>> property was set in the board dts, but I don't really know what each
>>> mach does with its DTSs.
>>
>>
>> That doesn't make sense; the mapping between GPIO controller pins and pin
>> controller pins is a property of the SoC not the board.
>
>  From what Rob said above, apparently some boards will rely on the pin
> setup done by the bootloader, and some other boards with the same soc
> will want to do it in the kernel. So it's not really a difference in
> the hw itself, but what expectations exist about the firmware on a
> specific board.

Sure, but none of that changes the mapping between the GPIO and pin 
controller pins.

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web