summaryrefslogtreecommitdiff
path: root/drivers/ssb/driver_gpio.c
AgeCommit message (Collapse)Author
2014-09-18driver:gpio remove all usage of gpio_remove retval in driverabdoulaye berthe
this remove all reference to gpio_remove retval in all driver except pinctrl and gpio. the same thing is done for gpio and pinctrl in two different patches. Signed-off-by: Abdoulaye Berthe <berthe.ab@gmail.com> Acked-by: Michael Büsch <m@bues.ch> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-01-24ssb: gpio: add own IRQ domainRafał Miłecki
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Michael Buesch <m@bues.ch> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6342/
2013-02-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
Synchronize with 'net' in order to sort out some l2tp, wireless, and ipv6 GRE fixes that will be built on top of in 'net-next'. Signed-off-by: David S. Miller <davem@davemloft.net>
2013-02-04ssb: unregister gpios before unloading ssbHauke Mehrtens
This patch unregisters the gpio chip before ssb gets unloaded. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-01-30ssb: add gpio_to_irqHauke Mehrtens
The old bcm47xx gpio code had support for gpio_to_irq, but the new code did not provide this function, but returned -ENXIO all the time. This patch adds the missing function. arch/mips/bcm47xx/wgt634u.c calls gpio_to_irq() and got the correct irq number with the old gpio handling code. With this patch the code in wgt634u.c should work again. I do not have a wgt634u to test this. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-11-21ssb: add GPIO driverHauke Mehrtens
Register a GPIO driver to access the GPIOs provided by the chip. The GPIOs of the SoC should always start at 0 and the other GPIOs could start at a random position. There is just one SoC in a system and when they start at 0 the number is predictable. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Patchwork: http://patchwork.linux-mips.org/patch/4591 Acked-by: Florian Fainelli <florian@openwrt.org>