linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Jonathan Corbet <corbet@lwn.net>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH v8 2/2] misc: gpio-virtuser: new virtual testing driver for the GPIO API
Date: Thu, 13 Jun 2024 12:02:11 +0200	[thread overview]
Message-ID: <2024061356-uptake-ideology-e57b@gregkh> (raw)
In-Reply-To: <20240613092830.15761-3-brgl@bgdev.pl>

On Thu, Jun 13, 2024 at 11:28:30AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> The GPIO subsystem used to have a serious problem with undefined behavior
> and use-after-free bugs on hot-unplug of GPIO chips. This can be
> considered a corner-case by some as most GPIO controllers are enabled
> early in the boot process and live until the system goes down but most
> GPIO drivers do allow unbind over sysfs, many are loadable modules that
> can be (force) unloaded and there are also GPIO devices that can be
> dynamically detached, for instance CP2112 which is a USB GPIO expender.
> 
> Bugs can be triggered both from user-space as well as by in-kernel users.
> We have the means of testing it from user-space via the character device
> but the issues manifest themselves differently in the kernel.
> 
> This is a proposition of adding a new virtual driver - a configurable
> GPIO consumer that can be configured over configfs (similarly to
> gpio-sim) or described on the device-tree.
> 
> This driver is aimed as a helper in spotting any regressions in
> hot-unplug handling in GPIOLIB.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  .../admin-guide/gpio/gpio-virtuser.rst        |  176 ++
>  Documentation/admin-guide/gpio/index.rst      |    1 +

sysfs documentation needs to go in Documentation/ABI/ not in a random
.rst file where the tools that check this will not catch it.

>  MAINTAINERS                                   |    8 +
>  drivers/misc/Kconfig                          |    8 +
>  drivers/misc/Makefile                         |    1 +
>  drivers/misc/gpio-virtuser.c                  | 1790 +++++++++++++++++

Why not put this in drivers/gpio/?  Why misc?

> +Both attributes allow to read and set arrays of GPIO values. User must pass
> +exactly the number of values that the array contains in the form of a string
> +containing zeroes and ones representing inactive and active GPIO states
> +respectively. In this example: ``echo 11 > values``.

sysfs is "one value per file", so why are there multiple values here?

If you want to just use this for testing, and want to put whatever you
want in the files, just use debugfs, that's what it is there for, not
sysfs.

> +config GPIO_VIRTUSER
> +	tristate "GPIO Virtual User Testing Module"
> +	select CONFIGFS_FS
> +	select IRQ_WORK
> +	help
> +	  This enables the configurable, configfs-based virtual GPIO consumer
> +	  testing driver.
> +

module name?

And you need more documentation here, I have no idea what this means
when it shows up in a Kconfig help entry :(

thanks,

greg k-h

  reply	other threads:[~2024-06-13 10:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13  9:28 [PATCH v8 0/2] misc: add a virtual driver for testing the GPIO API Bartosz Golaszewski
2024-06-13  9:28 ` [PATCH v8 1/2] drivers: export to_ext_attr() Bartosz Golaszewski
2024-06-13 10:02   ` Greg Kroah-Hartman
2024-06-13 11:18     ` Bartosz Golaszewski
2024-06-13  9:28 ` [PATCH v8 2/2] misc: gpio-virtuser: new virtual testing driver for the GPIO API Bartosz Golaszewski
2024-06-13 10:02   ` Greg Kroah-Hartman [this message]
2024-06-13 11:22     ` Bartosz Golaszewski
2024-06-13 11:33       ` Greg Kroah-Hartman

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=2024061356-uptake-ideology-e57b@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=corbet@lwn.net \
    --cc=linus.walleij@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.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).