kernel/linux.git/drivers/gpio, branch v3.18.62

gpio: Fix OF build problem on UM

2016-09-01T02:05:44+00:00

[ Upstream commit 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 ] The UserMode (UM) Linux build was failing in gpiolib-of as it requires ioremap()/iounmap() to exist, which is absent from UM. The non-existence of IO memory is negatively defined as CONFIG_NO_IOMEM which means we need to depend on HAS_IOMEM. Cc: stable@vger.kernel.org Cc: Geert Uytterhoeven Reported-by: kbuild test robot Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpio: intel-mid: Remove potentially harmful code

2016-08-22T16:23:16+00:00

[ Upstream commit 3dbd3212f81b2b410a34a922055e2da792864829 ] The commit d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support") doesn't look at all as a proper support for Intel Merrifield and I dare to say that it distorts the behaviour of the hardware. The register map is different on Intel Merrifield, i.e. only 6 out of 8 register have the same purpose but none of them has same location in the address space. The current case potentially harmful to existing hardware since it's poking registers on wrong offsets and may set some pin to be GPIO output when connected hardware doesn't expect such. Besides the above GPIO and pinctrl on Intel Merrifield have been located in different IP blocks. The functionality has been extended as well, i.e. added support of level interrupts, special registers for wake capable sources and thus, in my opinion, requires a completele separate driver. If someone wondering the existing gpio-intel-mid.c would be converted to actual pinctrl (which by the fact it is now), though I wouldn't be a volunteer to do that. Fixes: d56d6b3d7d69 ("gpio: langwell: add Intel Merrifield support") Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpio: pca953x: Fix NBANK calculation for PCA9536

2016-08-22T16:22:58+00:00

[ Upstream commit a246b8198f776a16d1d3a3bbfc2d437bad766b29 ] NBANK() macro assumes that ngpios is a multiple of 8(BANK_SZ) and hence results in 0 banks for PCA9536 which has just 4 gpios. This is wrong as PCA9356 has 1 bank with 4 gpios. This results in uninitialized PCA953X_INVERT register. Fix this by using DIV_ROUND_UP macro in NBANK(). Cc: stable@vger.kernel.org Signed-off-by: Vignesh R Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings

2016-06-20T03:47:46+00:00

[ Upstream commit b66b2a0adf0e48973b582e055758b9907a7eee7c ] 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 Cc: stable@vger.kernel.org Signed-off-by: Ben Dooks Acked-by: Ray Jui Reviewed-by: Markus Mayer Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpiolib: Fix NULL pointer deference

2016-06-20T03:47:46+00:00

[ Upstream commit 11f33a6d15bfa397867ac0d7f3481b6dd683286f ] 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 Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpio: pca953x: Use correct u16 value for register word write

2016-04-20T13:40:57+00:00

[ Upstream commit 9b8e3ec34318663affced3c14d960e78d760dd9a ] The current implementation only uses the first byte in val, the second byte is always 0. Change it to use cpu_to_le16 to write the two bytes into the register Cc: stable@vger.kernel.org Signed-off-by: Yong Li Reviewed-by: Phil Reid Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpio: crystalcove: set IRQCHIP_SKIP_SET_WAKE for the irqchip

2015-07-04T03:02:23+00:00

[ Upstream commit 61e749d7e1627d375156553ea0ae83c4f6bb5a9b ] The CrystalCove GPIO irqchip doesn't have irq_set_wake callback defined so we should set IRQCHIP_SKIP_SET_WAKE for it or it would cause an irq desc's wake_depth unbalanced warning during system resume phase from the gpio_keys driver, which is the driver for the power button of the ASUS T100 laptop. Signed-off-by: Aaron Lu Cc: Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpio: gpio-kempld: Fix get_direction return value

2015-06-10T17:42:28+00:00

[ Upstream commit f230e8ffc03f17bd9d6b90ea890b8252a8cc1821 ] This patch fixes an inverted return value of the gpio get_direction function. The wrong value causes the direction sysfs entry and GPIO debugfs file to indicate incorrect GPIO direction settings. In some cases it also prevents setting GPIO output values. The problem is also present in all other stable kernel versions since linux-3.12. Cc: Stable # v3.12+ Reported-by: Jochen Henneberg Signed-off-by: Michael Brunner Reviewed-by: Guenter Roeck Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpio: sysfs: fix memory leaks and device hotplug

2015-05-23T19:43:19+00:00

[ Upstream commit 483d821108791092798f5d230686868112927044 ] Unregister GPIOs requested through sysfs at chip remove to avoid leaking the associated memory and sysfs entries. The stale sysfs entries prevented the gpio numbers from being exported when the gpio range was later reused (e.g. at device reconnect). This also fixes the related module-reference leak. Note that kernfs makes sure that any on-going sysfs operations finish before the class devices are unregistered and that further accesses fail. The chip exported flag is used to prevent gpiod exports during removal. This also makes it harder to trigger, but does not fix, the related race between gpiochip_remove and export_store, which is really a race with gpiod_request that needs to be addressed separately. Also note that this would prevent the crashes (e.g. NULL-dereferences) at reconnect that affects pre-3.18 kernels, as well as use-after-free on operations on open attribute files on pre-3.14 kernels (prior to kernfs). Fixes: d8f388d8dc8d ("gpio: sysfs interface") Cc: stable # v2.6.27: 01cca93a9491 Signed-off-by: Johan Hovold Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

gpio: mvebu: Fix mask/unmask managment per irq chip type

2015-05-17T23:12:18+00:00

[ Upstream commit 61819549f572edd7fce53f228c0d8420cdc85f71 ] Level IRQ handlers and edge IRQ handler are managed by tow different sets of registers. But currently the driver uses the same mask for the both registers. It lead to issues with the following scenario: First, an IRQ is requested on a GPIO to be triggered on front. After, this an other IRQ is requested for a GPIO of the same bank but triggered on level. Then the first one will be also setup to be triggered on level. It leads to an interrupt storm. The different kind of handler are already associated with two different irq chip type. With this patch the driver uses a private mask for each one which solves this issue. It has been tested on an Armada XP based board and on an Armada 375 board. For the both boards, with this patch is applied, there is no such interrupt storm when running the previous scenario. This bug was already fixed but in a different way in the legacy version of this driver by Evgeniy Dushistov: 9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain sequence of request_irq can cause irq storm". The fact the new version of the gpio drive could be affected had been discussed there: http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012 Reported-by: Evgeniy A. Dushistov Signed-off-by: Gregory CLEMENT Cc: # v3.7 + Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin