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

Groups > linux.kernel > #1168602 > unrolled thread

Re: [PATCH v2 3/5] extcon: arizona: Convert to gpiod

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 v2 3/5] extcon: arizona: Convert to gpiod Charles Keepax <ckeepax@opensource.wolfsonmicro.com> - 2015-06-19 10:20 +0200
    Re: [PATCH v2 3/5] extcon: arizona: Convert to gpiod Chanwoo Choi <cwchoi00@gmail.com> - 2015-06-19 10:40 +0200
      Re: [PATCH v2 3/5] extcon: arizona: Convert to gpiod Charles Keepax <ckeepax@opensource.wolfsonmicro.com> - 2015-06-19 11:20 +0200
        Re: [PATCH v2 3/5] extcon: arizona: Convert to gpiod Chanwoo Choi <cwchoi00@gmail.com> - 2015-06-19 12:00 +0200
          Re: [PATCH v2 3/5] extcon: arizona: Convert to gpiod Charles Keepax <ckeepax@opensource.wolfsonmicro.com> - 2015-06-19 12:00 +0200

#1168602 — Re: [PATCH v2 3/5] extcon: arizona: Convert to gpiod

On Fri, Jun 19, 2015 at 11:36:47AM +0900, Chanwoo Choi wrote:
> Hi Charles,
> 
> On Thu, Jun 18, 2015 at 11:43 PM, Charles Keepax
> <ckeepax@opensource.wolfsonmicro.com> wrote:
> > Convert to using the newer gpiod interface for the micd_pol_gpio.
> > Although we still carry support for the old gpio interface from pdata.
> >
> > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> > ---
> > +                       mode = GPIOD_OUT_HIGH;
> > +               else
> > +                       mode = GPIOD_OUT_LOW;
> > +
> > +               info->micd_pol_gpio = gpiod_get_optional(arizona->dev,
> > +                                                        "wlf,micd-pol",
> > +                                                        GPIOD_OUT_LOW);
> 
> You can use the devm_gpiod_get_optional() to manage the system
> resource automatically.
> 

We can't actually use the devm call here, we need to pass
arizona->dev as that is where the DT will reside, which is the
device for the MFD. But if the devm is attached to the device for
the MFD then it will not clear up when the extcon driver is
unloaded. As such we have to do the put manually.

I will look at respinning for the other comments.

Thanks,
Charles
--
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]

#1168614

On Fri, Jun 19, 2015 at 5:14 PM, Charles Keepax
<ckeepax@opensource.wolfsonmicro.com> wrote:
> On Fri, Jun 19, 2015 at 11:36:47AM +0900, Chanwoo Choi wrote:
>> Hi Charles,
>>
>> On Thu, Jun 18, 2015 at 11:43 PM, Charles Keepax
>> <ckeepax@opensource.wolfsonmicro.com> wrote:
>> > Convert to using the newer gpiod interface for the micd_pol_gpio.
>> > Although we still carry support for the old gpio interface from pdata.
>> >
>> > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>> > ---
>> > +                       mode = GPIOD_OUT_HIGH;
>> > +               else
>> > +                       mode = GPIOD_OUT_LOW;
>> > +
>> > +               info->micd_pol_gpio = gpiod_get_optional(arizona->dev,
>> > +                                                        "wlf,micd-pol",
>> > +                                                        GPIOD_OUT_LOW);
>>
>> You can use the devm_gpiod_get_optional() to manage the system
>> resource automatically.
>>
>
> We can't actually use the devm call here, we need to pass
> arizona->dev as that is where the DT will reside, which is the
> device for the MFD. But if the devm is attached to the device for
> the MFD then it will not clear up when the extcon driver is
> unloaded. As such we have to do the put manually.
>
> I will look at respinning for the other comments.

I don't understand. extcon-arizona.c used already following devm_* functions:
- devm_kzalloc()
- devm_regulator_get()
- devm_extcon_dev_*()
- devm_input_allocate_device()
- devm_gpio_request_one()

Thanks,
Chanwoo Choi
--
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]

#1168649

On Fri, Jun 19, 2015 at 05:39:22PM +0900, Chanwoo Choi wrote:
> On Fri, Jun 19, 2015 at 5:14 PM, Charles Keepax
> <ckeepax@opensource.wolfsonmicro.com> wrote:
> > On Fri, Jun 19, 2015 at 11:36:47AM +0900, Chanwoo Choi wrote:
> >> Hi Charles,
> >>
> >> On Thu, Jun 18, 2015 at 11:43 PM, Charles Keepax
> >> <ckeepax@opensource.wolfsonmicro.com> wrote:
> >> > Convert to using the newer gpiod interface for the micd_pol_gpio.
> >> > Although we still carry support for the old gpio interface from pdata.
> >> >
> >> > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> >> > ---
> >> > +                       mode = GPIOD_OUT_HIGH;
> >> > +               else
> >> > +                       mode = GPIOD_OUT_LOW;
> >> > +
> >> > +               info->micd_pol_gpio = gpiod_get_optional(arizona->dev,
> >> > +                                                        "wlf,micd-pol",
> >> > +                                                        GPIOD_OUT_LOW);
> >>
> >> You can use the devm_gpiod_get_optional() to manage the system
> >> resource automatically.
> >>
> >
> > We can't actually use the devm call here, we need to pass
> > arizona->dev as that is where the DT will reside, which is the
> > device for the MFD. But if the devm is attached to the device for
> > the MFD then it will not clear up when the extcon driver is
> > unloaded. As such we have to do the put manually.
> >
> > I will look at respinning for the other comments.
> 
> I don't understand. extcon-arizona.c used already following devm_* functions:
> - devm_kzalloc()
> - devm_regulator_get()
> - devm_extcon_dev_*()
> - devm_input_allocate_device()
> - devm_gpio_request_one()

Yes but if you look at those all of those are against &pdev->dev
which is the extcon device.

The gpiod interface expects the device passed to both contain
the of_node and be used for the devm operations. But we need to
use the extcon device for the devm operations, but the of_node is
contained on the MFD device.

So if I do:

devm_gpiod_get_optional(arizona->dev, ....

Then the gpiod won't be released when the extcon device is
removed. But if I do:

devm_gpiod_get_optional(&pdev->dev, ....

Then it won't be able to find the DT entries.

Thanks,
Charles
--
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]

#1168664

On Fri, Jun 19, 2015 at 6:13 PM, Charles Keepax
<ckeepax@opensource.wolfsonmicro.com> wrote:
> On Fri, Jun 19, 2015 at 05:39:22PM +0900, Chanwoo Choi wrote:
>> On Fri, Jun 19, 2015 at 5:14 PM, Charles Keepax
>> <ckeepax@opensource.wolfsonmicro.com> wrote:
>> > On Fri, Jun 19, 2015 at 11:36:47AM +0900, Chanwoo Choi wrote:
>> >> Hi Charles,
>> >>
>> >> On Thu, Jun 18, 2015 at 11:43 PM, Charles Keepax
>> >> <ckeepax@opensource.wolfsonmicro.com> wrote:
>> >> > Convert to using the newer gpiod interface for the micd_pol_gpio.
>> >> > Although we still carry support for the old gpio interface from pdata.
>> >> >
>> >> > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
>> >> > ---
>> >> > +                       mode = GPIOD_OUT_HIGH;
>> >> > +               else
>> >> > +                       mode = GPIOD_OUT_LOW;
>> >> > +
>> >> > +               info->micd_pol_gpio = gpiod_get_optional(arizona->dev,
>> >> > +                                                        "wlf,micd-pol",
>> >> > +                                                        GPIOD_OUT_LOW);
>> >>
>> >> You can use the devm_gpiod_get_optional() to manage the system
>> >> resource automatically.
>> >>
>> >
>> > We can't actually use the devm call here, we need to pass
>> > arizona->dev as that is where the DT will reside, which is the
>> > device for the MFD. But if the devm is attached to the device for
>> > the MFD then it will not clear up when the extcon driver is
>> > unloaded. As such we have to do the put manually.
>> >
>> > I will look at respinning for the other comments.
>>
>> I don't understand. extcon-arizona.c used already following devm_* functions:
>> - devm_kzalloc()
>> - devm_regulator_get()
>> - devm_extcon_dev_*()
>> - devm_input_allocate_device()
>> - devm_gpio_request_one()
>
> Yes but if you look at those all of those are against &pdev->dev
> which is the extcon device.
>
> The gpiod interface expects the device passed to both contain
> the of_node and be used for the devm operations. But we need to
> use the extcon device for the devm operations, but the of_node is
> contained on the MFD device.
>
> So if I do:
>
> devm_gpiod_get_optional(arizona->dev, ....
>
> Then the gpiod won't be released when the extcon device is
> removed. But if I do:
>
> devm_gpiod_get_optional(&pdev->dev, ....
>
> Then it won't be able to find the DT entries.

I understand the difference between arizona->dev and &pdev->dev.

But, extcon-arizona.c already get the instance of regulator by using
devm_regulator_get() with &pdev->dev as following:
The devm_regulator_get() can find the DT entry in dts file.
                 info->micvdd = devm_regulator_get(&pdev-dev, "MICVDD");

How did extcon-arizona.c get the instance of regulator throught
devm_regulator_get() in dts file?
--
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]

#1168665

On Fri, Jun 19, 2015 at 06:50:03PM +0900, Chanwoo Choi wrote:
> On Fri, Jun 19, 2015 at 6:13 PM, Charles Keepax
> <ckeepax@opensource.wolfsonmicro.com> wrote:
> > On Fri, Jun 19, 2015 at 05:39:22PM +0900, Chanwoo Choi wrote:
> >> On Fri, Jun 19, 2015 at 5:14 PM, Charles Keepax
> >> <ckeepax@opensource.wolfsonmicro.com> wrote:
> >> > On Fri, Jun 19, 2015 at 11:36:47AM +0900, Chanwoo Choi wrote:
> >> >> Hi Charles,
> >> >>
> >> >> On Thu, Jun 18, 2015 at 11:43 PM, Charles Keepax
> >> >> <ckeepax@opensource.wolfsonmicro.com> wrote:
> >> >> > Convert to using the newer gpiod interface for the micd_pol_gpio.
> >> >> > Although we still carry support for the old gpio interface from pdata.
> >> >> >
> >> >> > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> >> >> > ---
> >> >> > +                       mode = GPIOD_OUT_HIGH;
> >> >> > +               else
> >> >> > +                       mode = GPIOD_OUT_LOW;
> >> >> > +
> >> >> > +               info->micd_pol_gpio = gpiod_get_optional(arizona->dev,
> >> >> > +                                                        "wlf,micd-pol",
> >> >> > +                                                        GPIOD_OUT_LOW);
> >> >>
> >> >> You can use the devm_gpiod_get_optional() to manage the system
> >> >> resource automatically.
> >> >>
> >> >
> >> > We can't actually use the devm call here, we need to pass
> >> > arizona->dev as that is where the DT will reside, which is the
> >> > device for the MFD. But if the devm is attached to the device for
> >> > the MFD then it will not clear up when the extcon driver is
> >> > unloaded. As such we have to do the put manually.
> >> >
> >> > I will look at respinning for the other comments.
> >>
> >> I don't understand. extcon-arizona.c used already following devm_* functions:
> >> - devm_kzalloc()
> >> - devm_regulator_get()
> >> - devm_extcon_dev_*()
> >> - devm_input_allocate_device()
> >> - devm_gpio_request_one()
> >
> > Yes but if you look at those all of those are against &pdev->dev
> > which is the extcon device.
> >
> > The gpiod interface expects the device passed to both contain
> > the of_node and be used for the devm operations. But we need to
> > use the extcon device for the devm operations, but the of_node is
> > contained on the MFD device.
> >
> > So if I do:
> >
> > devm_gpiod_get_optional(arizona->dev, ....
> >
> > Then the gpiod won't be released when the extcon device is
> > removed. But if I do:
> >
> > devm_gpiod_get_optional(&pdev->dev, ....
> >
> > Then it won't be able to find the DT entries.
> 
> I understand the difference between arizona->dev and &pdev->dev.
> 
> But, extcon-arizona.c already get the instance of regulator by using
> devm_regulator_get() with &pdev->dev as following:
> The devm_regulator_get() can find the DT entry in dts file.
>                  info->micvdd = devm_regulator_get(&pdev-dev, "MICVDD");
> 
> How did extcon-arizona.c get the instance of regulator throught
> devm_regulator_get() in dts file?

The regulator API contains a feature called regulator aliases,
(see regulator_register_supply_alias) which the MFD driver for
Arizona registers a bunch of. So when the regulator lookup is
done the regulator core will actually do the lookup on the
parent MFD device rather than on the extcon device.

Thanks,
Charles
--
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