- 30 Sep, 2020 2 commits
-
-
Michael Walle authored
Some Layerscape/QoriQ SoCs have input buffers which needs to be enabled first. This was done in two different ways in the driver. Unify it. This was tested on a LS1028A SoC. Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com>
-
Bartosz Golaszewski authored
If the module init function fails after creating the debugs directory, it's never removed. Add proper cleanup calls to avoid this resource leak. Fixes: 9202ba23 ("gpio: mockup: implement event injecting over debugfs") Cc: <stable@vger.kernel.org> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
- 29 Sep, 2020 7 commits
-
-
Anson Huang authored
Change config to tristate, add module device table, module author, description and license to support module build for i.MX GPIO driver. As this is a SoC GPIO module, it provides common functions for most of the peripheral devices, such as GPIO pins control, secondary interrupt controller for GPIO pins IRQ etc., without GPIO driver, most of the peripheral devices will NOT work properly, so GPIO module is similar with clock, pinctrl driver that should be loaded ONCE and never unloaded. Since MXC GPIO driver needs to have init function to register syscore ops once, here still use subsys_initcall(), NOT module_platform_driver(). Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Link: https://lore.kernel.org/r/1600320829-1453-1-git-send-email-Anson.Huang@nxp.comSigned-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Necip Fazil Yildiran authored
When PINCTRL_BCM2835 is enabled and GPIOLIB is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for GPIOLIB_IRQCHIP Depends on [n]: GPIOLIB [=n] Selected by [y]: - PINCTRL_BCM2835 [=y] && PINCTRL [=y] && OF [=y] && (ARCH_BCM2835 [=n] || ARCH_BRCMSTB [=n] || COMPILE_TEST [=y]) The reason is that PINCTRL_BCM2835 selects GPIOLIB_IRQCHIP without depending on or selecting GPIOLIB while GPIOLIB_IRQCHIP is subordinate to GPIOLIB. Honor the kconfig menu hierarchy to remove kconfig dependency warnings. Fixes: 85ae9e51 ("pinctrl: bcm2835: switch to GPIOLIB_IRQCHIP") Signed-off-by:
Necip Fazil Yildiran <fazilyildiran@gmail.com> Link: https://lore.kernel.org/r/20200914144025.371370-1-fazilyildiran@gmail.comSigned-off-by:
-
Krzysztof Kozlowski authored
Convert the Maxim MAX732x family of GPIO expanders bindings to device tree schema by merging it with existing PCA95xx schema. These are quite similar so merging reduces duplication. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200916155715.21009-3-krzk@kernel.orgSigned-off-by:
-
Krzysztof Kozlowski authored
Convert the NXP PCA953x family of GPIO expanders bindings to device tree schema. Signed-off-by:
-
Krzysztof Kozlowski authored
Describe common "gpio-line-names" property to fix dtbs_check warnings like: arch/arm/boot/dts/imx53-m53menlo.dt.yaml: gpio@53f84000: 'gpio-line-names' does not match any of the regexes: '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$', 'pinctrl-[0-9]+' Signed-off-by: -
Krzysztof Kozlowski authored
Several DTSes with ARMv6 and ARMv7 i.MX SoCs introduce their own compatibles so add them to fix dtbs_check warnings like: arch/arm/boot/dts/imx35-pdk.dt.yaml: gpio@53fa4000: compatible: ['fsl,imx35-gpio', 'fsl,imx31-gpio'] is not valid under any of the given schemas arch/arm/boot/dts/imx51-babbage.dt.yaml: gpio@73f90000: compatible: ['fsl,imx51-gpio', 'fsl,imx35-gpio'] is not valid under any of the given schemas Signed-off-by: -
Krzysztof Kozlowski authored
Describe common "gpio-line-names" property to fix dtbs_check warnings like: arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dt.yaml: gpio@e8a0b000: 'gpio-line-names' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by:
-
- 21 Sep, 2020 1 commit
-
-
Linus Walleij authored
Merge tag 'gpio-updates-for-v5.10-part1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel gpio updates for v5.10 - part 1 - automatically drive GPHY leds in gpio-stp-xway - refactor ->{get, set}_multiple() in gpio-aggregator - add support for a new model in rcar-gpio DT bindings - simplify several GPIO drivers with dev_err_probe() - disable Direct KBD interrupts in gpio-tc35894 - use DEFINE_SEQ_ATTRIBUTE() in GPIO chardev to shrink code - switch to using a simpler IDA API in gpiolib - make devprop_gpiochip_set_names() more generic by using device properties instead of using fwnode helpers
-
- 17 Sep, 2020 1 commit
-
-
Bartosz Golaszewski authored
It's possible for a GPIO chip to not have a parent device (whose properties we inspect for 'gpio-line-names'). In this case we should simply return from devprop_gpiochip_set_names(). Add an appropriate check for this use-case. Fixes: 7cba1a4d ("gpiolib: generalize devprop_gpiochip_set_names() for device properties") Reported-by:
Anders Roxell <anders.roxell@linaro.org> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com>
-
- 14 Sep, 2020 4 commits
-
-
Bartosz Golaszewski authored
Now that devprop_gpiochip_set_names() is only used in a single place inside drivers/gpio/gpiolib.c, there's no need anymore for it to be exported or to even live in its own source file. Pull this function into the core source file for gpiolib. Signed-off-by:
-
Bartosz Golaszewski authored
devprop_gpiochip_set_names() is overly complicated with taking the fwnode argument (which requires using dev_fwnode() & of_fwnode_handle() in ACPI and OF GPIO code respectively). Let's just switch to using the generic device properties. This allows us to pull the code setting line names directly into gpiochip_add_data_with_key() instead of handling it separately for ACPI and OF. Signed-off-by:
-
Bartosz Golaszewski authored
Instead of doing the following: count = device_property_read_string_array(dev, propname, NULL, 0); Let's provide inline helpers with hardcoded arguments for counting strings in property arrays. Suggested-by: -
Bartosz Golaszewski authored
We don't need to specify any ranges when allocating IDs so we can switch to ida_alloc() and ida_free() instead of the ida_simple_ counterparts. ida_simple_get(ida, 0, 0, gfp) is equivalent to ida_alloc_range(ida, 0, UINT_MAX, gfp) which is equivalent to ida_alloc(ida, gfp). Note: IDR will never actually allocate an ID larger than INT_MAX. Signed-off-by:
-
- 12 Sep, 2020 1 commit
-
-
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linuxLinus Walleij authored
NXP i.MX GPIO bindings for v5.10 Few NXP i.MX GPIO controller bindings cleanup.
-
- 11 Sep, 2020 1 commit
-
-
Andy Shevchenko authored
Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code. Signed-off-by:
-
- 09 Sep, 2020 1 commit
-
-
dillon min authored
On tc35894, have to disable direct keypad interrupts to make it as general purpose interrupts functionality work. if not, after chip reset, IRQST(0x91) will always 0x20, IRQN always low level, can't be clear. Configure DIRECTx to enable general purpose gpio mode, else read GPIOMISx register always zero in irq routine. verified on tc35894, need more test on other tc3589x. Signed-off-by:
dillon min <dillon.minfei@gmail.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
- 04 Sep, 2020 4 commits
-
-
Krzysztof Kozlowski authored
Parse also optional power-domains property to fix dtbs_check warnings like: arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dt.yaml: gpio@5d080000: 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml Signed-off-by: -
Krzysztof Kozlowski authored
Allow parsing GPIO controller children nodes with GPIO hogs to fix warning: arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpio@30240000: 'wl-reg-on' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml Signed-off-by: -
Krzysztof Kozlowski authored
The GPIO controller node can have gpio-ranges property. This fixes dtbs_check warnings like: arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000: 'gpio-ranges' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml Signed-off-by: -
Krzysztof Kozlowski authored
DTSes with new i.MX 8 SoCs introduce their own compatibles so add them to fix dtbs_check warnings like: arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000: compatible:0: 'fsl,imx8mm-gpio' is not one of ['fsl,imx1-gpio', 'fsl,imx21-gpio', 'fsl,imx31-gpio', 'fsl,imx35-gpio', 'fsl,imx7d-gpio'] From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000: compatible: ['fsl,imx8mm-gpio', 'fsl,imx35-gpio'] is too long arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000: compatible: Additional items are not allowed ('fsl,imx35-gpio' was unexpected) Signed-off-by:
-
- 28 Aug, 2020 7 commits
-
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by:
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by:
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by:
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by:
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and also it prints the error value. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Lad Prabhakar authored
Document Renesas RZ/G2H (R8A774E1) GPIO blocks compatibility within the relevant dt-bindings. R8A774E1 GPIO module is identical to R-Car Gen3 family. No driver change is needed due to the fallback compatible value "renesas,rcar-gen3-gpio". Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
- 27 Aug, 2020 10 commits
-
-
Serge Semin authored
Since the resource managed version of gpiochip_add_data() will handle the GPIO-chip data automated cleanup we can freely remove the DW APB GPIO driver code responsible for that. After doing so the DW APB GPIO driver removal callback can be also fully discarded since there is nothing left to be done for it. All the cleanups are now performed by means of the device managed framework. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by:
-
Serge Semin authored
The kernel clock framework provides the resource managed version of the clk_bulk_get() method. The only thing which needs to be also automated is the clocks disable/unprepare procedure executed on the device removal. It can be implemented by means of the custom action definition. After that the clocks acquisition and release will be purely managed by the device resources interface. Signed-off-by:
-
Serge Semin authored
The reset control interface provides the resource managed version of the reset_control_get() method. The only thing which needs to be also automated is the reset lane assertion on the device removal. It can be implemented by means of the custom action definition. After that the reset control will be purely managed by the device resources interface. Signed-off-by:
-
Serge Semin authored
Since GPIOlib-based IRQ-chip interface is now utilized there is no need in calling the methods acpi_gpiochip_{request,free}_interrupts() here. They will be called from gpiochip_add_irqchip()/gpiochip_irqchip_remove() anyway. Signed-off-by: -
Serge Semin authored
Since GPIOlib-based IRQ-chip interface is now utilized there is no need in setting up a custom GPIO-to-IRQ mapping method. GPIO-lib defines the standard mapping method - gpiochip_to_irq(), which will be used anyway no matter whether the custom to_irq callback is specified or not. Signed-off-by:
-
Serge Semin authored
GPIO-lib provides a ready-to-use interface to initialize an IRQ-chip on top of a GPIO chip. It's better from maintainability and readability point of view to use one instead of supporting a hand-written Generic IRQ-chip-based implementation. Moreover the new implementation won't cause much functional overhead but will provide a cleaner driver code. All of that makes the DW APB GPIO driver conversion pretty much justified especially seeing a tendency of the other GPIO drivers getting converted too. Here is what we do in the framework of this commit to convert the driver to using the GPIO-lib-based IRQ-chip interface: 1) IRQ ack, mask and unmask callbacks are locally defined instead of using the Generic IRQ-chip ones. 2) An irq_chip structure instance is embedded into the dwapb_gpio private data. Note we can't have a static instance of that structure since GPIO-lib will add some hooks into it by calling gpiochip_set_irq_hooks(). A warning about that would have been printed by the GPIO-lib code if we used a single irq_chip structure instance for multiple DW APB GPIO controllers. 3) Initialize the gpio_irq_chip structure embedded into the gpio_chip descriptor. By default there is no IRQ enabled so any event raised will be handled by the handle_bad_irq() IRQ flow handler. If DW APB GPIO IP-core is synthesized to have non-shared reference IRQ-lines, then as before the hierarchical and cascaded cases are distinguished by checking how many parental IRQs are defined. (Note irq_set_chained_handler_and_data() won't initialize IRQs, which descriptors couldn't be found.) If DW APB GPIO IP is used on a platform with shared IRQ line, then we simply won't let the GPIO-lib to initialize the parental IRQs, but will handle them locally in the driver. 4) Discard linear IRQ-domain and Generic IRQ-chip initialization, since GPIO-lib IRQ-chip interface will create a new domain and accept a standard IRQ-chip structure pointer based on the setting we provided in the gpio_irq_chip structure. 5) Manually select a proper IRQ flow handler directly in the irq_set_type() callback by calling irq_set_handler_locked() method, since an ordinary (not Generic) irq_chip descriptor is now utilized. Note this shalln't give any regression 6) Alter CONFIG_GPIO_DWAPB kernel config to select CONFIG_GPIOLIB_IRQCHIP instead of CONFIG_GENERIC_IRQ_CHIP. Note neither 4) nor 5) shall cause a regression of commit 6a2f4b7d ("gpio: dwapb: use a second irq chip"), since the later isn't properly used here anyway. Signed-off-by:
-
Serge Semin authored
Add a new macro DWAPB_MAX_GPIOS which defines the maximum possible number of GPIO lines corresponding to the maximum DW APB GPIO controller port width. Use the new macro instead of number literal 32 where it's applicable. Suggested-by:
-
Serge Semin authored
For better readability let's group all the IRQ handlers in a single place of the driver instead of having them scatter around all over the file. Signed-off-by:
-
Serge Semin authored
Indeed generic GPIO DT-schema implies that number of GPIOs should be described by the "ngpios" property located under a GPIO-provider DT node. In that case it's redundant to have a vendor-specific "snps,nr-gpios" property describing the same setting. Moreover it might be errors prone. Since commit 93d2e432 ("of: platform: Batch fwnode parsing when adding all top level devices") the fwnode parsing is resumed after the vast majority of the platform devices are added. Implicitly that commit activates re-parsing of the whole device tree GPIOs-phandle properties detected having "-gpio/-gpios" suffixes. Since the vendor-specific number of GPIOs property is defined with "-gpios" suffix, then of_link_property() will consider it as a suffix-property with "#gpio-cells" structure, which obviously it doesn't have. As a result for two DW APB GPIO controllers we'll have the next errors printed. OF: /bus@1f059000/gpio@1f044000/gpio-port@0: could not find phandle OF: /bus@1f059000/gpio@1f045000/gpio-port@0: could not get #gpio-cells for /opp-table OF: /bus@1f059000/gpio@1f044000/gpio-port@0: could not find phandle OF: /bus@1f059000/gpio@1f045000/gpio-port@0: could not get #gpio-cells for /opp-table See, the kernel fwnode parsing procedure even tried to resolve the phandle ID, which it thought was the opp-table DT-node, while in fact it was just a number "32". What would happen if that magic number actually referred to a GPIO DT-node with "#gpio-cells" property defined?.. In order to fix the problem let's mark the "snps,nr-gpios" property as deprecated and add the generic "ngpios" property support with the same purpose as the deprecated one. That and the errors log above shall motivate the platform developer to convert the DW APB GPIO DT-nodes to using the standard number of GPIOs property. Signed-off-by:
-
Serge Semin authored
It's redundant to have a vendor-specific property describing a number of GPIOS while there is a generic one. Let's mark the former one as deprecated and define the "ngpios" property supported with constraints of being within [1; 32] range. Signed-off-by:
-
- 18 Aug, 2020 1 commit
-
-
Andy Shevchenko authored
Sparse can't see locking scheme used in ->get_multiple() and ->set_multiple() callbacks. CHECK .../drivers/gpio/gpio-aggregator.c .../spinlock.h:409:9: warning: context imbalance in 'gpio_fwd_get_multiple' - unexpected unlock .../spinlock.h:409:9: warning: context imbalance in 'gpio_fwd_set_multiple' - unexpected unlock Refactor them to have better readability and make Sparse happy. Code size impact is +52 bytes with arm-linux-gnueabihf-gcc 7.5.0. Signed-off-by:
-
