BMC/Intel-BMC/linux.git/drivers/gpio, branch dev-4.6

Revert "HACK: gpio-aspeed: Request pins via pinctrl"

2016-07-21T15:05:11+00:00

This reverts commit 3ab5ce11fbc786236b0edf0c2344595455ac3d04. Signed-off-by: Joel Stanley

Revert "gpio-aspeed: Add offset to base on pinctrl_{request,free}_gpio()"

2016-07-21T15:04:59+00:00

This reverts commit 6e0489784e1d9ae0ec95ad77239a4cff3fa0b6ef. Signed-off-by: Joel Stanley

Merge tag 'v4.6.4' into dev-4.6

2016-07-12T10:03:22+00:00

This is the 4.6.4 stable release

gpio: make sure gpiod_to_irq() returns negative on NULL desc

2016-06-24T17:22:06+00:00

commit 79bb71bd1d93197ce227fa167b450b633f30a52b upstream. commit 54d77198fdfbc4f0fe11b4252c1d9c97d51a3264 ("gpio: bail out silently on NULL descriptors") doesn't work for gpiod_to_irq(): drivers assume that NULL descriptors will give negative IRQ numbers in return. It has been pointed out that returning 0 is NO_IRQ and that drivers should be amended to treat this as an error, but that is for the longer term: now let us repair the semantics. Cc: Maxime Ripard Reported-by: Hans de Goede Tested-by: Hans de Goede Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: zynq: initialize clock even without CONFIG_PM

2016-06-24T17:22:04+00:00

commit 0f84f29ff30bdb1bca23017b118b4ea3999cac32 upstream. When the PM initialization was moved in the commit referenced below, the code enabling the clock was removed from the probe function. On CONFIG_PM=y kernels, this is not a problem as the pm resume hook enables the clock, but when power management is disabled, all those pm_* functions are noops and the clock is never enabled resulting in a dysfunctional gpio controller. Put the clock initialization back to support CONFIG_PM=n. Signed-off-by: Helmut Grohne Fixes: 3773c195d387 ("gpio: zynq: Do PM initialization earlier to support gpio hogs") Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: zynq: Fix the error path

2016-06-24T17:22:04+00:00

commit 615d23f80efc60f8c5146223f305d19207c742e4 upstream. pm_runtime_disable is called only in remove it is missed out in the error path. Fix the same. Signed-off-by: Shubhrajyoti Datta Signed-off-by: Linus Walleij Cc: Helmut Grohne Signed-off-by: Greg Kroah-Hartman

gpiolib: Fix unaligned used of reference counters

2016-06-24T17:22:02+00:00

commit f4833b8cc7edab57d3f3033e549111a546c2e02b upstream. gpiolib relies on the reference counters to clean up the gpio_device structure. Although the number of get/put is properly aligned on gpiolib.c itself, it does not take into consideration how the referece counters are affected by other external functions such as cdev_add and device_add. Because of this, after the last call to put_device, the reference counter has a value of +3, therefore never calling gpiodevice_release. Due to the fact that some of the device has already been cleaned on gpiochip_remove, the library will end up OOPsing the kernel (e.g. a call to of_gpiochip_find_and_xlate). Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpiolib: Fix NULL pointer deference

2016-06-24T17:22:02+00:00

commit 11f33a6d15bfa397867ac0d7f3481b6dd683286f upstream. Under some circumstances, a gpiochip might be half cleaned from the gpio_device list. This patch makes sure that the chip pointer is still valid, before calling the match function. [ 104.088296] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [ 104.089772] IP: [] of_gpiochip_find_and_xlate+0x15/0x80 [ 104.128273] Call Trace: [ 104.129802] [] ? of_parse_own_gpio+0x1f0/0x1f0 [ 104.131353] [] gpiochip_find+0x60/0x90 [ 104.132868] [] of_get_named_gpiod_flags+0x9a/0x120 ... [ 104.141586] [] gpio_led_probe+0x11b/0x360 Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings

2016-06-24T17:22:02+00:00

commit b66b2a0adf0e48973b582e055758b9907a7eee7c upstream. The bcm_kona_gpio_reset() calls bcm_kona_gpio_write_lock_regs() with what looks like the wrong parameter. The write_lock_regs function takes a pointer to the registers, not the bcm_kona_gpio structure. Fix the warning, and probably bug by changing the function to pass reg_base instead of kona_gpio, fixing the following warning: drivers/gpio/gpio-bcm-kona.c:550:47: warning: incorrect type in argument 1 (different address spaces) expected void [noderef] *reg_base got struct bcm_kona_gpio *kona_gpio warning: incorrect type in argument 1 (different address spaces) expected void [noderef] *reg_base got struct bcm_kona_gpio *kona_gpio Signed-off-by: Ben Dooks Acked-by: Ray Jui Reviewed-by: Markus Mayer Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: bail out silently on NULL descriptors

2016-06-24T17:22:02+00:00

commit 54d77198fdfbc4f0fe11b4252c1d9c97d51a3264 upstream. In fdeb8e1547cb9dd39d5d7223b33f3565cf86c28e ("gpio: reflect base and ngpio into gpio_device") assumed that GPIO descriptors are either valid or error pointers, but gpiod_get_[index_]optional() actually return NULL descriptors and then all subsequent calls should just bail out. Cc: Sergei Shtylyov Cc: Florian Fainelli Cc: Andrew Lunn Fixes: fdeb8e1547cb ("gpio: reflect base and ngpio into gpio_device") Reported-by: Uwe Kleine-König Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman