All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Courbot <gnurou@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linaro-kernel@lists.linaro.org
Subject: Re: [PATCH] regulator: core: Still free GPIOs using gpio_free()
Date: Tue, 1 Jul 2014 21:24:22 +0900	[thread overview]
Message-ID: <CAAVeFuJqRW0ih8Mg9MFwLf=wQ7eVK5+pm8deW0vTUdozJ16FfQ@mail.gmail.com> (raw)
In-Reply-To: <20140701121142.GM23300@sirena.org.uk>

On Tue, Jul 1, 2014 at 9:11 PM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Jul 01, 2014 at 01:06:22PM +0100, Russell King - ARM Linux wrote:
>> On Tue, Jul 01, 2014 at 12:55:26PM +0100, Mark Brown wrote:
>
>> > Even though we mostly use GPIO descriptors internally we still use
>> > gpio_request_one() to request so we need to pair that with gpio_free() to
>> > release the GPIO.
>
>> This doesn't explain the reason...  I see the current GPIO code doing this:
>
>> void gpio_free(unsigned gpio)
>> {
>>         gpiod_free(gpio_to_desc(gpio));
>> }
>> EXPORT_SYMBOL_GPL(gpio_free);
>
> Huh, good point (though it still seems a bit neater to match up the
> request and release functions I guess).  Linus?

Yeah it's a nice habit to free the GPIOs using the same interface as
the one used to obtain them. Although if we are to allow the regulator
framework to request GPIO through both the integer and descriptor
interfaces, we certainly don't want to track that information forever.

On top of that we want to limit the use of gpio_to_desc() and
desc_to_gpio() in drivers as much as possible, so I'd say I prefer to
see gpiod_free() used no matter where the GPIO came from.

WARNING: multiple messages have this Message-ID (diff)
From: gnurou@gmail.com (Alexandre Courbot)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] regulator: core: Still free GPIOs using gpio_free()
Date: Tue, 1 Jul 2014 21:24:22 +0900	[thread overview]
Message-ID: <CAAVeFuJqRW0ih8Mg9MFwLf=wQ7eVK5+pm8deW0vTUdozJ16FfQ@mail.gmail.com> (raw)
In-Reply-To: <20140701121142.GM23300@sirena.org.uk>

On Tue, Jul 1, 2014 at 9:11 PM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Jul 01, 2014 at 01:06:22PM +0100, Russell King - ARM Linux wrote:
>> On Tue, Jul 01, 2014 at 12:55:26PM +0100, Mark Brown wrote:
>
>> > Even though we mostly use GPIO descriptors internally we still use
>> > gpio_request_one() to request so we need to pair that with gpio_free() to
>> > release the GPIO.
>
>> This doesn't explain the reason...  I see the current GPIO code doing this:
>
>> void gpio_free(unsigned gpio)
>> {
>>         gpiod_free(gpio_to_desc(gpio));
>> }
>> EXPORT_SYMBOL_GPL(gpio_free);
>
> Huh, good point (though it still seems a bit neater to match up the
> request and release functions I guess).  Linus?

Yeah it's a nice habit to free the GPIOs using the same interface as
the one used to obtain them. Although if we are to allow the regulator
framework to request GPIO through both the integer and descriptor
interfaces, we certainly don't want to track that information forever.

On top of that we want to limit the use of gpio_to_desc() and
desc_to_gpio() in drivers as much as possible, so I'd say I prefer to
see gpiod_free() used no matter where the GPIO came from.

  reply	other threads:[~2014-07-01 12:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01 11:55 [PATCH] regulator: core: Still free GPIOs using gpio_free() Mark Brown
2014-07-01 11:55 ` Mark Brown
2014-07-01 12:06 ` Russell King - ARM Linux
2014-07-01 12:06   ` Russell King - ARM Linux
2014-07-01 12:11   ` Mark Brown
2014-07-01 12:11     ` Mark Brown
2014-07-01 12:24     ` Alexandre Courbot [this message]
2014-07-01 12:24       ` Alexandre Courbot
2014-07-01 12:27       ` Mark Brown
2014-07-01 12:27         ` Mark Brown
2014-07-08  8:33         ` Linus Walleij
2014-07-08  8:33           ` Linus Walleij
2014-07-08 11:53           ` Mark Brown
2014-07-08 11:53             ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAVeFuJqRW0ih8Mg9MFwLf=wQ7eVK5+pm8deW0vTUdozJ16FfQ@mail.gmail.com' \
    --to=gnurou@gmail.com \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.