This patch adds support for defining memory-mapped GPIOs which
are compatible with the existing gpio-mmio interface. The generic
library provides support for many memory-mapped GPIO controllers
that are found in various on-board FPGA and ASIC solutions that
are used to control board's switches, LEDs, chip-selects,
Ethernet/USB PHY power, etc.

For setting GPIOs there are three configurations:
	1. single input/output register resource (named "dat"),
	2. set/clear pair (named "set" and "clr"),
	3. single output register resource and single input resource
	   ("set" and dat").

The configuration is detected by which resources are present.
For the single output register, this drives a 1 by setting a bit
and a zero by clearing a bit.  For the set clr pair, this drives
a 1 by setting a bit in the set register and clears it by setting
a bit in the clear register.

For setting the GPIO direction, there are three configurations:
	a. simple bidirectional GPIOs that requires no configuration.
	b. an output direction register (named "dirout")
	   where a 1 bit indicates the GPIO is an output.
	c. an input direction register (named "dirin")
	   where a 1 bit indicates the GPIO is an input.
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch renames the gpio-generic.c into gpio-mmio.c.
This is because currently the file only contains code
for a memory-mapped GPIO driver. There isn't any support
for ioports or other resource type.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

GPIO_GENERIC_PLATFORM is a tristate. If the module option is
selected the resulting gpio-generic.ko will lack most of the
module initialzation and probe code.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>

The separate struct bgpio_chip has been a pain to handle, both
by being confusingly similar in name to struct gpio_chip and
for being contained inside a struct so that struct gpio_chip
is contained in a struct contained in a struct, making several
steps of dereferencing necessary.

Make things simpler: include the fields directly into
<linux/gpio/driver.h>, #ifdef:ed for CONFIG_GENERIC_GPIO, and
get rid of the <linux/basic_mmio_gpio.h> altogether. Prefix
some of the member variables with bgpio_* and add proper
kerneldoc while we're at it.

Modify all users to handle the change and use a struct
gpio_chip directly. And while we're at it: replace all
container_of() dereferencing by gpiochip_get_data() and
registering the gpio_chip with gpiochip_add_data().

Cc: arm@kernel.org
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: Rabin Vincent <rabin@rab.in>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: bcm-kernel-feedback-list@broadcom.com
Acked-by: NGregory Fong <gregory.0xf0@gmail.com>
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

cppcheck reports this:

(style) int result is returned as long value. If the return
value is long to avoid loss of information, then you have
loss of information.

This can be fixed with (1UL << pin) but that is the same
as using <linux/bitops.h> that already use 1UL so take
this approach.
Reported-by: NDavid Binderman <dcb314@hotmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The bgpio_get_set() call should return a value clamped to [0,1],
the current code will return a negative value if reading
bit 31, which turns the value negative as this is a signed value
and thus gets interpreted as an error by the gpiolib core.
Found on the gpio-mxc but applies to any MMIO driver.

Cc: stable@vger.kernel.org # 4.3+
Cc: kernel@pengutronix.de
Cc: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Fixes:  e20538b8 ("gpio: Propagate errors from chip->get()")
Reported-by: NClemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The name .dev in a struct is normally reserved for a struct device
that is let us say a superclass to the thing described by the struct.
struct gpio_chip stands out by confusingly using a struct device *dev
to point to the parent device (such as a platform_device) that
represents the hardware. As we want to give gpio_chip:s real devices,
this is not working. We need to rename this member to parent.

This was done by two coccinelle scripts, I guess it is possible to
combine them into one, but I don't know such stuff. They look like
this:

@@
struct gpio_chip *var;
@@
-var->dev
+var->parent

and:

@@
struct gpio_chip var;
@@
-var.dev
+var.parent

and:

@@
struct bgpio_chip *var;
@@
-var->gc.dev
+var->gc.parent

Plus a few instances of bgpio that I couldn't figure out how
to teach Coccinelle to rewrite.

This patch hits all over the place, but I *strongly* prefer this
solution to any piecemal approaches that just exercise patch
mechanics all over the place. It mainly hits drivers/gpio and
drivers/pinctrl which is my own backyard anyway.

Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Alek Du <alek.du@intel.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Returning an error instead of NULL in bgpio_map if
platform_get_resource_byname does not find a resource was introduced with
commit cf3f2a2c ("gpio: generic: improve error handling in bgpio_map").
This results in several qemu runtime failures with default and non-default
configurations, if attempts are made to boot from mmcblk0. Examples for
failures with multi_v7_defconfig are

Machine: vexpress-a9	dtb: vexpress-v2p-ca9
Machine: vexpress-a15	dtb: vexpress-v2p-ca15-tc1

Crash:

VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Looking into the code, always returning an error if bgpio_map fails
does not appear to make much sense, since the code in bgpio_setup_io
specifically supports some of the resources to be NULL.

Fixes: cf3f2a2c ("gpio: generic: improve error handling in bgpio_map")
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use the ERRPTR standard way to return an error code in a pointer
thus simplifiying the code.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Replace devm_request_mem_region / devm_ioremap with devm_ioremap_resource.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If bgpio_map returns NULL then err should always be set.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Allow chips to indicates that they are input-only and thus cannot set
the output value.  This will be used by the gpio-etraxfs driver.
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Allow to determine the current direction configuration by
reading back from the direction register.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The change introduces BGPIOF_READ_OUTPUT_REG_SET flag for gpio-generic
GPIO chip implementation, which allows to get correct configured value
from reg_set register, input value is still get from reg_dat.
Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add set_multiple functions to the generic driver for memory-mapped GPIO
controllers to improve performance when setting multiple outputs
simultaneously.
Signed-off-by: NRojhalat Ibrahim <imr@rtschenk.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Signed-off-by: Nabdoulaye berthe <berthe.ab@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

gpiolib will require all gpio drivers to expicitly set the request
function pointer in the future. To encourage gpio driver developers
to adhere to this standard gpio-generic.c now sets this function
pointer.
Signed-off-by: NAnthony Fee <anthony.fee@emutex.com>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The generic GPIO would return 0 for low generic GPIO, and
something != 0 for high GPIO. Let's make this sane by clamping
the returned value to [0,1].
Reported-by: NEvgeny Boger <boger@contactless.ru>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When registering more than one platform device, it is
useful to set the gpio chip label in the platform data.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Memory for basic-mmio-gpio driver is allocated by the driver
using it, whether it's the generic GPIO driver itself or another
driver. In either case, the owner shall allocate and free the
struct bgpio_chip it is using, preferably using a managed
resource.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There is no general support for 64-bit big endian accesses, so that is
left unsupported.
Signed-off-by: NAndreas Larsson <andreas@gaisler.com>
Acked-by: NAnton Vorontsov <anton@enomsg.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Grant Likely <grant.likely@secretlab.ca>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Peter Tyser <ptyser@xes-inc.com>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Peter Tyser <ptyser@xes-inc.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It fixes the issue in gpio-generic that commit fb149218 (gpio/mxc: add
missing initialization of basic_mmio_gpio shadow variables) manged to
fix in gpio-mxc driver, so that other platform specific drivers do not
suffer from the same problem over and over again.

Changes since v1:
* Turn the last parameter of bgpio_init() "bool big_endian" into
  "unsigned long flags" and give those really quirky hardwares a
  chance to tell that reg_set and reg_dir are unreadable.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
[grant.likely: Fix big-endian usage to explicitly set BBGPIOF_BIG_ENDIAN]
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Where appropriate factor out some boilerplate code for platform device
registration into module_platform_driver. Drivers that don't use the
standard module_init initcall haven't been converted.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Building a kernel with hotplug disabled results in a link failure:

  `bgpio_remove' referenced in section `___ksymtab_gpl+bgpio_remove' of drivers/built-in.o: defined in discarded section `.devexit.text' of drivers/built-in.o

This is because of bgpio_remove() is exported.  It is illegal to export
symbols which are discarded either at link time or as part of an
init/exit section.

Fix this by dropping the __devexit attributation from bgpio_remove().
Also drop the __devinit attributation from bgpio_init().
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Sort the gpio makefile and enforce the naming convention gpio-*.c for
gpio drivers.

v2: cleaned up filenames in Kconfig and comment blocks
v3: fixup use of BASIC_MMIO to GENERIC_GPIO for mxc
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Allow GPIO_BASIC_MMIO_CORE to be used to provide an accessor library
for implementing GPIO drivers whilst abstracting the register access
detail.  Based on a patch from Anton Vorontsov[1] and adapted to allow
bgpio_chip to be embedded in another structure.

Changes since v1:
	- Register the gpio_chip in the platform device probe

1. https://lkml.org/lkml/2011/4/19/401Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The __raw_* accessors don't include memory barriers and can cause
problems when writes get stuck in write buffers.
Suggested-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Most controllers require the direction of a GPIO to be set by writing to
a direction register.  Add support for either an input direction
register or an output direction register.
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Some controllers have separate input and output registers.  For these
controllers, use "set" for the output and "dat" for the input.

Changes since v2: reuse "set" for output and "dat" for input rather than
adding a new "in" register.
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Rather than detecting the output method each time in the .set()
callback, do it at probe time and set the appropriate callback.

Changes since v2: moved the reg_dat initialization into
bgpio_setup_io().
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Make sure that we get the register regions with request_mem_region()
before ioremap() to make sure we have exclusive access.
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Some platforms may have a number of GPIO that is less than the register
width of the peripheral.
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Use the platform drvdata helpers rather than working on the struct
device itself.
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Remove endianness/width calculations at runtime by installing function
pointers for bit-to-mask conversion and register accessors.
Reported-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The basic GPIO controllers may be found in various on-board FPGA and ASIC
solutions that are used to control board's switches, LEDs, chip-selects,
Ethernet/USB PHY power, etc.

These controllers may not provide any means of pin setup
(in/out/open drain).

The driver supports:
- 8/16/32/64 bits registers;
- GPIO controllers with clear/set registers;
- GPIO controllers with a single "data" register;
- Big endian bits/GPIOs ordering (mostly used on PowerPC).
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>