- 22 May, 2017 39 commits
-
-
Linus Walleij authored
-
Paul Cercueil authored
All the drivers for the various hardware elements of the jz4740 SoC have been modified to use the pinctrl framework for their pin configuration needs. As such, this platform code is now unused and can be deleted. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Paul Cercueil authored
We set the pin configuration for the jz4780-nand and jz4780-uart drivers. Signed-off-by:
-
Paul Cercueil authored
We set the pin configuration for the jz4740-nand, jz4740-mmc, jz4740-fb, jz4740-pwm and jz4740-uart drivers. This will permit those drivers to be cleaned out of the custom GPIO code that they currently use. Signed-off-by:
-
Paul Cercueil authored
For a description of the devicetree node, please read Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt For a description of the gpio devicetree nodes, please read Documentation/devicetree/bindings/gpio/ingenic,gpio.txt Signed-off-by:
-
Paul Cercueil authored
For a description of the pinctrl devicetree node, please read Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt For a description of the gpio devicetree nodes, please read Documentation/devicetree/bindings/gpio/ingenic,gpio.txt Signed-off-by:
-
Paul Cercueil authored
There is a pinctrl driver for each of the Ingenic SoCs supported by the upstream Linux kernel. In order to switch away from the old GPIO platform code, we now enable the pinctrl drivers by default for the Ingenic SoCs. Signed-off-by:
-
Paul Cercueil authored
Before, this NAND driver would set itself the configuration of the chip-select pins for the various NAND banks. Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Paul Cercueil authored
Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Paul Cercueil authored
Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. One inherent problem of this new approach is that the pinctrl framework does not allow us to configure each pin on demand, when the various PWM channels are requested or released. For instance, the PWM channels can be configured from sysfs, which would require all PWM pins to be configured properly beforehand for the PWM function, eventually causing conflicts with other platform or board drivers. The proper solution here would be to modify the pwm-jz4740 driver to handle only one PWM channel, and create an instance of this driver for each one of the 8 PWM channels. Then, it could use the pinctrl framework to dynamically configure the PWM pin it controls. Until this can be done, the only jz4740 board supported upstream (Qi lb60) can configure all of its connected PWM pins in PWM function mode, since those are not used by other drivers nor by GPIOs on the board. Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Paul Cercueil authored
Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on the pins being properly configured before the driver probes. Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Paul Cercueil authored
This driver handles the GPIOs of all the Ingenic JZ47xx SoCs currently supported by the upsteam Linux kernel. Signed-off-by:
-
Paul Cercueil authored
This driver handles pin configuration and pin muxing for the JZ4740 and JZ4780 SoCs from Ingenic. Signed-off-by:
-
Paul Cercueil authored
This commit adds documentation for the devicetree bindings of the gpio-ingenic driver, which handles GPIOs of the Ingenic SoCs currently supported by the Linux kernel. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Paul Cercueil authored
This commit adds documentation for the devicetree bindings of the pinctrl-ingenic driver, which handles pin configuration and pin muxing of the Ingenic SoCs currently supported by the Linux kernel. Signed-off-by:
-
Nikita Yushchenko authored
When pinctrl device registers, it automatically claims hogs, that is, maps that pinctrl device serves for itself. It is possible that in addition to SoC's pinctrl device, other pinctrl devices get registered. E.g. some gpio expander devies are registered as pinctrl devices. For such devices, pinctrl maps could be defined that set up SoC's pins (e.g. interrupt pin for gpio expander). Such a map will have target device set to gpio expander. Here is device tree snippet that causes this scenario: &i2c0 { sx1503@20 { compatible = "semtech,sx1503q"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sx1503_20>; ... }; }; ... &iomuxc { pinctrl_sx1503_20: pinctrl-sx1503-20 { fsl,pins = < VF610_PAD_PTB1__GPIO_23 0x219d >; }; }; Such a map will have target device set to gpio expander. However is not a hog, it is a regular map that is claimed by core before gpio expander device is probed. Thus when looking for hogs, it is not enough to check that map's target device is set to pinctrl device being registered. Need also check that map's control device is also set to the same. Signed-off-by:Nikita Yushchenko <nikita.yoush@cogentembedded.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Dong Aisheng authored
MX7ULP MUX mode mask and shift bit is different from VF610. Let's make it a platform specific property for the later easy of adding MX7ULP support. One trick in exist code that Vybrid hardcoded the config part as 0xffff because its mux_config register BIT[15-0] are all configs part. But it's not true in ULP, so use mux_mask instead to address the difference. Cc: Stefan Agner <stefan@agner.ch> Cc: Bai Ping <ping.bai@nxp.com> Signed-off-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
Dong Aisheng <aisheng.dong@nxp.com> Acked-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Dong Aisheng authored
The design is based on the exist architecture that the core will provide a uniformed way to decode the generic pin config into platform config register raw data according to the imx_cfg_params_decode maps registered by platform. Two useful macros, IMX_CFG_PARAMS_DECODE and IMX_CFG_PARAMS_DECODE_INVERT, are created for platform to register decode map conveniently. In order to cope with some special case, a platform specific fixup() function is also available to use. Note that rather than fully utilizing the generic pinconf support provided by pinctrl core, IMX only adopts the device tree bindings of generic pinconf. The config used in .pin_config_get[set] are raw register data instead of generic one which makes us align the exist using. And that's also why we cannot set pinconf_ops.is_generic. Cc: Bai Ping <ping.bai@nxp.com> Signed-off-by:
-
Dong Aisheng authored
The original implemented debug message does not work for SHARE_MUX_CONF_REG case. This patch fixes it. Fixes: bf5a5309 ("pinctrl: imx: add VF610 support to imx pinctrl framework") Signed-off-by:
-
Christophe JAILLET authored
If 'devm_kzalloc' fails, a NULL pointer will be dereferenced. Return -ENOMEM instead, as done for the other memory allocation just a few lines below. BTW, change the 'devm_kzalloc' into a 'devm_kcalloc'. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Sean Wang authored
mt7623 pinctrl hardware can be compatible with mt2701 driver, so the patch lets the pinctrl on mt7623 SoC reuse the driver and deletes those redundant ones. Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Acked-by:
John Crispin <john@phrozen.org> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
-
Martin Blumenstingl authored
This adds another missing pin found in the Meson8 SoCs. Currently there's no driver which would use this pin yet. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Martin Blumenstingl authored
This adds another missing pin found in the Meson8 SoCs. Currently there's no driver which would use this pin yet. Signed-off-by:
-
Martin Blumenstingl authored
This adds support for the I2S and SPDIF input and output pins, similar to what we have on GXBB and GXL. Signed-off-by:
-
Martin Blumenstingl authored
This adds the missing pins for the PWM controllers found in Amlogic Meson8 SoCs. This includes the pins for PWM_A, PWM_B, PWM_C, PWM_D, PWM_E and PWM_F controllers. There is an additional PWM function with the name PWM_VS in the vendor kernel sources which seems to be used for external video input. Thus it's not part of this change as the IP block behind the pwm-meson driver is not responsible for these pins. Signed-off-by:
-
Markus Elfring authored
MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script “checkpatch.pl” pointed information out like the following. Comparison to NULL could be written … Thus fix the affected source code places. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Markus Elfring authored
A single character (line break) should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The script "checkpatch.pl" pointed information out like the following. CHECK: spaces preferred around that '+' (ctx:VxV) Thus fix the affected source code places. Signed-off-by:
-
Markus Elfring authored
The script "checkpatch.pl" pointed information out like the following. WARNING: quoted string split across lines Thus fix the affected source code place. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Markus Elfring authored
MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The script “checkpatch.pl” pointed information out like the following. Comparison to NULL could be written !… Thus fix the affected source code places. Signed-off-by:
-
Markus Elfring authored
Strings which did not contain data format specifications should be put into a sequence. Thus use the corresponding function "seq_puts". This issue was detected by using the Coccinelle software. Signed-off-by:
-
Shyam Sundar S K authored
Updating the point of contact for AMD GPIO driver. Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by:
Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Cc: Ken Xue <Ken.Xue@amd.com> Signed-off-by:
-
Markus Elfring authored
A single character (line break) should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by:
-
Gregory CLEMENT authored
The Armada 37xx SoCs can handle interrupt through GPIO. However it can only manage the edge ones. The way the interrupt are managed is classical so we can use the generic interrupt chip model. The only unusual "feature" is that many interrupts are connected to the parent interrupt controller. But we do not take advantage of this and use the chained irq with all of them. Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.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> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Shawn Guo authored
The pin controller on ZTE ZX platforms is kinda of hybrid. It consists of a main controller and an auxiliary one. For example, on ZX296718 SoC, the main controller is TOP_PMM and the auxiliary one is AON_IOCFG. Both controllers work together to control pin multiplexing and configuration. For most of pins, the pinmux function is controlled by main controller only, and this type of pins are meant by term 'TOP pins'. For other pins, the pinmux is controlled by both main and auxiliary controllers, as the available multiplexing functions for the pin spread in both controllers. This type of pins are called 'AON pins'. Though pinmux implementation is quite different, pinconf is same for both types of pins. Both are controlled by auxiliary controller, i.e. AON_IOCFG on ZX296718. The patch adds the ZTE ZX core pinctrl driver to support this hybrid pin controller as well as ZX296718 SoC specific pin data. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Shawn Guo authored
It adds device tree bindings for ZTE pin controller found on ZX2967xx family SoCs. 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 1 commit
-
-
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:
-
