All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] GPIO User I/O
@ 2020-07-06 12:19 Rodolfo Giometti
  2020-07-06 13:35 ` Drew Fustini
  2020-07-06 13:43 ` Linus Walleij
  0 siblings, 2 replies; 28+ messages in thread
From: Rodolfo Giometti @ 2020-07-06 12:19 UTC (permalink / raw)
  To: linux-gpio; +Cc: Linus Walleij, Bartosz Golaszewski

[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]

Hello,

at the moment if a developer wishes to use a GPIO as output or input with a well
defined name from userspace via the sysfs interface he/she can use,
respectively, the gpio-leds or gpio-uinput devices. However, IMHO, this is not
the best nor a proper way to do it, that's why I'm here to propose this really
simple interface named GPIO_UIO.

That's why I wrote the attached patch (for kernel 4.19) which it's just a
proposal, and the purpose of this message is to collect feedback about this
solution. Of course I'll be happy to port it for latest kernel release and
complete it with all requested documentation and needed modifications, but I'll
do it only if this patch has some changes to be accepted by GPIO subsystem's
maintainers. :)

For the moment here is how it works:

1) The patch is activated by the configuration entry CONFIG_GPIO_UIO.

2) In the device-tree the developer defines all board's GPIO lines with their
names and mode of functioning:

+       gpio_uio {
+               compatible = "gpio-uio";
+
+               bypass0 {
+                       gpios = <&gpionb 10 GPIO_ACTIVE_HIGH>;
+                       mode = "out-low";
+               };
+
+               bypass1 {
+                       gpios = <&gpiosb 11 GPIO_ACTIVE_HIGH>;
+                       mode = "out-low";
+                       label = "bypass-1";
+               };
+        };

Property "mode" can be "asis", "input", "out-low", etc. and the property label
can be used in case the GPIO line's name should be different from the node's name.

3) At boot the GPIO lines are added:

[    2.398902] gpio-uio bypass0: line added
[    2.423558] gpio-uio bypass-1: line added

4) Then users will find a new class with entries, one for each new line:

# ls /sys/class/gpio-uio/
bypass-1  bypass0

5) By using the attribute "line" the users can get or set the line status

# cat /sys/class/gpio-uio/bypass-1/line
0
# echo 1 > /sys/class/gpio-uio/bypass-1/line
# cat /sys/class/gpio-uio/bypass-1/line
1

6) Developers can monitor the GPIO lines via debugfs as for kernel modules:

# cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 446-475, parent: platform/d0018800.pinctrl, GPIO2:
 gpio-457 (                    |bypass-1            ) out lo

gpiochip0: GPIOs 476-511, parent: platform/d0013800.pinctrl, GPIO1:
 gpio-479 (                    |cd                  ) in  hi IRQ
 gpio-480 (                    |vcc_sd1             ) out lo
 gpio-486 (                    |bypass0             ) out lo


The End. :)

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

[-- Attachment #2: rfc_gpio-uio.patch --]
[-- Type: text/x-patch, Size: 8607 bytes --]

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4f52c3a8ec99..a072b45d7f20 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -73,6 +73,16 @@ config GPIO_SYSFS
 	  Kernel drivers may also request that a particular GPIO be
 	  exported to userspace; this can be useful when debugging.
 
+config GPIO_UIO
+	bool "/sys/class/gpio-uio/... (sysfs user I/O interface)"
+	depends on SYSFS
+	help
+	  Say Y here to add a sysfs interface for I/O activities from userspace.
+
+	  Instead of the GPIO_SYSFS support, by using this support, you'll be
+	  able to use GPIOs from userspace as stated in the device-tree
+	  for well defined pourposes and by using proper names.
+
 config GPIO_GENERIC
 	depends on HAS_IOMEM # Only for IOMEM drivers
 	tristate
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index c256aff66a65..2be35a9df6e0 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_GPIOLIB)		+= gpiolib-legacy.o
 obj-$(CONFIG_GPIOLIB)		+= gpiolib-devprop.o
 obj-$(CONFIG_OF_GPIO)		+= gpiolib-of.o
 obj-$(CONFIG_GPIO_SYSFS)	+= gpiolib-sysfs.o
+obj-$(CONFIG_GPIO_UIO)		+= gpiolib-uio.o
 obj-$(CONFIG_GPIO_ACPI)		+= gpiolib-acpi.o
 
 # Device drivers. Generally keep list sorted alphabetically
diff --git a/drivers/gpio/gpiolib-uio.c b/drivers/gpio/gpiolib-uio.c
new file mode 100644
index 000000000000..8d6f584c710e
--- /dev/null
+++ b/drivers/gpio/gpiolib-uio.c
@@ -0,0 +1,256 @@
+/*
+ * GPIOlib - userspace I/O interface
+ *
+ *
+ * Copyright (C) 2020   Rodolfo Giometti <giometti@linux.it>
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 2 of the License, or
+ *   (at your option) any later version.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details.
+ *
+ *   You should have received a copy of the GNU General Public License
+ *   along with this program; if not, write to the Free Software
+ *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/idr.h>
+#include <linux/kdev_t.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+
+#define GPIOUIO_MAX_SOURCES       128      /* should be enough... */
+
+/*
+ * Local variables
+ */
+
+static dev_t gpiouio_devt;
+static struct class *gpiouio_class;
+
+static DEFINE_MUTEX(gpiouio_idr_lock);
+static DEFINE_IDR(gpiouio_idr);
+
+struct gpiouio_device {
+	struct gpio_desc *gpiod;
+        const char *name;
+        unsigned int id;
+        struct device *dev;
+};
+
+/*
+ * sysfs methods
+ */
+
+static ssize_t line_store(struct device *dev,
+                                struct device_attribute *attr,
+                                const char *buf, size_t count)
+{
+        struct gpiouio_device *gpiouio = dev_get_drvdata(dev);
+        int status, ret;
+
+        ret = sscanf(buf, "%d", &status);
+        if (ret != 1 && status != 0 && status != 1)
+                return -EINVAL;
+
+	gpiod_set_value_cansleep(gpiouio->gpiod, status);
+
+        return count;
+}
+
+static ssize_t line_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct gpiouio_device *gpiouio = dev_get_drvdata(dev);
+	int status = gpiod_get_value_cansleep(gpiouio->gpiod);
+
+	return sprintf(buf, "%d\n", status);
+}
+static DEVICE_ATTR_RW(line);
+
+/*
+ * Class attributes
+ */
+
+static struct attribute *gpiouio_attrs[] = {
+        &dev_attr_line.attr,
+        NULL,
+};
+
+static const struct attribute_group gpiouio_group = {
+        .attrs = gpiouio_attrs,
+};
+
+static const struct attribute_group *gpiouio_groups[] = {
+        &gpiouio_group,
+        NULL,
+};
+
+/*
+ * Driver stuff
+ */
+
+static int gpiouio_create_entry(const char *name,
+				struct gpio_desc *gpiod,
+				struct device *parent)
+{
+	struct gpiouio_device *gpiouio;
+	dev_t devt;
+	int ret;
+
+	/* First allocate a new gpiouio device */
+	gpiouio = kmalloc(sizeof(struct gpiouio_device), GFP_KERNEL);
+	if (!gpiouio)
+		return -ENOMEM;
+
+        mutex_lock(&gpiouio_idr_lock);
+        /*
+         * Get new ID for the new gpiouio source.  After idr_alloc() calling
+         * the new source will be freely available into the kernel.
+         */
+        ret = idr_alloc(&gpiouio_idr, gpiouio, 0,
+			GPIOUIO_MAX_SOURCES, GFP_KERNEL);
+        if (ret < 0) {
+                if (ret == -ENOSPC) {
+                        pr_err("%s: too many PPS sources in the system\n",
+                               name);
+                        ret = -EBUSY;
+                }
+                goto error_device_create;
+        }
+        gpiouio->id = ret;
+        mutex_unlock(&gpiouio_idr_lock);
+
+	/* Create the device and init the device's data */
+        devt = MKDEV(MAJOR(gpiouio_devt), gpiouio->id);
+	gpiouio->dev = device_create(gpiouio_class, parent, devt, gpiouio,
+				   "%s", name);
+	if (IS_ERR(gpiouio->dev)) {
+		dev_err(gpiouio->dev, "unable to create device %s\n", name);
+		ret = PTR_ERR(gpiouio->dev);
+		goto error_idr_remove;
+	}
+	dev_set_drvdata(gpiouio->dev, gpiouio);
+
+	/* Init the gpiouio data */
+	gpiouio->gpiod = gpiod;
+	gpiouio->name = name;
+
+	dev_info(gpiouio->dev, "line added\n");
+
+	return 0;
+
+error_idr_remove:
+	mutex_lock(&gpiouio_idr_lock);
+        idr_remove(&gpiouio_idr, gpiouio->id);
+
+error_device_create:
+	mutex_unlock(&gpiouio_idr_lock);
+	kfree(gpiouio);
+
+	return ret;
+}
+
+static int gpiouio_gpio_probe(struct platform_device *pdev)
+{
+        struct device *dev = &pdev->dev;
+        struct fwnode_handle *child;
+        int ret;
+
+        device_for_each_child_node(dev, child) {
+		struct device_node *np = to_of_node(child);
+                const char *label;
+		enum gpiod_flags flags = GPIOD_ASIS;
+                const char *mode = "as-is";
+		struct gpio_desc *gpiod;
+
+                ret = fwnode_property_read_string(child, "label", &label);
+                if (ret && IS_ENABLED(CONFIG_OF) && np)
+                        label = np->name;
+                if (!label) {
+                        dev_err(dev,
+				"label property not defined or invalid!\n");
+                        goto skip;
+                }
+
+		ret = fwnode_property_read_string(child, "mode", &mode);
+		if ((ret == 0) && mode) {
+			if (strcmp("as-is", mode) == 0)
+				flags = GPIOD_ASIS;
+			else if (strcmp("input", mode) == 0)
+				flags = GPIOD_IN;
+			else if (strcmp("out-low", mode) == 0)
+				flags = GPIOD_OUT_LOW;
+			else if (strcmp("out-high", mode) == 0)
+				flags = GPIOD_OUT_HIGH;
+			else if (strcmp("out-low-open-drain", mode) == 0)
+				flags = GPIOD_OUT_LOW_OPEN_DRAIN;
+			else if (strcmp("out-high-open-drain", mode) == 0)
+				flags = GPIOD_OUT_HIGH_OPEN_DRAIN;
+		}
+
+                gpiod = devm_fwnode_get_gpiod_from_child(dev, NULL, child,
+                                                         flags, label);
+                if (IS_ERR(gpiod)) {
+                        dev_err(dev, "gpios property not defined!\n");
+                        goto skip;
+                }
+
+                ret = gpiouio_create_entry(label, gpiod, dev);
+                if (ret)
+                        goto skip;
+
+		/* Success, now go to the next child */
+		continue;
+
+skip:		/* Error, skip the child */
+		fwnode_handle_put(child);
+		dev_err(dev, "failed to register GPIO UIO interface\n");
+        }
+
+        return 0;
+}
+
+static const struct of_device_id of_gpio_gpiouio_match[] = {
+        { .compatible = "gpio-uio", },
+        { /* sentinel */ }
+};
+
+static struct platform_driver gpiouio_gpio_driver = {
+        .driver         = {
+                .name   = "gpio-uio",
+                .of_match_table = of_gpio_gpiouio_match,
+        },
+};
+
+builtin_platform_driver_probe(gpiouio_gpio_driver, gpiouio_gpio_probe);
+
+/*
+ * Module stuff
+ */
+
+static int __init gpiolib_uio_init(void)
+{
+	/* Create the new class */
+	gpiouio_class = class_create(THIS_MODULE, "gpio-uio");
+	if (!gpiouio_class) {
+		printk(KERN_ERR "gpiouio: failed to allocate class\n");
+		return -ENOMEM;
+	}
+	gpiouio_class->dev_groups = gpiouio_groups;
+
+	return 0;
+}
+
+postcore_initcall(gpiolib_uio_init);

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO User I/O
  2020-07-06 12:19 [RFC] GPIO User I/O Rodolfo Giometti
@ 2020-07-06 13:35 ` Drew Fustini
  2020-07-06 18:19   ` Rodolfo Giometti
  2020-07-06 13:43 ` Linus Walleij
  1 sibling, 1 reply; 28+ messages in thread
From: Drew Fustini @ 2020-07-06 13:35 UTC (permalink / raw)
  To: Rodolfo Giometti; +Cc: linux-gpio, Linus Walleij, Bartosz Golaszewski

On Mon, Jul 06, 2020 at 02:19:49PM +0200, Rodolfo Giometti wrote:
> Hello,
> 
> at the moment if a developer wishes to use a GPIO as output or input with a well
> defined name from userspace via the sysfs interface he/she can use,
> respectively, the gpio-leds or gpio-uinput devices. However, IMHO, this is not
> the best nor a proper way to do it, that's why I'm here to propose this really
> simple interface named GPIO_UIO.
> 
> That's why I wrote the attached patch (for kernel 4.19) which it's just a
> proposal, and the purpose of this message is to collect feedback about this
> solution. Of course I'll be happy to port it for latest kernel release and
> complete it with all requested documentation and needed modifications, but I'll
> do it only if this patch has some changes to be accepted by GPIO subsystem's
> maintainers. :)
> 
> For the moment here is how it works:
> 
> 1) The patch is activated by the configuration entry CONFIG_GPIO_UIO.
> 
> 2) In the device-tree the developer defines all board's GPIO lines with their
> names and mode of functioning:
> 
> +       gpio_uio {
> +               compatible = "gpio-uio";
> +
> +               bypass0 {
> +                       gpios = <&gpionb 10 GPIO_ACTIVE_HIGH>;
> +                       mode = "out-low";
> +               };
> +
> +               bypass1 {
> +                       gpios = <&gpiosb 11 GPIO_ACTIVE_HIGH>;
> +                       mode = "out-low";
> +                       label = "bypass-1";
> +               };
> +        };
> 
> Property "mode" can be "asis", "input", "out-low", etc. and the property label
> can be used in case the GPIO line's name should be different from the node's name.
> 
> 3) At boot the GPIO lines are added:
> 
> [    2.398902] gpio-uio bypass0: line added
> [    2.423558] gpio-uio bypass-1: line added
> 
> 4) Then users will find a new class with entries, one for each new line:
> 
> # ls /sys/class/gpio-uio/
> bypass-1  bypass0
> 
> 5) By using the attribute "line" the users can get or set the line status
> 
> # cat /sys/class/gpio-uio/bypass-1/line
> 0
> # echo 1 > /sys/class/gpio-uio/bypass-1/line
> # cat /sys/class/gpio-uio/bypass-1/line
> 1
> 
> 6) Developers can monitor the GPIO lines via debugfs as for kernel modules:
> 
> # cat /sys/kernel/debug/gpio
> gpiochip1: GPIOs 446-475, parent: platform/d0018800.pinctrl, GPIO2:
>  gpio-457 (                    |bypass-1            ) out lo
> 
> gpiochip0: GPIOs 476-511, parent: platform/d0013800.pinctrl, GPIO1:
>  gpio-479 (                    |cd                  ) in  hi IRQ
>  gpio-480 (                    |vcc_sd1             ) out lo
>  gpio-486 (                    |bypass0             ) out lo

This is similar to an out-of-tree driver we use in the kernel build for
our BeagleBoard.org Debian images called gpio-of-helper [0].

It is a DT based driver created by Pantelis Antoniou back in 2013.  It
allows our downstream BeagleBoard.org dts files to describe the gpio
lines that will be controlled from userspace.  We failed to get the
driver upstream back then, and it has remained out-of-tree since.

Currently, I am trying to shrink our out-of-tree patches [1] so we can
eventually get our BeagleBoard.org kernel builds on to mainline. Thus
coming up with a mainline solution for this is important to me. I was to
chat virtually last week with Bart [2], Geert and Linus and it does seem
like the new GPIO aggregator [3] could address this use case. I need to
do some experimentation to understand how that would work.

Regards,
Drew

[0] https://github.com/beagleboard/linux/blob/5.4/drivers/gpio/gpio-of-helper.c
[1] https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-5.4.y/patches
[2] https://static.sched.com/hosted_files/ossna2020/67/Linux%20GPIO-Evolution%20and%20Current%20State%20of%20the%20User%20API.pdf
[3] https://www.kernel.org/doc/html/latest/admin-guide/gpio/gpio-aggregator.html


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO User I/O
  2020-07-06 12:19 [RFC] GPIO User I/O Rodolfo Giometti
  2020-07-06 13:35 ` Drew Fustini
@ 2020-07-06 13:43 ` Linus Walleij
  2020-07-06 15:33   ` Rodolfo Giometti
  1 sibling, 1 reply; 28+ messages in thread
From: Linus Walleij @ 2020-07-06 13:43 UTC (permalink / raw)
  To: Rodolfo Giometti; +Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski

Hi Rodolfo!

thanks for your mail.

On Mon, Jul 6, 2020 at 2:19 PM Rodolfo Giometti <giometti@enneenne.com> wrote:

> 4) Then users will find a new class with entries, one for each new line:
>
> # ls /sys/class/gpio-uio/
> bypass-1  bypass0
>
> 5) By using the attribute "line" the users can get or set the line status
>
> # cat /sys/class/gpio-uio/bypass-1/line
> 0
> # echo 1 > /sys/class/gpio-uio/bypass-1/line
> # cat /sys/class/gpio-uio/bypass-1/line
> 1

This interface is problematic because it extends the sysfs ABI which is
obsolete. This is why the documentation of this ABI has been moved to
Documentation/ABI/obsolete/sysfs-gpio  for many years.

The sysfs approach has several problems which are summarized like
this in the commit where it was introduced:

commit 3c702e9987e261042a07e43460a8148be254412e
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Wed Oct 21 15:29:53 2015 +0200

    gpio: add a userspace chardev ABI for GPIOs

    A new chardev that is to be used for userspace GPIO access is
    added in this patch. It is intended to gradually replace the
    horribly broken sysfs ABI.

    Using a chardev has many upsides:

    - All operations are per-gpiochip, which is the actual
      device underlying the GPIOs, making us tie in to the
      kernel device model properly.

    - Hotpluggable GPIO controllers can come and go, as this
      kind of problem has been know to userspace for character
      devices since ages, and if a gpiochip handle is held in
      userspace we know we will break something, whereas the
      sysfs is stateless.

    - The one-value-per-file rule of sysfs is really hard to
      maintain when you want to twist more than one knob at a time,
      for example have in-kernel APIs to switch several GPIO
      lines at the same time, and this will be possible to do
      with a single ioctl() from userspace, saving a lot of
      context switching.
(...)

Another thing that is not mentioned here is that when a character
device is opened it is automatically closed if a process crashes,
which means that kernelspace can do clean-ups and reference counting
and making the lines available to other consumers (like if you
restart the program).

With Geert's GPIO aggregator userspace and device tree can conjure
special per-usecase gpio chips as pointed out by Drew: this is
very useful when you want some kernel-managed yet
usecase-specific GPIO lines in a special "container" chip.
To me this is the best of two worlds. (Kernelspace and userspace.)

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO User I/O
  2020-07-06 13:43 ` Linus Walleij
@ 2020-07-06 15:33   ` Rodolfo Giometti
  2020-07-06 20:38     ` Linus Walleij
  0 siblings, 1 reply; 28+ messages in thread
From: Rodolfo Giometti @ 2020-07-06 15:33 UTC (permalink / raw)
  To: Linus Walleij; +Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski

On 06/07/2020 15:43, Linus Walleij wrote:
> Hi Rodolfo!

Hi. :)

> thanks for your mail.
> 
> On Mon, Jul 6, 2020 at 2:19 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
> 
>> 4) Then users will find a new class with entries, one for each new line:
>>
>> # ls /sys/class/gpio-uio/
>> bypass-1  bypass0
>>
>> 5) By using the attribute "line" the users can get or set the line status
>>
>> # cat /sys/class/gpio-uio/bypass-1/line
>> 0
>> # echo 1 > /sys/class/gpio-uio/bypass-1/line
>> # cat /sys/class/gpio-uio/bypass-1/line
>> 1
> 
> This interface is problematic because it extends the sysfs ABI which is
> obsolete. This is why the documentation of this ABI has been moved to
> Documentation/ABI/obsolete/sysfs-gpio  for many years.

This support is not part of CONFIG_GPIO_SYSFS; it just uses the sysfs to work.

> The sysfs approach has several problems which are summarized like
> this in the commit where it was introduced:

I see, but my solution is just for having an easy-to-use way to get access to
meaningful GPIOs the board manufacturer defined for some specific usage during
the board design. It's not generic as gpio-sysfs.

> Another thing that is not mentioned here is that when a character
> device is opened it is automatically closed if a process crashes,
> which means that kernelspace can do clean-ups and reference counting
> and making the lines available to other consumers (like if you
> restart the program).

In this case there is nothing to release nor clean up since each line has a
fixed name, usage and it can be used as input or output without modifications.

> With Geert's GPIO aggregator userspace and device tree can conjure
> special per-usecase gpio chips as pointed out by Drew: this is
> very useful when you want some kernel-managed yet
> usecase-specific GPIO lines in a special "container" chip.
> To me this is the best of two worlds. (Kernelspace and userspace.)

Maybe this is the "best of two worlds" as you say but the problem is that board
manufactures need a way to well-define how a GPIO line must be used for within
the device-tree and without the need of patches! In this point of view neither
the "driver_override" way nor adding a compatible value to
gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each
board!). That's why at the moment they prefer not specify these GPIO lines at
all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it
simple...

By using my solution each board manufacturer can specify meaningful GPIO lines
directly within the device-tree, then users can use it via the "line" property
or just use the new chrdev interface for better performances.

Also my solution allows developers to manage these lines without any external
programs but just using cat&echo. This is _very_ useful when your embedded
system has a very tiny rootfs!

My two cents. :)

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO User I/O
  2020-07-06 13:35 ` Drew Fustini
@ 2020-07-06 18:19   ` Rodolfo Giometti
  0 siblings, 0 replies; 28+ messages in thread
From: Rodolfo Giometti @ 2020-07-06 18:19 UTC (permalink / raw)
  To: Drew Fustini; +Cc: linux-gpio, Linus Walleij, Bartosz Golaszewski

On 06/07/2020 15:35, Drew Fustini wrote:
> This is similar to an out-of-tree driver we use in the kernel build for
> our BeagleBoard.org Debian images called gpio-of-helper [0].
> 
> It is a DT based driver created by Pantelis Antoniou back in 2013.  It
> allows our downstream BeagleBoard.org dts files to describe the gpio
> lines that will be controlled from userspace.  We failed to get the
> driver upstream back then, and it has remained out-of-tree since.

I see.

However my support is not designed for a general purpose board where GPIOs usage
may vary, but for final products where GPIO lines are well-defined (even if the
patch can be easily modified in order to support unregister() operations).

> Currently, I am trying to shrink our out-of-tree patches [1] so we can
> eventually get our BeagleBoard.org kernel builds on to mainline. Thus
> coming up with a mainline solution for this is important to me. I was to
> chat virtually last week with Bart [2], Geert and Linus and it does seem
> like the new GPIO aggregator [3] could address this use case. I need to
> do some experimentation to understand how that would work.

As already stated in my last e-mail to Linus GPIO aggregator doesn't allow board
manufacturer to define meaningful GPIO lines within the device tree without
additional patches or by forcing users to define them by additional commands
after boot.

Why a LED should be easily and completely managed within the device-tree and a
relè, a photo-diode or any other input/output digital line should not? :-/

The driver by Pantelis Antoniou and my support does this jobs without interfere
with other GPIOs mechanisms.

I think the maintainers should seriously consider it.

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO User I/O
  2020-07-06 15:33   ` Rodolfo Giometti
@ 2020-07-06 20:38     ` Linus Walleij
  2020-07-06 21:00       ` Geert Uytterhoeven
  0 siblings, 1 reply; 28+ messages in thread
From: Linus Walleij @ 2020-07-06 20:38 UTC (permalink / raw)
  To: Rodolfo Giometti, Geert Uytterhoeven
  Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski

On Mon, Jul 6, 2020 at 5:33 PM Rodolfo Giometti <giometti@enneenne.com> wrote:

> > With Geert's GPIO aggregator userspace and device tree can conjure
> > special per-usecase gpio chips as pointed out by Drew: this is
> > very useful when you want some kernel-managed yet
> > usecase-specific GPIO lines in a special "container" chip.
> > To me this is the best of two worlds. (Kernelspace and userspace.)
>
> Maybe this is the "best of two worlds" as you say but the problem is that board
> manufactures need a way to well-define how a GPIO line must be used for within
> the device-tree and without the need of patches! In this point of view neither
> the "driver_override" way nor adding a compatible value to
> gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each
> board!). That's why at the moment they prefer not specify these GPIO lines at
> all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it
> simple...

I think the idea is to add a very generic DT compatible to the
gpio_aggregator_dt_ids[]. That way, any DT can use the aggregator
to create a new chip with named lines etc.

But Geert can speak of that.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO User I/O
  2020-07-06 20:38     ` Linus Walleij
@ 2020-07-06 21:00       ` Geert Uytterhoeven
  2020-07-07  7:17         ` Rodolfo Giometti
  0 siblings, 1 reply; 28+ messages in thread
From: Geert Uytterhoeven @ 2020-07-06 21:00 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Rodolfo Giometti, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski

On Mon, Jul 6, 2020 at 10:38 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Jul 6, 2020 at 5:33 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
> > > With Geert's GPIO aggregator userspace and device tree can conjure
> > > special per-usecase gpio chips as pointed out by Drew: this is
> > > very useful when you want some kernel-managed yet
> > > usecase-specific GPIO lines in a special "container" chip.
> > > To me this is the best of two worlds. (Kernelspace and userspace.)
> >
> > Maybe this is the "best of two worlds" as you say but the problem is that board
> > manufactures need a way to well-define how a GPIO line must be used for within
> > the device-tree and without the need of patches! In this point of view neither
> > the "driver_override" way nor adding a compatible value to
> > gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each
> > board!). That's why at the moment they prefer not specify these GPIO lines at
> > all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it
> > simple...
>
> I think the idea is to add a very generic DT compatible to the
> gpio_aggregator_dt_ids[]. That way, any DT can use the aggregator
> to create a new chip with named lines etc.
>
> But Geert can speak of that.

The idea is to describe the real device in DT, and add it's compatible value
to gpio_aggregator_dt_ids[], or enable support for it dynamically using
driver_override.
The former indeed requires modifying the driver.
Note that if you ever want to write a pure kernelspace driver, you do need
a proper compatible value anyway.

I do agree that it's annoying to have "gpio-leds", but not "gpio-motors"
or "gpio-relays".  However, you can always propose bindings for the
latter, and, when they have been accepted, add those compatible
values to upstream gpio_aggregator_dt_ids[].

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO User I/O
  2020-07-06 21:00       ` Geert Uytterhoeven
@ 2020-07-07  7:17         ` Rodolfo Giometti
  2020-07-07  7:41           ` Geert Uytterhoeven
       [not found]           ` <CAEf4M_C5ztHoiu4uGiiqxLF7uW6wbyxdg43cs=YgArszMfbXcw@mail.gmail.com>
  0 siblings, 2 replies; 28+ messages in thread
From: Rodolfo Giometti @ 2020-07-07  7:17 UTC (permalink / raw)
  To: Geert Uytterhoeven, Linus Walleij
  Cc: Geert Uytterhoeven, open list:GPIO SUBSYSTEM, Bartosz Golaszewski

On 06/07/2020 23:00, Geert Uytterhoeven wrote:
> On Mon, Jul 6, 2020 at 10:38 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Mon, Jul 6, 2020 at 5:33 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>>>> With Geert's GPIO aggregator userspace and device tree can conjure
>>>> special per-usecase gpio chips as pointed out by Drew: this is
>>>> very useful when you want some kernel-managed yet
>>>> usecase-specific GPIO lines in a special "container" chip.
>>>> To me this is the best of two worlds. (Kernelspace and userspace.)
>>>
>>> Maybe this is the "best of two worlds" as you say but the problem is that board
>>> manufactures need a way to well-define how a GPIO line must be used for within
>>> the device-tree and without the need of patches! In this point of view neither
>>> the "driver_override" way nor adding a compatible value to
>>> gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each
>>> board!). That's why at the moment they prefer not specify these GPIO lines at
>>> all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it
>>> simple...
>>
>> I think the idea is to add a very generic DT compatible to the
>> gpio_aggregator_dt_ids[]. That way, any DT can use the aggregator
>> to create a new chip with named lines etc.
>>
>> But Geert can speak of that.
> 
> The idea is to describe the real device in DT, and add it's compatible value
> to gpio_aggregator_dt_ids[], or enable support for it dynamically using
> driver_override.
> The former indeed requires modifying the driver.

I see.

> Note that if you ever want to write a pure kernelspace driver, you do need
> a proper compatible value anyway.

OK, but for our purposes we need just one compatible value.

> I do agree that it's annoying to have "gpio-leds", but not "gpio-motors"
> or "gpio-relays".  However, you can always propose bindings for the
> latter, and, when they have been accepted, add those compatible
> values to upstream gpio_aggregator_dt_ids[].

Having gpio-uio with proper names within it as motor0, motor1, relay0, etc. as
in my solution would be suffice. However, after these discussions, are there any
chances my patch (with needed modifications and documentation) may be accepted? :)

Thanks for your time and answers.

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO User I/O
  2020-07-07  7:17         ` Rodolfo Giometti
@ 2020-07-07  7:41           ` Geert Uytterhoeven
  2020-07-07  9:56             ` Rodolfo Giometti
       [not found]           ` <CAEf4M_C5ztHoiu4uGiiqxLF7uW6wbyxdg43cs=YgArszMfbXcw@mail.gmail.com>
  1 sibling, 1 reply; 28+ messages in thread
From: Geert Uytterhoeven @ 2020-07-07  7:41 UTC (permalink / raw)
  To: Rodolfo Giometti
  Cc: Linus Walleij, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

Hi Rodolfo,

CC devicetree

On Tue, Jul 7, 2020 at 9:17 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
> On 06/07/2020 23:00, Geert Uytterhoeven wrote:
> > On Mon, Jul 6, 2020 at 10:38 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> >> On Mon, Jul 6, 2020 at 5:33 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
> >>>> With Geert's GPIO aggregator userspace and device tree can conjure
> >>>> special per-usecase gpio chips as pointed out by Drew: this is
> >>>> very useful when you want some kernel-managed yet
> >>>> usecase-specific GPIO lines in a special "container" chip.
> >>>> To me this is the best of two worlds. (Kernelspace and userspace.)
> >>>
> >>> Maybe this is the "best of two worlds" as you say but the problem is that board
> >>> manufactures need a way to well-define how a GPIO line must be used for within
> >>> the device-tree and without the need of patches! In this point of view neither
> >>> the "driver_override" way nor adding a compatible value to
> >>> gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each
> >>> board!). That's why at the moment they prefer not specify these GPIO lines at
> >>> all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it
> >>> simple...
> >>
> >> I think the idea is to add a very generic DT compatible to the
> >> gpio_aggregator_dt_ids[]. That way, any DT can use the aggregator
> >> to create a new chip with named lines etc.
> >>
> >> But Geert can speak of that.
> >
> > The idea is to describe the real device in DT, and add it's compatible value
> > to gpio_aggregator_dt_ids[], or enable support for it dynamically using
> > driver_override.
> > The former indeed requires modifying the driver.
>
> I see.
>
> > Note that if you ever want to write a pure kernelspace driver, you do need
> > a proper compatible value anyway.
>
> OK, but for our purposes we need just one compatible value.
>
> > I do agree that it's annoying to have "gpio-leds", but not "gpio-motors"
> > or "gpio-relays".  However, you can always propose bindings for the
> > latter, and, when they have been accepted, add those compatible
> > values to upstream gpio_aggregator_dt_ids[].
>
> Having gpio-uio with proper names within it as motor0, motor1, relay0, etc. as
> in my solution would be suffice. However, after these discussions, are there any
> chances my patch (with needed modifications and documentation) may be accepted? :)
>
> Thanks for your time and answers.

Let's ask the DT people...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO User I/O
       [not found]           ` <CAEf4M_C5ztHoiu4uGiiqxLF7uW6wbyxdg43cs=YgArszMfbXcw@mail.gmail.com>
@ 2020-07-07  8:47             ` Geert Uytterhoeven
  0 siblings, 0 replies; 28+ messages in thread
From: Geert Uytterhoeven @ 2020-07-07  8:47 UTC (permalink / raw)
  To: Drew Fustini
  Cc: Rodolfo Giometti, Linus Walleij, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, Bartosz Golaszewski

Hi Drew,

On Tue, Jul 7, 2020 at 10:39 AM Drew Fustini <pdp7pdp7@gmail.com> wrote:
> On Tue, Jul 7, 2020, 09:18 Rodolfo Giometti <giometti@enneenne.com> wrote:
>> On 06/07/2020 23:00, Geert Uytterhoeven wrote:
>> > On Mon, Jul 6, 2020 at 10:38 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>> >> On Mon, Jul 6, 2020 at 5:33 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>> >>>> With Geert's GPIO aggregator userspace and device tree can conjure
>> >>>> special per-usecase gpio chips as pointed out by Drew: this is
>> >>>> very useful when you want some kernel-managed yet
>> >>>> usecase-specific GPIO lines in a special "container" chip.
>> >>>> To me this is the best of two worlds. (Kernelspace and userspace.)
>> >>>
>> >>> Maybe this is the "best of two worlds" as you say but the problem is that board
>> >>> manufactures need a way to well-define how a GPIO line must be used for within
>> >>> the device-tree and without the need of patches! In this point of view neither
>> >>> the "driver_override" way nor adding a compatible value to
>> >>> gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each
>> >>> board!). That's why at the moment they prefer not specify these GPIO lines at
>> >>> all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it
>> >>> simple...
>> >>
>> >> I think the idea is to add a very generic DT compatible to the
>> >> gpio_aggregator_dt_ids[]. That way, any DT can use the aggregator
>> >> to create a new chip with named lines etc.
>> >>
>> >> But Geert can speak of that.
>> >
>> > The idea is to describe the real device in DT, and add it's compatible value
>> > to gpio_aggregator_dt_ids[], or enable support for it dynamically using
>> > driver_override.
>> > The former indeed requires modifying the driver.
>>
>> I see.
>>
>> > Note that if you ever want to write a pure kernelspace driver, you do need
>> > a proper compatible value anyway.
>>
>> OK, but for our purposes we need just one compatible value.
>>
>> > I do agree that it's annoying to have "gpio-leds", but not "gpio-motors"
>> > or "gpio-relays".  However, you can always propose bindings for the
>> > latter, and, when they have been accepted, add those compatible
>> > values to upstream gpio_aggregator_dt_ids[].
>>
>> Having gpio-uio with proper names within it as motor0, motor1, relay0, etc. as
>> in my solution would be suffice. However, after these discussions, are there any
>> chances my patch (with needed modifications and documentation) may be accepted? :)
>
>
> Hi, I would like to clarify my understanding of what gpio-uio.
>
> Is there something in mainline that already uses that binding?

No there isn't.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO User I/O
  2020-07-07  7:41           ` Geert Uytterhoeven
@ 2020-07-07  9:56             ` Rodolfo Giometti
  2020-07-09 14:11               ` [RFC] GPIO lines [was: GPIO User I/O] Rodolfo Giometti
  0 siblings, 1 reply; 28+ messages in thread
From: Rodolfo Giometti @ 2020-07-07  9:56 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Linus Walleij, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On 07/07/2020 09:41, Geert Uytterhoeven wrote:
> Hi Rodolfo,
> 
> CC devicetree
> 
> On Tue, Jul 7, 2020 at 9:17 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>> On 06/07/2020 23:00, Geert Uytterhoeven wrote:
>>> On Mon, Jul 6, 2020 at 10:38 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>>>> On Mon, Jul 6, 2020 at 5:33 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>>>>>> With Geert's GPIO aggregator userspace and device tree can conjure
>>>>>> special per-usecase gpio chips as pointed out by Drew: this is
>>>>>> very useful when you want some kernel-managed yet
>>>>>> usecase-specific GPIO lines in a special "container" chip.
>>>>>> To me this is the best of two worlds. (Kernelspace and userspace.)
>>>>>
>>>>> Maybe this is the "best of two worlds" as you say but the problem is that board
>>>>> manufactures need a way to well-define how a GPIO line must be used for within
>>>>> the device-tree and without the need of patches! In this point of view neither
>>>>> the "driver_override" way nor adding a compatible value to
>>>>> gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each
>>>>> board!). That's why at the moment they prefer not specify these GPIO lines at
>>>>> all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it
>>>>> simple...
>>>>
>>>> I think the idea is to add a very generic DT compatible to the
>>>> gpio_aggregator_dt_ids[]. That way, any DT can use the aggregator
>>>> to create a new chip with named lines etc.
>>>>
>>>> But Geert can speak of that.
>>>
>>> The idea is to describe the real device in DT, and add it's compatible value
>>> to gpio_aggregator_dt_ids[], or enable support for it dynamically using
>>> driver_override.
>>> The former indeed requires modifying the driver.
>>
>> I see.
>>
>>> Note that if you ever want to write a pure kernelspace driver, you do need
>>> a proper compatible value anyway.
>>
>> OK, but for our purposes we need just one compatible value.
>>
>>> I do agree that it's annoying to have "gpio-leds", but not "gpio-motors"
>>> or "gpio-relays".  However, you can always propose bindings for the
>>> latter, and, when they have been accepted, add those compatible
>>> values to upstream gpio_aggregator_dt_ids[].
>>
>> Having gpio-uio with proper names within it as motor0, motor1, relay0, etc. as
>> in my solution would be suffice. However, after these discussions, are there any
>> chances my patch (with needed modifications and documentation) may be accepted? :)
>>
>> Thanks for your time and answers.
> 
> Let's ask the DT people...

I think I need an OK from GPIO SUBSYSTEM's maintainers first...

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [RFC] GPIO lines [was: GPIO User I/O]
  2020-07-07  9:56             ` Rodolfo Giometti
@ 2020-07-09 14:11               ` Rodolfo Giometti
  2020-07-11 15:21                 ` Linus Walleij
  0 siblings, 1 reply; 28+ messages in thread
From: Rodolfo Giometti @ 2020-07-09 14:11 UTC (permalink / raw)
  To: Geert Uytterhoeven, Linus Walleij
  Cc: Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]

Hello,

I reworked a bit my proposal due to the fact that the name "GPIO User I/O" is
not so clear as I supposed to be... so I renamed it as "GPIO lines". :)

Since this support is intended to allow boards developers to easily define their
GPIO lines for a well defined purpose from the userspace I thing this last name
is more appropriate.

Within the device tree we have to specify each line:

        gpio_lines {
                compatible = "gpio-line";

                bypass0 {
                        gpios = <&gpionb 10 GPIO_ACTIVE_HIGH>;
                        mode = "out-low";
                };

                bypass1 {
                        gpios = <&gpiosb 11 GPIO_ACTIVE_HIGH>;
                        mode = "out-low";
                };

                key {
                        gpios = <&gpionb 4 GPIO_ACTIVE_HIGH>;
                        mode = "input";
                };

                motor {
                        gpios = <&gpionb 8 GPIO_ACTIVE_HIGH>;
                        mode = "out-high-open-drain";
                };
        };

Then we enable the configuration settings CONFIG_GPIO_LINE so at boot we have:

[    2.377401] line bypass0: added
[    2.411496] line bypass1: added
[    2.416141] line key: added
[    2.419758] line motor: added

Then, when the boot is finished, we have the following entries in the new "line"
class:

# ls /sys/class/line/
bypass0  bypass1  key  motor

Now each line can be read and written by using the "state" attribute:

# cat /sys/class/line/bypass0/state
0
# echo 1 > /sys/class/line/bypass0/state
# cat /sys/class/line/bypass0/state
1

Hope it could be more acceptable now.

Please, let me know if should I propose a proper patch for inclusion or
something must be changed/added/fixed.

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

[-- Attachment #2: gpio-lines.patch --]
[-- Type: text/x-patch, Size: 8732 bytes --]

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4f52c3a8ec99..f117b0b9d33e 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -73,6 +73,16 @@ config GPIO_SYSFS
 	  Kernel drivers may also request that a particular GPIO be
 	  exported to userspace; this can be useful when debugging.
 
+config GPIO_LINE
+	bool "/sys/class/line/... (GPIO lines interface)"
+	depends on SYSFS
+	help
+	  Say Y here to add a sysfs interface to manage system's GPIO lines.
+
+	  Instead of the GPIO_SYSFS support, by using this support, you'll be
+	  able to use GPIOs from userspace as stated in the device-tree
+	  for well defined pourposes and by using proper names.
+
 config GPIO_GENERIC
 	depends on HAS_IOMEM # Only for IOMEM drivers
 	tristate
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index c256aff66a65..033a6b836dec 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_GPIOLIB)		+= gpiolib-legacy.o
 obj-$(CONFIG_GPIOLIB)		+= gpiolib-devprop.o
 obj-$(CONFIG_OF_GPIO)		+= gpiolib-of.o
 obj-$(CONFIG_GPIO_SYSFS)	+= gpiolib-sysfs.o
+obj-$(CONFIG_GPIO_LINE)		+= gpiolib-line.o
 obj-$(CONFIG_GPIO_ACPI)		+= gpiolib-acpi.o
 
 # Device drivers. Generally keep list sorted alphabetically
diff --git a/drivers/gpio/gpiolib-line.c b/drivers/gpio/gpiolib-line.c
new file mode 100644
index 000000000000..8abd08c1a5e3
--- /dev/null
+++ b/drivers/gpio/gpiolib-line.c
@@ -0,0 +1,256 @@
+/*
+ * GPIOlib - userspace I/O line interface
+ *
+ *
+ * Copyright (C) 2020   Rodolfo Giometti <giometti@enneenne.com>
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 2 of the License, or
+ *   (at your option) any later version.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details.
+ *
+ *   You should have received a copy of the GNU General Public License
+ *   along with this program; if not, write to the Free Software
+ *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/idr.h>
+#include <linux/kdev_t.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+
+#define GPIO_LINE_MAX_SOURCES       128      /* should be enough... */
+
+/*
+ * Local variables
+ */
+
+static dev_t gpio_line_devt;
+static struct class *gpio_line_class;
+
+static DEFINE_MUTEX(gpio_line_idr_lock);
+static DEFINE_IDR(gpio_line_idr);
+
+struct gpio_line_device {
+	struct gpio_desc *gpiod;
+        const char *name;
+        unsigned int id;
+        struct device *dev;
+};
+
+/*
+ * sysfs methods
+ */
+
+static ssize_t state_store(struct device *dev,
+                                struct device_attribute *attr,
+                                const char *buf, size_t count)
+{
+        struct gpio_line_device *gpio_line = dev_get_drvdata(dev);
+        int status, ret;
+
+        ret = sscanf(buf, "%d", &status);
+        if (ret != 1 && status != 0 && status != 1)
+                return -EINVAL;
+
+	gpiod_set_value_cansleep(gpio_line->gpiod, status);
+
+        return count;
+}
+
+static ssize_t state_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct gpio_line_device *gpio_line = dev_get_drvdata(dev);
+	int status = gpiod_get_value_cansleep(gpio_line->gpiod);
+
+	return sprintf(buf, "%d\n", status);
+}
+static DEVICE_ATTR_RW(state);
+
+/*
+ * Class attributes
+ */
+
+static struct attribute *gpio_line_attrs[] = {
+        &dev_attr_state.attr,
+        NULL,
+};
+
+static const struct attribute_group gpio_line_group = {
+        .attrs = gpio_line_attrs,
+};
+
+static const struct attribute_group *gpio_line_groups[] = {
+        &gpio_line_group,
+        NULL,
+};
+
+/*
+ * Driver stuff
+ */
+
+static int gpio_line_create_entry(const char *name,
+				struct gpio_desc *gpiod,
+				struct device *parent)
+{
+	struct gpio_line_device *gpio_line;
+	dev_t devt;
+	int ret;
+
+	/* First allocate a new gpio_line device */
+	gpio_line = kmalloc(sizeof(struct gpio_line_device), GFP_KERNEL);
+	if (!gpio_line)
+		return -ENOMEM;
+
+        mutex_lock(&gpio_line_idr_lock);
+        /*
+         * Get new ID for the new gpio_line source.  After idr_alloc() calling
+         * the new source will be freely available into the kernel.
+         */
+        ret = idr_alloc(&gpio_line_idr, gpio_line, 0,
+			GPIO_LINE_MAX_SOURCES, GFP_KERNEL);
+        if (ret < 0) {
+                if (ret == -ENOSPC) {
+                        pr_err("%s: too many GPIO lines in the system\n",
+                               name);
+                        ret = -EBUSY;
+                }
+                goto error_device_create;
+        }
+        gpio_line->id = ret;
+        mutex_unlock(&gpio_line_idr_lock);
+
+	/* Create the device and init the device's data */
+        devt = MKDEV(MAJOR(gpio_line_devt), gpio_line->id);
+	gpio_line->dev = device_create(gpio_line_class, parent, devt, gpio_line,
+				   "%s", name);
+	if (IS_ERR(gpio_line->dev)) {
+		dev_err(gpio_line->dev, "unable to create device %s\n", name);
+		ret = PTR_ERR(gpio_line->dev);
+		goto error_idr_remove;
+	}
+	dev_set_drvdata(gpio_line->dev, gpio_line);
+
+	/* Init the gpio_line data */
+	gpio_line->gpiod = gpiod;
+	gpio_line->name = name;
+
+	dev_info(gpio_line->dev, "added\n");
+
+	return 0;
+
+error_idr_remove:
+	mutex_lock(&gpio_line_idr_lock);
+        idr_remove(&gpio_line_idr, gpio_line->id);
+
+error_device_create:
+	mutex_unlock(&gpio_line_idr_lock);
+	kfree(gpio_line);
+
+	return ret;
+}
+
+static int gpio_line_gpio_probe(struct platform_device *pdev)
+{
+        struct device *dev = &pdev->dev;
+        struct fwnode_handle *child;
+        int ret;
+
+        device_for_each_child_node(dev, child) {
+		struct device_node *np = to_of_node(child);
+                const char *label;
+		enum gpiod_flags flags = GPIOD_ASIS;
+                const char *mode = "as-is";
+		struct gpio_desc *gpiod;
+
+                ret = fwnode_property_read_string(child, "label", &label);
+                if (ret && IS_ENABLED(CONFIG_OF) && np)
+                        label = np->name;
+                if (!label) {
+                        dev_err(dev,
+				"label property not defined or invalid!\n");
+                        goto skip;
+                }
+
+		ret = fwnode_property_read_string(child, "mode", &mode);
+		if ((ret == 0) && mode) {
+			if (strcmp("as-is", mode) == 0)
+				flags = GPIOD_ASIS;
+			else if (strcmp("input", mode) == 0)
+				flags = GPIOD_IN;
+			else if (strcmp("out-low", mode) == 0)
+				flags = GPIOD_OUT_LOW;
+			else if (strcmp("out-high", mode) == 0)
+				flags = GPIOD_OUT_HIGH;
+			else if (strcmp("out-low-open-drain", mode) == 0)
+				flags = GPIOD_OUT_LOW_OPEN_DRAIN;
+			else if (strcmp("out-high-open-drain", mode) == 0)
+				flags = GPIOD_OUT_HIGH_OPEN_DRAIN;
+		}
+
+                gpiod = devm_fwnode_get_gpiod_from_child(dev, NULL, child,
+                                                         flags, label);
+                if (IS_ERR(gpiod)) {
+                        dev_err(dev, "gpios property not defined!\n");
+                        goto skip;
+                }
+
+                ret = gpio_line_create_entry(label, gpiod, dev);
+                if (ret)
+                        goto skip;
+
+		/* Success, now go to the next child */
+		continue;
+
+skip:		/* Error, skip the child */
+		fwnode_handle_put(child);
+		dev_err(dev, "failed to register GPIO lines interface\n");
+        }
+
+        return 0;
+}
+
+static const struct of_device_id of_gpio_gpio_line_match[] = {
+        { .compatible = "gpio-line", },
+        { /* sentinel */ }
+};
+
+static struct platform_driver gpio_line_gpio_driver = {
+        .driver         = {
+                .name   = "gpio-line",
+                .of_match_table = of_gpio_gpio_line_match,
+        },
+};
+
+builtin_platform_driver_probe(gpio_line_gpio_driver, gpio_line_gpio_probe);
+
+/*
+ * Module stuff
+ */
+
+static int __init gpiolib_line_init(void)
+{
+	/* Create the new class */
+	gpio_line_class = class_create(THIS_MODULE, "line");
+	if (!gpio_line_class) {
+		printk(KERN_ERR "gpio_line: failed to create class\n");
+		return -ENOMEM;
+	}
+	gpio_line_class->dev_groups = gpio_line_groups;
+
+	return 0;
+}
+
+postcore_initcall(gpiolib_line_init);

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO lines [was: GPIO User I/O]
  2020-07-09 14:11               ` [RFC] GPIO lines [was: GPIO User I/O] Rodolfo Giometti
@ 2020-07-11 15:21                 ` Linus Walleij
  2020-07-13 14:20                   ` Rodolfo Giometti
  0 siblings, 1 reply; 28+ messages in thread
From: Linus Walleij @ 2020-07-11 15:21 UTC (permalink / raw)
  To: Rodolfo Giometti
  Cc: Geert Uytterhoeven, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Thu, Jul 9, 2020 at 4:11 PM Rodolfo Giometti <giometti@enneenne.com> wrote:

>         gpio_lines {
>                 compatible = "gpio-line";
>
>                 bypass0 {
>                         gpios = <&gpionb 10 GPIO_ACTIVE_HIGH>;
>                         mode = "out-low";
>                 };
>
>                 bypass1 {
>                         gpios = <&gpiosb 11 GPIO_ACTIVE_HIGH>;
>                         mode = "out-low";
>                 };
>
>                 key {
>                         gpios = <&gpionb 4 GPIO_ACTIVE_HIGH>;
>                         mode = "input";
>                 };
>
>                 motor {
>                         gpios = <&gpionb 8 GPIO_ACTIVE_HIGH>;
>                         mode = "out-high-open-drain";
>                 };

These mode = ... strings are really just a big confusion for me since
they reinvent several of the flags you can already give to the gpios,
see include/dt-bindings/gpio/gpio.h:

/* Bit 0 express polarity */
#define GPIO_ACTIVE_HIGH 0
#define GPIO_ACTIVE_LOW 1

/* Bit 1 express single-endedness */
#define GPIO_PUSH_PULL 0
#define GPIO_SINGLE_ENDED 2

/* Bit 2 express Open drain or open source */
#define GPIO_LINE_OPEN_SOURCE 0
#define GPIO_LINE_OPEN_DRAIN 4

/*
 * Open Drain/Collector is the combination of single-ended open drain interface.
 * Open Source/Emitter is the combination of single-ended open source interface.
 */
#define GPIO_OPEN_DRAIN (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN)
#define GPIO_OPEN_SOURCE (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_SOURCE)

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO lines [was: GPIO User I/O]
  2020-07-11 15:21                 ` Linus Walleij
@ 2020-07-13 14:20                   ` Rodolfo Giometti
  2020-07-13 21:26                     ` Linus Walleij
  0 siblings, 1 reply; 28+ messages in thread
From: Rodolfo Giometti @ 2020-07-13 14:20 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Geert Uytterhoeven, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On 11/07/2020 17:21, Linus Walleij wrote:
> On Thu, Jul 9, 2020 at 4:11 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
> 
>>         gpio_lines {
>>                 compatible = "gpio-line";
>>
>>                 bypass0 {
>>                         gpios = <&gpionb 10 GPIO_ACTIVE_HIGH>;
>>                         mode = "out-low";
>>                 };
>>
>>                 bypass1 {
>>                         gpios = <&gpiosb 11 GPIO_ACTIVE_HIGH>;
>>                         mode = "out-low";
>>                 };
>>
>>                 key {
>>                         gpios = <&gpionb 4 GPIO_ACTIVE_HIGH>;
>>                         mode = "input";
>>                 };
>>
>>                 motor {
>>                         gpios = <&gpionb 8 GPIO_ACTIVE_HIGH>;
>>                         mode = "out-high-open-drain";
>>                 };
> 
> These mode = ... strings are really just a big confusion for me since
> they reinvent several of the flags you can already give to the gpios,
> see include/dt-bindings/gpio/gpio.h:
> 
> /* Bit 0 express polarity */
> #define GPIO_ACTIVE_HIGH 0
> #define GPIO_ACTIVE_LOW 1
> 
> /* Bit 1 express single-endedness */
> #define GPIO_PUSH_PULL 0
> #define GPIO_SINGLE_ENDED 2
> 
> /* Bit 2 express Open drain or open source */
> #define GPIO_LINE_OPEN_SOURCE 0
> #define GPIO_LINE_OPEN_DRAIN 4
> 
> /*
>  * Open Drain/Collector is the combination of single-ended open drain interface.
>  * Open Source/Emitter is the combination of single-ended open source interface.
>  */
> #define GPIO_OPEN_DRAIN (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN)
> #define GPIO_OPEN_SOURCE (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_SOURCE)

These modes came from include/linux/gpio/consumer.h:

/**
 * Optional flags that can be passed to one of gpiod_* to configure direction
 * and output value. These values cannot be OR'd.
 */
enum gpiod_flags {
        GPIOD_ASIS      = 0,
        GPIOD_IN        = GPIOD_FLAGS_BIT_DIR_SET,
        GPIOD_OUT_LOW   = GPIOD_FLAGS_BIT_DIR_SET | GPIOD_FLAGS_BIT_DIR_OUT,
        GPIOD_OUT_HIGH  = GPIOD_FLAGS_BIT_DIR_SET | GPIOD_FLAGS_BIT_DIR_OUT |
                          GPIOD_FLAGS_BIT_DIR_VAL,
        GPIOD_OUT_LOW_OPEN_DRAIN = GPIOD_OUT_LOW | GPIOD_FLAGS_BIT_OPEN_DRAIN,
        GPIOD_OUT_HIGH_OPEN_DRAIN = GPIOD_OUT_HIGH | GPIOD_FLAGS_BIT_OPEN_DRAIN,
};

So a setting like the following should set at boot gpio10 as output to 0:

bypass0 {
        gpios = <&gpionb 10 GPIO_ACTIVE_HIGH>;
        mode = "out-low";
};

While the next one should set gpio10 as output to 1:

bypass0 {
        gpios = <&gpionb 10 GPIO_ACTIVE_LOW>;
        mode = "out-low";
};

Maybe I can do something similar to hog-gpio as below, if you prefer...

bypass0 {
        gpios = <&gpionb 10 GPIO_ACTIVE_LOW>;
	output-low;
};

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC] GPIO lines [was: GPIO User I/O]
  2020-07-13 14:20                   ` Rodolfo Giometti
@ 2020-07-13 21:26                     ` Linus Walleij
  2020-07-14 14:01                       ` [RFC v2 " Rodolfo Giometti
  0 siblings, 1 reply; 28+ messages in thread
From: Linus Walleij @ 2020-07-13 21:26 UTC (permalink / raw)
  To: Rodolfo Giometti
  Cc: Geert Uytterhoeven, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Jul 13, 2020 at 4:20 PM Rodolfo Giometti <giometti@enneenne.com> wrote:

> >>                 motor {
> >>                         gpios = <&gpionb 8 GPIO_ACTIVE_HIGH>;
> >>                         mode = "out-high-open-drain";
> >>                 };
(...)
> > /* Bit 2 express Open drain or open source */
> > #define GPIO_LINE_OPEN_SOURCE 0
> > #define GPIO_LINE_OPEN_DRAIN 4
(...)
> These modes came from include/linux/gpio/consumer.h:

OK I was a bit unclear. Mainly open drain should be a flag on
the line, not a mode.

> Maybe I can do something similar to hog-gpio as below, if you prefer...
>
> bypass0 {
>         gpios = <&gpionb 10 GPIO_ACTIVE_LOW>;
>         output-low;

Yes this is better, just boolean flags is not natural than strings
for this.

However it addresses in a way an issue we have had popping
up from time to time which is assignment of default values to
lines before they are used overall.

I think that would be a bit of thing that should be proper to
solve as part of this.

The discussion has often stopped short due to different
opinions on the device tree bindings for that.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2020-07-13 21:26                     ` Linus Walleij
@ 2020-07-14 14:01                       ` Rodolfo Giometti
  2020-07-16 13:38                         ` Linus Walleij
  0 siblings, 1 reply; 28+ messages in thread
From: Rodolfo Giometti @ 2020-07-14 14:01 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Geert Uytterhoeven, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

On 13/07/2020 23:26, Linus Walleij wrote:
> On Mon, Jul 13, 2020 at 4:20 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>> Maybe I can do something similar to hog-gpio as below, if you prefer...
>>
>> bypass0 {
>>         gpios = <&gpionb 10 GPIO_ACTIVE_LOW>;
>>         output-low;
> 
> Yes this is better, just boolean flags is not natural than strings
> for this.

OK, changed.

> However it addresses in a way an issue we have had popping
> up from time to time which is assignment of default values to
> lines before they are used overall.
> 
> I think that would be a bit of thing that should be proper to
> solve as part of this.
> 
> The discussion has often stopped short due to different
> opinions on the device tree bindings for that.

I see... however attached is a new version of my proposal patch with the
following changelog:

- GPIO line modes are now decoded as boolean properties (as for gpio-hogs).
  Allowed values are" "input", "output-low" and "output-high". If nothing is
  specified defaults to "as-is";

- At boot a more descriptive message for each line is displayed as below:

[    1.834901] line bypass0: GPIO486 added as output-low

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

[-- Attachment #2: gpio-line.patch --]
[-- Type: text/x-patch, Size: 7919 bytes --]

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4f52c3a8ec99..f117b0b9d33e 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -73,6 +73,16 @@ config GPIO_SYSFS
 	  Kernel drivers may also request that a particular GPIO be
 	  exported to userspace; this can be useful when debugging.
 
+config GPIO_LINE
+	bool "/sys/class/line/... (GPIO lines interface)"
+	depends on SYSFS
+	help
+	  Say Y here to add a sysfs interface to manage system's GPIO lines.
+
+	  Instead of the GPIO_SYSFS support, by using this support, you'll be
+	  able to use GPIOs from userspace as stated in the device-tree
+	  for well defined pourposes and by using proper names.
+
 config GPIO_GENERIC
 	depends on HAS_IOMEM # Only for IOMEM drivers
 	tristate
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index c256aff66a65..033a6b836dec 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_GPIOLIB)		+= gpiolib-legacy.o
 obj-$(CONFIG_GPIOLIB)		+= gpiolib-devprop.o
 obj-$(CONFIG_OF_GPIO)		+= gpiolib-of.o
 obj-$(CONFIG_GPIO_SYSFS)	+= gpiolib-sysfs.o
+obj-$(CONFIG_GPIO_LINE)		+= gpiolib-line.o
 obj-$(CONFIG_GPIO_ACPI)		+= gpiolib-acpi.o
 
 # Device drivers. Generally keep list sorted alphabetically
diff --git a/drivers/gpio/gpiolib-line.c b/drivers/gpio/gpiolib-line.c
new file mode 100644
index 000000000000..640c9971d97e
--- /dev/null
+++ b/drivers/gpio/gpiolib-line.c
@@ -0,0 +1,251 @@
+/*
+ * GPIOlib - userspace I/O line interface
+ *
+ *
+ * Copyright (C) 2020   Rodolfo Giometti <giometti@enneenne.com>
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 2 of the License, or
+ *   (at your option) any later version.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details.
+ *
+ *   You should have received a copy of the GNU General Public License
+ *   along with this program; if not, write to the Free Software
+ *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/idr.h>
+#include <linux/kdev_t.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+
+#define GPIO_LINE_MAX_SOURCES       128      /* should be enough... */
+
+/*
+ * Local variables
+ */
+
+static dev_t gpio_line_devt;
+static struct class *gpio_line_class;
+
+static DEFINE_MUTEX(gpio_line_idr_lock);
+static DEFINE_IDR(gpio_line_idr);
+
+struct gpio_line_device {
+	struct gpio_desc *gpiod;
+	const char *name;
+	unsigned int id;
+	struct device *dev;
+};
+
+/*
+ * sysfs methods
+ */
+
+static ssize_t state_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t count)
+{
+	struct gpio_line_device *gpio_line = dev_get_drvdata(dev);
+	int status, ret;
+
+	ret = sscanf(buf, "%d", &status);
+	if (ret != 1 && status != 0 && status != 1)
+		return -EINVAL;
+
+	gpiod_set_value_cansleep(gpio_line->gpiod, status);
+
+	return count;
+}
+
+static ssize_t state_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct gpio_line_device *gpio_line = dev_get_drvdata(dev);
+	int status = gpiod_get_value_cansleep(gpio_line->gpiod);
+
+	return sprintf(buf, "%d\n", status);
+}
+static DEVICE_ATTR_RW(state);
+
+/*
+ * Class attributes
+ */
+
+static struct attribute *gpio_line_attrs[] = {
+	&dev_attr_state.attr,
+	NULL,
+};
+
+static const struct attribute_group gpio_line_group = {
+	.attrs = gpio_line_attrs,
+};
+
+static const struct attribute_group *gpio_line_groups[] = {
+	&gpio_line_group,
+	NULL,
+};
+
+/*
+ * Driver stuff
+ */
+
+static struct gpio_line_device *gpio_line_create_entry(const char *name,
+				struct gpio_desc *gpiod,
+				struct device *parent)
+{
+	struct gpio_line_device *gpio_line;
+	dev_t devt;
+	int ret;
+
+	/* First allocate a new gpio_line device */
+	gpio_line = kmalloc(sizeof(struct gpio_line_device), GFP_KERNEL);
+	if (!gpio_line)
+		return ERR_PTR(-ENOMEM);
+
+	mutex_lock(&gpio_line_idr_lock);
+	/*
+	 * Get new ID for the new gpio_line source.  After idr_alloc() calling
+	 * the new source will be freely available into the kernel.
+	 */
+	ret = idr_alloc(&gpio_line_idr, gpio_line, 0,
+			GPIO_LINE_MAX_SOURCES, GFP_KERNEL);
+	if (ret < 0) {
+		if (ret == -ENOSPC) {
+			pr_err("%s: too many GPIO lines in the system\n",
+			       name);
+			ret = -EBUSY;
+		}
+		goto error_device_create;
+	}
+	gpio_line->id = ret;
+	mutex_unlock(&gpio_line_idr_lock);
+
+	/* Create the device and init the device's data */
+	devt = MKDEV(MAJOR(gpio_line_devt), gpio_line->id);
+	gpio_line->dev = device_create(gpio_line_class, parent, devt, gpio_line,
+				   "%s", name);
+	if (IS_ERR(gpio_line->dev)) {
+		dev_err(gpio_line->dev, "unable to create device %s\n", name);
+		ret = PTR_ERR(gpio_line->dev);
+		goto error_idr_remove;
+	}
+	dev_set_drvdata(gpio_line->dev, gpio_line);
+
+	/* Init the gpio_line data */
+	gpio_line->gpiod = gpiod;
+	gpio_line->name = name;
+
+	return gpio_line;
+
+error_idr_remove:
+	mutex_lock(&gpio_line_idr_lock);
+	idr_remove(&gpio_line_idr, gpio_line->id);
+
+error_device_create:
+	mutex_unlock(&gpio_line_idr_lock);
+	kfree(gpio_line);
+
+	return ERR_PTR(ret);
+}
+
+static int gpio_line_gpio_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct fwnode_handle *child;
+	struct gpio_line_device *gpio_line;
+	int ret;
+
+	device_for_each_child_node(dev, child) {
+		struct device_node *np = to_of_node(child);
+		const char *name;
+		enum gpiod_flags flags;
+		struct gpio_desc *gpiod;
+
+		ret = fwnode_property_read_string(child, "line-name", &name);
+		if (ret && IS_ENABLED(CONFIG_OF) && np)
+			name = np->name;
+		if (!name) {
+			dev_err(dev,
+				"name property not defined or invalid!\n");
+			goto skip;
+		}
+
+		flags = GPIOD_ASIS;
+		if (of_property_read_bool(np, "input"))
+			flags = GPIOD_IN;
+		else if (of_property_read_bool(np, "output-low"))
+			flags = GPIOD_OUT_LOW;
+		else if (of_property_read_bool(np, "output-high"))
+			flags = GPIOD_OUT_HIGH;
+		gpiod = devm_fwnode_get_gpiod_from_child(dev, NULL, child,
+							 flags, name);
+		if (IS_ERR(gpiod)) {
+			dev_err(dev, "gpios property not defined!\n");
+			goto skip;
+		}
+
+		gpio_line = gpio_line_create_entry(name, gpiod, dev);
+		if (IS_ERR(gpio_line))
+			goto skip;
+
+		/* Success, go to the next child */
+		dev_info(gpio_line->dev, "GPIO%d added as %s\n",
+			desc_to_gpio(gpiod),
+			flags == GPIOD_ASIS ? "as-is" :
+			  flags == GPIOD_OUT_HIGH ? "output-high" :
+			    flags == GPIOD_OUT_LOW ? "output-low" :
+			      flags == GPIOD_IN ? "input" : "unknow!");
+		continue;
+
+skip:		/* Error, skip the child */
+		fwnode_handle_put(child);
+		dev_err(dev, "failed to register GPIO lines interface\n");
+	}
+
+	return 0;
+}
+
+static const struct of_device_id of_gpio_gpio_line_match[] = {
+	{ .compatible = "gpio-line", },
+	{ /* sentinel */ }
+};
+
+static struct platform_driver gpio_line_gpio_driver = {
+	.driver	 = {
+		.name   = "gpio-line",
+		.of_match_table = of_gpio_gpio_line_match,
+	},
+};
+
+builtin_platform_driver_probe(gpio_line_gpio_driver, gpio_line_gpio_probe);
+
+/*
+ * Module stuff
+ */
+
+static int __init gpiolib_line_init(void)
+{
+	/* Create the new class */
+	gpio_line_class = class_create(THIS_MODULE, "line");
+	if (!gpio_line_class) {
+		printk(KERN_ERR "gpio_line: failed to create class\n");
+		return -ENOMEM;
+	}
+	gpio_line_class->dev_groups = gpio_line_groups;
+
+	return 0;
+}
+
+postcore_initcall(gpiolib_line_init);

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2020-07-14 14:01                       ` [RFC v2 " Rodolfo Giometti
@ 2020-07-16 13:38                         ` Linus Walleij
  2020-07-16 15:15                           ` Rodolfo Giometti
  0 siblings, 1 reply; 28+ messages in thread
From: Linus Walleij @ 2020-07-16 13:38 UTC (permalink / raw)
  To: Rodolfo Giometti
  Cc: Geert Uytterhoeven, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Tue, Jul 14, 2020 at 4:01 PM Rodolfo Giometti <giometti@enneenne.com> wrote:

> I see... however attached is a new version of my proposal patch

I looked a bit at this!

IIUC the idea is a "new" sysfs interface that does not require the exporting
etc used by the current "old" sysfs interface. Instead of poking around in
sysfs to export lines we do that from the device tree.

It also does not use any global GPIO numbers which would be my other
main concern.

I must admit that it has some elegance to it. Especially when it comes
to scripting.

The problem I see is that lines are left in whatever state they were in
if a script crashes, so there is no "return to the initial value" that was
there when the GPIOs were picked from the device tree. This makes
this a bit fragile.

Also users regularly need to listen to events. This interface can and
should never support that, for this one must use the character device,
which will of course not work in parallel with using this sysfs ABI.
And the day someone wants that we simply have to say no. There
is no way to hold states for event handling in a stateless ABI.

Well of course they can poll for a line to change, but that is not
proper event handling that reacts to an interrupt.

So while this is much more elegant the old sysfs ABI, and certainly
better for scripting, it still suffers from some conflicts with
the character device, and there is a risk to make users dissatisfied
when they want to e.g. script event handlers.

What are your thoughts on this?

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2020-07-16 13:38                         ` Linus Walleij
@ 2020-07-16 15:15                           ` Rodolfo Giometti
  2020-07-19 18:35                             ` Andy Shevchenko
  0 siblings, 1 reply; 28+ messages in thread
From: Rodolfo Giometti @ 2020-07-16 15:15 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Geert Uytterhoeven, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On 16/07/2020 15:38, Linus Walleij wrote:
> On Tue, Jul 14, 2020 at 4:01 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
> 
>> I see... however attached is a new version of my proposal patch
> 
> I looked a bit at this!
> 
> IIUC the idea is a "new" sysfs interface that does not require the exporting
> etc used by the current "old" sysfs interface. Instead of poking around in
> sysfs to export lines we do that from the device tree.

Yes.

> It also does not use any global GPIO numbers which would be my other
> main concern.

Exactly, the idea is to have "names" that describe the IO lines to the userspace
and a way to fix their usage in each board in the device tree. If a board has a
relay line is a non-sense allow users in the userland to use it as an input line.

> I must admit that it has some elegance to it. Especially when it comes
> to scripting.

:)

> The problem I see is that lines are left in whatever state they were in
> if a script crashes, so there is no "return to the initial value" that was
> there when the GPIOs were picked from the device tree. This makes
> this a bit fragile.

I see but this interface is not designed for such complex usage nor to compete
with the current character interface! It is designed to allow boards
manufactures to "describe" some I/O lines that are not used by any driver in the
device tree, and that users may desire to manage in a very simple manner. Let's
thing about relay lines, or just a locked/unlocked input line which can be
easily polled.

> Also users regularly need to listen to events. This interface can and
> should never support that, for this one must use the character device,
> which will of course not work in parallel with using this sysfs ABI.
> And the day someone wants that we simply have to say no. There
> is no way to hold states for event handling in a stateless ABI.
> 
> Well of course they can poll for a line to change, but that is not
> proper event handling that reacts to an interrupt.

Again, the basic idea is not to compete with the current character interface nor
to manage interrupts lines, but just to have a really simple way to describe
those I/O lines which at the moment has no name nor references within the device
tree.

> So while this is much more elegant the old sysfs ABI, and certainly
> better for scripting, it still suffers from some conflicts with
> the character device, and there is a risk to make users dissatisfied
> when they want to e.g. script event handlers.
> 
> What are your thoughts on this?

Regarding the event handlers we can add irq supports... however I prefer to keep
this interface really simple just to not be confused with the character interface.

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2020-07-16 15:15                           ` Rodolfo Giometti
@ 2020-07-19 18:35                             ` Andy Shevchenko
  2020-07-20  7:38                               ` Rodolfo Giometti
  2020-07-20  8:17                               ` Linus Walleij
  0 siblings, 2 replies; 28+ messages in thread
From: Andy Shevchenko @ 2020-07-19 18:35 UTC (permalink / raw)
  To: Rodolfo Giometti
  Cc: Linus Walleij, Geert Uytterhoeven, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Thu, Jul 16, 2020 at 6:17 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
> On 16/07/2020 15:38, Linus Walleij wrote:

...

> I see but this interface is not designed for such complex usage nor to compete
> with the current character interface! It is designed to allow boards
> manufactures to "describe" some I/O lines that are not used by any driver in the
> device tree,

Why are they not in firmware tables? Platform is a set of hardware
that makes it so.
If something is not in DT, then there is no possible way to know what
is that line?

Or in other words how does the OS know that the certain line is
connected to a relay?

> and that users may desire to manage in a very simple manner. Let's
> thing about relay lines, or just a locked/unlocked input line which can be
> easily polled.


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2020-07-19 18:35                             ` Andy Shevchenko
@ 2020-07-20  7:38                               ` Rodolfo Giometti
  2020-07-20  8:17                               ` Linus Walleij
  1 sibling, 0 replies; 28+ messages in thread
From: Rodolfo Giometti @ 2020-07-20  7:38 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Linus Walleij, Geert Uytterhoeven, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On 19/07/2020 20:35, Andy Shevchenko wrote:
> On Thu, Jul 16, 2020 at 6:17 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>> On 16/07/2020 15:38, Linus Walleij wrote:
> 
> ...
> 
>> I see but this interface is not designed for such complex usage nor to compete
>> with the current character interface! It is designed to allow boards
>> manufactures to "describe" some I/O lines that are not used by any driver in the
>> device tree,
> 
> Why are they not in firmware tables? Platform is a set of hardware
> that makes it so.
> If something is not in DT, then there is no possible way to know what
> is that line?
> 
> Or in other words how does the OS know that the certain line is
> connected to a relay?

I'm sorry but I'm not sure to understand you.

I think that within the DT the board developer should describe his/her hardware
in the most detailed manner for drivers and, as last step, for the userspace.
The OS should only knows such IO lines whose are driver related while other ones
(such as a relay or a generic digital input such as a lock/unlock signal) should
be described for the userspace.

At the moment the only way to "describe" a digital output/input not related to
any driver is by using the led or uinput interface that are not designed for
such purposes! My suggestion is to give a proper/dedicated description of such
IO lines.

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2020-07-19 18:35                             ` Andy Shevchenko
  2020-07-20  7:38                               ` Rodolfo Giometti
@ 2020-07-20  8:17                               ` Linus Walleij
  2021-04-26  8:44                                 ` Rodolfo Giometti
  1 sibling, 1 reply; 28+ messages in thread
From: Linus Walleij @ 2020-07-20  8:17 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rodolfo Giometti, Geert Uytterhoeven, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Sun, Jul 19, 2020 at 8:36 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Thu, Jul 16, 2020 at 6:17 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
> > On 16/07/2020 15:38, Linus Walleij wrote:
>
> > I see but this interface is not designed for such complex usage nor to compete
> > with the current character interface! It is designed to allow boards
> > manufactures to "describe" some I/O lines that are not used by any driver in the
> > device tree,
>
> Why are they not in firmware tables? Platform is a set of hardware
> that makes it so.
> If something is not in DT, then there is no possible way to know what
> is that line?
>
> Or in other words how does the OS know that the certain line is
> connected to a relay?

IIUC Rodolfo's idea is to provide this with a DT compatible.
The use case will be industrial automation-ish tasks from userspace.

Currently the only mechanism we have in the device tree to
assign a use for a line is the "gpio-line-names" property,
which creates a name that is reported upward to the character
device.

Rodolfo's patch is for scripting use cases, assigning some lines
for some cases to be handled by scripts, not the character device.

What I am a bit worried about is if this would be a Linuxism, as DT
should be OS neutral.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2020-07-20  8:17                               ` Linus Walleij
@ 2021-04-26  8:44                                 ` Rodolfo Giometti
  2021-04-26  8:48                                   ` Andy Shevchenko
  2021-04-26  9:31                                   ` Linus Walleij
  0 siblings, 2 replies; 28+ messages in thread
From: Rodolfo Giometti @ 2021-04-26  8:44 UTC (permalink / raw)
  To: Linus Walleij, Andy Shevchenko
  Cc: Geert Uytterhoeven, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
	Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On 20/07/20 10:17, Linus Walleij wrote:
> IIUC Rodolfo's idea is to provide this with a DT compatible.
> The use case will be industrial automation-ish tasks from userspace.
> 
> Currently the only mechanism we have in the device tree to
> assign a use for a line is the "gpio-line-names" property,
> which creates a name that is reported upward to the character
> device.
> 
> Rodolfo's patch is for scripting use cases, assigning some lines
> for some cases to be handled by scripts, not the character device.
> 
> What I am a bit worried about is if this would be a Linuxism, as DT
> should be OS neutral.

Hello Linus,

I'm currently using my solution for GPIOs management as input or output lines
described in the DT on several systems.

Are you re-thinking about this topic? Can we go further for inclusion or should
I continue doing out-of-tree? :(

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2021-04-26  8:44                                 ` Rodolfo Giometti
@ 2021-04-26  8:48                                   ` Andy Shevchenko
  2021-04-26  9:16                                     ` Rodolfo Giometti
  2021-04-26  9:31                                   ` Linus Walleij
  1 sibling, 1 reply; 28+ messages in thread
From: Andy Shevchenko @ 2021-04-26  8:48 UTC (permalink / raw)
  To: Rodolfo Giometti
  Cc: Linus Walleij, Geert Uytterhoeven, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Apr 26, 2021 at 11:44 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>
> On 20/07/20 10:17, Linus Walleij wrote:
> > IIUC Rodolfo's idea is to provide this with a DT compatible.
> > The use case will be industrial automation-ish tasks from userspace.
> >
> > Currently the only mechanism we have in the device tree to
> > assign a use for a line is the "gpio-line-names" property,
> > which creates a name that is reported upward to the character
> > device.
> >
> > Rodolfo's patch is for scripting use cases, assigning some lines
> > for some cases to be handled by scripts, not the character device.
> >
> > What I am a bit worried about is if this would be a Linuxism, as DT
> > should be OS neutral.

Not only neutral but be software'isms free!
It's only about hardware.

What I understand here is that we have missed the intermediate layer
(let's call it 'platform abstraction') where it's related to the
platform and neither strictly speaking hardware, nor software per se.

> I'm currently using my solution for GPIOs management as input or output lines
> described in the DT on several systems.
>
> Are you re-thinking about this topic? Can we go further for inclusion or should
> I continue doing out-of-tree? :(


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2021-04-26  8:48                                   ` Andy Shevchenko
@ 2021-04-26  9:16                                     ` Rodolfo Giometti
  0 siblings, 0 replies; 28+ messages in thread
From: Rodolfo Giometti @ 2021-04-26  9:16 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Linus Walleij, Geert Uytterhoeven, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On 26/04/21 10:48, Andy Shevchenko wrote:
> On Mon, Apr 26, 2021 at 11:44 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>>
>> On 20/07/20 10:17, Linus Walleij wrote:
>>> IIUC Rodolfo's idea is to provide this with a DT compatible.
>>> The use case will be industrial automation-ish tasks from userspace.
>>>
>>> Currently the only mechanism we have in the device tree to
>>> assign a use for a line is the "gpio-line-names" property,
>>> which creates a name that is reported upward to the character
>>> device.
>>>
>>> Rodolfo's patch is for scripting use cases, assigning some lines
>>> for some cases to be handled by scripts, not the character device.
>>>
>>> What I am a bit worried about is if this would be a Linuxism, as DT
>>> should be OS neutral.
> 
> Not only neutral but be software'isms free!
> It's only about hardware.
> 
> What I understand here is that we have missed the intermediate layer
> (let's call it 'platform abstraction') where it's related to the
> platform and neither strictly speaking hardware, nor software per se.

Maybe I don't well understand the-problem(TM), but why people are currently
using led and uinput layers to describes their output or input lines?

Why don't providing a dedicated layer for this special scope?

My two cents,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2021-04-26  8:44                                 ` Rodolfo Giometti
  2021-04-26  8:48                                   ` Andy Shevchenko
@ 2021-04-26  9:31                                   ` Linus Walleij
  2021-04-26  9:43                                     ` Rodolfo Giometti
  1 sibling, 1 reply; 28+ messages in thread
From: Linus Walleij @ 2021-04-26  9:31 UTC (permalink / raw)
  To: Rodolfo Giometti
  Cc: Andy Shevchenko, Geert Uytterhoeven, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Apr 26, 2021 at 10:44 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>
> On 20/07/20 10:17, Linus Walleij wrote:
> > IIUC Rodolfo's idea is to provide this with a DT compatible.
> > The use case will be industrial automation-ish tasks from userspace.
> >
> > Currently the only mechanism we have in the device tree to
> > assign a use for a line is the "gpio-line-names" property,
> > which creates a name that is reported upward to the character
> > device.
> >
> > Rodolfo's patch is for scripting use cases, assigning some lines
> > for some cases to be handled by scripts, not the character device.
> >
> > What I am a bit worried about is if this would be a Linuxism, as DT
> > should be OS neutral.
>
> Hello Linus,
>
> I'm currently using my solution for GPIOs management as input or output lines
> described in the DT on several systems.
>
> Are you re-thinking about this topic? Can we go further for inclusion or should
> I continue doing out-of-tree? :(

It is a system description question, and I think you will need to discuss it
on the devicetree@vger.kernel.org mailing list.

The people there are working with things like the system device tree which
is intended to describe aspects of a system apart from what Linux or
any operating system is doing with the hardware.

I would send an RFC of the proposed DT bindings there.

They have been Cced in the past but not addressed directly.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2021-04-26  9:31                                   ` Linus Walleij
@ 2021-04-26  9:43                                     ` Rodolfo Giometti
  2021-04-26 10:12                                       ` Linus Walleij
  0 siblings, 1 reply; 28+ messages in thread
From: Rodolfo Giometti @ 2021-04-26  9:43 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Andy Shevchenko, Geert Uytterhoeven, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On 26/04/21 11:31, Linus Walleij wrote:
> On Mon, Apr 26, 2021 at 10:44 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>>
>> On 20/07/20 10:17, Linus Walleij wrote:
>>> IIUC Rodolfo's idea is to provide this with a DT compatible.
>>> The use case will be industrial automation-ish tasks from userspace.
>>>
>>> Currently the only mechanism we have in the device tree to
>>> assign a use for a line is the "gpio-line-names" property,
>>> which creates a name that is reported upward to the character
>>> device.
>>>
>>> Rodolfo's patch is for scripting use cases, assigning some lines
>>> for some cases to be handled by scripts, not the character device.
>>>
>>> What I am a bit worried about is if this would be a Linuxism, as DT
>>> should be OS neutral.
>>
>> Hello Linus,
>>
>> I'm currently using my solution for GPIOs management as input or output lines
>> described in the DT on several systems.
>>
>> Are you re-thinking about this topic? Can we go further for inclusion or should
>> I continue doing out-of-tree? :(
> 
> It is a system description question, and I think you will need to discuss it
> on the devicetree@vger.kernel.org mailing list.
> 
> The people there are working with things like the system device tree which
> is intended to describe aspects of a system apart from what Linux or
> any operating system is doing with the hardware.

That sounds great to me! :-)

> I would send an RFC of the proposed DT bindings there.

I agree. Please, let me know if you need some help.

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2021-04-26  9:43                                     ` Rodolfo Giometti
@ 2021-04-26 10:12                                       ` Linus Walleij
  2021-04-26 11:20                                         ` Rodolfo Giometti
  0 siblings, 1 reply; 28+ messages in thread
From: Linus Walleij @ 2021-04-26 10:12 UTC (permalink / raw)
  To: Rodolfo Giometti
  Cc: Andy Shevchenko, Geert Uytterhoeven, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Mon, Apr 26, 2021 at 11:44 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
> On 26/04/21 11:31, Linus Walleij wrote:
> > On Mon, Apr 26, 2021 at 10:44 AM Rodolfo Giometti <giometti@enneenne.com> wrote:

> > I would send an RFC of the proposed DT bindings there.
>
> I agree. Please, let me know if you need some help.

I [general tense] would, implied [if I were you].

What I mean is that whoever wants to drive this should send
proposed DT bindings there.

I am not volunteering to drive the project. It needs to be driven
by those who have the need and can verify that it is fulfils the
needs they have.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [RFC v2 GPIO lines [was: GPIO User I/O]
  2021-04-26 10:12                                       ` Linus Walleij
@ 2021-04-26 11:20                                         ` Rodolfo Giometti
  0 siblings, 0 replies; 28+ messages in thread
From: Rodolfo Giometti @ 2021-04-26 11:20 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Andy Shevchenko, Geert Uytterhoeven, Geert Uytterhoeven,
	open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Rob Herring,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On 26/04/21 12:12, Linus Walleij wrote:
> On Mon, Apr 26, 2021 at 11:44 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>> On 26/04/21 11:31, Linus Walleij wrote:
>>> On Mon, Apr 26, 2021 at 10:44 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
> 
>>> I would send an RFC of the proposed DT bindings there.
>>
>> I agree. Please, let me know if you need some help.
> 
> I [general tense] would, implied [if I were you].
> 
> What I mean is that whoever wants to drive this should send
> proposed DT bindings there.

:)

> I am not volunteering to drive the project. It needs to be driven
> by those who have the need and can verify that it is fulfils the
> needs they have.

OK, I'm going to re-propose my patch to the devicetree@vger.kernel.org mailing
list putting you on Cc.

Thanks a lot for your suggestions.

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2021-04-26 11:20 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-06 12:19 [RFC] GPIO User I/O Rodolfo Giometti
2020-07-06 13:35 ` Drew Fustini
2020-07-06 18:19   ` Rodolfo Giometti
2020-07-06 13:43 ` Linus Walleij
2020-07-06 15:33   ` Rodolfo Giometti
2020-07-06 20:38     ` Linus Walleij
2020-07-06 21:00       ` Geert Uytterhoeven
2020-07-07  7:17         ` Rodolfo Giometti
2020-07-07  7:41           ` Geert Uytterhoeven
2020-07-07  9:56             ` Rodolfo Giometti
2020-07-09 14:11               ` [RFC] GPIO lines [was: GPIO User I/O] Rodolfo Giometti
2020-07-11 15:21                 ` Linus Walleij
2020-07-13 14:20                   ` Rodolfo Giometti
2020-07-13 21:26                     ` Linus Walleij
2020-07-14 14:01                       ` [RFC v2 " Rodolfo Giometti
2020-07-16 13:38                         ` Linus Walleij
2020-07-16 15:15                           ` Rodolfo Giometti
2020-07-19 18:35                             ` Andy Shevchenko
2020-07-20  7:38                               ` Rodolfo Giometti
2020-07-20  8:17                               ` Linus Walleij
2021-04-26  8:44                                 ` Rodolfo Giometti
2021-04-26  8:48                                   ` Andy Shevchenko
2021-04-26  9:16                                     ` Rodolfo Giometti
2021-04-26  9:31                                   ` Linus Walleij
2021-04-26  9:43                                     ` Rodolfo Giometti
2021-04-26 10:12                                       ` Linus Walleij
2021-04-26 11:20                                         ` Rodolfo Giometti
     [not found]           ` <CAEf4M_C5ztHoiu4uGiiqxLF7uW6wbyxdg43cs=YgArszMfbXcw@mail.gmail.com>
2020-07-07  8:47             ` [RFC] GPIO User I/O Geert Uytterhoeven

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.