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

gpio: max7301: fix driver for use with CONFIG_VMAP_STACK

2019-02-11T17:54:30+00:00

commit abf221d2f51b8ce7b9959a8953f880a8b0a1400d upstream.

spi_read() and spi_write() require DMA-safe memory. When
CONFIG_VMAP_STACK is selected, those functions cannot be used
with buffers on stack.

This patch replaces calls to spi_read() and spi_write() by
spi_write_then_read() which doesn't require DMA-safe buffers.

Fixes: 0c36ec314735 ("gpio: gpio driver for max7301 SPI GPIO expander")
Signed-off-by: Christophe Leroy 
Signed-off-by: Linus Walleij 
Signed-off-by: Ben Hutchings

gpio: acpi: work around false-positive -Wstring-overflow warning

2018-01-01T20:51:33+00:00

commit e40a3ae1f794a35c4af3746291ed6fedc1fa0f6f upstream.

gcc-7 notices that the pin_table is an array of 16-bit numbers,
but fails to take the following range check into account:

drivers/gpio/gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt':
drivers/gpio/gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=]
   sprintf(ev_name, "_%c%02X",
                        ^~~~
drivers/gpio/gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535]
   sprintf(ev_name, "_%c%02X",
                    ^~~~~~~~~
drivers/gpio/gpiolib-acpi.c:206:3: note: 'sprintf' output between 5 and 7 bytes into a destination of size 5
   sprintf(ev_name, "_%c%02X",
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
    agpio->triggering == ACPI_EDGE_SENSITIVE ? 'E' : 'L',
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    pin);
    ~~~~

As suggested by Andy, this changes the format string to have a fixed length.
Since modifying the range check did not help, I also opened a bug against
gcc, see link below.

Fixes: 0d1c28a449c6 ("gpiolib-acpi: Add ACPI5 event model support to gpio.")
Cc: Andy Shevchenko 
Link: https://patchwork.kernel.org/patch/9840801/
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82123
Signed-off-by: Arnd Bergmann 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Ben Hutchings

gpio: tegra: fix unbalanced chained_irq_enter/exit

2017-11-11T13:33:14+00:00

commit 9e9509e38fbe034782339eb09c915f0b5765ff69 upstream.

When more than one GPIO IRQs are triggered simultaneously,
tegra_gpio_irq_handler() called chained_irq_exit() multiple
times for one chained_irq_enter().

Fixes: 3c92db9ac0ca3eee8e46e2424b6c074e2e394ad9
Signed-off-by: Michał Mirosław 
[Also changed the variable to a bool]
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

gpio:mcp23s08 Fixed missing interrupts

2017-07-18T17:40:18+00:00

commit 2cd29f2387be70de9feb4c9f8dbc7c0bd55748ce upstream.

When an interrupt occurs on an MCP23S08 chip, the INTF register will only
contain one bit as causing the interrupt.  If more than two pins change at
the same time on the chip, this causes one of the pins to not be reported.
This patch fixes the logic for checking if a pin has changed, so that
multiple pins will always cause more than one change.

Signed-off-by: Robert Middleton 
Tested-by: Phil Reid 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.16:
 - No support for level-triggered interrupts
 - Use mcp->ops->read instead of mcp_read()
 - Device pointer for logging is mcp->chip.dev]
Signed-off-by: Ben Hutchings

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