linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Khouloud Touil <ktouil@baylibre.com>
Subject: Re: [PATCH 2/3] gpiolib: use kref in gpio_desc
Date: Thu, 5 Mar 2020 17:49:28 +0100	[thread overview]
Message-ID: <CAMRc=MdbvwQ3Exa2gmY-J0p8UeB-_dKrgqHEBo=S08yU4Uth=A@mail.gmail.com> (raw)
In-Reply-To: <20200224094158.28761-3-brgl@bgdev.pl>

pon., 24 lut 2020 o 10:42 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> GPIO descriptors are freed by consumers using gpiod_put(). The name of
> this function suggests some reference counting is going on but it's not
> true.
>
> Use kref to actually introduce reference counting for gpio_desc objects.
> Add a corresponding gpiod_get() helper for increasing the reference count.
>
> This doesn't change anything for already existing (correct) drivers but
> allows us to keep track of GPIO descs used by multiple users.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Linus,

This is in response to your suggestion under the previous version of this patch.

I refreshed my memory on device links and reference counting. I think
that device links are not the right tool for the problem I'm trying to
solve. You're right on the other hand about the need for reference
counting of gpiochip devices. Right now if we remove the chip with
GPIOs still requested the only thing that happens is a big splat:
"REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED".

We should probably have a kref on the gpiochip structure which would
be set to 1 when registering the chip, increased and decreased on
every operation such as requesting and releasing a GPIO respectively
and decreased by gpiochip_remove() too. That way if we call
gpiochip_remove() while some users are still holding GPIO descriptors
then the only thing that happens is: the reference count for this
gpiochip is decreased. Once the final consumer calls the appropriate
release routine and the reference count goes to 0, we'd call the
actual gpiochip release code. This is similar to what the clock
framework does IIRC.

This patch however addresses a different issue: I'd like to add
reference counting to descriptors associated with GPIOs requested by
consumers. The kref release function would not trigger a destruction
of the gpiochip - just releasing of the requested GPIO. In this
particular use-case: we can pass an already requested GPIO descriptor
to nvmem. I'd like the nvmem framework to be able to reference it and
then drop the reference once it's done with the line, so that the life
of this resource is not controlled only by the entity that initially
requested it.

In other words: we could use two kref objects: one for the gpiochip
and one for GPIO descriptors.

I hope that makes it more clear.

Best regards,
Bartosz

  reply	other threads:[~2020-03-05 16:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-24  9:41 [PATCH 0/3] gpiolib: add reference counting to GPIO descriptors Bartosz Golaszewski
2020-02-24  9:41 ` [PATCH 1/3] gpiolib: provide VALIDATE_DESC_PTR() macro Bartosz Golaszewski
2020-02-24  9:41 ` [PATCH 2/3] gpiolib: use kref in gpio_desc Bartosz Golaszewski
2020-03-05 16:49   ` Bartosz Golaszewski [this message]
2020-03-12 10:10     ` Linus Walleij
2020-03-12 18:24       ` Bartosz Golaszewski
2020-03-13  8:43         ` Linus Walleij
2020-03-13 15:04           ` Bartosz Golaszewski
2020-03-23  8:44             ` Bartosz Golaszewski
2020-03-25 11:16               ` Linus Walleij
2020-03-25 11:35                 ` Bartosz Golaszewski
2020-03-12 10:35   ` Linus Walleij
2020-03-13 14:47     ` Bartosz Golaszewski
2020-03-26 20:50       ` Linus Walleij
2020-03-30 14:36         ` Bartosz Golaszewski
2020-05-14 13:42           ` Bartosz Golaszewski
2020-05-16  9:50             ` Linus Walleij
2020-02-24  9:41 ` [PATCH 3/3] nvmem: increase the reference count of a gpio passed over config Bartosz Golaszewski

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='CAMRc=MdbvwQ3Exa2gmY-J0p8UeB-_dKrgqHEBo=S08yU4Uth=A@mail.gmail.com' \
    --to=brgl@bgdev.pl \
    --cc=bgolaszewski@baylibre.com \
    --cc=geert@linux-m68k.org \
    --cc=ktouil@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).