linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/9] gpiolib: use descriptors internally
Date: Sat, 09 Feb 2013 13:11:58 +0000	[thread overview]
Message-ID: <20130209131158.22FD53E30EC@localhost> (raw)
In-Reply-To: <1359822572-26009-8-git-send-email-acourbot@nvidia.com>

On Sun,  3 Feb 2013 01:29:29 +0900, Alexandre Courbot <acourbot@nvidia.com> wrote:
> Make sure gpiolib works internally with descriptors and (chip, offset)
> pairs instead of using the global integer namespace. This prepares the
> ground for the removal of the global gpio_desc[] array and the
> introduction of the descriptor-based GPIO API.
> 
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
>  drivers/gpio/gpiolib.c | 493 +++++++++++++++++++++++++++++++------------------
>  1 file changed, 317 insertions(+), 176 deletions(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index af4c350..82c40bd 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -78,6 +78,28 @@ static LIST_HEAD(gpio_chips);
>  static DEFINE_IDR(dirent_idr);
>  #endif
>  
> +/*
> + * Internal gpiod_* API using descriptors instead of the integer namespace.
> + * Most of this should eventually go public.
> + */
> +static int gpiod_request(struct gpio_desc *desc, const char *label);
> +static void gpiod_free(struct gpio_desc *desc);
> +static int gpiod_direction_input(struct gpio_desc *desc);
> +static int gpiod_direction_output(struct gpio_desc *desc, int value);
> +static int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce);
> +static int gpiod_get_value_cansleep(struct gpio_desc *desc);
> +static void gpiod_set_value_cansleep(struct gpio_desc *desc, int value);
> +static int gpiod_get_value(struct gpio_desc *desc);
> +static void gpiod_set_value(struct gpio_desc *desc, int value);
> +static int gpiod_cansleep(struct gpio_desc *desc);
> +static int gpiod_to_irq(struct gpio_desc *desc);
> +static int gpiod_export(struct gpio_desc *desc, bool direction_may_change);
> +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);
> +static void gpiod_unexport(struct gpio_desc *desc);

I've been thinking about the adding of a new API to supplant the old,
and I'm wondering if we're going about this the wrong way around; at
least for the public api. We've moved to a model where device drivers
are really supposed to tread GPIO numbers as opaque handles. Most device
drivers are well behaved on this point. (Others of course are not so
well behaved and either hard code or interpret what a number means, but
those users already need to be fixed before they will work with the
device tree)

Rather than creating a new API with a long-term-plan to move all old
users to the new API - touching a lot of code all over the kernel in the
process - what if we repurposed the existing API in a backwards
compatible way.

I think the maximum GPIO number I've seen in use is 65535, and that was
based on dynamic allocation. What if we did the following:

typedef unsigned long gpio_handle_t;

struct gpio_desc *gpio_handle_to_desc(gpio_handle_t gpio)
{
	if (gpio <= NR_GPIOS)
		return &gpio_desc[gpio];
	return (struct gpio_desc *)gpio;
}

int gpio_get_direction(gpio_handle_t gpio)
{
	struct gpio_desc *desc = gpio_handle_to_desc(gpio);
	if (!desc)
		return -EEXIST;
	return gpiod_get_direction(desc);
}

And do the same for all the other hooks. That will make the gpio changes
much lower impact across the kernel, allow legacy gpio users to keep
doing what they are doing, and encourage driver authors to keep out of
the gpio_desc internals.

Thoughts?

I'm probably going to apply this patch anyway because it only affects
the gpiolib internals, I need to take one more look over it before I
make a decision. I want to get as much of this as possible queued up for
v3.9 to make future work easier.

g.

  parent reply	other threads:[~2013-02-09 13:11 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-02 16:29 [PATCH 0/9] gpiolib: remove gpio_desc[] static array Alexandre Courbot
2013-02-02 16:29 ` Alexandre Courbot
2013-02-02 16:29 ` [PATCH 1/9] gpiolib: link all gpio_chips using a list Alexandre Courbot
2013-02-05 17:00   ` Linus Walleij
2013-02-09  9:20     ` Grant Likely
2013-02-02 16:29 ` [PATCH 2/9] gpiolib: use gpio_chips list in gpiolib_sysfs_init Alexandre Courbot
2013-02-05 17:04   ` Linus Walleij
2013-02-09  9:22     ` Grant Likely
2013-02-02 16:29 ` [PATCH 3/9] gpiolib: use gpio_chips list in gpiochip_find Alexandre Courbot
2013-02-05 17:05   ` Linus Walleij
2013-02-09  9:25     ` Grant Likely
2013-02-02 16:29 ` [PATCH 4/9] gpiolib: use gpio_chips list in sysfs ops Alexandre Courbot
2013-02-05 17:15   ` Linus Walleij
2013-02-09  9:37     ` Grant Likely
2013-02-09 13:53       ` Alexandre Courbot
2013-02-02 16:29 ` [PATCH 5/9] gpiolib: use gpio_chips list in gpiochip_find_base Alexandre Courbot
2013-02-05 17:21   ` Linus Walleij
2013-02-06  4:48     ` Alex Courbot
2013-02-09  9:47       ` Grant Likely
2013-02-02 16:29 ` [PATCH 6/9] gpiolib: use descriptors internally Alexandre Courbot
2013-02-05 17:53   ` Linus Walleij
2013-02-07  6:57     ` Alexandre Courbot
2013-02-09  9:17       ` Grant Likely
2013-02-11 14:09         ` Linus Walleij
2013-02-11 15:40           ` Paul Mundt
2013-02-11 17:39           ` Stephen Warren
2013-02-12 12:29             ` Linus Walleij
2013-02-12 15:59               ` Paul Mundt
2013-02-12 17:18                 ` Arnd Bergmann
2013-02-09 13:11   ` Grant Likely [this message]
2013-02-09 14:15     ` Alexandre Courbot
2013-02-09 13:24   ` Grant Likely
2013-02-09 14:18     ` Alexandre Courbot
2013-02-02 16:29 ` [PATCH 7/9] gpiolib: let gpio_chip reference its descriptors Alexandre Courbot
2013-02-05 18:00   ` Linus Walleij
2013-02-09 13:28     ` Grant Likely
2013-02-02 16:29 ` [PATCH 8/9] gpiolib: use gpio_chips list in gpio_to_desc Alexandre Courbot
2013-02-05 18:01   ` Linus Walleij
2013-02-09  9:58   ` Grant Likely
2013-02-09 14:21     ` Alexandre Courbot
2013-02-09 14:37       ` Grant Likely
2013-02-02 16:29 ` [PATCH 9/9] gpiolib: dynamically allocate descriptors array Alexandre Courbot
2013-02-05 18:02   ` 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=20130209131158.22FD53E30EC@localhost \
    --to=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).