summaryrefslogtreecommitdiffstats
path: root/include/linux/gpio.h
Commit message (Collapse)AuthorAgeFilesLines
* gpiolib: rename pin range argumentsLinus Walleij2012-11-211-1/+1
| | | | | | | | | | | | | To be crystal clear on what the arguments mean in this funtion dealing with both GPIO and PIN ranges with confusing naming, we now have gpio_offset and pin_offset and we are on the clear that these are offsets into the specific GPIO and pin controller respectively. The GPIO chip itself will of course keep track of the base offset into the global GPIO number space. Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpiolib: let gpiochip_add_pin_range() specify offsetLinus Walleij2012-11-211-1/+2
| | | | | | | | | | | | | | | | | | Like with commit 3c739ad0df5eb41cd7adad879eda6aa09879eb76 it is not always enough to specify all the pins of a gpio_chip from offset zero to be added to a pin map range, since the mapping from GPIO to pin controller may not be linear at all, but need to be broken into a few consecutive sub-ranges or 1-pin entries for complicated cases. The ranges may also be sparse. This alters the signature of the function to accept offsets into both the GPIO-chip local pinspace and the pin controller local pinspace. Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpiolib: iron out include ladder mistakesLinus Walleij2012-11-111-4/+3
| | | | | | | | | | | | | | | | | | | | | The <*/gpio.h> includes are updated again: now we need to account for the problem introduced by commit: 595679a8038584df7b9398bf34f61db3c038bfea "gpiolib: fix up function prototypes etc" Actually we need static inlines in include/asm-generic/gpio.h as well since we may have GPIOLIB but not PINCTRL. Make sure to move all the CONFIG_PINCTRL business to the end of the file so we are sure we have declared struct gpio_chip. And we need to keep the static inlines in <linux/gpio.h> but here for the !CONFIG_GENERIC_GPIO case, and then we may as well throw in a few warnings like the other prototypes there, if someone would have the bad taste of compiling without GENERIC_GPIO even. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpiolib: separation of pin concernsLinus Walleij2012-11-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fact that of_gpiochip_add_pin_range() and gpiochip_add_pin_range() share too much code is fragile and will invariably mean that bugs need to be fixed in two places instead of one. So separate the concerns of gpiolib.c and gpiolib-of.c and have the latter call the former as back-end. This is necessary also when going forward with other device descriptions such as ACPI. This is done by: - Adding a return code to gpiochip_add_pin_range() so we can reliably check whether this succeeds. - Get rid of the custom of_pinctrl_add_gpio_range() from pinctrl. Instead create of_pinctrl_get() to just retrive the pin controller per se from an OF node. This composite function was just begging to be deleted, it was way to purpose-specific. - Use pinctrl_dev_get_name() to get the name of the retrieved pin controller and use that to call back into the generic gpiochip_add_pin_range(). Now the pin range is only allocated and tied to a pin controller from the core implementation in gpiolib.c. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpiolib: fix up function prototypes etcLinus Walleij2012-11-111-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | Commit 69e1601bca88809dc118abd1becb02c15a02ec71 "gpiolib: provide provision to register pin ranges" Got most of it's function prototypes wrong, so fix this up by: - Moving the void declarations into static inlines in <linux/gpio.h> (previously the actual prototypes were declared here...) - Declare the gpiochip_add_pin_range() and gpiochip_remove_pin_ranges() functions in <asm-generic/gpio.h> together with the pin range struct declaration itself. - Actually only implement these very functions in gpiolib.c if CONFIG_PINCTRL is set. - Additionally export the symbols since modules will need to be able to do this. Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpiolib: provide provision to register pin rangesShiraz Hashim2012-11-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | pinctrl subsystem needs gpio chip base to prepare set of gpio pin ranges, which a given pinctrl driver can handle. This is important to handle pinctrl gpio request calls in order to program a given pin properly for gpio operation. As gpio base is allocated dynamically during gpiochip registration, presently there exists no clean way to pass this information to the pinctrl subsystem. After few discussions from [1], it was concluded that may be gpio controller reporting the pin range it supports, is a better way than pinctrl subsystem directly registering it. [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816 Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com> [Edited documentation a bit] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpio: fix bits conflict for gpio flagsLaxman Dewangan2012-07-051-2/+2
| | | | | | | | | | | | The bit 2 and 3 in GPIO flag are allocated for the flag OPEN_DRAIN/OPEN_SOURCE. These bits are reused for the flag EXPORT/EXPORT_CHANGEABLE and so creating conflict. Fix this conflict by assigning bit 4 and 5 for the flag EXPORT/EXPORT_CHANGEABLE. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* gpiolib: Implement devm_gpio_request_one()Mark Brown2012-05-181-0/+6
| | | | | | | | | | | | | | | | | Allow drivers to use the modern request and configure idiom together with devres. As with plain gpio_request() and gpio_request_one() we can't implement the old school version in terms of _one() as this would force the explicit selection of a direction in gpio_request() which could break systems if we pick the wrong one. Implementing devm_gpio_request_one() in terms of devm_gpio_request() would needlessly complicate things or lead to duplication from the unmanaged version depending on how it's done. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* gpiolib/arches: Centralise bolierplate asm/gpio.hMark Brown2012-05-111-0/+34
| | | | | | | | | | | | | | | | | | | | | Rather than requiring architectures that use gpiolib but don't have any need to define anything custom to copy an asm/gpio.h provide a Kconfig symbol which architectures must select in order to include gpio.h and for other architectures just provide the trivial implementation directly. This makes it much easier to do gpiolib updates and is also a step towards making gpiolib APIs available on every architecture. For architectures with existing boilerplate code leave a stub header in place which warns on direct inclusion of asm/gpio.h and includes linux/gpio.h to catch code that's doing this. Direct inclusion of asm/gpio.h has long been deprecated. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Jonas Bonn <jonas@southpole.se> Acked-by: Tony Luck <tony.luck@intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* gpiolib: Add !CONFIG_GPIOLIB definitions of devm_ functionsMark Brown2012-04-051-0/+14
| | | | | | | | Currently the managed gpio_request() and gpio_free() are not stubbed out for configurations not using gpiolib - do that to aid use in drivers. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* gpio: add flags to export GPIOs when requestingWolfram Sang2012-04-051-0/+5
| | | | | | | | | | Introduce new flags to automatically export GPIOs when using the convenience functions gpio_request_one() or gpio_request_array(). This eases support for custom boards where lots of GPIOs need to be exported for customer applications. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6Linus Torvalds2012-03-281-0/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull GPIO changes for v3.4 from Grant Likely: "Primarily gpio device driver changes with some minor side effects under arch/arm and arch/x86. Also includes a few core changes such as explicitly supporting (electrical) open source and open drain outputs and some help for parsing gpio devicetree properties." Fix up context conflict due to Laxman Dewangan adding sleep control for the tps65910 driver separately for gpio's and regulators. * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6: (34 commits) gpio/ep93xx: Remove unused inline function and useless pr_err message gpio/sodaville: Mark broken due to core irqdomain migration gpio/omap: fix redundant decoding of gpio offset gpio/omap: fix incorrect update to context.irqenable1 gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_* gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg gpio/omap: fix _set_gpio_irqenable implementation gpio/omap: fix trigger type to unsigned gpio/omap: fix wakeup_en register update in _set_gpio_wakeup() gpio: tegra: tegra_gpio_config shouldn't be __init gpio/davinci: fix enabling unbanked GPIO IRQs gpio/davinci: fix oops on unbanked gpio irq request gpio/omap: Fix section warning for omap_mpuio_alloc_gc() ARM: tegra: export tegra_gpio_{en,dis}able gpio/gpio-stmpe: Fix the value returned by _get_value routine Documentation/gpio.txt: Explain expected pinctrl interaction GPIO: LPC32xx: Add output reading to GPO P3 GPIO: LPC32xx: Fix missing bit selection mask gpio/omap: fix wakeups on level-triggered GPIOs gpio/omap: Fix IRQ handling for SPARSE_IRQ ...
| * gpio: gpiolib: Support for open source/emitter gpiosLaxman Dewangan2012-03-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding support for the open source gpio on which client can specify the open source property through GPIO flag GPIOF_OPEN_SOURCE at the time of gpio request. The open source pins are normally pulled low and it cannot be driven to output with value of 0 and so when client request for setting the pin to LOW, the gpio will be set to input direction to make pin in tristate and hence PULL-DOWN on pins will make the state to LOW. The open source pin can be driven to HIGH by setting output with value of 1. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
| * gpio: gpiolib: Support for open drain/collector gpiosLaxman Dewangan2012-03-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding support for the open drain gpio on which client can specify the open drain property through GPIO flag GPIOF_OPEN_DRAIN at the time of gpio request. The open drain pins are normally pulled high and it cannot be driven to output with value of 1 and so when client request for setting the pin to HIGH, the gpio will be set to input direction to make pin in tristate and hence PULL-UP on pins will make the state to HIGH. The open drain pin can be driven to LOW by setting output with value of 0. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* | BUG: headers with BUG/BUG_ON etc. need linux/bug.hPaul Gortmaker2012-03-041-0/+1
|/ | | | | | | | | | | | | If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any other BUG variant in a static inline (i.e. not in a #define) then that header really should be including <linux/bug.h> and not just expecting it to be implicitly present. We can make this change risk-free, since if the files using these headers didn't have exposure to linux/bug.h already, they would have been causing compile failures/warnings. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* gpiolib: Ensure struct gpio is always definedMark Brown2011-10-241-10/+12
| | | | | | | | | | | | Currently struct gpio is only defined when using gpiolib which makes the stub gpio_request_array() much less useful in drivers than is ideal as they can't work with struct gpio. Since there are no other definitions in kernel instead make the define always available no matter if gpiolib is selectable or selected, ensuring that drivers can always use the type. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* gpio: add GPIOF_ values regardless on kconfig settingsRandy Dunlap2011-06-161-0/+11
| | | | | | | | | | | | Make GPIOF_ defined values available even when GPIOLIB nor GENERIC_GPIO is enabled by moving them to <linux/gpio.h>. Fixes these build errors in linux-next: sound/soc/codecs/ak4641.c:524: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function) sound/soc/codecs/wm8915.c:2921: error: 'GPIOF_OUT_INIT_LOW' undeclared (first use in this function) Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* gpio: make gpio_{request,free}_array gpio array parameter constLars-Peter Clausen2011-05-271-2/+2
| | | | | | | | | | | gpio_{request,free}_array should not (and do not) modify the passed gpio array, so make the parameter const. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Eric Miao <eric.y.miao@gmail.com> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* gpio: Convert gpio_is_valid to return boolJoe Perches2011-05-261-2/+2
| | | | | | | | | | | | | | Make the code a bit more readable. Instead of casting an int to an unsigned then comparing to MAX_NR_GPIOS, add a >= 0 test and let the compiler optimizer do the conversion to unsigned. The generated code should be the same. Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* include/gpio.h: remove remaining __must_check-annotiationsWolfram Sang2011-01-141-2/+2
| | | | | | | | | | Commit 5f829e405ec4e96f711165a4a7b55c271d4363e2 (gpiolib: add missing functions to generic fallback) also introduced two. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Cc: Greg KH <gregkh@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Revert "gpiolib: annotate gpio-intialization with __must_check"Linus Torvalds2011-01-131-3/+3
| | | | | | | | | | | | | | | | | This reverts commit 0fdae42d361bbb431ca0ab0efed5126a94821177, which wasn't really supposed to go in, and causes lots of annoying warnings. Quoth Andrew: "Complete brainfart - I meant to drop that patch ages ago." Quoth Greg: "Ick, yeah, that patch isn't ok to go in as-is, all of the callers need to be fixed up first, which is what I thought we had agreed on..." Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Greg KH <greg@kroah.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* gpiolib: add missing functions to generic fallbackWolfram Sang2011-01-131-0/+20
| | | | | | | | Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Greg KH <gregkh@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* gpiolib: annotate gpio-intialization with __must_checkWolfram Sang2011-01-131-3/+3
| | | | | | | | | | | | | | Because GPIOs can have crucial functions especially in embedded systems, we are better safe than sorry regarding their configuration. For gpio_request, the documentation is simply enforced: <quote>"The return value of gpio_request() must be checked."</quote> For gpio_direction_* and gpio_request_*, we now act accordingly. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Greg KH <gregkh@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* gpiolib: Add 'struct gpio_chip' forward declaration for !GPIOLIB caseAnton Vorontsov2010-09-011-0/+1
| | | | | | | | | | | | | | | | | | | | | With CONFIG_GPIOLIB=n, the 'struct gpio_chip' is not declared, so the following pops up on PowerPC: cc1: warnings being treated as errors In file included from arch/powerpc/platforms/52xx/mpc52xx_common.c:19: include/linux/of_gpio.h:74: warning: 'struct gpio_chip' declared inside parameter list include/linux/of_gpio.h:74: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/of_gpio.h:75: warning: 'struct gpio_chip' declared inside parameter list make[2]: *** [arch/powerpc/platforms/52xx/mpc52xx_common.o] Error 1 This patch fixes the issue by providing the proper forward declaration. Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* gpiolib: introduce set_debounce methodFelipe Balbi2010-05-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A few architectures, like OMAP, allow you to set a debouncing time for the gpio before generating the IRQ. Teach gpiolib about that. Mark said: : This would be generally useful for embedded systems, especially where : the interrupt concerned is a wake source. It allows drivers to avoid : spurious interrupts from noisy sources so if the hardware supports it : the driver can avoid having to explicitly wait for the signal to become : stable and software has to cope with fewer events. We've lived without : it for quite some time, though. David said: : I looked at adding debounce support to the generic GPIO calls (and thus : gpiolib) some time back, but decided against it. I forget why at this : time (check list archives) but it wasn't because of lack of utility in : certain contexts. : : One thing to watch out for is just how variable the hardware capabilities : are. Atmel GPIOs have something like a fixed number of 32K clock cycles : for debounce, twl4030 had something odd, OMAPs were more like the Atmel : chips but with a different clock. In some cases debouncing had to be : ganged, not per-GPIO. And so forth. Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com> Cc: Tony Lindgren <tony@atomide.com> Cc: David Brownell <david-b@pacbell.net> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* gpiolib: add support for changing value polarity in sysfsJani Nikula2009-12-161-0/+6
| | | | | | | | | | | | | Drivers may use gpiolib sysfs as part of their public user space interface. The GPIO number and polarity might change from board to board. The gpio_export_link() call can be used to hide the GPIO number from user space. Add support for also hiding the GPIO line polarity changes from user space. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* gpiolib: allow exported GPIO nodes to be named using sysfs linksJani Nikula2009-09-231-0/+11
| | | | | | | | | | | | | | | | | | Commit 926b663ce8215ba448960e1ff6e58b67a2c3b99b (gpiolib: allow GPIOs to be named) already provides naming on the chip level. This patch provides more flexibility by allowing multiple names where ever in sysfs on a per GPIO basis. Adapted from David Brownell's comments on a similar concept: http://lkml.org/lkml/2009/4/20/203. [randy.dunlap@oracle.com: fix build for CONFIG_GENERIC_GPIO=n] Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: David Brownell <david-b@pacbell.net> Cc: Daniel Silverstone <dsilvers@simtec.co.uk> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* gpio_free might sleep, generic partUwe Kleine-König2008-10-161-0/+3
| | | | | | | | | | | | | | According to the documentation gpio_free should only be called from task context only. To make this more explicit add a might sleep to all implementations. This is the generic part which changes gpiolib and the fallback implementation only. Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* gpio: sysfs interfaceDavid Brownell2008-07-251-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a simple sysfs interface for GPIOs. /sys/class/gpio /export ... asks the kernel to export a GPIO to userspace /unexport ... to return a GPIO to the kernel /gpioN ... for each exported GPIO #N /value ... always readable, writes fail for input GPIOs /direction ... r/w as: in, out (default low); write high, low /gpiochipN ... for each gpiochip; #N is its first GPIO /base ... (r/o) same as N /label ... (r/o) descriptive, not necessarily unique /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1) GPIOs claimed by kernel code may be exported by its owner using a new gpio_export() call, which should be most useful for driver debugging. Such exports may optionally be done without a "direction" attribute. Userspace may ask to take over a GPIO by writing to a sysfs control file, helping to cope with incomplete board support or other "one-off" requirements that don't merit full kernel support: echo 23 > /sys/class/gpio/export ... will gpio_request(23, "sysfs") and gpio_export(23); use /sys/class/gpio/gpio-23/direction to (re)configure it, when that GPIO can be used as both input and output. echo 23 > /sys/class/gpio/unexport ... will gpio_free(23), when it was exported as above The extra D-space footprint is a few hundred bytes, except for the sysfs resources associated with each exported GPIO. The additional I-space footprint is about two thirds of the current size of gpiolib (!). Since no /dev node creation is involved, no "udev" support is needed. Related changes: * This adds a device pointer to "struct gpio_chip". When GPIO providers initialize that, sysfs gpio class devices become children of that device instead of being "virtual" devices. * The (few) gpio_chip providers which have such a device node have been updated. * Some gpio_chip drivers also needed to update their module "owner" field ... for which missing kerneldoc was added. * Some gpio_chips don't support input GPIOs. Those GPIOs are now flagged appropriately when the chip is registered. Based on previous patches, and discussion both on and off LKML. A Documentation/ABI/testing/sysfs-gpio update is ready to submit once this merges to mainline. [akpm@linux-foundation.org: a few maintenance build fixes] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* gpio: build fixesDavid Brownell2008-05-241-0/+3
| | | | | | | | | | | | This fixes various gpio-related build errors (mostly potential) reported in part by Russell King and Uwe Kleine-König. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* gpio: <linux/gpio.h> and "no GPIO support here" stubsDavid Brownell2008-03-041-0/+95
Add a <linux/gpio.h> defining fail/warn stubs for GPIO calls on platforms that don't support the GPIO programming interface. That includes the arch-specific implementation glue otherwise. This facilitates a new model for GPIO usage: drivers that can use GPIOs if they're available, but don't require them. One example of such a driver is NAND driver for various FreeScale chips. On platforms update with GPIO support, they can be used instead of a worst-case delay to verify that the BUSY signal is off. (Also includes a couple minor unrelated doc updates.) 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 18:15:53 +0000