08 Jun, 2017
6 commits
-
On i.MX7ULP, the IOMUXC PAD register has IBE and OBE bit to control
the input/output buffer if a PIN wants to use as GPIO function.Additonally, on i.MX7ULP, the MUX reg and CONFIG reg is shared in one
register and the GPIO function select in the MUX is not index zero as
on I.MX6 SOC, add support in code for i.MX7ULP GPIO function.Signed-off-by: Bai Ping
Signed-off-by: Fugang Duan
Signed-off-by: Peter Chen -
On i.MX7ULP, IOMUX's mux and pad config are in
same register, but mux field is different, add
support in pinctrl driver.Signed-off-by: Anson Huang
-
Add property to define mux register mask bits when SHARE_MUX_CONF_REG
flag is added.Signed-off-by: Fugang Duan
-
Add support for imx7ulp iomux controller.
Signed-off-by: Fugang Duan
-
Add pinctrl driver support for i.MX6SLL.
Signed-off-by: Anson Huang
Signed-off-by: Bai Ping -
On i.MX6ULL, the BOOT_MODEx and TAMPERx pin MUX and CTRL register
have been moved from IOMUXC to IOMUXC_SNVS, so the pinctrl driver
should be modified to support the IOMUXC_SNVS.Signed-off-by: Bai Ping
23 Feb, 2017
2 commits
-
To support pinctl hog restore after LPSR resume back,
add suspend/resume in pinctrl driver.Signed-off-by: Robin Gong
-
It's pretty common that on some reference design or validation boards,
one pin could be used by two devices on board, and the pin route is
controlled by a GPIO. So to assert the pin for given device, not only
the pinmux controller in SoC needs to be set up properly but also the
GPIO needs to be pulled up/down.The patch adds support of a device tree property "pinctrl-assert-gpios"
under client device node. It plays pretty much like a board level pin
multiplexer, and steers the pin route by controlling the GPIOs. When
client device has the property represent in its node, pinctrl device
tree mapping function will firstly pull up/down the GPIOs to assert the
pins for the device at board level.[shawn.guo: cherry-pick commit e5a718edab82 from imx_3.10.y]
Signed-off-by: Shawn Guo
09 Feb, 2017
3 commits
-
commit 19b26d92dfb70f56440c187a20c49102ab648b97 upstream.
Not every pin can be configured. Add missed check to prevent access
violation.Fixes: 4e80c8f50574 ("pinctrl: intel: Add Intel Merrifield pin controller support")
Acked-by: Mika Westerberg
Signed-off-by: Andy Shevchenko
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 1b89970d81bbd52720fc64a3fe9572ee33588363 upstream.
Debounce value is set globally per community. Otherwise user will easily
get a kernel crash when they start using the feature:BUG: unable to handle kernel paging request at ffffc900003be000
IP: byt_gpio_dbg_show+0xa9/0x430Make it clear in byt_gpio_reg().
Note that this fix just prevents kernel to crash, but doesn't make any
difference to the existing logic. It means the last caller will win the
trade and debounce value will be configured accordingly. The actual
logic fix needs to be thought about and it's not as important as crash
fix. That's why the latter goes separately and right now.Fixes: 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
Cc: Cristina Ciocan
Signed-off-by: Andy Shevchenko
Reviewed-by: Jean Delvare
Acked-by: Mika Westerberg
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit cdca06e4e85974d8a3503ab15709dbbaf90d3dd1 upstream.
According to VLI64 Intel Atom E3800 Specification Update (#329901)
concurrent read accesses may result in returning 0xffffffff and write
accesses may be dropped silently.
To workaround all accesses must be protected by locks.Signed-off-by: Alexander Stein
Acked-by: Mika Westerberg
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
01 Feb, 2017
3 commits
-
commit 04ff5a095d662e0879f0eb04b9247e092210aeff upstream.
The commit 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
implements debounce for Baytrail pin control, but seems wasn't tested properly.The register which keeps debounce value is separated from the configuration
one. Writing wrong values to the latter will guarantee wrong behaviour of the
driver and even might break something physically.Besides above there is missed case how to disable it, which is actually done
through the bit in configuration register.Rectify implementation here by using proper register for debounce value.
Fixes: 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
Cc: Cristina Ciocan
Signed-off-by: Andy Shevchenko
Acked-by: Mika Westerberg
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit df1539c25cce98e2ac69881958850c6535240707 upstream.
Fix the pin-mux values for the MDC, MDIO, MDIO_INTL, PHYRSTL pins.
Fixes: 1e359ab1285e ("pinctrl: uniphier: add Ethernet pin-mux settings")
Signed-off-by: Masahiro Yamada
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit ecc8995363ee6231b32dad61c955b371b79cc4cf upstream.
PADCFGLOCK (and PADCFGLOCK_TX) offset in Broxton actually starts at 0x060
and not 0x090 as used in the driver. Fix it to use the correct offset.Signed-off-by: Mika Westerberg
Reviewed-by: Andy Shevchenko
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
20 Jan, 2017
5 commits
-
commit 5d7400c4acbf7fe633a976a89ee845f7333de3e4 upstream.
Always stating PIN_CONFIG_BIAS_DISABLE is supported gives untrue output
when examining /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins if
the operation get_bias() is implemented but the pin is not handled by
the get_bias() implementation. In that case the output will state that
"input bias disabled" indicating that this pin has bias control
support.Make support for PIN_CONFIG_BIAS_DISABLE depend on that the pin either
supports SH_PFC_PIN_CFG_PULL_UP or SH_PFC_PIN_CFG_PULL_DOWN. This also
solves the issue where SoC specific implementations print error messages
if their particular implementation of {set,get}_bias() is called with a
pin it does not know about.Signed-off-by: Niklas Söderlund
Acked-by: Laurent Pinchart
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman -
commit f24d311f92b516a8aadef5056424ccabb4068e7b upstream.
The pinctrl_gpio_request is called with the "full" gpio number, already
containing the base, then meson_pmx_request_gpio is then called with the
final pin number.
Remove the base addition when calling meson_pmx_disable_other_groups.Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs")
CC: Beniamino Galvani
Signed-off-by: Neil Armstrong
Acked-by: Kevin Hilman
Acked-by: Beniamino Galvani
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit c314c9f15aa5f43f0e5c0e2602cc65798dbd1598 upstream.
On some SoC there are no simple mapping of pins to bias register bits
and a lookup table is needed. This logic is already implemented in some
SoC specific drivers that could benefit from a generic implementation.Add helpers to deal with the lookup which later can be used by the SoC
specific drivers. The logic used to lookup are different from the one it
aims to replace, this is intentional. This new method reduces the memory
consumption at the cost of increased CPU usage and fix a bug where a
WARN() would incorrectly be triggered if the register offset is 0.Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman -
commit d3b861bccdee2fa9963a2b6c64f74a8d752b9315 upstream.
There is a bug in the r8a7795 bias code where a WARN() is trigged
anytime a pin from PUEN0/PUD0 is accessed.# cat /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins
WARNING: CPU: 2 PID: 2391 at drivers/pinctrl/sh-pfc/pfc-r8a7795.c:5364 r8a7795_pinmux_get_bias+0xbc/0xc8
[..]
Call trace:
[] r8a7795_pinmux_get_bias+0xbc/0xc8
[] sh_pfc_pinconf_get+0x194/0x270
[] pin_config_get_for_pin+0x20/0x30
[] pinconf_generic_dump_one+0x168/0x188
[] pinconf_generic_dump_pins+0x5c/0x98
[] pinconf_pins_show+0xc8/0x128
[] seq_read+0x16c/0x420
[] full_proxy_read+0x58/0x88
[] __vfs_read+0x1c/0xf8
[] vfs_read+0x84/0x148
[] SyS_read+0x44/0xa0
[] __sys_trace_return+0x0/0x4This is due to the WARN() check if the reg field of the pullups struct
is zero, and this should be 0 for pins controlled by the PUEN0/PUD0
registers since PU0 is defined as 0. Change the data structure and use
the generic sh_pfc_pin_to_bias_info() function to get the register
offset and bit information.Fixes: 560655247b627ac7 ("pinctrl: sh-pfc: r8a7795: Add bias pinconf support")
Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman -
commit 8f5983ad6b81070376db9487ce81000c85a16027 upstream.
Fixes: 6e408ed8be0e ("pinctrl: imx: fix initialization of imx_pinctrl_desc")
Reviewed-by: Vladimir Zapolskiy
Reviewed-by: Peng Fan
Signed-off-by: Gary Bisson
Signed-off-by: Greg Kroah-HartmanSigned-off-by: Linus Walleij
12 Jan, 2017
1 commit
-
commit 2983f296f2327bc517e3b29344fce82271160197 upstream.
In the function amd_gpio_irq_set_type, read the values from
the ACPI table to set the level and drop the settings passed
by the client.Reviewed-by: Pankaj Sen
Reviewed-by: Nitesh Kumar Agrawal
Reviewed-by: Shah, Nehal-bakulchandra
Signed-off-by: Shyam-sundar S-k
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
07 Nov, 2016
1 commit
-
If a pin depending on bit 6 in SCU90 is requested for GPIO, the export
will succeed but changes to the GPIO's value will not be accepted by the
hardware. This is because the pinmux driver has misconfigured the SCU by
writing 1 to the reserved bit.The description of SCU90[6] from the datasheet is 'Reserved, must keep
at value ”0”'. The fix is to switch pinmux from the bit-flipping macro
to explicitly configuring the .enable and .disable values to zero.The patch has been tested on an AST2500 EVB.
Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
Reported-by: Uma Yadlapati
Signed-off-by: Andrew Jeffery
Reviewed-by: Joel Stanley
Signed-off-by: Linus Walleij
05 Nov, 2016
2 commits
-
When the system is suspended to S3 the BIOS might re-initialize certain
GPIO pins back to their original state or it may re-program interrupt mask
of others. For example Acer TravelMate B116-M had BIOS bug where certain
GPIO pin (MF_ISH_GPIO_5) was programmed to trigger on high level, and the
pin state was high once the BIOS gave control to the OS on resume.This triggers lots of messages like:
irq 117, desc: ffff88017a61e600, depth: 1, count: 0, unhandled: 0
->handle_irq(): ffffffff8109b613, handle_bad_irq+0x0/0x1e0
->irq_data.chip(): ffffffffa0020180, chv_pinctrl_exit+0x2d84/0x12 [pinctrl_cherryview]
->action(): (null)
IRQ_NOPROBE setWe reset the mask back to known state in chv_pinctrl_resume() but that is
called only after device interrupts have already been enabled.Now, this particular issue was fixed by upgrading the BIOS to the latest
(v1.23) but not everybody upgrades their BIOSes so we fix it up in the
driver as well.Prevent the possible interrupt storm by moving suspend and resume hooks to
be called at _noirq time instead. Since device interrupts are still
disabled we can restore the mask back to known state before interrupt storm
happens.Cc: stable@vger.kernel.org
Reported-by: Christian Steiner
Signed-off-by: Mika Westerberg
Signed-off-by: Linus Walleij -
If async suspend is enabled, the driver may access registers concurrently
with another instance which may fail because of the bug in Cherryview GPIO
hardware. Prevent this by taking the shared lock while accessing the
hardware in suspend and resume hooks.Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg
Signed-off-by: Linus Walleij
01 Nov, 2016
4 commits
-
Group index is incremented on every new group parsed. Since the
field is part of struct imx_pinctrl_soc_info, which is typically
a global variable passed by the individual pinctrl-imx.c based
driver, it does not get cleared automatically when re-probing the
driver. This lead imx_pinctrl_parse_functions passing a group
pointer which is outside of the allocated group space on second
probe and onwards. Typically this ended up in a NULL pointer
dereference when accessing the name field like this:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
PC is at strcmp+0x18/0x44
LR is at imx_dt_node_to_map+0xc4/0x290Avoid this by setting group_index to 0 on probe.
This has been observed when using DEBUG_TEST_DRIVER_REMOVE.
Signed-off-by: Stefan Agner
Signed-off-by: Linus Walleij -
This patch allows to probe stm32 pinctrl driver even if no interrupt
controller is defined to manage gpio irqs.Signed-off-by: Alexandre TORGUE
Signed-off-by: Linus Walleij -
Thanks to 332e99d5ae4 which now alerts of default
trigger usage when configuring interrupts.Signed-off-by: Patrice Chotard
Acked-by: Peter Griffin
Signed-off-by: Linus Walleij -
Since commit 44a7185c2ae6 ("of/platform: Add common method to populate
default bus"), ARM64 platform devices are populated at the
arch_initcall_sync level; as a result, the platform_driver_probe calls
in both the iProc and NSP GPIO drivers fail with -ENODEV since by that
time the platform device was not yet registered.Replace platform_driver_probe with platform_driver_register, that allow
the device to be register laterFixes: 44a7185c2ae6 ("of/platform: Add common method to populate default bus")
Signed-off-by: Ray Jui
Tested-by: Eric Anholt
Signed-off-by: Linus Walleij
18 Oct, 2016
6 commits
-
Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend
to explicitly disable USB touchscreen interrupt. This is done to prevent
situation where the lid is closed the touchscreen is left functional.The pinctrl driver (wrongly) assumes it owns all pins which are owned by
host and not locked down. It is perfectly fine for BIOS to use those pins
as it is also considered as host in this context.What happens is that when the lid of Dell XPS 13 is closed, the BIOS
configures CPU_GP_1 low disabling the touchscreen interrupt. During resume
we restore all host owned pins to the known state which includes CPU_GP_1
and this overwrites what the BIOS has programmed there causing the
touchscreen to fail as no interrupts are reaching the CPU anymore.Fix this by restoring only those pins we know are explicitly requested by
the kernel one way or other.Cc: stable@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361
Reported-by: AceLan Kao
Tested-by: AceLan Kao
Signed-off-by: Mika Westerberg
Signed-off-by: Linus Walleij -
Initialize the spinlock before using it.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.8.0-dwc-bisect #4
Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.1403240443 FFD8_X64_R_2014_13_1_00 03/24/2014
0000000000000000 ffff8800788ff770 ffffffff8133d597 0000000000000000
0000000000000000 ffff8800788ff7e0 ffffffff810cfb9e 0000000000000002
ffff8800788ff7d0 ffffffff8205b600 0000000000000002 ffff8800788ff7f0
Call Trace:
[] dump_stack+0x67/0x90
[] register_lock_class+0x52e/0x540
[] __lock_acquire+0x81/0x16b0
[] ? save_trace+0x41/0xd0
[] ? __lock_acquire+0x13b2/0x16b0
[] ? __lock_is_held+0x4a/0x70
[] lock_acquire+0xba/0x220
[] ? byt_gpio_get_direction+0x3e/0x80
[] _raw_spin_lock_irqsave+0x47/0x60
[] ? byt_gpio_get_direction+0x3e/0x80
[] byt_gpio_get_direction+0x3e/0x80
[] gpiochip_add_data+0x319/0x7d0
[] ? _raw_spin_unlock_irqrestore+0x43/0x70
[] byt_pinctrl_probe+0x2fb/0x620
[] platform_drv_probe+0x3c/0xa0
...Based on the diff it looks like the problem was introduced in
commit 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling")
but I wasn't able to verify that empirically as the parent commit
just oopsed when I tried to boot it.Cc: Cristina Ciocan
Cc: stable@vger.kernel.org
Fixes: 71e6ca61e826 ("pinctrl: baytrail: Register pin control handling")
Signed-off-by: Ville Syrjälä
Acked-by: Mika Westerberg
Signed-off-by: Linus Walleij -
The SPI1 function was associated with the wrong pins: The functions that
those pins provide is either an SPI debug or passthrough function
coupled to SPI1. Make the SPI1 mux function configure the relevant pins
and associate new SPI1DEBUG and SPI1PASSTHRU functions with the pins
that were already defined.The notation used in the datasheet's multi-function pin table for the SoC is
often creative: in this case the SYS* signals are enabled by a single bit,
which is nothing unusual on its own, but in this case the bit was also
participating in a multi-bit bitfield and therefore represented multiple
functions. This fact was overlooked in the original patch.Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
Signed-off-by: Andrew Jeffery
Reviewed-by: Joel Stanley
Acked-by: Rob Herring
Signed-off-by: Linus Walleij -
This prevented C20 from successfully being muxed as GPIO.
Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
Signed-off-by: Andrew Jeffery
Reviewed-by: Joel Stanley
Signed-off-by: Linus Walleij -
Fixes simple typos in the initial commit. There is no behavioural
change.Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
Reported-by: Xo Wang
Signed-off-by: Andrew Jeffery
Reviewed-by: Joel Stanley
Signed-off-by: Linus Walleij -
Consider a scenario with one pin P that has two signals A and B, where A
is defined to be higher priority than B: That is, if the mux IP is in a
state that would consider both A and B to be active on P, then A will be
the active signal.To instead configure B as the active signal we must configure the mux so
that A is inactive. The mux state for signals can be described by
logical operations on one or more bits from one or more registers (a
"signal expression"), which in some cases leads to aliased mux states for
a particular signal. Further, signals described by multi-bit bitfields
often do not only need to record the states that would make them active
(the "enable" expressions), but also the states that makes them inactive
(the "disable" expressions). All of this combined leads to four possible
states for a signal:1. A signal is active with respect to an "enable" expression
2. A signal is not active with respect to an "enable" expression
3. A signal is inactive with respect to a "disable" expression
4. A signal is not inactive with respect to a "disable" expressionIn the case of P, if we are looking to activate B without explicitly
having configured A it's enough to consider A inactive if all of A's
"enable" signal expressions evaluate to "not active". If any evaluate to
"active" then the corresponding "disable" states must be applied so it
becomes inactive.For example, on the AST2400 the pins composing GPIO bank H provide
signals ROMD8 through ROMD15 (high priority) and those for UART6 (low
priority). The mux states for ROMD8 through ROMD15 are aliased, i.e.
there are two mux states that result in the respective signals being
configured:A. SCU90[6]=1
B. Strap[4,1:0]=100Further, the second mux state is a 3-bit bitfield that explicitly
defines the enabled state but the disabled state is implicit, i.e. if
Strap[4,1:0] is not exactly "100" then ROMD8 through ROMD15 are not
considered active. This requires the mux function evaluation logic to
use approach 2. above, however the existing code was using approach 3.
The problem was brought to light on the Palmetto machines where the
strap register value is 0x120ce416, and prevented GPIO requests in bank
H from succeeding despite the hardware being in a position to allow
them.Fixes: 318398c09a8d ("pinctrl: Add core pinctrl support for Aspeed SoCs")
Signed-off-by: Andrew Jeffery
Reviewed-by: Joel Stanley
Signed-off-by: Linus Walleij
08 Oct, 2016
1 commit
-
Pull ARM SoC driver updates from Arnd Bergmann:
"Driver updates for ARM SoCs, including a couple of newly added
drivers:- The Qualcomm external bus interface 2 (EBI2), used in some of their
mobile phone chips for connecting flash memory, LCD displays or
other peripherals- Secure monitor firmware for Amlogic SoCs, and an NVMEM driver for
the EFUSE based on that firmware interface.- Perf support for the AppliedMicro X-Gene performance monitor unit
- Reset driver for STMicroelectronics STM32
- Reset driver for SocioNext UniPhier SoCs
Aside from these, there are minor updates to SoC-specific bus,
clocksource, firmware, pinctrl, reset, rtc and pmic drivers"* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (50 commits)
bus: qcom-ebi2: depend on HAS_IOMEM
pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181
clk: mvebu: Add clk support for the orion5x SoC mv88f5181
dt-bindings: EXYNOS: Add Exynos5433 PMU compatible
clocksource: exynos_mct: Add the support for ARM64
perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver
Documentation: Add documentation for APM X-Gene SoC PMU DTS binding
MAINTAINERS: Add entry for APM X-Gene SoC PMU driver
bus: qcom: add EBI2 driver
bus: qcom: add EBI2 device tree bindings
rtc: rtc-pm8xxx: Add support for pm8018 rtc
nvmem: amlogic: Add Amlogic Meson EFUSE driver
firmware: Amlogic: Add secure monitor driver
soc: qcom: smd: Reset rx tail rather than tx
memory: atmel-sdramc: fix a possible NULL dereference
reset: hi6220: allow to compile test driver on other architectures
reset: zynq: add driver Kconfig option
reset: sunxi: add driver Kconfig option
reset: stm32: add driver Kconfig option
reset: socfpga: add driver Kconfig option
...
06 Oct, 2016
1 commit
-
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for the v4.9 series:Subsystem improvements:
- do away with the last users of the obsolete Kconfig options
ARCH_REQUIRE_GPIOLIB and ARCH_WANT_OPTIONAL_GPIOLIB (the latter
always sounded like an item on a wishlist to Santa Claus to me). We
can now select GPIOLIB and be done with it, for all archs. After
some struggle it even work on UM. Not that it has GPIO, but if it
wants to, it can select the library.- continued efforts to make drivers properly either tristate or bool.
- introduce a warning for drivers assigning default triggers to their
irqchip lines when probed from device tree, so we find and fix
these ambigous drivers. It is agreed that in the OF config path,
the device tree defines trigger characteristics.- the same warning, mutatis mutandis, for ACPI-probed GPIO irqchips.
- we introduce the ability to mark certain IRQ lines as "unusable" as
they can be taken by BIOS/firmware, unrouted in silicon and
generally nasty if you use them, and such things. This is put to
good use in the STMPE driver and also in the Cherryview pin control
driver.- a new "mockup" virtual GPIO device that can be used for testing.
The plan is to add unit tests under tools/* for exercising this
device and verify that the kernel code paths are working as they
should.- make memory-mapped I/O-drivers depend on HAS_IOMEM. This was
implicit all the time, but when people started building UM with
allyesconfig or allmodconfig it exploded in their face.- move some stray bits of device tree and ACPI HW description
callbacks down into their respective implementation silo. These
were causing issues when compiling on !HAS_IOMEM as well, so now
eventually UM compiles the GPIOLIB library if it wants to.New drivers:
- new driver for the Aspeed GPIO front-end companion to the pin
controller merged through the pin control tree.- new driver for the LP873x PMIC GPIO portions.
- new driver for Technologic Systems' I2C FPGA GPIO such as TS4900,
TS-7970, TS-7990 and TS-4100.- new driver for the Broadcom BCM63xx series including BCM6338 and
BCM6345.- new driver for the Intel WhiskeyCove PMIC GPIO.
- new driver for the Allwinner AXP209 PMIC GPIO portions.
- new driver for Diamond Systems 48 line GPIO-MM, another of these
port-mapped I/O expansion cards.- support the STMicroelectronics STMPE1600 variant in the STMPE
driver.Driver improvements:
- the STMPE driver now supports rising/falling edge detection
properly for IRQs.- the PCA954x will now fetch and enable its VCC regulator properly.
- major rework of the PCA953x driver with the goal of eventually
switching it over to use regmap and thus modernize it even more.- switch the IOP driver to use the generic MMIO GPIO library.
- move the ages old HTC EGPIO (extended GPIO) GPIO expander driver
over to this subsystem from MFD, achieveing some separation of
concerns"* tag 'gpio-v4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (81 commits)
gpio: add missing static inline
gpio: OF: localize some gpiochip init functions
gpio: acpi: separation of concerns
gpio: OF: separation of concerns
gpio: make memory-mapped drivers depend on HAS_IOMEM
gpio: stmpe: use BIT() macro
gpio: stmpe: forbid unused lines to be mapped as IRQs
mfd/gpio: Move HTC GPIO driver to GPIO subsystem
gpio: MAINTAINERS: Add an entry for GPIO mockup driver
gpio/mockup: add virtual gpio device
gpio: Added zynq specific check for special pins on bank zero
gpio: axp209: Implement get_direction
gpio: aspeed: remove redundant return value check
gpio: loongson1: remove redundant return value check
ARM: omap2: fix missing include
gpio: tc3589x: fix up complaints on unsigned
gpio: tc3589x: add .get_direction() and small cleanup
gpio: f7188x: use gpiochip_get_data instead of container_of
gpio: tps65218: use devm_gpiochip_add_data() for gpio registration
gpio: aspeed: fix return value check in aspeed_gpio_probe()
...
04 Oct, 2016
2 commits
-
The following commit introduced a regression by not properly masking the
calculated value.Fixes: 47a01ee9a6c3 ("pinctrl: qcom: Clear all function selection bits")
Signed-off-by: John Crispin
Reviewed-by: Bjorn Andersson
Reviewed-by: Stephen Boyd
Signed-off-by: Linus Walleij -
The generic GPIO library directly implement code for acpi_find_gpio()
which is only used with CONFIG_ACPI. This was probably done because
OF did the same thing, but I removed that so remove this too.Rename the internal acpi_find_gpio() in gpiolib-acpi.c to
acpi_populate_gpio_lookup() which seems to be more appropriate anyway
so as to avoid a namespace clash with the same function.Make the stub return -ENOENT rather than -ENOSYS (as that is for
syscalls!).For some reason the sunxi pin control driver was including the private
gpiolib header, it works just fine without it so remove that oneliner.Cc: Rafael J. Wysocki
Acked-by: Mika Westerberg
Signed-off-by: Linus Walleij
23 Sep, 2016
3 commits
-
On some Intel BXT platform, wake-up from suspend-to-idle on pressing
power-button is not working. Its noticed that gpio-keys driver marking the
second level IRQ/power-button as wake capable but Intel pintctrl
driver is missing to mark GPIO chip/controller IRQ which first level IRQ
as wake cable if its GPIO pin IRQ is wakeble. So, though the first level
IRQ gets generated on power-button press, since it is not marked as
wake capable resume/wake-up flow is not happening.
Intel pintctrl/GPIO driver need to mark GPIO chip/controller IRQ (first
level IRQ) as wake capable iff GPIO pin's IRQ (second level IRQ) is marked
as wake cable.Changes in v2:
- Add missing irq initialisation.Signed-off-by: Nilesh Bacchewar
Reviewed-by: Mika Westerberg
Signed-off-by: Linus Walleij -
This simplifies the error handling and allows us to drop the whole
chv_pinctrl_remove() function.Signed-off-by: Mika Westerberg
Signed-off-by: Linus Walleij
