summaryrefslogtreecommitdiff
path: root/drivers/gpio/gpio-syscon.c
AgeCommit message (Collapse)Author
2016-02-23gpio: syscon: Use devm_gpiochip_add_data() for gpio registrationLaxman Dewangan
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 Walleij
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 Walleij
Linux 4.4-rc6
2015-11-19gpio: change member .dev to .parentLinus Walleij
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 Corentin
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 Strashko
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 Sang
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-16gpio: syscon: reuse for keystone 2 socsGrygorii Strashko
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-16gpio: syscon: retrive syscon node and regs offsets from dtGrygorii Strashko
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-16gpio: syscon: add soc specific callback to assign output valueGrygorii Strashko
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 berthe
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 Shiyan
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>