From: Alexandre Courbot <acourbot@nvidia.com>
To: Grant Likely <grant.likely@secretlab.ca>,
Linus Walleij <linus.walleij@linaro.org>,
Arnd Bergmann <arnd@arndb.de>
Cc: Guenter Roeck <linux@roeck-us.net>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org,
Alexandre Courbot <gnurou@gmail.com>,
Alexandre Courbot <acourbot@nvidia.com>
Subject: [PATCH 4/4] gpiolib: add documentation for new gpiod_ API
Date: Tue, 8 Jan 2013 16:18:55 +0900 [thread overview]
Message-ID: <1357629535-26033-5-git-send-email-acourbot@nvidia.com> (raw)
In-Reply-To: <1357629535-26033-1-git-send-email-acourbot@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Documentation/gpio.txt | 94 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 92 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index 77a1d11..871ccda 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -120,7 +120,8 @@ example, a number might be valid but temporarily unused on a given board.
Whether a platform supports multiple GPIO controllers is a platform-specific
implementation issue, as are whether that support can leave "holes" in the space
-of GPIO numbers, and whether new controllers can be added at runtime. Such issues
+of GPIO numbers, and whether new controllers can be added at runtime. Such
+issues
can affect things including whether adjacent GPIO numbers are both valid.
Using GPIOs
@@ -302,7 +303,8 @@ are claimed, three additional calls are defined:
* 'flags', identical to gpio_request() wrt other arguments and
* return value
*/
- int gpio_request_one(unsigned gpio, unsigned long flags, const char *label);
+ int gpio_request_one(unsigned gpio, unsigned long flags, const char
+*label);
/* request multiple GPIOs in a single call
*/
@@ -773,3 +775,91 @@ differences between boards from user space. This only affects the
sysfs interface. Polarity change can be done both before and after
gpio_export(), and previously enabled poll(2) support for either
rising or falling edge will be reconfigured to follow this setting.
+
+GPIO descriptor interface
+=========================
+A more secure, alternative GPIO interface is available through GPIOlib. Instead
+of relying on integers (which can easily be forged and used without being
+properly requested) to reference GPIOs, it uses a system of opaque descriptors
+that must be properly obtained and disposed through the common get/put set of
+functions. This ensures that all GPIO descriptors are valid at any time and
+makes it unnecessary to check the validity of a GPIO. Apart from this
+difference, the interface is similar to the integer-based one, excepted that the
+gpio_ prefix is changed to gpiod_.
+
+This interface can be used in conjonction with the integer-based API, however
+new drivers should really try to use the safer descriptor-based interface.
+Drivers using this interface should depend on CONFIG_GPIOLIB being set, as it is
+only available when GPIOlib is compiled in.
+
+Using GPIOs
+-----------
+GPIO consumers should include <linux/gpio/consumer.h> which declares the
+consumer-side GPIO functions. GPIOs are obtained through gpiod_get:
+
+ struct gpio_desc *gpiod_get(struct device *dev,
+ const char *con_id);
+
+This will return the GPIO descriptor corresponding to the con_id function of
+dev, or an error code in case of error. A devm variant is also available:
+
+ struct gpio_desc *devm_gpiod_get(struct device *dev,
+ const char *con_id);
+
+GPIO descriptors are disposed using the corresponding put functions:
+
+ void gpiod_put(struct gpio_desc *desc);
+ void devm_gpiod_put(struct device *dev, struct gpio_desc *desc);
+
+A valid descriptor can then be used with one of the gpiod_ functions. Their
+interface is identical to the integer-based API, excepted that they take a GPIO
+descriptor instead of an integer:
+
+ int gpiod_direction_input(struct gpio_desc *desc);
+ int gpiod_direction_output(struct gpio_desc *desc, int value);
+ int gpiod_get_value(struct gpio_desc *desc);
+ void gpiod_set_value(struct gpio_desc *desc, int value);
+ ...
+
+If you need to convert a descriptor to an integer or vice-versa, you can use
+gpio_to_desc or desc_to_gpio:
+
+ struct gpio_desc *gpio_to_desc(unsigned gpio);
+ int desc_to_gpio(const struct gpio_desc *desc);
+
+The same GPIO can be used by both interfaces as long as it has properly been
+acquired by one of them (i.e. using either gpio_request() or gpiod_get()).
+
+Declaring GPIOs
+---------------
+GPIOs can be made available for devices either through board-specific lookup
+tables, or using the device tree.
+
+Board-specific lookup tables match a device name and consumer ID to a GPIO chip
+and GPIO number relative to that chip. They are declared as follows:
+
+ static struct gpio_lookup board_gpio_lookup[] = {
+ GPIO_LOOKUP("tegra-gpio", 28, "backlight.1", "power"),
+ };
+
+ static void __init board_init(void)
+ {
+ ...
+ gpiod_add_table(board_gpio_lookup,
+ ARRAY_SIZE(board_gpio_lookup));
+ ...
+ }
+
+In the driver side, the following code:
+
+ gpiod_get(dev, "power");
+
+will return the descriptor for GPIO 28 of the "tegra-gpio" chip provided
+strcmp(dev_name(dev), "backlight.1") == 0.
+
+If the device tree is used, then the same "power" GPIO can be declared into the
+device's node as follows:
+
+ power-gpios = <&gpio 28 0>;
+
+Note that gpiod_get() only allows to access the first GPIO specifier.
\ No newline at end of file
--
1.8.1
WARNING: multiple messages have this Message-ID (diff)
From: acourbot@nvidia.com (Alexandre Courbot)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] gpiolib: add documentation for new gpiod_ API
Date: Tue, 8 Jan 2013 16:18:55 +0900 [thread overview]
Message-ID: <1357629535-26033-5-git-send-email-acourbot@nvidia.com> (raw)
In-Reply-To: <1357629535-26033-1-git-send-email-acourbot@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Documentation/gpio.txt | 94 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 92 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index 77a1d11..871ccda 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -120,7 +120,8 @@ example, a number might be valid but temporarily unused on a given board.
Whether a platform supports multiple GPIO controllers is a platform-specific
implementation issue, as are whether that support can leave "holes" in the space
-of GPIO numbers, and whether new controllers can be added at runtime. Such issues
+of GPIO numbers, and whether new controllers can be added at runtime. Such
+issues
can affect things including whether adjacent GPIO numbers are both valid.
Using GPIOs
@@ -302,7 +303,8 @@ are claimed, three additional calls are defined:
* 'flags', identical to gpio_request() wrt other arguments and
* return value
*/
- int gpio_request_one(unsigned gpio, unsigned long flags, const char *label);
+ int gpio_request_one(unsigned gpio, unsigned long flags, const char
+*label);
/* request multiple GPIOs in a single call
*/
@@ -773,3 +775,91 @@ differences between boards from user space. This only affects the
sysfs interface. Polarity change can be done both before and after
gpio_export(), and previously enabled poll(2) support for either
rising or falling edge will be reconfigured to follow this setting.
+
+GPIO descriptor interface
+=========================
+A more secure, alternative GPIO interface is available through GPIOlib. Instead
+of relying on integers (which can easily be forged and used without being
+properly requested) to reference GPIOs, it uses a system of opaque descriptors
+that must be properly obtained and disposed through the common get/put set of
+functions. This ensures that all GPIO descriptors are valid at any time and
+makes it unnecessary to check the validity of a GPIO. Apart from this
+difference, the interface is similar to the integer-based one, excepted that the
+gpio_ prefix is changed to gpiod_.
+
+This interface can be used in conjonction with the integer-based API, however
+new drivers should really try to use the safer descriptor-based interface.
+Drivers using this interface should depend on CONFIG_GPIOLIB being set, as it is
+only available when GPIOlib is compiled in.
+
+Using GPIOs
+-----------
+GPIO consumers should include <linux/gpio/consumer.h> which declares the
+consumer-side GPIO functions. GPIOs are obtained through gpiod_get:
+
+ struct gpio_desc *gpiod_get(struct device *dev,
+ const char *con_id);
+
+This will return the GPIO descriptor corresponding to the con_id function of
+dev, or an error code in case of error. A devm variant is also available:
+
+ struct gpio_desc *devm_gpiod_get(struct device *dev,
+ const char *con_id);
+
+GPIO descriptors are disposed using the corresponding put functions:
+
+ void gpiod_put(struct gpio_desc *desc);
+ void devm_gpiod_put(struct device *dev, struct gpio_desc *desc);
+
+A valid descriptor can then be used with one of the gpiod_ functions. Their
+interface is identical to the integer-based API, excepted that they take a GPIO
+descriptor instead of an integer:
+
+ int gpiod_direction_input(struct gpio_desc *desc);
+ int gpiod_direction_output(struct gpio_desc *desc, int value);
+ int gpiod_get_value(struct gpio_desc *desc);
+ void gpiod_set_value(struct gpio_desc *desc, int value);
+ ...
+
+If you need to convert a descriptor to an integer or vice-versa, you can use
+gpio_to_desc or desc_to_gpio:
+
+ struct gpio_desc *gpio_to_desc(unsigned gpio);
+ int desc_to_gpio(const struct gpio_desc *desc);
+
+The same GPIO can be used by both interfaces as long as it has properly been
+acquired by one of them (i.e. using either gpio_request() or gpiod_get()).
+
+Declaring GPIOs
+---------------
+GPIOs can be made available for devices either through board-specific lookup
+tables, or using the device tree.
+
+Board-specific lookup tables match a device name and consumer ID to a GPIO chip
+and GPIO number relative to that chip. They are declared as follows:
+
+ static struct gpio_lookup board_gpio_lookup[] = {
+ GPIO_LOOKUP("tegra-gpio", 28, "backlight.1", "power"),
+ };
+
+ static void __init board_init(void)
+ {
+ ...
+ gpiod_add_table(board_gpio_lookup,
+ ARRAY_SIZE(board_gpio_lookup));
+ ...
+ }
+
+In the driver side, the following code:
+
+ gpiod_get(dev, "power");
+
+will return the descriptor for GPIO 28 of the "tegra-gpio" chip provided
+strcmp(dev_name(dev), "backlight.1") == 0.
+
+If the device tree is used, then the same "power" GPIO can be declared into the
+device's node as follows:
+
+ power-gpios = <&gpio 28 0>;
+
+Note that gpiod_get() only allows to access the first GPIO specifier.
\ No newline at end of file
--
1.8.1
WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Courbot <acourbot@nvidia.com>
To: Grant Likely <grant.likely@secretlab.ca>,
Linus Walleij <linus.walleij@linaro.org>,
Arnd Bergmann <arnd@arndb.de>
Cc: Guenter Roeck <linux@roeck-us.net>,
<linux-kernel@vger.kernel.org>, <linux-arch@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<devicetree-discuss@lists.ozlabs.org>,
Alexandre Courbot <gnurou@gmail.com>,
Alexandre Courbot <acourbot@nvidia.com>
Subject: [PATCH 4/4] gpiolib: add documentation for new gpiod_ API
Date: Tue, 8 Jan 2013 16:18:55 +0900 [thread overview]
Message-ID: <1357629535-26033-5-git-send-email-acourbot@nvidia.com> (raw)
In-Reply-To: <1357629535-26033-1-git-send-email-acourbot@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Documentation/gpio.txt | 94 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 92 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index 77a1d11..871ccda 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -120,7 +120,8 @@ example, a number might be valid but temporarily unused on a given board.
Whether a platform supports multiple GPIO controllers is a platform-specific
implementation issue, as are whether that support can leave "holes" in the space
-of GPIO numbers, and whether new controllers can be added at runtime. Such issues
+of GPIO numbers, and whether new controllers can be added at runtime. Such
+issues
can affect things including whether adjacent GPIO numbers are both valid.
Using GPIOs
@@ -302,7 +303,8 @@ are claimed, three additional calls are defined:
* 'flags', identical to gpio_request() wrt other arguments and
* return value
*/
- int gpio_request_one(unsigned gpio, unsigned long flags, const char *label);
+ int gpio_request_one(unsigned gpio, unsigned long flags, const char
+*label);
/* request multiple GPIOs in a single call
*/
@@ -773,3 +775,91 @@ differences between boards from user space. This only affects the
sysfs interface. Polarity change can be done both before and after
gpio_export(), and previously enabled poll(2) support for either
rising or falling edge will be reconfigured to follow this setting.
+
+GPIO descriptor interface
+=========================
+A more secure, alternative GPIO interface is available through GPIOlib. Instead
+of relying on integers (which can easily be forged and used without being
+properly requested) to reference GPIOs, it uses a system of opaque descriptors
+that must be properly obtained and disposed through the common get/put set of
+functions. This ensures that all GPIO descriptors are valid at any time and
+makes it unnecessary to check the validity of a GPIO. Apart from this
+difference, the interface is similar to the integer-based one, excepted that the
+gpio_ prefix is changed to gpiod_.
+
+This interface can be used in conjonction with the integer-based API, however
+new drivers should really try to use the safer descriptor-based interface.
+Drivers using this interface should depend on CONFIG_GPIOLIB being set, as it is
+only available when GPIOlib is compiled in.
+
+Using GPIOs
+-----------
+GPIO consumers should include <linux/gpio/consumer.h> which declares the
+consumer-side GPIO functions. GPIOs are obtained through gpiod_get:
+
+ struct gpio_desc *gpiod_get(struct device *dev,
+ const char *con_id);
+
+This will return the GPIO descriptor corresponding to the con_id function of
+dev, or an error code in case of error. A devm variant is also available:
+
+ struct gpio_desc *devm_gpiod_get(struct device *dev,
+ const char *con_id);
+
+GPIO descriptors are disposed using the corresponding put functions:
+
+ void gpiod_put(struct gpio_desc *desc);
+ void devm_gpiod_put(struct device *dev, struct gpio_desc *desc);
+
+A valid descriptor can then be used with one of the gpiod_ functions. Their
+interface is identical to the integer-based API, excepted that they take a GPIO
+descriptor instead of an integer:
+
+ int gpiod_direction_input(struct gpio_desc *desc);
+ int gpiod_direction_output(struct gpio_desc *desc, int value);
+ int gpiod_get_value(struct gpio_desc *desc);
+ void gpiod_set_value(struct gpio_desc *desc, int value);
+ ...
+
+If you need to convert a descriptor to an integer or vice-versa, you can use
+gpio_to_desc or desc_to_gpio:
+
+ struct gpio_desc *gpio_to_desc(unsigned gpio);
+ int desc_to_gpio(const struct gpio_desc *desc);
+
+The same GPIO can be used by both interfaces as long as it has properly been
+acquired by one of them (i.e. using either gpio_request() or gpiod_get()).
+
+Declaring GPIOs
+---------------
+GPIOs can be made available for devices either through board-specific lookup
+tables, or using the device tree.
+
+Board-specific lookup tables match a device name and consumer ID to a GPIO chip
+and GPIO number relative to that chip. They are declared as follows:
+
+ static struct gpio_lookup board_gpio_lookup[] = {
+ GPIO_LOOKUP("tegra-gpio", 28, "backlight.1", "power"),
+ };
+
+ static void __init board_init(void)
+ {
+ ...
+ gpiod_add_table(board_gpio_lookup,
+ ARRAY_SIZE(board_gpio_lookup));
+ ...
+ }
+
+In the driver side, the following code:
+
+ gpiod_get(dev, "power");
+
+will return the descriptor for GPIO 28 of the "tegra-gpio" chip provided
+strcmp(dev_name(dev), "backlight.1") == 0.
+
+If the device tree is used, then the same "power" GPIO can be declared into the
+device's node as follows:
+
+ power-gpios = <&gpio 28 0>;
+
+Note that gpiod_get() only allows to access the first GPIO specifier.
\ No newline at end of file
--
1.8.1
next prev parent reply other threads:[~2013-01-08 7:18 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-08 7:18 [PATCH 0/4] gpio: introduce descriptor-based interface Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 7:18 ` [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 12:59 ` Arnd Bergmann
2013-01-08 12:59 ` Arnd Bergmann
2013-01-09 1:06 ` Alexandre Courbot
2013-01-09 1:06 ` Alexandre Courbot
2013-01-09 10:25 ` Russell King - ARM Linux
2013-01-09 10:25 ` Russell King - ARM Linux
2013-01-09 10:35 ` Arnd Bergmann
2013-01-09 10:35 ` Arnd Bergmann
2013-01-09 10:44 ` Russell King - ARM Linux
2013-01-09 10:44 ` Russell King - ARM Linux
2013-01-09 11:10 ` Russell King - ARM Linux
2013-01-09 11:10 ` Russell King - ARM Linux
[not found] ` <20130109111055.GG3931-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-01-09 11:52 ` Arnd Bergmann
2013-01-09 11:52 ` Arnd Bergmann
2013-01-09 11:52 ` Arnd Bergmann
2013-01-09 14:44 ` Nicolas Pitre
2013-01-09 14:44 ` Nicolas Pitre
2013-01-09 15:04 ` [PATCH] Proposed removal of IS_ERR_OR_NULL() (was: Re: [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface) Russell King - ARM Linux
2013-01-09 15:04 ` Russell King - ARM Linux
[not found] ` <20130109150427.GL3931-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-01-09 15:21 ` Grant Likely
2013-01-09 15:21 ` Grant Likely
2013-01-09 15:21 ` Grant Likely
2013-01-09 15:26 ` Arnd Bergmann
2013-01-09 15:26 ` Arnd Bergmann
2013-01-09 15:27 ` Nicolas Pitre
2013-01-09 15:27 ` Nicolas Pitre
2013-01-09 15:51 ` Russell King - ARM Linux
2013-01-09 15:51 ` Russell King - ARM Linux
2013-01-09 16:09 ` Nicolas Pitre
2013-01-09 16:09 ` Nicolas Pitre
2013-01-09 16:21 ` Russell King - ARM Linux
2013-01-09 16:21 ` Russell King - ARM Linux
2013-01-09 17:12 ` Russell King - ARM Linux
2013-01-09 17:12 ` Russell King - ARM Linux
2013-01-09 17:52 ` Tony Lindgren
2013-01-09 17:52 ` Tony Lindgren
2013-01-17 10:28 ` Linus Walleij
2013-01-17 10:28 ` Linus Walleij
2013-01-10 8:36 ` [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface Thierry Reding
2013-01-10 8:36 ` Thierry Reding
2013-01-08 7:18 ` [PATCH 2/4] gpiolib: add gpiod_get and gpiod_put functions Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 13:07 ` Arnd Bergmann
2013-01-08 13:07 ` Arnd Bergmann
2013-01-09 1:49 ` Alexandre Courbot
2013-01-09 1:49 ` Alexandre Courbot
2013-01-08 7:18 ` [PATCH 3/4] gpiolib: of: convert OF helpers to descriptor API Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot [this message]
2013-01-08 7:18 ` [PATCH 4/4] gpiolib: add documentation for new gpiod_ API Alexandre Courbot
2013-01-08 7:18 ` Alexandre Courbot
2013-01-08 13:06 ` [PATCH 0/4] gpio: introduce descriptor-based interface Arnd Bergmann
2013-01-08 13:06 ` Arnd Bergmann
2013-01-09 1:48 ` Alexandre Courbot
2013-01-09 1:48 ` Alexandre Courbot
2013-01-09 10:46 ` Arnd Bergmann
2013-01-09 10:46 ` Arnd Bergmann
2013-01-10 4:07 ` Alex Courbot
2013-01-10 4:07 ` Alex Courbot
2013-01-10 10:08 ` Arnd Bergmann
2013-01-10 10:08 ` Arnd Bergmann
2013-01-14 10:21 ` Alex Courbot
2013-01-14 10:21 ` Alex Courbot
2013-01-14 10:21 ` Alex Courbot
2013-01-14 10:21 ` Alex Courbot
2013-01-14 10:46 ` Arnd Bergmann
2013-01-14 10:46 ` Arnd Bergmann
2013-01-14 10:46 ` Arnd Bergmann
2013-01-17 11:15 ` Linus Walleij
2013-01-17 11:15 ` Linus Walleij
2013-01-17 12:02 ` Greg Ungerer
2013-01-17 12:02 ` Greg Ungerer
2013-01-17 16:50 ` Steven King
2013-01-17 16:50 ` Steven King
2013-01-17 16:50 ` Steven King
2013-01-17 19:22 ` Arnd Bergmann
2013-01-17 19:22 ` Arnd Bergmann
2013-01-20 6:07 ` Alex Courbot
2013-01-20 6:07 ` Alex Courbot
2013-01-20 6:07 ` Alex Courbot
2013-01-22 8:55 ` Linus Walleij
2013-01-22 8:55 ` Linus Walleij
2013-01-17 11:25 ` Linus Walleij
2013-01-17 11:25 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1357629535-26033-5-git-send-email-acourbot@nvidia.com \
--to=acourbot@nvidia.com \
--cc=arnd@arndb.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=gnurou@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.