From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: linux-wireless@vger.kernel.org,
Ulf Hansson <ulf.hansson@linaro.org>,
Wolfram Sang <wsa@the-dreams.de>,
linux-mmc@vger.kernel.org, Chris Ball <chris@printf.net>,
dri-devel@lists.freedesktop.org,
Liam Girdwood <lgirdwood@gmail.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
linux-i2c@vger.kernel.org, Pavel Machek <pavel@ucw.cz>,
Jiri Slaby <jslaby@suse.cz>,
gnurou@gmail.com, Florian Fainelli <f.fainelli@gmail.com>,
Samuel Ortiz <sameo@linux.intel.com>,
Alexander Shiyan <shc_work@mail.ru>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
Paul Handrigan <Paul.Handrigan@cirrus.com>,
linux-iio@vger.kernel.org, linux-omap@vger.kernel.org,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Hans Verkuil <hans.verkuil@cisco.com>,
linux-serial@vger.kernel.org, linux-input@vger.kernel.org,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
linux-media@vg
Subject: Re: [PATCH] gpio: extend gpiod_get*() with flags parameter
Date: Thu, 24 Jul 2014 18:23:39 +0200 [thread overview]
Message-ID: <1496956.3bpx902hFg@avalon> (raw)
In-Reply-To: <1406214298-20062-1-git-send-email-acourbot@nvidia.com>
Hi Alexandre,
Thank you for the patch.
On Friday 25 July 2014 00:04:58 Alexandre Courbot wrote:
> The huge majority of GPIOs have their direction and initial value set
> right after being obtained by one of the gpiod_get() functions. The
> integer GPIO API had gpio_request_one() that took a convenience flags
> parameter allowing to specify an direction and value applied to the
> returned GPIO. This feature greatly simplifies client code and ensures
> errors are always handled properly.
>
> A similar feature has been requested for the gpiod API. Since GPIOs need
> a direction to be used anyway, we prefer to extend the existing
> functions instead of introducing new functions that would raise the
> number of gpiod getters to 16 (!).
>
> The drawback of this approach is that all gpiod clients need to be
> updated, but there aren't that many and the moment and this results in
> smaller (and hopefully safer) code.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> This change will be difficult to apply without breaking things, but
> let's try to do it right. Hopefully the benefit will outweight the
> disturbance.
>
> This is a patch against -next to list and update all current gpiod
> consumers. Updates are trivial at first sight, but it would be nice to
> get as many acks as possible from the respective subsystem maintainers.
>
> I'm not sure how this could be applied harmlessly though - maybe through
> a dedicated branch for -next? Problem is that a lot of new code is not
> yet merged into mainline, and conflicts are very likely to occur. Linus,
> do you have any suggestion as to how this can be done without blood being
> spilled?
>
> Documentation/gpio/consumer.txt | 26 ++++++++---
> drivers/gpio/devres.c | 24 ++++++----
> drivers/gpio/gpiolib.c | 53 +++++++++++++------
> drivers/gpu/drm/panel/panel-ld9040.c | 7 +--
> drivers/gpu/drm/panel/panel-s6e8aa0.c | 7 +--
> drivers/gpu/drm/panel/panel-simple.c | 16 ++-----
> drivers/hsi/clients/nokia-modem.c | 7 +--
> drivers/i2c/muxes/i2c-mux-pca954x.c | 4 +-
> drivers/iio/accel/kxcjk-1013.c | 6 +--
> drivers/input/keyboard/clps711x-keypad.c | 6 +--
> drivers/input/misc/gpio-beeper.c | 6 +--
> drivers/input/misc/soc_button_array.c | 2 +-
> drivers/media/i2c/adv7604.c | 6 +--
> drivers/mfd/intel_soc_pmic_core.c | 2 +-
> drivers/mmc/core/slot-gpio.c | 6 +--
> drivers/net/phy/at803x.c | 4 +-
> drivers/power/reset/gpio-poweroff.c | 21 ++-------
> drivers/tty/serial/serial_mctrl_gpio.c | 2 +-
> drivers/video/backlight/pwm_bl.c | 6 +--
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 12 ++---
> .../omap2/displays-new/panel-lgphilips-lb035q02.c | 6 +--
> .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 7 +--
> include/linux/gpio/consumer.h | 38 ++++++++++++----
> net/rfkill/rfkill-gpio.c | 16 ++-----
> sound/soc/codecs/adau1977.c | 11 ++---
> sound/soc/codecs/cs4265.c | 5 +-
> sound/soc/codecs/sta350.c | 9 ++--
> sound/soc/codecs/tas2552.c | 4 +-
> sound/soc/jz4740/qi_lb60.c | 10 +---
> sound/soc/omap/rx51.c | 29 +++---------
> sound/soc/soc-jack.c | 9 ++--
> 31 files changed, 160 insertions(+), 207 deletions(-)
>
> diff --git a/Documentation/gpio/consumer.txt
> b/Documentation/gpio/consumer.txt index 7ff30d2..a3fb1d7 100644
> --- a/Documentation/gpio/consumer.txt
> +++ b/Documentation/gpio/consumer.txt
> @@ -29,13 +29,24 @@ gpiod_get() functions. Like many other kernel
> subsystems, gpiod_get() takes the device that will use the GPIO and the
> function the requested GPIO is supposed to fulfill:
>
> - struct gpio_desc *gpiod_get(struct device *dev, const char *con_id)
> + struct gpio_desc *gpiod_get(struct device *dev, const char *con_id,
> + enum gpio_flags flags)
I assume you mean enum gpiod_flags here and in the rest of the documentation.
> If a function is implemented by using several GPIOs together (e.g. a simple
> LED device that displays digits), an additional index argument can be
> specified:
>
> struct gpio_desc *gpiod_get_index(struct device *dev,
> - const char *con_id, unsigned int idx)
> + const char *con_id, unsigned int idx,
> + enum gpio_flags flags)
> +
> +The flags parameter is used to optionally specify a direction and initial
> value +for the GPIO. Values can be:
> +
> +* AS_IS or 0 to not initialize the GPIO at all. The direction must be set
> later
> + with one of the dedicated functions.
> +* INPUT to initialize the GPIO as input.
> +* OUTPUT_LOW to initialize the GPIO as output with a value of 0.
> +* OUTPUT_HIGH to initialize the GPIO as output with a value of 1.
Pretty please, could you at least prefix that with GPIOD_ ? Those names are
too generic.
How about renaming them to GPIOD_AS_IS, GPIOD_IN, GPIOD_OUT_INIT_LOW and
GPIOD_OUT_INIT_HIGH in order to match the GPIOF_ flags ?
> Both functions return either a valid GPIO descriptor, or an error code
> checkable with IS_ERR() (they will never return a NULL pointer). -ENOENT
> will be returned @@ -49,11 +60,13 @@ GPIO has been assigned to the
> requested function:
>
> Device-managed variants of these functions are also defined:
>
> - struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id)
> + struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id,
> + enum gpio_flags flags)
>
> struct gpio_desc *devm_gpiod_get_index(struct device *dev,
> const char *con_id,
> - unsigned int idx)
> + unsigned int idx,
> + enum gpio_flags flags)
>
> devm_gpiod_get_optional() and devm_gpiod_get_index_optional() exist as
> well.
>
> @@ -72,8 +85,9 @@ Using GPIOs
>
> Setting Direction
> -----------------
> -The first thing a driver must do with a GPIO is setting its direction. This
> is -done by invoking one of the gpiod_direction_*() functions:
> +The first thing a driver must do with a GPIO is setting its direction. If
> no +direction-setting flags as been given to one of the gpiod_get*()
> functions, this +is done by invoking one of the gpiod_direction_*()
> functions:
>
> int gpiod_direction_input(struct gpio_desc *desc)
> int gpiod_direction_output(struct gpio_desc *desc, int value)
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2014-07-24 16:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-24 15:04 [PATCH] gpio: extend gpiod_get*() with flags parameter Alexandre Courbot
2014-07-24 16:10 ` Arnd Bergmann
2014-07-25 1:32 ` Alexandre Courbot
2014-07-24 16:10 ` Greg Kroah-Hartman
2014-07-25 6:52 ` Lee Jones
2014-07-24 16:23 ` Laurent Pinchart [this message]
2014-07-25 1:36 ` Alexandre Courbot
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=1496956.3bpx902hFg@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=Paul.Handrigan@cirrus.com \
--cc=acourbot@nvidia.com \
--cc=chris@printf.net \
--cc=dbaryshkov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=f.fainelli@gmail.com \
--cc=gnurou@gmail.com \
--cc=hans.verkuil@cisco.com \
--cc=jslaby@suse.cz \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-media@vg \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=peter.ujfalusi@ti.com \
--cc=plagnioj@jcrosoft.com \
--cc=sameo@linux.intel.com \
--cc=shc_work@mail.ru \
--cc=tomi.valkeinen@ti.com \
--cc=ulf.hansson@linaro.org \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).