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

Groups > linux.kernel > #1550295 > unrolled thread

Re: [PATCH] gpio: pca953x: Add optional reset gpio control

Started byAndy Shevchenko <andy.shevchenko@gmail.com>
First post2017-01-04 00:40 +0100
Last post2017-01-10 20:00 +0100
Articles 5 — 3 participants

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] gpio: pca953x: Add optional reset gpio control Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-01-04 00:40 +0100
    Re: [PATCH] gpio: pca953x: Add optional reset gpio control Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> - 2017-01-04 11:30 +0100
      Re: [PATCH] gpio: pca953x: Add optional reset gpio control Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-01-04 11:40 +0100
        Re: [PATCH] gpio: pca953x: Add optional reset gpio control Steve Longerbeam <slongerbeam@gmail.com> - 2017-01-10 20:20 +0100
    Re: [PATCH] gpio: pca953x: Add optional reset gpio control Steve Longerbeam <slongerbeam@gmail.com> - 2017-01-10 20:00 +0100

#1550295 — Re: [PATCH] gpio: pca953x: Add optional reset gpio control

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-01-04 00:40 +0100
SubjectRe: [PATCH] gpio: pca953x: Add optional reset gpio control
Message-ID<sVGQp-4Vk-9@gated-at.bofh.it>
On Mon, Jan 2, 2017 at 11:07 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.

> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -22,6 +22,7 @@
>  #include <linux/of_platform.h>
>  #include <linux/acpi.h>
>  #include <linux/regulator/consumer.h>

> +#include <linux/gpio/consumer.h>

Please, try to put it somehow alphabetically ordered (yes, I see it's
not in general, but try to squeeze it into longest part which is
ordered).

>
>  #define PCA953X_INPUT          0
>  #define PCA953X_OUTPUT         1
> @@ -754,8 +755,18 @@ static int pca953x_probe(struct i2c_client *client,
>                 invert = pdata->invert;
>                 chip->names = pdata->names;
>         } else {
> +               struct gpio_desc *reset_gpio;
> +
>                 chip->gpio_start = -1;
>                 irq_base = 0;
> +
> +               /* see if we need to de-assert a reset pin */

see -> See

> +               reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> +                                                    GPIOD_OUT_LOW);

Shouldn't be _optional_exclusive?
See this recent discussion https://patchwork.ozlabs.org/patch/706002/

> +               if (IS_ERR(reset_gpio)) {
> +                       dev_err(&client->dev, "request for reset pin failed\n");
> +                       return PTR_ERR(reset_gpio);
> +               }
>         }

-- 
With Best Regards,
Andy Shevchenko

[toc] | [next] | [standalone]

#1550619

FromVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Date2017-01-04 11:30 +0100
Message-ID<sVQZr-3pc-9@gated-at.bofh.it>
In reply to#1550295
On 01/04/2017 01:37 AM, Andy Shevchenko wrote:
> On Mon, Jan 2, 2017 at 11:07 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
>> Add optional reset-gpios pin control. If present, de-assert the
>> specified reset gpio pin to bring the chip out of reset.
> 
>> --- a/drivers/gpio/gpio-pca953x.c
>> +++ b/drivers/gpio/gpio-pca953x.c
>> @@ -22,6 +22,7 @@
>>  #include <linux/of_platform.h>
>>  #include <linux/acpi.h>
>>  #include <linux/regulator/consumer.h>
> 
>> +#include <linux/gpio/consumer.h>
> 
> Please, try to put it somehow alphabetically ordered (yes, I see it's
> not in general, but try to squeeze it into longest part which is
> ordered).
> 
>>
>>  #define PCA953X_INPUT          0
>>  #define PCA953X_OUTPUT         1
>> @@ -754,8 +755,18 @@ static int pca953x_probe(struct i2c_client *client,
>>                 invert = pdata->invert;
>>                 chip->names = pdata->names;
>>         } else {
>> +               struct gpio_desc *reset_gpio;
>> +
>>                 chip->gpio_start = -1;
>>                 irq_base = 0;
>> +
>> +               /* see if we need to de-assert a reset pin */
> 
> see -> See
> 
>> +               reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
>> +                                                    GPIOD_OUT_LOW);
> 
> Shouldn't be _optional_exclusive?
> See this recent discussion https://patchwork.ozlabs.org/patch/706002/

There is no devm_gpiod_get_optional_exclusive(), probably you confuse
the function with devm_reset_control_get_optional_exclusive().

>> +               if (IS_ERR(reset_gpio)) {
>> +                       dev_err(&client->dev, "request for reset pin failed\n");
>> +                       return PTR_ERR(reset_gpio);
>> +               }
>>         }
> 

--
With best wishes,
Vladimir

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

#1550646

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-01-04 11:40 +0100
Message-ID<sVR98-3si-21@gated-at.bofh.it>
In reply to#1550619
On Wed, Jan 4, 2017 at 12:20 PM, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:
> On 01/04/2017 01:37 AM, Andy Shevchenko wrote:
>> On Mon, Jan 2, 2017 at 11:07 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
>>> Add optional reset-gpios pin control. If present, de-assert the
>>> specified reset gpio pin to bring the chip out of reset.
>>
>>> --- a/drivers/gpio/gpio-pca953x.c
>>> +++ b/drivers/gpio/gpio-pca953x.c
>>> @@ -22,6 +22,7 @@
>>>  #include <linux/of_platform.h>
>>>  #include <linux/acpi.h>
>>>  #include <linux/regulator/consumer.h>
>>
>>> +#include <linux/gpio/consumer.h>
>>
>> Please, try to put it somehow alphabetically ordered (yes, I see it's
>> not in general, but try to squeeze it into longest part which is
>> ordered).
>>
>>>
>>>  #define PCA953X_INPUT          0
>>>  #define PCA953X_OUTPUT         1
>>> @@ -754,8 +755,18 @@ static int pca953x_probe(struct i2c_client *client,
>>>                 invert = pdata->invert;
>>>                 chip->names = pdata->names;
>>>         } else {
>>> +               struct gpio_desc *reset_gpio;
>>> +
>>>                 chip->gpio_start = -1;
>>>                 irq_base = 0;
>>> +
>>> +               /* see if we need to de-assert a reset pin */
>>
>> see -> See
>>
>>> +               reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
>>> +                                                    GPIOD_OUT_LOW);
>>
>> Shouldn't be _optional_exclusive?
>> See this recent discussion https://patchwork.ozlabs.org/patch/706002/
>
> There is no devm_gpiod_get_optional_exclusive(), probably you confuse
> the function with devm_reset_control_get_optional_exclusive().

Perhaps it's time to add
drivers/reset/reset-gpio.c ?

>
>>> +               if (IS_ERR(reset_gpio)) {
>>> +                       dev_err(&client->dev, "request for reset pin failed\n");
>>> +                       return PTR_ERR(reset_gpio);
>>> +               }
>>>         }
>>
>
> --
> With best wishes,
> Vladimir



-- 
With Best Regards,
Andy Shevchenko

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

#1555839

FromSteve Longerbeam <slongerbeam@gmail.com>
Date2017-01-10 20:20 +0100
Message-ID<sYa7E-5fe-31@gated-at.bofh.it>
In reply to#1550646

On 01/04/2017 02:31 AM, Andy Shevchenko wrote:
>
>>>> +               reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
>>>> +                                                    GPIOD_OUT_LOW);
>>> Shouldn't be _optional_exclusive?
>>> See this recent discussion https://patchwork.ozlabs.org/patch/706002/
>> There is no devm_gpiod_get_optional_exclusive(), probably you confuse
>> the function with devm_reset_control_get_optional_exclusive().
> Perhaps it's time to add
> drivers/reset/reset-gpio.c ?

Yeah, looks like a GPIO based reset controller driver would need to be
implemented in order to go this route. The max7310 nodes in
imx6qdl-sabreauto.dtsi could then refer to that reset controller by the
'resets' phandle.

There are many many devices that would benefit from a GPIO reset
controller, I count 143 nodes under arch/arm/boot/dts that specify a
'reset-gpios' property.

But I don't have the time to write such a driver. So I would propose just
keeping the devm_gpiod_get_optional() call here. When such a gpio reset
controller is written, the work can begin to convert all the gpio reset 
users
to make use of it.

Steve

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

#1555822

FromSteve Longerbeam <slongerbeam@gmail.com>
Date2017-01-10 20:00 +0100
Message-ID<sY9Oi-4Tu-25@gated-at.bofh.it>
In reply to#1550295

On 01/03/2017 03:37 PM, Andy Shevchenko wrote:
> On Mon, Jan 2, 2017 at 11:07 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
>> Add optional reset-gpios pin control. If present, de-assert the
>> specified reset gpio pin to bring the chip out of reset.
>> --- a/drivers/gpio/gpio-pca953x.c
>> +++ b/drivers/gpio/gpio-pca953x.c
>> @@ -22,6 +22,7 @@
>>   #include <linux/of_platform.h>
>>   #include <linux/acpi.h>
>>   #include <linux/regulator/consumer.h>
>> +#include <linux/gpio/consumer.h>
> Please, try to put it somehow alphabetically ordered (yes, I see it's
> not in general, but try to squeeze it into longest part which is
> ordered).

done.

>
>>   #define PCA953X_INPUT          0
>>   #define PCA953X_OUTPUT         1
>> @@ -754,8 +755,18 @@ static int pca953x_probe(struct i2c_client *client,
>>                  invert = pdata->invert;
>>                  chip->names = pdata->names;
>>          } else {
>> +               struct gpio_desc *reset_gpio;
>> +
>>                  chip->gpio_start = -1;
>>                  irq_base = 0;
>> +
>> +               /* see if we need to de-assert a reset pin */
> see -> See

done.


Steve

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web