linux-stable.git/include/linux/gpio/driver.h, branch linux-4.5.y

gpio: generic: make bgpio_pdata always visible

2016-01-13T15:00:32+00:00

Board files that define their own bgpio_pdata are broken when
CONFIG_GPIO_GENERIC is disabled and the bgpio_pdata structure
definition is hidden by the #ifdef:

arch/arm/mach-clps711x/board-autcpu12.c:148:15: error: variable 'autcpu12_mmgpio_pdata' has initializer but incomplete type
 static struct bgpio_pdata autcpu12_mmgpio_pdata __initdata = {
arch/arm/mach-clps711x/board-autcpu12.c:149:2: error: unknown field 'base' specified in initializer
  .base = AUTCPU12_MMGPIO_BASE,

Since the board files should generally not care what drivers are
enabled, this makes the structure definition visible again.

Signed-off-by: Arnd Bergmann 
Fixes: 0f4630f3720e ("gpio: generic: factor into gpio_chip struct")
Signed-off-by: Linus Walleij

gpio: generic: factor into gpio_chip struct

2016-01-05T10:21:00+00:00

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
, #ifdef:ed for CONFIG_GENERIC_GPIO, and
get rid of the  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 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Kukjin Kim 
Cc: Alexandre Courbot 
Cc: Brian Norris 
Cc: Florian Fainelli 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Nicolas Pitre 
Cc: Olof Johansson 
Cc: Vladimir Zapolskiy 
Cc: Rabin Vincent 
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: Gregory Fong 
Acked-by: Liviu Dudau 
Acked-by: H Hartley Sweeten 
Acked-by: Tony Lindgren 
Acked-by: Krzysztof Kozlowski 
Acked-by: Lee Jones 
Signed-off-by: Linus Walleij

gpio: add a data pointer to gpio_chip

2016-01-05T10:20:12+00:00

This adds a void * pointer to gpio_chip so that driver can
assign and retrieve some states. This is done to get rid of
container_of() calls for gpio_chips embedded inside state
containers, so we can remove the need to have the gpio_chip
or later (planned) struct gpio_device be dynamically allocated
at registration time, so that its struct device can be properly
reference counted and not bound to its parent device (e.g.
a platform_device) but instead live on after unregistration
if it is opened by e.g. a char device or sysfs.

The data is added with the new function gpiochip_add_data()
and for compatibility we add static inline wrapper function
gpiochip_add() that will call gpiochip_add_data() with
NULL as argument. The latter will be removed once we have
exorcised gpiochip_add() from the kernel.

gpiochip_get_data() is added as a static inline accessor
for drivers to quickly get their data out.

Signed-off-by: Linus Walleij

gpio: update gpiochip .get() callback description

2015-12-26T21:28:43+00:00

Since gpiochip .get() callback may return a negative error value, it
strictly limits the range of possible non-error returned values to
a subset of [30:0] bitmask, however on practice on success all
gpiochip drivers return either 0 for low signal or 1 for high signal,
this is assured by "gpio: *: Be sure to clamp return value" series of
changes. To avoid any confusion, misinterpretation and potential
errors while developing gpiochip drivers in future convert this
implicit assumption to a mandatory rule.

For output signals with unknown output signal state gpiochip drivers
should return a negative error instead of 0.

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Linus Walleij

gpio: change member .dev to .parent

2015-11-19T08:24:35+00:00

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 
Cc: Rafał Miłecki 
Cc: Richard Purdie 
Cc: Mauro Carvalho Chehab 
Cc: Alek Du 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Acked-by: Dmitry Torokhov 
Acked-by: Greg Kroah-Hartman 
Acked-by: Lee Jones 
Acked-by: Jiri Kosina 
Acked-by: Hans-Christian Egtvedt 
Acked-by: Jacek Anaszewski 
Signed-off-by: Linus Walleij

gpiolib: provide generic request/free implementations

2015-10-16T20:11:16+00:00

Provide generic request/free implementations that pinctrl aware gpio
drivers can use instead of open coding if they use a 1:1 pin to gpio
signal mapping.

Signed-off-by: Jonas Gorski 
Signed-off-by: Linus Walleij

gpiolib: add description for gpio irqchip fields in struct gpio_chip

2015-08-26T07:29:50+00:00

Add missed description for GPIO irqchip fields in struct gpio_chip.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Linus Walleij

gpiolib: irqchip: use different lockdep class for each gpio irqchip

2015-08-17T13:32:03+00:00

Since IRQ chip helpers were introduced drivers lose ability to
register separate lockdep classes for each registered GPIO IRQ
chip and the gpiolib now is using shared lockdep class for
all GPIO IRQ chips (gpiochip_irq_lock_class).
As result, lockdep will produce warning when there are min two
stacked GPIO chips and all of them are interrupt controllers.

HW configuration which generates lockdep warning (TI dra7-evm):

[SOC GPIO bankA.gpioX]
  <- irq - [pcf875x.gpioY]
            <- irq - DevZ.enable_irq_wake(pcf_gpioY_irq);
The issue was reported in [1] and discussed [2].

=============================================
[ INFO: possible recursive locking detected ]
4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted
---------------------------------------------
sh/63 is trying to acquire lock:
 (class){......}, at: [] __irq_get_desc_lock+0x50/0x94

but task is already holding lock:
 (class){......}, at: [] __irq_get_desc_lock+0x50/0x94

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(class);
  lock(class);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

7 locks held by sh/63:
 #0:  (sb_writers#4){.+.+.+}, at: [] vfs_write+0x13c/0x164
 #1:  (&of->mutex){+.+.+.}, at: [] kernfs_fop_write+0x4c/0x1a0
 #2:  (s_active#36){.+.+.+}, at: [] kernfs_fop_write+0x54/0x1a0
 #3:  (pm_mutex){+.+.+.}, at: [] pm_suspend+0xec/0x4c4
 #4:  (&dev->mutex){......}, at: [] __device_suspend+0xd4/0x398
 #5:  (&gpio->lock){+.+.+.}, at: [] __irq_get_desc_lock+0x74/0x94
 #6:  (class){......}, at: [] __irq_get_desc_lock+0x50/0x94

stack backtrace:
CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55
Hardware name: Generic DRA74X (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x84/0x9c)
[] (dump_stack) from [] (__lock_acquire+0x19c0/0x1e20)
[] (__lock_acquire) from [] (lock_acquire+0xa8/0x128)
[] (lock_acquire) from [] (_raw_spin_lock_irqsave+0x38/0x4c)
[] (_raw_spin_lock_irqsave) from [] (__irq_get_desc_lock+0x50/0x94)
[] (__irq_get_desc_lock) from [] (irq_set_irq_wake+0x20/0xfc)
[] (irq_set_irq_wake) from [] (pcf857x_irq_set_wake+0x24/0x54)
[] (pcf857x_irq_set_wake) from [] (irq_set_irq_wake+0x8c/0xfc)
[] (irq_set_irq_wake) from [] (gpio_keys_suspend+0x70/0xd4)
[] (gpio_keys_suspend) from [] (dpm_run_callback+0x50/0x124)
[] (dpm_run_callback) from [] (__device_suspend+0x10c/0x398)
[] (__device_suspend) from [] (dpm_suspend+0x134/0x2f4)
[] (dpm_suspend) from [] (suspend_devices_and_enter+0xa8/0x728)
[] (suspend_devices_and_enter) from [] (pm_suspend+0x32c/0x4c4)
[] (pm_suspend) from [] (state_store+0x64/0xb8)
[] (state_store) from [] (kernfs_fop_write+0xbc/0x1a0)
[] (kernfs_fop_write) from [] (__vfs_write+0x20/0xd8)
[] (__vfs_write) from [] (vfs_write+0x90/0x164)
[] (vfs_write) from [] (SyS_write+0x44/0x9c)
[] (SyS_write) from [] (ret_fast_syscall+0x0/0x54)

Lets fix it by using separate lockdep class for each registered GPIO
IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros.

The implementation of this patch inspired by solution done by Nicolas
Boichat for regmap [3]

[1] http://www.spinics.net/lists/linux-gpio/msg05844.html
[2] http://www.spinics.net/lists/linux-gpio/msg06021.html
[3] http://www.spinics.net/lists/arm-kernel/msg429834.html

Cc: Geert Uytterhoeven 
Cc: Roger Quadros 
Reported-by: Roger Quadros 
Tested-by: Roger Quadros 
Signed-off-by: Grygorii Strashko 
Signed-off-by: Linus Walleij

gpio: Remove double "base" in comment

2015-07-15T22:12:24+00:00

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Walleij

gpio: discourage passing base to gpio_chip

2015-05-14T10:19:48+00:00

Passing a fixed base in struct gpio_chip is done for legacy
systems that cannot handle dynamic allocation. Discourage this
behaviour in the kerneldoc.

Acked-by: Alexandre Courbot 
Signed-off-by: Linus Walleij