| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix Kconfig warning for PCENGINES_APU2 symbol:
WARNING: unmet direct dependencies detected for KEYBOARD_GPIO_POLLED
Depends on [n]: !UML && INPUT [=y] && INPUT_KEYBOARD [=n] && GPIOLIB [=y]
Selected by [y]:
- PCENGINES_APU2 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y]
Add INPUT_KEYBOARD dependency for KEYBOARD_GPIO_POLLED.
Add LEDS_CLASS dependency for LEDS_GPIO.
Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver")
Reported-by: Arnd Bergmann <[email protected]>
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Enrico Weigelt, metux IT consult <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
If a PCA953x gpio was used as an interrupt and then released,
the shutdown function was trying to extract the pca953x_chip
pointer directly from the irq_data, but in reality was getting
the gpio_chip structure.
The net effect was that the subsequent writes to the data
structure corrupted data in the gpio_chip structure, which wasn't
immediately obvious until attempting to use the GPIO again in the
future, at which point the kernel panics.
This fix correctly extracts the pca953x_chip structure via the
gpio_chip structure, as is correctly done in the other irq
functions.
Fixes: 0a70fe00efea ("gpio: pca953x: Clear irq trigger type on irq shutdown")
Cc: [email protected]
Signed-off-by: Mark Walton <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Sparse complains:
gpio-amd-fch.c:45:27: sparse: expected void *
gpio-amd-fch.c:45:27: sparse: got void [noderef] <asn:2> *
gpio-amd-fch.c:45:27: sparse: warning: incorrect type in return
expression (different address spaces)
gpio-amd-fch.c:56:9: sparse: expected void const volatile [noderef]
<asn:2> *addr
gpio-amd-fch.c:56:9: sparse: expected void volatile [noderef] <asn:2> *addr
gpio-amd-fch.c:56:9: sparse: got void *ptr
gpio-amd-fch.c:56:9: sparse: warning: incorrect type in argument 1 (different address spaces)
I think it is because void * is returned rather than void __iomem *,
so fix it up.
Cc: Enrico Weigelt <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The build servers and linux-next are complaining like this:
drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe':
drivers/gpio/gpio-amd-fch.c:164:49: warning: passing argument 2 of
'devm_ioremap_resource' discards 'const' qualifier from pointer
target type [-Wdiscarded-qualifiers]
priv->base = devm_ioremap_resource(&pdev->dev, &amd_fch_gpio_iores);
^~~~~~~~~~~~~~~~~~~
In file included from include/linux/platform_device.h:14, from
drivers/gpio/gpio-amd-fch.c:15:
include/linux/device.h:709:15: note: expected 'struct resource *'
but argument is of type 'const struct resource *'
void __iomem *devm_ioremap_resource(struct device *dev,struct resource *res);
^~~~~~~~~~~~~~~~~~~~~
Let's just remove "const" for now.
It is possible that devm_ioremap_resource() should rather
be constified so we can pass const resources as arguments.
But right now I just want to get rid of this build warning.
Fixes: e09d168f13f0 ("gpio: AMD G-Series PCH gpio driver")
Reported-by: Stephen Rothwell <[email protected]>
Reported-by: kbuild test robot <[email protected]>
Reported-by: Anders Roxell <[email protected]>
Cc: Enrico Weigelt <[email protected]>
Tested-by: Anders Roxell <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
On i.MX8MQ platform, clock driver uses platform driver
model and it is probed after GPIO driver, so when GPIO
driver fails to get clock, it should check the error type
to decide whether to return defer probe or just ignore
the clock operation.
Fixes: 2808801aab8a ("gpio: mxc: add clock operation")
Signed-off-by: Anson Huang <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This augments the FTGPIO010 to register one irqchip
per instance instead of using a static definition.
Signed-off-by: Linus Walleij <[email protected]>
|
|
This adds DT bindings for the IXP4xx GPIO controller.
Cc: [email protected]
Reviewed-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Driver for PCengines APUv2 board's front LEDs and Button,
which are attached to AMD PCH GPIOs. Due to lack of dedicated
ACPI entry, detecting the board via DMI.
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
GPIO platform driver for the AMD G-series PCH (eg. on GX-412TC)
This driver doesn't registers itself automatically, as it needs to
be provided with platform specific configuration, provided by some
board driver setup code.
Didn't implement oftree probing yet, as it's rarely found on x86.
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
We only build devm_ioremap_resource() if HAS_IOMEM is selected, so this
dependency must cascade down to devm_platform_ioremap_resource().
Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
For output-only gpios, direction_output should set proper output level.
Signed-off-by: Axel Lin <[email protected]>
Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Change to use SoC compatible string instead of wildcard string.
The Spreadtrum SC9860 platform device trees and drivers' development
are still in progress, and now we will always recompile and ship
device trees at the same time as we will compile and ship the kernel,
so we do not need care about the backwards compatibility.
Signed-off-by: Baolin Wang <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Use SoC compatible string instead of wildcard string.
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Baolin Wang <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Handle both enable-gpio and enable-gpios properties of the GPIO
regulator in the quirk. The later is the preferred modern name
of the property.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Jan Kotas <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: [email protected]
To: [email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Commit 0e7d6f940164 ("gpio: of: Apply regulator-gpio quirk only to
enable-gpios") breaks the device tree ABI specified in the device tree
bindings for fixed regulators (compatible "regulator-fixed"). According
to these bindings the polarity of the GPIO is exclusively controlled by
the presence or absence of the enable-active-high property. As such the
polarity quirk implemented in of_gpio_flags_quirks() must be applied to
the GPIO specified for fixed regulators.
However, commit 0e7d6f940164 ("gpio: of: Apply regulator-gpio quirk only
to enable-gpios") restricted the quirk to the enable-gpios property for
fixed regulators as well, whereas according to the commit message itself
it should only apply to "regulator-gpio" compatible device tree nodes.
Fix this by actually implementing what the offending commit intended,
which is to ensure that the quirk is applied to the GPIO specified by
the "enable-gpio" property for the "regulator-gpio" bindings only.
This fixes a regression on Jetson TX1 where the fixed regulator for the
HDMI +5V pin relies on the flags quirk for the proper polarity.
Fixes: 0e7d6f940164 ("gpio: of: Apply regulator-gpio quirk only to enable-gpios")
Signed-off-by: Thierry Reding <[email protected]>
Tested-by: Marek Vasut <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Use the new helper that wraps the calls to platform_get_resource() and
devm_ioremap_resource() together.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
There are currently 1200+ instances of using platform_get_resource()
and devm_ioremap_resource() together in the kernel tree.
This patch wraps these two calls in a single helper. Thanks to that
we don't have to declare a local variable for struct resource * and can
omit the redundant argument for resource type. We also have one
function call less.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
|
|
According to the manpage of poll(2) and also looking at the respective
syscall providing POLLERR in .events is a no-op. So don't recommend
using it.
Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Implement the irq_set_wake() method in the (optional) irq_chip of the
GPIO expander, and propagate wake-up settings to the upstream interrupt
controller. This allows GPIOs connected to a PCA953X GPIO expander to
serve as wake-up sources.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Niklas Söderlund <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel
gpio: updates for v5.1 - part 2
- gpio-mockup updates improving the user-space testing interface and
adding line state tracking for correct edge interrupts
- interrupt simulator patch exposing the irq type configuration to
users
|
|
This patch hunk is a lightly modified version of a diff found
in a Tegra code dump from a product tree. It makes a lot of
sense because this is what most drivers do.
Cc: Thierry Reding <[email protected]>
Cc: Stefan Agner <[email protected]>
Cc: Dmitry Osipenko <[email protected]>
Cc: Jon Hunter <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Modify the way the debugfs interface works in gpio-mockup. Introduce
the concept of dummy pull config which will keep the mockup lines in
known state. The pull values can be modified by writing to the debugfs
files corresponding to lines. Lines in input mode always report the
current pull value, lines in output mode change the line value but
it will revert back to the one specified by current pull when released.
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
The unlocked variants only get called from places where we already have
the pointer to the underlying gpio_mockup_chip structure, so take it
as parameter instead of struct gpio_chip.
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
This field can never be negative.
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
User-space tests no longer use it and we're breaking the interface
anyway.
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
We already support set_multiple(). Implement get_multiple() as well.
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
While no user reported any race condition problems with gpio-mockup,
let's be on the safe side and use a mutex when performing any changes
on the dummy chip structures.
Suggested-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
Implement the irq_set_type() callback and call irqd_set_trigger_type()
internally so that users interested in the configured trigger type can
later retrieve it using irqd_get_trigger_type(). We only support edge
trigger types.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
|
|
Since commit d6cd33ad7102 ("regulator: gpio: Convert to use descriptors")
the GPIO regulator had inverted the polarity of the control GPIO. This
problem manifested itself on systems with DT containing the following
description (snippet from salvator-common.dtsi):
gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
gpios-states = <1>;
states = <3300000 1
1800000 0>;
Prior to the aforementioned commit, the gpio-regulator code used
gpio_request_array() to claim the GPIO(s) specified in the "gpios"
DT node, while the commit changed that to devm_gpiod_get_index().
The legacy gpio_request_array() calls gpio_request_one() and then
gpiod_request(), which parses the DT flags of the "gpios" node and
populates the GPIO descriptor flags field accordingly.
The new devm_gpiod_get_index() calls gpiod_get_index(), then
of_find_gpio(), of_get_named_gpiod_flags() with flags != NULL,
and then of_gpio_flags_quirks(). Since commit a603a2b8d86e
("gpio: of: Add special quirk to parse regulator flags"),
of_gpio_flags_quirks() contains a quirk for regulator-gpio
which was never triggered by the legacy gpio_request_array()
code path, but is triggered by devm_gpiod_get_index() code
path.
This quirk checks whether a GPIO is associated with a fixed
or gpio-regulator and if so, checks two additional conditions.
First, whether such GPIO is active-low, and if so, ignores the
active-low flag. Second, whether the regulator DT node does
have an "enable-active-high" property and if the property is
NOT present, sets the GPIO flags as active-low.
The second check triggers a problem, since it is applied to all
GPIOs associated with a gpio-regulator, rather than only on the
"enable" GPIOs, as the old code did. This changes the way the
gpio-regulator interprets the DT description of the control
GPIOs.
The old code using gpio_request_array() explicitly parsed the
"enable-active-high" DT property and only applied it to the
GPIOs described in the "enable-gpios" DT node, and only if
those were present.
This patch fixes the quirk code by only applying the quirk
to "enable-gpios", thus restoring the old behavior.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Jan Kotas <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: [email protected]
To: [email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into devel
intel-gpio for v5.1-1
Small clean up for Intel PMIC GPIO drivers, includes:
- optimizing IRQ handlers by usage of for_each_set_bit()
- sorting headers alphabetically for better maintenance
- conversion to SPDX identifier
The following is an automated git shortlog grouped by driver:
crystalcove:
- Convert to use SPDX identifier
- Sort headers alphabetically
- Use for_each_set_bit() in IRQ handler
msic:
- Convert to use SPDX identifier
- Sort headers alphabetically
- Remove duplicate check in IRQ handler
wcove:
- Convert to use SPDX identifier
- Fix indentation
- Sort headers alphabetically
- Allow return negative error code from to_reg()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel
gpio updates for v5.1
- support for a new variant of pca953x
- documentation fix from Wolfram
- some tegra186 name changes
- two minor fixes for madera and altera-a10sr
|
|
Change the coding style to make it does error checking first.
This also fixes checkpatch warning about line over 80 characters.
Signed-off-by: Axel Lin <[email protected]>
Tested by: Thor Thayer <[email protected]>
Reviewed by: Thor Thayer <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
The new prefix allows the GPIOs to be uniquely identified on a per-chip
basis, which makes it easier to distinguish Tegra186 specific GPIOs from
those of later chips such as Tegra194 which supports a very different
set of GPIOs.
Signed-off-by: Thierry Reding <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
Typo: the data line is called "SDA" not "SCA".
Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
madera_gpio_chip is only used as a template so it can be marked as const.
Signed-off-by: Charles Keepax <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
The NXP PCAL6416, documented at [1], is a variant of the PCA GPIO
expander with 16 GPIOs, and supporting an interrupt and the "extended"
features for interrupt, pull-up/pull-down configuration, etc.
[1] https://www.nxp.com/docs/en/data-sheet/PCAL6416A.pdf
Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
The NXP PCAL6416 is a variant of the PCA GPIO expander, with 16 GPIOs.
Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
SSBI GPIOs are numbered 1..ngpio, so the boundary check in
pm8xxx_domain_translate() is off by one. This patch corrects that check.
Signed-off-by: Brian Masney <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Select IRQ_DOMAIN_HIERARCHY for pm8xxx in Kconfig since this driver uses
the version 2 IRQ interfaces. IRQ_DOMAIN_HIERARCHY selects IRQ_DOMAIN,
so it can be removed from here.
Signed-off-by: Brian Masney <[email protected]>
Acked-by: Lee Jones <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Select IRQ_DOMAIN_HIERARCHY for pmic-arb in Kconfig since this driver
uses the version 2 IRQ interfaces. IRQ_DOMAIN_HIERARCHY selects
IRQ_DOMAIN, so it can be removed from here.
Signed-off-by: Brian Masney <[email protected]>
Reported-by: Randy Dunlap <[email protected]>
Acked-by: Randy Dunlap <[email protected]> # build-tested
Signed-off-by: Linus Walleij <[email protected]>
|
|
Unlike gpio_rcar_irq_set_wake(), which this solution was based on,
pcf857x_irq_set_wake() does not need to do anything else than calling
irq_set_irq_wake() for the upstream interrupt controller. Hence there
is no reason for making this call conditional, and no longer a need for
keeping a copy of the interrupt number that also serves as a flag.
Just propagate irq_set_irq_wake() to the upstream interrupt controller,
using the original interrupt number.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Niklas Söderlund <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
|
|
Fix the following warning by adding a missing break:
drivers/gpio/gpio-eic-sprd.c: In function ‘sprd_eic_irq_set_type’:
drivers/gpio/gpio-eic-sprd.c:403:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
switch (flow_type) {
^~~~~~
drivers/gpio/gpio-eic-sprd.c:435:2: note: here
default:
^~~~~~~
This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Baolin Wang <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The Zynq GPIO driver currently implements runtime PM by:
- Enabling runtime PM support in ->probe() and letting the runtime PM
reference counter drop to zero at the end of ->probe().
- Increasing the runtime PM reference counter in ->request() and
decreasing it in ->free().
However, the latter is not sufficient: when a GPIO is used as an
interrupt, ->request() and ->free() are not called. Due to this, the
runtime PM counter remains to zero when the only GPIOs in use are used
as interrupts, causing them to simply not work.
To address this problem, this commit implement the
->irq_request_resources() and ->irq_release_resources() hooks,
ensuring that the runtime PM counter is properly
incremented/decremented. Since we override the default hooks, we keep
the existing behavior by making sure they call gpiochip_reqres_irq() /
gpiochip_relres_irq() respectively.
Signed-off-by: Thomas Petazzoni <[email protected]>
Reviewed-by: Shubhrajyoti Datta <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Now that ssbi-gpio is a proper hierarchical IRQ chip, and all in-tree
users of device tree have been updated, we can now drop the hack that
was introduced to disassociate the old Linux virq if a hwirq mapping
already exists. That patch was introduced to not break git bisect for
any existing boards.
This change was tested on an APQ8060 DragonBoard.
Signed-off-by: Brian Masney <[email protected]>
Tested-by: Linus Walleij <[email protected]>
Acked-by: Lee Jones <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Before we fixed up the interrupt hierarchy for the SSBI
GPIO controller, we had to use the PM8058 directly to pick
interrupts. After making the interrupt controller work properly,
we can reference the real interrupt parent.
Signed-off-by: Brian Masney <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Add interrupt controller properties now that ssbi-gpio is a proper
hierarchical IRQ chip. The interrupts property is no longer needed so
remove it.
Note that the IRQs started at 24 instead of 192 like all of the other
PMICs. This is the same IRQs as the MPP for this board. qcom-pm8xxx.c
doesn't set the shared IRQs so this is highly likely to be a copy and
paste error.
Signed-off-by: Brian Masney <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Add interrupt controller properties now that ssbi-gpio is a proper
hierarchical IRQ chip. The interrupts property is no longer needed so
remove it.
This change was tested on an APQ8060 DragonBoard.
Signed-off-by: Brian Masney <[email protected]>
Tested-by: Linus Walleij <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Add interrupt controller properties now that ssbi-gpio is a proper
hierarchical IRQ chip. The interrupts property is no longer needed so
remove it.
This change was not tested on any hardware but the same change was
tested on an APQ8060 DragonBoard with no issues.
Signed-off-by: Brian Masney <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|