- 14 Aug, 2017 40 commits
-
-
Masahiro Yamada authored
Detected by sparse. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Masahiro Yamada authored
Detected by sparse. Signed-off-by:
-
Masahiro Yamada authored
Since commit 58957d2e ("pinctrl: Widen the generic pinconf argument from 16 to 24 bits"), the generic pinconf arguments are handled by u32. UniPhier pinctrl drivers do not support debouncing, so u16 is working, but align the argument type to u32 for consistency. Signed-off-by:
-
Icenowy Zheng authored
The V3s pin controller doesn't have the bank 0 (starts at address 0x200), which is like A33. However, this is not worked around when developing the driver, which makes IRQ not working. Fix the IRQ bank base. Fixes: 56d9e4a7 ("pinctrl: sunxi: add driver for V3s SoC") Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Reviewed-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Masahiro Yamada authored
Update subsystem wide for consistency. Signed-off-by:
-
Zhiyong Tao authored
The commit adds mt2712 compatible node in binding document. Signed-off-by:
Zhiyong Tao <zhiyong.tao@mediatek.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Sergei Shtylyov authored
of_irq_to_resource() has recently been fixed to return negative error #'s along with 0 in case of failure, however the ST driver still only regards 0 as failure indication -- fix it up. Fixes: 7a4228bb ("of: irq: use of_irq_get() in of_irq_to_resource()") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Linus Walleij authored
The Cortina Gemini pin controller uses the standard pin control bindings for muxing functions with groups so these bindings should be entirely uncontroversial. Cc: devicetree@vger.kernel.org Signed-off-by: -
Andy Yan authored
Some pins like i2c SCL/SDA need the schmitt input function to avoid crosstalk problems. Signed-off-by:
Andy Yan <andy.yan@rock-chips.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Peter Robinson authored
The Intel pin control drivers are architecture specific so add an if arch to check for X86 or compile test to ensure continued test coverage. Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Sergei Shtylyov authored
of_irq_get() may return any negative error number as well as 0 on failure, while the driver only checks for -EPROBE_DEFER, blithely continuing with the call to gpiochip_set_chained_irqchip() -- that function expects the parent IRQ as *unsigned int*, so would probably do nothing when a large IRQ number resulting from a conversion of a negative error number is passed to it, however passing 0 would probably work but the driver won't receive valid GPIO bank interrupts. Check for 'ret <= 0' instead and return -ENXIO from the driver's probe iff of_irq_get() returned 0. Fixes: f9367793 ("pinctrl: sirf: add sirf atlas7 pinctrl and gpio support") Signed-off-by:
-
Vivek Gautam authored
Update the binding doc for qcom pmi8994-gpio devices. Signed-off-by:
Vivek Gautam <vivek.gautam@codeaurora.org> Reviewed-by:
Stephen Boyd <sboyd@codeaurora.org> Acked-by:
-
David Wu authored
There are 3 IP blocks pin routes need to be switched, that are emmc-cmd, spi, i2s. And there are some pins need to be recalced, which are gpio2c4~gpio2c7 and gpio2d0. Signed-off-by:
David Wu <david.wu@rock-chips.com> Reviewed-by:
-
David Wu authored
The other Socs also need the feature of recalced iomux, so make it as a common interface like iomux route feature. Signed-off-by:
-
Thierry Reding authored
The irq_group field stores a 1:1 mapping. Use the loop variable to derive the values instead of storing them in an extra array. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Thierry Reding authored
The GPIO offset is never initialized, which means that it will end up being zero as per the devm_kzalloc() of the parent structure. Signed-off-by:
-
Rob Herring authored
Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Acked-by:
Patrice Chotard <patrice.chotard@st.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Philipp Zabel authored
Commit a53e35db ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit API call so the temporary transition helpers can be removed. No functional changes. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-gpio@vger.kernel.org Cc: linux-tegra@vger.kernel.org Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
Commit a53e35db ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit API call so the temporary transition helpers can be removed. No functional changes. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Signed-off-by:
-
Philipp Zabel authored
Commit a53e35db ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit API call so the temporary transition helpers can be removed. No functional changes. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: linux-gpio@vger.kernel.org Signed-off-by:
-
Andrew Jeffery authored
Implement the AST2500 USB functions as described by the devicetree bindings. The AST2500 exposes five USB controllers through two USB ports. Similar to the AST2400, the pins exposing USB are outliers with respect to the rest of the pinmux as they not capable of GPIO. Signed-off-by:
Andrew Jeffery <andrew@aj.id.au> Signed-off-by:
-
Andrew Jeffery authored
Implement the AST2400 USB functions as described by the devicetree bindings. Three ports are fully documented in the datasheet and exposed through the bindings and pinctrl, though there are remnants of documentation for a fourth port muxed with GPIO pins GPIOQ6 and GPIOQ7. The implementation is updated to reflect this but the function and group are not exposed. Disregarding the mostly undocumented fourth port, the USB functions are an outlier with respect to the rest of the muxed functionality on the AST2400 as GPIO is not supported on these pins. Signed-off-by:
-
Andrew Jeffery authored
The Aspeed AST2500 SoC contains a number of USB controllers: * USB 1.1 Host Controller * USB 2.0 Host Controller (x2) * USB 2.0 Virtual Hub * USB 2.0 Device Controller * USB 1.1 HID Controller The controllers are exposed via two USB ports with functionality muxed as required. The following table illustrates the relationships between the ports and the controllers via the mux function names: Port | USB Version | USB Mode | Mux Function ------|--------------|--------------|------------- A | 2.0 | Virtual Hub | USB2AD A | 2.0 | Host | USB2AH B | 1.1 | HID | USB11BHID B | 2.0 | Device | USB2BD B | 2.0 | Host | USB2BH Signed-off-by:
-
Andrew Jeffery authored
The AST2400 contains several USB controllers: * USB 1.1 Host Controller * USB 2.0 Host Controller * USB 2.0 Virtual Hub * USB 1.1 HID Controller Pins for three ports are routed to the three controllers such that: * Port 1 is a dedicated USB 1.1 host port * Port 2 is shared between the USB 1.1 host and HID controllers * Port 3 is shared between the USB 2.0 host and Hub controllers As the pins for port 1 are fixed function there is no associated mux function or group described in the bindings. Ports 2 and 3 are muxed as above, and the table below describes the mapping between pinmux function names and ports: Port | USB Version | USB Mode | Mux Function ------|--------------|-----------|------------- 1 | 1.1 | Host | - 2 | 1.1 | Host | USB11H2 2 | 1.1 | HID | USB11D1 3 | 2.0 | Host | USB2H1 3 | 2.0 | Device | USB2D1 Signed-off-by:
-
Shawn Guo authored
It fixes the following Smatch static check warning: drivers/pinctrl/zte/pinctrl-zx.c:338 zx_pinctrl_build_state() warn: passing devm_ allocated variable to kfree. As we will be calling krealloc() on pointer '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. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: cbff0c4d ("pinctrl: add ZTE ZX pinctrl driver support") Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Gustavo A. R. Silva authored
This structure is only used to copy into another structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e; position p; @@ e = i@p; @bad@ position p != {r.p,ok.p}; identifier r.i; struct gpio_chip e; @@ e@i@p @depends on !bad disable optional_qualifier@ identifier r.i; @@ static +const struct gpio_chip i = { ... }; In the following log you can see a significant difference in the code size and data segment, hence in the dec segment. This log is the output of the size command, before and after the code change: before: text data bss dec hex filename 15136 5112 0 20248 4f18 drivers/pinctrl/qcom/pinctrl-ssbi-mpp.o after: bss dec hex filename 14849 5024 0 19873 4da1 drivers/pinctrl/qcom/pinctrl-ssbi-mpp.o Signed-off-by:Gustavo A. R. Silva <garsilva@embeddedor.com> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Gustavo A. R. Silva authored
This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e; position p; @@ e = i@p; @bad@ position p != {r.p,ok.p}; identifier r.i; struct gpio_chip e; @@ e@i@p @depends on !bad disable optional_qualifier@ identifier r.i; @@ static +const struct gpio_chip i = { ... }; In the following log you can see a significant difference in the code size and data segment, hence in the dec segment. This log is the output of the size command, before and after the code change: before: text data bss dec hex filename 18958 9000 128 28086 6db6 drivers/pinctrl/bcm/pinctrl-bcm2835.o after: text data bss dec hex filename 18764 8912 128 27804 6c9c drivers/pinctrl/bcm/pinctrl-bcm2835.o Signed-off-by: -
Nava kishore Manne authored
This patch fixes the below warning --> Prefer 'unsigned int' to bare use of 'unsigned'. --> line over 80 characters. --> Prefer 'unsigned int **' to bare use of 'unsigned **'. Signed-off-by:Nava kishore Manne <navam@xilinx.com> Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Nava kishore Manne authored
This patch fixes the kernel doc warnings in the driver. Signed-off-by:
-
Gustavo A. R. Silva authored
This structure is only used to copy into other structure, so declare it as const. This issue was detected using Coccinelle and the following semantic patch: @r disable optional_qualifier@ identifier i; position p; @@ static struct gpio_chip i@p = { ... }; @ok@ identifier r.i; expression e; position p; @@ e = i@p; @bad@ position p != {r.p,ok.p}; identifier r.i; struct gpio_chip e; @@ e@i@p @depends on !bad disable optional_qualifier@ identifier r.i; @@ static +const struct gpio_chip i = { ... }; In the following log you can see a significant difference in the code size and data segment, hence in the dec segment. This log is the output of the size command, before and after the code change: before: text data bss dec hex filename 21671 3632 128 25431 6357 drivers/pinctrl/pinctrl-st.o after: text data bss dec hex filename 21366 3576 128 25070 61ee drivers/pinctrl/pinctrl-st.o Signed-off-by: -
Hans de Goede authored
WARN_ON causes a backtrace to get logged which is only useful for kernel bugs. For signalling a firmware bug dev_warn(dev, FW_BUG "...") should be used. This fixes users running userspace software to monitor kernel oopses getting a false positive bug-report every boot because of the wrong use of WARN_ON. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Dong Aisheng authored
Add gpio_set_direction support. This makes the driver support GPIO input/output dynamically change from userspace. Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Stefan Agner <stefan@agner.ch> Cc: Fugang Duan <fugang.duan@nxp.com> Cc: Bai Ping <ping.bai@nxp.com> Acked-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
-
Dong Aisheng authored
Various IMX platforms may have different imx_pmx_ops.gpio_set_direction implementations, so let's make it platform specific callbacks instead of the fixed common one. Currently only VF610 platform implements it. No function level changes. Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Acked-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Dong Aisheng authored
gpio_request_enable/disable_free actually are not quite necessary as standard IMX pinctrl binding already sets GPIO mux from device tree, e.g. VF610_PAD_PTB20__GPIO_42 or MX7D_PAD_SD2_CD_B__GPIO5_IO9 No need to do it again in gpio_request_enable. And according to Stefan: "For all GPIO I checked in upstream device trees we assign a pinctrl to the same node, so in all cases gpio_request_enable/disable is really unnecessary." So it should be safe to simply remove it. Note that this changes semantics for Vybrid, e.g. "The two functions have been introduced for Vybrid (through SHARE_MUX_CONF_REG) and mux pins as GPIOs automatically when a GPIO gets requested. The automatic mux is optional by the pinmux/gpio subsystem semantics, and other NXP devices do not use it, instead an explicit pinctrl node is added in the device tree to mux GPIOs where required. Hence this change aligns Vybrid to other NXP (i.MX) devices. Note that all upstream device tree assign proper pinctrl properties where GPIOs are used so no change is necessary for device trees." Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fugang Duan <fugang.duan@nxp.com> Cc: Bai Ping <ping.bai@nxp.com> Acked-by:
-
Dong Aisheng authored
i.MX 7ULP has three IOMUXC instances: IOMUXC0 for M4 ports, IOMUXC1 for A7 ports and IOMUXC DDR for DDR interface. This patch adds the IOMUXC1 support for A7. It only supports generic pin config. Cc: Bai Ping <ping.bai@nxp.com> Acked-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
-
Dong Aisheng authored
The generic pinmux property seems to be more suitable for IMX. So we change to use 'pinmux' instead of 'pins'. Cc: Bai Ping <ping.bai@nxp.com> Acked-by:
-
Dong Aisheng authored
i.MX 7ULP has three IOMUXC instances: IOMUXC0 for M4 ports, IOMUXC1 for A7 ports and IOMUXC DDR for DDR interface. This patch adds the IOMUXC1 support for A7. Cc: Mark Rutland <mark.rutland@arm.com> Cc: devicetree@vger.kernel.org Acked-by:
-
Masahiro Yamada authored
Add pin configuration and pinmux support for UniPhier PXs3 SoC. Signed-off-by:
-
Masahiro Yamada authored
Save registers lost in the sleep when suspending, and restore them when resuming. Signed-off-by:
-
Masahiro Yamada authored
For LD11/20 SoCs (capable of per-pin input enable), the iectrl bit number matches its pin number. So, this is redundant information. Instead, we just need a flag to know if the iectrl gating exists or not. With this refactoring, 5 bits in pin data will be saved. Signed-off-by:
-
