linux-stable.git/drivers/gpio, branch linux-4.1.y

gpio: label descriptors using the device name

2018-05-23T01:36:26+00:00

[ Upstream commit 24e78079bf2250874e33da2e7cfbb6db72d3caf4 ]

Some GPIO lines appear named "?" in the lsgpio dump due to their
requesting drivers not passing a reasonable label.

Most typically this happens if a device tree node just defines
gpios = <...> and not foo-gpios = <...>, the former gets named
"foo" and the latter gets named "?".

However the struct device passed in is always valid so let's
just label the GPIO with dev_name() on the device if no proper
label was passed.

Cc: Reported-by: Jason Kridner 
Reported-by: Jason Kridner 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: xgene: mark PM functions as __maybe_unused

2018-03-04T15:28:33+00:00

[ Upstream commit b115bebc07f282067eccc06fd5aa3060ab1426da ]

When CONFIG_PM_SLEEP is disabled, we get a warning about unused functions:

drivers/gpio/gpio-xgene.c:155:12: warning: 'xgene_gpio_resume' defined but not used [-Wunused-function]
 static int xgene_gpio_resume(struct device *dev)
            ^~~~~~~~~~~~~~~~~
drivers/gpio/gpio-xgene.c:142:12: warning: 'xgene_gpio_suspend' defined but not used [-Wunused-function]
 static int xgene_gpio_suspend(struct device *dev)

The warnings are harmless and can be avoided by simplifying the code and marking
the functions as __maybe_unused.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: intel-mid: Fix build warning when !CONFIG_PM

2018-03-04T15:28:28+00:00

[ Upstream commit fbc2a294f29e726787a0f5238b27137904f26b81 ]

The only usage of function intel_gpio_runtime_idle() is here (in the
same file):

static const struct dev_pm_ops intel_gpio_pm_ops = {
	SET_RUNTIME_PM_OPS(NULL, NULL, intel_gpio_runtime_idle)
};

And when CONFIG_PM is not set, the macro SET_RUNTIME_PM_OPS expands to
nothing, causing the following compiler warning:

drivers/gpio/gpio-intel-mid.c:324:12: warning: ‘intel_gpio_runtime_idle’
defined but not used [-Wunused-function]
static int intel_gpio_runtime_idle(struct device *dev)

Fix it by annotating the function with __maybe_unused.

Signed-off-by: Augusto Mecking Caringi 
Acked-by: Andy Shevchenko 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

2018-03-01T03:09:45+00:00

[ Upstream commit 97b03136e1b637d7a9d2274c099e44ecf23f1103 ]

This change resolves a new compile-time warning
when built as a loadable module:

WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-iop.o
see include/linux/module.h for more information

This adds the license as "GPL", which matches the header of the file.

MODULE_DESCRIPTION and MODULE_AUTHOR are also added.

Signed-off-by: Jesse Chan 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: 74xx: Fix build warning about void to integer cast

2018-01-17T17:55:42+00:00

[ Upstream commit 54442658d8e83b0589731620bd958cc8b2857167 ]

This fixes the build warning , warning: cast from pointer to integer
of different size when building this file on a x86 allmodconfig
configuration. In order for me to fix this build warning I changed
the cast in the function mmio_74xx_gpio_probe from casting the
variable data of the stucture pointer of_id to uintptr_t rather
then unsigned when assigning to the variable flag of the structure
pointer priv of the structure type mmio_74xx_gpio_priv.

Signed-off-by: Nicholas Krause 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: Fix OF build problem on UM

2016-08-31T23:21:09+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-20T03:07:58+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-16T12:25:03+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: sch: Fix Oops on module load on Asus Eee PC 1201

2016-07-19T19:49:42+00:00

[ Upstream commit 87041a58d3b19455d39baed2a5e5bb43b58fb915 ]

This fixes the issue descirbe in bug 117531
(https://bugzilla.kernel.org/show_bug.cgi?id=117531).
It's a regression introduced in linux 4.5 that causes a Oops at load of
gpio_sch and prevents powering off the computer.

The issue is that sch_gpio_reg_set is called in sch_gpio_probe before
gpio_chip data is initialized with the pointer to the sch_gpio struct. As
sch_gpio_reg_set calls gpiochip_get_data, it returns NULL which causes
the Oops.

The patch follows Mika's advice (https://lkml.org/lkml/2016/5/9/61) and
consists in modifying sch_gpio_reg_get and sch_gpio_reg_set to take a
sch_gpio struct directly instead of a gpio_chip, which avoids the call to
gpiochip_get_data.

Thanks Mika for your patience with me :-)

Cc: stable@vger.kernel.org
Signed-off-by: Colin Pitrat 
Acked-by: Alexandre Courbot 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings

2016-06-18T20:47:31+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