diff options
author | David Brownell <dbrownell@users.sourceforge.net> | 2009-04-02 19:57:06 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2009-04-02 22:04:51 -0400 |
commit | 8a0cecffeb52363a57257bbbbd58f4c4537a75bb (patch) | |
tree | ee7f754d49a2f2ad75b72ec59e90e6fa2c0753eb | |
parent | 926b663ce8215ba448960e1ff6e58b67a2c3b99b (diff) |
gpio: gpio_{request,free}() now required (feature removal)
We want to phase out the GPIO "autorequest" mechanism in gpiolib and
require all callers to use gpio_request().
- Update feature-removal-schedule
- Update the documentation now
- Convert the relevant pr_warning() in gpiolib to a WARN()
so folk using this mechanism get a noisy stack dump
Some drivers and board init code will probably need to change.
Implementations not using gpiolib will still be fine; they are already
required to implement gpio_{request,free}() stubs.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-rw-r--r-- | Documentation/feature-removal-schedule.txt | 10 | ||||
-rw-r--r-- | Documentation/gpio.txt | 23 | ||||
-rw-r--r-- | drivers/gpio/gpiolib.c | 12 |
3 files changed, 27 insertions, 18 deletions
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index d0f354670646..a23361e80c64 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -255,6 +255,16 @@ Who: Jan Engelhardt <jengelh@computergmbh.de> | |||
255 | 255 | ||
256 | --------------------------- | 256 | --------------------------- |
257 | 257 | ||
258 | What: GPIO autorequest on gpio_direction_{input,output}() in gpiolib | ||
259 | When: February 2010 | ||
260 | Why: All callers should use explicit gpio_request()/gpio_free(). | ||
261 | The autorequest mechanism in gpiolib was provided mostly as a | ||
262 | migration aid for legacy GPIO interfaces (for SOC based GPIOs). | ||
263 | Those users have now largely migrated. Platforms implementing | ||
264 | the GPIO interfaces without using gpiolib will see no changes. | ||
265 | Who: David Brownell <dbrownell@users.sourceforge.net> | ||
266 | --------------------------- | ||
267 | |||
258 | What: b43 support for firmware revision < 410 | 268 | What: b43 support for firmware revision < 410 |
259 | When: The schedule was July 2008, but it was decided that we are going to keep the | 269 | When: The schedule was July 2008, but it was decided that we are going to keep the |
260 | code as long as there are no major maintanance headaches. | 270 | code as long as there are no major maintanance headaches. |
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index b1b988701247..145c25a170c7 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt | |||
@@ -123,7 +123,10 @@ platform-specific implementation issue. | |||
123 | 123 | ||
124 | Using GPIOs | 124 | Using GPIOs |
125 | ----------- | 125 | ----------- |
126 | One of the first things to do with a GPIO, often in board setup code when | 126 | The first thing a system should do with a GPIO is allocate it, using |
127 | the gpio_request() call; see later. | ||
128 | |||
129 | One of the next things to do with a GPIO, often in board setup code when | ||
127 | setting up a platform_device using the GPIO, is mark its direction: | 130 | setting up a platform_device using the GPIO, is mark its direction: |
128 | 131 | ||
129 | /* set as input or output, returning 0 or negative errno */ | 132 | /* set as input or output, returning 0 or negative errno */ |
@@ -141,8 +144,8 @@ This helps avoid signal glitching during system startup. | |||
141 | 144 | ||
142 | For compatibility with legacy interfaces to GPIOs, setting the direction | 145 | For compatibility with legacy interfaces to GPIOs, setting the direction |
143 | of a GPIO implicitly requests that GPIO (see below) if it has not been | 146 | of a GPIO implicitly requests that GPIO (see below) if it has not been |
144 | requested already. That compatibility may be removed in the future; | 147 | requested already. That compatibility is being removed from the optional |
145 | explicitly requesting GPIOs is strongly preferred. | 148 | gpiolib framework. |
146 | 149 | ||
147 | Setting the direction can fail if the GPIO number is invalid, or when | 150 | Setting the direction can fail if the GPIO number is invalid, or when |
148 | that particular GPIO can't be used in that mode. It's generally a bad | 151 | that particular GPIO can't be used in that mode. It's generally a bad |
@@ -195,7 +198,7 @@ This requires sleeping, which can't be done from inside IRQ handlers. | |||
195 | 198 | ||
196 | Platforms that support this type of GPIO distinguish them from other GPIOs | 199 | Platforms that support this type of GPIO distinguish them from other GPIOs |
197 | by returning nonzero from this call (which requires a valid GPIO number, | 200 | by returning nonzero from this call (which requires a valid GPIO number, |
198 | either explicitly or implicitly requested): | 201 | which should have been previously allocated with gpio_request): |
199 | 202 | ||
200 | int gpio_cansleep(unsigned gpio); | 203 | int gpio_cansleep(unsigned gpio); |
201 | 204 | ||
@@ -212,10 +215,9 @@ for GPIOs that can't be accessed from IRQ handlers, these calls act the | |||
212 | same as the spinlock-safe calls. | 215 | same as the spinlock-safe calls. |
213 | 216 | ||
214 | 217 | ||
215 | Claiming and Releasing GPIOs (OPTIONAL) | 218 | Claiming and Releasing GPIOs |
216 | --------------------------------------- | 219 | ---------------------------- |
217 | To help catch system configuration errors, two calls are defined. | 220 | To help catch system configuration errors, two calls are defined. |
218 | However, many platforms don't currently support this mechanism. | ||
219 | 221 | ||
220 | /* request GPIO, returning 0 or negative errno. | 222 | /* request GPIO, returning 0 or negative errno. |
221 | * non-null labels may be useful for diagnostics. | 223 | * non-null labels may be useful for diagnostics. |
@@ -244,13 +246,6 @@ Some platforms may also use knowledge about what GPIOs are active for | |||
244 | power management, such as by powering down unused chip sectors and, more | 246 | power management, such as by powering down unused chip sectors and, more |
245 | easily, gating off unused clocks. | 247 | easily, gating off unused clocks. |
246 | 248 | ||
247 | These two calls are optional because not not all current Linux platforms | ||
248 | offer such functionality in their GPIO support; a valid implementation | ||
249 | could return success for all gpio_request() calls. Unlike the other calls, | ||
250 | the state they represent doesn't normally match anything from a hardware | ||
251 | register; it's just a software bitmap which clearly is not necessary for | ||
252 | correct operation of hardware or (bug free) drivers. | ||
253 | |||
254 | Note that requesting a GPIO does NOT cause it to be configured in any | 249 | Note that requesting a GPIO does NOT cause it to be configured in any |
255 | way; it just marks that GPIO as in use. Separate code must handle any | 250 | way; it just marks that GPIO as in use. Separate code must handle any |
256 | pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown). | 251 | pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown). |
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 83c3fe3a136b..51a8d4103be5 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c | |||
@@ -69,20 +69,24 @@ static inline void desc_set_label(struct gpio_desc *d, const char *label) | |||
69 | * those calls have no teeth) we can't avoid autorequesting. This nag | 69 | * those calls have no teeth) we can't avoid autorequesting. This nag |
70 | * message should motivate switching to explicit requests... so should | 70 | * message should motivate switching to explicit requests... so should |
71 | * the weaker cleanup after faults, compared to gpio_request(). | 71 | * the weaker cleanup after faults, compared to gpio_request(). |
72 | * | ||
73 | * NOTE: the autorequest mechanism is going away; at this point it's | ||
74 | * only "legal" in the sense that (old) code using it won't break yet, | ||
75 | * but instead only triggers a WARN() stack dump. | ||
72 | */ | 76 | */ |
73 | static int gpio_ensure_requested(struct gpio_desc *desc, unsigned offset) | 77 | static int gpio_ensure_requested(struct gpio_desc *desc, unsigned offset) |
74 | { | 78 | { |
75 | if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) { | 79 | const struct gpio_chip *chip = desc->chip; |
76 | struct gpio_chip *chip = desc->chip; | 80 | const int gpio = chip->base + offset; |
77 | int gpio = chip->base + offset; | ||
78 | 81 | ||
82 | if (WARN(test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0, | ||
83 | "autorequest GPIO-%d\n", gpio)) { | ||
79 | if (!try_module_get(chip->owner)) { | 84 | if (!try_module_get(chip->owner)) { |
80 | pr_err("GPIO-%d: module can't be gotten \n", gpio); | 85 | pr_err("GPIO-%d: module can't be gotten \n", gpio); |
81 | clear_bit(FLAG_REQUESTED, &desc->flags); | 86 | clear_bit(FLAG_REQUESTED, &desc->flags); |
82 | /* lose */ | 87 | /* lose */ |
83 | return -EIO; | 88 | return -EIO; |
84 | } | 89 | } |
85 | pr_warning("GPIO-%d autorequested\n", gpio); | ||
86 | desc_set_label(desc, "[auto]"); | 90 | desc_set_label(desc, "[auto]"); |
87 | /* caller must chip->request() w/o spinlock */ | 91 | /* caller must chip->request() w/o spinlock */ |
88 | if (chip->request) | 92 | if (chip->request) |