[PATCH 0/2] gpio: Allow userspace export from DT

[PATCH 0/2] gpio: Allow userspace export from DT

[Martin Fuzzey]

Currently the gpio sysfs interface allows userspace to access simple hardware
where no kernel driver exists or would be useful.

However it requires userspace to know the gpio number that has been assigned
by the kernel.

That number, in the case of gpio drviers using dynamic allocation, is not fixed,
and may change when:
* The kernel version changes and ARCH_NR_GPIOS is changed (happened in 3.17)
* The kernel version changes and probe order changes for gpio chips.
* The kernel configuration is changed if CONFIG_ARCH_NR_GPIO is used
* The board is redesigned (eg switching an externally visible signal from a
SoC provided GPIO to an I2C expander chip or vice versa).
* Other GPIO chips are added to the system.

The above means that, in order to export the GPIO to userspace via
/sys/class/gpio/export the userspace code must know the exact hardware and
kernel version information.

Furthermore, in many cases, it makes no sense to allow userspace to change the
signal direction; even if the GPIO itself allows it the circuitry connected
to the pin often does not (eg a signal dedicated to an output function driving
a  transistor).

This patch series solves both problems by performing the external
signal => GPIO mapping in the device tree.

[PATCH 0/2] gpio: Allow userspace export from DT

[Martin Fuzzey]

Currently the gpio sysfs interface allows userspace to access simple hardware
where no kernel driver exists or would be useful.

However it requires userspace to know the gpio number that has been assigned
by the kernel.

That number, in the case of gpio drviers using dynamic allocation, is not fixed,
and may change when:
* The kernel version changes and ARCH_NR_GPIOS is changed (happened in 3.17)
* The kernel version changes and probe order changes for gpio chips.
* The kernel configuration is changed if CONFIG_ARCH_NR_GPIO is used
* The board is redesigned (eg switching an externally visible signal from a
SoC provided GPIO to an I2C expander chip or vice versa).
* Other GPIO chips are added to the system.

The above means that, in order to export the GPIO to userspace via
/sys/class/gpio/export the userspace code must know the exact hardware and
kernel version information.

Furthermore, in many cases, it makes no sense to allow userspace to change the
signal direction; even if the GPIO itself allows it the circuitry connected
to the pin often does not (eg a signal dedicated to an output function driving
a  transistor).

This patch series solves both problems by performing the external
signal => GPIO mapping in the device tree.

[PATCH 1/2] Doc: DT: Add binding document for GPIO exporter

[Martin Fuzzey]

Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
---
 .../devicetree/bindings/gpio/gpio-exporter.txt     |   40 ++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-exporter.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-exporter.txt b/Documentation/devicetree/bindings/gpio/gpio-exporter.txt
new file mode 100644
index 0000000..58fc2a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-exporter.txt
@@ -0,0 +1,40 @@
+Bindings to export some GPIOs to userspace.
+
+This is useful when some signals are made externally available by a piece
+of hardware (eg terminal blocks to connect sensors, actuators) but no
+special purpose kernel driver exists.
+
+Use of this binding allows userspace to have a stable name and input
+/ output mode across hardware and software versions.
+
+Required properties:
+- compatible: "linux,gpio-exporter"
+
+
+Each GPIO to be exported is represented as a child node with:
+
+Required child properties:
+- gpios : Reference to the GPIO to export (standard gpio binding)
+
+Optional child properties:
+- output : if present GPIO is output, otherwise input
+- initial-state : Initial state (0=low, 1=high) for output
+- allow-direction-change : Present if GPIO direction may be modified
+
+The name of the child node is that exposed to userspace.
+
+Example:
+	gpio_exporter:gpio-exporter {
+		compatible = "linux,gpio-exporter";
+
+		terminalblock_1_out1 {
+			gpios = <&gpio2 12 0>;
+			output;
+			initial-state = <0>;
+		};
+
+		terminalblock_1_in1 {
+			gpios = <&gpio2 15 0>;
+		};
+
+	};

[PATCH 1/2] Doc: DT: Add binding document for GPIO exporter

[Martin Fuzzey]

Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
---
 .../devicetree/bindings/gpio/gpio-exporter.txt     |   40 ++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-exporter.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-exporter.txt b/Documentation/devicetree/bindings/gpio/gpio-exporter.txt
new file mode 100644
index 0000000..58fc2a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-exporter.txt
@@ -0,0 +1,40 @@
+Bindings to export some GPIOs to userspace.
+
+This is useful when some signals are made externally available by a piece
+of hardware (eg terminal blocks to connect sensors, actuators) but no
+special purpose kernel driver exists.
+
+Use of this binding allows userspace to have a stable name and input
+/ output mode across hardware and software versions.
+
+Required properties:
+- compatible: "linux,gpio-exporter"
+
+
+Each GPIO to be exported is represented as a child node with:
+
+Required child properties:
+- gpios : Reference to the GPIO to export (standard gpio binding)
+
+Optional child properties:
+- output : if present GPIO is output, otherwise input
+- initial-state : Initial state (0=low, 1=high) for output
+- allow-direction-change : Present if GPIO direction may be modified
+
+The name of the child node is that exposed to userspace.
+
+Example:
+	gpio_exporter:gpio-exporter {
+		compatible = "linux,gpio-exporter";
+
+		terminalblock_1_out1 {
+			gpios = <&gpio2 12 0>;
+			output;
+			initial-state = <0>;
+		};
+
+		terminalblock_1_in1 {
+			gpios = <&gpio2 15 0>;
+		};
+
+	};

[PATCH 2/2] gpio: add driver to export DT configured GPIOs to userspace

[Martin Fuzzey]

Selected GPIOs (defined as child nodes in DT) may be exported as
symlinks to user space (using gpiod_export_link())

The advantages of this are:
* Userspace no longer needs to know the GPIO number (which may
vary with other hardware and with kernel version due to dynamic
allocation)
* Userspace can be prevented from changing the direction if that
does not make sense from a hardware perspective.

Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
---
 drivers/gpio/Kconfig         |    9 ++
 drivers/gpio/Makefile        |    1 
 drivers/gpio/gpio-exporter.c |  171 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 181 insertions(+)
 create mode 100644 drivers/gpio/gpio-exporter.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 633ec21..682fce2 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -110,6 +110,15 @@ config GPIO_DA9055
 config GPIO_MAX730X
 	tristate
 
+config GPIO_EXPORTER
+	tristate "Userspace exporter driver"
+	depends on OF_GPIO && GPIO_SYSFS
+	help
+	  This enables a GPIO consumer which exports some GPIOs to userspace.
+	  The GPIOs to be exported are defined in the device tree.
+	  The exported GPIOs are represented as symbolic links in sysfs,
+	  relieving usespace of the burden of knowing the GPIO number to export
+
 comment "Memory mapped GPIO drivers:"
 
 config GPIO_74XX_MMIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 81755f1..bb665c5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_GPIO_SYSFS)	+= gpiolib-sysfs.o
 obj-$(CONFIG_GPIO_ACPI)		+= gpiolib-acpi.o
 
 # Device drivers. Generally keep list sorted alphabetically
+obj-$(CONFIG_GPIO_EXPORTER)	+= gpio-exporter.o
 obj-$(CONFIG_GPIO_GENERIC)	+= gpio-generic.o
 
 obj-$(CONFIG_GPIO_74X164)	+= gpio-74x164.o
diff --git a/drivers/gpio/gpio-exporter.c b/drivers/gpio/gpio-exporter.c
new file mode 100644
index 0000000..72cdcf0
--- /dev/null
+++ b/drivers/gpio/gpio-exporter.c
@@ -0,0 +1,171 @@
+/*
+ * A driver that allows some gpios to be exported to userspace
+ * using friendly names.
+ *
+ * This allows the gpios to be exported to be configured in the device tree
+ * and frees userspace from having to know unstable gpio numbers.
+ *
+ * Copyright 2015 Parkeon
+ *
+ * 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.
+ *
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+
+
+struct gpio_exporter_gpio {
+	const char *name;
+	struct gpio_desc *desc;
+};
+
+struct gpio_exporter_data {
+	struct device *dev;
+	int num_gpios;
+	struct gpio_exporter_gpio *gpios;
+};
+
+static int gpio_exporter_do_one(struct gpio_exporter_data *data,
+				struct fwnode_handle *child)
+{
+	struct device_node *np = of_node(child);
+	const char *name = np->name;
+	const char *config;
+	struct gpio_desc *desc;
+	int ret;
+
+	desc = devm_get_gpiod_from_child(data->dev, child);
+	if (IS_ERR(desc)) {
+		ret = PTR_ERR(desc);
+		goto failed_get;
+	}
+
+	if (of_property_read_bool(np, "output")) {
+		u32 state = 0;
+
+		of_property_read_u32(np, "initial-state", &state);
+		ret = gpiod_direction_output(desc, state);
+	} else {
+		ret = gpiod_direction_input(desc);
+	}
+	if (ret)
+		goto failed_setdir;
+
+	ret = gpiod_export(desc,
+			of_property_read_bool(np, "allow-direction-change"));
+	if (ret)
+		goto failed_export;
+
+	ret = gpiod_export_link(data->dev, name, desc);
+	if (ret)
+		goto failed_link;
+
+	data->gpios[data->num_gpios].name = name;
+	data->gpios[data->num_gpios].desc = desc;
+	data->num_gpios++;
+
+	dev_info(data->dev,
+		"Exported gpio%d as '%s'\n", desc_to_gpio(desc), name);
+
+	return 0;
+
+failed_link:
+	gpiod_unexport(desc);
+
+failed_export:
+failed_setdir:
+failed_get:
+	dev_err(data->dev, "Failed to export gpio '%s': %d\n", name, ret);
+
+	return ret;
+}
+
+static void gpio_exporter_cleanup(struct gpio_exporter_data *data)
+{
+	int i;
+
+	for (i = 0; i < data->num_gpios; i++) {
+		sysfs_remove_link(&data->dev->kobj, data->gpios[i].name);
+		gpiod_unexport(data->gpios[i].desc);
+	}
+}
+
+static int gpio_exporter_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct fwnode_handle *child;
+	int num_gpios;
+	int ret;
+	struct gpio_exporter_data *data;
+
+	if (!dev->of_node)
+		return -ENODEV;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->dev = dev;
+	dev_set_drvdata(dev, data);
+
+	num_gpios = device_get_child_node_count(dev);
+	data->gpios = devm_kzalloc(dev, num_gpios * sizeof(*data->gpios),
+					GFP_KERNEL);
+	if (!data->gpios)
+		return -ENOMEM;
+
+	device_for_each_child_node(dev, child) {
+		ret = gpio_exporter_do_one(data, child);
+		if (ret)
+			goto out_cleanup;
+	}
+
+	dev_info(dev, "exported %d gpios\n", data->num_gpios);
+
+	return 0;
+
+out_cleanup:
+	gpio_exporter_cleanup(data);
+
+	return ret;
+}
+
+static int gpio_exporter_remove(struct platform_device *pdev)
+{
+	struct gpio_exporter_data *data = platform_get_drvdata(pdev);
+
+	gpio_exporter_cleanup(data);
+
+	return 0;
+}
+
+static const struct of_device_id gpio_exporter_dt_ids[] = {
+	 { .compatible = "linux,gpio-exporter", },
+	 { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, gpio_exporter_dt_ids);
+
+static struct platform_driver gpio_exporter_driver = {
+	.driver	= {
+		.name	= "gpio-exporter",
+		.of_match_table	= gpio_exporter_dt_ids,
+	},
+	.probe	= gpio_exporter_probe,
+	.remove = gpio_exporter_remove,
+};
+
+module_platform_driver(gpio_exporter_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Martin Fuzzey <mfuzzey@parkeon.com>");
+MODULE_DESCRIPTION("Userspace GPIO exporter");
+MODULE_ALIAS("platform:gpio-exporter");

[PATCH 2/2] gpio: add driver to export DT configured GPIOs to userspace

[Martin Fuzzey]

Selected GPIOs (defined as child nodes in DT) may be exported as
symlinks to user space (using gpiod_export_link())

The advantages of this are:
* Userspace no longer needs to know the GPIO number (which may
vary with other hardware and with kernel version due to dynamic
allocation)
* Userspace can be prevented from changing the direction if that
does not make sense from a hardware perspective.

Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
---
 drivers/gpio/Kconfig         |    9 ++
 drivers/gpio/Makefile        |    1 
 drivers/gpio/gpio-exporter.c |  171 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 181 insertions(+)
 create mode 100644 drivers/gpio/gpio-exporter.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 633ec21..682fce2 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -110,6 +110,15 @@ config GPIO_DA9055
 config GPIO_MAX730X
 	tristate
 
+config GPIO_EXPORTER
+	tristate "Userspace exporter driver"
+	depends on OF_GPIO && GPIO_SYSFS
+	help
+	  This enables a GPIO consumer which exports some GPIOs to userspace.
+	  The GPIOs to be exported are defined in the device tree.
+	  The exported GPIOs are represented as symbolic links in sysfs,
+	  relieving usespace of the burden of knowing the GPIO number to export
+
 comment "Memory mapped GPIO drivers:"
 
 config GPIO_74XX_MMIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 81755f1..bb665c5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_GPIO_SYSFS)	+= gpiolib-sysfs.o
 obj-$(CONFIG_GPIO_ACPI)		+= gpiolib-acpi.o
 
 # Device drivers. Generally keep list sorted alphabetically
+obj-$(CONFIG_GPIO_EXPORTER)	+= gpio-exporter.o
 obj-$(CONFIG_GPIO_GENERIC)	+= gpio-generic.o
 
 obj-$(CONFIG_GPIO_74X164)	+= gpio-74x164.o
diff --git a/drivers/gpio/gpio-exporter.c b/drivers/gpio/gpio-exporter.c
new file mode 100644
index 0000000..72cdcf0
--- /dev/null
+++ b/drivers/gpio/gpio-exporter.c
@@ -0,0 +1,171 @@
+/*
+ * A driver that allows some gpios to be exported to userspace
+ * using friendly names.
+ *
+ * This allows the gpios to be exported to be configured in the device tree
+ * and frees userspace from having to know unstable gpio numbers.
+ *
+ * Copyright 2015 Parkeon
+ *
+ * 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.
+ *
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+
+
+struct gpio_exporter_gpio {
+	const char *name;
+	struct gpio_desc *desc;
+};
+
+struct gpio_exporter_data {
+	struct device *dev;
+	int num_gpios;
+	struct gpio_exporter_gpio *gpios;
+};
+
+static int gpio_exporter_do_one(struct gpio_exporter_data *data,
+				struct fwnode_handle *child)
+{
+	struct device_node *np = of_node(child);
+	const char *name = np->name;
+	const char *config;
+	struct gpio_desc *desc;
+	int ret;
+
+	desc = devm_get_gpiod_from_child(data->dev, child);
+	if (IS_ERR(desc)) {
+		ret = PTR_ERR(desc);
+		goto failed_get;
+	}
+
+	if (of_property_read_bool(np, "output")) {
+		u32 state = 0;
+
+		of_property_read_u32(np, "initial-state", &state);
+		ret = gpiod_direction_output(desc, state);
+	} else {
+		ret = gpiod_direction_input(desc);
+	}
+	if (ret)
+		goto failed_setdir;
+
+	ret = gpiod_export(desc,
+			of_property_read_bool(np, "allow-direction-change"));
+	if (ret)
+		goto failed_export;
+
+	ret = gpiod_export_link(data->dev, name, desc);
+	if (ret)
+		goto failed_link;
+
+	data->gpios[data->num_gpios].name = name;
+	data->gpios[data->num_gpios].desc = desc;
+	data->num_gpios++;
+
+	dev_info(data->dev,
+		"Exported gpio%d as '%s'\n", desc_to_gpio(desc), name);
+
+	return 0;
+
+failed_link:
+	gpiod_unexport(desc);
+
+failed_export:
+failed_setdir:
+failed_get:
+	dev_err(data->dev, "Failed to export gpio '%s': %d\n", name, ret);
+
+	return ret;
+}
+
+static void gpio_exporter_cleanup(struct gpio_exporter_data *data)
+{
+	int i;
+
+	for (i = 0; i < data->num_gpios; i++) {
+		sysfs_remove_link(&data->dev->kobj, data->gpios[i].name);
+		gpiod_unexport(data->gpios[i].desc);
+	}
+}
+
+static int gpio_exporter_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct fwnode_handle *child;
+	int num_gpios;
+	int ret;
+	struct gpio_exporter_data *data;
+
+	if (!dev->of_node)
+		return -ENODEV;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->dev = dev;
+	dev_set_drvdata(dev, data);
+
+	num_gpios = device_get_child_node_count(dev);
+	data->gpios = devm_kzalloc(dev, num_gpios * sizeof(*data->gpios),
+					GFP_KERNEL);
+	if (!data->gpios)
+		return -ENOMEM;
+
+	device_for_each_child_node(dev, child) {
+		ret = gpio_exporter_do_one(data, child);
+		if (ret)
+			goto out_cleanup;
+	}
+
+	dev_info(dev, "exported %d gpios\n", data->num_gpios);
+
+	return 0;
+
+out_cleanup:
+	gpio_exporter_cleanup(data);
+
+	return ret;
+}
+
+static int gpio_exporter_remove(struct platform_device *pdev)
+{
+	struct gpio_exporter_data *data = platform_get_drvdata(pdev);
+
+	gpio_exporter_cleanup(data);
+
+	return 0;
+}
+
+static const struct of_device_id gpio_exporter_dt_ids[] = {
+	 { .compatible = "linux,gpio-exporter", },
+	 { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, gpio_exporter_dt_ids);
+
+static struct platform_driver gpio_exporter_driver = {
+	.driver	= {
+		.name	= "gpio-exporter",
+		.of_match_table	= gpio_exporter_dt_ids,
+	},
+	.probe	= gpio_exporter_probe,
+	.remove = gpio_exporter_remove,
+};
+
+module_platform_driver(gpio_exporter_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Martin Fuzzey <mfuzzey@parkeon.com>");
+MODULE_DESCRIPTION("Userspace GPIO exporter");
+MODULE_ALIAS("platform:gpio-exporter");

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Rob Herring]

On Mon, Apr 13, 2015 at 6:05 AM, Martin Fuzzey <mfuzzey@parkeon.com> wrote:
> Currently the gpio sysfs interface allows userspace to access simple hardware
> where no kernel driver exists or would be useful.

Whether or not a kernel driver exists can vary by kernel version. The
dtb needs to work either way. The way you have done it would require
dtb changes.

It would be useful to describe the function of gpios in a way that
either subsystems can bind to them (e.g. leds, rf-kill, keys, etc.) or
that information can be exported to userspace.

> However it requires userspace to know the gpio number that has been assigned
> by the kernel.
>
> That number, in the case of gpio drviers using dynamic allocation, is not fixed,
> and may change when:
> * The kernel version changes and ARCH_NR_GPIOS is changed (happened in 3.17)
> * The kernel version changes and probe order changes for gpio chips.
> * The kernel configuration is changed if CONFIG_ARCH_NR_GPIO is used
> * The board is redesigned (eg switching an externally visible signal from a
> SoC provided GPIO to an I2C expander chip or vice versa).
> * Other GPIO chips are added to the system.

Isn't there some plan/desire to fix the GPIO sysfs interface?

> The above means that, in order to export the GPIO to userspace via
> /sys/class/gpio/export the userspace code must know the exact hardware and
> kernel version information.
>
> Furthermore, in many cases, it makes no sense to allow userspace to change the
> signal direction; even if the GPIO itself allows it the circuitry connected
> to the pin often does not (eg a signal dedicated to an output function driving
> a  transistor).
>
> This patch series solves both problems by performing the external
> signal => GPIO mapping in the device tree.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/2] gpio: Allow userspace export from DT

[Rob Herring]

On Mon, Apr 13, 2015 at 6:05 AM, Martin Fuzzey <mfuzzey@parkeon.com> wrote:
> Currently the gpio sysfs interface allows userspace to access simple hardware
> where no kernel driver exists or would be useful.

Whether or not a kernel driver exists can vary by kernel version. The
dtb needs to work either way. The way you have done it would require
dtb changes.

It would be useful to describe the function of gpios in a way that
either subsystems can bind to them (e.g. leds, rf-kill, keys, etc.) or
that information can be exported to userspace.

> However it requires userspace to know the gpio number that has been assigned
> by the kernel.
>
> That number, in the case of gpio drviers using dynamic allocation, is not fixed,
> and may change when:
> * The kernel version changes and ARCH_NR_GPIOS is changed (happened in 3.17)
> * The kernel version changes and probe order changes for gpio chips.
> * The kernel configuration is changed if CONFIG_ARCH_NR_GPIO is used
> * The board is redesigned (eg switching an externally visible signal from a
> SoC provided GPIO to an I2C expander chip or vice versa).
> * Other GPIO chips are added to the system.

Isn't there some plan/desire to fix the GPIO sysfs interface?

> The above means that, in order to export the GPIO to userspace via
> /sys/class/gpio/export the userspace code must know the exact hardware and
> kernel version information.
>
> Furthermore, in many cases, it makes no sense to allow userspace to change the
> signal direction; even if the GPIO itself allows it the circuitry connected
> to the pin often does not (eg a signal dedicated to an output function driving
> a  transistor).
>
> This patch series solves both problems by performing the external
> signal => GPIO mapping in the device tree.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Linus Walleij]

On Wed, Apr 15, 2015 at 3:19 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Apr 13, 2015 at 6:05 AM, Martin Fuzzey <mfuzzey-mB3Nsq4MPf1BDgjK7y7TUQ@public.gmane.org> wrote:

>> That number, in the case of gpio drviers using dynamic allocation, is not fixed,
>> and may change when:
>> * The kernel version changes and ARCH_NR_GPIOS is changed (happened in 3.17)
>> * The kernel version changes and probe order changes for gpio chips.
>> * The kernel configuration is changed if CONFIG_ARCH_NR_GPIO is used
>> * The board is redesigned (eg switching an externally visible signal from a
>> SoC provided GPIO to an I2C expander chip or vice versa).
>> * Other GPIO chips are added to the system.
>
> Isn't there some plan/desire to fix the GPIO sysfs interface?

Desire yes. But well noone seems to do it...

There is also the perpetual abuse of sysfs to do things that should
be done in the kernel, like driving LEDs or reading switches.
But that's another problem I guess.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] gpio: Allow userspace export from DT

[Linus Walleij]

On Wed, Apr 15, 2015 at 3:19 PM, Rob Herring <robherring2@gmail.com> wrote:
> On Mon, Apr 13, 2015 at 6:05 AM, Martin Fuzzey <mfuzzey@parkeon.com> wrote:

>> That number, in the case of gpio drviers using dynamic allocation, is not fixed,
>> and may change when:
>> * The kernel version changes and ARCH_NR_GPIOS is changed (happened in 3.17)
>> * The kernel version changes and probe order changes for gpio chips.
>> * The kernel configuration is changed if CONFIG_ARCH_NR_GPIO is used
>> * The board is redesigned (eg switching an externally visible signal from a
>> SoC provided GPIO to an I2C expander chip or vice versa).
>> * Other GPIO chips are added to the system.
>
> Isn't there some plan/desire to fix the GPIO sysfs interface?

Desire yes. But well noone seems to do it...

There is also the perpetual abuse of sysfs to do things that should
be done in the kernel, like driving LEDs or reading switches.
But that's another problem I guess.

Yours,
Linus Walleij

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
> Currently the gpio sysfs interface allows userspace to access simple hardware
> where no kernel driver exists or would be useful.
> 
> However it requires userspace to know the gpio number that has been assigned
> by the kernel.
> 
> That number, in the case of gpio drviers using dynamic allocation, is not fixed,
> and may change when:
> * The kernel version changes and ARCH_NR_GPIOS is changed (happened in 3.17)
> * The kernel version changes and probe order changes for gpio chips.
> * The kernel configuration is changed if CONFIG_ARCH_NR_GPIO is used
> * The board is redesigned (eg switching an externally visible signal from a
> SoC provided GPIO to an I2C expander chip or vice versa).
> * Other GPIO chips are added to the system.
> 
> The above means that, in order to export the GPIO to userspace via
> /sys/class/gpio/export the userspace code must know the exact hardware and
> kernel version information.

Not quite. You can still determine the gpio number in the above cases by
walking the sysfs tree to find the chip and it's base. This is the only
way to do this for dynamic buses such as USB.

The only case for which this fails is if a pin function is moved (e.g.
your i2c-expander case above).

> Furthermore, in many cases, it makes no sense to allow userspace to
> change the signal direction; even if the GPIO itself allows it the
> circuitry connected to the pin often does not (eg a signal dedicated
> to an output function driving a  transistor).

Indeed. The current sysfs-interface is a hack (which I personally think
never should have been merged).

Firmware should describe pin directionality and function, and undefined
pins should never be allowed to be accessed from userspace.

Sure, the current GPIO-sysfs-interface is useful during development and
for one-off hacks, but I'm convinced it's detrimental in the long run as
it removes the incentives to fix the driver code that it's used to work
around (e.g. custom init script to toggle enable lines of some radio
chips).

> This patch series solves both problems by performing the external
> signal => GPIO mapping in the device tree.

As Rob already mentioned, what we want is some way to declare pin
functions. These could then be requested from userspace (or used in DT,
something which should allow for further refactoring there as well)
unless a driver has already claimed them.

We don't want to add more dependencies on the current sysfs-based
interface, which I hope we'll one day will be able to retire in favour
of a more sane one.

Johan

[PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
> Currently the gpio sysfs interface allows userspace to access simple hardware
> where no kernel driver exists or would be useful.
> 
> However it requires userspace to know the gpio number that has been assigned
> by the kernel.
> 
> That number, in the case of gpio drviers using dynamic allocation, is not fixed,
> and may change when:
> * The kernel version changes and ARCH_NR_GPIOS is changed (happened in 3.17)
> * The kernel version changes and probe order changes for gpio chips.
> * The kernel configuration is changed if CONFIG_ARCH_NR_GPIO is used
> * The board is redesigned (eg switching an externally visible signal from a
> SoC provided GPIO to an I2C expander chip or vice versa).
> * Other GPIO chips are added to the system.
> 
> The above means that, in order to export the GPIO to userspace via
> /sys/class/gpio/export the userspace code must know the exact hardware and
> kernel version information.

Not quite. You can still determine the gpio number in the above cases by
walking the sysfs tree to find the chip and it's base. This is the only
way to do this for dynamic buses such as USB.

The only case for which this fails is if a pin function is moved (e.g.
your i2c-expander case above).

> Furthermore, in many cases, it makes no sense to allow userspace to
> change the signal direction; even if the GPIO itself allows it the
> circuitry connected to the pin often does not (eg a signal dedicated
> to an output function driving a  transistor).

Indeed. The current sysfs-interface is a hack (which I personally think
never should have been merged).

Firmware should describe pin directionality and function, and undefined
pins should never be allowed to be accessed from userspace.

Sure, the current GPIO-sysfs-interface is useful during development and
for one-off hacks, but I'm convinced it's detrimental in the long run as
it removes the incentives to fix the driver code that it's used to work
around (e.g. custom init script to toggle enable lines of some radio
chips).

> This patch series solves both problems by performing the external
> signal => GPIO mapping in the device tree.

As Rob already mentioned, what we want is some way to declare pin
functions. These could then be requested from userspace (or used in DT,
something which should allow for further refactoring there as well)
unless a driver has already claimed them.

We don't want to add more dependencies on the current sysfs-based
interface, which I hope we'll one day will be able to retire in favour
of a more sane one.

Johan

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Linus Walleij]

On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@kernel.org> wrote:
> On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:

>> The above means that, in order to export the GPIO to userspace via
>> /sys/class/gpio/export the userspace code must know the exact hardware and
>> kernel version information.
>
> Not quite. You can still determine the gpio number in the above cases by
> walking the sysfs tree to find the chip and it's base. This is the only
> way to do this for dynamic buses such as USB.

Maybe we should start providing something like an
"lsgpio" utility in tools/gpio to do this, just as a hint
to userspace people on how things should be done.

>> This patch series solves both problems by performing the external
>> signal => GPIO mapping in the device tree.
>
> As Rob already mentioned, what we want is some way to declare pin
> functions. These could then be requested from userspace (or used in DT,
> something which should allow for further refactoring there as well)
> unless a driver has already claimed them.

We have the ability to name the GPIO lines (I usually refer to
lines rather than pins, as pins are physical and not all GPIOs
are, actually) using the array "names" in struct gpio_chip,
however this has no DT binding, so maybe people should
work on that. These names appear as named line files
in sysfs IIRC. Or maybe you're thinking of something else?

> We don't want to add more dependencies on the current sysfs-based
> interface, which I hope we'll one day will be able to retire in favour
> of a more sane one.

Agree.

Yours,
Linus Walleij

[PATCH 0/2] gpio: Allow userspace export from DT

[Linus Walleij]

On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@kernel.org> wrote:
> On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:

>> The above means that, in order to export the GPIO to userspace via
>> /sys/class/gpio/export the userspace code must know the exact hardware and
>> kernel version information.
>
> Not quite. You can still determine the gpio number in the above cases by
> walking the sysfs tree to find the chip and it's base. This is the only
> way to do this for dynamic buses such as USB.

Maybe we should start providing something like an
"lsgpio" utility in tools/gpio to do this, just as a hint
to userspace people on how things should be done.

>> This patch series solves both problems by performing the external
>> signal => GPIO mapping in the device tree.
>
> As Rob already mentioned, what we want is some way to declare pin
> functions. These could then be requested from userspace (or used in DT,
> something which should allow for further refactoring there as well)
> unless a driver has already claimed them.

We have the ability to name the GPIO lines (I usually refer to
lines rather than pins, as pins are physical and not all GPIOs
are, actually) using the array "names" in struct gpio_chip,
however this has no DT binding, so maybe people should
work on that. These names appear as named line files
in sysfs IIRC. Or maybe you're thinking of something else?

> We don't want to add more dependencies on the current sysfs-based
> interface, which I hope we'll one day will be able to retire in favour
> of a more sane one.

Agree.

Yours,
Linus Walleij

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Wed, May 06, 2015 at 09:22:22AM +0200, Linus Walleij wrote:
> On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@kernel.org> wrote:
> > On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
> 
> >> The above means that, in order to export the GPIO to userspace via
> >> /sys/class/gpio/export the userspace code must know the exact hardware and
> >> kernel version information.
> >
> > Not quite. You can still determine the gpio number in the above cases by
> > walking the sysfs tree to find the chip and it's base. This is the only
> > way to do this for dynamic buses such as USB.
> 
> Maybe we should start providing something like an
> "lsgpio" utility in tools/gpio to do this, just as a hint
> to userspace people on how things should be done.

I think we should focus on defining a new user-space interface rather
than make it easier to use the current one (it should really only be
used for development or one-off hacks IMO).

> >> This patch series solves both problems by performing the external
> >> signal => GPIO mapping in the device tree.
> >
> > As Rob already mentioned, what we want is some way to declare pin
> > functions. These could then be requested from userspace (or used in DT,
> > something which should allow for further refactoring there as well)
> > unless a driver has already claimed them.
> 
> We have the ability to name the GPIO lines (I usually refer to
> lines rather than pins, as pins are physical and not all GPIOs
> are, actually) using the array "names" in struct gpio_chip,
> however this has no DT binding, so maybe people should
> work on that. These names appear as named line files
> in sysfs IIRC. Or maybe you're thinking of something else?

Yes, something like that. As you mention above, if it was possibly to
define those names in firmware, even the current sysfs interface would
expose the pins as

	/sys/class/gpio/<function>

rather than say /sys/class/gpio/gpio279, thereby solving the gpio-number
look-up issue. Well, to actually make the pin available *from* userspace
you'd currently still need the number...

Johan

[PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Wed, May 06, 2015 at 09:22:22AM +0200, Linus Walleij wrote:
> On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@kernel.org> wrote:
> > On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
> 
> >> The above means that, in order to export the GPIO to userspace via
> >> /sys/class/gpio/export the userspace code must know the exact hardware and
> >> kernel version information.
> >
> > Not quite. You can still determine the gpio number in the above cases by
> > walking the sysfs tree to find the chip and it's base. This is the only
> > way to do this for dynamic buses such as USB.
> 
> Maybe we should start providing something like an
> "lsgpio" utility in tools/gpio to do this, just as a hint
> to userspace people on how things should be done.

I think we should focus on defining a new user-space interface rather
than make it easier to use the current one (it should really only be
used for development or one-off hacks IMO).

> >> This patch series solves both problems by performing the external
> >> signal => GPIO mapping in the device tree.
> >
> > As Rob already mentioned, what we want is some way to declare pin
> > functions. These could then be requested from userspace (or used in DT,
> > something which should allow for further refactoring there as well)
> > unless a driver has already claimed them.
> 
> We have the ability to name the GPIO lines (I usually refer to
> lines rather than pins, as pins are physical and not all GPIOs
> are, actually) using the array "names" in struct gpio_chip,
> however this has no DT binding, so maybe people should
> work on that. These names appear as named line files
> in sysfs IIRC. Or maybe you're thinking of something else?

Yes, something like that. As you mention above, if it was possibly to
define those names in firmware, even the current sysfs interface would
expose the pins as

	/sys/class/gpio/<function>

rather than say /sys/class/gpio/gpio279, thereby solving the gpio-number
look-up issue. Well, to actually make the pin available *from* userspace
you'd currently still need the number...

Johan

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Fuzzey, Martin]

On 6 May 2015 at 15:06, Johan Hovold <johan@kernel.org> wrote:
>
> On Wed, May 06, 2015 at 09:22:22AM +0200, Linus Walleij wrote:
> > On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@kernel.org> wrote:
> > > On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
> >
> > >> The above means that, in order to export the GPIO to userspace via
> > >> /sys/class/gpio/export the userspace code must know the exact hardware and
> > >> kernel version information.
> > >
> > > Not quite. You can still determine the gpio number in the above cases by
> > > walking the sysfs tree to find the chip and it's base. This is the only
> > > way to do this for dynamic buses such as USB.
> >

A problem with that is that the "label" sysfs attribute is not
necessarilly unique (and is even documented as being non unique).
Many drivers just use the chip name as the label so if you have more
than one of them...

Of course if you know the bus and bus address it is possible to find
the associated GPIO base but why should userspace have to know that?
Isn't the whole point of the DT to describe such hardware details?

> > Maybe we should start providing something like an
> > "lsgpio" utility in tools/gpio to do this, just as a hint
> > to userspace people on how things should be done.
>
> I think we should focus on defining a new user-space interface rather
> than make it easier to use the current one (it should really only be
> used for development or one-off hacks IMO).
>

Doesn't the ability to name GPIOs, fix their direction, and "pre
export" them  in the device tree remove most of the warts of the
current interface? (for GPIOs for which it is used in any case)

While I agree that the sysfs GPIO interface is sometimes abused (such
as for LEDs and switches which already have proper kernel drivers)
there are still cases where a full kernel driver doesn't really make
sense (eg a signal to open a parking barrier) - is anyone suggesting
this needs a custom driver or that the LED one should be used  -
setting the heartbeat trigger on that would be interesting .... :)

> > >> This patch series solves both problems by performing the external
> > >> signal => GPIO mapping in the device tree.
> > >
> > > As Rob already mentioned, what we want is some way to declare pin
> > > functions. These could then be requested from userspace (or used in DT,
> > > something which should allow for further refactoring there as well)
> > > unless a driver has already claimed them.
> >
> > We have the ability to name the GPIO lines (I usually refer to
> > lines rather than pins, as pins are physical and not all GPIOs
> > are, actually) using the array "names" in struct gpio_chip,
> > however this has no DT binding, so maybe people should
> > work on that. These names appear as named line files
> > in sysfs IIRC. Or maybe you're thinking of something else?
>

>
> Yes, something like that. As you mention above, if it was possibly to
> define those names in firmware, even the current sysfs interface would
> expose the pins as
>
>         /sys/class/gpio/<function>
>
> rather than say /sys/class/gpio/gpio279, thereby solving the gpio-number
> look-up issue. Well, to actually make the pin available *from* userspace
> you'd currently still need the number...
>
Indeed that  doesn't solve the how to export it problem.
AFAICT nothing is visible in sysfs until the export has been done.

Martin



-- 
-- 
Martin Fuzzey | Software Expertise
Parc La Fayette - 6 rue Isaac Newton - 25075 Besançon - FR
+33381546880 | +33677158582
mfuzzey@parkeon.com | www.parkeon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] gpio: Allow userspace export from DT

[Fuzzey, Martin]

On 6 May 2015 at 15:06, Johan Hovold <johan@kernel.org> wrote:
>
> On Wed, May 06, 2015 at 09:22:22AM +0200, Linus Walleij wrote:
> > On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@kernel.org> wrote:
> > > On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
> >
> > >> The above means that, in order to export the GPIO to userspace via
> > >> /sys/class/gpio/export the userspace code must know the exact hardware and
> > >> kernel version information.
> > >
> > > Not quite. You can still determine the gpio number in the above cases by
> > > walking the sysfs tree to find the chip and it's base. This is the only
> > > way to do this for dynamic buses such as USB.
> >

A problem with that is that the "label" sysfs attribute is not
necessarilly unique (and is even documented as being non unique).
Many drivers just use the chip name as the label so if you have more
than one of them...

Of course if you know the bus and bus address it is possible to find
the associated GPIO base but why should userspace have to know that?
Isn't the whole point of the DT to describe such hardware details?

> > Maybe we should start providing something like an
> > "lsgpio" utility in tools/gpio to do this, just as a hint
> > to userspace people on how things should be done.
>
> I think we should focus on defining a new user-space interface rather
> than make it easier to use the current one (it should really only be
> used for development or one-off hacks IMO).
>

Doesn't the ability to name GPIOs, fix their direction, and "pre
export" them  in the device tree remove most of the warts of the
current interface? (for GPIOs for which it is used in any case)

While I agree that the sysfs GPIO interface is sometimes abused (such
as for LEDs and switches which already have proper kernel drivers)
there are still cases where a full kernel driver doesn't really make
sense (eg a signal to open a parking barrier) - is anyone suggesting
this needs a custom driver or that the LED one should be used  -
setting the heartbeat trigger on that would be interesting .... :)

> > >> This patch series solves both problems by performing the external
> > >> signal => GPIO mapping in the device tree.
> > >
> > > As Rob already mentioned, what we want is some way to declare pin
> > > functions. These could then be requested from userspace (or used in DT,
> > > something which should allow for further refactoring there as well)
> > > unless a driver has already claimed them.
> >
> > We have the ability to name the GPIO lines (I usually refer to
> > lines rather than pins, as pins are physical and not all GPIOs
> > are, actually) using the array "names" in struct gpio_chip,
> > however this has no DT binding, so maybe people should
> > work on that. These names appear as named line files
> > in sysfs IIRC. Or maybe you're thinking of something else?
>

>
> Yes, something like that. As you mention above, if it was possibly to
> define those names in firmware, even the current sysfs interface would
> expose the pins as
>
>         /sys/class/gpio/<function>
>
> rather than say /sys/class/gpio/gpio279, thereby solving the gpio-number
> look-up issue. Well, to actually make the pin available *from* userspace
> you'd currently still need the number...
>
Indeed that  doesn't solve the how to export it problem.
AFAICT nothing is visible in sysfs until the export has been done.

Martin



-- 
-- 
Martin Fuzzey | Software Expertise
Parc La Fayette - 6 rue Isaac Newton - 25075 Besan?on - FR
+33381546880 | +33677158582
mfuzzey at parkeon.com | www.parkeon.com

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Wed, May 06, 2015 at 07:56:05PM +0200, Fuzzey, Martin wrote:
> On 6 May 2015 at 15:06, Johan Hovold <johan@kernel.org> wrote:
> > On Wed, May 06, 2015 at 09:22:22AM +0200, Linus Walleij wrote:
> > > On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@kernel.org> wrote:
> > > > On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
> > >
> > > >> The above means that, in order to export the GPIO to userspace via
> > > >> /sys/class/gpio/export the userspace code must know the exact hardware and
> > > >> kernel version information.
> > > >
> > > > Not quite. You can still determine the gpio number in the above cases by
> > > > walking the sysfs tree to find the chip and it's base. This is the only
> > > > way to do this for dynamic buses such as USB.
> > >
> 
> A problem with that is that the "label" sysfs attribute is not
> necessarilly unique (and is even documented as being non unique).
> Many drivers just use the chip name as the label so if you have more
> than one of them...
> 
> Of course if you know the bus and bus address it is possible to find
> the associated GPIO base but why should userspace have to know that?
> Isn't the whole point of the DT to describe such hardware details?

Yes, eventually, but the current gpio sysfs-interface does not allow for
that information to be confined to DT. It has always required knowledge
of the hardware (e.g. the pin numbers), but people eventually discovered
that those numbers may actually change.

I'm only pointing out that *that* particular quirk can be worked around
by providing different information about the hardware (e.g. the bus
topology).

IMO, the current interface should remain to be a pain to use so that
people either fix the drivers or start working on a replacement
user-space interface.

> > > Maybe we should start providing something like an
> > > "lsgpio" utility in tools/gpio to do this, just as a hint
> > > to userspace people on how things should be done.
> >
> > I think we should focus on defining a new user-space interface rather
> > than make it easier to use the current one (it should really only be
> > used for development or one-off hacks IMO).
> >
> Doesn't the ability to name GPIOs, fix their direction, and "pre
> export" them  in the device tree remove most of the warts of the
> current interface? (for GPIOs for which it is used in any case)

I agree with you that such properties (e.g. direction and function)
should be defined in DT. A gpio should not be exported until requested
by userspace though. This allow for the case where a userspace driver
can be used as a fall back if a kernel driver isn't available or loaded.

> > > >> This patch series solves both problems by performing the external
> > > >> signal => GPIO mapping in the device tree.
> > > >
> > > > As Rob already mentioned, what we want is some way to declare pin
> > > > functions. These could then be requested from userspace (or used in DT,
> > > > something which should allow for further refactoring there as well)
> > > > unless a driver has already claimed them.
> > >
> > > We have the ability to name the GPIO lines (I usually refer to
> > > lines rather than pins, as pins are physical and not all GPIOs
> > > are, actually) using the array "names" in struct gpio_chip,
> > > however this has no DT binding, so maybe people should
> > > work on that. These names appear as named line files
> > > in sysfs IIRC. Or maybe you're thinking of something else?
> >
> > Yes, something like that. As you mention above, if it was possibly to
> > define those names in firmware, even the current sysfs interface would
> > expose the pins as
> >
> >         /sys/class/gpio/<function>
> >
> > rather than say /sys/class/gpio/gpio279, thereby solving the gpio-number
> > look-up issue. Well, to actually make the pin available *from* userspace
> > you'd currently still need the number...
> >
> Indeed that  doesn't solve the how to export it problem.
> AFAICT nothing is visible in sysfs until the export has been done.

That will be solved by the new userspace interface. ;)

Johan

[PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Wed, May 06, 2015 at 07:56:05PM +0200, Fuzzey, Martin wrote:
> On 6 May 2015 at 15:06, Johan Hovold <johan@kernel.org> wrote:
> > On Wed, May 06, 2015 at 09:22:22AM +0200, Linus Walleij wrote:
> > > On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@kernel.org> wrote:
> > > > On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
> > >
> > > >> The above means that, in order to export the GPIO to userspace via
> > > >> /sys/class/gpio/export the userspace code must know the exact hardware and
> > > >> kernel version information.
> > > >
> > > > Not quite. You can still determine the gpio number in the above cases by
> > > > walking the sysfs tree to find the chip and it's base. This is the only
> > > > way to do this for dynamic buses such as USB.
> > >
> 
> A problem with that is that the "label" sysfs attribute is not
> necessarilly unique (and is even documented as being non unique).
> Many drivers just use the chip name as the label so if you have more
> than one of them...
> 
> Of course if you know the bus and bus address it is possible to find
> the associated GPIO base but why should userspace have to know that?
> Isn't the whole point of the DT to describe such hardware details?

Yes, eventually, but the current gpio sysfs-interface does not allow for
that information to be confined to DT. It has always required knowledge
of the hardware (e.g. the pin numbers), but people eventually discovered
that those numbers may actually change.

I'm only pointing out that *that* particular quirk can be worked around
by providing different information about the hardware (e.g. the bus
topology).

IMO, the current interface should remain to be a pain to use so that
people either fix the drivers or start working on a replacement
user-space interface.

> > > Maybe we should start providing something like an
> > > "lsgpio" utility in tools/gpio to do this, just as a hint
> > > to userspace people on how things should be done.
> >
> > I think we should focus on defining a new user-space interface rather
> > than make it easier to use the current one (it should really only be
> > used for development or one-off hacks IMO).
> >
> Doesn't the ability to name GPIOs, fix their direction, and "pre
> export" them  in the device tree remove most of the warts of the
> current interface? (for GPIOs for which it is used in any case)

I agree with you that such properties (e.g. direction and function)
should be defined in DT. A gpio should not be exported until requested
by userspace though. This allow for the case where a userspace driver
can be used as a fall back if a kernel driver isn't available or loaded.

> > > >> This patch series solves both problems by performing the external
> > > >> signal => GPIO mapping in the device tree.
> > > >
> > > > As Rob already mentioned, what we want is some way to declare pin
> > > > functions. These could then be requested from userspace (or used in DT,
> > > > something which should allow for further refactoring there as well)
> > > > unless a driver has already claimed them.
> > >
> > > We have the ability to name the GPIO lines (I usually refer to
> > > lines rather than pins, as pins are physical and not all GPIOs
> > > are, actually) using the array "names" in struct gpio_chip,
> > > however this has no DT binding, so maybe people should
> > > work on that. These names appear as named line files
> > > in sysfs IIRC. Or maybe you're thinking of something else?
> >
> > Yes, something like that. As you mention above, if it was possibly to
> > define those names in firmware, even the current sysfs interface would
> > expose the pins as
> >
> >         /sys/class/gpio/<function>
> >
> > rather than say /sys/class/gpio/gpio279, thereby solving the gpio-number
> > look-up issue. Well, to actually make the pin available *from* userspace
> > you'd currently still need the number...
> >
> Indeed that  doesn't solve the how to export it problem.
> AFAICT nothing is visible in sysfs until the export has been done.

That will be solved by the new userspace interface. ;)

Johan

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Rob Herring]

On Wed, May 6, 2015 at 2:22 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, May 4, 2015 at 10:49 AM, Johan Hovold <johan@kernel.org> wrote:
>> On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
>
>>> The above means that, in order to export the GPIO to userspace via
>>> /sys/class/gpio/export the userspace code must know the exact hardware and
>>> kernel version information.
>>
>> Not quite. You can still determine the gpio number in the above cases by
>> walking the sysfs tree to find the chip and it's base. This is the only
>> way to do this for dynamic buses such as USB.
>
> Maybe we should start providing something like an
> "lsgpio" utility in tools/gpio to do this, just as a hint
> to userspace people on how things should be done.
>
>>> This patch series solves both problems by performing the external
>>> signal => GPIO mapping in the device tree.
>>
>> As Rob already mentioned, what we want is some way to declare pin
>> functions. These could then be requested from userspace (or used in DT,
>> something which should allow for further refactoring there as well)
>> unless a driver has already claimed them.
>
> We have the ability to name the GPIO lines (I usually refer to
> lines rather than pins, as pins are physical and not all GPIOs
> are, actually) using the array "names" in struct gpio_chip,
> however this has no DT binding, so maybe people should
> work on that. These names appear as named line files
> in sysfs IIRC. Or maybe you're thinking of something else?

This problem is in many ways the similar to LEDs. 

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Russell King - ARM Linux]

On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
> Firmware should describe pin directionality and function, and undefined
> pins should never be allowed to be accessed from userspace.

No, that's totally wrong if you consider one of the most common use
cases out there...

Think about something like a Raspberry Pi, where you have a header with
GPIOs on it, which can be used for multiple different purposes (and are
even multiplexed with some on-SoC functions.)

"Firmware" can't know about all possible configurations of those IO pins.

That's why Raspberry Pi uses a userspace helper and programs stuff up
appropriately for the users application.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/2] gpio: Allow userspace export from DT

[Russell King - ARM Linux]

On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
> Firmware should describe pin directionality and function, and undefined
> pins should never be allowed to be accessed from userspace.

No, that's totally wrong if you consider one of the most common use
cases out there...

Think about something like a Raspberry Pi, where you have a header with
GPIOs on it, which can be used for multiple different purposes (and are
even multiplexed with some on-SoC functions.)

"Firmware" can't know about all possible configurations of those IO pins.

That's why Raspberry Pi uses a userspace helper and programs stuff up
appropriately for the users application.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Wed, May 06, 2015 at 12:24:50PM +0100, Russell King - ARM Linux wrote:
> On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
> > Firmware should describe pin directionality and function, and undefined
> > pins should never be allowed to be accessed from userspace.
> 
> No, that's totally wrong if you consider one of the most common use
> cases out there...
> 
> Think about something like a Raspberry Pi, where you have a header with
> GPIOs on it, which can be used for multiple different purposes (and are
> even multiplexed with some on-SoC functions.)
> 
> "Firmware" can't know about all possible configurations of those IO pins.
> 
> That's why Raspberry Pi uses a userspace helper and programs stuff up
> appropriately for the users application.

I'm not familiar with exactly how the RPi handles its pin muxing, but
even if it requires userspace interaction that should not prevent having
firmware describe the pins.

In general, if the hardware configuration is static we use device trees.

If the configuration is dynamic we use device-tree overlays; either
loaded manually or by some service (e.g. Beaglebone capes). Perhaps this
could be handled by the RPi helper.

And for experimentation / development, firmware could even be totally
non-restrictive by simply declaring generic pin "functions" like
"expansion-pin-4" and even allow for the direction to be changed.

Johan

[PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Wed, May 06, 2015 at 12:24:50PM +0100, Russell King - ARM Linux wrote:
> On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
> > Firmware should describe pin directionality and function, and undefined
> > pins should never be allowed to be accessed from userspace.
> 
> No, that's totally wrong if you consider one of the most common use
> cases out there...
> 
> Think about something like a Raspberry Pi, where you have a header with
> GPIOs on it, which can be used for multiple different purposes (and are
> even multiplexed with some on-SoC functions.)
> 
> "Firmware" can't know about all possible configurations of those IO pins.
> 
> That's why Raspberry Pi uses a userspace helper and programs stuff up
> appropriately for the users application.

I'm not familiar with exactly how the RPi handles its pin muxing, but
even if it requires userspace interaction that should not prevent having
firmware describe the pins.

In general, if the hardware configuration is static we use device trees.

If the configuration is dynamic we use device-tree overlays; either
loaded manually or by some service (e.g. Beaglebone capes). Perhaps this
could be handled by the RPi helper.

And for experimentation / development, firmware could even be totally
non-restrictive by simply declaring generic pin "functions" like
"expansion-pin-4" and even allow for the direction to be changed.

Johan

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Russell King - ARM Linux]

On Wed, May 06, 2015 at 02:43:54PM +0200, Johan Hovold wrote:
> On Wed, May 06, 2015 at 12:24:50PM +0100, Russell King - ARM Linux wrote:
> > On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
> > > Firmware should describe pin directionality and function, and undefined
> > > pins should never be allowed to be accessed from userspace.
> > 
> > No, that's totally wrong if you consider one of the most common use
> > cases out there...
> > 
> > Think about something like a Raspberry Pi, where you have a header with
> > GPIOs on it, which can be used for multiple different purposes (and are
> > even multiplexed with some on-SoC functions.)
> > 
> > "Firmware" can't know about all possible configurations of those IO pins.
> > 
> > That's why Raspberry Pi uses a userspace helper and programs stuff up
> > appropriately for the users application.
> 
> I'm not familiar with exactly how the RPi handles its pin muxing, but
> even if it requires userspace interaction that should not prevent having
> firmware describe the pins.

How it handles this is... it doesn't.  Userspace does it.

There is *no* "firmware" on these devices.  The only thing you have is a
boot loader and a DT blob, and people will hate you if you tell them that
they have to change the DT blob and then reboot their systems to change
the functionality of a GPIO pin.

It's also entirely reasonable to assume that people are going to want to
change the configuration at runtime, given their diverse range of
applications.

> In general, if the hardware configuration is static we use device trees.
> 
> If the configuration is dynamic we use device-tree overlays; either
> loaded manually or by some service (e.g. Beaglebone capes). Perhaps this
> could be handled by the RPi helper.

Yes, that _could_ work, but I bet asking millions of people to change
what they're doing is going to be extremely difficult.  Remember the
golden rule of the kernel: thou shalt not break userspace.

So, there is _no_ possibility of removing this GPIO exposure to userspace
because we _know_ that it will break people.

If you think differently on the "thou shalt not break userspace" please
don't discuss it with me, I'm not interested.  Linus isn't interested
either, and if you try and discuss it with him, he'll tell you to get
out of kernel programming. :)

This is a commonly used API.  You can't change it.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/2] gpio: Allow userspace export from DT

[Russell King - ARM Linux]

On Wed, May 06, 2015 at 02:43:54PM +0200, Johan Hovold wrote:
> On Wed, May 06, 2015 at 12:24:50PM +0100, Russell King - ARM Linux wrote:
> > On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
> > > Firmware should describe pin directionality and function, and undefined
> > > pins should never be allowed to be accessed from userspace.
> > 
> > No, that's totally wrong if you consider one of the most common use
> > cases out there...
> > 
> > Think about something like a Raspberry Pi, where you have a header with
> > GPIOs on it, which can be used for multiple different purposes (and are
> > even multiplexed with some on-SoC functions.)
> > 
> > "Firmware" can't know about all possible configurations of those IO pins.
> > 
> > That's why Raspberry Pi uses a userspace helper and programs stuff up
> > appropriately for the users application.
> 
> I'm not familiar with exactly how the RPi handles its pin muxing, but
> even if it requires userspace interaction that should not prevent having
> firmware describe the pins.

How it handles this is... it doesn't.  Userspace does it.

There is *no* "firmware" on these devices.  The only thing you have is a
boot loader and a DT blob, and people will hate you if you tell them that
they have to change the DT blob and then reboot their systems to change
the functionality of a GPIO pin.

It's also entirely reasonable to assume that people are going to want to
change the configuration at runtime, given their diverse range of
applications.

> In general, if the hardware configuration is static we use device trees.
> 
> If the configuration is dynamic we use device-tree overlays; either
> loaded manually or by some service (e.g. Beaglebone capes). Perhaps this
> could be handled by the RPi helper.

Yes, that _could_ work, but I bet asking millions of people to change
what they're doing is going to be extremely difficult.  Remember the
golden rule of the kernel: thou shalt not break userspace.

So, there is _no_ possibility of removing this GPIO exposure to userspace
because we _know_ that it will break people.

If you think differently on the "thou shalt not break userspace" please
don't discuss it with me, I'm not interested.  Linus isn't interested
either, and if you try and discuss it with him, he'll tell you to get
out of kernel programming. :)

This is a commonly used API.  You can't change it.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Wed, May 06, 2015 at 01:57:08PM +0100, Russell King - ARM Linux wrote:
> On Wed, May 06, 2015 at 02:43:54PM +0200, Johan Hovold wrote:
> > On Wed, May 06, 2015 at 12:24:50PM +0100, Russell King - ARM Linux wrote:
> > > On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
> > > > Firmware should describe pin directionality and function, and undefined
> > > > pins should never be allowed to be accessed from userspace.
> > > 
> > > No, that's totally wrong if you consider one of the most common use
> > > cases out there...
> > > 
> > > Think about something like a Raspberry Pi, where you have a header with
> > > GPIOs on it, which can be used for multiple different purposes (and are
> > > even multiplexed with some on-SoC functions.)
> > > 
> > > "Firmware" can't know about all possible configurations of those IO pins.
> > > 
> > > That's why Raspberry Pi uses a userspace helper and programs stuff up
> > > appropriately for the users application.
> > 
> > I'm not familiar with exactly how the RPi handles its pin muxing, but
> > even if it requires userspace interaction that should not prevent having
> > firmware describe the pins.
> 
> How it handles this is... it doesn't.  Userspace does it.
> 
> There is *no* "firmware" on these devices.  The only thing you have is a
> boot loader and a DT blob, and people will hate you if you tell them that
> they have to change the DT blob and then reboot their systems to change
> the functionality of a GPIO pin.
>
> It's also entirely reasonable to assume that people are going to want to
> change the configuration at runtime, given their diverse range of
> applications.

DT can be changed at run-time using overlays.

This way the RPi users could define their i2c-clients, or whatever buses
they choose to expose on those pins as well.

> > In general, if the hardware configuration is static we use device trees.
> > 
> > If the configuration is dynamic we use device-tree overlays; either
> > loaded manually or by some service (e.g. Beaglebone capes). Perhaps this
> > could be handled by the RPi helper.
> 
> Yes, that _could_ work, but I bet asking millions of people to change
> what they're doing is going to be extremely difficult.  Remember the
> golden rule of the kernel: thou shalt not break userspace.
> 
> So, there is _no_ possibility of removing this GPIO exposure to userspace
> because we _know_ that it will break people.
> 
> If you think differently on the "thou shalt not break userspace" please
> don't discuss it with me, I'm not interested.  Linus isn't interested
> either, and if you try and discuss it with him, he'll tell you to get
> out of kernel programming. :)
> 
> This is a commonly used API.  You can't change it.

I've never suggested that we remove the current API, but *only* exposing
a totally non-restrictive interface for systems not used by school
children and hardware hackers is not sane.

You also cut out the part in my reply about continuing to allow
unrestricted access for such cases. That could still continue to be the
default (e.g. when there are no pin function names defined in DT).

And if those people ever update their DTs they could benefit from the
deterministic pin naming without loosing any flexibility too.

Johan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Wed, May 06, 2015 at 01:57:08PM +0100, Russell King - ARM Linux wrote:
> On Wed, May 06, 2015 at 02:43:54PM +0200, Johan Hovold wrote:
> > On Wed, May 06, 2015 at 12:24:50PM +0100, Russell King - ARM Linux wrote:
> > > On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
> > > > Firmware should describe pin directionality and function, and undefined
> > > > pins should never be allowed to be accessed from userspace.
> > > 
> > > No, that's totally wrong if you consider one of the most common use
> > > cases out there...
> > > 
> > > Think about something like a Raspberry Pi, where you have a header with
> > > GPIOs on it, which can be used for multiple different purposes (and are
> > > even multiplexed with some on-SoC functions.)
> > > 
> > > "Firmware" can't know about all possible configurations of those IO pins.
> > > 
> > > That's why Raspberry Pi uses a userspace helper and programs stuff up
> > > appropriately for the users application.
> > 
> > I'm not familiar with exactly how the RPi handles its pin muxing, but
> > even if it requires userspace interaction that should not prevent having
> > firmware describe the pins.
> 
> How it handles this is... it doesn't.  Userspace does it.
> 
> There is *no* "firmware" on these devices.  The only thing you have is a
> boot loader and a DT blob, and people will hate you if you tell them that
> they have to change the DT blob and then reboot their systems to change
> the functionality of a GPIO pin.
>
> It's also entirely reasonable to assume that people are going to want to
> change the configuration at runtime, given their diverse range of
> applications.

DT can be changed at run-time using overlays.

This way the RPi users could define their i2c-clients, or whatever buses
they choose to expose on those pins as well.

> > In general, if the hardware configuration is static we use device trees.
> > 
> > If the configuration is dynamic we use device-tree overlays; either
> > loaded manually or by some service (e.g. Beaglebone capes). Perhaps this
> > could be handled by the RPi helper.
> 
> Yes, that _could_ work, but I bet asking millions of people to change
> what they're doing is going to be extremely difficult.  Remember the
> golden rule of the kernel: thou shalt not break userspace.
> 
> So, there is _no_ possibility of removing this GPIO exposure to userspace
> because we _know_ that it will break people.
> 
> If you think differently on the "thou shalt not break userspace" please
> don't discuss it with me, I'm not interested.  Linus isn't interested
> either, and if you try and discuss it with him, he'll tell you to get
> out of kernel programming. :)
> 
> This is a commonly used API.  You can't change it.

I've never suggested that we remove the current API, but *only* exposing
a totally non-restrictive interface for systems not used by school
children and hardware hackers is not sane.

You also cut out the part in my reply about continuing to allow
unrestricted access for such cases. That could still continue to be the
default (e.g. when there are no pin function names defined in DT).

And if those people ever update their DTs they could benefit from the
deterministic pin naming without loosing any flexibility too.

Johan

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Jiří Prchal]

On 6.5.2015 15:25, Johan Hovold wrote:
> On Wed, May 06, 2015 at 01:57:08PM +0100, Russell King - ARM Linux wrote:
>> On Wed, May 06, 2015 at 02:43:54PM +0200, Johan Hovold wrote:
>>> On Wed, May 06, 2015 at 12:24:50PM +0100, Russell King - ARM Linux wrote:
>>>> On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
>>>>> Firmware should describe pin directionality and function, and undefined
>>>>> pins should never be allowed to be accessed from userspace.
>>>>
>>>> No, that's totally wrong if you consider one of the most common use
>>>> cases out there...
>>>>
>>>> Think about something like a Raspberry Pi, where you have a header with
>>>> GPIOs on it, which can be used for multiple different purposes (and are
>>>> even multiplexed with some on-SoC functions.)
>>>>
>>>> "Firmware" can't know about all possible configurations of those IO pins.
>>>>
>>>> That's why Raspberry Pi uses a userspace helper and programs stuff up
>>>> appropriately for the users application.
>>>
>>> I'm not familiar with exactly how the RPi handles its pin muxing, but
>>> even if it requires userspace interaction that should not prevent having
>>> firmware describe the pins.
>>
>> How it handles this is... it doesn't.  Userspace does it.
>>
>> There is *no* "firmware" on these devices.  The only thing you have is a
>> boot loader and a DT blob, and people will hate you if you tell them that
>> they have to change the DT blob and then reboot their systems to change
>> the functionality of a GPIO pin.
>>
>> It's also entirely reasonable to assume that people are going to want to
>> change the configuration at runtime, given their diverse range of
>> applications.
>
> DT can be changed at run-time using overlays.
>
> This way the RPi users could define their i2c-clients, or whatever buses
> they choose to expose on those pins as well.
>
>>> In general, if the hardware configuration is static we use device trees.
>>>
>>> If the configuration is dynamic we use device-tree overlays; either
>>> loaded manually or by some service (e.g. Beaglebone capes). Perhaps this
>>> could be handled by the RPi helper.
>>
>> Yes, that _could_ work, but I bet asking millions of people to change
>> what they're doing is going to be extremely difficult.  Remember the
>> golden rule of the kernel: thou shalt not break userspace.
>>
>> So, there is _no_ possibility of removing this GPIO exposure to userspace
>> because we _know_ that it will break people.
>>
>> If you think differently on the "thou shalt not break userspace" please
>> don't discuss it with me, I'm not interested.  Linus isn't interested
>> either, and if you try and discuss it with him, he'll tell you to get
>> out of kernel programming. :)
>>
>> This is a commonly used API.  You can't change it.
>
> I've never suggested that we remove the current API, but *only* exposing
> a totally non-restrictive interface for systems not used by school
> children and hardware hackers is not sane.
>
> You also cut out the part in my reply about continuing to allow
> unrestricted access for such cases. That could still continue to be the
> default (e.g. when there are no pin function names defined in DT).
>
> And if those people ever update their DTs they could benefit from the
> deterministic pin naming without loosing any flexibility too.

Just to not let Johan alone:
I totally agree with Johan and looking for this export for at least 2 years.
Jiri

>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[PATCH 0/2] gpio: Allow userspace export from DT

[Jiří Prchal]

On 6.5.2015 15:25, Johan Hovold wrote:
> On Wed, May 06, 2015 at 01:57:08PM +0100, Russell King - ARM Linux wrote:
>> On Wed, May 06, 2015 at 02:43:54PM +0200, Johan Hovold wrote:
>>> On Wed, May 06, 2015 at 12:24:50PM +0100, Russell King - ARM Linux wrote:
>>>> On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
>>>>> Firmware should describe pin directionality and function, and undefined
>>>>> pins should never be allowed to be accessed from userspace.
>>>>
>>>> No, that's totally wrong if you consider one of the most common use
>>>> cases out there...
>>>>
>>>> Think about something like a Raspberry Pi, where you have a header with
>>>> GPIOs on it, which can be used for multiple different purposes (and are
>>>> even multiplexed with some on-SoC functions.)
>>>>
>>>> "Firmware" can't know about all possible configurations of those IO pins.
>>>>
>>>> That's why Raspberry Pi uses a userspace helper and programs stuff up
>>>> appropriately for the users application.
>>>
>>> I'm not familiar with exactly how the RPi handles its pin muxing, but
>>> even if it requires userspace interaction that should not prevent having
>>> firmware describe the pins.
>>
>> How it handles this is... it doesn't.  Userspace does it.
>>
>> There is *no* "firmware" on these devices.  The only thing you have is a
>> boot loader and a DT blob, and people will hate you if you tell them that
>> they have to change the DT blob and then reboot their systems to change
>> the functionality of a GPIO pin.
>>
>> It's also entirely reasonable to assume that people are going to want to
>> change the configuration at runtime, given their diverse range of
>> applications.
>
> DT can be changed at run-time using overlays.
>
> This way the RPi users could define their i2c-clients, or whatever buses
> they choose to expose on those pins as well.
>
>>> In general, if the hardware configuration is static we use device trees.
>>>
>>> If the configuration is dynamic we use device-tree overlays; either
>>> loaded manually or by some service (e.g. Beaglebone capes). Perhaps this
>>> could be handled by the RPi helper.
>>
>> Yes, that _could_ work, but I bet asking millions of people to change
>> what they're doing is going to be extremely difficult.  Remember the
>> golden rule of the kernel: thou shalt not break userspace.
>>
>> So, there is _no_ possibility of removing this GPIO exposure to userspace
>> because we _know_ that it will break people.
>>
>> If you think differently on the "thou shalt not break userspace" please
>> don't discuss it with me, I'm not interested.  Linus isn't interested
>> either, and if you try and discuss it with him, he'll tell you to get
>> out of kernel programming. :)
>>
>> This is a commonly used API.  You can't change it.
>
> I've never suggested that we remove the current API, but *only* exposing
> a totally non-restrictive interface for systems not used by school
> children and hardware hackers is not sane.
>
> You also cut out the part in my reply about continuing to allow
> unrestricted access for such cases. That could still continue to be the
> default (e.g. when there are no pin function names defined in DT).
>
> And if those people ever update their DTs they could benefit from the
> deterministic pin naming without loosing any flexibility too.

Just to not let Johan alone:
I totally agree with Johan and looking for this export for at least 2 years.
Jiri

>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Russell King - ARM Linux]

On Wed, May 06, 2015 at 03:25:20PM +0200, Johan Hovold wrote:
> On Wed, May 06, 2015 at 01:57:08PM +0100, Russell King - ARM Linux wrote:
> > There is *no* "firmware" on these devices.  The only thing you have is a
> > boot loader and a DT blob, and people will hate you if you tell them that
> > they have to change the DT blob and then reboot their systems to change
> > the functionality of a GPIO pin.
> >
> > It's also entirely reasonable to assume that people are going to want to
> > change the configuration at runtime, given their diverse range of
> > applications.
> 
> DT can be changed at run-time using overlays.

Yes, I'm aware of that, but that code is really not nice.  There is no
notification system to drivers that something has changed, and with a
GPIO driver, you really don't want the driver to be unbound and
re-bound just because something changed.  That has the very real
possibility to disrupt users of other GPIOs.

I'm not sure what kind of driver you'd attach userspace GPIO pinctrl
settings to other than the GPIO driver.

Sure, if you're wanting to configure a couple of GPIOs as I2C, then
yes, you certainly should put the binding in the I2C device block in
DT, but you don't always have a device to do that with.

> You also cut out the part in my reply about continuing to allow
> unrestricted access for such cases. That could still continue to be the
> default (e.g. when there are no pin function names defined in DT).

Yes, that's standard Internet email etiquette - cut everything from
the message you're replying to which is not part of the context of the
immediate reply.  I'd include a URL to that, but unfortunately google
seems broken (it's inserting a refresh into the results page which causes
elinks to continually refetch the same page, eventually triggering a
violation of googles terms of use... yea, quite funny that google is
instructing browsers to violate their own terms of use.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] gpio: Allow userspace export from DT

[Russell King - ARM Linux]

On Wed, May 06, 2015 at 03:25:20PM +0200, Johan Hovold wrote:
> On Wed, May 06, 2015 at 01:57:08PM +0100, Russell King - ARM Linux wrote:
> > There is *no* "firmware" on these devices.  The only thing you have is a
> > boot loader and a DT blob, and people will hate you if you tell them that
> > they have to change the DT blob and then reboot their systems to change
> > the functionality of a GPIO pin.
> >
> > It's also entirely reasonable to assume that people are going to want to
> > change the configuration at runtime, given their diverse range of
> > applications.
> 
> DT can be changed at run-time using overlays.

Yes, I'm aware of that, but that code is really not nice.  There is no
notification system to drivers that something has changed, and with a
GPIO driver, you really don't want the driver to be unbound and
re-bound just because something changed.  That has the very real
possibility to disrupt users of other GPIOs.

I'm not sure what kind of driver you'd attach userspace GPIO pinctrl
settings to other than the GPIO driver.

Sure, if you're wanting to configure a couple of GPIOs as I2C, then
yes, you certainly should put the binding in the I2C device block in
DT, but you don't always have a device to do that with.

> You also cut out the part in my reply about continuing to allow
> unrestricted access for such cases. That could still continue to be the
> default (e.g. when there are no pin function names defined in DT).

Yes, that's standard Internet email etiquette - cut everything from
the message you're replying to which is not part of the context of the
immediate reply.  I'd include a URL to that, but unfortunately google
seems broken (it's inserting a refresh into the results page which causes
elinks to continually refetch the same page, eventually triggering a
violation of googles terms of use... yea, quite funny that google is
instructing browsers to violate their own terms of use.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Thu, May 07, 2015 at 01:28:40PM +0100, Russell King - ARM Linux wrote:
> On Wed, May 06, 2015 at 03:25:20PM +0200, Johan Hovold wrote:
> > On Wed, May 06, 2015 at 01:57:08PM +0100, Russell King - ARM Linux wrote:
> > > There is *no* "firmware" on these devices.  The only thing you have is a
> > > boot loader and a DT blob, and people will hate you if you tell them that
> > > they have to change the DT blob and then reboot their systems to change
> > > the functionality of a GPIO pin.
> > >
> > > It's also entirely reasonable to assume that people are going to want to
> > > change the configuration at runtime, given their diverse range of
> > > applications.
> > 
> > DT can be changed at run-time using overlays.
> 
> Yes, I'm aware of that, but that code is really not nice.  There is no
> notification system to drivers that something has changed, and with a
> GPIO driver, you really don't want the driver to be unbound and
> re-bound just because something changed.  That has the very real
> possibility to disrupt users of other GPIOs.

Yes, you'd need to configure your gpio chip before you start using it.

And for your RPi use case, things need not change much if the default
mode if undefined, or the default DT, continue to allow for full
flexibility.

But I imagine that even for such use cases some people will want to
configure pin directionality and default modes in DT (blob or overlay)
to limit potential damage from bugs in userspace applications.

And everyone should benefit from persistent, predictable pin names.

> > You also cut out the part in my reply about continuing to allow
> > unrestricted access for such cases. That could still continue to be the
> > default (e.g. when there are no pin function names defined in DT).
> 
> Yes, that's standard Internet email etiquette - cut everything from
> the message you're replying to which is not part of the context of the
> immediate reply.  I'd include a URL to that, but unfortunately google
> seems broken (it's inserting a refresh into the results page which causes
> elinks to continually refetch the same page, eventually triggering a
> violation of googles terms of use... yea, quite funny that google is
> instructing browsers to violate their own terms of use.)

Yes, but in this case you argued using an example that I had already
discussed in the part of the email that you left out (i.e. how to not
break userspace by continuing to allow full flexibility if desired).

Johan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] gpio: Allow userspace export from DT

[Johan Hovold]

On Thu, May 07, 2015 at 01:28:40PM +0100, Russell King - ARM Linux wrote:
> On Wed, May 06, 2015 at 03:25:20PM +0200, Johan Hovold wrote:
> > On Wed, May 06, 2015 at 01:57:08PM +0100, Russell King - ARM Linux wrote:
> > > There is *no* "firmware" on these devices.  The only thing you have is a
> > > boot loader and a DT blob, and people will hate you if you tell them that
> > > they have to change the DT blob and then reboot their systems to change
> > > the functionality of a GPIO pin.
> > >
> > > It's also entirely reasonable to assume that people are going to want to
> > > change the configuration at runtime, given their diverse range of
> > > applications.
> > 
> > DT can be changed at run-time using overlays.
> 
> Yes, I'm aware of that, but that code is really not nice.  There is no
> notification system to drivers that something has changed, and with a
> GPIO driver, you really don't want the driver to be unbound and
> re-bound just because something changed.  That has the very real
> possibility to disrupt users of other GPIOs.

Yes, you'd need to configure your gpio chip before you start using it.

And for your RPi use case, things need not change much if the default
mode if undefined, or the default DT, continue to allow for full
flexibility.

But I imagine that even for such use cases some people will want to
configure pin directionality and default modes in DT (blob or overlay)
to limit potential damage from bugs in userspace applications.

And everyone should benefit from persistent, predictable pin names.

> > You also cut out the part in my reply about continuing to allow
> > unrestricted access for such cases. That could still continue to be the
> > default (e.g. when there are no pin function names defined in DT).
> 
> Yes, that's standard Internet email etiquette - cut everything from
> the message you're replying to which is not part of the context of the
> immediate reply.  I'd include a URL to that, but unfortunately google
> seems broken (it's inserting a refresh into the results page which causes
> elinks to continually refetch the same page, eventually triggering a
> violation of googles terms of use... yea, quite funny that google is
> instructing browsers to violate their own terms of use.)

Yes, but in this case you argued using an example that I had already
discussed in the part of the email that you left out (i.e. how to not
break userspace by continuing to allow full flexibility if desired).

Johan