19 Feb, 2016
4 commits
-
The ks8695 gpio driver has its own copy of the irq_to_gpio()
function. This is completely unused in the mainline kernel
after we converted all remaining users several years ago,
so we can remove the definition as well.Signed-off-by: Arnd Bergmann
Signed-off-by: Linus Walleij -
gpiolib has removed the irq_to_gpio() API several years ago,
but the global header still provided a non-working stub.To prevent new users of this broken function from showing
up, let's remove the stubs as well.Signed-off-by: Arnd Bergmann
Signed-off-by: Linus Walleij -
This is fallout from commit 832f5dacfa0b ("MIPS: Remove all the uses of
custom gpio.h").Signed-off-by: Ralf Baechle
Suggested-by: Lars-Peter Clausen -
The use of kmalloc() to allocate the gpio_device leaves the contained struct
device object in an unknown state. Calling dev_set_name() on a struct device
of unknown state can trigger the free() of an invalid pointer, as seen in the
following backtrace (collected by Tony Lindgren):kfree
kobject_set_name_vargs
dev_set_name
gpiochip_add_data
omap_gpio_probe
platform_drv_probe
...Reported-by: Geert Uytterhoeven
Reported-by: Michael Welling
Reported-by: Tony Lindgren
Tested-by: Michael Welling
Tested-by: Tony Lindgren
Signed-off-by: Josh Cartwright
Signed-off-by: Linus Walleij
16 Feb, 2016
19 commits
-
Since devm_kzalloc can be failed in memory pressure,
it needs to check and return -ENOMEMSigned-off-by: Insu Yun
Signed-off-by: Linus Walleij -
The .direction_output callback should set proper output level.
Signed-off-by: Axel Lin
Signed-off-by: Linus Walleij -
The .direction_output callback should set proper output level.
Signed-off-by: Axel Lin
Signed-off-by: Linus Walleij -
My left hand merges code to privatize the descriptor handling
while my right hand merges drivers that poke around and
disrespect with the same gpiolib internals.So let's expose the proper APIs for drivers to ask the gpiolib
core if a line is marked as open drain or open source and
get some order around things so this driver compiles again.Reported-by: Stephen Rothwell
Cc: Nicolas Saenz Julienne
Signed-off-by: Linus Walleij -
This fixes a possible NULL pointer deference in the function,
davinci_gpio_probe due to the function, gpio2regs being able
to return a NULL pointer if it rans to get the registers for
the gpio devices on a davinci board. Furthermore if this does
arise return -ENXIO to signal callers that this case has arisen
and avoiding setting the regs or other pointer values on theSigned-off-by: Nicholas Krause
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
asm/gpio.h is included only by linux/gpio.h, and then only when the arch
selects ARCH_HAVE_CUSTOM_GPIO_H. Only the following arches select it: arm
avr32 blackfin m68k (COLDFIRE only) sh unicore32.Remove the unused asm/gpio.h files for the arches that do not select
ARCH_HAVE_CUSTOM_GPIO_H.This is a follow-on to 7563bbf89d06 ("gpiolib/arches: Centralise
bolierplate asm/gpio.h").Signed-off-by: Bjorn Helgaas
Acked-by: Thomas Gleixner
Acked-by: Arnd Bergmann
Acked-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
Most arches have an asm/gpio.h that merely includes linux/gpio.h. The
others select ARCH_HAVE_CUSTOM_GPIO_H, and when that's selected,
linux/gpio.h includes asm/gpio.h.Therefore, code should include linux/gpio.h instead of including asm/gpio.h
directly.Remove includes of asm/gpio.h, adding an include of linux/gpio.h when
necessary.This is a follow-on to 7563bbf89d06 ("gpiolib/arches: Centralise
bolierplate asm/gpio.h").Signed-off-by: Bjorn Helgaas
Acked-by: Thomas Gleixner
Acked-by: Arnd Bergmann
Acked-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
No flags are required for bgpio_init in the TS-4800 gpio driver. This
patch set zero instead. The driver will have the same behaviour since
the & operator between the flags already resulted to zero.Fixes: 5041e791440a ("gpio: add TS-4800 fpga GPIO support")
Signed-off-by: Julien Grossholtz
Signed-off-by: Linus Walleij -
We move to manage this pointer under gpiolib control rather than
leave it in the subdevice's gpio_chip. We can not NULL it after
gpiochip_remove so at to keep things tight.Signed-off-by: Linus Walleij
-
Instead of keeping this reference to the pin ranges in the
client driver-supplied gpio_chip, move it to the internal
gpio_device as the drivers have no need to inspect this.Signed-off-by: Linus Walleij
-
This code is poking around in the gpio_chip:s internal structures
to achieve some kind of pin to GPIO mappings.- It is wrong to poke around in these structs and the pinctrl
maintainer was stupid to let it pass unnoticed, mea culpa.- The right interface to use is gpiochip_add_pin_range()
- The code appears unused: the pin control part of the driver
is not adding any ranges, so we're iterating over an empty
list. Maybe it is poking around in some other pin controllers
GPIO ranges, and that's just totally wrong, again use
gpiochip_add_pin_range() and specify the right pin
controller.Cc: Barry Song
Cc: Guoying Zhang
Cc: Wei Chen
Signed-off-by: Linus Walleij -
By the time request_region is called in the WinSystems WS16C48 GPIO
driver, a corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.Signed-off-by: William Breathitt Gray
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
By the time request_region is called in the SMSC SCH311x GPIO driver, a
corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.Signed-off-by: William Breathitt Gray
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
By the time request_region is called in the Intel ICH series GPIO
driver, a corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.Cc: Peter Tyser
Signed-off-by: William Breathitt Gray
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
By the time request_region is called in the AMD 8111 GPIO driver, a
corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.Signed-off-by: William Breathitt Gray
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
By the time request_region is called in the ACCES 104-IDIO-16 GPIO
driver, a corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.Signed-off-by: William Breathitt Gray
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
By the time request_region is called in the ACCES 104-IDI-48 GPIO
driver, a corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.Signed-off-by: William Breathitt Gray
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
By the time request_region is called in the ACCES 104-DIO-48E GPIO
driver, a corresponding device structure has already been allocated. The
devm_request_region function should be used to help simplify the cleanup
code and reduce the possible points of failure.Signed-off-by: William Breathitt Gray
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij -
The GPIO driver copyright boilerplate lacks the "or
later" verbiage regarding GPL compliant distribution. The MODULE_LICENSE
string should reflect the actual copyright license terms used.Signed-off-by: William Breathitt Gray
Signed-off-by: Linus Walleij
12 Feb, 2016
6 commits
-
Every time a descriptor is retrieved from the gpiolib, we issue
module_get() to reference count the module supplying the GPIOs.
We also need to call device_get() and device_put() as we also
reference the backing gpio_device when doing this.Since the sysfs GPIO interface is using gpiod_get() this will
also reference count the sysfs requests until all GPIOs are
unexported.Signed-off-by: Linus Walleij
-
Some information about the GPIO chip need to stay around also
after the gpio_chip has been removed and only the gpio_device
persist. The base and ngpio are such things, for example we
don't want a new chip arriving to overlap the number space
of a dangling gpio_device, and the chardev may still query
the device for the number of lines etc.Note that the code that assigns base and insert gpio_device
into the global list no longer check for a missing gpio_chip:
we respect the number space allocated by any other gpio_device.As a consequence of the gdev being referenced directly from
the gpio_desc, we need to verify it differently from all
in-kernel API calls that fall through to direct queries to
the gpio_chip vtable: we first check that desc is !NULL, then
that desc->gdev is !NULL, then, if desc->gdev->chip is NULL,
we *BAIL OUT* without any error, so as to manage the case
where operations are requested on a device that is gone.These checks were non-uniform and partly missing in the past:
so to simplify: create the macros VALIDATE_DESC() that will
return -EINVAL if the desc or desc->gdev is missing and just
0 if the chip is gone, and conversely VALIDATE_DESC_VOID()
for the case where the function does not return an error.
By using these macros, we get warning messages about missing
gdev with reference to the right function in the kernel log.Despite the macro business this simplifies the code and make
it more readable than if we copy/paste the same descriptor
checking code into all code ABI call sites (IMHO).Signed-off-by: Linus Walleij
-
This kind of hacks disturbs the refactoring of the gpiolib.
The descriptor table belongs to the gpiolib, if we want to know
something about something in it, use or define the proper accessor
functions. Let's add this gpiochip_lins_is_irq() to do what the
sunxi driver is trying at so we can privatize the descriptors
properly.Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Signed-off-by: Linus Walleij -
We need gpio_device to hold the descriptors so that they can
be lifecycled with the struct gpio_device held from userspace.
Move the descriptor array into gpio_device. Also rename it from
"desc" (singularis) to "descs" (pluralis) to reflect the fact
that it is an array.Signed-off-by: Linus Walleij
-
Since gpio_device is the struct that survives if the backing
gpio_chip is removed, move the sysfs mock device to this state
container so it becomes part of the dangling state of the
GPIO device on removal.Signed-off-by: Linus Walleij
-
When the device core reference count for the device goes to
0 and it calls .release() we free resources and so can also
finally free up the GPIO state container, struct gpio_device.Signed-off-by: Linus Walleij
11 Feb, 2016
1 commit
-
Driver for the GPIO block found in ti's tps65218 pmics.
The device has two GPIOs and one GPO pin which can be configured as follows:
GPIO1:
-general-purpose, open-drain output controlled by GPO1 user bit and/or
sequencer
-DDR3 reset input signal from SOC. Signal is either latched or
passed-trough to GPO2 pin. See below for details.
GPO2:
-general-purpose output controlled by GPO2 user bit
-DDR3 reset output signal. Signal is controlled by GPIO1 and PGOOD.
See below for details.
-Output buffer can be configured as open-drain or push-pull.
GPIO3:
-general-purpose, open-drain output controlled by GPO3 user bit and/or
sequencer
-reset input-signal for DCDC1 and DCDC2.The input configurations are not meant to be used by the user so the driver
only offers GPOs.v2: Added request routine that evaluates the fw config flags and removed module
owner
v3: Added .direction_input() routine, and took care of all Linus Walleij
suggestions (clamp to bool, use proper include)Signed-off-by: Nicolas Saenz Julienne
Signed-off-by: Linus Walleij
10 Feb, 2016
7 commits
-
Add driver for TI TPIC2810 8-Bit LED Driver with I2C Interface.
The TPIC2810 has 8 open-drain outputs that can but used to drive
LEDs and other low-side switched resistive loads.Signed-off-by: Andrew F. Davis
Signed-off-by: Linus Walleij -
Add generic parallel-in/serial-out shift register GPIO driver.
This includes SPI compatible devices like SN74165 serial-out shift
registers and the SN65HVS88x series of industrial serializers that can
be read over the SPI bus and used for GPI (General Purpose Input).Signed-off-by: Andrew F. Davis
Tested-by: Sean Nyekjaer
Signed-off-by: Linus Walleij -
Add myself to the copyright list and remove the reference to Atheros'
BSP as nothing is left of this code.Signed-off-by: Alban Bedel
Signed-off-by: Linus Walleij -
Add support for the interrupt controller using GPIOLIB_IRQCHIP.
Both edges isn't supported by the chip and has to be emulated
by switching the polarity on each interrupt.Signed-off-by: Alban Bedel
Signed-off-by: Linus Walleij -
As we now allow the driver to be built as a module it should be
removable.Signed-off-by: Alban Bedel
Signed-off-by: Linus Walleij -
To allow building the driver in compile tests we must drop the
dependency on asm/mach-ath79/ar71xx_regs.h. For this we replace the
include with local definition of the registers needed for this driver.Signed-off-by: Alban Bedel
Signed-off-by: Linus Walleij -
Drop most of the code in favor of the generic MMIO GPIO driver.
As the driver now depend on CONFIG_GPIO_GENERIC also add a Kconfig
entry to make the driver optional.We leave the base pointer and lock in the data struct because they are
needed for the IRQ support.Signed-off-by: Alban Bedel
Acked-by: Alexandre Courbot
Signed-off-by: Linus Walleij
09 Feb, 2016
3 commits
-
This marks the (optional) sysfs GPIO ABI as obsolete and schedules
it for removal in 2020.Cc: Johan Hovold
Cc: Michael Welling
Cc: Markus Pargmann
Signed-off-by: Linus Walleij -
Put in some documentation for the new character device ABI
so we can properly etch it in stone.Signed-off-by: Linus Walleij