29 Jul, 2020
2 commits
-
[ Upstream commit 861254d826499944cb4d9b5a15f5a794a6b99a69 ]
Calling pm_runtime_get_sync increments the counter even in case of
failure, causing incorrect ref count if pm_runtime_put is not called in
error handling paths. Call pm_runtime_put if pm_runtime_get_sync fails.Signed-off-by: Navid Emamdoost
Acked-by: Charles Keepax
Link: https://lore.kernel.org/r/20200605030052.78235-1-navid.emamdoost@gmail.com
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin -
[ Upstream commit e6f390a834b56583e6fc0949822644ce92fbb107 ]
Calling pm_runtime_get_sync increments the counter even in case of
failure, causing incorrect ref count. Call pm_runtime_put if
pm_runtime_get_sync fails.Signed-off-by: Navid Emamdoost
Acked-by: Charles Keepax
Link: https://lore.kernel.org/r/20200605025207.65719-1-navid.emamdoost@gmail.com
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
22 Jul, 2020
1 commit
-
commit ec3decd21380081e3b5de4ba8d85d90a95f201a0 upstream.
It's a repetition of the commit aa58a21ae378
("gpio: pca953x: disable regmap locking")
which states the following:This driver uses its own locking but regmap silently uses
a mutex for all operations too. Add the option to disable
locking to the regmap config struct.Fixes: bcf41dc480b1 ("gpio: pca953x: fix handling of automatic address incrementing")
Cc: Uwe Kleine-König
Signed-off-by: Andy Shevchenko
Reviewed-by: Uwe Kleine-König
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Greg Kroah-Hartman
16 Jul, 2020
2 commits
-
[ Upstream commit 5d8913504ccfeea6120df5ae1c6f4479ff09b931 ]
When adding a quirk for IRQ on Intel Galileo Gen 2 the commit ba8c90c61847
("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2")
missed GPIO resource release. We can safely do this in the same quirk, since
IRQ will be locked by GPIO framework when requested and unlocked on freeing.Fixes: ba8c90c61847 ("gpio: pca953x: Override IRQ for one of the expanders on Galileo Gen 2")
Signed-off-by: Andy Shevchenko
Cc: Mika Westerberg
Reviewed-by: Mika Westerberg
Reviewed-by: Linus Walleij
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin -
[ Upstream commit ba8c90c6184784b397807b72403656085ac2f8c1 ]
ACPI table on Intel Galileo Gen 2 has wrong pin number for IRQ resource
of one of the I²C GPIO expanders. Since we know what that number is and
luckily have GPIO bases fixed for SoC's controllers, we may use a simple
DMI quirk to match the platform and retrieve GpioInt() pin on it for
the expander in question.Mika suggested the way to avoid a quirk in the GPIO ACPI library and
here is the second, almost rewritten version of it.Fixes: f32517bf1ae0 ("gpio: pca953x: support ACPI devices found on Galileo Gen2")
Depends-on: 25e3ef894eef ("gpio: acpi: Split out acpi_gpio_get_irq_resource() helper")
Suggested-by: Mika Westerberg
Reviewed-by: Mika Westerberg
Signed-off-by: Andy Shevchenko
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin
24 Jun, 2020
3 commits
-
[ Upstream commit bcf41dc480b179bfb669a232080a2e26dc7294b4 ]
Some of the chips supported by the pca953x driver need the most
significant bit in the address word set to automatically increment the
address pointer on subsequent reads and writes (example: PCA9505). With
this bit unset the same register is read multiple times on a multi-byte
read sequence. Other chips must not have this bit set and autoincrement
always (example: PCA9555).Up to now this AI bit was interpreted to be part of the address, which
resulted in inconsistent regmap caching when a register was written with
AI set and then read without it. This happened for the PCA9505 in
pca953x_gpio_set_multiple() where pca953x_read_regs() bulk read from the
cache for registers 0x8-0xc and then wrote to registers 0x88-0x8c. (Side
note: reading 5 values from offset 0x8 yiels OP0 5 times because AI must
be set to get OP0-OP4, which is another bug that is resolved here as a
by-product.) The same problem happens when calls to gpio_set_value() and
gpio_set_array_value() were mixed.With this patch the AI bit is always set for chips that support it. This
works as there are no code locations that make use of the behaviour with
AI unset (for the chips that support it).Note that the call to pca953x_setup_gpio() had to be done a bit earlier
to make the NBANK macro work.The history of this bug is a bit complicated. Commit b32cecb46bdc
("gpio: pca953x: Extract the register address mangling to single
function") changed which chips and functions are affected. Commit
3b00691cc46a ("gpio: pca953x: hack to fix 24 bit gpio expanders") used
some duct tape to make the driver at least appear to work. Commit
49427232764d ("gpio: pca953x: Perform basic regmap conversion")
introduced the caching. Commit b4818afeacbd ("gpio: pca953x: Add
set_multiple to allow multiple bits to be set in one write.") introduced
the .set_multiple() callback which didn't work for chips that need the
AI bit which was fixed later for some chips in 8958262af3fb ("gpio:
pca953x: Repair multi-byte IO address increment on PCA9575"). So I'm
sorry, I don't know which commit I should pick for a Fixes: line.Tested-by: Marcel Gudert
Signed-off-by: Uwe Kleine-König
Tested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Signed-off-by: Andy Shevchenko
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin -
[ Upstream commit c58220cba2e03618659fa7d5dfae31f5ad4ae9d0 ]
The commit 3d2613c4289f
("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver")
introduced a use of the platform driver but missed to add the following line
to it:
MODULE_ALIAS("platform:gpio-dwapb");Add this to get driver loaded automatically if platform device is registered.
Fixes: 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver")
Signed-off-by: Andy Shevchenko
Tested-by: Serge Semin
Reviewed-by: Serge Semin
Link: https://lore.kernel.org/r/20200415141534.31240-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin -
[ Upstream commit 494a94e38dcf62543a32a4424d646ff80b4b28bd ]
Add missed acpi_gpiochip_free_interrupts() call when unregistering ports.
While at it, drop extra check to call acpi_gpiochip_request_interrupts().
There is no need to have an additional check to call
acpi_gpiochip_request_interrupts(). Even without any interrupts available
the registered ACPI Event handlers can be useful for debugging purposes.Fixes: e6cb3486f5a1 ("gpio: dwapb: add gpio-signaled acpi event support")
Signed-off-by: Andy Shevchenko
Tested-by: Serge Semin
Acked-by: Serge Semin
Link: https://lore.kernel.org/r/20200519131233.59032-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
03 Jun, 2020
5 commits
-
[ Upstream commit e9bdf7e655b9ee81ee912fae1d59df48ce7311b6 ]
We provided the right semantics on open drain lines being
by definition output but incidentally the irq set up function
would only allow IRQs on lines that were "not output".Fix the semantics to allow output open drain lines to be used
for IRQs.Reported-by: Hans Verkuil
Signed-off-by: Linus Walleij
Signed-off-by: Hans Verkuil
Tested-by: Hans Verkuil
Cc: Russell King
Cc: stable@vger.kernel.org # v5.3+
Link: https://lore.kernel.org/r/20200527140758.162280-1-linus.walleij@linaro.org
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin -
[ Upstream commit 98f7d1b15e87c84488b30ecc4ec753b0690b9dbf ]
Propagate the error code returned by devm_platform_ioremap_resource()
out of probe() instead of overwriting it.Fixes: 72d8cb715477 ("drivers: gpio: bcm-kona: use devm_platform_ioremap_resource()")
Signed-off-by: Tiezhu Yang
[Bartosz: tweaked the commit message]
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin -
[ Upstream commit 558ab2e8155e5f42ca0a6407957cd4173dc166cc ]
When call function devm_platform_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.Fixes: 542c25b7a209 ("drivers: gpio: pxa: use devm_platform_ioremap_resource()")
Signed-off-by: Tiezhu Yang
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin -
[ Upstream commit 333830aa149a87cabeb5d30fbcf12eecc8040d2c ]
The commit 7ecced0934e5 ("gpio: exar: add a check for the return value
of ida_simple_get fails") added a goto jump to the common error
handler for ida_simple_get() error, but this is wrong in two ways:
it doesn't set the proper return code and, more badly, it invokes
ida_simple_remove() with a negative index that shall lead to a kernel
panic via BUG_ON().This patch addresses those two issues.
Fixes: 7ecced0934e5 ("gpio: exar: add a check for the return value of ida_simple_get fails")
Cc:
Signed-off-by: Takashi Iwai
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin -
[ Upstream commit 0cf253eed5d2bdf7bb3152457b38f39b012955f7 ]
The driver currently leaves GPIO IRQs unmasked even when the GPIO IRQ
client has released the GPIO IRQ. This allows the HW to raise IRQs, and
SW to process them, after shutdown. Fix this by masking the IRQ when it's
shut down. This is usually taken care of by the irqchip core, but since
this driver has a custom irq_shutdown implementation, it must do this
explicitly itself.Signed-off-by: Stephen Warren
Link: https://lore.kernel.org/r/20200427232605.11608-1-swarren@wwwdotorg.org
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
20 May, 2020
1 commit
-
[ Upstream commit dc87f6dd058a648cd2a35e4aa04592dccdc9f0c2 ]
pca953x_gpio_set_config is setup to support pull-up/down
bias. Currently the driver uses a variable called 'config' to
determine which options to use. Unfortunately, this is incorrect.This patch uses function pinconf_to_config_param(config), which
converts this 'config' parameter back to pinconfig to determine
which option to use.Fixes: 15add06841a3 ("gpio: pca953x: add ->set_config implementation")
Signed-off-by: Adam Ford
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin
02 Apr, 2020
1 commit
-
commit 0c625ccfe6f754d0896b8881f5c85bcb81699f1f upstream.
There are at least 3 models of the HP x2 10 models:
Bay Trail SoC + AXP288 PMIC
Cherry Trail SoC + AXP288 PMIC
Cherry Trail SoC + TI PMICLike on the other HP x2 10 models we need to ignore wakeup for ACPI GPIO
events on the external embedded-controller pin to avoid spurious wakeups
on the HP x2 10 CHT + AXP288 model too.This commit adds an extra DMI based quirk for the HP x2 10 CHT + AXP288
model, ignoring wakeups for ACPI GPIO events on the EC interrupt pin
on this model. This fixes spurious wakeups from suspend on this model.Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Reported-and-tested-by: Marc Lehmann
Signed-off-by: Hans de Goede
Link: https://lore.kernel.org/r/20200302111225.6641-4-hdegoede@redhat.com
Acked-by: Mika Westerberg
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
01 Apr, 2020
4 commits
-
commit 0e91506ba00730f088961a8d39f8693b0f8e3fea upstream.
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series. In the mean time I have learned that there
are at least 3 different HP x2 10 models:Bay Trail SoC + AXP288 PMIC
Cherry Trail SoC + AXP288 PMIC
Cherry Trail SoC + TI PMICAnd the original quirk is only correct for (and only matches the)
Cherry Trail SoC + TI PMIC model.The Bay Trail SoC + AXP288 PMIC model has different DMI strings, has
the external EC interrupt on a different GPIO pin and only needs to ignore
wakeups on the EC interrupt, the INT0002 device works fine on this model.This commit adds an extra DMI based quirk for the HP x2 10 BYT + AXP288
model, ignoring wakeups for ACPI GPIO events on the EC interrupt pin
on this model. This fixes spurious wakeups from suspend on this model.Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede
Link: https://lore.kernel.org/r/20200302111225.6641-3-hdegoede@redhat.com
Acked-by: Mika Westerberg
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 2ccb21f5516afef5e251184eeefbf36db90206d7 upstream.
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg
Reviewed-by: Andy Shevchenko
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit efaa87fa0947d525cf7c075316adde4e3ac7720b upstream.
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") added a quirk for some models of the HP x2 10 series.There are 2 issues with the comment describing the quirk:
1) The comment claims the DMI quirk applies to all Cherry Trail based HP x2
10 models. In the mean time I have learned that there are at least 3
models of the HP x2 10 models:Bay Trail SoC + AXP288 PMIC
Cherry Trail SoC + AXP288 PMIC
Cherry Trail SoC + TI PMICAnd this quirk's DMI matches only match the Cherry Trail SoC + TI PMIC
SoC, which is good because we want a slightly different quirk for the
others. This commit updates the comment to make it clear that the quirk
is only for the Cherry Trail SoC + TI PMIC models.2) The comment says that it is ok to disable wakeup on all ACPI GPIO event
handlers, because there is only the one for the embedded-controller
events. This is not true, there also is a handler for the special
INT0002 device which is related to USB wakeups. We need to also disable
wakeups on that one because the device turns of the USB-keyboard built
into the dock when closing the lid. The XHCI controller takes a while
to notice this, so it only notices it when already suspended, causing
a spurious wakeup because of this. So disabling wakeup on all handlers
is the right thing to do, but not because there only is the one handler
for the EC events. This commit updates the comment to correctly reflect
this.Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede
Link: https://lore.kernel.org/r/20200302111225.6641-1-hdegoede@redhat.com
Acked-by: Mika Westerberg
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 8959b304c7062889b1276092cc8590dc1ba98f65 upstream.
The implementation if .irq_disable() which kicks in between
the gpiolib and the driver is not properly mimicking the
expected semantics of the irqchip core: the irqchip will
call .irq_disable() if that exists, else it will call
mask_irq() which first checks if .irq_mask() is defined
before calling it.Since we are calling it unconditionally, we get this bug
from drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c, as it only
defines .irq_mask_ack and not .irq_mask:Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = (ptrval)
(...)
PC is at 0x0
LR is at gpiochip_irq_disable+0x20/0x30Fix this by only calling .irq_mask() if it exists.
Cc: Brian Masney
Cc: Hans Verkuil
Cc: stable@vger.kernel.org
Reviewed-by: Bartosz Golaszewski
Fixes: 461c1a7d4733 ("gpiolib: override irq_enable/disable")
Signed-off-by: Linus Walleij
Link: https://lore.kernel.org/r/20200306132326.1329640-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman
24 Feb, 2020
2 commits
-
[ Upstream commit c34f6dc8c9e6bbe9fba1d53acd6d9a3889599da3 ]
I see the following lockdep splat in the qcom pinctrl driver when
attempting to suspend the device.============================================
WARNING: possible recursive locking detected
5.4.2 #2 Tainted: G S
--------------------------------------------
cat/6536 is trying to acquire lock:
ffffff814787ccc0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94but task is already holding lock:
ffffff81436740c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94other info that might help us debug this:
Possible unsafe locking scenario:CPU0
----
lock(&irq_desc_lock_class);
lock(&irq_desc_lock_class);*** DEADLOCK ***
May be due to missing lock nesting notation
7 locks held by cat/6536:
#0: ffffff8140e0c420 (sb_writers#7){.+.+}, at: vfs_write+0xc8/0x19c
#1: ffffff8121eec480 (&of->mutex){+.+.}, at: kernfs_fop_write+0x128/0x1f4
#2: ffffff8147cad668 (kn->count#263){.+.+}, at: kernfs_fop_write+0x130/0x1f4
#3: ffffffd011446000 (system_transition_mutex){+.+.}, at: pm_suspend+0x108/0x354
#4: ffffff814302b970 (&dev->mutex){....}, at: __device_suspend+0x16c/0x420
#5: ffffff81436740c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94
#6: ffffff81479b8c10 (&pctrl->lock){....}, at: msm_gpio_irq_set_wake+0x48/0x7cstack backtrace:
CPU: 4 PID: 6536 Comm: cat Tainted: G S 5.4.2 #2
Call trace:
dump_backtrace+0x0/0x174
show_stack+0x20/0x2c
dump_stack+0xdc/0x144
__lock_acquire+0x52c/0x2268
lock_acquire+0x1dc/0x220
_raw_spin_lock_irqsave+0x64/0x80
__irq_get_desc_lock+0x64/0x94
irq_set_irq_wake+0x40/0x144
msm_gpio_irq_set_wake+0x5c/0x7c
set_irq_wake_real+0x40/0x5c
irq_set_irq_wake+0x70/0x144
cros_ec_rtc_suspend+0x38/0x4c
platform_pm_suspend+0x34/0x60
dpm_run_callback+0x64/0xcc
__device_suspend+0x314/0x420
dpm_suspend+0xf8/0x298
dpm_suspend_start+0x84/0xb4
suspend_devices_and_enter+0xbc/0x628
pm_suspend+0x214/0x354
state_store+0xb0/0x108
kobj_attr_store+0x14/0x24
sysfs_kf_write+0x4c/0x64
kernfs_fop_write+0x158/0x1f4
__vfs_write+0x54/0x18c
vfs_write+0xdc/0x19c
ksys_write+0x7c/0xe4
__arm64_sys_write+0x20/0x2c
el0_svc_common+0xa8/0x160
el0_svc_compat_handler+0x2c/0x38
el0_svc_compat+0x8/0x10This is because the msm_gpio_irq_set_wake() function calls
irq_set_irq_wake() as a backup in case the irq comes in during the path
to idle. Given that we're calling irqchip functions from within an
irqchip we need to set the lockdep class to be different for this child
controller vs. the default one that the parent irqchip gets.This used to be done before this driver was converted to hierarchical
irq domains in commit e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in
hierarchy") via the gpiochip_irq_map() function. With hierarchical irq
domains this function has been replaced by
gpiochip_hierarchy_irq_domain_alloc(). Therefore, set the lockdep class
like was done previously in the irq domain path so we can avoid this
lockdep warning.Fixes: fdd61a013a24 ("gpio: Add support for hierarchical IRQ domains")
Cc: Thierry Reding
Cc: Brian Masney
Cc: Lina Iyer
Cc: Marc Zyngier
Cc: Maulik Shah
Signed-off-by: Stephen Boyd
Link: https://lore.kernel.org/r/20200114231103.85641-1-swboyd@chromium.org
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin -
[ Upstream commit e36eaf94be8f7bc4e686246eed3cf92d845e2ef8 ]
The driver may sleep while holding a spinlock.
The function call path (from bottom to top) in Linux 4.19 is:drivers/gpio/gpio-grgpio.c, 261:
request_irq in grgpio_irq_map
drivers/gpio/gpio-grgpio.c, 255:
_raw_spin_lock_irqsave in grgpio_irq_mapdrivers/gpio/gpio-grgpio.c, 318:
free_irq in grgpio_irq_unmap
drivers/gpio/gpio-grgpio.c, 299:
_raw_spin_lock_irqsave in grgpio_irq_unmaprequest_irq() and free_irq() can sleep at runtime.
To fix these bugs, request_irq() and free_irq() are called without
holding the spinlock.These bugs are found by a static analysis tool STCheck written by myself.
Signed-off-by: Jia-Ju Bai
Link: https://lore.kernel.org/r/20191218132605.10594-1-baijiaju1990@gmail.com
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
20 Feb, 2020
3 commits
-
[ Upstream commit 9073d10b098973519044f5fcdc25586810b435da ]
Use MMC_CAP2_RO_ACTIVE_HIGH flag as indicator if GPIO line is to be
inverted compared to DT/platform-specified polarity. The flag is not used
after init in GPIO mode anyway. No functional changes intended.Signed-off-by: Michał Mirosław
Link: https://lore.kernel.org/r/a60f563f11bbff821da2fa2949ca82922b144860.1576031637.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin -
[ Upstream commit d3a5bcb4a17f1ad072484bb92c42519ff3aba6e1 ]
Add possibility to toggle active-low flag of a gpio descriptor. This is
useful for compatibility code, where defaults are inverted vs DT gpio
flags or the active-low flag is taken from elsewhere.Acked-by: Linus Walleij
Signed-off-by: Michał Mirosław
Link: https://lore.kernel.org/r/7ce0338e01ad17fa5a227176813941b41a7c35c1.1576031637.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Ulf Hansson
Signed-off-by: Sasha Levin -
commit c3afa804c58e5c30ac63858b527fffadc88bce82 upstream.
Care is taken with "index", however with the current version
the actual xgpio_writereg is using index for data but
xgpio_regoffset(chip, i) for the offset. And since i is already
incremented it is incorrect. This patch fixes it so that index
is used for the offset too.Cc: stable@vger.kernel.org
Signed-off-by: Paul Thomas
Link: https://lore.kernel.org/r/20200125221410.8022-1-pthomas8589@gmail.com
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
01 Feb, 2020
1 commit
-
[ Upstream commit c5706c7defc79de68a115b5536376298a8fef111 ]
Driver fails to compile in a minimized kernel's configuration because of
the missing dependency on GPIOLIB_IRQCHIP.error: ‘struct gpio_chip’ has no member named ‘irq’
44 | virq = irq_find_mapping(gpio->gpio_chip.irq.domain, offset);Signed-off-by: Dmitry Osipenko
Link: https://lore.kernel.org/r/20200106015154.12040-1-digetx@gmail.com
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
26 Jan, 2020
2 commits
-
[ Upstream commit 11e299de3aced4ea23a9fb1fef6c983c8d516302 ]
gcc has a hard time tracking whether BUG_ON(1) ends
execution or not:drivers/gpio/gpio-aspeed-sgpio.c: In function 'bank_reg':
drivers/gpio/gpio-aspeed-sgpio.c:112:1: error: control reaches end of non-void function [-Werror=return-type]Use the simpler BUG() that gcc knows cannot continue.
Fixes: f8b410e3695a ("gpio: aspeed-sgpio: Rename and add Kconfig/Makefile")
Signed-off-by: Arnd Bergmann
Acked-by: Andrew Jeffery
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin -
commit 2f4133bb5f14f49a99acf0cc55b84996dbfb4dff upstream.
of_gpiochip_add(), when fails, calls gpiochip_remove_pin_ranges().
ADD:
gpiochip_add_data_with_key() ->
of_gpiochip_add() -> (ERROR path)
gpiochip_remove_pin_ranges()At the same time of_gpiochip_remove() calls exactly the above mentioned
function unconditionally and so does gpiochip_remove().REMOVE:
gpiochip_remove() ->
gpiochip_remove_pin_ranges()
of_gpiochip_remove() ->
gpiochip_remove_pin_ranges()Since gpiochip_remove() calls gpiochip_remove_pin_ranges() unconditionally,
we have duplicate call to the same function when it's not necessary.Move gpiochip_remove_pin_ranges() from of_gpiochip_add() to gpiochip_add()
to avoid duplicate calls and be consistent with the explicit call in
gpiochip_remove().Fixes: e93fa3f24353 ("gpiolib: remove duplicate pin range code")
Depends-on: f7299d441a4d ("gpio: of: Fix of_gpiochip_add() error path")
Cc: Geert Uytterhoeven
Signed-off-by: Andy Shevchenko
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
23 Jan, 2020
1 commit
-
commit a564ac35d60564dd5b509e32afdc04e7aafee40e upstream.
This reverts commit a7fc89f9d5fcc10a5474cfe555f5a9e5df8b0f1f because
there are some bugs in this commit, and we don't have a simple way to
fix these bugs. So revert this commit to make the thunderx gpio work
on the stable kernel at least. We will switch to GPIOLIB_IRQCHIP
for thunderx gpio by following patches.Fixes: a7fc89f9d5fc ("gpio: thunderx: Switch to GPIOLIB_IRQCHIP")
Signed-off-by: Kevin Hao
Link: https://lore.kernel.org/r/20200114082821.14015-2-haokexin@gmail.com
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
18 Jan, 2020
3 commits
-
[ Upstream commit 322f6a3182d42df18059a89c53b09d33919f755e ]
Dear Linus Walleij,
In old kernels, some APIs still try to use parent->of_node from struct gpio_chip,
and it could be resulted in kernel panic because parent is NULL. Adding platform
device to gpiochip->parent can fix this problem.Signed-off-by: Johnson Chen
Link: https://patchwork.kernel.org/patch/11234609
Link: https://lore.kernel.org/r/HK0PR01MB3521489269F76467DFD7843FFA450@HK0PR01MB3521.apcprd01.prod.exchangelabs.com
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin -
commit d935bd50dd14a7714cbdba9a76435dbb56edb1ae upstream.
When a GPIO offset in a lookup table is out-of-range, the printed error
message (1) does not include the actual out-of-range value, and (2)
contains an off-by-one error in the upper bound.Avoid user confusion by also printing the actual GPIO offset, and
correcting the upper bound of the range.
While at it, use "%u" for unsigned int.Sample impact:
-requested GPIO 0 is out of range [0..32] for chip e6052000.gpio
+requested GPIO 0 (45) is out of range [0..31] for chip e6052000.gpioFixes: 2a3cf6a3599e9015 ("gpiolib: return -ENOENT if no GPIO mapping exists")
Signed-off-by: Geert Uytterhoeven
Link: https://lore.kernel.org/r/20191127095919.4214-1-geert+renesas@glider.be
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 36f2e7207f21a83ca0054116191f119ac64583ab upstream.
This patch writes the inverse value of Interrupt Mask Status
register into the Interrupt Enable register in
zynq_gpio_restore_context API to fix the bug.Fixes: e11de4de28c0 ("gpio: zynq: Add support for suspend resume")
Signed-off-by: Swapna Manupati
Signed-off-by: Michal Simek
Signed-off-by: Srinivas Neeli
Link: https://lore.kernel.org/r/1577362338-28744-2-git-send-email-srinivas.neeli@xilinx.com
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
15 Jan, 2020
2 commits
-
commit aa23ca3d98f756d5b1e503fb140665fb24a41a38 upstream.
On some laptops enabling wakeup on the GPIO interrupts used for ACPI _AEI
event handling causes spurious wakeups.This commit adds a new honor_wakeup option, defaulting to true (our current
behavior), which can be used to disable wakeup on troublesome hardware
to avoid these spurious wakeups.This is a workaround for an architectural problem with s2idle under Linux
where we do not have any mechanism to immediately go back to sleep after
wakeup events, other then for embedded-controller events using the standard
ACPI EC interface, for details see:
https://lore.kernel.org/linux-acpi/61450f9b-cbc6-0c09-8b3a-aff6bf9a0b3c@redhat.com/One series of laptops which is not able to suspend without this workaround
is the HP x2 10 Cherry Trail models, this commit adds a DMI based quirk
which makes sets honor_wakeup to false on these models.Cc: stable@vger.kernel.org
Reviewed-by: Andy Shevchenko
Acked-by: Mika Westerberg
Signed-off-by: Hans de Goede
Link: https://lore.kernel.org/r/20200105160357.97154-3-hdegoede@redhat.com
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 1ad1b54099c231aed8f6f257065c1b322583f264 upstream.
Turn the existing run_edge_events_on_boot_blacklist dmi_system_id table
into a generic quirk table, storing the quirks in the driver_data ptr.This is a preparation patch for adding other types of (DMI based) quirks.
Cc: stable@vger.kernel.org
Reviewed-by: Andy Shevchenko
Acked-by: Mika Westerberg
Signed-off-by: Hans de Goede
Link: https://lore.kernel.org/r/20200105160357.97154-2-hdegoede@redhat.com
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
12 Jan, 2020
1 commit
-
[ Upstream commit 71b8f600b034c7f5780f6fb311dabfe331c64feb ]
We have a special quirk to handle the Freescale
nonstandard SPI chipselect GPIOs in the gpiolib-of.c
file, but it currently only handles the case where
the GPIOs are actually requested (gpiod_*get()).We also need to handle that the SPI core attempts
to count the GPIOs before use, and that needs a
similar quirk in the OF part of the library.Cc: Christophe Leroy
Reported-by: Christophe Leroy
Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors")
Signed-off-by: Linus Walleij
Tested-by: Christophe Leroy
Link: https://lore.kernel.org/r/20191128083718.39177-2-linus.walleij@linaro.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
09 Jan, 2020
2 commits
-
commit 256efaea1fdc4e38970489197409a26125ee0aaa upstream.
gpiolib has a corner case with open drain outputs that are emulated.
When such outputs are outputting a logic 1, emulation will set the
hardware to input mode, which will cause gpiod_get_direction() to
report that it is in input mode. This is different from the behaviour
with a true open-drain output.Unify the semantics here.
Cc:
Suggested-by: Linus Walleij
Signed-off-by: Russell King
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Greg Kroah-Hartman -
commit 634f0348fe336fce8f6cab1933139115e983ed2f upstream.
Commit cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr") removed
{RSR,WSR}_CPENABLE from xtensa code, but did not fix up all users,
breaking gpio-xtensa driver build. Update gpio-xtensa to use
new xtensa_{get,set}_sr API.Cc: stable@vger.kernel.org # v5.0+
Fixes: cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr")
Signed-off-by: Max Filippov
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Greg Kroah-Hartman
05 Jan, 2020
4 commits
-
[ Upstream commit e272f7ec070d212b9301d5a465bc8952f8dcf908 ]
When commit 75e99bf5ed8f ("gpio: lynxpoint: set default handler to be
handle_bad_irq()") switched default handler to be handle_bad_irq() the
lp_irq_type() function remained untouched. It means that even request_irq()
can't change the handler and we are not able to handle IRQs properly anymore.
Fix it by setting correct handlers in the lp_irq_type() callback.Fixes: 75e99bf5ed8f ("gpio: lynxpoint: set default handler to be handle_bad_irq()")
Signed-off-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20191118180251.31439-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin -
[ Upstream commit 4e50573f39229d5e9c985fa3b4923a8b29619ade ]
The per-SoC devtype structures can contain their own callbacks that
overwrite mpc8xxx_gpio_devtype_default.The clear intention is that mpc8xxx_irq_set_type is used in case the SoC
does not specify a more specific callback. But what happens is that if
the SoC doesn't specify one, its .irq_set_type is de-facto NULL, and
this overwrites mpc8xxx_irq_set_type to a no-op. This means that the
following SoCs are affected:- fsl,mpc8572-gpio
- fsl,ls1028a-gpio
- fsl,ls1088a-gpioOn these boards, the irq_set_type does exactly nothing, and the GPIO
controller keeps its GPICR register in the hardware-default state. On
the LS1028A, that is ACTIVE_BOTH, which means 2 interrupts are raised
even if the IRQ client requests LEVEL_HIGH. Another implication is that
the IRQs are not checked (e.g. level-triggered interrupts are not
rejected, although they are not supported).Fixes: 82e39b0d8566 ("gpio: mpc8xxx: handle differences between incarnations at a single place")
Signed-off-by: Vladimir Oltean
Link: https://lore.kernel.org/r/20191115125551.31061-1-olteanv@gmail.com
Tested-by: Michael Walle
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin -
[ Upstream commit 787b64a43f7acacf8099329ea08872e663f1e74f ]
Qoriq requires the IBE register to be set to enable GPIO inputs to be
read. Set it.Signed-off-by: Russell King
Link: https://lore.kernel.org/r/E1iX3HC-00069N-0T@rmk-PC.armlinux.org.uk
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin -
[ Upstream commit c8f3d144004dd3f471ffd414690d15a005e4acd6 ]
On some of i.MX SoCs like i.MX8QXP, there is ONLY one IRQ for each
GPIO bank, so it is better to check the IRQ count before getting
second IRQ to avoid below error message during probe:[ 1.070908] gpio-mxc 5d080000.gpio: IRQ index 1 not found
[ 1.077420] gpio-mxc 5d090000.gpio: IRQ index 1 not found
[ 1.083766] gpio-mxc 5d0a0000.gpio: IRQ index 1 not found
[ 1.090122] gpio-mxc 5d0b0000.gpio: IRQ index 1 not found
[ 1.096470] gpio-mxc 5d0c0000.gpio: IRQ index 1 not found
[ 1.102804] gpio-mxc 5d0d0000.gpio: IRQ index 1 not found
[ 1.109144] gpio-mxc 5d0e0000.gpio: IRQ index 1 not found
[ 1.115475] gpio-mxc 5d0f0000.gpio: IRQ index 1 not foundSigned-off-by: Anson Huang
Signed-off-by: Bartosz Golaszewski
Signed-off-by: Sasha Levin
