- 29 May, 2017 10 commits
-
-
Andy Shevchenko authored
The commit 10cf4899 ("gpiolib: tighten up ACPI legacy gpio lookups") prevents to getting same resource twice if the driver asks twice using different connection ID. But the whole idea of fallback might bring some problems. Imagine the case when we have two versions of BIOS/hardware where in one _DSD is introduced along with GPIO resources, but the other one uses just plain GPIO resource for another purpose Case 1: Device (DEVX) { ... Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {15} }) Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"some-gpios", Package() {^DEVX, 0, 0, 0 }}, } }) } Case 2: Device (DEVX) { ... Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {27} }) } To prevent the possible misconfiguration tighten up even more GPIO ACPI lookups for case without connection ID provided. In the past the issue had been triggered by "use mctrl_gpio helpers" series [1,2]. [1] commit 4ef03d32 ("tty/serial/8250: use mctrl_gpio helpers") [2] https://patchwork.kernel.org/patch/9283745/ Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Bastien Nocera <hadess@hadess.net> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Andy Shevchenko authored
Check that we don't ask for output direction on GpioInt resource in cases with or without _DSD defined. Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
By some reason acpi_find_gpio() and acpi_gpio_count() have compared connection ID to "gpios" when tries to check if suffix is needed or not. Don't do any assumptions about what connection ID can be and, when defined, use it only with suffix as it's done in the device tree version. Reviewed-by:
-
Andy Shevchenko authored
This is preparatory patch for enabling GPIO ACPI to configure a pin accordingly. Signed-off-by:
-
Charles Keepax authored
Add documentation of new GPIO specifiers indicating if the state of an output pin should be maintained during sleep/low-power mode. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by:
Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by:
-
Charles Keepax authored
The Arizona devices only maintain the state of output GPIOs whilst the CODEC is active, this can cause issues if the CODEC suspends whilst something is relying on the state of one of its GPIOs. However, in many systems the CODEC GPIOs are used for audio related features and thus the state of the GPIOs is unimportant whilst the CODEC is suspended. Often keeping the CODEC resumed in such a system would incur a power impact that is unacceptable. Allow the user to select whether a GPIO output should keep the CODEC resumed, by adding a flag through the second cell of the GPIO specifier in device tree. Signed-off-by:
-
Charles Keepax authored
Add new flags to allow users to specify that they are not concerned with the status of GPIOs whilst in a sleep/low power state. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Charles Keepax authored
Commit 4c0facdd ("gpio: core: Decouple open drain/source flag with active low/high") decoupled the open collector outputs from active low/high but did not update the documentation. Update the device tree documentation to correctly reflect this new separation between the two concepts. Signed-off-by:
-
Arvind Yadav authored
clk_prepare_enable() can fail here and we must check its return value. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
Gregory CLEMENT authored
Since the commit "gpio: mvebu: switch to regmap for register access" the driver use the regmap. Explicitly select the REGMAP_MMIO symbol to fix build error. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
- 23 May, 2017 21 commits
-
-
Jayachandran C authored
Broadcom Vulcan (ARCH_VULCAN) has been discontinued and will be deleted soon. So, update the GPIO_XLP Kconfig entry to remove the ARCH_VULCAN dependency. Also update the documentation to note that Cavium ThunderX2 uses this driver. Signed-off-by:
Jayachandran C <jnair@caviumnetworks.com> Signed-off-by:
-
Wolfram Sang authored
include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Wolfram Sang authored
include/linux/i2c is not for client devices. Move the header file to a more appropriate location. Signed-off-by:
-
Gregory CLEMENT authored
The mvebu gpio driver can also be used on arm64 mvebu SoC such as the Armada 7K/8K. This commit allows to build the driver for them (when only ARCH_MVEBU is defined) Reviewed-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Thomas Petazzoni authored
In order to be able to use this driver with the Armada 7K/8K SoCs, we need to use the regmap to access the registers. Indeed for these new SoCs, the gpio node will be part of a syscon. [gregory.clement@free-electrons.com: - fixed merge conflcit from 4.10 to 4.12-rc1 - added a commit log] Signed-off-by:
-
Gregory CLEMENT authored
This commit sorts alphabetically the header files. Reviewed-by:
-
Linus Walleij authored
-
Sebastian Reichel authored
The comment does not match the driver, which actually supports automatic assignment. Fix this by updating the comment. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by:
-
Sebastian Reichel authored
The driver supports using mcp23xxx as interrupt controller, so let's drop all comments stating otherwise. Signed-off-by:
-
Sebastian Reichel authored
Signed-off-by:
-
Sebastian Reichel authored
This moves irq property handling from spi/i2c specific code into the generic mcp23s08_probe_one. This is possible because the device properties are named equally. As a side-effect this drops support for setting the properties via pdata, which has no mainline users. If boardcode wants to enable the chip as interrupt controller it can attach the device properties instead. Signed-off-by:
-
Sebastian Reichel authored
Simplify spi pdata handling, so that it uses pdata when available and falls back to reading device properties otherwise. Signed-off-by:
-
Sebastian Reichel authored
Simplify i2c pdata handling, so that it uses pdata when available and falls back to reading device properties otherwise. Signed-off-by:
-
Sebastian Reichel authored
Switching to devm_gpiochip_add_data simplifies the driver's cleanup routine and safes a few loc. Signed-off-by:
-
Sebastian Reichel authored
Let's remove a few lines of code by using managed memory for mcp variable. Signed-off-by:
-
Sebastian Reichel authored
i2c-core and spi-core already assign the irq, so we can drop the additional call from the mcp driver. Signed-off-by:
-
Sebastian Reichel authored
The driver compiles & works perfectly fine without OF_GPIO on x86, so lets drop the dependency. Signed-off-by:
-
Sebastian Reichel authored
Instead of using custom caching, this switches to regmap based caching. Before the conversion the debugfs file used uncached values, so that it was easily possible to see power-loss related problems. The new code will check and recover at this place. The patch will also ensure, that irqs are not cleared by checking register status in debugfs. Signed-off-by:
-
Sebastian Reichel authored
mcp23s08 support configuration of the pullups using the pinconf framework. This removes the custom pullup configuration from platform data, which has no upstream users. Signed-off-by:
-
Sebastian Reichel authored
mcp23xxx device have configurable 100k pullup resistors. This adds support for enabling them using pinctrl's pinconf interface. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
-
Sebastian Reichel authored
This moves the mcp23s08 driver from gpio to pinctrl. Actual pinctrl support for configuration of the pull-up resistors follows in its own patch. Signed-off-by:
Sylvain Lemieux <slemieux.tyco@gmail.com> Signed-off-by:
-
- 22 May, 2017 7 commits
-
-
Nandor Han authored
Add XRA1403 support to MAINTAINERS list. Signed-off-by:
Nandor Han <nandor.han@ge.com> Signed-off-by:
-
Nandor Han authored
This driver support basic XRA1403 functionalities: - set gpio direction - get gpio direction - set gpio high/low - get gpio status Signed-off-by:Semi Malinen <semi.malinen@ge.com> Signed-off-by:
-
Masahiro Yamada authored
of_device_id::data is an opaque pointer. No explicit cast is needed. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Sören Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by:
-
Anatolij Gustschin authored
For hot-pluggable devices adding GPIOs dynamically we need to assemble and add the gpio lookup tables at probe time in modules, so that requesting these GPIOs in attached drivers can work. Export lookup table functions for modules. Signed-off-by:
Anatolij Gustschin <agust@denx.de> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Uwe Kleine-König authored
The length of the second entry is 20, so it affects GPIOs 10..29. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Linus Torvalds authored
-
Linus Torvalds authored
The code to fetch a 64-bit value from user space was entirely buggered, and has been since the code was merged in early 2016 in commit b2f68038 ("x86/mm/32: Add support for 64-bit __get_user() on 32-bit kernels"). Happily the buggered routine is almost certainly entirely unused, since the normal way to access user space memory is just with the non-inlined "get_user()", and the inlined version didn't even historically exist. The normal "get_user()" case is handled by external hand-written asm in arch/x86/lib/getuser.S that doesn't have either of these issues. There were two independent bugs in __get_user_asm_u64(): - it still did the STAC/CLAC user space access marking, even though that is now done by the wrapper macros, see commit 11f1a4b9 ("x86: reorganize SMAP handling in user space accesses"). This didn't result in a semantic error, it just means that the inlined optimized version was hugely less efficient than the allegedly slower standard version, since the CLAC/STAC overhead is quite high on modern Intel CPU's. - the double register %eax/%edx was marked as an output, but the %eax part of it was touched early in the asm, and could thus clobber other inputs to the asm that gcc didn't expect it to touch. In particular, that meant that the generated code could look like this: mov (%eax),%eax mov 0x4(%eax),%edx where the load of %edx obviously was _supposed_ to be from the 32-bit word that followed the source of %eax, but because %eax was overwritten by the first instruction, the source of %edx was basically random garbage. The fixes are trivial: remove the extraneous STAC/CLAC entries, and mark the 64-bit output as early-clobber to let gcc know that no inputs should alias with the output register. Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: stable@kernel.org # v4.8+ Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 21 May, 2017 2 commits
-
-
Linus Torvalds authored
Al noticed that unsafe_put_user() had type problems, and fixed them in commit a7cc722f ("fix unsafe_put_user()"), which made me look more at those functions. It turns out that unsafe_get_user() had a type issue too: it limited the largest size of the type it could handle to "unsigned long". Which is fine with the current users, but doesn't match our existing normal get_user() semantics, which can also handle "u64" even when that does not fit in a long. While at it, also clean up the type cast in unsafe_put_user(). We actually want to just make it an assignment to the expected type of the pointer, because we actually do want warnings from types that don't convert silently. And it makes the code more readable by not having that one very long and complex line. [ This patch might become stable material if we ever end up back-porting any new users of the unsafe uaccess code, but as things stand now this doesn't matter for any current existing uses. ] Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull misc uaccess fixes from Al Viro: "Fix for unsafe_put_user() (no callers currently in mainline, but anyone starting to use it will step into that) + alpha osf_wait4() infoleak fix" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: osf_wait4(): fix infoleak fix unsafe_put_user()
-
