[ Upstream commit 2b745ac3cc ]
The GPIOAO pins (as well as the two exotic GPIO_BSD_EN and GPIO_TEST_N)
only belong to the pin controller in the AO domain. With the current
definition these pins cannot be referred to in .dts files as group
(which is possible on GXBB and GXL for example).
Add a separate "gpio_aobus" function to fix the mapping between the pin
controller and the GPIO pins in the AO domain. This is similar to how
the GXBB and GXL drivers implement this functionality.
Fixes: 9dab1868ec ("pinctrl: amlogic: Make driver independent from two-domain configuration")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 42f9b48cc5 ]
The GPIOAO pins (as well as the two exotic GPIO_BSD_EN and GPIO_TEST_N)
only belong to the pin controller in the AO domain. With the current
definition these pins cannot be referred to in .dts files as group
(which is possible on GXBB and GXL for example).
Add a separate "gpio_aobus" function to fix the mapping between the pin
controller and the GPIO pins in the AO domain. This is similar to how
the GXBB and GXL drivers implement this functionality.
Fixes: 9dab1868ec ("pinctrl: amlogic: Make driver independent from two-domain configuration")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a9d9f6b83f ]
devm_kstrdup() may return NULL if internal allocation failed.
Thus using label, name is unsafe without checking. Therefor
in the unlikely case of allocation failure, sx150x_probe() simply
returns -ENOMEM.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Fixes: 9e80f9064e ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3c7b30f704 ]
The BCM2835 pinctrl driver acquires a spinlock in its ->irq_enable,
->irq_disable and ->irq_set_type callbacks. Spinlocks become sleeping
locks with CONFIG_PREEMPT_RT_FULL=y, therefore invocation of one of the
callbacks in atomic context may cause a hard lockup if at least two GPIO
pins in the same bank are used as interrupts. The issue doesn't occur
with just a single interrupt pin per bank because the lock is never
contended. I'm experiencing such lockups with GPIO 8 and 28 used as
level-triggered interrupts, i.e. with ->irq_disable being invoked on
reception of every IRQ.
The critical section protected by the spinlock is very small (one bitop
and one RMW of an MMIO register), hence converting to a raw spinlock
seems a better trade-off than converting the driver to threaded IRQ
handling (which would increase latency to handle an interrupt).
Cc: Mathias Duckeck <m.duckeck@kunbus.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Julia Cartwright <julia@ni.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 614b1868a1 ]
We just changed the code so we apply bias disable on the correct
register but forgot to align the register calculation. The result
is that we apply the change on the correct register, but possibly
at the incorrect offset/bit
This went undetected because offsets tends to be the same between
REG_PULL and REG_PULLEN for a given pin the EE controller. This
is not true for the AO controller.
Fixes: e39f9dd820 ("pinctrl: meson: fix pinconf bias disable")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 478b6767ad upstream.
Pin PH11 is used on various A83T board to detect a change in the OTG
port's ID pin, as in when an OTG host cable is plugged in.
The incorrect offset meant the gpiochip/irqchip was activating the wrong
pin for interrupts.
Fixes: 4730f33f0d ("pinctrl: sunxi: add allwinner A83T PIO controller support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit e39f9dd820 ]
If a bias is enabled on a pin of an Amlogic SoC, calling .pin_config_set()
with PIN_CONFIG_BIAS_DISABLE will not disable the bias. Instead it will
force a pull-down bias on the pin.
Instead of the pull type register bank, the driver should access the pull
enable register bank.
Fixes: 6ac7309511 ("pinctrl: add driver for Amlogic Meson SoCs")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b432414b99 ]
If you look at "pinconf-groups" in debugfs for ssbi-gpio you'll notice
it looks like nonsense.
The problem is fairly well described in commit 1cf86bc212 ("pinctrl:
qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant") and
commit 05e0c82895 ("pinctrl: msm: Fix msm_config_group_get() to be
compliant"), but it was pointed out that ssbi-gpio has the same
problem. Let's fix it there too.
Fixes: b4c45fe974 ("pinctrl: qcom: ssbi: Family A gpio & mpp drivers")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 0d5b476f8f ]
If you look at "pinconf-groups" in debugfs for ssbi-mpp you'll notice
it looks like nonsense.
The problem is fairly well described in commit 1cf86bc212 ("pinctrl:
qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant") and
commit 05e0c82895 ("pinctrl: msm: Fix msm_config_group_get() to be
compliant"), but it was pointed out that ssbi-mpp has the same
problem. Let's fix it there too.
NOTE: in case it's helpful to someone reading this, the way to tell
whether to do the -EINVAL or not is to look at the PCONFDUMP for a
given attribute. If the last element (has_arg) is false then you need
to do the -EINVAL trick.
ALSO NOTE: it seems unlikely that the values returned when we try to
get PIN_CONFIG_BIAS_PULL_UP will actually be printed since "has_arg"
is false for that one, but I guess it's still fine to return different
values so I kept doing that. It seems like another driver (ssbi-gpio)
uses a custom attribute (PM8XXX_QCOM_PULL_UP_STRENGTH) for something
similar so maybe a future change should do that here too.
Fixes: cfb24f6ebd ("pinctrl: Qualcomm SPMI PMIC MPP pin controller driver")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 89c68b102f ]
It looks like we parse the drive strength setting here, but never
actually write it into the hardware to update it. Parse the setting and
then write it at the end of the pinconf setting function so that it
actually sticks in the hardware.
Fixes: 0e948042c4 ("pinctrl: qcom: spmi-mpp: Implement support for sink mode")
Cc: Doug Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit a4925311a5 ]
fixes following Smatch static check warning:
./drivers/pinctrl/sunxi/pinctrl-sunxi.c:1112 sunxi_pinctrl_build_state()
warn: passing devm_ allocated variable to kfree. 'pctrl->functions'
As we will be calling krealloc() on pointer 'pctrl->functions', which means
kfree() will be called in there, devm_kzalloc() shouldn't be used with
the allocation in the first place. Fix the warning by calling kcalloc()
and managing the free procedure in error path on our own.
Fixes: 0e37f88d9a ("ARM: sunxi: Add pinctrl driver for Allwinner SoCs")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since 'commit 02e389e63e ("pinctrl: mcp23s08: fix irq setup order")' the
irq request isn't the last devm_* allocation. Without a deeper look at
the irq and testing this isn't a good solution. Since this driver relies
on the devm mechanism, requesting a interrupt should be the last thing
to avoid memory corruptions during unbinding.
'Commit 02e389e63e ("pinctrl: mcp23s08: fix irq setup order")' fixed the
order for the interrupt-controller use case only. The
mcp23s08_irq_setup() must be split into two to fix it for the
interrupt-controller use case and to register the irq at last. So the
irq will be freed first during unbind.
Cc: stable@vger.kernel.org
Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
Cc: Dmitry Mastykin <mastichi@gmail.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Fixes: 82039d244f ("pinctrl: mcp23s08: add pinconf support")
Fixes: 02e389e63e ("pinctrl: mcp23s08: fix irq setup order")
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Tested-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This reverts commit 55aedef50d.
Commit 55aedef50d ("pinctrl: intel: Do pin translation when lock IRQ")
added special translation from GPIO number to hardware pin number to
irq_reqres/relres hooks to avoid failure when IRQs are requested. The
actual failure happened inside gpiochip_lock_as_irq() because it calls
gpiod_get_direction() and pinctrl-intel.c::intel_gpio_get_direction()
implementation originally missed the translation so the two hooks made
it work by skipping the ->get_direction() call entirely (it overwrote
the default GPIOLIB provided functions).
The proper fix that adds translation to GPIO callbacks was merged with
commit 96147db1e1 ("pinctrl: intel: Do pin translation in other GPIO
operations as well"). This allows us to use the default GPIOLIB provided
functions again.
In addition as find out by Benjamin Tissoires the two functions
(intel_gpio_irq_reqres()/intel_gpio_irq_relres()) now cause problems of
their own because they operate on pin numbers and pass that pin number
to gpiochip_lock_as_irq() which actually expects a GPIO number.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=199911
Fixes: 55aedef50d ("pinctrl: intel: Do pin translation when lock IRQ")
Reported-and-tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
From the AMD BKDG, if WAKE_INT_MASTER_REG.MaskStsEn is set, a software
write to the debounce registers of *any* gpio will block wake/interrupt
status generation for *all* gpios for a length of time that depends on
WAKE_INT_MASTER_REG.MaskStsLength[11:0]. During this period the Interrupt
Delivery bit (INTERRUPT_ENABLE) will read as 0.
In commit 4c1de0414a ("pinctrl/amd: poll InterruptEnable bits in
enable_irq") we tried to fix this same "gpio Interrupts are blocked
immediately after writing debounce registers" problem, but incorrectly
assumed it only affected the gpio whose debounce was being configured
and not ALL gpios.
To solve this for all gpios, we move the polling loop from
amd_gpio_irq_enable() to amd_gpio_irq_set_type(), while holding the gpio
spinlock. This ensures that another gpio operation (e.g.
amd_gpio_irq_unmask()) can read a temporarily disabled IRQ and
incorrectly disable it while trying to modify some other register bits.
Fixes: 4c1de0414a pinctrl/amd: poll InterruptEnable bits in enable_irq
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For some reason I thought GPIOLIB handles translation from GPIO ranges
to pinctrl pins but it turns out not to be the case. This means that
when GPIOs operations are performed for a pin controller having a custom
GPIO base such as Cannon Lake and Ice Lake incorrect pin number gets
used internally.
Fix this in the same way we did for lock/unlock IRQ operations and
translate the GPIO number to pin before using it.
Fixes: a60eac3239 ("pinctrl: intel: Allow custom GPIO base for pad groups")
Reported-by: Rajat Jain <rajatja@google.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Rajat Jain <rajatja@google.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If we are being configured via pdata we don't necessarily have
any gpio mappings being configured that way so pdata->gpio_config
could be NULL.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit a203728ac6 ("pinctrl: core: Return selector to the pinctrl
driver") and commit f913cfce4e ("pinctrl: pinmux: Return selector to
the pinctrl driver") modified the return values of
pinctrl_generic_add_group() and pinmux_generic_add_function()
respectively, but did so without updating their callers. This broke the
pinctrl-ingenic driver, which treats non-zero return values from these
functions as errors & fails to probe. For example on a MIPS Ci20:
pinctrl-ingenic 10010000.pin-controller: Failed to register group uart0-hwflow
pinctrl-ingenic: probe of 10010000.pin-controller failed with error 1
Without the pinctrl driver probed, other drivers go on to fail to probe
too & the system is unusable.
Fix this by modifying the error checks to treat only negative values as
errors, matching the commits that introduced the breakage & similar
changes made to other drivers.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes: a203728ac6 ("pinctrl: core: Return selector to the pinctrl driver")
Fixes: f913cfce4e ("pinctrl: pinmux: Return selector to the pinctrl driver")
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The interrupt controller hardware in this pin controller has two status
enable bits. The first "normal" status enable bit enables or disables
the summary interrupt line being raised when a gpio interrupt triggers
and the "raw" status enable bit allows or prevents the hardware from
latching an interrupt into the status register for a gpio interrupt.
Currently we just toggle the "normal" status enable bit in the mask and
unmask ops so that the summary irq interrupt going to the CPU's
interrupt controller doesn't trigger for the masked gpio interrupt.
For a level triggered interrupt, the flow would be as follows: the pin
controller sees the interrupt, latches the status into the status
register, raises the summary irq to the CPU, summary irq handler runs
and calls handle_level_irq(), handle_level_irq() masks and acks the gpio
interrupt, the interrupt handler runs, and finally unmask the interrupt.
When the interrupt handler completes, we expect that the interrupt line
level will go back to the deasserted state so the genirq code can unmask
the interrupt without it triggering again.
If we only mask the interrupt by clearing the "normal" status enable bit
then we'll ack the interrupt but it will continue to show up as pending
in the status register because the raw status bit is enabled, the
hardware hasn't deasserted the line, and thus the asserted state latches
into the status register again. When the hardware deasserts the
interrupt the pin controller still thinks there is a pending unserviced
level interrupt because it latched it earlier. This behavior causes
software to see an extra interrupt for level type interrupts each time
the interrupt is handled.
Let's fix this by clearing the raw status enable bit for level type
interrupts so that the hardware stops latching the status of the
interrupt after we ack it. We don't do this for edge type interrupts
because it seems that toggling the raw status enable bit for edge type
interrupts causes spurious edge interrupts.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull MFD updates from Lee Jones:
"New Drivers:
- Add Cirrus Logic Madera Codec (CS47L35, CS47L85 and CS47L90/91) driver
- Add ChromeOS EC CEC driver
- Add ROHM BD71837 PMIC driver
New Device Support:
- Add support for Dialog Semi DA9063L PMIC variant to DA9063
- Add support for Intel Ice Lake to Intel-PLSS-PCI
- Add support for X-Powers AXP806 to AXP20x
New Functionality:
- Add support for USB Charging to the ChromeOS Embedded Controller
- Add support for HDMI CEC to the ChromeOS Embedded Controller
- Add support for HDMI CEC to Intel HDMI
- Add support for accessory detection to Madera devices
- Allow individual pins to be configured via DT' wlf,csnaddr-pd
- Provide legacy platform specific EEPROM/Watchdog commands; rave-sp
Fix-upsL
- Trivial renaming/spelling fixes; cros_ec, da9063-*
- Convert to Managed Resources (devm_*); da9063-*, ti_am335x_tscadc
- Transition to helper macros/functions; da9063-*
- Constify; kempld-core
- Improve error path/messages; wm8994-core
- Disable IRQs locally instead of relying on USB subsystem; dln2
- Remove unused code; rave-sp
- New exports; sec-core
Bug Fixes:
- Fix possible false I2C transaction error; arizona-core
- Fix declared memory area size; hi655x-pmic
- Fix checksum type; rave-sp
- Fix incorrect default serial port configuration: rave-sp
- Fix incorrect coherent DMA mask for sub-devices; sm501"
* tag 'mfd-next-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (60 commits)
mfd: madera: Add register definitions for accessory detect
mfd: sm501: Set coherent_dma_mask when creating subdevices
mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
mfd: bd71837: Core driver for ROHM BD71837 PMIC
media: platform: cros-ec-cec: Fix dependency on MFD_CROS_EC
mfd: sec-core: Export OF module alias table
mfd: as3722: Disable auto-power-on when AC OK
mfd: axp20x: Support AXP806 in I2C mode
mfd: axp20x: Add self-working mode support for AXP806
dt-bindings: mfd: axp20x: Add "self-working" mode for AXP806
mfd: wm8994: Allow to configure CS/ADDR Pulldown from dts
mfd: wm8994: Allow to configure Speaker Mode Pullup from dts
mfd: rave-sp: Emulate CMD_GET_STATUS on device that don't support it
mfd: rave-sp: Add legacy watchdog ping command translation
mfd: rave-sp: Add legacy EEPROM access command translation
mfd: rave-sp: Initialize flow control and parity of the port
mfd: rave-sp: Fix incorrectly specified checksum type
mfd: rave-sp: Remove unused defines
mfd: hi655x: Fix regmap area declared size for hi655x
mfd: ti_am335x_tscadc: Fix struct clk memory leak
...
Pull driver core updates from Greg KH:
"Here are all of the driver core and related patches for 4.19-rc1.
Nothing huge here, just a number of small cleanups and the ability to
now stop the deferred probing after init happens.
All of these have been in linux-next for a while with only a merge
issue reported"
* tag 'driver-core-4.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (21 commits)
base: core: Remove WARN_ON from link dependencies check
drivers/base: stop new probing during shutdown
drivers: core: Remove glue dirs from sysfs earlier
driver core: remove unnecessary function extern declare
sysfs.h: fix non-kernel-doc comment
PM / Domains: Stop deferring probe at the end of initcall
iommu: Remove IOMMU_OF_DECLARE
iommu: Stop deferring probe at end of initcalls
pinctrl: Support stopping deferred probe after initcalls
dt-bindings: pinctrl: add a 'pinctrl-use-default' property
driver core: allow stopping deferred probe after init
driver core: add a debugfs entry to show deferred devices
sysfs: Fix internal_create_group() for named group updates
base: fix order of OF initialization
linux/device.h: fix kernel-doc notation warning
Documentation: update firmware loader fallback reference
kobject: Replace strncpy with memcpy
drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
kernfs: Replace strncpy with memcpy
device: Add #define dev_fmt similar to #define pr_fmt
...
Pull char/misc driver updates from Greg KH:
"Here is the bit set of char/misc drivers for 4.19-rc1
There is a lot here, much more than normal, seems like everyone is
writing new driver subsystems these days... Anyway, major things here
are:
- new FSI driver subsystem, yet-another-powerpc low-level hardware
bus
- gnss, finally an in-kernel GPS subsystem to try to tame all of the
crazy out-of-tree drivers that have been floating around for years,
combined with some really hacky userspace implementations. This is
only for GNSS receivers, but you have to start somewhere, and this
is great to see.
Other than that, there are new slimbus drivers, new coresight drivers,
new fpga drivers, and loads of DT bindings for all of these and
existing drivers.
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-4.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (255 commits)
android: binder: Rate-limit debug and userspace triggered err msgs
fsi: sbefifo: Bump max command length
fsi: scom: Fix NULL dereference
misc: mic: SCIF Fix scif_get_new_port() error handling
misc: cxl: changed asterisk position
genwqe: card_base: Use true and false for boolean values
misc: eeprom: assignment outside the if statement
uio: potential double frees if __uio_register_device() fails
eeprom: idt_89hpesx: clean up an error pointer vs NULL inconsistency
misc: ti-st: Fix memory leak in the error path of probe()
android: binder: Show extra_buffers_size in trace
firmware: vpd: Fix section enabled flag on vpd_section_destroy
platform: goldfish: Retire pdev_bus
goldfish: Use dedicated macros instead of manual bit shifting
goldfish: Add missing includes to goldfish.h
mux: adgs1408: new driver for Analog Devices ADGS1408/1409 mux
dt-bindings: mux: add adi,adgs1408
Drivers: hv: vmbus: Cleanup synic memory free path
Drivers: hv: vmbus: Remove use of slow_virt_to_phys()
Drivers: hv: vmbus: Reset the channel callback in vmbus_onoffer_rescind()
...
Pull pin control updates from Linus Walleij:
"This is the bulk of pin control changes for v4.19:
Core changes:
- Augment pinctrl_generic_add_group() and pinmux_generic_add_function()
to return the selector for the added group/function to the caller
and augment (hopefully) all drivers to handle this
New subdrivers:
- Qualcomm PM8998 and PM8005 are supported in the SPMI pin control
and GPIO driver
- Intel Ice Lake PCH (platform controller hub) support
- NXP (ex Freescale) i.MX8MQ support
- Berlin AS370 support
Improvements to drivers:
- Support interrupts on the Ocelot pin controller
- Add SPI pins to the Uniphier driver
- Define a GPIO compatible per SoC in the Tegra driver
- Push Tegra initialization down in the initlevels
- Support external wakeup interrupts on the Exynos
- Add generic clocks pins to the meson driver
- Add USB and HSCIF pins for some Renesas PFC chips
- Suspend/resume support in the armada-37xx
- Interrupt support for the Actions Semiconductor S900 also known as
"owl"
- Correct the pin ordering in Cedarfork
- Debugfs output for INTF in the mcp23s08 driver
- Avoid divisions in context save/restore in pinctrl-single
The rest is minor bug fixes or cleanups"
* tag 'pinctrl-v4.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (69 commits)
pinctrl: nomadik: silence uninitialized variable warning
pinctrl: axp209: Fix NULL pointer dereference after allocation
pinctrl: samsung: Remove duplicated "wakeup" in printk
pinctrl: ocelot: add support for interrupt controller
pinctrl: intel: Don't shadow error code of gpiochip_lock_as_irq()
pinctrl: berlin: fix 'pctrl->functions' allocation in berlin_pinctrl_build_state
gpio: tegra: Move driver registration to subsys_init level
pinctrl: tegra: Move drivers registration to arch_init level
pinctrl: baytrail: actually print the apparently misconfigured pin
MAINTAINERS: Replace Heikki as maintainer of Intel pinctrl
pinctrl: freescale: off by one in imx1_pinconf_group_dbg_show()
pinctrl: uniphier: add spi pin-mux settings
pinctrl: cannonlake: Fix community ordering for H variant
pinctrl: tegra: define GPIO compatible node per SoC
pinctrl: intel: Do pin translation when lock IRQ
pinctrl: imx: off by one in imx_pinconf_group_dbg_show()
pinctrl: mediatek: include chained_irq.h header
pinctrl/amd: only handle irq if it is pending and unmasked
pinctrl/amd: fix gpio irq level in debugfs
pinctrl: stm32: add syscfg mask parameter
...
This is harmless, but "val" isn't necessarily initialized if
abx500_get_register_interruptible() fails. I've re-arranged the code to
just return an error code in that situation.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is no check that allocation in axp20x_funcs_groups_from_mask
is successful.
The patch adds corresponding check and return values.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This GPIO controller can serve as an interrupt controller as well on the
GPIOs it handles.
An interrupt is generated whenever a GPIO line changes and the
interrupt for this GPIO line is enabled. This means that both the
changes from low to high and high to low generate an interrupt.
For some use cases, it makes sense to ignore the high to low change and
not generate an interrupt. Such a use case is a line that is hold in a
level high/low manner until the event holding the line gets acked.
This can be achieved by making sure the interrupt on the GPIO controller
side gets acked and masked only after the line gets hold in its default
state, this is what's done with the fasteoi functions.
Only IRQ_TYPE_EDGE_BOTH and IRQ_TYPE_LEVEL_HIGH are supported for now.
Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
fixes following Smatch static check warning:
drivers/pinctrl/berlin/berlin.c:237 berlin_pinctrl_build_state()
warn: passing devm_ allocated variable to kfree. 'pctrl->functions'
As we will be calling krealloc() on pointer 'pctrl->functions', which means
kfree() will be called in there, devm_kzalloc() shouldn't be used with
the allocation in the first place. Fix the warning by calling kcalloc()
and managing the free procedure in error path on our own.
Fixes: 3de68d331c ("pinctrl: berlin: add the core pinctrl driver for Marvell Berlin SoCs")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is a bug in regards to deferred probing within the drivers core
that causes GPIO-driver to suspend after its users. The bug appears if
GPIO-driver probe is getting deferred, which happens after introducing
dependency on PINCTRL-driver for the GPIO-driver by defining "gpio-ranges"
property in device-tree. The bug in the drivers core is old (more than 4
years now) and is well known, unfortunately there is no easy fix for it.
The good news is that we can workaround the deferred probe issue by
changing GPIO / PINCTRL drivers registration order and hence by moving
PINCTRL driver registration to the arch_init level and GPIO to the
subsys_init.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The info->groups[] array is allocated in imx1_pinctrl_parse_dt(). It
has info->ngroups elements. Thus the > here should be >= to prevent
reading one element beyond the end of the array.
Cc: stable@vger.kernel.org
Fixes: 30612cd900 ("pinctrl: imx1 core driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Uwe Kleine-König <u.kleine-könig@pengutronix.de>
Acked-by: Dong Aisheng <Aisheng.dong@nxp.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tegra 2 uses a different GPIO controller which uses "tegra20-gpio" as
compatible string.
Make the compatible string the GPIO node is using a SoC specific
property. This prevents the kernel from registering the GPIO range
twice in case the GPIO range is specified in the device tree.
Fixes: 9462510ce3 ("pinctrl: tegra: Only set the gpio range if needed")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Default GPIOLIB callbacks for request and release IRQ do not do a GPIO
to pin translation which is necessary for Intel hardware, such as Intel
Cannonlake. Absence of the translation prevents some pins to be locked
as IRQ due to direction check. Introduce own callbacks to make
translation possible to avoid above issue.
Fixes: a60eac3239 ("pinctrl: intel: Allow custom GPIO base for pad groups")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The > should really be >= here. It's harmless because
pinctrl_generic_get_group() will return a NULL if group is invalid.
Fixes: ae75ff8145 ("pinctrl: pinctrl-imx: add imx pinctrl core driver")
Reported-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some randconfig builds fail in the mtk-eint driver:
drivers/pinctrl/mediatek/mtk-eint.c: In function 'mtk_eint_irq_handler':
drivers/pinctrl/mediatek/mtk-eint.c:324:2: error: implicit declaration of function 'chained_irq_enter'; did you mean 'rcu_irq_enter'? [-Werror=implicit-function-declaration]
chained_irq_enter(chip, desc);
^~~~~~~~~~~~~~~~~
rcu_irq_enter
drivers/pinctrl/mediatek/mtk-eint.c:367:2: error: implicit declaration of function 'chained_irq_exit'; did you mean 'rcu_irq_exit'? [-Werror=implicit-function-declaration]
The functions are declared in linux/irqchip/chained_irq.h, and including
that header makes it build in all configurations.
Fixes: e46df235b4 ("pinctrl: mediatek: refactor EINT related code for all MediaTek pinctrl can fit")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The AMD pinctrl driver demultiplexes GPIO interrupts and fires off their
individual handlers.
If one of these GPIO irqs is configured as a level interrupt, and its
downstream handler is a threaded ONESHOT interrupt, the GPIO interrupt
source is masked by handle_level_irq() until the eventual return of the
threaded irq handler. During this time the level GPIO interrupt status
will still report as high until the actual gpio source is cleared - both
in the individual GPIO interrupt status bit (INTERRUPT_STS_OFF) and in
its corresponding "WAKE_INT_STATUS_REG" bit.
Thus, if another GPIO interrupt occurs during this time,
amd_gpio_irq_handler() will see that the (masked-and-not-yet-cleared)
level irq is still pending and incorrectly call its handler again.
To fix this, have amd_gpio_irq_handler() check for both interrupts status
and mask before calling generic_handle_irq().
Note: Is it possible that this bug was the source of the interrupt storm
on Ryzen when using chained interrupts before commit ba714a9c1d
("pinctrl/amd: Use regular interrupt instead of chained")?
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
According to the AMD BKDG, the GPIO ActiveLevel bits (10:9) map to:
00 Active High
01 Active Low
10 Active on both edges iff LevelTrig (bit 8) == 0
11 Reserved
The current code has a bug where it interprets 00 => Active Low, and
01 => Active High.
Fix the bug, restrict "Active on both" to just the edge trigger case, and
refactor a bit to make the logic more readable.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds mask parameter to define IRQ mux field.
This field could vary depend of IRQ mux selection register.
To avoid backward compatibility, the drivers set
the legacy value by default.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Register a new GPIO bank only if GPIO bank node is enabled. This patch also
adds checks on ranges which are defined only if a bank is registered.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In case the exti line is not in line with the bank number (that is the case
when there is an hole between two banks, for example GPIOK and then GPIOZ),
use "st,bank-ioport" DT property to get the right exti line.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Martin Blumenstingl
Nicholas Mc Guire
Lukas Wunner
Jerome Brunet
Chen-Yu Tsai
Douglas Anderson
Stephen Boyd
YueHaibing
Marco Felsch
Mika Westerberg
Daniel Kurtz
Simon Detheridge
Richard Fitzgerald
Paul Burton
Linus Torvalds
Dan Carpenter
Anton Vasilyev
Krzysztof Kozlowski
Quentin Schulz
Andy Shevchenko
Dmitry Osipenko
Alexander Stein
Kunihiko Hayashi
Greg Kroah-Hartman
Stefan Agner
Arnd Bergmann
Ludovic Barre
Alexandre Torgue