linux-stable.git/drivers/gpio, branch v3.16.40

gpio/mvebu: Use irq_domain_add_linear

2017-02-23T03:54:27+00:00

commit 812d47889a8e418d7bea9bec383581a34c19183e upstream.

This fixes the irq allocation in this driver to not print:
 irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
 irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated

Which happens because the driver already called irq_alloc_descs()
and so the change to use irq_domain_add_simple resulted in calling
irq_alloc_descs() twice.

Modernize the irq allocation in this driver to use the
irq_domain_add_linear flow directly and eliminate the use of
irq_domain_add_simple/legacy

Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()")
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.16:
 - Keep using irq_set_handler_data(), irq_set_chained_handler()
 - Adjust context]
Signed-off-by: Ben Hutchings

gpio: Fix OF build problem on UM

2016-11-20T01:17:13+00:00

commit 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 upstream.

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: Geert Uytterhoeven 
Reported-by: kbuild test robot 
Signed-off-by: Linus Walleij 
Signed-off-by: Ben Hutchings

gpio: intel-mid: Remove potentially harmful code

2016-11-20T01:16:57+00:00

commit 3dbd3212f81b2b410a34a922055e2da792864829 upstream.

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")
Signed-off-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Ben Hutchings

gpio: pca953x: Fix NBANK calculation for PCA9536

2016-11-20T01:16:40+00:00

commit a246b8198f776a16d1d3a3bbfc2d437bad766b29 upstream.

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().

Signed-off-by: Vignesh R 
Signed-off-by: Linus Walleij 
Signed-off-by: Ben Hutchings

gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings

2016-08-22T21:38:10+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: Ben Hutchings

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

2016-04-30T22:06:09+00:00

commit 9b8e3ec34318663affced3c14d960e78d760dd9a upstream.

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

Signed-off-by: Yong Li 
Reviewed-by: Phil Reid 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

gpiolib: Fix comment referring to gpio_() in gpiod_()

2016-04-30T22:06:00+00:00

commit 1cfab8f8b397f7d95ad43f72ed9a1fa7d26e210e upstream.

Fixes: 79a9becda8940deb ("gpiolib: export descriptor-based GPIO interface")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

gpio: rcar: Add Runtime PM handling for interrupts

2016-03-24T10:01:05+00:00

commit b26a719bdba9aa926ceaadecc66e07623d2b8a53 upstream.

The R-Car GPIO driver handles Runtime PM for requested GPIOs only.

When using a GPIO purely as an interrupt source, no Runtime PM handling
is done, and the GPIO module's clock may not be enabled.

To fix this:
  - Add .irq_request_resources() and .irq_release_resources() callbacks
    to handle Runtime PM when an interrupt is requested,
  - Add irq_bus_lock() and sync_unlock() callbacks to handle Runtime PM
    when e.g. disabling/enabling an interrupt, or configuring the
    interrupt type.

Fixes: d5c3d84657db57bd "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Linus Walleij 
[ luis: backported to 3.16:
  - use gpio_to_priv() instead of gpiochip_get_data()
  - adjusted context ]
Signed-off-by: Luis Henriques

gpio: gpio-kempld: Fix get_direction return value

2015-06-03T12:27:19+00:00

commit f230e8ffc03f17bd9d6b90ea890b8252a8cc1821 upstream.

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.

Reported-by: Jochen Henneberg 
Signed-off-by: Michael Brunner 
Reviewed-by: Guenter Roeck 
Signed-off-by: Linus Walleij 
Signed-off-by: Luis Henriques

gpio: sysfs: fix memory leaks and device hotplug

2015-05-20T12:26:01+00:00

commit 483d821108791092798f5d230686868112927044 upstream.

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")
Signed-off-by: Johan Hovold 
Signed-off-by: Linus Walleij 
[ luis: backported to 3.16:
  - file rename: drivers/gpio/gpiolib-sysfs.c -> drivers/gpio/gpiolib.c ]
Signed-off-by: Luis Henriques