Re: [PATCH] gpio: add export with name from dts

Re: [PATCH] gpio: add export with name from dts

[Linus Walleij]

This patch must be CC to devicetree@vger.kernel.org as it concerns
device tree bindings. Please also keep Alexandre Courbot in the loop as
he's working on GPIO refactorings.

On Fri, Oct 11, 2013 at 12:05 PM, Jiri Prchal <jiri.prchal@aksignal.cz> wrote:

> Add export possibility to sysfs with given name in device tree.
> Rebased from older unapplyed patch: [PATCH] owrt: GPIO: add gpio_export_with_name.
>
> Signed-off-by: Jiri Prchal <jiri.prchal@aksignal.cz>

This is a very terse commit message for something which will have
a very drastic impact on the Linux kernel and device tree.

> +3) gpio-export
> +--------------
> +
> +gpio-export will allow you to automatically export gpio


What does this mean? You have to define all terms. And also consider the
audience. If someone is using device tree on Symbian or Windows,
what does "export" mean to them? Not all readers of this document
are Linux implementers.

> +required properties:
> +- compatible: Should be "gpio-export"

If this is a Linux-specific concept it should be named "linux-gpio-export"

But overall I'm not happy with this *at all* as the sysfs ABI is already
enough of a trouble for us. WIth platforms switching to DT-only
probing it would be perfect to get rid of this sysfs interface altogether.

Two questions:

- What do you think of the approach of just not using this for DT
  boots, instead we create a new userspace ABI, using e.g. a
  char device for each GPIO chip like /dev/gpio0, /dev/gpio1 etc
  and access these using ioctl:s?

- I guess you have a specific system in mind for this? What is the
  use case? I have seen *way* too many people trying to reimplement
  drivers/leds/leds-gpio.c
  drivers/input/keyboard/gpio_keys.c
  drivers/input/keyboard/gpio_keys_polled.c
  drivers/power/gpio-charger.c
  drivers/i2c/busses/i2c-gpio.c
  drivers/extcon/extcon-gpio.c
  drivers/spi/spi-gpio.c
  IN USERSPACE! JUST BECAUSE THEY CAN!

>From a kernel developers point of view the kernel shall handle
hardware, so that is why I'm quite picky about this.

Yours,
Linus Walleij

[PATCH] gpio: add export with name from dts

[Jiri Prchal]

Add export possibility to sysfs with given name in device tree.
Rebased from older unapplyed patch: [PATCH] owrt: GPIO: add gpio_export_with_name.

Signed-off-by: Jiri Prchal <jiri.prchal-cKCO0sOKHLPtwjQa/ONI9g@public.gmane.org>
---
 Documentation/devicetree/bindings/gpio/gpio.txt |   61 +++++++++++++++++++++++
 drivers/gpio/gpiolib-of.c                       |   61 +++++++++++++++++++++++
 drivers/gpio/gpiolib.c                          |   27 ++++++----
 include/asm-generic/gpio.h                      |    6 ++-
 include/linux/gpio.h                            |   23 ++++++++-
 5 files changed, 166 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 6cec6ff..03c4ef5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -117,3 +117,64 @@ Example:
 Here, a single GPIO controller has GPIOs 0..9 routed to pin controller
 pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's
 pins 50..59.
+
+
+3) gpio-export
+--------------
+
+gpio-export will allow you to automatically export gpio
+
+required properties:
+- compatible: Should be "gpio-export"
+
+in each child node will reprensent a gpio or if no name is specified
+a list of gpio to export
+
+required properties:
+- gpios: gpio to export
+
+optional properties:
+ - gpio-export,name: export name
+ - gpio-export,output: to set the as output with default value
+ 		       if no present gpio as input
+ - pio-export,direction_may_change: boolean to allow the direction to be controllable
+
+Example:
+
+
+gpio_export {
+	compatible = "gpio-export";
+	#size-cells = <0>;
+
+	in {
+		gpio-export,name = "in";
+		gpios = <&pioC 20 0>;
+	};
+
+	out {
+		gpio-export,name = "out";
+		gpio-export,output = <1>;
+		gpio-export,direction_may_change;
+		gpios = <&pioC 21 0>;
+	};
+
+	in_out {
+		gpio-export,name = "in_out";
+		gpio-export,direction_may_change;
+		gpios = <&pioC 21 0>;
+	};
+
+	gpios_in {
+		gpios = <&pioB 0 0
+			 &pioB 3 0
+			 &pioC 4 0>;
+		gpio-export,direction_may_change;
+	};
+
+	gpios_out {
+		gpios = <&pioB 1 0
+			 &pioB 2 0
+			 &pioC 3 0>;
+		gpio-export,output = <1>;
+	};
+};
\ No newline at end of file
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 0dfaf20..1a43d8b 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -21,6 +21,8 @@
 #include <linux/of_gpio.h>
 #include <linux/pinctrl/pinctrl.h>
 #include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
 
 /* Private data structure for of_gpiochip_find_and_xlate */
 struct gg_data {
@@ -243,3 +245,62 @@ void of_gpiochip_remove(struct gpio_chip *chip)
 	if (chip->of_node)
 		of_node_put(chip->of_node);
 }
+
+static struct of_device_id gpio_export_ids[] = {
+	{ .compatible = "gpio-export" },
+	{ /* sentinel */ }
+};
+
+static int __init of_gpio_export_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *cnp;
+	u32 val;
+	int nb = 0;
+
+	for_each_child_of_node(np, cnp) {
+		const char *name = NULL;
+		int gpio;
+		bool dmc;
+		int max_gpio = 1;
+		int i;
+
+		of_property_read_string(cnp, "gpio-export,name", &name);
+
+		if (!name)
+			max_gpio = of_gpio_count(cnp);
+
+		for (i = 0; i < max_gpio; i++) {
+			gpio = of_get_gpio(cnp, i);
+			if (devm_gpio_request(&pdev->dev, gpio, name ? name : of_node_full_name(np)))
+				continue;
+
+			if (!of_property_read_u32(cnp, "gpio-export,output", &val))
+				gpio_direction_output(gpio, val);
+			else
+				gpio_direction_input(gpio);
+
+			dmc = of_property_read_bool(np, "gpio-export,direction_may_change");
+			gpio_export_with_name(gpio, dmc, name);
+			nb++;
+		}
+	}
+
+	dev_info(&pdev->dev, "%d gpio(s) exported\n", nb);
+
+	return 0;
+}
+
+static struct platform_driver gpio_export_driver = {
+	.driver		= {
+		.name		= "gpio-export",
+		.owner	= THIS_MODULE,
+		.of_match_table	= of_match_ptr(gpio_export_ids),
+	},
+};
+
+static int __init of_gpio_export_init(void)
+{
+	return platform_driver_probe(&gpio_export_driver, of_gpio_export_probe);
+}
+device_initcall(of_gpio_export_init);
\ No newline at end of file
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 86ef346..c7494d1 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -96,7 +96,8 @@ static int gpiod_get_value(const struct gpio_desc *desc);
 static void gpiod_set_value(struct gpio_desc *desc, int value);
 static int gpiod_cansleep(const struct gpio_desc *desc);
 static int gpiod_to_irq(const struct gpio_desc *desc);
-static int gpiod_export(struct gpio_desc *desc, bool direction_may_change);
+static int gpiod_export_with_name(struct gpio_desc *desc,
+				  bool direction_may_change, const char *name);
 static int gpiod_export_link(struct device *dev, const char *name,
 			     struct gpio_desc *desc);
 static int gpiod_sysfs_set_active_low(struct gpio_desc *desc, int value);
@@ -674,7 +675,7 @@ static ssize_t export_store(struct class *class,
 			status = -ENODEV;
 		goto done;
 	}
-	status = gpiod_export(desc, true);
+	status = gpiod_export_with_name(desc, true, NULL);
 	if (status < 0)
 		gpiod_free(desc);
 	else
@@ -736,9 +737,10 @@ static struct class gpio_class = {
 
 
 /**
- * gpio_export - export a GPIO through sysfs
+ * gpiod_export_with_name - export a GPIO through sysfs
  * @gpio: gpio to make available, already requested
  * @direction_may_change: true if userspace may change gpio direction
+ * @name: gpio name
  * Context: arch_initcall or later
  *
  * When drivers want to make a GPIO accessible to userspace after they
@@ -750,7 +752,8 @@ static struct class gpio_class = {
  *
  * Returns zero on success, else an error.
  */
-static int gpiod_export(struct gpio_desc *desc, bool direction_may_change)
+int gpiod_export_with_name(struct gpio_desc *desc, bool direction_may_change,
+			  const char *name)
 {
 	unsigned long		flags;
 	int			status;
@@ -788,7 +791,9 @@ static int gpiod_export(struct gpio_desc *desc, bool direction_may_change)
 	spin_unlock_irqrestore(&gpio_lock, flags);
 
 	offset = gpio_chip_hwgpio(desc);
-	if (desc->chip->names && desc->chip->names[offset])
+	if (name)
+		ioname = name;
+	else if (desc->chip->names && desc->chip->names[offset])
 		ioname = desc->chip->names[offset];
 
 	dev = device_create(&gpio_class, desc->chip->dev, MKDEV(0, 0),
@@ -829,11 +834,13 @@ fail_unlock:
 	return status;
 }
 
-int gpio_export(unsigned gpio, bool direction_may_change)
+int gpio_export_with_name(unsigned gpio, bool direction_may_change,
+			  const char *name)
 {
-	return gpiod_export(gpio_to_desc(gpio), direction_may_change);
+	return gpiod_export_with_name(gpio_to_desc(gpio), direction_may_change,
+				      name);
 }
-EXPORT_SYMBOL_GPL(gpio_export);
+EXPORT_SYMBOL_GPL(gpio_export_with_name);
 
 static int match_export(struct device *dev, const void *data)
 {
@@ -1531,7 +1538,9 @@ int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
 		goto free_gpio;
 
 	if (flags & GPIOF_EXPORT) {
-		err = gpiod_export(desc, flags & GPIOF_EXPORT_CHANGEABLE);
+		err = gpiod_export_with_name(desc,
+					     flags & GPIOF_EXPORT_CHANGEABLE,
+					     NULL);
 		if (err)
 			goto free_gpio;
 	}
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index bde6469..d0970e3 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -202,7 +202,8 @@ extern void gpio_free_array(const struct gpio *array, size_t num);
  * A sysfs interface can be exported by individual drivers if they want,
  * but more typically is configured entirely from userspace.
  */
-extern int gpio_export(unsigned gpio, bool direction_may_change);
+extern int gpio_export_with_name(unsigned gpio, bool direction_may_change,
+				 const char *name);
 extern int gpio_export_link(struct device *dev, const char *name,
 			unsigned gpio);
 extern int gpio_sysfs_set_active_low(unsigned gpio, int value);
@@ -284,7 +285,8 @@ struct device;
 
 /* sysfs support is only available with gpiolib, where it's optional */
 
-static inline int gpio_export(unsigned gpio, bool direction_may_change)
+static inline int gpio_export_with_name(unsigned gpio, bool direction_may_change,
+					const char *name)
 {
 	return -ENOSYS;
 }
diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index 552e3f4..12a6cd2 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -169,7 +169,8 @@ static inline void gpio_set_value_cansleep(unsigned gpio, int value)
 	WARN_ON(1);
 }
 
-static inline int gpio_export(unsigned gpio, bool direction_may_change)
+static inline int gpio_export_with_name(unsigned gpio, bool direction_may_change,
+					const char *name)
 {
 	/* GPIO can never have been requested or set as {in,out}put */
 	WARN_ON(1);
@@ -236,4 +237,24 @@ int devm_gpio_request_one(struct device *dev, unsigned gpio,
 			  unsigned long flags, const char *label);
 void devm_gpio_free(struct device *dev, unsigned int gpio);
 
+/**
+ * gpio_export - export a GPIO through sysfs
+ * @gpio: gpio to make available, already requested
+ * @direction_may_change: true if userspace may change gpio direction
+ * Context: arch_initcall or later
+ *
+ * When drivers want to make a GPIO accessible to userspace after they
+ * have requested it -- perhaps while debugging, or as part of their
+ * public interface -- they may use this routine.  If the GPIO can
+ * change direction (some can't) and the caller allows it, userspace
+ * will see "direction" sysfs attribute which may be used to change
+ * the gpio's direction.  A "value" attribute will always be provided.
+ *
+ * Returns zero on success, else an error.
+ */
+static inline int gpio_export(unsigned gpio,bool direction_may_change)
+{
+	return gpio_export_with_name(gpio, direction_may_change, NULL);
+}
+
 #endif /* __LINUX_GPIO_H */
-- 
1.7.9.5

--
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

Re: [PATCH] gpio: add export with name from dts

[Jiří Prchal]

Dne 11.10.2013 12:48, Linus Walleij napsal(a):
> This patch must be CC to devicetree@vger.kernel.org as it concerns
> device tree bindings. Please also keep Alexandre Courbot in the loop as
> he's working on GPIO refactorings.
Send them too.

>
> On Fri, Oct 11, 2013 at 12:05 PM, Jiri Prchal <jiri.prchal@aksignal.cz> wrote:
>
>> Add export possibility to sysfs with given name in device tree.
>> Rebased from older unapplyed patch: [PATCH] owrt: GPIO: add gpio_export_with_name.
>>
>> Signed-off-by: Jiri Prchal <jiri.prchal@aksignal.cz>
>
> This is a very terse commit message for something which will have
> a very drastic impact on the Linux kernel and device tree.
It looks drastic, but it change name of function and adds one parameter to it.
And of course dt probe.
>
>> +3) gpio-export
>> +--------------
>> +
>> +gpio-export will allow you to automatically export gpio
>
>
> What does this mean? You have to define all terms. And also consider the
> audience. If someone is using device tree on Symbian or Windows,
> what does "export" mean to them? Not all readers of this document
> are Linux implementers.
Didn't know that dt is using someone else.
>
>> +required properties:
>> +- compatible: Should be "gpio-export"
>
> If this is a Linux-specific concept it should be named "linux-gpio-export"
>
> But overall I'm not happy with this *at all* as the sysfs ABI is already
> enough of a trouble for us. WIth platforms switching to DT-only
> probing it would be perfect to get rid of this sysfs interface altogether.
I'm not happy too.

>
> Two questions:
>
> - What do you think of the approach of just not using this for DT
>    boots, instead we create a new userspace ABI, using e.g. a
>    char device for each GPIO chip like /dev/gpio0, /dev/gpio1 etc
>    and access these using ioctl:s?
It would be nice, but yesterday was late.
Even nicer would be /dev/in13, /dev/out20 etc.

>
> - I guess you have a specific system in mind for this? What is the
>    use case? I have seen *way* too many people trying to reimplement
>    drivers/leds/leds-gpio.c
>    drivers/input/keyboard/gpio_keys.c
>    drivers/input/keyboard/gpio_keys_polled.c
>    drivers/power/gpio-charger.c
>    drivers/i2c/busses/i2c-gpio.c
>    drivers/extcon/extcon-gpio.c
>    drivers/spi/spi-gpio.c
>    IN USERSPACE! JUST BECAUSE THEY CAN!
As I know, no one is good for me. May be I could use gpio-led for outputs,
but they would be under sysfs/leds and it isn't clear. And what for inputs?

>
>>From a kernel developers point of view the kernel shall handle
> hardware, so that is why I'm quite picky about this.
It is hardware, my board has IN13, IN14 ... OUT19, GSM_ON etc. Why didn't
access them by right HW name.

Thanks
Jiri

Re: [PATCH] gpio: add export with name from dts

[Linus Walleij]

On Fri, Oct 11, 2013 at 1:30 PM, skrev Jiří Prchal <jiri.prchal@aksignal.cz>:
> Dne 11.10.2013 12:48, Linus Walleij napsal(a):

>> - What do you think of the approach of just not using this for DT
>>    boots, instead we create a new userspace ABI, using e.g. a
>>    char device for each GPIO chip like /dev/gpio0, /dev/gpio1 etc
>>    and access these using ioctl:s?
>
> It would be nice, but yesterday was late.
> Even nicer would be /dev/in13, /dev/out20 etc.

Hm like one device node per pin?

/dev/gpio0/in01
/dev/gpio0/out01
etc

>> - I guess you have a specific system in mind for this? What is the
>>    use case? I have seen *way* too many people trying to reimplement
>>    drivers/leds/leds-gpio.c
>>    drivers/input/keyboard/gpio_keys.c
>>    drivers/input/keyboard/gpio_keys_polled.c
>>    drivers/power/gpio-charger.c
>>    drivers/i2c/busses/i2c-gpio.c
>>    drivers/extcon/extcon-gpio.c
>>    drivers/spi/spi-gpio.c
>>    IN USERSPACE! JUST BECAUSE THEY CAN!
>
> As I know, no one is good for me. May be I could use gpio-led for outputs,
> but they would be under sysfs/leds and it isn't clear.

If the GPIOs are actually connected to LEDs you should be
using drivers/leds/leds-gpio.c and not export the GPIOs.

> And what for inputs?

Depends on what input. For simple buttons:

drivers/input/keyboard/gpio_keys.c
drivers/input/keyboard/gpio_keys_polled.c

Then you get the input events from /dev/input/eventN
just like any other key press.

extcon-gpio.c is for e.g. headphone insertion on mobile
phones etc.

Yours,
Linus Walleij
--
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

Re: [PATCH] gpio: add export with name from dts

[Jiří Prchal]

Dne 11.10.2013 14:49, Linus Walleij napsal(a):
> On Fri, Oct 11, 2013 at 1:30 PM, skrev Jiří Prchal <jiri.prchal@aksignal.cz>:
>> Dne 11.10.2013 12:48, Linus Walleij napsal(a):
>
>>> - What do you think of the approach of just not using this for DT
>>>     boots, instead we create a new userspace ABI, using e.g. a
>>>     char device for each GPIO chip like /dev/gpio0, /dev/gpio1 etc
>>>     and access these using ioctl:s?
>>
>> It would be nice, but yesterday was late.
>> Even nicer would be /dev/in13, /dev/out20 etc.
>
> Hm like one device node per pin?
>
> /dev/gpio0/in01
> /dev/gpio0/out01
> etc
Yes, because one userspace app is controling out1 and the other out2.
And maybe /dev/gpio/, not sorted by chip, because out2 and out3 could be another chip.
Just picked up unused gpio over soc and some added by SPI expander.
For example:
SOC -> board name
pioC18 -> in13
pioB12 -> in14
pioA31 -> out15
etc

>
>>> - I guess you have a specific system in mind for this? What is the
>>>     use case? I have seen *way* too many people trying to reimplement
>>>     drivers/leds/leds-gpio.c
>>>     drivers/input/keyboard/gpio_keys.c
>>>     drivers/input/keyboard/gpio_keys_polled.c
>>>     drivers/power/gpio-charger.c
>>>     drivers/i2c/busses/i2c-gpio.c
>>>     drivers/extcon/extcon-gpio.c
>>>     drivers/spi/spi-gpio.c
>>>     IN USERSPACE! JUST BECAUSE THEY CAN!
>>
>> As I know, no one is good for me. May be I could use gpio-led for outputs,
>> but they would be under sysfs/leds and it isn't clear.
>
> If the GPIOs are actually connected to LEDs you should be
> using drivers/leds/leds-gpio.c and not export the GPIOs.
I know that, just don't like /sys/class/leds/out15/brightness.

>
>> And what for inputs?
>
> Depends on what input. For simple buttons:
>
> drivers/input/keyboard/gpio_keys.c
> drivers/input/keyboard/gpio_keys_polled.c
>
> Then you get the input events from /dev/input/eventN
> just like any other key press.
>
> extcon-gpio.c is for e.g. headphone insertion on mobile
> phones etc.
Hm, my inputs are simple digital inputs from real world, like "door open",
"somewhere is voltage", "some switch is on". And more than one app is reading them.
So what to use for it?

Thanks
Jiri
--
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

Re: [PATCH] gpio: add export with name from dts

[Mark Rutland]

Hi,

On Fri, Oct 11, 2013 at 12:03:40PM +0100, Jiri Prchal wrote:
> Add export possibility to sysfs with given name in device tree.
> Rebased from older unapplyed patch: [PATCH] owrt: GPIO: add gpio_export_with_name.
> 
> Signed-off-by: Jiri Prchal <jiri.prchal-cKCO0sOKHLPtwjQa/ONI9g@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/gpio/gpio.txt |   61 +++++++++++++++++++++++
>  drivers/gpio/gpiolib-of.c                       |   61 +++++++++++++++++++++++
>  drivers/gpio/gpiolib.c                          |   27 ++++++----
>  include/asm-generic/gpio.h                      |    6 ++-
>  include/linux/gpio.h                            |   23 ++++++++-
>  5 files changed, 166 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
> index 6cec6ff..03c4ef5 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -117,3 +117,64 @@ Example:
>  Here, a single GPIO controller has GPIOs 0..9 routed to pin controller
>  pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's
>  pins 50..59.
> +
> +
> +3) gpio-export
> +--------------
> +
> +gpio-export will allow you to automatically export gpio

What does this mean? In what sense is the gpio exported?

Why is this needed? What's the intended purpose?

This patch is embedding a completely Linux-specific policy (when and how
to export devices via sysfs) into the DT. That does not belong in the
DT, as it is not a description of hardware. As such, NAK.

If we want gpios exported to userspace, that is better handled
elsewhere, and does not warrant a device tree binding for controlling
software.

> +
> +required properties:
> +- compatible: Should be "gpio-export"
> +
> +in each child node will reprensent a gpio or if no name is specified
> +a list of gpio to export

What does this mean?

What is each child node meant to look like?

Why are names and lists mutually exclusive?

s/reprensent/represent/

> +
> +required properties:
> +- gpios: gpio to export

Isn't this contradictory to the above?

> +
> +optional properties:
> + - gpio-export,name: export name

What does this mean?

Type?

> + - gpio-export,output: to set the as output with default value
> + 		       if no present gpio as input

Type?

What values are valid?

> + - pio-export,direction_may_change: boolean to allow the direction to be controllable

s/pio/gpio/.

'_' should be '-'.

> +
> +Example:
> +
> +
> +gpio_export {
> +	compatible = "gpio-export";
> +	#size-cells = <0>;

Why is there a #size-cells? No children have reg properties.

> +
> +	in {
> +		gpio-export,name = "in";
> +		gpios = <&pioC 20 0>;
> +	};
> +
> +	out {
> +		gpio-export,name = "out";
> +		gpio-export,output = <1>;
> +		gpio-export,direction_may_change;
> +		gpios = <&pioC 21 0>;
> +	};
> +
> +	in_out {
> +		gpio-export,name = "in_out";
> +		gpio-export,direction_may_change;
> +		gpios = <&pioC 21 0>;
> +	};
> +
> +	gpios_in {
> +		gpios = <&pioB 0 0
> +			 &pioB 3 0
> +			 &pioC 4 0>;

Tom maintain consistency across various arbitrary-size composite value
lists, I'd prefer we bracket each entry in lists individually, e.g.

gpios = <&pioB 0 0>,
        <&pioB 3 0>,
        <&pioC 4 0>;

Thanks,
Mark.
--
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

Re: [PATCH] gpio: add export with name from dts

[Linus Walleij]

On Fri, Oct 11, 2013 at 3:10 PM, Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
> Dne 11.10.2013 14:49, Linus Walleij napsal(a):

>> If the GPIOs are actually connected to LEDs you should be
>> using drivers/leds/leds-gpio.c and not export the GPIOs.
>
> I know that, just don't like /sys/class/leds/out15/brightness.

Hm, then you might want to modify the way names are set
on leds rather ... this is the way we handle LEDs in the kernel
so any problems need to be discussed with Bryan Wu,
the LED maintainer.

>>> And what for inputs?
>>
>> Depends on what input. For simple buttons:
>>
>> drivers/input/keyboard/gpio_keys.c
>> drivers/input/keyboard/gpio_keys_polled.c
>>
>> Then you get the input events from /dev/input/eventN
>> just like any other key press.
>>
>> extcon-gpio.c is for e.g. headphone insertion on mobile
>> phones etc.
>
> Hm, my inputs are simple digital inputs from real world, like "door open",
> "somewhere is voltage", "some switch is on". And more than one app is
> reading them.
> So what to use for it?

This is actually a valid case for using userspace GPIO, because
of course the kernel cannot model the entire world :-D

What makes me suspicious is mostly when some system
(board with GPIO used in an electronic design) is modeled
from userspace.

So this seems to be OK.

Yours,
Linus Walleij
--
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

Re: [PATCH] gpio: add export with name from dts

[Bryan Wu]

On Fri, Oct 11, 2013 at 7:46 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Oct 11, 2013 at 3:10 PM, Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
>> Dne 11.10.2013 14:49, Linus Walleij napsal(a):
>
>>> If the GPIOs are actually connected to LEDs you should be
>>> using drivers/leds/leds-gpio.c and not export the GPIOs.
>>
>> I know that, just don't like /sys/class/leds/out15/brightness.
>

Maybe I lost some context here, what's problem about the name?

Thanks,
-Bryan

> Hm, then you might want to modify the way names are set
> on leds rather ... this is the way we handle LEDs in the kernel
> so any problems need to be discussed with Bryan Wu,
> the LED maintainer.
>
--
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