From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Linus Walleij <linus.walleij@linaro.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: [PATCH v4 00/11] gpiolib: work towards removing gpiochip_find()
Date: Wed, 27 Sep 2023 16:29:20 +0200 [thread overview]
Message-ID: <20230927142931.19798-1-brgl@bgdev.pl> (raw)
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This is a reduced subset of patches from the initial sumbission[1]
limited only to changes inside GPIOLIB. Once this is upstream, we can
then slowly merge patches for other subsystems (like HTE) and then
eventually remove gpiochip_find() entirely.
The GPIO subsystem does not handle hot-unplug events very well. We have
recently patched the user-space part of it so that at least a rouge user
cannot crash the kernel but in-kernel users are still affected by a lot of
issues: from incorrect locking or lack thereof to using structures that are
private to GPIO drivers. Since almost all GPIO controllers can be unbound,
not to mention that we have USB devices registering GPIO expanders as well as
I2C-on-USB HID devices on which I2C GPIO expanders can live, various media
gadgets etc., we really need to make GPIO hotplug/unplug friendly.
Before we can even get to fixing the locking, we need to address a serious
abuse of the GPIO driver API - accessing struct gpio_chip by anyone who isn't
the driver owning this object. This structure is owned by the GPIO provider
and its lifetime is tied to that of that provider. It is destroyed when the
device is unregistered and this may happen at any moment. struct gpio_device
is the opaque, reference counted interface to struct gpio_chip (which is the
low-level implementation) and all access should pass through it.
The end-goal is to make all gpio_device manipulators check the existence of
gdev->chip and then lock it for the duration of any of the calls using SRCU.
Before we can get there, we need to first provide a set of functions that will
replace any gpio_chip functions and convert all in-kernel users.
This series adds several new helpers to the public GPIO API and uses
them across the core GPIO code.
Note that this does not make everything correct just yet. Especially the
GPIOLIB internal users release the reference returned by the lookup function
after getting the descriptor of interest but before requesting it. This will
eventually be addressed. This is not a regression either.
[1] https://lore.kernel.org/lkml/20230905185309.131295-1-brgl@bgdev.pl/T/
v3 -> v4:
- initialize managed pointers when declaring them
- drop unneeded casting
- collect more tags
v2 -> v3:
- use gpio_device_get_chip() consistently
- clarify comments
- fix buggy chip assignment
- check for PTR_ERR() in automatic cleanup
- rearrange code as requested by Andy
v1 -> v2:
- drop all non-GPIOLIB patches
- collect tags
- fix kernel docs
Bartosz Golaszewski (11):
gpiolib: make gpio_device_get() and gpio_device_put() public
gpiolib: add support for scope-based management to gpio_device
gpiolib: provide gpio_device_find()
gpiolib: provide gpio_device_find_by_label()
gpiolib: provide gpio_device_get_desc()
gpiolib: reluctantly provide gpio_device_get_chip()
gpiolib: replace find_chip_by_name() with gpio_device_find_by_label()
gpio: of: replace gpiochip_find_* with gpio_device_find_*
gpio: acpi: replace gpiochip_find() with gpio_device_find()
gpio: swnode: replace gpiochip_find() with gpio_device_find_by_label()
gpio: sysfs: drop the mention of gpiochip_find() from sysfs code
drivers/gpio/gpiolib-acpi.c | 12 +-
drivers/gpio/gpiolib-of.c | 33 +++---
drivers/gpio/gpiolib-swnode.c | 33 +++---
drivers/gpio/gpiolib-sysfs.c | 2 +-
drivers/gpio/gpiolib.c | 202 ++++++++++++++++++++++++++--------
drivers/gpio/gpiolib.h | 10 --
include/linux/gpio/driver.h | 16 +++
7 files changed, 215 insertions(+), 93 deletions(-)
--
2.39.2
next reply other threads:[~2023-09-27 14:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 14:29 Bartosz Golaszewski [this message]
2023-09-27 14:29 ` [PATCH v4 01/11] gpiolib: make gpio_device_get() and gpio_device_put() public Bartosz Golaszewski
2023-10-02 9:39 ` Andy Shevchenko
2023-09-27 14:29 ` [PATCH v4 02/11] gpiolib: add support for scope-based management to gpio_device Bartosz Golaszewski
2023-10-02 9:39 ` Andy Shevchenko
2023-09-27 14:29 ` [PATCH v4 03/11] gpiolib: provide gpio_device_find() Bartosz Golaszewski
2023-10-02 9:42 ` Andy Shevchenko
2023-10-02 9:52 ` Bartosz Golaszewski
2023-10-02 9:57 ` Andy Shevchenko
2023-10-02 9:59 ` Bartosz Golaszewski
2023-09-27 14:29 ` [PATCH v4 04/11] gpiolib: provide gpio_device_find_by_label() Bartosz Golaszewski
2023-10-02 9:44 ` Andy Shevchenko
2023-10-02 9:53 ` Bartosz Golaszewski
2023-10-03 12:44 ` Bartosz Golaszewski
2023-09-27 14:29 ` [PATCH v4 05/11] gpiolib: provide gpio_device_get_desc() Bartosz Golaszewski
2023-10-02 9:46 ` Andy Shevchenko
2023-10-02 9:54 ` Bartosz Golaszewski
2023-10-02 9:58 ` Andy Shevchenko
2023-09-27 14:29 ` [PATCH v4 06/11] gpiolib: reluctantly provide gpio_device_get_chip() Bartosz Golaszewski
2023-09-27 14:29 ` [PATCH v4 07/11] gpiolib: replace find_chip_by_name() with gpio_device_find_by_label() Bartosz Golaszewski
2023-09-27 14:29 ` [PATCH v4 08/11] gpio: of: replace gpiochip_find_* with gpio_device_find_* Bartosz Golaszewski
2023-09-27 14:29 ` [PATCH v4 09/11] gpio: acpi: replace gpiochip_find() with gpio_device_find() Bartosz Golaszewski
2023-09-27 14:29 ` [PATCH v4 10/11] gpio: swnode: replace gpiochip_find() with gpio_device_find_by_label() Bartosz Golaszewski
2023-09-27 14:29 ` [PATCH v4 11/11] gpio: sysfs: drop the mention of gpiochip_find() from sysfs code Bartosz Golaszewski
2023-10-04 11:58 ` [PATCH v4 00/11] gpiolib: work towards removing gpiochip_find() 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=20230927142931.19798-1-brgl@bgdev.pl \
--to=brgl@bgdev.pl \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bartosz.golaszewski@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
/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).