linux-stable.git/drivers/gpio, branch v4.19.22

gpio: mt7621: pass mediatek_gpio_bank_probe() failure up the stack

2019-02-12T18:47:06+00:00

[ Upstream commit a109c2dbb571b10bb9969285b646f57309c98251 ]

The error cases of mediatek_gpio_bank_probe() would go unnoticed (except
for the dev_err() messages). The probe function should return an error
if one of the banks failed to initialize properly indicated by
not returning non-0.

Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
Signed-off-by: Nicholas Mc Guire 
Acked-by: Sean Wang 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: mt7621: report failure of devm_kasprintf()

2019-02-12T18:47:06+00:00

[ Upstream commit 59d646c775d6ae688ee90fda9f2a4270c47b7490 ]

kasprintf() may return NULL on failure of internal allocation thus the
assigned  label  is not safe if not explicitly checked. On error
mediatek_gpio_bank_probe() returns negative values so -ENOMEM in the
(unlikely) failure case should be fine here.

Fixes: 4ba9c3afda41 ("gpio: mt7621: Add a driver for MT7621")
Signed-off-by: Nicholas Mc Guire 
Reviewed-by: Bartosz Golaszewski 
Acked-by: Sean Wang 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpiolib: Fix possible use after free on label

2019-02-12T18:46:57+00:00

[ Upstream commit 18534df419041e6c1f4b41af56ee7d41f757815c ]

gpiod_request_commit() copies the pointer to the label passed as
an argument only to be used later. But there's a chance the caller
could immediately free the passed string(e.g., local variable).
This could trigger a use after free when we use gpio label(e.g.,
gpiochip_unlock_as_irq(), gpiochip_is_requested()).

To be on the safe side: duplicate the string with kstrdup_const()
so that if an unaware user passes an address to a stack-allocated
buffer, we won't get the arbitrary label.

Also fix gpiod_set_consumer_name().

Signed-off-by: Muchun Song 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: sprd: Fix incorrect irq type setting for the async EIC

2019-02-06T16:30:13+00:00

commit f785ffb61605734b518afa766d1b5445e9f38c8d upstream.

When setting async EIC as IRQ_TYPE_EDGE_BOTH type, we missed to set the
SPRD_EIC_ASYNC_INTMODE register to 0, which means detecting edge signals.

Thus this patch fixes the issue.

Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
Cc: 
Signed-off-by: Neo Hou 
Signed-off-by: Baolin Wang 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Greg Kroah-Hartman

gpio: sprd: Fix the incorrect data register

2019-02-06T16:30:12+00:00

commit 09d158d52d2bceda736797a61b6c13d7fc83707b upstream.

Since differnt type EICs have its own data register to read, thus fix the
incorrect data register.

Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
Cc: 
Signed-off-by: Neo Hou 
Signed-off-by: Baolin Wang 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Greg Kroah-Hartman

gpio: pcf857x: Fix interrupts on multiple instances

2019-02-06T16:30:12+00:00

commit 2486e67374aa8b7854c2de32869642c2873b3d53 upstream.

When multiple instances of pcf857x chips are present, a fix up
message [1] is printed during the probe of the 2nd and later
instances.

The issue is that the driver is using the same irq_chip data
structure between multiple instances.

Fix this by allocating the irq_chip data structure per instance.

[1] fix up message addressed by this patch
[    1.212100] gpio gpiochip9: (pcf8575): detected irqchip that is shared with multiple gpiochips: please fix the driver.

Cc: Stable 
Signed-off-by: Roger Quadros 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Greg Kroah-Hartman

gpiolib: fix line event timestamps for nested irqs

2019-02-06T16:30:12+00:00

commit 1033be58992f818dc564196ded2bcc3f360bc297 upstream.

Nested interrupts run inside the calling thread's context and the top
half handler is never called which means that we never read the
timestamp.

This issue came up when trying to read line events from a gpiochip
using regmap_irq_chip for interrupts.

Fix it by reading the timestamp from the irq thread function if it's
still 0 by the time the second handler is called.

Fixes: d58f2bf261fd ("gpio: Timestamp events in hardirq handler")
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Greg Kroah-Hartman

gpio: altera-a10sr: Set proper output level for direction_output

2019-02-06T16:30:12+00:00

commit 2095a45e345e669ea77a9b34bdd7de5ceb422f93 upstream.

The altr_a10sr_gpio_direction_output should set proper output level
based on the value argument.

Fixes: 26a48c4cc2f1 ("gpio: altera-a10sr: Add A10 System Resource Chip GPIO support.")
Cc: 
Signed-off-by: Axel Lin 
Tested by: Thor Thayer 
Reviewed by: Thor Thayer 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Greg Kroah-Hartman

gpio: pl061: Move irq_chip definition inside struct pl061

2019-01-26T08:32:33+00:00

[ Upstream commit ed8dce4c6f726b7f3c6bf40859b92a9e32f189c1 ]

Keeping the irq_chip definition static will make it shared with multiple
giochips in the system. This practice is considered to be bad and now we
will get the below warning from gpiolib core:

"detected irqchip that is shared with multiple gpiochips: please fix the
driver."

Hence, move the irq_chip definition from static to `struct pl061` for
using a unique irq_chip for each gpiochip.

Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin

gpio: mvebu: only fail on missing clk if pwm is actually to be used

2019-01-13T08:51:03+00:00

[ Upstream commit c8da642d41a6811c21177c9994aa7dc35be67d46 ]

The gpio IP on Armada 370 at offset 0x18180 has neither a clk nor pwm
registers. So there is no need for a clk as the pwm isn't used anyhow.
So only check for the clk in the presence of the pwm registers. This fixes
a failure to probe the gpio driver for the above mentioned gpio device.

Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support")
Signed-off-by: Uwe Kleine-König 
Reviewed-by: Gregory CLEMENT 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin