From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: "Ahmad Fatoum" <a.fatoum@pengutronix.de>,
"Kent Gibson" <warthog618@gmail.com>,
"Jan Lübbe" <jlu@pengutronix.de>, "Marek Vasut" <marex@denx.de>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Linus Walleij" <linus.walleij@linaro.org>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
"Bartosz Golaszewski" <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH v2 1/9] gpio: sysfs: add a parallel class device for each GPIO chip using device IDs
Date: Fri, 27 Jun 2025 18:21:17 +0300 [thread overview]
Message-ID: <aF627RVZ8GFZ_S_x@black.fi.intel.com> (raw)
In-Reply-To: <20250623-gpio-sysfs-chip-export-v2-1-d592793f8964@linaro.org>
On Mon, Jun 23, 2025 at 10:59:49AM +0200, Bartosz Golaszewski wrote:
>
> In order to enable moving away from the global GPIO numberspace-based
> exporting of lines over sysfs: add a parallel, per-chip entry under
> /sys/class/gpio/ for every registered GPIO chip, denoted by device ID
> in the file name and not its base GPIO number.
>
> Compared to the existing chip group: it does not contain the "base"
> attribute as the goal of this change is to not refer to GPIOs by their
> global number from user-space anymore. It also contains its own,
> per-chip export/unexport attribute pair which allow to export lines by
> their hardware offset within the chip.
>
> Caveat #1: the new device cannot be a link to (or be linked to by) the
> existing "gpiochip<BASE>" entry as we cannot create links in
> /sys/class/xyz/.
>
> Caveat #2: the new entry cannot be named "gpiochipX" as it could
> conflict with devices whose base is statically defined to a low number.
> Let's go with "chipX" instead.
>
> While at it: the chip label is unique so update the untrue statement
> when extending the docs.
...
> struct gpiodev_data {
> struct gpio_device *gdev;
> struct device *cdev_base; /* Class device by GPIO base */
> + struct device *cdev_id; /* Class device by GPIO device ID */
I would add it in the middle in a way of the possible drop or conditional
compiling of the legacy access in the future.
> };
...
> +static int export_gpio_desc(struct gpio_desc *desc)
> +{
> + int offset, ret;
Why offset is signed?
> + CLASS(gpio_chip_guard, guard)(desc);
> + if (!guard.gc)
> + return -ENODEV;
> +
> + offset = gpio_chip_hwgpio(desc);
> + if (!gpiochip_line_is_valid(guard.gc, offset)) {
> + pr_debug_ratelimited("%s: GPIO %d masked\n", __func__,
> + gpio_chip_hwgpio(desc));
Can we use gdev here? (IIRC we can't due to some legacy corner cases)
> + return -EINVAL;
> + }
> +
> + /*
> + * No extra locking here; FLAG_SYSFS just signifies that the
> + * request and export were done by on behalf of userspace, so
> + * they may be undone on its behalf too.
> + */
> +
> + ret = gpiod_request_user(desc, "sysfs");
> + if (ret)
> + return ret;
> +
> + ret = gpiod_set_transitory(desc, false);
> + if (ret) {
> + gpiod_free(desc);
> + return ret;
> + }
> +
> + ret = gpiod_export(desc, true);
> + if (ret < 0) {
> + gpiod_free(desc);
> + } else {
> + set_bit(FLAG_SYSFS, &desc->flags);
> + gpiod_line_state_notify(desc, GPIO_V2_LINE_CHANGED_REQUESTED);
> + }
> +
> + return ret;
> +}
...
> +static struct device_attribute dev_attr_export = __ATTR(export, 0200, NULL,
> + chip_export_store);
__ATTR_WO()
...
> +static struct device_attribute dev_attr_unexport = __ATTR(unexport, 0200,
> + NULL,
> + chip_unexport_store);
Ditto.
...
> +static struct attribute *gpiochip_ext_attrs[] = {
> + &dev_attr_label.attr,
> + &dev_attr_ngpio.attr,
> + &dev_attr_export.attr,
> + &dev_attr_unexport.attr,
> + NULL,
No comma for the terminator, please.
> +};
...
> + data->cdev_id = device_create_with_groups(&gpio_class, parent,
> + MKDEV(0, 0), data,
> + gpiochip_ext_groups,
> + "chip%d", gdev->id);
> + if (IS_ERR(data->cdev_id)) {
> + device_unregister(data->cdev_base);
> + kfree(data);
UAF
> + return PTR_ERR(data->cdev_id);
> + }
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-06-27 15:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-23 8:59 [PATCH v2 0/9] gpio: sysfs: add a per-chip export/unexport attribute pair Bartosz Golaszewski
2025-06-23 8:59 ` [PATCH v2 1/9] gpio: sysfs: add a parallel class device for each GPIO chip using device IDs Bartosz Golaszewski
2025-06-27 15:21 ` Andy Shevchenko [this message]
2025-06-30 8:34 ` Bartosz Golaszewski
2025-06-30 9:16 ` Andy Shevchenko
2025-06-23 8:59 ` [PATCH v2 2/9] gpio: sysfs: only get the dirent reference for the value attr once Bartosz Golaszewski
2025-06-27 15:35 ` Andy Shevchenko
2025-06-30 8:41 ` Bartosz Golaszewski
2025-06-23 8:59 ` [PATCH v2 3/9] gpio: sysfs: pass gpiod_data directly to internal GPIO sysfs functions Bartosz Golaszewski
2025-06-24 19:32 ` Linus Walleij
2025-06-27 15:37 ` Andy Shevchenko
2025-06-23 8:59 ` [PATCH v2 4/9] gpio: sysfs: don't use driver data in sysfs callbacks for line attributes Bartosz Golaszewski
2025-06-24 19:33 ` Linus Walleij
2025-06-27 15:41 ` Andy Shevchenko
2025-06-30 8:57 ` Bartosz Golaszewski
2025-06-30 10:05 ` Andy Shevchenko
2025-06-23 8:59 ` [PATCH v2 5/9] gpio: sysfs: rename the data variable in gpiod_(un)export() Bartosz Golaszewski
2025-06-24 19:34 ` Linus Walleij
2025-06-27 15:43 ` Andy Shevchenko
2025-06-30 8:57 ` Bartosz Golaszewski
2025-06-30 9:03 ` Bartosz Golaszewski
2025-06-23 8:59 ` [PATCH v2 6/9] gpio: sysfs: don't look up exported lines as class devices Bartosz Golaszewski
2025-06-24 19:34 ` Linus Walleij
2025-06-27 15:47 ` Andy Shevchenko
2025-06-23 8:59 ` [PATCH v2 7/9] gpio: sysfs: export the GPIO directory locally in the gpiochip<id> directory Bartosz Golaszewski
2025-06-23 22:07 ` kernel test robot
2025-06-23 8:59 ` [PATCH v2 8/9] gpio: sysfs: allow disabling the legacy parts of the GPIO sysfs interface Bartosz Golaszewski
2025-06-24 11:31 ` Geert Uytterhoeven
2025-06-24 19:40 ` Linus Walleij
2025-06-27 11:40 ` kernel test robot
2025-06-23 8:59 ` [PATCH v2 9/9] gpio: TODO: remove the task for the sysfs rework 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=aF627RVZ8GFZ_S_x@black.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=a.fatoum@pengutronix.de \
--cc=bartosz.golaszewski@linaro.org \
--cc=brgl@bgdev.pl \
--cc=geert+renesas@glider.be \
--cc=jlu@pengutronix.de \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marex@denx.de \
--cc=warthog618@gmail.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 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.