summaryrefslogtreecommitdiff
path: root/drivers/gpio/gpio-syscon.c
AgeCommit message (Collapse)AuthorFilesLines
2024-09-02gpio: syscon: fix excess struct member build warningDhruva Gole1-1/+0
Fix the build warning with W=1 flag, "Excess struct member 'compatible' description in 'syscon_gpio_data' " by removing the documentation for the non existent member. Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20240902-b4-gpio-fix-v1-1-49a997994fa5@ti.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-05-29gpio: syscon: do not report bogus errorEtienne Buira1-11/+16
Do not issue "can't read the data register offset!" when gpio,syscon-dev is not set albeit unneeded. gpio-syscon is used with rk3328 chip, but this iomem region is documented in Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml and does not require gpio,syscon-dev setting. Signed-off-by: Etienne Buira <etienne.buira@free.fr> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/Zktwd4Y8zu6XSGaE@Z926fQmE5jqhFMgp6 Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-08-03gpio: syscon: remove unneeded call to platform_set_drvdata()Andrei Coardos1-2/+0
This function call was found to be unnecessary as there is no equivalent platform_get_drvdata() call to access the private data of the driver. Also, the private data is defined in this driver, so there is no risk of it being accessed outside of this driver file. Reviewed-by: Alexandru Ardelean <alex@shruggie.ro> Signed-off-by: Andrei Coardos <aboutphysycs@gmail.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2023-07-19gpio: Explicitly include correct DT includesRob Herring1-1/+0
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Romain Perier <romain.perier@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2022-05-02gpio: syscon: Remove usage of syscon_regmap_lookup_by_compatibleAlexander Shiyan1-30/+19
Since version 5.13, the standard syscon bindings have been added to all clps711x DT nodes, so we can now use the more general syscon_regmap_lookup_by_phandle function to get the syscon pointer. This patch removes the usage of the syscon_regmap_lookup_by_compatible function as it is no longer used in the driver. Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2020-07-08gpio: gpio-syscon: Fix formatting issues which confuse kerneldocLee Jones1-6/+6
Kerneldoc expects struct properties to be documented using the syntax '@.*: ', but no '@' has been provided in 'struct syscon_gpio_data's header. Add them to stop confusing kerneldoc. Fixes the following W=1 warnings: drivers/gpio/gpio-syscon.c:48: warning: Function parameter or member 'compatible' not described in 'syscon_gpio_data' drivers/gpio/gpio-syscon.c:48: warning: Function parameter or member 'flags' not described in 'syscon_gpio_data' drivers/gpio/gpio-syscon.c:48: warning: Function parameter or member 'bit_count' not described in 'syscon_gpio_data' drivers/gpio/gpio-syscon.c:48: warning: Function parameter or member 'dat_bit_offset' not described in 'syscon_gpio_data' drivers/gpio/gpio-syscon.c:48: warning: Function parameter or member 'dir_bit_offset' not described in 'syscon_gpio_data' drivers/gpio/gpio-syscon.c:48: warning: Function parameter or member 'set' not described in 'syscon_gpio_data' Signed-off-by: Lee Jones <lee.jones@linaro.org> Cc: Alexander Shiyan <shc_work@mail.ru> Link: https://lore.kernel.org/r/20200630133345.2232932-7-lee.jones@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152Thomas Gleixner1-5/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-10gpio: syscon: Fix possible NULL ptr usageMarek Vasut1-1/+1
The priv->data->set can be NULL while flags contains GPIO_SYSCON_FEAT_OUT and chip->set is valid pointer. This happens in case the controller uses the default GPIO setter. Always use chip->set to access the setter to avoid possible NULL pointer dereferencing. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-08-07gpio: syscon: rockchip: add GRF GPIO support for rk3328Levin Du1-0/+31
In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute control, can also be used for general purpose. It is manipulated by the GRF_SOC_CON10 register in GRF. Aside from the GPIO_MUTE pin, the HDMI pins can also be set in the same way. Currently this GRF GPIO controller only supports the mute pin. If needed in the future, the HDMI pins support can also be added. Signed-off-by: Levin Du <djw@t-chip.com.cn> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-07-02gpio: syscon: Include the right headerLinus Walleij1-1/+1
This is a GPIO driver, include only <linux/gpio/driver.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-05-23gpio: syscon: allow fetching syscon from parent nodeHeiko Stuebner1-0/+2
Syscon nodes can be a simple-mfd and the syscon-users then be declared as children of this node. That way the parent-child structure can be better represented for devices that are fully embedded in the syscon. Therefore allow getting the syscon from the parent if neither a special compatible nor a gpio,syscon-dev property is defined. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Levin Du <djw@t-chip.com.cn> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-05-16gpio: syscon: Use of_device_get_match_data()Thierry Reding1-6/+1
Use of_device_get_match_data() instead of open-coding it. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-08gpio: syscon: Change the compatibility stringAlexander Shiyan1-2/+2
This patch changes the compatibility string to match with the smallest supported chip (EP7209). Since the DT-support for this CPU is not yet announced, this change is safe. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-23gpio: syscon: Use devm_gpiochip_add_data() for gpio registrationLaxman Dewangan1-10/+1
Use devm_gpiochip_add_data() for GPIO registration and remove the need of driver callback .remove. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
2016-01-05gpio: syscon: use gpiochip data pointerLinus Walleij1-11/+6
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-12-21Merge tag 'v4.4-rc6' into develLinus Walleij1-1/+5
Linux 4.4-rc6
2015-11-19gpio: change member .dev to .parentLinus Walleij1-2/+2
The name .dev in a struct is normally reserved for a struct device that is let us say a superclass to the thing described by the struct. struct gpio_chip stands out by confusingly using a struct device *dev to point to the parent device (such as a platform_device) that represents the hardware. As we want to give gpio_chip:s real devices, this is not working. We need to rename this member to parent. This was done by two coccinelle scripts, I guess it is possible to combine them into one, but I don't know such stuff. They look like this: @@ struct gpio_chip *var; @@ -var->dev +var->parent and: @@ struct gpio_chip var; @@ -var.dev +var.parent and: @@ struct bgpio_chip *var; @@ -var->gc.dev +var->gc.parent Plus a few instances of bgpio that I couldn't figure out how to teach Coccinelle to rewrite. This patch hits all over the place, but I *strongly* prefer this solution to any piecemal approaches that just exercise patch mechanics all over the place. It mainly hits drivers/gpio and drivers/pinctrl which is my own backyard anyway. Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Alek Du <alek.du@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-11-17gpio: syscon: fix a possible NULL dereferenceLABBE Corentin1-1/+5
of_match_device could return NULL, and so cause a NULL pointer dereference later at line 199: priv->flags = of_id->data; Reported-by: coverity (CID 1324140) Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-03-27gpio: syscon: reduce message level when direction reg offset not in dtGrygorii Strashko1-1/+1
Now GPIO syscon driver produces bunch of warnings during the boot of Kesytone 2 SoCs: gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset! gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset! This message unintentionally was added using dev_err(), but its actual log level is debug, because third cell of "ti,syscon-dev" is optional. Hence change it to dev_dbg() as it should be. This patch fixes commit: 5a3e3f8 ("gpio: syscon: retriave syscon node and regs offsets from dt") Reported-by: Russell King <linux@arm.linux.org.uk> Tested-by: Murali Karicheri <m-karicheri2@ti.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-10-20gpio: drop owner assignment from platform_driversWolfram Sang1-1/+0
A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-09-17gpio: syscon: reuse for keystone 2 socsGrygorii Strashko1-0/+35
On Keystone SOCs, ARM host can send interrupts to DSP cores using the DSP GPIO controller IP. Each DSP GPIO controller provides 28 IRQ signals for each DSP core. This is one of the component used by the IPC mechanism used on Keystone SOCs. Keystone 2 DSP GPIO controller has specific features: - each GPIO can be configured only as output pin; - setting GPIO value to 1 causes IRQ generation on target DSP core; - reading pin value returns 0 - if IRQ was handled or 1 - IRQ is still pending. This patch updates gpio-syscon driver to be reused by Keystone 2 SoCs, because the Keystone 2 DSP GPIO controller is controlled through Syscon devices and, as requested by Linus Walleij, such kind of GPIO controllers should be integrated with drivers/gpio/gpio-syscon.c driver. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-17gpio: syscon: retrive syscon node and regs offsets from dtGrygorii Strashko1-8/+43
This patch adds handling of new "gpio,syscon-dev" DT property, which allows to specify syscon node and data/direction registers offsets in DT. "gpio,syscon-dev" has following format: gpio,syscon-dev = <&syscon_dev data_reg_offset [direction_reg_offset]>; where - syscon_dev - phandle on syscon node - data_reg_offset - offset of data register (in bytes) - direction_reg_offset - offset of dirrection register (optional, in bytes) for example: gpio,syscon-dev = <&devctrl 0x254>; In such way, the support of multiple Syscon GPIO devices is added. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-09-17gpio: syscon: add soc specific callback to assign output valueGrygorii Strashko1-2/+6
Some SoCs (like Keystone) may require to perform special sequence of operations to assign output GPIO value, so default implementation of .set() callback from gpio-syscon driver can't be used. Hence, add optional, SoC specific callback to assign output gpio value. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-07-22gpio: remove all usage of gpio_remove retval in driver/gpioabdoulaye berthe1-1/+2
Signed-off-by: abdoulaye berthe <berthe.ab@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-18gpio: Driver for SYSCON-based GPIOsAlexander Shiyan1-0/+191
SYSCON driver was designed for using memory areas (registers) that are used in several subsystems. There are systems (CPUs) which use bits in one register for various purposes and thus should be handled by various kernel subsystems. This driver allows you to use the individual SYSCON bits as GPIOs. ARM CLPS711X SYSFLG1 input lines has been added as first user of this driver. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>